1 Catalysis Methodology Ali Khoshgozaran August 2002

2 Agenda r Definition r Highlights of Catalysis r Catalysis in Practice r Design Issues r Abstraction Layers in Development r Some Case Studies r Different Refinements r Conclusion

3 The Name r Catalysis An acceleration of the rate of a process or reaction, brought about by a catalyst, usually present in small managed quantities and unaffected at the end of the reaction. A catalyst permits reactions or processes to take place more effectively or under milder conditions than would otherwise be possible.

4 Component-based, architecture and reuse centric, business driven Layered architectures separating UI, application, business, data A more mature, repeatable, sustainable business and IT development process Typical Enterprise Evolution Path “As-Is” Inventory“To-Be” PlanningTransition ….. Very heterogeneous hardware and software platform mix Rampant duplication of effort, functions, code Very difficult to maintain and change Inconsistent and conflicting architectural styles Too many “magical” gaps between business need and code Tools Methods Architectures Education Maturity transition …

5 Traceabilitybridge Business and IT precise shared vocabulary critical business questions early Traceabilitybridge Business and IT precise shared vocabulary critical business questions early Architectureinterfacesplug standards Architectureinterfacesplug standards Talk Preview - Success With Components Reuse Processdevelop for reuse develop with reuse reuse interface,code Reuse Processdevelop for reuse develop with reuse reuse interface,code Pluggable Componentsprecise interface-centric design traceable business components Pluggable Componentsprecise interface-centric design traceable business components Business Drivenunderstand business first Business Drivenunderstand business first

6 A Multi-Pronged Approach Object and component modeling Data modeling Business modeling Configuration management Project management Strategic Consulting Education Systems Development Systems Integration Tools Methods & Processes Architecture & Reuse Services Catalysis CBD method Next-generation approach = Precise models and systematic process Roles, activities, … Process implementations Catalysis Core Business problem Software architecture Code Deployment Consistency via Architecture &Reuse Design patterns Interface and technology standards Code components

7 Highlights of Catalysis r Traceability r Precision r Components r Reuse r Scalability r Process

8 Traceability and Catalysis r Traceability from business models to code Same techniques and notations apply from business level to code Explicit refinement relationship: business, design, and code Improved configuration management, testing, maintainability Frameworks enable reuse of standard refinement patterns

9 Precision with Catalysis r Precision Uncover important problems early Create clear and concise documents and models Build explicit shared vocabulary  Enhance scalability to large systems, enhance traceability, testability

10 Component-Based Development with Catalysis r Component Based Development Strong support for interface-centered design Black-box descriptions of components that are clear and simple Leads to rapid assembly and flexible configuration from parts

11 Reuse with Catalysis r Strong emphasis and fundamental support for reuse Reuse not simply implementations, but interfaces, architectures, business models Eliminate duplication of work - each important design, spec, or architecture element defined once and only once Build up consistency via patterns and frameworks

12 Catalysis Process Requirements Domain Models System Context Understand problem, context, & non-functional req. System Specification Scenarios Operation Specs Describe external behavior of the system Architectural Design Platform, Phy. Architecture Log. Application Architecture Partition technical & application architecture components Component Internal Design Design interfaces for each component; build and test Interface and Class Specs Implementation and Test Dictionary Outside (+ project constraints) boundary inside UI Design DB Design

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

14 Catalysis in Practice System c1 ab m1 m2 c2 m3 m4 xyxy c system

15 Main Elements of Catalysis r Object: Representing a cluster of information and functionality r Action: Representing any-thing that happens : An event Task Job Message Change of state Interaction Activity

16 Actions and Postconditions Teacher Student Teach Action type = Use case Object type r action (student, teacher) :: teach (skill) r post -- this skill has been added to the student’s accomplishments (Skill here is an attribute )

17 Precision in Business Models Actor Business model -The actions (use-cases) that take place between objects (actors) in the business, with each action specified in terms of a supporting model of concepts (glossary) Sales Rep Credit Authorization System Customer pay by bank card purchase Purchase (customer, sales rep, item list) post: sales rep has new sale with totaled cost for items based on quantity and product price Pay by bank card (customer, sales rep, credit system, card) post: sales rep has authorized payment on customer card from credit system for the sale total, and recorded sale Use-Case / Action

18 Elements of an Action Teach action is a composition made up of the smaller ones Assembly

19 Actions at Different Scales Action Type Collaboratio n Diagram Object Type Teach Schedule the course Deliver the course Zoomed-in actions constituting teach. Run Course Arrange

20 An Occurrence of the Teach Action Object Instances Sequence Diagram Action Occurrences

21 Assigning Responsibilities to Objects r First state what happens r Then state which object is responsible for doing it r Which one is responsible for initiating it r Actions characterized by what they achieve r Then by how they achieve it

22 Associations The useful aspect of associations: r Don’t have to say exactly how they are realized r Statements about how actions affect them are still meaningful r These specifications are abstract and yet precise r They expose inconsistencies of natural language

23 Refining Associations Association Assembly r Use of stick figures instead to highlight roles r Several roles can be played by one object

24 More Detailed Description Zooming in and out is useful when seeking r What a business does r Why it does it

25 Business Modeling r The main objective is for the model to represent how the users think of the world with which they work r Starting questions are “What do you do?” and “Whom do you deal with?” r Every time you introduce a new object type, add to the list of questions “What actions affect that? What actions does it affect?”

26 Business Modeling (cont.) r Every time a verb is mentioned, draw an action and add to your list of questions “Who and what else participates in that? What is its effect on their state?” r The answers to these questions lead you to Draw object types Write post conditions r These in turn lead to associations and attributes

27 Traceability from Business to Code Zoom in/out of use-case (user task) (abstract action or detailed dialog) Zoom in/out of objects (external or internal view, including software) Client Company buy course Client Company schedule pay deliver pay Client Company schedule deliver Client Company schedule pay deliver SW System Fractal zooming without losing preciseness Refinement (mapping)

28 Rules = Actions + Static + Dynamic Invariants Captures important rules accurately without getting into implementation details Enable the User to raise and resolve critical issues early Static invariant Attribute constraint in all states “New session created, confirmed if qualified instructor available” Dynamic Invariant A state change rule that applies to all actions Admin Company schedule pay deliver Session date, topic cost Instructor qualified Students skills funds assigned “Assigned instructor is qualified for topic” “Any change in session must propagate to scheduler”

29 Design Issues

30 Directed Actions At some stage in a completed design all actions turn into a dialog, in which each action is a message with r A definite sender (with responsibility for initiating the action) r A receiver (with responsibility for achieving the required outcome) r And parameters (that do what the receiver asks of them) r These are called directed actions; when viewed strictly from the side of the receiver, they are called localized actions

31 Separation of concerns This skill is crucial, in Catalysis we provide the means to separate different layers of design decisions: r The behavior that is required (post conditions) r Assignment of responsibilities (roles and collaborations) r The way each object and action is implemented (successive refinement)

32 Catalysis Vs. Others r Abstraction technique in Catalysis: Treat a complex system as one object Treat complex interactions as one action Yet state the out-come precisely r This approach contrasts with more-traditional design techniques in which abstract also tends to mean fuzzy

33 Abstraction Layers in Development Two to five layers of abstraction in development : ( a bigger number for more complex projects ) r Business model (sometimes called domain or essential model): Describes the users’ world separately from any notion of the target software. r Requirements specification: Describes what is required of software (no reference to how it is implemented). It is mandatory for a major component or complete system. It may be approached differently when the complete system is created by rapidly plugging kit components together

34 Abstraction Layers in Development (cont.) r Component design: Describes (on a high level) how the major components collaborate, with references to a requirements specification for each one. Needed if there are distinct major components r Object design: Describes how a component or system works, down to programming language classes or some other level that can be coded (or turned into code by a generator) r Component kit architecture: Describes the common elements of the way a collection of components work together (e.g. standard interaction protocols).  Different developers build interoperable components

35 Static Models and Invariants r Business rules can be written as invariants: inv -- for every CourseRun, its instructor’s qualifications must include the course CourseRun :: instructor.qualifications -> includes (course) r The invariants are described informally and are written in a simple language of Boolean conditions & set relationships (Client, SeminarCo) :: arrange (Subject)

36 Snapshots r Draw Snapshots to help visualize the effects: Action postconditions: = 0 & instructor.qualifications -> includes (t) ] Newly created object links Association inherited from supertype

37 Actions and Postconditions action (c: Client, s: SeminarCompany) :: arrange (t: Course, d: Date) post -- a new CourseRun is created with date, client, course r : CourseRun.new [date=d, client=c, course=t] -- assigned instructor who was free on date d and qualified for the course

38 Another Example: ATM r A simple ATM user: type User walletAmount : Currency.. What the user has got in her pocket account : BankAccount.. Her bank account end type ATM cashAmount : Currency.. What remains in the machine end

39 Example : ATM (cont.) r The getMoney action describes an ATM transaction: action (u:User,a:ATM)::getMoney(amount:Currency) pre : u.account.balance > amount pre : a.cashAmount >= amount post : u.account.balance = u.account.balance - amount post : a.cashAmount = a.cashAmount - amount post : u.walletAmount = + amount end model

40 Object Oriented Design The process begins by turning many things in a model into classes: r Hence, Instructor, Course Run, and Course now become classes r Roles are assigned to the classes, as for components r The actions at this level are finally standard OO messages r The associations become pointers, decisions are made about their directionality r Design patterns are used to guide these decisions (as they can be used throughout the development process)

41 Object Oriented Design (cont.) The end result of OO design is a collection of : r Classes that encapsulate program variables and code r Types that define the behavior expected at the interfaces to classes. Classes implement types r Next, component implementation (the “Insides” process) commences

42 Refining Catalysis action types using UML How Catalysis action types can be modeled in UML? r The UML Action concept: an action is executed when a stimulus is (bound to this action) received  completely different from the one we need r The UML Collaboration concept: describes interactions among objects. Using Collaboration to model Catalysis seems possible r The UML Use Case concept bears similarities with the concept of Action in Catalysis. A Use Case connects several participants, is extensible, and therefore is a good candidate to represent refinements

43 UML Use Cases VS Catalysis Actions They are somewhat different for several reasons: r Use Cases: interactions between some central object and its environment, which includes actors. On the contrary, Catalysis actions give symmetric roles to its participants r Use Cases are modeling tools showing interactions between actors and the system. This is not as flexible and precise as a speciation tool as Catalysis' pre/post conditions on actions.

44 A simple usecase refinement Get Money Get Cash Request Money Provide Id >

45 Review r UML + simple consistent approach, process, techniques Traceability from business models to code Precision, with clear unambiguous models and documents Component Based Development Reuse of designs, specs, problem domain models, architectures,... Scalability from small to large teams and projects Process that is flexible yet repeatable Next Generation Solutions

46 References r r r sunye.pdf r