null  null
Software Architecture
and the UML
Grady Booch
Architecting a dog house
Can be built by one person
Requires
Minimal modeling
Simple process
Simple tools
2
Architecting a house
Built most efficiently and timely by a team
Requires
Modeling
Well-defined process
Power tools
3
Architecting a high rise
4
Early architecture
Progress
- Limited knowledge of theory
5
Modern architecture
Progress
- Advances in materials
- Advances in analysis
Scale
- 5 times the span of the Pantheon
- 3 times the height of Cheops
6
Modeling a house
7
Movements in civil architecture
Bronze age/Egyptian (Imhotep)
Grecian/Roman (Vitruvius)
Byzantine/Romanesque
Progress
- Imitation of previous efforts
- Learning from failure
- Integration of other forces
- Experimentation
Gothic
Mannerism (Michelangelo, Palladio)
Baroque
Engineering/Rational/National/Romantic
Art noveau
Modern movement (Wright, LeCorbusier)
8
Kinds of civil architecture
Neufert Architect’s Data
The Handbook of Building Types
Community
- houses, flats and apartments, gardens,
education, hospitals, religion
Commerce
- shops and stores, restaurants, hotels, office
buildings, banks, airports
Industry
- industrial buildings, laboratories, farm buildings
Leisure
- sport, theaters and cinemas, museums
9
Forces in civil architecture
Load
Compression
Kinds of loads
Tension
- Dead loads
- Live loads
- Dynamic loads
Avoiding failure
- Safety factors
- Redundancy
- Equilibrium
Load
Any time you depart from established practice, make ten times the
effort, ten times the investigation. Especially on a very large project.
- LeMessuier
10
Brand, How Buildings Learn
Shearing layers of change
Space plan
Services
Stuff
Structure
Skin
Site
11
Walker Royce
Dimensions of software complexity
Higher technical complexity
- Embedded, real-time, distributed, fault-tolerant
- Custom, unprecedented, architecture reengineering
- High performance
An average software project:
- 5-10 people
- 10-15 month duration
- 3-5 external interfaces
- Some unknowns & risks
Lower
management
complexity
- Small scale
- Informal
- Single stakeholder
- “Products”
Telecom
Switch
Commercial
Embedded Compiler
Automotive
Software
CASE Tool
Small Scientific
Simulation
IS Application
Distributed Objects
(Order Entry)
Defense
Weapon System
National Air Traffic
Control System
Large-Scale
Organization/Entity
Simulation
Enterprise IS
(Family of IS
Applications)
Defense
MIS System
IS Application
GUI/RDB
(Order Entry)
Business
Spreadsheet
Lower technical complexity
- Mostly 4GL, or component-based
- Application reengineering
- Interactive performance
12
Higher
management
complexity
- Large scale
- Contractual
- Many stake holders
- “Projects”
Forces in Software
Functionality
Cost
Compatibility
Capacity
Fail safe
Availability
Fault tolerance
Performance
Throughput
Technology churn
Resilience
The challenge over the next 20 years will not be speed or cost or performance;
it will be a question of complexity.
Bill Raduchel, Chief Strategy Officer, Sun Microsystems
Our enemy is complexity, and it’s our goal to kill it.
Jan Baan
13
Wojtek Kozaczynski
The domain of architecting
The “why”
The “what”
Architecture
Qualities
Architecture
Constrain
Architecture
Representation
The “who”
System
Features
Satisfies
S/W
Requirements
System
Quality Attributes
Technology
Produces
Defines
The “how”
Follows
Architect
Process
Skills
Defines role
Stakeholders
14
Organization
Philippe Kruchten
We all know that ...
Architecture and design are the same thing
Architecture and infrastructure are the same thing
<my favorite technology> is the architecture
A good architecture is the work of a single architect
Architecture is flat, one blueprint is enough
Architecture is just structure
System architecture precedes software architecture
Architecture cannot be measured and validated
Architecture is a Science
Architecture is an Art
15
Architecture defined (again)
Merriam Webster’s Collegiate Dictionary
10th edition
Architecture n (1555) 1: the art of science of
building, specifically, the art or practice of
designing and building structures and esp.
habitable ones 2 a: formation or
construction as or as if as the result of
conscious act <the ~ of the garden> b: a
unifying or coherent form or structure <the
novel lacks ~>
16
Architecture defined (yet again)
Mary Shaw, CMU
Grady Booch,
Philippe Kruchten,
Rich Reitman
Kurt Bittner, Rational
Software architecture encompasses the set
of significant decisions about the
organization of a software system
- selection of the structural elements and their
interfaces by which a system is composed
- behavior as specified in collaborations among
those elements
- composition of these structural and behavioral
elements into larger subsystem
- architectural style that guides this organization
17
Architecture defined (continued)
Software architecture also involves
-
usage
functionality
performance
resilience
reuse
comprehensibility
economic and technology constraints and
tradeoffs
- aesthetic concerns
18
Mary Shaw, CMU
Grady Booch,
Philippe Kruchten,
Rich Reitman
Kurt Bittner, Rational
Mary Shaw, CMU
Architectural style
An architecture style defines a family of
systems in terms of a pattern of structural
organization.
An architectural style defines
- a vocabulary of components and connector
types
- a set of constraints on how they can be
combined
- one or more semantic models that specify how
a system’s overall properties can be
determined from the properties of its parts
19
Architecture metamodel
Software
Architecture
Software
Architects
is part
of
are actors in
System
architecture
is represented by
Architecture
Design Process
produces
Software
Architecture
Description
has
Logical view
Process
view
is made of
relates to
is a
Architecture
Style guide
Architectural
view
has
Architectural style
Deployment
view
is made of
has
is a
Implementation view
Use case
view
constrains
Form
Connection
Architectural
Pattern
Component
depicts
Constraints
satisfies
constrains
Requirements
20
Architectural
Blueprint
Models
Models are the language of designer, in
many disciplines
Models are representations of the system
to-be-built or as-built
Models are vehicle for communications
with various stakeholders
Visual models, blueprints
Scale
Models allow reasoning about some
characteristic of the real system
21
Many stakeholders, many views
Architecture is many things to many different
interested parties
-
end-user
customer
project manager
system engineer
developer
architect
maintainer
other developers
Multidimensional reality
Multiple stakeholders
multiple views, multiple blueprints
22
Architectural view
An architectural view is a simplified
description (an abstraction) of a system
from a particular perspective or vantage
point, covering particular concerns, and
omitting entities that are not relevant to this
perspective
23
Architecturally significant elements
Not all design is architecture
Main “business” classes
Important mechanisms
Processors and processes
Layers and subsystems
Architectural views = slices through models
24
Characteristics of a Good Architecture
Resilient
Simple
Approachable
Clear separation of concerns
Balanced distribution of responsibilities
Balances economic and technology
constraints
25
Representing System Architecture
Logical View
Implementation View
End-user
Functionality
Programmers
Software management
Use Case View
Process View
Deployment View
System integrators
Performance
Scalability
Throughput
System engineering
System topology
Delivery, installation
Communication
Conceptual
Physical
26
Relation Between Views
Logical view
Component view
α
Process view
β
Deployment view
27
How many views?
Simplified models to fit the context
Not all systems require all views:
- Single processor: drop deployment view
- Single process: drop process view
- Very Small program: drop implementation view
Adding views:
- Data view, security view
28
The Value of the UML
Is an open standard
Supports the entire software development
lifecycle
Supports diverse applications areas
Is based on experience and needs of the
user community
Supported by many tools
29
Creating the UML
UML 1.3
OMG Acceptance, Nov 1997
UML 1.1
Final submission to OMG, Sep ‘97
public
feedback
First submission to OMG, Jan ´97
UML 1.0
UML partners
UML 0.9
Web - June ´96
OOPSLA ´95
Other methods
Unified Method 0.8
Booch method
OMT
30
OOSE
UML Partners
Rational Software Corporation
Hewlett-Packard
I-Logix
IBM
ICON Computing
Intellicorp
MCI Systemhouse
Microsoft
ObjecTime
Oracle
Platinum Technology
Taskon
Texas Instruments/Sterling Software
Unisys
31
Contributions to the UML
Harel
Meyer
Before and after
conditions
Gamma, et al
Statecharts
Frameworks and patterns,
HP Fusion
Booch
Operation descriptions and
message numbering
Booch method
Embley
Rumbaugh
Singleton classes and
high-level view
OMT
Jacobson
Wirfs-Brock
OOSE
Responsibilities
Odell
Shlaer - Mellor
Classification
Object lifecycles
32
Overview of the UML
The UML is a language for
-
visualizing
specifying
constructing
documenting
the artifacts of a software-intensive system
33
Overview of the UML
Modeling elements
Relationships
Extensibility Mechanisms
Diagrams
34
Modeling Elements
Structural elements
- class, interface, collaboration, use case,
active class, component, node
Behavioral elements
- interaction, state machine
Grouping elements
- package, subsystem
Other elements
- note
35
Relationships
Dependency
Association
Generalization
Realization
36
Extensibility Mechanisms
Stereotype
Tagged value
Constraint
37
Models, Views, and Diagrams
A model is a complete
description of a system
from a particular
perspective
Use Case
Use Case
Diagrams
Sequence
Diagrams
Diagrams
Scenario
Scenario
Diagrams
Collaboration
Diagrams
Diagrams
Scenario
Scenario
Diagrams
Statechart
Diagrams
Diagrams
State
State
Diagrams
Class
Diagrams
Diagrams
Use Case
Use Case
Diagrams
Use Case
Diagrams
Diagrams
State
State
Diagrams
Object
Diagrams
Diagrams
State
State
Diagrams
Component
Diagrams
Diagrams
Models
Component
Component
Diagrams
Deployment
Diagrams
Activity
Diagrams
38
Diagrams
Diagrams
A diagram is a view into a model
- Presented from the aspect of a particular
stakeholder
- Provides a partial representation of the system
- Is semantically consistent with other views
In the UML, there are nine standard
diagrams
- Static views: use case, class, object,
component, deployment
- Dynamic views: sequence, collaboration,
statechart, activity
39
Use Case Diagram
Captures system functionality as seen by
users
40
Use Case Diagram
Captures system functionality as seen by
users
Built in early stages of development
Purpose
-
Specify the context of a system
Capture the requirements of a system
Validate a system’s architecture
Drive implementation and generate test cases
Developed by analysts and domain experts
41
Class Diagram
Captures the vocabulary of a system
42
Class Diagram
Captures the vocabulary of a system
Built and refined throughout development
Purpose
- Name and model concepts in the system
- Specify collaborations
- Specify logical database schemas
Developed by analysts, designers, and
implementers
43
Object Diagram
Captures instances and links
44
Object Diagram
Shows instances and links
Built during analysis and design
Purpose
- Illustrate data/object structures
- Specify snapshots
Developed by analysts, designers, and
implementers
45
Component Diagram
Captures the physical structure of the
implementation
46
Component Diagram
Captures the physical structure of the
implementation
Built as part of architectural specification
Purpose
- Organize source code
- Construct an executable release
- Specify a physical database
Developed by architects and programmers
47
Deployment Diagram
Captures the topology of a system’s
hardware
48
Deployment Diagram
Captures the topology of a system’s
hardware
Built as part of architectural specification
Purpose
- Specify the distribution of components
- Identify performance bottlenecks
Developed by architects, networking
engineers, and system engineers
49
Sequence Diagram
Captures dynamic behavior (time-oriented)
50
Sequence Diagram
Captures dynamic behavior (time-oriented)
Purpose
- Model flow of control
- Illustrate typical scenarios
51
Collaboration Diagram
Captures dynamic behavior (messageoriented)
52
Collaboration Diagram
Captures dynamic behavior (messageoriented)
Purpose
- Model flow of control
- Illustrate coordination of object structure and
control
53
Statechart Diagram
Captures dynamic behavior (eventoriented)
54
Statechart Diagram
Captures dynamic behavior (eventoriented)
Purpose
- Model object lifecycle
- Model reactive objects (user interfaces,
devices, etc.)
55
Activity Diagram
Captures dynamic behavior (activity-oriented)
56
Activity Diagram
Captures dynamic behavior (activity-oriented)
Purpose
- Model business workflows
- Model operations
57
Architecture and the UML
Design View
Classes, interfaces,
collaborations
Implementation View
Components
Use cases
Use Case View
Process View
Deployment View
Active classes
Nodes
Organization
Package, subsystem
Dynamics
Interaction
State machine
58
Software engineering process
A set of partially ordered steps intended to
reach a goal. In software engineering the
goal is to build a software product or to
enhance an existing one.
Architectural process
- Sequence of activities that lead to the
production of architectural artifacts:
A software architecture description
An architectural prototype
59
Rational Unified Process
Iterative
Architecture-centric
Use-case driven
Risk confronting
60
Focus over time
Discovery
Invention
Focus
61
Implementation
Key concepts
When does
architecture happen?
Phase, Iterations
Process Workflows
What does
happen?
- Activity, steps
Artifacts
What is
produced?
- models
- reports, documents
Who does
it?
Worker: Architect
62
Lifecycle Phases
Inception
Elaboration
Construction
Transition
time
Inception
Define the scope of the project and
develop business case
Elaboration
Plan project, specify features, and
baseline the architecture
Construction
Transition
Build the product
Transition the product to its users
63
Major Milestones
Inception
Elaboration
Construction
Transition
time
Vision
Baseline
Architecture
Initial
Capability
64
Product
Release
Phases and Iterations
Inception
Prelim
Iteration
Elaboration
...
Arch
Iteration
Release
Release
...
Construction
Dev
Iteration
Release
Dev
Iteration
Release
Release
Transition
...
Trans
Iteration
Release
...
Release
An iteration is a sequence of activities with an established plan and
evaluation criteria, resulting in an executable release
65
Release
Architecture-Centric
Models are vehicles for visualizing, specifying,
constructing, and documenting architecture
The Unified Process prescribes the
successive refinement of an executable
architecture
Inception
Elaboration
Construction
time
Architecture
66
Transition
Unified Process structure
Phases
Process Workflows
Inception Elaboration
Construction
Transition
Business Modeling
Requirements
Analysis & Design
Implementation
Test
Deployment
Supporting Workflows
Configuration Mgmt
Management
Environment
Preliminary
Iteration(s)
Iter.
#1
Iter.
#2
Iter.
#n
Iter. Iter.
#n+1 #n+2
Iterations
67
Iter.
#m
Iter.
#m+1
Architecture and Iterations
Use case
Model
Design
Model
Implementation
Model
Content
68
Deployment
Model
Test
Model
Architectural design
Identify, select, and validate
“architecturally significant” elements
Not everything is architecture
-
Main “business” classes
Important mechanisms
Processors and processes
Layers and subsystems
Interfaces
Produce a Software Architecture Documen
69
Architectural design workflow
Use case view
Select scenarios: criticality and risk
Identify main classes and their
responsibility
Logical view
Distribute behavior on classes
Structure in subsystems, layers,
define interfaces
Implementation view
Define distribution and concurrency
Implement architectural prototype
Derive tests from use cases
Evaluate architecture
Iterate
70
Deployment view
Process view
Sources of architecture
Method
Method
Theft
Theft
Intuition
Classical system
Intuition
Unprecedented system
71
Patterns
A pattern is a solution to a problem in a
context
A pattern codifies specific knowledge
collected from experience in a domain
All well-structured systems are full of
patterns
- Idioms
- Design patterns
- Architectural patterns
72
daVinci
Mechanisms
Screws
• Brakes
Keys
• Pipes
Rivets
• Valves
Bearings
• Springs
Pins, axles, shafts
• Cranks and rods
Couplings
• Cams
Ropes, belts, and chains
• Pulleys
Friction wheels
• Engaging gears
Toothed wheels
Flywheels
Levers and connecting rods
Click wheels and gears
Ratchets
73
Design Patterns
Gamma et al
Design patterns
Creational patterns
- Abstract factory
- Prototype
Structural patterns
- Adapter
- Bridge
- Proxy
Behavioral patterns
- Chain of responsibility
- Mediator
- Visitor
Mechanisms are the soul of an architecture
74
Modeling a design pattern
75
Modeling a design pattern (cont.)
76
Modeling a design pattern (cont.)
77
Architectural patterns
Distributed
•
Layered
Event-driven
•
MVC
Frame-based
•
IR-centric
Batch
•
Subsumption
Pipes and filters
•
Disposable
Repository-centric
Blackboard
Interpreter
Rule-based
78
Software Architecture
Shaw and Garlan
Buschmann et al
A System of Patterns
Buschman et al
Booch
Complex business system
Real-Life Object-oriented Systems
Soren Lauesen
Custom er
nam e : S tring
A ddres s : S tring
S ales
Order
pro duc t : P rod uct
date : Date
GUI layer
s ave()
S erviceA gent
Observer
purchase(c ustom er, product, item s )
upd ate()
M iddle lay er
Custo m er
nam e : S tr ing
A ddr es s : S tring
s ave()
get Nam e()
updateNam e()
P roduc t
O rder L ine
na me : S tring
pr ice : C urren cy
item s : P roduct
get Na me()
updateNam e()
Custom er
ge tNam e()
up dateNam e()
Order Line
*
P roduct
*
79
S QL Databas e
Logical application architecture
Graphical
User
Interface
Relational
Database
Graphical
User
Interface
Business
Object
Model
Relational
Database
80
Graphical
User
Interface
Business
Object
Model
Relational
Database
Physical application architecture
Thinner client, thicker server
Client B
Client A
Client C
Application
Application
WWW Browser
DCOM
CORBA Beans
ADO/R
Business Object
Services
Business Object
Engine
COM
Business
Object Server MTS
Beans
ETS
Web
HTML
Server CGI
ASP
Java
Business Object
Services
Business Object
Services
Business Object
Engine
Business Object
Engine
Relational Database Server(s)
81
The Second Wave
Paul Dreyfus, Netscape
Complex Internet system
Client
Dynamic HTML, JavaScript, Java
plug-ins, source code enhancements
Java, C, C++, JavaScript, CGI
Server
Application
Server
Fulfillment
System
Financial
System
Inventory
System
82
Java, C, C++, JavaBeans, CORBA, DCOM
RDBMS
Server
Native languages
Who are the architects?
Experience
- software development
- domain
Pro-active, goal oriented
Leadership, authority
Architecture team
- balance
83
Architect
Not just a top level designer
Need to ensure feasibility
Not the project manager
But “joined at the hip”
Not a technology expert
Purpose of the system, “fit”,
Not a lone scientist
Communicator
84
Software architecture team charter
Defining the architecture of the software
Maintaining the architectural integrity of the
software
Assessing technical risks related to the
software design
Proposing the order and contents of the
successive iterations
Consulting services
Assisting marketing for future product
definition
Facilitating communications between
project teams
85
Architecture is making decisions
The life of a software architect is a long
(and sometimes painful) succession of
suboptimal decisions made partly in the
dark.
86
Futures
ADL: Architecture Description Languages
- UML, UniCon, LILEAnna, P++, LEAP, Wright,
µRapid
Standardization of concepts
- IEEE Working Group on Architecture
- INCOSE Working Group on System
Architecture
Systematic capture of architectural patterns
87
References (Architecture)
Len Bass, Paul Clements & Rick Kazman, Software Architecture in
Practice, Addison-Wesley, 1998.
Frank Buschmann, Régine Meunier, Hans Rohnert, Peter Sommerlad,
and Michael Stahl, Pattern-Oriented Software Architecture - A
System of Patterns, Wiley and Sons, 1996.
Christine Hofmeister, Robert Nord, Dilip Soni, Applied Software
Architecture, Addison-Wesley 1999.
Eric Gamma, John Vlissides, Richard Helm, Ralph Johnson, Design
Patterns, Addison-Wesley 1995.
Philippe Kruchten, “The 4+1 View Model of Architecture,” IEEE
Software, 12 (6), November 1995, IEEE.
-
http://www.rational.com/support/techpapers/ieee/
Eberhardt Rechtin, Systems Architecting: Creating and Building
Complex Systems, Englewood Cliffs NJ, Prentice-Hall, 1991.
88
References (Architecture)
Eberhardt Rechtin & Mark Maier, The Art of System
Architecting, CRC Press, 1997.
Recommended Practice for Architectural Description, Draft 2.0 of
IEEE P1471, May 1998
-
http://www.pithecanthropus.com/~awg/
Mary Shaw, and David Garlan, Software Architecture—
Perspectives on an Emerging Discipline, Upper Saddle River,
NJ, Prentice-Hall, 1996.
Bernard I. Witt, F. Terry Baker, and Everett W. Merritt, Software
Architecture and Design—Principles, Models, and Methods,
New York NY, Van Nostrand Reinhold, 1995.
The World-wide Institute of Software Architects
-
http://www.wwisa.org
89
References (UML)
Grady Booch, James Rumbaugh, Ivar Jacobson, The Unified
Modeling Language User Guide, Addison-Wesley, 1999.
90
References (Process)
Barry Boehm, “A spiral model of software development and
enhancement,” IEEE Computer, May 1998.
Barry Boehm, “Anchoring the software process,” IEEE
Software, July 1996.
Grady Booch, Object Solutions, Addison-Wesley, 1995.
Philippe Kruchten, “A Rational Development Process,”
CrossTalk, July 1996.
-
http://www.rational.com/support/techpapers/devprcs/
Philippe Kruchten, The Rational Unified Process - An
Introduction, Addison-Wesley, 1999.
Rational Unified Process 5.0, Rational, Cupertino, CA, 1998
Walker Royce, Software Project Management: a Unified
Framework, Addison-Wesley, 1998
The Software Program Manager’s Network
-
http://www.spmn.com
91
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement