Home ] Overview ] Publications ] OMG ] Case Study ] Support ] Other Work ] Search ]
horiz-space.GIF (952 bytes)

Concept Map
How to...
Model Kinds
This 'n That






A model is a description, from some view or perspective, of some phenomenon or system. As such, it always presents an abstraction of the "real" thing, by ignoring or deliberately suppressing those aspects that would not interest a user of that model. What you choose to ignore depends, of course, on your objectives. Different modeling constructs help focus attention by ignoring selected things. Models may be presented in different forms, including graphical notations, tables, or in a formal textual syntax.

Models are not just for software designs. Building models, even informal ones, can help clarify a person's conceptual view of the world (see Don Norman's book for a delightful description), describing something that exists, or that we may intend to build.

Modeling Constructs

The primary modeling constructs visible to the modeler are listed below. The descriptions are explanatory, rather than formal definitions. You can also browse the Concept Map that shows graphically how the key concepts are related. Notice that there can be many possible presentations, both formal and informal, of each construct.

Construct Description Presentation
(See Notation)
Object Any individual thing you need to talk about: a customer, product, telephone call, boiler, insurance policy, department, company, computer, software application, component within an application. UML instance
Action An action names and specifies the effect of interactions between participating objects: place an order, end a phone call, make a claim on an insurance policy, deploy a computer system in the accounting department. UML use case;
UML operation (special case of action)
Type An implementation-independent specification of an object, typically describing its external interface and visible behavior in terms of an abstract model of its state as a set of attributes. More properly, the specification is called a type specification; and any object that satisfies that description is a member of that type. Note the contexts in which we use "type":
interface: typically refers to a list of operations (names and signatures) e.g. a Java interface
type specification: an interface + a behavioral specification together with an abstract model of object state
role: a type in the context of a collaboration

e.g. a Customer type may describe all objects that purchase and return goods, building up and paying off their account balances.

UML Type diagram (class diagram interpreted or stereotyped as <<types>>);
text table;
OCL syntax specifications; informal text
Collaboration Describes a related set of actions among a group of objects; each action potentially abstracts a more detailed interaction between participant objects. The role of each participant in the collaboration is defined as a type. A single type, specified independently of any others that use its services, is a degenerate collaboration in which a single role is of primary relevance to the specification.

e.g. a Retail-Sale collaboration might have:

actions: sell, return
participant roles described by object types Buyer, Seller
effects of the actions specified by modeling attributes like funds and goods on the buyer and seller types.
Collaboration diagram, UML use-case diagram; table; OCL syntax specs; informal text
Refinement Anything can be modeled at different levels of abstraction; a refinement (noun) is a relationship between detailed and abstract models of the same thing, with a mapping from detailed to abstract to justify the refinement. The mapping itself can be informal or formal, and is defined in a refinement model

e.g. the Retail-Sale collaboration may itself be a refinement of a more abstract Sale action.

Refinements are the primary focus of attention during design reviews, inspections, and testing. A refinement may have an associated architecture, which defines the design elements, patterns, and rules used in constructing the detailed model.

UML refinement arrow between two models. The  associated refinement model and mapping can be shown as: activity diagram, state chart, sequence diagram, associations between two models, OCL, informal text.
Package Defines a collection of related model elements. All modeling work is done in a package. Within a package you can reference elements (interfaces, specs, architectures, etc.) from another package if you import that package. In advanced usage, different aspects of a model element may be defined in different packages. Packages are used to separate (a) interfaces from implementations (b) different views of a subject (c) business process from specs from designs, etc.

e.g. a business (system) with retail sales and customer support might be split across multiple packages:

Package retail-sale-0 may contain an abstract collaboration with actions sell, return.
Package retail-sale-1 may contain a detailed collaboration with select, pay, bring-back, refund.
Package sale-refinement-01 may import both and include a refinement model that refers to both and shows how the detailed model maps to the abstract: <select,pay> refines sell, and <bring-back, refund> refines return.
Package customer-support may have actions call, provide help, setup service level.

Note that the above separations could be useful for a pure model of the business itself, or for a software system that dealt with retail sales.

UML package symbol and import arrows; text equivalents.
Framework definition A framework is a generic package i.e. one whose contents are intended to be used by "plugging in" specializing elements in place of the parameterized parts of the framework package. Any elements may be substituted for; alternately, distinguished substitutable elements and assumptions about them may be marked explicitly. When the framework defines some features of its model elements, and the user of that framework "plugs-in" other elements with separately defined features, the Catalysis rules for composition provide well-defined results.

Frameworks capture many kinds of patterns:

domain patterns (resource allocation, account settlement).
UI patterns (a master-detail widget pair and how it hooks into a generic domain model).
design patterns (subject-observer).
code patterns (Java Beans get<X> and set<X> name patterns for properties).
patterns for using language features (e.g. simulating multiple-inheritance with delegation).
patterns that recur in basic modeling and design constructs e.g. 2-way pointers between objects; lifetime dependency of one object on a related object. 
generic classes (List<X>, Map<X,Y>).
UML package with optional <<framework>> stereotype, and with conventions to distinguish placeholders.

In Catalysis we make a further distinction of the "assumptions" the framework makes about the bits that must be plugged in when the framework is applied.

Framework application A framework application is the usage of a pattern with a different context substituted into that pattern. Technically, it is a package import with substitutions for certain elements of the imported package. UML pattern notation, with further substitutions (e.g. attributes) annotated textually. It is sometimes convenient to use UML stereotypes as a notational shorthand for a framework application.

The modeling constructs and diagrams in Catalysis are themselves defined in Catalysis as frameworks, and can even be translated into a common core, down to the level of statements in logic. While this is not something the end user typically cares about, it does provide two major benefits:

project or domain-specific user-defined design patterns and modeling extensions
sophisticated tool support such as consistency checking and change propagation
Email suggestions to All contents copyrighted 1998.