Underline nouns and noun phrases
If you have a textual specification or concept document, underlining the nouns and noun phrases can lead to the
identification of:
-
Objects
-
Classes
-
Attributes
-
Actors
You can also identify:
-
synonyms
-
uninteresting objects
This is a common approach but is problematic in an incremental, spiral process. Problems arise because the increments
implement only a subset of the entire system. Unless the textual specification is organized around the use cases, it is
difficult to focus only on the nouns or noun phrases relevant to the specific use case under consideration.
Nevertheless, if you have a well-written textual specification and it is organized around the use cases, then the
strategy can be effective.
|
Identify Causal Agents
Causal agents are things that cause results to occur; for example, a button on an elevator system "causes" the elevator to
be selected and dispatched to the floor; the arrival of the elevator at the floor "causes" the elevator door and floor door
to interlock; the resulting interlock "causes' the doors to cycle open, and so on. Identification of causal streams can
lead to the objects and classes that provide the cause and others that realize the effects. |
Identify services to be performed
Systems provide various services, some visible to an actor, some not. Every executing service is owned by a single instance
and typed by a single class; some of these services result in the sequenced execution of other services in other instances.
Following the service execution chain can identify the objects and classes that "own" and provide those services. This
strategy can also lead to the identification of attributes by asking "What information does this service need or produce?" |
Identify events to be received
Events are related to services in that they can invoke the execution of services. The "Identify events to be received"
strategy is very similar to the "Identify services to be performed" but may be more obvious in reactive systems - that is,
systems which receive and react to events of interest. Every event is generated by a class and received and processed. |
Identify information to be created or managed
Data must be stored as attributes of classes, so the identification of data leads one to identify the class that creates,
owns, manages, or destroys that data. This strategy can also identify services provided by the owner classes by asking "how
is this information used?" |
Identify transactions
A transaction is the reification of an interaction between objects as an object itself. Transactions are used when an
interaction is complex, state-full, or persist for a period of time and must be managed. Transactions are used in reliable
message delivery, connection-oriented messaging, staged interactions, or whenever an interaction between objects must be
remembered (such as in a deposit into a banking account). |
Identify real-world things to be represented
Systems must often represent real-world elements as interfaces, data representation, simulations, or resources. Physical
devices (important enough to be a strategy on its own) are most often represented as interfaces to electronics, but may be
simulated in some cases. Data representations stand in for some specific aspects of these real-world things; for example a
banking customer class might hold the customer's name, bank ID, tax billing number, phone and address. Resources are
represented as classes with a finite capacity of some kind; such as a list of available parts or a fuel tank with a
specific quantity being held within its capacity. These are represented within the system as objects, typed by classes. |
Identify resources to be managed
Resources are objects that have finite capacity. They can represent physical elements (such a memory available, fuel in a
fuel tank or missiles in a missile launcher) or abstractions (such as number of available connections or number of
awaiting messages) but they are represented as objects in the system. |
Identify physical devices
Physical devices are a special kind of real-world thing. Most commonly by far, physical devices are represented by
interfaces; that is, a single object "knows" how to actually talk to the physical sensor or actuator; any object in the
system that must access the physical device does so through this interface object. Sometimes, however, the physics (or
other characteristics) of a physical device must be simulated, such as when the device is not yet available for
integration, or when you're modeling physical properties, such as modeling a bullet's trajectory in a video game. |
Identify key concepts and abstractions
Key abstractions are the antithesis to physical devices; these are things that are conceptual, but nevertheless essential
in the domain of discourse. For example, a track in a tracking application, an account in a banking application, a window
in a GUI application, a thread in an operating system, a function in a compiler, etc. Every application domain has an
interrelated set of concepts that must be represented as objects and classes. |
Identify persistent data
The Persistent Data strategy looks for data that is important to remember for long periods of time, possible between hard
restarts of the system. Such data might be user names and passwords, configuration data, maps and geolocation data, etc.
These data must be represented as objects and classes within the model. |
Execute scenarios
The execute scenarios strategy is a personal favorite; it seeks to identify objects by walking through or executing use
case scenarios and adding objects (as lifelines) to the scenario to "flush it out." The messages to the lifelines
become services provided by those objects, invoked either by calls (synchronous rendezvous) or event receptions
(asynchronous rendezvous). Lifelines (objects) are added as you walk through the scenario. When a message is sent
between objects, an association between them is drawn between then on a class diagram.
Scenarios may be walked through from the beginning or at any "interesting" part. This is an invaluable strategy for
identifying objects, services, and relations.
|
|