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