iConcepts: Design, Architecture ,OOD and SOLID Programming (Snap Shots)

 Design, Architecture ,OOD and SOLID Programming (Snap Shots)
Hi Friends :
In practice, you will often find it difficult to differentiate architecture from detailed design”. And also adds: “You will not be alone, since experts generally agree about the broad strokes of architecture but disagree about the fine details, such as where architecture stops and detailed design begins”. Others say that architecture refers to high level details, and Design to low level details.
Where is the line that clearly separates what is Architecture and what is Design? Where Architecture stops and where Design begins? If you are presented with any kind of software diagram, is that Architecture or Design? Also, I have read about Modular Design and Modular Architecture, same concept with a different title, which one is the most appropriate? I will try to answer these questions.
The rule that I think we should use is: If the elements of a software diagram can be mapped one to one to a programming language syntactical construction, then is Design, if not is Architecture.
So, for example, if you are seeing a class diagram or a sequence diagram, you are able to map a class and their relationships to an Object Oriented Programming language using the Class syntactical construction. This is clearly Design. In addition, this might bring to the table that this discussion has a relation with the programming language you will use to implement a software system. If you use Java, the previous example applies, as Java is an Object Oriented Programming Language. If you come up with a diagram that shows packages and its dependencies, that is Design too. You can map the element (a package in this case) to a Java syntactical construction.
Now, suppose your Java application is divided in modules, and each module is a set of packages(represented as a jar file deployment unit), and you are presented with a diagram containing modules and its dependencies, then, that is Architecture. There isn’t a way in Java (at least not until Java 7) to map a module (a set of packages) to a syntactical construction. You might notice that this diagram represents a step higher in the level of abstraction of your software model. Any diagram above (coarse grained than) a package diagram, represents an Architectural view when developing in the Java programming language. On the other hand, if you are developing in Modula-2, then a module diagram represents a Design.
As a final more obvious example, a diagram that represents a layered style system, it is clearlyArchitecture. There is no way to map the element (layer) to a syntactical construction in any programming language (at least that I’m aware of).
The rule above is applicable to the activity too. If you are creating a Class diagram, then you are working on the Design of your software. And if you are creating a layered picture, then you are working on the Architecture of your software.
Reference Here :Resources
 Books References :
1.Software Architecture. Foundations. Theory and Practice.Taylor, Medvidovic and Dashofy.
2. Just Enough Software Architecture. A Risk-Driver Approach. George Fairbanks.
 10 Ways to improve your Software Architecture Design (By : Patrick Kalkman) 
Reference Source : Read Here
You can improve the quality of your Software Architecture Design by using the following 10 tips. I use these 10 tips or guidelines daily and they have helped me creating high quality Software Architectures. Describing your software architecture design is useful for any type of project, it will share the design of the system among your stakeholder.
My 10 ways:
  1. Based on non functional requirements

  2. Rationale, rationale, rationale

  3. Don’t Repeat Yourself

  4. Slice the cake

  5. Prototype

  6. Quantify

  7. Get it working, Get it right, Get it optimized

  8. Focus on the boundaries and interfaces

  9. The Perfect is the enemy of the Good

  10. Align with your stakeholders

