Upload
ophelia-johnston
View
220
Download
0
Embed Size (px)
Citation preview
2
Agenda
Definition Highlights of Catalysis Catalysis in Practice Design Issues Abstraction Layers in Development Some Case Studies Different Refinements Conclusion
3
The Name
Catalysis
• An acceleration of the rate of a process or reaction, brought about by a catalyst, usually present in small managed quantities and unaffected at the end of the reaction. A catalyst permits reactions or processes to take place more effectively or under milder conditions than would otherwise be possible.
4
•Component-based, architecture and reuse centric, business driven•Layered architectures separating UI, application, business, data•A more mature, repeatable, sustainable business and IT development process
Typical Enterprise Evolution Path
“As-Is” Inventory “To-Be” Planning Transition …..
• Very heterogeneous hardware and software platform mix• Rampant duplication of effort, functions, code• Very difficult to maintain and change• Inconsistent and conflicting architectural styles•Too many “magical” gaps between business need and code
• Tools• Methods•Architectures•Education•Maturity transition• …
5
Traceabilitybridge Business and ITprecise shared vocabularycritical business questions early
Traceabilitybridge Business and ITprecise shared vocabularycritical business questions early
Architectureinterfacesplug standards
Architectureinterfacesplug standards
Talk Preview - Success With Components
Reuse Processdevelop for reusedevelop with reusereuse interface,code
Reuse Processdevelop for reusedevelop with reusereuse interface,code
Pluggable Componentsprecise interface-centric designtraceable business components
Pluggable Componentsprecise interface-centric designtraceable business components
Business Drivenunderstand business first
Business Drivenunderstand business first
6
A Multi-Pronged Approach
Object and component modelingData modelingBusiness modelingConfiguration managementProject management
Strategic ConsultingEducationSystems DevelopmentSystems Integration
ToolsMethods
&Processes
Architecture&
Reuse
Services
Catalysis CBD methodNext-generation approach =Precise models and
systematic process Roles, activities, …Process implementations
CatalysisCore
Business problem
Software architecture
Code Deployment
Consistency via Architecture &Reuse Design patterns Interface and technology standards Code components
7
Highlights of Catalysis
Traceability
Precision
Components
Reuse
Scalability
Process
8
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 configuration management, testing, maintainability
• Frameworks enable reuse of standard refinement patterns
9
Precision with Catalysis
Precision
• Uncover important problems early
• Create clear and concise documents and models
• Build explicit shared vocabulary
Enhance scalability to large systems, enhance traceability, testability
10
Component-Based Development with Catalysis
Component Based Development
• Strong support for interface-centered design
• Black-box descriptions of components that are clear and simple
• Leads to rapid assembly and flexible configuration from parts
11
Reuse with Catalysis
Strong emphasis and fundamental support for reuse
• Reuse not simply implementations, but interfaces, architectures, business models
• Eliminate duplication of work - each important design, spec, or architecture element defined once and only once
• Build up consistency via patterns and frameworks
12
Catalysis Process
RequirementsRequirementsDomain ModelsDomain Models
System ContextSystem ContextUnderstand problem, context,
& non-functional req.
System SpecificationSystem Specification ScenariosScenarios
Operation SpecsOperation SpecsDescribe external behavior of
the system
Architectural DesignArchitectural Design Platform, Phy. ArchitecturePlatform, Phy. Architecture
Log. Application ArchitectureLog. Application Architecture
Partition technical & application
architecture components
Component Internal DesignComponent Internal Design
Design interfaces for each
component; build and test
Interface and Class SpecsInterface and Class Specs
Implementation and TestImplementation and Test
Dictio
nary
Dictio
nary
Outside(+ project constraints)
boundary
inside
UI DesignUI Design
DB DesignDB Design
13
Three Modeling Scopes or Levels
Domain/BusinessDomain/Business
Component SpecComponent Spec
Internal DesignInternal Design
Goal
“Boundary”: Specify Componentscope and define component responsibilitiesdefine component/system interfacespecify desired component operations
“Outside”: Identify Problem, Solutionestablish problem domain terminologyunderstand business process, roles, collaborationsbuild as-is and to-be models
“Inside”: Implement the Specdefine internal architecturedefine internal components and collaborationsrecursively design insides of each component
Level/Scope
14
Catalysis in Practice
System
c1
a b
m1m2
c2
m3m4
xy
c
system
15
Main Elements of Catalysis
Object: Representing a cluster of information and functionality
Action: Representing any-thing that happens :
• An event
• Task
• Job
• Message
• Change of state
• Interaction
• Activity
16
Actions and Postconditions
TeacherStudent
Teach
Action type = Use case Object type
action (student, teacher) :: teach (skill) post -- this skill has been added to the student’s
accomplishments (Skill here is an attribute )
17
Precision in Business Models
Actor
Business model - The actions (use-cases) that take place between objects (actors) in the business, with each action specified in terms of a supporting model of concepts (glossary)
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
18
Elements of an Action
Teach action is a composition made up of the smaller ones
Assembly
19
Actions at Different Scales
Action Type
Collaboration Diagram
Object Type
Teach
Schedule the course
Deliver the course
Zoomed-in actions
constituting teach.
Run Course
Arrange
20
An Occurrence of the Teach Action
Object Instances
Sequence Diagram
Action Occurrences
21
Assigning Responsibilities to Objects
First state what happens
Then state which object is responsible for doing it
Which one is responsible for initiating it
Actions characterized by what they achieve
Then by how they achieve it
22
Associations
The useful aspect of associations:
Don’t have to say exactly how they are realized
Statements about how actions affect them are still
meaningful
These specifications are abstract and yet precise
They expose inconsistencies of natural language
23
Refining Associations
AssociationAssembly
Use of stick figures instead to highlight roles
Several roles can be played by one object
24
More Detailed Description
Zooming in and out is useful when seeking What a business does Why it does it
25
Business Modeling
The main objective is for the model to represent how the users think of the world with which they work
Starting questions are “What do you do?” and “Whom do you deal with?”
Every time you introduce a new object type, add to the list of questions “What actions affect that? What actions does it affect?”
26
Business Modeling (cont.)
Every time a verb is mentioned, draw an action and add to your list of questions• “Who and what else participates in that?
• What is its effect on their state?”
The answers to these questions lead you to• Draw object types
• Write post conditions
These in turn lead to associations and attributes
27
Traceability from Business to CodeZoom in/out of use-case (user task)(abstract action or detailed dialog)
Zoom in/out 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
• Fractal zooming without losing preciseness
Refinement (mapping)
28
Rules = Actions + Static + Dynamic Invariants
• Captures important rules accurately without getting into implementation details
• Enable the User to raise and resolve critical issues early
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
Admin
Company
schedule
pay
deliver
Sessiondate, topiccost
Instructorqualified
Studentsskills
fundsassigned
“Assigned instructor is qualified for topic”
“Any change in session must propagate to scheduler”
29
Design Issues
30
Directed Actions
At some stage in a completed design all actions turn into a dialog, in which each action is a message with
A definite sender (with responsibility for initiating the action)
A receiver (with responsibility for achieving the required outcome)
And parameters (that do what the receiver asks of them)
These are called directed actions; when viewed strictly from the side of the receiver, they are called localized actions
31
Separation of concerns
This skill is crucial, in Catalysis we provide the means to separate different layers of design decisions:
The behavior that is required (post conditions)
Assignment of responsibilities (roles and collaborations)
The way each object and action is implemented (successive refinement)
32
Catalysis Vs. Others
Abstraction technique in Catalysis:
• Treat a complex system as one object
• Treat complex interactions as one action
• Yet state the out-come precisely
This approach contrasts with more-traditional design techniques in which abstract also tends to mean fuzzy
33
Abstraction Layers in Development
Two to five layers of abstraction in development : ( a bigger number for more complex projects )
Business model (sometimes called domain or essential model): Describes the users’ world separately from any notion of the target software.
Requirements specification: Describes what is required of software (no reference to how it is implemented). It is mandatory for a major component or complete system. It may be approached differently when the complete system is created by rapidly plugging kit components together
34
Abstraction Layers in Development (cont.)
Component design: Describes (on a high level) how the major components collaborate, with references to a requirements specification for each one. Needed if there are distinct major components
Object design: Describes how a component or system works, down to programming language classes or some other level that can be coded (or turned into code by a generator)
Component kit architecture: Describes the common elements of the way a collection of components work together (e.g. standard interaction protocols).
Different developers build interoperable components
35
Static Models and Invariants
Business rules can be written as invariants:
inv -- for every CourseRun, its instructor’s qualifications must include the course
CourseRun :: instructor.qualifications -> includes (course)
The invariants are described informally and are written in a simple language of Boolean conditions & set relationships
(Client, SeminarCo) :: arrange (Subject)
36
Snapshots
Draw Snapshots to help visualize the effects:
Action postconditions:instructor.outage@pre[when=d] = 0 & instructor.qualifications -> includes (t) ]
Newly created object links
Association inherited from supertype
37
Actions and Postconditions
action (c: Client, s: SeminarCompany) :: arrange (t: Course, d: Date)
post -- a new CourseRun is created with date, client, course
r : CourseRun.new [date=d, client=c, course=t]
-- assigned instructor who was free on date d and qualified for the course
38
Another Example: ATM
A simple ATM user:
type UserwalletAmount : Currency .. What the user has got in her pocketaccount : BankAccount .. Her bank accountend
type ATMcashAmount : Currency .. What remains in the machineend
39
Example : ATM (cont.)
The getMoney action describes an ATM transaction:
action (u:User,a:ATM)::getMoney(amount:Currency)
pre : u.account.balance > amount
pre : a.cashAmount >= amount
post : u.account.balance = u.account.balance - amount
post : a.cashAmount = a.cashAmount - amount
post : u.walletAmount = u.walletAmount@pre + amount
end model
40
Object Oriented Design
The process begins by turning many things in a model into classes:
Hence, Instructor, Course Run, and Course now become classes
Roles are assigned to the classes, as for components The actions at this level are finally standard OO messages The associations become pointers, decisions are made
about their directionality Design patterns are used to guide these decisions (as they
can be used throughout the development process)
41
Object Oriented Design (cont.)
The end result of OO design is a collection of :
Classes that encapsulate program variables and code
Types that define the behavior expected at the interfaces to classes. Classes implement types
Next, component implementation (the “Insides” process) commences
42
Refining Catalysis action types using UML
How Catalysis action types can be modeled in UML? The UML Action concept: an action is executed when a
stimulus is (bound to this action) received completely different from the one we need
The UML Collaboration concept: describes interactions among objects. Using Collaboration to model Catalysis seems possible
The UML Use Case concept bears similarities with the concept of Action in Catalysis. A Use Case connects several participants, is extensible, and therefore is a good candidate to represent refinements
43
UML Use Cases VS Catalysis Actions
They are somewhat different for several reasons:
Use Cases: interactions between some central object and its environment, which includes actors. On the contrary, Catalysis actions give symmetric roles to its participants
Use Cases are modeling tools showing interactions between actors and the system. This is not as flexible and precise as a speciation tool as Catalysis' pre/post conditions on actions.
44
A simple usecase refinement
Get Money Get Money Get Cash
Request Money
Provide Id
<<refine>>
<<include>>
<<include>>
<<inclu
de>>
45
Review
UML + simple consistent approach, process, techniques• Traceability from business models to code
• Precision, with clear unambiguous models and documents
• Component Based Development
• Reuse of designs, specs, problem domain models, architectures, ...
• Scalability from small to large teams and projects
• Process that is flexible yet repeatable
Next Generation Solutions
46
References
http://www.catalysis.org
http://www.catalysis.org/publications/catalysis.zip
http://ase.arc.nasa.gov/wtuml01/submissions/plouzeau-sunye.pdf
http://www.cetus-links.org