The Nature and Purpose of Models

What Is a Model?
y y

y y y

A model is a representation in a certain medium of something in the same or another medium. The model captures the important aspects of the thing being modeled from a certain point of view and simplifies or omits the rest. Engineering, architecture, and many other creative fields use models. A model is expressed in a medium that is convenient for working. Models of buildings may be drawings on paper, 3-D figures made of cardboard , or finite-element equations in a computer.

A construction model of a building shows the appearance of the building but can also be used to make engineering and cost calculations. y A model of a software system is made in a modeling language, such as UML. y The model has both semantics and notation and can take various forms that include both pictures and text. y The model is intended to be easier to use for certain purposes than the final system.
y

What Are Models For?

Models are used for several purposes. To capture and precisely state requirements and domain knowledge so that all stakeholders may understand and agree on them. y Various models of a building capture requirements about the appearance, y traffic patterns, y various kinds of utility services, y strength against wind and earthquakes, cost, and many other things. y Stakeholders include the architect, structural engineer, general contractor, various subcontractors, owner, renters, and the city.

Different models of a software system may capture requirements about its application domain, the ways users will use it, its breakdown into modules, Common patterns used in its construction, and other things. y Stakeholders include the architect, analysts, programmers, project manager, customers, funders, end users, and operators. y Various kinds of UML models are used.
y

To think about the design of a system.

An architect uses models on paper, on a computer, or as 3-D constructs to visualize and experiment with possible designs. y The simplicity of creating and modifying small models permits creative thought and innovation at little cost. y A model of a software system helps developers explore several architectures and design solutions easily before writing code. y A good modeling language allows the designer to get the overall architecture right before detailed design begins.
y

To capture design decisions in a mutable form separate from the requirements.

y y y y y

One model of a building shows the external appearance agreed to with the customer. Another model shows the internal routing of wires, pipes, and ventilation ducts. There are many ways to implement these services. The final model shows a design that the architect believes is a good one. The customer may verify this information, but often customers are not concerned about the details, as long as they work.

One model of a software system can capture the external behavior of a system and the real-world domain information represented by the system. y Another model shows the internal classes and operations that implement the external behavior. y There are many ways to implement the behavior; the final design model shows one approach that the designer believes is a good one.
y

To generate usable work products.

A model of a building can be used to generate various kinds of products. y These include a bill of materials, a simulated animated walkthrough, a table of deflections at various wind speeds, and a visualization of strain at various points in the frame. y A model of a software system can be used to generate class declarations, procedure bodies, user interfaces, databases, scenarios of legal use, configuration scripts,
y

and lists of race conditions.

To organize, find, filter, retrieve, examine, and edit information about large systems. y A model of a building organizes information by service: structural, electrical, plumbing, ventilation, decoration, and so on. y Unless the model is on a computer, however, finding things and modifying them are not so easy. y If it is on a computer, changes can be made and recalled easily, and multiple designs can be easily explored while sharing some common elements. y A model of a software system organizes information into several views: static structure, state machines, interactions, requirements, and so on.

Each view is a projection of the information in the complete model as selected for a purpose. y Keeping a model of any size accurate is impossible without having an editing tool that manages the model. y An interactive graphical model editor can present information in different formats, hide information that is unnecessary for a given purpose and show it again later, group related operations together, make changes to individual elements, as well as change groups of elements with one command, and so on.
y

To explore multiple solutions economically.

y y

y y

The advantages and risks of different design methods for buildings may not be clear at first. For example, different substructures may interact in complicated ways that cannot be evaluated in an engineers head. Models can explore the various designs and permit calculations of costs and risks before the actual building is constructed. Models of a large software system permit several designs to be proposed and compared. The models are not constructed in full detail, of course, but even a rough model can expose many issues the final design must deal with.

Modeling permits several designs to be considered, at a small cost of implementing any one design.

To master complex systems.

y

y y y y

