Génie Logiciel

Gnie Logiciel Page 1/54
BTS Gnie Informatique
SUPPORT DE COURS
Gnie Logiciel
Par :
Hamid AL HAIANE
Professeur au Lyce technique Ibn Sina, Knitra, Maroc
Hamid ALHAIANE
Chapitre I
Introduction au Gnie Logiciel

I- Dfinitions :
On appelle Gnie Logiciel : "l'ensemble des activits de conception et de mise en uvre des produits et des procdures tendant rationaliser la production du logiciel et son suivi". [Journal officiel franais du 19 fvrier 1984]. Une dfinition plus pratique pourrait tre la suivante : Procdures, mthodes, langages, ateliers, imposs ou prconiss par les normes adaptes l'environnement d'utilisation afin de favoriser la production et la maintenance de composants logiciels de qualit. [Patrick Jaulent, Gnie Logiciel, les mthodes, Armand Colin, Paris, 1992]. L'appellation gnie logiciel concerne l'ingnierie applique au logiciel informatique. Cette branche de l'informatique s'intresse plus particulirement la manire dont le code source d'un logiciel est spcifi puis produit. Le gnie logiciel touche au cycle de vie des logiciels. Toutes les phases de la cration d'un logiciel informatique y sont enseignes : l'analyse du besoin, l'laboration des spcifications, la conceptualisation du mcanisme interne au logiciel ainsi que des techniques de programmation, le dveloppement, la phase de test et finalement la maintenance. Les projets relatifs l'ingnierie logicielle sont de l'ordre du "Programming in the large", cest--dire que les projets sont gnralement de grande envergure et dpassent souvent les 10000 lignes de code. Ces projets ncessitent une quipe de dveloppement bien structure. La gestion de projet vient en complment naturel du gnie logiciel.
Hamid ALHAIANE
II- Objectif et ncessit :

L'objectif du gnie logiciel est d'optimiser le cot de dveloppement du logiciel. L'importance d'une approche mthodologique s'est montre par la crise de l'industrie du logiciel la fin des annes 70 :

augmentation des cots ; difficults d'volution ; non fiabilit ; non respect des spcifications ; non respect des dlais. Les exemples suivants montre l'ampleur de l'impact des dfaillances dues au manque
de mthodologie de dveloppement :
La sonde Mariner vers Vnus s'est perdue dans l'espace cause d'une erreur de programme FORTRAN ; En 1972, lors d'une exprience mtorologique en France 72 ballons contenant des instruments de mesure furent dtruits cause d'un dfaut dans le logiciel ; En 1981, le premier lancement de la navette spatiale a t retard de deux jours cause d'un problme logiciel. La navette a d'ailleurs t lance sans que l'on ait localis exactement le problme;
Le nouveau systme dinformation des douanes marocaines BADR a rencontr des difficults importantes lors de ces premiers jours de mise en service et a caus dimportantes pertes chiffres en plusieurs millions de Dirham. Une enqute effectue aux USA en 1986 auprs de 55 entreprises rvle que 53% du
budget total d'un logiciel est affect la maintenance. Ce cot est rparti comme suit :

34% maintenance volutive : modification des spcifications initiales ; 10% maintenance adaptative : nouvel environnement, nouveaux utilisateurs ; 17% maintenance corrective : correction des bogues ; 16% maintenance perfective : amliorer les performance sans changer les spcifications ; 6% assistance aux utilisateurs ;
Hamid ALHAIANE
6% contrle qualit ; 7% organisation/suivi ; 4% divers. Pour apporter une rponse tous ces problmes, le gnie logiciel tente de dvelopper
des comptences et des habilets qui visent : la conception et le dveloppement de nouveaux logiciels selon les principes propres l'ingnierie l'analyse des problmes en vue de la programmation d'une solution logicielle conomique l'tablissement des objectifs quantitatifs sur le plan de la scurit, de l'utilisation, de l'impact sur la productivit, de la maintenance, de la fiabilit ainsi que de l'adaptation et de la viabilit d'un projet logiciel d'un point de vue conomique la mise en uvre de solutions par des logiciels bien structurs la vrification des logiciels dans le respect des objectifs initiaux la gestion et la coordination efficace des projets logiciels et de l'quipe de dveloppement l'valuation du processus de dveloppement et de son niveau de maturit
Hamid ALHAIANE
Chapitre II
Les Logiciels
I- Dfinition :
``Un logiciel est l'ensemble des programmes, procds et rgles, et ventuellement de la documentation, relatifs au fonctionnement d'un ensemble de traitement de l'information''. [Arrt du 22 dc. 1981] De faon plus gnrale, un logiciel est un ensemble de programmes informatiques (du code) mais galement un certain nombre de documents se rapportant ces programmes et ncessaires leur installation, utilisation, dveloppement et maintenance: spcifications, schmas conceptuels, jeux de tests, mode d'emploi, ...
II- Attributs dun logiciel :

Comme dans dautres disciplines (gnie lectrique, gnie civil, mdecine, etc.), lapplication de la thorie de mesure en gnie logiciel a t lobjet de plusieurs travaux de recherche durant les trois dernires dcades. Ces travaux de recherches consistaient dvelopper des mesures pour lvaluation, le contrle et la prdiction des attributs les plus pertinents dun logiciel tels que leffort de dveloppement, la fiabilit logicielle et la productivit du personnel. Ces attributs peuvent tre classs en quatre types :
1- Attributs du produit :
LOC (Line Of Code) : Longueur dun programme. RELY (Software Reliability) :
Hamid ALHAIANE
Ce facteur exprime le degr de fiabilit du logiciel. Il traduit les consquences dune ventuelle dfaillance. DATA (Data Base Size) : Ce facteur exprime leffet de la taille de la base de donnes sur le cot de dveloppement du logiciel. Ainsi, plus la taille de la base de donnes est grande plus elle influence positivement le cot du logiciel. DATA est mesur par le ratio D/P o D est la taille de la base de donnes et P est la taille du code source du logiciel mesure en ISL (nombre de lignes sources).
2- Attributs de lordinateur :
TIME et STOR (Execution Time Constraint, Main Storage Constraint) Le facteur TIME (STOR) exprime leffet des ressources temporelles (spatiales) exiges par le logiciel sur le cot de dveloppement. Ainsi, plus ces ressources sont considrables, plus elles influencent positivement le cot de dveloppement du logiciel. TIME (STOR) est mesur en termes de pourcentage dutilisation des ressources temporelles (spatiales) disponibles. TURN (Computer Turnaround Time): Le facteur TURN exprime leffet du temps de rponse du systme sous lequel on dveloppe le logiciel, en rapport avec le cot de dveloppement du logiciel. Ainsi, plus le temps de rponse est lev, plus le cot de dveloppement augmente. TURN est mesur par le nombre dheures dattente pour avoir la rponse du systme. VIRT (Virtual Machine Volatility): Le facteur VIRT exprime leffet de la volatilit de la machine virtuelle sur le cot de dveloppement du logiciel. Le cot de dveloppement augmente si la machine virtuelle est trs volatile.
3- Attributs du personnel :
ACAP et PCAP (Analyst Capability, Programmer Capability) Le facteur ACAP (PCAP) exprime leffet de la comptence des analystes (programmeurs) sur le cot de dveloppement du logiciel. Ainsi, plus
Hamid ALHAIANE
cette comptence est faible, plus le cot de dveloppement augmente. ACAP (PCAP) est mesur par lordre de classement des analystes (programmeurs). AEXP (Application Experience) Le facteur AEXP exprime leffet de lexprience du personnel impliqu dans dveloppement, sur le cot du logiciel. Ainsi, plus cette exprience est leve, plus le cot de dveloppement est faible. Le facteur AEXP est mesur par le nombre dannes dexprience. VEXP et LEXP (Virtual Machine Experience, Programming Language Experience) Le facteur VEXP (LEXP) exprime leffet de lexprience du personnel dans lutilisation de la machine virtuelle (langage de programmation) sur le cot de dveloppement du logiciel. Ainsi, plus cette exprience est leve, plus le cot de dveloppement diminue. VEXP (LEXP) est mesur par le nombre dannes dexprience.
4- Attributs du projet:
SCED (Required Development Schedule) Le facteur SCED exprime leffet des contraintes de rduction ou dallongement du temps de dveloppement initialement prvu, sur le cot de dveloppement du logiciel. Il gnre une augmentation du cot dans les deux cas: rduction ou allongement du temps. SCED est mesur par le pourcentage de rduction ou dallongement du temps de dveloppement initial. MODP (Modern Programming Practices) Le facteur MODP exprime leffet de la Pratique des mthodes de programmation sur le cot de dveloppement du logiciel. TOOL (Use of Software Tools) Le facteur TOOL exprime leffet de lutilisation doutils logiciels sur le cot de dveloppement du logiciel.
III- Types de logiciels :
Hamid ALHAIANE
Un logiciel ou une application est un ensemble de programmes, qui permet un ordinateur ou un systme informatique d'assurer une tche ou une fonction en particulier. Un essai de classification des logiciels peut se prsenter de la manire suivante :
Types de logiciels
Logiciels de base
Logiciels dapplication
Utilitaires
Langages
L. Professionnel
Jeux
Didacticiels
Moniteur
S. Expl.
JAVA
Tetris
Math.
Windows
Linux
T. Texte
T. Image
SGBD
Word
Photoshop
ACESS
Adibou.
Fig.1 : Types de logiciels
VI- Qualit dun logiciel :

