Java Beans Specification Design and Test using Catalysis

Java. Beans Specification, Design, and Test (using Catalysis) Aamod Sane Platinum Technology www. platinum. com 1

About the Speaker Dr. Aamod Sane is principal architect at Platinum Technology. He is involved in developing the Catalysis method , component specification and implementation techniques, including tool support. He has worked with software technology since 1987 and developed object systems since 1989. He has published on design patterns, frameworks, and components at conferences like OOPSLA, ECOOP, and PLOP. Aamod has worked on operating systems, distributed systems, orbs, designpattern tools, and case tools. He is experienced in software architectures, modeling, analysis, and specification and programming. Aamod’s home page is http: //choices. cs. uiuc. edu/sane/home. html © 1998 ICON Computing www. iconcomp. com 2

Outline r From objects to components r Java interface versus class r Components with Java Beans r Specifying Java Beans r Components and connectors r Testing against specifications r Reuse © 1998 ICON Computing www. iconcomp. com 3

What is a Component? r A coherent package of software that can be independently developed and delivered as a unit, and that defines interfaces by which it can be composed with other components to provide and use services. • A component package can include: – Executable, source, design, specification, models, test • Must be self-contained to be independently delivered – A component implements provided interfaces in terms of required interfaces – The implementation must be in terms of interfaces expected from others © 1998 ICON Computing www. iconcomp. com 4

Components and Interfaces IDisplay IData. Source Spreadsheet Display Calc Data source Many implementations of used interfaces Must contain (or reference) interfaces provided and used • Packages must clearly separate interfaces from implementations • Interfaces must be organized to capture interface dependencies © 1998 ICON Computing www. iconcomp. com 5

Component Essentials 1. Components interact 2. Components compose and grow Warehouse 3. Components may be distributed Supplier That’s what’s interesting about them © 1998 ICON Computing www. iconcomp. com 6

How do Components Interact? Components interact via clearly specified interfaces IPickup Interface Warehouse IDelivery How is data stored? Is the data stored here? …or actually stored here? What other interfaces are provided or used? Supplier Focus on behavior; stored data, implemented procedures, other interfaces remain completely hidden © 1998 ICON Computing www. iconcomp. com 7

Describing a Component Services Provided: Interface Spec Services Required: Interface Spec Not standard OO!! Warehouse IDelivery Supplier Events Raised: Notifications of state changes Logical model of component state: Type Model Interface operations and events specified based on this Result: Precise model of information exchanged, assumptions, guarantees © 1998 ICON Computing www. iconcomp. com 8

Component “connectors” slider Button start position pressed <<event>> start <<event>> stop <<physical>> value toggled Switch <<prop>> Thermometer in Threshold out <<prop>> reactor in Differentiator gradient <<prop>> limit out in 1 in 2 OR out in Alarm in Threshold Other forms of higher-level “connectors” <<replicate>> <<workflow>> © 1998 ICON Computing www. iconcomp. com [OCF 10. 8] 9

Components must share Architectural Standards r Standard “horizontal” infrastructure services synchronous? event? work-flow? – request broker, interface and server repository, transaction, security, … – OMG, Microsoft rapidly defining many global “standards” r Standard “vertical” models of domain concepts • What is a “Customer”, “Phone Call”, “Order”, etc. – components must talk the same “domain language” • OMG defines “Vertical” architectures standards as well r infrastructure services Standard “connector” mechanisms between components • Synchronous request, asynchronous message, event, workflow, replicate • Location transparency: RMI, CORBA, DCOM • Mobility of code vs. data, mobile objects: Java, Active. X, Tele. Script What is customer, phone call…? © 1998 ICON Computing www. iconcomp. com 10

Are Components and Objects Different? r Most components can be described as objects • both emphasize encapsulation, interfaces, polymorphic late-bound connections • most new components will be built from traditional objects inside r So, what did traditional object-oriented development do wrong? • • • undue emphasis on class and implementation inheritance rather than interfaces just one basic form of “connectors” -- explicit message invocations unfortunate language-imposed dependencies on class source code --. h files boundaries such as host, programming language visible to components infrastructure services ignored -- persistence, transactions, security, discovery… component can be larger than a traditional single “object” or “class” class host/language obj-1 obj-2 host/language obj-3 obj-4 infrastructure services © 1998 ICON Computing www. iconcomp. com 11

Component Granularity and Binding Time r Granularity spans the spectrum • UI widgets: combo-box, tree • “Application” and component-document elements: spreadsheet • Large-grain components: scheduler, inventory manager r Good components are often not “business objects”!! • Naïve OOA/D will not lead automatically to component design r Running component can usually be modeled as an object • But it need not correspond to a single OOPL object! – Services may be exposed by separate constituents r Range of binding times • Design-time • Run-time © 1998 ICON Computing www. iconcomp. com 12

Components + Objects: Best of Both • Plug together components and objects at any level and any binding time Larger-grain, more static, polymorphic “components” Finer-grain, dynamic, polymorphic “objects” © 1998 ICON Computing www. iconcomp. com 13

Outline r From objects to components r Java interface versus class r Components with Java Beans r Specifying Java Beans r Components and connectors r Testing against specifications r Reuse © 1998 ICON Computing www. iconcomp. com 14

Type of an Object: Multiple (Inter)Faces “Plug” into new service What Type? Airline • • Passenger check Baggage board deplane What Type? Guest guarantee check In order room Service pay at check Out Hotel Object or component plays different roles It offers multiple interfaces, and is seen as different types Benefits to the airline, hotel: less coupling, more “pluggability” Benefits to person: easier to adapt to “plug” into a bigger system © 1998 ICON Computing www. iconcomp. com

