Upload
hal
View
36
Download
0
Tags:
Embed Size (px)
DESCRIPTION
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 - PowerPoint PPT Presentation
Citation preview
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