03-AltriModelliDiProcesso

Lezione 3.
Altri modelli di processo software
•
[GJM91, Sez. 7.1], [S2001, Cap. 3, Sez. 19.4], [TMcG93, Cap. 2],
[BRJ99, App. C (°)]
•
•
•
Incremental delivery
Modello evolutivo
Modello formale-trasformazionale
» Esempio: Cleanroom (anche incrementale)
•
•
•
•
•
•
Reuse
Extreme programming
Modelli ibridi e metamodello a spirale
Modello Unified (UML) (°)
Visibilità nei vari modelli
Supporto CASE
Slide 1
ESA - Incremental delivery approach (*)
- Assume UR e SR stabili, come Waterfall, ma
- Affronta UR incrementalmente (priorità temporali)
- Development team ridotto ==> sequenzializz. di deliverables
- ‘Spalma’ il budget nel tempo
User Requirements
Software Requirements
Architectural Design
Detailed Design and coding
TRansfer to operations
Operations and Maintenance
(*) European Space Agency Software Engineering Standards, ESA PSS-05-0, N. 2, Feb. 91.
In [TMcG93]
Slide 2
Incremental delivery [S2001]
Define outline
requirements
Assign requirements
to increments
Develop system
increment
Valida te
increment
Design system
architecture
Integrate
increment
Valida te
system
Final
system
System incomplete
- Consegna alcune funzionalità molto presto
- ...e queste aiutano nella definizione di ulteriori requisiti
- Diminuisce il rischio di fallimento completo del progetto
- Le funzionalità prioritarie sono testate ripetutamente
Slide 3
ESA - Evolutionary development approach
Sequenza rapida
di cicli waterfall completi
Serve a chiarire e far evolvere i requisiti
attraverso esperienza diretta su
implementazioni intermedie
Slide 4
Evolutionary development [S2001]
Concurr ent
activities
Outline
description
Specification
Initial
version
Development
Intermediate
versions
Validation
Final
version
Slide 5
Slide 6
Due forme di evolutionary development

Exploratory prototyping
•
•

Forma ‘costruttiva’ - mira ad assistere il Cliente nel
raffinamento dei requisiti (chiari) iniziali.
Si parte con i requisiti piu’ chiari…
Throw-away prototyping
•
•
Forma ‘distruttiva’ - serve allo sviluppatore per capire cosa il
Cliente NON vuole
Si parte dai requisiti piu’ oscuri...
Slide 7
Evolutionary development - problemi e applicabilità

Problemi
•
•
•

La visibilità del processo è debole
Non promuove buone architetture
Puo’ richiedere personale specializzato (p.es. su linguaggi di
prototipazione rapida).
Applicabilità
•
•
•
Sistemi interattivi piccoli (fino 100.000 linee) o medi (500.000)
Parti (p. es. interfaccia utente) di sistemi complessi
Short-lifetime systems
Slide 8
Trasformazione formale
Formal transformations
T1
Formal
specification
T2
R1
P1
T3
R2
P2
T4
Executable
program
R3
P3
P4
Proofs of transformation correctness
Slide 9
Esempi di metodi basati su trasf. formale



Cleanroom software development (H. Mills,IBM)
LOTOS equivalence-preserving transformations
(Esprit LotoSphere Project)
B Method (J.-R. Abrial -->Wordsworth ‘96)
Slide 10
Esempio: Cleanroom software development



Nome ‘cleanroom’ derivato da un processo di
produzione di semiconduttori.
Mira e evitare gli errori a priori, anziché
rimuoverli a posteriori
Si basa su:
•
•
•
•
Incremental development
Formal specification by state-transition model
‘Rigorous’, semi-formal static verification using correctness
arguments
Statistical testing to determine program reliability.
Slide 11
The Cleanroom process
Functional
requirements in
‘box structure’ notation
Formally
specify
system
Error rework
Define
software
increments
Develop
operational
profile
Construct
structured
program
Formally
verify
code
Design
statistical
tests
Integrate
increment
Test
integrated
system
System usages
By correctness-preserving transformations
Slide 12
Cleanroom process characteristics



