Software Architecture in Practice
Part Two:
Creating an Architecture
2nd Ed.
Len Bass, Paul Clements, Rick Kazman
Chapter 7:
Designing the Architecture
• Architecture in the life cycle
• Designing the architecture
• Forming the team structure & its
relationship to the architecture
• Creating a skeletal system
2
Evolutionary Delivery Life Cycle
Figure 7.1
3
Architectural Drivers
• Shaping requirements: functional, quality, & business
requirements
• Find them by:
1 Identify the highest priority business goals (relatively few).
2 Turn these into quality scenarios or use cases.
3 Choose the ones that will have the most impact on the
architecture.
• These are the architectural drivers & should be < 10.
4
Attribute Driven Design
• An extension of other methods.
• Bases the decomposition process on the quality
attributes.
• Recursive decomposition:
– tactics & architectural patterns are chosen to satisfy a
set of quality scenarios
– functionality is allocated to instantiate the module types
– results in course-grained architecture
5
ADD Steps
A.
B.
C.
Identify an initial set of architectural drivers
Choose the module to decompose (initially the entire
system)
Refine the module:
1.
2.
3.
Choose the specific architectural drivers
Choose an architectural pattern that satisfies the drivers, based
on the appropriate tactics. Identify child modules to implement
the tactics.
Instantiate modules & allocate functionality: draw multiple
views.
6
ADD Steps, con’t
4.
5.
D.
Define interfaces of the child modules. The decomposition
provides modules & constraints on the types of module
interactions. Document.
Verify & refine use cases & quality scenarios and make them
constraints for the child modules. Verification & preparation for
more decomposition or implementation.
Repeat C for every module that needs further
decomposition.
7
Creating a Skeletal System
• Provide an underlying capability to implement a
system’s functionality in an effective order:
– Implement execution & interaction.
– Install the simplest of functions that instigates some
rote behavior.
• Result: a running system that sits & hums to itself.
– Choose functionality: most problematic; available staff;
initial deliverable.
– Employ the uses structure to identify additional
software to support chosen functionality.
8
Skeleton, con’t
• Benefits:
– At no point is the integration & test overwhelming;
easy to find incremental source of errors.
– Budgets & schedules are more predictable with smaller
increments, providing management & marketing with
more delivery options.
– Stubs adhere to the final version of interfaces:
• help with understanding & testing interactions
• producing hardcoded canned output or reading in output
• can generate synthetic load that aids early understanding of
performance, including interactions & bottlenecks.
9
Skeleton, con’t
• Potential problem:
– The first development team to complete a portion of the
system gets to define the interfaces for everyone.
– This might be too simple, and penalize the complex
parts of the system.
– The effect would be to make they complex subsystems
more complex.
• So, first negotiate the interfaces.
10
In Summary
• Architectural design must follow requirements
analysis, but should begin as soon as the
architectural drivers are determined.
• When a sufficient portion of the architecture has
been designed (but not completed), start building
a skeletal framework that is the basis of iterative
development.
11
Chapter 8:
Flight Simulation
• Among the most sophisticated software
systems:
– Highly distributed
– Hard real-time performance requirements
– Modifiability: changes in requirements,
simulated vehicles & environment
– Scalability: continuous improvement of the
simulation of the real world
12
Integrability
• A driving concern in large systems
• Those developed by distributed teams or
separate organizations
• Definition: the ease with which separately
developed elements, including COTS, can
be made to work together to fulfill the
system’s requirements.
13
Applicable Tactics
• Keep interfaces small, simple, and stable.
• Adhere to defined protocols.
• Loose coupling or minimal dependencies between
elements.
• Use a component framework.
• Use “versioned” interfaces that allow extensions
while permitting existing elements to work under
the original constraints.
14
Pattern: a Structural Model
• With the emphasis on:
– Simplicity and similarity of system’s
substructures
– Decoupling of data- and control-passing
strategies from computation
– Minimizing module types
– A small number of system-wide coordination
strategies
– Transparency of design
15
Details, p. 181
• The pattern includes an object-oriented
design to model the subsystems and
controller children of the air vehicle. It
marries real-time scheduling to this OOD as
a mean of controlling the execution order of
the simulation’s subsystems so that fidelity
can be guaranteed.
16
Highlights
• Architectural solution:
– reference model Fig 8.3
• Treatment of time:
– Periodic Time Management (for real-time)
– Event-based Time Management (non-RT)
• Skeletal System: Architecture Prototype
– Flight Simulator has 6 module types!
– What are the benefits?
17
Integrability
• Both the data connections and the control
connections have been minimized.
– Integrating another controller has been reduced
to a problem that is linear, not exponential.
– Integrating two subsystems is again reduced to
ensuring that the two pass data consistently.
18
Cost/Benefit Ratio
• The cost is that the subsystem controllers
often act purely as data conduits, increasing
complexity and performance overhead.
• In practice (for applicable) systems, the
benefits far outweigh the cost:
– Architectural skeleton allows incremental
development and easier integration.
– Every project that has used structural modeling
has reported easy, smooth integration.
19
Chapter 10:
Reconstructing Software Architectures
• What if you have software that has no architecture
documentation?
– Never recorded
– Recorded but lost
– Evolution didn’t include updating the documentation
• Finding the architecture hidden in an existing system
– Detailed analysis with tool support
– Hard, messy, and not always possible
20
Reconstruction Process
• Interpretive, interactive, and iterative, involving
many activities; it is not automatic!
• Needs skills of a reverse engineering expert and
the system’s expert
– Reconstruct from implementation elements
– Complier construction techniques & tools: grep, sed,
awk, perl, python, and lex/yacc, etc.
21
Actual Projects
•
•
•
•
•
•
•
•
MRI scanners
Public telephone switches
Helicopter guidance systems
Classified NASA systems
Physics simulation systems
Embedded control software for mining machinery
Satellite ground systems
A variety of automotive software
22
Workbench Approach
• No single tool or tool set is adequate
• Tools tend to be language specific
– EX: MRI scanner can have software in 15
languages
• Data extraction tools are imperfect
– Incomplete results or false positives
– Use tools to augment and check on each other
23
Reconstruction Activities
• Iteratively, do:
–
–
–
–
Information extraction - from various sources.
Database construction - into standard form.
View fusion – combine into coherent view.
Reconstruction – main work of building
abstractions and representations.
24
Information Flow among Activities
Figure 10.1
25
Information Extraction
• Analyzing existing design and implementation artifacts to
construct a model
• Blend of the ideal with the practical
– Ideal – what you want to discover
– Practical – what available tools can give you
• Static - looking at system artifacts
• Dynamic – looking at runtime behavior
– Multi-process and multi-processor systems with middleware such
as J2EE, Jini, or .NET, frequently build topology dynamically,
depending on availability of system resources
26
Remaining Steps
• Database construction & Guidelines
• View Fusion
– Improving the view
– Disambiguating function calls
– Guidelines
• Reconstruction
– Visualization and interaction
– Pattern definition and recognition
– Guidelines
27
Groupwork
•
•
•
•
Have you done any similar work?
What type of application?
Why was the effort important?
What were your results?
28