20180309-7-Fault Avoidance-Ficco

Università di degli Studi della Campania
Luigi Vanvitelli
Dipartimento di Ingegneria
Laurea Magistrale in Ingegneria Informatica
Affidabilità dei Sistemi Software Complessi

a.a. 2018-2019
Fault Avoidance
Docente : Massimo Ficco

E-mail : massimo.ficco@unicampania.it
1
Topics covered
Fault avoidance
Dependable processes
Affidabilità dei Sistemi Software Complessi - Docente: Massimo Ficco 2

Fault removal costs over software life cycle
Fault Avoidance
Fault avoidance
 The system is developed in such a way that human error is
avoided and thus system faults are minimised.
 The development process is organised so that faults in the system
are detected and repaired before delivery to the customer.

Fault Avoidance
Avoidance deals with good practices of SW engineering
aimed at preventing developers from introducing faults
 It applies to all phases of SW lifecycle
 It is about software quality
 It concerns the quality of the product and of the process
 Standard compliance, especially for critical systems
Some Best Practices

Requirements Engineering
 Elicitation
 Raccolta Collaborativa dei requisiti
 Analisi e Negoziazione
 Checklist, Requirements prioritization, Interaction matrix, Risk
Analysis, (per sist. Critici: FME(C)A, FTA, ETA, Hazard Analysis)
 Documentazione
 Linguaggio naturale strutturato, metodi formali (grammatiche, FSA,
reti di petri), semiformali (UML, SysML)
 Validazione
 Revisioni, Ispezioni Manuali, Prototipazione, Use case
 Gestione
 Tracciabilità, Impact Analysis

Some Best Practices
HL e LL Design:
 Modellazione (app modeling, es. UML, data modelling, metodi
formali, FSA, RdPetri, perf./depend. Modeling, data/control flow
diagrams,…)
 Pattern e paradigmi di progettazione
 Component-based Sw Engineering
 Modularità, Information Hiding
 Fully defined Interface (e.g., design by contract)
 Per sist. Critici: design diversity, recovery block, graceful
degradation
Some Best Practices

Coding
 OOP, Procedural programming
 Coding Standards
 Coding Rules (e.g., no pointer, no global var.)
 Defensive programming
 Appropriate language (e.g., strongly typed, language subset)

Some Best Practices
V&V:
 V&V Process definition, planning
 V&V Process monitoring and Control
 Functional Testing
 Structural Testing
 Non Functional Testing (perf. Robustness, usability,…)
 Static and Dynamic Analysis
 Formal Method
Some Best Practices

Manutenzione:
 CVS
 Defect tracking
 Data Recording and Analysis
 Configuration management
 Design for change
 Impact Analysis

Dependable processes
Fault avoidance: To ensure a minimal number of software
faults, it is important to have a well-defined, repeatable
software process.
A well-defined repeatable process is one that does not
depend entirely on individual skills; rather can be enacted
by different people.
Processi ben definiti e ripetibili

 Documentabile, Standardizzabile, Verificabile, Differente,
Robusto
Dependable process characteristics
Documentable The process shou ld have a defined process model that sets out
the activities in the process and the docu mentation that is to be
produced during these activities.
Standardised A comprehensive set of software development standards that
define ho w the software is to be produced and documented
should be available.
Auditable The process shou ld be understandable by people apart from
process participants who can check that process standards are
being followed and make suggestions for process improvement.
Diverse The process shou ld include redundant and diverse verification
and validation activities.
Robust The process shou ld be able to recover from failures of
individual process activities.

Cicli di sviluppo rigorosi:
Es. il Modello a V
Software Design

Software Design
Utilizzo di metodi, modelli, e tecniche avanzate per la
progettazione del software:
• UML
• SysML
• …
UML
"The Unified Modeling Language (UML) is a graphical
language for visualizing, specifying, constructing, and
documenting the artifacts of a software‐intensive
System”
The UML offers a standard way to write a system's

blueprints, including conceptual things such as
business processes and system functions as well as
concrete things such as programming language
statements, database schemas, and reusable software
components."
UML
UML Diagrams

