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







Catalysis is based on the Unified Modeling Language (UML) and contributed to its definition. However, there are some clarifications and simplifications made in Catalysis which make the core of UML much simpler and more consistent. It is useful to know the correspondence or mapping to UML. Some of these mappings will also help with using Catalysis with a modeling tool that is not Catalysis-"enabled".

The current UML (1.3)

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.

Towards UML 2.0

Jim Rumbaugh, in his March 1999 presentation at UML World '99, lists the following among his prime candidates for being addressed in UML 2.0 in the second-last slide of his presentation:

First-class extensibility mechanism Catalysis already provides this through its use of foundational packages as frameworks. These provide a way to define modeling construct, modeling extensions, and "dialects" of mutually consistent extensions.
Precise specification of refinement semantics Catalysis treats refinement as fundamental construct, of which object and use-case decomposition are special cases.
Versioning of models Catalysis provides a basis for versioning and model management based on packages and their import structure.
More permissive concurrency in activity and state graphs Catalysis uses a declarative approach to state graphs, rather than a complex imperative semantics.
Associations at several levels The Catalysis usage of refinement permits well-defined modeling and decomposition of associations (and attributes, objects, actions, ..... )
Email suggestions to All contents copyrighted 1998.