Introduction to Software Architecture - · PDF fileIntroduction to Software Architecture ... Requirements & Architecting Design Implementation Testing Deployment ... architecturally

Introduction to Software

Architecture

Imed Hammouda

Chalmers | University of Gothenburg

Introduction to Software Architecture

Who am I?

• Associate Professor of Software Engineering, previously in Tampere, Finland

• Research interests

– Software Architecture, Open Source, Software Development

Methods and Tools, Variability Management

• Developing and supporting open software architectures

• Studying socio-technical dependencies in software development

• Software ecosystems

• Coordinates:

[email protected], [email protected]

• Room 416, floor 4, Jupiter building, Campus Lindholmen

• Phone +46 31 772 60 40

2


• What is software architecture?

• Architectural drivers

• Addressing architectural drivers

• Architectural views

• Stakeholders and concerns

• Example system

3


What is Software Architecture?

• Software Architecture is the global organization of a software system, including

– the division of software into subsystems/components,

– policies according to which these subsystems interact,

– the definition of their interfaces.

T. C. Lethbridge & R. Laganière

4



• "The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them."

5

Len Bass



• “fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution.”

ISO/IEC/IEEE 42010

http://www.iso-architecture.org/ieee-1471/defining-architecture.html

6


Architectural Information Increases

• Add your own definition:http://www.sei.cmu.edu/architecture/start/glossary/community.cfm

7

Architecture is everythingeverythingeverythingeverything that a (group of)

