Catalysis
Download
1 / 59

Catalysis - PowerPoint PPT Presentation


  • 412 Views
  • Updated On :

Catalysis Objects, components, and Frameworks with UML From the book Objects, components, and frameworks with UML: the Catalysis Approach, by Desmond D’Souza and Alan Wills. A tour Objects and actions object: cluster of information + functionality action: anything that happens

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Catalysis' - jacob


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Catalysis l.jpg

Catalysis

Objects, components, and Frameworks with UML

Catalysis/Testing


From the book l.jpg
From the book

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

Catalysis/Testing


A tour l.jpg
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 l.jpg
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 l.jpg
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 objects6 l.jpg
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 l.jpg
Precise specifications

action(student,teacher)::

teach(skill)

post student.accomplishments =

[email protected]+

skill

Catalysis/Testing


Refinement l.jpg
Refinement

  • Of objects and actions

  • Zoom in and out

Catalysis/Testing


Connection to aspectual components l.jpg
Connection to aspectual components

  • objects, components (actions), connectors

  • actions have a modification interface

Catalysis/Testing


Commonalities catalysis ac l.jpg

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

Commonalities Catalysis/AC

Catalysis/Testing


Differences catalysis ac l.jpg

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

Differences Catalysis/AC

Catalysis/Testing


Development layers vanilla development from scratch l.jpg
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 l.jpg
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 l.jpg
Model Frameworks as Templates

  • Similar to AC, but no aspects

  • parameterized

Catalysis/Testing


Requirements specification models l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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


Testing20 l.jpg
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 l.jpg
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 functions22 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
Testing by adapting the implementation

  • Specification (with test information)

  • Implementation package

    • Adapter

    • Implementation

Catalysis/Testing


Slide26 l.jpg

Spreadsheet

Content

*

Cell

content

shows

value

right

left

Sum

Number

Blank

Invariants:

for all Sum objects s:

s.value = s.left.content.value + s.right.content.value

for all Blank objects b: b.value = 0

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

Catalysis/Testing


Slide27 l.jpg

Spreadsheet

Content

*

Cell

content

shows

value

abs

Sum s;

s.left = s.impl1.operands[1].abs

s.right=s.impl1.operands[2].abs

s.value=s.impl1.container.value

right

left

Sum

Number

Invariants:

for all Sum objects s:

s.value = s.left.content.value + s.right.content.value

for all Blank objects b: b.value = 0

abs

Blank

abs

RETRIEVAL DIAGR.

impl1

Spreadsheet_1

impl1

impl1

*

sumpart

Cell_I

shows

container

Sum_I

isBlank:boolean

value

*

operands

Catalysis/Testing


Retrieval functions with dj l.jpg
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 functions29 l.jpg
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


Slide30 l.jpg

S is participant graph for G

F=t

F

D

D

E

E

B

B

C

C

S

G

A = s

A


Catalysis process main theme l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 evolution35 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
Static model with behavior

Course Scheduling

staff

fullSchedule

*

*

Static

model

instructor 0..1

Client

Session

Instructor

sessions

*

grade: Grade

date : Date

*

sessions

rating: Grade

client

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

behavior

Behavior defined in

terms of static model

Catalysis/Testing


Static model l.jpg

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

Static Model

busStops

BusStop

BusRoute

0..*

DOES NOT REVEAL TOO

MANY IMPLEMENTATION

DETAILS

waiting

0..*

Person

Catalysis/Testing


Implementation 1 l.jpg
Implementation 1

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

busStops

BusRoute

BusStopList

OO solution:

one method

for each red

class

buses

0..*

BusStop

BusList

waiting

0..*

passengers

Bus

PersonList

Person

0..*

Catalysis/Testing


Implementation 2 l.jpg

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

Implementation 2

villages

BusRoute

BusStopList

buses

VillageList

busStops

0..*

0..*

BusStop

BusList

Village

waiting

0..*

passengers

Bus

PersonList

Person

0..*

Catalysis/Testing


Filter out noise in class diagram l.jpg
Filter out noise in class diagram

  • only three out of seven classes

  • are mentioned in static model

BusRoute BusStop Person

replaces the classes

BusRoute VillageList Village BusStopList BusStop

PersonList Person

Catalysis/Testing


Map static model to application class graph l.jpg
Map static model to application class graph

villages

BusRoute

BusStopList

VillageList

busStops

0..*

0..*

BusStop

Village

busStops

BusStop

BusRoute

0..*

edge -> path

Catalysis/Testing


Using dj l.jpg
Using DJ

class BusRoute {

Vector busStops(){return

Main.cg.gather(this,

new Strategy(

“from BusRoute to BusStop”);}

}

Catalysis/Testing


Using dj complete solution l.jpg
Using DJ: complete solution

class BusRoute {

Vector waitingPersons(){return

Main.cg.gather(this,

new Strategy(

“from BusRoute via BusStop to Person”);}

}

Catalysis/Testing


Notes l.jpg
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 l.jpg

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

Two approaches

Catalysis/Testing


Using dj complete solution java problem parameterization l.jpg
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 solution java problem parameterization52 l.jpg
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


Slide53 l.jpg

Resource Allocation

reqs

<JobCategory>

<Facility>

0..*

type

provides

0..*

<Job>

when: TimeInterval

schedule

allocated

<Resource>

0..*

0..1

inv Job::allocated<>0 ==> allocated.provides->includesAll(type.reqs)

--Any allocated resource must have the required facilities

inv Resource::jo1, jo2: Job::

(schedule->includesAll({jo1,jo2}) ==>

jo1.when.noOverlap(jo2.when)

-- no double-booking of resources

Catalysis/Testing


Slide54 l.jpg

Resource Allocation

reqs

JobDescription

Skill

0..*

type

JobCategory

Facility

provides

0..*

Resource Allocation

Resource

Job

Job

when: TimeInterval

schedule

allocated

Plumber

0..*

0..1

Customer

Application of resource allocation to Pluming

Catalysis/Testing


Reuse and pluggable design chapter 11 l.jpg
Reuse and Pluggable designchapter 11

  • Reuse requires components that are

    • generic

    • customizable

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

Catalysis/Testing


Reuse l.jpg
Reuse

  • Reuse without alteration? Is limited.

Catalysis/Testing


What is an aspect l.jpg
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 l.jpg
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 l.jpg
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

Catalysis/Testing


ad