Catalysis 'lite'

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

Catalysis 'lite'
Catalysis complete
Process routes






You can use the Catalysis approach in a "lite" way by simply adapting which deliverable you will make a formal part of your process, and how rigorous you will be about the specifications. Here is a simplified example; a more complete description will be published here later.

The key points to note are:

A "model" in Catalysis can be pictures, formal text, or informal prose
A precise shared glossary is not worth compromising on, even in a "lite" process
Test-driven design and programming gets some of the benefits of more careful specification

Some of the activities below may span multiple days or weeks, others may just be a few hours long, depending on your project.

Activity Lite variant
Domain model
Produce a 1-time concept map; e.g. the Catalysis map
Write a glossary of terms
System spec
Draw a system context model to clearly bound what is "inside" and "outside" your system. Show your system and external roles (for users, hardware, software) and collaborations between them (using abstract use cases). Do not add new functionality or interfaces to the system without updating this model.
Write informal post-conditions for operations on the system in terms of attributes on your system type model. Exercise with some concrete scenarios.
Prioritize the use cases, plan the initial increments. Tackle the high priority ones in your early increments.
Produce/update a system type model as a text/tabular glossary or UML diagram. Check that the terms you use in the operation specs are defined in your type model.
Don't forget to include the minimal necessary model (operations, glossary) of any external on whom you rely for services.
Sketch or prototype the system UIs. Check that you can reasonably name the UI elements in terms of your type model and its attributes.
Application Architecture
Design each type from your system type model as a class to be implemented. If the system is complex, use an intermediate level of singleton "components" that you treat exactly like the "System spec" above:
Name, draw, and identify primary responsibilities for each one.
For each system operation, work out collaborations between the components to implement it.
For each system operation, design the interactions down to the level of operations on each component or class. Write an informal pre/post for these operations, optionally supported by a glossary for that component.
Design packages to separate interfaces and implementations; if you are using an intermediate layer of "components", use packages to separate each component spec from its implementation.
Technical Architecture
Select the technical architecture:
Nature of communication channels between components: document with stereotypes on collaborations to indicate the nature of the protocol e.g. <<sql>>, <<rmi>>, <<events>>, <<javabeans-com-bridge>>.
Utility components and code you will use: logging, security, parsing. Treat these as packages and show their usage in the implementation packages with <<import>>.
Prototype, functional test, and load test an early implementation of technical architecture with a most minimal use-case that you carry through from UI to database and back.
Construct, Integrate, and Test
Design, write tests for each method, class, use-case
Implement and run tests

Of course, there would be many more aspects to the process, dealing with incremental delivery, light-weight documentation templates, iterative development, configuration management, QA processes, roles, deployment, training, and downstream issues. You will find these described in more complete implementations of a Catalysis process.

Email suggestions to All contents copyrighted 1998.