Assess the scope of analysis versus the scope of design.
The transition from analysis to design requires that you understand the difference between what was modeled in analysis and what you will
model in design. Throughout project initiation and problem analysis you proceeded under the assumption that the "system" you were modeling had
nothing at all to do with software and hardware.
Problem domain definition
The functionality (use case model ), the resources (object model ), and the interaction of the resources to support the
functionality (sequence and collaboration diagrams) would exist whether or not you ever provided automation. For example, in the
ticket sales system, you identified the need to set up the seating, set up shows, price the seating in the shows, and sell tickets. There is
nothing technological about these functions. In fact, they have been performed manually for centuries.
Use case model :The UML model used to represent clients' expectations about how they will interact with the system.
Object model: For many people this phrase is synonymous with class diagram. However, the model in a larger sense
also includes the object diagram and package diagram.
Sequence diagram: The UML diagram designed to model the interaction between objects overtime. The scope of the
diagram is typically a single scenario.
Collaboration diagram: One of the two UML standard interaction diagrams designed to model the communication between objects.
Preserve the problem domain model
Everything you defined in analysis must remain intact as you move into design. In fact, the analysis level object model will be the basis for
your database design. Few, if any, of the new objects added during design will become part of the database. Those that do will be added during
object design to improve performance, not functionality.
Design adds a layer of functionality on top of the analysis models. This layer is the software that facilitates the use of the problem domain
resources using interfaces, databases, transaction control, and communication that conforms to the use case model. This layer of technology
will likely change often, but the underlying problem domain will remain relatively stable.