Vous êtes sur la page 1sur 49

GL.

1 / Introduction 2012-2013
1
1. Introduction
1.1 Dfinition du GL
Le Gnie Logiciel (Software Engineering) est un domaine des sciences de l'ingnieur dont la finalit
est la conception, la fabrication et la maintenance de systmes logiciels complexes, srs et de
qualit. C'est un ensemble de mthodes, techniques et outils pour la production et la maintenance
de composants logiciels de qualit.
Contrairement au dveloppement artisanal (production individuelle d'un systme simple), dans le
cas du GL, il s'agit d'une production collective d'un systme complexe concrtise par un
ensemble de documents de conception, de programmes et de jeux de tests avec souvent de
multiples versions (multi-person construction of multi-version software).
1.2 Problmatique
Compte tenu des volutions des techniques de programmation, du matriel et des besoins,
plusieurs problmes ont confront le dveloppement de logiciels dont les plus importants sont :
Taille et complexit des systmes logiciels de plus en plus accrues :
- Besoins et fonctionnalits qui augmentent et voluent sans arrt
- Evolution du matriel
- Diversification des architectures
Dlais de ralisation courts
Dveloppement collectif (diffrents intervenants au dveloppement avec des comptences
multiples).
Les difficults lies la nature du logiciel
un logiciel ne s'use pas, sa fiabilit ne dpend que de sa conception
mais, pour rester utilis, un logiciel doit voluer
pas de direction clairement exprime
changements frquents
contradictions des besoins, etc.
Les difficults lies aux personnes
ne savent pas toujours ce qu'elles veulent, ou ne savent pas bien l'exprimer
communication difficile entre personnes de mtiers diffrents
Les difficults technologiques
courte dure de vie du matriel
beaucoup de mthodes et de langages
volution des outils de dveloppement, etc.
GL.1 / Introduction 2012-2013
2
1.3 Objectifs du GL La rgle du CQFD
Le GL se proccupe des procds de fabrication de logiciels de faon s'assurer que les quatre
critres suivants soient satisfaits :
Le systme dvelopp doit assurer les fonctionnalits attendues ;
Les cots du dveloppement doivent rester dans les limites prvues au dpart ;
Les dlais doivent rester dans les limites prvues au dpart ;
La qualit du logiciel correspond au contrat de service initial. C'est une notion multiforme qui
recouvre :
Fiabilit : capacit d'un logiciel assurer de manire continue le service attendu,
Correction (validit) : aptitude d'un logiciel raliser exactement les tches telles qu'elles
ont t dfinies par sa spcification,
Robustesse : aptitude d'un logiciel fonctionner mme dans des conditions anormales,
Extensibilit : facilit d'adaptation d'un logiciel aux changements de spcification,
Rutilisabilit : aptitude d'un logiciel tre rutilis en tout ou partie,
Compatibilit : aptitude des logiciels tre combins les uns aux autres,
Efficacit : capacit d'un logiciel bien utiliser le minimum des ressources matrielles
(mmoire, puissance de l'U.C., etc.),
Portabilit : facilit tre port sur diffrents environnements matriels et/ou logiciels,
Traabilit : capacit identifier et/ou suivre un lment du cahier des charges li un
composant logiciel,
Vrifiabilit : aptitude d'un logiciel tre test (optimisation de la prparation et de la
vrification des jeux d'essai)
Intgrit : aptitude d'un logiciel protger ses composants contre des accs ou des
modifications non autoriss,
Autres qualits : facilit d'utilisation, rparabilit, etc.
Ces qualits sont parfois contradictoires (chic et pas cher!). Il faut les pondrer selon le type du
logiciel (critique/grand public, systmes sur mesure/produits logiciels de grande diffusion, etc.).
1.4 Objectifs de la premire partie du cours
Couvrir le domaine de la production de logiciels
mettre en vidence les besoins
aspects organisationnels
o cycles de vie
o dmarches
aspects techniques
o mthodes
o spcification
o design patterns
o qualit, test.
GL.2 / Cycles de Vie de Logiciels 2012-2013
3
2. Cycles de vie de logiciels
2.1 Introduction
Le cycle de vie du logiciel (ou processus de dveloppement) est un ensemble cohrent dactivits
pour spcifier, concevoir, implmenter et tester des systmes logiciels. Il y a alors diffrents
livrables (modles danalyse, codes sources, manuels dutilisation, etc.) associs chaque activit.
2.1.1 Activits
a. - Etude de faisabilit : dterminer si le dveloppement propos est ralisable.
- Analyse du march : dterminer sil y a un march potentiel pour ce produit.
b. - Expression des besoins : dterminer quelles sont les fonctionnalits que le logiciel doit offrir.
- Recueil des besoins : obtenir les besoins partir des utilisateurs.
- Analyse du domaine : dterminer quelles sont les tches et les structures qui sont communes
ce problme.
c. - Planification du projet : dterminer comment dvelopper le logiciel.
- Analyse des cots : dterminer les estimations du cot.
- Assurance qualit : dterminer les activits qui permettront dassurer la qualit du produit
pour garantir la satisfaction du client (selon les objectifs contractuels).
- Structure work-breakdown : dterminer les sous-tches ncessaires pour dvelopper le
produit.
d. - Conception : dterminer comment le logiciel doit fournir la fonctionnalit.
- Conception architecturale : concevoir la structure du systme.
- Conception dinterfaces : spcifier les interfaces entres les diffrentes parties du systme.
- Conception dtaille : concevoir les algorithmes pour les parties individuelles.
e. - Implmentation : construire le logiciel.
f. - Test : excuter le logiciel avec des donnes pour permettre de sassurer que le logiciel opre
correctement.
- Test unitaire : tester par le dveloppeur original.
- Test dintgration : tester durant lintgration du logiciel.
- Test du systme : tester le logiciel dans un environnement.
- Test dacceptation : tester pour satisfaire le client.
GL.2 / Cycles de Vie de Logiciels 2012-2013
4
g. - Livraison : fournir au client une solution logicielle efficace.
- Installation : mettre le logiciel disponible dans le site oprationnel du client.
- Formation : former les utilisateurs utiliser le logiciel et rpondre leurs questions.
h. - Maintenance : mettre--jour et amliorer le logiciel pour garantir une utilisation efficace
continue.
2.1.2 Documents
Les rsultats des diffrentes activits sont reprsents par plusieurs types de documents, dont les
plus importants sont :
- Spcification des besoins logiciels : dcrit ce que doit faire le logiciel.
- Modle dobjet : montre les principaux objets / classes.
- scnarios de cas dutilisation : montrent les squences des comportements possibles du point de
vue utilisateur.
- Plan du projet : dcrit lordre des tches et estime les besoins en matire temps et efforts.
- Plan de test du logiciel : dcrit comment le logiciel serait test pour garantir un comportement
correct.
- Conception du logiciel : dcrit la structure du logiciel
- Plan assurance qualit du logiciel : dcrit les activits effectuer pour assurer la qualit.
- Manuel dutilisation : dcrit comment utiliser le logiciel final.
- Code source : le code du produit final.
- Rapport du test : dcrit quels sont les tests effectus et quel tait le comportement du systme.
2.2 Modles de cycles de vie
Un modle dun processus de dveloppement est une reprsentation abstraite dun processus. Il
prsente la description du processus dune perspective particulire. Nous avons quatre principaux
modles de cycles de vie de logiciel :
2.2.1 Modle squentiel linaire
Appel aussi le modle en cascade (Waterfall model) du fait que le diagramme ressemble des
sries de cascades. Cest un modle adapt seulement quand tous les besoins sont bien
dtermins priori.
GL.2 / Cycles de Vie de Logiciels 2012-2013
5
Figure 1. Modle en cascade.
Le modle dorigine a t dcrit initialement par Royce (1970), mais actuellement il y a plusieurs
versions qui peuvent mettre laccent sur certaines activits et ngliger dautres selon le besoins.
Dans la version prsente par la figure 1, les activits de planification du projet sont inclues dans la
phase expression des besoins. Dautre part, les phases livraison et maintenance ont t ngliges
dans cette version du modle.
Lune des variantes les plus importantes de ce modle et qui a t mme considre comme tant
un modle part entire est le modle en V (figure 2).
Figure 2. Modle en V.
2.2.2 Modle de prototypage
Ce modle de cycles de vie construit un prototype pour tester les concepts et les besoins. Aprs
accord du client, le dveloppement du logiciel se poursuit en passant toujours par les mmes
phases du modle prcdent.
Etude de
Faisabilit
Expression
Besoins
Conception
Test
Implmentation
GL.2 / Cycles de Vie de Logiciels 2012-2013
6
2.2.3 Modle incrmental
Propos par D. L. Parnas (1979) pour concevoir et livrer au client un sous-ensemble oprationnel
du systme global. Le processus continue ditrer, comme le montre la figure 3, travers le cycle
de vie global avec des incrments additionnels.
Figure 3. Modle incrmental.
2.2.4 Modle en spirale
Cest un modle qui a t introduit par B. Boehm (1988). Limage du modle est une spirale qui
commence au milieu et qui ritre continuellement les tches de base (figure 4).
Figure 4. Modle en spirale.
Systme final
Systme incomplet
Dfinir les besoins
Assigner les besoins aux
incrments
Concevoir larchitecture
du systme
Dvelopper incrment Valider systme Intgrer incrment Valider incrment
GL.2 / Cycles de Vie de Logiciels 2012-2013
7
Les principaux risques et leurs remdes, tels que dfinis par Boehm, sont les suivants :
- Dfaillance de personnel : embauches de haut niveau, formation mutuelle, leaders,
adquation profil/fonction, ...
- Calendrier et budgets irralistes : estimation dtaille, dveloppement incrmental,
rutilisation, lagage des besoins, ...
- Dveloppement de fonctions inappropries : revues dutilisateurs, manuel dutilisation
prcoce, ...
- Dveloppement dinterfaces utilisateurs inappropries : maquettage, analyse des tches, ...
- Produit "plaqu or" : analyse des cots/bnfices, conception tenant compte des cots, ...
- Volatilit des besoins : dveloppement incrmental de la partie la plus stable dabord,
masquage dinformation, ...
- Problmes de performances : simulations, modlisations, essais et mesures, maquettage,
- Exigences dmesures par rapport la technologie : analyses techniques de faisabilit,
maquettage, ...
- Tches ou composants externes dfaillants : audit des sous-traitants, contrats, revues,
analyse de compatibilit, essais et mesures, ...
2.2.5 Autres modles
Il y a plusieurs autres modles ou variantes de modles dj existants tels que le modle de
dveloppement des systmes formels, dveloppement bas rutilisation, programmation
extrme, etc.
GL.3 / Mthodes danalyse et de conception 2012-2013
8
3 Mthodes d'analyse et de conception
3.1 Introduction
Les mthodes d'analyse et de conception fournissent des notations standards et des dmarches
pratiques pour aboutir des conceptions appropries.
3.2 Classification des mthodes
Il existe diffrentes manires pour classer ces mthodes, dont :
la distinction composition / dcomposition : les mthodes peuvent tre ascendantes et
consistent construire un logiciel par composition de modules existants ou, descendantes
et dcomposent rcursivement un systme jusqu' arriver des modules simples ;
la distinction fonctionnel / objet. Dans un raisonnement fonctionnel, le systme est
considr comme un ensemble d'units fonctionnelles en interaction. Les fonctions
disposent d'un tat local, mais le systme a un tat centralis partageable par l'ensemble
des units fonctionnelles. Par contre, un raisonnement objet considre qu'un systme est
un ensemble d'objets en interaction. Chaque objet dispose d'un ensemble d'attributs
dcrivant son tat et l'tat du systme est dcrit (de faon dcentralis) par l'tat de
l'ensemble des objets constituant ce systme.
3.2.1 Mthodes fonctionnelles (annes 60)
Bases sur une dcomposition fonctionnelle du systme (inspire de larchitecture des
ordinateurs), les mthodes fonctionnelles trouvent leur origine dans les langages procduraux.
Elles mettent en vidence les fonctions assurer et proposent une approche hirarchique
descendante et modulaire. Ces mthodes utilisent les raffinements successifs dont le plus haut
niveau reprsente l'ensemble du problme. Chaque niveau est ensuite dcompos en respectant
les entres/sorties du niveau suprieur. La dcomposition se poursuit jusqu' arriver des
composants simples et matrisables.
En plus des problmes rencontrs avec les langages procduraux, ce style de raisonnement
dissimule galement une srieuse limite touchant directement la stabilit de l'architecture du
systme. En fait, cette dernire est base principalement sur des fonctionnalits qui peuvent tre
sujet de modifications ou d'volutions.
Parmi ces mthodes, nous pouvons citer SA (Structured Analysis), SART (Structured Analysis for
Real Time systems), SADT (Structured Analysis and Design technique), etc.
3.2.2 Mthodes systmiques (annes 70)
Une variante des mthodes fonctionnelles qui spare compltement les donnes des traitements.
Une tape de validation du systme de donnes par celui des traitements est alors ncessaire. Ce
type de mthodes est trs bien adapt pour les systmes d'information d'entreprise.
GL.3 / Mthodes danalyse et de conception 2012-2013
9
Exemple : MERISE (Mthode d'Etude et de Ralisation Informatique des Systmes d'Entreprises),
etc.
3.2.3 Mthodes Objet (annes 80)
L'approche objet propose une mthode de dcomposition (dcomposer pour runir) base sur
l'intgration de ce que le systme est (structure) et fait (fonction). Le systme est constitu d'un
ensemble d'objets en interaction (par change de messages) pour raliser les fonctionnalits
attendues. L'architecture du systme est alors base sur la partie statique qui est plus stable.
Le principe de l'orientation objet tant bas sur l'identification et l'organisation des concepts du
domaine d'application, plutt que leur reprsentation terminale dans un langage de
programmation qu'il soit orient objet ou non. Ce processus est un style de raisonnement et non
pas une technique de programmation, entre autres, il est indpendant des langages de
programmation jusqu'aux derniers stades. Il se concentre sur la modlisation et non pas sur
l'implantation des concepts, ce qui permet de bien comprendre et organiser les concepts
inhrents l'application avant de chercher une implantation efficace des structures de donnes et
des algorithmes. Aussi, en plus de prparer la programmation, la modlisation peut servir de
support pour la documentation et l'interface avec le client.
Les principaux avantages des ces mthodes peuvent tre :
stabilit de la modlisation par rapport aux entits du monde rel,
construction itrative facilite par le couplage faible entre composants,
possibilits de rutiliser des lments dun dveloppement un autre,

Cependant, les mthodes objet restent encore rcentes et trouvent toujours des difficults dans le
dveloppement de systmes critiques, temps rel, ou encore embarqus qui ncessitent des
mthodes rigoureuses permettant d'accomplir une vrification formelle.
Exemple : OMT (Object Modeling Technique), Booch'93 (le nom de son auteur), OOD (Object
Oriented Design), OOSE (Object Oriented Software Engineering), etc.
3.3 Spcification
Tout produit complexe construire doit d'abord tre spcifi ; par exemple un pont de 30 mtres
de long, supportant au moins 1000 tonnes, construit en bton, etc. ces spcifications peuvent tre
considres comme un contrat entre le client (la collectivit qui veut raliser le pont) et le
producteur (l'entreprise de gnie civil).
En informatique, le client et le producteur peuvent tre diffrents selon les phases du cycle de vie
du logiciel :
GL.3 / Mthodes danalyse et de conception 2012-2013
10
Spcification des besoins ou spcification des exigences (requirements specification) : c'est
un contrat entre les futurs utilisateurs et les concepteurs. Elle concerne les caractristiques
attendues (exigences fonctionnelles et non fonctionnelles : efficacit, sret, portabilit,
taille, etc.). Elle intervient en phase d'analyse des besoins et se rdige en langue naturelle.
Spcification du systme : c'est un contrat entre les futurs utilisateurs et les concepteurs et
concerne la nature des fonctions offertes, les comportements souhaits, les donnes
ncessaires, etc. Elle intervient pendant la phase d'analyse du systme.
Spcification de l'architecture du systme : c'est un contrat entre les concepteurs et les
ralisateurs et dfinit l'architecture en modules de l'application raliser. Elle intervient
pendant la phase de conception gnrale.
Spcification technique (d'un module, d'un programme, d'une structure de donnes, etc.) :
c'est un contrat entre le programmeur qui l'implmente et les programmeurs qui
l'utilisent. Elle intervient pendant la phase de conception dtaille.
De manire gnrale, une spcification dcrit les caractristiques attendues (le quoi) d'une
implmentation (le comment).
Il est souhaitable qu'une spcification soit claire, non ambigu et comprhensible,
Les spcifications du langage naturel manquent souvent de prcision,
Les spcifications doivent aussi tre cohrentes et compltes. Ici, la compltude peut
prendre deux formes :
- Interne : tous les concepts utiliss sont compltement spcifis,
- Externes : compltude de la spcification par rapport la ralit dcrite. C'est une
forme quelque peu illusoire en pratique ; on ne peut pas en gnral spcifier tous
les dtails qui entourent le systme.
3.3.1 Classification des styles de spcification
Il y deux critres de classification orthogonaux :
Formalit : on distingue les spcifications informelles (langage naturel), semi-formelles
(smantique plus ou moins prcise souvent graphique), et formelles (syntaxe et
smantique dfinies formellement par des outils mathmatiques).
Caractre oprationnel ou dclaratif : les spcifications oprationnelles dcrivent le
comportement dsir par un modle ce qui permet d'une certaine manire de le simuler;
par opposition, les spcifications dclaratives dcrivent seulement les proprits dsires.
3.3.2 Techniques de spcification
Les techniques de spcification utilises dans les mthodes danalyse et de conception peuvent
tre :
- Les spcifications en langage naturel,
- Les spcifications techniques avec des langages spcialiss
GL.3 / Mthodes danalyse et de conception 2012-2013
11
- Les machines d'tats finis
- Les rseaux de Petri
- Les schmas entit-association
- Les spcifications formelles et logiques temporelles
-
Souvent, les techniques de spcification se compltent pour dcrire diffrentes vues d'un mme
systme. Les mthodes tentent de proposer des assemblages efficaces de telles techniques avec
des guides pour les construire et les valider. Le langage de modlisation UML constitue une bonne
combinaison des diffrentes techniques de spcifications objets couvrant la totalit des aspects
fonctionnel, statique, dynamique et architectural d'une application logicielle.
3.4 Langage de modlisation unifi (UML)
UML est un langage de modlisation objet qui permet de spcifier, construire, visualiser et dcrire
les artfacts d'un systme logiciel. Le langage reprsente l'tat de l'art des langages de
modlisations objets et possde une notation graphique riche et expressive.
UML permet la modlisation de la structure et du comportement du systme indpendamment de
toute mthode ou de tout langage de programmation.
- Spcifier & Documenter : modlisation prcise, non ambigu et complte
Syntaxe et smantique bien dfinies des lments de modlisation UML.
Support complet pour les tapes analyse, architecture/conception, implmentation,
et test.
- Construire : mapping UML- OOPL (langage de programmation orients objet).
- Visualiser : notation graphique riche et expressive.
Le langage de modlisation unifi ou UML est une notation graphique standard semi formelle qui
regroupe les meilleures pratiques de lobjet et est adopt par l'OMG (Object Management Group).
3.4.1 Historique
Au dbut des annes 90, il a t constat que les mthodes objet (environ une cinquantaine)
taient lies uniquement par un accord sur les concepts de base de l'objet (attribut, objet, classe,
hritage, ). Cependant, chacune des ces mthodes possdait sa propre notation et aucune
mthode ne pouvait prtendre couvrir tous les besoins ni modliser correctement les diffrentes
vues de l'application.
En 1995, des efforts d'unification des mthodes objet, pratiques industrielles et notations ont
conduit la proposition de la mthode unifie (Unified Method). Cette tentative a chou pour les
deux principales raisons :
Dissemblance des styles de conception des dveloppeurs,
Diversit des classes de systmes dvelopper (ordinaire/critique, ).
GL.3 / Mthodes danalyse et de conception 2012-2013
12
En fait, les mthodes objet se partagent les concepts objets et non pas les dmarches. Les efforts
ont t orients depuis vers l'unification des notations manipules par les mthodes ; UML a ainsi
vu le jour.
L'historique en quelques points.
Apparition des langages OO (mi 60 et fin 80)
Entre 89 et 94, le nombre de mthodes OO a augment de 10 50.
En 1995 tentative d'unification des mthodes objet, pratiques industrielles et notations :
Unified Method v0.8 draft 95,
Efforts rorients vers l'unification des notations.
UML (Unified Modeling Language) propos en 1996,
Normalisation OMG.
UML v0.9 en Juin 96,
UML 1.1 adopt par l'OMG en novembre 97,
UML 1.3 en 99,
UML 1.4 (UML 1.4.2 standard ISO/IEC 19501),
UML 2.0 2003,
UML 2.1.2 novembre 2007,
Version actuelle : UML 2.4.1 ; les travaux d'amlioration continuent toujours
http://www.uml.org/
Principaux auteurs :
Ivar Jacobson (OOSE),
Grady Booch (BOOCH'93),
James Rumbaugh (OMT), et
Autres partenaires
Rle de l'OMG (Object Management Group) http://www.omg.org/
Standardisation des technologies Objet (UML, CORBA, etc.),
Rvisions bases sur les contributions de la communaut des concepteurs UML.
3.4.2 Organisation du langage.
UML n'impose pas un processus de dveloppement particulier, mais il est prfrable (selon ses
auteurs) de prvoir un processus de dveloppement centr sur l'architecture, guid pas les cas
d'utilisation, itratif et incrmental (principales caractristiques du Processus Unifi). La figure 3.1
prsente l'organisation en vues des neuf principaux diagrammes UML (UML 1.4).
GL.3 / Mthodes danalyse et de conception 2012-2013
13
Fig. 3.1 organisation d'UML.
3.5 Diagrammes UML
A partir de la version 2.0, UML a dfini quatre nouveaux diagrammes et une nouvelle structuration
de sa collection de treize diagrammes : structure, comportement et interaction.
Structural Diagrams
Class
Object
Package
Composite Structure
Component
Deployment
Behavioral Diagrams
Use case
State Machine
Activity
Interaction Diagrams
Sequence
Communication
Interaction Overview
Timing
Vue Processus
Machines d'tats
diagramme d'activits
Vue logique
diagramme de classes, d'objets
diagramme de squence,
diagramme de collaborations.
Vue de dploiement
diagramme de dploiement
Vue d'environnement
Vue d'implmentation
diagramme de composants
Vue utilisateur
diagramme de cas
d'utilisation
GL.3 / Mthodes danalyse et de conception 2012-2013
14
3.5.1 Diagrammes de Structure
Cette partie dfinit les constructions statiques et structurelles (classes, composants, nuds, etc.)
et leurs utilisations dans les diffrents diagrammes structurels, tels que le diagramme de classes,
le diagramme de composants, et le diagramme de dploiement.
3.5.1.1 Diagramme de Classes
Un diagramme de classe exprime de manire gnrale la structure statique du systme en termes
de classes et de relations entre classes. Un diagramme de classes regroupe gnralement les
lments de modlisation suivants : Association, Aggregation, Class, Composition, Dependency,
Generalization, Interface, InterfaceRealization, Realization.
3.5.1.2 Diagramme dObjets
C'est une instance d'un diagramme de classe (comprenant des objets et des valeurs relles) qui
donne une image instantane de l'tat dtaill du systme. Un diagramme d'objets contient
principalement des objets (instances de classes) et des liens (instances d'associations).
3.5.1.3 Diagrammes de Packages
Un package est utilis pour grouper des lments (et mme d'autres packages) et fournir ainsi un
namespace pour ce groupe d'lments.
Un package peut importer soit une partie ou la totalit des membres des autres packages. En plus,
une relation 'merge' peut tre galement dfinie entre packages.
Fig. 3.2 diagramme de packages.
Les lments de modlisation typiquement utiliss dans un diagramme de package sont :
Dependency, Package, PackageExtension, et PackageImport.
GL.3 / Mthodes danalyse et de conception 2012-2013
15
3.5.1.4 Diagramme de Structure Composite
Un diagramme de structure composite montre la structure interne d'un classificateur, ainsi que
l'utilisation d'une collaboration dans un 'collaboration use'. Le terme "structure" dsigne ici une
composition d'lments interconnects, reprsentant des instances run-time en collaboration
travers des liens de communications pour accomplir certains objectifs communs.
Structures internes. Des structures d'lments interconnects qui sont crs dans une instance du
classificateur container. Une structure de ce type reprsente une dcomposition de ce
classificateur.
Ports. Dont l'objectif est d'isoler un classificateur de son environnement en offrant un point
permettant d'accomplir les interactions entre ses lments internes du classificateur et son
environnement. Ce dcouplage entre les lments internes du classificateur et son environnement
permet une dfinition indpendante et mme rutilisable du classificateur.
Collaborations. Les Collaborations permettent une description exclusive des aspects pertinents
d'une coopration d'un ensemble d'instances par l'identification des rles spcifiques jous par
chacune de ces instances.
GL.3 / Mthodes danalyse et de conception 2012-2013
16
Fig. 3.3 collaboration.
Classes structures. C'est un moyen permettant la reprsentation des classes qui peuvent avoir
des ports en plus d'une structure interne.
Fig. 3.4 classes structures.
3.5.1.5 Diagramme de Composants
Les diagrammes de composants montrent la structure des composants, les classificateurs qui les
spcifient (classes d'implmentation par exemple) et les artfacts qui les implmentent (code
source, binaire, excutables, etc.). Ces diagrammes contiennent gnralement des composants
(descriptions d'implmentation) qui peuvent tre composites, et des dpendances (utilisations de
services des composants).
GL.3 / Mthodes danalyse et de conception 2012-2013
17
Fig. 3.5 diagramme de composants.
Les composants reprsentent en gnral des implmentations de classes, implantent des services
et/ou requirent des services offerts par d'autres composants. Le type du composant peut tre
spcifi par un strotype (document, excutable, table, etc.).
3.5.1.6 Diagrammes de Dploiement
Les diagrammes de dploiement refltent la structure des nuds sur lesquels les composants sont
dploys et les moyens de communication entre ces nuds. Ils existent sous deux formes :
spcification et instance. En gnral, un nud reprsente une ressource matrielle qui possde
ses propres attributs (capacit mmoire, vitesse d'horloge, ). La nature de ces ressources peut
tre prcise par un strotype (environnement d'excution, dispositif, etc.).
Fig. 3.6 diagramme de dploiement.
GL.3 / Mthodes danalyse et de conception 2012-2013
18
Dans l'exemple que montre la figure 2.8, les composants dploys sont exprims textuellement
(Order.jar, OrderSchema.dll, ).
3.5.2 Diagrammes du Comportement
3.5.2.1 Diagramme de Cas d'utilisation
Les cas d'utilisation dcrivent les fonctionnalits d'un systme ou d'un classificateur (sous-systme
ou classe) du point de vue de lutilisateur (ou des lments externes) en interaction avec le
systme ou le classificateur.
Un cas d'utilisation dcrit le comportement du systme du point de vue d'un utilisateur en
prcisant les limites du systme et ses relations avec l'environnement.
Un acteur reprsente un rle jou par une personne ou un systme externe qui interagit avec le
systme tudi ; la mme personne physique (ou systme externe) peut jouer diffrents rles
(donc diffrents acteurs).
Un diagramme de cas d'utilisation traduit la relation entre les cas d'utilisation dans le systme et
leurs acteurs. Des descriptions dtailles des diffrents scnarios possibles du mme cas peuvent
tre ralises laide des diagrammes dinteraction.
Relations entre cas d'utilisation :
Gnralisation. Le cas d'utilisation fils est une spcialisation du cas pre.
Inclusion. Une instance du cas source comprend le comportement dcrit par le cas cible.
Extension. Le cas source ajoute son comportement au cas destination; l'extension est soumise la
vrification d'une condition (point d'extension).
Dans l'exemple :
Fig 3.7 un diagramme de cas d'utilisation.
GL.3 / Mthodes danalyse et de conception 2012-2013
18
Dans l'exemple que montre la figure 2.8, les composants dploys sont exprims textuellement
(Order.jar, OrderSchema.dll, ).
3.5.2 Diagrammes du Comportement
3.5.2.1 Diagramme de Cas d'utilisation
Les cas d'utilisation dcrivent les fonctionnalits d'un systme ou d'un classificateur (sous-systme
ou classe) du point de vue de lutilisateur (ou des lments externes) en interaction avec le
systme ou le classificateur.
Un cas d'utilisation dcrit le comportement du systme du point de vue d'un utilisateur en
prcisant les limites du systme et ses relations avec l'environnement.
Un acteur reprsente un rle jou par une personne ou un systme externe qui interagit avec le
systme tudi ; la mme personne physique (ou systme externe) peut jouer diffrents rles
(donc diffrents acteurs).
Un diagramme de cas d'utilisation traduit la relation entre les cas d'utilisation dans le systme et
leurs acteurs. Des descriptions dtailles des diffrents scnarios possibles du mme cas peuvent
tre ralises laide des diagrammes dinteraction.
Relations entre cas d'utilisation :
Gnralisation. Le cas d'utilisation fils est une spcialisation du cas pre.
Inclusion. Une instance du cas source comprend le comportement dcrit par le cas cible.
Extension. Le cas source ajoute son comportement au cas destination; l'extension est soumise la
vrification d'une condition (point d'extension).
Dans l'exemple :
Fig 3.7 un diagramme de cas d'utilisation.
GL.3 / Mthodes danalyse et de conception 2012-2013
18
Dans l'exemple que montre la figure 2.8, les composants dploys sont exprims textuellement
(Order.jar, OrderSchema.dll, ).
3.5.2 Diagrammes du Comportement
3.5.2.1 Diagramme de Cas d'utilisation
Les cas d'utilisation dcrivent les fonctionnalits d'un systme ou d'un classificateur (sous-systme
ou classe) du point de vue de lutilisateur (ou des lments externes) en interaction avec le
systme ou le classificateur.
Un cas d'utilisation dcrit le comportement du systme du point de vue d'un utilisateur en
prcisant les limites du systme et ses relations avec l'environnement.
Un acteur reprsente un rle jou par une personne ou un systme externe qui interagit avec le
systme tudi ; la mme personne physique (ou systme externe) peut jouer diffrents rles
(donc diffrents acteurs).
Un diagramme de cas d'utilisation traduit la relation entre les cas d'utilisation dans le systme et
leurs acteurs. Des descriptions dtailles des diffrents scnarios possibles du mme cas peuvent
tre ralises laide des diagrammes dinteraction.
Relations entre cas d'utilisation :
Gnralisation. Le cas d'utilisation fils est une spcialisation du cas pre.
Inclusion. Une instance du cas source comprend le comportement dcrit par le cas cible.
Extension. Le cas source ajoute son comportement au cas destination; l'extension est soumise la
vrification d'une condition (point d'extension).
Dans l'exemple :
Fig 3.7 un diagramme de cas d'utilisation.
GL.3 / Mthodes danalyse et de conception 2012-2013
19
Le comportement "Retrait Distant" est une spcialisation du comportement "RetraitCCP".
Le comportement "RetraitCCP" inclut toujours celui de "Authentification".
Le comportement "Vrification Signature" tend le comportement "RetraitCCP" ; le point
d'extension tant "MontantRetrait 20.000DA".
3.5.2.2 Machines d'tats (Statecharts)
Les machines d'tats (drives des statecharts 1987) dcrivent le comportement des instances
d'un lment modle (objet ou interaction par exemple). Elles reprsentent les squences
possibles des tats et des actions par lesquels les instances de l'lment peuvent passer en
raction aux vnements reus (signal, invocations d'opration, etc.). Une machine d'tat est
attache d'habitude chaque classe active dans le diagramme de classes. Le comportement global
du systme est dfini par l'ensemble des machines d'tats des objets actifs constituants ce
systme.
Evnement. Un stimulus pouvant gnrer des ractions dans le systme. Il peut avoir diffrentes
formes : appel, signal, changement ou temporel.
Etat. C'est une tape dans l'volution du systme pendant laquelle, il excute une action ou
attend un vnement. Le systme doit galement satisfaire une condition appele invariant tant
qu'il se trouve dans cet tat. Les tats peuvent tre simples, composites squentiels ou composites
concurrents.
Transition. Passage ventuel d'un tat un autre (qui peut tre le mme). Les transitions sont
instantanes et le temps ne peut s'couler que si le systme est dans un tat propre. Chaque
transition est caractrise par un tat source, un tat destination, un vnement dclencheur
(trigger), une garde (condition) et une liste d'actions excuter lors du franchissement de la
transition :
Smantique oprationnelle. Aprs occurrence de l'vnement dclencheur, si la garde de la
transition est value vrai, la transition est dite alors franchissable. Elle est excute (tire ou
traverse) s'il existe une configuration atteignable (sans violation d'invariant) et si la transition ne
prsente aucun conflit avec le reste des transitions franchissables. Deux transitions excutables
prsentent un conflit si elles appartiennent une mme hirarchie d'tats. UML donne priorit
la transition du plus bas niveau et les autres transitions conflictuelles seront alors abandonnes.
Le principe de base dexcution dune machine dtats est quelle traite un seul vnement la
fois et finit de traiter toutes ses consquences avant den traiter un autre (run-to-completion). Les
GL.3 / Mthodes danalyse et de conception 2012-2013
20
actions sont instantanes et les vnements ne sont jamais simultans. Si un nouvel vnement
(deferrable) est reconnu pendant lexcution d'une tape run-to-completion, loccurrence de
lvnement est place dans un pool dvnement (aucune structure de donnes n'est impose).
Aprs achvement d'une tape RTC, le systme traite tous les vnements dans le pool un par un
(aucune politique de slection n'est impose) de la mme manire et excute ses transitions et
passe une autre configuration stable.
Fig. 3.8 un exemple d'une machine d'tats.
3.5.2.3 Diagrammes d'activit
C'est une variante des machines d'tats dans laquelle les tats reprsentent l'excution des
actions (ou sous-activits) et les transitions sont dclenches par accomplissement des actions
(ou sous-activits). Ils sont proposs pour la reprsentation du comportement des oprations
d'une classe ou la formalisation d'un processus d'une organisation.
Fig. 3.9 diagramme d'activits.
GL.3 / Mthodes danalyse et de conception 2012-2013
21
3.5.3 Diagrammes d'interaction
Les diagrammes d'interaction possdent diffrentes variantes :
- diagramme de Squence qui focalise sur l'change de messages entre un nombre de lignes
de vie (lifelines),
- diagramme de Communication montrant les interactions d'un point de vue architectural,
- diagramme 'Interaction Overview' qui est une variante du diagramme d'activits
dfinissant les interactions de faon encourager la reprsentation des flots de contrle,
- diagramme 'Timing' est utilis pour la reprsentation des interactions lorsque l'objectif
principal est de raisonner sur le temps.
3.5.3.1 Diagramme de squence
Les diagrammes de squence montrent des interactions entre objets selon un point de vue
temporel. Dans ce contexte, il est utile de noter que UML propose un large ventail de
mcanismes de communication inter objets (appels d'oprations, signaux, invitations, exceptions,
envois synchrone et asynchrone, etc.).
Fig. 3.10 notation du diagramme de squence.
3.5.3.2 Diagrammes de communication (collaboration)
Ces diagrammes insistent sur les interactions entre lignes de vie du point de vue architecture de la
structure interne les changes de messages correspondants. L'ordonnancement des messages est
ralis l'aide d'un schma de numrotation de squence.
Un diagramme de collaboration, montre l'interaction organise autour des rles et leurs relations.
Le temps n'est pas montr comme dimension spare et les squences de communication et
threads concurrentes doivent tre dtermines par l'utilisation de nombres de squence. Une
collaboration est utilise pour dcrire la ralisation d'une opration ou d'un classificateur ce qui
GL.3 / Mthodes danalyse et de conception 2012-2013
22
simplifie lidentification des design patterns prsents (un pattern est une collaboration
paramtrique dont chaque utilisation, les classificateurs rels vont remplacer les paramtres de
dfinition du pattern).
Fig. 3.11 notation du diagramme de communication.
3.5.3.3 'Interaction Overview Diagrams'
Ces diagrammes dfinissent les interactions par le biais d'une variante des diagrammes d'activits
de manire dcrire le flot de contrle. Les lignes de vie et les messages n'apparaissent pas au
niveau overview.
GL.3 / Mthodes danalyse et de conception 2012-2013
23
Fig. 3.12 notation 'Interaction Overview'
3.5.3.4 'Timing Diagrams'
L'objectif principal de ces diagrammes est la reprsentation des contraintes de temps sur les
interactions. Ils dcrivent le comportement avec les temps d'occurrence des vnements qui
provoquent des changements dans les conditions ou tats modliss des lignes de vie.
GL.3 / Mthodes danalyse et de conception 2012-2013
24
Fig. 3.13 notation 1 'Timing Diagram'
Ces diagrammes peuvent tre galement utiliss pour montrer les changements d'tats d'un objet
en rponse des vnements ou stimuli d'une perspective temporelle.
Fig. 3.14 Notation 2 'Timing Diagram'
Finalement, il est possible d'avoir une forme plus labore de ces diagrammes dans laquelle
plusieurs lignes de vie et messages seront reprsents.
GL.3 / Mthodes danalyse et de conception 2012-2013
25
3.5.4 Extensibilit UML & notion de Profils
UML fournit un ensemble riche et soigneusement choisi de notations et concepts de
modlisation. Cependant, certains projets peuvent parfois exiger des mcanismes de
reprsentation additionnels autres que ceux prdfinis. Pour rpondre ce besoin, UML permet
par l'intermdiaire de ses mcanismes d'extension l'ajout de nouveaux lments de modlisation
ou de formes libres d'information. C'est un moyen pour raffiner la smantique standard d'UML et
permettre ainsi l'ajout de nouveaux lments de modlisation qui seront utiliss dans la cration
de modles UML spcifiques. Une restriction fondamentale sur toutes les extensions dfinies est
qu'elles doivent tre strictement additives la smantique standard.
Les lments d'un modle UML sont personnaliss et tendus avec de nouvelles smantiques en
utilisant des strotypes, des contraintes et des valeurs marques. Un ensemble cohrent de telles
extensions dfinies pour un objectif spcifique constitue un profil UML.
Contraintes. Des expressions crites dans un langage de dfinition de contraintes donn pour
permettre la spcification linguistique de nouvelles smantiques d'un lment modle (des
restrictions smantiques que l'lment doit obir). Le langage peut tre spcifique (OCL par
exemple), un langage de programmation, des notations mathmatiques ou le langage naturel.
Strotypes. Fournissent un moyen de classification d'lments de modlisation (classes,
associations, etc.) pour qu'ils se comportent sous certaines considrations comme tant des
instances de nouvelles constructions virtuelles du mta modle. C'est un lment modle qui
dfinit des valeurs (bases sur valeurs marques) et contraintes additionnelles et facultativement
une nouvelle reprsentation graphique. Tout lment marqu par un strotype particulier reoit
alors ces valeurs et contraintes en plus des attributs, associations et super classes que l'lment
possde.
Valeurs marques (Tagged value). Permettent d'attacher l'information n'importe quel lment
modle en conformit avec la dfinition de marque. Cette dernire (Tag definition) spcifie les
valeurs marques qui peuvent tre attaches un genre d'lments modles.
Dfinition de strotype :
Utilisation du strotype :
GL.3 / Mthodes danalyse et de conception 2012-2013
26
Utilisation du strotype avec prsentation de valeurs :
Application de plusieurs strotypes sur le mme lment de modlisation :
Profils. Les profils UML prsentent un mcanisme permettant de spcialiser le langage pour un
contexte particulier (analyse, conception technique, codage, etc.) par l'introduction de notions
plus adaptes au contexte de travail actuel, de rgles de modlisation spcifiques, et de modes de
prsentation des modles adapts.
Un profil est un package strotyp qui contient des lments de modlisation personnaliss pour
un objectif ou un domaine spcifique en tendant le mta modle par des strotypes, des
dfinitions de marques, et des contraintes.
Fig. 3.15 dfinition et utilisation de profil.
"Ahmed"
GL.3 / Mthodes danalyse et de conception 2012-2013
27
Pour traiter la complexit de certains domaines particuliers, La politique de l'OMG repose sur le
lancement de plusieurs RFPs (Requests For Proposal) spcifiques et d'valuer par la suite les
propositions. De cette manire, divers profils ont t dfinis ou amliors par l'OMG tels que le
SPT et MARTE (profils du temps rel), EDOC, CORBA, EJB, etc.
3.5.5 Langage de dfinition de contraintes (OCL)
Les diagrammes UML ne sont pas typiquement assez raffins pour fournir tous les aspects
pertinents d'une spcification. Il y a galement le besoin de dcrire des contraintes additionnelles
sur les objets du modle. D'un autre cot, les contraintes exprimes en langage naturel conduisent
souvent des ambiguts.
OCL (Object Constraint Language) est un langage formel simple dvelopp pour rpondre ce
besoin. C'est un pur langage de spcification ; il ne peut pas donc changer quoi que ce soit dans le
modle ou son excution. La version actuelle (janvier 2009) adopte par l'OMG est OCL 2.0.
OCL peut tre utilis dans diffrentes situations :
spcification d'invariants sur les classes et les types dans un modle de classes,
spcification des invariants de type pour les strotypes,
description des pr et post-conditions sur les oprations et les mthodes,
description des gardes,
spcification des destinations des messages et actions,
spcification de contraintes sur les oprations,
spcification des rgles de drivation d'attributs pour toute expression sur un modle
UML.
Un exemple de contrainte OCL attache l'attribut numberOfEmployees d'une classe Company :
context Company inv:
self.numberOfEmployees > 50
Des contraintes de pr et post-condition d'une opration peuvent tre exprimes de la manire
suivante :
context Typename::operationName(param1 : Type1, ... ): ReturnType
pre parameterOk: param1 > ...
post resultOk : result = ...
GL .4/ Concepts Objet 2012-2013
28
4 Concepts objet
4.1 L'objet
Un objet dfinit une reprsentation dune entit atomique relle ou virtuelle, dans le but de le
piloter ou de le simuler. Il encapsule une partie des connaissances du monde dans lequel il volue.
Un objet associe donnes et traitements en ne laissant visible que linterface de lobjet (les
traitements que lon peut faire dessus).
Objet = Identit + Etat + Comportement
- Lidentit : permet de distinguer l'objet de manire non ambigu indpendamment de son
Etat (non explicite);
- Ltat : dfini par les valeurs instantanes de tous les attributs dun objet. Il volue au
cours du temps;
- Le comportement : regroupe toutes les comptences (services) dun objet et dcrit les
actions et les ractions de cet objet. Chaque comportement lmentaire d'un objet est
appel opration et est dclench suite une stimulation externe (message envoy par un
autre objet).
Les objets dun systme informatique travaillent en collaboration pour raliser les fonctions de
lapplication. Le comportement global de l'application repose sur la communication entre les
objets. Cette communication est ralise par envoi et rception de messages.
4.2 Dmarche d'abstraction
L'abstraction consiste concentrer la rflexion sur un lment d'une reprsentation en ngligeant
tous les autres.
La dmarche d'abstraction procde de l'identification des caractristiques communes un
ensemble d'lments, puis de la description condense de ces caractristiques dans ce qui est
appel classe. La dmarche se dfinit par rapport un point de vue (critres pertinents dans le
domaine considr).
GL .4/ Concepts Objet 2012-2013
28
4 Concepts objet
4.1 L'objet
Un objet dfinit une reprsentation dune entit atomique relle ou virtuelle, dans le but de le
piloter ou de le simuler. Il encapsule une partie des connaissances du monde dans lequel il volue.
Un objet associe donnes et traitements en ne laissant visible que linterface de lobjet (les
traitements que lon peut faire dessus).
Objet = Identit + Etat + Comportement
- Lidentit : permet de distinguer l'objet de manire non ambigu indpendamment de son
Etat (non explicite);
- Ltat : dfini par les valeurs instantanes de tous les attributs dun objet. Il volue au
cours du temps;
- Le comportement : regroupe toutes les comptences (services) dun objet et dcrit les
actions et les ractions de cet objet. Chaque comportement lmentaire d'un objet est
appel opration et est dclench suite une stimulation externe (message envoy par un
autre objet).
Les objets dun systme informatique travaillent en collaboration pour raliser les fonctions de
lapplication. Le comportement global de l'application repose sur la communication entre les
objets. Cette communication est ralise par envoi et rception de messages.
4.2 Dmarche d'abstraction
L'abstraction consiste concentrer la rflexion sur un lment d'une reprsentation en ngligeant
tous les autres.
La dmarche d'abstraction procde de l'identification des caractristiques communes un
ensemble d'lments, puis de la description condense de ces caractristiques dans ce qui est
appel classe. La dmarche se dfinit par rapport un point de vue (critres pertinents dans le
domaine considr).
GL .4/ Concepts Objet 2012-2013
28
4 Concepts objet
4.1 L'objet
Un objet dfinit une reprsentation dune entit atomique relle ou virtuelle, dans le but de le
piloter ou de le simuler. Il encapsule une partie des connaissances du monde dans lequel il volue.
Un objet associe donnes et traitements en ne laissant visible que linterface de lobjet (les
traitements que lon peut faire dessus).
Objet = Identit + Etat + Comportement
- Lidentit : permet de distinguer l'objet de manire non ambigu indpendamment de son
Etat (non explicite);
- Ltat : dfini par les valeurs instantanes de tous les attributs dun objet. Il volue au
cours du temps;
- Le comportement : regroupe toutes les comptences (services) dun objet et dcrit les
actions et les ractions de cet objet. Chaque comportement lmentaire d'un objet est
appel opration et est dclench suite une stimulation externe (message envoy par un
autre objet).
Les objets dun systme informatique travaillent en collaboration pour raliser les fonctions de
lapplication. Le comportement global de l'application repose sur la communication entre les
objets. Cette communication est ralise par envoi et rception de messages.
4.2 Dmarche d'abstraction
L'abstraction consiste concentrer la rflexion sur un lment d'une reprsentation en ngligeant
tous les autres.
La dmarche d'abstraction procde de l'identification des caractristiques communes un
ensemble d'lments, puis de la description condense de ces caractristiques dans ce qui est
appel classe. La dmarche se dfinit par rapport un point de vue (critres pertinents dans le
domaine considr).
GL .4/ Concepts Objet 2012-2013
29
4.3 Classe
Une classe dcrit le domaine de dfinition d'un ensemble d'objets; les objets d'une classe sont
construits par instanciation.
4.4 Attributs et Oprations
les attributs correspondent aux proprits de la classe. En phase d'analyse, il est
recommand de ne pas confondre entre objet et attribut :
"Si l'on ne peut demander un lment que sa valeur, il s'agit d'un simple attribut; si plusieurs
questions s'y appliquent, il s'agit plutt d'un objet qui possde lui mme plusieurs attributs
ainsi que des liens avec d'autres objets"
les oprations dcrivent la spcification du comportement des objets de la classe (une
mthode est une implmentation d'une opration ou service). Elles sont identifies aprs
tude des diffrents scnarios dcrivant les fonctionnalits du systme. Cinq types
d'oprations sont distingus :
- Constructeurs,
- Destructeurs,
- Slecteur (opration de consultation qui renvoie l'tat de l'objet),
- Modificateurs, et
- Itrateurs (qui visitent l'tat d'un objet ou une structure de donne qui contient plusieurs
objets.
4.5 Communication entre objets
La communication entre objets est ralise par envoi et rception de messages. Un message
regroupe les flots de contrle et les flots de donnes et peut prendre diffrentes formes : appel de
mthode, vnement discret, interruption, etc.
GL .4/ Concepts Objet 2012-2013
29
4.3 Classe
Une classe dcrit le domaine de dfinition d'un ensemble d'objets; les objets d'une classe sont
construits par instanciation.
4.4 Attributs et Oprations
les attributs correspondent aux proprits de la classe. En phase d'analyse, il est
recommand de ne pas confondre entre objet et attribut :
"Si l'on ne peut demander un lment que sa valeur, il s'agit d'un simple attribut; si plusieurs
questions s'y appliquent, il s'agit plutt d'un objet qui possde lui mme plusieurs attributs
ainsi que des liens avec d'autres objets"
les oprations dcrivent la spcification du comportement des objets de la classe (une
mthode est une implmentation d'une opration ou service). Elles sont identifies aprs
tude des diffrents scnarios dcrivant les fonctionnalits du systme. Cinq types
d'oprations sont distingus :
- Constructeurs,
- Destructeurs,
- Slecteur (opration de consultation qui renvoie l'tat de l'objet),
- Modificateurs, et
- Itrateurs (qui visitent l'tat d'un objet ou une structure de donne qui contient plusieurs
objets.
4.5 Communication entre objets
La communication entre objets est ralise par envoi et rception de messages. Un message
regroupe les flots de contrle et les flots de donnes et peut prendre diffrentes formes : appel de
mthode, vnement discret, interruption, etc.
GL .4/ Concepts Objet 2012-2013
29
4.3 Classe
Une classe dcrit le domaine de dfinition d'un ensemble d'objets; les objets d'une classe sont
construits par instanciation.
4.4 Attributs et Oprations
les attributs correspondent aux proprits de la classe. En phase d'analyse, il est
recommand de ne pas confondre entre objet et attribut :
"Si l'on ne peut demander un lment que sa valeur, il s'agit d'un simple attribut; si plusieurs
questions s'y appliquent, il s'agit plutt d'un objet qui possde lui mme plusieurs attributs
ainsi que des liens avec d'autres objets"
les oprations dcrivent la spcification du comportement des objets de la classe (une
mthode est une implmentation d'une opration ou service). Elles sont identifies aprs
tude des diffrents scnarios dcrivant les fonctionnalits du systme. Cinq types
d'oprations sont distingus :
- Constructeurs,
- Destructeurs,
- Slecteur (opration de consultation qui renvoie l'tat de l'objet),
- Modificateurs, et
- Itrateurs (qui visitent l'tat d'un objet ou une structure de donne qui contient plusieurs
objets.
4.5 Communication entre objets
La communication entre objets est ralise par envoi et rception de messages. Un message
regroupe les flots de contrle et les flots de donnes et peut prendre diffrentes formes : appel de
mthode, vnement discret, interruption, etc.
GL .4/ Concepts Objet 2012-2013
30
4.5 Relations entre classes
Les relations entre classes peuvent prendre diffrentes formes :
1. Association : abstraction des liens qui existent entre objets (connexion smantique
bidirectionnelle).
Dcoration : tudie dans
Rles : Etud, Enseign
Multiplicits : 1, 0..1, M..N, * ou 0..*, 1..*
2. Agrgation : permet d'exprimer des relations de type matre / esclave (ensemble-lment,
tout-partie, compos-composant, etc.).
3. Composition : forme d'agrgation avec couplage plus important. Les composants ne sont pas
partageables et la destruction de l'agrgat entrane la destruction des composants agrgs.
GL .4/ Concepts Objet 2012-2013
30
4.5 Relations entre classes
Les relations entre classes peuvent prendre diffrentes formes :
1. Association : abstraction des liens qui existent entre objets (connexion smantique
bidirectionnelle).
Dcoration : tudie dans
Rles : Etud, Enseign
Multiplicits : 1, 0..1, M..N, * ou 0..*, 1..*
2. Agrgation : permet d'exprimer des relations de type matre / esclave (ensemble-lment,
tout-partie, compos-composant, etc.).
3. Composition : forme d'agrgation avec couplage plus important. Les composants ne sont pas
partageables et la destruction de l'agrgat entrane la destruction des composants agrgs.
GL .4/ Concepts Objet 2012-2013
30
4.5 Relations entre classes
Les relations entre classes peuvent prendre diffrentes formes :
1. Association : abstraction des liens qui existent entre objets (connexion smantique
bidirectionnelle).
Dcoration : tudie dans
Rles : Etud, Enseign
Multiplicits : 1, 0..1, M..N, * ou 0..*, 1..*
2. Agrgation : permet d'exprimer des relations de type matre / esclave (ensemble-lment,
tout-partie, compos-composant, etc.).
3. Composition : forme d'agrgation avec couplage plus important. Les composants ne sont pas
partageables et la destruction de l'agrgat entrane la destruction des composants agrgs.
GL .4/ Concepts Objet 2012-2013
31
4. Hirarchie de classes : c'est une classification des objets au sein d'une arborescence de classes
permettant ainsi de grer la complexit par rutilisation des caractristiques hrites. C'est une
relation non rflexive et non symtrique.
L'hritage peut prendre l'une des deux formes (selon le sens de la lecture ou le besoin d'analyse) ;
gnralisation ou spcialisation.
Gnralisation Spcialisation
La gnralisation est employe une fois que les lments du domaine ont t identifis.
Elle consiste alors factoriser les informations communes entre classes.
La spcialisation permet de capturer les particularits (d'un ensemble d'objets) non
couvertes par les classes dj identifies. Les nouvelles caractristiques sont reprsentes
par une nouvelle classe, sous classe d'une des classes dj existantes.
La dfinition des sous classes doit rpondre un critre de classification pertinent et non
pas sur des valeurs particulires des attributs d'une mme classe.
La gnralisation introduit un couplage statique trs fort et non mutable. Donc, elle n'est
pas adapte pour reprsenter les mtamorphoses.
5. Hritage multiple :
4.6 Dlgation
La dlgation est base sur l'agrgation et consiste une propagation manuelle des proprits.
Une reprsentation quivalente de l'hritage multiple de la figure prcdente peut tre ralise
par dlgation.
GL .4/ Concepts Objet 2012-2013
31
4. Hirarchie de classes : c'est une classification des objets au sein d'une arborescence de classes
permettant ainsi de grer la complexit par rutilisation des caractristiques hrites. C'est une
relation non rflexive et non symtrique.
L'hritage peut prendre l'une des deux formes (selon le sens de la lecture ou le besoin d'analyse) ;
gnralisation ou spcialisation.
Gnralisation Spcialisation
La gnralisation est employe une fois que les lments du domaine ont t identifis.
Elle consiste alors factoriser les informations communes entre classes.
La spcialisation permet de capturer les particularits (d'un ensemble d'objets) non
couvertes par les classes dj identifies. Les nouvelles caractristiques sont reprsentes
par une nouvelle classe, sous classe d'une des classes dj existantes.
La dfinition des sous classes doit rpondre un critre de classification pertinent et non
pas sur des valeurs particulires des attributs d'une mme classe.
La gnralisation introduit un couplage statique trs fort et non mutable. Donc, elle n'est
pas adapte pour reprsenter les mtamorphoses.
5. Hritage multiple :
4.6 Dlgation
La dlgation est base sur l'agrgation et consiste une propagation manuelle des proprits.
Une reprsentation quivalente de l'hritage multiple de la figure prcdente peut tre ralise
par dlgation.
GL .4/ Concepts Objet 2012-2013
31
4. Hirarchie de classes : c'est une classification des objets au sein d'une arborescence de classes
permettant ainsi de grer la complexit par rutilisation des caractristiques hrites. C'est une
relation non rflexive et non symtrique.
L'hritage peut prendre l'une des deux formes (selon le sens de la lecture ou le besoin d'analyse) ;
gnralisation ou spcialisation.
Gnralisation Spcialisation
La gnralisation est employe une fois que les lments du domaine ont t identifis.
Elle consiste alors factoriser les informations communes entre classes.
La spcialisation permet de capturer les particularits (d'un ensemble d'objets) non
couvertes par les classes dj identifies. Les nouvelles caractristiques sont reprsentes
par une nouvelle classe, sous classe d'une des classes dj existantes.
La dfinition des sous classes doit rpondre un critre de classification pertinent et non
pas sur des valeurs particulires des attributs d'une mme classe.
La gnralisation introduit un couplage statique trs fort et non mutable. Donc, elle n'est
pas adapte pour reprsenter les mtamorphoses.
5. Hritage multiple :
4.6 Dlgation
La dlgation est base sur l'agrgation et consiste une propagation manuelle des proprits.
Une reprsentation quivalente de l'hritage multiple de la figure prcdente peut tre ralise
par dlgation.
GL .4/ Concepts Objet 2012-2013
32
4.7 Polymorphisme
Le polymorphisme implique qu'un nom d'objet peut dsigner des instances de classes diffrentes
issues d'une mme arborescence; le polymorphisme d'oprations offre la possibilit de dclencher
des oprations diffrentes en rponse un mme message (dsignation donne au niveau de la
super classe).
GL .4/ Concepts Objet 2012-2013
32
4.7 Polymorphisme
Le polymorphisme implique qu'un nom d'objet peut dsigner des instances de classes diffrentes
issues d'une mme arborescence; le polymorphisme d'oprations offre la possibilit de dclencher
des oprations diffrentes en rponse un mme message (dsignation donne au niveau de la
super classe).
GL .4/ Concepts Objet 2012-2013
32
4.7 Polymorphisme
Le polymorphisme implique qu'un nom d'objet peut dsigner des instances de classes diffrentes
issues d'une mme arborescence; le polymorphisme d'oprations offre la possibilit de dclencher
des oprations diffrentes en rponse un mme message (dsignation donne au niveau de la
super classe).
GL.5 / Vrification de logiciels 2012-2013
33
5.1 Introduction
Malgr le dveloppement des nouvelles technologies de l'information, des dfaillances et des
erreurs srieuses dcoulent toujours des diffrentes phases du dveloppement de logiciels. Ces
erreurs sont dues principalement aux :
- Les personnes qui rdigent les cahiers des charges sont trs rarement les personnes qui
dveloppent les systmes logiciels,
- Le cahier des charges est trs souvent crit en langage naturel; source d'ambigut,
d'imprcision ou d'incohrence,
- La complexit des applications que les machines actuelles permettent de raliser.
Donc, il est crucial de permettre la dtection (vrification) et la correction de ces erreurs
(maintenance curative) bien avant la livraison ou l'exploitation du produit logiciel. Le rle de la
vrification se limite alors la dtection des erreurs susceptibles d'tre prsentes dans le systme.
Elle ne propose, par contre, aucune solution vis--vis aux problmes rencontrs.
La vrification vise principalement s'assurer que le comportement du produit logiciel
(spcification ou excutable) satisfait toutes les proprits exiges dans le systme.
Diffrentes techniques ont t proposes afin d'accomplir cette tche, dont les plus importantes
sont : le test, la dmonstration et le model-checking.
5.2 Test
Le test est le processus manuel ou automatique qui vise vrifier qu'un systme respecte les
proprits exiges par sa spcification ou dtecter des diffrences entres les rsultats attendus
et ceux gnrs par le systme.
Types de tests. Les tests peuvent tre statiques ou dynamiques. Les mthodes de test statique
consistent en l'analyse textuelle du code du logiciel (revue de code ou recherche danomalies) afin
de dtecter des erreurs sans avoir excuter le programme. Les techniques de spcification
utilises dans ce type de test peuvent varier des graphes de contrle, les diagrammes de flots de
donnes, les systmes de transitions, etc.
Pour les techniques de test dynamique, l'excution du programme est ncessaire pour dceler les
diffrentes fautes. La dmarche repose sur la slection et l'excution dun jeu de tests et la
comparaison des rsultats obtenus avec ceux prvus ce qui permet de dcider le succs ou l'chec
du test.
5.2.1 Construction des jeux de tests
Trois diffrentes approches sont distingues pour : structurelle, fonctionnelle et alatoire.
- Approche structurelle (boite blanche), consiste une slection de jeu de tests sur la base
de la structure du code source de limplmentation. Cette slection est souvent fonde sur
GL.5 / Vrification de logiciels 2012-2013
34
la notion de critre de couverture qui dfinit la faon dont les constructions de base du
code sont testes.
- Approche fonctionnelle (boite noire), repose sur la slection du jeu de test partir de la
spcification des fonctionnalits du logiciel. La slection dans ce cas dpend du degr de
formalit de la spcification.
- Approche alatoire, caractrise par une slection au hasard des jeux de test sur le
domaine des entres du programme. Le domaine de dfinition des entres du programme
est dtermin laide des interfaces de la spcification ou du programme. Cette mthode
ne garantit pas une bonne couverture de lensemble des entres du programme. En
particulier, elle peut ne pas prendre en compte certains cas limites ou exceptionnels. Cette
mthode a donc une efficacit trs variable.
5.2.1.1 Approche structurelle (boite blanche)
Ce test consiste analyser la structure interne du programme en dterminant les chemins
minimaux. Afin d'assurer que:
- Toutes les conditions d'arrt de boucle ont t vrifies.
- Toutes les branches d'une instruction conditionnelle ont t testes.
- Les structures de donnes internes ont t testes (pour assurer la validit).
-
Structures de la reprsentation de la bote blanche. La structure de contrle se prsente sous la
forme d'un graphe de flots. On reprsente les instructions comme suit :
Remarque : If A & B & C If A then if B then if C then
Mesure de complexit Cyclomatique. Cette mesure donne le nombre de chemins minimaux. Elle
est donne par la formule suivante qui correspond au nombre de rgions du graphe de flot :
Nbre Arcs Nbre Nuds + 2 = Nombre de cycles
Exemple : Supposons le programme reprsent par l'organigramme suivant:
GL.5 / Vrification de logiciels 2012-2013
35
Donc le nombre de cycles est : Nbre Arcs - Nbre Nuds + 2 = 11 - 10 + 2 = 3
Pour vrifier, on regarde les chemins minimaux (un test par chemin pour tester toutes les
possibilits du programme). Dans lexemple, les trois chemins sont :
1. 1.2.9.10
2. 1.2.3.4.5.8.2.9.10
3. 1.2.3.6.7.8.2.9.10
5.2.1.2 Approche fonctionnelle (boite noire)
On considre seulement la spcification de ce que doit faire le programme, sans tenir compte de
sa structure interne. On peut donc vrifier chaque fonctionnalit dcrite dans la spcification (On
sappuie principalement sur les donnes et les rsultats). Le danger est lexplosion combinatoire
quentrane un grand nombre dentres du programme. Par contre, on peut crire ces tests trs
tt, ds qu'on connat la spcification.
Principe :
1. On considre le programme dans son aspect fonctionnel et non plus structurel.
2. On partitionne le domaine (DE) en classes.
3. On gnre des cas de test aux limites des classes.
Exemple : Soit P un programme. Supposons que les donnes de P soient des nombres de cinq
chiffres. Alors les classes de nombre cinq chiffres s'obtiennent de la manire suivante:
1
2
3
4
5 7
8
6
9
10
GL.5 / Vrification de logiciels 2012-2013
36
1. x < 10 000
2. 10000 x 99 999
3. x 100 000
Les cas de test aux limites de ces classes sont donc 00 000 et 09 999 pour la premire classe, 10
000 et 99 999 pour la deuxime classe et 100 000 pour la troisime.
5.2.2 Types de tests
a) Les test unitaires de programmes ou de modules Dans ce qui prcde nous avons fait
lhypothse du test dun programme isol. Le test dun module ressemble au test dun programme
isol si ce nest que le module ne fonctionne pas seul mais utilise dautres modules et est appel
par dautres modules. Pour tester un module, il faut simuler le comportement des modules
appels (relation 'utilise') et simuler les appels du module.
b) Les tests dintgration Aprs avoir test unitairement les modules il faut tester leur intgration
progressive jusqu obtenir le systme complet.
Test alpha : lapplication est mise dans des conditions relles dutilisation, au sein de lquipe de
dveloppement (simulation de lutilisateur final).
c) Les test de rception Test, gnralement effectu par l'acqureur dans ses locaux aprs
installation d'un systme, avec la participation du fournisseur, pour vrifier que les dispositions
contractuelles sont bien respectes.
Test bta : distribution du produit sur un groupe de clients avant la version dfinitive.
d) Les tests de non rgression A la suite de la modification d'un logiciel (ou d'un de ses
constituants), un test de non rgression a pour but de montrer que les autres parties du logiciel
n'ont pas t affectes par cette modification.
5.2.3 Test de spcification.
Dans le test fonctionnel, l'extraction des squences de test partir des spcifications permet en
particulier de dcouvrir des lacunes et des ambiguts de spcifications dune manire
indpendante de nimporte quelle excution particulire de ces spcifications. Le but immdiat
inclut un appui pour lautomatisation des transformations des spcifications fonctionnelles en une
suite de tests.
Le test de spcification apporte linformation utilise comme entre de test et les rsultats prvus
partir de la spcification du systme sous test. Cette spcification reprsente une description
prcise du comportement du systme, mais qui nintgre pas les dtailles dimplmentation. Les
spcifications de type machines d'tats sont trs utilises pour la reprsentation de la dynamique
du systme en termes dtats et de transitions.
GL.5 / Vrification de logiciels 2012-2013
37
Les spcifications formelles sont trs adaptes pour ce type de test et peuvent servir dans une
procdure de test totalement mcanise (utilisation de model-checkers par exemple). Mais ces
spcifications sont trs complexes et ncessitent une expertise spcialise souvent rare. Les
spcifications semi formelles sont beaucoup plus simples utiliser mais ncessitent une prise en
charge particulire afin de bien prciser leur smantique. La technique de spcification semi
formelle la plus utilise est certainement le langage de modlisation unifi UML. Les diagrammes
tat-transition dUML (appels galement machines d'tats ou statecharts) reprsentent un outil
prouv de modlisation du comportement bas sur les machines dtats finis. Donc, leur
utilisation semble inluctable dans le contexte de gnration de test partir dune spcification
UML. Cependant, leur utilisation ncessite d'abord une tape de formalisation permettant de
prciser leur smantique.
5.3 Vrification formelle
5.3.1 Dmonstration ou preuve de thormes
La dmonstration permet partir d'un systme et d'une proprit (les deux spcifis
formellement par le mme langage), de prouver que le systme vrifie ou non la proprit. Ceci
est ralis en utilisant des rgles de dduction, comme on pourrait le faire pour dmontrer un
thorme mathmatique. Un outil permettant de faire une telle preuve pour chaque systme et
chaque proprit est bien entendu impossible implmenter. Cependant, des assistants la
preuve (comme PVS par exemple) permettent d'accomplir certaines classes de preuve tout en
maintenant l'intervention de l'oprateur humain. L'assistant de preuve fournit alors un certain
nombre de lemmes intermdiaires qui permettront de prouver le thorme et donc d'affirmer que
le modle du systme satisfait la proprit (exprime par la formule du thorme).
Cette technique traite avec des systmes complexes de taille considrable (espace d'tats infinis).
Elle couvre galement un trs grand nombre de proprits. En grande partie, parce qu'elle fait
constamment appel l'oprateur humain pour palier les lacunes de ses stratgies de preuves
automatiques. Cependant, la technique prsente deux principaux inconvnients majeurs qui
possdent la mme cause : l'indcidabilit. Le premier est l'absence de garantie sur le rsultat ; le
thorme que l'on vent dmontrer peut s'avrer indcidable. Le deuxime problme est que
l'assistant de preuve ncessitera toujours l'intervention humaine.
5.3.2 Model-checking
La vrification de modles peut prendre deux formes : partielle appele simulation ou complte
appele Model-checking.
La simulation est une technique de vrification semi-formelle utilise pour vrifier les systmes
matriels ou logiciels pour dtecter les erreurs de comportement assez tt pendant la phase de
conception. Le problme pos par cette technique est qu'elle ne permet pas de couvrir toutes les
possibilits d'excution du systme en cours de vrification. Cette dficience est traite par les
GL.5 / Vrification de logiciels 2012-2013
38
techniques de vrification formelle de modles appeles Model-checking ou exploration de
l'espace d'tats du systme.
La model-checking est une procdure automatique permettant de vrifier qu'un modle d'un
systme donn satisfait ou non une spcification particulire. Cette procdure ne se fait pas par
dductions comme dans le cas des assistants de preuve, mais grce des algorithmes tirant profit
des spcifications utilises pour dcrire le systme et ses proprits.
Le model-checking repose sur la modlisation formelle du systme gnralement par des
machines d'tats finis (automates, structures de kripke, etc.) et la spcification des proprits
vrifier par des formules logiques (logique classique, logique temporelle, etc.). L'algorithme de
vrification combine le modle et la formule pour calculer l'ensemble des tats accessibles qui
vrifient cette formule ; La proprit est vrifie s'il y a au moins chemin qui relie l'tat initial
l'ensemble des tats qui vrifient cette proprit.
Le model-checking est une procdure compltement automatise et rapide, et peut tre utilis
mme pour vrifier des spcifications partielles. Il produit galement des contre-exemples
reprsentant gnralement des erreurs subtiles de conception. Son inconvnient majeur est le
problme d'explosion combinatoire caus par une complexit accrue des systmes dvelopps et
confronte des limites srieuses de ressources matrielles. Ce problme peut tre partiellement
surmont par l'utilisation des techniques du model-checking symbolique (des reprsentations plus
abstraites des lments constituant le systme vrifier). L'implmentation du model-checking
symbolique peut tre ralise par utilisation des BDD (Binary Decision Diagram) par exemple.
A l'heure actuelle, on utilise la preuve assiste conjointement avec le model-checking par le biais
d'abstractions finies du systme ralises de faon automatique afin de rduire la complexit du
systme et de rester dans le cadre d'une thorie dcidable. En pratique, ces techniques formelles,
plutt d'origines acadmiques commencent ce dvelopper dans les entreprises et des outils
bass sur ces techniques ont dj fait leurs preuves sur des exemples industriels concrets. Des
exemples comme PVS, Coq, etc. (s de preuve), Spin, Java Pathfinder, Kronos, Uppaal, etc. (model-
checkers).
Ces mthodes n'ont pas la prtention de pouvoir certifier le comportement exact de n'importe
quel systme. En fait, elles s'appliquent des modles et non pas des systmes rel. Des
modles qui ne permettent pas toujours de reprsenter tout ce qui peut se passer dans la ralit ;
les systmes rel sont influencs par un environnement non contrl, alors que les modles de ces
systmes ne peuvent reflter qu'une partie minime du comportement de cet environnement. Le
test classique vient toujours en complment de ce genre de mthodes : il permet de mettre en
condition relles les systmes, ce que ne permettent pas les model-checkers et pas toujours les
assistants de preuve.
GL.5 / Vrification de logiciels 2012-2013
39
5.4 Techniques de spcification formelle
Principalement, deux classes de techniques de spcification sont considres : techniques
formelles et semi formelles (les spcifications informelles sont omises volontairement). Les
techniques semi formelles offrent des spcifications conviviales concdant des reprsentations
graphiques simples des systmes dvelopper. Cependant, l'utilisation de certains concepts
informels rend la spcification obtenue imprcise ce qui peut tromper les procdures de
vrification.
Les techniques formelles se basent, par contre, sur des fondements mathmatiques et disposent
d'une axiomatique permettant une spcification prcise et donc des oprations de vrification
patentes. Plusieurs techniques de spcification ont t suggres dans la littrature ; certaines se
basent sur la thorie des ensembles (Z, VDM, ...), d'autres sur les logiques temporelles (LTL, CTL,
TCTL ), etc. Plusieurs entre elles ont prouv une efficacit dans le milieu industriel.
GL.A / Processus Unifi 2012/2013
40
A.1 Introduction
Rappel des objectifs des processus.
Un processus dfinit QUI fait QUOI, QUAND et COMMENT pour atteindre un certain objectif. Les
principaux objectifs peuvent tre :
- Construction des modles dun ou plusieurs systmes,
- Organisation et gestion de la totalit du cycle de vie du projet,
- Gestion des risques,
- construction rptitive de produits logiciels de qualit constante.
A.2 Principes du processus unifi
Comme l'exprience l'a dmontr avec l'histoire d'unification des mthodes objet, il est clair qu'il
n'y a pas un seul processus de dveloppement standard et utilisable sur toutes les classes de
systmes et par tous les dveloppeurs de systmes logiciels. Cependant, des caractristiques
communes et essentielles peuvent tre mises en avant.
Un processus d'ingnierie logicielle doit tre :
- Pilot par les cas dutilisation,
- Centr sur larchitecture,
- Itratif et incrmental,
- Guid par les Design Patterns.
Ces caractristiques sont gnriques ; le processus unifi ne peut tre utilis directement et
ncessite une spcialisation qui tient compte des facteurs organisationnels et techniques du
domaine.
1. Pilot par les cas d'utilisation
A partir des cas d'utilisation, il est possible de crer toute une srie de modles UML :
- Les modles d'analyse spcifient les cas d'utilisation,
- Les modles de conception ralisent les cas d'utilisation,
GL.A / Processus Unifi 2012/2013
41
- Les modles de dploiement distribuent les cas d'utilisation,
- Les modles d'implmentation implantent les cas d'utilisation,
- Les modles de tests vrifient les cas d'utilisation.
2. Centr sur l'architecture
Larchitecture regroupe les diffrentes vues du systme qui doit tre construit. Elle doit prvoir la
ralisation de tous les cas dutilisation. Larchitecture et les cas dutilisation voluent de faon
concomitante.
- Recherche de la forme gnrale du systme ds le dbut,
- Approche systmatique pour trouver une bonne architecture qui soit :
o support des cas dutilisation,
o adaptable aux changements,
o pour et avec la rutilisation,
o comprhensible intuitivement.
3. Itratif et incrmental
Dcoupage du projet en 'mini-projets' : des ITERATIONS qui donnent lieu un INCREMENT.
- Chaque itration traite un certain nombre de cas dutilisation en donnant priorit aux
risques majeurs.
- Une itration reprend les livrables dans ltat o les a laiss litration prcdente et les
enrichit progressivement (incrmental).
- Les itrations sont regroupes dans une phase. Chaque phase est ponctue par un repre
qui marquera la dcision que les objectifs (fixs pralablement) ont t remplis.
- Les premires itrations sont des prototypes qui dfinissent le noyau de larchitecture.
Les phases. Le processus unifi comme le montre la figure suivante propose quatre phases sur une
chelle temporelle : Pr-tude (Inception), Elaboration, Construction et Transition.
a. Pr-tude :
- Dlimiter la porte du systme,
- Dfinir les frontires et identifier les interfaces,
- Dvelopper les cas dutilisation,
- Dcrire et esquisser larchitecture candidate,
GL.A / Processus Unifi 2012/2013
42
- Identifier les risques les plus srieux,
- Dmontrer que le systme propos est en mesure de rsoudre les problmes ou de
prendre en charge les objectifs fixs.
Le rsultat Vision : Glossaire, Dtermination des parties prenantes et des utilisateurs,
Dtermination de leurs Besoins fonctionnels et non fonctionnels, Contraintes de conception.
b. Elaboration :
- Spcifier des fondements de larchitecture et crer une architecture de rfrence,
- Identifier les risques qui peuvent bouleverser le plan, le cot et le calendrier,
- Dfinir les niveaux de qualit atteindre,
- Formuler les cas dutilisation pour couvrir environ 80% des besoins fonctionnels et de
planifier la phase de construction,
- Planifier le projet, laborer une offre abordant les questions de calendrier, de personnel et
de budget.
Le rsultat Architecture : Document darchitecture Logicielle, diffrentes vues selon la partie
prenante, une architecture candidate, comportement et conception des composants du systme.
c. Construction :
- Etendre lidentification, la description et la ralisation des cas dutilisation,
- Finaliser lanalyse, la conception, limplmentation et les tests,
- Prserver lintgrit de larchitecture,
- Surveiller les risques critiques et significatifs identifis dans les deux premires phases et
rduire les risques.
Le rsultat Produit. Premires fonctionnalits.
d. Transition :
- Prparer les activits,
- Recommandations au client sur la mise jour de lenvironnement logiciel,
- Elaborer les manuels et la documentation concernant la version du produit,
- Adaptation du logiciel,
- Correction des anomalies lies au bta test,
- Dernires corrections.
Le rsultat Livraison du produit aux utilisateurs.
Les Activits.
1. Modlisation mtier :
- Comprhension de la structure et la dynamique de lorganisation,
- Comprendre les problmes poss dans le contexte de lorganisation,
- Conception dun glossaire.
GL.A / Processus Unifi 2012/2013
43
2. Recueil et expression des besoins :
- Auprs des clients et parties prenantes du projet,
- Ce que le systme doit faire,
- Expression des besoins dans les cas dutilisation,
- Spcifications des cas dutilisation en scnarios,
- Spcifications fonctionnelles et non fonctionnelles,
- Planification et prvision de cot,
- Production de Maquettes de lIHM:
o La production de maquettes peut tre ralise avec nimporte quel outil graphique :
ce sont de simples dessins dcrans et descriptions de contenu de fentres,
prototype dinterface gnr par un outil,
Intressant pour dcrire les interfaces avec des acteurs non humains.
o Pourquoi si tt dans le processus ?
Aide la description et validation des cas dutilisation,
moyen de communication avec le client,
permet lidentification de classes,
3. Analyse et conception :
- Transformation des besoins utilisateurs en modles UML,
- Modle danalyse et modle de conception.
4. Implmentation :
- Dveloppement itratif,
- Dcoupage en couches,
- Composants darchitecture,
- Retouche des modles et des besoins,
5. Test, Dploiement, Configuration et gestion des changements, Gestion du projet et de
l'environnement.
Les Itrations.
Une itration est une squence dactivits selon un plan prtabli et des critres dvaluation,
rsultant en un produit excutable.
GL.A / Processus Unifi 2012/2013
44
4. Guid par les Design patterns
La notion de pattern dsigne une solution gnrique d'un problme rcurrent.
- Les bonnes pratiques et solutions.
- La plupart des patterns visent la rutilisabilit et lextensibilit
- Un moyen de transfrer des comptences.
Nom du Pattern
Problme
(problme rcurrent de conception OO)
Solution (exprime en UML)
Bnfices
Fig. A.1 structure template du pattern.
La figure suivante montre l'exemple du design pattern 'composite' qui est un pattern de structure
(chapitre suivant) permettant d'tablir des structures arborescentes entre des objets et les traiter
uniformment.
Nom du Pattern Composite Pattern
Problme (problme rcurrent de conception OO) Reprsenter des objets complexes
Solution (exprime en UML)
Bnfices
- Construction rcursive de hirarchies
- Considrer de manire homogne les
nuds simples et complexes
Fig. A.2 exemple du pattern composite.
GL.B / Design Patterns 2012-2013
13
B.1 Dfinition des patterns
Le terme pattern a t initialement introduit dans le domaine d'architecture par C. Alexander qui a
dfini 253 patrons de conception architecturaux (64, 77, 79).
Un patron (selon C. Alexander) dcrit la fois un problme qui se produit trs frquemment dans
votre environnement et larchitecture de la solution ce problme de telle faon qu'on puisse
utiliser cette solution plusieurs fois sans avoir ladapter de la mme manire.
Dcrire avec succs des types de solutions rcurrentes des problmes communs dans des
types de situations.
B.2 Classification des patterns
Les patterns utiliss dans l'ingnierie logicielle peuvent tre identifis dans diffrents domaines et
diffrents niveaux :
Patterns Architecturaux. Schmas dorganisation structurelle de logiciels (pipes, filters, )
Design Patterns. Caractristiques cls dune structure de conception commune plusieurs
applications, de porte plus limite que les patterns architecturaux. Selon leurs portes (classe ou
objet), les design patterns peuvent tre rutiliss par hritage (classe) ou par composition (objet).
Anti-patterns. Mauvaise solution ou comment sortir dune mauvaise solution.
Coding patterns. Solution lie un langage particulier.
Analysis Patterns. Schmas d'analyse (vrification) de conception.
Specification Patterns. Schmas de spcification de proprits vrifier par model-checking.
Patterns Organisationnel. Organisation de tout ce qui entoure le dveloppement dun logiciel
(humains)
B.3 Objectifs des design patterns
Les design patterns prsentent de nombreux avantages, dont les plus importants sont :
- Documentation dune exprience prouve de conception,
- Identification et spcification dabstractions de haut niveau,
- Vocabulaire commun et aide la comprhension de principes de conception,
- Moyen de documentation de logiciels,
- Aide la construction de logiciels caractristiques prcises, de logiciels complexes et
htrognes,
- produit logiciel plus simple modifier et moins fragiles.
GL.B / Design Patterns 2012-2013
14
B.4 Classification des design patterns
l'ouvrage des GoF (gang of four : ses quatre auteurs) Design Patterns: Elements of Reusable
Object-Oriented Software, Addison-Wesley Publishing Company, 1994. A dfini la premire
classification de design patterns. Initialement, 23 patterns ont t rpartis dans trois catgories :
Creational patterns : processus de cration d'objet,
Structural patterns, composition et structure statiques des classes et des objets,
Behavioral patterns, interactions dynamiques entre classes e objets.
Creational Patterns
Abstract Factory
Builder
Factory Method
Prototype
Singleton
Structural Patterns
Adapter
Bridge
Composite
Decorator
Faade
Flyweight
Proxy
Behavioral Patterns
Chain of Responsibility
Command
Interpreter
Iterator
Mediator
Memento
Observer
State
Strategy
Template Method
Visitor
Plusieurs autres patterns ont t ensuite proposes par d'autres auteurs.
L'ouvrage 'Data Access Patterns' de Clifton Nock a introduit 4 decoupling patterns, 5
resource patterns, 5 I/O patterns, 7 cache patterns, et 4 concurrency patterns.
Autres langages de patterns incluent telecommunications patterns, pedagogical
patterns, analysis patterns, etc.
GL.B / Design Patterns 2012-2013
46
B.4.1 Design Patterns de cration
1. Abstract Factory : interface pour la cration de familles dobjets sans spcifier les classes
concrtes.
2. Builder : sparation de la construction dobjets complexes de leur reprsentation afin
quun mme processus de construction puisse crer diffrentes reprsentations.
3. Factory Method : dfinition dune interface pour la cration dobjets associs dans une
classe drive.
4. Prototype : spcification des types dobjet crer en utilisant une instance prototype.
5. Singleton : comment assurer lunicit de linstance dune classe.
B.4.2 Design Patterns de structure
6. Adapter : traducteur adaptant linterface dune classe en une autre interface convenant
aux attentes des classes clientes.
7. Bridge : dcouplage de labstraction de limplmentation pour faire varier les deux
indpendamment.
8. Composite : structure pour la construction dagrgations rcursives.
GL.B / Design Patterns 2012-2013
47
9. Decorator : extension dun objet de manire transparente.
10. Faade : unification de plusieurs interfaces de sous-systmes.
11. Flyweight : partage efficace de plusieurs objets.
12. Proxy : approximation dun objet par un autre.
B.4.3 Design Patterns de comportement
13. Chain of Responsibility : dlgation des requtes des responsables de services.
14. Command : encapsulation de requtes par des objets afin de permettre un objet de
traiter plusieurs types de requtes.
15. Interpreter : tant donn un langage, reprsentation de la grammaire le dfinissant pour
linterprter.
16. Iterator : parcours squentiel de collections.
17. Mediator : coordination dinteractions entre des objets associs.
18. Memento : capture et restauration dtats dobjets.
19. Observer : mise jour automatique des dpendants dun objet.
GL.B / Design Patterns 2012-2013
48
20. State : permettre un objet de modifier son comportement lorsque son tat interne
change.
21. Strategy : abstraction pour slectionner un algorithme parmi plusieurs.
22. Template method : dfinition dun squelette dalgorithme dont certaines tapes sont
fournies par une classe drive.
23. Visitor : reprsentation doprations devant tre appliques des lments dune
structure htrogne dobjets.
B.5 Style de description de Patterns
Diffrentes structures templates peuvent tre utilises pour la description des patterns. La
structure que nous prsentons semble satisfaisante :
Pattern name
Recurring problem
Description du problme que traite le pattern
Solution
Approche gnrale du pattern
UML model
Spcification UML de la solution
Use Example(s)
Exemples du pattern dans un langage de programmation