Types: Java, COM, Corba, . . . interface Guest { guarantee. Check. In (); order. Room. Service(); pay. Check. Out (); } interface Passenger { check. Baggage (); board (); deplane (); } Airline Passenger Hotel object: Both class Both implements Guest, Passenger { Full type/class separation possible!! © 1998 ICON Computing www. iconcomp. com Guest // implementation …. }

Interface vs. Class: Which does a Client Use? Which of the Tx types here have to be classes, and which can be interfaces? class C 1 implements T extends T 0 { private T 1 contents; public T 2 foo (T 3 b) { super (); this (); contents = b; T 2 d; d = new T 5 (); return d; } } © 1998 ICON Computing www. iconcomp. com Client never needs to mention “class - except to instantiate - can use “factory” patterns here 17

Outline r From objects to components r Java interface versus class r Components with Java Beans r Specifying Java Beans r Components and connectors r Testing against specifications r Reuse © 1998 ICON Computing www. iconcomp. com 18

Java Beans r A “Component” standard for Java A reusable software component that can be manipulated in a visual builder tool r Describes component by properties, methods, events • Property: an observable state variable • Method: an invocable service • Event: a notification of state change r Builds on underlying technology of reflection, persistence © 1998 ICON Computing www. iconcomp. com 19

“Wiring” beans together m (p, q) properties p 1 p 2 E (x) method p 3 event r Events can be “wired” to methods • Match event parameters and properties (state variables) to method inputs r Properties can be “wired” to other properties • Implicit, rather than explicit update protocols • Not currently supported by Java. Beans products © 1998 ICON Computing www. iconcomp. com 20

Reflection r JDK 1. 1 introduced the reflection API r Run-time representation of class, interface, method, … r Run-time operations on these objects r Enables very-late binding of calls r Determines properties, methods, events from signatures • Can be supplanted by an explicit Bean. Info class © 1998 ICON Computing www. iconcomp. com 21

JDK 1. 1 Reflection r Reflect on Java definitions at run-time by accessing: • Class: static Class for. Name(String) get. Superclass, get. Interfaces, get. Fields, get. Methods, get. Constructors, … new. Instance, . . . • Field: get. Declaring. Class, get. Name, get. Modifiers, get. Type, get. Boolean, get. Int, … set. Boolean, set. Int. . . • Method: get. Declaring. Class, get. Name, get. Return. Type, get. Parameter. Types, get. Exception. Types, invoke. . . • Constructor: … new. Instance r Uses wrappers for primitives, arrays © 1998 ICON Computing www. iconcomp. com 22

Reflection Example // locate and load the class dynamically Class c = Class. for. Name (“User. Defined. Class”); // instantiate the class Object o = c. new. Instance (); // get one of the methods on that class Method m = c. get. Declared. Method (“user. Method”, { } ); // invoke that method on the new instance m. invoke (o); © 1998 ICON Computing www. iconcomp. com 23

Beans Properties via Naming + Reflection r r Properties derived by reflection using name conventions Simple properties: “Stock. Symbol” of type String get. Stock. Symbol(); void set. Stock. Symbol(String new. Symbol); r “Multi-valued” properties: “Symbol” of type String [] public String get. Symbol(int index); // throws bounds error public void set. Symbol(int index, String new. Value); // throws … r r Other property types: bound, constrained Example: class My. Bean { String get. Stock. Symbol() {…} void set. Stock. Symbol (String) {…} } © 1998 ICON Computing www. iconcomp. com 24

Event Design Patterns in Java. Beans r Group events into event channels by Listener interfaces interface Balance. Listener extends java. util. Event. Listener { void overdrawn (Balance. Event); void balance. OK (Balance. Event); } r Bean may offer different event channels Usage event channel r Account Bean Balance event channel Balance Listener Standard protocol pattern for registering event listener: void add. Balance. Listener (Balance. Listener f); void remove. Balance. Listener (Balance. Listener f); © 1998 ICON Computing www. iconcomp. com 25

Beans persistence via Serialization r r Save and restore graphs of Bean objects to/from streams All JDK 1. 1 classes can be serialized implement java. io. Serializable r Default behavior/formats easily extended or overridden public class My. Bean implements java. io. Serializable { Some. Other. Bean delegate; transient Object another. Field; } r Save and restore automatically available Object. Output. Stream ost = new Object. Output. Stream(a); out. write. Object(new My. Bean()); Object. Input. Stream ist = new Object. Input. Stream(b); My. Bean x = (My. Bean)ist. read. Object(); © 1998 ICON Computing www. iconcomp. com 26

Java. Bean versus Java Object r The interfaces of a Java. Bean may be provided by a group of collaborating objects of different classes • This will become increasingly common with complex beans r They conceptually work as a single object r Danger: Java language primitives will not know this! a b d c • Don’t use a language “cast” to get another interface • Don’t use the language == operator to check for identity • Beans Glasgow specs provide some interim recommendations © 1998 ICON Computing www. iconcomp. com 27

JAR files r A Java. Bean is packaged into a JAR file • Set of class files that implement its behaviors • Serialized instance to use for initialization • Help files • Resource files: images, sound, video, … • Manifest file: describes the JAR file contents and dependencies r When modeling, use package structure effectively © 1998 ICON Computing www. iconcomp. com 28

Enterprise Java Beans r A standard for simplifying server components by implementing most “middle-tier” services • • Distributed transactions Thread and database connection pooling Concurrent access Authentication © 1998 ICON Computing www. iconcomp. com 29

Outline r From objects to components r Java interface versus class r Components with Java Beans r Specifying Java Beans • • • Type models Methods Exceptions Properties Events r Components and connectors r Testing against specifications r Reuse © 1998 ICON Computing www. iconcomp. com 30

The “Black-Box” Component Thingami Editor frob (Thing, int) Thing fritz(int) spell. Check() layout() add. Element(…) del. Element(…) r Nuclear. Reactor. Core add (Control. Rod, int) Control. Rod remove(int) Signatures are not enough to define widely-used components © 1998 ICON Computing www. iconcomp. com 31

Components need Precise Interfaces r To build systems by “plugging” together components is one implementation of. . . “Type” spec what is expected of any “plug-in” ? will work with. . . certify and publish • Two choices: “plug-n-pray”, or use better specifications that are: – abstract: apply to any implementation – precise: accurately cover all necessary expectations © 1998 ICON Computing www. iconcomp. com 32

Model-Based Type Specification - Example Editor Type Specification Editor contents «type» * Element preferred. Size * position dictionary * Word type-model = vocabulary type specification usually in separate package operations specified in terms of the type model “vocabulary” Composite spell. Check() layout() add. Element(…) del. ELement(…) © 1998 ICON Computing www. iconcomp. com every word in contents is correct by the dictionary every element is positioned so that its preferred size can be accommodated [OCF 3. 4] 33

Formalizing Operation Specs Editor: : spell. Check () post // every word in contents -> for. All (w: Word | // has a matching entry in the dictionary -> exists (dw: Word | dw. matches(w))) r Operation specification can formalized • OCL (Object Constraint Language) used after rectifying some shortcomings • Checked, used for refinements, testing, change propagation, … r Enables checkable/testable design-by-contract © 1998 ICON Computing www. iconcomp. com 35

Component-Based Design internal design in a separate package from the specification Editor Internal Design next word replace word Editor spell. Check() layout() add. Element(…) del. ELement(…) E-Core Layout Manager Spell Checker dictionary maximum size resize children spell. Check() layout() words • • 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 © 1998 ICON Computing www. iconcomp. com 36

Each Component implements many Types SC Spell-Checker Spell. Checkable seq * Editor. Core LM Layoutable Word Elem size next word replace word descendants * maximum Size resize children curr Layout Manager • Components offer different interfaces to each other • Each interface has a different supporting model • The implementation refines each interface spec © 1998 ICON Computing www. iconcomp. com 37

Type-Based Components are “Pluggable” Spell. Checker Spell Checkable seq * Word next Word replace Word Acme r Spell Bee Editor. Core DB Record Any component that provides the correct interface (operations and apparent type model) can plug-into another component © 1998 ICON Computing www. iconcomp. com 38

Component Implementation class Editor. Core. Class implements Spell. Checkable, Layoutable { // store a tree of all elements — graphics, words, characters, tables, etc. private Element. Tree contents; // this iterator traverses all elements in the contents tree in depth-first order private Depth. First. Iterator element. Iterator = contents. root(); // this iterator only visits Word elements, ignoring others private Word. Iterator spell. Position = new Word. Filter (element. Iterator); // return the “next” word in the tree public Word next. Word () { Word w = spell. Position. word(); spell. Position. next(); return w; } // replace the last visited word with the replacement public void replace. Word (Word replacement) { spell. Postion. replace. Before (replacement); } } © 1998 ICON Computing www. iconcomp. com 39

Class refines Interface Spell Checkable words seq * Word next Word replace Word “abstraction function” or “retrieval” words = contents. as. Depth. First. Sequence -> select (e | e. is. Kind. Of (Word)) refinement Editor. Core <<class>> r Abstraction function “retrieves” abstract model attributes © 1998 ICON Computing www. iconcomp. com 40

Business Components: Modeling Issues • To assemble variety of configurations from a kit of reusable parts – demands abstract parts, abstract connections, multiple views and “plug” precision 1. Higher-level parts … abstract the objects 2. Higher-level late-bound connectors and properties … abstract the protocol, defer binding Order Taker <<event>> Shipper Receiver * Shipment ship (shipment, receiver) shipping. Status (order) ordered Buyer * Order take. Order (info) order. Status (. . . ) cancel (. . . ) <<output>> ordered 4. Precise interfaces for 3 rd assembly 3. Separate views for flexible use (can ship to any receiver) - must integrate in conceptual models - must integrate data in implementation Integrated business model - shared objects with multiple interfaces Customer - federated data + cross-component links © 1998 ICON Computing www. iconcomp. com 42

Business Components: Tiered Architecture Shipper Order Taker Can zoom in to show architectural tiers, or zoom out to model abstract business components Can package application components as: Business area Presentation “local” connector Local Application - vertical slice “distributed” connector - interfaces connecting Business Logic Component packaging + reuse at all levels UI parts “distributed” connector Domain Objects + UI Panels Data Access Business Logic Logging, events, . . . © 1998 ICON Computing www. iconcomp. com Business Data Shipper Order Taker 43

Outline r From objects to components r Java interface versus class r Components with Java Beans r Specifying Java Beans • • • Type models Methods Exceptions Properties Events r Components and connectors r Testing against specifications r Reuse © 1998 ICON Computing www. iconcomp. com 44

Exception versus Undefined Behavior r Guaranteed exceptions are different from undefined failures Invoker needs clear indication of exception versus success Exceptions should not be overspecified: e 1 versus e 2 – [OCF 8. 4] © 1998 ICON Computing www. iconcomp. com 45

Specifying Exceptions r Define normal and exception indicators Editor: : spell. Check () exception = throws (Object) normal = not throws (Object) r // throw <=> exception // if normal, nothing thrown Write separate post defining different exceptions Editor: : spell. Check () post (dictionary@pre = null) or (read_only) implies exception // a definite exception if no dictionary or read_only post throws (Dictionary. Error) implies (dictionary@pre = null) post exception implies contents unchanged // contents definitely unchanged on any exception © 1998 ICON Computing www. iconcomp. com 46

Outline r From objects to components r Java interface versus class r Components with Java Beans r Specifying Java Beans • • • Type models Methods Exceptions Properties Events r Components and connectors r Testing against specifications r Reuse © 1998 ICON Computing www. iconcomp. com 47

Type model attribute vs. query method r A type-model attribute does not imply a get/set method • Attributes are just a model of state • Not necessarily externally accessible r Model only public The only publicly accessible things are methods • So we must have read-only methods for any public query – which is a recurring pattern for any “exposed” attributes r Shortcut for “property” attributes with Catalysis frameworks © 1998 ICON Computing www. iconcomp. com 48

Intent r We don’t want to model with explicit get/set • Loses the main intent r Define a modeling pattern where: • <<property>> can be annotated on any attribute • <<property>> is defined as a framework • get/set is implied (expanded form) of that annotation © 1998 ICON Computing www. iconcomp. com 49

Catalysis Model Framework • A generic template package which is imported with substitutions A package to be imported property X substituting for this property: T get_<property> () : T set_<property> (T) © 1998 ICON Computing www. iconcomp. com generates this [OCF 9. 8] 50

<<property>> stereotype property editor X Editor. Core selection 0, 1 <<property>> Element property: T get_<property> () : T set_<property> (T) get_selection () : Element set_selection (Element) • <<property>> stereotype means a read-write accessor • Stereotype implies import with substitution import property [ X Editor. Core, propertycurrent, TElement ] © 1998 ICON Computing www. iconcomp. com 51

Other “property” variations r <<indexed_property>> property (int): Property. Type <<indexed_property>> (generates) set. Property (int, Property. Type) get. Property (int) : Property. Type set. Property ( Array(Property. Type)) get. Property () : Array(Property. Type) r <<bound_property>> – implies event protocol for notifying of change in property – uses Catalysis framework for output event and change i. e. equality [OCF 9. 7] r <<constrained_property>> – implies vetoable protocol of change in property – uses Catalysis framework for output event and change i. e. equality © 1998 ICON Computing www. iconcomp. com 52

Outline r From objects to components r Java interface versus class r Components with Java Beans r Specifying Java Beans • • • Type models Methods Exceptions Properties Events r Components and connectors r Testing against specifications r Reuse © 1998 ICON Computing www. iconcomp. com 53

Events r An event is a notification of a change in state r Need to specify events an object can respond to • based on its type information r Need to specify events an object can generate • based on its type information r Events generated are a problem • Not specified in normal OO interface specs © 1998 ICON Computing www. iconcomp. com 54

Specifying Events • Event recipient does not know of other interfaces and users – account balance changes due to deposit, withdraw, transfer, interest, fraud, . . . – editor element size changes due to edits, spell check, … • Outgoing events should be specified independently of triggering requests • In Catalysis, a dynamic invariant applies to every operation postcondition – A static invariant applies to every state, before and after each operation – A dynamic invariant applies to every state change i. e. to every postcondition Editor. Core contents * Element size For any operation, if any element in contents Just discuss <<output event>> here; <<output_event>> element. Changed a spec size change, it separately discusshas event inv effect contents[size@pre <> size] -> causes an output event for. All (e | ^ element. Changed (e)) © 1998 ICON Computing www. iconcomp. com 55

<<output_event>> stereotype output_event editor Editor. Core contents * Element Framework definition of register/deregister for any output event, with model of listeners. Defines ^output on source <<output_event>> element. Changed add. Element. Changed. Listener (…) remove. Element. Changed. Listener (…) • <<output_event>> implies a protocol of de/registration of listeners – Defines list of listeners, and ^output in terms of that registered list • Can group output events into Listener interfaces © 1998 ICON Computing www. iconcomp. com 56

Outline r From objects to components r Java interface versus class r Components with Java Beans r Specifying Java Beans r Components and connectors r Testing against specifications r Reuse © 1998 ICON Computing www. iconcomp. com 57

Component “connectors” output event Button slider start position pressed start <<physical>> Thermometer stop value toggled Switch property limit reactor Differentiator Threshold out in input method in gradient out in 1 in 2 OR out in Alarm in Threshold Other forms of higher-level “connectors” <<replicate>> <<workflow>> © 1998 ICON Computing www. iconcomp. com [OCF 10. 8] 58

Framework for Architectural Connector Here is what I mean by “Workflow” in any domain. . . r A Catalysis action is an abstraction of some interaction protocol r Frameworks define abstract connectors: workflow, events, properties © 1998 ICON Computing www. iconcomp. com 59

Outline r From objects to components r Java interface versus class r Components with Java Beans r Specifying Java Beans r Components and connectors r Testing against specifications r Reuse © 1998 ICON Computing www. iconcomp. com 60

Outline r From objects to components r Java interface versus class r Components with Java Beans r Specifying Java Beans r Components and connectors r Testing against specifications r Reuse © 1998 ICON Computing www. iconcomp. com 61

Systematic Testing r Testing: the activity of trying to uncover defects in an implementation against a specification (I. e. in a refinement) at run-time © 1998 ICON Computing www. iconcomp. com 62

Refinement kind determines test harness r Different test strategies for different refinement kinds • pre/post instrumentation • sequence of actions, covering success and exceptions paths • hardware test structures with mapping to deployment hardware r Link to systematic test generation © 1998 ICON Computing www. iconcomp. com 63

Testing with Abstraction functions r Modeler writes a spec and associated test assertions r Designer has to supply two things: • the design • a set of abstraction function so the test assertions to execute r One abstraction function for each specification attribute • Specification types must be implemented as adapter for this test harness • The pre/post conditions can then be executed as part of the code r [OCF 6. 4] © 1998 ICON Computing www. iconcomp. com 64

Test Adaptors SC Editor. Core Spell. Checkable seq * LM Layoutable Word Elem size next word replace word descendants * maximum Size resize children curr © 1998 ICON Computing www. iconcomp. com 1 adapter for each view/spec 65

Outline r From objects to components r Java interface versus class r Components with Java Beans r Specifying Java Beans r Components and connectors r Testing against specifications r Reuse © 1998 ICON Computing www. iconcomp. com 66

What is Reuse? Interface Reused V 1 Impl Reused V 2 What to reuse? How to reuse? r r My Code r How: • • r r Don’t reuse code without spec Model reuse is highest payback Reusable artifacts must be precise Cut and paste Import by white-box inheritance Import by black-box composition Code generation What: code? interfaces? designs? business models? © 1998 ICON Computing www. iconcomp. com 67

Re-usable Components and Variation Points Variation Point - A location at which a generic component may be specialized for use in a particular application. Variation point Generic Component Resource Allocator Machine Time Hotel Room Allocator Editor Spell Checker © 1998 ICON Computing www. iconcomp. com 68

Complete Seminar Business Model • Composed from all three frameworks, with fold/unfold Seminar Scheduling Copy. Center Production Room. Facility Topic Instructor. Skill * skills Resource. Alloc Certification Room Seminar. Session when: Date. Range * certs Instructor Customer. Trends Customer © 1998 ICON Computing www. iconcomp. com inv capability == certs. skills 69

Component Framework for Seminar Sys r Partial implementation with type specs of missing pieces © 1998 ICON Computing www. iconcomp. com 70

References r Java. Beans specs: www. javasoft. com r Enterprise Java. Beans specs: www. javasoft. com r [OCF] Objects, Components, and Frameworks with UML: the Catalysis approach, D. D’Souza and A. Wills, Addison Wesley, 1998 r C. Szyperski, “Component Software: Beyond OO Programming”, Addison Wesley, 1998 © 1998 ICON Computing www. iconcomp. com 71

Desmond: add success stories, biz slant (investment and ROI), risks and critical success factors, rollout roadmap, product packages CATALYSIS Desmond: main changes Addendum to Java Beans presentation (1) What is Catalysis: method, process, verticals, Platinum support (2) Platinum: what it does (3) 6 sales points, Catalysis is broad and deep, with a simple but high-impact core (4) [ Example -> impact ] * (5) That was one “route” (6) List of 6 sales points (7) Slides on integrating legacy systems and legacy development methods 72

Outline r Highlights of Catalysis - Platinum’s CBD method • • • Traceability Precision Components Reuse Scalability Process r Looking back - method perspective r A process walkthrough © 1998 ICON Computing www. iconcomp. com 73

Desmond: animate; make this standard What is Catalysis™? UML partner, OMG standards, TI/MS standards Precise models and systematic process Dynamic non “stovepipe” systems r A next-generation standards-aligned method • For open distributed object systems – from components and frameworks – that reflect and support an adaptive enterprise From business to code Compose pre-built interfaces, models, specs, implementations. . . …all built for extensibility Catalysis has been in development and use since 1992 Supports components, OO, legacy, heterogenous systems Addison Wesley, “Objects, Components, Frameworks…” 1998, D’Souza & Wills The foundation of Platinum’s CBD and methods offering © 1998 ICON Computing www. iconcomp. com 74

Catalysis: Beyond UML and Unified Process r UML + clear consistent approach + process • Traceability from business models to code – Business-driven, improved change management, quality assurance • Precision, with clear unambiguous models and documents – Uncover issues early, explicit shared vocabulary and understanding • Component Based Development – Interface-centric flexible black-box configuration from parts • Reuse of designs, specs, problem domain models, architectures, . . . – Consistency via patterns and frameworks, accelerated development • Scalability with abstract yet coherent UML models – consistency, completeness, and incremental development • Process that is flexible yet repeatable, with multiple “routes” – In terms of flexible process patterns with full process implementation Next Generation Method © 1998 ICON Computing www. iconcomp. com Next-Generation Tools 75

Traceability Precision Components Reuse Scalability Process Traceability of Use cases and Objects Desmond: + inside of s/w (make std) Granularity of use cases (abstract action or detailed dialog) buy course Granularity of objects (external or internal view, including software) schedule Company Client deliver Client pay SW System Refinement model (mapping) schedule deliver Client Company deliver Company Client pay Components pay © 1998 ICON Computing www. iconcomp. com • Precision will further improve traceability 76

Traceability Precision Components Reuse Scalability Process 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 change management, testing, maintainability • Frameworks (later) enable reuse of standard refinement patterns © 1998 ICON Computing www. iconcomp. com 77

Traceability Precision Components Reuse Scalability Process Precision in Business Models Business model - The actions/use-cases that take place between objects in the domain, with a specification of each action made precise in terms of a supporting model Purchase (customer, sales rep, item list) post: sales rep has new sale with totaled cost for items based on quantity and product price Sale. Item quantity purchase * item list Actor - A type of person, existing system, object, involved in actions Customer * Product price Sale total pay by bank card Credit Authorization System Sales Rep Payment total card Info Card info 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 © 1998 ICON Computing www. iconcomp. com Use-Case / Action - Abstraction of an interaction between objects to accomplish a useful unit of work. Other views (e. g. process flow, role-coordination, … ) possible as well 78

Traceability Precision Components Reuse Scalability Process Precision in System or Component Specs System of Interest Sales System <<type>> Product * inventory prods * * Sale. Item quantity Interface Operations of System curr. Sale Cust Payment Terms used to specify system operations Not a stored data model “What this system must know about the domain” Authorization start. Sale () add. Item (Product, quantity) close. Sale () pay (bank. Card, Pin) A new sale is current A new sale item has been added to the current sale with product, quantity; product inventory updated Note: Behavior Specs can be made precise using UML/Object Constraint Language (OCL) © 1998 ICON Computing www. iconcomp. com 79

Traceability Precision Components Reuse Scalability Process Rules = Actions + Static + Dynamic Invariants “New session created, confirmed if qualified instructor available” schedule deliver Students skills Admin fee-due funds Action Spec guarantees and assumptions of action Company Instructor qualified pay Session assigned date, topic cost “Any change in session must propagate to scheduler” Dynamic Invariant “Assigned instructor is qualified for topic” A state change rule that applies to all actions Static invariant Attribute constraint in all states • Captures important rules accurately without getting into implementation details © 1998 ICON Computing www. iconcomp. com 81

Traceability Precision Components Reuse Scalability Process Precision with Catalysis r Precision • Uncover important problems early • Create clear and concise documents and models • Build explicit shared vocabulary and understanding among all stakeholders • Improve early confidence in requirements and abstract models • Enhance scalability to large systems, enhance traceability, testability © 1998 ICON Computing www. iconcomp. com 83

Component-Based Development r Component-based Development: a development approach in which • … all artifacts — from executable code to interface specifications, architectures, and business models … • … scaling from complete applications and systems down to individual components … • … can be built by assembling, adapting, and “wiring” together existing components into a variety of different configurations © 1998 ICON Computing www. iconcomp. com 84

Traceabilityuse example Precision Desmond: of Toaster: what does it provide? Require? What about precise specs (110 vs. 220) Components Reuse Scalability Process What is a Component? r A coherent package of software that can be independently developed and delivered as a unit, and that defines interfaces by which it can be composed with other components to provide and use services. • Must be self-contained to be independently delivered – A component implements provided interfaces in terms of required interfaces – Interfaces must have accurate behavior specs to be useful with “black boxes” • A component package can include: – Executable, interface specification, source, design, models, test • Typically bigger than a single traditional OO “class” © 1998 ICON Computing www. iconcomp. com 85

Traceability Precision Components Reuse Scalability Process “Plugging” together - A Symmetrical View 220 V@50 Hz 120 V@60 Hz r “Plugging-in” parts will only work if the two ends are compatible • Client must specify required behavior • Implementor must specify provided behavior r Needs a symmetrical, precise, black-box view of every component • We want to “plug” together even dynamically, in cyberspace ! © 1998 ICON Computing www. iconcomp. com 86

Traceability Precision Components Reuse Scalability Process How do Components Interact? Components interact via clearly specified interfaces IPickup Interface Warehouse IDelivery Supplier Focus on interfaces - precise external behavior (provided + required) - all implementation aspects completely hidden © 1998 ICON Computing www. iconcomp. com 88

Traceability Precision Components Reuse Scalability Process Business Components: Main Issues • Assemble variety of configurations from a kit of reusable parts – covering new, legacy, and heterogeneous components Higher-level conceptual connectors Shipper Receiver * Shipment ship (shipment, receiver) shipping. Status (order) <<event>> ship ordered Higher-level parts Order Taker Customer * take. Order (info) order. Status (. . . ) cancel (. . . ) <<output>> ordered Separate views must be reconciled Common business model - conceptually with models - in implementation - shared objects with multiple interfaces - federated data + cross-component links © 1998 ICON Computing www. iconcomp. com Order Precise interfaces for 3 rd party build or assembly 89

Traceability Precision Components Reuse Scalability Process Components demand Architectural Standards r For separately built components to work together they must share… synchronous? event? work-flow? r Standard “horizontal” infrastructure services and interfaces – transactions, security, directory, request broker, interface repository. . . – OMG, Microsoft rapidly defining many global “standards” r Standard “vertical” models of domain concepts • What is a “Customer”, “Phone Call”, “Order”, etc. – components must talk the same “domain language” infrastructure services • OMG defines “Vertical” architectures standards as well r Standard “connector” mechanisms between components • Synchronous / asynchronous message, event, workflow, mobile code • Location transparency: CORBA, DCOM What is customer, phone call…? © 1998 ICON Computing www. iconcomp. com 90

Traceability Precision Components Reuse Scalability Process What is “Architecture” The set of design decisions, rules, or patterns about any system that keep its designers from exercising needless creativity • It is not about any specific size, scale, domain, or infrastructure • Can range from “ 3 -tier C/S” to “use Corba OTS” to “get/set method names” • Includes ways of defining, structuring, packaging, and sharing services • Should often be made precise using an appropriate formalism © 1998 ICON Computing www. iconcomp. com 91

Traceability Precision Components Reuse Scalability Process Architecture in Catalysis Architecture (rules, constraints, design elements) • Range of options • Fully defined translation (compiler) • Completely ad-hoc (or “creative”) • Defined rules and constraints abstraction realization • Architecture is defined in a separate package • Requirement is realized in a way that conforms to the architecture © 1998 ICON Computing www. iconcomp. com 92

Traceability Precision Components Reuse Scalability Process Tiered Components and Services Presentation “local” connector Useful to package some components as: - vertical slice Application Logic “distributed” connector - interfaces to Business Logic But there is finer grained reuse as well Data Access UI parts Domain Objects © 1998 ICON Computing www. iconcomp. com “distributed” connector Business Data Shipper Order Taker 93

Needed Elements for CBD r Language: UML r • UML-based method + process(es) • Strong support for • Standard modeling language and notation • Platinum + Catalysis were key contributors to UML 1. 0 onward r r – Components, Connectors, Arch – Precision, Interoperability – Traceability and Testability • Tool and process support • The book: www. amazon. com Products and Tools: • application development: OO, components, rules-based, data modeling, process support, configuration management, architectural consistency • systems management, security, user management, infrastructure • repository Method + Process: Catalysis r Architecture • • • Interfaces Patterns Models Infrastructure Design rules Platinum: broad, deep, strong © 1998 ICON Computing www. iconcomp. com 97

Traceability Precision Components Reuse Scalability Process 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 • Explicitly addresses problems of business components integration • Clear definition and support for architecture centered development • Works for heterogeneous and legacy components as well • Leads to rapid assembly and flexible configuration from parts © 1998 ICON Computing www. iconcomp. com 98

Traceability Precision Components Reuse Scalability Process What is Reuse? Problem Interface Code What happens when new code version released? Reused V 1 Reused V 2 What to reuse? r How to reuse? r My Code r r Don’t reuse code without spec Model reuse is highest payback Reusable artifacts must be precise What to reuse: • • Code Interfaces Designs` Problem Domain Models © 1998 ICON Computing www. iconcomp. com r How to reuse: • • Cut and paste White-box inheritance Black-box composition Reuse by code generation 99

Traceability Precision Components Reuse Scalability Process Model Frameworks - Generic Components Generic model, design, or code allocate resources to jobs if resource capability meets job req. . . room session generalize time lot plug in allocate room to seminar session if room facility meets session needs. . . allocate machine time to batch lot if machine capability meets lot processing. . . • A generic model / design / implementation component whose – Defines the broad generic structure and behavior – Provides plug-points for adaptation • Reuse starts by recognizing commonality in problems themselves! © 1998 ICON Computing www. iconcomp. com 100

Traceability Precision Components Reuse Scalability Process Some Business Model Frameworks r Resource Allocation • Assign a resource to a job if the resource capability meets the job requirement, watching for overbooking r Customer Trends • Track a customer’s preferences for different products by monitoring how frequently he/she has indicated an interest in that product (e. g. by purchasing, calling, requesting samples, …) r Production and Inventory • Manage just-in-time inventory of some products by tracking the number of items of that product in inventory, and placing an order for the production facility when inventory drops below some threshold r Note: these could be used in a variety of very different combinations © 1998 ICON Computing www. iconcomp. com 101

Traceabilityuse Desmond: animated version Precision Components Reuse Scalability Process A Complete Seminar Business Model • Built from three different model frameworks with all questions uncovered Seminar Business Copy product Room. Facility Production Topic Resource. Alloc resource Instructor. Skill * skills product Resource. Alloc job Room job Seminar. Session when: Date. Range indication Customer. Trends customer Customer © 1998 ICON Computing www. iconcomp. com Copy. Center producer item Certification * certs resource Instructor inv capability == certs. skills 102

animate to show Traceability how code reuse needs design/intnterface /etc. reuse Precision Components Reuse Scalability Process Enterprise Software Assets and Cycles • Applications – rapidly built solutions – specialize and assemble Assets Enterprise Software Assets SW Process Software components Compiled Pluggable parts Architectures Frameworks Rapid assembly Specs, Models Interfaces Rapid assembly • Assets of reusable components Replenish © 1998 ICON Computing www. iconcomp. com – – includes all asset forms, . . . generalized from application needs not created in a vacuum separately funded 104

Traceability Precision Components Reuse Scalability Process Framework Architectures at All Levels Business Models Barter Trader Authorizer Design Patterns Subject-Observer 2 -Way Link Cache Moving Window Data Normalization Domain Models Resource Allocation Account Settlement User-Interface Patterns Fundamentals Total Ordering Groups Range Descriptors • Constructive approach to modeling and design with full traceability • Libraries and commerce of frameworks of models, designs, and code © 1998 ICON Computing www. iconcomp. com 105

Traceability Precision Components Reuse Scalability Process Reuse with Catalysis r Strong emphasis on reuse • Reuse not simply implementations, but interfaces, architectures, business models • Enterprise software assets include all the above • Eliminate duplication of work - each important design, spec, or architecture element defined once and only once • Build up consistency via patterns and frameworks • Addresses organization and process implications of reuse © 1998 ICON Computing www. iconcomp. com 107

Traceability Precision Components Reuse Scalability Process What makes the method scalable? r Can be adopted in “light” or sophisticated usage r Makes key separations: deliverable structure, process routes, concrete syntax r Good support for abstraction without loss of precision r Can zoom-in and zoom-out to control complexity r More uniformity with reuse of interfaces, designs, architectures r Support multiple views of a business, system, or component r Separates key customizable parts: “route”, “deliverable format”, . . . © 1998 ICON Computing www. iconcomp. com 108

Traceability Precision Components Reuse Scalability Process Deliverable separated from “routes” Build Assemble What can I deliver? What do I have? Glue together © 1998 ICON Computing www. iconcomp. com 112

Traceability Precision Components Reuse Scalability Process Clear Structure, Process, Schedule, Deliverables Planned structure of artifacts Planned units of work Deliverables customer product sale bank card Business models System system c System spec Architecture Planned schedule Design © 1998 ICON Computing www. iconcomp. com c 1 a m 1 m 2 b c 2 x y m 3 m 4 113

Traceability Precision Components Reuse Scalability Process and Design Patterns / Guidelines – – – – The OO Golden Rule The Golden Rule vs. other Optimizations Orthogonal abstractions and refinement Refinement is a relation, not a sequence Recursive refinement Extracting generic code components Componentware management Build models from frameworks Plug conformance Using legacy or bought-in components Role delegation Pluggable roles Object Development from Scratch Re-engineering Short-Cycle Development Parallel Work © 1998 ICON Computing www. iconcomp. com – – – – – Business Process Improvement Make a business model Represent business vocabulary and rules Involve business experts Creating a Common Business Model Choose a level of abstraction Type model = glossary Separation of concepts — Normalization Items and Descriptors Generalize and specialize Recursive composite Invariants from association loops Action Reification Specify components Bridge requirements and specifications Use-case led system specification Recursive decomposition …. Many more 114

Traceability Precision Components Reuse Scalability Process PPC Catalysis Process Implementation Business context, problem definition, solution constraints Analyze, design, build, test cycles Deliver solutions © 1998 ICON Computing www. iconcomp. com 115

Traceability Precision Components Reuse Scalability Process - High Level Package Structure © 1998 ICON Computing www. iconcomp. com 116

Traceability Precision Components Reuse Scalability Process - Detailed Package Structure © 1998 ICON Computing www. iconcomp. com 117

Traceability Precision Components Reuse Scalability Process - Example of Product Structure © 1998 ICON Computing www. iconcomp. com 118

Traceability Precision Components Reuse Scalability Process - Work Breakdown and Activities © 1998 ICON Computing www. iconcomp. com 119

Traceability Precision Components Reuse Scalability Process - Tasks and Techniques © 1998 ICON Computing www. iconcomp. com 120

Traceability Precision Components Reuse Scalability Process - Detailed Techniques, Inspections. . . © 1998 ICON Computing www. iconcomp. com 121

Traceability Precision Components Reuse Scalability Process Highlights r Repeatable with clear steps, deliverables, metrics, guidelines - CMM stuff r Rich collection of “fractal” techniques -- apply at all levels r Use-case driven, with most drawbacks resolved r Builds confidence in requirements and architecture early r Supports incremental and overlapping/parallel development r From “light” version to very sophisticated usage r Clearly separates deliverables from multiple development “routes” r Supported by PPC tool implementation of process © 1998 ICON Computing www. iconcomp. com 122

Three Modeling Scopes or Levels Level/Scope Goal Domain/Business Identify Problem: “Outside” establish problem domain terminology understand business process, roles, collaborations build as-is and to-be models Component Spec Internal Design 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 the insides of each component © 1998 ICON Computing www. iconcomp. com 123

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 Buy(x) specifies behavior of a group of objects Type specifies external behavior of an object Select(x)do(Y) Framework Range(Y) Collaboration Refinement relate different levels of description of behavior map or trace from realization to abstraction recurring patterns of collaborations, types, designs, etc. define generically, “plug-in” to specialize © 1998 ICON Computing www. iconcomp. com 124

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

Looking Back - Constructs r Refinement and traceability • Objects and actions/use-cases apply at all levels of granularity • Traceable progression from high-level (business) to detailed models (code) r Use-case driven • Generalized to “actions” abstracting business tasks to OOP messages r Type and type-model based • Type defines external view of object, independent of implementation • Attributes model stored data, computed information, or real-world concepts r Captures most important forms of Rules • Static and Dynamic Invariants: constraints on attributes and state changes • Pre/post conditions: the net effect of an operation or action (before and after) • Object Constraint Language (OCL) makes these precise at all modeling levels r r Packages support flexible horizontal + vertical “extensible” partitions Frameworks support pattern capture, consistent architecture at all levels • Any recurring pattern in a model captured with a framework © 1998 ICON Computing www. iconcomp. com 126

What is its scope? r Catalysis has a simple core and broad and deep implications r It will be used in several ways and places by Platinum • A method and process(es) for Component-Based Development • A modeling approach strongly supported by a full modeling tool suite • A method for relating business problems to IT solutions • A set of process routes supported in the PPC tool set • Vertical domain knowledge assets captured in Catalysis models: ESM, DW. . . © 1998 ICON Computing www. iconcomp. com 127

Catalysis Adoption Spectrum breadth Enterprise organization roles standards reuse program Project team skills mentoring Lite type models component models implementation © 1998 ICON Computing www. iconcomp. com depth Sophisticated standard frameworks testable refinement architecture process 128

Experiences with Catalysis r EDS : Internet Multimedia division • Adopted as a required part of development standards r Credit Suisse: Asset Management • Adopted as integral part of standard r Lockheed Martin: Defense projects • Adopted as integral part of standard r USAA: Insurance • Successful application on risk-profiling project r Texas Instruments WORKS: Factory Automation • Successful and “deep” use on capacity planning and scheduling • Successful “lite” use on overall project r r Visa / Chicago: known usage Nortel, Olivetti, Siemens, many others… © 1998 ICON Computing www. iconcomp. com 129

Building on “State-of-the-Art-and-Practice” r Catalysis builds on best practices and experiences since 1990 • UML - standard notation and language for modeling components • FUSION - clear process and separation of concerns • OMT, Booch, Objectory - effective guidelines, use-case driven • Component standards - CORBA, Java. Beans, COM+ • Architecture centric - standardize architectures and frameworks © 1998 ICON Computing www. iconcomp. com 130

The Key to Catalysis Minimize the Magic r Minimize the “magic” that happens in a development process • • r Gaps between business process, software solutions, technical infrastructure Capture known designs, techniques, processes, architectures, … Common vocabulary across business, analyst, architect, programmer Common core techniques for requirements, non-functionals, design, specs. . . Full lifecycle coverage • Business problem driven with traceability from requirements to code • Rapid application development with reuse of all levels © 1998 ICON Computing www. iconcomp. com 131

Traceabilityre. Desmond: animate Precision Components Reuse Scalability Process with Catalysis Requirements Domain Models Understand problem, system context, arch and non-functional requirements. System Context Type Model and Op Specs 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 UI Design Dictionary Architectural Design boundary Scenarios System Specification Describe external behavior of target system using problem domain model Outside (+ project constraints) dialog flow, prototype, usability inside DB Design © 1998 ICON Computing www. iconcomp. com class mapping, transactions, etc. 132

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

Requirements System Specification Architectural Design Internal Design Formalized Domain Collaboration Domain collaboration - The actions/use-cases that take place between objects in the domain, with a specification of each action, in terms of a corresponding set of specification types Purchase (customer, sales rep, item list) post: sales rep has new sale with totaled cost for items based on quantity and product price Sale. Item quantity purchase * item list Actor - A type of person, existing system, object, involved in actions Customer * Product price Sale total pay by bank card Credit Authorization System Sales Rep Payment total card Info Card info Use-Case / Action - Abstraction of an interaction between objects to accomplish a useful unit of work. 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 © 1998 ICON Computing www. iconcomp. com 134

Business (Re-)Design: As-is and To-be As-Is job test track fix To-Be dispatch report track test • • essential • model Analyze existing interaction Extract essential behavior Do a re-design (refinement) Framework for use-cases Many business implications – – – performance new functionality cycle-time error rate costs phased transition plan fix © 1998 ICON Computing www. iconcomp. com 135

Requirements System Specification Architectural Design Internal Design 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 pay by bank card Sales Rep start sale add item remove item close sale cancel sale Sales System add authorized sales rep remove authorized sales rep Head sales rep © 1998 ICON Computing www. iconcomp. com Credit Authorization 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. 136

Requirements System Specification Architectural Design Internal Design Scenario of Use Actors identified from System 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 pay for the purchase. The sales rep has completed his last sale so there is currently no sale in progress. sales. System Narrative: credit. Authorization System sales rep customer The sales rep starts a new sale. The total for the sale is $0. 00. start. Sale() The sales rep adds the three watzits to the current sale. add. Item(watzit, 3) The sales rep closes the sale. The sales system returns the total due. total : = close. Sale() 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. pay(bank. Card, pin) authorized : = authorize. Payment(bank. Card, pin, total) Interactions from system-context actions © 1998 ICON Computing www. iconcomp. com 137

Requirements System Specification Architectural Design Internal Design Type Model and Operation Specs System of Interest Sales System <<type>> “Specification” type and abstract attribute Interface Operations of System Product * inventory * * Sale. Item quantity curr. Sale Cust Payment Model of object types for terms used to specify system operations Not a stored data model “What this system must know about the domain” Authorization start. Sale () add. Item (Product, quantity) close. Sale () pay (bank. Card, Pin) A new sale is current A new sale item has been added to the current sale with product, quantity; product inventory updated Note: Does not as yet commit to operations on individual classes inside system Internal component partitioning and class design not decided yet. © 1998 ICON Computing www. iconcomp. com 138

Desmond: use Requirements stereotypes System Specification Architectural Design Internal Design Tech Architecture: Platform and Physical SQL requests methods> UI <views Inventory DB Application Server SQL requests Customer DB • 3 -Tier Architecture – Thin Client: User interface, dialog flow logic – Application Server: Business objects and rules – Oracle Database: Persistent data storage • Must explicitly evaluate technical architecture factors – Scalability, performance, thruput, seats, platform, clustering. . . Note: 3 -Tier could also be a purely logical partition of presentation, business objects, store © 1998 ICON Computing www. iconcomp. com 139

Requirements System Specification Architectural Design Internal Design Architecture: Application Components Application Server Sales Manager UI Sale. Item Inventory Manager Product Credit Authorizer Payment DB Server 1 Authorization Frequent Buyer Mgr Customer DB Server 2 • Application components partitioned and interactions designed – Partition based on ease of change, re-use, buy Vs. build, etc. • Original domain types split across components, some partly shared © 1998 ICON Computing www. iconcomp. com 140

Development Process with Catalysis Traceability r Precision Components Reuse Scalability Process coverage meets many needs • Repeatable and predictable process • Flexible with clear separation of deliverable from “routes” • Supports multiple routes • Strong support for architecture, patterns, traceability • Tool implementation of process in Platinum LBMS/PPC © 1998 ICON Computing www. iconcomp. com 141

For more information r For information on Catalysis/CBD contact us at: • Desmond D’Souza desmond. dsouza@platinum. com • Daryl Winters daryl. winters@platinum. com r Visit the Platinum and Catalysis web sites • www. platinum. com (Catalysis Resources page coming soon) • www. catalysis. org © 1998 ICON Computing www. iconcomp. com 142