About the Speaker

1

JavaBeans

Specification, Design, and Test(using Catalysis)

Aamod Sane

Platinum Technology www.platinum.com

2© 1998 ICON Computing www.iconcomp.com

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, design-pattern 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


Outline

From objects to components

Java interface versus class

Components with Java Beans

Specifying Java Beans

Components and connectors

Testing against specifications

Reuse


What is a Component?

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


Components and Interfaces

• Packages must clearly separate interfaces from implementations

• Interfaces must be organized to capture interface dependencies

Spreadsheet

Display

Data sourceCalc

IDisplay IDataSource

Must contain (or reference)interfaces provided and used

Many implementationsof used interfaces


That’s what’s interesting about themThat’s what’s interesting about them

2. Components compose and grow2. Components compose and grow

1. Components interact1. Components interact

3. Components may be distributed3. Components may be distributed

Warehouse

Supplier

Component Essentials


How do Components Interact?

Components interact via clearly specified interfacesComponents interact via clearly specified interfaces

Focus on behavior; stored data, implemented procedures, other interfaces remain completely

hidden

Focus on behavior; stored data, implemented procedures, other interfaces remain completely

hidden

Warehouse

Supplier

IDelivery

How is data stored?Is the data stored here?

…or actually stored here?What other interfaces are provided or used?

Interface

IPickup


Describing a Component

Warehouse

Supplier

IDelivery

Services Provided: Interface SpecServices Provided: Interface Spec Services Required: Interface SpecServices Required: Interface Spec

Events Raised: Notificationsof state changes

Events Raised: Notificationsof state changes

Logical model of component state: Type Model Interface operations and events specified based on thisLogical model of component state: Type Model Interface operations and events specified based on this

Result: Precise model of information exchanged, assumptions, guarantees

Result: Precise model of information exchanged, assumptions, guarantees

Not standard OO!!


Component “connectors”

<<event>>

ButtonButton

SwitchSwitch reactor

ThermometerThermometer ThresholdThreshold

OROR

ThresholdThresholdDifferentiatorDifferentiator

slider

pressed

start

start

stop

toggled

<<physical>>

position

limitvalue in

value

ingradient

in

out

outin1

in2

outAlarmAlarm

in

<<replicate>>

<<workflow>>

Other forms of higher-level “connectors”

[OCF 10.8]

<<event>>

<<prop>>

<<prop>>

<<prop>>


infrastructure services

Components must share Architectural Standards

Standard “horizontal” infrastructure services– request broker, interface and server repository, transaction, security, …

– OMG, Microsoft rapidly defining many global “standards”

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

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, ActiveX, TeleScript

synchronous? event? work-flow?

What is customer,phone call…?


Are Components and Objects Different?

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

obj-2obj-1

host/language

obj-4obj-3

host/language



Component Granularity and Binding Time

Granularity spans the spectrum• UI widgets: combo-box, tree

• “Application” and component-document elements: spreadsheet

• Large-grain components: scheduler, inventory manager

Good components are often not “business objects”!!• Naïve OOA/D will not lead automatically to component design

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

Range of binding times• Design-time

• Run-time


Components + Objects: Best of Both

• Plug together components and objects at any level and any binding time

Finer-grain, dynamic, polymorphic “objects”Finer-grain, dynamic, polymorphic “objects”

Larger-grain, more static, polymorphic “components”Larger-grain, more static, polymorphic “components”


Outline







Reuse

© 1998 ICON Computing www.iconcomp.com

Type of an Object: Multiple (Inter)Faces

• 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

Passenger check Baggage board deplane

Guest guarantee check In order room Service pay at check Out

What Type? What Type?

“Plug” into new service

AirlineHotel

© 1998 ICON Computing www.iconcomp.com

Types: Java, COM, Corba, ...

interface Guest {guaranteeCheckIn ();orderRoomService();payCheckOut ();

}

interface Passenger {checkBaggage ();board ();deplane ();

}

interface Guest {guaranteeCheckIn ();orderRoomService();payCheckOut ();

}

