Catalysis Methodology
Ali Khoshgozaran
August 2002
khoshgozaran@ce.sharif.edu
1
Agenda








Definition
Highlights of Catalysis
Catalysis in Practice
Design Issues
Abstraction Layers in Development
Some Case Studies
Different Refinements
Conclusion
2
The Name

Catalysis
• 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.
3
Typical Enterprise Evolution Path
“As-Is” Inventory
“To-Be” Planning
• Very heterogeneous hardware and software platform mix
• Rampant duplication of effort, functions, code
• Very difficult to maintain and change
• Inconsistent and conflicting architectural styles
•Too many “magical” gaps between business need and code
Transition …..
• Tools
• Methods
•Architectures
•Education
•Maturity transition
•…
•Component-based, architecture and reuse centric, business driven
•Layered architectures separating UI, application, business, data
•A more mature, repeatable, sustainable business and IT development process
4
Talk Preview - Success With Components
Traceability
Business Driven
bridge Business and IT
precise shared vocabulary
understand business first
critical business questions early
Architecture
interfaces
plug standards
Reuse Process
develop for reuse
develop with reuse
reuse interface,code
Pluggable Components
precise interface-centric design
traceable business components
5
A Multi-Pronged Approach
Catalysis CBD method
Next-generation approach
=Precise models and
systematic process
Roles, activities, …
Process implementations
Object and component modeling
Data modeling
Business modeling
Configuration management
Project management
Methods
&
Processes
Tools
Catalysis
Core
Services
Strategic Consulting
Education
Systems Development
Systems Integration
Architecture
&
Reuse
Consistency via Architecture &Reuse
Design patterns
Interface and technology standards
Code components
6
Highlights of Catalysis

Traceability

Precision

Components

Reuse

Scalability

Process
7
Traceability and Catalysis

Traceability from business models to code
• Same techniques and notations apply from business level to code
• Explicit refinement relationship: business, design, and code
• Improved configuration management, testing, maintainability
• Frameworks enable reuse of standard refinement patterns
8
Precision with Catalysis

Precision
• Uncover important problems early
• Create clear and concise documents and models
• Build explicit shared vocabulary
Enhance scalability to large systems, enhance traceability, testability
9
Component-Based Development with Catalysis

Component Based Development
• Strong support for interface-centered design
• Black-box descriptions of components that are clear and simple
• Leads to rapid assembly and flexible configuration from parts
10
Reuse with Catalysis

Strong emphasis and fundamental support for reuse
• Reuse not simply implementations, but interfaces, architectures,
business models
• Eliminate duplication of work - each important design, spec, or
architecture element defined once and only once
• Build up consistency via patterns and frameworks
11
Catalysis Process
Requirements
Understand problem, context,
& non-functional req.
System Specification
Architectural Design
Domain Models
System Context
boundary
Scenarios
Operation Specs
Platform, Phy. Architecture
Partition technical & application
architecture components
Log. Application Architecture
Dictionary
Describe external behavior of
the system
Outside
(+ project
constraints)
UI Design
inside
DB Design
Component Internal Design
Interface and Class Specs
Design interfaces for each
component; build and test
Implementation and Test
12
Three Modeling Scopes or Levels
Level/Scope
Goal
Domain/Business
“Outside”: Identify Problem, Solution
establish problem domain terminology
understand business process, roles, collaborations
build as-is and to-be models
Component Spec
Internal Design
“Boundary”: Specify Component
scope and define component responsibilities
define component/system interface
specify desired component operations
“Inside”: Implement the Spec
define internal architecture
define internal components and collaborations
recursively design insides of each component
13
Catalysis in Practice
system
c
System
c1
a
m1
m2
b
c2
x
y
m3
m4
14
Main Elements of Catalysis


Object: Representing a cluster of information and
functionality
Action: Representing any-thing that happens :
•
•
•
•
•
•
•
An event
Task
Job
Message
Change of state
Interaction
Activity
15
Actions and Postconditions
Teach
Teacher
Object type


