Task: Identify Objects and Classes
This task identifies essential elements of the analysis collaboration (i.e. elements that must be present) within the collaboration realizing the use case.
Disciplines: Architecture
Purpose
The purpose is to identify structural elements, their relations, and their behavior that is essential for correctness.
Relationships
RolesPrimary Performer: Additional Performers:
InputsMandatory:
    Optional:
      Outputs
        Main Description
        There are many different ways to identify objects and classes, their features, relations, and behaviors. These are known as object identification strategies. These strategies are neither completely overlapping nor completely orthogonal. It is usually enough to apply 2-4 of these strategies to find all the objects in the analysis collaboration.
        Steps
        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.

        More Information