Upload
swapnil-kulkarni
View
143
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Software Architecture
Citation preview
SOFTWARE ARCHITECTURE IN
PRACTICEPart Two:
Creating an Architecture
CHAPTER 7:
Designing the Architecture
1/18/2011
Designing the Architecture
• Architecture in the life cycle• Designing the architecture• Forming the team structure & its
relationship to the architecture• Creating a skeletal system
Evolutionary Delivery Life Cycle
Architectural Drivers
• Shaping requirements: functional, quality, & business requirements
• Find them by:o Identify the highest priority business goals (relatively
few).o Turn these into quality scenarios or use cases.o Choose the ones that will have the most impact on
the architecture.• These are the architectural drivers & should be < 10.
Attribute Driven Design
• An extension of other methods.• Bases the decomposition process on the quality
attributes.• Recursive decomposition:
o tactics & architectural patterns are chosen to satisfy a set of quality scenarios
o functionality is allocated to instantiate the module types
o results in course-grained architecture
ADD Steps
1. Identify an initial set of architectural drivers2. Choose the module to decompose (initially the entire
system)3. Refine the module:
1. Choose the specific architectural drivers2. Choose an architectural pattern that satisfies the drivers, based
on the appropriate tactics. Identify child modules to implement the tactics.
3. Instantiate modules & allocate functionality: draw multiple views.
ADD Steps, con’t
1. Define interfaces of the child modules. The decomposition provides modules & constraints on the types of module interactions. Document.
2. Verify & refine use cases & quality scenarios and make them constraints for the child modules. Verification & preparation for more decomposition or implementation.
3. Repeat C for every module that needs further decomposition.
Forming the team structure & its relationship to the architecture
• Once the first few levels of the architecture's module decomposition structure are fairly stable, those modules can be allocated to development teams
• The impact of an architecture on the development of organizational structure is clear.
• Once an architecture for the system under construction has been agreed on, teams are allocated to work on the major modules and a work breakdown structure is created that reflects those teams.
• Each team then creates its own internal work practices
1/18/2011
Creating a Skeletal System
• Provide an underlying capability to implement a system’s functionality in an effective order:o Implement execution & interaction.o Install the simplest of functions that instigates some
rote behavior. Result: a running system that sits & hums to itself.
o Choose functionality: most problematic; available staff; initial deliverable.
o Employ the uses structure to identify additional software to support chosen functionality.
Skeleton, (continued)
• Benefits:o At no point is the integration & test overwhelming; easy to find
incremental source of errors.o Budgets & schedules are more predictable with smaller
increments, providing management & marketing with more delivery options.
o 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.
Skeleton, (continued)
• Potential problem:o The first development team to complete a portion of
the system gets to define the interfaces for everyone.
o This might be too simple, and penalize the complex parts of the system.
o The effect would be to make they complex subsystems more complex.
• So, first negotiate the interfaces.
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.
CHAPTER 8:
Flight Simulation
1/18/2011
Flight Simulation• Among the most sophisticated software
systems:o Highly distributedo Hard real-time performance requirementso Modifiability: changes in requirements,
simulated vehicles & environment o Scalability: continuous improvement of the
simulation of the real world
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.
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.
Pattern: a Structural Model
• With the emphasis on:o Simplicity and similarity of system’s
substructureso Decoupling of data- and control-passing
strategies from computationo Minimizing module typeso A small number of system-wide coordination
strategieso Transparency of design
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.
Highlights
• Architectural solution: o reference model Fig 8.3
• Treatment of time:o Periodic Time Management (for real-time)o Event-based Time Management (non-RT)
• Skeletal System: Architecture Prototypeo Flight Simulator has 6 module types!o What are the benefits?
Integrability
• Both the data connections and the control connections have been minimized.o Integrating another controller has been
reduced to a problem that is linear, not exponential.
o Integrating two subsystems is again reduced to ensuring that the two pass data consistently.
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:o Architectural skeleton allows incremental
development and easier integration.o Every project that has used structural
modeling has reported easy, smooth integration.
CHAPTER 9:
Documenting Software Architectures
1/18/2011
Documenting Software Architectures
• Documenting the architecture is the crowning step to crafting it.
• Even a perfect architecture is useless if no one understands it or (perhaps worse) if key stakeholders misunderstand it.
• If you go to the trouble of creating a strong architecture, you must describe it in sufficient detail, without ambiguity, and organized in such a way that others can quickly find needed information.
• Otherwise, your effort will have been wasted because the architecture will be unusable.
1/18/2011
Uses of Architectural Documentation• Architecture documentation is both prescriptive and
descriptive.• It might mean producing different documents for
different stakeholders• One of the most fundamental rules for technical
documentation in general, and software architecture documentation in particular, is to write from the point of view of the reader.
1/18/2011
Views
• Perhaps the most important concept associated with software architecture documentation is the view.
• Recall that we defined a Software Architecture for a system as :- o "the structure or structures of the system, which comprise
elements, the externally visible properties of those elements, and the relationships among them."
• A View is a representation of a coherent set of architectural elements, as written by and read by system stakeholders.
• A Structure is the set of elements itself, as they exist in software or hardware.
1/18/2011
Views
• The basic principle of documenting software architecture:o Documenting an architecture is a matter of documenting the
relevant views and then adding documentation that applies to more than one View.
• The above basic principle is useful for:-o Choosing the relevant viewso Documenting a viewo Documenting information that applies to more than one view
1/18/2011
Choosing the Relevant Views
• A layered view will tell about system's portability. • A deployment view will reason about system's performance and
reliability.• A simple three-step procedure for choosing the views :-
o Produce a candidate view list. Begin by building a stakeholder/viewo Combine views. The candidate view list from step 1 is likely to yield an
impractically large number of views. To reduce the list to a manageable size, first look for views in the table that require only overview depth or that serve very few stakeholders
o Prioritize. Select an appropriate set of views to serve your stakeholder community.
1/18/2011
The seven parts of a documented view
1/18/2011
Documenting a View• There is no industry-standard template for
documenting a view, but the seven-part standard organization that has worked well in practice are :- 1. Primary presentation shows the elements and the
relationships among them that populate the view 2. Element catalog details at least those elements
and relations depicted in the primary presentation, and perhaps others. For example, a module decomposition view has
elements that are modules, relations that are a form of "is part of," and properties that define the responsibilities of each module. A process view has elements that are processes, relations
1/18/2011
Documenting a View 3. Context diagram shows how the system depicted in the view
relates to its environment in the vocabulary of the view. o For example, in a component-and-connector view you show
which component and connectors interact with external components and connectors, via which interfaces and protocols.
4. Variability guide shows how to exercise any variation points that are a part of the architecture shown in this view.o An example of variability is found in software product lines where
the product line architecture is suitable for multiple particular systems
5. Architecture background explains why the design reflected in the view came to be. The goal of this section is to explain to someone why the design is as it is and to provide a convincing argument that it is sound.
1/18/2011
Documenting a View
6. Glossary of terms used in the views, with a brief description of each.7. Other information. The precise contents of this section will vary according to the standard practices of the organization. It might include management information such as authorship, configuration control data, and change histories.
1/18/2011
DOCUMENTING BEHAVIOR
• Behavior can be documented either about an element or about an ensemble of elements working in concert. Exactly what to model will depend on the type of system being designed. o For example,
if it is a real-time embedded system, you will need to say a lot about timing properties and the time of events.
In a banking system, the sequence of events (e.g., atomic transactions and rollback procedures) is more important than the actual time of events being considered.
• Different modeling techniques and notations are used depending on the type of analysis to be performed.
• In UML, sequence diagrams and state charts are examples of behavioral descriptions. These notations are widely used.
1/18/2011
DOCUMENTING INTERFACES
• An interface is a boundary across which two independent entities meet and interact or communicate with each other.
• Documenting an interface consists of naming and identifying it and documenting its syntactic and semantic information
1/18/2011
The nine parts of interface documentation
1/18/2011
Documentation across Views
1/18/2011
Unified Modeling Language
• MODULE VIEWS
1/18/2011
UML
• Aggregation
1/18/2011
UML
• Dependency
1/18/2011
COMPONENT-AND-CONNECTOR VIEWS
1/18/2011
ALLOCATION VIEWS
1/18/2011
Summary
5:31 AM SEPS ZG651 Software Architectures
5:31 AM SEPS ZG651 Software Architectures