Sie sind auf Seite 1von 19

3/11/2013

Lecture 7
Lecture 7

Lecture

7

Objectives  Explain the purpose of domain modelling.  Explain what a conceptual class is.

Objectives

Explain the purpose of domain modelling.

Explain what a conceptual class is.

List techniques for finding conceptual classes.

Define the terms Aassociations and Attributes .

Identify and explain different types of association present in a domain model .

Create a domain class diagram for a given domain, using correct UML class diagram notation.

3/11/2013

Definition “A domain model captures the most important types of objects in the context of

Definition

“A domain model captures the most important types of objects in the context of the business. The domain model represents the ‘things’ that exist or events that transpire in the business environment " I. Jacobsen Domain model (Conceptual Model)is produced during the analysis and it is not a description of software objects; but it is visualization of concepts in the real- world domain. It has identification of the concepts, attributes and associations as shown below:

Characteristics of Domain Modeling  Visual representation of conceptual classes.  Associations and relationships

Characteristics of Domain Modeling

Visual representation of conceptual classes.

Associations and relationships between concepts (e. g Payment PAYS-FOR Sales).

Attributes for information content (e.g. Sale records DATE and TIME).

Does not include operations / functions.

Does not describe software classes.

Does not describe software responsibilities.

Input

Problem Description, Use Cases, …

Output

A set of class diagrams

3/11/2013

Why a domain model?
Why a domain model?

Gives a conceptual framework of the things in the problem space

Helps you think focus on semantics Provides a glossary of terms noun based

It is a static view - meaning it allows us convey time invariant business rules

Foundation for use case/workflow modeling

Based on the defined structure, we can describe the state of the problem domain at any time.

Motivation for Domain Models
Motivation for Domain Models

Helps to understand the key concepts in a business or

in a problem domain

Lower representational gap with OO modeling

Helps to understand the key concepts in a business or in a problem domain  Lower

3/11/2013

Simple Domain Model Class Diagram  No methods shown in domain model  Domain classes

Simple Domain Model Class Diagram

Simple Domain Model Class Diagram  No methods shown in domain model  Domain classes are

No methods shown in domain model

Domain classes are not software classes

Very similar to ERD

UML and domain model can be used in place of ERD in traditional approach

7

GENERAL STEPS IN DOMAIN MODELING
GENERAL STEPS IN DOMAIN MODELING

A recommended flow for domain modeling is shown below in sequential order:

1. Prepare problem statement for the system being developed.

2. Identify classes and objects. 3.

3. Develop data dictionary.

4. Identify association between classes.

5. Identify attributes of classes and association classes.

6. Structure objects using inheritance.

7. Verify access paths for likely queries.

8. Iterate and refine the model

3/11/2013

Identifying Objects and Classes  To identify objects and classes, we first perform textual analysis
Identifying Objects and Classes
 To identify objects and classes, we first perform textual
analysis to extract all available noun and noun phrases
from the given problem statement.
Category List
Category List

3/11/2013

Noun Phrase Identification  Noun Phrase Identification [Abbot 83]  Analyze textual description of the

Noun Phrase Identification

Noun Phrase Identification [Abbot 83]

Analyze textual description of the domain

Identify nouns and noun phrases (indicate candidate classes, objects or attributes)

Caveats:

Automatic mapping isn’t possible

Textual descriptions are ambiguous! (different words may refer to the same class, people may refer to things at different abstract levels: class, object, or somewhere in between)

Identify conceptual classes from noun phrases  Vision and Scope, Glossary and Use Cases are

Identify conceptual classes from noun phrases

Vision and Scope, Glossary and Use Cases are good for this type of linguistic analysis However:

Words may be ambiguous or synonymous

Noun phrases may also be attributes or parameters rather than classes:

If it stores state information or it has multiple behaviors, then it’s a class

If it’s just a number or a string, then it’s probably

an attribute

3/11/2013

Create Data Dictionary  After candidate classes have been identified, a data dictionary is prepared

Create Data Dictionary

After candidate classes have been identified, a data dictionary is prepared to record definition of a class. Each class is written a short description defining its scope / detail of the class.

to record definition of a class. Each class is written a short description defining its scope
Identify Associations between Classes- UML: Associations
Identify Associations between
Classes- UML: Associations

-"direction reading arrow"

