catalysis
Download
Skip this Video
Download Presentation
Catalysis

Loading in 2 Seconds...

play fullscreen
1 / 59

Catalysis - PowerPoint PPT Presentation


  • 413 Views
  • Uploaded 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

Catalysis

Objects, components, and Frameworks with UML

Catalysis/Testing

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

Catalysis/Testing

a tour
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
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 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
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
Precise specifications

action(student,teacher)::

teach(skill)

post student.accomplishments =

[email protected]+

skill

Catalysis/Testing

refinement
Refinement
  • Of objects and actions
  • Zoom in and out

Catalysis/Testing

connection to aspectual components
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

Commonalities Catalysis/AC

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

Differences Catalysis/AC

Catalysis/Testing

development layers vanilla development from scratch
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
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
Model Frameworks as Templates
  • Similar to AC, but no aspects
  • parameterized

Catalysis/Testing

requirements specification models
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
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
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
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
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
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
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
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
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
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
Testing by adapting the implementation
  • Specification (with test information)
  • Implementation package
    • Adapter
    • Implementation

Catalysis/Testing

slide26
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Using DJ

class BusRoute {

Vector busStops(){return

Main.cg.gather(this,

new Strategy(

“from BusRoute to BusStop”);}

}

Catalysis/Testing

using dj complete solution
Using DJ: complete solution

class BusRoute {

Vector waitingPersons(){return

Main.cg.gather(this,

new Strategy(

“from BusRoute via BusStop to Person”);}

}

Catalysis/Testing

notes
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

Two approaches

Catalysis/Testing

using dj complete solution java problem parameterization
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
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
Resource Allocation

reqs

0..*

type

provides

0..*

when: TimeInterval

schedule

allocated

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
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
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
  • Reuse without alteration? Is limited.

Catalysis/Testing

what is an aspect
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
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
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