Formal specification using a state transition
model called box structure notation
Incremental development
Structured programming - limited control and
abstraction constructs are used
•

Static verification using rigorous inspections
•

for facilitating verification of consistency between steps
in place of unit testing
Statistical testing of the system
•
after each increment integration
Slide 13
box structure notation ha tre livelli



Black box: funzione da sequenze di inputs -->outputs.
Raffinata in
State box: una funzione di transizione (input, stato)-->
(output, stato). Raffinata in
Clear box: una state box definita usando i costrutti di
structured programming: assignment, sequence, if-thenelse, while-do
Slide 14
Formal specification and inspections

The state based model is a system specification
and the inspection process checks the program
against this model
•


even though the use of correctness-preserving transformations
should in principle make inspections unnecessary...
Programming approach is defined so that the
correspondence between the model and the
system is clear
Mathematical arguments (not proofs) are used to
increase confidence in the inspection process
Slide 15
Cleanroom process teams

Specification team.
•

Development team.
•

Responsible for developing and maintaining the customeroriented and developer-oriented system specification
Responsible for developing and verifying the software. The
software is NOT executed or even compiled during this process
Certification team.
•
Responsible for developing a set of statistical tests to exercise
the software after development. Reliability growth models
used to determine when reliability is acceptable (MTTF: mean
time to failure)
Slide 16
Cleanroom process evaluation



Results in IBM have been very impressive with
few discovered faults in delivered systems
Independent assessment shows that the
process is no more expensive than other
approaches
Not clear how this approach can be transferred
to an environment with less skilled or less
highly motivated engineers
Slide 17
LOTOS equivalence-preserving transformation




Basato sulla specifica in LOTOS di struttura e comportamento del
sistema,
Sequenza di (due, tre, quattro…) descrizioni sempre piu’ dettagliate
del sistema, utilizzando diversi stili di specifica: Constraint-Oriented,
Resource-Oriented, e State-Oriented, da cui è facilmente derivabile il
codice.
Verifica formale di equivalenza osservazionale fra due descrizioni
successive
(vedi lezioni su Verifica e Validazione)
Slide 18
B-method

B is a generic term given to a method of software development, the
B-Method, its process and notation, and and its supporting toolset,
the B-Toolkit. B derives from Z, and has similarities with Z and
VDM. Axiomatic semantics based on Dijkstra’s weakestprecondition calculus.