Drawbacks of UML for SE
• UML is standardized modeling language in the field of
object‐oriented software engineering.
• The strong link between the software and hardware is not
expressed in UML
• The lack of unified representation of software‐hardware
functions makes it difficult to check the whole system
• The lack of visibility in terms of functional and structural
specifications
SysML
The OMG systems Modeling Language (OMG SysML™) is a
general‐purpose graphical modeling language for specifying,
analyzing, designing, and verifying complex systems that may
include hardware, software, information, personnel, procedures,
and facilities.
In particular, the language provides graphical representations

with a semantic foundation for modeling system requirements,
behavior, structure, and parametrics, which is used to integrate
with other engineering analysis models
- http://www.omgsysml.org/
- http://www.ati.ttu.ee/~helena_k/sysml

Relationship with UML
SysML includes extensions that are needed to satisfy the
needs of Systems Engineering community
SysML Structure

UML 2.2 to SysML
UML 2.2 to SysML

SysML Taxonomy
SysML vs UML

SysML vs UML
Pillars of SysML

SysML diagram frame
SysML diagram frame
• type: indicates the type of diagram

• [model element type]: indicates the type of model element
that the diagram represents
• model element: indicates the Name of the represented
model element
• [diagram name]: indicates the Name of the diagram; used
to provide a description of the diagram purpose
• description can be added as a note

Diagram abbreviations
• act ‐ Activity diagram
• req ‐ Requirement diagram
• uc ‐ Use case diagram
• bdd ‐ Block definition diagram
• ibd ‐ Internal block diagram
• pkg ‐ Package diagram
• par ‐ Parametric diagram
• sd ‐ Sequence diagram
• stm ‐ State machine diagram
Requirements
• A requirement describes one or more properties or
behaviors of a system that always have to be met.
• Functional requirements represent capabilities of the
system (can be modeled with Use Case)
• Non‐functional requirments cover areas such as
performance or reliability, constraints (no element in UML
to explicitly describe nonfunctional requirements)

Requirement hierarchy
Requirement element

Block definition diagram
• Basic structural element used to model the structure of
systems
• Replaces UML Class Diagram
• Used to represent blocks, their properties and
inter‐relations
• Block is represented graphically by a rectangle
subdivided into compartmets
• Used to define blocks

Block characteristics:
• Name
• Values
• Operations
• Constraints
• Etc.
Internal block diagrams

• Describes the internal structure of a block in terms of
parts, ports and connections
• Several levels of decomposition can be presented
• Used to depict usage of blocks in a context
• Shows the connectons of ports
• Shows the flows between parts and ports

Internal block diagrams
SysML Activity Diagram

• Specifies the flow as well as input and output of data.
• Flows can run in parallel, or they can be synchronized, or
split based on conditions.
• SysML extends several properties of UML 2 activity model
• Extended control flow with additional information to stop
actions or control the flow via so‐called control operators
• Support for modeling of continuous systems
• Continuous or discrete object flow
• Object nodes can reject data that are no longer current
• Probabilities of flows.
• Modeling rules for activities in the form of a block definition
diagram (function trees).
Function trees can be
represented by block
definition diagrams

Allocations
• A mechanism that enables user to connect elemets to
each other
• Three types of allocations:
• Behavior – links a behavior to the block that realizes the
behavior
• Structure – links logical structures with physical
structures (and vice versa)
• Object flow – connects an item flow (found in structure
diagram) with an object flow edge (found in the activity
diagram)
Allocations

Allocations
Parametric diagram
• SysML provides possibility to simulate portions of the
model, based on mathematical and physical laws that
describe key aspects of the system.
• Allows to represent constraints on system parameter

values – for example, performance, reliability and mass

Parametric diagram
Constraint blocks
• A constraint block describes constraints on system
structures and the parameters required.
• Notation: «constraintBlock» (or «constraint»)
• Constraints are declared in Block Definition Diagram
• Decraled constrains are applied to the parametric diagram