interface Passenger {checkBaggage ();board ();deplane ();

}class Both implements Guest, Passenger {

// implementation …. }

class Both implements Guest, Passenger {

// implementation …. }

object:Both

Guest

Passenger

HotelAirline

Full type/class separation possible!!


Interface vs. Class: Which does a Client Use?

Which of the Tx types here have to be classes, and which can be interfaces?

class C1 implements T extends T0 {

private T1 contents;

public T2 foo (T3 b) {

super ();

this ();

contents = b;

T2 d;

d = new T5 ();

return d;

}

}

Client never needs to mention “class - except to instantiate - can use “factory” patterns here


Outline







Reuse


Java Beans

A “Component” standard for Java

A reusable software component that can be manipulated in a visual builder tool

Describes component by properties, methods, events• Property: an observable state variable

• Method: an invocable service

• Event: a notification of state change

Builds on underlying technology of reflection, persistence


“Wiring” beans together

p1

p2

Events can be “wired” to methods• Match event parameters and properties (state variables) to method inputs

Properties can be “wired” to other properties• Implicit, rather than explicit update protocols

• Not currently supported by JavaBeans products

properties

E (x)

event

m (p,q)

method

p3


Reflection

JDK 1.1 introduced the reflection API

Run-time representation of class, interface, method, …

Run-time operations on these objects

Enables very-late binding of calls

Determines properties, methods, events from signatures• Can be supplanted by an explicit BeanInfo class


JDK 1.1 Reflection

Reflect on Java definitions at run-time by accessing:• Class: static Class forName(String)

getSuperclass, getInterfaces, getFields, getMethods, getConstructors, …newInstance, ...

• Field: getDeclaringClass, getName, getModifiers, getType, getBoolean, getInt, … setBoolean, setInt ...

• Method: getDeclaringClass, getName, getReturnType, getParameterTypes, getExceptionTypes, invoke ...

• Constructor: … newInstance

Uses wrappers for primitives, arrays


Reflection Example

// locate and load the class dynamicallyClass c = Class.forName (“UserDefinedClass”);

// instantiate the classObject o = c.newInstance ();

// get one of the methods on that classMethod m = c.getDeclaredMethod (“userMethod”, {

} );

// invoke that method on the new instancem.invoke (o);


Beans Properties via Naming + Reflection

Properties derived by reflection using name conventions Simple properties: “StockSymbol” of type String

String getStockSymbol();

void setStockSymbol(String newSymbol);

“Multi-valued” properties: “Symbol” of type String []public String getSymbol(int index); // throws bounds

error public void setSymbol(int index, String newValue); // throws …

Other property types: bound, constrained Example:

class MyBean {

String getStockSymbol() {…}

void setStockSymbol (String) {…}

}


Event Design Patterns in JavaBeans

Group events into event channels by Listener interfacesinterface BalanceListener extends java.util.EventListener

{

void overdrawn (BalanceEvent);

void balanceOK (BalanceEvent);

}

Bean may offer different event channels

Standard protocol pattern for registering event listener: void addBalanceListener (BalanceListener f);

void removeBalanceListener (BalanceListener f);

Account BeanBalance event channel

Usage event channelBalanceListener


Beans persistence via Serialization

Save and restore graphs of Bean objects to/from streams All JDK 1.1 classes can be serialized

implement java.io.Serializable

Default behavior/formats easily extended or overridden public class MyBean implements java.io.Serializable

{ SomeOtherBean delegate;

transient Object anotherField;

}

Save and restore automatically availableObjectOutputStream ost = new ObjectOutputStream(a);

out.writeObject(new MyBean());

ObjectInputStream ist = new ObjectInputStream(b);

MyBean x = (MyBean)ist.readObject();


JavaBean versus Java Object

The interfaces of a JavaBean may be provided by a group of collaborating objects of different classes• This will become increasingly common with complex beans

They conceptually work as a single object

Danger: Java language primitives will not know this!

• 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

a

b

dc


JAR files

A JavaBean 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

When modeling, use package structure effectively


Enterprise Java Beans

A standard for simplifying server components by implementing most “middle-tier” services• Distributed transactions• Thread and database connection pooling• Concurrent access• Authentication


Outline From objects to components



Specifying Java Beans• Type models• Methods• Exceptions• Properties• Events



Reuse


The “Black-Box” Component

Signatures are not enough to define widely-used components

Thingami

frob (Thing, int)Thing fritz(int)

NuclearReactorCore

add (ControlRod, int)ControlRod remove(int)

Editor

spellCheck()layout()addElement(…)delElement(…)


Components need Precise Interfaces

To build systems by “plugging” together components

?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

“Type” specwhat is expected ofany “plug-in”

will work with...

is one implementation of...


Model-Based Type Specification - Example

spellCheck()layout()addElement(…)delELement(…)

Editor «type»

*

ElementpreferredSizeposition

Word Composite

*

*

dictionary

contents

every element is positioned so that its preferred size can be accommodated

every word in contents is correct by the dictionary

Editor Type Specificationtype-model = vocabulary

operations specified in termsof the type model “vocabulary”

type specificationusually in separatepackage

[OCF 3.4]


Formalizing Operation Specs

Operation specification can formalized• OCL (Object Constraint Language) used after rectifying some shortcomings

• Checked, used for refinements, testing, change propagation, …

Enables checkable/testable design-by-contract

Editor:: spellCheck ()

post // every word in contentscontents -> forAll (w: Word |

// has a matching entry in the dictionary

dictionary -> exists (dw: Word | dw.matches(w)))


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

E-Corenext word

replace word

maximum sizeresize

children

Spell Checker

spellCheck()

Layout Manager

layout()dictionary

words

Editor

spellCheck()layout()addElement(…)delELement(…)

