17.2. Object Design: Example Inputs, Activities, and Outputs
This section summarizes a big-picture example of design in an iterative method:
- What's been done?
Prior activities (e.g., workshop) and artifacts. - How do things relate?
Influence of prior artifacts (e.g., use cases) on OO design. - How much design modeling to do, and how?
- What's the output?
Especially, I'd like you to understand how the analysis artifacts relate to object design.
What Are Inputs to Object Design?
Let's start with "process" inputs. Assume we are developers working on the POS NextGen project, and the following scenario is true:
The first two-day requirements workshop is finished. | The chief architect and business agree to implement and test some scenarios of Process Sale in the first three-week timeboxed iteration. |
Three of the twenty use cases those that are the most architecturally significant and of high business valuehave been analyzed in detail, including, of course, the Process Sale use case. (The UP recommends, as typical with iterative methods, analyzing only 10%20% of the requirements in detail before starting to program.) | Other artifacts have been started: Supplementary Specification, Glossary, and Domain Model. |
Programming experiments have resolved the show-stopper technical questions, such as whether a Java Swing UI will work on a touch screen. | The chief architect has drawn some ideas for the large-scale logical architecture , using UML package diagrams. This is part of the UP Design Model. |
[1] Other artifact inputs could include design documents for an existing system being modified. It's also useful to reverse-engineer existing code into UML package diagrams to see the large-scale logical structure and some class and sequence diagrams.
Figure 17.1. Artifact relationships emphasizing influence on OO design.
[View full size image]
The use case text defines the visible behavior that the software objects must ultimately supportobjects are designed to "realize" (implement) the use cases. In the UP, this OO design is called, not surprisingly, the use case realization . | The Supplementary Specification defines the non-functional goals, such as internalization, our objects must satisfy. |
The system sequence diagrams identify the system operation messages, which are the starting messages on our interaction diagrams of collaborating objects. | The Glossary clarifies details of parameters or data coming in from the UI layer, data being passed to the database, and detailed item-specific logic or validation requirements, such as the legal formats and validation for product UPCs (universal product codes). |
The operation contracts may complement the use case text to clarify what the software objects must achieve in a system operation. The post-conditions define detailed achievements. | The Domain Model suggests some names and attributes of software domain objects in the domain layer of the software architecture. |
What Are Activities of Object Design?
We're ready to take off our analyst hats and put on our designer-modeler hats.Given one or more of these inputs, developers 1) start immediately coding (ideally with test-first development ), 2) start some UML modeling for the object design, or 3) start with another modeling technique, such as CRC cards.[2]
[2] All of these approaches are skillful depending on context and person.
test first p. 386 In the UML case, the real point is not the UML, but visual modelingusing a language that allows us to explore more visually than we can with just raw text. In this case, for example, we draw both interaction diagrams and complementary class diagrams (dynamic and static modeling) during one modeling day . And most importantly, during the drawing (and coding) activity we apply various OO design principles, such as GRASP and the Gang-of-Four (GoF) design patterns . The overall approach to doing the OO design modeling will be based on the metaphor of responsibility-driven design (RDD), thinking about how to assign responsibilities to collaborating objects.GRASP p. 277 435 276
This and subsequent chapters explore what it means to apply RDD, GRASP, and some of the GoF design patterns. |
What Are the Outputs?
UML data modeling profile notation p. 629)