Copyright W. Howden*Lecture 4: Elaboration Tasks and Domain Modeling

Copyright W. Howden

Copyright W. Howden*Elaboration TasksExplore concepts from requirements use casesDiscovering the basic pieces of the design?Functional design: functions in the top down abstractionObject oriented designchoice of system architectureclass concepts in domain model

Copyright W. Howden

Copyright W. Howden*Stable System Design and Domain ConceptsSystems change due to:Incremental development, changing requirements, post deployment enhancementDomain modeling and design for changeUse basic classes that are a kind of simulation of the problem domainFunctionality is added to simulation so it can be removed and changed

Copyright W. Howden

Sample Basic Domain Concepts in DSdating system memberdate preferencesdater characteristicsmatching datesadministratordate request...

Copyright W. Howden*

Copyright W. Howden

Sample Potential Functionality in DSFinding a date or set of possible datesSurvey of characteristics of DS membersAverage frequency of date requests per memberProfiles of most frequently selected dateesReport of number of times a dater has changed his/her dater propertiesCopyright W. Howden*

Copyright W. Howden

Copyright W. Howden*Domain ModelGraphical model of basic domain concepts and their relationshipsNodes: ConceptsMay have attributes - properties of concepts-classesEdges: Relationships between concepts called associationsDrawn using the UML Class Diagrams

Copyright W. Howden

Copyright W. Howden*Sample Partial Domain Modelfor Member Actor w/o Attributes

Copyright W. Howden

LogOn

SetMemberData

GetADate

Preferences

DatingSystem

NoDateMessage

DateDescription

DataBase

MemberData

PersonalProps

Member

3 initiates

*

1

1

*

3 initiates

*

*

captured on4

*

1

*

1

captured On

*

1

displays

*

1

displays

1

*

HasA

1

1

partOf

1

1

identifies4

1

*

describedBy4

1

1

3 partOf

1

1

3 contained in

1

*

Copyright W. Howden*DM Concept AttributesIncluded in the DM node for the conceptIf not enough room show them in separate document.Sample attributes for DS DM

Copyright W. Howden

-Name: : string-UserType : char

Logon

-Gender : bool-Religion : string-Occupation : string

SetMemberData

Copyright W. Howden*Finding Concepts for a Domain ModelLook for noun and noun phrase identificationfrom prose descriptions and use casesUse generic concept category checklistsincludes DM-oriented special kindsdescription and event concepts

Copyright W. Howden

Copyright W. Howden*Sample Nouns and Noun Phrases for DSUserDating SystemLogOnMemberMember Option ChoiceError MessagMatchingDatesGetADateDataBaseSetMemberDataPreferencesDateDescriptionNoDateMessageMemberDataPersonalProps

Copyright W. Howden

Copyright W. Howden*Concept Categories and the DS ConceptsPhysical Objects: user, memberDescriptions: personal props, prefs., datesRoles: member, dater, administratorContainers: DS Data BaseOrganizations: DS Accounting Dept.Events: logon, getADate, SetMemberDataAbstract nouns: session

Copyright W. Howden

Copyright W. Howden*Descriptions as Domain Model ConceptsDescriptions of other concepts that have a lifetime of their ownE.g. dater properties in Dating SystemMay be stored in data baseMay be changed

Copyright W. Howden

Copyright W. Howden*Events as DM ConceptsThings to which system will have to respondE.g. logon, date-requestEvent objects created and passed to class/object having responsibility for handling themOr, event objects contain knowledge of how to perform the responsibility (in one of their methods)

Copyright W. Howden

Copyright W. Howden*AssociationsEdges between nodes in a DMDescribe semantically meaningful relationships between conceptsMay be annotated with roles and multiplicity designators

Copyright W. Howden

Copyright W. Howden*Domain Model Example

Copyright W. Howden

LogOn

SetMemberData

GetADate

Preferences

DatingSystem

NoDateMessage

DateDescription

DataBase

MemberData

