Introduction to Software Architecture

Sam MalekCS 795 / SWE 699

Spring 2010

George Mason University

Software Architecture Definition

Definition. A software system’s architecture is the set of principal design decisions about the system.

Software architecture is the blueprint for a software system’s construction and evolution.

© Malek 2

Design Decisions

Design decisions encompass every aspect of the system under developmentThis includes design decisions related to

StructureBehaviorInteractionNon-functional properties

© Malek 3

Defining “Principal”

• “Principal” implies a degree of importance that grants a design decision “architectural status”.

• It also implies that not all design decisions are architectural, that is, they do not necessarily impact a system’s architecture.

• How one defines “principal” will depend on what the stakeholders define as the system goals.

© Malek 4

Software Architecture as a Field of Study

• Software architecture is a field of study that is characterized by an unusual diversity of views and understandings of some fundamental concepts.

• A quick search of the internet will yield many definitions of architecture for example.

© Malek 5

Other Definitions of Software Architecture

Perry and WolfSoftware Architecture = { Elements, Form, Rationale }

what how whyShaw and Garlan

Software architecture [is a level of design that] involves • the description of elements from which systems are built, • interactions among those elements, • patterns that guide their composition, and • constraints on these patterns.

KruchtenSoftware architecture deals with the design and implementation of the high-level structure of software.Architecture deals with abstraction, decomposition, composition, style, and aesthetics.

© Malek 6

Temporal Aspect

Design decisions are (un)made over a system’s lifetime Architecture has a temporal aspect.

A system’s architecture will change over time. However, at any given point in time, the system has only one architecture.

© Malek 7

Prescriptive vs. Descriptive Architecture

A system’s prescriptive architecture captures the design decisions made prior to the system’s construction.

It is the as-designed or as-intended architecture.

A system’s descriptive architecture describes how the system has been built.

It is the as-implemented or as-realized architecture.

© Malek 8

As-Designed vs. As-Implemented Architecture

© Malek 9

10© Malek

As-Designed vs. As-Implemented Architecture

11© Malek

As-Designed vs. As-Implemented Architecture

• Which architecture is “correct”? • Are the two architectures consistent with one

another? • What criteria are used to establish the consistency

between the two architectures? • On what information is the answer to the

preceding questions based?

Architectural EvolutionWhen a system evolves, ideally its prescriptive architecture is modified first.

Unfortunately often the system and thus its descriptive architecture is directly modified.

This failure of update happens because ofDeveloper sloppinessPerception of short deadlines which prevent thinking through and documenting Lack of documented prescriptive architectureNeed or desire for code optimizationsInadequate techniques or tool support

12© Malek

Architectural Drift vs. Erosion

Definition. Architectural drift involves architectural design decisions that are applied directly to a system’s descriptive architecture, but are not properly reflected in the system’s prescriptive architecture.

Definition. Architectural erosion involves architectural design decisions that are applied directly to a system’s descriptive architecture, and that violate design decisions captured by the system’s prescriptive architecture.

13© Malek

Architectural RecoveryIf drift or erosion are allowed to occur, the development organization is likely to be forced to recover the system’s architecture sooner or later. Definition. Architectural recovery is the process of determining a software system’s architecture from its implementation-level artifacts.Implementation-level artifacts can be

Source codeExecutable filesJava .class files

14© Malek

Implementation-Level View of an Application

15© Malek

Software Architecture’s Elements

A software system’s architecture typically is not (and should not be) a uniform monolithA software system’s architecture should be a composition and interplay of different elements

Processing Data, also referred as information or stateInteraction

16© Malek

ComponentElements that encapsulate processing and data in a system’s architecture are referred to as software components.

Definition. A software component is an architectural building block that encapsulates a subset of the system’s functionality and/or data, and restricts access to them via an explicitly defined interface.

17© Malek

Connector In complex systems interaction might become more important and challenging than the functionality of the individual components.

Definition. A software connector is an architectural building block tasked with regulating interactions among components.

