Chapter 2 Architectures in Context: The

Reorientation of Software Engineering

Software Architecture: Foundations, Theory, and Practice

Chapter 2 SummaryIn 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

2

The Reorientation of Software EngineeringThe 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

3

Fundamental UnderstandingsArchitecture: the set of principal design decisions

made about a systemThree fundamental understandings of architecture:

1. Every application has an architecture2. Every application has at least one architect3. 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”?

4

Fundamental UnderstandingsEvery application has an architectAn architect is the person, or group, who:

1. makes the principal decisions about the application

2. establishes and maintains the foundational design

5

Fundamental UnderstandingsArchitecture is not a phase of development

It refers to the conceptual essence of an application, including:Principal decisions regarding its designKey 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 system’s architecture should result from a conscious, deliberate activity by the architects

6

RequirementsIn 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 applicationRequirements are the statement of what the

application should doTraditional view: requirements analysis is completely

separated from any consideration of the design that may be used

7

RequirementsMathematician George Polya’s approach to isolating

requirements as stated in “How to Solve It”First, understand the problemSecond, find the connection between the data and

the unknown, and obtain a plan of the solutionThird, carry out the planFourth, examine the solution obtained

8

RequirementsIn practice, substantive requirements documents are

seldom produced before developmentReasons that requirements analysis may be done

quickly and superficially:Schedule and budget pressuresInferior processesDenigration of the engineer’s 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 termsIt is also difficult to assess practicality, schedules or cost

this way

9

RequirementsLooking at what is done in other systems evokes

“requirements”In current practice, reasoning about structure and

solution happens along with requirements analysisSuccessful new ventures are begun on the basis of a

potential solution

10

RequirementsExisting designs and architectures provide ideas

about what might be done in a new systemOur understanding of what works now and how it

works affects our wants and perceived needsThe insights from our experience with existing

systems helps us imagine what might workThis 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

RequirementsAnalysis of requirements and consideration of design

are pursued at the same timeNew development activity begins with:

knowledge of what exists nowhow the existing systems fail or fail to provide all that is

desiredknowledge of what about those systems can or cannot be

changed

Current architecture drives the requirementsRequirements can be thought of as articulation of

improvements needed to existing architectures

12

RequirementsDevelopers should be concerned with having their

vision limited by current designsIn 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 predecessorShould 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

DesignDesigning is the activity that creates a system’s

software architectureDesigning decisions span issues that arise throughout

the development processThe 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

DesignMost often design decisions are concerned with a

system’s structureprimary components and how they are connected

With an architectural-centric approach to development, phase boundaries are diminished or eliminatedArchitecture decisions are made throughout the

process of development

15

DesignDesign techniques are needed to deal with:

Stakeholder issuesOver arching style and structureThe type of connectors for composing subelementsPackage and primary class structureDistributed and decentralized system concernsDeployment issuesSecurity and other nonfunctional propertiesPost-implementation issues

16

Design TechniquesObject 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 situationsIt does not address stakeholder concerns,

deployment issues, security and trust, or use of commercial components

17

Design TechniquesLimitations 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 structureno 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 TechniquesPositive aspects of OOD

UML notation used in OOD is above the programming language levelUML has some simple notions of architecture

Extensive work in patternsEnables carry-forward of knowledge and

experience from previous work into new applications

19

Design TechniquesDomain-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 TechniquesTo successfully follow the DSSA approach, good

technical support is requiredPrevious architectures must be captured and refined for reusePoints of allowable variation must be identified and isolatedInterfaces between the points of variation and the core

architecture must be made explicitThe 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

ImplementationImplementation 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 architectureIf key design decisions are made while working with

source code they are part of the architectureThere is no presumption that architecture is

completed before implementation beginsThere may be iteration and revision of architecture

as code is developed

22

ImplementationImplementation should be consistent with the

architectureAll structural elements found in the architecture are

implemented in the source codeAll source code corresponds to parts of the explicit

architectureThe 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

ImplementationFurther issues may come into notion of faithfulness

between implementation and the architectureExamples:

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 StrategiesTechniques are available to assist in faithful

development of the implementation from the design, including:Generation technologiesFrameworks and middlewareReuse

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 StrategiesNo human labor needs to be spent on programming

with the use of generative technologiesThis 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 StrategiesAn 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 codeFrameworks may be extensive or very basic, depending on

how much code must be added by handDevelopers only need to add code in certain locationsFramework selection and development is an integral part

of architectural-based system implementationThe 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 StrategiesMiddleware technologies typically support

communication between software componentsMiddleware 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, Microsoft’s DCOM, RPC, message-oriented middleware

30

Implementation StrategiesReuse of software components is also used to assist

in implementationThe 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 StrategiesImplementation has an architectureFailure to recognize this:

Robs one of the ability to reason about the implemented application’s 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 TestingAnalysis and testing assess the qualities of an artifactAnalysis and testing may be integrated within the

development activitiesConducting analysis before the code exists is cost savingThe 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 TestingThe architecture of an application can be examined

for consistency, correctness and exhibition of desired nonfunctional propertiesHigh-quality architecture raises prospects for high-quality

implementation

The architectural model can be examined for internal consistency and correctness, bySyntactic checks of the model, which can identify mismatched

componentsData flow analysis, which can determine definition/use

mismatches

34

Analysis and TestingThe architecture governs the specification-based testing at

all levels (unit, subsystem, and system level)The architectural model may be examined for consistency

with requirementsThe 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 subassembliesTesting costs money, only some testing may be in the budget

and organizations may use architecture to guide testing

35

Analysis and TestingArchitecture can provide guidance in the development

of test harnessesTest harnesses are small programs used to test components

and subassemblies of larger applicationsThey conveniently test the internal parts of an applicationFor 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 analyst’s attention to the connectors in a systems implementation

36

Analysis and TestingThe architectural model can be compared to a model

derived from the source code of an applicationFeatures of implementation can be readily extracted

and compared with the architectureFor example, extracting a model from the source code that

shows which components communicate with which others

37

Evolution and MaintenanceSoftware evolution and software maintenance refer to

all manner of activities that chronologically follow the release of an applicationExamples 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 MaintenanceA major risk of evolution is degradation of the quality

of the applicationIt 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 evolutionThis is possible because of sustained focus on an explicit,

substantive, modifiable, faithful architectural model

39

Evolution and MaintenanceThe evolution process consists of the following

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

application are examined to learn about the change neededDesign and choice of approach; choosing an approach that

satisfies the requirement that motivated the activityAction, 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 MaintenanceErrors in maintenance often arise from a lack of

understanding and analysis of the applicationInsufficient 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

ProcessesTraditional software process discussions do not focus

on architectureThere is not a single correct way to proceed in

application development with an architecture-centric software development processDifferent 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 DepictionsA 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 artifactsParameterize those artifacts to meet the new project’s

needs and to perform any customization necessaryIntegrate, assess, and deploy the product

43

Example Process DepictionsAgile Development

Agile processes show and emphasize concurrency between a variety of kinds of development activities

All activities continue throughout the projectThe skinny core is because the agile process

denies development of any explicit architectureThe code is the architecture

44

Example Process DepictionsProblems with the agile method are clear when follow-

on projects are requiredVery little documentation is done with original

projectThis 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