-"direction reading arrow" -it has no meaning except to indicate direction of reading the association label

-it has no meaning except to indicate direction of

reading the association label

-optional

direction of reading the association label -optional Stocks  VideoStore Video 1 * association name
Stocks  VideoStore Video 1 * association name multiplicity 14
Stocks 
VideoStore
Video
1
*
association name
multiplicity
14

3/11/2013

common UML notations concerning relationships in Classes
common UML notations
concerning relationships in Classes
Multiplicity of Associations 5-32) 16

Multiplicity of Associations 5-32)

Multiplicity of Associations 5-32) 16

16

3/11/2013

GUIDELINES: Associations  Only add associations for noteworthy relationships. Literally, those for which making a

GUIDELINES: Associations

Only add associations for noteworthy relationships. Literally, those for which making a “note” is worthy or business motivated.

 

1

*

Video

1

Rents

motivated.   1 * Video 1 Rents  Important association. Need to remember. Customer

Important association.

Important association. Need to remember.

Need to remember.

Customer

Influenced-by

1

Need to remember. Customer Influenced-by  1 Loan Policy Low value association. Possible, but so what?

Loan Policy

Need to remember. Customer Influenced-by  1 Loan Policy Low value association. Possible, but so what?

Low value association.

Possible, but so what?

When to show association  Associations for which knowledge of the relationship needs to be

When to show association

Associations for which knowledge of the relationship needs to be preserved for some duration

„In the POS domain

„We need to remember what SalesLineItem instances that are associated with a Sale.

„Cashier may look up ProductionDescription during the process of sale, but we do not need to remember who looked up what after the sales has been made.

„We should avoid showing too many associations

3/11/2013

Identifying Attributes  Show only “simple” relatively primitive types as attributes.  Connections to other

Identifying Attributes

Show only “simple” relatively primitive types as attributes.

Connections to other concepts are to be represented as associations, not attributes.

Payment

date : Date time : Time amount : Money

attributes

attributes
are to be represented as associations, not attributes. Payment date : Date time : Time amount
Suitable attribute types  Most attribute types should be what are often thought of as

Suitable attribute types

Most attribute types should be what are often thought of as “primitive” data types

„Relate conceptual classes with an association, not with an attribute

thought of as “primitive” data types  „Relate conceptual classes with an association, not with an

3/11/2013

Class or Attributes  If we do not think of some conceptual class X as

Class or Attributes

If we do not think of some conceptual class X as a number or text in the real world, X is probably a conceptual class, not an attributes

of some conceptual class X as a number or text in the real world, X is
Association class
Association class

3/11/2013

University Course Enrollment Domain Model Class Diagram  Where is each student’s grade remembered in

University Course Enrollment Domain Model Class Diagram

University Course Enrollment Domain Model Class Diagram  Where is each student’s grade remembered in this

Where is each student’s grade remembered in this model?

Each section has many grades and each grade is association with a student

Each student has many grades and each grade is association with a section

23

Refined Model with Association Class and Grade Attribute  Association class — an association that

Refined Model with Association Class and Grade Attribute

Association classan association that is treated as a class in a many to many association because it has attributes that need to be remembered, such as grade

is treated as a class in a many to many association because it has attributes that

24

3/11/2013

