3/11/2013

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

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

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

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

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

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 isnt 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 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 its a class If its just a number or a string, then its probably an attribute

3/11/2013

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.

Identify Associations between Classes- UML: Associations

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

VideoStore

Stocks 1

Video

14

association name

multiplicity

3/11/2013

common UML notations concerning relationships in Classes

Multiplicity of Associations 5-32)

16

3/11/2013

GUIDELINES: Associations

Only add associations for noteworthy relationships. Literally, those for which making a note is worthy or business motivated.
1..* 1 Customer ... Rents ... Video

Important association. Need to remember.

Influenced-by Low value association. Possible, but so what?

1 ...

Loan Policy

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

10

3/11/2013

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

11

3/11/2013

University Course Enrollment Domain Model Class Diagram

Where is each students 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 is treated as a class in a many to many association because it has attributes that need to be remembered, such as grade

24

12

3/11/2013

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

13

3/11/2013

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
27

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

14

3/11/2013

A Generalization/Specialization Class Hierarchy for Motor Vehicles

29

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

30

15

3/11/2013

Whole-Part Aggregation Relationships

31

Example: A typical Description

16

3/11/2013

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 doesnt (so they have different methods and attributes, although they share things they inherit from class Account)

33

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

34

17

3/11/2013

Mapping parts of speech to object model component

18

3/11/2013

Summary: Create a domain model?

o o o o o o

Perform the following in very short iterations:

Make a list of candidate domain classes. Draw these classes in a UML class diagram. If possible, add brief descriptions for the classes. Identify any associations that are necessary. Decide if some domain classes are really just attributes. 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 !

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

38

19