Catalysis/Testing

Catalysis

Objects, components, and Frameworks with UML

Catalysis/Testing

From the book

• Objects, components, and frameworks with UML: the Catalysis Approach, by Desmond D’Souza and Alan Wills.

Catalysis/Testing

A tour

• Objects and actions– object: cluster of information + functionality– action: anything that happens

• actions can be independent of objects. Bound to objects later.

– what happens during action– which object is responsible for doing action– which object is responsible for initiating action– how is it done

• actions affect objects

Catalysis/Testing

Fractal picture

• A fractal picture has the same appearance at all scales

• objects: business departments, machines, running software components, programming language concepts

• actions: interactions among objects: big business deals,phone calls, bike rides, etc.

Catalysis/Testing

Actions affect objects

• Actions = collaborations• In Catalysis collaborations are first-class

units of design.• Where should collaborations be used?

– what goes on inside a software component– user-component interactions– business modeling: how do real-world objects

interact?

Catalysis/Testing

Actions affect objects

• Actions have participants (objects)• Which objects do you need? Enough to

describe the actions• Associations provide a vocabulary in which

it is possible to describe effects of actions (prefer: class graph over associations)

Catalysis/Testing

Precise specifications

action(student,teacher):: teach(skill)post student.accomplishments = student.accomplishments@pre+ skill

Catalysis/Testing

Refinement

• Of objects and actions• Zoom in and out

Catalysis/Testing

Connection to aspectual components

• objects, components (actions), connectors• actions have a modification interface

Catalysis/Testing

Commonalities Catalysis/AC

• actions independent of objects

• abstract does not mean fuzzy

• program should be structured according to a business model

• static model

• AC independent of objects

• AC is abstract and executable

• program should look like a design

• participant graph

Catalysis/Testing

Differences Catalysis/AC

• actions cannot describe aspects

• uses pre- and post-conditions

• no connectors

• AC (when modification interface is used) can model aspects

• should use pre and post conditions

• connectors keep components clean

Catalysis/Testing

Development Layers: vanilla development from scratch

• Business model (domain/essential model)• Requirements specification• Component design• Object design• Component kit architecture: needed to build

interoperable components• April 11,99

Catalysis/Testing

Static models and invariants

• An action’s postcondition can be written in terms of static relationships

• Connection: participant graph of AC contains information to describe postconditions

Catalysis/Testing

Model Frameworks as Templates

• Similar to AC, but no aspects• parameterized

Catalysis/Testing

Requirements Specification Models

• Objects in this diagram are not real objects but rather the system’s own representation of them

• Static model: is a hypothetical picture created for explaining the systems externally visible behavior to its users.

Catalysis/Testing

Static model (continued)

• There is no mandate on the designer to implement it exactly with classes and variables that mirror directly the types and associations in the spec.

Catalysis/Testing

Partitioning the model between components

• Each of the components performs only some of the system’s functions and includes only part of its state

• different vocabulary; need map• reconstruct all the attributes and associations

from component design

Catalysis/Testing

Collaborations

• Now: a collaboration is a collection of actions and the types of objects that participate in them

• Sometimes they say: action = collaboration

Catalysis/Testing

Testing

• When does a more detailed design conform/implement/refine a more abstract one?

• How to test different kinds of refinement relations?

• Connection: refinement/testing

Catalysis/Testing

Testing

• Pre and post conditions useful for testing• test harness• C++ STL library: has assert macro• Every component needs to have its own test

kit to monitor behavior in new context

Catalysis/Testing

Retrieval functions

• Every implementation should have a complete set of retrieval functions; that is, read only abstraction functions for computing the value of every attribute in the spec. from the implementation

• Need to translate from one model to another• Retrieval functions can be inefficient: only

used for verification; e.g. testing.

Catalysis/Testing

Retrieval functions

• Long history: VDM, Z• support traceability: how change in spec or

code influences the other• use retrieval diagrams

Catalysis/Testing

Benefits of retrieval functions

• cross-check• make it explicit how abstract model is

represented in the code• testing: execute postconditions and

invariants defined in requirement model

Catalysis/Testing

Golden rule of OOD

• Choose your classes to mirror your specification model. 1-1 correspondence often not possible– model that gives best performance often

different from one that clearly explains what the object does

