1

Software Architecture

Schahram DustdarDistributed Systems Group

TU Wien

Main Topics

Software Architecture: Introduction Architecture and Architecture Disciplines Architectural Requirements Architectural Principles Architectural Styles and Patterns Important Architectural Styles and Patterns Modeling Architectures Model-Driven Design and Development Architectural Views Architectural Decisions Architecture in the Organization

2

SOFTWARE ARCHITECTURE: INTRODUCTION

3

Main Goals

Provide an orientation on architecture Improve the quality of the software Understand architectural thinking

4

5

Typical process of developing software – developer’s point of view

Starting point: A “wishlist” Next step: A “concept” is created Then: Changes are needed Deviations from the concept are necessary

Result: Big Ball of Mud

6

Big Ball of Mud

In computer programming, Big Ball of Mud is a term for a system or

computer program that has no real distinguishable architecture.

7

Analogy in Civil Architecture

8

Many IT-Projects Fail

The big ball of mud scenario is not exaggerated Most of the IT projects fail more or less E.g.: Only 16 % of the projects in the study by [Standish

1994] have been concluded successfully

Examples for failing are [Yourdon 2004]: Exceeding the budget Exceeding the time Customers are not satisfied with the delivered product The project gets cancelled

9

Inspiration from Civil Architecture

In analogy to civil architecture, software architecture aims to manage the complexity of the

systems we build

ARCHITECTURE AND ARCHITECTURE DISCIPLINES

10

11

Civil Architecture as a Starting Point

Architecture Definition (American Heritage Dictionary): The art and science of designing and erecting buildings A style and method of design and construction Orderly arrangement of parts

That is, architecture includes: The structure of a building – or software system The act of designing this structure

12

What is Software Architecture?

Architecture does not specify the details, but the “load carrying” components Think of coarse-grained components and subsystems

rather than of individual classes an algorithms

Architecture reaches from analysis of the problem to the realization of the solution

Architecture aims to make complexity manageable

Architecture deals with decisions that have system-wide consequences

13

What is Software Architecture?

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 Design decisions encompass every facet of the

system under development Structure Behavior Interaction Non-functional properties

There are numerous definitions of SW architecture: http://www.sei.cmu.edu/architecture/definitions.html

14

What is “Principal”?

“Principal” implies a degree of importance that grants a design decision “architectural status” It 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

15

Other Definitions of Software Architecture

Perry and Wolf Software Architecture = { Elements, Form, Rationale }

what how why Shaw 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.

Kruchten Software architecture deals with the design and implementation of

the high-level structure of software. Architecture deals with abstraction, decomposition, composition,

style, and aesthetics.

16

Temporal Aspect

Architecture has a temporal aspect At any given point in time the system has only one

architecture A system’s architecture will change over time

17

Prescriptive vs. Descriptive Architecture

A system’s prescriptive architecture captures the design decisions made prior to the system’s construction It is the as-conceived 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

18

Architectural Evolution

When a system evolves, ideally its prescriptive architecture is modified first

In practice, the system – and thus its descriptive architecture – is often directly modified

This happens because of Developer sloppiness Perception of short deadlines which prevent thinking

through and documenting Lack of documented prescriptive architecture Need or desire for code optimizations Inadequate techniques or tool support

19

Implementation-Level View of an Application

Complex and virtuallyincomprehensible!

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

20

Deployment

A software system cannot fulfill its purpose until it is deployed Executable modules are physically placed on the

hardware devices on which they are supposed to run

The deployment view of an architecture can be critical in assessing whether the system will be able to satisfy its requirements

Possible assessment dimensions Available memory Power consumption Required network bandwidth

21

Software Architecture’s Elements

A software system’s architecture typically is not (and should not be) a uniform monolith

A software system’s architecture should be a composition and interplay of different elements Processing Data, also referred as information or state Interaction

22

Components

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

Definition A software component is an architectural entity that encapsulates a subset of the system’s functionality and/or

data restricts access to that subset via an explicitly defined

interface has explicitly defined dependencies on its required

execution context Components typically provide application-specific services

23

Connectors