Editor Internal Designinternal design in a separate package from the specification


Each Component implements many Types

• Components offer different interfaces to each other

• Each interface has a different supporting model

• The implementation refines each interface spec

SC LM

next wordreplace word

SpellCheckable

Wordseq *

curr

maximum Sizeresizechildren

Layoutable

Elemsize

descendants *

Spell-Checker Layout Manager

EditorCore


Type-Based Components are “Pluggable”

Any component that provides the correct interface (operations and apparent type model) can plug-into another component

DB RecordEditorCoreAcme Spell Bee

Spell Checkable

next Wordreplace Word

Wordseq *SpellChecker


Component Implementation

class EditorCoreClass implements SpellCheckable, Layoutable {

// store a tree of all elements — graphics, words, characters, tables, etc.private ElementTree contents;

// this iterator traverses all elements in the contents tree in depth-first order

private DepthFirstIterator elementIterator = contents.root();

// this iterator only visits Word elements, ignoring othersprivate WordIterator spellPosition = new WordFilter (elementIterator);

// return the “next” word in the treepublic Word nextWord () {

Word w = spellPosition.word();spellPosition.next();return w;

}

// replace the last visited word with the replacementpublic void replaceWord (Word replacement) {

spellPostion.replaceBefore (replacement);}

}


Class refines Interface

contents

para-1 table

word1

word2

fig1

row1 row2

word3fig2

Wordwords seq *

EditorCore <<class>>

Spell Checkable

next Wordreplace Word

refinementwords = contents.asDepthFirstSequence -> select (e | e.isKindOf (Word))

“abstraction function” or “retrieval”

Abstraction function “retrieves” abstract model attributes


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

ReceiverShipment*

BuyerOrder*

3. Separate views for flexible use (can ship to any receiver)

Integrated business modelCustomer

4. Precise interfaces for 3rd assembly

<<event>>

ship ordered

2. Higher-level late-bound connectors and properties… abstract the protocol, defer binding

Shipper

ship (shipment, receiver)shippingStatus (order)

Order Taker

takeOrder (info)orderStatus (...)cancel (...)<<output>> ordered

1. Higher-level parts… abstract the objects

- must integrate in conceptual models- must integrate data in implementation - shared objects with multiple interfaces - federated data + cross-component links


Presentation

Local Application

Business Logic

Business Data

Business area

“local” connector

“distributed” connector


Business Components: Tiered Architecture

- interfaces connecting Business Logic

- vertical slice

Can package application components as:

Shipper Order Taker

Component packaging + reuse at all levels

Data Access

UI parts Domain Objects

Domain Objects + UI Panels

Logging, events,...

Can zoom in to show architecturaltiers, or zoom out to model abstract business components

Shipper Order Taker








Reuse


Exception versus Undefined Behavior

Guaranteed exceptions are different from undefined failures Invoker needs clear indication of exception versus success Exceptions should not be overspecified: e1 versus e2

– [OCF8.4]

space of inputs + initial states

defined

undefined

normal input

exception input

space of outcomes: outputs + result states

normal outcome

exception outcomee2

e2

undefined outcome

what outcome here?


Specifying Exceptions

Define normal and exception indicators

Editor::spellCheck ()

exception = throws (Object) // throw <=> exception

normal = not throws (Object) // if normal, nothing thrown

Write separate post defining different exceptions

Editor::spellCheck ()

post (dictionary@pre = null) or (read_only) implies exception

// a definite exception if no dictionary or read_only

post throws (DictionaryError) implies (dictionary@pre = null)

post exception implies contents unchanged

// contents definitely unchanged on any exception








Reuse


Type model attribute vs. query method

A type-model attribute does not imply a get/set method

• Attributes are just a model of state

• Not necessarily externally accessible

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

Shortcut for “property” attributes with Catalysis frameworks

Model only

public


Intent

We don’t want to model with explicit get/set • Loses the main intent

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


Catalysis Model Framework

• A generic template package which is imported with substitutions

property

get_<property> () : Tset_<property> (T)

property: T

A package to be imported

generates this

substituting for this

X

[OCF9.8]


<<property>> stereotype

• <<property>> stereotype means a read-write accessor• Stereotype implies import with substitution

import property [ X \ EditorCore, property\current, T\Element ]

get_selection () : Elementset_selection (Element)

EditorCore

Elementselection 0,1

<<property>>

editor

property

get_<property> () : Tset_<property> (T)

property: TX


Other “property” variations

<<indexed_property>>property (int): PropertyType <<indexed_property>>

(generates)

setProperty (int, PropertyType)

getProperty (int) : PropertyType

setProperty ( Array(PropertyType))

getProperty () : Array(PropertyType)

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

<<constrained_property>>– implies vetoable protocol of change in property

– uses Catalysis framework for output event and change i.e. equality








Reuse


Events

An event is a notification of a change in state

