1

Catalysis Methodology

Ali Khoshgozaran

August 2002khoshgozaran@ce.sharif.edu

2

Agenda

Definition Highlights of Catalysis Catalysis in Practice Design Issues Abstraction Layers in Development Some Case Studies Different Refinements Conclusion

3

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.

4

•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

Typical Enterprise Evolution Path

“As-Is” Inventory “To-Be” Planning Transition …..

• 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

• Tools• Methods•Architectures•Education•Maturity transition• …

5

Traceabilitybridge Business and ITprecise shared vocabularycritical business questions early

Traceabilitybridge Business and ITprecise shared vocabularycritical business questions early

Architectureinterfacesplug standards

Architectureinterfacesplug standards

Talk Preview - Success With Components

Reuse Processdevelop for reusedevelop with reusereuse interface,code

Reuse Processdevelop for reusedevelop with reusereuse interface,code

Pluggable Componentsprecise interface-centric designtraceable business components

Pluggable Componentsprecise interface-centric designtraceable business components

Business Drivenunderstand business first

Business Drivenunderstand business first

6

A Multi-Pronged Approach

Object and component modelingData modelingBusiness modelingConfiguration managementProject management

Strategic ConsultingEducationSystems DevelopmentSystems Integration

ToolsMethods

&Processes

Architecture&

Reuse

Services

Catalysis CBD methodNext-generation approach =Precise models and

systematic process Roles, activities, …Process implementations

CatalysisCore

Business problem

Software architecture

Code Deployment

Consistency via Architecture &Reuse Design patterns Interface and technology standards Code components

7

Highlights of Catalysis

Traceability

Precision

Components

Reuse

Scalability

Process

8

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

9

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

10

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

11

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

12

Catalysis Process

RequirementsRequirementsDomain ModelsDomain Models

System ContextSystem ContextUnderstand problem, context,

& non-functional req.

System SpecificationSystem Specification ScenariosScenarios

Operation SpecsOperation SpecsDescribe external behavior of

the system

Architectural DesignArchitectural Design Platform, Phy. ArchitecturePlatform, Phy. Architecture

Log. Application ArchitectureLog. Application Architecture

Partition technical & application

architecture components

Component Internal DesignComponent Internal Design

Design interfaces for each

component; build and test

Interface and Class SpecsInterface and Class Specs

Implementation and TestImplementation and Test

Dictio

nary

Dictio

nary

Outside(+ project constraints)

boundary

inside

UI DesignUI Design

DB DesignDB Design

13

Three Modeling Scopes or Levels

Domain/BusinessDomain/Business

Component SpecComponent Spec

Internal DesignInternal Design

Goal

“Boundary”: Specify Componentscope and define component responsibilitiesdefine component/system interfacespecify desired component operations

“Outside”: Identify Problem, Solutionestablish problem domain terminologyunderstand business process, roles, collaborationsbuild as-is and to-be models

“Inside”: Implement the Specdefine internal architecturedefine internal components and collaborationsrecursively design insides of each component

Level/Scope

14

Catalysis in Practice

System

c1

a b

m1m2

c2

m3m4

xy

c

system

15

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

16

Actions and Postconditions

TeacherStudent

Teach

Action type = Use case Object type

action (student, teacher) :: teach (skill) post -- this skill has been added to the student’s

accomplishments (Skill here is an attribute )

17

Precision in Business Models

Actor

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)

Sales Rep

CreditAuthorization

System

Customer

pay by bank card

purchase

Purchase (customer, sales rep, item list)post: sales rep has new sale with totaled cost for items based on quantity and product price

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

Use-Case / Action

18

Elements of an Action

Teach action is a composition made up of the smaller ones

Assembly

19

Actions at Different Scales

Action Type

Collaboration Diagram

Object Type

Teach

Schedule the course

Deliver the course

Zoomed-in actions

constituting teach.

Run Course

Arrange

20

An Occurrence of the Teach Action

Object Instances

Sequence Diagram

Action Occurrences

21

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

22

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

23

Refining Associations

AssociationAssembly

Use of stick figures instead to highlight roles

Several roles can be played by one object

24

More Detailed Description

Zooming in and out is useful when seeking What a business does Why it does it

25

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?”

26

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

27

Traceability from Business to CodeZoom in/out of use-case (user task)(abstract action or detailed dialog)

Zoom in/out of objects(external or internal view, including software)

Client

Companybuy course

Client

Company

schedule

pay

deliver

payClient

Company

schedule

deliver

Client

Companyschedule

pay

deliver

SW System

• Fractal zooming without losing preciseness

Refinement (mapping)

28

Rules = Actions + Static + Dynamic Invariants

• Captures important rules accurately without getting into implementation details

• Enable the User to raise and resolve critical issues early

Static invariantAttribute constraint in all states

“New session created, confirmed if qualified instructor available”

Dynamic Invariant A state change rule that applies to all actions

Admin

Company

schedule

pay

deliver

Sessiondate, topiccost

Instructorqualified

Studentsskills

fundsassigned

“Assigned instructor is qualified for topic”

“Any change in session must propagate to scheduler”

29

Design Issues

30

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

31

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)

32

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

33

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

34

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

35

Static Models and Invariants

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

(Client, SeminarCo) :: arrange (Subject)

36

Snapshots

Draw Snapshots to help visualize the effects:

Action postconditions:instructor.outage@pre[when=d] = 0 & instructor.qualifications -> includes (t) ]

Newly created object links

Association inherited from supertype

37

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

38

Another Example: ATM

A simple ATM user:

type UserwalletAmount : Currency .. What the user has got in her pocketaccount : BankAccount .. Her bank accountend

type ATMcashAmount : Currency .. What remains in the machineend

39

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

40

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)

41

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

42

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

43

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.

44

A simple usecase refinement

Get Money Get Money Get Cash

Request Money

Provide Id

<<refine>>

<<include>>

<<include>>

<<inclu

de>>

45

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

46

References

http://www.catalysis.org

http://www.catalysis.org/publications/catalysis.zip

http://ase.arc.nasa.gov/wtuml01/submissions/plouzeau-sunye.pdf

http://www.cetus-links.org