Home >
Design
Software design: Basics are important
{ "Basics are important": [{ "Perceptions in software development": [ "We have to do Microservices using SpringBoot", "We have to learn these two" ], "Reality": [ "We have to implement solution of a requirement", "Requirements are complex as a whole", "Finding solution of a requirement as a whole is difficult", "If somehow we implement a system, it becomes complex, difficult to change and maintain", "Knowledge of NodeJS, SpringBoot doesn't help us" ], "Result": "We fail a project", "Why": [ "Because requirement is a complexity and", "We have to reduce this complexity by dividing it in to smaller parts", "We have to analyse the requirement" ], "Our perception of the solution": [ "Design", "Class" ], "What are we missing?": [ "We can't jump to the design before analysis", "We can't find out classes from the air", "We can't solve this complexity without taking a step by step computational thinking" ] }, { "What is the right approach": { "Use cases or scenarios": "Helps finding what a user requires or does with the system. This will help finding responsibilities later", "Domain Objects": "Real world entities, vocabulary of the domain, nouns or noun phrases. These objects will take responsibility of achieving what user wants", "CRC Card": "A good technique to find out responsibilities of Domain classes and any other class they will collaborate to achieve the scenarios", "Object responsibility assignment principles": "Certain principles help us assigning right responsibility to the right object", "Collaboration diagram": "For more complex scenarios to showcase collaboration of more than two objects", "Software classes": "Applying patters which are solution of recurring problems, we add more classes which are not domain objects but are software classes", "Class diagram": "Now you can have static view of the classes and their association without their properties and behaviors (responsibilities) in a model", "Iterate": "This is not a one time activity, in agile world you may have to iterate your model, starting with a small slice" } } ] } |
What users want in design?
Object oriented analysis & design
You can use a case tool or you can create UML diagrams in a white board and then take a picture of it or just draw them in a white sheet of paper. Case tool is not mandatory for good design. A) Managers are comfortable in power point and spread sheets and they would always prefer to show everything with spreadsheet. If you and your team is convinced, you can use spread sheet. B) Even if writing design in spread sheet looks too costly, go ancient way, write your design on walls and caves (obviously there are challenges while following this approach in office because there are limited walls in office). C) And finally if you still see challenges writing your design somewhere, you can think about it and keep it in your mind. How to convey it to others?, how to refer to it later? Leave it to god. The almighty will help at the time when it will be required, right now we are living in an agile world so do whatever takes less time and don't take pain in thinking about reviewing and giving feedback. D) There may be some one among us who may ask "why to do design at all?" Yes it is absolutely correct if your users or client asks what is needed (requirements are not written) and expectation is that programmers will write the code, client or users will see the output and if it is fine go ahead otherwise changes are suggested and programmers will write the code again. You may rely on programmers to think, understand and write code with best design decisions directly on IDE, nothing better than that. In any one of above cases, some one may be thinking about design even if directly writing the code. Good design skill is still required even if no design document is created. Good design principles are still applied. So let us see those principles and steps, which steps to follow and which one to escape depends upon team to team. Here are some steps to follow in "usecase driven analysis and design" of object oriented system: Object oriented analysisIdentify and describe your usecaseThis is not the focus of this topic hence not talking in detail but just to mention: for good object oriented design you should have your usecases identified. If in detail nothing like that. If usecases are not identified yet you will have to do iterations to complete them. Usecase is going to define needs, actors involved and constraints, business rules, validation rules and non functional requirements (special requirements). Otherwise how will you be able to take care of all these aspects in your design? In the name of Agile how much are you going to write your requirements and how formally are you going to define the business rules? It depends on different teams and set-up (people have defined their own methods to escape everything but to code so nothing is mandatory :) ). Less documentation may be fine (less formal) but even if you are discussing about important topics/aspects and making important decisions, you will have to put them somewhere? Identify domain objects:This is the place where you first introduce objects. Where do objects come from? How to identify objects? Answer is domain vocabulary. Objects should be representatives of the domain. Real world objects come to play role in the form of Java or .NET classes (class is not an object but a template to define them. Using a class you can create many objects).
Refine domain objects
Object oriented designObject oriented design is about identifying the objects, assigning them responsibilities, identifying their attributes and identifying relationship among objects (how they interact). There may be different ways to do design, one of which is usecase driven or requirement driven design. Another way may be database driven design. Apart from defining responsibilities you may have to decide if a class is going to aggregate other class or there is a composition required or not. If there is an opportunity to extend the class from a super class or a new super class needs to be designed. |
ClassName |
|
|
|
Use patterns
Solution to common problems. This will add software classes apart from domain classes you earlier identified in analysis.
Who should be given responsibility of doing something? One who has the information. If you want to get age of an Employee, it is Employee class who has the information so you will have to call it for getting age.
Who creates the objects of similar types or category? Normally a Factory pattern is used where Factory is called to create the object.
How to reduce network round trip or chatty interfaces with remote objects? Use Facade or synthetic object at remote to take one message from client and Facade calls other objects locally.
GoF or Gang of Four patterns are useful patterns to deal with commonly occurring problems and their solution through better design of objects.
Interesting Resources
1-3 of 3