AdvancedSoftware EngineeringSoftware Architecture

(1)

Software Architecture

Advanced

Software Engineering

Software Architecture

(2)

References

[1] Software Engineering, A Practitioner’s

Approach, 7th Ed., Roger S. Pressman, McGraw-Hill Publications, 2010

[2] Software Architecture, Foundations, Theory, and Practice, 1st Ed., Taylor, Medvidovich &

(3)

Agenda

❑

Introduction

❑

Software Difficulties

▫

How can SW Architecture help?

❑

Analogy: Architecture of

Buildings

❑

Architectural Styles &

Architectures

(4)

Introduction

❑

What is SW Architecture?

❑

How does it differ from SW Design?

❑

Which SW architectures do you know?

▫ _{How do they differ from SW Design?}

(5)

Introduction

❑

Q: Why SW Architecture?

❑

A: Reducing/Removing

“

SW Engineering Difficulties”

❑

Problems facing SW engineers :

▫ _{Young field}_{with tremendous expectations}

▫ _{Building of vastly}_complex_{, but}_intangible

systems

▫ _Software_{is not useful on its own}_{e.g., unlike a}

car, thus:

▫ _{It must}_{conform to changes}_{in other engineering}

areas

(6)

Agenda

❑

Introduction

❑

Software Difficulties

▫

How can SW Architecture help?

❑

Analogy: Architecture of

Buildings

(7)

Software Engineering Difficulties

❑

Frederick P. Brooks [3] divides SW Eng.

Difficulties to:

▫ _{“Accidental Difficulties”}

● problems that can be eliminated

▫ _{“Essential Difficulties”}

● problems that can be lessened, but not eliminated

(8)

Software Engineering Difficulties

❑

Accidental Difficulties:

▫ _{Solutions exist}

● _{Possibly waiting to be discovered}

▫ _Examples:

● Difficulty: Inadequate programming constructs & abstractions

● Reduced by: high-level programming languages

(9)

Software Engineering Difficulties

❑

Accidental Difficulties:

▫ _{Examples: (cont’d)}

● Difficulty: Viewing results of programming decisions took long time

● Remedied by: time–sharing

● Benefits: Turnaround time approached the limit of human perception

(10)

Software Engineering Difficulties

❑

Accidental Difficulties:

▫ _{Examples: (cont’d)}

● Difficulty: Working on heterogeneous programs ● Remedied by: integrated software development

environments (IDEs)

(11)

Software Engineering Difficulties

❑

Frederick P. Brooks [3] divides SW Eng.

Difficulties to:

▫ _{“Accidental Difficulties”}

● problems that can be eliminated

▫ _{“Essential Difficulties”}

● problems that can be lessened, but not eliminated

(12)

Software Engineering Difficulties

❑

Essential Difficulties:

▫ _{Only partial solutions exist for them, if any} ▫ _{Cannot be abstracted away}

▫ _Examples:

● _Complexity ● _Conformity ● Changeability

(13)

Software Engineering Difficulties

❑

Essential Difficulties:

▫ _Complexity:

● Complex system is a system with:

● _{many “different” parts}

● high degree of relations between parts ● _{each part can be complex system itself} ● SW is a Complex System!

● _{No two software parts are alike}

● It is impossible to enumerate all states of program

▫ _{except in “toy” programs}

● _{So, it is impossible to model SW as a finite-state}

machine

▫ _{thus, SW evaluation will be difficult!}

(14)

Software Engineering Difficulties

❑

Essential Difficulties:

▫ _Conformity:

● _{Software is required to conform to its}

● _{Operating environment} ● Hardware

● _{Often “}_{last kid on block}_”

(15)

Software Engineering Difficulties

❑

Essential Difficulties:

▫ _{Changeability:}

● _{Change originates with}

● _{New applications, users, machines, standards, laws} ● Hardware problems

● _{Software is viewed as}_{infinitely malleable}

(16)

Software Engineering Difficulties

❑

Essential Difficulties:

▫ _{Intangibility:}

● _{Software is not embedded in space}

● _{Often no constraining physical laws}

● _{No obvious representation}

(17)

Software Engineering Difficulties

❑

Pewter Bullets:

▫ _{Ada, C++, Java and other high–level languages} ▫ _{Object-oriented design/analysis/programming} ▫ _{Artificial Intelligence}

▫ _{Automatic Programming} ▫ _{Graphical Programming} ▫ _{Program Verification} ▫ _{Environments & tools} ▫ _Workstations

(18)

Software Engineering Difficulties

❑

How can SW Architecture help?

▫ _{Many properties of SW depends on its}

architecture/design:

● e.g., SW complexity, changeability, maintainability,

quality, interoperability

● Example:

● _{Do you think 3-layer architecture is appropriate for}

(19)

Agenda

❑

Introduction

❑

Software Difficulties

▫

How can SW Architecture help?

❑

Analogy: Architecture of

Buildings

❑

Architectural Styles &

Architectures

(20)

Analogy: Architecture of Buildings

❑

We all live in them

❑

(We think) We know how they are built

▫ _Requirements

▫ _{Design (blueprints)} ▫ _Construction

▫ _Use

❑

This is similar (though not identical) to how

(21)

Analogy: Architecture of Buildings

❑

Some Obvious Parallels:

▫ _{Satisfaction of customers’ needs} ▫ _{Specialization of labor}

▫ _{Multiple perspectives of the final product}

▫ _{Intermediate points where plans and progress}

are reviewed

(22)

Analogy: Architecture of Buildings

❑

Deeper Parallels:

▫ _{Architecture is different from, but linked with}

the product/structure

▫ _{Properties of structures are induced by the}

design of the architecture

▫ _{The architect has a distinctive role and}

(23)

Analogy: Architecture of Buildings

❑

Deeper Parallels (cont’d):

▫ _{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 constraints}

● Styles also as wide range of solutions, techniques and palettes of compatible materials, colors, and sizes

(24)

Analogy: Architecture of Buildings

❑

Limitations of the Analogy:

▫ _{We know a lot about buildings, much less about}

software

▫ _{The nature of software is different from that}

of building architecture

▫ _{Software is much more malleable than physical}

materials

(25)

Analogy: Architecture of Buildings

❑ But Still Very Real Power of Architecture:

▫ Giving preeminence to architecture offers the potential for

● Effective basis for knowledge reuse ● _{Realizing experience, designs, and code} ● Effective project communication

● _{Management of a set of variant systems}

▫ Limited-term focus on architecture will not yield significant benefits!

● Architectural Design should be considered at the

very beginning of SW development process ● Why? (e.g., cost & time estimation)

(26)

Agenda

❑

Introduction

❑

Software Difficulties

▫

How can SW Architecture help?

❑

Analogy: Architecture of

Buildings

(27)

Architectural Styles & Architectures

❑ Architectural style vs. Architecture :

▫ Example: What is the difference between “layered” & “3-layer” sw design?

● Number of layers, role of each layer, direction of communications

❑ A architectural style/architecture is formulated in terms of

▫ _components,

▫ _{Connectors: the way components are}_connect_{to each other,}

● E.g., remote procedure call, Message passing

▫ _{Communication restrictions}

(28)

Architectural Styles & Architectures

❑

Several Architectural Styles:

▫ _{Client-Server} ▫ _Layered

▫ _Object-based

▫ _{Data-centered (Backboard)}

▫ _Event-based

(Publish-Subscribe)

▫ _{Pipe & Filter}

(29)

Architectural Styles & Architectures

Slide -29

❑ Client-Server Style:

❑

Components are clients and servers

❑

Servers do not know number or identities

of clients

❑

Clients know server’s identity

❑

Connectors are RPC-based network

(30)

Architectural Styles & Architectures

❑ Layered style:

❑ Example architectures: • _{3-layer, client-server}

(31)

Three-Tiered Pattern (State-Logic-Display)

❑

Application Examples

▫ _{Business applications} ▫ _{Multi-player games}

▫ _{Web-based applications}

(32)

Layered Style (cont’d)

❑ Advantages

▫ Increasing abstraction levels

▫ _Evolvability

▫ Changes in a layer affect at most the adjacent two layers

● Reuse

▫ Different implementations of layer are allowed as long as interface is preserved

▫ _{Standardized layer interfaces for libraries and}

(33)

Architectural Styles & Architectures

❑ Object-based style:

▫ Basic idea: Organize into logically different components, and subsequently

distribute those components over the various machines.

▫ Advantages

● _{“Infinite malleability” of object}

internals

● _{System decomposition into sets}

of interacting agents

▫ _{Disadvantages}

● Objects must know identities of

servers

● _{Side effects in object method invocations}

▫ Example Architectures:

● Model-View-Controller Architecture

● Sense-Compute-Control

(34)

Architectural Styles & Architectures

(35)

Architectural Styles & Architectures

● Model-View-Controller Architecture:

● _{When a model object value changes, a notification is sent}

to the view and to the controller. So that the view can update itself and the controller can modify the view if its logic requires so .

● _{When handling input from the user the windowing system}

sends the user event to the controller; If a change is required, the controller updates the model object.

