In the analysis phase, sequence diagrams were used to model the behavior and interactions between objects. In the design phase, sequence diagrams can be used to show the interaction and behavior required of real classes. These diagrams can be useful in discovering classes and more importantly are a real boon to development in that they outline the specific requirements and flows needed to solve problems. The sequence diagrams in this phase will model the classes along with their defined properties. There are no differences in terms of the diagram properties where UML is concerned. The difference is in the use of the diagram. The process used to design software can vary among designers so the use of sequence diagrams to some may appear to be superfluous. My own preference especially for very large projects is to start at a very high level during analysis and iteratively get more detailed towards actual construction. Depending on the project this may or may not make sense. Sometimes the diagrams built using the objects are enough to describe class behavior. Oftentimes they are not. Using our video example, we can sequence the operation of adding a video to the library.
![]() |
Notice the mixed use of objects and classes. The Rental System object creates and adds a Video class to the VideoCatalog. Depending on the design work being done, you may find it advantageous to show a boundary object (Rental System) working with the actual entity classes (Video, VideoCatalog) of the system.


Follow Us: