Introduction GL

Licence Mention Informatique – L2/S4 – 2012
Programmation Object
& Genie Logiciel
Burkhart Wolff
Département Informatique
Bibliographie et Weberies

UML 2.0, Martin Fowler, Campus Press, 2004

Developing Applications with Java and UML, Paul R. Reed Jr.,
Addison Wesley, 2002
UML 2 et les Design Patterns, G. Larman, Campus Press, 2005
UML 2 en action, P. Roques, F. Vallée, Eyrolles 2004
Paul R. Reed Jr., Addison Wesley, 2002



The Unified Modeling Language User Guide, Grady Booch, James
Rumbaugh, Ivar Jacobson, Addison-Wesley, 2005

Précis de Génie Logiciel,
M.-C. Gaudel, B. Marre, F. Schlienger et G. Bernot, Masson, 1996
The Science of Programming, D. Gries, Springer Verlag, 1981

http://www.omg.org/gettingstarted/what_is_uml.htm
http://www.eecs.ucf.edu/~leavens/JML/
http://www.junit.org/
2011-12
L2-GL - Intro
2
Part II.1 :
Introduction to Software Engineering
If the automobile had followed the same development
cycle as the computer, a Rolls-Royce would today cost
$100, get a million miles per gallon, and explode once a
year, killing everyone inside.
Robert X. Cringely
Why Software Engineering ?
Why does ad-hoc software development not scale:

Constraints to trustworthyness, safety, security,

Growing mix of hardware and software (complexity!),

Informatics is omnipresent et « diffuse »

Presence of clients, with imprecise and changing
requirements, with whom we must communicate

Development in (very) large, longstanding teams nec.
Software can have a long life-cycle, implying maintenance

 reference documents

Bad image of a company, loss of market credibility
society
aspects
Software becomes more and more complex and large
technological
aspects

 obstacle for development

2011-12
Legal constraints (Common Criteria Certification,
Antri-Trust-Laws, ...)
L2-GL - Intro
4
Software becomes more dangerous ...

Trust, safety and security of software :




Transportation: railway, aircrafts, space,
Control of industrial processes, nuclear, military, …
Tele-surgery, medical imaging and instruments …
Communication infrastructure, e-commerce, ...

Economics: costs and delay of development of reliable software,
reflecting customer needs, accepted by stakeholders and the
public…

Techniques and tools evolve :
in 20 years: factor 100 (?) higher la density components
… local errors accumulate, so more large and complex
systems require more quality in local components !

Technological aspects, methodologies, management,
as in other industrial activities ...
2011-12
L2-GL - Intro
5
Software becomes BIG ...

Windows 7:





Team of 1200 programmers only
5 Bln € development costs (estimation)
Revenues : 20 Bln € (estimation) !
Legal Bindings: 15 -20 years !
Problems:
Legal Battle about Windows Server 98;
led to a settlement with the EU costing 700 mio € !

Technological aspects,
methodologies,
management, as in other industrial activities ...

That is what Software Engineering is talking about !
2011-12
L2-GL - Intro
6
Famous Software Desasters

Mariner 1 (Venus, 1962) : wrong transcription of a formula
 erratic corrections of the trajectory (crash during flight)










1981 : Delay of first start of spaceship « voyager »
(problème de synchronisation des résultats de calculateurs redondants)
1985 - 1987 : Overdosis in a radiotherapy system (Therac-25, 5 dead). Item 2007
1992 : Crash of planning and tracking system of london ambulance calls
1996 : Crash of flight 501 of Ariane 5 (« validation » problem of the systeme)
Juillet 1997 : Blocking of names of the domaine .com
Septembre 1999 : Loss of Mars Climate Orbiter after 9 months of flight.
Costs : 120 M$ (confusion of unities between two different components)
2004 : defect of reservation system for SNCF tickets,
2004 : denial of access for the Bouygues Télécom and France Telecom networks
2008 : Toll-Collect Desaster (Allemagne)
2010 : NPfIT desaster in Great Britan (Loss: 12 Billion British Pound)
2011-12
L2-GL - Intro
7
Call-backs ?
(interrogations)
Example of a call-back: Speed Control Renault Laguna (2005)
Is it an informatics-bug or not ?
Is it a problem of interaction hardware/software/environment ?
 Even if no « bug », no-one is completely convinced !


need to justify/control the « proces of construction» (Common Criteria)
need to guarantee quality of tests of final product
Ubiquity of software !
Peugeot 607 = 2 Mb of embedded software, 40 processors, 20 % total cost
«Needs» (ABS, ESP, electronic pedals, sensors, …)

Interaction of services difficult to control. Trafic/Interferences on busses …

Validation of the systeme with all combinations of variants/options ?
Future automatisation of métro lines (RATP – ligne 1: 2010)

What validation process ?

Responsabilities: RATP or industrial partners (SIEMENS)

Who authorizes finally the service ? With what prospected reliability ?
2011-12
L2-GL - Intro
8
Some figures

Size of software systems ?




Windows « 90 » : 10 M. LOC source, Win2000: 30 M. LOC
Core RedHat 7.1 (2002) : ~2.4 M. LOC, XWindow ~1.8 M.,
Space shuttle (and its environment) : ~50 MLOC
Colombus Station (abandoned) : 980 MLOC compiled ??
Development costs ?

Proportion of «Coding» : 15 - 20 %
Coding is more and more automated (CASE-tools, MDA)



Proportion of Validation and Verification ? ~ 40%
Proportion of Specification and Design ? ~ 40%
Estimation of « Necessary Manpower » (Boehm)
Man-Month = 3,5 * C1,2
(«Complexity C» very approximative, but clearly Man-Months grow non-linear!
see http://www.compapp.dcu.ie/~renaat/ca421/LWu1.html for an
overview on cost estimation methods ...)
2011-12
L2-GL - Intro
9
Des chiffres sur les « défauts logiciels »
Algorithms
25%
Specification and
design
Code
60%
15%
Distribution of faults
Algorithms
Distribution of costs of faults
9%
Code
8%
83%
Specification and design
Source: F. Fichot, Cours de Conduite de Projets, IFIPS
2011-12
L2-GL - Intro
10
Particularities of software

Complexity strongly depends on applications :




Synchronisation, repartition of processes (concurrency, true parallelism)
Nature or volume of data, existence of algorithmic problems,
Interdependency of hardware and software,
Performance or « real-time réponse » (in reactive systems)

Apparently, software is easy to modify (versatility)
but impacts/consequences of modifications are difficult to predict

Difficult prediction on fault-rates and mesurement of « quality»:



small changes may have the most dramatic consequences
(in contrast to physics: small changes have usually small impacts)
no way to predict the « probability » of impacts/consequences
Weak visibility of development processes for clients, but also management!
 Importance of the phases (requirements) analysis, design, validation
 Need for an «industrial» development process, i.e. s.th. tracable
 Need for document-orientation of the development (at least in classic S.E.)
2011-12
L2-GL - Intro
11
Different aspects of Software Engineering
MANAGEMENT PROCESS
Development Mgt.
Risc Management
Configuration
Management
« PeopleWare »
(Staff, Sub-contractors)
FEASIBILITY STUDIES
(BEFORE PROJET)
SPECIFICATION &
DESIGN
Development
PRODUCTION
INTEGRATION &
VALIDATION
EXPLOITATION
Maintenance
& Support
QUALITY
CONTROL
METRICS
PROCESSUS
QUALITE
TECHNICAL PROCESS
2011-12
QUALITY
ASSURANCE
L2-GL - Intro
12
Organisational aspects: the conduct of projets
Planning, organisation, problem detection, reaction !






Estimation of costs and delays
Planning (e.g. diagrams like PERT or GANTT charts)
Follow-ups (Suivi): management of staff, des échéances et
fournitures à remettre au client
Risk Management (prevention or corrections)
Configuration management (versioning of documents, sources,
and tests as well as keeping track of their links and dependencies)
Document management associted to different phases of software
production (part of configuration management!)
…
 and all that respecting quality norms ... (document
types, circuits de validation, règles de nommage)
2011-12
L2-GL - Intro
13
Development Phases vs. Documents

A Sequence of increasingly precise and executable documents,






Development in «phases»


Informal Requirement Specification (Cahier des charges informel)
-> model(s) of the analyse (captures / formalizes the requirements)
-> model(s) of design (captures interfaces of the implementation)
-> code (implementation)
-> validation et vérification protocols, documentation
Each phase of the development process ends by producing (versions of) these
documents verified and validated before transition to next phase.
Each phase contributes to a number of «activities», which are pervasive

Production of Documentation (user manuals(manuel utilisateur), reference manuals
(manuel de référence), installation manual (manuel d’installation),…): extended at
different phases.

Activity of Validation/Verification
2011-12
L2-GL - Intro
14
Activities and Phases (1)

Phase Requirements Analysis (capture des besoins)
Study of the environment and the system application context, analysis of
requirements and constraints (performance, ergonomics, portability,…)
Output: requirement specification (cahier des charges)

Phase specification analysis (analyse et spécification)
Description of what the system should do (and not how)
Output: analysis models

Phase architectural design (conception architecturale)
Decomposition of the software into «components»
Conception of an integration proceeding and order of the different components
(increments); conception of related tests for integration

Phase (detailed) design (conception détaillée)
Choice of algorithms, data structures,definition of interfaces and classes to
describe conception of tests which verify or validate the implementation
Output: design documents, possibly code-interfaces, code fragments,
pseudo-code, mock-ups, prototypes.
2011-12
L2-GL - Intro
15
Activities and Phases (2)

Phase coding

Phase unit test
Controled execution of tests of each procedure/method
if they behave as defined

Phase integration and intégration tests
Execution of test scenarios conceived in the analysis
(Emphasis on high-level system behaviour)

Phase Acceptance Tests and System test (by the producer)
Test global tests under real conditions (platforms, under stress,
mesuring performance, ...)

Phase Deployment (Recette; par le client) Tests, inspection of
delivered documents, possibly véerification of relevant quality norms
2011-12
L2-GL - Intro
16
Beyond phases …

Importance of documentations :
stake-holders: users, admins, mainteners, providers, general public …

Distinction of two complementary activities :
Validation: check that the right system is built
(what is needed by the client; «external» coherence)
Verification: check if the system has been built right
(what has been specified ? «internal» coherence)

Importance of tracability ! (extremely important in open-source devs!)


Document and archive the choices beend done ! (mailings, versions,...)
Enforce the coherence between the models and the product
(environments must be «forward/reverse engineered»)

Importance of archiving, version and configuration management
(versioning documents, «building» particular configurations)

Guarante of document coherence wrt. to different versions

Guarante of reconstructibility of particular versions (can you
re-build version 1.6.4.7.4. and observe if bug XXX occurs in it ?)
2011-12
L2-GL - Intro
17
And after deployment ?

Maintenance is painful and expensive !

Correction maintenance: correction of critical bugs

Adaptive maintenance: new OS version, new hardware, new performance
problems, Y2K !!!

Evolutionary maintenance: integrating new functionality
Even worse: it may be nbecessary to maintain different
versions/configurations of systems simultaneously !

Maintenance costs: 2 - 4 times more than development ?

Need for regression tests from one version to another:

Requires precise test goal descriptions
(input, expected output and
execution context + requirement trancing in tests)

Need for test automation (execution, metrics, archiving)
and, therefore, tool-chains
2011-12
L2-GL - Intro
18
Process development models …

Organisation of the phases associated documents

Structuring of the process and improve its visibility,

Development of Tool Support for a concrete process
(RUP, V Model, Spiral, Méthodes Agiles, Xtreme programming, ...)
Produce templates for associated documents
Minimise risc of „procedural“ errors the software process
Support for non-linear development (back-tracks)
(modification of requirements, correction of design errors,
modification of technical environment (platform), …) ?




Are there methodologies adapted to the general tendancies ?




Distributed aspects in informatics, Global trends like virtualization,
Need for interoperability (SOAP, WebServices, XML, …)
Component-based approches (reuse, « COTS », libraries, frameworks)
Separation of business logic (logique métier) / technical services
(Norms like spécifications J2EE et .Net, WebServices)
2011-12
L2-GL - Intro
19
The V-Model (Le Modèle en V) …
Requirements Engineering
Installation, Systeme Tests
Acceptance Tests
Specification
Architectural Design
Integration &
Integration Tests
Detailed Design
Unit Tests
Coding



Principle temporal dependencies
Potential Back-flow
Plans and Document Flow
Historically best known, and pretty pedagogical !
The descending flow produit les guides pour les phases montantes
Pédagogique, mais pas toujours adapté…(global, linéaire)
2011-12
L2-GL - Intro
20
The V-Model (Le Modèle en V) …
Analyse des besoins, Faisabilité
Installation, Test Système
Spécification
Test d’acceptation
Conception Architecturale
Intégration
Conception Détaillée

Tests unitaires

Codage



Flux temporel principal
Retour en arrière éventuel
Plans et Documents
Historically best known, and pretty pedagogical !
The descending flow produit les guides pour les phases montantes
Pédagogique, mais pas toujours adapté…(global, linéaire)
2011-12
L2-GL - Intro
21
Other process development models
Spécification

Iteration Model

Spiral Model (Boehm)
Révision
Intégration et
deploiement
Version 2
Version 1
Analyse de risques
Prototype
Incrément n
Validation
Exigences
Spécification
Implémentation
Conception
Principes généraux:
Diminuer les risques, meilleure visibilité, retours utilisateur rapides,
Intégration et validation progressive des fonctionnalités
2011-12
L2-GL - Intro
22
Development process models en vogue

Xtreme Programming (and other méthodes agiles such as SCRUM)
http://www.en.wikipedia.org/wiki/Extreme_programming

Development driven by tests, « client »-centered

Permanent restructuring of code, coding in «teams of two»

Permanent presence of the client

Rational Unified Process (RUP): iterative, using UML.
http://www.idbconsulting.com/francais/incIBMRationalRUP.cfm
http://en.wikipedia.org/wiki/Rational_Unified_Process

Architecture MDA
(http://www.omg.org/mda/)
Approach based on the
transformation of UML models
2011-12
L2-GL - Intro
23
Summary

Programming in the small is not enough!
When constructing systems with more than 50000 LOC's,
the development process must be structured:






into phases
establishing a „bureaucratic“ decumentation process
tool-chains for code-generation, testing, verification,
documentation generation.
the work of 1000 of collaborators must be organized
... and financed
There is no silver-bullet,
not ONE particular SE Development Process, rather:


every process model can be found in industry,
from V-Model (large projects with public/military clients) ...
... to Methodes Agiles and Xtreme Programming (google)
... to MDA (e.g. SAP)
2011-12
L2-GL - Intro
24