Page 319 -

286 Part 3 • the analysis Process

model describes the use cases and actors. The object model describes the objects and object asso-
ciations, and the responsibilities, collaborators, and attributes of the objects.
1. Define the use case model:
• Find the actors in the problem domain by reviewing the system requirements and inter-
viewing some business experts.
• Identify the major events initiated by the actors and develop a set of primary use cases
at a very high level that describe the events from the perspective of each actor.
• Develop the use case diagrams to provide understanding of how the actors relate to the
use cases that will define the system.
• Refine the primary use cases to develop a detailed description of system functionality
for each primary use case. Provide additional details by developing the use case sce-
narios that document the alternate flows of the primary use cases.
• Review the use case scenarios with the business area experts to verify processes and
interactions. Make modifications as necessary until the business area experts agree that
the use case scenarios are complete and accurate.
2. Continue UML diagramming to model the system during the systems analysis phase:
• Derive activity diagrams from use case diagrams.
• Develop sequence and communication diagrams from use case scenarios.
• Review the sequence diagrams with the business area experts to verify processes and
interactions. Make modifications as necessary until the business area experts agree that
the sequence diagrams are complete and accurate. This additional review of the graphi-
cal sequence diagrams often provides the business area experts an opportunity to rethink
and refine processes in more atomic detail than the review of the use case scenarios.
3. Develop the class diagrams:

• Look for nouns in use cases and list them. They are potential objects. Once you identify
the objects, look for similarities and differences in the objects due to the objects’ states
or behavior, and then create classes.
• Define the major relationships between the classes. Look for “has a” and “is a” relation-
ships between classes.
• Examine use case and sequence diagrams in order to determine classes.
• Beginning with the use cases that are the most important to the system design, create class
diagrams that show the classes and relationships that exist in the use cases. One class dia-
gram may represent the classes and relationships described in several related use cases.
4. Draw statechart diagrams:
• Develop statechart diagrams for certain class diagrams to provide further analysis of the
system at this point. Use statechart diagrams to aid in understanding complex processes
that cannot be fully derived by the sequence diagrams.
• Determine methods by examining statechart diagrams. Derive state (data) class attri-
butes from use cases, business area experts, and class methods. Indicate whether the
methods and attributes of the class are public (accessible externally) or private (internal
to the class). The statechart diagrams are extremely useful in modifying class diagrams.
5. Begin systems design by refining UML diagrams and using them to derive classes and their
attributes and methods:
• Review all existing UML diagrams for the system. Write class specifications for each
class that include the class attributes, methods, and their descriptions. Review sequence
diagrams to identify other class methods.
• Develop methods specifications that detail the input and output requirements for the
method, along with a detailed description of the internal processing of the method.
• Create another set of sequence diagrams (if necessary) to reflect the actual class meth-
ods and interactions with each other and the system interfaces.
• Create class diagrams, using the specialized class symbols for boundary or interface
class, entity class, and control class.