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.
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:
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.
The relationship "Position X is filled by person Y" can be represented by an association connecting Position and Person:
· 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.
Specific persons and positions can be represented using objects. Specific instances of the filledBy relationship can be represented by links connecting the participating objects:
· This is an example of a UML object diagram.
· Object diagrams are an advanced modeling feature.
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
· 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.
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:
· 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" 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
An analysis pattern is a reusable fragment of a domain model.
More details about class diagrams can be found here: Class Diagrams.
Procedures are modeled using UML activity diagrams.
Try these: OOA Labs