8 . Iteration 1 Basics & 9. Domain Models I

1. 8. Iteration 1 Basics & 9. Domain Models I CSE 5324 Quiz 7 due at 5 PM, Tuesday, 9 September 2014

2. 8. Iteration 1 –Basics • Objectives: • Define the elaboration phase’s first iteration. • Describe key inception and elaboration phase concepts.

3. 8.1 Iteration 1 Requirements & Emphasis: Core OOA/D Skills • Iteration 1 requirements normally would be architecture-centric (i.e., core software first) and risk-driven (i.e., prove feasibility early). • But this chapter emphasizes a simple happy path use case for instructional purposes.

4. 8.2 Process: Inception • Inception creates incomplete artifacts, which show feasibility, risk, scope and confidence in the project’s future. • It names most actors, goals and use cases. • It fully dresses 10-20% of named use cases. • It drafts the Vision and Supl Spec artifacts. • Its interface prototypes prove concepts. • It identifies external parts and tools to buy. • It plans the first iteration.

5. 8.2 Process: Elaboration Table 8.1 Sample elaboration artifacts (excluding those started in inception). • Elaboration’s initial series of iterations programs (with production quality) and tests the risky core software architecture. • It discovers & stabilizes most requirements. • It mitigates or retires the project’s major risks. • It estimates overall schedule and resources. • It adapts plans based on developer feedback. • It writes all named use cases and other requirements in fully-dressed detail. • It drafts the Domain, Design and Data Models, as well as the Software Architecture Document.

6. 8.3 Planning the Next Iteration • Project management plans high-ranking tasks: • Risk: technical complexity, uncertainty, usability. • Coverage: wide impact & shallow subsystems. • Criticality: client’s high business values. • High-ranking tasks must be completed early. • Keep an ordered list of use cases and features.

7. R U O K ? • Iteration 1 requirements are… __ • Architecture-centric (i.e., core software first). • Risk-driven (i.e., prove feasibility early). • A simple happy path. • Both a and b. • None of the above.

8. R U O K ? 2. Which of the following is NOT part of the inception phase? __ • Creating complete artifacts to show feasibility, risk, scope and confidence in the project’s future. • Naming most actors, goals and use cases. • Fully dressing 10-20% of named use cases. • Drafting Vision and Supplementary Specification artifacts. • Using interface prototypes to prove concepts. • Identifying external parts and tools to buy. • Planning the first iteration.

9. R U O K ? 3. Which of the following is NOT part of the elaboration phase’s initial series of iterations? __ • Writing production quality computer programs. • Testing risky core software architecture. • Discovering & stabilizing most requirements. • Mitigating or retiring all project risks. • Estimating overall schedule and resources. • Adapting plans to developer feedback. • Writing all named use cases and other known requirements in fully-dressed detail. • Drafting the Domain, Design and Data Models, and the Software Architecture Document.

10. R U O K ? 4. Which of the following would qualify for early scheduling by project management? __ • High risk tasks: technical complexity, uncertainty, usability. • Wide coverage use cases: shallow subsystems with wide impact. • Mission critical features: client’s suggested high business values. • All of the above. • None of the above.

11. 9. Domain Models Figure 9.1 Sample UP artifact influence. • Objectives: • Identify current iteration’s conceptual classes. • Create initial domain model. • Also model attributes (objects) and associations (methods). • This initial OOA model inspires the creation of software objects in the domain-layer Design Model, as it fuels many case study artifacts. • Emphasize skillful OOA, not pretty UML.

12. 9.1 Example Figure 9.2 Partial domain mode –a visual dictionary. • Use UML class diagram notation to illustrate NextGenrequirements in a conceptual perspective model, which shows: • This real domain’s significant conceptual classes. • Meaningful relationships among those classes. • Attributes that we care about; e.g., date & time. • Quickly and skillfully identify a rich set of conceptual classes, to inspire later designs.

13. 9.2 What is a Domain Model? Figure 9.5 A conceptual class has a symbol, intension and extension. • A domain model is a visual representation of real-situation (not software) conceptual classes. • A conceptual class is… • Symbol: a word or image of a real ideaor thing; e.g., Sale. • Intension: a noun-phrase definition; e.g., purchase event. • Extension: a set of illustrative examples; e.g., car purchase. • Decomposing a domain into noun-phrase concepts (no verbs) is the most important part of OOA. • English dictionaries offer many definitions of every word. As a “visual dictionary,” the domain model sharply pictures specific meanings by relating conceptual words to each other.

14. 9.3 Why Create a Domain Model? Figure 9.6 Reducing the representational gap with OO modeling. • A Domain Model provides class names that bridge the gap between reality and the software’s UML domain layer (object model) diagram. • Imagine the gap between our mental model of the payroll domain and this c.1953 payroll program: 0011011101010010110011010100… • OO also helps design loosely coupled systems that scale and extend easily, as well as manage and hide complexity.

15. 9.4 How to Create a Domain Model • Model classes of the current iteration only. • Find conceptual classes (see next slide). • Draw them on a UML class diagram (e.g., Figure 9.2, p.133). • Add associations (§9.14) & attributes (§9.16).

16. 9.5 Find Conceptual Classes 3 Ways Table 9.1 Conceptual Class Category List. • Reuse existing model patterns: see Fowler, Hay and Silverston’s books in §9.14, pp.170. • Use a category list: see Table 9.1, pp.140-1, for categories related to business information system, POS terminal, board game and airline reservation domains. • Simply identify noun phrases: highlight the nouns in a fully dressed use case (e.g., Process Sale, pp.142). (Warning: sometimes English nouns are ambiguous, or they map indirectly into classes or not at all.)

17. R U O K ? 5. Which of the following is NOT characteristic of the initial OOA Domain Model? __ • It inspires the creation of software objects in the domain-layer Design Model. • It fuels many case study artifacts. • It produces pretty UML diagrams. • Actually all of the above are Domain Model characteristics.

18. R U O K ? 6. Which of the following does a conceptual perspective model NOT show? __ • Unambiguous UML class diagram notation. • System software requirements. • The real problem domain’s significant conceptual classes. • Meaningful relationships among those classes. • Attributes that the customer cares about. • A quickly and skillfully identified rich set of software classes, which will appear in subsequent design diagrams.

19. R U O K ? Match the following terms with their definitions below. 7. Domain model __ 8. Conceptual class __ 9. Symbol __ 10. Intension __ 11. Extension __ • Noun-phrase definition; e.g., a purchasing event. • Word or image of a real idea or thing; e.g., Sale. • Set of illustrative examples; e.g., a car purchase. • Visual representation of real-situation (not software) conceptual classes. • Symbol, intension or extension.

20. R U O K ? 12. What is the most important part of OOA? __ • Decomposing a domain into noun-phrase concepts (no verbs). • Drawing unambiguous UML diagrams. • Providing a “visual dictionary,” which sharply pictures specific meanings by relating conceptual words to each other. • All of the above.

21. R U O K ? 13. Which of the following justify creating a Domain Model? __ • It provides class names that bridge the gap between reality and the software’s UML domain layer (object model) diagram. • It helps design loosely coupled systems. • It scales and extends easily. • It manages and hides complexity. • All of the above. • None of the above.

22. R U O K ? 14. How does one create a domain model? __ • Consider only the current iteration’s fully dressed use cases. • Find conceptual classes in existing patterns, in a category list or in simple noun phrases. • Draw those classes on a UML class diagram. • Add association connectors. • Add attribute objects. • All of the above.