CHAPTER : 12 FROM REQUIREMENTS TO DESIGN IN THIS ITERATION

Introduction: So far, the case study has emphasized investigation of the requirements, concepts, and operations related to a system. Following the UP guidelines, perhaps 10% of the requirements were investigated in inception, and a slightly deeper investigation was started in this first iteration of elaboration.

The following chapters are a shift in emphasis toward designing a solution for this iteration in terms of collaborating software objects. Iteratively Do the Right Thing, Do the Thing Right :

The requirements and object-oriented analysis has focused on learning to do the right thing; that is, understanding some of the outstanding goals for the Next-Gen POS, and related rules and constraints. By contrast, the following design work will stress do the thing right; that is, skillfully designing a solution to satisfy the requirements for this iteration.

In iterative development, a transition from primarily a requirements focus to primarily a design and implementation focus will occur in each iteration. Furthermore, it is natural and healthy to discover and change some requirements during the design and implementation work of the early iterations. These discoveries will both clarify the purpose of the design work of this iteration and refine the requirements understanding for future iterations.

Over the course of these early elaboration iterations, the requirements discovery will stabilize, so that by the end of elaboration, perhaps 80% of the requirements are reliably defined in detail.

Didnt That Take Weeks To Do? No, Not Exactly. After many chapters of detailed discussion, it must surely seem like the prior modeling would take weeks of effort. Not so. When one is comfortable with the skills of use case writing, domain modeling, and so forth, the duration to do all the actual modeling that has been explored so far is realistically just a few days. However, that does not mean that only a few days have passed since the start of the project. Many other activities, such as proof-of-concept programming, finding resources (people, software, ...), planning, setting up the environment, and so on, could consume a few weeks of preparation.

On to Object Design

During object design, a logical solution based on the object-oriented paradigm is developed. The heart of this solution is the creation of interaction diagrams, which illustrate how objects collaborate to fulfill the requirements. After or in parallel with drawing interaction diagrams, (design) class dia-grams can be drawn. These summarize the definition of the software classes (and interfaces) that are to be implemented in software.

In terms of the UP, these artifacts are part of the Design Model. In practice, the creation of interaction and class diagrams happens in parallel and synergistically, but their introduction is linear in this case study, for simplicity and clarity.

The Importance of Object Design Skill vs. UML Notation Skill

The following chapters explore the creation of these artifacts, or more precisely, the object design skills underlying their creation. What is imp how to think and design in objects, which is a very different and much more important ability than knowing UML diagramming notation. At the same time, a standard visual language is great, and thus the required UML notation to support the design work is presented.

Of the two artifacts that will be explored, interactions diagrams are the most important from the point of view of developing a good design and require the greatest degree of creative effort. The creation of interaction diagrams requires the application of principles for assigning responsibilities and the use of design principles and patterns. Therefore, the emphasis of the following chapters is on these principles and patterns in object design.