The B-Method uses a simple `pseudo' programming language, AMN
(The Abstract Machine Notation), to model requirements, interfaces,
implementations and intermediate designs.

Step-wise development is used. A complete implementation (in C) is
thus constructed from layers of specification/implementation pairs.

Specification/implementation pairs at the lowest levels are drawn
from an extensive library of pre-implemented re-usable components.
Slide 19



Una abstract machine incapsula variabili di stato
I valori delle variabili devono sempre soddisfare
l’invariante della macchina, espresso da un predicato
Il comportamento della macchina è espresso da
•
•

inizializzazione delle variabili
lista di operazioni che possono accedere e modificare lo stato
Ogni specifica espressa come abstract machine viene
validata mediante un insieme di proof obligations
generabili automaticamente
•
•
l’inizializzazione deve soddisfare l’invariante
ogni operazione deve preservare l’invariante
Slide 20


inizializzazione e operazioni sono espresse mediante ‘sostituzioni generalizzate’,
simili a istruzioni di assegnamento ma dotate di semantica formale ben definita.
Macchine astratte complesse sono ottenute componendo macchine piu’ semplici
attraverso relazioni di
•
•
•
•
•

include
use
see
import
extend
Tools commerciali di supporto:
•
Atelier B, di Stéria Méditerranée, Aix-en-Provence, Francia
» http://www.atelierb.societe.com
•
B Tool, di B-Core Limited, Oxford, UK
» http://www.b-core.com

Applicato con successo a sistemi di controllo ferroviario (Metro Parigi)
Slide 21
Trasformazione formale - problemi e applicabilità

Problemi
•
•
•

Non pratico per sistemi di dimensioni medio-grandi
Richiede training, o personale già specializzato
Non adatto alla specifica dell’interfaccia utente
Applicabilità
•
•
Sistemi critici con requisity di safety o security.
Parti piccole o critiche di sistemi complessi
Slide 22
Reuse-oriented development


Il sistema è ottenuto per integrazione di
componenti esistenti, eventualmente comperate
da terze parti (COTS =Commercial-off-the-shelf)
Fasi
•
•
•
•

Component analysis
Requirements modification
System design with reuse
Development and integration
Tecnica recente, in forte crescita, poco
consolidata e formalizzata
Slide 23
Extreme programming



Nuovo approccio per team medio-piccoli che sviluppano sw
dai requisiti vaghi o rapidamente mutevoli
Sviluppo e rilascio di incrementi molto piccoli di funzionalità
Si basa su
•
•
•
•
•
•
pair programming: codice scritto da due programmatori sulla stessa macchina
collective ownership: chiunque nel team puo’ migliorare il codice in ogni
parte, in ogni momento
on-site customer: coinvolgimento full-time di un utente nel team di sviluppo
testing: gli sviluppatori scrivono continuamente unit test, i cui fallimenti
originano nuovo codice
stories: la funzionalità del sistema è caratterizzata mediante brevi storie
(simili a UML use-cases)
‘egoless’ programming: decisioni di management prese dal gruppo
Slide 24
Modelli ibridi

Usare diversi modelli per diverse parti dello
stesso sistema (complesso)
•
•
•
Evolutionary/Prototyping per parti con requisiti poco stabili o
oscuri
Waterfall per parti con requisiti stabili e chiari
Formal development per parti safety-critical
Slide 25
Il (meta-)modello ibrido a spirale
Determine objectives
alternatives and
constraints
Risk
analysis
[Boehm 88]
Evaluate alternatives
identify, resolve risks
Risk
analysis
Risk
analysis
REVIEW
Requirements plan
Life-cycle plan
Development
plan
Plan next phase
Integration
and test plan
Prototype 3
Prototype 2
Operational
protoype
Risk
analysis Prototype 1
Simulations, models, benchmarks
Concept of
Operation
S/W
requirements
Requirement
validation
Product
design
Detailed
design
Code
Unit test
Design
V&V
Integr ation
test
Acceptance
test
Develop, verify
Service
next-level product
Slide 26
I quattro settori della spirale

Stabilire gli obiettivi
•

Valutare e ridurre i rischi
•

I principali rischi sono identificati, analizzati, e viene raccolta
informazione su come minimizzarli
Sviluppo e validazione
•

Identifica obiettivi specifici per una fase (un giro)
Viene scelto un modello di sviluppo e validazione dei risultati
Pianificazione
•
Review del progetto e piani per il nuovo ‘giro’
Slide 27
Modello a Spirale - vantaggi e problemi





+ Attento al ri-uso
+ Attento alla eliminazione precoce di rischi
- Non applicabile quando il contratto prescrive un
dato modello e identifica precisi deliverables
- Richiede esperti in valutazione dei rischi
- E’ molto astratto, e va istanziato
Slide 28
Modello Rational Unified (UML)

Root causes of Software Development Problems
•
•
•
•
•
•
•
•
•
•
Insufficient requirements management
Ambiguous and imprecise communications
Fragile architectures
Overwhelming complexity
Undetected inconsistencies among requirements, designs and
implementations
Insufficient testing
Subjective project status assessment
Delayed risk reduction due to waterfall development
Uncontrolled change propagation
Insufficient automation
(source: RatiOnal)
Slide 29
‘Best practices’ in S.E. processes
1
2
3
4
5
6
Slide 30
1. Develop iteratively (Phases and Workflows)
Slide 31
2. Manage requirements


Requirements can be related to many other
project documents.
They can be prioritized, filtered, traced
•


Each iteraction handles a requirements subset
Requirements error detection by prototyping the
user interface.
Requirements repository tool, with traceability
information and links to external documents.
Slide 32
3. Use component architectures

Architecture is part of Design
•

but stops at the major abstractions (components), those that
have crucial effect on system quality, performance, evolvability.
Good architecture
•
•
•
•
===> good team sizing and supervision
===> good control over iterative, incremental system
development
===> guidance in build vs. buy decision
===> re-use and evolution
Slide 33
Evolvable architecture
(bought, built, new)
Slide 34
4. Model software visually (with UML diagrams)
Slide 35
5. Verify quality - test incrementally
Slide 36
…using test tools
Slide 37
Visibilità nel processo di sviluppo



Il software è poco tangibile ma i manager
richiedono documenti per poter controllare il
progresso
Un modello ha alta visibilità quando prevede la
produzione documentazione accurata delle varie
fasi e dei risultati intermedi.
Ma:
•
•
•
Timing of progress deliverables may not match the time needed
to complete an activity
The need to produce documents constraints process iteration
The rime taken to review and approve documents is significant
Slide 38
Process Model
Process Visibility
Waterfall Model
Good; each activity produces
some deliverable
Poor: uneconomic to produce
documents during rapid iteration
Good; each segment in each spiral
loop must produce paper…
Good (but difficult to read…)
Evolutionary development
Spiral Model
Formal transformations
Reuse-oriented development
Moderate; may be ‘artificial’ to
produce documents about reused
components
Slide 39
La scelta del modello dipende da




tipo di sistema e di utente finale
rapporti fra Cliente e Sviluppatore
politiche aziendali del Cliente o dello Sviluppatore
Es. 1 - Sistema per utenti non esperti: va sviluppata documentazione
didattico-illustrativa, e mantenuta allineata agli altri artefatti.

Es. 2 - Lo studio di fattibilita’ cambia se la SW House sviluppa:
•
•
•
Software specifico per cliente esterno, o
Software specifico per altro ramo della stessa Compagnia, o
Software generico da lanciare sul mercato.
Slide 40
Automated process support: CASE


Computer-aided software engineering (CASE) is
software to support software development and
evolution processes
Activity automation
•
•
•
•
•
•
Graphical editors for system model development
Data dictionary to manage design entities
Graphical UI builder for user interface construction
Debuggers to support program fault finding
Automated code generators: code (skeletons) from designs
Automated translators from old (versions of a) programming
language to new version or language.
Slide 41
Case technology

Case technology has led to significant improvements
(40%, Huff’92) in the software process -- but not the
predicted order of magnitude improvements

Reasons for limited effectiveness
•
•
Creative work is not readily automatable
Software engineering effort largely spent in team interactions. CASE
technology does not really help here
Slide 42
Functional tool classification
Tool type
Planning tools
Editing tools
Change ma nagement tools
Configuration management tools
Prototyping tools
Method-support tools
Language-processing tools
Program analysis tools
Testing tools
Debugging tools
Documentation tools
Re-engineering tools
Examples
PERT tools, estimation tools,
spreadsheets
Text editors, diagram editors, word (Syntax-directed)
processors
Requirements traceability tools, change
control systems
Version management systems , system
building tools
Very high-level languages,
user in terface generators
Design editors, data dictionaries, code
generators
Compilers, interpreters
Cross reference generators, static
analysers, dynamic analysers
Test data generators, file comp arators
Interactive debugging systems
Page layout programs, ima ge editors
Cross-reference systems , program restructuring systems
Slide 43

PERT - Project Evaluation and Review Technique
•
•
•
U.S. Dept. Of Defense ha usato PERT (‘50) nel progettare il sottomarino
Polaris
Presenta un progetto (sia per pianificazione che per gestione) come insieme
parzialmente ordinato di attività, ciascuno con una durata.
Cammino critico dal nodo START al nodo END: quello di maggior durata
Slide 44