Software systems engineering PRINCIPLES

Software systems engineering
PRINCIPLES
Ivano Malavolta

Course website
http://lore.com/Software-systems-and-services.1
UY737U

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

Software engineering
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
“Physicist example”

Definitions
Application of a systematic, disciplined, quantifiable
approach to the development, operation, and
maintenance of software (IEEE 1990)
Multi-person construction of multi-version software
(Parnas 1978)

Role of software engineer
Programming skill not enough
Software engineering involves “programming-in-the –
large”
– understand requirements and write specifications
• derive models and reason about them
– master software
– operate at various abstraction levels
– member of a team
• communication skills
• management skills

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

Classification of SW qualities "ilities"
Internal vs. external
– Externalà visible to users
– Internalà concern developers
Product vs. process
– Our goal is to develop software products
– The process is how we do it
Internal qualities affect external qualities
Process quality affects product quality

Representative SW qualities
Correctness
Reliability
Robustness
Performance
Usability
Maintainability
Repairability
Evolvability
Understandability
Interoperability
Reusability
Portability

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)

Idealized situation
Requirements are correct
Reliability
Correctness

Robustness
Software behaves “reasonably” even in unforeseen
circumstances (e.g., incorrect input, hardware failure)
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
Improved by:
• Considering it during design
• Small-scale code optimization
– 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

Usability
Improved by:
• User-centred design process
• Adaptable user interfaces
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
(Performance and correctness) vs usability?
Can the user interface impact reliability?

Maintainability
See it as software evolution
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%)
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

Portability
Improved by:
• Isolation of dependencies
on environment
• Layered architectures
• Virtual machines
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

Understandability
Ease of understanding software
Maintainability vs understandability?
Is it internal or external?
Improved by:
• Modular design
• Well-defined models

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

Interoperability
Improved by:
• Well-documented interfaces
• Standard interface formats
e.g., XML, JSON objects
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!

Typical process qualities
Productivity
– denotes its efficiency and performance
– classical example of metric: lines of code
Timeliness
– ability to deliver a product on time
– e.g., incremental delivery technique
Visibility
– all of its steps and current status are documented clearly
– also visibility of the product is needed

Quality measurement
Many qualities are subjective
No standard metrics defined for most qualities
Much research work is currently about defining
objective metrics for SW

Exercise
Show graphically the interdependence of the SW qualities
Correctness
Reliability
Robustness
Performance
Usability
Maintainability
Repairability
Evolvability
Understandability
Interoperability
Reusability
Portability

Question-time
Is this “software engineering”?

Principles
Principles form the basis of methods, techniques,
methodologies and tools
In this lecture we will discuss the 7 important principles
that may be used in all phases of software development
Modularity is the cornerstone principle supporting
software design

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
Tools
Methodologies
Methodologies
Methods
and techniques
Principles
Principles

Application of principles
Tools
Methodologies
Methodologies
Methods
and techniques
Principles
Principles
Principles:
General and abstract descriptions
of desirable properties of
products and processes
Methods:
General guidelines
that govern activities
Techniques:
More technical and
mechanic than methods
Methodologies:
Sets of methods
and techniques
Tools:
Software for applying
methodologies

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, BUT
it 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
GSSI website GSSI automatic doors
Requirements
Analysis
System design
Detailed Design
Implementation
Validation
Requirements
Analysis
System design
Detailed Design
Implementation
Validation

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
Informa(on
Architect
UI
Designer
App
Developer
Back-‐end
Developer
Experience
Security
Performance
Upgradability
Schedule
Content
Cost
Management
Product
Strategy

Example: compiler
Correctness is primary concern
Other concerns:
– Efficiency of compiler and of generated code
– User friendliness (helpful warnings, etc.)
Example for 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
image by Peter Müller

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.$$$
Example: web reputation dashboard
!!!
$$$$$$$$$$$$$$$$$$$$$
$
DB$ $
FB$connector$
Data$
Aggregator$
TP$connector$
Sentiment$
analyzer$
Topic$extractor$$
Dashboard$
$$$$id$ $$$$tIeDst$o$$$$$$$$$pIrDov$$ $$timIeDsta$mp$$$$$poIlaDri$t$y$$$$$$$$$toIpDics$$
I
D$
$$$$$$$$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)
– Parameterization (templates)
– 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 already
provided 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 is risky
– deliver a first prototype and then incrementally add effort to
turn prototype into product
Ever heared about user-centered 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

What this lecture means to you?
Given a problem to solve
– Analyze it
– Synthesize a solution
Understand that requirements may change
Must view quality from several different perspectives
Use fundamental software engineering principles
(e.g., abstractions and separation of concerns)
Keep system boundary in mind

Suggested readings
1. M. E. Joorabchi, A. Mesbah, and P. Kruchten. Real challenges in
mobile app development. In Empirical Software Engineering and
Measurement, 2013, pages 15–24, 2013.
2. Mirco Franzago, Henry Muccini, and Ivano Malavolta. Towards a
collaborative framework for the design and development of data-intensive
mobile applications. In Proceedings of the 1st International
Conference on Mobile Software Engineering and Systems, pages
58–61. ACM, 2014.
3. SWEBOK V.3.0 – Guide to the software engineering body of
knowledge. Pierre Bourke, Richard E. Fairley. IEEE Computer Society,
2014.

Contact Ivano Malavolta |
Post-doc researcher
Gran Sasso Science Institute
iivanoo
ivano.malavolta@gssi.infn.it
www.ivanomalavolta.com

Software systems engineering PRINCIPLES

More Related Content

What's hot

Viewers also liked

Similar to Software systems engineering PRINCIPLES

More from Ivano Malavolta

Recently uploaded

Software systems engineering PRINCIPLES