Architectural Design
of
Distributed Business Systems
Tutorial M3,
TOOLS Europe 2001
13 March 2001
Trygve Reenskaug
Mogul Norway AS, Oslo
http://www.ifi.uio.no/~trygver
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
5/29/2016 3:31:59 AM.
Slide
1
The Autokon system
for the Computer-Aided Design of Ships
1960 - Architecture created
1962 - First deployed
1965 - First international
1997 - Converted to PC
Architecture still valid!!
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
5/29/2016 3:31:59 AM.
Slide
2
The Autokon architecture
Why the long life ?
¤ Shipbuilding essentially unchanged
¤ Luck - random access mass storage
devices enabled database solution
¤ Reality reflected into
Clean, intelligible modular structure
¤ Expressed user needs as symptoms
for required abstractions
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
5/29/2016 3:32:00 AM.
Slide
3
The Autokon architecture
Was it worth it ?
YES!
¤ System integrity maintained through
major revisions
¤ System reliability maintained through
major revisions
¤ System is comprehensible to
users and maintainers
¤ Architecture spans decades of
development projects
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
5/29/2016 3:32:00 AM.
Slide
4
Exercise 1: What do WE mean by
System Architecture?
•
•
•
•
•
……………………………………….
……………………………………….
……………………………………….
……………………………………….
……………………………………….
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
5/29/2016 3:32:01 AM.
Slide
5
Highlights
• Why architecture is important & What it is
• Habitable Architectures created for people
– Enterprise models
– Personal information environments
– System models, the heavy part
• UML Collaboration, a powerful abstraction for
architectural topology
– Collaboration (role model) specify many instances
– CollaborationInstance depicting a concrete topology
• Patterns, a literary style for sharing experience
– Wrap Entity Beans with Session Beans
– Caterpillars Fate: Smooth transition from analysis to design
• Summary and Conclusion
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
5/29/2016 3:32:01 AM.
Slide
6
WHY ARCHITECTURE?
• Help create habitable systems
• Help create long-lived, robust systems
• i. e., aim for simplicity:
…simple systems are easy to master
…simple systems are easy to build - correctly
…simple systems are easy to maintain
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
5/29/2016 3:32:01 AM.
Slide
7
Theory X vs. Theory Y
(MacGregor)
Theory Y
Theory X:
•
Authoritarian
Dislike
work
leadership
• Are
• Lack ambition
Inspiring
willing
to work
leadership
• Are capable of selfcontrol
• Are irresponsible
Rigid,
Bored,
• Are
resistant to
controlling
passive
change
environment
workers
• Are
willing to Interested,
accept
Flexible,
responsibility
supportive
creative
environment
workers
• Prefer to be led rather • Are imaginative and
creative
than to lead
• Are capable of selfdirection
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
5/29/2016 3:32:01 AM.
Slide
9
Vision of Distribution
anno 1973
Mary’s
System
Kari’s
System
Architectural Design of Distributed Systems
Jonas’
System
Yngvar’s
System
Anton’s
System
© Trygve Reenskaug 2001
5/29/2016 3:32:02 AM. Slide
10
The Importance
of the User's Mental Model
• A good conceptual model allows us to predict the
effects of our actions.
• Without a good model we operate by rote, blindly.
• We do operations as we are told; we cannot fully
appreciate why, what effects to expect, or what to do
if things go wrong.
Design
model
USER'S
MODEL
USER
DESIGNER
SYSTEM
Donald A. Norman:
The Design of Everyday Things
Architectural Design of Distributed Systems
System
Image
© Trygve Reenskaug 2001
5/29/2016 3:32:02 AM. Slide
11
Make IT so simple that even a
programmer can understand IT
Edsger Dijkstra:
• Testing can only show the presence of bugs
• Testing can never show the absence of bugs
• so, the number of bugs in the system when you
deliver it is proportional to the number of bugs
found during testing
• The only way to avoid bugs
is not to put them in in the first place
• I.E., Keep It Simple, Stupid (KISS)
60.000 bugs removed from Windows2000 during testing
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
5/29/2016 3:32:03 AM. Slide
12
Architectural styles
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
5/29/2016 3:32:03 AM. Slide
13
Architecture Example
First Priority: Make it Habitable!
Second Priority: Make it Buildable!
Third Priority: Make it Cost Effective!
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
5/29/2016 3:32:03 AM. Slide
14
RATIONAL's Definition of Architecture
"Principles of Architecting Software Systems"
• Software architecture encompasses
the set of significant decisions
about the organization of a software system
– Selection of the structural elements and their interfaces
– Behavior as specified in collaborations among those
elements
– Composition of these structural and behavioral
elements into larger subsystems
– Architectural style that guides this organization
• Software architecture also involves
– Functionality, Usability, Resilience, Performance,
Reuse, Comprehensibility
– Economic and technology constraints and tradeoffs
– Aesthetic concerns
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
5/29/2016 3:32:03 AM. Slide
15
Highlights
• Why architecture is important & What it is
• Habitable Architectures created for people
– Enterprise models
– Personal information environments
– System models, the heavy part
• UML Collaboration, a powerful abstraction for
architectural topology
– Collaboration (role model) specify many instances
– CollaborationInstance depicting a concrete topology
• Patterns, a literary style for sharing experience
– Wrap Entity Beans with Session Beans
– Caterpillars Fate: Smooth transition from analysis to design
• Summary and Conclusion
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
5/29/2016 3:32:04 AM. Slide
16
Personal, Integrated
Information Environments
Enterprise level
Work processes
UML Object Model
Personal level
User's mental model
UML Collaboration
System level
Design models
All of UML
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
5/29/2016 3:32:04 AM. Slide
17
Enterprise level
Example:Travel Expense
Enterprise level
Work processes
UML Object Model
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
5/29/2016 3:32:05 AM. Slide
18
Two Approaches
to Object Orientation
"East Coast Approach":
Object orientation is a smart programming artifact.
An object is an instance of a class.
Simula; Master complexity;
Classification Theory
"West Coast Approach":
Object Orientation is a powerful modeling paradigm.
An object encapsulates state and behavior so that it can
collaborate with other objects.
Smalltalk; Personal Information Systems;
Computer Augmentation + Lisp + Simula (+ Operating Systems)
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
5/29/2016 3:32:05 AM. Slide
19
UML Instance Interaction Diagram
Travel Expense Model
Ruth
(President)
4: authorizedExpenseReport
Eve
Douglas
Adam
(Software Manager)
(Marketing manager)
(Chief Accountant)
1: travelPermissionRequest
2: travelPermission
Joyce
Joe
Elsie
(Sales clerk)
(Paymaster)
(Programmer)
3: expenseReport
Bill
(Bookkeeper)
Peter
(Technical author)
Bill
(Dispatcher)
5: paymentRequest
John
(Cashier)
Architectural Design of Distributed Systems
Kim
(Methodologist)
© Trygve Reenskaug 2001
Ann
(Customer consultant)
5/29/2016 3:32:06 AM. Slide
20
UML Collaboration Diagram
Travel Expense Model
Ruth
(President)
Adam
(Chief Accountant)
Eve
(Software Manager)
/ Authorizer
Douglas
(Marketing manager)
Joe
(Paymaster)
/ Paymaster
Elsie
(Programmer)
Joyce
(Sales clerk)
Bill
(Bookkeeper)
/ BookKeeper
Peter
(Technical author)
Bill
(Dispatcher)
John
(Cashier)
Kim
(Methodologist)
Architectural Design of Distributed Systems
/ Traveler
Ann
(Customer consultant)
Objects --> ClassifierRoles
© Trygve Reenskaug 2001
5/29/2016 3:32:07 AM. Slide
21
Behavior: Action-Object Flow Diagram
Travel Expense Model
/ Traveler
/ Authorizer
/ BookKeeper
/ Paymaster
Who
<Plan trip>
<Buy tickets>
Travel perm.
request
Travel
permission
Action
<Travel>
<Write exp.
Report>
A Swimlane What
for each
Object or When
ClassifierRole
<Decide>
Expense
Report
<Check OK>
<Authorize>
Data Object
Authorized
Expense
Report
<Check>
<Bookkeeping>
Payment
Request
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
<Pay out>
5/29/2016 3:32:08 AM. Slide
22
Pipes and Filters:
Travel Expense Model
/ Traveler
/ Authorizer
/ BookKeeper
/ Paymaster
Who
<Plan trip>
<Buy tickets>
TravelRecord
[request]
What
<Decide>
Data Object
changes state
over time
TravelRecord
[permission]
When
<Travel>
<Write exp.
Report>
TravelRecord
[report]
<Check OK>
<Authorize>
TravelRecord
[authorized]
<Check>
<Bookkeeping>
TravelRecord
[pay]
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
<Pay out>
5/29/2016 3:32:09 AM. Slide
23
Personal Information Environment
Personal level
User's mental model
UML Collaboration
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
5/29/2016 3:32:09 AM. Slide
24
Task: Decide permission
Travel Expense Model
/ Traveler
<Plan trip>
<Buy tickets>
/ Authorizer
Travel perm.
request
/ BookKeeper
/ Paymaster
<Decide>
Travel
permission
<Travel>
<Write exp.
Report>
Expense
Report
<Check OK>
<Authorize>
Authorized
Expense
Report
<Check>
<Bookkeeping>
Payment
Request
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
<Pay out>
5/29/2016 3:32:10 AM. Slide
25
Travel Permission Decision Tool
Travel Expense System
Traveler
Peter
Period
week 11
Planned cost
USD 2000.-
Purpose Attend TOOLS Europe 2001
Current plan for Peter
Budget + commitments
activity 1
activity 2
activity 3
week
Item
Budget Committed
Travel 10,000
4,000
10 11 12 13 14 15
Permit
Architectural Design of Distributed Systems
Reject
© Trygve Reenskaug 2001
5/29/2016 3:32:11 AM. Slide
26
Travel Permission Decision Tool
Required Topology
Traveler
Peter
Period
week 11
Planned cost
USD 2000./ Planning
Service
Purpose Attend TOOLS Europe 2001
/Current
Authorizer
plan for Peter
activity 1
activity 2
activity 3
week
/ Travel
/ DecisionTool
Service
Budget + commitments
Item
Budget Committed
Travel 10,000
10 11 12 13 14 15
Permit
Architectural Design of Distributed Systems
Reject
© Trygve Reenskaug 2001
4,000
/ Accounting
Service
5/29/2016 3:32:15 AM. Slide
27
Architecting Distributed Systems
System level
Design models
All of UML
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
5/29/2016 3:32:15 AM. Slide
28
Highlights
• Why architecture is important & What it is
• Habitable Architectures created for people
– Enterprise models
– Personal information environments
– System models, the heavy part
• UML Collaboration, a powerful abstraction for
architectural topology
– Collaboration (role model) specify many instances
– CollaborationInstance depicting a concrete topology
• Patterns, a literary style for sharing experience
– Wrap Entity Beans with Session Beans
– Caterpillars Fate: Smooth transition from analysis to design
• Summary and Conclusion
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
5/29/2016 3:32:16 AM. Slide
29
Enterprise
Production Planning & Control
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
5/29/2016 3:32:17 AM. Slide
30
UML Use Case Notation
Demo Example
ActivityNetworkDemo
UC 1: Generate test networks
User (Me)
UC 2: Frontload
UC 3: Allocate resource
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
5/29/2016 3:32:19 AM. Slide
31
Use Case 2: Frontloading
UML Instance Interaction Diagram
fL(t) =
Project
public void
frontLoad (int time )
0
--20
Activity-B
4:fL(10)
7
(4)
10
14
(3)
16
Activity-F
Activity-C
Activity-E
18
(2)
19
7
(7)
13
14
(4)
17
Activity-A
1
(6)
6
Activity-D
Architectural Design of Distributed Systems
6:fL(13)
© Trygve Reenskaug 2001
5/29/2016 3:32:19 AM. Slide
32
The UML Collaboration
and the ClassifierRole
/ RoleName
2: mess2
1: mess1
A collaboration describes how an operation, like a use case, is
realized by a set of classifiers and associations used in a
specific way. The collaboration defines a set of roles to be
played by instances, as well as a set of interactions that define
the communication between the instances when they play the
roles.
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
5/29/2016 3:32:20 AM. Slide
33
The essence of frontloading
Collaboration with Interaction
/ Predecessor
/ Activity
fL(t1)
*
*
/ Successor
fL(t2)
*
*
"In an instance of a collaboration, each
ClassifierRole maps onto at most one object.”
A many-relation (*) means that
the role represents a typical member of the set
All other members behave correspondingly
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
5/29/2016 3:32:20 AM. Slide
34
Interfaces in the
Basic scheduling collaboration
The interfaces specify minimal requirements
to receiving classes
/ Predecessor
fL(t1)
/ Activity
fL(t2)
/ Successor
«Interface»
FrontloadIntf
frontLoad(time)
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
5/29/2016 3:32:20 AM. Slide
35
Interface Definitions
Java
public interface FrontloadIntf {
public void frontLoad (int t);
}
/ Predecessor
fL(t1)
/ Activity
fL(t2)
/ Successor
«Interface»
FrontloadIntf
frontLoad(time)
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
5/29/2016 3:32:21 AM. Slide
36
The UML Class
playing a role in a Collaboration
:ClassName
2: mess2
1: mess1
An Instance of a given class
playing the specified role at run time
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
5/29/2016 3:32:21 AM. Slide
37
Assign classes to roles
(Optional)
/ Predecessor
:Activity, :Project
fL(t1)
/ Activity
: Activity
fL(t2)
/ Successor
:Activity, :Project
«Interface»
FrontloadIntf
frontLoad(time)
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
5/29/2016 3:32:22 AM. Slide
38
Class Definitions
Java
public class Activity
implements FrontloadIntf {
private FrontloadIntf[] successors;
… … …
/ Predecessor
/ Activity
fL(t1)
public
frontload
(int t)fL(t2)
{…}
: Activity,
Project void
: Activity
… … …
}
/ Successor
: Activity, Project
public class Project
implements FrontloadIntf{
private FrontloadIntf[] startActivities;
… … …
«Interface»
«Interface»
public
void frontload (int t) FrontloadIntf
{…}
BackloadIntf
… … …
backload(time)
frontLoad(time)
}
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
5/29/2016 3:32:22 AM. Slide
39
Highlights
• Why architecture is important & What it is
• Habitable Architectures created for people
– Enterprise models
– Personal information environments
– System models, the heavy part
• UML Collaboration, a powerful abstraction for
architectural topology
– Collaboration (role model) specify many instances
– CollaborationInstance depicting a concrete topology
• Patterns, a literary style for sharing experience
– Wrap Entity Beans with Session Beans
– Caterpillars Fate: Smooth transition from analysis to design
• Summary and Conclusion
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
5/29/2016 3:32:22 AM. Slide
40
Separate Presentation and Business
Objects
WEB Browser
Button
ActivityGraph
paint();
Tool
BarChart
Project
activity-B
activity-D
activity-A
Activity-F
activity-C
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
activity-E
5/29/2016 3:32:22 AM. Slide
41
An Unrealistic
Implementation
class ActivityGraph extends Canvas {. . .
public void paint(Graphics g) {
. . . // paint frame etc.
Graphics ng = g.create(. . .);
tool.getProject().paintGraph(ng);
}
public class Project {. . .
public void paintGraph(Graphics g) {
// collect ranked activities
Activity[][] bucket = rankedActivities();
// Plot activities in each column.
for (int i=0; i < bucket.length; i++) {
for (int j=0; j < bucket[i].length; j++) {
bucket[i][j].paintSymbol(g, new Point (…), grid);
}
}
// draw connections . . .
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
5/29/2016 3:32:22 AM. Slide
42
Java RMI
Remote Method Invocation
WEB Browser
Button
ActivityGraph
Client
paint();
Server
Tool
BarChart
Project
activity-B
activity-D
activity-A
Activity-F
activity-C
activity-E
Exercise 3:
Suggest an implementation for this system
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
5/29/2016 3:32:23 AM. Slide
43
The UML Subsystem
playing a role in a Collaboration
2: mess2
1: mess1
SubsystemName
A subsystem is a grouping of model elements that represents a
behavioral unit in a physical system.
A subsystem offers interfaces and has operations.
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
5/29/2016 3:32:23 AM. Slide
44
High level Collaboration
with Subsystems
WEB Browser
Button
Tool
paint();
Applet
ActivityGraph
BarChart
Project
PlanningService
activity-B
activity-D
activity-A
Activity-F
activity-C
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
activity-E
5/29/2016 3:32:24 AM. Slide
45
The UML Component
playing a role in a Collaboration
1: mess1
ComponentName
2: mess2
A Component represents a modular, deployable, and
replaceable part of a system that encapsulates implementation
and exposes a set of interfaces.
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
5/29/2016 3:32:24 AM. Slide
46
High level Collaboration
with UML Components
WEB Browser
Button
paint();
Tool
Responsibility
Applet
ActivityGraph
BarChart
«Interface»
Project
?
Architectural Design of Distributed Systems
Project
PlanningService
Responsibility
activity-B
activity-D
activity-A
Activity-F
activity-C
© Trygve Reenskaug 2001
activity-E
5/29/2016 3:32:24 AM. Slide
47
Assign Components
to Physical Nodes
PC
Tool
Application Server
Planning
Service
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
5/29/2016 3:32:24 AM. Slide
48
Some UML Definitions
• A Collaboration describes how an operation, like a use case, is realized
by a set of classifiers and associations used in a specific way. The
collaboration defines a set of roles to be played by Instances, as well as
a set of interactions that define the communication between the
instances when they play the roles.
• The Instance is encapsulated. It has identity, interface and state.
• An instance of a given Class can play one or more roles at run time.
A ClassifierRole can be implemented by many ways.
• A Subsystem is a grouping of model elements that represents a
behavioral unit in a physical system. A subsystem offers interfaces and
has operations.
• A Component represents a modular, deployable, and replaceable part of
a system that encapsulates implementation and exposes a set of
interfaces.
• A Node is a run-time physical object that represents a computational
resource,
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
5/29/2016 3:32:25 AM. Slide
49
UML Diagrams
(Architecturally Significant)
# Build-time Diagrams (Code and Code Management)
* Class Diagrams
* Deployment Diagrams
* Component Diagrams
# Run-time Diagrams
* Use Case Diagrams
* Collaboration Diagrams
(Objects, ClassifierRoles, Subsystems, Components)
* Interaction & Sequence Diagrams
* Object Diagrams
* Statechart Diagrams
* Activity Diagrams / Action-Object Flow Diagrams
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
5/29/2016 3:32:25 AM. Slide
50
Highlights
• Why architecture is important & What it is
• Habitable Architectures created for people
– Enterprise models
– Personal information environments
– System models, the heavy part
• UML Collaboration, a powerful abstraction for
architectural topology
– Collaboration (role model) specify many instances
– CollaborationInstance depicting a concrete topology
• Patterns, a literary style for sharing experience
– Wrap Entity Beans with Session Beans
– Caterpillars Fate: Smooth transition from analysis to design
• Summary and Conclusion
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
5/29/2016 3:32:25 AM. Slide
51
Design Patterns
ChristopherAlexander, Architect:
Each pattern describes a problem that occurs over and
over again in our environment and then describes the
core of the solution to that problem in such a way that
you can use this solution a million times over without
ever doing it the same way twice.
Jim Coplien and Doug Schmidt, Software Engineers:
• A clear statement of a problem and its context.
• Offering a concrete solution addressing the problem
• A clear statement of the forces that motivate the solution.
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
5/29/2016 3:32:25 AM. Slide
52
Highlights
• Why architecture is important & What it is
• Habitable Architectures created for people
– Enterprise models
– Personal information environments
– System models, the heavy part
• UML Collaboration, a powerful abstraction for
architectural topology
– Collaboration (role model) specify many instances
– CollaborationInstance depicting a concrete topology
• Patterns, a literary style for sharing experience
– Wrap Entity Beans with Session Beans
– Caterpillars Fate: Smooth transition from analysis to design
• Summary and Conclusion
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
5/29/2016 3:32:25 AM. Slide
53
Wrap Entity Beans with Session Beans-1
Ed Roman, TheServerside.com, August, 2000
"Artist's Impression"
S
JDBC
Business API
Business Logic
S
E
Architectural Design of Distributed Systems
E
Persistent Data
Data Logic
© Trygve Reenskaug 2001
5/29/2016 3:32:25 AM. Slide
54
A Real Example Application
Execution Architecture
Web
Browser
Data
Storage
Web
Server
UI
UIControl
«web
pages»
«JavaServer
Page»
1
Data
base
1
Application
Server
1
Activity
Task
«Stateful
SessionBean»
«Stateless
SessionBean»
*
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
Mapper
1
«EntityBean»
5/29/2016 3:32:26 AM. Slide
55
Highlights
• Why architecture is important & What it is
• Habitable Architectures created for people
– Enterprise models
– Personal information environments
– System models, the heavy part
• UML Collaboration, a powerful abstraction for
architectural topology
– Collaboration (role model) specify many instances
– CollaborationInstance depicting a concrete topology
• Patterns, a literary style for sharing experience
– Wrap Entity Beans with Session Beans
– Caterpillars Fate: Smooth transition from analysis to design
• Summary and Conclusion
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
5/29/2016 3:32:26 AM. Slide
56
Caterpillar's Fate - 1
Norman Kerth, Coplien's book
2.
Synchronization
of Concurrent Threads
3.
1.
Concurrent
Collaborative
Work Packets
Threads of Execution
9.
Shape of Program
The main patterns
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
5/29/2016 3:32:26 AM. Slide
57
Highlights
• Why architecture is important & What it is
• Habitable Architectures created for people
– Enterprise models
– Personal information environments
– System models, the heavy part
• UML Collaboration, a powerful abstraction for
architectural topology
– Collaboration (role model) specify many instances
– CollaborationInstance depicting a concrete topology
• Patterns, a literary style for sharing experience
– Wrap Entity Beans with Session Beans
– Caterpillars Fate: Smooth transition from analysis to design
• Summary and Conclusion
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
5/29/2016 3:32:26 AM. Slide
58
Personal, Integrated
Information Environments
#
#
#
Habitable Systems
Theory X for inspiring organizations
Explicit Users' Mental Models
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
5/29/2016 3:32:26 AM. Slide
59
Control Components through their
Responsibilities and Interfaces
Tool
Responsibility
«Interface»
Project
?
Architectural Design of Distributed Systems
PlanningService
Responsibility
© Trygve Reenskaug 2001
5/29/2016 3:32:29 AM. Slide
60
Plan Behavior
Who - What - When
/ Traveler
/ Authorizer
<Plan trip>
TravelRecord
[request]
<Buy tickets>
TravelRecord
[permission]
/ BookKeeper
/ Paymaster
<Decide>
<Travel>
<Write exp.
Report>
TravelRecord
[report]
<Check OK>
<Authorize>
TravelRecord
[authorized]
<Check>
<Bookkeeping>
TravelRecord
[pay]
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
<Pay out>
5/29/2016 3:32:29 AM. Slide
61
Instruct implementors and maintainers
Objects
Collaboration links
Backplane
(Container)
Operating
System
Net
Hardware
Architectural Design of Distributed Systems
Thanks to Øystein Myhre for this illustration
© Trygve Reenskaug 2001
5/29/2016 3:32:29 AM. Slide
62
Questions ?
Comments ?
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
5/29/2016 3:32:30 AM. Slide
63
More details ….
• http://www.ifi.uio.no/~trygver
• trygve.reenskaug@ifi.uio.no
• Coplien, James O. and Douglas C. Schmidt, ed. Pattern Languages of Program Design, Addison-Wesley, 1995.
• Reenskaug, Wold, Lehne: Working With Objects. Manning/Prentice Hall 1996. ISBN 0-13-452930-8
The reference work. This book is out of print. A .pdf version kan be downloaded free from above website.
• Theory: Egil P. Andersen: Conceptual Modeling of Objects. A Role Modeling Approach. Dr Scient thesis. Dept. of
Informatics, University of Oslo. 4 November 1997.
The theory of role modeling
ftp://ftp.nr.no/pub/egil/ConceptualModelingOO.ps.gz
• Unified Modeling Language (UML). Object Management Group. UML Draft Specification v. 1.4. UML Draft
Specification v. 1.4. OMG DOC#: ad/01-02-13. http://cgi.omg.org/cgi-bin/doc?ad/01-02-13
• Donald A. Norman: "The Design of Everyday Things." Doubleday/Currency 1990. ISBN 0-385-26774-6.
• Douglas MacGregor: “Human Side of Enterprise : 25th Anniversary Printing” McGraw-Hill 1985; ISBN:
0070450986
• Alexander, Christopher, et al. A Pattern Language, Oxford University Press, New York, 1977.
• http://www.c2.com/cgi/wiki?WelcomeVisitors
• http://hillside.net/patterns/
• http://theserverside.com/patterns/
• http://www.c2.com/cgi/wiki?EjbRoadmap
• Frank Buschmann: Pattern-Oriented Software Architecture. Wiley 1996; ISBN: 0471958697
• IBM WebSphere: http://www.redbooks.ibm.com/abstracts/sg246161.html
© Trygve Reenskaug 2001
Architectural Design of Distributed Systems
5/29/2016 3:32:30 AM. Slide
64