La qualit est dfinie de manire gnrale par : laptitude dun produit ou dun service satisfaire les besoins des utilisateurs . En gnie logiciel divers travaux ont men la dfinition de la qualit du logiciel en termes de facteurs, qui dpendent, entre autres, du domaine de l'application et des outils utiliss. Les facteurs peuvent tre classs en internes (visibles par les dveloppeurs) et externes (visibles par les utilisateurs). Parmi ces derniers nous retiendrons : La validit :
Aptitude dun logiciel raliser exactement les tches dfinies par sa spcification.
Hamid ALHAIANE
La fiabilit : La robustesse : Lextensibilit : La rutilisabilit : La compatibilit : Lefficacit :
Aptitude dun logiciel assurer de manire continue le service attendu. Aptitude dun logiciel fonctionner mme dans des conditions anormales. Facilit d'adaptation d'un logiciel aux changements de spcifications. Aptitude dun logiciel tre rutilis en tout ou partie. Aptitude des logiciels pouvoir tre combins les uns aux autres. Aptitude dun logiciel bien utiliser les ressources matrielles (Mmoire, puissance de lU.C., etc.). La portabilit : La traabilit : La vrifiabilit : Lintgrit : Facilit tre port sur de nouveaux environnements matriels et/ou logiciels. Capacit identifier et/ou suivre un lment du cahier des charges li un composant. Facilit de prparation des procdures de recette et de certification. Aptitude dun logiciel protger ses composants contre des accs ou des modifications non autoriss ; La facilit d'utilisation, dentretien, etc.
Hamid ALHAIANE
Chapitre III
Les projets Logiciels

I- Notion de projet :
On appelle projet un ensemble finalis d'activits et d'actions entreprises dans le but de rpondre un besoin dfini dans des dlais fixs et dans la limite de l'enveloppe budgtaire alloue. Un projet est une action temporaire avec un dbut et une fin, qui mobilise des ressources identifies (humaines, matrielles (quipements), matires premires, informationnelles et financires) durant sa ralisation, qui possde un cot et fait donc l'objet d'une budgtisation de moyens et d'un bilan indpendant de celui de l'entreprise.
II- Gestion de projet logiciel:

La gestion de projet ou conduite de projet est une dmarche visant structurer, assurer et optimiser le bon droulement d'un projet logiciel suffisamment complexe pour devoir :

tre planifie dans le temps : c'est l'objet de la planification tre budgtise (tude pralable des cots et avantages ou revenus attendus en contrepartie, des sources de financement, tude des risques oprationnels et financiers et des impacts divers...)
matriser et piloter les risques atteindre le niveau de qualit souhait faire intervenir de nombreuses parties prenantes : Clients, Concepteurs, Financiers, Utilisateurs, ) suivre des enjeux oprationnels et financiers importants
Hamid ALHAIANE
L'objectif doit tre prcis de faon claire, chiffre et date. Le rsultat doit tre conforme des normes de qualit et de performances prdfinies, pour le moindre cot et dans le meilleur dlai possible. La gestion du projet logiciel a donc pour but de mener le projet son terme, en tenant compte des contraintes qui lient chacun des aspects du triangle projet.
Gestion des productions
Objectifs
Moyens
Gestion des ressources
Dlais
Gestion des dlais
Fig.2 : Types de gestions
III- Types de gestion: 3-1 Gestion des dlais :

Elle consiste dterminer un parcours que l'on va suivre, un calendrier de ralisation et une matrise d'enveloppe temps.
3-2 Gestion des ressources :

La gestion des ressources (resource management) comprend l'identification, l'estimation, l'allocation et la surveillance de ressources utilises pour dvelopper un produit ou fournir un service. Les moyens constituent le budget du projet, il s'agit donc de transformer le budget en travail, locaux, matriels, dplacements dans ce but.
Hamid ALHAIANE
3-3 Gestion des productions :

La gestion des productions (product management) comprend la dfinition, la coordination et le suivi des caractristiques d'un produit pendant son dveloppement. Lobjectif d'un projet doit son terme tre concrtise par une ou plusieurs fournitures. Il faut s'assurer que ce qui est produit se rapproche du but final.
VI- Complexit des projets logiciels:

La complexit des projets logiciels peut tre de trois types :
S : Projet simple ou Organique (organic) (LOC < 50 000 lignes) Ce sont des applications relativement simples, n'ayant que peu de cas particuliers et de contraintes. Elles sont parfaitement dterministes.
P : Projet moyen ou semi-dtach (semidetached) (50 000 LOC 300 000)
Ce sont des applications intermdiaires, plus complexes que les applications de type S, elles restent tout de mme dterministes, bien que le nombre de cas particuliers et de tests doivent tre plus important que pour les applications de type S.
E : Projet complexe ou imbriqu (embedded) (LOC 300 000 lignes) Ce sont des applications trs complexes, que se soit au niveau de leurs contraintes (comme un systme temps rel) ou au niveau des donnes saisies (comme certaines interfaces graphiques o l'on ne peut envisager toutes les possibilits de saisies qu'un utilisateur pourrait effectuer). Elles ne sont pas dterministes.
. V- Estimation de charge :
5-1 Dfinitions :
Hamid ALHAIANE
Charge : Dsigne la quantit de travail ncessaire pour dvelopper un logiciel. Elle est mesure en jour / homme, mois / homme, anne / homme (charge sur un mois: en gnral 20 jours.) TDEV : Dsigne le temps ncessaire au dveloppement dun logiciel. Egalement
appel dlai, Il dpend de la charge et du nombre de personnes affectes au projet et se mesure en (Jour, Moi, Anne) Taille du projet : la taille du projet se mesure sa charge. Daprs ISO une classification des projets selon leurs charges se prsente de la manire suivante : Trs petit projet Petit projet Projet moyen Grand projet Trs grand projet Exemple: : Charge < 6 M/h : 6 M/h charge 12 M/h : 12 M/h charge 30 M/h : 30 M/h charge 100 M/h : 100 M/h charge
60 M/h peut tre 1 personne pendant 5 ans ou 10 personnes pendant 6 mois ou 60 personnes pendant 1 mois.
5-2 Les mthodes destimation de charge : 5-2-1 La mthode DELPHI :

Cette mthode est base sur l'exprience des experts du domaine. Principe: 1. Chaque expert propose une estimation base sur son exprience. 2. On publie le rsultat (anonyme). 3. Les experts sont invits modifier ou maintenir leurs estimations.
Hamid ALHAIANE
4. On publie les rsultats nominaux. 5. Les experts refont la troisime tape. 6. On analyse les disparits, on calcule la moyenne.
5-2-2 La mthode COCOMO (COnstructive COst Model) :

1- Historique : Conue dans les annes 1970 par Barry Boehm, COCOMO (COnstructive COst MOdel) est une mthode base sur les rsultats de 63 projets de dveloppements informatiques (allant de 2 000 100 000 lignes de code). Elle se base donc sur des statistiques. 2- Principe : COCOMO est un modle permettant de dfinir une estimation de l'effort fournir dans un dveloppement logiciel et la dure que ce dernier prendra en fonction des ressources alloues. Cette mthode est divis en trois modles, qui affinent l'estimation en prenant en compte de plus en plus de paramtres : Le modle de base Le modle intermdiaire Le modle dtaill
3- Modle de base : Ce modle effectue un simple calcul de l'effort et de la dure en fonction du nombre de lignes de code que l'application doit contenir et de la complexit de cette dernire. Une ventilation est galement possible, permettant de dterminer le temps de dveloppement et l'effort ncessaire pour chaque partie du cycle de dveloppement.
Type de projet
Charge en M/h
TDEV en M
Hamid ALHAIANE
Organique Semi-dtach Imbriqu
Charge
= TDEV 2,5*(Charge)0,38 TDEV
= = =
2,4*(KLOC)1,05 Charge = 3*(KLOC)1,12 Charge 3,6*(KLOC)1,20
2,5*(Charge)0,35 = TDEV 2,5*(Charge)0,32
Tab. 1 : Modle COCOMO de base Taille moyenne d'quipe = Charge / TDEV 4- Modle intermdiaire : Ce modle effectue le calcul de la charge brute et de la dure en fonction du nombre de lignes de code et procde ensuite par une correction en appliquant cette fois-ci des coefficients prenant en compte des facteurs de cot (RELY, DATA, TIME, VIRT, etc.).
Type de projet
Organique Semi-dtach Imbriqu
Charge en M/h Charge
TDEV en M = TDEV 2,5*(Charge)0,38 TDEV = = =
3,2*(KLOC)1,05 Charge = 3*(KLOC)1,12 Charge 2,8*(KLOC)1,20
2,5*(Charge)0,35 = TDEV 2,5*(Charge)0,32
Tab. 2 : Modle COCOMO intermdiaire Les multiplicateurs associs aux attributs sont prsents sur le tableau suivant :
Evaluation Nominal Haut 1.00 1.00 1.00 1.15 1.08 1.15
Facteurs de productivit Attributs du produit RELY DATA CPLX Attributs de lordinateur
T.Bas 0.75 0.70
Bas 0.88 0.94 0.85
T.Haut 1.40 1.16 1.30
Ext. Haut
1.65
Hamid ALHAIANE
TIME STOR VIRT TURN Attributs du personnel ACAP AEXP PCAP VEXP LEXP Attributs du projet MODP TOOL SCED
0.87 0.87 1.46 1.29 1.42 1.21 1.14 1.24 1.24 1.23 1.19 1.13 1.17 1.10 1.07 1.10 1.10 1.08
1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00
1.11 1.06 1.15 1.07 0.86 0.91 0.86 0.90 0.95 0.91 0.91 1.04
1.30 1.21 1.30 1.15 0.71 0.82 0.70
1.66 1.66
0.82 0.83 1.10
Tab. 3 : Facteurs correcteurs de la charge Charge nette = Produit (facteurs) x Charge brute Taille moyenne d'quipe = Charge / TDEV
5- Modle dtaill : Ce modle reprend les donnes du modle intermdiaire en affinant notamment les facteurs de cot en fonction de chaque phase du cycle de dveloppement.
5-2-3 La mthode de rpartition proportionnelle :

Elle s'appuie sur le dcoupage du projet en diffrentes phases. On commence par faire l'estimation de la charge globale. Ensuite, on dtermine la charge pour chaque phase du cycle de vie.
Tab. 4 : Mthode de rpartition proportionnelle

Hamid ALHAIANE
4-4 Exercices :
1- En appliquant la mthode COCOMO de base, estimer la taille moyenne de lquipe quil faudra prvoir pour dvelopper un logiciel denviron 40 000 lignes de code sources ? 2- Estimer la charge de ce mme projet pour le cas o la fiabilit requise est trs faible et dans le cas o la fiabilit est trs forte ? 3- Sachant que la phase d'observation reprsente environ un tiers de la charge de l'tude pralable, calculer la charge du projet en M/h et sa rpartition dans le cycle de dveloppement. Nous supposons que la charge de la phase d'observation a t estime 7,5 J/h. 4- Commenter les rsultats. Rponses :
Hamid ALHAIANE
Chapitre IV
Principes gnraux en Gnie Logiciel

I- Gnralit :
En gnrale les principes sont la base dune discipline, dun phnomne ou du fonctionnement dun objet. Un deuxime sens donn au terme principe est une proposition premire, pose et non-dduite (Le Robert, Le Grand Robert). Du fait de son jeune age la discipline du gnie logiciel ne dispose toujours pas de principes gnraux reconnus par tous. Sur ce sujet de nombreux essais ont t effectus, nous verrons ici les principes gnraux en GL proposs par Carlo Ghezzi : Rigueur;
Hamid ALHAIANE
Sparation des problmes ; Modularit ; Abstraction ; Anticipation du changement ; Gnricit ; Construction incrmentale ;
II- Principes gnraux en Gnie Logiciel :

1- Rigueur
La production de logiciel est une activit crative, mais qui doit se conduire avec une certaine rigueur. Certains opposent parfois crativit et rigueur, mais il ny a pas contradiction : par exemple, le rsultat d'une activit de cration pure peut tre valu rigoureusement, avec des critres prcis. Le niveau maximum de rigueur est la formalit, cest dire le cas o les descriptions et les validations sappuient sur des notations et des lois mathmatiques. Il nest pas possible dtre formel tout le temps : il faut bien construire la premire description formelle partir de connaissances non formalises.
2- Sparation des problmes

