Component-Based Development With Catalysis

1. Component-Based DevelopmentWith Catalysis Daryl Winters Component Architects July 19, 2001

2. Why Components? • A practical way to organize and package systems • Develop, market, and maintain on a component basis • Support capabilities that are impractical for “small” objects • Interfaces through different programming languages • Components interact transparently across networks • More cost-effective to maintain since they do more than “small” objects, and less than “monolithic” programs • Each component could itself be a candidate “product” • Component partitioning enables parallel development

3. Outline • Method Overview • Types • Collaborations • Refinements • Frameworks • Process

4. UML partner, OMG standards, TI/MS standards Precise models and systematic process Dynamic Architectures From business to code Compose pre-built interfaces, models, specs, implementations... …all built for extensibility What is Catalysis™? • A next-generationstandards-aligned method • For open distributed object systems • from componentsandframeworks • that reflect and support an adaptive enterprise Catalysis has been in development and use since 1992. Authors: Desmond D’Souza and Alan Wills Text: Addison Wesley, “Objects, Components, and Frameworks with UML: The Catalysis Approach”. OMG Model Driven Architecture uses Catalysis.

5. Domain/Business Component Spec Internal Design Three Modeling Scopes or Levels Level/Scope Goal Identify Problem: “Outside” establish problem domain terminology understand business process, roles, collaborations build as-is and to-be models Specify Solution: “Boundary” scope and define component responsibilities define component/system interface specify desired component operations Implement the Spec: “Inside” define internal architecture define internal components and collaborations design each component’s internals

6. Framework Collaboration Refinement Type Desmond: Refinement is common to types and collaborations; frameworks are common to all three. Re-draw the figure to show this Three Modeling Constructs Purpose Model Construct specifies behavior of a group of objects specifies external behavior of an object relate different levels of description of behavior map or trace from refinement to abstraction recurring patterns of collaborations, types, designs, etc. define generically, “plug-in” to specialize

7. Three Principles Intent Principle focus on essential aspects, deferring others uncluttered description of requirements and architecture Abstraction expose gaps and inconsistencies early make abstract models accurate, not fuzzy Precision Pluggable Parts all work done by adapting and composing parts models, architectures, and designs are assets

8. Outline • Method Overview • Type Models • Collaboration Models • Refinement Models • Framework Models • Process

9. There are many definitions of component A user-interface widget that can be assembled on an interface builder An executable module with a specified interface A large-grained object with encapsulated persistent state and an interface All have the goal of software assembly An independently deliverable unit that encapsulates services behind a published interface and that can be composed with other components Components

10. To build systems by “plugging” together components Two choices: “plug-n-pray”, or use better specifications that are: abstract: apply to any implementation precise: accurately cover all necessary expectations is one implementation of... ? certify and publish will work with... “Type” spec what is expected of any “plug-in” Components Depend On Interfaces

11. Thingami frob (Thing, int) Thing fritz(int) Editor spellCheck() layout() addElement(…) delElement(…) NuclearReactorCore add (ControlRod, int) ControlRod remove(int) Component Interfaces • Signatures are not enough to define widely-used components

12. Type described by list of operations All operations specified in terms of a type model The Type Model defines specification terms type-model = vocabulary Editor <<type>> contents * Element preferredSize position * dictionary Word Composite * spellCheck() layout() addElement(…) delELement(…) every word in contents is correct by the dictionary every element has been positioned so that its preferred size can be accommodated Model-Based Type Specification

13. Operation specification can formalized OCL (Object Constraint Language) used as needed Checked, used for refinements, testing, change propagation, … Enables checkable/testable design-by-contract Editor:: spellCheck () post -- every word in contents contents->forAll (w: Word | -- has a matching entry in the dictionary dictionary->exist (dw: Word | dw.matches(w))) Formal Operation Specifications

14. Component XYZ type SPECIFICATION interface (Type) operation IMPLEMENTATION EXECUTABLE (Class) Component Models • Every component description has at least 2 parts: • The specification of the interfaces via types. • The implementation (designed classes, modules).