In complex systems interaction may become more important and challenging than the functionality of the individual components

Definition A software connector is an architectural building block

tasked with effecting and regulating interactions among components

In many software systems connectors are usually simple procedure calls or shared data accesses Much more sophisticated and complex connectors are

possible! Connectors typically provide application-

independent interaction facilities

24

Examples of Connectors

Procedure call connectors Shared memory connectors Message passing connectors Streaming connectors Distribution connectors Wrapper/adaptor connectors

25

Configurations

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

Definition An architectural configuration, or topology, is a set of

specific associations between the components and connectors of a software system’s architecture

26

Architectural Styles

Certain design choices regularly result in solutions with superior properties Compared to other possible alternatives, solutions such as this are

more elegant, effective, efficient, dependable, evolvable, scalable, and so on

Definition An architectural style is a named collection of architectural design

decisions that are applicable in a given development context constrain architectural design decisions that are specific to a

particular system within that context elicit beneficial qualities in each resulting system

27

Architectural Patterns

Definition An architectural pattern is a set of architectural design

decisions that are applicable to a recurring design problem and parameterized to account for different software development contexts in which that problem appears

A widely used pattern in modern distributed systems is the three-tiered system pattern Science Banking E-commerce Reservation systems

28

Three-Tiered Pattern

Front Tier Contains the user interface functionality to access the

system’s services Middle Tier

Contains the application’s major functionality Back Tier

Contains the application’s data access and storage functionality

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

29

Architectural Models, Views, and Visualizations

Architecture Model An artifact documenting some or all of the architectural

design decisions about a system

Architecture Visualization A way of depicting some or all of the architectural design

decisions about a system to a stakeholder

Architecture View A subset of related architectural design decisions

30

Architectural Processes

Architectural design Architecture modeling and visualization Architecture-driven system analysis Architecture-driven system implementation Architecture-driven system deployment, runtime

redeployment, and mobility Architecture-based design for non-functional

properties, including security and trust Architectural adaptation

31

Stakeholders in a System’s Architecture

Architects Developers Testers Managers Customers Users Vendors

32

Software Architecture as a Discipline

Architecture does not only encompass the architectural description of a system (structure)

But also the activities of the architect Sometimes called the architecting of a system

This includes the work with all the stakeholders of the system

33

Influencing factors

Functional requirements

Non-functional requirements

Organizational factors

Cultural factors

Social factors

Arc

hite

ctur

e

34

The Architect’s Tasks and Roles

Architectures and architecture

disciplines

Architectural means

Organizations and individuals

Architectural methods and procedures

Architectural requirements

Architectural perspectives

Architect

35

Example: Small student Web project in Java

Architectures and architecture

disciplines

Architectural means

Organizations and individuals

Architectural methods and procedures

Architectural requirements

Architectural perspectives

Architect

• Programming language: Java

• Technologies: Hibernate, Web Server

• Concept: Object-Orientation

• UML for modeling in the documentation

• 2 Students: Programmers for functional building blocks

• 1 Student: Planning, documentation, and integration

• Teacher ~ Customer role

• Domain model is designed first• Refined to technical model• Mapped to platforms

(technologies)

• Different system views (domain view, logical view, realization view, …) are modeled using UML diagrams in the documentation

• Functional requirements

• Non-functional requirements: Extensibility, Changeability, System should be well tested

• Iterative Development• Agile Approach

36

Architectural Refinement

Domain Architecture

Technical Architecture

uses

Platform Architecture

uses

structures

structures

structures

Domain Components

Technical Components

uses

Platform Components

uses

37

Domain Architecture

The domain architecture reflects the problem space for which the system is developed Driven by the character of the domain Driven by the functional requirements

Example: In an order fulfillment system, domain components for

order entry, order management, customer management can be identified

38

Technical Architecture

The technical architecture is domain-neutral and deals with realizing the non-functional requirements Examples: Logging, Auditing, Security, Data Consistency,

Data Persistence, Transaction Management

Technical components use services of the platform They can be used platform-neutrally by domain

components

39

Platform Architecture

The platform architecture provides services for executing software components Can contain hardware and/or software components