PersonalProps

Member

3 initiates

*

1

1

*

3 initiates

*

*

captured on4

*

1

*

1

captured On

*

1

displays

*

1

displays

1

*

HasA

1

1

partOf

1

1

identifies4

1

*

describedBy4

1

1

3 partOf

1

1

3 contained in

1

*

Copyright W. Howden*Association Annotations 1Kind of relationship, sometimes referred to as a role. In DS DM examplepart of, contained indescribed by, identifies (used with description concept)captured on, initiates (used with events)

Copyright W. Howden

Association Annotations 2Multiplicitye.g. A 1- 1 B means for every instance of an A there is 1 instance of a Be.g. A 1-* B means for every instance of an A there is 0 or more B instancesDirectionvarious interpretations. Some relationships are inherently directional e.g. part-of, initiatesCopyright W. Howden*

Copyright W. Howden

Copyright W. Howden*Finding AssociationsLook in use cases for relationships that are:Needed for operation of systemHave a lifetime of importanceGood link: between DS Member and MemberPropertiesBad link: between Administrator and GetaDate request - not needed.Use generic association category checklists

Copyright W. Howden

Copyright W. Howden*Association Category ChecklistsA is a physical or logical part of BE.g. Personal Characteristics are part-of Dater PropertiesA is physically or logically contained in BE.g. MembershipData contained-in MemberDBA is described by or identified by BSpecial event-oriented relationships

Copyright W. Howden

Special Event-Oriented RelationshipsActors perform actions/requests that are modeled as events concepts in the DMAn event is associated with an actor (concept) that initiates that eventE.g. Member initiates getDateEach event is handled by or captured on some entity conceptCopyright W. Howden*

Copyright W. Howden

Copyright W. Howden*Description Associations vs Attributes Why Associations?Allows postponing of detailsLeads to a design that facilitates changeRecognizes that some kinds of properties/descriptions may have a life of their ownE.g. may want to treat member descriptions independently of members for the purposes of a catalog of profiles

Copyright W. Howden

Copyright W. Howden*Attributes vs Associations?AttributesShould have primitive data type valuesAssociationsIf property is a (complex) object, should be a separate concept with a linking associationE.g. Dater has Dater Properties. This is a complex object and should be its own concept. Linking association:

Copyright W. Howden

Dater

Dater Properties

3 Describes

*

1

Copyright W. Howden*Some Domain Model Dos and DontsDoStatic ModelE.g. Parts explosion diagramReal World ConceptsE.g. Gender Preference in Dating System ApplicationDo not be afraid to overdo concept list

DontDynamic Flow ChartOne entity sends a message to anotherSoftware EntitiesE.g. GenderPrefTextStringLeave out concepts

Copyright W. Howden

Copyright W. Howden*Domain Model Example

Copyright W. Howden

LogOn

SetMemberData

GetADate

Preferences

DatingSystem

NoDateMessage

DateDescription

DataBase

MemberData

PersonalProps

Member

3 initiates

*

1

1

*

3 initiates

*

*

captured on4

*

1

*

1

captured On

*

1

displays

*

1

displays

1

*

HasA

1

1

partOf

1

1

identifies4

1

*

describedBy4

1

1

3 partOf

1

1

3 contained in

1

*

Data Flow Diagram Not a Domain Model

Copyright W. Howden*UML and Domain ModelsUML does not include Domain ModelsUML class diagrams can be used for several purposesConceptual classes as in Domain ModelAttributes but no methodsDesign classes from design activitiesGraphical representation of PL classes

Copyright W. Howden

Copyright W. Howden*Use Cases, Domain Models and System IncrementsUse cases are constructed for the whole systemOriginal domain model is for first phase/iteration onlyAt the beginning of each new iteration, the previous domain model is augmented to include concepts in the next iteration

Copyright W. Howden

Assignment 3Construct a domain model for the first increment (phase 1) of your projectCopyright W. Howden*

Copyright W. Howden