15. ListBox count: int itemAt (int): Item selected (Item): boolean movedUp(i,j): boolean addItem (Item, int) Item delItem (int) Behaviors Specified Using Models Behavior “contract” you can rely on post-conditions provided pre-conditions are met interface ListBox {model { .... }void addItem (Item item, int pos) pre 0 < pos and pos <= count+1 // provided position is in range post item = itemAt(pos) and selected(item) // inserted and selected and count = count@pre + 1 // count increased from before and movedUp (pos,count@pre) // items moved up addItem (Item item, int pos) pre (0 < pos <= count+1) post item = itemAt(pos) and count = count@pre+1 andmovedUp(pos,count@pre) and selected(item) aux. query prior value

16. awt.ListBox <<type>> count: int itemAt (int): Item selected (Item): boolean movedUp(i,j): boolean addItem (Item, int) Item delItem (int) class ListBoxA items: List selection: Set(Item) addItem (Item, int) Item delItem (int) addItem (Item item, int pos) { items.insertAt(item,pos); selection.add(item); } retrieval: boolean selected(i) { return (selection.has(i));} int count() { return (items.length()); } …. Item itemAt(pos) { return items[pos]; } Valid Implementations of a Type • Any valid implementation class • Selects data members • Implements member functions • Can implement (retrieve) the model queries • Guarantees specified behavior <<implements>>

17. A class implements an interface The interface defines its own model and behavior specification The class selects its own data and code implementation The class is a refinement of the type I.e. conforms to it It claims to meet the behavior guarantees of the type for any client A retrieval (informal or formal) can support the claim Implemented abstract queries (formal) can be used for testing Conformance and Retrieval Interface retrieval Implementation maps from refinement to abstraction

18. Conformance/Refinement • The notion of conformance and retrieval is very useful • It permits flexible mapping between from refinement to abstraction • It solves a very real problem: • “I have just made some change to my code. Do I have to update my design models? Do I have to update my analysis models?” • Pick abstract model to conveniently express client spec • Implementation model must have correct mapping to the abstract • Encapsulates implementation without hiding specified behavior • Even more powerful with temporal refinement • The abstract level describes an abstract action • The concrete level details an interaction sequence • The retrieval establishes the mapping between the two

19. Outline • Method Overview • Type Models • Collaboration Models • Refinement Models • Framework Models • Process

20. Editor maximum size resize children Editor E-Core next word replace word spellCheck() layout() addElement(…) delELement(…) Layout Manager Spell Checker spellCheck() layout() Component-Based Design • Large component is a type for its external clients • Implement it as collaboration of other components • Specify these other components as types • The child component models must map to the original model dictionary words

21. seq * Word next Word replace Word SpellChecker Acme Spell Bee E-Core DB Record Type-Based Components • Any component that provides the correct interface (operations and apparent type model) can plug-into another component Spell Checkable

22. Large-Grain Business Components • “Executable” component = large-grained object • Components configurations tend to be more static • One component may be built from several classes • Underlying objects implement several types e.g. Customer Customer Membership Manager Shipper addMember (info) findMember (name) memberStatus (mem#) ship (shipment, receiver) shippingStatus (order) Money Order Taker Order takeOrder (product, buyer) checkCredit (card#) orderStatus (order#) Credit-Card

23. Shipper ship (shipment, receiver) Order Taker order (item, buyer) plug in plug in customer product product shipment customer (service) (supply return) (vendor) receiver buyer “Frameworks” as Components • A large-grain component designed with “plug-points” • Application will “plug” domain objects into plug-points • “Plug-in” based on interface, sub-class, delegation, etc. Customer

24. Outline • Method Overview • Type Models • Collaboration Models • Refinement Models • Framework Models • Process

25. ListBox <<type>> count: int itemAt (int): Item selected (Item): boolean movedUp(i,j): boolean addItem (Item, int) Item delItem (int) class ListBoxA items: List selection: Set(Item) addItem (Item, int) Item delItem (int) addItem (Item item, int pos) { items.insertAt(item,pos); selection.add(item); } retrieval: boolean selected(i) { return (selection.has(i));} int count() { return (items.length()); } …. Item itemAt(pos) { return items[pos]; } Class Vs. Type -- A Basic Refinement • Any valid implementation class • Selects data members • Implements member functions • Can implement (retrieve) the model queries • Guarantees specified behavior <<implements>>

26. Editor-1-Step delete (Shape) Editor-2-Step select (Shape) deleteSelection() Subtypes and Refinements • Sub-types refine (and retain) guarantees made by super-types • The concrete implements, and can retrieve to, the abstract • Any sub-type implementation meets all super-type behavior guarantees • Clients remain blissfully unaware of any change • Here is a common refinement: is it a sub-type? refine the protocol

27. Shape Editor-1-Step delete (Shape) * unselected 0,1 * Editor-2-Step select (Shape) deleteSelection() Shape 0,1 0,1 selected Refined Models and “Retrieval” contents • Finer grained interactions induce a finer grained model • Retrieve: Define abstract query in terms of refined model • Define refined sequences that achieve each abstract action • Still, this is not a sub-type contents1-step= unselected2-step + selected2-step select2-step (s) + deleteSelection2-step () => delete1-step(s)

28. Editor-1-Step delete (Shape) Editor-2-Step select (Shape) deleteSelection() Varieties of Refinements • Many common refinements do not create sub-types • Time granularity, signature, helper objects, ... Editor-with-Mouse click (Point) deleteKey()

29. Joint Refinement of Collaborations Collab-A • We refined the joint interaction protocol • Both sides are affected by the refinement Editor-1-Step deleteA joint-model, invariants, action specs selectB deleteSelectionB Collab-B retrieval: statechart maps action sequences also map attributes Editor-2-Step joint-model, invariants, action specs

30. Collaboration collaboration action (joint or localized) Collab-A Editor-1-Step b a external invariants, action specs external action specs, constraints typed role model Collaboration: A set of actions between typed objects playing certain roles, specified in terms of a common model. The actions themselves may be joint (not assigned to a particular type) or localized (responsibility assigned to a particular type), and may be external (not between collaborators, must maintain invariants) or internal (between collaborators, does not have to maintain invariants).

31. Scenario and Sequence Diagram • A scenario is a trace through a collaboration • Action pre/post attribute values are “snapshots” • Snapshots conform/define type model • Snapshot-pairs conform/define action specs • Scenarios conform/define collaboration specs sequence diagram Narrative 1. user does …. 2. system does … 3. database does …

32. Observer isProjection(Subject): boolean update() spec post isProjection(sub); Subject-Observer Collaboration abstract query Observation Subject s: State inv changed(s)=> forall obs, obs.update(self) register() unregister() obs * sub inv forall s: Subject, obs in s.observers => obs.isProjection(s) externally: subject-observer are always synchronized

33. TextWindow display showText SwitchDisplay isRed: boolean setColor TextBuffer contents: Text queryText() PowerSwitch isOn: boolean queryState() “Specializing” Subject-Observer • Do not confuse this with subtype or subclass • The entire family of related types (playing roles) is being specialized • Will be addressed by “frameworks” Observation h h TextDisplay Power-Switch-Display isProjection == is text the same? isProjection == sw.isOn <=> disp.isRed

34. From Use-cases to Code (and Back) System-Context • Collaborations and refinement provide full traceability • Use-cases at the level of system and user-tasks • Refinement of interaction granularity, external and internal roles • Clear semantics for use-case development, business to code System Refinement-number-N System

35. Outline • Method Overview • Type Models • Collaboration Models • Refinement Models • Framework Models • Process

36. allocate resources to jobs if ... generalize session lot room time plug in Frameworks - Generic Components • A generic model / design / implementation component that • Defines the broad generic structure and behavior • Provides plug-points for adaptation allocate room to seminar session if... allocate machine time to production lots if ...

37. ResourceAllocation meets * * <Capability> <Requirement> capability * * * 0,1 <Job> when: DateRange schedule allocated Desmond: change this example!! Resource Allocation Framework requirement <Resource> invariants Job:://only allocate resource whose capability matches requirements allocated <> nil implies allocated.capability.meets #includes (self.requirement) Resource:://do not double-book any resource i.e. at most 1 job per date Date.forAll (d | self.schedule #select (j | j.when.includes(d)) #size <=1)

38. Course-Scheduling RoomFacility Topic InstructorSkill * skills Certification SeminarSession when: DateRange * certs Room Instructor inv capability = certs.skills “Applying” a Modeling Framework • “Apply” resource-allocation twice to course scheduling • Each application substitutes different resource, capability, etc. • Both apply to the same job: Seminar Session ResourceAlloc ResourceAlloc

39. Course-Scheduling InstructorSkill RoomFacility Topic * <meets instr Rqmts * * skills * meets Room Rqmts> * * * capability facility Certification * certs * * * * <schedule SeminarSession when: DateRange Instructor schedule> * Room instructor> 0,1 0,1 <room inv capability = certs.skills SeminarSession:://only allocate suitable instructors and rooms instructor <> nil implies instructor.capability.meets instr Rqmts (topic) room <> nil implies room.facility.meets Room Rqmts (topic) Room:://do not double-book any rooms i.e. at most 1 session per date Date.forAll (d | self.schedule #select (j | j.when.includes(d)) #size <=1) Instructor:://do not double-book any instructor i.e. at most 1 session per date Date.forAll (d | self.schedule #select (j | j.when.includes(d)) #size <=1) The “Model” is Generated

40. <Observer> isProjection(Subject): boolean update() post: isProjection(sub) Design Patterns as Frameworks Subject-Observer obs <Subject> s: State inv changed(s)=> obs->forAll (o | obs.update(self)) register(Observer) unregister(Observer) sub * externally: subject and observers always appear to be in sync inv Subject->forAll (s | s.obs->forAll (isProjection(s))

41. SubjectObserver PowerSwitch isOn: boolean turnOn turnOff SwitchDisplay isRed: boolean update Applying Design Patterns • The instantiation defines mappings of types, queries, actions • Needed to generate the instantiation, and for the “retrieval” Power-Switch-Display subject [s = isOn] observer [isProjection(s) = s.isOn <=> isRed]

42. Business Models Barter Trader Authorizer Domain Models Resource Allocation Account Settlement User-Interface Patterns Fundamentals Total Ordering Groups Range Descriptors Design Patterns Subject-Observer 2-Way Link Cache Moving Window Data Normalization Example Frameworks at All Levels • Constructive approach to modeling and design with full traceability • Libraries and commerce of frameworks of models, designs, and code

43. Outline • Method Overview • Type Models • Collaboration Models • Refinement Models • Framework Models • Process

44. Requirements Domain Models Understand the business problem, system context and requirements. System Context DB Design UI Design System Specification Scenarios class mapping, transactions, etc. dialog flow, prototype, usability Describe external behavior of target system using problem domain model Type Model and Op Specs Dictionary Architectural Design Platform, Physical Architecture Partition technical and application architecture components and their connectors to meet design goals Logical Application Architecture Component Internal Design Interface and Class Specs Design interfaces and classes for each component; build and test Implementation and Test Catalysis Development Process UML = Unified Modeling Language, standard notation for OO design

45. SQL Java Global Groceries Focus on the Problem Domain External models should reflect the customer’s view of the problem domain, not the programmer’s view. X A problem domain focus helps to ensure continuity between the software and the real world. • Continuity makes it easier to • verify model with customer • train new developers • estimate maintenance effort • identify sources of defects

46. Global Groceries Informal Domain Model Concept Map - An informal structured representation of a problem domain Not a stored data model!! shelf Clusters - Domain terms representing potential attributes. product price discount percent purchases customer records sale Sales System bank card conducts Arcs (optionally directed and labeled) - Representations of potential associations or collaborations between objects. Nodes - Domain terms representing potential objects, types, or actors. Can include “rich-pictures” as drawings of the problem domain sales rep Can be formalized if appropriate

47. System Context -- a Collaboration System Context Model - A structured representation of the collaborations that take place between a system and objects in its surrounding environment (context). Actor - A person, existing system, device, etc. that interacts directly with the target system. Specialization - Indicates that a specialized actor can also play the role of a more general actor. Customer Credit Authorization System pay by bank card Sales Rep start sale add item remove item close sale cancel sale Sales System Target System - The system or component under construction. Use-Case / Action - An interaction between the system and an actor to accomplish a useful unit of work. add authorized sales rep remove authorized sales rep Head sales rep

48. creditAuthorization System salesSystem Actors identified from System Context. startSale() addItem(watzit, 3) total := closeSale() pay(bankCard, pin) authorized := authorizePayment(bankCard, pin, total) Interactions from system-context actions Scenario of Use Context: A customer approaches a sales rep with the intention of purchasing three watzits using her bank card. There are sufficient funds in her account to payfor the purchase. The sales rep has completed his last sale so there is currentlyno sale in progress. Narrative: sales rep customer The sales rep starts a new sale. The total for the sale is $0.00. The sales rep adds the three watzits to the current sale. The sales rep closes the sale. The sales system returns the total due. The customer inserts her bank card into the reader and enters her pin number The Sales System requests payment authorization from the credit authorization system. The system authorizes payment.

49. System of Interest currSale Product inventory * Sale Cust Model of object types for terms used to specify system operations Not a stored data model Object type and abstract attribute * * SaleItem quantity Payment Authorization Interface Operations of System Operation Spec 1 Operation Spec 2 Type Model and Operation Specs Sales System <<type>> startSale () addItem (Product, quantity) closeSale () pay (bankCard, Pin) Note: Does not as yet commit to operations on individual classes inside system Internal component partitioning and class design not decided yet.

50. Mind Map product customer bank card sale Domain Models Reqs System Context System Context System system c Scenario of Interaction Scenarios Spec system Type Model and Op Specs Type Model and Op Specs op1 op2 Platform Physical Architecture Arch a b Logical Application Architecture c Architectural Collaborations, Interfaces, Scenarios Interface and Class Specs Int Des c1 a b c c2 Class and Interface Model, Scenarios a b x y Implementation and Test m1 m2 m3 m4 A Recursive Process: Domain to Code