Action type = Use case
Student
action (student, teacher) :: teach (skill)
post -- this skill has been added to the student’s
accomplishments (Skill here is an attribute )
16
Precision in Business Models
Business model -
The actions (use-cases) that take place between objects
(actors) in the business, with each action specified in terms
of a supporting model of concepts (glossary)
Purchase (customer, sales rep, item list)
post: sales rep has new sale with totaled cost for
items based on quantity and product price
purchase
Actor
Customer
pay by bank card
Sales Rep
Pay by bank card (customer, sales rep, credit system, card)
post: sales rep has authorized payment on customer card
from credit system for the sale total, and recorded sale
Credit
Authorization
System
Use-Case / Action
17
Elements of an Action
Teach action is a composition made up of the smaller ones
Assembly
18
Actions at Different Scales
Collaboratio
n Diagram
Teach
Action Type
Object Type
Arrange
Zoomed-in
actions
constituting
teach.
Run Course
19
An Occurrence of the Teach Action
Sequence
Diagram
Object Instances
Action
Occurrences
20
Assigning Responsibilities to Objects

First state what happens

Then state which object is responsible for doing it

Which one is responsible for initiating it

Actions characterized by what they achieve

Then by how they achieve it
21
Associations
The useful aspect of associations:

Don’t have to say exactly how they are realized

Statements about how actions affect them are still
meaningful

These specifications are abstract and yet precise

They expose inconsistencies of natural language
22
Refining Associations
Assembly
Association

Use of stick figures instead to highlight roles

Several roles can be played by one object
23
More Detailed Description
Zooming in and out is useful when seeking
 What a business does
 Why it does it
24
Business Modeling

The main objective is for the model to represent how the
users think of the world with which they work

Starting questions are “What do you do?” and “Whom do
you deal with?”

Every time you introduce a new object type, add to the list
of questions “What actions affect that? What actions does
it affect?”
25
Business Modeling (cont.)

Every time a verb is mentioned, draw an action and add to
your list of questions
• “Who and what else participates in that?
• What is its effect on their state?”

The answers to these questions lead you to
• Draw object types
• Write post conditions

These in turn lead to associations and attributes
26
Traceability from Business to Code
Zoom in/out of use-case (user task)
(abstract action or detailed dialog)
Zoom in/out of objects
(external or internal view, including software)
schedule
buy course
Company
deliver
Company
Client
Client
pay
Refinement
(mapping)
SW System
schedule
schedule
deliver
deliver
Company
Client
Client
Company
pay
pay
• Fractal zooming without losing preciseness
27
Rules = Actions + Static + Dynamic Invariants
“New session created, confirmed if qualified instructor available”
schedule
deliver
Students
skills
Company
Instructor
qualified
Admin
funds
pay
Session
date, topic
cost
assigned
“Any change in session must propagate to scheduler”
Dynamic Invariant
“Assigned instructor is qualified for topic”
A state change rule that applies to all actions
Static invariant
Attribute constraint in all states
• Captures important rules accurately without getting into implementation details
• Enable the User to raise and resolve critical issues early
28
Design Issues
29
Directed Actions




At some stage in a completed design all actions turn into a
dialog, in which each action is a message with
A definite sender (with responsibility for initiating the
action)
A receiver (with responsibility for achieving the required
outcome)
And parameters (that do what the receiver asks of them)
These are called directed actions; when viewed strictly
from the side of the receiver, they are called localized
actions
30
Separation of concerns
This skill is crucial, in Catalysis we provide the means to
separate different layers of design decisions:

The behavior that is required (post conditions)

Assignment of responsibilities (roles and collaborations)

The way each object and action is implemented
(successive refinement)
31
Catalysis Vs. Others


Abstraction technique in Catalysis:
•
Treat a complex system as one object
•
Treat complex interactions as one action
•
Yet state the out-come precisely
This approach contrasts with more-traditional design
techniques in which abstract also tends to mean fuzzy
32
Abstraction Layers in Development
Two to five layers of abstraction in development :
( a bigger number for more complex projects )


