Domain Modeling
We can view an organization such as a business, governmental organization, or military organization as a system.
Like a software system, an organizational system has goals or objectives.
The components of an organizational system are roles, procedures, products, and resources.
Examples of roles include employee, customer, investor, manager.
Examples of resources include people, equipment, software, labs, and offices.
Examples of products include reports, services, software, and hardware.
Examples of procedures (aka workflows) include manufacturing procedures, testing procedures, and management procedures.
In some cases developers may need a deeper understanding of their customer's business. This is important if, for example, the system being developed must integrate smoothly with existing business procedures.
A domain model is a formal model of the important roles, procedures, products, and resources of an organization.
The domain model has two parts: the conceptual model and the procedural model.
Domain Models
One of the goals of a conceptual model is to understand the important domain concepts, entities, and relationships. This is necessary for a complete understanding of the use cases.
There are many types of domain models: taxonomies, E-R models, ontologies, etc. But for software engineering, UML diagrams are the most popular.
UML class diagrams
as a conceptual models
A conceptual model captures the important concepts and
relationships in some domain.
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:
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.
Note that the "-" sign indicates that the scope of
an attribute or association endpoint 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:
Note that 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.
Note that the endpoints of an association can be decorated
by:
name = the name used by objects on one end to refer to objects on
the other end. 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:
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
Domain Procedure
Models
Procedures are modeled using UML activity diagrams.