© 1998 by Carnegie Mellon University Intro - page 1 Version 1.1 1 The Architecture Business Cycle...
-
Upload
maximillian-lang -
Category
Documents
-
view
213 -
download
0
Transcript of © 1998 by Carnegie Mellon University Intro - page 1 Version 1.1 1 The Architecture Business Cycle...
© 1998 by Carnegie Mellon University
Intro - page 1Version 1.1 1
The Architecture Business The Architecture Business CycleCyclePaul C. Clements
Software Engineering InstituteCarnegie Mellon UniversityPittsburgh, PA 15213-3890
Sponsored by the U.S. Department of Defense© 1998 by Carnegie Mellon University
Carnegie Mellon University
Software Engineering Institute
© 1998 by Carnegie Mellon University Intro - page 2Version 1.1
The Importance of Architecture
To a project• vehicle for stakeholder communication• key to achieving system qualities• basis for development project structure
To an organization• can be reused from project to project• forms a basis for product lines• is a foundation for new market entry
To a community• standard models emerge for mature domains• is a basis for component markets
© 1998 by Carnegie Mellon University Intro - page 3Version 1.1
Definition of Software Architecture
The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them.
© 1998 by Carnegie Mellon University Intro - page 4Version 1.1
Communication Vehicle
Architecture provides a common frame of reference in which competing interests may be exposed and negotiated. • negotiating requirements with users• keeping the customer informed of progress and
cost• implementing management decisions and
allocations
© 1998 by Carnegie Mellon University Intro - page 5Version 1.1
Result of Early Design Decisions -1An architecture defines constraints on an implementation.• implementations must conform to architecture• (global) resource allocation decisions constrain
implementations of individual components• system trade-offs are in the architectural realm
© 1998 by Carnegie Mellon University Intro - page 6Version 1.1
Result of Early Design Decisions -2The architecture dictates organizational structure for development/maintenance efforts. Examples include• division into teams• units for budgeting, planning• basis of work breakdown structure• organization for documentation• organization for CM libraries• basis of integration• basis of test plans, testing• basis of maintenance
Once decided, architecture is extremely hard to change!
© 1998 by Carnegie Mellon University Intro - page 7Version 1.1
Result of Early Design Decisions -3Architecture permits/precludes achievement of a system’s desired quality attributes. For example:
If you desire Examineperformance inter-component communicationmodifiability component responsibilitiessecurity inter-component communication,
specialized components (e. g., kernels)scalability localization of resourcesability to subset inter-component usagereusability inter-component coupling
The architecture influences qualities, but does not guarantee them.
© 1998 by Carnegie Mellon University Intro - page 8Version 1.1
Result of Early Design Decisions -4An architecture helps users reason about and manage change (about 80% of effort in systems occurs after deployment).
Architecture divides all changes into three classes.• local: modifying a single component• non-local: modifying several components• architectural: modifying the gross system topology,
communication, and coordination mechanisms
A good architecture is one in which the most likely changes are also the easiest to make.
© 1998 by Carnegie Mellon University Intro - page 9Version 1.1
Reusable Model
Less is more: It pays to restrict the vocabulary of design alternatives.
Architectural styles serve as that restricted vocabulary of design alternatives.
Working with known styles• reduces learning time• enhances communication• takes advantage of known style properties (e.g.,
performance, security, reliability)
© 1998 by Carnegie Mellon University Intro - page 10Version 1.1
Where do architectures come from?
Architectures are influenced by
• stakeholders of the system(s) being built
• technical and organizational factors
• architect’s background
© 1998 by Carnegie Mellon University Intro - page 11Version 1.1
Stakeholders
Customer: wants low cost, quick delivery, …
End user: wants functionality, usability, ...
Maintainer: wants modifiability, ...
Developer: wants understandability, simple interfaces, ...
Developing organization: amortizing infrastructure, employing personnel, low cost, ...
...
© 1998 by Carnegie Mellon University Intro - page 12Version 1.1
Stakeholders of a System
Marketingstakeholder
Behavior,performance,
security,reliability!
Low cost,keeping people
employed, leveraging existing corporate
assets!
Low cost, timelydelivery, not changed
very often!
Modifiability!Neat features,short time to market,low cost, parity withcompeting products!
Ohhhhh...Architect
Developmentorganization’smanagementstakeholder
End userstakeholder
Maintenanceorganizationstakeholder
Customerstakeholder
© 1998 by Carnegie Mellon University Intro - page 13Version 1.1
Technical Environment
Current trends: today’s information system will likely employ a• database management system• Web browser for delivery and distribution across
platformsThis was not true 10 years ago.
Available technology: decisions on using a centralized or decentralized system depend on processor cost and communication speed; both are changing quantities.
© 1998 by Carnegie Mellon University Intro - page 14Version 1.1
Architect’s Background
Architects develop their mindset from their past experiences. • Prior good experiences will lead to replication
of prior designs.• Prior bad experiences will be avoided in the
new design.
© 1998 by Carnegie Mellon University Intro - page 15Version 1.1
Summary: Influences on the Architect
Architect’s influences
Stakeholders
Developmentorganization
Technicalenvironment
Architect’sexperience
Requirements
Architecture
System
Architect(s)
© 1998 by Carnegie Mellon University Intro - page 16Version 1.1
Factors Influenced by Architectures
Structure of the development organization
Enterprise goals of the development organization
Customer requirements
Architect’s experience
Technical environment
The architecture itself
© 1998 by Carnegie Mellon University Intro - page 17Version 1.1
Architecture Influences the Development Organization StructureShort term: Work units are organized around architectural units for a particular system under construction.
Long term: When company constructs collection of similar systems, organizational units reflect common components • e.g., operating system unit or database unit• especially true in product line organization
© 1998 by Carnegie Mellon University Intro - page 18Version 1.1
Architecture Influences the Development Organization’s Enterprise GoalsDevelopment of a system may establish a foothold in the market niche.
Being known for developing particular kinds of systems becomes a marketing device.
Architecture becomes a leveraging point for additional market opportunities and networking.
© 1998 by Carnegie Mellon University Intro - page 19Version 1.1
Architecture Influences Customer Requirements
Knowledge of similar fielded systems leads customers to ask for particular features.
Customers will alter their requirements on the basis of the availability of existing systems.
© 1998 by Carnegie Mellon University Intro - page 20Version 1.1
Architecture Influences the Architect’s Experience and Technical Environment
Creation of a system affects the architect’s background.
Occasionally, a system or an architecture will affect the technical environment. • the WWW for information systems• the three-tier architecture for database systems
© 1998 by Carnegie Mellon University Intro - page 21Version 1.1
A Cycle of Influences
Architectures and organizations influence each other.• Influences to and from architectures form a
cycle.• An organization can manage this cycle to its
advantage.
© 1998 by Carnegie Mellon University Intro - page 22Version 1.1
Architecture Business Cycle (ABC)
Architect’s influences
Stakeholders
Developmentorganization
Technicalenvironment
Architect’sexperience
Requirements
Architecture
System
Architect(s)
© 1998 by Carnegie Mellon University Intro - page 23Version 1.1
Importance of the ABC
Recognizing architecture as a capital asset• develop it with care• develop it with more than one system in mind• keep it, nurture it, grow it, use it later
Looking for new business opportunities that architecture opens up
Planning and managing the feedback cycle
© 1998 by Carnegie Mellon University Intro - page 24Version 1.1
Example of ABC: Product Lines
Architecture enables entire suite of products to be built more efficiently
Case study: CelsiusTech AB of Sweden
© 1998 by Carnegie Mellon University Intro - page 25Version 1.1
ABC for CelsiusTech
Architect’s influencesCustomer and end userVarious navies
Developing organizationCelsiusTech
Technical environmentAdaObject orientationIterative development
Architect’s experienceReal-time embedded C3I
Requirements(Qualities)Fault toleranceTailorabilityAsset reuseTime to market
Architecture
SystemSS2000 products
Architect(s)
© 1998 by Carnegie Mellon University Intro - page 26Version 1.1
CelsiusTech’s Software ArchitectureTwo dominant styles• layered architecture to separate application-
specific software from software used across the entire product line
• blackboard style to decouple producers and consumers of data
Both styles promote modifiability and reusability.
© 1998 by Carnegie Mellon University Intro - page 27Version 1.1
Layered Architecture
General applications:100% Ada
Common applications:100% Ada
Fundamentals:95% Ada, 5% assembly language
Base system 2000:10% Ada, 90% C
Operator’s console
Targettracking
Firecontrol ASC ECM
Picture compilations
Common application
IPC
Fundamentals
Tacticalconfiguration Database Diagnostics Common
functions
LAN IPC
OS-2000
Base system architecture
© 1998 by Carnegie Mellon University Intro - page 28Version 1.1
Runtime Blackboard Architecture
Similar to A-7E data banker module
COOBData-providing
application HCI
Track information
Updates
RequestsRequests
Updates
Track-ball updates
© 1998 by Carnegie Mellon University Intro - page 29Version 1.1
Current Members of Product FamilySold 55 variants in SS2000 product family• Swedish Goteborg class Coastal Corvettes (KKV) (380
tons)• Danish SF300 class multi-role patrol vessels
(300 tons)• Finnish Rauma class Fast Attack Craft (FAC)
(200 tons)• Australian/New Zealand ANZAC frigates (3225 tons)• Danish Thetis class Ocean Patrol vessels (2700 tons)• Swedish Gotland class A19 submarines (1330 tons)• Pakistani Type 21 class frigates• Republic of Oman patrol vessels• Danish Niels Juel class corvettes
© 1998 by Carnegie Mellon University Intro - page 30Version 1.1
Result of Changes:Shrinking, Predictable Schedules
1986 1988 1990 1992 1994 1996
A
B
C
D
E
F
G
Ships
© 1998 by Carnegie Mellon University Intro - page 31Version 1.1
Result of Changes: Lower Staffing
200
180
160
140
120
100
80
60
40
20
01986 1987 1988 1989 1990 1991 1992 1993 1994 1995 1996
© 1998 by Carnegie Mellon University Intro - page 32Version 1.1
Result of Changes: Reuse
Ships
Num
ber
of S
yste
m M
odul
es
Unique application
National application
Modified
Reusable application
Common (verbatim)
140
120
100
80
60
40
20
0A B C D E
© 1998 by Carnegie Mellon University Intro - page 33Version 1.1
ABC Feedback Loop
CelsiusTech is now exploring other domains in which their architecture and product line approach offers promise.
Air defense sector: Surprise! 40% of brand new system could be lifted verbatim from SS2000.
© 1998 by Carnegie Mellon University Intro - page 34Version 1.1
How is architecture-based development different?The architecture-specific aspects of system creation include:• forming an organizational structure that
supports/reflects architecture • architecture design process
- using reference models and domain models - using patterns and styles- building skeletal system, incremental
development• architecture evaluation• checking for conformance
© 1998 by Carnegie Mellon University Intro - page 35Version 1.1
Can We Evaluate an Architecture?Yes. Since architecture• is the key to system qualities• involves decisions relevant to achieving those
qualities• is not a random process
it follows that we can evaluate architectural decisions for their effect on qualities.
Analyzing for system qualities early in the life cycle allows for a comparison of architectural options.
© 1998 by Carnegie Mellon University Intro - page 36Version 1.1
Why evaluate an architecture?
All design involves tradeoffs. Not all tradeoffs are optimal (or anywhere near). Architecture is the earliest artifact where trade-offs are visible.
A evaluation ensures that:• the right questions are asked . . . early• tradeoff points are explicitly identified
Since architecture has such a profound effect on the success/failure of a project, evaluating an architecture is cheap risk insurance.
© 1998 by Carnegie Mellon University Intro - page 37Version 1.1
Cost of architecture evaluations AT&T • 300 full-scale reviews done on projects of 700
staff-days or longer• average cost per review: 70 staff days
Rational Software• 30 reviews done on projects gteq 500 KSLOC each • average cost per review: $50,000
SEI SAAM evaluations• ~15 reviews done on projects ranging from 100
KSLOC to 1,000 KSLOC• average cost per review: 14 to 20 staff-days• average length of review: 2 days
© 1998 by Carnegie Mellon University Intro - page 38Version 1.1
Example of Indirect Staff Costs
Using senior designers for evaluations instead of designing
Loss of productivity (due to reassignment of superior designers)
Time spent training staff in review techniques
© 1998 by Carnegie Mellon University Intro - page 39Version 1.1
Benefits of Architectural ReviewsFive different types of benefits result from holding architectural reviews.1. financial2. forces preparation for review3. early detection of problems4. validation of requirements5. improved architectures
© 1998 by Carnegie Mellon University Intro - page 40Version 1.1
Financial Benefits of Reviews
AT&T estimated that each reviewed project saves 10% of total cost as a result of the review. Thus, a 70-staff-day review of projects of 700 staff-days pays for itself.
Consultants who perform architecture evaluations report 80% repeat business.
© 1998 by Carnegie Mellon University Intro - page 41Version 1.1
Forces Preparation for Review
Documentation/specifications must be provided, hence they must exist or be created.
Some reviews use standard questions, and the architect can prepare ahead to ensure that the architecture scores well.
Reviews make the criteria for evaluation explicit by prioritizing requirements or quality goals.
© 1998 by Carnegie Mellon University Intro - page 42Version 1.1
Early Detection of Problems
The problems that can be found by an architectural level inspection include• unreasonable requirements• performance problems• problems associated with potential future
modifications
The earlier in the life cycle that problems are found, the easier it is to fix them.
© 1998 by Carnegie Mellon University Intro - page 43Version 1.1
Validation of Requirements
Reviews put stakeholders in the same room with each other, often for the first time.• uncovers conflicts and tradeoffs• provides a forum for negotiated resolution of
problems
It often results in the generation of new requirements or the clarification of existing requirements.
© 1998 by Carnegie Mellon University Intro - page 44Version 1.1
Improved Architectures
Development organizations anticipate types of questions raised at reviews and• design architectures with questions in mind• prepare documentation of the type needed at
review• give explicit consideration to qualities to be
reviewed
© 1998 by Carnegie Mellon University Intro - page 45Version 1.1
Review Techniques
There are a variety of techniques for performing architectural reviews; each has a different cost and provides different information.
These techniques fall into one of two basic categories.1. questioning techniques: applied to evaluate
any aspect of an architecture for any given reason
2. measuring techniques: applied to answer questions about a specific quality
© 1998 by Carnegie Mellon University Intro - page 46Version 1.1
Architecture Tradeoff Analysis Method (ATAM)
ATAM is an architecture evaluation method that focuses on multiple quality attributes. In doing so, it:• illuminates points in the architecture where
quality attribute sensitivities & tradeoffs occur• generates a framework for ongoing quantitative
analysis
© 1998 by Carnegie Mellon University Intro - page 47Version 1.1
ATAM and Risks
The point of an ATAM analysis is not to provide precise analyses . . . the point is to discover areas of high potential risk in the architecture.
We want to find trends: correlations between architectural parameters and measurable properties.
These areas can then be made the focus of risk mitigation activities: e.g. further design, further analysis, prototyping.
© 1998 by Carnegie Mellon University Intro - page 48Version 1.1
ATAM Benefits
We have observed a number of benefits to performing ATAM analyses:• stakeholder buy-in and interaction• clarified requirements• improved architecture documentation• documented basis for architectural decisions
And, obviously, improved architectures.
© 1998 by Carnegie Mellon University Intro - page 49Version 1.1
Day 0 Day 1 Day 2
Scenario Elicitation
Architecture Elicitation & Mapping
Analysis
ATAM Steps
The ATAM takes 3 days to execute
Each day follows the same set of steps, but with different emphases:
© 1998 by Carnegie Mellon University Intro - page 50Version 1.1
Day 0: Information Exchange
Purpose: to elicit or refine architectural descriptions, to identify stakeholders, to develop scenarios and initial analyses.
Activities:• identify important quality attributes • document “seed” scenarios• identify stakeholders needed at evaluation• create initial representations of the architecture• define homework for the architect
Outcome: an analyzable architecture
© 1998 by Carnegie Mellon University Intro - page 51Version 1.1
Day 1: Skeleton Analyses
Purpose: to generate a baseline model that characterizes each quality attribute
Activities: [On a per attribute basis]• Elicit attribute-specific usage scenarios• Map important usage scenarios onto relevant
architectural views• Attribute annotation/Skeleton analysis building• Sensitivity point identification• Initial tradeoff point identification
Outcome: qualitative analyses of all important quality attributes
© 1998 by Carnegie Mellon University Intro - page 52Version 1.1
Attribute Analysis Taxonomies
Performance
Stimulus Architecture Parameters Response
Mode Source Frequency Regularity
regular overload Clock interrupt
e.g.,load balancing
e.g.,message arrival
e.g.,missile detected
Internalevent
Externalevent
Periodic Aperiodic
Sporadic Randomparams:period
params:min inter-arrival
interval
params:distribution
© 1998 by Carnegie Mellon University Intro - page 53Version 1.1
Attribute Analysis Taxonomies
Performance
Stimulus Architecture Parameters Response
Resource Resource Arbitration Resource Consumption
params:MIPS
CPU memory
networkdevices/sensors
params:bandwidth
params:MB
off-line on-line
cyclic executive fixed
prioritydynamicpriority
queuing policy preemption
policy
locking(non-preemptable)
shared(preemptable
queuing per processor
queue
one-to-one one-to-many
SJF fixed priority
deadline
FIFO
© 1998 by Carnegie Mellon University Intro - page 54Version 1.1
Attribute Analysis Taxonomies
Performance
Stimulus Architecture Parameters Response
Latency Throughput Precedence
Responsewindow
Best/avg/worst case
jitter
Criticality
Best/avg/worst case
variabilitywindow
Criticality
Criticality Ordering
Partial Total
© 1998 by Carnegie Mellon University Intro - page 55Version 1.1
Day 2: Finding Tradeoffs
Purpose: to identify growth areas via sensitivities and tradeoffs
Activities: • Attribute-specific growth scenario elicitation
and prioritization• Mapping of growth scenarios onto architecture• Sensitivity point identification• Tradeoff point identification
Outcome: potential sensitivity/tradeoff risk areas of the architecture identified
© 1998 by Carnegie Mellon University Intro - page 56Version 1.1
Experience to date - 1
SAAM• ~15 evaluations to date• supporting artifacts (process model, handbook,
tips and guidance, seed scenarios, artifact examples)
• good for functionality / modifiability investigations
• good for eliciting, prioritizing specific quality requirements
• good for eliciting architectural description
© 1998 by Carnegie Mellon University Intro - page 57Version 1.1
Experience to date - 2
ATAM• 4 evaluations so far, 6-10 more planned• precise method is still firming up• handbook being written• customer feels good value is given• good at non-run-time qualities plus run-time
qualities (SAAM is a procedural subset)
© 1998 by Carnegie Mellon University Intro - page 58Version 1.1
Conclusions
Architecture is a fundamental asset in software development.
Companies who manage it and let it work to their benefit are discovering pay-off.
Architecture-based development must be matured as a discipline.
A key aspect of architecture-based development is architecture evaluation.