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.
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