L01: Intro to Software Architecture

Vittorio Cortellessa & Henry Muccini

DISIM Department, University of L’Aquila

vittorio.cortellessa@univaq.it;henry.muccini@univaq.it

The material in these slides may be freely reproduced

and distributed, partially or totally, as far as an explicit

reference or acknowledge to the material author is

preserved.

SEA Group

preserved.

Intro to Software Testing

Structural Testing

Model-based Testing

Architecture-based Testing

Lab

Intro to SA

Lab

SA style

ADLs

Design Decisions

Views/Viewpoints

SEA Group

Non Functional S.E.

Performance modeling

Performance analysis

UML

UML Profiling

Lab

Views/Viewpoints

SEA Group

SEA Group

SEA Group

SEA Group

SEA Group

Software Architecture

The Software Architecture is the earliest modelof the whole software system created along the software lifecycle

“Traditional” definition:

A set of components and connectors communicating through

SEA Group

→A set of components and connectors communicating through interfaces

“Recent/Future” understanding:

→A set of architecture design decisions taken to generate the architecture artifact

→Focus on set of Views and Viewpoints, looking at stakeholders and their concern

Software Architecture definitionsPerry and Wolf, ’92 (aspects):

→“Architecture is concerned with the selection of architectural elements, their interactions, and the constraints on those elements and their interactions necessary to provide a framework in which to satisfy the requirements and serve as a basis for the design.”

→Elements are divided into processing elements, data elements and connection elements

SEA Group

Garlan and Shaw, ’93 (elements):

→ Architecture for a specific system may be captured as “a collection of computational components - or simply components - together with a description of the interactions between these components - the connectors -”

Sommerville, 7th edition, ’04 (process):

→ The design process for identifying the sub-systems making up a system and the framework for sub-system control and communication is architectural design. The output of this design process is a description of the SA.

Application Example

“We want to build a software system that allows

people to vote electronically.

→ The citizen goes to the electoral place, and she votes using

a hw/sw device.

→ The vote is stored locally and automatically sent to other

SEA Group

→ The vote is stored locally and automatically sent to other

computers.

→ The citizen identity must be validated by the system

→ …”

Basic Requirement Example

The voting system must satisfy the following

requirements:

→ One voter – one vote (no more than one vote for voter)

→ The voter can vote in only one previous designated voting

place

SEA Group

place

→ The voter must be identified by the election officials at the

voting place

─ The citizen identity must be validated by the system

→ It is not possible to trace the votes back to the voters

→ The election officials can’t read the results, guarantying that

the results are unknown until the end of the voting process

Example

SEA Group

A modeling language

(e.g. UML)

Software

modeled in

Process

Requirements

Drives

SEA Group

Software

Architecture

Implementation

modeled in

Traceability

Analysis

Advantages of explicit architecture

System analysis

→Analysis of whether the system can meet its functional and non-functional requirements is possible.

Large-scale reuse

→The architecture (or part of it) may be reusable across a range of systems.

SEA Group

range of systems.

Stakeholder communication

→Architecture may be used as a focus of discussion by system stakeholders.

SA History

1992 and 1993: SA is recognized as an independent area of research;

→ What is SA

1993-1995: SA described through box and line (i.e. informal) diagrams;

1995-1997: Architectural Description Languages (ADLs) are introduced to formally describe SA;

→ SA and Specification (with ADLs)

1997-2003:

SEA Group

1997-2003:

→ more interest on dynamic aspects of SA;

→ SA recognized as a valid tool to deal with various aspects of complex, concurrent, real systems;

→ SA and UML

→ SA and Analysis

2003-today:

→ SA vs CBSE, AOP, SOA, etc…

→ Design Decisions, Viewpoints

Civil Architecture vs Software Architecture�

Civil :

BricksRoofChimney top

» Software :

- Three types of components

- Multiple instances of the type “brick”

SEA Group

» Civil :

- Concrete

- Construction Rules

» Software :

- Connectors

- Assembly constraints

In general terms…

SA describes (in a more or less “formal” notation) how a system is

structured into components and connectors…

→Components

→Connectors

→Channels and Ports

SA Structure (topology)

SEA Group

… and how these components interact

→ Scenarios

→State Diagrams

→…

SA Dynamics (behavior)

General workflow

SEA Group

Static Description

→Components

→Connectors

→Interfaces

SEA Group

Components

A component is a building block that is …

→A unit of computation or a data store, with an interface

specifying the services it provides and requires

→A unit of deployment

→A unit of reuse

SEA Group

→A unit of reuse

─ e.g., client, server, database, filters, ...

C1S1S2S3

S’xS’Y

provided services

required services

Components vs Objects

The level of abstraction is usually different

Size

→Objects tend to be small

