Home‎ > ‎Design‎ > ‎

Object oriented analysis & design

posted Feb 8, 2011, 8:53 PM by Jageshwar Tripathi   [ updated Jun 3, 2020, 1:42 PM ]
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.

Object oriented analysis and design is not about creating UML diagrams. Diagrams are a way to write your design decisions and give you a canvas to draw while you are thinking. I used them like mind maps. If you don't want to use UML to write and convey your design decisions for review and to be followed by programmers or your team, you can use other means of presenting your 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 analysis

Identify and describe your usecase

This 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). 
  • Read you requirement document or usecases carefully and see the nouns or noun-phrases. Yes believe me they come from there. 
  • They may also come from your historical knowledge of same domain and similar project/application
  • Remove duplicates: The nouns which may be same with little different name, eliminate the duplicates.
  • Identify attributes of the objects: Which information should they have? An employee should know about his name, age, department etc. These attributes may not be complete in one go but you may define few, high level first.
  • How are they (objects) related? Do they need help from each other or some how reference one another? If there are some who are related identify this relationship in a diagram called domain object model. 
  • Relationship may be association, aggregation or composition but don't stress too much very early about much detail and precision. Just define two objects are associated (association relationship). 
  • Sometimes people also define cardinality (one to one or one to many or many to many). Initially when you are doing analysis it is not mandatory. 

Refine domain objects

  • System sequence diagram: To refine this domain object model you can create a diagram which is called system sequence diagram. In this diagram an actor interacts with a context level object which is system. System here is represented as a blackbox and events starting from actor (user) to the system are drawn. It helps in understanding the usecase. It can be created  for main flow of a usecase and for those usecases which are complex. 
  • Note: For usecase estimation model analysis up to system sequence diagram is needed and I have seen use of system sequence diagram for this purpose in most of the cases where SSD were created. 
  • Analysis model: Defines how a usecase will be realised. It is logical structure of the usecase. Class diagram represent static structure and sequence diagram shows flow of event in a usecase. In theory you may define boundary, control and entity per usecase by doing SSD and model your domain objects better. When you have all the boundaries, control and entities known you can better know complexity of a usecase and size of the system. It is not a mandatory activity for estimation.that (in practice I have seen people guestimating without going to all this detail because they don't have opportunity to do it or may be there were some other limitations)  
  • Activity diagram: With activity diagram (which is kind of flowchart in UML) you are able to see how request will be processed. This may also help knowing behavior required by the user of a usecase and will help discovering complexity of a usecase. This is also not a mandatory thing to do (in practice I have seen very few people doing it). If you have to do it, it should be for complex usecases only. Why to waste time if things are clear :).

Object oriented design

Object 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.  
Identifying objects

We have already seen above in analysis how we find domain objects. Other objects are also identified which help in making design better and these objects which are our of domain vocabulary but come from software engineering are called software objects or these classes are called software classes. When design patterns are applied or any framework is used these software classes come in to picture. Some software classes are introduced when we apply some OOD principles of best design. See OOD principles and Use patterns sections bellow.

Assigning responsibilities to objects

Assigning responsibilities means identifying which object will do what. In most of the cases it is identifying methods of a class or messages an object will receive from other objects or actors. Some times objects may have responsibility of doing something when an event is fired.   

Sequence diagrams

Sequence diagrams in design help identifying messages to an object. When events from an actor to system are drawn and some of the objects in the system collaborate to realise the usecase messages are passed between objects, these messages become operations or methods of the objects. In design phase sequence diagram shows how system works.

Collaboration diagram

Some times collaborations diagrams are also created (with case tools they can be automatically generated if you have created sequence diagram. Collaboration diagrams are another representation of how objects collaborate in a usecase.

Use OOD principles: 

Separation of concerns

Software should be divided according to different aspect of the system. All the classes related so specific aspect should be kept in a layer. These layers dealing with different things should interact with each other through predefined contract or protocol. A layer (objects in that layer) should only interact with layer adjacent to it (object in adjacent layer). This way impact of changes in one layer can be limited to calling layer and it doesn't spread all over the system. Making changes and maintenance is easy in this case.
Example of layers may be Presentation (view), Controller, Business Logic, Data Access, Database
Model View Controller is one of the pattern for separation of concerns.

Principle of least knowledge

While design one object interacting with other object (to get some work done it calls a method of other object) it should not know internal state of the other object. Objects should interact through a standard predefined contact. For this purpose attributes of the classes are made private and if there is any access needed it is given by getters or setters. Giving direct access to attribute of an object may lead to uncontrolled change of state of the object. For example public attribute age of an Employee class can be set to negative ( - value) which is not correct in any case. If age is private and setter is provided, it can be controlled by checking in setter whether value being set is greater than zero or not.

Principle of single responsibility

Cohesiveness is the desired characteristic of an object. If an object is doing or dealing with multiple things handling it will be difficult. Its impact will be on many objects and larger part of the system. If there is an object which is dealing with many different responsibilities it should be split in to two objects. 

Principle of don't repeat yourself

During processing of business logic many objects may deal with some common business logic or processing. If this is repeated in many objects it becomes source of maintainability challenge. Higher maintenance cost of duplicate code is always higher.  Such common functionality should be taken out in the form of common object or reusable components.

Low coupling

To reduce coupling between two different types of objects or layers, a de-coupling object should be introduced which can insulate caller from change impact of called object or layer. One of the example is Web layer or controllers need to call a remote EJB and hence they have to lookup it, they know about its (EJBs) specific nature. In future if services of EJB are provided by a web-service, there will be a change needed in controller classes. To insulate them from impact of such changes a Business Delegate can be introduced between web layer and business login layer so that Business Delegate can handle any changes and web layer always considers it is communicating to a local object. 

CRC cards

Classes, Responsibility & Collaborators. It is a method of identifying classes, assigning responsibilities and their collaborators. In this method Name of classes on cards is written and a team role plays and defines responsibilities of the  class and its collaborator or class which this class interact with. A card has three areas: On the top name of the class, on the left: responsibilities of the class and on the right: its collaborators are written.
There is one basic tool specially for CRC card: https://echeung.me/crcmaker/

ClassName
  • Responsibility 1
  • Responsibility 2

 
  • Collaborator class 1
  • Collaborator class 2

 

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