Generalization/Specialization  Generalization means grouping similar types of things (e.g., motor vehicles group

Generalization/Specialization

Generalization means grouping similar types of things (e.g., motor vehicles group cars, trucks and tanks. They share certain general features (e.g., wheels, engine, etc.), so motor vehicle is a more general class)

Specializations are judgments that categorize different types of things (e.g., sports car is a special type of car)

A generalization/specialization hierarchy is used to structure (or rank) things from the more general down to the more special

Each class has a more general class above it a superclass

A class may have a more specialized class below a subclass

Inheritance the concept that subclasses classes inherit characteristics of the more general superclass

25

A Generalization/Specialization Class Hierarchy for RMO Orders 26

A Generalization/Specialization Class Hierarchy for RMO Orders

A Generalization/Specialization Class Hierarchy for RMO Orders 26

26

3/11/2013

A Generalization/Specialization Class Hierarchy for RMO Types of Sales  Abstract class — a class

A Generalization/Specialization Class Hierarchy for RMO Types of Sales

Class Hierarchy for RMO Types of Sales  Abstract class — a class that allow subclasses

Abstract classa class that allow subclasses to inherit characteristics but never gets instantiated. In Italics (Sale above)

Concrete classa class that can have instances

27

Inheritance  Inheritance is a concept that allows subclasses to share characteristics of their superclasses

Inheritance

Inheritance is a concept that allows subclasses to share characteristics of their superclasses

E.g. a sports car has everything a car has (e.g., 4 wheels and an engine, which it inherits from the class car which is above it)

The sports car then specializes E.g., has a sports option, racing wheels, etc.

In the object-oriented approach, inheritance is a key concept that is possible because of generalization/specialization hierarchies (these hierarchies are often called inheritance hierarchies)

28

3/11/2013

A Generalization/Specialization Class Hierarchy for Motor Vehicles 29

A Generalization/Specialization Class Hierarchy for Motor Vehicles

A Generalization/Specialization Class Hierarchy for Motor Vehicles 29

29

Whole-Part Relationships  Whole-part hierarchies – relationships that structure classes by components where one

Whole-Part Relationships

Whole-part hierarchies relationships that structure

classes by components where one class is part of or a component portion of another class

Aggregation whole-part relationships between and object and its removable parts

Parts can exist separatelyrelationships between and object and its removable parts Like car and its tires  Composition –

Like car and its tiresobject and its removable parts Parts can exist separately  Composition – whole-part relationships between and

Composition whole-part relationships between and object and its non-removable parts.

Parts cannot exist separatelywhole-part relationships between and object and its non-removable parts. Like Hand is composed of fingers and

Like Hand is composed of fingers and thumb– whole-part relationships between and object and its non-removable parts. Parts cannot exist separately 30

30

3/11/2013

Whole-Part Aggregation Relationships 31

Whole-Part Aggregation Relationships

Whole-Part Aggregation Relationships 31

31

Example: A typical Description

Example: A typical Description

Example: A typical Description

3/11/2013

Class Diagram Example: Bank Account • Bank account system includes a generalization/specialization hierarchy: –

Class Diagram Example: Bank Account

Bank account system includes a generalization/specialization hierarchy:

Account is the superclass

SavingsAccount and CheckingAccount are subclasses of Account

A triangle on the line connecting classes indicates inheritance (the

subclasses inherit attributes and behaviors from the superclass Account like having an account number)

But Savings and Checking accounts are also specialized

A SavingsAccount “knows” how to calculate interest but a checking

account doesn’t (so they have different methods and attributes, although they

share things they inherit from class Account)

33

Class Diagram Example: Bank Account • The Customer class and the Account class are associated

Class Diagram Example: Bank

Account

The Customer class and the Account class are associated

Each customer can have zero or more accounts (the diagram shows the

minimum and maximum cardinality on the line connecting the classes, and

the asterisk means “many”

Each account is owned by one and only one customer

The SavingsAccount and CheckingAccount classes inherit the

association with the Customer class

The Account class is an abstract class (i.e., the class that cannot be

instantiated, existing only to allow subclasses to inherit its attributes, methods and associations) shown in italics

SavingsAccount, CheckingAccount and Customer are examples of class

are concrete classes that can be instantiated (i.e., objects can be created)

34

3/11/2013

Mapping parts of speech to object model component

Mapping parts of speech to object model component

Mapping parts of speech to object model component
3/11/2013 Mapping parts of speech to object model component 18

3/11/2013

Summary: Create a domain model?
Summary: Create a domain
model?

Perform the following in very short iterations:

o

Make a list of candidate domain classes.

o

Draw these classes in a UML class diagram.

o

If possible, add brief descriptions for the classes.

o

Identify any associations that are necessary.

o

Decide if some domain classes are really just attributes.

o

Where helpful, identify role names and multiplicity for associations.

o

Add any additional static rules as UML notes that cannot be conveyed with UML symbols.

o

Group diagrams/domain classes by category into packages.

Concentrate more on just identifying domain classes in early iterations !

38 Notice how this can be viewed as a “visual dictionary.” It illustrates concepts, words,

38

38 Notice how this can be viewed as a “visual dictionary.” It illustrates concepts, words, things

Notice how this can be viewed as a “visual dictionary.” It illustrates concepts, words, things in a domain