5 basic design parameter of a good design.

Many things that come into the picture when we say evaluation of a software design. One necessary quality of an architectural design is to handle non-functional requirement. Software has to meet functional needs but how well non-functional requirements are taken care of by architecture makes software, great software.

Five primary design parameter of good designs are -

  1. Usability 
    1.  It is all about how a simple system is designed and defined for user to use.
    2. With the minimum input. How can you give maximum result effortlessly and efficiently? For example, Google search engine, how simple it looks, and the most straightforward web page to use, but the powerful at the same time.
    3. It's not about the result; it's about the best result (or maximum relevant result). For example, in your phone book – after typing "a" you should not get all names who have alphabet "a". You should get all names which start with alphabet "a".
    4. If you are a library developer, try to create Black box systems. For other software developers, who will use your library, black-box are more useful than white-box systems. It will increase the usability of your library. Because in black box system there is no need for the user to remember or know. All the methods defined inside the system; he will see the public behavior of the system and call according to their need.
  2. Performance –
    1. No need to say more here; it has been a critical area for all users. If we have made the best robust system in this world, but it works very slow, no client will turn up to buy it.
    2. Sometimes client compromises on some functionality but takes the product if it is fast.
  3.  Flexibility –
    1. To achieve this. Your solution has to work like a black box system. Whatever you do inside ( core logic), the client will not be affected. The application has to perform the same way it was designed before; with better core logic to make the system even faster and robust. 
    2. There are three kinds of flexibility –
      1. Structural flexibility – When we make any changes in structure (i.e., adding new modules, deleting some module, etc.) it should not change the behavior of the entire system.
      2. Behavioral flexibility – Changing one behavior (any function inside the module) should not affect any other independent behavior. 
      3. Creational flexibility -  Classes are just blueprints, but objects are the one who lives in your memory (RAM). Creating a new object or deleting old objects, shall not disturb/corrupt the existing setup of objects currently part of the process in memory.
  4. Security –
    1. There are two types of security –
      1. Structural – Internal components of the system should not shown to the outer world. If you show all your internal component (how they interact with each other and what are their signature and how we can call them), it will become a very vulnerable system; anyone can hack it easily.
      2. Behavioral – All behavior should not be visible to all actors of the system. For example – a user of application should not know (or have access) of admin modules of that system. Only admin can see (or access) admin related functionalities and vice versa.
  5. Accountability –
    1. Do we have any component in the system who is responsible for completing any particular task? A task may consist of many subtasks, which should have one capable module. Which should take care of the completion of those sub-tasks; to maintain atomicity.
    2. For example – it should not happen that money is deducted from your account but not credited into other account due to some system error. Either the task should get completed or aborted (to maintain atomicity in system).




Thanks for reading it. To learn more about design patterns and basic design principles, please see my web page.

Comments

  1. This comment has been removed by the author.

    ReplyDelete
  2. A clear and concise explanation of the concepts. For a newbie like I found it a great place to start my learning of System Architecture.

    Thanks for this Article. :)

    ReplyDelete

Post a Comment

Popular posts from this blog

Non-virtual interface idiom (NVI)

Architectural patterns => Mud to structure => layers.

Architectural style -> Adoptable system -> Reflection.