In traditional, desktop software systems, connectors would have usually manifested themselves as simple procedure calls or shared data accesses. 18© Malek

© Malek 19

Multiple Connectors in a Single System

DATABASEACCESSIMPLICIT

INVOCATION

PIPE PIPE

METHODCALLADT OP

ACCESS

REAL-TIMEDATASTREAM

Software ConnectorsArchitectural element that models

Interactions among componentsRules that govern those interactions

Simple interactionsProcedure callsShared variable access

Complex & semantically rich interactionsClient-server protocolsDatabase access protocolsAsynchronous event multicast

Each connector providesInteraction duct(s)Transfer of control and/or data

20© Malek

Implemented vs. Conceptual Connectors

Connectors in software system implementationsFrequently no dedicated codeFrequently no identityTypically do not correspond to compilation unitsDistributed implementation

• Across multiple modules• Across interaction mechanisms

Connectors in software architecturesFirst-class entitiesHave identityDescribe all system interactionEntitled to their own specifications & abstractions

21© Malek

Reasons for Treating Connectors Independently

Connector ComponentComponents provide application-specific functionalityConnectors provide application-independent interaction mechanisms

Interaction abstraction and/or parameterizationSpecification of complex interactions

Binary vs. N-aryAsymmetric vs. SymmetricInteraction protocols

Localization of interaction definitionExtra-component system (interaction) informationComponent independenceComponent interaction flexibility

22© Malek

Benefits of First-Class Connectors

Separate computation from interactionMinimize component interdependenciesSupport software evolution

At component-, connector-, & system-level

Potential for supporting dynamismFacilitate heterogeneityBecome points of distributionAid system analysis & testing

23© Malek

Software Connector Roles

Locus of interaction among set of componentsProtocol specification (sometimes implicit) that defines its properties

Types of interfaces it is able to mediateAssurances about interaction propertiesRules about interaction orderingInteraction commitments (e.g., performance)

RolesCommunicationCoordinationConversionFacilitation

24© Malek

Connectors as Communicators

Main role associated with connectorsSupports

Different communication mechanisms• e.g. procedure call, RPC, shared data access, message

passingConstraints on communication structure/direction• e.g. pipes

Constraints on quality of service• e.g. persistence

Separates communication from computationMay influence non-functional system characteristics

e.g. performance, scalability, security

25© Malek

Connectors as Coordinators

Determine computation controlControl delivery of dataSeparates control from computationOrthogonal to communication, conversion, & facilitation

Elements of control are in communication, conversion & facilitation

26© Malek

Connectors as Converters

Enable interaction of independently developed, mismatched componentsMismatches based on interaction

TypeNumberFrequencyOrder

Examples of convertersAdaptorsWrappers

27© Malek

Connectors as Facilitators

Enable interaction of components intended to interoperate

Mediate & streamline interaction

Govern access to shared informationEnsure proper performance profiles

e.g., load balancing

Provide synchronization mechanismsCritical sectionsMonitors

28© Malek

Configuration

Components and connectors are composed in a specific way in a given system’s architecture to accomplish that system’s objective.

Definition. Architectural configurations, or topologies, capture architectural structure via graphs whose nodes represent components and connectors, and whose edges represent their interconnectivity.

29© Malek

An Example Configuration

30© Malek

Architectural Models, Views, and Visualizations

Architecture ModelAn artifact documenting some or all of the architectural design decisions about a system.

Architecture VisualizationA way of depicting some or all of the architectural design decisions about a system to a stakeholder.

Architecture ViewA subset of related architectural design decisions.

31© Malek

Architectural StyleAn architectural style is a named set of constraints (e.g., rules) you put on your development

Constraints may be topological, behavioral, communication-oriented, you name it

© Malek, 2008 32

VS.

Basic Properties of Styles

A vocabulary of design elementsComponent and connector typese.g., pipes, filters, objects, servers

A set of configuration rulesTopological constraints that determine allowed compositions of elementse.g., a component may be connected to at most two other components

A semantic interpretationCompositions of design elements have well-defined meanings

© Malek, 2008 33

Different Aspects of StylesWhat is the design vocabulary?

Component and connector types

What are the allowable structural patterns?What is the underlying computational model?What are the essential invariants of the style?What are common examples of its use?What are the (dis)advantages of using the style?What are the style’s specializations?

© Malek, 2008 34

Some Common Styles“Basic” styles

Pipe and filterObject-orientedLayeredBlackboardState transitionClient-server

• Many flavors Peer-to-peerEvent-based (a.k.a. Implicit invocation)Push-based

“Derived” stylesGenVocaC2

© Malek, 2008 35

Pipe and Filter StyleComponents are filters

Transform input data streams into output data streamsPossibly incremental production of output

Connectors are pipesConduits for data streams

Style invariantsFilters are independent (no shared state) Filter has no knowledge of up- and down-stream filters

ExamplesUNIX shell signal processing

Distributed systems parallel programming

InputCircularShift Alphabetizer Output

InputMedium

OutputMedium

© Malek, 2008 36

Pipe and Filter (cont.)

VariationsPipelines — linear sequences of filtersBounded pipes — limited amount of data on a pipeTyped pipes — data strongly typedBatch sequential — data streams are not incremental

AdvantagesSystem behavior is a succession of component behaviorsFilter addition, replacement, and reuse

• Possible to hook any two filters together Certain analyses

• Throughput, latency, deadlockConcurrent execution

DisadvantagesBatch organization of processingInteractive applicationsLowest common denominator on data transmission

© Malek, 2008 37

Object-Oriented StyleComponents are objects

Data and associated operationsConnectors are messages and method invocationsStyle invariants

Objects are responsible for their internal representation integrityInternal representation is hidden from other objects

Advantages“Infinite malleability” of object internalsSystem decomposition into sets of interacting agents

DisadvantagesObjects must know identities of serversOften very tightly coupled systems

© Malek, 2008 38

Layered Style

Hierarchical system organization“Multi-level client-server”

Each layer exports an “API” to be used by above layers

Each layer acts as aServer: service provider to layers “above”

Client: service consumer from layers “below”

Connectors are protocols of layer interaction

Example: operating systems

Virtual machine style results from fully opaque layers

L1

L2

L3

L1L2

L3

L1

L2

L3

L1L2

L3

© Malek, 2008 39

Layered Style (cont.)

AdvantagesIncreasing abstraction levelsEvolvabilityChanges in a layer affect at most the adjacent two layers

• ReuseDifferent implementations of layer are allowed as long as interface is preservedStandardized layer interfaces for libraries and frameworks

DisadvantagesNot universally applicablePerformance

Layers may have to be skippedDetermining the correct abstraction level

© Malek, 2008 40

Blackboard StyleTwo kinds of components

Central data structure — blackboardComponents operating on the blackboard

System control is entirely driven by the blackboard stateExamples

Typically used for AI systemsIntegrated software environments (e.g., Interlisp)Compiler architecture

Lexer Parser Semantor

BLACKBOARD

© Malek, 2008 41

Client-Server Style

Instance of a more general styleDistributed systems

Components are clients and serversServers do not know number or identities of clientsClients know server’s identityConnectors are point-to-point interaction protocolsA number of different flavors of client-server

© Malek, 2008 42

Peer-to-Peer Style

Similar to Client-ServerPoint-to-point communication between components

There is no distinction between a client and server

i.e., a client can also be a server

It is almost a “null” styleNot that many constraints

© Malek, 2008 43

Implicit Invocation Style

Event announcement instead of method invocation

“Listeners” register interest in & associate methods with eventsSystem invokes all registered methods implicitly

Component interfaces are methods and eventsTwo types of connectors

Invocation is either explicit or implicit in response to events

Style invariants“Announcers” are unaware of their events’ effects, if anyNo assumption about processing in response to events

© Malek, 2008 44

Implicit Invocation (cont.)Advantages

Component reuseSystem evolution• Both at system construction-time & run-time

