Software Architecture: Foundations, Theory, and Practice Chapter 2

Architectures in Context: The Reorientation of Software Engineering

Chapter 2 Summary
In this chapter the role of software architecture in the

major activities of software engineering will be explored, including application conception, design, implementation, and analysis An architecture-centric perspective on development will be presented

The Reorientation of Software Engineering

The power of architecture demands a primacy of

place in development which alters the character of key software engineering activities An architecture-centric approach means the technical approaches taken during various software development activities are changed

Fundamental Understandings
Architecture: the set of principal design decisions

made about a system Three fundamental understandings of architecture:

1. 2. 3.

Every application has an architecture Every application has at least one architect Architecture is NOT a phase of development

Some questions:
But where did the architecture come from? How can it be characterized? What are its properties? Is it a good architecture?

Fundamental Understandings
Every application has an architect An architect is the person, or group, who: 1. makes the principal decisions about the

application 2. establishes and maintains the foundational design

Fundamental Understandings
Architecture is not a phase of development It refers to the conceptual essence of an application, including: Principal decisions regarding its design Key abstractions that characterize the application While the creation and maintenance of the

architecture may begin or have prominence in a phase, activities related to architecture encompass the entire development process
A systems architecture should result from a

conscious, deliberate activity by the architects

6

Requirements
In an architecture-centric approach, notions of

structure, design and solutions are appropriate during the requirements analysis activities Initial phase of software development process models is focused on developing requirements for an application Requirements are the statement of what the application should do Traditional view: requirements analysis is completely separated from any consideration of the design that may be used
7

Requirements
Mathematician George Polyas approach to isolating

requirements as stated in How to Solve It First, understand the problem Second, find the connection between the data and the unknown, and obtain a plan of the solution Third, carry out the plan Fourth, examine the solution obtained

Requirements
In practice, substantive requirements documents are

seldom produced before development Reasons that requirements analysis may be done quickly and superficially:
Schedule and budget pressures Inferior processes Denigration of the engineers qualification and training

Specifying requirements independently of any

concern for how those requirements might be met is difficult It is difficult to reason in abstract terms It is also difficult to assess practicality, schedules or cost this way

Requirements
Looking at what is done in other systems evokes

requirements In current practice, reasoning about structure and solution happens along with requirements analysis Successful new ventures are begun on the basis of a potential solution

10

Requirements
Existing designs and architectures provide ideas

about what might be done in a new system Our understanding of what works now and how it works affects our wants and perceived needs The insights from our experience with existing systems helps us imagine what might work This also enables us to assess how long we must be willing to wait for it and how much we need to pay for it

11

Requirements
Analysis of requirements and consideration of design

are pursued at the same time New development activity begins with:
knowledge of what exists now how the existing systems fail or fail to provide all that is

desired knowledge of what about those systems can or cannot be changed

Current architecture drives the requirements Requirements can be thought of as articulation of

improvements needed to existing architectures

12

Requirements
Developers should be concerned with having their

vision limited by current designs In situations where an adequate predecessor is unknown caution must be exercised in drawing any architectural notions from predecessors Greenfield development: development for which there is no immediate architectural predecessor
Should first extensively search for existing architectures that

might provide a basis for framing the new requirements and solution

Not all architectures deserve to be used in future

systems
13

Design
Designing is the activity that creates a systems

software architecture Designing decisions span issues that arise throughout the development process The traditional design phase is when particular emphasis is placed on architectural concerns as well as when the architecture is developed Designing must be seen as an aspect of many other development activities Architecture decisions are of many different kinds, requiring many different design techniques
14

Design
Most often design decisions are concerned with a

systems structure primary components and how they are connected With an architectural-centric approach to development, phase boundaries are diminished or eliminated Architecture decisions are made throughout the process of development

15

Design
Design techniques are needed to deal with: Stakeholder issues Over arching style and structure The type of connectors for composing subelements Package and primary class structure

Distributed and decentralized system concerns

Deployment issues Security and other nonfunctional properties Post-implementation issues

16

Design Techniques
Object Oriented Design (OOD) Object Oriented Programming is the reduction of an

algorithm to machine-executable form OOD identifies objects, encapsulations of state with functions for assessing and manipulating that state OOD is not a complete approach to developing an architecture and is not effective in all situations It does not address stakeholder concerns, deployment issues, security and trust, or use of commercial components

17

Design Techniques
Limitations of OOD It views all applications as consisting of one software species (an object), regardless of purpose It provides only one kind of encapsulation (the object), one notion of interface, one type of explicit connector (procedure call) no real notion of structure no notion of required interfaces It is so closely related to programming language concerns and choices that OOD tends to obscure the design issues A typical OOD approach assumes a shared address space and adequate support for heap-and-stack management

18

Design Techniques
Positive aspects of OOD UML notation used in OOD is above the

programming language level UML has some simple notions of architecture Extensive work in patterns Enables carry-forward of knowledge and experience from previous work into new applications

19

Design Techniques
Domain-Specific Software Architectures (DSSAs) Extends the idea of patterns to a broad, application-

encompassing level Appropriate when prior experience and prior architectures are able to strongly influence new projects Captures and characterizes the best solutions and best practices from past projects within a domain The production of new applications can focus more or less exclusively on points of novel variation

20

Design Techniques
To successfully follow the DSSA approach, good

technical support is required

Previous architectures must be captured and refined for reuse Points of allowable variation must be identified and isolated Interfaces between the points of variation and the core

architecture must be made explicit The dependencies between multiple points of variation must be identified

DSSA creates a standard way of describing products

and systems within the domain of interest

21

Implementation
Implementation activity creates machine-executable

source code that is faithful to the architecture and that fully develops all outstanding details of the application Implementation may add to or modify the architecture If key design decisions are made while working with source code they are part of the architecture There is no presumption that architecture is completed before implementation begins There may be iteration and revision of architecture as code is developed

22

Implementation
Implementation should be consistent with the

architecture All structural elements found in the architecture are implemented in the source code All source code corresponds to parts of the explicit architecture The source code must not: Utilize major new computational elements that have no corresponding elements in architecture Contain new connections between elements of the architecture that are not found in the architecture
23

Implementation
Further issues may come into notion of faithfulness

between implementation and the architecture Examples: Examining a candidate mathematics library may reveal it provides 98% of the functionality required by the architecture, for a low price, and at a high quality level Analyzing the consequence of the missing 2% of functionality may lead designers to conclude it will be acceptable under most usage situations

24

Implementation Strategies
Techniques are available to assist in faithful

development of the implementation from the design, including: Generation technologies Frameworks and middleware Reuse Choosing a technique is largely determined by availability Reuse base techniques reduce implementation time and produce higher quality products than programming the entire implementation from scratch
25

Implementation Strategies
Generative technologies automatically generate the

implementation They ensure complete consistency between the architecture and the implementation
Using them is also easy and straightforward and ensures quality

For narrow application domains, intelligence can be encoded in a

tool
a formal specification of the architecture can be the input to the tool the tool will generate a complete program to perform the functions as

specified
Example is a parser generator
Given the specification of the syntax of a programming language, it

will generate a program capable of recognizing programs written in the language specified by the grammar
26

Implementation Strategies
No human labor needs to be spent on programming

with the use of generative technologies This approach has limitations it is only applicable in limited situations where the domain is so thoroughly understood and bounded that generation is feasible

27

Implementation Strategies
An architecture-implementation framework is a piece of

software that acts as a bridge between a particular architectural style and a set of implementation technologies It provides key elements of the architecture style in code Frameworks may be extensive or very basic, depending on how much code must be added by hand Developers only need to add code in certain locations Framework selection and development is an integral part of architectural-based system implementation
The framework provides the bridge between concepts from the

architecture and concepts from the platform

28

Implementation Strategies
The figure shows the role of

frameworks in the implementation of an architecture

Common frameworks in use

include the Microsoft Foundation Classes (MFC) and the Java Swing library Both are targeted at supporting the implementation of user interfaces
Frameworks fundamentally

influence the architectures of systems that employ them

29

Implementation Strategies
Middleware technologies typically support

communication between software components Middleware facilitates the implementation of connectors (architectural elements responsible for providing communication between components) The developer must implement the components business logic, but the middleware implements the connectors Examples of middleware: COBRA, Microsofts DCOM, RPC, message-oriented middleware

30

Implementation Strategies
Reuse of software components is also used to assist

in implementation The key issue is the degree to which functionality, interfaces, and nonfunctional properties of a candidate component for reuse match those required by the architecture

31

Implementation Strategies
Implementation has an architecture Failure to recognize this: Robs one of the ability to reason about the

implemented applications architecture in the future Misleads all stakeholders regarding what they believe they have Makes any development or evolution strategy that is based on the documented but inaccurate architecture doomed to failure

32

Analysis and Testing

Analysis and testing assess the qualities of an artifact Analysis and testing may be integrated within the

development activities
Conducting analysis before the code exists is cost saving The earlier an error is detected and corrected, the lower the

aggregate cost

Analysis and Testing is often left only to the source

code because no representation of the application exists other than the source code An architecture-centric approach offers opportunity for early analysis and improved analysis of source code
33

Analysis and Testing

The architecture of an application can be examined

for consistency, correctness and exhibition of desired nonfunctional properties

High-quality architecture raises prospects for high-quality

implementation

The architectural model can be examined for internal

consistency and correctness, by

Syntactic checks of the model, which can identify mismatched

components Data flow analysis, which can determine definition/use mismatches

34

Analysis and Testing

The architecture governs the specification-based testing at

all levels (unit, subsystem, and system level) The architectural model may be examined for consistency with requirements The architectural model may be used in determining and supporting analysis and testing strategies applied to the source code The architect can prioritize analysis and testing activities based upon the architecture, focusing activities on the most critical components and subassemblies
Testing costs money, only some testing may be in the budget

and organizations may use architecture to guide testing

35

Analysis and Testing

Architecture can provide guidance in the development

of test harnesses
Test harnesses are small programs used to test components

and subassemblies of larger applications They conveniently test the internal parts of an application For example, each customized product in a product family can have a testing regimen emphasizing only those parts that have changed

Architecture can provide guidance in directing the

analysts attention to the connectors in a systems implementation

36

Analysis and Testing

The architectural model can be compared to a model

derived from the source code of an application Features of implementation can be readily extracted and compared with the architecture
For example, extracting a model from the source code that

shows which components communicate with which others

37

Evolution and Maintenance

Software evolution and software maintenance refer to

all manner of activities that chronologically follow the release of an application

Examples of software evolution range from bug fixes to major

additions of new functionality

In a good practice of software maintenance, each

type of change causes the software process to return to whatever phase that issue is considered in, and the development process restarts from that point

38

Evolution and Maintenance

A major risk of evolution is degradation of the quality

of the application
It is common that changes are made anywhere it is most

expedient (usually changes are made only in the code) Quality degrades making subsequent changes increasingly difficult

An architecture-centric approach to development

offers a solid basis for effective evolution

This is possible because of sustained focus on an explicit,

substantive, modifiable, faithful architectural model

39

Evolution and Maintenance

The evolution process consists of the following

stages:
Motivation, such as creating new versions of a product Evaluation or assessment; the proposed change and existing

application are examined to learn about the change needed Design and choice of approach; choosing an approach that satisfies the requirement that motivated the activity Action, which includes preparation for the next round of adaptation

If an explicit architectural model is available, then

understanding and analysis can proceed If not, understanding the application must proceed in a reverse-engineering fashion
40

Evolution and Maintenance

Errors in maintenance often arise from a lack of

understanding and analysis of the application

Insufficient understanding of the existing structure will mean

changes to the structure are likely to fail

A good architectural model provides a basis for

deciding whether a desired modification is reasonable Avoid changing code first and then planning on changing the architectural description; changing the description seldom takes place, even with good intentions Making changes is not complete until all elements of an application are consistent; this will help for future modifications 41

Processes
Traditional software process discussions do not focus

on architecture There is not a single correct way to proceed in application development with an architecture-centric software development process
Different organizations will demand different prominence given

to various development activities

A good description for software development

strategies will provide a way of showing what activities are occurring when, and also give architecture a central role in the formation of the software product
42

Example Process Depictions

A Robust Domain-Specific Architecture-based Project A notional project based upon a preexisting domain-specific software architecture Core is large at beginning of the project because of reusable artifacts The activities are to: Assess the artifacts to ensure that the current project fits within the constraint imposed by those artifacts Parameterize those artifacts to meet the new projects needs and to perform any customization necessary Integrate, assess, and deploy the product

43

Example Process Depictions

Agile Development Agile processes show and emphasize concurrency

between a variety of kinds of development activities All activities continue throughout the project The skinny core is because the agile process denies development of any explicit architecture The code is the architecture

44

Example Process Depictions

Problems with the agile method are clear when follow-

on projects are required Very little documentation is done with original project This means a different development team may have to give a significant portion of time at the beginning of the project to simply understand the existing code base and partially recover the latent architecture so planning can proceed

45