Unified Modeling Language - Sequence Diagrams

After use case and class diagrams, sequence diagrams are important element to any design document. One issue with sequence diagram is, we can spend 12 hours to draw a diagram or 5 mins to do the same. But it all depends on each team's decision that how much time they want to spend on sequence diagrams. Sequence diagram comes handy when the system/product goes to maintenance mode or when ever new team takes over the system/product from current team.

The simple definition of sequence diagram is, explore the logic of complex function and how many objects required and how they interacts with each other to satisfy an use case. Not all use case required a sequence diagram, we can identify complex or most critical ones to be the candidate for sequence diagram.

Lets take a simple use case "add a product in shopping cart".
1. User enter user name and password in login screen.
2. System validates user and let user in the main page.
3. User select a product from product menu.
4. System adds the product into user's shopping cart.
5. User clicks checkout link.
6. System displays checkout page.

Based on above simple use case, we can draw a simple sequence like this

User -> Login - > main page -> Product catalog -> check out

Now we need to convert this simple sequence into objects

aLogin -> aProductCatalog -> aCheckOut -> aBusinessService

After second iteration, we identified that we need a business service to get products from a data base. After second iteration we have to put some more stress on aBusinessService, how it is going to get data, which pattern we are going to use to get data, how we are going to transfer the data etc.

aLogin - > aProductCatalog -> aCheckOut -> aLookUp -> aProductDTO -> aProductDAO

Ok. Now we have some decent sequence, lookup service going to get DAO reference and return to aProductCatalog and aProductCatalog executes getProducts method on aProductDAO, in return aProductDTO as value object. We have a good explained sequence here at high level.

DAO = Data Access Objects
DTO = Data transfer Objects

So we are moving towards Sun's J2EE design pattern here, hence it is good add a business delegate in front of aLookUp. Like wise, we can improve our design and apply design pattern after each iteration until we satisfy our design.

Here is excellent UML and applying design patterns book by Craig Larmen

UML - Use Case.

Use case is important for any software development. Use case is a structured way of describing a scenario. In extreme coding style, use case may not be a structured way rather it can be in a form of story telling. But some complex application required a structured way of use case so that we can discuss and brainstorm alternative scenarios and exception handling. The main input of use case is scenario like "buy a product". This detailed scenario can be found from "Product requirement document". But it won't describe well with in system level and who is going to execute this requirement etc. Use case is the only way to capture all those missing points from requirement document.

The main sections of use case are

1. Actors : Actors is nothing but users who is going to interact with system in real time. User can divide into their roles. So any given system, we can identify level of user roles well before implementation.

2. Use case text: This is the extension of a scenario, starts with pre-condition, main use case flow, exception and extensions. 

3. Use case diagram : Conceptional view of entire requirement. This can give us detailed view of all requirements and what can be reused(as includes) and what can be extend(as extends) and actors interacts with system. 

Unified Modeling Language(UML) - Class Diagrams.

First 2-3 years in start-up, we are always in hurry to code new features based on hallway, coffee break discussions. No documents, no design and no formal code comments also. After some point of time, our products are out there in market and everybody liked it. Now comes the documentation trouble, we have to document all, whatever we designed and developed in past, primarily in our mind. If you are designer, you no need to write 100-200 pages document describing what you did. All we need are excellent diagrams, sketches and flow from start to end. UML is the only way to achieve this.

UML is not a strict language, in other words, there is no compiler out there to check our code against standards. A rough sketch can do the purpose. UML is useful on both forward and reverse engineering. The main component of UML is class diagrams, there is almost none design document without class diagrams. In class diagrams, the following notations and relationships are really important. This class diagrams are going to be a blue print for long time, hence this notations are important to communicate because we don't know whether designer who developed this diagram going to be with company or not.

1. Associations
In Class diagrams, if a class associate with other class, the a solid line with a arrow, from source to target. A perfect example would be, Customer and Order class. Order class must give a customer id, who created order. Since we can identify an unique customer id from order, Order class has an association with Customer class, that same with customer class also, from customer class we can find orders by the customers.

2. Compositions
A class can have other class's reference in it. This is useful when we want to utilize other class's methods without inheritance. Decorator pattern is mainly based on compositions.

3. Generalization
This is for grouping similar classes, to add these similar methods in a super class and all other classes are derived(inheritance) from it. This is nothing but super class and sub class notation in UML.

4. Aggregation
Aggregation and association are interchangeable. There is no major difference between them. A car has an engine, then car (whole) has a aggregation relationship with engine (part). To make our life simple, we can use association notation instead of aggregation. Most of the UML gurus discourage us to use aggregation notation in class diagram. We can just use association for top level design and composition and aggregation can be used in detailed design.

5. Realization
Realization is relationship between an interface and implements class. The interface specifies behaviours and a class implements that behaviour then the class realize relationship with interface.

6. Dependency
Dependency relationship as name implies, if one class change, other class's state changes then these two classes are dependency relationship. MVC pattern can be good example of dependency relationship.

The other important elements from class diagrams are multiplicity (upper bound..lower bound), Stereotype, visibilities and properties.