Ivano Malavolta

Software systems engineering

PRINCIPLES

Hello

Software Architecture & Model-Driven Engineering

applied to

Autonomous drones

Mobile applicationsWeb technologies

If you think good architecture is expensive, try bad architecture.

... Brian Foote and Joseph Yoder

Course website

http://lore.com/SSS2016

BF9M2X

Course overviewModule name #hours Instructor

Introduction to the course 2 Inverardi

Software engineering principles and research 4 Malavolta

Software development process 2 Malavolta

Eclipse IDE 2 Iovino

Collaborative software development 1 Malavolta

Model-based design and development 8 Iovino

Software architecture 6 Malavolta

LAB 2 Iovino, Malavolta

Modern development paradigms 2 Malavolta

Principles of software testing and dependability 2 Bertolino

Homework 1

Christmas break

Homework 2

Homework 1

Tasks• create an AADL specification describing the architecture of a chosen system• write an Acceleo program or an ATL transformation that takes as input the

AADL model and produces some report or other artifact• write a report describing the performed activities

Goals• to understand what are the advantages of SE principles like abstraction and

separation of concerns• to concretely understand what architectural modeling means• to be exposed to concerns and issues related to dependability• to understand how to use MDE techniques like model transformations and

code generators

Tentative deadline20/12/2015

Homework 2

Tasks• pick a set of articles related to a chosen research theme• carefully read them and explore the state of the art about the research

theme• write a report about your findings• make a brief presentation to the classroom

Goals• to have the chance to study a specific area of software engineering that

may be of interest to each student• to be exposed to a specific problem in software engineering• to start being trained in reading and writing scientific papers

Tentative deadline15/01/2016

Research themes will be available soon

Roadmap

Introduction

Software qualities

Principles

Software today

Where is software today?

Software today

How “big” is software today?

http://www.informationisbeautiful.net/visualizations/million-lines-of-code/

http://hbr.org/2010/06/why-dinosaurs-will-keep-ruling-the-auto-industry/ar/1

Needs

To DESIGN software– software development has to be a systematic activity

QUALITY assurance– we have to verify and validate our SW in order to make it

something people can rely on

– we have to do it as soon as possible

ABSTRACTION– the principal instrument for managing complexity

The application of engineering to software

Field of computer science dealing with software systems that are:

– large and complex– built by teams– exist in many versions– last many years– undergo changes

Programming skills are not enough“Physicist example”

Software engineering

Programmer: complete program

Software engineer: software component

What is part of software engineering?

http://wonderfulengineering.com/what-is-software-engineering/

Software engineering vs computer science

Computer Science – Computability, algorithms and complexity, programming

languages, data structures, databases, artificial intelligence, etc.

Software Engineering – The APPLICATION of computer science, mathematics,

project management to build high quality software

Roadmap

Introduction

Software qualities

Principles

Representative SW qualities

Correctness

Reliability

Robustness

Performance

Usability

Maintainability

Reusability

Portability

Understandability

Interoperability

Repairability

Evolvability

Correctness

Software is correct if it satisfies the functional requirements specifications

– assuming that specification exists!

If specifications are formal, since programs are formal objects, correctness can be defined formally

– It can be proven as a theorem or disproved by counterexamples (testing)

Improved by:• Appropriate tools • Standard algorithms and libraries• An established development process

The limits of correctness

It is an absolute (yes/no) quality– there is no concept of “degree of correctness”– there is no concept of severity of deviation

What if specifications are wrong?– (e.g., they derive from incorrect requirements or errors in

domain knowledge)

Reliability

Informal definition:

software is reliable if the user can depend on it

can be defined mathematically as “probability of absence of failures for a certain time period”

Improved by:• Fault avoidance (e.g., careful design)• Fault tolerance (e.g., redundancy)• Fault detection (e.g., testing)

Reliability

Hardware reliability

Software reliability?

http://users.ece.cmu.edu/~koopman/des_s99/sw_reliability/

Reliability metrics

http://users.ece.cmu.edu/~koopman/des_s99/sw_reliability/

Software behaves “reasonably” even in unforeseen circumstances (e.g., incorrect input, hardware failure)

Robustness

Robustness vs correctness vs reliability?

Improved by:• Software monitoring• Defensive programming

Example: the MAPE-K loop

http://www.cs.kent.ac.uk/people/rpg/cb492/saaf/concept.html

Performance