– multiple models are implemented simultaneously: each model: partial view

Catalysis/Testing

Testing by adapting the implementation

• Specification (with test information)• Implementation package

– Adapter– Implementation

Catalysis/Testing

Spreadsheet

CellContent

valueright

Number

Blank

left

Sum

contentshows

Invariants: for all Sum objects s: s.value = s.left.content.value + s.right.content.valuefor all Blank objects b: b.value = 0

*

Simplified: a formula can be only the sum of two other cells

Catalysis/Testing

Spreadsheet

CellContent

valueright

Number

Blank

left

Sum

contentshows

Invariants: for all Sum objects s: s.value = s.left.content.value + s.right.content.valuefor all Blank objects b: b.value = 0

*

Spreadsheet_1

Cell_I

isBlank:booleanvalue

Sum_Icontainer

sumpart

shows

RETRIEVAL DIAGR.

operands

impl1impl1

impl1

abs

abs

abs

Sum s;s.left = s.impl1.operands[1].abss.right=s.impl1.operands[2].abss.value=s.impl1.container.value

*

*

Catalysis/Testing

Retrieval functions with DJ

• How to represent the participant graph?– Use strategy graph. Introduce a string for each

edge. E1 = “{A->B bypassing X}”. class A {B getB(){return (B)

tg.fetch(this);} }– tg is the traversal graph for E1.

Catalysis/Testing

Retrieval functions

• Overlay concrete class graph with participant class graph using getter functions that are implemented using strategies. Name map is identity map.

• Can simplify class graph before writing strategies. Can introduce multiple class graph views.

Catalysis/Testing

A = s A

B BC C

D DE E

F=t F

G

S

S is participant graph for G

Catalysis/Testing

Catalysis Process: Main Theme

• Higher-level• Lower-level, a refinement of higher level.

Retrieve mapping from higher-level to lower-level.

• For every specification activity there is a corresponding implementation and testing activity

Catalysis/Testing

Typical Process for a Business System

• Requirements• System Specification• Architectural Design: components/connectors

– application architecture: packages, collaborations– technical architecture: hardware, software platform,

infrastructure components• Component Internal Design

Catalysis/Testing

Typical Project Evolution : page 522

• The business case: initial requirements• Domain or business model: independent of

software solution. Reusable across multiple projects.

• Joint-Application Development: developers/users

• Glossary

Catalysis/Testing

Typical Project Evolution

• Type model plus system specifications. Primary actions system participates in. Refined to atomic interaction with system.

• UI sketches• Subject areas• Generic problem frameworks• Refactor for reuse

Catalysis/Testing

Typical Project Evolution

• Design rules for technical architecture• Technical architecture model• Horizontal slices: architecture simulation• Application architecture: design of

application logic as a collection of collaborating components

• Project plan, deployment

Catalysis/Testing

Testing/Specification

• Write action specifications precisely enough – to form the basis for testing and– to make the model explicit enough to uncover

business issues

Catalysis/Testing

Chapter 3: Behavior Models

• Component-based software development: separate external behavior from internal implementation

• Describe behavior: by list of actions and response to those actions (called the component’s type)

Catalysis/Testing

Actions

• action (party1:Type1, party2:Type2,…) ::actionName(…)• not centered on a single object type• action effect is described in terms of of all

participant

Catalysis/Testing

More precise action specifications

• Well-written pre- and postconditions can be used as the basis for verification and testing

• Use general syntax from UML called Object Constraint Language (OCL). More convenient than Java

• Pre- and postconditions

Catalysis/Testing

Two parts of a specification

• Static model (structure): UML class diagram and invariants

• Type specification (behavior): specify effects of actions on component using vocabulary provided by static model

• This chapter: about how to derive and write type specifications. Examples follow.

Catalysis/Testing

Static model with behavior Course Scheduling

Client Session

fullSchedule

sessions *

client

*

Instructor

rating: Grade

staff*

instructor 0..1

sessions*grade: Gradedate : Date

Invariant (business rule): fullSchedule.grade <=fullSchedule.instructor.rating

checkAvailability(instructor,date)post: find whether instructor is doing a session on that date

scheduleCourse(date,client)post: set up a new session and assign an instructor

{ordered date}

Staticmodel

behavior Behavior defined interms of static model

