copyright w. howden1 lecture 4: elaboration tasks and domain modeling

Copyright W. Howden 1

Lecture 4: Elaboration Tasks and Domain Modeling


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”


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

Sample Basic Domain Concepts in DS

• dating system member

• date preferences

• dater characteristics

• matching dates

• administrator

• date request

• ...Copyright W. Howden 4

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



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


Sample Partial Domain Modelfor Member Actor w/o Attributes

LogOn SetMemberData GetADate Preferences

DatingSystem NoDateMessageDateDescription

DataBase MemberData PersonalProps

Member*

1

initiates 1

* *

* initiates

*1

captured on*

1 captured On

*

1

* 1

displays

1 *

displays

11

HasA

1 1

partOf

1

*

identifies

1

1

describedBy

1 1

partOf

1 *

contained in


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

-Name: : string-UserType : char

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

SetMemberData


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


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


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


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


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)


Associations

• Edges between nodes in a DM

• Describe “semantically meaningful” relationships between concepts

• May be annotated with roles and multiplicity designators


Domain Model Example




Member*

1

initiates 1

* *

* initiates

*1

captured on*

1 captured On

*

1

* 1

displays

1 *

displays

11

HasA

1 1

partOf

1

*

identifies

1

1

describedBy

1 1

partOf

1 *

contained in


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)

Association Annotations 2

• Multiplicitye.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



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


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

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



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


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:

Dater Dater Properties

* 1

Describes


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


Domain Model Example




Member*

1

initiates 1

* *

* initiates

*1

captured on*

1 captured On

*

1

* 1

displays

1 *

displays

11

HasA

1 1

partOf

1

*

identifies

1

1

describedBy

1 1

partOf

1 *

contained in

Data Flow Diagram – Not a Domain Model

Data Base

DateRequest

DatingSystem

Member

MatchingDates

1 -UsedBy1

*

-Used By 1

1-Initiates *

-Produces

1*


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


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

Assignment 3

• Construct a domain model for the first increment (phase 1) of your project


copyright w. howden1 lecture 4: elaboration tasks and domain modeling

Documents