Architectural Design of Distributed Business Systems
TOOLS Europe 2001
Architectural Design
of
Distributed Business Systems
Tutorial M3.
TOOLS Europe 2001, 13 March 2001
Trygve Reenskaug
Mogul Norway, Oslo
© Trygve Reenskaug 2001
Page 1
Architectural Design of Distributed Business Systems
TOOLS Europe 2001
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
3/11/01 10:36 AM.
Slide
1
Slide
2
Slide
3
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
3/11/01 10:36 AM.
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
© Trygve Reenskaug 2001
3/11/01 10:36 AM.
Page 2
Architectural Design of Distributed Business Systems
TOOLS Europe 2001
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
3/11/01 10:36 AM.
Slide
4
Exercise 1: What do WE mean by
System Architecture?
•
•
•
•
•
……………………………………….
……………………………………….
……………………………………….
……………………………………….
……………………………………….
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
3/11/01 10:36 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
© Trygve Reenskaug 2001
3/11/01 10:36 AM.
Slide
6
Page 3
Architectural Design of Distributed Business Systems
TOOLS Europe 2001
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
3/11/01 10:36 AM.
© Trygve Reenskaug 2001
Slide
7
Slide
8
Slide
9
Theory X vs. Theory Y
(MacGregor)
Theory X:
Theory Y
• Dislike work
• Lack ambition
• Are irresponsible
• Are resistant to
change
• Prefer to be led
rather than to lead
Architectural Design of Distributed Systems
• Are willing to work
• Are capable of selfcontrol
• Are willing to accept
responsibility
• Are imaginative and
creative
• Are capable of selfdirection
3/11/01 10:36 AM.
© Trygve Reenskaug 2001
Theory X vs. Theory Y
(MacGregor)
Authoritarian
leadership
Rigid,
controlling
environment
Inspiring
leadership
Bored,
passive
workers
Architectural Design of Distributed Systems
Flexible,
supportive
environment
© Trygve Reenskaug 2001
© Trygve Reenskaug 2001
Interested,
creative
workers
3/11/01 10:36 AM.
Page 4
Architectural Design of Distributed Business Systems
TOOLS Europe 2001
Vision of Distribution
anno 1973
Mary’s
System
Yngvar’s
System
Jonas’
System
Kari’s
System
Anton’s
System
Architectural Design of Distributed Systems
3/11/01 10:36 AM.
© Trygve Reenskaug 2001
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
System
Image
Donald A. Norman:
The Design of Everyday Things
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
3/11/01 10:36 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
© Trygve Reenskaug 2001
3/11/01 10:36 AM.
Slide
12
Page 5
Architectural Design of Distributed Business Systems
TOOLS Europe 2001
Architecture for:
Chaos-Beauty-Flexibility?
Architectural styles
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
3/11/01 10:36 AM.
Slide
13
First: Architect describes end
result.
Second: Architect describes how to
build.
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
3/11/01 10:36 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
© Trygve Reenskaug 2001
3/11/01 10:36 AM.
Slide
15
Page 6
Architectural Design of Distributed Business Systems
TOOLS Europe 2001
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
3/11/01 10:36 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
3/11/01 10:36 AM.
Slide
17
Enterprise level
Example:Travel Expense
Enterprise level
Work processes
UML Object Model
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
© Trygve Reenskaug 2001
3/11/01 10:36 AM.
Slide
18
Page 7
Architectural Design of Distributed Business Systems
TOOLS Europe 2001
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
3/11/01 10:36 AM.
Slide
19
UML Instance Interaction Diagram
Travel Expense Model
Ruth
(President)
4: authorizedExpenseReport
Eve
Douglas
(Software Manager)
(Marketing manager)
1: travelPermissionRequest
2: travelPermission
Joyce
Joe
Elsie
(Sales clerk)
(Paymaster)
(Programmer)
3: expenseReport
Adam
(Chief Accountant)
Bill
(Bookkeeper)
Peter
(Technical author)
Bill
(Dispatcher)
5: paymentRequest
John
(Cashier)
Architectural Design of Distributed Systems
Kim
(Methodologist)
© Trygve Reenskaug 2001
Ann
(Customer consultant)
3/11/01 10:36 AM.
Slide
20
Travel Expense Model
Ruth
(President)
Eve
(Software Manager)
/ Authorizer
Douglas
(Marketing manager)
Elsie
(Programmer)
Joyce
(Sales clerk)
(Bookkeeper)
/ BookKeeper
Peter
(Technical author)
Bill
(Dispatcher)
John
(Cashier)
Kim
(Methodologist)
Joe
(Paymaster)
/ Paymaster
Bill
Architectural Design of Distributed Systems
/ Traveler
In the collaboration, we study
patterns of interacting objects:
What are the objects, what are their
responsibilities, and how do they
collaborate to achieve the system
functionality.
The classifierRole represents the
object’s position in the structure
and its responsibility for
performing its part of the system
function.
UML Collaboration Diagram
Adam
(Chief Accountant)
We achieve a separation of
concern; a collaboration describes
the objects involved in one or more
functions, describing the objects
involved only and focusing on the
relevant object properties.
Ann
(Customer consultant)
Objects --> ClassifierRoles
© Trygve Reenskaug 2001
© Trygve Reenskaug 2001
3/11/01 10:36 AM.
Slide
21
Page 8
Architectural Design of Distributed Business Systems
TOOLS Europe 2001
Behavior: Action-Object Flow Diagram
Travel Expense Model
/ Traveler
/ Authorizer
Travel perm.
request
<Plan trip>
/ BookKeeper
A Swimlane
for each
Object or
ClassifierRole
<Decide>
Travel
permission
<Buy tickets>
Who
What
When
Action
<Travel>
<Write exp.
Report>
/ Paymaster
Expense
Report
Data Object
<Check OK>
<Authorize>
Authorized
Expense
Report
<Check>
<Bookkeeping>
Payment
Request
Architectural Design of Distributed Systems
<Pay out>
3/11/01 10:36 AM.
© Trygve Reenskaug 2001
Slide
22
Pipes and Filters:
Travel Expense Model
/ Traveler
/ Authorizer
/ BookKeeper
/ Paymaster
Who
<Plan trip>
TravelRecord
[request]
<Buy tickets>
TravelRecord
[permission]
<Decide>
Data Object
changes state
over time
What
When
<Travel>
<Write exp.
Report>
TravelRecord
[report]
<Check OK>
<Authorize>
TravelRecord
[authorized]
<Check>
<Bookkeeping>
TravelRecord
[pay]
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
© Trygve Reenskaug 2001
<Pay out>
3/11/01 10:36 AM.
Slide
23
Page 9
Architectural Design of Distributed Business Systems
TOOLS Europe 2001
Personal Information Environment
Personal level
User's mental model
UML Collaboration
Architectural Design of Distributed Systems
3/11/01 10:36 AM.
© Trygve Reenskaug 2001
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
© Trygve Reenskaug 2001
<Pay out>
3/11/01 10:36 AM.
Slide
25
Page 10
Architectural Design of Distributed Business Systems
TOOLS Europe 2001
Travel Permission Decision Tool
Travel Expense System
Traveler
Period
Peter
Planned cost
week 11
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
3/11/01 10:36 AM.
© Trygve Reenskaug 2001
Slide
26
Travel Permission Decision Tool
Required Topology
Traveler
Peter
Period
Planned cost
USD 2000./ Planning
week 11
Service
Purpose Attend TOOLS Europe 2001
/Current
Authorizer
plan for Peter
Budget + commitments
activity 1
activity 2
activity 3
week
/ Travel
Service
/ DecisionTool
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
3/11/01 10:36 AM.
Slide
27
Architecting Distributed Systems
System level
Design models
All of UML
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
© Trygve Reenskaug 2001
3/11/01 10:36 AM.
Slide
28
Page 11
Architectural Design of Distributed Business Systems
TOOLS Europe 2001
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
3/11/01 10:36 AM.
Slide
29
The (toy) sample user interface is a
Java Applet that is run from a web
browser. The interface interacts
with a background service that is
also written in Java.
Enterprise
Production Planning & Control
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
3/11/01 10:36 AM.
The top bars in the bar chart shows
the earliest times when the
activities can be performed. The
bottom bars show when the
activities all have to be done by the
same resource, and this resource
can only serve one activity at the
time.
Slide
30
Slide
31
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
© Trygve Reenskaug 2001
3/11/01 10:36 AM.
Page 12
Architectural Design of Distributed Business Systems
TOOLS Europe 2001
Use Case 2: Frontloading
UML Instance Interaction Diagram
fL(t) =
Project
public void
frontLoad (int time )
9:
fL
(1
)
(6
fL
3:
Activity-C
7
(7)
13
7:
fL
(1
6)
14
(3)
16
Activity-E
Activity-F
7)
L(1
8:f
14
(4)
17
6:fL(13)
Architectural Design of Distributed Systems
9)
Activity-D
4:fL(10)
7
(4)
10
)
(6
fL
2:
Activity-A
1
(6)
6
Activity-B
5:f
L(1
3)
1
)
(0
:fL
0
--20
3/11/01 10:36 AM.
© Trygve Reenskaug 2001
18
(2)
19
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
3/11/01 10:36 AM.
© Trygve Reenskaug 2001
Slide
33
What are the objects, what are their
responsibilities, and how do their
collaborate to achieve the system
functionality.
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
© Trygve Reenskaug 2001
3/11/01 10:36 AM.
Slide
34
Page 13
Architectural Design of Distributed Business Systems
TOOLS Europe 2001
Interfaces in the
Basic scheduling collaboration
The interfaces specify minimal requirements
to receiving classes
/ Predecessor
/ Activity
fL(t1)
/ Successor
fL(t2)
«Interface»
FrontloadIntf
frontLoad(time)
Architectural Design of Distributed Systems
3/11/01 10:36 AM.
© Trygve Reenskaug 2001
Slide
35
Interface Definitions
Java
public interface FrontloadIntf {
public void frontLoad (int t);
}
/ Predecessor
/ Activity
fL(t1)
fL(t2)
/ Successor
«Interface»
FrontloadIntf
frontLoad(time)
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
3/11/01 10:36 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
© Trygve Reenskaug 2001
3/11/01 10:36 AM.
Slide
37
Page 14
Architectural Design of Distributed Business Systems
TOOLS Europe 2001
Assign classes to roles
(Optional)
/ Predecessor
:Activity, :Project
/ Activity
: Activity
fL(t1)
/ Successor
:Activity, :Project
fL(t2)
«Interface»
FrontloadIntf
frontLoad(time)
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
3/11/01 10:36 AM.
Slide
38
Slide
39
Class Definitions
Java
public class Activity
implements FrontloadIntf {
private FrontloadIntf[] successors;
… … …
public void frontload (int t) {…}
… … …
}
public class Project
implements FrontloadIntf{
private FrontloadIntf[] startActivities;
… … …
public void frontload (int t) {…}
… … …
}
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
3/11/01 10:36 AM.
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
© Trygve Reenskaug 2001
3/11/01 10:36 AM.
Slide
40
Page 15
Architectural Design of Distributed Business Systems
TOOLS Europe 2001
Separate Presentation and Business
Objects
WEB Browser
paint();
Button
Tool
ActivityGraph
BarChart
Project
activity-B
activity-D
activity-C
activity-E
activity-A
Architectural Design of Distributed Systems
Activity-F
3/11/01 10:36 AM.
© Trygve Reenskaug 2001
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
3/11/01 10:36 AM.
Slide
42
Java RMI
Remote Method Invocation
WEB Browser
Button
ActivityGraph
BarChart
Client
paint();
s
Bu
Tool
Server
n
io
Project
at
m
or
f
In
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
© Trygve Reenskaug 2001
3/11/01 10:36 AM.
Slide
43
Page 16
Architectural Design of Distributed Business Systems
TOOLS Europe 2001
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
3/11/01 10:36 AM.
Slide
44
High level Collaboration
with Subsystems
The Subsystem hides detail to
simplify the drawing, but is neither
visible at compile time nor at run
time.
Tool
Responsibility
PlanningService
Responsibility
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
3/11/01 10:37 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
© Trygve Reenskaug 2001
3/11/01 10:37 AM.
Slide
46
Page 17
Architectural Design of Distributed Business Systems
TOOLS Europe 2001
High level Collaboration
with UML Components
The Component simplifies the
system. It supports separate
compilation and deployment; the
separation is visible at run time.
Tool
Responsibility
«Interface»
Project
PlanningService
Responsibility
?
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
3/11/01 10:37 AM.
Slide
47
The Node is a container of
components. In itself, it does not
offer operations to its environment,
so it cannot be a classifierRole.
Assign Components
to Physical Nodes
PC
Tool
Application Server
Planning
Service
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
3/11/01 10:37 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
© Trygve Reenskaug 2001
3/11/01 10:37 AM.
Slide
49
Page 18
Architectural Design of Distributed Business Systems
TOOLS Europe 2001
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
3/11/01 10:37 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
3/11/01 10:37 AM.
Slide
51
A pattern tells you how to solve a
problem.
Design Patterns
A framework solves the problem
for you.
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
© Trygve Reenskaug 2001
3/11/01 10:37 AM.
Slide
52
Page 19
Architectural Design of Distributed Business Systems
TOOLS Europe 2001
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
3/11/01 10:37 AM.
© Trygve Reenskaug 2001
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
Persistent Data
Data Logic
E
Architectural Design of Distributed Systems
3/11/01 10:37 AM.
© Trygve Reenskaug 2001
Slide
54
Slide
55
A Real Example Application
Execution Architecture
Web
Browser
Data
Storage
Web
Server
UI
«web
pages»
1
UIControl
«JavaServer
Page»
Data
base
1
Application
Server
1
Activity
Task
«Stateful
SessionBean»
«Stateless
SessionBean»
*
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
© Trygve Reenskaug 2001
Mapper
1
«EntityBean»
3/11/01 10:37 AM.
Page 20
Architectural Design of Distributed Business Systems
TOOLS Europe 2001
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
3/11/01 10:37 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
3/11/01 10:37 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
© Trygve Reenskaug 2001
3/11/01 10:37 AM.
Slide
58
Page 21
Architectural Design of Distributed Business Systems
TOOLS Europe 2001
Personal, Integrated
Information Environments
#
#
#
Habitable Systems
Theory X for inspiring organizations
Explicit Users' Mental Models
Architectural Design of Distributed Systems
3/11/01 10:37 AM.
© Trygve Reenskaug 2001
Slide
59
Control Components through their
Responsibilities and Interfaces
Tool
Responsibility
«Interface»
Project
PlanningService
Responsibility
?
Architectural Design of Distributed Systems
3/11/01 10:37 AM.
© Trygve Reenskaug 2001
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
© Trygve Reenskaug 2001
<Pay out>
3/11/01 10:37 AM.
Slide
61
Page 22
Architectural Design of Distributed Business Systems
TOOLS Europe 2001
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
3/11/01 10:37 AM.
Slide
62
Questions ?
Comments ?
Architectural Design of Distributed Systems
© Trygve Reenskaug 2001
3/11/01 10:37 AM.
Slide
63
THE END
© Trygve Reenskaug 2001
Page 23
Architectural Design of Distributed Business Systems
TOOLS Europe 2001
More details
•
•
•
http://www.ifi.uio.no/~trygver
•
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-38526774-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.
trygve.reenskaug@ifi.uio.no
Coplien, James O. and Douglas C. Schmidt, ed. Pattern Languages of Program Design, AddisonWesley, 1995.
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
Page 24