Identifying Domain Classes

Review

From the object-oriented perspective, the world as made of objects.

Objects can represent material things, but they can also represent abstract things such as events, roles, and descriptions.

If requested by another object, an object can execute one of its methods/functions.

Executing a method may change the object's internal state, it may change the object's environment, it may send requests to other objects to execute some of their methods, and/or it may simply provide information to the original requesting object.

Here are some basic definitions:

Objects, Classes, and Packages

An object model consists of one or more UML class diagrams. A class diagram is a graph: nodes connected by arrows. The nodes represent packages, interfaces, classes, and objects:

UML Package, Class, and Object Icons

Domains

A domain is a package of related concepts, roles, procedures, events, and entities. (See Domain Modeling).

Examples of domains include:

business
engineering
science
government
health care

In UML:

Examples of sub-domains of the business might include:

sales
marketing
management
finance

In UML we can represent this as packages connected by dependency arrows.

A dependency arrow connecting the sales package to the business package indicates that some of the concepts contained in business—profit, overhead, employee, customer, etc.—are used in the sales package:

A video rental store is a sub-domain of many domains:

film
sales

In UML:

Domain Classes and Objects

Objects that represent domain entities are called entities or domain objects. The classes they instantiate are called domain classes.

Executing a use case involves creating, destroying, querying, and updating domain objects.

Identifying Stereotypes

Typical domain class stereotypes include:

<<thing>> = an entity that has mass and volume

<<event>> = an entity that has a start time and duration

<<role>> = an entity that executes tasks. For example: plumber, clerk, nurse

<<type>> = an entity that describes other entities: film genre (Sci Fi, comedy, etc.), film rating (P, PG, etc.)

Examples of <<thing>> classes:

Person, Report,

Examples of <<role>> classes:

Customer, Doctor, Student

Examples of <<event>> classes:

Transaction,

Examples of <<type>> classes:

Genre, ProductType, Rank

 

Identifying Attributes

A class contains definitions of all of the attributes its instances will contain.

An attribute has four attributes:

name

type

visibility (+ | ~ | # | -)

initial value (optional)

The type of an attribute usually is not a domain class. These kinds of properties will be represented by associations.

Attribute types include:

primitive types: int, double, boolean

foundation classes: String, Money, Date

external/imported classes (i.e., classes from external domains)

Example:

An employee has a name, birth date, salary, marital status, and unique employee ID number.

We probably want to distinguish first and last name. Names are usually strings.

We can assume the existence of a Date class for birth day.

Ideally, salary should be of type Money. If this isn't available we can choose a type for representing decimal numbers like float (32 bit) or double (64 bit). It's probably a good idea to initialize this to zero.

Marital status can be a simple Boolean flag. We initialize it to false.

Employee ID number should be an integer (int).

 

Note that we use Java primitive types. We could also use C++ types (string, bool), XSD types, or CORBA types.

By default, the visibility of all attributes should be private. This gives the developer to make the attributes read-write or read only. This can be done by providing getters and setters for the attributes.

Attributes usually map to fields in Java and C++:

Employee.java

Note that age is an example of a derived attribute. It doesn't map to a field because it can be computed from other attributes.

Note that birthDay and id are read-only attributes.

Identifying Operations

Administrative functions: constructors, getters, setters, destructors, printers, etc. are usually not shown in a UML diagram.

In the analysis phase we only specify operations that are domain-specific.

An operation has four attributes:

name

return type

parameters

visibility  (+ | ~ | # | -)

Example:

A word processor document has content string and a cursor, which marks a position in the content string.

We need to be able to insert and delete text in a word processor at the cursor's location. We also need to be able to get a word count and move the cursor:

Our class has two attributes: content and cursor.

The text suggests four operations. The parameters are inferred:

 

Static Attributes and Operations

A static attribute or operation is an attribute or operation belonging to a class rather than the instances of the class.

For example, a Trig utility class might contain sin and cos methods as well as the constant PI. There is no need to create objects to execute these methods.

Here's a Java declaration:

class TrigUtils {
   static public double PI = 3.1416;
   static public double sin(double x) { ... }
   static public double cos(double x) { ... }
   // etc.
}

Here's how this might be used:

TrigUtils.sin(TrigUtils.PI/2); // should = 1

In UML static operations and attributes are underlined:

Textual Analysis

Example

A point-of-sale application needs to record all purchases. Here are a few facts:

F1: Customers make purchases.

F2: Customers have names.

F3: Purchases have dates.

F4: One or more items are sold in a purchase.

F5: Items have prices and descriptions.

F6: Purchases have amounts equal to the sum of the prices of the items sold.

F7: Customer Smith purchases copies of Ulysses and Moby Dick.

F1 and F6 are general rules about the retail sales domain, while F7 is an assertion about a specific sale.

In this example Smith, the copy of Ulysses and the copy of Moby Dick are objects. In fact these are things or entities, a special category of objects that have mass and volume.

The record of the purchase is also an object. This type of object is an event. Events don't have mass and volume. Instead they have start times and durations.

Here's an initial analysis object model representing the domain rules:

Assertions like F7 can be represented by objects: