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