Today in OOADThe Domain Model Artifact

UML Classes EU-Bid Domain Model ExerciseEU-Lease Domain Model Assignment

Guest Speaker Kate Cunningham, Flexcar

Entity Class terminology

name• from the glossary entry

attributes• 'nominal' at first

operations• later

not shown graphically definition

• recorded in the Glossary

rules• constraints(aka "business rules)

the data contained in an object of the class• A student ‘knows’ its name• A course ‘knows’ how many students it can hold• A person ‘knows’ his or her date of birth

• What are some attributes for EU-Bid and EU-Lease classes?

What about class variables?

The Domain Model ~ Attributes

The following things can be specified about an attribute: name – noun or noun phrase (documented in the Glossary)

multiplicityo typically only 1 (“mandatory”) or 0..1 (“optional”)

initial value – is there a system-supplied value at birth?

changeability – is the value: changeable, frozen, or addOnly?

visibility – (same as for operations)

• encapsulation

Implementation perspective: Attribute values are considered hidden; an attribute’s value must be requested.

Specification perspective: We will treat all attributes as visible (“public” with an assumed accessor operation).

type – datatype (we will define this later)

Attribute properties

The Domain Model ~ Associations

Next, show where one entity has to know about another entity….

Relationship• Association• Generalization • Aggregation

rents

Are we taking a static or dynamic view? Does an attribute of Customer contain a Vehicle object

(or collection of Vehicle objects)? What about navigability?

What are the advantages and disadvantages of deciding about navigability at this stage?

informal definition:

An association is the shared knowledge that classes have about their long-lasting connections.

example:• A customer “knows” its accounts.• An course “knows” its enrolled-students.• An order “knows” its order-lines.

UML definitions:

An association is the representation of a set of links between objects (instances of classes).

A link is an instance of an association.

The Domain Model ~ Associations

Each association has 2* participating classes. • These are the classes at each end of an association line.

Each participating class is said to "play a role" in the association.

• Each role represents one "direction" in the association.

Multiplicities – How many objects may participate in the given relationship.

• An exact number, e.g., 27• A range of numbers 0..1, or 1, or …. • An arbitrary, unspecified number *

*Associations that: involve more than 2 classes, have their own properties, or are promoted to full class status (“reified”) are “advanced concepts” and not covered here.

The Domain Model ~ Association Roles

The Domain Model ~ Associations & Association Role properties

Consider the problem of keeping track of courses and specific offerings at a BrandX university. Professors must be assigned to teach courses, students must register for courses, and professors receive rosters for each course they teach.

Working with the person next to you, draw a simple class model for this system. Note:

• the entities of interest in this system• some relationships between entities• some attributes for each entity • some interesting behavior for each entity

Example Domain Model – A university registration system

The following things can be specified about each role in an association:

role name

verb phrase

multiplicity

navigability

changeability

The Domain Model ~ Association Role properties

Each role can be given an explicit name (a "rolename").

• example:

An employee plays the role of “sales rep” to a customer.

The default rolename is the class name. • example:

An order is placed by a customer.

o Here, “customer” is both the class name and the rolename.

EmployeesalesRep

Customer

Association Role properties ~ rolename

An explicit rolename is usually optional – used only when it adds clarity to a class’ participation in an association.

• as in the examples just given

BUT ... Sometimes a rolename is required.

• example:

A flight segment involves two cities – a departure city and an arrival city.

Here, at least one association end requires a rolename.

Flight Segment

CitydepartureCity

arrivalCity

Association Role properties ~ rolename

various labeling schemes: • verb-phrase (natural language sentence style)• gerund (applying to the association as a whole)

useful as an aid in communication between analysts and with users.

optional in the UML

Association Role properties ~ verb phrase

Each association role also has multiplicity. Multiplicity specifies "how many?" objects of a class may

participate in a given link. • It indicates both a lower and an upper bound for the number of participating

objects.

notation – an annotation next to the class at the far end of the association line.

• default is the range 0..infinityo or shorthand representation as simply * 0..*

• other commonly-used multiplicity values: o exactly one: 1o at least one: 1..*o at most one: 0..1o explicit range (e.g., between 2 and 4, inclusive): 2..4

Association Role properties ~ multiplicity

Association Role properties ~ multiplicity

for now, in the Domain Model

we will assume each association is "navigable in both directions“

Association Role properties ~ navigability & changeability

Class model

A Class Model defines the static structure of concepts, types, and classes.

concept – how users think and talk about the world

~ the semantics

type – software component interface

~ the interface

class – software component implementation

~ the realization

note: in many 00 languages, the notion of ‘class’ combines both ‘interface’ & ‘implementation.’

• but the distinction is important! "Program to a class's interface (type)rather than to its implementation."

Class models & the development process

3 perspectives we can take when defining a class model: Conceptual

• the terms & facts of the problem spacei.e., the system glossary or domain model

• typically, business-focused

Specification• the software, rather than the business• only the software "type" (the interface)

Implementation• language-specific realization• the implementation – "the classes that implement the type" (or, “implement

the interface”)~one type (interface) specification can have multiple implementations.

This course deals with the “conceptual” and “specification” perspective class models; the Java course deals with the "implementation" perspective.

Class model diagram elements

Class – a description of a set of objects that share the same responsibilities (attributes, relationships, operations, rules) and semantics. Attributes – the “value facts” the system records

the “variables” Relationships between classes – 3 types:

• association• generalization (supertype/subtype)• aggregation (“advanced”)

Operations – the behavior the "methods"

Rules – the constraints that govern both structure (relationships & attributes) and behavior (operations).

Many of these elements can be shown visually as a Class Model Diagram.

Class behavior – Operations

informal definition:

An operation specifies what an object can “do.”– i.e., the processes a class knows how to carry out, when

requested.

example:• An ATM machine knows how to “accept a deposit.”• A reservation knows how to “close a reservation.”

UML definition:

An operation is the specification of a transformation or query that an object may be called on to execute.

Associations in perspective

Conceptual• association = "facts" in the users' problem space

facts relate concepts, applying terms to form sentences.

example:“Customers place orders.”

“Orders may have several order lines.”

Specification• association = responsibilities

an object is "responsible to know" the other objects it is associated with.

example:“A customer knows the orders it has placed.” “An order knows the customer who placed the order.”

Implementation (e.g., Java)• association = pointer specifications ("navigability")

example:

<refer to OOP lecture & also Fowler, p. 54-56>

Association properties – navigability

different treatment for each perspective:

Conceptual – typically left undefined/unannotated• interpretation is “not applicable”/"undecided"

Specification – directional knowledge• knowledge in both directions (bi-directional) is assumed• typically drawn without navigation arrowheads

Implementation – navigation• arrowhead means implementation pointer

Note: bi-directional navigation implies an additional constraintThe two navigations must be inverses of each other.This is true for all three perspectives.

Domain Model Relationships: Generalization / Specialization

Generalization / Specialization is a feature of OO languages that permits an object's class to be specified as a hierarchy (or network) of classes, ranging from more general classes to very specific classes.

• typically referred to as simply "generalization"• also referred to as "supertype / subtype" relationships

For example,

Employee• a supertype

Relationship Manager and Branch Manager• two, more-specialized types of Employee

Subtypes "inherit" responsibilities from the supertype.

Domain Model relationships: Generalization / Specialization (cont)

Conceptual• generalization = a way of expressing "fact" hierarchies.

e.g., everything we say about an Employee is also true for a Relationship Manager.

Specification• generalization = the interface of a subtype must include all

elements from the interface of the supertype.

the subtype's interface conforms to the supertype's interface.

the principle of ‘substitutability’ applies.

Implementation (e.g., Java)• generalization = inheritance features in a programming language

Generalization in perspective

Domain Model relationships: Aggregation

Terminology• Aggregation

Examples• order + order item --> product• reservation + reservation detail -> reservable item

Terminology• Aggregation

Domain Model Diagram Elements:rule elements

definition

A rule is a constraint or condition that limits or guides what an object can "know" or "do."

Many (structure) rules are expressible using the graphical language.

• e.g., limiting a relationship to "at most one" or an attribute value to being “mandatory.”

When you need to express a rule that the graphics don't support, state the rule in a “note” or use braces {  } surrounding the rule statement.

• write in informal natural language, or• use a formal rule language, e.g., UML's Object Constraint

Language (OCL).

Class responsibilities:Rules

It is good practice to summarize the Domain Model rules and provide to the stakeholders in a form they can readily review.

Standard rules• initial value rules• mandatory value rules• unique value rules• frozen value rules• at-most-one rules [associations]

Custom rulesrules that are custom-written to support domain integrity

requirements

Class responsibilities: Rules (cont)