1 / 49

Catalysis

Catalysis. Objects, components, and Frameworks with UML. From the book. Objects, components, and frameworks with UML: the Catalysis Approach, by Desmond D’Souza and Alan Wills. A tour. Objects and actions object: cluster of information + functionality action: anything that happens

mkroeker
Download Presentation

Catalysis

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  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 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 BusStop BusRoute 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. 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

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

More Related