(36)

Architectural Styles & Architectures

(37)

Architectural Styles & Architectures

❑ Data-Centered (Blackboard) style:

▫ Basic idea: Processes communicate through a common (passive or active)

repository

▫ Example systems:

● Networked applications that rely on a shared distributed file system

● Distributed Expert System

● Compiler

(38)

Architectural Styles & Architectures

❑ Data-Centered (Blackboard) style: ▫ _{Two kinds of components}

● _{Central data structure — blackboard}

● _{Components operating on the blackboard}

▫ System control is entirely driven by the blackboard state

(39)

Architectural Styles & Architectures

❑ event-based (Publish-Subscribe) style:

▫ Basic idea: Decouple processes in space (“anonymous”) and also time (“asynchronous”)

Slide -39

(a) Publish/subscribe [decoupled in space] :

Loose Connectivity between objects (Objects do not need to reference to each other) (b) Shared data spaces [decoupled in space and time] :

Combined with data-centered style ( Objects do not need to be active either while the communication is performed)

Highly efficient one-way dissemination of information with very low-coupling of components

(40)

Architectural Styles & Architectures

❑ Pipe and Filter Style:

▫ Components are filters

● Transform input data streams into output data streams

● Possibly incremental production of output

▫ Connectors are pipes

● Conduits for data streams

▫ Style invariants

● Filters are independent (no shared state)

● Filter has no knowledge of up- or down-stream filters

▫ Examples

● signal processing

(41)

Architectural Styles & Architectures

Slide -41

❑ Pipe and Filter Style (cont’d):

▫ Variations

● Pipelines — linear sequences of filters

● Bounded pipes — limited amount of data on a pipe ● Typed pipes — data strongly typed

▫ Advantages

● System behavior is a succession of component behaviors ● Filter addition, replacement, and reuse

● Possible to hook any two filters together ● Certain analyses

● Throughput, latency, deadlock ● Concurrent execution

▫ Disadvantages

● Batch organization of processing

● Interactive applications

(42)

Architectural Styles & Architectures

❑ Rule-Based Style:

▫ _{Inference engine parses user input and determines whether it}

is a fact/rule or a query. If it is a fact/rule, it adds this entry to the knowledge base. Otherwise, it queries the knowledge base for applicable rules and attempts to resolve the query.

▫ Components: User interface, inference engine, knowledge base

▫ _Connectors:_{Components are tightly interconnected, with}

(43)

Architectural Styles & Architectures

Slide -43

❑ Rule-Based Style:

▫ _{Data Elements:}_{Facts and queries}

▫ _{Behavior of the application can be very easily}

modified through addition or deletion of rules from the knowledge base.

▫ _Caution:_{When a large number of rules are}

involved understanding the interactions

between multiple rules affected by the same facts can become very difficult.

(44)

Architectural Styles & Architectures

❑ Interpreter Style:

▫ Interpreter parses and executes input commands, updating the state maintained by the interpreter

▫ _Components:_{Command interpreter, program/interpreter}

state, user interface.

▫ _Connectors:_{Typically very closely bound with direct}

procedure calls and shared state.

▫ Highly dynamic behavior possible, where the set of

commands is dynamically modified. System architecture may remain constant while new capabilities are created

(45)

Architectural Styles & Architectures

Slide -45

❑ Implicit Invocation Style:

▫ _{Event announcement instead of method invocation}

● “Listeners” register interest in and associate methods with

events

● _{System invokes all registered methods implicitly} ▫ Component interfaces are methods and events

▫ _{Style invariants}

● “Announcers” are unaware of their events’ effects ● _{No assumption about processing in response to events}

(46)

Architectural Styles & Architectures

❑ Implicit Invocation Style (cont’d):

▫ _Advantages

● _{Component reuse} ● System evolution

● _{Both at system construction-time & run-time}

▫ _{Disadvantages}

● Counter-intuitive system structure

● _{Components relinquish computation control to the} system

(47)

Architectural Styles & Architectures

Slide -47

❑ Peer-to-Peer Style:

▫ State and behavior are distributed among peers which can act as either clients or servers.

▫ _{Peers: independent components, having their own state}

and control thread.

▫ _{Connectors: Network protocols, often custom.} ▫ _{Data Elements: Network messages}

(48)

Architectural Styles & Architectures

❑ Peer-to-Peer Style:

▫ _{Topology: Network (may have redundant}

connections between peers); can vary arbitrarily and dynamically

▫ _{Supports decentralized computing with flow of}

control and resources distributed among peers. Highly robust in the face of failure of any given node. Scalable in terms of access to resources and computing power.

(49)