Introduction
Before software is built, it helps to first build a model of it — a simplified representation that can be examined, discussed, and refined at far lower cost than the finished system. This chapter explains what modeling means as a design technique, and introduces the Object Modeling Technique (OMT), which describes a system through three complementary views: the object model, the dynamic model, and the functional model.
2.1 Modeling
A model is an abstraction of something, built for the purpose of understanding it before building it for real. Because a model deliberately leaves out nonessential detail, it is far easier to work with, question, and change than the actual system it stands in for. People have relied on models — architectural mock-ups, engineering blueprints, storyboards, scale replicas — for centuries to try out ideas before committing to them, and software development benefits from the same discipline.
Models earn their place in the development process for several reasons:
Testing Before Building
A model can be examined and evaluated before a system is actually constructed, so design flaws surface — and get fixed — while they are still inexpensive to fix.
Communicating With Others
A model gives customers, users, and domain experts something concrete to react to, review, and correct, closing gaps in understanding early.
Visualizing Structure
A model lets a designer see how the pieces of a system relate before the details of implementation obscure the bigger picture.
Managing Complexity
The human mind can only track a limited amount of detail at once. A model reduces a large, tangled problem to a smaller number of essential ideas that can be reasoned about directly.
2.2 The Object Modeling Technique
The Object Modeling Technique (OMT) is the approach this book presents for carrying object-oriented thinking through the entire software life cycle — from understanding a problem, through designing a solution, to writing the code. Because the same underlying concepts (objects, classes, and their relationships) are used at every stage, a system does not need to be re-expressed in a new notation each time development moves forward; models simply accumulate more detail as they go.
At the heart of OMT is the idea that no single diagram can describe a system completely. A system has structure, it has behavior that unfolds over time, and it performs transformations on data — three different concerns that are best understood separately before being related back to one another. OMT therefore builds three distinct models, each capturing one of these concerns.
2.2.1 The Object Model
The object model describes the static structure of the objects in a system: what they are, what attributes and operations they carry, and how they relate to one another through associations and generalization. It answers the question "what exists?" and provides the vocabulary that the other two models depend on — behavior and transformation only make sense once there is something defined to behave or be transformed. Object diagrams, built from classes connected by relationship lines, are the notation used to express this model.
2.2.2 The Dynamic Model
The dynamic model describes how a system changes over time — the events that occur, the states an object moves through, and the conditions that govern the transitions between those states. It answers the question "when does something happen, and in what order?" without concerning itself with what data is being changed or how a given step is carried out internally. State diagrams, showing states linked by event-triggered transitions, express this model.
2.2.3 The Functional Model
The functional model describes the transformations that values undergo as they flow through a system, independent of when those transformations happen or how they are sequenced. It answers the question "what computation takes place?" and is expressed using data flow diagrams, which show processes, the data that flows between them, and the external sources and destinations of that data.
2.2.4 How the Three Models Relate
None of the three models stands completely on its own. The object model supplies the structural context — the objects and data — that the dynamic and functional models act upon. Operations named in the object model correspond to processes in the functional model and to actions triggered by events in the dynamic model. Because a real system always has structure, sequencing, and transformation happening together, a full description of it requires all three models, cross-linked to one another.
| Model | Answers | Notation |
|---|---|---|
| Object Model | What exists, and how is it structured? | Object diagrams (classes and relationships) |
| Dynamic Model | When does something happen, and in what order? | State diagrams |
| Functional Model | What transformation is being performed on the data? | Data flow diagrams |
2.3 Chapter Summary
- A model is a simplified stand-in for a system, built to support understanding, communication, and complexity management before the real system is built.
- The Object Modeling Technique (OMT) carries the same object-oriented concepts across analysis, design, and implementation, avoiding repeated translation between notations.
- OMT describes a system using three complementary models:
- The object model — static structure of objects, classes, and relationships.
- The dynamic model — the sequencing of events and states over time.
- The functional model — the transformations performed on data values.
- The three models are cross-linked but can largely be understood on their own; together they give a complete picture of a system.
Reference
Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., & Lorensen, W. (1991). Object-Oriented Modeling and Design, Chapter 2: Modeling as a Design Technique. Prentice Hall International / Prentice Hall India.
This page presents an explanation of the modeling concepts introduced in the cited chapter, reorganized and reworded in original language for study purposes rather than reproduced verbatim from the source text.