Need to specify events an object can respond to • based on its type information

Need to specify events an object can generate • based on its type information

Events generated are a problem• Not specified in normal OO interface specs


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

<<output_event>> elementChangedinv effect contents[size@pre <> size] ->

forAll (e | ^ elementChanged (e))

EditorCore

Elementsize

contents *

For any operation, ifany element in contentshas a size change, itcauses an output event

Just discuss <<output event>> here; separately discuss event spec

Just discuss <<output event>> here; separately discuss event spec


<<output_event>> stereotype

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

<<output_event>> elementChanged

addElementChangedListener (…)removeElementChangedListener (…)

EditorCore

Elementcontents *

editoroutput_event

Framework definitionof register/deregisterfor any output event, withmodel of list of listeners.Defines ^output on source


Outline







Reuse


Component “connectors”

property

output event

input method

ButtonButton

SwitchSwitch reactor

ThermometerThermometer ThresholdThreshold

OROR

ThresholdThresholdDifferentiatorDifferentiator

slider

pressed

start

start

stop

toggled

<<physical>>

position

limitvalue in

value

ingradient

in

out

outin1

in2

outAlarmAlarm

in

<<replicate>>

<<workflow>>

Other forms of higher-level “connectors”

[OCF 10.8]


Framework for Architectural Connector

connector

Workflow connector

<xxx> <yyy>

template definesprotocol of actionsbetween components thatuse this connector type

«Workflow»

Placeholder typesmap to existing façades withinconnected components, or to code generated “adapters”

Here is what I meanby “Workflow” in any domain...

A Catalysis action is an abstraction of some interaction protocol

Frameworks define abstract connectors: workflow, events, properties


Outline







Reuse


Outline







Reuse


Systematic Testing

internal design “collaboration”

domain model: ‘to-be’

sys t em sp ec

refin ement

refi nemen t

spec of 1 component/class

int er fa ce sp ec implem ent a c la sst es t a gain s t int erface op s pec

full “build” of sys t emt es t a ga ins t s ys t em s pecs

int egrat e cla ss est es t a gain s t collabo rat ion s pec

deploy s ys t emuser t ra in, a ccept an ce t es t

S pe c ify Im p le m en t a nd Te s t

t es t refi nemen t

t es t refi nem ent

t es t refin ement

Testing: the activity of trying to uncover defects in an implementation against a specification (I.e. in a refinement) at run-time


Refinement kind determines test harness

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

Link to systematic test generation

message1

Black Boxmessage2

pre ...post ...

(debug phase)test harness

pre ...post ...

Component

straight-through(installed mode)


Testing with Abstraction functions

Modeler writes a spec and associated test assertions

Designer has to supply two things: • the design

• a set of abstraction function so the test assertions to execute

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

[OCF 6.4]


Test Adaptors

BusinessCore Adapter

Spec

Adapter

Spec

interface interface

Component

SC LM

next wordreplace word

SpellCheckable

Wordseq *

curr

maximum Sizeresizechildren

Layoutable

Elemsize

descendants *

EditorCore

1 adapter foreach view/spec


Outline







Reuse


What is Reuse?

How:• Cut and paste• Import by white-box inheritance• Import by black-box composition• Code generation

What: code? interfaces? designs? business models?

Reused V1 Reused V2

My Code

What to reuse?How to reuse?

Interface

Don’t reuse code without spec Model reuse is highest payback Reusable artifacts must be precise

Impl


Re-usable Components and Variation Points

Variation Point - A location at which a generic component may bespecialized for use in a particular application.

GenericComponent

Resource AllocatorResource Allocator Machine TimeMachine Time

HotelHotel Room AllocatorRoom Allocator

EditorEditor Spell CheckerSpell Checker

Variation point


Complete Seminar Business Model

• Composed from all three frameworks, with fold/unfold

Topic

SeminarSessionwhen: DateRange

Room

RoomFacility

Instructor

InstructorSkill

inv capability == certs.skills

Certification

* skills

* certs

ResourceAlloc ResourceAlloc

Seminar Scheduling

Copy CopyCenter

Customer

CustomerTrends

Production


Component Framework for Seminar Sys

Partial implementation with type specs of missing pieces

Seminar System Implementation 2

Sales FE Qualifications DB

Calendar

PlannerInstructor FE

FancyPlanner

PlanTasticDatime

Carl’s CalOur Q DB

frameworkwith specification‘sockets’

implementations‘plug into’sockets

implements

light border =specs only

dark border =implementations


References

JavaBeans specs: www.javasoft.com

Enterprise JavaBeans specs: www.javasoft.com

[OCF] Objects, Components, and Frameworks with UML: the Catalysis approach, D. D’Souza and A. Wills, Addison Wesley, 1998

C. Szyperski, “Component Software: Beyond OO Programming”, Addison Wesley, 1998

72

CATALYSIS

Addendum to Java Beans presentation