An engineering model of a tornado approaching a building provides understanding that is not possible from a realworld building. A real tornado cannot be produced on demand, and it would destroy the measuring instruments, anyway. Many fast, small, or violent physical processes can now be understood using physical models. A model of a large software system permits dealing with complexity that is too difficult to deal with directly. A model can abstract to a level that is comprehensible to humans, without getting lost in details.

A computer can perform complicated analyses on a model in an effort to find possible trouble spots, such as timing errors and resource overruns. y A model can determine the potential impact of a change before it is made, by exploring dependencies in the system. y A model can also show how to restructure a system to reduce such effects.
y

Levels of Models
Models take on different forms for various purposes and appear at different levels of abstraction. y The amount of detail in the model must be adapted to one of the following purposes. y Guides to the thought process. High-level models built early in a project serve to focus the thought process of the stakeholders and highlight options. They capture requirements and represent a starting point toward a system design. The early models help the originators explore possible options before converging on a system concept.
y

y y

y y

y y

As design progresses, the early models are replaced by more accurate models. There is no need to preserve every twist and turn of the early exploratory process. Its purpose is to produce ideas. The final thinking models should be preserved even after the focus shifts to design issues, however. Early models do not require the detail or precision of an implementation model, and they do not require a full range of implementation concepts. Such models use a subset of UML constructs, a more limited subset than later design models. When an early model is a complete view of a system at a given precisionfor example, an analysis model of what must be donethen it should be preserved when development shifts to the next stage.

Abstract specifications of the essential structure of a system. (Essential model/Abstract model) y Models in the analysis or preliminary design stages focus on the key concepts and mechanisms of the eventual system. They correspond in certain ways with the final system. y The purpose of the abstract models is to get the highlevel pervasive issues correct before tackling the more localized details. y These models are intended to be evolved into the final models by a careful process that guarantees that the final system correctly implements the intent of the earlier models.

There must be traceability from these essential models to the full models; y Essential models focus on semantic intent. They do not need the full range of implementation options. y The path from an essential model to a complete implementation model must be clear and straightforward,
y

however, whether it is generated automatically by a code generator or evolved manually by a designer.

Full specifications of a final system. (Implementation model) y An implementation model includes enough information to build the system. y It must include not only the
logical semantics of the system and the algorithms, data structures, and mechanisms that ensure proper performance, but also organizational decisions about the system artifacts
y

that are necessary for cooperative work by humans and processing by tools.

Exemplars of typical or possible systems. (Example model) y Well-chosen examples can give insight to humans and can validate system specifications and implementations. y Examples of typical data structures, interaction sequences, or object histories can help a human trying to understand a complicated situation, y An example model includes instances rather than general descriptors. y It therefore tends to have a different feel than a generic descriptive model. y Example models usually use only a subset of the UML constructs, those that deal with instances. Both descriptive models and exemplar models are useful in modeling a system.

Complete or partial descriptions of systems. y A model can be a complete description of a single system with no outside references. y More often, it is organized as a set of distinct, discrete units, each of which may be stored and manipulated separately as a part of the entire description. y Such models have loose ends that must be bound to other models in a complete system. y Because the pieces have coherence and meaning, they can be combined with other pieces in various ways to produce many different systems. y Achieving reuse is an important goal of good modeling. y Models evolve over time. y Models with greater degrees of detail are derived from more abstract models

y y y y

more concrete models are derived from more logical models. For example, a model might start as a high-level view of the entire system, with a few key services in brief detail. Over time, much more detail is added and variations are introduced. Also over time, the focus shifts from a front-end, usercentered logical view to a back-end, implementation centered physical view. As the developers work with a system and understand it better, the model must be iterated at all levels to capture that understanding; it is impossible to understand a large system in a single, linear pass.

