This FAQ will be frequently updated initially. Feel free to post about these or other
questions for this FAQ using the form below.
- What does "catalysis" mean?
An acceleration of the rate of a process or reaction, brought about by a
catalyst, usually present in small managed quantities and unaffected at the end of the
reaction.A catalyst permits reactions or processes to take place more effectively or under
milder conditions than would otherwise be possible.
- Where does it come from?
Catalysis was developed by Desmond D'Souza and Alan Wills, and is published in a
book by Addison-Wesley. It draws heavily on experiences and lessons learned and problems
encountered with OMT, Objectory, Fusion, UML, Syntropy, as well as formal methods; and has
been defined largely through application on projects since 1992. Catalysis contributed
significant concepts into the definition of UML 1.0 onwards, including type,
refinement, precise specifications, collaboration, and patterns/frameworks.
- Who has used it?
Catalysis has been used, as it evolved and matured since 1992, in fields including
telecommunications, finance, manufacturing, process control, embedded systems, travel and
transportation, and systems management. Companies who have used it include Siemens, EDS,
Texas Instruments, Fisher Rosemont, USAA, Credit Suisse, Olivetti, Yellow Services,
Sterling Software, Hewlett Packard, Citibank Visa, Lockheed Martin, and others. If you
know of others, drop a note with a reference to firstname.lastname@example.org.
- What is the easiest way to get started?
Become familiar with some of the introductory material available on, or through this site,
including the Publications section. Get a
Catalysis book (which, admittedly, is somewhat dense in it's content). Attend a Catalysis
tutorial at a public forum or conference, or arrange for either a presentation or
full training courses on Catalysis. It is a good idea to start applying a
"light" version of the method after such training, preferably with some
- How should I read the book?
Don't do it all in one sitting! The book preface has guidelines on reading for
different audiences. Skip the sections that are marked as "advanced" on your
first reading. Read some introductory materials or presentations from this site to give
you and overview before you dive into the book.
- How to do use-case "uses" and "extends"? or "includes" and
This will grow into a longer answer...the short version is:
Treat "uses" or "includes" simply as one Catalysis action referring to
the effect specification of another action. There is nothing profound about this -- you do
it all the time in your code when you have one procedure "call" another. Using
Catalysis actions, you can be more precise about "parameters" and the context of
Treat "extends" simply as a fancy editing construct: you define a basic sequence
of steps that realize the abstract action in one place; elsewhere you want to
"edit" your definition of that use case by adding some additional paths. This is
just a fancy equivalent of taking a piece of tracing paper, laying it over the original
use case, and drawing some additional appendages on it.
If you want to do "extends" to define multiple versions of a use-case, put the
action and the base sequence of steps that realize it into one package; then import that
package into another and define the <<extends>> relation in the second
- How do I define the "system boundary"?
Carefully. Be very aware of what behaviors you consider "inside" versus
"outside" the system. Also, be aware of whether you are defining all external
views of that system, or just a one-sided view. If the latter, your model of the one-sided
view may include a simplified view of the behavior of agents on the "other
sides" of that system.
- How do FAQs about use-cases relate to Catalysis?
Ah. There is much to be said here. Coming soon.
- Where can I leverage convenience attributes?
Anywhere you need to make a statement that refers to some state information of an
object, and can express it more simply by inventing other terms. For example:
"...all instructors who have passed a qualification exam for the
could be simplified to:
"...all qualified instructors for the course..."
What you have done is introduce a new attribute (the set of instructors qualified for a
course), which you may draw as an association; and then re-stated your requirement more
simply in its terms.
Of course, when you do introduce such a convenience attribute you must also
define what it means in terms of other attributes. Below is the informal version; it can
trivially be formalized, and checked.
"the qualified instructors for a course are those instructors who have
passed a qualification exam for that course"
- What do "parameters" in abstract actions mean?
They do not directly represent the actual data passed back and forth in the
code. Instead, they are an abstraction of any correct information exchange protocol that
may be used in any correct implementation.
For example, you may make a selection in a text editor by some sequence of:
<up, down, forward, back, forward(n), back(n)>
At the abstract level you might model an action:
The refinement relation must document how the concept of Selection is related to
the data exchanged. For example, if we model Selection by a start and end
position, we would document how the start and end of the (abstract) selection is defined
by the number and parameters of the up, down, ... forward(n), back(m) actions.
And this information would be crucial for inspections, design reviews, and testing.
- How many levels of refinement should I have?
More seriously, there is no single answer to this. A business model, the system
spec, the high level design, and the code are often sufficient. Remember, refinement is a
relation, and not a sequence; so you don't necessarily do this top-down.
- Where does database design fit in?
We will distinguish when the database design starts in a particular development
sequence, from where do database design issues (and vocabulary) appear in the conceptual structure of the
deliverables. The latter appears where you need to distinguish the database from "the
application". While this is sometimes problem dependent (e.g. you may have
requirements that talk about a database shared with other applications -- in which case
the system context itself might model the database as an external actor), life is
typically simpler if your initial models treat <application + database> as a single
type, abstracting any database issues into the logical view of that information as a
idealized type model. Thus, you may freely use convenience attributes to simplify your
models in this single type view, while you may need to minimize (for normalization) or
introduced different redundancies (for caching and performance) in the database design
- What are the implications of having a canonical package structure?
Many. We will elaborate on this soon.
The short answer is that you can understand the end structure and result to be produced by
the development effort independent of particular sequences
in which the work is done to populate that structure. There would be very different
"routes", or work-breakdown structures, for projects which built everything from
scratch, or did heavy reuse of existing components and frameworks, or were built by
outsourcing the development of well-specified sub-systems to multiple sub-contractors.
More fundamentally, there are many mini-"patterns" of package structures
themselves i.e. Catalysis "frameworks" of package structures. These cover
structures for separating interfaces from implementations, defining refinement models,
incorporating existing or legacy components, and dealing with incremental development.
- Why have joint actions? Where and why would I use them?
Joint actions let you defer certain (often volatile and unnecessary) decisions. They
abstract interaction protocols and responsibility assignment, and specify the net
effect of any of those protocols. Remember that you can have lots of variations of how two
parties collaborate to get a particular job done, and it is useful to specify the job to
be done separately from the particular collaboration protocol they follow to accomplish
- Why does a package of a business model import a system spec package?
An abstract business model need not refer to software systems at all (provided, of
course, the problem domain is not essentially about such systems). A detailed
(refined) business model might explain how some business processes are realized by
interactions that include the software systems. Of course, the same software system could
be used with different business processes (with the exception of some well-known ERP
systems :-), so the specification of that system should be independent of the particular
business process within which it is deployed in a particular configuration.
- How should I interpret pre/post/rely/guarantee specifications?
Treat them as a quartet. If an action occurs in a state in which the precondition
was true, and the rely condition is maintained true while that action is executing (only
relevant for concurrent actions), then a correct implementation must guarantee that
the postcondition becomes true upon completion of that action, and that the guarantee
condition was never violated during that action.
Each action can have many such quartets; the AND of all quartets must hold.
- How should I interpret pre/post in abstract actions that become refined, and how do they
relate to the pre/post/rely/guarantee of the refined ones?
Ah. Coming soon.
- Are diagrams and models the same thing?
No. A model is an abstract concept; you can render or describe it in pictures,
tables, or text. Too often people consider the pictures as an end in themselves; they are
not! A piece of narrative text, a dictionary definition, a short rule expressed in formal
OCL, will often be far more useful than forcing everything into pictures.
In the Catalysis book we were not always sufficiently strict in our naming, often using
"type model" to mean a particular UML-based diagrammatic representation. We will
publish more consistent definitions shortly.
- What is the difference between action, effect, event, effect invariant, signal,
exception and required service?
An action is an abstraction of some interaction between objects. Every
action has some effect.
An effect is a state change, such as "order got fulfilled", or
"stock price dropped three days in a row", or "administrator
now knows all new alarms since she last checked alarm status". It can always be
modeled as a before/after predicate on some model of attributes. Important effects may be
given a name and referred to in many places.
An event is a named effect.
An effect invariant is a specification construct that acts as a triggering rule,
commonly of the form: for any action that takes place, if that action
causes an order to become fulfilled, then that action must also cause the invoicing
cycle to begin.
A (UML) signal is a design construct for communication about an event from a
source (which recognizes that a change has taken place) to a destination (which may need
to respond to that change). In general, events can be signalled to any number of
interested parties; the signal is a design choice that typically realizes an effect
An exception is an outcome (postcondition) of an action, whose effect is
considered "abnormal". Exceptions can be specified as a part of action
specifications, and designed using different signalling mechanisms to communicate about
that exception. Exceptions are signalled from the receiver of a request to the initiator
of that request.
- Components and connectors confuse me. Explain the idea to me at a developer level.
Coming soon. The idea is simpler than you might guess (and simpler than the book
description might lead you to believe :). And extremely useful to help you think more
abstractly about design or architecture.
- How is refinement different from standard sub-classing or sub-typing?
In some important ways. When you subclass, the implementation of the child class is defined
in terms of its parent, including all the instance variables and methods. Similarly, when
you subtype, the child type is defined in terms of its parent, including all its
attributes and action specifications.
Refinement is more general. With refinement, you
are taking two different levels of abstraction (e.g. an interface spec and an
implementation class, or an abstract action and a detailed interaction protocol to realize
it), each with its own models (attributes vs. instance variables, action specs vs.
procedural method bodies), and showing the mapping between them.
Details coming soon.
- What does the UML aggregation symbol mean?
Coming soon - a clarification and systematic way to use this symbol using Catalysis
There are too many loose interpretation about what the aggregation
"diamond" means. Our view in Catalysis is that the notation is the least of the
concerns; the interpretation is of essence. You can create a Catalysis framework for "every
<X> is lifetime-dependent on that <Y> instance which is its <r>
attribute", and then use that as a stereotype on any association. Or, "every
<X> is inaccessible to any other object except through that <Y> instance which
is its <r> attribute", and use that as another stereotype. Or, "once
an <X> gets into an <r> relationship with a <Y>, it must remain with
that same <Y> until it ceases to exist".
You can even combine stereotypes.
And lastly, if you really find it convenient, you can define a particular diamond
notation to mean a specific such interpretation and use it as a notational shorthand.
- How can I reuse existing designs in new models and specifications, without requiring
that those designs and code be used in the implementation?
The answer lies in the Catalysis definition of effects. Coming soon.
- How far should I partition "roles" e.g. of actors?
Should Supervisor be one role? Or should I separate SignerOfTimeSheet
The answer lies in the specific behavior you want to
describe, as behavior descriptions in Catalysis induce corresponding attribute models. 2
roles whose behaviors specs need to refer to common attribute values (i.e. their
behaviors are really state dependent upon each other) should either be (a) modeled as 1
role; (b) modeled as 2 roles with an explicit association and invariant between them, so
the state dependency is well defined; (c) modeled as 2 roles with an explicit interaction
between those roles as well. Details coming soon.
- I heard there is a Catalysis-"lite" process. What is it?
Take a look at the Process section.
- What does it mean to say that "document structure follows package structure"?
The structure of your document - requirements, specification, architecture,
implementation - should correspond to the structure of your packages. Moreover, you should
follow the same rules as with packages: in any given section of your document, you should
try to only refer to terms and concepts that are defined in that section, or in sections
corresponding to packages you would be importing. Details coming soon.
- What tools can I use on a Catalysis project?
Two answers. First: use any UML tool you are comfortable; just follow sensible
guidelines for applying Catalysis. Second: use a tool that offers specific support for the
kinds of advanced modeling capabilities that are enabled by Catalysis. Details coming
- How do I add OCL-based precision to my Rose/P+/Select... models?
Icon Computing had an add-on called Xtend:Specs; search the web for
- What are invariants?
At the risk of sounding trite, invariants are things that "don't vary"
while other things change. The two main kinds of invariants defined in Catalysis are:
Static invariants: while the state changes (i.e. for every
state), the static invariant does not vary (i.e. it remains true in every state). This
lets you describe things that are "always" true at any single point in time.
More accurately, it is true for every state before and after any of the
actions that are within the purview of that invariant. Static invariants range from the
simplest type declaration of an attribute (a person's age is "always" a
non-negative integer in every state of that person); to complex relationships that
must hold across multiple attributes in every state ("the qualified instructors
for a course are those instructors who have passed a qualification exam for that
course"). Static invariants can be conditional: e.g. every Man, at any time,
must have a wife if he is married.
Dynamic invariants: (also called effect invariants): while
the state transition varies (i.e. for every state change, corresponding to the
postcondition of any action), the dynamic invariant does not vary (i.e. it remains true
for every before/after state pair). This lets you describe things that are
"always" true whenever "anything happens". More accurately, it is true
of the postcondition of every action in the purview of that invariant. Dynamic
invariants range from the simplest "every operation must increment this
counter" to more complex and conditional "trigger" rules: "every
operation that causes the stock price to drop by more than 3% must also notify the
Visitors' Contributions to the FAQ
Why should I write a postcondition for a method?
A client who will call that method needs to know what it does, but should not see its implementation. The signature and comments are usually not sufficient. A postcondition is simply a way of saying:
"I don't care how you implement this method. If you do implement it correctly, your implementation should pass this <postcondition> test whenever I use it with any data (that passes the <precondition> test)".
You can have many implementations of the same postcondition.
Catalysis seems like a lot of work, and I'm already a good OO
developer. Why bother?
How can we manage database application with class diagrams ? ( In
terms of normalization & integrity of database)
How does Catalysis practically benefit our development process, as
compared to less-formal methods like Rational's Unified Process.
where and how can I use collaboration in Catalysis
Give ERP concepts and methods
Give idea about ERP concepts and methods in details
Give idea about ERP concepts and methods in details
What is the difference between the UML Components and Catalysis?
Lyfe of Catalysis
explain nickle as catalyst
explain nickle as catalyst
Catalysis Vs. ADL
My question is why is OCL not adequate to specify constraints on
How do components and actions relate to the comonent-port-connector
What are the advantages and disadvantages of reuse in UML?
What kind of link is there between UML and OOP?
Is UML any good in designing web applications? and why?
Contribute to the FAQ
If you have a question you think would be frequently asked about Catalysis, we would
like to include it in this FAQ list.