Basic design principles.

-
Once you understand the requirement, how to propose high level architectural draft is the main question. There are some basic design principles, we can follow and come up with high level draft. 
1. Draw the boundary. 
You have to have a clear idea about what is in your application's scope and what is not, it is defined by client in the requirements. So draw the boundary and list out all internal and external sub -systems (who will give input to application and how, what all other external sub systems exist). That boundary will define the scope of the application.

 Boundary of the system is very important part of scope defining, it gives an idea what is there in designer's hand and what is external. Designer should not worry about anything which is external and not in his control while defining the system and its scope. 

 There is saying, focus more on what your system is not supposed to do, and don't implement that, make a release note and specify what it is not supposed to do, and then you can fully focus on what it supposed to do.

Before proceeding further let me tell you what is the system
It is made of two things -
a. Components/modules.
b. inner connections/(How some component will talk to each other).

You can also think of any software solution as a system which has many modules and how that modules interact to each other.

2. Design system as block box -
   
Only public behavior of the system should be shown to the outer world. All internal logic should be hidden from the client/user (or say an encapsulated system). To know more about black box system click here.

 3. Think about different actors or users of the system, like normal user, admin, privileged user, manager, accountant, etc..

 4. Components/modules should not interact with each other -

If you think about a very small application, where we have only 2 to 4 functionalities then this rule not applicable. As soon as your application becomes middle sized to a large enterprise solution/application you should follow this rule, otherwise code will become unmanageable and maintenance of the project will be very costly. There are so many pattern that fits into different places, on how module should interact with each other like - front controller architectural pattern, mediator design pattern, command design pattern etc.

 There are many concepts for designing high level design draft, I will add them periodically soon....
Thanks for reading it. To read more on design patterns and basic design principles please see my web page. You can also join me on FB or on G++. Please drop comments for any question related to this blog.

Comments

Post a Comment

Popular posts from this blog

Non-virtual interface idiom (NVI)

-
In almost every cases, it’s recommended to follow OOAD principles, but sometimes we should try to look some other alternatives, provided by programming languages, which could be a better options for certain situations. In C++, we can implement virtual function in private and we can redefine its behavior in derived class's private  and it will work in same way(did you try that?). When we define virtual function as private and expose a non-virtual public function to outer world, we call it “ non-virtual interface idiom ”. Non-virtual public function will internally call virtual function, in other words you are not exposing your virtual function to client. You will achieve high encapsulation, plus we can add pre and post execution/condition in the body of non-virtual public function. Call some set of functions, as prerequisite of calling virtual function, and after call returns from virtual function, again call some set of function as part of post cleanups/conditions,
Read more

Architectural patterns => Mud to structure => layers.

-
Image
Background - We apply mud to structure when a large system requires decomposition. If you notice, your application/requirement has verity of logical units which can be decomposed into a group of sub-tasks, first,  group them into different levels of abstraction. One abstract unit perform a totally different task(s) from other units, but any unit alone is not enough to give meaningful service to customer. Actually, different issues/solutions are splinted into different abstract units. Second,  after you divide them into different units, if you see a mix of low and high-level dependencies, where high-level operations depend on low-level operations, then assume those logical units as layers, third draw a dependency diagram between layers.  If control flows from high to low layer (or dependency diagram forms a stack, one layer on top of other), you can think of implementing it through layer pattern. Layer architecture - We can have many components in one layer. Layer
Read more

Architectural style -> Adoptable system -> Reflection.

-
Image
Background - We have discussed very less about reflection, especially if you are C, C++, mainframe, LSI developer and working on server side implementation or in low level hardware-interaction development team.  But it is very popular among high level languages like JAVA, Scala, C#, Python etc, many languages have implemented reflection in it.  It gives you flexibility to do things dynamically (at run-time). After working closely with different clients, you will get a clear understanding that no one is as confusing as a software client, not even your girlfriend! So we should have a flexible architecture in place who can absorb shocks of client’s last moment changes. Not only that, sometimes we have N number of different behaviors and structure in place, and we want our application to behave differently depending upon run-time situations. Let’s build understanding step by step through an example. Think you have got an assignment where you have to build an application
Read more