Object Modeling Technique
Suggested Design Format

Object Model

The object model describes the structure of the objects in the system - their identity, their relationships to other objects, their attributes, and their operations. The object model depicts the primary view of how the real world in which the system interacts is divided and the overall decomposition of the system. The object model provides the framework into which the other models are placed.

The object model is represented graphically with object class diagrams containing the object classes and their relationships. Each application-domain concept from the real world that is important to the application should be modeled as an object class. Classes are arranged into hierarchies sharing common structure and behavior and are associated with other classes. Classes define the attributes carried by each object instance and the operations that each object performs or undergoes.

The object class diagram should adhere to OMT's notation and exploit the capabilities of OMT, such as links and associations, inheritence (generalization and specialization), and aggregation. The attributes and operations need not be included in this diagram, as they will be described below in the object class specifications.

Dynamic Model

The dynamic model describes those aspects of the system concerned with the sequencing of operations and time - events that cause state changes, sequences of events, states that define the context for events, and the organization of events and states. The dynamic model captures control infomation without regard for what the operations act on or how they are implemented.

The dynamic model includes event trace diagrams describing scenarios. An event is an external stimulus from one object to another, which occurs at a particular point in time. An event is a one-way transmission of information from one object to another. A scenario is a sequence of events that occurs during one particular execution of a system. Each basic execution of the system should be represented as a scenario (this may correspond to the scenarios in your HCI mockup).

The dynamic model is represented graphically by state diagrams. A state corresponds to the interval between two events received by an object and describes the "value" of the object for that time period. A state is an abstraction of an object's attribute values and links, where sets of values are grouped together into a state according to properties that affect the general behavior of the object. Each state diagram shows the state and event sequences permitted in a system for one object class. State diagrams also refer to other models: actions correcpond to functions in the functional model; events correspond to operations on objects in the object model.

The state diagram should adhere to OMT's notation and exploit the capabilities of OMT, such as transition guards, actions and activities, nesting (state and event generalization), and concurrency.


 

Functional Model

The functional model describes computations and specifies those aspects of the system concerned with transformations of values - functions, mappings, constraints, and fucntional dependencies. The functional model captures what the system does, without regard to how or when it is done.

The functional model is represented graphically with multiple data flow diagrams, which show the flow of values from external inputs, through operations and internal data stores, to external outputs. Data flow diagrams show the dependencies between values and the computation of output values from input values and functions. Functions are invoked as actions in the dynamic model and are shown as operations on objects in the object model.

The data flow diagram should adhere to OMT's notation and exploit the capabilities of OMT, such as nesting, control flows, and constraints.


 

Object Class Specifications

Once all of the models have been defined, the object classes can be further specified. This is the time to reconcile any differences in the models and ensure their consistency. Operations may be added to the object model based on the other models: events, actions, and activities from the dynamic model and processes from the functional model.

Object classes are specified by their attributes and the behavior of their operations. Each object class specification must include both the attributes of the objects and the signature and transformation for each operation as well as any constraints on its application. The signature defines the interface to the operations (arguments and their types). The transformation defines the effect of the operation (output values as functions of input values and any side effects on operand objects). Each transformation must be described as a mathematic function by one of the following: mapping of inputs to outputs, table of I/O values, equations specifying outputs in terms of inputs, pre- and post-conditions, pseudocode, or natural language. The constraint should describe when the transformation is valid and what exceptions arise when it is not. The description should be an external specification, including only changes visible outside of the operation, and thus excluding any implementation details.

This specification should be organized by object class. Thus, this section might be organized as follows:

Object Class <class name>

...


 

Object/Integration Test Plan (more specific to OMT)

Includes an integration test plan capable of demonstrating that the design meets the functionality specified in the requirements. Test cases should cover each object and object interaction specified in the object model as well as each sequence of events in the dynamic model. You should consider each object class as a subsystem and apply functional (black box) test heuristics (such as input/output coverage and error/exception coverage) to the parameters identified in each operation in the class interface. In addition, you should develop a test case for each potential sequence of events (up to iterations). Note that these two views on the test plan need not be independent; you may be able to cover all objects by covering all sequences of events (this will depend on how thorough your dynamic model is).

NOTE: if desired, the test cases can be grouped with the design entity to which they apply, else a cross reference listing of some sort should be provided.