Cest une rgle de bons sens qui consiste considrer sparment diffrents aspects dun problme afin den matriser la complexit. Cest un aspect de la stratgie gnrale du prendre une multitude de formes : diviser pour rgner . Elle peut
Hamid ALHAIANE
Sparation dans le temps (les diffrents aspects sont abords successivement), avec la notion de cycle de vie du logiciel que nous tudierons en dtail, Sparation des qualits que lon cherche optimiser un stade donn (ex : assurer la correction avant de se proccuper de lefficacit), Sparations des vues que lon peut avoir dun systme (ex : se concentrer sur laspect flots de donnes avant de considrer laspect ordonnancement des oprations ou flot de contrle), Sparation du systme en parties (un noyau, des extensions, ), Etc. Les mthodes aident organiser le travail en guidant dans la
sparation et lordonnancement des questions traiter.
3- Modularit
Un systme est modulaire sil est compos de sous-systmes plus simples, ou modules. La modularit est une proprit importante de tous les procds et produits industriels (cf. lindustrie automobile ou le produit et le procd sont trs structurs et modulaires). La modularit permet de considrer sparment le contenu du module et les relations entre modules (ce qui rejoint lide de sparation des questions). Elle facilite galement la rutilisation de composants bien dlimits. Un bon dcoupage modulaire se caractrise par une forte cohsion interne des modules (ex : fonctionnelle, temporelle, logique, ...) et un faible couplage entre les modules (relations inter modulaires en nombre limit et clairement dcrites).
Hamid ALHAIANE
Fig.3 : La modularit Toute lvolution des langages de programmation vise rendre plus facile une programmation modulaire, appele aujourdhui programmation par composants.
4- Abstraction
Labstraction consiste ne considrer que les aspects jugs importants dun systme un moment donn, en faisant abstraction des autres aspects (cest encore un exemple de sparation des problmes). Une mme ralit peut souvent tre dcrite diffrents niveaux dabstraction. Par exemple, un circuit lectronique peut tre dcrit par un modle mathmatique trs abstrait (quation logique), ou par un assemblage de composants logiques qui font abstraction des dtails de ralisation (circuit logique), ou par un plan physique de composants rels au sein d'un circuit intgr. Labstraction permet une meilleure matrise de la complexit.
5- Anticipation du changement
La caractristique essentielle du logiciel, par rapport dautres produits, est quil est presque toujours soumis des changements continuels (corrections d'imperfections et volutions en fonctions des besoins qui changent). Ceci requiert des efforts particuliers pour prvoir, faciliter et grer ces volutions invitables. Il faut par exemple : faire en sorte que les changements soient les plus localiss possibles (bonne modularit), tre capable de grer les multiples versions des modules et configurations des versions des modules, constituant des versions du produit complet.
Hamid ALHAIANE
6- Gnricit
Il est parfois avantageux de remplacer la rsolution dun problme spcifique par la rsolution dun problme plus gnral. Cette solution gnrique (paramtrable ou adaptable) pourra tre rutilise plus facilement. Exemple : plutt que dcrire une identification spcifique un cran particulier, crire (ou rutiliser) un module gnrique dauthentification (saisie dune identification ventuellement dans une liste - et ventuellement dun mot de passe).
7- Construction incrmentale
Un procd incrmental atteint son but par tapes en sen approchant de plus en plus ; chaque rsultat est construit en tendant le prcdent. On peut par exemple raliser dabord un noyau des fonctions essentielles et ajouter progressivement les aspects plus secondaires. Ou encore, construire une srie de prototypes simulant plus ou moins compltement le systme envisag.
III. Conclusion
Ces principes sont trs abstraits et ne sont pas utilisables directement. Mais ils font partie du vocabulaire de base du gnie logiciel. Ces principes ont un impact rel sur beaucoup daspects (on le verra dans la suite du cours) et constituent le type de connaissance le plus stable, dans un domaine o les outils, les mthodes et les techniques voluent trs vite.
Hamid ALHAIANE
Chapitre V
Cycle de vie dun logiciel

I- Notion de cycle de vie dun logiciel :
Hamid ALHAIANE
Le cycle de vie d'un logiciel (Software life cycle), dsigne toutes les tapes du dveloppement d'un logiciel, de sa conception son limination. L'objectif d'un tel dcoupage est de dfinir des jalons intermdiaires permettant la validation du logiciel ( Conformit du logiciel avec les besoins exprims), et la vrification du processus de dveloppement (Adquation des mthodes mises en uvre). L'origine de ce dcoupage provient du constat que les erreurs ont un cot d'autant plus lev qu'elles sont dtectes tardivement dans le processus de ralisation. Un tel dcoupage permet donc de dtecter en amont les erreurs et de matriser ainsi la qualit du logiciel, les dlais de sa ralisation et les cots associs. Le cycle de vie dun logiciel comprend gnralement les phases suivantes : Etude prliminaire ou tude de faisabilit, Analyse des besoins et Analyse du systme, Conception gnrale ; Conception dtaille ; Codage ou programmation, Tests unitaires ; Intgration, Test dintgration ; Test de validation, recette; Installation, maintenance.
II- Les diffrentes phases du cycle de vie dun logiciel :

1- Etude prliminaire ou tude de faisabilit : Dfinition globale du problme, Diffrentes stratgies possibles avec avantages et inconvnients, Estimation des ressources, cots et dlais.
Livrables : Rapport danalyse prliminaire ou schma directeur. 2- Analyse des besoins ou spcification gnrales : Qualits fonctionnelles attendues en termes de services offerts, Qualits non fonctionnelles attendues : efficacit, sret, scurit, facilit... Qualits attendues du procd de dveloppement
Livrables : Cahier des charges + Plan qualit
Hamid ALHAIANE
3- Analyse du systme : Modlisation du domaine, Modlisation de lexistant (ventuellement), Dfinition dun modle conceptuel (ou spcification conceptuelle),
Livrables : Dossier danalyse + Plan de validation 4- Conception gnrale: Proposition de solution au problme spcifi dans lanalyse Architecture du logiciel ( modules et interface des modules )
Livrables : Dossier de conception + Plan de test global 5- Conception dtaille : Description dtaille des modules avec les algorithmes essentiels Structuration des donnes.
Livrables : Dossier de conception dtaille + Plan de test par module 6- Programmation et tests unitaires : Implmentation dans un langage de programmation, Tests avec les jeux dessais par module selon le plan de test.
Livrables : Dossiers de programmation et codes sources 7- Intgration et tests de qualification : Composition progressive des modules, Tests des regroupements de modules, Test en vraie grandeur du systme complet selon le plan de test global
8- Installation : Mise en fonctionnement oprationnel chez les utilisateurs. Parfois restreint dans un premier temps des utilisateurs slectionns (Beta testing).
9- Maintenance : Maintenance corrective (ou curative), Maintenance adaptative, Maintenance perfective.
III- Modles de cycle de vie dun logiciel :

Hamid ALHAIANE
Dans le but d tablir une mthodologie commune entre le client et la socit de service ralisant le dveloppement, des modles de cycle de vie ont t mis au point dfinissant les tapes du dveloppement ainsi que les documents produire permettant de valider chacune des tapes avant de passer la suivante.
1- Modle en cascade (Water fall) :

Mis au point la fin des annes 60s, ce modle est issu de la construction de btiment. En effet, on doit dabord construire les fondations avant de construire la maison. Ce principe est aussi appliqu au dveloppement des logiciels. Ce modle dfinit les phases traditionnelles de dveloppement effectues de manire squentielles l'issue desquelles des livrables sont produits pour en vrifier la conformit avant de passer l'tape suivante.
Etude prliminaire
Analyse des besoins Validation Conception gnrale
Conception dtaille
Codage
Test unitaires
Test dintgration
Test dacceptation
Installation Hamid ALHAIANE Maintenance
Fig.4: Modle en cascade
2- Modle en V :
Le cycle de vie en V est une amlioration du cycle en cascade. Il est devenu un standard dans les annes '80s. Son but est de limiter un retour aux tapes prcdentes. Pour ce faire, avec toute dcomposition doit tre temps la recomposition, et que toute description dcrite d'un composant est accompagne de tests qui permettront de s'assurer qu'il correspond sa
Etude description. prliminaire Maintenance
Les premires phases permettent de dcomposer l'ensemble du projet pour simplifier Validation la phase de programmation (Top-Down). Les phases suivantes recomposent l'ensemble du logiciel en le testant du dtail vers l'ensemble (Bottom-Up).
Conception gnrale Test dintgration Analyse des besoins Test dacceptation
Conception dtaille Hamid ALHAIANE Codage
Test unitaires
Fig.5: Modle en V
3- Modle Incrmentale :
Dans ce modle, un seul composant est dvelopp la fois. On dbute par dfinir les exigences et on les dcompose en sous-systme. chaque version du logiciel, de nouvelles fonctionnalits venant combler les exigences sont ajoutes. On continue de la sorte jusqu' ce que toutes les fonctionnalits demandes soient combles par le systme. Chaque incrment peut utiliser un autre modle (V, en cascade...).
Hamid ALHAIANE
Fig.6: Modle incrmental
2- Modle en Spirale:
Ce modle est plus rcent, il date du milieu des annes 80. L'emphase de ce modle est mise sur la rduction des risques. Ce modle est adapt pour les gros projets complexes. Les risques sont sans cesse valus chaque cycle. Un cycle est dcompos en tapes.

Analyse prliminaire pour le premier cycle, pour les autre cycles on dtermine les objectifs, contraintes partir du rsultat du cycle antrieur. Analyse des risques, cration de prototype Dveloppement et test Planification du cycle suivant
Fig.7: Modle en spirale
Hamid ALHAIANE
La mise en oeuvre de ce modle demande des comptences managriales et devrait tre limite aux projets innovants cause de l'importance quil accorde l'analyse des risques. Citons, par exemple : Risques humains: Dfaillance du personnel ; surestimation des comptences Travailleur solitaire, manque de motivation Risques processus Pas de gestion de projet Calendrier et budget irralistes ; Calendrier abandonn sous la pression des clients Composants externes manquants ; Tches externes dfaillantes ; Insuffisance de donnes Validit des besoins ; Dveloppement de fonctions inappropries Dveloppement d'interfaces utilisateurs inappropries Risques technologiques Changement de technologie en cours de route Problmes de performance Exigences dmesures par rapport la technologie Incomprhension des fondements de la technologie
Chapitre VI
Modlisation et Analyse Structure
Hamid ALHAIANE
1- La mthode dAnalyse Structure SADT: 1-1 Introduction :

La mthode SADT (Structured Analysis and Design Technique) est une mthode d'analyse particulirement bien adapte la phase de spcification fonctionnelle d'un systme. Conue au dbut des annes 70 par Doug Ross. La dmarche conduit la ralisation de plusieurs modles de la ralit : modle du systme d'information existant, modle du systme idal, modle du systme ralisable et enfin modle du systme raliser.
1-2 Principe :
Hamid ALHAIANE
SADT utilise une approche de dcomposition descendante (top-down), modulaire et hirarchique. La premire description est la description la plus gnrale possible. Elle est reprsente comme un module ou une bote, clat en un nombre n de sous-modules ou sousbotes. Chaque sous-module peut lui-mme tre clat en n sous-modules et ainsi de suite. Par commodit n doit tre compris entre 3 et 6. Le monde est considr comme un ensemble d'objets (donnes) et d'actions (activits) qui doivent tre analyss et dcomposs en parallle. Graphiquement, donnes et activits sont reprsentes dans des Diagrammes d'activits ou Actigrammes et des Diagrammes de donnes ou Datagrammes (figure 8).
Donnes de Contrle Donnes dentre Donnes de sortie Activits gnratrices Activits de Contrle Activits utilisatrices
......
ACTIVITE
Mcanisme ou support dactivit
DONNEE
Mcanisme ou support de la donne
a - Actigramme
b - Datagramme
Fig.8: Actigramme et Datagramme
1-3 Organisation hirarchique des diagrammes :

Les diagrammes sont organiss de faon hirarchique (figure 9). L'actigramme correspondant au systme global est l'actigramme A-0. La premire dcomposition correspond l'actigramme A0. Les actigrammes du niveau suivant sont numrots A1,A2,A3, ..., An et les actigrammes de niveau infrieur A31,A32,..,A3n.
Hamid ALHAIANE
Fig.9: Organisation hirarchique des actigrammes
1-4 Exemple :
La figure 10 montre l'actigramme principal A-0 d'une consultation mdicale. Les
patients en attente sont examins en fonction des horaires de consultation. L'examen dpend des protocoles mdicaux suivis. L'actigramme A-0 peut tre dcompos selon les trois actigrammes de la figure 11.
Protocole dexamen Appel des patients Horaires de consultation
Consulter
Patients en attente
Patients examins
Hamid ALHAIANE
Fig.10: Actgramme A-0 dune consultation mdicale
C2 Horaires de consultation Fin de consultation Appel des patients Rendez-vous des patients C1
Prendre des rendez-vous 1

Rendez-vous
Patient suivant
C3
Protocole dexamen
E1
Chercher le patient suivant 2

Rendez-vous
Patients en attente
Examiner le patient 3
S1
Patients examins
Fig.11: Dcomposition de lactivit de consultation en trois actigrammes
2- La mthode dAnalyse Structure SASS: 2-1 Introduction :

La mthode SASS (Structured Analysis and System Specification ) est une mthode d'analyse structure dveloppe par Tom de Marco au milieu des annes 70 [DeMarco 1978 ]. Comme SADT, la mthode SASS utilise une approche de dcomposition descendante partant du plus gnral pour arriver au plus particulier. La mthode SASS est compose des lments suivants : Diagramme de Contexte de Donnes (DCD) Diagrammes de Flots de Donnes (DFD)
Hamid ALHAIANE
Dictionnaire de Donnes (DD) Spcification de Processus (PSPEC)
2-2 Diagramme de contexte de donnes DCD :

Objectif : Exposer le but principal du systme et identifier les entits extrieures avec lesquelles il doit communiquer Composants : Processus unique Terminaisons Donnes dentre/ sortie du systme
Reprsentation :
Entre 2 Entit extrieure 1 Entit extrieure 2
2-3 Diagramme de flots de donnes DFD :

Objectif :
Fig.12: Diagramme Processus de donnes de contexte Sortie 1 Entre 1 unique
Hamid ALHAIANE
Dcomposer le processus unique en sous-processus et les flots dentre/ sortie en sous-flots afin de dtailler le fonctionnement du systme Composants : Processus Flots de donnes Stockages des donnes
Reprsentation : Entre 2 Processus 2 Sortie 1 Processus 3 Stockage 1
Processus 1 Entre 1 Fig.13: Diagramme de flots de donnes
2-4 Dictionnaire de donnes DD:

Objectif : Regrouper la smantique et la structure des donnes prsente dans le systme. Exemple : Adresse postale : nom + Rue + Ville + Code postal Fonction : {tudiant, Professeur, Administrateur}
2-5 Spcification de processus PSPEC :

Hamid ALHAIANE
Objectif : Raffiner les explications de chaque processus en faisant apparatre les traitements lmentaires. Outils de spcification : Les algorithmes abstraits Les arbres de dcision Les tables de dcision Les diagrammes de Michal JACKSON Les diagrammes de Nassi SHEIDERMAN (ou structurogrammes)
2-6 Exemple dapplication : Distributeur automatique de boisson

1 - Diagramme de contexte de donnes DCD:
Produit Fausse pice Client Fig.14: DCD du systme : distributeur automatique de Client boissons 2 Dictionnaire partiel de donnes DD : vendre Objet des produits Objet : [pice | Fausse pice]
Pices rendues
Slection client Pices : { Pice de 1DH | Pice de 2DH | Pice de 5DH | Pice de 10DH}
Hamid ALHAIANE
Pice de 2DH : Pice de monnaie officielle marocaine, D =24 mm, m= 8g Slection client : [Soda | Eau minrale | Jus de fruit | yaourt}
3 - Diagramme de flot de donnes DFD niveau 1:
Pices Objet
Obtenir le Paiement
Pices rendues
Rendre la Monnaie
Paiement
Valider le paiement
2 Monnaie rendre Produit
Fausse pice
3 Table des prix Slection valide

Obtenir le prix du produit Obtenir Une bonne slection Distribuer le produit
5 4 Fig.15: DFD0 : Vendre des produits Slection client
Produits Paramtres pices 4 - Diagramme de flot de donnes DFD niveau 2: Objet

Valider les pices Initialiser le paiement
1-1 Fausse pice Pices

Amasser les pices
Valeur de la pice
Totaliser le paiement
1-2
1-3
1-4 Pices amasses Paiement
Hamid ALHAIANE
Dposer les pices
Pices
1-5
Fig.16: DFD1: Obtenir le paiement 5 Spcification de processus PSPEC niveau 2: PSPEC 1.1 : Valider les pices Examiner les OBJETS pour vrifier s'ils sont conformes aux PARAMETRES PIECES Si oui: Autrement: Accepter OBJETS comme PIECES Retourner OBJETS comme FAUSSES PIECES
PSPEC 1.2 : Initialiser paiement Rsultat : PAIEMENT= 0
Chapitre VII
Modlisation Oriente Objet

Hamid ALHAIANE
I- Historique :
Les mthodes de modlisation utilises dans les annes 1980 (notamment Merise) taient fondes sur la modlisation spare des donnes et des traitements. Lorsque la programmation par objets prend de limportance au dbut des annes 1990, la ncessit dune mthode qui lui soit adapte devient vidente. Plus de cinquante mthodes apparaissent entre 1990 et 1995 (Booch, Classe-Relation, Fusion, HOOD, OMT, OOA, OOD, OOM, OOSE, etc.) mais aucune ne parvient simposer. En 1994, le consensus se fait autour de trois mthodes : OMT de James Rumbaugh (General Electric) fournit une reprsentation graphique des aspects statique, dynamique et fonctionnel dun systme ; OOD de Grady Booch, dfinie pour le Department of Defense, introduit le concept de paquetage (package) ; OOSE dIvar Jacobson (Ericsson) fonde lanalyse sur la description des besoins des utilisateurs (cas dutilisation, ou use cases). Chaque mthode avait ses avantages et ses partisans. Le nombre de mthodes en comptition stait rduit, mais le risque dun clatement subsistait : la profession pouvait se diviser entre ces trois mthodes, crant autant de continents intellectuels qui auraient du mal communiquer. Lvnement considrable qui sest produit est que les auteurs de ces trois mthodes se sont mis daccord pour dfinir une mthode commune qui fdrerait leurs apports respectifs. UML (Unified Modeling Language) est n de cet effort de convergence. et comme son nom lindique, UML na pas lambition dtre exactement une mthode : cest un langage. Lunification a progresse par tapes. En 1995, Booch et Rumbaugh (et quelques autres) se sont mis daccord pour construire une mthode unifie, Unified Method 0.8 ; en 1996, Jacobson les a rejoints pour produire UML 0.9 (notez le remplacement du mot mthode par le mot langage, plus modeste). Les acteurs les plus importants dans le monde du logiciel
Hamid ALHAIANE
sassocient alors leffort (IBM, Microsoft, Oracle, DEC, HP, Rational, Unisys etc.) et UML 1.0 est soumis lOMG 5 . LOMG adopte en novembre 1997 UML 1.1 comme langage de modlisation des systmes dinformation objets. La version dUML en cours la fin 2006 est UML 2.0 et les travaux damlioration se poursuivent.
II- Mise en uvre dUML :

UML nest pas une mthode (i.e. une description normative des tapes de la modlisation) : ses auteurs ont en effet estim quil ntait pas opportun de dfinir une mthode en raison de la diversit des cas particuliers. Ils ont prfr de se limiter dfinir un langage graphique qui permet de reprsenter, de communiquer les divers aspects dun systme dinformation. Il est impossible de donner une reprsentation graphique complte dun logiciel, ou de tout autre systme complexe, de mme quil est impossible de reprsenter entirement une statue ( trois dimensions) par des photographies ( deux dimensions). Mais il est possible de donner sur un tel systme des vues partielles, analogues chacune une photographie dune statue, et dont la juxtaposition donnera une ide utilisable en pratique sans risque derreur grave. UML 2.0 comporte ainsi plusieurs types de diagrammes reprsentant autant de vues distinctes pour reprsenter des concepts particuliers du systme dinformation. Ils se rpartissent en deux grands groupes :
Diagrammes structurels ou diagrammes statiques (UML Structure) Diagramme de classes (Class diagram) Diagramme dobjets (Object diagram) Diagramme de composants (Component diagram) Diagramme de dploiement (Deployment diagram) Diagramme de paquetages (Package diagram)
Hamid ALHAIANE
Diagrammes comportementaux ou diagrammes dynamiques (UML Behavior) Diagramme de cas dutilisation (Use case diagram) Diagramme dactivits (Activity diagram) Diagramme dtats-transitions (State machine diagram) Diagramme de squence (Sequence diagram)
Ces diagrammes, dune utilit variable selon les cas, ne sont pas ncessairement tous produits lors dune modlisation. Les plus utiles sont les diagrammes dactivits, de cas dutilisation, de classes, dobjets, de squence et dtats-transitions. Les diagrammes de composants, de dploiement et de communication sont surtout utiles pour la matrise duvre qui ils permettent de formaliser les contraintes de la ralisation et la solution technique.
1- Diagramme de cas dutilisation

Le diagramme de cas dutilisation reprsente la structure des grandes fonctionnalits ncessaires aux utilisateurs du systme. Il dcrit sous forme dactions et de ractions, le comportement dun systme du point de vue dun utilisateur. 1-1 Elments de base des cas d'utilisation
Acteur : entit externe qui agit sur le systme (oprateur, autre systme...).
L'acteur peut consulter ou modifier l'tat du systme. En rponse l'action d'un acteur, le systme fournit un service qui correspond son besoin. Les acteurs peuvent tre classs (hirarchiss).
Cas dutilisation (Use case) : ensemble d'actions ralises par le systme, en rponse une action d'un acteur.
Cas dutilisation
Les uses cases peuvent tre structurs. Les uses cases peuvent tre organiss en paquetages (packages).
Hamid ALHAIANE
L'ensemble des use cases dcrit les objectifs (le but) du systme.
1-2 Exemple de diagramme de cas d'utilisation standard : Distributeur de billets

Consulter solde
Client
Retirer de largent
Eteindre/Allumer le distributeur
Ravitailler le coffre
Technicien
1-3 Relation entre cas dutilisation : a- Relation dutilisation : include Cette relation indique que le cas dutilisation source contient aussi le comportement dcrit dans le cas dutilisation destination. Lexemple suivant montre que pour raliser le CU imprimer compte on doit utiliser les services : consulter solde et imprimer ticket.
include
Imprimer solde
Consulter solde
include
Imprimer ticket
b- Relation dextension : Extends
Hamid ALHAIANE
Cette relation indique que le cas dutilisation source tend (prcise) le comportement du cas dutilisation destination. Lexemple suivant montre que les CU : Retirer des dirhams et Retirer des devises prcisent le comportement du CU : Retirer de largent.
Retirer de largent
Extends
Extends
Retirer des devises
Retirer des Dirhams
2- Diagramme de Classes :
2-1 UML et les concepts de la POO : 2-1-1 Classe : Une classe est un type abstrait caractris par des proprits (attributs et mthodes) communes un ensemble d'objets et permettant de crer des objets ayant ces proprits.
Exemple de classe : Voiture Voiture
Classe non documente
marque immatriculation Propritaire dmarrer conduire arrter
Classe documente Attributs Mthodes
2-1-2 Objet et instance:
Un objet est une entit qui a un sens dans le contexte de l'application. En UML, le mot objet est souvent li la notion dinstance alors quen orient objet usuel, le mot objet est souvent li aux deux notions de classe et dinstance.
Exemple dinstances :
Hamid ALHAIANE
:Voiture Toyota :Voiture Toyota :voiture couleur : gris marque : Golf :Voiture :Voiture :Voiture
Instance anonyme de la classe voiture Instance nomme de la classe voiture Instance nomme dune classe anonyme Instance anonyme de la clase voiture dont la valeurs de certains attributs sont spcifis explicitement Collection dinstances anonymes de la classe voiture
2-1-3 Relations entre classes: a Liens et association : Les liens permettent d'tablir des relations entre objets (ou instances). Les associations permettent d'tablir des relations entre classes. Pour une association binaire ( entre deux classes) : il existe un rle vers l'avant et un rle inverse. UML permet de spcifier le sens de lecture avec les symboles > et <.
Exemple de lien et dassociation :
personne
Possde >
voiture
:personne
< Appartient
:voiture
possde est une association de la classe personne avec la classe voiture. appartient est le rle inverse de lassociation possde.
Une association peut relier une, deux ou plusieurs classes. Dans le cas o elle relie n classes elle est dite n-aire.
Hamid ALHAIANE
Exemple dassociation n-aire:
Achte - chez Personne concessionnaire
Voiture
Lexemple ci-dessus reprsente une association ternaire exprimant lide quune personne achte une voiture chez un concessionnaire.
b Multiplicit dune association : Pour les deux rles dune association binaire, la multiplicit est un ensemble de valeurs indiquant le nombre possible d'instances de la classe destination du rle qui peuvent tre relies une instance de la classe origine du rle. 1 1..* * et 0..* 3..10 2,4,10 * : Signifie un exactement : Signifie de un plusieurs : Signifie de zro plusieurs : Signifie lintervalle 3 10 inclus : Signifie explicitement les valeurs 2, 4 et 10 : Signifie plusieurs
par dfaut une ligne simple = un
c Gnralisation et hritage : La gnralisation dcrit une relation entre une classe gnrale (classe de base ou classe parent) et une classe spcialise (sous-classe ou classe fille). La classe spcialise est intgralement cohrente avec la classe de base, mais comporte des informations
Hamid ALHAIANE
supplmentaires (attributs, oprations, associations). Un objet de la classe spcialise peut tre utilis partout o un objet de la classe de base est autoris.
Exemple dune relation de gnralisation :
Vhicule
Voiture
Tracteur
Camion
d Lagrgation : Une agrgation est une association qui reprsente une relation dinclusion structurelle ou comportementale dun lment dans un ensemble. Graphiquement, on ajoute un losange vide du ct de lagrgat.
Exemple dune relation dagrgation :
Entreprise
Vhicule
e La composition : La composition, galement appele agrgation composite, dcrit une contenance structurelle entre instances. Ainsi, la destruction de lobjet composite implique la destruction de ses composants. Une instance de la partie appartient toujours au plus une instance de llment composite. Graphiquement, on ajoute un losange plein du ct de lagrgat.
Exemple dune relation dagrgation composition :
Voiture
Roue
Hamid ALHAIANE
2-1 Elaboration dun diagramme de calasses: Une dmarche couramment utilise pour btir un diagramme de classes consiste : a- Trouver les classes du domaine tudi ; Cette tape empirique se fait gnralement en collaboration avec un expert du domaine. Les classes correspondent gnralement des concepts du domaine. b- Trouver les associations entre classes ; Les associations correspondent souvent des verbes, ou des constructions verbales, mettant en relation plusieurs classes, comme est compos de , pilote , travaille pour . c- Trouver les attributs des classes ; Les attributs correspondent souvent des substantifs, ou des groupes nominaux, tels que la masse dune voiture ou le montant dune transaction . Les adjectifs et les valeurs correspondent souvent des valeurs dattributs. Vous pouvez ajouter des attributs toutes les tapes du cycle de vie dun projet (implmentation comprise). d- Organiser et simplifier le modle En liminant les classes redondantes et en utilisant lhritage. e- Vrifier les chemins daccs aux classes. Raffiner le modle. Un modle est rarement correct ds sa premire construction. 2-2 Exercice : Elaboration dun diagramme de calasses: Elaborer un diagramme de classe modlisant les spcifications suivantes :
Un compte bancaire est domicilier dans une banque Une personne est client dune o plusieurs banques et peut possder plusieurs comptes Chaque personne est caractris par son nom et son age
Hamid ALHAIANE
Chaque compte est caractris par son solde et peut subir les oprations suivantes : dbiter, crditer, lire-Solde. Banque 1 * Compte -Solde +dbiter() +crditer() +lire-solde() * * Personne client +nom +age 1 propritaire *
3- Diagramme dobjets :
3-1 Prsentation : Un diagramme dobjets reprsente des objets (i.e. instances de classes) et leurs liens (i.e. instances de relations) pour donner une vue de ltat du systme un instant donn. Un diagramme dobjets permet, selon les situations, dillustrer le modle de classes (en montrant un exemple qui explique le modle), de prciser certains aspects du systme (en mettant en vidence des dtails imperceptibles dans le diagramme de classes), dexprimer une exception (en modlisant des cas particuliers, des connaissances non gnralisables . . .), ou de prendre une image (snapshot) dun systme un moment donn. Le diagramme de classes modlise les rgles et le diagramme dobjets modlise des faits. 3-2 Exemple de diagramme dobjets :
Entreprise nom : String 0..1 Travaille pour Travaille pour 2..* Personne
Hamid ALHAIANE
e :Entreprise nom : String = WANA Travaille pour
p1:Personne
p2:Personne
Le diagramme de classes montre quune entreprise emploie au moins deux personnes et quune personne travaille dans au plus une entreprise. Le diagramme dobjets modlise quant lui une entreprise particulire (WANA) qui emploie deux personnes (p1 et p2).
4- Diagramme de collaboration :
4-1 Prsentation :
Les diagrammes de collaboration montrent des interactions entre objets (instances de classes et acteurs). Ils permettent de reprsenter le contexte d'une interaction, car on peut y prciser les tats des objets qui interagissent. Exemple : dcoller :Tour de contrle Fk74:Airbus etat = a_terre
atterrir
WT12:concorde etat = en_vol
Lexemple montre que lobjet tour de contrle envoie un message dcoller et un autre message atterrir aux deux objets : fk74 et WT12. lordre de ces messages nest pas indiqu. 4-2 Synchronisation des messages : UML permet de spcifier de manire trs prcise l'ordre et les conditions d'envoi des messages sur un diagramme dynamique. Pour chaque message, il est possible d'indiquer :
o les clauses qui conditionnent son envoi,
Hamid ALHAIANE
o o o
son rang (son numro d'ordre par rapport aux autres messages), sa rcurrence, ses arguments.
Un message est, habituellement, spcifi sous la forme suivante : [pr /] [ [cond] [sq] [ *[||] [iter] ] :] [r :=] msg([par]) pr : prdcesseurs (liste de numros de squence de messages spars par une virgule ; voir aussi "sq"). cond : est une condition sous forme dexpression boolenne entre crochets. sq : est le numro de squence du message. On numrote les messages par envoi et sous-envoi dsigns par des chiffres spars par des points : ainsi lenvoi du message 1.4.3 est antrieur celui du message 1.4.4 mais postrieur celui du message 1.3.5. La simultanit dun envoi est dsigne par une lettre : les messages 1.6.a et 1.6.b sont envoys en mme temps. iter : spcifie (en langage naturel, entre crochets) lenvoi squentiel (ou en parallle, avec ||). On peut omettre cette spcification et ne garder que le caractre "*" (ou "*||") pour dsigner un message rcurrent envoy un certain nombre de fois. r : est la valeur de retour du message, qui sera par exemple transmise en paramtre un autre message. msg : est le nom du message. par : dsigne les paramtres (optionnels) du message.
Exemples :
[heure = midi] 1 : manger() : Ce message n'est envoy que s'il est midi.
1.3.6 * : ouvrir() certain nombre de fois.
: Ce message est envoy de manire squentielle un
3 / *||[i := 1..5] : fermer() : cet exemple reprsente l'envoi en parallle de 5 messages. Ces messages ne seront envoys qu'aprs l'envoi du message 3.
Hamid ALHAIANE
4-3 types de messages : UML propose un certain nombre de strotypes graphiques pour dcrire la nature des messages (ces strotypes graphiques s'appliquent galement aux messages des diagrammes de collaborations) :
message simple Message dont on ne spcifie aucune caractristique d'envoi ou de rception particulire. message minut (timeout) Bloque l'expditeur pendant un temps donn (qui peut tre spcifi dans une contrainte), en attendant la prise en compte du message par le rcepteur. L'expditeur est libr si la prise en compte n'a pas eu lieu pendant le dlai spcifi. message synchrone Bloque l'expditeur jusqu' prise en compte du message par le destinataire. Le flot de contrle passe de l'metteur au rcepteur (l'metteur devient passif et le rcepteur actif) la prise en compte du message. message asynchrone N'interrompt pas l'excution de l'expditeur. Le message envoy peut tre pris en compte par le rcepteur tout moment ou ignor (jamais trait). message drobant N'interrompt pas l'excution de l'expditeur et ne dclenche une opration chez le rcepteur que s'il s'est pralablement mis en attente de ce message.
4-4 Exemple de diagramme de collaboration :

1* : mayday() 1/2b: envoyer(piste)
:Tour de contrle
pompiers
1/2a : atterrir(piste)
2b/3 * || : seDeplacer(piste,parking)
pa87:Boeing
Hamid ALHAIANE etat = dtresse
:avions :avions :avions etat ==a_terre etat =a_terre etat a_terre position ==piste position =piste position piste
5- Diagramme de squence :
5-1 Prsentation : Les diagrammes de squences permettent de reprsenter des collaborations entre objets selon un point de vue temporel, on y met l'accent sur la chronologie des envois de messages. Contrairement au diagramme de collaboration, on n'y dcrit pas le contexte ou l'tat des objets, la reprsentation se concentre sur l'expression des interactions. 5-2 Exemple de diagramme de squence :
: pilote
Toyota : voiture
HDI : moteur
Priode dactivation dmarrer temps
allumer
Ligne de vie
6- Diagramme dtat transition :

6-1 Notion dautomate tats finis : un automate tats finis est un automate dont le comportement des sorties ne dpend pas seulement de ltat de ses entres, mais aussi dun historique des sollicitations passes. Un automate tats finis est graphiquement reprsent par un graphe comportant des tats, matrialiss par des rectangles aux coins arrondis, et des transitions, matrialises par des arcs orients liant les tats entre eux.
Hamid ALHAIANE
6-2 Notion dtat : Un objet peut passer par une srie dtats pendant sa dure de vie. Un tat reprsente une priode dans la vie dun objet pendant laquelle ce dernier attend un vnement ou accomplit une activit. Un tat se caractrise donc par sa dure et sa stabilit, il reprsente une conjonction instantane des valeurs des attributs d'un objet.
tat Etat simple 6-3 Transition et vnements : Etat initial Etat final
Une transition dfinit la rponse dun objet loccurrence dun vnement. Elle lie, gnralement, deux tats E1 et E2 et indique quun objet dans un tat E1 peut entrer dans ltat E2 et excuter certaines activits, si un vnement dclencheur se produit et que la condition de garde est vrifie. La syntaxe dune transition est la suivante :
[ <vnement> ][ [ <garde> ] ] [ / <activit> ]
teint
pression pression
allume r
tat1 [condition]
tat2
[else] tat1
Hamid ALHAIANE

Génie Logiciel

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Génie Logiciel

Uploaded by

Copyright:

Available Formats

Gnie Logiciel Page 1/54

BTS Gnie Informatique

Gnie Logiciel Page 2/54

Introduction au Gnie Logiciel

Gnie Logiciel Page 3/54

II- Objectif et ncessit :

Gnie Logiciel Page 4/54

Gnie Logiciel Page 5/54

II- Attributs dun logiciel :

Gnie Logiciel Page 6/54

Gnie Logiciel Page 7/54

III- Types de logiciels :

Gnie Logiciel Page 8/54

Fig.1 : Types de logiciels

VI- Qualit dun logiciel :

Gnie Logiciel Page 9/54

La fiabilit : La robustesse : Lextensibilit : La rutilisabilit : La compatibilit : Lefficacit :

Gnie Logiciel Page 10/54

Les projets Logiciels

II- Gestion de projet logiciel:

Gnie Logiciel Page 11/54

Gestion des productions

Fig.2 : Types de gestions

III- Types de gestion: 3-1 Gestion des dlais :

3-2 Gestion des ressources :

Gnie Logiciel Page 12/54

3-3 Gestion des productions :

VI- Complexit des projets logiciels:

P : Projet moyen ou semi-dtach (semidetached) (50 000 LOC 300 000)

Gnie Logiciel Page 13/54

5-2 Les mthodes destimation de charge : 5-2-1 La mthode DELPHI :

Gnie Logiciel Page 14/54

5-2-2 La mthode COCOMO (COnstructive COst Model) :

Gnie Logiciel Page 15/54

Organique Semi-dtach Imbriqu

= TDEV 2,5*(Charge)0,38 TDEV

2,4*(KLOC)1,05 Charge = 3*(KLOC)1,12 Charge 3,6*(KLOC)1,20

2,5*(Charge)0,35 = TDEV 2,5*(Charge)0,32

Charge en M/h Charge

TDEV en M = TDEV 2,5*(Charge)0,38 TDEV = = =

3,2*(KLOC)1,05 Charge = 3*(KLOC)1,12 Charge 2,8*(KLOC)1,20

2,5*(Charge)0,35 = TDEV 2,5*(Charge)0,32

Facteurs de productivit Attributs du produit RELY DATA CPLX Attributs de lordinateur

T.Bas 0.75 0.70

Bas 0.88 0.94 0.85

T.Haut 1.40 1.16 1.30

Gnie Logiciel Page 16/54

1.30 1.21 1.30 1.15 0.71 0.82 0.70

0.82 0.83 1.10

5-2-3 La mthode de rpartition proportionnelle :

Tab. 4 : Mthode de rpartition proportionnelle

Gnie Logiciel Page 17/54

Gnie Logiciel Page 18/54

Principes gnraux en Gnie Logiciel

Gnie Logiciel Page 19/54

II- Principes gnraux en Gnie Logiciel :

2- Sparation des problmes

Gnie Logiciel Page 20/54

sparation et lordonnancement des questions traiter.

Gnie Logiciel Page 21/54

Gnie Logiciel Page 22/54

Gnie Logiciel Page 23/54

Cycle de vie dun logiciel

2,4(KLOC)1,05 Charge = 3(KLOC)1,12 Charge 3,6*(KLOC)1,20

2,5(Charge)0,35 = TDEV 2,5(Charge)0,32

3,2(KLOC)1,05 Charge = 3(KLOC)1,12 Charge 2,8*(KLOC)1,20

2,5(Charge)0,35 = TDEV 2,5(Charge)0,32