1. Lecture 4: Elaboration Tasks and Domain Modeling

2. 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. 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
...

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

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. Sample Partial Domain Model for Member Actor w/o Attributes

8. 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. Finding Concepts for a Domain Model
Look for noun and noun phrase identification from prose descriptions and use cases
Use generic concept category checklists
includes DM-oriented special kinds
description and event concepts

10. 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. 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. 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. 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. Associations Edges between nodes in a DM
Describe “semantically meaningful” relationships between concepts
May be annotated with roles and multiplicity designators

15. Domain Model Example

16. 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

18. 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. 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

21. 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. Attributes vs Associations?
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. Some Domain Model Do’s and Dont’s
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. Domain Model Example

25. Data Flow Diagram – Not a Domain Model

26. 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. 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