person(sperson(sperson(sperson(s) needs to let a large teamteamteamteam successfully

develop a (family of) productsproductsproductsproducts

Rob van Ommering, Philips Natlab


Levels of Architecture*

8* Mowbray and Malveau

Macro-architecture Frameworks

Micro-architecture Design patternsObserver

update()

Subjectattach(Observer)detach(Observer)

notify()

ConcreteObserver

update()

ConcreteSubject

getState()

forall o in observers

o.update()

System architecture Subsystem

Enterprise architecture

Application architecture Application


Types of Architecture

9

Mobile System

Operating

SystemMessagingDisplay

Screenshape

Color capacity

Screensize

Keypad

Keypad

type

Camera

SymbianLinux

Connectivity

FaxSMS MMS Email BluetoothCable Infrared Internet

Web

S60 S80Simultaneous

Key press

No Simultaneous

Key press

Key press

type

Large Medium Small

Rationale:

”Large” for game applications

Composition Rule:

”Web” requires ”Internet”

Single Product

Product family


Increasing Amount of Software in

Systems

10


The Importance of Architecture

11

Requirements &

Architecting

Design

Implementation

Testing

Deployment

Operation

SW fault repair

costs

≥ 100x

1x

10% of the lifecycle determines

90% of the costs and risks



• “If a project has not achieved a system architecture, including its rationale, the project should not proceed to full-scale system development. Specifying the architecture as a deliverable enables its use throughout the development and maintenanceprocess”

12

Barry Boehm



• Software architecture:

– provides a communication among stakeholders

– captures early design decisions

– acts as a transferable abstraction of a system

– defines constraints on implementation

– dictates organizational structure

– inhibits or enables a system’s quality attributes

– is analyzable and a vehicle for predicting system qualities

– makes it easier to reason about and manage change

– helps in evolutionary prototyping

– enables more accurate cost and schedule estimates

13


What Drives Software Architecture?

• System requirements:

– Functional needs (what the system should do)

– Quality needs (properties that the system must possess such as

availability, performance, security,…

• Design constraints

– Development process

– Technical constraints

– Business constraints

– Contractual requirements

– Legal obligations

– Economic factors

14


What Drives Software Architecture?*

Plain Old Telephone System

• Feature:

– Call subscriber

• Architecture:

– Centralized hardware switch

• Good qualities:

– Works during power shortage

– Reliable

– Emergency calls get location

information

15

*George Fairbanks

Skype

• Feature:

– Call subscriber

• Architecture:

– Peer-to-peer software

• Good qualities:

– Scales without central

hardware changes

– Easy to add new features

– Easy deployment


Architectural Drivers

• Architectural drivers are the design forces that will influence the early design decisions the architects make

• Architectural drivers are not all of the requirements for a system, but they are an early attempt to identify and capture those requirements, that are most influential to the architect making early design decisions.

� architecturally significant requirements

Archietcts pay more attention to qualities that arrisefrom architecture choices

16


Functional Requirements

• Functional requirements specify what the software needs to do. They relate to the actions that the product must carry out in order to satisfy the fundamental reasons for its existence.

• Business Level: defines the objective/goal of the project and the measurable business benefits for doing it.

• User Level: user requirements are written from the user's point-of-view.

• System Level: defines what the system must do to process input and provide the desired output.

17


Functional Requirements

• MoSCoW Method:

– M - MUST: Describes a requirement that must be satisfied in the

final solution for the solution to be considered a success.

– S - SHOULD: Represents a high-priority item that should be

included in the solution if it is possible. This is often a critical

requirement but one which can be satisfied in other ways if strictly

necessary.

– C - COULD: Describes a requirement which is considered desirable

but not necessary. This will be included if time and resources

permit.

– W - WON'T: Represents a requirement that stakeholders have

agreed will not be implemented in a given release, but may be

considered for the future.

18


Functionality and Software Architecture

• It is the ability of the system or application to satisfy the purpose for which it was designed.

• It drives the initial decomposition of the system.

• It is the basis upon which all other quality attributes are specified.

• It is related to quality attributes like validity, correctness, interoperability, and security.

Functional requirements often get the most focus in a development project. But systems are often redesigned, not because of functional requirements.

19


Quality Attributes

• A quality attribute is a measurable or testable property of a system that is used to indicate how well the system satisfies the needs of its stakeholders.*

• A quality requirement is a specification of the acceptable values of a quality attribute that must be present in the system.

• Quality attributes should be:

– Not subjective

– In sufficient detail

– Of a value and context (e.g: 180 seconds)

20

*Bass Clements Kazman


Quality Attributes*

21

Attribute Description

Performance How fast does it respond or execute?

Availability Is it available when an where I need to use it?

Safety How well does it protect against damage?

Usability How easy it is for people to learn and use?

Interoperability How easily does it interconnect with other systems?

Integrity Does it protect against unauthorized access and data loss?

Installability How easy is it to correctly install the product?

Robustness How well does it respond to unexpected operating conditions?

Reliability How long does it run before experiencing a failure?

Recoverability How quickly can the user recover from a failure?

*EnfocusSolutions


Quality Attributes

22

Attribute Description

Recoverability How quickly can the user recover from a failure?

Efficiency How well does it utilize processor capacity, disk space,

memory, bandwidth, and other resources?

Flexibility How easily can it be updated with new functionality?

Maintainability How easy is it to correct defects or make changes?

Portability How easily can it be made to work on other platforms?

Reusability How easily can we use components in other systems?

Scalability How easily can I add more users, servers, or other

extensions?

Supportability How easy will it be support after installation?

Testability Can I verify that it eas implemented correctly?


ISO/IEC 25010:2011 Quality Model

23

Functional suitability

Functional completeness

Functional correctness

Functional appropriateness

Compatibility

Co-existence

Interoperability

Reliability

Maturity

Availability

Fault tolerance

Recoverability

Maintainability

Modularity

Reusability

Analysability

Modifiability

Testability

Performance efficiency

Time behaviour

Resource utilization

Capacity

Usability

Appropriateness recognizability

Learnability

Operability

User error protection

User interface aesthetics

Accessibility

Security

Confidentiality

Integrity

Non-repudiation

Accountability

Authenticity

Portability

Adaptability

Installability

Replaceability


ISO/IEC 25010:2011 Quality in Use

Characteristics

24

Effectiveness Efficiency

Satisfaction

Usefulness

Trust

Pleasure

Comfort

Freedom from risk

Economic risk mitigation

Health and safety risk mitigation

Environmental risk mitigation

Context coverage

Context completeness

Flexibility


Quality Attributes & Software Architecture

• Different architectural styles address different sets of quality attributes and to varying degrees

– Architecture decides range of quality possibilities

• The specification of quality attributes affects the architecturalstyle of the system

– Architectures are evaluated w.r.t quality attributes

• Not all quality attributes are addressed by the architectural design, e.g. some aspects of usability (e.g. layouts) and some aspects of performance (e.g. algorithms)

• Impossible to maximize all quality attributes at once

– Tradeoff: More of this � less of that

– Performance versus security

– Everything versus time-to-market (or cost)

25


Specifying Quality Requirements

• A Quality Attribute Scenario is a quality attribute specificrequirement.

– Stimulus – a condition that needs to be considered

– Source of stimulus (e.g., human, computer system, etc.)

– Environment - what are the conditions when the stimulus occurs?

– Artifact – what elements of the system are stimulated.

– Response – the activity undertaken after arrival of the stimulus.

– Response measure – when the response occurs it should be

measurable so that the requirement can be tested.

26


Specifying Quality Requirements

27

Reliability

Stimulus Database unresponsive/crash

Source of Stimulus System

Environment Runtime

Artifact Database

Response Detect the failure, inform the system, use redundant database server

Response Measure Degraded mode not to exceed 5 mins


Addressing Quality Attributes

• Quality attributes can be addressed through different (architectural) tactics:

– Architectural styles: for example pipes-and-filters, MVC,

blackboard, publish-subscribe,…

– Design patterns: for example Abstract Factory, Adapter,

Command, Observer,…

– Tactics: A design decision: for example encapsulate, limit access

– Converting quality requirement to functionality: for example

exception handling, logging

• Quality requirements can be distributed at the system level tothe subsystems or components that make up the system.

28


Example Architectural Style

29

Remote Interaction System

Pipes and Filters


Example Design Pattern

30

display

predict

Statistics

Observer


Example Architectural Tactics

31


Evaluating Quality Attributes

• Quality attributes can be evaluated through:

– Scenario-based evaluation: for example change scenarios for

assessing maintainability

– Simulation: for example Prototyping is a form of simulation where

a part of the architecture is implemented and executed in the actual

system context.

– Mathematical modeling: for example, checking for potential

deadlocks.

– Experience-based assessment: this is based on subjective

factors like intuition and expertise of software engineers.

32


Views

33


Views

• A view is a projection of a model showing a subset of itsdetails

– Think of a Master Model that has all the details of the system

(master model may not concretely exist)

– Views are projections of the master model

• A view is a representation of the whole system, as seen through the prism of specific concerns. A view consists of one or more models that represent it.

34

Requirements

Concern

Identifier

Business Logic Persistence

Security Logging[Laddad 2002]


Stakeholders and Concerns

• A stakeholder is any person with interest in the project. Example: customers, developers, maintainers, and management.

• A concern is any matter of interest in a software system

– Architectual (e.g. security) versus non-architectural (e.g. single

responsibilities)

– Reifiable (e.g. functional feature) versus non-reifiable (e.g. usabililty

attributes)

• Example Concern categories:

– Functional requirements

– Quality attributes

– Business issues

– User experience

35


Viewpoints/Viewtypes

• A viewpoint is a pattern or generalization of a view. The viewpoint defines the rules for the viewpoint.

• Viewpoints are selected according to the concerns of the stakeholders.

• A viewpoint repository or viewpoint library is a name for the set of viewpoints that an architect knows about and which she can use to find a suitable viewpoint suitable for her immediate needs and interests.

• Example frameworks: 4+1 View Model, SEI, Zachmann, SoniHofmeister Nord

36


’4 + 1’ View Model*

37

* Philippe Kruchten


’4 + 1’ View Model*

• Logical

– Focus: Functional requirements of the system.

– Contents: Class diagrams, Sequence diagrams, Layer diagrams.

• Development (implementation)

– Focus: Static organization of the software in its development environment

– Contents: Component diagram, Package diagrams.

• Process

– Focus: Runtime behavior of the system, such as the system processes and

communication, concurrency, performance and scalability.

– Contents: Activity diagrams.

• Physical (Deployment)

– Focus: System Engineer’s perspective, looking at the system topology,

deployment and communication.

– Contents: Deployment diagrams.

• Scenarios

– Focus: Use cases for illustrating and validating the architecture.

– Contents: Use case diagrams.

38


The ”Sad” Reality

39


Example System

• Solutions for Open Land Administration (SOLA) is a 3 year project to develop open source software that supports cadastreand registration functions in a typical land office.

• Plan is to Support the pilot customization and implementation of the software in Ghana, Nepal and Samoa.

• The project started in June 2010. Pilot customization has been done in the first quarter of 2012.

40

FLOSS SOLASolutions for Open Land Administration

http://www.flossola.org/


SOLA: Business Needs

41

Identifier Description

BN-1 Reduce processing times for applications for registration and cadastre changes

BN–2 Provide better access to land information and improved delivery of registration and cadastre related services

BN-3 Ensure an acceptable of quality is maintained with respect to

registration and cadastre transactions and the associated official

record of land, properties, rights, restrictions and rightholders(including ownership)

BN-4 Reduce the processing effort for the maintenance of the official

record of land, properties, rights, restrictions and rightholders and the cadastre

BN-5 Provide the means of monitoring and managing the processing of

applications for registration and cadastre changes (including performance reporting)


SOLA: Functional Requirements

• Case Management

• Spatial Capability (View & Spatial Editing)

• Rights Management

• Cadastre Management

• Business Rule Management

• Generate Certificates

• Access to Property & Cadastre Information

• Digital Archive

• Electronic Data Interchange

• Auditing & Logging

• System Administration

42


SOLA: Functional Requirements

43

Identifier Capability Feature Priority

1 – Neutral

10 - Vital

Traces To BN

FN-1 Display.

Service

Requirements

Client explains their situation and

Public Counter Officer determines the

relevant service (including transaction

type). Public Counter Officer enters

type of service and system presents a

checklist of supporting documents

required for the selected service with the option to print this out for the client

8 BN - 2

FN-2 Log.serviceEnquiry

When Public Counter Officer enters

type of service (in FN – 1

Display.service Requirement), system

logs a service enquiry for a particular

type of service has been made by the Public Counter Officer.

5 BN - 5


Quality Attributes for SOLA

• System Security

• System Performance

• Software Maintainability

• System Scalability

• Software Deployment

• Data Migration

• Low Power Environments

44


Quality Requirements for SOLA

45

Identifier Feature Description Priority

QL-1 The system will capable of supporting multiple languages and

compatible with Unicode 3.0+ and UTF-8 encoding.

10

QL-2 The system will support optimistic concurrency control for real time

transaction processing.

10

QL-3 The system will support a rules engine that will allow definition and maintenance of business rules.

6

General Quality Requirements


Quality Requirements for SOLA

46

Identifier Feature Description Priority

QL-35 The system will be capable of supporting peak user volumes up to

100 users

10

QL-36 The system will process and respond to login requests in less than 5

seconds 90% of the time when subjected to peak user volumes.

10

QL-37 The system will process and respond to general transactions in less

than 5 seconds 90% of the time when subjected to peak user

volumes.

10

QL-38 The system will process and response to process intensive

transactions in less than 8 seconds 90% of the time when subjected

to peak user volumes.

10

QL-39 The system will perform document generation in less than 30 seconds 90% of the time when subjected to peak user volumes.

10

Performance Requirements


Design Constraints for SOLA

• Open source

• Portability

• Low power environments

• Compatibility with national e-strategies (Ghana, Samoa, and Nepal)

47


Stakeholders for SOLA

• Software Development Team

• Citizens

• Land Administration Agencies

• Goverments

• Commercial Companies

• Open Source Communities

• Universities

• NGO’s

48


SOLA: Overview

49

Da

taP

rese

nta

tion

Other Clients

Customizations

SOLA Desktop

SO

LA

Se

rvic

es

Security

Au

ditin

gA

uth

en

ticationWeb Sites Other Clients

SOLA Database

Sch

em

a

EJB

Se

rvic

e

Other DBs

Sch

em

a

Sch

em

a

Sch

em

a

EJB EJB EJB EJB

Se

rvic

e

Se

rvic

e

Se

rvic

e

Se

rvic

e

Se

rvic

e

Se

rvic

e

Se

rvic

e

Au

tho

riza

tio

n


SOLA: Logical View

50

External Systems

+ Email Server

+ Print Server

+ Scanner

«layer»

Data Layer

+ ETL Tool

+ PostGIS Template

+ SOLA Database

«layer»

Serv ices Layer

+ Boundary

+ Services Common

+ EJBs

«layer»

Presentation Layer

+ Geotools UI

+ SOLA Desktop

+ SOLA GIS

Common

+ Help

+ Messaging

+ Rules

+ Util ities


SOLA: Logical View

51

«system»

SOLA Desktop

+ Beans

+ Cache

+ Configuration

+ Converters

+ Desktop

+ Forms

+ Localization

+ Renderers

+ Reports

+ Resources

+ Tasks

+ Uti li ties

Geotools UI

+ Data

+ Layers

+ Map Actions

+ Map Tools

+ UI

SOLA GIS

+ Data

+ GIS

+ Layers

+ Map Actions

+ Tools

+ UI

Messaging

+ Localized Message

+ Message Util ity

+ Client Message Bundle

+ GIS Message Bundle

+ Server Message Bundle

(from Common)

Help

+ Help Uti li ty

+ Default Helpset

(from Common)

Web Serv ice Clients

+ Administration Client Impl

+ Case Management Client Impl

+ Digital Archive Client Impl

+ Reference Data Client Impl

+ Search Client Impl

+ Security Client Impl

+ Spatial Client Impl

+ WS Client Factory

+ Administration Client

+ Case Management Client

+ Digital Archive Client

+ Reference Data Client

+ Search Client

+ Security Client

+ Spatial Client

+ Generated Sources

+ Security Configuration

(from Boundary)

Utilities

+ Date Uti li ty

+ File Uti l ity

+ Log Uti l ity

(from Common)


SOLA: Process View

52


SOLA: Physical View

53

Application Serv erDB Serv er

Desktop PC (SOLA User)PostgreSQL 9.0

SOLA Database

PostGIS

Glassfish 3.1.1 / Metro

SOLA Services EAR

Jav a 7 (JDK)

SOLA Desktop

Jav a 7 Web Start (JRE)

SOLA Desktop Web Start

Internet Zone

JDBCHTTP

HTTP / JNLP


SOLA: Scenarios View

54

UC01 Serv ice

Enquiry

UC03 Lodge

Application

UC04 Rev iew Quality

UC05 Register or

Approv e

UC06 Ceate New

Property

Land Office Client

Public Counter Officer

Notification Serv iceQuality Rev iewer

Registrar or Approv ing

Officer

Land Officer Specialist

Archiv ist

Architecturally Significant Use Cases


SOLA: Scenarios View

55

Search Results

Screen

Public Counter Officer Search Criteria

Screen

Subsystem

Control ler

Search and EDI

Service

SOLA DatabaseSearch Service

Agent

Case Management

Service

Case Management

Service Agent[Enter criteria and click

Search]:Search(Criteria) :

SearchResults

Search(Criteria) :SearchResultsTranslate(Criteria)

:CriteriaDTO

Search(CriteriaDTO) :SearchResultsDTOTranslate(CriteriaDTO) :

Criteria

Search(Criteria) :Results

Translate(Results) :

ResultsDTO

Translate(SearchResultsDTO) :

SearchResultsDisplay(SerachResults)

[Select Result]:

Get(ResultId) :ResultDetailGet(ResultId) :ResultDetailDTO

Get(ResultId) :ResultDetail

Translate(ResultDetail) :

ResultDetailDTO

Translate(ResultDetailDTO) :

ResultDetail

Display(ResultDetail)


SOLA: Data View

56

SOLA Database

+ Address

+ Administrative

+ Application

+ Cadastre

+ Document

+ Extra Spatial Functions

+ Party

+ Source

+ System

(from Data Model)

SOLA Database Schemas


SOLA: Security View

57

Glassfish / Metro

SOLA Desktop SOLA Database

Log4J Serv er Log

Log4J Desktop Log

SOLA Serv ices

+ Administrative

+ Case Management

+ Cadastre

+ Document Archive

+ Reference Data

+ Search

+ Security

+ Spatial

Server Certificate

(Public)

Server Certificate

(Private)

Database User Credentails,

No Transport SecurityUser Credentials,

Message Security

Exceptions &

Faults

No Credentials, No

Transport Security

DB Exceptions

DB Audit

Exceptions

Service Faults

SOLA Security Model


Wrap-up: IEEE-Std-1471 Conceptual Framework

58

Rationale

Architectural Description

Model

View

Concern

Architecture System

Environment Mission

Viewpoint

LibraryViewpoint

Stakeholder

provides

1..*aggregates

participates in

consists of

participates in

1..*

1..*organized by

establishes methods for

described by

selects1..*

used to cover1..*identifies

1..*

has is important to

1..*

1..*

identifies 1..*

1..*

has

conforms to1..* has source

has an

1..*fulfillsinhabits

influences

1..*

is addressed to


Wrap-up

• Architecture should be the product of a single architect or a small group of architects with an identified leader.

• Architect team should have functional requirements for the system and an articulated prioritized list of quality attributes that the architecture is expected to satisfy.

• Architecture should be well documented, and circulated and reviewed by system stakeholders.

• Architecture should be analyzed for applicable quantitative measures and formally evaluated for quality attributes before it is too late to make changes to it.

• Architecture should lend itself to incremental refinement and implementation.

59

Introduction to Software Architecture 60

Tack så mycket!

Frågor?

Documents

Introduction to Software Architecture - · PDF fileIntroduction to Software Architecture ... Requirements & Architecting Design Implementation Testing Deployment ... architecturally