1. Copyright W. Howden1 Lecture 4: Elaboration Tasks and Domain Modeling

2. Copyright W. Howden2 Elaboration Tasks Explore concepts from requirements use cases Discovering the basic pieces of the design? Functional design: –functions in the top down abstraction Object oriented design –choice of system architecture –class concepts in “domain model”

3. Copyright W. Howden3 Stable System Design and Domain Concepts Systems change due to: –Incremental development, changing requirements, post deployment enhancement Domain modeling and design for change –Use basic classes that are a kind of simulation of the problem domain –Functionality is added to simulation so it can be removed and changed

4. Sample Basic Domain Concepts in DS dating system member date preferences dater characteristics matching dates administrator date request... Copyright W. Howden4

5. Sample Potential Functionality in DS Finding a date or set of possible dates Survey of characteristics of DS members Average frequency of date requests per member Profiles of most frequently selected datees Report of number of times a dater has changed his/her dater properties Copyright W. Howden5

6. 6 Domain Model Graphical model of basic domain concepts and their relationships Nodes: Concepts May have attributes - properties of concepts-classes Edges: Relationships between concepts called “associations” Drawn using the UML Class Diagrams

7. Copyright W. Howden7 Sample Partial Domain Model for Member Actor w/o Attributes

8. Copyright W. Howden8 DM Concept Attributes Included in the DM node for the concept –If not enough room show them in separate document. Sample attributes for DS DM

9. Copyright W. Howden9 Finding Concepts for a Domain Model Look for noun and noun phrase identificationfrom prose descriptions and use cases Use generic concept category checklists –includes DM-oriented special kinds description and event concepts

10. Copyright W. Howden10 Sample Nouns and Noun Phrases for DS User Dating System LogOn Member Member Option Choice Error Messag MatchingDates GetADate DataBase SetMemberData Preferences DateDescription NoDateMessage MemberData PersonalProps

11. Copyright W. Howden11 Concept Categories and the DS Concepts Physical Objects: user, member Descriptions: personal props, prefs., dates Roles: member, dater, administrator Containers: DS Data Base Organizations: DS Accounting Dept. Events: logon, getADate, SetMemberData Abstract nouns: session

12. Copyright W. Howden12 Descriptions as Domain Model Concepts Descriptions of other concepts that have a lifetime of their own –E.g. dater properties in Dating System May be stored in data base May be changed

13. Copyright W. Howden13 Events as DM Concepts Things to which system will have to respond –E.g. logon, date-request Event objects created and passed to class/object having responsibility for handling them Or, event objects contain knowledge of how to perform the responsibility (in one of their methods)

14. Copyright W. Howden14 Associations Edges between nodes in a DM Describe “semantically meaningful” relationships between concepts May be annotated with roles and multiplicity designators

15. Copyright W. Howden15 Domain Model Example

16. Copyright W. Howden16 Association Annotations 1 Kind of relationship, sometimes referred to as a role. In DS DM example –part of, contained in –described by, identifies (used with description concept) –captured on, initiates (used with events)

17. Association Annotations 2 Multiplicity e.g. A 1- 1 B means for every instance of an A there is 1 instance of a B e.g. A 1-* B means for every instance of an A there is 0 or more B instances Direction –various interpretations. Some relationships are inherently directional e.g. part-of, initiates Copyright W. Howden17

18. Copyright W. Howden18 Finding Associations Look in use cases for relationships that are: –Needed for operation of system –Have a lifetime of importance Good link: between DS Member and MemberProperties Bad link: between Administrator and GetaDate request - not needed. Use generic association category checklists

19. Copyright W. Howden19 Association Category Checklists A is a physical or logical part of B –E.g. Personal Characteristics are part-of Dater Properties A is physically or logically contained in B –E.g. MembershipData contained-in MemberDB A is described by or identified by B Special event-oriented relationships

20. Special Event-Oriented Relationships Actors perform actions/requests that are modeled as events concepts in the DM An event is associated with an actor (concept) that initiates that event –E.g. Member initiates getDate Each event is handled by or captured on some entity concept Copyright W. Howden20

21. Copyright W. Howden21 Description Associations vs Attributes – Why Associations? Allows postponing of details Leads to a design that facilitates change Recognizes that some kinds of properties/descriptions may have a life of their own E.g. may want to treat member descriptions independently of members for the purposes of a catalog of profiles

22. Copyright W. Howden22 Attributes vs Associations? Attributes Should have primitive data type values Associations If property is a (complex) object, should be a separate concept with a linking association E.g. Dater has Dater Properties. This is a complex object and should be its own concept. Linking association:

23. Copyright W. Howden23 Some Domain Model Do’s and Dont’s Do –Static Model E.g. Parts explosion diagram –Real World Concepts E.g. Gender Preference in Dating System Application –Do not be afraid to overdo concept list Don’t –Dynamic Flow Chart One entity sends a message to another –Software Entities E.g. GenderPrefTextString –Leave out concepts

24. Copyright W. Howden24 Domain Model Example

25. Data Flow Diagram – Not a Domain Model

26. Copyright W. Howden26 UML and Domain Models UML does not include Domain Models UML class diagrams –can be used for several purposes –Conceptual classes as in Domain Model Attributes but no methods –Design classes from design activities Graphical representation of PL classes

27. Copyright W. Howden27 Use Cases, Domain Models and System Increments Use cases are constructed for the whole system Original domain model is for first phase/iteration only At the beginning of each new iteration, the previous domain model is augmented to include concepts in the next iteration

28. Assignment 3 Construct a domain model for the first increment (phase 1) of your project Copyright W. Howden28