Catalysis

1
Catalysis

• Objects, components, and Frameworks with UML

2
From the book

• Objects, components, and frameworks with UML the
  Catalysis Approach, by Desmond DSouza and Alan
  Wills.

3
A tour

• Objects and actions
• object cluster of information functionality
• action anything that happens
• actions can be independent of objects. Bound to
  objects later.
• what happens during action
• which object is responsible for doing action
• which object is responsible for initiating action
• how is it done
• actions affect objects

4
Fractal picture

• A fractal picture has the same appearance at all
  scales
• objects business departments, machines, running
  software components, programming language
  concepts
• actions interactions among objects big business
  deals,phone calls, bike rides, etc.

5
Actions affect objects

• Actions collaborations
• In Catalysis collaborations are first-class units
  of design.
• Where should collaborations be used?
• what goes on inside a software component
• user-component interactions
• business modeling how do real-world objects
  interact?

6
Actions affect objects

• Actions have participants (objects)
• Which objects do you need? Enough to describe the
  actions
• Associations provide a vocabulary in which it is
  possible to describe effects of actions (prefer
  class graph over associations)

7
Precise specifications

• action(student,teacher)
• teach(skill)
• post student.accomplishments
• student.accomplishments_at_pre
• skill

8
Refinement

• Of objects and actions
• Zoom in and out

9
Connection to aspectual components

• objects, components (actions), connectors
• actions have a modification interface

10
Commonalities Catalysis/AC

• actions independent of objects
• abstract does not mean fuzzy
• program should be structured according to a
  business model
• static model

• AC independent of objects
• AC is abstract and executable
• program should look like a design
• participant graph

11
Differences Catalysis/AC

• actions cannot describe aspects
• uses pre- and post-conditions
• no connectors

• AC (when modification interface is used) can
  model aspects
• should use pre and post conditions
• connectors keep components clean

12
Development Layers vanilla development from
scratch

• Business model (domain/essential model)
• Requirements specification
• Component design
• Object design
• Component kit architecture needed to build
  interoperable components
• April 11,99

13
Static models and invariants

• An actions postcondition can be written in terms
  of static relationships
• Connection participant graph of AC contains
  information to describe postconditions

14
Model Frameworks as Templates

• Similar to AC, but no aspects
• parameterized

15
Requirements Specification Models

• Objects in this diagram are not real objects but
  rather the systems own representation of them
• Static model is a hypothetical picture created
  for explaining the systems externally visible
  behavior to its users.

16
Static model (continued)

• There is no mandate on the designer to implement
  it exactly with classes and variables that mirror
  directly the types and associations in the spec.

17
Partitioning the model between components

• Each of the components performs only some of the
  systems functions and includes only part of its
  state
• different vocabulary need map
• reconstruct all the attributes and associations
  from component design

18
Collaborations

• Now a collaboration is a collection of actions
  and the types of objects that participate in them
• Sometimes they say action collaboration

19
Testing

• When does a more detailed design
  conform/implement/refine a more abstract one?
• How to test different kinds of refinement
  relations?
• Connection refinement/testing

20
Testing

• Pre and post conditions useful for testing
• test harness
• C STL library has assert macro
• Every component needs to have its own test kit to
  monitor behavior in new context

21
Retrieval functions

• Every implementation should have a complete set
  of retrieval functions that is, read only
  abstraction functions for computing the value of
  every attribute in the spec. from the
  implementation
• Need to translate from one model to another
• Retrieval functions can be inefficient only used
  for verification e.g. testing.

22
Retrieval functions

• Long history VDM, Z
• support traceability how change in spec or code
  influences the other
• use retrieval diagrams

23
Benefits of retrieval functions

• cross-check
• make it explicit how abstract model is
  represented in the code
• testing execute postconditions and invariants
  defined in requirement model

24
Golden rule of OOD

• Choose your classes to mirror your specification
  model. 1-1 correspondence often not possible
• model that gives best performance often different
  from one that clearly explains what the object
  does
• multiple models are implemented simultaneously
  each model partial view

25
Testing by adapting the implementation

• Specification (with test information)
• Implementation package
• Adapter
• Implementation

26
Spreadsheet
Content

Cell
content
value
shows
right
left
Number
Sum
Blank
Invariants for all Sum objects s s.value
s.left.content.value s.right.content.value for
all Blank objects b b.value 0
Simplified a formula can be only the sum of two
other cells
27
Spreadsheet
Content

Cell
content
shows
value
abs
Sum s s.left s.impl1.operands1.abs s.rights.
impl1.operands2.abs s.values.impl1.container.va
lue
right
left
Number
Sum
Invariants for all Sum objects s s.value
s.left.content.value s.right.content.value for
all Blank objects b b.value 0
abs
Blank
abs
RETRIEVAL DIAGR.
impl1
Spreadsheet_1
impl1
impl1

sumpart
Cell_I
Sum_I
container
shows
isBlankboolean value

operands
28
Retrieval functions with DJ

• How to represent the participant graph?
• Use strategy graph. Introduce a string for each
  edge. E1 A-gtB bypassing X. class A B
  getB()return (B)