Efficient use of resources– memory, processing time, communication

Can be evaluated:– algorithms complexity– measurement of the implemented system– analysis of a model (e.g., using queuing theory)– simulation

Performance can affect scalability– e.g., a solution that works on a small local network

may not work on a large intranet

Improved by:• Considering it during design• Small-scale code optimization

Usability

Expected users find the system easy to use– other term: user-friendliness

Rather subjective, difficult to evaluate

Affected mostly by user interface• e.g., visual vs. textual

Can the user interface impact reliability?

(Performance and correctness) vs usability?

Improved by:• User-centred design process• Adaptable user interfaces

Maintainability

Maintainability: ease of maintenanceàMaintenance: changes after release

Maintenance costs exceed 60% of total cost of software

Three main categories of maintenance– corrective: removing residual errors (20%)– adaptive: adjusting to environment changes (20%)– perfective: quality improvements (>50%)

See it as software evolution

Improved by:• Modular design• Well-defined interfaces• Good documentation

Maintainability

Can be decomposed as– Repairability

• ability to correct defects in reasonable time

– Evolvability• ability to adapt SW to environment changes and to improve it

in reasonable time

Repairability vs modularity?

Ever heared about software product lines?

Reusability

Existing product (or components) used (with minor modifications) to build another product

– e.g., software libraries, jQuery plugins

Also applies to process

Reuse of standard parts measure of maturity of the field

Improved by:• Modular design• Well-defined interfaces• Parameterization• Good documentation

Portability

Software can run on different HW platforms or SW environments

Remains relevant as new platforms and environments are introduced (e.g. digital assistants)

Relevant when downloading software in a heterogeneous network environment

Improved by:• Isolation of dependencies

on environment• Layered architectures• Virtual machines

Understandability

Ease of understanding software

Maintainability vs understandability?

Is it internal or external?

Improved by:• Modular design• Well-defined models• Good documentation

Understandability

Richard Wettel, Michele Lanza: CodeCity: 3D visualization of large-scale software. ICSE Companion 2008: 921-922

Interoperability

Ability of a system to coexist and cooperate with other systems

– e.g., OSX + iOS– OSGI

Can be achieved via standardization of interfaces

Examples?

• Browser plug-ins• The whole open data movement!

Improved by:• Well-documented interfaces• Standard interface formats

e.g., XML, JSON objects

Exercise

Show graphically the interdependence of the SW qualities

Correctness

Reliability

Robustness

Performance

Usability

Maintainability

Reusability

Portability

Understandability

Interoperability

Repairability

Evolvability

Question-time

Is this “software engineering”?

Roadmap

Introduction

Software qualities

Principles

Application of principles

Principles apply to process and product

Principles become practice through methods and techniques

– often methods and techniques are packaged in a methodology– methodologies can be enforced by tools

Principles

Methodologies

Principles

Methods and techniques

Methodologies

Tools

Application of principles

Principles

Methodologies

Principles

Methods and techniques

Methodologies

Tools

Principles:General and abstract descriptionsof desirable properties of products and processes

Methods:General guidelines that govern activities

Techniques:More technical and mechanic than methods

Methodologies:Preselected methods and techniques

Tools:Software for applyingmethodologies

Key principles

• Rigor and formality

• SEPARATION OF CONCERNS

• MODULARITY• ABSTRACTION• Anticipation of change

• Generality• Incrementality

Rigor and formality

Software engineering is a creative design activity, BUTit must be practiced systematically

Rigor is necessary to:– repeatedly produce reliable products– control their costs

Formality is rigor at the highest degree– software process driven and evaluated by mathematical laws– opens to automation

Examples

• Mathematical (formal) analysis of program correctness

• Systematic (rigorous) test data derivation

• Rigorous documentation of development steps helps project management and assessment of timeliness

More on formality

No need to be always formal during design

The engineer must know how and when to be formal

Requirements

Analysis

System design

Detailed Design

Implementation

Validation

Requirements

Analysis

System design

Detailed Design

Implementation

Validation

GSSI website GSSI automatic doors

Separation of concerns

Edsger Dijkstra; On the role of scientific thought; EWD447; 30th August 1974

Why separation of concerns?

Helps you focus – easier to pay attention to one thing at a time – put some complexities aside

– separate out critical functions

Encourages decoupling – disentangle aspects that seemed intertwined

Supports parallelization of efforts and separation of responsibilities

