Catalysis

1. 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 = student.accomplishments@pre+ 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. 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 Commonalities Catalysis/AC Catalysis/Testing

11. 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 Differences Catalysis/AC 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. 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. 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. Testing/Specification • Write action specifications precisely enough • to form the basis for testing and • to make the model explicit enough to uncover business issues Catalysis/Testing

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

38. Actions • action (party1:Type1, party2:Type2,…) ::actionName(…) • not centered on a single object type • action effect is described in terms of of all participant Catalysis/Testing

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

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

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

42. find all persons waiting at any bus stop on a bus route Static Model busStops BusStop BusRoute 0..* DOES NOT REVEAL TOO MANY IMPLEMENTATION DETAILS waiting 0..* Person Catalysis/Testing

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

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

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

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

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

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

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

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