|
Up
Basics
Fractals
Models
Concept Map
How to...
OOA/D?
CBD
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 |
|
