01 the big idea

8/7/2019 01 the Big Idea

1/38

Copyright Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved.

The Big Idea

Software Architecture

Lecture 1


2/38

Software Architecture: Foundations, Theory, and Practice

The OriginsSoftware Engineers have always employed softwarearchitectures

Very often without realizing it! Address issues identified by researchers andpractitioners

Essential software engineering difficultiesUnique characteristics of programming-in-the-large

Need for software reuseMany ideas originated in other (non-computing) domains

2


3/38


Softw are Engineering Di ff icul t iesSoftware engineers deal with unique set of problems

Young field with tremendous expectations

Building of vastly complex, but intangible systemsSoftware is not useful on its own e.g., unlike a car,thusIt must conform to changes in other engineeringareas

Some problems can be eliminatedThese are Brooks accidental difficulties

Other problems can be lessened, but not eliminatedThese are Brooks essential difficulties

3


4/38


Acciden t al Di ff icul t iesSolutions exist

Possibly waiting to be discovered

Past productivity increases result of overcomingInadequate programming constructs & abstractions

Remedied by high-level programming languagesIncreased productivity by factor of five

Complexity was never inherent in program at all

4


5/38


Acciden t al Di ff icul t ies (c o n td)Past productivity increases result of overcoming (cont d)

Viewing results of programming decisions took long

timeRemedied by time sharingTurnaround time approaching limit of humanperception

Difficulty of using heterogeneous programs Addressed by integrated software development environmentsSupport task that was conceptually always possible

5


6/38


Essen t ial Di ff icul t iesOnly partial solutions exist for them, if anyCannot be abstracted away

ComplexityConformityChangeability

Intangibility

6


7/38


Comp lexi tyNo two software parts are alike

If they are, they are abstracted away into one

Complexity grows non-linearly with sizeE.g., it is impossible to enumerate all states of programExcept perhaps toy programs

7


8/38


Co n fo r m itySoftware is required to conform to its

Operating environment

HardwareOften last kid on blockPerceived as most conformable

8


9/38


Changeabili tyChange originates with

New applications, users, machines, standards, laws

Hardware problemsSoftware is viewed as infinitely malleable

9


10/38


In t angibili tySoftware is not embedded in space

Often no constraining physical laws

No obvious representationE.g., familiar geometric shapes

10


11/38


Pe wt er Bulle t s Ada, C++, Java and other high level languagesObject-oriented design/analysis/programming

Artificial Intelligence Automatic ProgrammingGraphical ProgrammingProgram Verification

Environments & toolsWorkstations

11


12/38


P r om ising A tt acks On C omp lexi ty (In1987)

Buy vs. BuildRequirements refinement & rapid prototyping

Hardest part is deciding what to build (or buy?)Must show product to customer to get complete spec.Need for iterative feedback

12


13/38


P r om ising A tt acks On C omp lexi ty (c o n td)

Incremental/Evolutionary/Spiral Development Grow systems, don t build them

Good for moraleEasy backtrackingEarly prototypes

Great designers

Good design can be taught; great design cannot Nurture great designers

13


14/38


Pri m ac y of DesignSoftware engineers collect requirements, code, test,integrate, configure, etc.

An architecture-centric approach to software engineeringplaces an emphasis on designDesign pervades the engineering activity from thevery beginning

But how do we go about the task of architecturaldesign?

14


15/38


Anal o g y:

Archi t ec t ure of Buildings

We all live in them(We think) We know how they are built

RequirementsDesign (blueprints)ConstructionUse

This is similar (though not identical) to how we buildsoftware

15


16/38


Som e Obvi o usP

arallelsSatisfaction of customers needsSpecialization of labor

Multiple perspectives of the final product Intermediate points where plans and progress arereviewed

16


17/38


Dee p erP

arallels Architecture is different from, but linked with theproduct/structure

Properties of structures are induced by the design of thearchitectureThe architect has a distinctive role and character

17


18/38


Dee p erP

arallels (c o n td)Process is not as important as architecture

Design and resulting qualities are at the forefront

Process is a means, not an end Architecture has matured over time into a discipline

Architectural styles as sets of constraintsStyles also as wide range of solutions, techniques and

palettes of compatible materials, colors, and sizes

18


19/38


Mo re ab o u t t he

Archi t ec t

A distinctive role and character in a project Very broad training

Amasses and leverages extensive experience A keen sense of aestheticsDeep understanding of the domain

