| Catalysis |
UML |
| Type |
Type. However, the UML makes a strange distinction between interface
and type: an interface is not permitted to have attributes. To a Catalysis
modeler this would be confusing, since specifying an object's behavior visible through an
interface always requires some abstract model of its state using attributes. |
| Attribute |
Attribute. However, UML would model a parameterized attribute as an
operation with isQuery = true. To a Catalysis modeler this would be mixing up the
abstraction of state (attributes, whether parameterized or not) and of behavior
(operations). Further, attributes are defined and constrainted by static invariants;
operations are defined by their pre/post-conditions. It is possible to approximate this in
UML if you (a) model an attribute whose type is a mapping or function, or (b) use an isQuery
operation and permit such operations to be used just like attributes within invariants and
operation specifications. |
| Association |
Association. However, UML does not provide a correspondence between
association and attributes. |
| Action |
Use case. In Catalysis we distinguish between the specification of the
abstract action, and the finer-grained actions that can be composed as a refinement of the
abstract action. The typical use case form forces these two to be combined together. However,
the recent definition of use-case in Booch's UML User Guide takes a step closer
to Catalysis in defining a use case as "a set of sequences of actions";
but it is still internally inconsistent e.g. what is the difference between this use of action
and the previous instance of use case? And would you not want to use exactly the
same modeling tools and techniques at this action level as at the level of the
use-case?
Also, at various times the three amigos state that use cases apply from
business level to inter-object messaging. In this case, a UML operation is also a use-case
(at some level of granularity). In Catalysis, an operation is a special restricted case of
a general action. |
| Joint Action |
Use case in which you are explicitly interested in the roles played by
multiple participants. Note, however, that in typical application a use-case description
includes both the abstract action itself, and a particular interaction protocol for
realizing that action. Catalysis permits this grouping in a use-case template, but
recommends that the two are often better separated by a refinement relationship. |
| Collaboration |
UML collaboration. However, a UML collaboration diagram typically
describes a sequence of messages that follow from a triggering message. Note, too, that
the three amigos have loosened their usage from what they insisted was correct in the UML
1.1 specifications e.g. Booch's book recommends sometimes using a collaboration diagram but
without using the numbering i.e. a Catalysis collaboration. Also, if you eliminate
the sequence numbering this becomes little different from a use-case diagram (except for
the bubble syntax, and showing use-cases "inside" the system instead of as a
collaboration with the actors). |
| Refinement |
Refinement exists in the UML, and even has a "mapping"
attribute, but is not treated as a central construct. This leaves many loose ends in the
UML e.g.
 | Why are the finer-grained use cases not themselves use-cases? |
| Why isn't the sequence of finer-grained use cases treated as a refinement of the
larger-grained use-case? |
| Isn't the relation between a class and an interface just a special kind of refinement? |
|
| Package nesting |
UML 1.1 stated that a containing package imported the contained packages.
Booch's UML User Guide reverses this rule and adopts a Catalysis-like semantics
for package nesting. Which one is it? |
| Package import |
UML package imports unduly restricts what an importer can say about the
elements from an imported package e.g. It is not clear whether a model element can have
new attributes and operations defined on in when imported into other packages, and then
composed together automatically when re-imported in a "diamond" import
structure. Catalysis uses such a facility to great effect in separating different
horizontal and vertical views of any problem domain. |
| Pattern |
UML pattern. However, patterns in UML and RUP appear defined to be about
use case realizations. In fact, patterns can be about a single type, a static model, a
dynamic behavior, and even a refinement relation between two entire models. Patterns in
Catalysis have fully defined semantics using framework packages and import with
substitution. There are even tools that provide support for this advanced facility. These
provide a basis for design patterns, user-defined stereotypes, domain analysis patterns,
business process patterns, template classes, template collaborations, design
transformations, and more. |
| State - treated as a boolean attribute i.e. a predicate.
You can do the same things with a state as with any other attribute: read it, modify it,
write invariants on it... |
In the UML 1.1 there is no semantic connection between a state and an
attribute. Thus, after introducing a state old, there was no way to refer to it
from OCL with e.g. person.old. UML 1.3 attempts to rectify this by
introducing an instate(state):boolean function, but overlooks the fact
that the structure of states imposes an invariant on which states can be true
simultaneously. |
| State Transition |
In the UML, there is a detailed breakdown of very many different kinds of
transitione, events, and actions, effectively defining an computational model for
communicating finite state machines. Surprisingly, state transitions have no semantic
connection to pre/post conditions on operations specified in OCL. This again leave some
worrisome loose ends dangling. In Catalysis, a state transition is a graphical depiction
of a (partial) action specification. |
| State chart |
State chart. In Catalysis we integrate state charts very tightly to
actions and their specifications: a state charts is just a graphical way to define states
(boolean attributes and static invariants about state inclusion and exclusion) and actions
(defined by transitions between states). |
| Simply a type with a potentially infinite set of members whose
relationship to each other (and to other objects) can be immutable and defined by static
invariants. |
Values vs. Objects - the UML treats "values" as
different from objects. |
| An enumeration type simply has a predefined set of named members. Can be
defined as a frameworks, rather than a primitive construct. |
Enumeration type |
| Type constants |
Shown as a "class attribute" with an underlined name. |
| Simply a substitution when importing the framework package which defines
the template. |
Binding - used to describe the parameter bindings in a
template class instantiation. |
| Activity Model - except that the ovals represent actions, and pre/post
states correspond to the lines between actions. We most often use an
activity model to document an action refinement i.e. to show how an
abstract action is composed from some finer-grained actions. |
Activity Model - the UML describes the ovals in an
activity diagram as states, and the arrows as self-triggered state transitions. Yet, when
describing object states (e.g. Order[paid]) on an activity diagram, the state is
attached to the transition (before or after an activity). Confusing, possibly
inconsistent.\ |
| Component, connector |
These very expressive architectural views of component-based systems are
not directly defined in the UML. Catalysis supports them using types (and the
"fractal" nature of objects and interactions) and frameworks (to extract
interaction protocols into genericized protocol connectors) |
| Composition |
UML does not define rules for composing models, or partial views defined
in different places (e.g. different diagrams or packages). Catalysis provides these rules. |
| Not necessary once you understand packages, types, and the
"fractal" nature of modeling. At most these are a descriptive label or comment. |
Model, Subsystem |
| Not needed as primitive constructs, as they can be directly modeled
as frameworks. |
Aggregation, Powertype, others |
| Type as Set - a type is a set of objects; the type
specification is a specification of that set. |
The UML does not treat a type (or class) as a set of objects. Yet it does
treat members selected from a class by a state predicate as a set. For example, UML 1.3
now treats Order[fulfilled] as the set of orders (a type) that have been
fulfilled (a state). This could be made simpler and more consistent by treating
the type as a set, and a state as a boolean attribute (or predicate); then Order[fulfilled]
would just be an OCL selection expression defining the set of Orders that are fulfilled. |
| |
|
| |
|
| |
|