Dimensions of separation of concerns

Complexity

Time(waterfall model)

Size(modularization)

Qualities(correctness, and

performance later)

Views(data flow,

control flow)

Example: concerns in a mobile app

InformationArchitect

UIDesigner

AppDeveloper

Back-endDeveloper

Experience Security Performance

Upgradability

Schedule

CostContentManagement

ProductStrategy

Example: compiler

Correctness is primary concern

Other concerns:– Efficiency of compiler and of generated code

– User friendliness (helpful warnings, etc.)

Example of interdependencies: runtime diagnostics vs. efficient code

– Diagnostics simplify testing, but create overhead

– Typical solution: option to disable checks

Modularity

A complex system may be divided into simpler pieces called modules

A system that is composed of modules is called modular

Supports application of separation of concerns– when dealing with a module we can ignore details of other

modules

Modularity is the basis for understandability à software evolution

Modularity VS reusability?

Cohesion and coupling

Each module should be highly cohesive– module understandable as a meaningful unit

– components of a module are closely related to one another

Modules should exhibit low coupling– modules have low interactions with others– understandable separately

imag

e by P

eter Muller

Example: web reputation dashboard

Architettura*software*!Gli$strumenti$esistenti$a$supporto$di$analisi$di$Web$reputation$possono$essere$divisi$in$due$categorie:$semantici$ e$non$ semantici.$ I$ primi$basano$ le$ loro$ valutazioni$dei$ contenuti$Web$ sull’interpretazione$semantica$ del$ linguaggio$ naturale.$ I$ secondi$ basano$ la$ loro$ competitività$ sull’enorme$ quantità$ di$informazioni$che$analizzano$(alto$numero$di$fonti$Web),$fornendo$però$un’interpretazione$grossolana$della$reputation,$ottenuta$senza$comprendere$la$semantica$del$contenuto.$I$ testi$ che$ derivano$ da$ fonti$ di$ informazione$ ufficiali,$ quali$ giornali$ online,$ possono$ essere$ assunti$come$affidabili,$ generalmente$ben$ scritti$ e$ semplici$da$ interpretare.$Ma$ se$derivano$da$ siti$Web$2.0,$quali$ siti$ di$ microblogging,$ devono$ essere$ necessariamente$ trattati$ da$ strumenti$ specifici$ prima$ di$poter$essere$interpretati.$$Inoltre,$una$delle$ sfide$maggiori$per$ il$ futuro$dell’ICT$è$ la$gestione$dell’overload$ informativo$dovuto$all’aumento$della$disponibilità$di$acquisizione$e$scambio$di$dati.$Come$conseguenza,$diviene$cruciale$la$definizione$di$un$metodo$capace$di$valutare$ la$qualità$dell’informazione$nonché$di$valutare$ la$sua$rilevanza$per$compiti$specifici.$$$A$ tale$ scopo$ la$ nostra$ piattaforma$ comprenderà$ componenti$ software$ necessarie$ ad$ abilitare$l’interpretazione$ semantica$ del$ linguaggio$ naturale$ ottenuto$ dall’interazione$ con$ le$ fonti$ web$ di$interesse,$ovvero$i$social$network$Facebook$e$Twitter,$e$lo$strumento$Telpress$per$l’interazione$con$le$agenzie$di$stampa.$$Infine,$ sulla$ base$ dell’architettura$ definita$ e$ sull’analisi$ degli$ strumenti$ esistenti,$ sono$ stati$ definiti$degli$indicatori$in$grado$di$stimare$polarità$e$pertinenza$con$i$topics$di$interesse.$Tali$indicatori$sono$quindi$inclusi$in$una$dashboard.!!!In$ Figura$ che$ segue$ è$ riportata$ l’architettura$ software$ dello$ strumento$ proposto,$ dove,$ con$ linee$spesse,$ è$ indicato$ il$ flusso$ dei$ dati$ mentre,$ con$ linee$ sottili,$ sono$ mostrate$ le$ interazioni$ tra$componenti$ software$ o$ tra$ componenti$ e$ sorgenti$ dati.$ $ Ad$ interrompere$ il$ flusso$ di$ elaborazione$ è$riportato$ un$ database,$ che$ è$ popolato$ con$ informazioni$ relative$ ai$ contenuti$ testuali$ di$ interesse$ e$arricchito$con$i$valori$relativi$alle$stime$di$polarità$e$topics.$$$!!!$$$$$$$$$$$$$$$$$$$$$