→Components can be small (one object) or large (a library of

objects or a complete application)

SEA Group

objects or a complete application)

An architectural component may be implemented by

several objects

Lifecycle

→Objects are created and destroyed constantly

→Components are created and destroyed infrequently

Connectors

A connector is a building block that enables interaction among components

→Events

→Client/server middleware

→Messages and message buses

→Shared variables

→Procedure calls (local or remote)

SEA Group

→Procedure calls (local or remote)

→Pipes

Connectors may be implicit or explicit

→Connectors sometimes are just channels

→Connectors sometimes have their own logic and complexity

Connectors may be endogenous or exogenous

Components and Connectors

A component is (or should be) independent of the context in which it is used to provide services

A connector is (or should be) dependent on the context in which it is used to connect components

SEA Group

context in which it is used to connect components

Connectors sometimes are modeled as special kinds of components

Interfaces

An interface is the external connection of a component (or connector) that describes how to interact with it

Provided and required interfaces are important

Spectrum of interface specification

SEA Group

Spectrum of interface specification

→ Loosely specified (events go in, events go out)

→ API style (list of functions)

→ Very highly specified (event protocols across the interface in CSP)

Architecting: example

GUI

FeedServiceFeedServiceCommon

Action

NewsFeeder

Action

Admin

Action

Transfer

Object DATABASE

Trasformation

SEA Group

Factory

FeedDelegate

POJOs

NewsFeeder

DAO

FeedDAO

NewsFeederDAO

FeedDAO

FeedDelegate

ValidatorService

NewsFeeder

DelegatePOJOs

NewsFeederDelegate

Browser(html

javascript)

Web

Services

Trasformation

Validation

BusinessFactory

Validation

Service

Architecting: example

SEA Group

Dynamic Description Behavioral models

SEA Group

SA dynamics

The SA dynamics is expressed in terms of component interactions via connectors

•Labeled Transition Systems

•Automata

SEA Group

•Automata

•UML StateCharts, Sequence Diagrams, Activity Diagrams

•State Diagrams

•Message Sequence Charts

•…

Customer Interface

Customer Process

Web Server

Cart Server

AN EXAMPLE : E-COMMERCE SYSTEM

SEA Group

Customer Server

Order Server

Catalog ServerDelivery Order

Process

SA Static Description

CustomerInterface

Registered Customer

CustomerProcess CatalogServer

Catalog DB

BrowseCatalog

BrowseCatalog

ReadStatus

AN EXAMPLE : E-COMMERCE SYSTEM

SEA Group

SA Dynamic Description : Browse Catalogue Sequence Diagram

Catalog DBInvolved

Catalog Page

Output Page

Catalog Info

AN EXAMPLE : E-COMMERCE SYSTEM

SEA Group

SA Dynamic Description : Place Order Sequence Diagram (success)

AN EXAMPLE : E-COMMERCE SYSTEM

SEA Group

SA Dynamic Description : Place Order Sequence Diagram (empty cart)

Architectural Elements vs Design Elements

“Architecture is concerned with the selection of architectural elements, their interactions, and the constraints on those elements and their interactions necessary to provide a framework in which to satisfy the requirements and serve as a basis for the design.”

“Design is concerned with the modularization and

SEA Group

“Design is concerned with the modularization and detailed interfaces of the design elements, their algorithms and procedures, and the data typesneeded to support the architecture and to satisfy the requirements.”

(Perry & Wolf 92)

Architectural Elements vs Design Elements

“The architecture of a software system defines that

system in terms of computational components and

interactions among those components. … In addition

to specifying the structure and topology of the

system, the architecture shows the correspondence

SEA Group

system, the architecture shows the correspondence

between the requirements and elements of the

constructed system, thereby providing some

rationale for the design decisions.”

(Shaw & Garlan 96)

Architecture and NF characteristics…

Performance

→Localise critical operations and minimise communications.

Security

→Use a layered architecture with critical assets in the inner layers.

Safety

→Localise safety-critical features in a small number of sub-systems.

SEA Group

→Localise safety-critical features in a small number of sub-systems.

Availability

→Include redundant components and mechanisms for fault tolerance.

Maintainability

→Use fine-grain, replaceable components.

… may originate architectural conflicts

Using large-grain components improves performance

but reduces maintainability.

Introducing redundant data improves availability but

makes security more difficult.

Localising safety-related features usually means more

SEA Group

Localising safety-related features usually means more

communication so degraded performance.

Architectural styles

The architectural model of a system may conform to a

generic architectural model or style.

The awareness of these styles can simplify the problem

of defining system architectures.

There is a strict relation between the ADLs and the

SEA Group

There is a strict relation between the ADLs and the

style adopted.

However, most large systems are heterogeneous and

do not follow a single architectural style.