Table of Contents

This FAQ will be frequently updated initially. Feel free to post about these or other questions for this FAQ using the form below.

1. 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.

   

2. 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.

   

3. 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 webmaster@catalysis.org.

   

4. 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 mentoring help.

   

5. 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.

   

6. How to do use-case "uses" and "extends"? or "includes" and "extends"?
   
   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 that reference.
   
   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 package.

   

7. 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.

   

8. How do FAQs about use-cases relate to Catalysis?
   
   Ah. There is much to be said here. Coming soon.

   

9. 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 course..."
   
   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"

   

10. 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:
    select (Selection)
    
    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.

    

11. How many levels of refinement should I have?
    
    Seven.
    
    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.

    

12. 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 itself.

    

13. 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.

    

14. 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 it.

    

15. 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.

    

16. 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.

    

17. 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.

    

18. 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.

    

19. 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 invariant.
    
    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.



20. 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.

    

21. 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.

    

22. What does the UML aggregation symbol mean?
    
    Coming soon - a clarification and systematic way to use this symbol using Catalysis frameworks.

    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.

    

23. 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.

    

24. How far should I partition "roles" e.g. of actors?
    
    Should Supervisor be one role? Or should I separate SignerOfTimeSheet and ApproverOfVacation?

    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.

    

25. I heard there is a Catalysis-"lite" process. What is it?
    
    Take a look at the Process section.

    

26. 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.

    

27. 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 soon.

    

28. 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 other alternatives.

    

29. 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 AnamolyMonitor".