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