3/11/2013

1

Lecture 7

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

2

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

3

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 Helps to understand the key concepts in a business or

in a problem domain

Lower representational gap with OO modeling

3/11/2013

4

7

Simple Domain Model Class Diagram

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

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

5

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

3/11/2013

6

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 good for this type of linguistic analysisHowever: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

7

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.

14

Identify Associations between Classes- UML: Associations

VideoVideoStoreStocks

*1

association name multiplicity

-"direction reading arrow"

-it has no meaning except to indicate direction of

reading the association label

-optional

3/11/2013

8

common UML notations concerning relationships in Classes

16

Multiplicity of Associations 5-32)

3/11/2013

9

GUIDELINES: Associations Only add associations for noteworthy relationships.

Literally, those for which making a “note” is worthy or business motivated.

Video

...Rents

Influenced-by

1

1..*

1 Loan Policy

...

Customer

...

Important association.

Need to remember.

Low value association.

Possible, but so what?

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

10

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

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

3/11/2013

11

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

Association class

3/11/2013

12

23

University Course EnrollmentDomain Model Class Diagram

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

24

Refined Model with Association Class and Grade Attribute Association class— an 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

3/11/2013

13

25

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

26

A Generalization/Specialization Class Hierarchy for RMO Orders

3/11/2013

14

27

A Generalization/Specialization Class Hierarchy for RMO Types of Sales

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

Concrete class— a class that can have instances

28

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)

Inheritance

3/11/2013

15

29

A Generalization/Specialization Class Hierarchy for Motor Vehicles

30

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 separately

Like car and its tires

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

Parts cannot exist separately

Like Hand is composed of fingers and thumb

3/11/2013

16

31

Whole-Part Aggregation Relationships

Example: A typical Description

3/11/2013

17

33

• 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)

Class Diagram Example: Bank Account

34

• 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)

Class Diagram Example: Bank Account

3/11/2013

18

Mapping parts of speech to object model component

3/11/2013

19

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,

things in a domain