1. Objects, components, and Frameworks with UML
Catalysis
Objects, components, and Frameworks with UML
Catalysis/Testing

2. From the book
Objects, components, and frameworks with UML: the Catalysis Approach, by Desmond D’Souza and Alan Wills.
Catalysis/Testing

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
Catalysis/Testing

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.
Catalysis/Testing

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?
Catalysis/Testing

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)
Catalysis/Testing

7. Precise specifications
action(student,teacher)::
teach(skill)
post student.accomplishments =
skill
Catalysis/Testing

8. Refinement
Of objects and actions
Zoom in and out
Catalysis/Testing

9. Connection to aspectual components
objects, components (actions), connectors
actions have a modification interface
Catalysis/Testing

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
Catalysis/Testing

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
Catalysis/Testing

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
Catalysis/Testing

13. Static models and invariants
An action’s postcondition can be written in terms of static relationships
Connection: participant graph of AC contains information to describe postconditions
Catalysis/Testing

14. Model Frameworks as Templates
Similar to AC, but no aspects
parameterized
Catalysis/Testing

15. Requirements Specification Models
Objects in this diagram are not real objects but rather the system’s own representation of them
Static model: is a hypothetical picture created for explaining the systems externally visible behavior to its users.
Catalysis/Testing

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.
Catalysis/Testing

17. Partitioning the model between components
Each of the components performs only some of the system’s functions and includes only part of its state
different vocabulary; need map
reconstruct all the attributes and associations from component design
Catalysis/Testing

18. Collaborations
Now: a collaboration is a collection of actions and the types of objects that participate in them
Sometimes they say: action = collaboration
Catalysis/Testing

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
Catalysis/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
Catalysis/Testing

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.
Catalysis/Testing

22. Retrieval functions Long history: VDM, Z
support traceability: how change in spec or code influences the other
use retrieval diagrams
Catalysis/Testing

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
Catalysis/Testing

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
Catalysis/Testing

25. Testing by adapting the implementation
Specification (with test information)
Implementation package
Adapter
Implementation
Catalysis/Testing

26. s.value = s.left.content.value + s.right.content.value
Spreadsheet
Content *
Cell
content
shows
value
right
left
Sum
Number
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
Catalysis/Testing

27. RETRIEVAL DIAGR. Sum s; s.left = s.impl1.operands[1].abs
Spreadsheet
Content *
Cell
content
shows
value
abs
Sum s;
s.left = s.impl1.operands[1].abs
s.right=s.impl1.operands[2].abs
s.value=s.impl1.container.value
right
left
Sum
Number
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
shows
container
Sum_I
isBlank:boolean
value *
operands
Catalysis/Testing

28. Retrieval functions with DJ
How to represent the participant graph?
Use strategy graph. Introduce a string for each edge. E1 = “{A->B bypassing X}”. class A {B getB(){return (B)
tg.fetch(this);} }
tg is the traversal graph for E1.
Catalysis/Testing

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.
Catalysis/Testing

30. S is participant graph for G
F=t 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
Catalysis/Testing

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
Catalysis/Testing

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
Catalysis/Testing

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
Catalysis/Testing

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
Catalysis/Testing

36. 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 component’s type)
Catalysis/Testing

37. 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.
Catalysis/Testing

38. Static model with behavior
Course Scheduling
staff
fullSchedule * *
Static
model
instructor 0..1
Client
Session
Instructor
sessions *
grade: Grade
date : Date *
sessions
rating: Grade
client
{ordered date}
Invariant (business rule): fullSchedule.grade <=fullSchedule.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
Catalysis/Testing

39. 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
Catalysis/Testing

40. 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..*
Catalysis/Testing

41. find all persons waiting at any bus stop on a bus route
Implementation 2
villages
BusRoute
BusStopList
buses
VillageList
busStops
0..*
0..*
BusStop
BusList
Village
waiting
0..*
passengers
Bus
PersonList
Person
0..*
Catalysis/Testing

42. Filter out noise in class diagram
only three out of seven classes
are mentioned in static model
BusRoute BusStop Person
explain why strategy better
replaces traversal methods for the classes
BusRoute VillageList Village BusStopList BusStop
PersonList Person
Catalysis/Testing

43. Map static model to application class graph
villages
BusRoute
BusStopList
VillageList
busStops
0..*
0..*
BusStop
Village
busStops
BusRoute
BusStop
0..*
edge -> path
Catalysis/Testing

44. Using DJ class BusRoute { Vector busStops(){return
Main.cg.gather(this,
new Strategy(
“from BusRoute to BusStop”);} }
Catalysis/Testing

45. Using DJ: complete solution
class BusRoute {
Vector waitingPersons(){return
Main.cg.gather(this,
new Strategy(
“from BusRoute via BusStop to Person”);} }
Catalysis/Testing

46. 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
Catalysis/Testing

47. 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
Catalysis/Testing

48. Using DJ: complete solution Java problem: parameterization
class BusRoute {
Vector waitingPersons(){return
Main.cg.gather(this,new Strategy(
“from BusRoute via BusStop to Person”);} }
Catalysis/Testing

49. Using DJ: complete solution Java problem: parameterization
class BusRoute {
PersonList waitingPersons(){return
Main.cg.traverse(this,new Strategy(
“from BusRoute via BusStop to Person”,new CollectionVisitor());} }
Catalysis/Testing