Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Scribd
Upload
79 views

Object Modeling Technique Suggested Design Format

The document describes the Object Modeling Technique (OMT) for software design, which includes four main models: 1) The object model defines the structure of objects, their relationships, attributes, and operations using class diagrams. 2) The dynamic model describes system behavior over time using event trace diagrams and state diagrams. 3) The functional model specifies system functions using data flow diagrams. 4) Object class specifications define attributes and operations for each class.

Uploaded by

Zubair Alam
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PDF, TXT or read online on Scribd
79 views

Object Modeling Technique Suggested Design Format

The document describes the Object Modeling Technique (OMT) for software design, which includes four main models: 1) The object model defines the structure of objects, their relationships, attributes, and operations using class diagrams. 2) The dynamic model describes system behavior over time using event trace diagrams and state diagrams. 3) The functional model specifies system functions using data flow diagrams. 4) Object class specifications define attributes and operations for each class.

Uploaded by

Zubair Alam
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

Object Modelling Technique http://www.ics.uci.edu/~djr/ics125/OMT.

html

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).

1 of 4 Sunday 12 December 2010 06:09 PM


Object Modelling Technique http://www.ics.uci.edu/~djr/ics125/OMT.html

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

2 of 4 Sunday 12 December 2010 06:09 PM


Object Modelling Technique http://www.ics.uci.edu/~djr/ics125/OMT.html

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>

Attribute <attribute name>: <type description>

...

Operation <operation name>:

Inputs: <list of inputs>

Outputs: <list of outputs>

Transformation: <list of transformations from inputs to outputs>

Constraints: <list of constraints that must be observed for a valid


transformation, exceptions, etc.>

...

...

Object/Integration Test Plan (more specific to OMT)

3 of 4 Sunday 12 December 2010 06:09 PM


Object Modelling Technique http://www.ics.uci.edu/~djr/ics125/OMT.html

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.

4 of 4 Sunday 12 December 2010 06:09 PM

You might also like