Constraint blocks
• Support the construction of parametric
models
• Define equations so that they may be
re‐used and inter‐connected
• Define a set of parameters
• Contained in the ‘parameters’
compartment
• Define an expression that constrains the
parameters
• Contained in the ‘constraints’
compartment
• Depicted with the keyword <<constraint>>
Online resources
UML:
• UML Resource Page: http://www.uml.org/
• UML graphical notation overview: http://www.uml‐diagrams.org/
• UML Tutorial: http://uml‐tutorials.trireme.com/
SysML:
• OMG SysML page: http://www.omgsysml.org/
• INCOSE SysML Tutorial:
http://www.sysmlforum.com/sysmltutorials/
• Think SysML: http://www.thinksysml.org/Tutorials.html
• SysML FAQ: http://www.sysmlforum.com/sysml‐faq/
• HSUV sxample: http://www.omg.org/ocsmp/HSUV.pdf

ESEMPIO
La domotica, è l’incontro tra tecnologia informatica,
elettrotecnica e elettronica che fa diventare una
abitazione per così dire "intelligente"
La domotica cont’d
Nei sistemi domotici, impianti ed elettrodomestici
convivono in uno stesso ambiente grazie all’impiego
di un sistema di controllo che garantisce
contemporaneamente requisiti di:
● Semplicità
● Affidabilità
● Apertura
● Integrazione
● Flessibilità
● Espandibilità
● Continuità di funzionamento

La casa domotica ~ MyHome cont

Analisi dei requisiti
Il primo passo nella progettazione del sistema
domotico è stata l’individuazione dei requisiti,
ovvero delle funzionalità che il sistema deve offrire e
che, indirettamente, deve garantire agli utenti che lo
utilizzano.


Successivamente aspetti troppo generici, ambigui e
poco definiti, sono stati scomposti in requisiti più
semplici.

Analisi strutturale
A questo punto si definisce l’architettura ad alto
livello del sistema utilizzando i “Block Definition
Diagrams”, dove vengono definiti le componenti del
sistema, e le relazioni tra di loro.

Analisi strutturale

Analisi strutturale

Analisi strutturale
Il cuore del sistema, è identificato dal blocco
“Impianto a Bus”.

Analisi strutturale

Analisi strutturale

Analisi strutturale
Seppure il “Block Definition Diagram” fornisca una
rappresentazione delle componenti del modulo, non
dà informazioni su come le parti sono interconnesse.

Analisi strutturale

Analisi strutturale

Analisi strutturale

Tracciabilità dei requisiti
Per ogni requisito è possibile individuare quale
blocco ne implementi la funzionalità.

Analisi comportamentale
Una volta definita la struttura del sistema, il passo
successivo è stato quello di modellare il
comportamento del sistema, ovvero, di definire ed
invididuare i vari contesti o scenari in cui il sistema
deve agire e modellare come le parti del sistema
interagiscono tra di loro.
Scenario ~ La tranquillità di uscire di casa
Inserendo l’antifurto, con la pratica chiave

elettronica, si attivano i sistemi di protezione su tutti
gli ambienti, si spengono tutte le luci, si abbassano
tutte le serrande e la temperatura.

Prima di poter modellare correttamenete le possibili
interazioni tra i blocchi e moduli del sistema, bisogna
avere un’idea chiara di tutti i possibili stati in cui un
particolare blocco può ritrovarsi.

Prima di poter modellare correttamenete le possibili
interazioni tra i blocchi e moduli del sistema, bisogna
avere un’idea chiara di tutti i possibili stati in cui un
particolare blocco può ritrovarsi.

Un “Activity Diagram” definisce le attività da
svolgere per realizzare una determinata funzionalità.

Un “Sequence Diagram” riporta i flussi già
precedentemente esaminati ma in maniera molto
più approfondita.

Dependable programming
Dependable programming
Use programming constructs and techniques that contribute
to fault avoidance
 Design for simplicity;

 Protect information from unauthorised access;
 Minimise the use of unsafe programming constructs.