$

$DB$

FB$connector$

Data$Aggregator$

TP$connector$

1

Sentiment$analyzer$

Topic$extractor$$

Dashboard$

ID$

ID$ ID$ ID$ ID$ ID$$$$$id$ $$$$testo$$$$$$$$$prov$ $$timestamp$$$$$polarity$$$$$$$$$$topics$$$$$$$$$tw/fb$ $$$$$$$$$$T1/+1$$$$$$$$$T1/+1$

TW$connector$connector$

Facebook$$

Twitter$$

Telpress$$

Abstraction

Given a difficult problem/system, extract a simpler view of it, avoiding unneeded details

Abstraction in software engineering:– Models of the real world (omit irrelevant details)

– Subtyping and inheritance (factor out commonalities)

– Interfaces and information hiding (hide implementation details)

– Structured programming (loops, methods) – Layered systems (hide deeper layers in the stack)

Abstraction

Engineers abstract away from a number of details that can

be ignored SAFELY

Example: – equations describing complex circuit (e.g., amplifier allows

designer to reason about signal amplification)

– equations may approximate description, ignoring details that yield negligible effects (e.g., connectors assumed to be ideal)

Example: mobile app navigation

Anticipation of change

It is very rare in reality that requirements are fully understood and freezed since the beginning of the project

Ability to support software evolution à anticipating potential future changes

It is the basis for software EVOLVABILITY and REUSABILITY

How does it relate to modularity?

Example: sorting algorithm

http://en.wikibooks.org/wiki/Algorithm_Implementation/Sorting/Quicksort#JavaScript

Generality

While solving a problem, try to discover if it is an instance of a MORE GENERAL PROBLEM

– Sometimes a general problem is easier to solve than a special case

– A solution to a more general problem may be alreadyprovided by off-the-shelf packages

– A solution to a more general problem can be reused in other cases

Carefully balance generality against performance and cost

Incrementality

Process proceeds in a stepwise fashion (increments)

Examples (process)– deliver subsets of a system early to get early feedback from

expected users, then add new features incrementally

– deal first with functionality, then turn to performance

• this may be risky

– deliver a first prototype and then incrementally add effort to turn prototype into product

Ever eared about user-centered design?

Analysis & Planning

Launch

htt

p:/

/paz

no

w.s

3.a

maz

on

aws.

com

/Use

r-C

entr

ed-D

esig

n.p

df

User-centred design

Case study

Mirco Franzago, Henry Muccini, Ivano Malavolta: Towards a collaborative framework for the design and development of data-intensive mobile applications. MOBILESoft 2014

Key principles

•  Rigor and formality

•  SEPARATION OF CONCERNS • MODULARITY • ABSTRACTION •  Anticipation of change •  Generality •  Incrementality

Case studyKey principles

•  Rigor and formality

•  SEPARATION OF CONCERNS • MODULARITY • ABSTRACTION •  Anticipation of change •  Generality •  Incrementality

Mirco Franzago, Henry Muccini, Ivano Malavolta: Towards a collaborative framework for the design and development of data-intensive mobile applications. MOBILESoft 2014

Case studyKey principles

•  Rigor and formality

•  SEPARATION OF CONCERNS • MODULARITY • ABSTRACTION •  Anticipation of change •  Generality •  Incrementality

Mirco Franzago, Henry Muccini, Ivano Malavolta: Towards a collaborative framework for the design and development of data-intensive mobile applications. MOBILESoft 2014

Suggested readings

1. M. E. Joorabchi, A. Mesbah, and P. Kruchten. Real challenges inmobile app development. In Empirical Software Engineering andMeasurement, 2013, pages 15–24, 2013.

2. Mirco Franzago, Henry Muccini, and Ivano Malavolta. Towards acollaborative framework for the design and development of data-intensive mobile applications. In Proceedings of the 1st InternationalConference on Mobile Software Engineering and Systems, pages58–61. ACM, 2014.

1. SWEBOK V.3.0 – Guide to the software engineering body ofknowledge. Pierre Bourke, Richard E. Fairley. IEEE Computer Society,2014.

References

Chapters 1, 2, 3

ContactIvano Malavolta |

Post-doc researcherGran Sasso Science Institute

iivanoo

ivano.malavolta@gssi.infn.it

www.ivanomalavolta.com