18.2. Artifact Comments
SSDs, System Operations, Interaction Diagrams, and Use Case Realizations
In the current NextGen POS iteration we are considering scenarios and system operations identified on the SSDs of the Process Sale use case:
- makeNewSale
- enterItem
- endSale
- makePayment
If we use communication diagrams to illustrate the use case realizations, we will draw a different communication diagram to show the handling of each system operation message. Of course, the same is true for sequence diagrams. For example, see Figure 18.2 and Figure 18.3.
Figure 18.3. Sequence diagrams and system operation handling.
[View full size image]
Key Point The system operations in the SSDs are used as the starting messages into the domain layer controller objects. |
Use Cases and Use Case Realizations
Naturally, use cases are a prime input to use case realizations. The use case text and related requirements expressed in the Supplementary Specifications, Glossary, UI prototypes, report prototypes, and so forth, all inform developers what needs to be built. But bear in mind that written requirements are imperfectoften very imperfect.
Involve the Customer Frequently
The above section gives the impression that documents are the critical requirements input to doing software design and development. Truly, though, it is hard to beat the ongoing participation of customers in evaluating demos, discussing requirements and tests, prioritizing, and so forth. One of the principles of agile methods is "Business people and developers must work together daily throughout the project"a very worthy goal.
Operation Contracts and Use Case Realizations
As discussed, use case realizations could be designed directly from the use case text or from one's domain knowledge. For some complex system operations, contracts may have been written that add more analysis detail. For example:
Operation: | enterItem(itemID : ItemID, quantity : integer) |
Cross References: | Use Cases: Process Sale |
Preconditions: | There is a sale underway. |
Postconditions: |
|
Figure 18.4. Partial interaction diagram satisfies a contract postcondition.
[View full size image]
The Domain Model and Use Case Realizations
In the interaction diagrams, the Domain Model inspires some of the software objects, such as a Sale conceptual class and Sale software class. The existing Domain Modelas with all analysis artifactswon't be perfect; you should expect errors and omissions. You will discover new concepts that were previously missed, ignore concepts that were previously identified, and do likewise with associations and attributes.Must you limit the design classes in the Design Model to classes with names inspired from the Domain Model? Not at all. It's normal to discover new conceptual classes during design work that were missed during earlier domain analysis and to make up software classes whose names and purpose are completely unrelated to the Domain Model.