1. Based on requirements
You should base your software architecture design on the requirements of your stakeholders. An architecture focuses on the non-functional requirements. I see many software architecture designs based on purely technical motives. Each part of your design should be based on business requirements. You as an architect should translate these requirements into the right architectural design decisions. If the stakeholder valuesmaintainability, you could use the layer pattern to separate several parts of the application. If performance is important, maybe layering is not a good solution. An exhaustive list of non-functional requirements can be found at ISO 9126 and at QUINT. If you do not use Non-functional requirements in your organization but want to introduce them,  take a look at this post.
From the Non-functional requirements or quality attributes you have to create the right design. While you could create this from scratch there are many examples in the form of design patterns or architectural patterns. A design or architectural pattern expresses a relation between a problem and a solution. Although we often think that our problem is unique this is often not the case. If you take a step back you will see that many of our problems already have been solved using existing patterns. Two books that I can recommend are “Pattern-Oriented Software Architecture” and “Design Patterns”. Both books contain a catalog patterns. Each pattern describes the problem it solves and in which context it can be used. There are also many online pattern source on the web such as this one on Wikipedia and this from The OpenGROUP
2. Rationale, rationale, rationale
The most important aspect of your architecture description is the recording of your rationale behind yourdesign decisions. It is important for a reader of the architecture description to understand the reason why you made a specific decision. Make your assumptions explicit and add them to the description. Assumptions may be invalid now or later but at least it will be clear how you came to that decision. It make communicating with your team (you do communicate do you?) that much easier if you share you rationale.
Note that recording your rationale become much easier if your non-functional requirements are explicit. It will be much clearer if you describe that you created several components to increase the testability because testability is the most important requirements. Do describe the Why and How in your software architecture design!
3. Don’t Repeat Yourself (DRY)
Don’t Repeat Yourself (DRY) or Duplication Is Evil (DIE) come from software-engineering in general. The DRY principle is stated as “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system”. You can apply this principle on many levels; Architecture, Design, Testing, Source Code and Data. For me this is one of the most difficult things to uphold. You have to fight the repetition because it will slow you and your project down. The difficult part of this Repetition Creep as I call it is that it is introduces very slowly. The first repetition won’t hurt you directly, it will even gain some time. You are able to release the first version of the application somewhat quicker, but as I found it always shows up later and makes something elsemore difficult. At that moment you regret the decision to introduce repetition.
If you absolutely must add another copy of information make sure that you automatically generate that copy of the information. It will make your live so much easier in the future. One thing that helps to fight repetition is to store the data where it belongs. This seems logical and is the basis of object oriented design but I often see thisviolated with regards to system architectures. For example take packaging an application for deployment. The process in which you filter the build of your software to include the components that are necessary in a package. Where would you store the information which component should be included in the package? You could create a list that includes the names of the components that should be packaged. That means you introduce your firstrepetition! You now have two places where component names are mentioned. A better solution would be to add that information to the component itself.
When the first list in any format shows up in or around an application, alarm bells should sound and you should be on the lookout for repetition!
4. Slice the cake
I struggled with naming this, but found Slicing the cake as it is called in Agile development the best description. By slicing the cake I mean that you design your architecture iterative in vertical slices. An architect implements or prototypes each vertical slice to confirm if it actually works. You should do this because architectures cannotbe created on paper. It does not mean that you cannot use horizontal layering or any other pattern in your architecture. In the case of layering the horizontal layers are smaller. The picture below shows the principle.
Say you use layering in your architecture design because your stakeholders expect that the components that you develop for this system will be used in other systems as well. During the first iteration you design a small part of the User Interface (UI), a small part of the Business Layer (BL) and a small part of the Data Layer (DL). You make sure that this works as expected by proving it with a prototype or by actually implementing it. In the second iteration you add new functionality and expand each layer horizontally with the needed functionality. The existing UI, BL and DL are combined with the new UI, BL and DL to form the new layers.
The difficulty with slicing is how to slice the cake so that the next slice will properly align with the previous.
5. Prototype
When creating a software architecture design make sure that you prototype your design. Validate your assumptions, do that performance test and make sure that the security architecture is valid. A prototype will give you the opportunity to fail fast which is a good thing.
6. Quantify
This principle extends the first principle “Based on Requirements”. To be able to create a proper software architecture design you need to quantify your Non-functional requirements. It should be “fast” cannot be a requirement neither is maintainable or testable. How will you know if you have met these requirements? You won’t.
ISO 9126 and QUINT both describe ways to quantify the non-functional requirements. For example testability specifies an indicator “number of test cases per unit volume”. QUINT also specifies how you can actually measure an indicator for example the indicator “Ratio Reused Parts” from the quality attribute Reusability which you can measure using the following protocol:
  1. Measure the size of each reused part;

  2. Measure the size of the entire software product;

  3. Calculate the ratio of reused parts, which is the sum of reused parts divided by (2).

7. Get it working, Get it right, Get it optimized
In many projects I have seen architects and developers design software architectures that focus on creatinggeneral purpose libraries, services or infrastructure. These are created without a direct reference to aconcrete application. Instead they are designing for tomorrow. This for me is like walking backwards, generality cannot be designed up-front. If you think, well… stop! you actually can’t. Today’s businesses changeway too fast to design for generality up-front.
You should always start with a concrete implementation for a specific problem. At the time you start working on the next application and find similarities, that’s the time to think about generalizing. This makes the first solution simpler, which should be your design goal.
8. Focus on the Boundaries and Interfaces
When creating your software architecture design you should focus on the boundaries of your system and components. When starting blank you should think about separation of concerns. What component or system has which responsibility? Between the components or system design explicit interfaces. Don’t separate a system of component when a lot of communication is necessary between these components or systems.
9. The Perfect is the enemy of the Good
The phrase “The perfect is the enemy of the good” from Voltaire is also valid for software architecture design. How many times have you started a new project and thought I want this project to be perfect? And how many times have you actually found out that the project wasn’t perfect. Well, guess what – a project will never be perfect. There will always be problems or forgotten requirements.
Perfection is never possible. However you are able to create a good software architecture design. Do not try to analyze everything during the start of the project it will slow you down. Watch out for Analysis Paralysis.
10. Align with your stakeholders
Before you can create any type of system you need to identify your stakeholders. Each stakeholder has different needs of your software architecture and may require a different view. Software developers may need descriptions using Unified Modeling Language (UML) while business sponsors need a description in natural language. Operations and support staff for example may need other view such as context diagrams.
There is a tension between creating all these views for stakeholders and principle 3. Don’t Repeat Yourself. Each view essentially describe the same system and adds repetition. Therefore you should only add those descriptions that adds value for a specific stakeholder.
SOLID PROGRAMMING :
Image
I explained SOLID Software development. SOLID is an acronym that stand for five principles for object-oriented development. SOLID stands for Single ResponsibilityOpen ClosedLiskov SubstitutionInterface Segregation and the Dependency Inversion Principle.
These principles can help a software developer manage dependencies between software components. Bob Martin the author of the principles writes So dependency management, and therefore these principles, are at the foundation of the -ilities that software developers desire”. You can read the original article here.
References : 1) Principle of OOD’s 2) Architecture VS Design 3) ARCHITECTURE ROLES AND RESPONSIBILITIES Read Here
 
Well there you have it, my 10 tips to improve your Software Architecture Design, SOLID and OOD Programming. If you have another tip that you use to improve your architecture design and other topics which discussed here. Welcome to hear your comments.
Thanks 🙂 Keep Coding 🙂

SolutionPointLogo

 

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s