2003.09.291

Week III

Recap from Last WeekReview Classes

Review Domain Model for EU-Bid & EU-Lease

Aggregation Example (Reservation)

Attribute Properties / Standard rule categories (see rules for EU-Bid for examples)

New MaterialUse Cases, Part I

Understanding the Business Dynamics

Class models & the development process -- A Class Model defines the static structure of concepts, types, and classes.

3 perspectives we can take when defining a class model: Conceptual - how users think and talk about the world

• the terms & facts of the problem space -- the semantics i.e., the system glossary or domain model

• typically, business-focused

Specification - type - software component interface• the software, rather than the business

Implementation - class - software component 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.

Association Role properties ~ multiplicity

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)

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.