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

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

3. Catalysis/Testing 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. Catalysis/Testing 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. Catalysis/Testing 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. Catalysis/Testing 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. Catalysis/Testing Precise specifications action(student,teacher):: teach(skill) post student.accomplishments = student.accomplishments@pre+ skill

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

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

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

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

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

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

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

19. Catalysis/Testing 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. Catalysis/Testing 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. Catalysis/Testing 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. Catalysis/Testing Retrieval functions Long history: VDM, Z support traceability: how change in spec or code influences the other use retrieval diagrams

23. Catalysis/Testing 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. Catalysis/Testing 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. Catalysis/Testing Testing by adapting the implementation Specification (with test information) Implementation package –Adapter –Implementation

26. Catalysis/Testing Spreadsheet Cell Content value right Number Blank left Sum content shows 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. Catalysis/Testing Spreadsheet Cell Content value right Number Blank left Sum content shows Invariants: for all Sum objects s: s.value = s.left.content.value + s.right.content.value for all Blank objects b: b.value = 0 * Spreadsheet_1 Cell_I isBlank:boolean value Sum_Icontainer sumpart shows RETRIEVAL DIAGR. operands impl1 abs Sum s; s.left = s.impl1.operands[1].abs s.right=s.impl1.operands[2].abs s.value=s.impl1.container.value * *

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

29. Catalysis/Testing 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. A = s A BB C C D D E E F=t F G S S is participant graph for G

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

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

39. Catalysis/Testing 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. Catalysis/Testing 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. Catalysis/Testing Static model with behavior Course Scheduling ClientSession fullSchedule sessions* client * Instructor rating: Grade staff * instructor 0..1 sessions*grade: Grade date : 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 {ordered date} Static model behavior Behavior defined in terms of static model

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

43. Catalysis/Testing Implementation 1 BusRoute BusStopList BusStop BusList BusPersonList Person passengers buses busStops waiting 0..* find all persons waiting at any bus stop on a bus route OO solution: one method for each red class

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

45. Catalysis/Testing Filter out noise in class diagram only three out of seven classes are mentioned in static model BusRoute BusStop Person BusRoute VillageList Village BusStopList BusStop PersonList Person replaces the classes

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

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

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

49. Catalysis/Testing 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. Catalysis/Testing 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. Catalysis/Testing Using DJ: complete solution Java problem: parameterization class BusRoute { Vector waitingPersons(){return Main.cg.gather(this,new Strategy( “from BusRoute via BusStop to Person”);} }

52. Catalysis/Testing 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 PersonVisitor());} }

53. Catalysis/Testing Resource Allocation reqs when: TimeInterval 0..* type allocated provides0..* 0..1 inv Job::allocated<>0 ==> allocated.provides->includesAll(type.reqs) --Any allocated resource must have the required facilities inv Resource::jo1, jo2: Job:: (schedule->includesAll({jo1,jo2}) ==> jo1.when.noOverlap(jo2.when) -- no double-booking of resources schedule 0..*

54. Catalysis/Testing Resource Allocation JobDescription Skill reqs Job when: TimeInterval Plumber 0..* type allocated provides0..* 0..1 schedule 0..* Resource Allocation Facility Resource Job JobCategory Application of resource allocation to Pluming Customer

55. Catalysis/Testing Reuse and Pluggable design chapter 11 Reuse requires components that are –generic –customizable Reuse: most compelling reason for adopting component-based approaches

56. Catalysis/Testing Reuse Reuse without alteration? Is limited.

57. Catalysis/Testing What is an aspect? An aspect is a modular unit that cross-cuts other modular units. What means cross-cutting? Apply AOP to AOP. Tease an aspect apart into three units: ideal graph, labels on nodes and edges of ideal graph, application to concrete graph using connectors: specifies cross-cutting

58. Catalysis/Testing Example: ACs Ideal graph: participant graph Labels on nodes and edges: participant code Concrete graph: participant graph or application class graph Connectors specify cross-cutting

59. Catalysis/Testing Theory of cross cutting Model programs as graphs (e.g. class diagrams, abstract syntax trees, etc.) Aspects: model as graph editing instructions modeled with respect to an ideal graph. Graph editing: add new