Domain Modeling

Often a use-case model will refer to important domain-specific concepts such as roles, relationships, resources, products, and procedures.

·       Roles include employee, customer, investor, manager.

·       Resources include people, equipment, software, labs, and offices.

·       Relationships include X owns Y, X uses Y, X supervises Y, X treats Y, and X is a student of Y.

·       Products include reports, services, software, and hardware.

·       Procedures (aka workflows) include manufacturing procedures, testing procedures, and management procedures.

A domain model is one or more UML class diagrams that provide an understanding of the domain that is easily converted into code.

Domain models are often created with the aid of a domain expert.

UML class diagrams as a conceptual models

Concepts are represented by classes, while relationships are represented by associations.

Packages represent groups of related classes and associations.

Objects represent specific instances of classes.

For example a business might organize its concepts and relationships into three packages:

eg1

Classes

In the hr package we might find the Position and Person classes. Typical attributes of persons and positions can be listed in the attribute compartments of the respective class icons. Typical operations performed by persons and positions can be listed in their operation compartments:

In this example, an object representing a position, vice president for example, has a title attribute of type String and an execute operation that takes a task, t, as an input, and outputs a result.

An object representing a person has four attributes: last name, first name, and Social Security number, all of type String, and a salary of type Money and with initial value $0.0. The person class has no operations specified at this point.

It is often the case that operations correspond to responsibilities and are not assigned to classes until the design phase. For this reason operation compartments are often suppressed in domain models. Attribute compartments can also be suppressed if they are not needed.

Scopes are usually not specified in a domain model, but for pedagogical reasons are shown here. Note that the "-" sign indicates that the scope of an element is private, visible only inside of the class. Other possible scopes are:

+ = public = system-wide scope
~ = package scope
# = protected = subclass scope

Generally speaking, the default for an attribute or association endpoint is private, while the default for an operation is public.

Associations

The relationship "Position X is filled by person Y" can be represented by an association connecting Position and Person:

Notes

·       Names of associations aren't usually specified.

·       The name of an association can be decorated by a tiny arrow showing which way the association is read. This helps distinguish a relationship from its inverse.

·       The endpoints of an association have the following important properties:

navigability = true if the object on the other end of the association can access the object on the navigable end. One-way associations have an arrowhead indicating the navigable end. No arrowheads on either end indicate that the association is bi-directional. (0-way associations are pointless!) The filledBy association is bi-directional.

name = the name used by objects on one end to refer to objects on the other end (assuming the other end is navigable). For example, an employee refers to his position as his "role" while a position refers to the employees filling it as its "actors."

multiplicity = the number of objects that can be related to a given object. For example, a given position, vice president, say, can be filled by by 0 or more persons (indicated by "*"), while a given person, Joe Smith, say, can fill one position.

Objects

Specific persons and positions can be represented using objects. Specific instances of the filledBy relationship can be represented by links connecting the participating objects:

hr2

Note

·       This is an example of a UML object diagram.

·       Object diagrams are an advanced modeling feature.

Generalization

Generalizations are used in domain models to represent the is-a relationship. For example:

·       A graduate student is a student

·       A triangle is a polygon

·       A meeting is an event

Here it is in UML

Notes

·       If A generalizes B, then we say that B specializes A.

·       If A generalizes B then in Java we would implement this as:

class B extends A { ... }

·       If B specializes A then B inherits all of the operations, attributes, and associations of A.

·       If B specializes A, then instances of B can be substituted for instances of A:

A a = new B();

·       Not all occurrences of "is-a" in a piece of text are generalizations, and vice-versa.

Interfaces

Actors from the use case model are often represented by interfaces in the domain model.

For example, assume the following use-case model fragment for an ATM is given:

At this stage we're not sure what the bank server's API looks like. Indeed, different banks may have different APIs, so we model the bank as an interface:

Later, as we learn how different bank servers work, we can provide different realizations of the interface:

Notes

·       In Java, we would implement the A realizes B as:

class A implements B { ... }

·       Interfaces describe behaviors, not objects.

o   A class can realize many interfaces.

o   A realizes B means that B is one of A's behaviors.

·       Interfaces can be thought of as types.

·       Variables and parameters can be typed as interfaces.

·       If A realizes B, then instances of A can be assigned to variables and parameters of type B:

B x = new A();

Text Analysis

"Text Analysis" is a fancy term that simply means identifying important sounding phrases in a textual description of a domain. Important noun phrases—user, owner, controller, buffer, etc.-- are often modeled by classes, important verb phrases—uses, has, owns, controls, etc.-- are often modeled by associations. Phrases suggesting classifications—kinds, types, is one of, etc.—are often modeled using generalization. Phrases suggesting assemblies— is part of, is made from, etc.—are often modeled using composition. Phrases suggesting collections—contains, holds, etc.—are often modeled using aggregation.

See also http://en.wikipedia.org/wiki/Entity-relationship_model

Patterns

An analysis pattern is a reusable fragment of a domain model.

See: Analysis Pattern Catalog

Class Diagrams

More details about class diagrams can be found here: Class Diagrams.

Domain Procedure Models

Procedures are modeled using UML activity diagrams.

Labs

Try these: OOA Labs

Case Study

Case Study: Trilogy