DisadvantagesCounter-intuitive system structureComponents relinquish computation control to the systemNo knowledge of what components will respond to eventNo knowledge of order of responses

© Malek, 2008 45

Push-Based StyleSpecialization of this style is the Publish-Subscribe style

Distinguished from pull-based (e.g., the Web)

Examplesemployee information systemsmaintenance manualsstock ticker

Consumer ProducerRequest

Reply

Consumer Producer

Subscribe

Receive

UnsubscribePublish

AnnouncePushInfra-

structure

© Malek, 2008 46

Push-Based Style (cont.)“Components”

ProducerReceiverChannelBroadcasterTransport system

• Repeater, cache, proxy• Transparent to all other components

Asymmetric communication modelProducers/ReceiversMore receivers than producers

© Malek, 2008 47

The C2 StyleTopological Constraints

All components, connectors have two interfaces, “top” and “bottom”Components can be connected to 0-1 connector on each interfaceConnectors can be connected to 0+ components or connectors on each interface

Component Connector

top

bottom

top

bottom

© Malek, 2008 48

The C2 Style

Communication ConstraintsComponents & connectors communicate using only independent events or messages

• Requests go up (“requests rise”)

• Notifications go down• No passing pointers

Components & connectors communicate asynchronously

• Can send/receive events at any time

• No blocking!

DataStore

GUI

GUIInterpreter

Alarm

Notifications

Requests

© Malek, 2008 49

The C2 StyleDependency Constraints

Components may make assumptions about services provided above them• But not who is providing them

Components may NOT make assumptions about services provided below them

© Malek, 2008 50

C2 Example

DataStore

GUI

GUIInterpreter

Alarm

© Malek, 2008 51

C2 Example

DataStore

GUI

GUIInterpreter

Alarm

Stores data; emits notifications whenever

data changes.

© Malek, 2008 52

C2 Example

DataStore

GUI

GUIInterpreter

Alarm

Interprets basic GUI actions & translates them into data store operations

© Malek, 2008 53

C2 Example

DataStore

GUI

GUIInterpreter

Alarm

Rings a bell whenever value of X changes

© Malek, 2008 54

C2 Example

DataStore

GUI

GUIInterpreter

AlarmAccept & process user

actions

© Malek, 2008 55

C2 Example

DataStore

GUI

GUIInterpreter

AlarmConnector routes

messages: requests are broadcasted up, notifications are

broadcasted down

© Malek, 2008 56

What ilities does C2 buy us?Flexibility and Adaptability

Loose coupling lets you swap out components, interpose componentsFlexible connectors allow run-time changes

DistributabilitySince no assumption of shared address space, distributing an app across machines is easyEvent routing is determined by the configuration of the architecture

VisibilitySince all messages go through connectors, they are easy to catch and log

ParallelizabilitySince the same event is delivered to multiple components in a given layer

© Malek, 2008 57

Heterogeneous Styles

L1L2

L3s1s2

s3

t12 t23t32

t31

I/I

BLACKBOARD

FIFOQueue

ProcCalls

Subscribe

Push

© Malek, 2008 58

General Benefits of Using StylesDesign reuse

Well-understood solutions applied to new problems

Code reuseShared implementations of invariant aspects of a style

Understandability of system organization A phrase such as “client-server” conveys a lot of information

InteroperabilitySupported by style standardization

Style-specific analysesEnabled by the constrained design space

VisualizationsStyle-specific depictions matching engineers’ mental models

© Malek, 2008 59

The impact of style on software qualities

In general, styles could have a significant impact on the properties of a software system:

PerformanceScalabilityModifiability/AdaptabilityVisibilityPortabilityReliabilitySimplicity

© Malek, 2008 60

Style Comparison (from Fielding’s paper)

© Malek, 2008 61

ObservationsDifferent styles often result in

Different architecturesArchitectures with greatly differing properties

A style does not fully influence resulting architecture

A single style can result in different architecturesConsiderable room for

• Individual judgment• Variations among architects• Different emphases

– e.g., Imposed by customer

© Malek, 2008 62