Information protection
Information should only be exposed to those parts of
the program which need to access it. This involves the
creation of objects or abstract data types that maintain
state and that provide operations on that state.
This avoids faults for three reasons:
 the probability of accidental corruption of information is reduced;
 the information is surrounded by ‘firewalls’ so that problems are
less likely to spread to other parts of the program;
 as all information is localised, you are less likely to make errors
and reviewers are more likely to find errors.
Fault-free software
Current methods of software engineering now
allow for the production of fault-free software, at least
for relatively small systems.
Fault-free software means software which
conforms to its specification. It does NOT mean
software which will always perform correctly as
there may be specification errors.
The cost of producing fault free software is very
high. It is only cost-effective in exceptional
situations. It is often cheaper to accept software faults
and pay for their consequences than to expend
resources on developing fault-free software.

*Fault-free software development
Quality management (standard, processi e formalismi per la progettazione
e sviluppo)
Formal specification
Static verification
Strong typing (rilevazione di errori tramite i compilatori del linguaggio)
Safe programming
Protected information (Information hiding ed incapsulamento)
Dependable software processes (attività di verifica e validazione
approprate)
Safe programming
Faults in programs are usually a consequence of
programmers making mistakes.
These mistakes occur because people lose track of the
relationships between program variables.
Some programming constructs are more error-prone than
others so avoiding their use reduces programmer mistakes.

Structured programming
First proposed in 1968 as an approach to development
that makes programs easier to understand and that
avoids programmer errors.
Programming without gotos.
While loops and if statements as the only control
statements.
Top-down design.
An important development because it promoted
thought and discussion about programming.
Error-prone constructs (da evitare)

Floating-point numbers
 Inherently imprecise. The imprecision may lead to invalid
comparisons.
Pointers
 Pointers referring to the wrong memory areas can corrupt
data.
Aliasing (più di un nome è utlizzato per lo stesso oggetto)
 can make programs difficult to understand and change.
Dynamic memory allocation
 Run-time allocation can cause memory overflow.

Error-prone constructs
Parallelism (problemi di tempistica difficili da verificare)
 Can result in subtle timing errors because of unforeseen
interaction between parallel processes.
Recursion (difficoltà nel seguire la logica)
 Errors in recursion can cause memory overflow.
Interrupts (forza il trasferimento del controllo a una sezione di
codice)
 Interrupts can cause a critical operation to be terminated and
make a program difficult to understand.
Error-prone constructs
Inheritance (binding dinamico che rende difficile comprendere il
comportamento di un oggetto)
 Code is not localised. This can result in unexpected
behaviour when changes are made and problems of
understanding.
Unbounded arrays
 A run-time il sistema non controlla se le assegnazioni sono
corrette – buffer-overflow
Default input processing
 Può costituire una vulnerabilità sfruttabile da un attacker
Alcuni standard proibiscono l’uso di questi costrutti

Vanno utilizzati ma con cautela
Es. Java

Exception handling
A program exception is an error or some unexpected
event such as a power failure.
Exception handling constructs allow for such events to
be handled without the need for continual status
checking to detect exceptions.
Using normal control constructs to detect
exceptions needs many additional statements to be
added to the program (es. costrutti throw-catch java).
This adds a significant overhead and is potentially
error-prone.
Validation activities
Requirements inspections
Model checking (analisi automatica tramite strumenti CASE
per garantire la consistenza)
Design and code inspection
Static analysis
Test planning and management
Configuration management

20180309-7-Fault Avoidance-Ficco

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

20180309-7-Fault Avoidance-Ficco

Caricato da

Copyright:

Formati disponibili

Università di degli Studi della Campania

Affidabilità dei Sistemi Software Complessi

Docente : Massimo Ficco

Affidabilità dei Sistemi Software Complessi - Docente: Massimo Ficco 2

Affidabilità dei Sistemi Software Complessi - Docente: Massimo Ficco 3

Affidabilità dei Sistemi Software Complessi - Docente: Massimo Ficco 4

Affidabilità dei Sistemi Software Complessi - Docente: Massimo Ficco 5

Some Best Practices