What Is in a Model?
Semantics and presentation.
Models have two major aspects: semantic information (semantics) and visual presentation (notation). y The semantic aspect captures the meaning of an application as a network of logical constructs, such as classes, associations, states, use cases, and messages. y Semantic model elements carry the meaning of the modelthat is, they convey the semantics. y The semantic modeling elements are used for code generation, validity checking, complexity metrics, and so on.
y

y y y y

y y

The visual appearance is irrelevant to most tools that process models. The semantic information is often called the model. A semantic model has a syntactic structure, well-formedness rules, and execution dynamics. These aspects are often described separately (as in the UML definition documents), but they are tightly interrelated and part of a single coherent model. The visual presentation shows semantic information in a form that can be seen, browsed, and edited by humans. Presentation elements carry the visual presentation of the modelthat is, they show it in a form directly apprehensible by humans.

They do not add meaning, but they do organize the presentation to emphasize the arrangement of the model in a usable way. y They therefore guide human understanding of a model. y Presentation elements derive their semantics from semantic model elements. Context. Models are themselves artifacts in a computer system, y they are used within a larger context that gives them their full meaning. y This context includes the internal organization of the model, annotations about the use of each model in the overall development process, a set of defaults and assumptions for element creation and manipulation, and a relationship to the environment in which they are used.
y

Models are not built and used in isolation. They are part of a larger environment that includes
modeling tools, languages and compilers, operating systems, networks of computers, implementation constraints, and so on.

The information about a system includes information about all parts of the environment. y Some of it will be stored in a model even though it is not semantic information. y Examples include project management annotations , code generation hints and directives, model packaging, and default command settings for an editor tool. y Other information may be stored separately.
y

Examples include program source code and operating system configuration commands. y Even if some information is part of a model, the responsibility for interpreting it may lie in various places, including the modeling language, the modeling tool, the code generator, the compiler, a command language, and so on.
y

What Does a Model Mean?

y y y y y y y

A model is a generator of potential configurations of systems; the possible systems are its extent, or values. Ideally, all configurations consistent with the model should be possible. Sometimes, however, it is not possible to represent all constraints within a model. A model is also a description of the generic structure and meaning of a system. The descriptions are its intent, or meaning. A model is always an abstraction at some level. It captures the essential aspects of a system and ignores some of the details.

There are the following aspects to consider for models. Abstraction versus detail. y A model captures the essential aspects of a system and ignores others. y Which ones are essential is a matter of judgment that depends on the purpose of the model. y A modeling language is not a programming language. y A modeling language may be less precise on purpose because additional detail is irrelevant for the purpose at hand.

Models at different levels of precision can be used across the life of a project. y A model intended for code generation requires at least some programming language issues to be addressed. y Typically, models have low precision during early analysis. y They gain detail as the development cycle progresses, so the final models have considerable detail and precision.
y

Specification versus implementation. y A model can tell what something does (specification), as well as how the function is accomplished (implementation). y These aspects should be separated in modeling. y It is important to get the what correct before investing much time in the how. y Abstracting away from implementation is an important facet of modeling. y There may be a chain of several specificationimplementation relationships, in which each implementation defines the specifications for the next layer.

Description versus instance. y Models are mostly description. y The things they describe are instances, which usually appear in models only as examples. y Most instances exist only as part of the run-time execution. y Sometimes, however, runtime instances are themselves descriptions of other things. We call these hybrid objects metadata. y Looked at more deeply, it is unrealistic to insist that everything is either an instance or a description. y Something is an instance or a description not in isolation but only in relation to something else, and most things can be approached from multiple viewpoints.

Variations in interpretation.
y y

y y

There are many possible interpretations of models in a modeling language. One can define certain semantic variation pointsplaces at which different interpretations are possibleand assign each interpretation a name as a semantic variation so that one can state which variation is being used. For example, users of Smalltalk might wish to avoid multiple inheritance in an implementation model because it is not supported by the programming language. Users of other programming languages would need it. Semantic variation points permit different execution models to be supported.