Example: JEE is a component platform that uses itself various

operating system and hardware platforms

40

Other Architecture Disciplines in IT

Software architecture is only one of the architecture disciplines in IT

IT systems get more and more complex

Hence a specialization is necessary

Software Architecture

Network Architecture

Integration Architecture

Data Architecture

Security Architecture

System Management Architecture

Enterprise Architecture

Sys

tem

41

Components

This definition encompasses many different concepts, such as: Subsystems DLLs JavaBeans ActiveX Controls JEE-Components .NET-Components Components in scripting

languages (Tcl, Python, Perl)

...

A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to third-party composition.“

-- Clemens Szyperski, Component Software

ARCHITECTURAL REQUIREMENTS

42

43

Architecture is always a compromise

Marcus Vitruvius Pollio (born c. 80–70 BC, died after c. 15 BC) was a Roman writer, architect and engineer […]

Vitruvius is famous for asserting in his book De architectura that a structure must exhibit the three qualities of firmitas, utilitas, venustas —that is, it must be strong or durable, useful, and beautiful.

– http://en.wikipedia.org/wiki/Vitruvius

44

Architectural Requirements

The system must be designed to fulfill its requirements They must be properly

balanced They have a different

influence on the architecture

Architectural requirements can be seen as forces that influence and form a system design

Requirement

Requirement

Requirement

RequirementRequirement

Requirement

Requirement

Architecture

45

Requirements and their Properties

A requirement should be ... correct in the view of the users and stakeholders of the

system implementable with the given resources and in the given

environment unambiguously defined testable

A requirement ...... is a capability of a system needed by a user of the system to solve a problem or reach a goal. ... is a capability of a system to fulfill a contract, a standard, a specification, or another formal document.

46

Kinds of Architectural Requirements

Component-Level Requirements

System-LevelRequirements

Organization-LevelRequirements

Func

tiona

l Req

uire

men

ts

based on

based onN

on-F

unct

iona

l Req

uire

men

ts

Des

ign

Tim

e R

equi

rem

ents

Run

time

Req

uire

men

ts

Org

aniz

atio

nal E

nviro

nmen

t Req

uire

men

ts

abst

ract

ion

leve

l

47

Functional Requirements

Functional Requirements define the functionalities needed: They define what a system is supposed to accomplish For example they can be modeled using use cases

Modeler

Create Diagram

Save Diagram

Open Diagram

Create Class Diagram

Create Use Case Diagram

Create Object Diagram

Create Sequence Diagram

Create Activity Diagram

Example: Use Case Diagramfor a modelling tool

48

Example using the Basic Use Case Template by Cockburn

Use Case: 5 Buy GoodsCHARACTERISTIC INFORMATIONGoal in Context: Buyer issues request directly to our company, expects goods shipped and to be billed.Scope: CompanyLevel: SummaryPreconditions: We know Buyer, their address, etc.Success End Condition: Buyer has goods, we have money for the goods.Failed End Condition: We have not sent the goods, Buyer has not spent the money.Primary Actor: Buyer, any agent (or computer) acting for the customerTrigger: purchase request comes in.MAIN SUCCESS SCENARIO1. Buyer calls in with a purchase request.2. Company captures buyer’s name, address, requested goods, etc.3. Company gives buyer information on goods, prices, delivery dates, etc.4. Buyer signs for order.5. Company creates order, ships order to buyer.6. Company ships invoice to buyer.7. Buyers pays invoice.EXTENSIONS3a. Company is out of one of the ordered items:3a1. Renegotiate order.

4a. Buyer pays directly with credit card:4a1. Take payment by credit card (use case 44)7a. Buyer returns goods:7a. Handle returned goods (use case 105)SUB-VARIATIONS1. Buyer may use phone in, fax in, use web order form, electronic interchange7. Buyer may pay by cash or money order check credit cardRELATED INFORMATIONPriority: topPerformance Target: 5 minutes for order, 45 days until paidFrequency: 200/daySuperordinate Use Case: Manage customer relationship (use case 2)Subordinate Use Cases:Create order (use case 15)Take payment by credit card (use case 44)Handle returned goods (use case 105)Channel to primary actor: may be phone, file or interacticeSecondary Actors: credit card company, bank, shipping serviceChannels to Secondary Actors:OPEN ISSUESWhat happens if we have part of the order?What happens if credit card is stolen?SCHEDULEDue Date: release 1.0Sample in table format: From:

http://alistair.cockburn.us/Basic+use+case+template

49

Non-functional Requirements

Non-functional requirements (NFR) define expectations or criteria that can be used to judge the operation of a system

NFRs with direct implications: qualities or quality attributes Examples: Performance, Extensibility, Reusability, ...

NFRs with indirect implications: Standards, parameters, or conditions that must be considered or reached Examples: Budget, Regulations, Legislatives, Business

Policies

50

Relevance of NFRs

Fulfilling the NFRs is essential to the acceptance of the functionality of the system

Nevertheless NFRs are often neglected The focus is often clearly on the functional requirements Major task of the architect: Sensitize the stakeholders

for the importance of the NFRs NFRs should be considered even in early phases of

architecting

ARCHITECTURAL PRINCIPLES

51

52

Architectural Principles

Given the many influencing factors on an architecture: How to decide whether an architecture is “good”? It is difficult to say that an architecture is “good” or “bad”

per se It just fulfills its functional and non-functional

requirements better or worse

But there are principles that can help when designing a software architecture

53

Coupling

Coupling measures the dependencies among the components of an architecture Characterizes the interactions of the components Can be measured by counting the relationships

among components There are many kinds of coupling that can be

measured, such as: Coupling of classes Coupling of runtime objects Coupling of modules or components Coupling of HW components

54

Principle of Loose Coupling

The coupling of components should be kept as low as possible

1st Goal: Keep the complexity of structures low The less a components is coupled with other

components, the easier it is understandable on its own

2nd Goal: Increase the changeability of the architecture The less components are affected by a change in a

component, the easier it is to do a change locally in a component without looking at the environment

55

Cohesion

Cohesion measures the dependencies within a component A class consists of methods and variables Components can have sub-components

56

Principle of High Cohesion

The cohesion of a component should be as high as possible

As in loose coupling, the goal is to support understandability and changeability of components: If a component contains all elements that are needed to

understand or change it, it can be understood or changed without looking at other components

57

Interdependence: Coupling and Cohesion

Most often: the higher the cohesion of individual components, the lower the coupling between the components

58

Principle of Design for Change

Design for change means to plan for foreseeable changes when designing an architecture

Requirements that are likely to arise can be considered during planning Inconsistencies and unclear parts of requirement

specifications can requirements that are likely to arise Experiences from designing similar architectures can be

considered when designing a new architecture

59

Risks of Design for Change

A more changeable design can also bear risks More development time High costs for more elaborate designs More implementation effort

More flexible architectures often consume more resources (memory, performance)

60

Separation of Concerns Principle

Different aspects of a problem should be separated from each other, and each aspect of the problem should be treated on its own

Main kind of area of Separation of Concerns in SW architecture: Modularization Separate a software system into a structure of

components

61

Other Kinds of Separation of Concerns in SW Architecture

Separation of requirements Separation of a complex architecture model into

views Separation of organizational responsibilities Separation of process into sub-processes Multi-dimensional separation of concerns (Aspect-

Orientation)

62

Information Hiding Principle

To a client present only the really necessary parts of the whole information and hide all the rest

Goal: Reduction of the complexity of a SW architecture.

Example: Hiding implementation details behind an interface

63

Example: Information Hiding using the Facade Pattern

64

Other Important ArchitecturePrinciples

Abstraction Principles are using abstractions to make a complex problem understandable by identifying important aspects and neglecting less important ones E.g. Abstraction Principles with a focus on interfaces:

Explicit Interfaces Segregation of Interface and Implementation

Many other more special architecture principles: Modularization Principle (see above) Traceability Principle Self Documentation Principle Incremental Evolution Principle

65

Many thanks for your attention!

Schahram Dustdar

Distributed Systems Group

TU Wien

http://www.infosys.tuwien.ac.at/Staff/sd