OBM (Object-Behavior Model) Overview


Why OBM?

The ORM (Object-Relationship Model) is a powerful tool for representing objects and relationships. However, it does not allow us to model the behavior of objects. We need a behavior model to document the way the objects in a system function, respond or perform.

In OSA, we use the OBM (Object-Behavior Model) to describe the behavior of the objects in a system. Behavior in the OBM has three basic components:

The OBM models these aspects of the behavior using state nets.


OBM outline

States

A state represents the status, phase, situation, or activity of an object. It is represented by a rectangle with rounded corners, with the name of the state written inside. A state can be on or off, active or inactive, etc. A state can only be turned on or off by transition, unless an exception occurs.

Transitions

A transition is the process of changing the state of an object. It is represented by a rectangle divided into two sections. The top section contains the trigger, which is the event or condition that activates the transition. The bottom section contains the action, which may cause events, create, destroy, and observe objects and relationships, and send and receive messages.

Initial transitions activate initial states, which are the states exhibited by an object when it comes into existence in a system. They have no prior states and are always enabled.

Final transitions are transitions with no subsequent states. When a final transition fires, the prior states of the final transition are turned off.

Exceptions

An exception is an event or condition that is not part of normal system behavior. A state exception is represented in the state-net by a bar across a transition arrow. A transition exception is represented by an arrow from the transition in which the exception may occur to a state that the object enters following the exception.

Threads

An object can be in more than one state at the same time. In other words, there can be multiple threads of execution in an object. Real-time constraints

Real-time constraints may be added to a state net when time is an important element of object behavior. Real-time constraints can applied to triggers, actions, states, and state-transition paths. We use braces, { }, to specify real-time constraints. The braces can be put in the transition rectangle, near the state and on the state-transition path.

High-level states

A high-level state is a state in which the activity performed is defined by another state net. We may define high-level states bottom-up by creating high-level states from low-level states and transitions. We may also define high-level states top-down by providing a state net for an existing state.

High-level transition

A high-level transition is a transition in which the activity performed is defined by another state net. As for high-level states, we may create high-level transitions either top-down or bottom-up. For top-down creation, a state net is supplied which describes the behavior of a high-level transition. For bottom-up creation, a high-level transition is created by specifying which existing state-net components belong to the new transition.

Generalization/Specialization

Abstraction and inheritance are powerful tools. In order to represent common behaviors commonly, object classes inherit all behaviors which their generalization object classes have. Specialization object classes may add addition states or transitions and modify or delete inherited ones.


Concurrency

Objects in OSA behave concurrently. For example, a student can be doing his/her homework while the teacher is preparing for the class. We refer to this concurrent behavior among objects as interobject concurrency.

The OBM supports interobject concurrency by associating a different state-net instance with each object. A state-net instance is an object's private copy of a state net. Although templates for a state net for two different objects in the same object class are identical, the two objects behave independently. Each may be in the same or different states and transitions, independent of the other. Thus, objects in OSA naturally have concurrent behavior.

Objects in OSA may also exhibit concurrent states or actions, which we call intraobject concurrency. For example, a student can be doing his/her homework while listening to the radio.

The OBM supports intraobject concurrency by a state net that allows an object to be in more than one state or transition at the same time.

General Constraints and Notes

OBM's may have general constraints and notes just as ORM's may have.

A general constraint describes constraints on states, transitions, etc. which are not otherwise expressible. A general constraint is represented by text.

A note is information which may prove helpful to other people. It has no semantics in OSA at all. It is represented by test, too.


Go to the OSA Tutorial

Go to the OIM Tutorial

Begin the OBM tutorial with State


 OSM Home Page CS Dept Home Page  BYU Home Page


Last updated 13 October 1994.
by Lei Cao (caol@bert.cs.byu.edu)