Business model (sometimes called domain or essential
model): Describes the users’ world separately from any
notion of the target software.
Requirements specification: Describes what is required
of software (no reference to how it is implemented). It is
mandatory for a major component or complete system. It
may be approached differently when the complete system
is created by rapidly plugging kit components together
33
Abstraction Layers in Development (cont.)
Component design: Describes (on a high level) how the
major components collaborate, with references to a
requirements specification for each one. Needed if there
are distinct major components
 Object design: Describes how a component or system
works, down to programming language classes or some
other level that can be coded (or turned into code by a
generator)
 Component kit architecture: Describes the common
elements of the way a collection of components work
together (e.g. standard interaction protocols).
 Different developers build interoperable components

34
Static Models and Invariants
(Client, SeminarCo) :: arrange (Subject)

Business rules can be written as invariants:
inv -- for every CourseRun, its instructor’s qualifications
must include the course
CourseRun :: instructor.qualifications -> includes (course)

The invariants are described informally and are written in a
simple language of Boolean conditions & set relationships
35
Snapshots

Draw Snapshots to help visualize the effects:
Newly created
object links
Association
inherited from
supertype
Action postconditions:
instructor.outage@pre[when=d] = 0 & instructor.qualifications -> includes (t) ]
36
Actions and Postconditions
action (c: Client, s: SeminarCompany) :: arrange (t:
Course, d: Date)
post -- a new CourseRun is created with date, client, course
r : CourseRun.new [date=d, client=c, course=t]
-- assigned instructor who was free on date d and
qualified for the course
37
Another Example: ATM

A simple ATM user:
type User
walletAmount : Currency .. What the user has got in her
pocket
account : BankAccount .. Her bank account
end
type ATM
cashAmount : Currency .. What remains in the machine
end
38
Example : ATM (cont.)

The getMoney action describes an ATM transaction:
action (u:User,a:ATM)::getMoney(amount:Currency)
pre : u.account.balance > amount
pre : a.cashAmount >= amount
post : u.account.balance = u.account.balance - amount
post : a.cashAmount = a.cashAmount - amount
post : u.walletAmount = u.walletAmount@pre + amount
end model
39
Object Oriented Design
The process begins by turning many things in a model into
classes:





Hence, Instructor, Course Run, and Course now become
classes
Roles are assigned to the classes, as for components
The actions at this level are finally standard OO messages
The associations become pointers, decisions are made
about their directionality
Design patterns are used to guide these decisions (as they
can be used throughout the development process)
40
Object Oriented Design (cont.)
The end result of OO design is a collection of :

Classes that encapsulate program variables and code

Types that define the behavior expected at the interfaces to
classes. Classes implement types

Next, component implementation (the “Insides” process)
commences
41
Refining Catalysis action types using UML



How Catalysis action types can be modeled in UML?
The UML Action concept: an action is executed when a
stimulus is (bound to this action) received  completely
different from the one we need
The UML Collaboration concept: describes interactions
among objects. Using Collaboration to model Catalysis
seems possible
The UML Use Case concept bears similarities with the
concept of Action in Catalysis. A Use Case connects
several participants, is extensible, and therefore is a good
candidate to represent refinements
42
UML Use Cases VS Catalysis Actions
They are somewhat different for several reasons:

Use Cases: interactions between some central object and
its environment, which includes actors. On the contrary,
Catalysis actions give symmetric roles to its participants

Use Cases are modeling tools showing interactions
between actors and the system. This is not as flexible and
precise as a speciation tool as Catalysis' pre/post conditions
on actions.
43
A simple usecase refinement
Provide Id
<<refine>>
Get Money
Get Money
<<include>>
Get Cash
Request
Money
44
Review

UML + simple consistent approach, process, techniques
•
•
•
•
•
•
Traceability from business models to code
Precision, with clear unambiguous models and documents
Component Based Development
Reuse of designs, specs, problem domain models, architectures, ...
Scalability from small to large teams and projects
Process that is flexible yet repeatable
Next Generation Solutions
45
References

http://www.catalysis.org

http://www.catalysis.org/publications/catalysis.zip

http://ase.arc.nasa.gov/wtuml01/submissions/plouzeausunye.pdf

http://www.cetus-links.org
46