Affidabilità dei Sistemi Software Complessi - Docente: Massimo Ficco 6

Affidabilità dei Sistemi Software Complessi - Docente: Massimo Ficco 7

Some Best Practices

Affidabilità dei Sistemi Software Complessi - Docente: Massimo Ficco 8

Affidabilità dei Sistemi Software Complessi - Docente: Massimo Ficco 9

Some Best Practices

Affidabilità dei Sistemi Software Complessi - Docente: Massimo Ficco 10

Processi ben definiti e ripetibili

Affidabilità dei Sistemi Software Complessi - Docente: Massimo Ficco 11

Dependable process characteristics

Affidabilità dei Sistemi Software Complessi - Docente: Massimo Ficco 12

Affidabilità dei Sistemi Software Complessi - Docente: Massimo Ficco 13

Affidabilità dei Sistemi Software Complessi - Docente: Massimo Ficco 14

Affidabilità dei Sistemi Software Complessi - Docente: Massimo Ficco 15

The UML offers a standard way to write a system's

Affidabilità dei Sistemi Software Complessi - Docente: Massimo Ficco 17

Affidabilità dei Sistemi Software Complessi - Docente: Massimo Ficco 18

Affidabilità dei Sistemi Software Complessi - Docente: Massimo Ficco 19

In particular, the language provides graphical representations

Affidabilità dei Sistemi Software Complessi - Docente: Massimo Ficco 20

Affidabilità dei Sistemi Software Complessi - Docente: Massimo Ficco 21

Affidabilità dei Sistemi Software Complessi - Docente: Massimo Ficco 22

Affidabilità dei Sistemi Software Complessi - Docente: Massimo Ficco 23

UML 2.2 to SysML

Affidabilità dei Sistemi Software Complessi - Docente: Massimo Ficco 24

Affidabilità dei Sistemi Software Complessi - Docente: Massimo Ficco 25

Affidabilità dei Sistemi Software Complessi - Docente: Massimo Ficco 26

Affidabilità dei Sistemi Software Complessi - Docente: Massimo Ficco 27

Affidabilità dei Sistemi Software Complessi - Docente: Massimo Ficco 28

Affidabilità dei Sistemi Software Complessi - Docente: Massimo Ficco 29

SysML diagram frame

• type: indicates the type of diagram

Affidabilità dei Sistemi Software Complessi - Docente: Massimo Ficco 30

Affidabilità dei Sistemi Software Complessi - Docente: Massimo Ficco 31

Affidabilità dei Sistemi Software Complessi - Docente: Massimo Ficco 32

Affidabilità dei Sistemi Software Complessi - Docente: Massimo Ficco 33

Affidabilità dei Sistemi Software Complessi - Docente: Massimo Ficco 34

Affidabilità dei Sistemi Software Complessi - Docente: Massimo Ficco 35

Block definition diagram

Affidabilità dei Sistemi Software Complessi - Docente: Massimo Ficco 36

Affidabilità dei Sistemi Software Complessi - Docente: Massimo Ficco 37

Internal block diagrams

Affidabilità dei Sistemi Software Complessi - Docente: Massimo Ficco 38

Affidabilità dei Sistemi Software Complessi - Docente: Massimo Ficco 39

SysML Activity Diagram

• Object nodes can reject data that are no longer current

Affidabilità dei Sistemi Software Complessi - Docente: Massimo Ficco 41

SysML Activity Diagram

Affidabilità dei Sistemi Software Complessi - Docente: Massimo Ficco 42

Affidabilità dei Sistemi Software Complessi - Docente: Massimo Ficco 43

Affidabilità dei Sistemi Software Complessi - Docente: Massimo Ficco 44

Affidabilità dei Sistemi Software Complessi - Docente: Massimo Ficco 45

• Allows to represent constraints on system parameter

Affidabilità dei Sistemi Software Complessi - Docente: Massimo Ficco 46

Affidabilità dei Sistemi Software Complessi - Docente: Massimo Ficco 47

Affidabilità dei Sistemi Software Complessi - Docente: Massimo Ficco 48