Software Architecture Session8 part 1

Software Architecture in Practice

Part Two:Creating an Architecture

Chapter 7:

Designing the Architecture

04/09/23 2

3

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

4

5

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.

6

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

7

ADD Steps

A. Identify an initial set of architectural driversB. Choose the module to decompose (initially

the entire system)C. 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.

8

ADD Steps, con’t

4. Define interfaces of the child modules. The decomposition provides modules & constraints on the types of module interactions. Document.

5. Verify & refine use cases & quality scenarios and make them constraints for the child modules. Verification & preparation for more decomposition or implementation.

D. 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

04/09/23 9

10

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.

11

Skeleton, (continued) 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.

12

Skeleton, (continued) 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.

13

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 9:

Documenting Software Architectures

04/09/23 23

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.

04/09/23 24

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.

04/09/23 25

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 :- "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.

04/09/23 26

Views The basic principle of documenting software

architecture: 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:- Choosing the relevant views Documenting a view Documenting information that applies to more than

one view

04/09/23 27

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 :-

Produce a candidate view list. Begin by building a stakeholder/view

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

Prioritize. Select an appropriate set of views to serve your stakeholder community.

04/09/23 28

The seven parts of a documented view

04/09/23 29

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 view2. 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

04/09/23 30

Documenting a View3. Context diagram shows how the system depicted in the view

relates to its environment in the vocabulary of the view. 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. 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.

04/09/23 31

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.

04/09/23 32

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.

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.

04/09/23 33

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

04/09/23 34

The nine parts of interface documentation

04/09/23 35

Documentation across Views

04/09/23 36

Unified Modeling Language MODULE VIEWS

04/09/23 37

UML Aggregation

04/09/23 38

UML Dependency

04/09/23 39

COMPONENT-AND-CONNECTOR VIEWS

04/09/23 40

ALLOCATION VIEWS

04/09/23 41

Thank You

04/09/23 42