• tg.fetch(this)
• tg is the traversal graph for E1.

29
Retrieval functions

• Overlay concrete class graph with participant
  class graph using getter functions that are
  implemented using strategies. Name map is
  identity map.
• Can simplify class graph before writing
  strategies. Can introduce multiple class graph
  views.

30
S is participant graph for G
Ft
F
D
D
E
E
B
B
C
C
S
G
A s
A
31
Catalysis Process Main Theme

• Higher-level
• Lower-level, a refinement of higher level.
  Retrieve mapping from higher-level to
  lower-level.
• For every specification activity there is a
  corresponding implementation and testing activity

32
Typical Process for a Business System

• Requirements
• System Specification
• Architectural Design components/connectors
• application architecture packages,
  collaborations
• technical architecture hardware, software
  platform, infrastructure components
• Component Internal Design

33
Typical Project Evolution page 522

• The business case initial requirements
• Domain or business model independent of software
  solution. Reusable across multiple projects.
• Joint-Application Development developers/users
• Glossary

34
Typical Project Evolution

• Type model plus system specifications. Primary
  actions system participates in. Refined to atomic
  interaction with system.
• UI sketches
• Subject areas
• Generic problem frameworks
• Refactor for reuse

35
Typical Project Evolution

• Design rules for technical architecture
• Technical architecture model
• Horizontal slices architecture simulation
• Application architecture design of application
  logic as a collection of collaborating components
• Project plan, deployment

36
Testing/Specification

• Write action specifications precisely enough
• to form the basis for testing and
• to make the model explicit enough to uncover
  business issues

37
Chapter 3 Behavior Models

• Component-based software development separate
  external behavior from internal implementation
• Describe behavior by list of actions and
  response to those actions (called the components
  type)

38
Actions

• action
• (party1Type1, party2Type2,)
• actionName()
• not centered on a single object type
• action effect is described in terms of of all
  participant

39
More precise action specifications

• Well-written pre- and postconditions can be used
  as the basis for verification and testing
• Use general syntax from UML called Object
  Constraint Language (OCL). More convenient than
  Java
• Pre- and postconditions

40
Two parts of a specification

• Static model (structure) UML class diagram and
  invariants
• Type specification (behavior) specify effects of
  actions on component using vocabulary provided by
  static model
• This chapter about how to derive and write type
  specifications. Examples follow.

41
Static model with behavior
Course Scheduling
staff
fullSchedule


Static model
instructor 0..1
Client
Session
Instructor
sessions

rating Grade
sessions

grade Grade date Date
client
ordered date
Invariant (business rule) fullSchedule.grade
ltfullSchedule.instructor.rating
checkAvailability(instructor,date) post find
whether instructor is doing a session on that
date scheduleCourse(date,client) post set up a
new session and assign an instructor
behavior
Behavior defined in terms of static model
42
Static Model
find all persons waiting at any bus stop on a bus
route

busStops
BusRoute
BusStop
0..
DOES NOT REVEAL TOO MANY IMPLEMENTATION DETAILS
waiting
0..
Person
43
Implementation 1
find all persons waiting at any bus stop on a bus
route
busStops
BusRoute
BusStopList
OO solution one method for each red class
buses
0..
BusStop
BusList
waiting
0..
passengers
Bus
PersonList
Person
0..
44
Implementation 2
find all persons waiting at any bus stop on a bus
route
villages
BusRoute
BusStopList
buses
VillageList
busStops
0..
0..
BusStop
BusList
Village
waiting
0..
passengers
Bus
PersonList
Person
0..
45
Filter out noise in class diagram

• only three out of seven classes
• are mentioned in static model

BusRoute BusStop Person
replaces the classes
BusRoute VillageList Village BusStopList
BusStop PersonList Person
46
Map static model to application class graph
villages
BusRoute
BusStopList
VillageList
busStops
0..
0..
BusStop
Village
busStops
BusRoute
BusStop
0..
edge -gt path
47
Using DJ

• class BusRoute
• Vector busStops()return
• Main.cg.gather(this,
• new Strategy(
• from BusRoute to BusStop)

48
Using DJ complete solution

• class BusRoute
• Vector waitingPersons()return
• Main.cg.gather(this,
• new Strategy(
• from BusRoute via BusStop to Person)

49
Notes

• Static model is translated into a strategy
• Why? With DJ behavior is written in such a way
  that it is usable in many different static models

50
Two approaches

• Catalysis
• Define static model and define behavior using
  static model
• Map static model to implementation model
• Behavior is in implementation model

• DJ
• Define strategies corresponding to static model
  and express behavior using strategies.
• Adjust strategies for implementation model.
• Behavior is in implementation model

51
Using DJ complete solutionJava problem
parameterization

• class BusRoute
• Vector waitingPersons()return
• Main.cg.gather(this,new Strategy(
• from BusRoute via BusStop to Person)

52
Using DJ complete solutionJava problem
parameterization

• class BusRoute
• PersonList waitingPersons()return
• Main.cg.traverse(this,new Strategy(
• from BusRoute via BusStop to Person,new
  PersonVisitor())