Desmond: add success stories, biz slant (investment and ROI), risks and critical success factors,

rollout roadmap, product packages

Desmond: add success stories, biz slant (investment and ROI), risks and critical success factors,

rollout roadmap, product packages

Desmond: main changes

(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

Desmond: main changes

(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


Outline

Highlights of Catalysis - Platinum’s CBD method• Traceability

• Precision

• Components

• Reuse

• Scalability

• Process

Looking back - method perspective

A process walkthrough


What is Catalysis™?

A next-generation standards-aligned method• For open distributed object systems

– from components and frameworks

– that reflect and support an adaptive enterprise

Precise models and systematic processUML partner, OMG standards, TI/MS standards

Dynamic non “stovepipe” systems

Compose pre-built interfaces,models, specs, implementations...

…all built for extensibility

From business to code

Catalysis has been in development and use since 1992Supports components, OO, legacy, heterogenous systemsAddison Wesley, “Objects, Components, Frameworks…” 1998, D’Souza & Wills

The foundation of Platinum’s CBD and methods offering

Desmond: animate; make this standard

Desmond: animate; make this standard


Catalysis: Beyond UML and Unified Process

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 ToolsNext Generation Method


Traceability of Use cases and ObjectsGranularity of use cases (abstract action or detailed dialog)

Granularity of objects (external or internal view, including software)

Client

Companybuy course

Client

Company

schedule

pay

deliver

payClient

Company

schedule

deliver

Client

Companyschedule

pay

deliver

SW System

Components

Traceability Precision Components Reuse Scalability Process

Desmond: + inside of s/w (make std)Desmond: + inside of s/w (make std)

• Precision will further improve traceability

Refinement model(mapping)


Traceability and Catalysis

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



Precision in Business Models

Actor - A type of person, existing system, object, involved in actions

Business model - The actions/use-cases that take place between objects in the domain, with a specification of each action madeprecise in terms of a supporting model

Sales Rep

CreditAuthorization

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 - Abstraction of an interaction between objects to accomplish a useful unit of work.

* item list

*

SaleItemquantity

Productprice

Saletotal

Paymenttotal

card Info

Cardinfo

Other views (e.g. process flow,role-coordination, … ) possible as well



Precision in System or Component Specs

Sales System <<type>>

startSale ()addItem (Product, quantity)closeSale ()pay (bankCard, Pin)

Interface Operationsof System

A new sale is current

A new sale item has beenadded to the current salewith product, quantity;product inventory updated

System of Interest

Terms used to specify system operations Not a stored data model“What this system mustknow about the domain”

Note: Behavior Specs can be made precise using UML/Object Constraint Language (OCL)

Sale

SaleItemquantity

Payment

Authorization

*prods

**

currSaleCust

Productinventory



Rules = Actions + Static + Dynamic Invariants

Admin

Company

schedule

pay

deliver

Sessiondate, topiccost

Instructorqualified

Studentsskills

fee-duefunds

• Captures important rules accurately without getting into implementation details

Static invariantAttribute constraint in all states

“New session created, confirmed if qualified instructor available”

Dynamic Invariant A state change rule that applies to all actions

assigned

Action Specguarantees and assumptions of action

“Assigned instructor is qualified for topic”

“Any change in session must propagate to scheduler”



Precision with Catalysis

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



Component-Based Development

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


What is a Component?

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”

Traceability Precision Components Reuse Scalability ProcessDesmond: use example of Toaster: what does it provide? Require? What about precise specs (110 vs. 220)

Desmond: use example of Toaster: what does it provide? Require? What about precise specs (110 vs. 220)


“Plugging” together - A Symmetrical View

“Plugging-in” parts will only work if the two ends are compatible• Client must specify required behavior• Implementor must specify provided behavior

Needs a symmetrical, precise, black-box view of every component• We want to “plug” together even dynamically, in cyberspace !

120V@60Hz

220V@50Hz



How do Components Interact?

Components interact via clearly specified interfacesComponents interact via clearly specified interfaces

Warehouse

Supplier

IDelivery

Interface

IPickup

Focus on interfaces- precise external behavior (provided + required)- all implementation aspects completely hidden

Focus on interfaces- precise external behavior (provided + required)- all implementation aspects completely hidden



Business Components: Main Issues

• Assemble variety of configurations from a kit of reusable parts– covering new, legacy, and heterogeneous components

ReceiverShipment*

CustomerOrder*

Common business modelSeparate views must be reconciled- conceptually with models- in implementation - shared objects with multiple interfaces - federated data + cross-component links

Precise interfaces for 3rdparty build or assembly

<<event>>

ship ordered

Higher-level conceptualconnectors

Shipper

ship (shipment, receiver)shippingStatus (order)

Order Taker

takeOrder (info)orderStatus (...)cancel (...)<<output>> ordered

Higher-level parts




Components demand Architectural Standards

For separately built components to work together they must share…

Standard “horizontal” infrastructure services and interfaces– transactions, security, directory, request broker, interface repository...

– OMG, Microsoft rapidly defining many global “standards”

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

Standard “connector” mechanisms between components• Synchronous / asynchronous message, event, workflow, mobile code

• Location transparency: CORBA, DCOM

synchronous? event? work-flow?

What is customer,phone call…?



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



Architecture in Catalysis

• Architecture is defined in a separate package• Requirement is realized in a way that conforms to the architecture


abstraction

realization

Architecture(rules, constraints, design elements)

• Range of options• Fully defined translation (compiler)• Completely ad-hoc (or “creative”)• Defined rules and constraints


“local” connector



Tiered Components and ServicesTraceability Precision Components Reuse Scalability Process

Presentation

Application Logic

Business Logic

Business Data

- interfaces to Business Logic

- vertical slice

Useful to package some components as:

Shipper Order Taker

But there is finer grained reuse as well

Data Access UI parts

Domain Objects


Needed Elements for CBD

Products and Tools:• application development: OO,

components, rules-based, data modeling, process support, configuration management, architectural consistency

• systems management, security, user management, infrastructure

• repository Platinum: broad, deep, strong

Language: UML• Standard modeling language

and notation

• Platinum + Catalysis were key contributors to UML 1.0 onward

Method + Process: Catalysis• UML-based method + process(es)

• Strong support for– Components, Connectors, Arch

– Precision, Interoperability

– Traceability and Testability

• Tool and process support

• The book: www.amazon.com

Architecture• Interfaces

• Patterns

• Models

• Infrastructure

• Design rules


Component-Based Development with Catalysis

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



What is Reuse?

What to reuse:• Code

• Interfaces

• Designs`

• Problem Domain Models

Reused V1

My Code

What to reuse?

Interface

Don’t reuse code without spec Model reuse is highest payback Reusable artifacts must be precise

Code


How to reuse:• Cut and paste

• White-box inheritance

• Black-box composition

• Reuse by code generation

How to reuse?

Problem

Reused V2

What happens when new code version released?


Model Frameworks - Generic Components

• 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!

allocate room toseminar session if

room facility meetssession needs...

allocate machine timeto batch lot if

machine capabilitymeets lot processing...

generalize

allocate resourcesto jobs if resource

capability meets job req ...

plug in

room session time lot

Generic model, design, or code



Some Business Model Frameworks

Resource Allocation• Assign a resource to a job if the resource capability meets the job

requirement, watching for overbooking

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, …)

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

Note: these could be used in a variety of very different combinations



A Complete Seminar Business Model

• Built from three different model frameworks with all questions uncovered

Seminar Business

Topic

SeminarSessionwhen: DateRange

Room

RoomFacility

Instructor

InstructorSkill

inv capability == certs.skills

Certification

* skills

* certs

Copy CopyCenter

Customer

ResourceAlloc ResourceAlloc

CustomerTrends

Production

indication

customer

product

producerproduct

item

jobresourcejob

resource

Traceability Precision Components Reuse Scalability ProcessDesmond: use animated version

Desmond: use animated version


Enterprise Software Assets

SW Process

Enterprise Software Assets and Cycles

Software componentsCompiled

Pluggable partsArchitectures

Frameworks

Specs, Models

Interfaces

Rapid assembly

Rapid assembly

Replenish

• Applications– rapidly built solutions

– specialize and assemble Assets

• Assets of reusable components– includes all asset forms, ...– generalized from application needs– not created in a vacuum– separately funded


Desmond: animate to show how code reuse needs design/intnterface/etc. reuse

Desmond: animate to show how code reuse needs design/intnterface/etc. reuse


Framework Architectures at All Levels

• Constructive approach to modeling and design with full traceability

• Libraries and commerce of frameworks of models, designs, and code

Business Models

Barter

Trader

Authorizer

Domain Models

Resource Allocation

Account Settlement

User-Interface Patterns

Design Patterns

Subject-Observer

2-Way Link

Cache

Moving Window

Data Normalization

Fundamentals

Total Ordering

Groups

Range

Descriptors



Reuse with Catalysis

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



What makes the method scalable?

Can be adopted in “light” or sophisticated usage

Makes key separations: deliverable structure, process routes, concrete syntax

Good support for abstraction without loss of precision

Can zoom-in and zoom-out to control complexity

More uniformity with reuse of interfaces, designs, architectures

Support multiple views of a business, system, or component

Separates key customizable parts: “route”, “deliverable format”, ...



Deliverable separated from “routes”

Infra. Tool Specs

Detailed to-be

Component-Spec

Variant-1 Variant-2

Component-Design

internal components and collaborations

Technical ArchitectureApplicationArchitecture

Component-Implementation

(next level of) implementation of each internal component conforms to spec

TechnicalArchitecture Impl.

T1 T2

T2 implementation

Infra. Tool Impls.

Business Model V-0.9

technical architecture may use published standards and APIs

T1 implementation

existing products, tools, standards

design rules,patterns

Abstract BusinessModel, no Software

Detailed to-beBusiness Model V-1.0

Uses Variant-1 of system Uses Variant-2 of system

componenrt spec based on business model detailed business tasks using new software

component internal design refines its spec

<<build>>

‘build’ tool dependencies

to implement abstract business model

to realize the component spec

using technical architecture

this should eventually beshared across projects

Business

may use published stdsor infrastructure tools

<<use>>

implementation dependencies

Build Assemble

What do I have?

Glue together

What can I deliver?



Clear Structure, Process, Schedule, Deliverables

product

sale

customer

bank card

System

c

c1

a b

m1m2

c2

m3m4

xy

system

Planned structure of artifacts Planned units of work

Planned schedule

Deliverables


Businessmodels

Systemspec

Design

Architecture


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

– 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



PPC Catalysis Process ImplementationTraceability Precision Components Reuse Scalability Process

Business context, problem definition, solution constraints

Analyze, design, build, test cycles

Deliver solutions


Process - High Level Package StructureTraceability Precision Components Reuse Scalability Process


Process - Detailed Package StructureTraceability Precision Components Reuse Scalability Process


Process - Example of Product StructureTraceability Precision Components Reuse Scalability Process


Process - Work Breakdown and ActivitiesTraceability Precision Components Reuse Scalability Process


Process - Tasks and TechniquesTraceability Precision Components Reuse Scalability Process


Process - Detailed Techniques, Inspections...Traceability Precision Components Reuse Scalability Process


Process Highlights

Repeatable with clear steps, deliverables, metrics, guidelines - CMM stuff

Rich collection of “fractal” techniques -- apply at all levels

Use-case driven, with most drawbacks resolved

Builds confidence in requirements and architecture early

Supports incremental and overlapping/parallel development

From “light” version to very sophisticated usage

Clearly separates deliverables from multiple development “routes”

Supported by PPC tool implementation of process



Three Modeling Scopes or Levels

Domain/BusinessDomain/Business

Component SpecComponent Spec

Internal DesignInternal Design

Goal

Specify Solution: “Boundary”scope and define component responsibilitiesdefine component/system interfacespecify desired component operations

Identify Problem: “Outside”establish problem domain terminologyunderstand business process, roles, collaborationsbuild as-is and to-be models

Implement the Spec: “Inside”define internal architecturedefine internal components and collaborationsdesign the insides of each component

Level/Scope


Three Modeling ConstructsPurpose

specifies external behavior of an object

specifies behavior of a group of objects

relate different levels of description of behaviormap or trace from realization to abstraction

recurring patterns of collaborations, types, designs, etc.define generically, “plug-in” to specialize

Collaboration

Type

Refinement

ModelConstruct

Fra

mew

ork

Desmond:

Refinement is common to types and collaborations; frameworks are common to all three. Re-draw the figure to show this

Desmond:

Refinement is common to types and collaborations; frameworks are common to all three. Re-draw the figure to show this

Buy(x)

Range(Y)

Select(x)do(Y)


Three Principles

Intent

expose gaps and inconsistencies earlymake abstract models accurate, not fuzzy

focus on essential aspects, deferring othersuncluttered description of requirements and

architecture

all work done by adapting and composing partsmodels, architectures, and designs are assets

Abstraction

Precision

Pluggable Parts

Principle


Looking Back - Constructs

Refinement and traceability• Objects and actions/use-cases apply at all levels of granularity• Traceable progression from high-level (business) to detailed models (code)

Use-case driven• Generalized to “actions” abstracting business tasks to OOP messages

Type and type-model based• Type defines external view of object, independent of implementation• Attributes model stored data, computed information, or real-world concepts

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

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


What is its scope?

Catalysis has a simple core and broad and deep implications

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


Catalysis Adoption Spectrum

Litetype modelscomponent modelsimplementation

Sophisticatedstandard frameworkstestable refinementarchitectureprocess

Enterpriseorganizationrolesstandardsreuse program

Projectteam skillsmentoring

depth

breadth


Experiences with Catalysis

EDS : Internet Multimedia division• Adopted as a required part of development standards

Credit Suisse: Asset Management• Adopted as integral part of standard

Lockheed Martin: Defense projects• Adopted as integral part of standard

USAA: Insurance • Successful application on risk-profiling project

Texas Instruments WORKS: Factory Automation• Successful and “deep” use on capacity planning and scheduling

• Successful “lite” use on overall project

Visa / Chicago: known usage Nortel, Olivetti, Siemens, many others…


Building on “State-of-the-Art-and-Practice”

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, JavaBeans, COM+

• Architecture centric - standardize architectures and frameworks


Minimize the MagicMinimize the Magic

The Key to Catalysis

Minimize the “magic” that happens in a development process• 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


Process with Catalysis

RequirementsRequirements Domain ModelsDomain Models

System ContextSystem ContextUnderstand problem, system context,

arch and non-functional requirements.

System SpecificationSystem Specification ScenariosScenarios

Type Model and Op SpecsType Model and Op SpecsDescribe external behavior of target

system using problem domain model

Architectural DesignArchitectural Design Platform, Physical ArchitecturePlatform, Physical Architecture

Logical Application ArchitectureLogical Application Architecture

Partition technical and application

architecture components and their

connectors to meet design goals

UI DesignUI Design

dialog flow, prototype, usability

DB DesignDB Design

class mapping,

transactions, etc.

Component Internal DesignComponent Internal Design

Design interfaces and classes for

each component; build and test

Interface and Class SpecsInterface and Class Specs

Implementation and TestImplementation and Test

Dictionary

Dictionary

Outside(+ project constraints)

boundary

inside

Traceability Precision Components Reuse Scalability ProcessDesmond: re-animate

Desmond: re-animate


Mind Map: Informal Problem Domain Model

Mind Map - An informal structured representation of a problem domainNot a stored data model!!

Global Groceries

customer

sales rep

product price

shelf

discount percent

sale

purchases

Sales System

conducts

records

bank card

Clusters - Domain terms representingpotential attributes.

Nodes - Domain terms representingpotential objects, types, or actors.Can include “rich-pictures” as drawingsof the problem domain

Arcs (optionally directed and labeled) -Representations of potential associationsor collaborations between objects.

Requirements System Specification Architectural Design Internal Design

Can be formalized if appropriate


Formalized Domain Collaboration

Actor - A type of person, existing system, object, involved in actions

Domain collaboration - The actions/use-cases that take place between objects in the domain, with a specification of each action, in termsof a corresponding set of specification types


Sales Rep

CreditAuthorization

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 - Abstraction of an interaction between objects to accomplish a useful unit of work.

* item list

*

SaleItemquantity

Productprice

Saletotal

Paymenttotal

card Info

Cardinfo


Business (Re-)Design: As-is and To-be

• 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

essential

model

job

fix

testtrack

As-Is

trackdispatchreport

fix

test

To-Be


System Context -- a Collaboration

Head sales rep

Sales Rep

CreditAuthorization

System

Customer

add authorized sales repremove authorized sales rep

pay by bank card

start saleadd item

remove itemclose sale

cancel sale

Sales System

Specialization - Indicates that a specialized actor can also play the role of a more

general actor.

Actor - A person, existing system, device, etc. that interacts directly

with the target 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.

System Context Model -A structured representation of the collaborationsthat take place between a system and objects inits surrounding environment (context).



Scenario of Use

startSale()

addItem(watzit, 3)

total := closeSale()

sales rep customer

salesSystem creditAuthorizationSystem

authorized := authorizePayment(bankCard,pin, total)

pay(bankCard, pin)

Context: A customer approaches a sales rep with the intention of purchasing three watzitsusing 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.Actors identified

from System Context.

Narrative:

The sales rep starts a new sale. The totalfor the sale is $0.00.

The sales rep adds the three watzitsto the current sale.

The sales rep closes the sale. The salessystem returns the total due.

The customer inserts her bank card intothe reader and enters her pin number

The Sales System requests paymentauthorization from the credit authorizationsystem. The system authorizes payment.

Interactions from system-context actions



Type Model and Operation Specs

Sales System <<type>>

startSale ()addItem (Product, quantity)closeSale ()pay (bankCard, Pin)

Interface Operationsof System

A new sale is current

A new sale item has beenadded to the current salewith product, quantity;product inventory updated

System of Interest

Model of object types for terms used to specify system operations Not a stored data model“What this system mustknow about the domain”

Note: Does not as yet commit to operations on individual classes inside system

Internal component partitioning and class design not decided yet.

“Specification” type and abstract attribute

Sale

SaleItemquantity

Payment

Authorization

*

**

currSaleCust

Productinventory



Tech Architecture: Platform and Physical

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

UI Application ServerInventory DB

SQL requestsmethods>

<views

Note: 3-Tier could also be a purely logical partition of presentation, business objects, store

Customer DB

SQL requests

Requirements System Specification Architectural Design Internal DesignDesmond:use stereotypes

Desmond:use stereotypes


Frequent Buyer Mgr

Credit Authorizer

Inventory ManagerSales Manager

Architecture: Application Components

• 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

Application Server

Sale SaleItem

Customer

Product

AuthorizationPayment

DBServer

1

UI

DBServer

2



Development Process with Catalysis

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



For more information

For information on Catalysis/CBD contact us at:

• Desmond D’[email protected]

• Daryl [email protected]

Visit the Platinum and Catalysis web sites• www.platinum.com (Catalysis Resources page coming soon)

• www.catalysis.org

Documents

About the Speaker