Properties of structures, materials, and environments

Needs of customers

19


20/38


Mo re ab o u t t he

Archi t ec t (c o n td)

Even first-rate programming skills are insufficient for thecreation of complex software applications

But are they even necessary?

20


21/38


Lim it a t io ns of t he

Anal o g y

We know a lot about buildings, much less about softwareThe nature of software is different from that of buildingarchitectureSoftware is much more malleable than physical materialsThe two construction industries are very different Software deployment has no counterpart in buildingarchitectureSoftware is a machine; a building is not

21


22/38


Bu t St ill Ver y Real P ow er of A rchi t ec t ure

Giving preeminence to architecture offers the potentialfor

Intellectual controlConceptual integrityEffective basis for knowledge reuseRealizing experience, designs, and code

Effective project communicationManagement of a set of variant systems

Limited-term focus on architecture will not yieldsignificant benefits!

22


23/38


Archi t ec t ure in

Ac t io n : WWW

This is the Web

23

Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; 2008 John Wiley & Sons, Inc. Reprinted with permission.


24/38


A rchi t ec t ure in A c t io n : WWW

So is this

24



25/38


Archi t ec t ure in

Ac t io n : WWW

And this

25



26/38


WWW in a (Big) Nu t shellThe Web is a collection of resources, each of which hasa unique name known as a uniform resource locator, or

URL .Each resource denotes, informally, some information.URI s can be used to determine the identity of a machineon the Internet, known as an origin server, where thevalue of the resource may be ascertained.Communication is initiated by clients, known as useragents, who make requests of servers.

Web browsers are common instances of user agents.

26


27/38


WWW in a (Big) Nutshell (c

on

td)

Resources can be manipulated through theirrepresentations.

HTML is a very common representation languageused on the Web.

All communication between user agents and originservers must be performed by a simple, generic protocol(HTTP), which offers the command methods GET, POST,etc.

All communication between user agents and originservers must be fully self-contained. (So-called statelessinteractions )

27


28/38


WWW s A rchi t ec t ure

Architecture of the Web is wholly separate from the codeThere is no single piece of code that implements thearchitecture.There are multiple pieces of code that implement thevarious components of the architecture.

E.g., different Web browsers

28


29/38


WWW s A rchi t ec t ure (c o n td)

Stylistic constraints of the Web s architectural style arenot apparent in the code

The effects of the constraints are evident in the Web

One of the world s most successful applications is onlyunderstood adequately from an architectural vantagepoint.

29


30/38


A rchi t ec t ure in A c t io n : Desk top

Remember pipes and filters in Unix?

ls invoices | grep e august | sort Application architecture can be understood based onvery few rules

Applications can be composed by non-programmers Akin to Lego blocks

A simple architectural concept that can becomprehended and applied by a broad audience

30


31/38


A rchi t ec t ure in A c t io n : P r o duc t L ine

Motivating example A consumer is interested in a 35-inch HDTV with a built-in DVDplayer for the North American market.

Such a device might contain upwards of a million lines of embedded software.

This particular television/DVD player will be very similar to a 35-inch HDTV without the DVD player, and also to a 35-inch HDTVwith a built-in DVD player for the European market, where theTV must be able to handle PAL or SECAM encoded broadcasts,rather than North America s NTSC format.

These closely related televisions will similarly each have a millionor more lines of code embedded within them.

31


32/38


Growing Sophistication of Consumer Devices

32


33/38


F a m ilies of Rela t ed P r o duc t s

33


34/38


The Necessi ty and Bene f it of PL s

Building each of these TVs from scratch would likely put Philips out of businessReusing structure, behaviors, and component implementations is increasingly important to successfulbusiness practice

It simplifies the software development taskIt reduces the development time and cost it improves the overall system reliability

Recognizing and exploiting commonality and variabilityacross products

34


35/38


Reuse as t he Big Win

Architecture: reuse of Ideas

KnowledgePatternsengineeringguidance

Well-wornexperience

Product families: reuse of Structure

BehaviorsImplementationsTest suites

35


36/38


A dded Bene f it P r o duc t P op ula t io ns

36


37/38


The C en t er p iece A rchi t ec t ure

37


38/38


S u mm ar y

Software is complexSo are buildings

And other engineering artifactsBuilding architectures are an attractive source of analogy

Software engineers can learn from other domains

They also need to develop and have developed a richbody of their own architectural knowledge andexperience

38

01 the big idea

Documents