Scenarios
I will assume for this exercise that the requirements have been captured or translated into use cases. The next stage is to examine the dynamic behavior of the system using scenarios, and UML sequence diagrams are the natural mechanism for this. Drawing the sequence diagrams verifies the relationships and interfaces that we identified in our package diagrams, and may identify some gaps in the design. Usually these gaps are the parts that require hand coding by the system integrator. The design of these hand-coded features can use traditional UML software design techniques, albeit constrained by the existing structure imposed by the packages being used in the system. The coding will often take the form of odd event-handling methods extending existing classes, or the creation of just one or two new classes. The focus of the design documentation for these stages must be on identifying which parts of which package have been modified, what the new classes look like, and where they exist within the system. A sequence diagram for a simple inbound call with a CRM screen pop might look something like the one shown in Figure 3 (telephony messages are represented by dotted lines).
){kind=link}
Call Center Sequence Diagram