Catalysis/Testing

Static Model

BusRoute BusStop

Person

busStops

waiting

0..*

find all persons waiting at any bus stop on a bus route

0..*

DOES NOT REVEAL TOOMANY IMPLEMENTATIONDETAILS

Catalysis/Testing

Implementation 1

BusRoute BusStopList

BusStopBusList

Bus PersonList

Person

passengers

buses

busStops

waiting

0..*

0..*

0..*

find all persons waiting at any bus stop on a bus route

OO solution:one methodfor each redclass

Catalysis/Testing

Implementation 2

BusRoute BusStopList

BusStopBusList

Bus PersonList

Person

passengers

busesbusStops

waiting

0..*

0..*

0..*

VillageList

Village

villages

0..*

find all persons waiting at any bus stop on a bus route

Catalysis/Testing

Filter out noise in class diagram

•only three out of seven classes are mentioned in static model

BusRoute BusStop Person

BusRoute VillageList Village BusStopList BusStopPersonList Person

replaces the classes

Catalysis/Testing

Map static model to application class graph

BusRoute BusStopList

BusStop

busStops 0..*VillageList

Village

villages

0..*

edge -> path

BusRoute BusStopbusStops

0..*

Catalysis/Testing

Using DJ

class BusRoute { Vector busStops(){return Main.cg.gather(this, new Strategy( “from BusRoute to BusStop”);}}

Catalysis/Testing

Using DJ: complete solution

class BusRoute { Vector waitingPersons(){return Main.cg.gather(this, new Strategy( “from BusRoute via BusStop to Person”);}

}

Catalysis/Testing

Notes

• Static model is translated into a strategy• Why? With DJ behavior is written in such a

way that it is usable in many different static models

Catalysis/Testing

Two approaches

Catalysis:• Define static model and

define behavior using static model

• Map static model to implementation model

• Behavior is in implementation model

DJ:• Define strategies

corresponding to static model and express behavior using strategies.

• Adjust strategies for implementation model.

• Behavior is in implementation model

Catalysis/Testing

Using DJ: complete solutionJava problem: parameterization

class BusRoute { Vector waitingPersons(){return Main.cg.gather(this,new Strategy( “from BusRoute via BusStop to Person”);}

}

Catalysis/Testing

Using DJ: complete solutionJava problem: parameterization

class BusRoute { PersonList waitingPersons(){return Main.cg.traverse(this,new Strategy( “from BusRoute via BusStop to Person”,new PersonVisitor());}

}

Catalysis/Testing

Resource Allocation

<JobCategory> <Facility>reqs

<Job>when: TimeInterval <Resource>

0..*

type

allocated

provides 0..*

0..1

inv Job::allocated<>0 ==> allocated.provides->includesAll(type.reqs)--Any allocated resource must have the required facilitiesinv Resource::jo1, jo2: Job:: (schedule->includesAll({jo1,jo2}) ==> jo1.when.noOverlap(jo2.when)-- no double-booking of resources

schedule

0..*

Catalysis/Testing

Resource Allocation

JobDescription Skillreqs

Jobwhen: TimeInterval Plumber

0..*

type

allocated

provides 0..*

0..1

schedule

0..*

Resource Allocation

Facility

ResourceJob

JobCategory

Application of resource allocation to Pluming

Customer

Catalysis/Testing

Reuse and Pluggable designchapter 11

• Reuse requires components that are– generic– customizable

• Reuse: most compelling reason for adopting component-based approaches

Catalysis/Testing

Reuse

• Reuse without alteration? Is limited.

Catalysis/Testing

What is an aspect?

• An aspect is a modular unit that cross-cuts other modular units.

• What means cross-cutting?• Apply AOP to AOP. Tease an aspect apart

into three units: ideal graph, labels on nodes and edges of ideal graph, application to concrete graph using connectors: specifies cross-cutting

Catalysis/Testing

Example: ACs

• Ideal graph: participant graph• Labels on nodes and edges: participant code• Concrete graph: participant graph or

application class graph• Connectors specify cross-cutting

Catalysis/Testing

Theory of cross cutting

• Model programs as graphs (e.g. class diagrams, abstract syntax trees, etc.)

• Aspects: model as graph editing instructions modeled with respect to an ideal graph.

• Graph editing: add new