Genie Logiciel

Support de cours : Introduction au Génie Logiciel
Suivant : Préface Père : Ma page d'accueil
Support de cours
Introduction au Génie
Logiciel
Mamoun ALISSALI
Novembre 1998
http://www-ic2.univ-lemans.fr/~alissali/Enseignement/Polys/GL/gl.html (1 of 5) [31-12-2001 21:47:44]

Avertissement
Ce document est en cours d'élaboration ce qui ne me permet pas d'en diffuser que la version HTML. En
attendant une version papier présentable, voici, en plus des références bibliographiques, quelques sites
WEB qui peuvent intéresser le lecteur :
● Programmation - Objets - Modélisation de la connaissance
● The Software Quality Page

● Object-Oriented Information Sources
● The Method Engineering Encyclopaedia
● The Virtual Library - Computer Programming Languages
Université du Maine - Le Mans
● Préface
❍ Objectifs
❍ Position du problème
❍ Agencement de la programmation et de la conception
❍ Conclusion
● Principes du Génie Logiciel
❍ Introduction
■ Définitions
■ Objectif et nécessité
❍ Qualité du logiciel
❍ Modélisation

● Modèles de développement du logiciel

❍ Introduction
❍ Le cycle de vie du logiciel
❍ Les activités
■ Analyse des besoins
❍ Modèles du cycle de vie
■ Modèle de la cascade
■ Modèle en V
■ Modèle en spirale
■ Modèles par incrément
❍ Analyse et spécification du logiciel
■ Techniques de spécification
❍ Conception du logiciel
■ Méthodes d'analyse et de conception
■ Méthodes fonctionnelles
● SADT: méthode d'analyse fonctionnelle et de gestion de projets
❍ Présentation générale
■ Historique
❍ Le Modèle SADT
❍ La syntaxe des diagrammes SADT
■ Actigrammes
■ Datagrammes
■ Les textes explicatifs
■ Les diagrammes pour explication seulement
■ Liste hiérarchique et numérotation des diagrammes
■ Glossaires
■ Conditions d'activation
■ Processus de liens
❍ Travail en équipe
■ Cycle auteur/lecteur
● Conception du logiciel
❍ Qualité de la conception
■ Modularité

■ Critères de qualité de la conception

■ Processus de conception de logiciel
● Conception fonctionnelle
❍ Les diagrammes de flux de données
❍ Les diagrammes de structure
● Approche orientée objet
❍ Première définition
❍ Caratéristiques des objets
■ Identité : notion d'objet
■ Classification : notion de classe
■ Polymorphisme : notion de surcharge
■ Héritage : notion de paratge
● OMT : méthode d'analyse et de conception orientée objet
❍ Introduction
❍ Analyse
■ Modèle objet
■ Modèle dynamique
■ Modèle fonctionnel
■ Ajouter les opérations
■ Itération de l'analyse
❍ Conception du système
■ Introduction
■ Décomposer le système
■ Couches
■ Partitions
■ Topologie du système
❍ Identification des ressources
■ Concurrences intrinsèques
■ Tâches concurrentes
❍ Allocation des sous-systèmes aux processeurs/tâches
❍ Réservoires de données
❍ Partage des ressources globales
❍ Logiciel de contrôle

❍ Conditions limites
❍ Compromis de priorités
❍ Architectures type
■ Transformation par lots (Pipeline)
■ Transformation continue
■ Interface interactive
■ Simulation dynamique
■ Systémes temps réel
■ Gestionnaire de transactions
❍ Conception des objets
● Management des projets logiciels
● Gestion des projets Logiciels
● Validation, Vérification et tests
● Qualité et assurance qualité
● Gestion des configurations
● Liste des figures
● Références
● Index
© Copyright 1998 Mamoun Alissali. Tous droits réservés.

Commentaires et suggestions.
Dernière mise à jour le 18 janvier 2000.

Préface
Suivant : Objectifs Précédent : Support de cours : Introduction Père : Support de cours : Introduction
Préface
● Objectifs
● Position du problème
● Agencement de la programmation et de la conception
● Conclusion

http://www-ic2.univ-lemans.fr/~alissali/Enseignement/Polys/GL/ACUnode1.html [31-12-2001 21:47:58]

Index
Précédent : Références Père : Support de cours : Introduction
Index
description des fonctions
expérimentalemaquette
abstraction ,
activité
analyse des risques
Analyse
des besoins
architecturale
conception
architecture
du système
fermée
ouverte
association ,
attribut ,
cahier des charges ,
cardianlité
classe
classe
fille
mère
clé
comportement ,
conception
architecturale
http://www-ic2.univ-lemans.fr/~alissali/Enseignement/Polys/GL/ACUnode95.html (1 of 6) [31-12-2001 21:48:08]

Index
détaillée
globale
concurrence
configurations
gestion de
contrainte
couche ,
cycle de vie
cycle de vie
modèles de
d'objets
diagramme
d'états
diagramme
de données
dictionnaire
de l'événement
paramètres
description des fonctions
diagramme
d'objets
d'états
à flot de données|textbf
diagrammes
à flot de données
dictionnaire
de données
détaillée
conception
développement
processus de
encapsulation
entité
entité-association

Index
en étoile
organisation
exploratoire
maquette
expérimentalemaquette
fille
classe
gestion
de configurations
globale
conception
généralisation
héritage
identité
instance
intégration
de logiciel
tests@{tests d'}
invisibilité
l'interface
utilisateur
logiciel
intégration de
noyau de
validation de
vérification de
maintenance
maquettage
maquette
exploratoire
masquage de données
modularité
Modularité
principes de

Index
module ,
module
fermé
ouvert
modules
modèle
modèle
de la cascade
dynamique|textbf
en V
entité-association
objet
modèles
de cycle de vie
mère
classe
méthode
Méthode OMT
méthodes ascendantes
méthodes descendates
noyau
de logiciel
objet
modèle
opération
organisation
en étoile
paramètres
de l'événement
partage hiérarchique
partition
partitions
phase
polymorphisme

Index
processus
de développement
procédé
de production
production
procédé de
propriété
protocôle
client-serveur
égal-à-égal
prototypage rapide
raffinements successifs
revue
réutilisation
scénario
signature
sous-classe
sous-système
spécialisation
super-classe
synchronisation
système
architecture du
test
système
tests
dynamiques
intégration@d'intégration
statiques
unitaires
transition
utilisateur
l'interface
validation

Index
de logiciel
vérification
de logiciel
à flot de données
diagrammes
étape
état ,
événement


Objectifs
Suivant : Position du problème Précédent : Préface Père : Préface
Objectifs
Ce document tente de présenter quelques aspects, de nature plutôt pratique, du vaste domaine du Génie
Logiciel. Nous insisterons sur trois points principaux : la conception du logiciel, la conduite de projet et
le travail d'équipe.
Les évolutions récentes dans le monde de l'informatique (taille et nature des logiciels, ouverture réseau,
etc.) créent une demande croissante de la part de l'industrie de concepteurs informaticiens. Pour diverses
raisons, la conception est généralement enseignée après la programmation. Quelque soit la démarche, il
est indispensable d'enseigner les deux : la programmation et la conception, mais lorsqu'il s'agit de <<
grands systèmes >> l'expérience prouve que la conception reste handicapée et en arrière plan lorsqu'elle
est introduite après une certaine expérience en programmation. Ainsi, notre approche vise à former des
concepteurs qui savent programmer plutôt que des programmeurs qui savent concevoir.
Pour éviter une polémique souvent rencontrée dans les milieux de l'enseignement et de l'industrie, il est
important de souligner que cette démarche au lieu de les contredire, renforce et appuie les points suivants
:
● les bases de l'informatique (programmation, algorithmique et structures de données) sont
indispensables ;
● la programmation orientée-objet est complexe et nécessite une attention particulière ;
● il est impératif que les étudiants puissent mener au moins un << grand projet >> de A a Z.
Sur un autre plan, étroitement lié au premier, les systèmes informatiques deviennent de plus en plus
grands et complexes. Ils ne peuvent plus être conçus, réalisés et maintenus par une seule (ou un nombre
réduit de) personne(s). D'où la nécessité de former nos étudiants au travail d'équipe et à la gestion des
projets également.


Position du problème
Suivant : Agencement de la programmation et Précédent : Objectifs Père : Préface
Position du problème
Un système informatique est un système complexe, qui répond à des besoins issus du << monde réel >>
et non pas des contraintes des ordinateurs sur lesquels il sera réalisé. Le tout est de faire le pont entre les
deux : exprimer une << modélisation du monde réel >> en termes de langage de programmation
fatalement lié à l'ordinateur. Cette dichotomie a de tout temps existé pour l'informatique. Si on tient
compte du très jeune âge de cette discipline relativement à d'autres domaines scientifiques, il paraît
évident que les techniques les plus récentes sont les plus adéquates.
Mais de quoi s'agit-il au juste ? De la modélisation du << monde réel >> à l'aide des techniques
orientées-objet et de la programmation qui porte le même nom. Mais les deux ne sont pas indissociables,
comme le prouvent des environnements très évolués, complexes, performants et fiables tels que
X/Window, Motif et DCE (tous disponible pour les plate-formes les plus courantes) conçus orienté-objet
et réalisés en C !


Agencement de la programmation et de la conception
Suivant : Conclusion Précédent : Position du problème Père : Préface
Agencement de la programmation et de
la conception
Mettons les choses à leurs places : la programmation est l'outil qui permet de réaliser ce qui a été conçu.
Mettre l'outil avant le concept revient à apprendre à un apprenti garagiste à utiliser le tournevis, la
perceuses et tous les détails de tous les outils dont il pourrait ou pas avoir besoin, sans lui expliquer à
quoi il servent vraiment ni lui montrer le véritable objectif : construire ou réparer une voiture ! Le
logiciel avec ses particularités (et surtout sa complexité) est un produit exactement comme (et parfois
beaucoup plus sérieusement) une voiture.
Il se trouve que la modélisation du monde réel, qui permet d'appréhender le logiciel dans sa globalité, est
aussi simple que notre propre conception du monde réel. Un objet chaise appartient à la classe des
chaises1 qui peut être décrite par des propriétés statiques (comme la couleur et le poids) et fonctionnelles,
comme le fait qu'on peut s'asseoir dessus2. Cette description générique peut être instanciée pour chaque
nouvel objet pour décrire ses caractéristiques propres3. Mais en même temps deux objets ayant
exactement les mêmes caractéristiques sont quand même deux objets différents4. Les chaises, aussi bien
que les tables, les armoires, etc. sont des meubles. La classe meuble regroupe toutes les caractéristiques
de ces << sous-classes >>, on dit que celles-ci héritent leur propriétés d'une << classe-mère >>5.
Ce sont là les concepts clefs de l'orienté-objet, le reste n'est pas plus complexe, alors que la
programmation orintée-objet, abordée séparément, paraît très complexe car elle doit ramener tout ça à
des structures de données et des algorithmes, tout ce qu'un ordinateur sait faire jusqu'à preuve du
contraire. Comment donc faire le pont entre les deux ? Il faut transcrire les objets du monde réel en objets
informatiques, c.à.d. tenir compte des contraintes qu'impose la réalisation sur ordinateur. Ces contraintes
sont variées mais très bien étudiées et classées dans des catégories pour lesquelles nous avons les
solutions adéquates ou, au moins, des idées assez précises. Pour ne prendre qu'un exemple simple, alors
que nous parlons dans le monde réel d'une << collection de chaises >>, un informaticien parlerait d'un
tableau ou d'une liste de chaises : il s'agit de << Structure de Données >> informatique et cet aspect est
indépendant (tant qu'il ne s'agit pas de la réalisation) de l'approche orientée-objet. Il en va de même pour
les << opérations >> sur les objets : rechercher une chaise se traduit par un algorithme encore
indépendant de l'orienté-objet. De ce point de vue, un langage de programmation orienté-objet n'est pas
un meilleur langage de programmation procédurale (ou impérative), mais un outil de construction de
systèmes complexes qui ne peut d'ailleurs pas s'affranchir des acquis informatiques de base (les
Structures de Données et les Algorithmes). Le savoir faire d'un concepteur est justement de faire cette
liaison entre ces acquis et la modélisation du monde réel, et c'est cette compétence qu'on appelle une

Agencement de la programmation et de la conception
méthode.


Conclusion
Suivant : Principes du Génie Logiciel Précédent : Agencement de la programmation et Père : Préface
Conclusion
Une erreur courante consiste à apprendre et à utiliser intensivement la programmation orientée-objet
avant la conception, mais ceci revient à mettre la charrue devant les bufs.
On peut même en dire plus : les langages à objets offrent un avantage ceratin mais ils ne sont
indispensables ni à la conception ni à la réalisation du logiciel objet.
Le processus de conception n'est en réalité rien d'autre que rappeler (et se rappeler) ce qu'est un
ordinateur et comment réaliser ou simuler les objets du monde réel, par leurs caractéristiques et leurs
comportements, sur des machines dont la principale caractéristique reste (encore jusqu'à preuve du
contraire) leur capacité à exécuter de manière répétitive et très organisée des tâches fondées sur la
logique formelle et la logique formelle seule !


Principes du Génie Logiciel
Suivant : Introduction Précédent : Conclusion Père : Support de cours : Introduction
Principes du Génie Logiciel
● Introduction
❍ Définitions
❍ Objectif et nécessité
● Qualité du logiciel
● Modélisation


Introduction
Suivant : Définitions Précédent : Principes du Génie Logiciel Père : Principes du Génie Logiciel
Introduction
Le génie logiciel est un domaine de recherche qui a été défini (fait rare) du 7 au 11 octobre 1968, à
Garmisch-Partenkirchen, sous le parrainage de l'OTAN. Il a pour objectif de répondre à un problème qui
s'énonçait en deux constatations :
d'une part le logiciel n'était pas faible, d'autre part, il était incroyablement difficile de
réaliser dans des délais prévus des logiciels satisfaisant leur cahier des charges.
La production du logiciel implique des environnements de développement, avec toute la variété d'outils
et d'approches dont on peut disposer, les méthodes et les techniques de gestion de processus, mais aussi
les aspects humains au sein de l'équipe de développement et les relations que celle-ci entretient avec les
commanditaires et les utilisateurs du produit.
● Définitions
● Objectif et nécessité


Définitions
Suivant : Objectif et nécessité Précédent : Introduction Père : Introduction
Définitions


Objectif et nécessité
Suivant : Qualité du logiciel Précédent : Définitions Père : Introduction
L'objectif du génie logiciel est d'optimiser le coût de développement du logiciel. L'importance d'une
approche méthodologique s'est montrée par la crise de l'industrie du logiciel à la fin des années 70 :
● augmentation des coûts ;
● difficultés d'évolution ;
● non fiabilité ;
● non respect des spécifications ;
● non respect des délais.
Les exemples suivants montre l'ampleur de l'impact des défaillances dûes au manque de méthodologie de
développement :
● la sonde Mariner vers Vénus s'est perdue dans l'espace à cause d'une erreur de programme
FORTRAN ;
● en 1972, lors d'une expérience météorologique en France 72 ballons contenant des instruments de
mesure furent détruits à cause d'un défaut dans le logiciel ;
● en 1981, le premier lancement de la navette spatiale a été retardé de deux jours à cause d'un
problème logiciel. La navette a d'ailleurs été lancé sans que l'on ait localisé exactement le
problème (mais les symptôme étaient bien délimités) ;
● le développement du compilateur PL1 de Control Data n'a jamais abouti ;
● EDF a récemment renoncé à la mise en service de nouveaux systèmes de contrôle-commande de

ses centrales 1400 méga-watts ;
● la SNCF a rencontré des difficultés importantes pour la mise en service du système Socrate.
● L'explosion d'Ariane 5, le 4 juin 1996, qui a coûté un demi milliard de dollars (non assuré !), est
dûe à une faute logicielle d'une composante dont le fonctionnement n'était pas indispensable
durant le vol [12].
Une enquête effectuée aux USA en 1986 auprès de 55 entreprises révèle que 53% du budget total d'un
logiciel est affecté à la maintenance. Ce coût est réparti comme suit :
● 34% maintenance évolutive : modification des spécifications initiales ;
● 10% maintenance adaptative : nouvel environnement, nouveaux utilisateurs ;
● 17% maintenance corrective : correction des bogues ;
● 16% maintenance perfective : améliorer les performance sans changer les spécifications ;

● 6% assistance aux utilisateurs ;

● 6% contrôle qualité ;
● 7% organisation/suivi ;
● 4% divers.
Ceci s'explique par l'augmentation de la complexité des logiciel avec la montée en puissance des
performances du matériel.


Qualité du logiciel
Suivant : Modélisation Précédent : Objectif et nécessité Père : Principes du Génie Logiciel
Cette définition est délibéremment ambiguë puisqu'elle se veut générale. Selon les domaines des
définitions plus précises peuvent se dégager. En génie logiciel divers travaux ont mené à la défintion de
la qualité du logiciel en termes de facteurs, qui dépendent, entre autres, du domaine de l'application et des
outils utilisés. Les facteurs peuvent être classés en internes (visibles par les développeurs) et externes
(visibles par les utilisateurs). Parmi ces derniers nous retiendrons [19] :
● Validité : aptitude d'un produit logiciel à remplir exactement ses fonctions, définies par le cahier
des charges et les spécifications.
● Fiabilité (ou robustesse) : aptitude d'un produit logiciel à fonctionner dans des conditions
anormales.
● Extensibilité : facilité avec laquelle un logiciel se prête à une modification ou à une extension des
fonctions qui lui sont demandées.
● Réutilisabilité : aptitude d'un logiciel à être réutilisé, en tout ou en partie, dans de nouvelles
applications.
● Compatibilité : facilité avec laquelle un logiciel peut être combiné avec d'autres logiciels.
● Efficacité : Utilisation optimales des ressources matérielles.
● Portabilité : facilité avec laquelle un logiciel peut être transférée sous différents environnements
matériels et logiciels.
● Vérifiabilité : facilité de préparation des procédures de test.
● Intégrité : aptitude d'un logiciel à protéger son code et ses données contre des accès non autorisés.
● Facilité d'emploi : facilité d'apprentissage, d'utilisation, de préparation des données,

d'interprétation des erreurs et de rattrapage en cas d'erreur d'utilisation.
Ces facteurs sont parfois contradictoires, le choix des compromis doit s'effectuer en fonction du contexte.
Par exemple,la facilité d'emploi et la fiabilité peuvent être contradictoires. Dans une application du type «
traitement de texte » (resp. pilotage d'usine) c'est le premier (resp. le deuxième) de ces deux facteurs qui
sera favorisé.



Modélisation
Suivant : Modèles de développement du logiciel Précédent : Qualité du logiciel Père : Principes du

Génie Logiciel
Modélisation
Un modèle est une abstraction de quelque chose de réel qui permet de comprendre avant de construire,
ou de retrouver les informations nécessaire pour effectuer des entretiens, modifications et extensions. Il
est plus aisé de se référer à un modèle qu'à l'entité d'origine car le modèle simplifie la gestion de la
complexité en offrant des points de vue et des niveaux d'abstractions plus ou moins détaillés selon les
besoins.
Il n'y a pas de « modèle correct unique » pour une situation donnée, mais un modèle est plus ou moins
adéquat selon qu'il réussisse à saisir les aspects cruciaux et négliger les autres en fonction du but
recherché. L'abstraction dans ce contexte signifie l'examen sélectif de certains aspects du problème ; c'est
l'outil qui permet de délimiter notre connaissance de l'univers aux entités et aux interactions qui nous
concernent dans une situation donnée.
La modélisation est utilisée en Génie Logiciel à différents niveaux. Dans ce document nous parlerons des
modèles de développement du logicielcha:modelesDev, des modèles de cycle de viesec:modCycVie ainsi
que des modèles du logiciel produits par l'analyse fonctionellecha:SADT, la conception
fonctionnellecha:concFctl et l'analyse et la conception orientées objetcha:OMT.


Modèles de développement du logiciel
Suivant : Introduction Précédent : Modélisation Père : Support de cours : Introduction
● Introduction
● Le cycle de vie du logiciel
● Les activités
❍ Analyse des besoins
■ Spécification globale
■ Conception architecturale et détaillée
■ Programmation
■ Gestion de configurations et intégration
■ Validation et vérification
■ Rôle du maquettage
● Modèles du cycle de vie
❍ Modèle de la cascade
❍ Modèle en V
■ Relations entre phases et activités selon le modèle en V
❍ Modèle en spirale
■ Risques majeurs du développement du logiciel
■ Exemple : Console de contrôle de lumière
❍ Modèles par incrément
■ Avantages
■ Risques
■ Exemple : Une extension pour une chaîne d'édition
● Analyse et spécification du logiciel
❍ Techniques de spécification

■ Énonces informels
■ Présentations formatées
■ Techniques graphiques ou semi-formelles
■ Techniques formelles
● Conception du logiciel
❍ Méthodes d'analyse et de conception
❍ Méthodes fonctionnelles
■ Analyse structurée
■ Analyse « temps réel »
■ Méthodes de conception fonctionnelle


Introduction
Suivant : Le cycle de vie du Précédent : Modèles de développement du logiciel Père : Modèles de

développement du logiciel
Introduction
Comparé aux autre produits, le logiciel présente quelques, particularités, p.e. le problème de production
en série ne se pose pas. Néanmoins il est produit selon un procédé de production ou un processus de
développement. Ce processus a les caractéristiques suivantes :
● il fait une large place à l'analyse des besoins, à la conception et à la validation ;
● il s'opère par raffinements successifs : la partie technique du développement d'un logiciel consiste
en l'établissement d'une suite de descriptions de plus en plus proches d'un programmes exécutable
et sa documentation ;
● certaines étapes peuvent déclencher la révision des étapes précédentes : un manque de précision
des spécifications peut être détecté lors de la conception. Une erreur de conception peut ne paraître
que lors du test du logiciel.
● pour pallier au problème de l'invisibilité, il donne lieu à la production de documents intermédiaires
permettant de contrôler un logiciel en cours de développement ;
● la plupart du temps il est poursuivi après la livraison du logiciel, pour la maintenance qui peut
remettre en cause les fonctions du système et impliquer des modifications et/ou un
redéveloppement.
L'ensemble des phases par lesquelles passe le logiciel s'appelle le cycle de vie.


Le cycle de vie du logiciel
Suivant : Les activités Précédent : Introduction Père : Modèles de développement du logiciel

Comme tout produit complexe , le cycle de vie du logiciel passe par les phases (ou étapes) suivantes :
● Étude de faisabilité ;
● Spécifications ;
● Production ;
● Contrôles ;
● Essais ;
● Contrôle de la production ;
● Vente/utilisation/entretien ;
Pour mieux maîtriser le processus développement on se réfère à des modèles de cycle de vie, (cf. 2.4 et
1.3) permettant de prendre en compte, en plus des aspects techniques, l'organisation et les aspects
humains.
Il est important de noter qu'une étape, telle que la conception, peut faire intervenir plusieurs activités,
comme celles de la spécification globale, du maquettage et de la validation. Inversement une activité
comme la documentation peut se dérouler pendant plusieurs étapes.
Les relations entre les différentes activités, entre les différentes étapes et entre les étapes et les activités
dépendent du modèle. La définition fournie par le modèle en Vsec:relPhaseAc est parmi les plus
complètes.
La continuité du cycle de vie du logiciel implique qu'il faut respecter l'enchaînement des différentes
phases. Le processus de développement consiste à décomposer le problème en veillant à :
● à chaque niveau de décomposition, bien décrire le problème et sa décomposition en
sous-problèmes ;
● bien préciser le procédé de recomposition (ou intégration) : l'assemblage des solutions des sous
problèmes ne donne pas automatiquement la solution du problème ;
● concevoir (et utiliser) des solutions réutilisables.



Les activités
Suivant : Analyse des besoins Précédent : Le cycle de vie du Père : Modèles de développement du
logiciel
Les activités
Le développement du logiciel peut être découpé en plusieurs activités qui seront présentées brièvement
ici et dont les plus importantes seront détaillées dans les chapitres suivants.
● Analyse des besoins

❍ Spécification globale
❍ Conception architecturale et détaillée
❍ Programmation
❍ Gestion de configurations et intégration
❍ Validation et vérification
❍ Rôle du maquettage


Analyse des besoins
Suivant : Modèles du cycle de vie Précédent : Les activités Père : Les activités
Sous-sections
● Spécification globale
● Conception architecturale et détaillée

● Programmation
● Gestion de configurations et intégration
● Validation et vérification
● Rôle du maquettage
Analyse des besoins

But : éviter de produire un logiciel non adéquat.
Démarche : pour établir les besoins (le cahier des charges) il faut étudier :
● le domaine d'application ;
● l'état actuel de l'environnement du futur système ;
● le rôle du système ;
● les ressources disponibles et requises ;
● les contraintes d'utilisation ;
● les performances attendues ;
● ...
Il faut surtout établir un dialogue avec les experts du domaine, qui ne sont pas forcément des
informaticiens, et, pour ce faire, utiliser des méthodes plutôt cognitives : entretiens, questionnaires,
observation de l'existant et étude de situations similaires.
Cette activité doit être menée en liaison avec les études de faisabilité et la planification, et doit se
poursuivre durant tout le processus de développement.
Spécification globale
But : Établir une première description du futur système.
Cette activité utilise les résultats de l'analyse des besoins, les considérations techniques et la faisabilité
informatique pour produire une description de ce que doit faire le système mais sans préciser comment il

Analyse des besoins
le fait (on précise le quoi mais pas le comment).
Conception architecturale et détaillée

But : enrichir la description du logiciel de détails d'implémentation afin d'aboutir à une description très
proche d'un programme (décrire le comment).
La conception architecturale (ou conception globale) a pour but de décomposer le logiciel en
composants plus simples, définis par leurs interfaces et leurs fonctions (les services qu'ils rendent).
La conception détaillée fournit pour chaque composant une description de la manière dont les fonctions
ou les services sont réalisés : algorithmes, représentation des données.
Programmation
But : réalisation, à partir de la conception détaillée, d'un ensemble de programme ou de composants de
programmes.
Gestion de configurations et intégration

La gestion de configurations a pour but de maîtriser l'évolution et la mise à jour des composants tout au
long du processus de développement. Les environnements intégrés de développement permettent de
gérer de façon plus cohérentes les documents relatifs à un logiciel.
L'intégration a pour but de réaliser un ou plusieurs systèmes exécutables à partir des composants. Les
choix possibles correspondent à des variantes du système.
Validation et vérification
La validation a pour but de répondre à la délicate question : a-t-on décrit le bon système, celui qui répond
à l'attente des utilisateurs ? Elle consiste essentiellement en des revues et inspections de spécifications ou
de manuels et du prototypage rapide.
La vérification répond à la question : le développement est-il correct par rapport à la spécification globale
? Ce qui consiste à s'assurer que les description successives et, in fine, le logiciel lui-même satisfont la
spécification globale. Elle inclut des inspection de spécifications et de programmes ainsi que de la preuve
et du test.
On distingue les tests statiques (examen ou analyse du texte) des tests dynamiques. Ceux derniers
consiste en l'exécutions du logiciel sur un sous-ensemble des données permettant de vérifier :
● tous les chemins d'accès logiques ;
● la plage de validité des données et en particulier les « conditions limites » ;
● la conformité des résultats aux spécifications.
Par ailleurs, on distingue différents niveaux de test :

● les tests unitaires pour les composants isolés ;
● les tests d'intégration pour un assemblage de composants ;

Analyse des besoins
● le test système qui consiste à tester le logiciel dans des conditions opérationnelles et au delà
(surcharge, défaillances matérielles, ...).
Rôle du maquettage
Le maquettage ou prototypage rapide (rapid prototyping) est une technique qui permet de surmonter la
difficulté de spécification du logiciel due à la différence de terminologie et au manque de précision dans
l'expression des besoins. Cette activité consiste à développer rapidement une ébauche du futur système
(maquette ou prototype).
Il est important de préciser le rôle de la maquette : elle peut être exploratoire si elle est utilisée pour
préciser les besoins des utilisateurs, ou expérimentalemaquette si elle intervient lors de la conception
pour aider à expérimenter différents choix.
Dans un projet « bien conduit », l'effort se répartit comme suit : 15 à 20% programmation, 40%
spécification et conception, 40% validation et vérification.


Modèles du cycle de vie
Suivant : Modèle de la cascade Précédent : Analyse des besoins Père : Modèles de développement du
logiciel
Modèles du cycle de vie
● Modèle de la cascade
● Modèle en V
❍ Relations entre phases et activités selon le modèle en V
● Modèle en spirale
❍ Risques majeurs du développement du logiciel
❍ Exemple : Console de contrôle de lumière
● Modèles par incrément
❍ Avantages
❍ Risques
❍ Exemple : Une extension pour une chaîne d'édition


Modèle de la cascade
Suivant : Modèle en V Précédent : Modèles du cycle de vie Père : Modèles du cycle de vie
Modèle de la cascade
Dans ce modèle le principe est très simple : chaque phase se termine à une date précise par la production
de certains documents ou logiciels. Les résultats sont définis sur la base des interactions entre étapes et
activités, ils sont soumis à une revue approfondie, on ne passe à la phase suivante que s'ils sont jugés
satisfaisants.
Certaines phases portent le nom d'une activité ce qui signifie que l'activité est essentielle pour cette
phase, mais n'impose pas qu'elle n'ait lieu que dans cette étape. D'autres activités interviennent, par
exemple le contrôle technique et la gestion de la configuration sont présents tout au long du processus.
Le modèle original ne comportait pas de possibilité de retour en arrière. Celle-ci a été rajoutée
ultérieurement sur la base qu'une étape ne remet en cause que l'étape précédente, ce qui, dans la pratique,
s'avère insuffisant.
Les développements récents de ce modèle font paraître de la validation-vérification à chaque étape :
● faisabilité et analyse des besoins : validation ;
● conception du produit et conception détaillée : vérification ;
● intégration : test d'intégration et test d'acceptation ;
● installation : test du système.


Modèle en V
Suivant : Modèle en spirale Précédent : Modèle de la cascade Père : Modèles du cycle de vie
Sous-sections
● Relations entre phases et activités selon le modèle en V
Modèle en V
Le principe de ce modèle est qu'avec toute décomposition doit être décrite la recomposition, et que toute
description d'un composant est accompagnée de tests qui permettront de s'assurer qu'il correspond à sa
description.
Ceci rend explicite la préparation des dernières phases (validation-vérification) par les premières
(construction du logiciel), et permet ainsi d'éviter un écueil bien connu de la spécification du logiciel :
énoncer une propriété qu'il est impossible de vérifier objectivement après la réalisation.
On distingue donc deux sortes de dépendances :
● enchaînement et itération : se déroulent essentiellement de gauche à droite.
● préparation des phases ultérieures. Par exemple à l'issue de la conception architecturale le

protocole et les jeux de test de l'intégration doivent être complètement décrits.
conséquences :
● obligation de concevoir les jeux de test et leurs résultats ;
● réflexion et retour sur la description en cours ;
● meilleure préparation de la branche droite du V.
Notons aussi que les activités de chaque phase peuvent être réparites en 5 catégories :
● assurance qualité ;
● production ;
● contrôle technique ;
● gestion ;
● contrôle de qualité.
Relations entre phases et activités selon le modèle en V

Le tableau 2.1 montrent la répartition des activités 2.1 selon les phases ainsi que les documents en entrées
et en sortie de chaque phase. Ces correspondances restent largement valables pour les (ou des partie des)

Modèle en V
modèles plus complexes : le modèle en spiralesec:modSpir et le modèle par incrémentssec:modIncr.
Tableau 2.1: Pahses, activités et production de documents selon le modèle en V.

Phase Activité Documents
Spécification Traduction des besoins en : Entrée : cahier des charges
- fonctionnalités ; Sortie :
- interfaces ; - Dossier de spécifications du logiciel
- performances ; - Manuels (installation/utilisation
- contraintes ;
- exigence qualité ;
Conception architecture globale : Entrée : Dossier de spécifications
générale - découpage en modules Sortie :
- communication inter-module - Dossier de conception générale
- échange de données - Dossier provisoire de tests/validation
- contrôle (qui appelle qui)
Conception - Conception de chaque module Entrée : DCG
détaillée - Décomposition de chaque Sortie :
module en fonctions simples - Dossier de conception détaillée
facilement testables - Dossier provisoire de tests unitaires
Codage - Traduction des traitements Entrée : DCD
en code Sortie :
- Production - listage du code
- Dossier des tests unitaires
Tests Test de chaque composant Entrée : DCD, DTU
unitaires Sortie :
- listage des composants testés
- Dossier des tests d'intégration
Intégration Assemblage progressif des Entrée : DCG, DTI

Modèle en V
composants Sortie :
- DTI complet
- listage des composants testés
- Dossier des tests de validation
Validation - Test du logiciel complet Entrée : DSL, DTV,
en fonctionnement opérationnel cahier des recettes
- Recette : tests faits par Sortie :
le commanditaire - DTV complet
- Vérification et gestion - Manuel d'utilisation
des modification et d'installation
- dossier définitif de livraison - Dossier de livraison


Modèle en spirale
Suivant : Modèles par incrément Précédent : Modèle en V Père : Modèles du cycle de vie
Sous-sections
● Risques majeurs du développement du logiciel
● Exemple : Console de contrôle de lumière
Modèle en spirale
Proposé par B. Boehm en 1988, ce modèle est beaucoup plus général que le précédent. Il met l'accent sur
l'activité d'analyse des risques : chaque cycle de la spirale se déroule en quatre phases :
1.
détermination, à partir des résultats des cycles précédents --ou de l'analyse préliminaire des
besoins, des objectifs du cycle, des alternatives pour les atteindre et des contraintes ;
2.
analyse des risques, évaluation des alternatives et, éventuellement maquettage ;
3.
développement et vérification de la solution retenue, un modèle « classique » (cascade ou en V)
peut être utilisé ici ;
4.
revue des résultats et vérification du cycle suivant.
L'analyse préliminaire est affinée au cours des premiers cycles. Le modèle utilise des maquettes
exploratoires pour guider la phase de conception du cycle suivant. Le dernier cycle se termine par un
processus de développement classique.
Ce modèle a été moins expérimenté que les deux précédents. Sa mise en uvre demande de grandes
compétences et devrait être limitée aux projets innovants à cause de l'importnace qu'il accorde à l'analyse
des risques. Néanmoins, ce dernier concept peut être appliqué aux autres modèles.
Risques majeurs du développement du logiciel

● défaillance du personnel ;
● calendrier et budget irréalistes ;
● développement de fonctions inappropriées ;
● développement d'interfaces utilisateurs inappropriées ;

Modèle en spirale
● produit « plaqué or » ;
● validité des besoins ;
● composants externes manquants ;
● tâches externes défaillantes ;
● problèmes de performance ;
● exigences démesurées par rapport à la technologie.
Exemple : Console de contrôle de lumière


Modèles par incrément
Suivant : Analyse et spécification du logiciel Précédent : Modèle en spirale Père : Modèles du cycle de
vie
Sous-sections
● Avantages
● Risques
● Exemple : Une extension pour une chaîne d'édition

Dans les modèles précédents un logiciel est décomposé en composants développés séparément et intégrés
à la fin du processus.
Dans les modèles par incrément un seul ensemble de composants est développé à la fois : des incréments
viennent s'intégrer à un noyau de logiciel développé au préalable. Chaque incrément est développé selon
l'un des modèles précédents.
Avantages
● chaque développement est moins complexe ;
● les intégrations sont progressives ;
● possibilité de livraisons et de mises en service après chaque incrément ;
● meilleur lissage du temps et de l'effort de développement à cause de la possibilité de recouvrement
des différentes phases.
Risques
● mettre en cause le noyau ou les incréments précédents ;
● ne pas pouvoir intégrer de nouveaux incréments.
Les noyau, les incréments ainsi que leurs interactions doivent donc être faites globalement, au début du
projet. Les incréments doivent être aussi indépendants que possibles, fonctionnellement mais aussi sur le
plan du calendrier du développement.

Exemple : Une extension pour une chaîne d'édition


Analyse et spécification du logiciel
Suivant : Techniques de spécification Précédent : Modèles par incrément Père : Modèles de

développement du logiciel
Analyse et spécification du logiciel

Objectif : répondre à l'évolution des matériels, des systèmes, des langages de programmation, et surtout
la complexité toujours croissantes des logiciels.
● Techniques de spécification
❍ Énonces informels
❍ Présentations formatées
❍ Techniques graphiques ou semi-formelles
❍ Techniques formelles


Techniques de spécification
Suivant : Conception du logiciel Précédent : Analyse et spécification du logiciel Père : Analyse et

spécification du logiciel
Sous-sections
● Énonces informels
● Présentations formatées
● Techniques graphiques ou semi-formelles
● Techniques formelles
Énonces informels
description en langage naturel pouvant respecter des plans types (standardisés ou propres à une entreprise
ou à un projet).
Risque de non-cohérence, d'ambiguïté, de non complétudes, de difficulté d'organisation et de redondance
d'informations.
Présentations formatées
Dictionnaire de données ou glossaire :
spécification de l'ensemble des données utilisées en analyse et en conception. Définition des
termes, sigles, codes, symboles, synonymes et alias. Peut utiliser des notations syntaxique strictes
de forme Backus-Naur. Peut contenir des infos sur les spécifications des données, les fichiers qui
les contiennent et les processus qui les utilisent.
Table de décision :
correspondance entre les valeurs d'entrée et les valeurs de sortie d'un processus (adaptée à la
définition des systèmes finis).
Table états-transitions :
table des états et, pour chaque état les événements qui provoquent la transition à un autre état, les
actions à effectuer et l'état suivant pour chaque transition. Peut être représentée par une matrice.

Techniques graphiques ou semi-formelles

Techniques relativement simples favorisant la communication. Représentation graphique formelle
accompagnée de textes informels
Modèle entité-association :
les objets du domaine (entités) sont identifié par des attributs et sont reliés par des liens dont on
peut préciser les limites du nombre (associations) d'occurences (cardianlité).
Diagrammes de flots de données :
montrent comment chaque processus transforme les données qu'il reçoit entrée pour générer celle
qu'il produit en sortie. Un DFD représente aussi les stockages de données accessibles par tout
processus. Il est souvent accompagné d'un diagramme de contexte qui représente les échanges
avec le monde extérieur
diagrammes de structures :
description du système sous forme de hiérarchie de fonctions. La notation permet d'exprimer les
appels de fonctions, les paramètres (entrées, sorties, contrôle), les structures itératives et
alternatives.
Diagrammes etats-transitions :
semblables (et complémentaires) aux tables états-transitions.
Réseaux de Petri et Grafcet :
un réseau de Petri est un outil mathématique très général permettant de modéliser le comportement
d'un système dynamique à des événements discrets.
Le Graphset, inspiré des réseaux de Petri, est un outil de spécification des automates logiques
fréquemment utilisé en automatique.
Techniques formelles
The virtues of a software technology developed on mathematical basis have been envisioned
as being capable of providing software that is (a) correct, and the correctness can be proved
mathematically, (b) safe, so that it can be used in the implementation of critical systems, (c)
portable, i.e., independent of computing platforms and language generations, and (d)
evolutionary, i.e., it is self-adaptable and evolves with the problem domain.
Call for papers, AMAST '2000, 20 May to 27 May 2000, Iowa City, Iowa, USA.


Conception du logiciel
Suivant : Méthodes d'analyse et de conception Précédent : Techniques de spécification Père : Modèles

de développement du logiciel
La conception est un processus créatif qui nécessite de l'expérience et un certain flair de la part du
programmeur [25].
L'objectif du processus de conception est de construire, à partir des spécification des besoins, obtenues
par la phase d'analyse une première conception informelle qu'il s'agit de traduire, par un processus de
raffinements successifs avec retour en arrière, en une conception formelle.
La continuité entre les différentes phases doit être garantie, mais uniquement du point de vue fonctionnel.
En particulier le découpage et l'architecture proposés par la conception peuvent être (et c'est très souvent
le cas) très différents de ceux de l'analyse/spécification.
● Méthodes d'analyse et de conception

● Méthodes fonctionnelles
❍ Analyse structurée
❍ Analyse « temps réel »
❍ Méthodes de conception fonctionnelle


Méthodes d'analyse et de conception
Suivant : Méthodes fonctionnelles Précédent : Conception du logiciel Père : Conception du logiciel
Méthodes d'analyse et de conception

Les méthodes d'analyse et de conception fournissent des notations standards et des conseils pratiques qui
permettent d'aboutir à des conceptions « raisonnables », mais on fera toujours appel à la créativité du
concepteur. Il existe différentes manières pour classer ces méthodes, dont :
● la distinction composition/décompostion2.2 : met en opposition d'une part les méthodes
ascendantes qui consistent à construire un logiciel par composition à partir de modules existants
et, d'autre part, les méthodes descendates qui décomposent récursivement le un système jusqu'à
arriver à des modules programmables « simplement ». ;
● la distinction fonctionnel (dirigée par le traitement)/orientée objet. Dans la stratégie fonctionnelle
un système est vu comme un ensemble d'unités en interaction, ayant chacune une fonction
clairement définie. Les fonction disposent d'un état local, mais le système a un état partagé, qui est
centralisé et accessible par l'ensemble des fonctions. Les stratégies orientées objet considèrent
qu'un système est un ensemble d'objets interagissants. Chaque objet dispose d'un ensemble
d'attributs décrivant son état et l'état du système est décrit (de façon décentralisé) par l'état de
l'ensemble 2.3.
Dans le reste du document, c'est cette dernière classification qui sera adoptée. D'abord nous présenterons
la méthode d'analyse structuraleSADTcha:SADT
Contrairement à la plupart des méthodes fonctionnelle, les méthodes orientée-objet sont à la fois des
méthodes d'analyse et de conception, ce qui fait que l'analyse orientée-objet n'est présentée qu'après les
deux chapitres suivants : la conception du logiceilcha:concLog et l'approche structuralecha:concFctl de
concpetion.
Le concept de l'approche orientée objetcha:approcheOO seront décrite brièvement avant de présenter de
manière détaillée une méthode d'analyse et de conception orientée-objetcha:OMT.


Méthodes fonctionnelles
Suivant : SADT: méthode d'analyse fonctionnelle et Précédent : Méthodes d'analyse et de conception

Père : Conception du logiciel
Sous-sections
● Analyse structurée
● Analyse « temps réel »

● Méthodes de conception fonctionnelle
Les méthodes fonctionnelles trouvent leur origine dans les langages procéduraux. Elles mettent en
évidence les fonctions à assurer et proposent une approche hiérarchique descendante et modulaire.
Ces méthodes utilisent intensivement les raffinements successifs pour produire des spécification dont
l'essentielle est sous forme de notation graphique en diagrammes de flots de données. Le plus haut niveau
représente l'ensemble du problème (sous frome d'activité, de données ou de processus, selon la méhtode).
Chaque niveau est ensuite décomposé en respectant les entrées/sorties du niveau supérieur. La
décompisition se poursuit jusqu'à arriver à des composants « maîtrisables ».
Analyse structurée
Dans la méthode d'Analyse Structurée le plus haut niveau est appelé diagramme de contexte. Une boîte
de DFD représente un processus et doit être décomposée. Chaque processus (ou traitement) non
décomposé est décrit par une « mini-spécification » ; un dictionnaire précise la définition des données,
processus et zones de stockage.
Par exemple la méthode SADTcha:SADT permet de produire un modèle du logiciel sous forme d'une
suite cohérente et hiérarchisée de diagrammes obtenues par raffinements successifs.
Analyse « temps réel »

L'analyse structurée n'étant pas suffisante pour exprimer les contraintes de temps et de synchronisation,
des extensions ont été apportées à cet effet :
● ajout des diagramme de flot de contrôle et spécifications de contrôle : information
d'activation/désactivation des processus ;
● utilisation des diagrammes états/transitions.

Méthodes de conception fonctionnelle

Parmi ces méthodes (qui couvrent parfois la phase d'anlyse aussi, nous pouvons compter les méhtodes
suivantes : RAPID/USE, JSD, MASCOT. Toutes ces méthodes proposent de modéliser le logiciel avec
toutes ou une partie des vues suivantes :
● flux de données : modélisation des transformations des données.
● entité-association (relation) : structure logique des données.
● vue structurée : documentation des composantes du système ainsi que leurs relations.


SADT: méthode d'analyse fonctionnelle et de gestion de projets
Suivant : Présentation générale Précédent : Méthodes fonctionnelles Père : Support de cours :

Introduction
SADT: méthode d'analyse fonctionnelle

et de gestion de projets
● Présentation générale
❍ Historique
● Le Modèle SADT
● La syntaxe des diagrammes SADT
❍ Actigrammes
❍ Datagrammes
■ Remarques
❍ Les textes explicatifs
❍ Les diagrammes pour explication seulement
❍ Liste hiérarchique et numérotation des diagrammes
❍ Glossaires
❍ Conditions d'activation
❍ Processus de liens
● Travail en équipe
❍ Cycle auteur/lecteur


Présentation générale
Suivant : Historique Précédent : SADT: méthode d'analyse fonctionnelle et Père : SADT: méthode
d'analyse fonctionnelle et
Présentation générale
● Historique


Historique
Suivant : Le Modèle SADT Précédent : Présentation générale Père : Présentation générale
Historique
● Développée à SOFTTECH (U.S.A.) en 1976 ;
● utilisée dans des projets industriels à ITT, THOMSON, AÉROSPATIALE etc.
● peut être utilisée pour décrire (spécifier) n'importe quel système (cf. 3.1.1) ;
● sert à définir des modèles de systèmes existants, idéaux, réalisables compte tenu des contraintes
d'un projet, etc.


Le Modèle SADT
Suivant : La syntaxe des diagrammes SADT Précédent : Historique Père : SADT: méthode d'analyse
fonctionnelle et
Le Modèle SADT
Un modèle SADT représente une image d'un système qu'on veut appréhender. La technique d'analyse
structurée identifie et organise les détails d'un tel système suivant une hiérarchie parfaitement référencée.
Un modèle SADT est composé de :
● Diagrammes d'activités ou actigrammes, représentant l'ensemble des activités du système.
● Diagrammes de données ou datagrammes, montrant l'ensemble des données du système.
● Textes explicatifs sur les diagrammes.
● Diagrammes Pour Explication Seulement (PES).
● Schéma de la hiérarchie du système analysé.
● Glossaire définissant les principaux termes employés.
● Conditions d'activation.


La syntaxe des diagrammes SADT
Suivant : Actigrammes Précédent : Le Modèle SADT Père : SADT: méthode d'analyse fonctionnelle et
La syntaxe des diagrammes SADT
● Actigrammes
● Datagrammes
❍ Remarques
● Les textes explicatifs
● Les diagrammes pour explication seulement
● Liste hiérarchique et numérotation des diagrammes
● Glossaires
● Conditions d'activation
● Processus de liens


Actigrammes
Suivant : Datagrammes Précédent : La syntaxe des diagrammes SADT Père : La syntaxe des
diagrammes SADT
Actigrammes
Un actigramme est identifié par un verbe d'action, il gère des données désignés par des noms à partir de
directives de contrôle (désignés par des noms aussi) en s'appuyant sur les potentialités des
mécanismes. Il génère des données en sortie par création ou par modifications des données en entrée.
Les données de contrôle ne sont pas modifiées par l'activité mais influent sur son déroulement (ex. choix
de l'utilisateur dans un menu).
Les mécanismes, ou supports, de l'activité désignent le « comment » de la réalisation de l'activité. Ils
peuvent aussi représenter « qui » la réalise. Les mécanismes peuvent être développés par des modèles
SADT indépendants.


Datagrammes
Suivant : Les textes explicatifs Précédent : Actigrammes Père : La syntaxe des diagrammes SADT
Sous-sections
● Remarques
Datagrammes
Un datagramme représente des données créées par des activités Génératrices (en entrée) et consommées
par des activités Utilisatrices (en sortie), sous le contrôle d'activité de contrôle.
Pour une données, les mécanismes expriment le support de stockage (physique ou logique) de la donnée.
Remarques
● On peut associer un Label de propriété, représentant une information nécessaire courte, à une boîte
(Activité ou donnée).
● Une flèche véhicule une classe de données (ou d'activités) et non pas une seule donnée ou activité.
Son label doit décrire de façon précise et concise l'information véhiculée.
● Contrairement aux organigrammes, les flèches ne représentent ni les commandes ni leurs
séquencement. Elles montrent uniquement les contraintes : ce dont une boîte a besoin pour
fonctionner.
● Lorsqu'il y a réciprocité dans les interfaces entre deux boîtes, on peut remplacer les deux flèches
par une flèche à double sens. Il faut dans ce cas placer un point à droite ou en dessous de chaque
extrémité de la flèche. L'étiquette peut être simple si l'information est la même dans les deux sens,
ou double, avec les deux parties séparée par une barre dans le cas contraire.
● Une flèche peut reboucler pour indiquer la mise à jour d'une donnée.
● Dans le cas général, toutes les flèches présentes sur une boîtes doivent paraître sur la feuille fille
(diagramme fils, détaillant la boîte). Pour éviter toute ambiguïté, ces flèches doivent être
numérotées avec les codes MECS accompagnés d'un numéro d'identification.
● Cependant, une information peut être implicitement présente pour tous les fils, ou, dans un fils,
être trop détaillée pour paraître dans le père. Dans ce cas on utilise une notation paranthésée pour
le label de la flèche qui la représente.

Datagrammes

Les textes explicatifs
Suivant : Les diagrammes pour explication seulement Précédent : Datagrammes Père : La syntaxe des
diagrammes SADT
Les textes explicatifs

Ils accompagnent les diagramme pour présenter brièvement des généralités sur le diagramme et les faits
auxquels l'auteur accorde un intérêt particulier, sans toute fois dupliquer l'information présentée par le
diagramme lui-même. Ce texte doit être écrit uniquement lorsque le diagramme aura atteint son niveau
d'approbation, permettant ainsi de vérifier la lisibilité du diagramme lors du cycle écriture/lecture. Le
texte explicatif du niveau global doit présenter les faits qui s'appliquent à l'ensemble du modèle,
fournissant ainsi une description globale du système.


Les diagrammes pour explication seulement
Suivant : Liste hiérarchique et numérotation des Précédent : Les textes explicatifs Père : La syntaxe des
diagrammes SADT
Les diagrammes pour explication seulement

Ils ne font pas vraiment partie du modèle. Il illustrent ou clarifient un aspect particulier du système. IL
est par exemple utile de produire une copie simplifiée des schémas complexes.


Liste hiérarchique et numérotation des diagrammes
Suivant : Glossaires Précédent : Les diagrammes pour explication seulement Père : La syntaxe des
diagrammes SADT
Liste hiérarchique et numérotation des diagrammes

Les nuds d'un modèle SADT sont numérotés d'une façon précise. Le premier nud représente le système
global. Il porte le numéro particulier A-0 (resp. D-0) pour le modèle des actigrammes (resp.
datagrammes). Il sera décomposé sur la feuille A0 (resp. D0) en plusieurs nuds portant les numéros A1,
A2 ...An (resp D1, D2, ...Dn), décomposés à leur tours en A11, A12 etc.
Les pages de textes et de glossaires sont numérotées de manière identique avec les lettres G et T
respectivement.


Glossaires
Suivant : Conditions d'activation Précédent : Liste hiérarchique et numérotation des Père : La syntaxe
des diagrammes SADT
Glossaires
L'utilisation de glossaires améliore la lisibilité des diagrammes et permet d'utiliser des labels court et
précis pour les flèches et les boîtes.


Conditions d'activation
Suivant : Processus de liens Précédent : Glossaires Père : La syntaxe des diagrammes SADT
Conditions d'activation
Dans les actigrammes permettent de spécifier dans quelles circonstances une boîte sera activée et ce
qu'elle produira.


Processus de liens
Suivant : Travail en équipe Précédent : Conditions d'activation Père : La syntaxe des diagrammes
SADT
Processus de liens


Travail en équipe
Suivant : Cycle auteur/lecteur Précédent : Processus de liens Père : SADT: méthode d'analyse
fonctionnelle et
Travail en équipe
À la fin de chaque phase le chef de projet convoque l'équipe pour une revue au cours de laquelle
s'effectue une analyse critique permettant de s'assurer que les éléments de décision pour le passage à la
phase suivante sont acquis.
● Cycle auteur/lecteur


Cycle auteur/lecteur
Suivant : Conception du logiciel Précédent : Travail en équipe Père : Travail en équipe
Cycle auteur/lecteur
Chaque membre de l'équipe est appelé auteur lorsqu'il produit de la documaentation (une partie du
modèle SADT). Tout document produit doit être revu par au moins un autre membre de l'équipe pour
compléter les points de vue, corriger les erreurs, etc. L'auteur propose son document à la relecture par
d'autres membres de l'équipe (les lecteurs. Le document peut circuler plusieurs fois entre l'auteur et
chacun des lecteurs avant de trouver une solution satisafaisante. Tout échange de document doit se faire
par l'intermédiaire du biliothécaire qui enregistre toutes les informations nécessaires afin de garder trace
de tous les documents et de pouvoir bien gérer les différentes versions.


Suivant : Qualité de la conception Précédent : Cycle auteur/lecteur Père : Support de cours :

Introduction
● Qualité de la conception
❍ Modularité
■ Principes de Modularité
■ Principe d'ouverture/fermeture
❍ Critères de qualité de la conception
■ Cohésion
■ Couplage
■ Compréhensibilité
■ Adaptabilité
❍ Processus de conception de logiciel
■ La description de la conception


Qualité de la conception
Suivant : Modularité Précédent : Conception du logiciel Père : Conception du logiciel
Qualité de la conception
Une « bonne » conception se définit en termes de la satisfaction des besoins et des spécifications : les
critères de qualités peuvent donc varier énormément d'un système à un autre ou même pour deux
implantation différentes d'un même système (cf. 1.2).
Par la suite on considérera de préférence les facteurs qui facilitent la gestion du produit tout le long de
son cycle de vie. Il s'agit essentiellement de l'extensibilité, la réutilisabilité, la compatibilité, la portabilité
la vérifiabilité et la facilité d'emploi.
Une bonne structuration participe largement à la production d'un logiciel qui possède ces caractéristiques.
Comme dans beaucoup de domaine, cette bonne structuration se base sur la Modularité.
● Modularité
❍ Principes de Modularité
❍ Principe d'ouverture/fermeture
● Critères de qualité de la conception
❍ Cohésion
❍ Couplage
❍ Compréhensibilité
❍ Adaptabilité
● Processus de conception de logiciel
❍ La description de la conception


Modularité
Suivant : Critères de qualité de la Précédent : Qualité de la conception Père : Qualité de la conception
Sous-sections
● Principes de Modularité
● Principe d'ouverture/fermeture
Modularité
Un module est un élément de petite taille (en général un ou quelques sous-programmes) qui sert, par
assemblage à la construction de logiciels. Un module doit être cohérent et autonome. Un ensemble de
modules (un logiciel ou un assemblage de modules) doit être bien organisé en architecture robuste.
La modularité se fait ressentir dans la conception et dans la programmation, d'où on peut parler de deux
sortes de modules : modules de conception et modules de programmation.
Principes de Modularité
Un module rend des « services » (ex. printf, perror) ou effectue des traitements (ex. scanf, strcpy, atoi).
Pour exploiter un module dans un logiciel, il est nécessaire (et suffisant) d'avoir une description précise
de ce qu'il fait, ce qui, dans la pratique se traduit par le passage d'information à travers son interface. De
ce point de vue, on peut dire qu'un module est défini par son interface. D'où les principes de la
modularité [20] (cf exemple) :
● Interfaces explicites : chaque fois que deux modules A et B communiquent, cela doit ressortir
clairement du texte de A, de B ou des deux.
● Petites interfaces (couplage faible) : si deux modules communiquent, ils doivent échanger aussi
peu d'informations que possible.
● Masquage de l'information : seules les informations qui servent à la communication avec d'autres
modules doivent être publiques (visibles de l'extérieur du module).
● Peu d'interfaces : un module doit communiquer avec aussi peu d'autres que possible.
● Unités linguistiques modulaires : les modules doivent correspondre à des unités syntaxiques du
langage.
remarque : la modularité n'implique pas automatiquement la réutilisabilité (qui ne sera pas abordée ici)
dans tous les cas.

Modularité
Principe d'ouverture/fermeture
Un module est dit :
● ouvert : s'il est encore disponible pour des extensions/modifications ;
● fermé : s'il est prêt à être utilisé par d'autres modules ce qui suppose qu'il est stable.
Ces deux principes sont souvent contradictoires. Les langages à objets proposent une solution avec
l'héritage. Dans le cas général il faut garder une trace précise des dépendances entre les modules pour
savoir quels sont les modules « clients » à rouvrir suite à une modification sur un module donné.


Critères de qualité de la conception
Suivant : Processus de conception de logiciel Précédent : Modularité Père : Qualité de la conception
Sous-sections
● Cohésion
● Couplage
● Compréhensibilité
● Adaptabilité

Cohésion
Une composante (module) doit implanter une seule entité logique. Toutes les parties de cette composante
doivent contribuer à cette implantation. Ainsi dans un système (logiciel) chaque composante résout une
partie du problème. La modification d'une telle partie peut être faite sans modifier l'ensemble.
On peut distinguer plusieurs degrés de cohésion, (du plus faible au plus fort) : l'association logique,
cohésion temporelle, cohésion procédurale, cohésion de communication, cohésion séquentielle et
cohésion fonctionnelle, auxquels on peut ajouter la cohésion objet propre à l'approche orientée objet.
Couplage
Le couplage est relatif à la cohésion : il exprime le degré d'interconnexion des différents composants d'un
système. Un couplage fort (partage de données, échange d'informations de contrôle, codage en dur des
paramètres du système, etc.) implique des difficultés d'entretien.
Compréhensibilité
La compréhensibilité d'un module dépend de :
● sa cohésion ;
● l'appellation : utilisation de noms significatifs ;
● la documentation : établir un lien entre le monde réel et le composant ;

(parenthèse : documentation d'un projet C/Unix).
● la complexité (une composante complexe nécessite un effort de documentation supplémentaire).

Adaptabilité
L'adaptabilité dépend du couplage et de la documentation. Une conception ou un logiciel adaptable doit
avoir un haut degré de lisibilité : fournir plusieurs représentations, cohérentes avec l'implantation, à
différents niveaux d'abstraction. Les modification doivent être faciles à incorporer sur tous les niveaux
pour ne pas avoir des problèmes d'incohérence.


Processus de conception de logiciel
Suivant : Conception fonctionnelle Précédent : Critères de qualité de la Père : Qualité de la conception
Sous-sections
● La description de la conception

La conception d'un logiciel peut être effectuée par un processus de résolution de problème qui, à partir
d'une conception initiale, identifie des abstractions de plus en plus raffinées. Le processus se répète
jusqu'à ce que l'on soit en mesure de préparer une spécification de la conception de chaque abstraction. À
chaque itération de ce processus il faut effectuer les étapes suivantes :
● Étude et compréhension du problème (analyse et spécifications) : examiner le problème sous
différents angles.
● Identifier les caractéristiques d'au moins une solution possible. Il est souvent utile (et parfois
indispensable) d'évaluer plusieurs solutions.
● Décrire toutes les abstractions utilisées dans la solution. Il est conseillé de créer et de mettre au
point une description informelle de la conception, ce qui permet de corriger les erreurs de haut
niveau avant de commencer la documentation de la conception.
Comme le montre la figure 4.1, on peut raffiner description donnée précédemment (cf. 2.3) du processus
de conception comme suit :
● Conception de l'architecture : identifier les sous-systèmes et leurs relations.
● Spécification abstraite : pour chaque sous-système produire une spécification abstraite des services
qu'il offre et des contraintes auxquelles il est soumis.
● Conception de l'interface : pour chaque sous-système, concevoir et documenter (de manière claire)
l'interface avec les autres sous-systèmes.
● Conception des composants de chaque sous-système.
● Conception détaillée des structures de données.
● Conception détaillée des algorithme.
La conception doit représenter le système à plusieurs niveaux d'abstraction. Chaque activité de

conception doit produire une spécification formelle correspondante au niveau d'abstraction, ces
spécifications seront donc de plus en plus détaillées et doivent aboutir à la spécification des algorithmes
et des structures de données permettant l'implantation du système. Mais, malgré l'apparance séquentielle
de ce processus, il n'est pas rare d'entamer une nouvelle phase de conception avant la fin de la précédente
pour avoir des retours d'information.

Figure: Activités et produits de la conceptions [25]
La description de la conception
Une conception est utilisée de différentes manières :
● pour produire des implantations ;
● comme moyen de communication entre les concepteurs de différents sous-systèmes ;
● comme référence pour l'entretien du système.
● ...
Dans la pratique la conception du sytème produit une description (un modèle) du système qui sous forme
de spécifications formalisées avec des techniques d'analysesec:techSpecif, des descriptions en langage
naturel ou en langage de description de programmes (pseudo-langage)4.1.
Le choix des techniques utlisées dépend de la méthode de conception et de l'adéquation de la technique
aux besoins précis (image d'ensemble, description d'algorithmes et de structures de données, etc.)


Conception fonctionnelle
Suivant : Les diagrammes de flux de Précédent : Processus de conception de logiciel Père : Support de
cours : Introduction
Conception fonctionnelle
On a dit que cette stratégie était obsolète et qu'elle devait être remplacée par l'approche orientée objet,
mais il existe beaucoup de standards, méthodes, CASE (ou AGL) et systèmes développés selon cette
approche.
On résume ici la présentation faite par I. Sommerville [25] de variante de cette approche développée par
Constantine et Yourdon sous le nom de la conception structurée. Elle utilise trois types de documents :
● diagramme de flux de données ;
● diagrammes de structure du logiciel ;
● Description détaillée en LDP.
Pour minimiser les effets que peut avoir une modification imprévue de l'état du système par une fonction,
il faut minimiser la description de l'état du système et rendre explicite le partage des informations (ex.
déclaration extern en C). Cette approche est naturelle lorsque l'état du système ne dépend que d'une
entrée. Dans ce cas-là une conception orientée objet n'en différerait que par la syntaxe. (ex. Distributeur
Automatiques de Billets, cf. transparent--à faire).
● Les diagrammes de flux de données

● Les diagrammes de structure


Les diagrammes de flux de données
Suivant : Les diagrammes de structure Précédent : Conception fonctionnelle Père : Conception

fonctionnelle
Les diagrammes de flux de données

Les diagrammes de flux de données montrent les transformations sur les données sans faire d'hypothèse
sur la manière dont elles seront réalisées. En particulier, comme les diagrammes SADT, ils ne doivent
pas contenir d'information de séquencement, mais bien préciser les transformations fonctionnelles qui
s'opèrent sur les données d'entrée pour générer des données de sortie.
La production des DFD doit être le premier stade de la conception. Il existe plusieurs notations très
semblables (du style SADT) dont celle utilisée dans la figure 5.1.
Figure 5.1: Exemple de diagramme de flux de

données. Système de Recherche d'Informations
Professionnelles.


Les diagrammes de structure
Suivant : Approche orientée objet Précédent : Les diagrammes de flux de Père : Conception
fonctionnelle
Les diagrammes de structure

Les diagrammes de structure servent à décrire visuellement l'organisation d'un système. Ils montrent
comment réaliser les éléments d'un diagramme de flux de données à l'aide d'une hiérarchie d'unités de
programmation. Ils peuvent contenir des informations de contrôle (sélections, boucles, etc.), mais il est
préférable de décrire ceux-ci à l'aide d'un Langage de Description de Conception (ou de Programme).
Dans ce cas les diagrammes de structure décrivent l'aspect statique du système uniquement.


Approche orientée objet
Suivant : Première définition Précédent : Les diagrammes de structure Père : Support de cours :
Introduction
Approche orientée objet

L'essence du développement orientée objet est l'identification et l'organisation des concepts du domaine
d'application, plutôt que leur représentation terminale dans un langage de progrrammation qu'il soit
orienté objet ou non. Ce processus est une manière de penser et non pas une technique de
programmation, entre autres il est indépendant des langages de programmation jusqu'aux stades ultimes.
Il se concentre sur la modélisation (cf 1.3 et non pas sur la l'implantation des concepts, ce qui permet de
bien comprendre et organiser les concepts inhérents à l'application avant de chercher une implantation
efficace des structures de données et des algorithmes. Aussi, en plus de préparer la programmation, la
modélisation peut servir de support pour la documentation et l'interface avec le client.
Dans ce qui suit nous survelerons quelques concepts de base de l'approche orientée objet avant de
préciser ce que nous entendons par la modélisation et comment s'en servir dans le processus de
développement.
● Première définition
● Caratéristiques des objets
❍ Identité : notion d'objet
❍ Classification : notion de classe
■ Attributs
■ Opérations et méthodes
❍ Polymorphisme : notion de surcharge
❍ Héritage : notion de paratge


Première définition
Suivant : Caratéristiques des objets Précédent : Approche orientée objet Père : Approche orientée objet
Première définition
L'approche orientée objet considère le logiciel comme une collection d'objets dissociés définis par des
propriété. Une propriété est soit un attribut : une entité élementaire (donnée) de la description de l'état
de l'objet, ou une opération : entité élemntaire de la description du comportement de l'objet. Un objet
comprend donc à la fois une structure de données (son état sous forme de collection d'attributs) et une
collection d'opérations (son comportement).
Cette défintion permet de déterminer un certain nombre de caractéristiques pour qu'une approche soit dite
orientée objet. Parmi les caractéristiques considérées par les différents génie-logiciens nous retenons les
suivantes : l'identité, la classification, le polymorphisme et l'héritage.


Caratéristiques des objets
Suivant : Identité : notion d'objet Précédent : Première définition Père : Approche orientée objet
● Identité : notion d'objet

● Classification : notion de classe
❍ Attributs
❍ Opérations et méthodes
● Polymorphisme : notion de surcharge
● Héritage : notion de paratge


Identité : notion d'objet
Suivant : Classification : notion de classe Précédent : Caratéristiques des objets Père : Caratéristiques
des objets

Un objet est un concept, une abstraction ou une chose ayant des limites très claires et un sens bien précis
dans le contexte du problème étudié.
Le principe de l'identité stipule qu'un objet est une entité discrète et distincte. Un objet se distingue
même des autres objets ayant les mêmes caractéristiques : deux pommes de la même couleur, du même
poids et de la même taille sont deux objets distincts. Deux véhicule de la même marque, de la même série
et ayant exactement les mêmes options sont aussi deux objets disticts.
Un objet peut être concret tel un fichier, un paragraphe dans un document, un véhicule
donné, un pneu ou le moteur de ce véhicule, ou conceptuel tel une politique
d'ordonnancement ou les perforformances du véhicule. Dans tous les cas un objet possède sa
propre identité, mais, contrairement au monde réel, dans un langage de programmation il est nécessaire
de diposer d'une clé (adresse, indice dans un tableau ou valeur unique d'un attribut) pour pouvoir
référencer un objet sans ambiguïté. Pour permettre la manipulation de collections d'objet les références
sur les objets doivent être uniformes et indépendants des contenus (des caractéristiques) des objets. Par
exemple, sous UNIX la notion générale dede fichier regroupe les fichiers ordinaires, les répertoires, les
périphériques, les tubes, etc. ce qui permet d'effectuer les mêmes opérations sur ces divers objets : les
contenus d'un fichier ordinaires peuvent par exemple être copiés dans un autre fichier, à l'écran ou sur
une imprimante.
La définition d'objet s'appuie largement sur les principes d'abstraction et d'encapsulation.
L'abstraction siginife que l'on se concentre sur ce qu'est un objet et ce qu'il fait en mettant l'accent sur
ses propriétés essentielles, inhérentes (dans le domaine d'application), et en ignorant les propriété
accidentelles (ce qui relève des détails d'implanation).
L'encapsulation (ou le masquage de données) signifie la séparation entre les propriétés externs, visibles
des autres objets, et les aspects internes, propres aux choix d'implantation d'un objet. Elle peremt de
modifier, redéfinir ou même remplacer un objet par un autre sans avoir à faire des modifications sur les
objets qui communique avec lui. Le regroupement de l'état et du comportement simplifient largement
l'application de ce principe.
Par exemple, du point de vue extérieur un rectangle peut être défini par ses quatre coins, mais
intérieurement, pour optimiser la taille des données il suffit de le définir en termes de ses coins bas
gauche et haut droit. Une autre implantation peut préférere optimiser les opérations et choisir de définir
les quatre coins dans l'état (interne) du rectangle. Dans le monde réel, malgré la grande variété et les

énormes différences des mise en vre spécifiques, la pédale d'accélération est la même pour tous les
véhicules.


Classification : notion de classe
Suivant : Polymorphisme : notion de surcharge Précédent : Identité : notion d'objet Père :

Sous-sections
● Attributs
● Opérations et méthodes

La classification signifie le regroupement d'objets de même nature (mêmes description d'état, même
comportement) dans une classe. Par exemple Fichier (resp. Paragraphe, resp. Véhicule) est la
classe de tous les fichiers (resp. paragraphes, resp. véhicules).
Une classe est une abstraction qui décrit un ensemble potentiellement infini d'objets individuels
caractérisés par des propriétés similaires. Chaque objet membre de l'ensemble est dit instance de la
classe.
Attributs
Un attribut est données définie par un nom unique pour une classe (mais deux attributs de deux classes
différents peuvent avoir le même nom) et par une valeur pour chaque instance d'objet de de la classe.
L'ensemble des attributs définit l'état de la classe. Dans la modélisation objet, contrairement aux usages
courants en bases de données par exemple et conformément au principe de l'identité, un identificateur
d'objet n'est pas nécessaire et ne doit pas faire partie des attributs de l'objet. Un tel identificateur est un
détail interne (d'implantation) et ne doit pas être confondu avec des attributs permettant d'identifier un
objet de manière unique mais ayant un sens dans le monde réel, tel que le numéro de sécutrité social ou
le numéro d'immatriculation.
Opérations et méthodes
Une opération est une action ou une transforamtion qu'un objet peut effectuer ou subir. L'ensemble des
opérations définit le comportement de l'objet.
Une opération est une abstraction définie par sa signature : le nom de l'opération, le type de valeur de
retour et le nombre et les types de ses arguments. Concrètement une opération peut être implantée de
manières différentes dans différentes classes. Une telle implantation est appelée méthode. Une opération
a un objet cible comme argument implicite permettant ainis d'identifier la méthode à appeler (cf 6.2.3).



Polymorphisme : notion de surcharge
Suivant : Héritage : notion de paratge Précédent : Classification : notion de classe Père :

Polymorphisme : notion de surcharge

Le polymorphisme signifie qu'un même opération peut se comporter différemment sur différents
classes. L'opération déplacer agira de manières différentes sur un fichier, une fenêtre
graphique ou un véhicule.
Le polymorphisme signifie que les différentes méthodes d'une opération ont la même signature. Lorsque
une opération est invoquée sur un objet, celui-ci « connaît » sa classe et par conséquent est capbale
d'invoquer automatiquement la méthode correspondante. Pour qu'une nouvelle classe supporte une
opération existante il lui suffit de fournir la méthode correspondante sans avoir à se soucier des autres
méthodes déjà définies.


Héritage : notion de paratge
Suivant : OMT : méthode d'analyse et Précédent : Polymorphisme : notion de surcharge Père :

Héritage : notion de paratge

L'héritage permet un partage hiérarchique des propriétés (attributs et opérations). Une sous-classe (ou
classe fille peut incorporer, ou hériter, des proporiétés d'une super-classe (ou classe mère).
Généralement une super-classe définit les grands traits d'une abstraction, une sous-classe hérite de cette
définition et peut la modifier, raffiner et/ou rajouter ses propres propriétés. Par exemple une classe
Rectangle peut être définie comme suit :
Une fenêtre est un rectangle, mais qui, en plus, a ses propres propriétés. La classe Fenêtre peut s'écrire
:
Puisque la classe Fenêtre est une sous-classe de Rectangle, elle hérite de ses propriétés, celles-ci
n'ont pas besoin d'être redéfinies explicitement. Par contre une fenêtre a ses propres propriétés telles que
la largeur-du-bord ou l'opération fermer. Elle peut aussi redéfinir les propriétés de sa classe
mère en s'appuyant éventuellement sur les définition d'origine. Par exemple pour dessiner une fênetre il
faut dessiner le rectangle et le bord.
De la même manière une voiture ou une moto peut être définie en terme d'une super-classe Véhicule.


OMT : méthode d'analyse et de conception orientée objet
Suivant : Introduction Précédent : Héritage : notion de paratge Père : Support de cours : Introduction
OMT : méthode d'analyse et de

conception orientée objet
● Introduction
● Analyse
❍ Modèle objet
■ Identification des objets
■ Sélection des classes pertinentes
■ Préparation d'un dictionnaire de données
■ Identification des associations
■ Sélection des bonnes associations
■ Identification des attributs
■ Sélection des attributs
■ Affinage en utilisant l'héritage
■ Vérification des chemins d'accès
■ Itération de la modélisation objet
■ Groupement des classes en modules
❍ Modèle dynamique
■ Préparation des scénarios
■ Format d'interface
■ Identification des événements
■ Construction des diagrammes d'états
■ Vérification de la correspondance des événements entre les objets
❍ Modèle fonctionnel

■ Identification des valeurs d'entrée et de sortie

■ Construction du diagramme à flot de données
■ Description des fonctions
■ Identification des contraintes entre objets
■ Spécification des critères d'optimisation
❍ Ajouter les opérations
■ Les opérations du modèle objet
■ Les opérations des événements
■ Les opérations des activités et des actions entre les états
■ Les opérations des fonctions
■ Les opérations « pense-bête » (shopping-list)
■ Simplification des opérations
❍ Itération de l'analyse
■ Affiner le modèle d'analyse
■ Reformuler les besoins
● Conception du système
❍ Introduction
❍ Décomposer le système
❍ Couches
❍ Partitions
❍ Topologie du système
● Identification des ressources
❍ Concurrences intrinsèques
❍ Tâches concurrentes
● Allocation des sous-systèmes aux processeurs/tâches
● Réservoires de données
● Partage des ressources globales
● Logiciel de contrôle
● Conditions limites
● Compromis de priorités
● Architectures type
❍ Transformation par lots (Pipeline)
■ Principe

■ Exemples
■ Importance relative des modèles
■ Étapes de la conception
❍ Transformation continue
■ Principe
■ Exemples
❍ Interface interactive
■ Principe
■ Exemples
❍ Simulation dynamique
■ Principe
■ Exemples
❍ Systémes temps réel
■ Principe
■ Exemples
❍ Gestionnaire de transactions
■ Principe
■ Exemples
● Conception des objets


Introduction
Suivant : Analyse Précédent : OMT : méthode d'analyse et Père : OMT : méthode d'analyse et
Introduction
La Méthode OMT [23] suit les étapes suivantes :
Analyse
: décrire le but du système et non pas la façon dont il sera réalisé. Il ne faut prendre aucune
décision d'implantation (7.2) ;
Conception système
: définit le découpage du système en sous-systèmes, à partir des résultats de l'analyse et dans
l'objectif de définir le choix de l'architecture (7.3) ;
Conception des objets
: raffiner les structures de données et les algorithmes en y ajoutant les détails d'implantation et en
tenant compte de l'environnement (7.12) ;
La différence avec l'approche fonctionnelle réside dans le fait que l'on utilise des objets qui appartiennent
au domaine de l'application plutôt que des fonctionnalités, ce qui garantit une meilleure évolution du
système.
La méthode sera présentée à l'aide d'un exemple, dont l'énoncé, schématisé par la figure 7.1, peut être
résumé comme suit :
Concevoir un logiciel de gestion d'un réseau de guichets automatiques bancaires (GAB). Le
système doit permettre de gérer les transactions des clients qui portent sur des comptes
apprtenant à plusieurs banques. Chaque banque dispose d'un ordinateur, l'ensemble des
banques est géré par un consortium qui dispose aussi de son propre ordinateur. Tous les
ordinateurs sont reliés par un réseau inforamtique. Les clients doivent pouvoir effectuer
leurs transactions à partir d'un guichet automatique par l'intermédiaire d'un agent caissier.
Figure: Réseau de guichets automatiques bancaires

(GAB)

Introduction


Analyse
Suivant : Modèle objet Précédent : Introduction Père : OMT : méthode d'analyse et
Analyse
Cette phase consiste à produire un modèle représenté sous trois aspects :
● Modèle objet
❍ Identification des objets
❍ Sélection des classes pertinentes
❍ Préparation d'un dictionnaire de données
❍ Identification des associations
❍ Sélection des bonnes associations
❍ Identification des attributs
❍ Sélection des attributs
❍ Affinage en utilisant l'héritage
■ La généralisation
■ La spécialisation
■ Remarque
■ Étude des figures 7.9 et 7.10
❍ Vérification des chemins d'accès
❍ Itération de la modélisation objet
■ Détection de manque d'objets
■ Indices
❍ Groupement des classes en modules
■ Exemple
● Modèle dynamique
❍ Préparation des scénarios

Analyse
❍ Format d'interface
❍ Identification des événements
■ Exemple
❍ Construction des diagrammes d'états
❍ Vérification de la correspondance des événements entre les objets
● Modèle fonctionnel
❍ Identification des valeurs d'entrée et de sortie
❍ Construction du diagramme à flot de données
❍ Description des fonctions
❍ Identification des contraintes entre objets
❍ Spécification des critères d'optimisation
● Ajouter les opérations
❍ Les opérations du modèle objet
❍ Les opérations des événements
❍ Les opérations des activités et des actions entre les états
❍ Les opérations des fonctions
❍ Les opérations « pense-bête » (shopping-list)
❍ Simplification des opérations
● Itération de l'analyse
❍ Affiner le modèle d'analyse
❍ Reformuler les besoins


Modèle objet
Suivant : Modèle dynamique Précédent : Analyse Père : Analyse
Sous-sections
● Identification des objets
● Sélection des classes pertinentes

● Préparation d'un dictionnaire de données
● Identification des associations
● Sélection des bonnes associations
● Identification des attributs
● Sélection des attributs
● Affinage en utilisant l'héritage
❍ La généralisation
❍ La spécialisation
❍ Remarque
❍ Étude des figures 7.9 et 7.10
● Vérification des chemins d'accès
● Itération de la modélisation objet
❍ Détection de manque d'objets
❍ Indices
● Groupement des classes en modules
❍ Exemple
Modèle objet
Le modèle objet comporte la description des objets, leurs attributs et les association qui les relient. La
démarche consiste à identifier les objets, leurs associations et leurs attributs, puis raffiner de différentes
manières pour obtenir un diagramme d'objets.

Modèle objet
Identification des objets

Pour commencer on énumère toutes les classes susceptibles d'exister, sans se soucier de leur organisation
ni de l'héritage, comme l'illustre schématiquement la figure 7.2.
Figure 7.2: Identification des classes d'objets
Pour ce faire on se réfère à l'énoncé du problème (ou le cahier des charges) (fig. 7.3) et on exploite nos
connaissances sur le domaine de l'application (fig. 7.4).
Figure 7.3: Classes du GAB déduites de la

description du problème
Figure 7.4: Classes du GAB déduites de la

connaissance du domaine du problème
Sélection des classes pertinentes

Certaines classes peuvent être éliminées, on peut les classer dans différentes catégories (fig. 7.5) :

Modèle objet
Figure 7.5: Élimination des classes inutiles du

problème du GAB
Préparation d'un dictionnaire de données

Décrire, dans un dictionnaire de données, les classes obtenues dans l'étape précédente, cf. figure 7.6.
Figure 7.6: Dictionnaires de données pour les

classes du GAB
Identification des associations

Une association est une relation de dépendance entre classes. Il vaut mieux utiliser les associations plutôt
que les attributs lorsque possible, car il existe différentes manières (dont les attributs) pour implanter une
association.
ex : employeur comme attribut de personne peut s'exprimer comme l'association travaille
pour entre une personne et une société (cf. fig. 7.7).
Figure 7.7: Associations déduites de la description

du problème du GAB

Modèle objet
Sélection des bonnes associations

Supprimer les associations dans les cas suivants :
À la fin de cette phase on obtient le diagramme d'objets initial (fig. 7.8).
Figure 7.8: Diagramme d'objets initial pour le

système GAB
Identification des attributs

Les attributs sont identifiables dans les phrases où le un nom est suivi d'une expression de possession,
l'adjectif dans cette expression est la valeur de l'attribut : la voiture a la couleur rouge.
Pour retenir les attributs pertinents uniquement il faut :
Sélection des attributs

Certains attributs inutiles doivent être éliminés selon les critères suivants :
L'application de ces critères au système GAB, qui n'est qu'un exemple et non pas une application réelle,
donne les observations suivantes :
Figure 7.9: Modèle objets d'un GAB avec attributs

Modèle objet
Affinage en utilisant l'héritage

L'héritage sert à partager les ressources communes, il peut être établi par deux méthodes :
généralisation
qui consiste à regrouper les aspects communs dans une super-classe (approche de bas en haut) ; et
spécialisation
qui s'obtient par l'affinement des classes en sous-classes (approche de haut en bas)
La généralisation
C'est le regroupement des attributs, associations et opérations communs dans une super-classe. Par
exemple, transaction peut être une super-classe de transaction caissier et
transaction distante, par contre ordinateur central et ordinateur de banque
n'ont pas grand-chose en commun et la création d'une super-classe. Il peut s'avérer nécessaire de redéfinir
les classes mais il ne faut pas forcer ; les suggestions de généralisation doivent venir du monde réel ou de
par la symétrie. La généralisation peut s'effectuer à partir d'une association (ex. point d'entrée
pour GAB et caissier d'agence). Dans tous les cas de figure il faut essayer de maximiser la
généralisation en regroupant autant d'attributs et d'associations que possible. La symétrie permet de
rajouter les attributs nécessaires à la distinction entre les sous-classes ;
La spécialisation
Elle est, généralement, apparente dans le domaine de l'application. Il s'agit de détecter les expressions qui
se composent d'un nom et d'un adjectif, le nom deviendra celui de la super-classe (ex. barre de menu
déroulant et menu étendu). La source la plus fréquente de la spécialisation est l'énumération de
sous-ensembles du domaine de l'application. Ce raffinement peut permettre de détecter certaines
mauvaises conceptions (de classes), mais il ne faut pas trop raffiner. Par exemple compte GAB se
spécialise en chèque et épargne, mais dans notre application cette spécialisation peut ne pas être très
utile, et il serait avantageux de la remplacer par un attribut type_compte.
Remarque
les mêmes super-classe peuvent être trouvées par l'une ou l'autre approche.
Il vaut mieux éviter l'héritage multiple qui, en général, simplifie l'écriture du code mais augmente
considérablement la complexité de la conception et de l'implantation. Il est cependant souvent utile de
définir une super-classe regroupant les informations communes à toutes les classes.
Étude des figures 7.9 et 7.10
On s'intéresse aux deux derniers cas pour illustrer une généralisation (fig. 7.10) :

Modèle objet
Figure 7.10: Modèle objets d'un GAB avec héritage
Vérification des chemins d'accès

Avant de raffiner le modèle objet il faut vérifier l'obtention des résultats :
Itération de la modélisation objet

Une fois le modèle objet est terminé il faut faire des retours en arrière, même après la construction des
modèles dynamique et fonctionnel, pour corriger, compléter, etc.
Détection de manque d'objets
Indices
Classes inutiles
: elles se manifestent par le défaut d'attributs, associations et opérations.
Associations inutiles
peuvent être détectées par :
Mauvais placement d'une association

comme dans les cas suivants :
Le résultat de ces amélioration est le diagramme, plus claire et plus simple, de la figure 7.11.
Figure 7.11: Modèle objets d'un GAB après

révision

Modèle objet
Groupement des classes en modules

Il s'agit de diviser le système en feuillets de taille uniforme ce qui le rend plus claire pour les perspectives
de dessin, de compréhension, etc.
Un module est un ensemble de classes (plusieurs feuillets) représentant une vue logique d'un
sous-ensemble du modèle.
Certaines classes joueront le rôle de ponts reliant les différents feuillets, il faut les choisir judicieusement
de manière à minimiser le nombre de passerelles et à limiter les références croisées entre modules. Une
des organisations possibles est l'organisation en étoile qui est composée d'un noyau autour duquel sont
disposés les modules (structures de haut niveau). Chaque module est une extension de classe représentant
une hiérarchie de généralisations avec ses associations.
Pour les objectif de réutilisation il faut faire confiance à son « bon sens » comme point de départ.
Exemple
GAB est une petite application qui n'a pas vraiment besoin d'être découpée en modules, mais pour
l'exemple il peut être décomposé en :


Modèle dynamique
Suivant : Modèle fonctionnel Précédent : Modèle objet Père : Analyse
Sous-sections
● Préparation des scénarios
● Format d'interface
● Identification des événements
❍ Exemple
● Construction des diagrammes d'états
● Vérification de la correspondance des événements entre les objets
Modèle dynamique
Objectif : description des aspects temporels et dynamiques du système et des objets.
Un événement est un stimuli externe visible, avec ses réponses. On commence la modélisation
dynamique par l'extraction d'un résumé des séquences d'événements ; pour chaque objet il faut établir un
diagramme d'états avec les événements entrants et sortants et qui montre les interactions entre objets (cf.
fig 7.15). On n'établit pas d'algorithme, ce qui relève de l'implantation, si l'événement n'est pas externe.
Ces diagrammes sont essentiels pour les systèmes interactifs, contrairement aux systèmes statiques
comme les Bases de Données. Il faut aussi noter qu'ils ne sont pas suffisants pour les systèmes temps
réel.
Un scénario est une séquence type d'événements, il permet de décrire les interactions courantes pour
l'extraction des événements et l'identification des objets cibles 7.1. Le suivi des séquences et des états
permet d'établir les diagrammes d'états et de les comparer afin d'obtenir la correspondance
événement-objet. L'ensemble des diagrammes d'état définit le modèle dynamique.
La modélisation dynamique passe par les phases suivantes :
Préparation des scénarios

Pour établir un scénario on part d'un dialogue type qui décrit le comportement du système du point de
vue de l'utilisateur, on y décrit les informations importantes, les formats d'affichage et les échanges
d'informations. Un événement est déclenché lorsqu'on opère un tel échange entre un objet et un élément
extérieur tel l'utilisateur, des capteur ou une tâche externe. Le cas échéant, les valeurs des informations
forment les paramètres de l'événement.

Modèle dynamique
Dans ce processus (exemples fig. 7.12 et 7.13) il faut éviter de décrire directement le modèle général (à
cause de sa complexité). Il faut par contre étoffer ou inventer des interactions qui correspondent à
l'énoncé du problème, et y ajouter les cas d'exceptions. Ces derniers peuvent être des oublis ou des
défauts, des conditions limites ou des erreurs humaines comme les dépassements des valeurs et la nature
des données. En particulier il faut veiller à gérer :
Figure 7.12: scénario normal du GAB
Figure 7.13: scénario du GAB avec un cas d'erreur
Pour chaque événement il faut identifier l'acteur mais sans se soucier, dans un premier temps, du format
du message. Ceci laisse la liberté d'imaginer d'autres cas d'exception.
Il faut aussi envisager les scénarios qui correspondent à tous les types d'interactions, comme par exemple
l'ouverture de compte, le création de nouvelles cartes et banques, l'obtention d'un journal de transactions,
etc.
Format d'interface
Les opérations d'un logiciel interactif peuvent être partagés en deux catégories : la logique de
l'application et l'interface utilisateur. Le découplage de ces deux aspects permet d'effectuer des tests
indépendants et donc de réaliser les deux parties en parallèle. Il est important de noter qu'il s'agit de deux
aspects très différents : pour l'interface c'est l'ergonomie et non pas la logique qu'on cherche à optimiser.
L'interface est aussi importante pour les évaluations.
L'analyse permet la description des flots de données et de contrôle quelque soit le format de présentation
(ligne de commande, fichier, interface graphique, communication distante, etc.). Le modèle dynamique
décrit ce qui se passe et non pas comment cela se passe ; il doit se concentrer sur la logique de contrôle
de l'application.

Modèle dynamique
L'interface peut par contre être simulée par l'utilisation de procédures factices pour la simulation du
système. Dans l'interface ce sont les informations échangées et non pas leur format qui sont importantes
(fig. 7.14), par exemple la séquence des touches pour entrer un mot de passe est beaucoup moins
importante que l'information elle-même.
Figure: Foramt d'une interface du GAB
Identification des événements

Les événements comprennent les signaux, les entrées, les décisions, les transitions et les actions avec
l'utilisateur, mais pas les séquences internes. En plus des événements normaux il faut considérer ceux
inhabituels ainsi que les cas d'erreur. Par exemple entrer mot de passe est un événement émis
par l'objet externe utilisateur vers le GAB, délivrer billets, qui est un événement implicite,
prend le chemin inverse.
Lorsqu'on constate un même effet produit par différentes valeurs il s'agit d'un même événement puisque
le flot de contrôle ne sera pas affecté. C'est pourquoi cette identification ne peut se faire qu'après avoir
établi les diagrammes d'état.
Exemple
mot de passe et délivrer billets sont les 2 classes d'événements mais compte OK,
mauvais compte et mauvais mot de passe ne doivent pas être groupés car ce sont des
événements différents. Par contre on peut considérer que toutes les entrées clavier correspondent à une
même classe d'événement, mis à part valider qui altère le comportement du système.
Pour chaque événement il faut identifier sa classe émettrice et sa classe réceptrice qui peuvent être
identique si la classe s'envoie l'événement à lui-même.
Dans le cas de l'exemple le scénario permet de définir le suivi d'événements de la figure 7.15 et de
produire le diagramme de flots d'événements entre classes/modules de la figure 7.16. La dernière étape
consiste à attacher les événements aux classes sans s'occuper du séquencement.
Figure: Suivi d'événements pour un scénario du

GAB

Modèle dynamique
Figure: Diagramme à flot d'événements pour le

GAB
Le modèle d'objets décrit les flots d'informations possibles, le diagramme d'états décrit les flots de
contrôle possibles.
Construction des diagrammes d'états

Un état est une abstraction des valeurs des attributs et des liens d'un objet. Ces valeurs sont groupées
selon les propriétés qui affectent le comportement de l'objet. Il faut établir, pour chaque objet non trivial
un diagramme d'états qui décrit ses événements d'entrées et de sortie. Un scénario correspond à un
chemin dans un tel diagramme. Pour ce faire il faut considérer un objet unique et ses interactions type, ce
qui définit un chemin constitué d'un ensemble d'arcs étiquetés par les événements d'une colonne du suivi.
L'intervalle entre deux événements correspond à une activité continue ou qui prend du temps ; c'est un
état, représenté par un nud et auquel on peut donner un nom si nécessaire (cf. fig. 7.17). La modification
d'un état par un événement donne lieu à une transition.
Il faut repérer les boucles et bien distinguer celles où l'objet « mémorise » son passage : dans ce cas l'état
final de la boucle n'est pas nécessairement le même d'un passage à l'autre. Ensuite les autres scénarios
doivent être « accrochés » au diagramme à partir de l'état où ils diffèrent du scénario d'origine. Il faut
veiller à distinguer les chemins semblables mais non identiques. Par exemple un système peut s'arrêter
après un certain nombre d'erreurs d'entrée de la part de l'utilisateur, si cette différence est masquée par un
attribut, nombre d'échecs, une des sorties de l'état final doit en dépendre. Il est ainsi possible de
largement simplifier un diagramme d'états. Une autre approche consiste à développer deux
sous-diagrammes ; l'un pour le fonctionnement normal et l'autre pour les cas spéciaux.
Il faut aussi ajouter les événements survenant à des instants indéfinis, comme l'annulation, et ceux
produits par l'absence de réponse après un certain délai. Le traitement des erreurs humaines demande
beaucoup plus de réflexion et de code que les cas normaux, mais elle doit être faite. Le diagramme d'états
est terminé quand il peut répondre à toutes les questions de la forme : « Que se passe-t-il si... ? ». Dans
certain cas (les plus complexes) il peut s'avérer nécessaire d'utiliser des diagrammes imbriqués.
Toutes les classes ne nécessitent pas de diagrammes d'états : pour les objets qui ne mémorisent pas leur

Modèle dynamique
passé et n'affectent pas le contrôle on peut se satisfaire d'établir la liste d'événements d'entrée et de sortie.
On peut aussi ne pas passer par les suivis d'événements mais dans tous les cas un nombre minimum de
scénarios est nécessaire.
Dans l'exemple GAB, Caissier d'agence, Consortium et Banque sont des acteurs pour
lesquels on fournit des diagrammes d'états comme celui de la classe GAB (fig. 7.17). Carte
bancaire Transaction et Compte sont des objets passifs. Client et Caissier sont des classes
extérieurs au système qui ne nécessitent pas d'implantation et dont les interactions avec le point d'entrée
ont déjà été montrées.
Figure: Diagramme d'états de la classe GAB
Les deux figures 7.18 et 7.19 montrent respectivement les diagrammes d'états des classes consortium
et Banque. Ces duex diagrammes doivent être confrontés au précédent pour vérfier la cohérence : les
événements en entrée et en sortie doivent être conformes à ceux émis et reçus par la classe GAB.
Figure: Diagramme d'états de la classe

Consortium
Figure: Diagramme d'états de la classe Banque

Modèle dynamique
Vérification de la correspondance des événements entre les objets

L'ensemble des diagrammes d'états pour les classes ayant un comportement dynamique important
constitue le modèle fonctionnel. Il faut suivre à travers les modèles l'influence d'un événement et vérifier
qu'il a toujours un émetteur et un récepteur. Vérifier aussi que tout état n'ayant pas de de prédécesseur
(resp. successeur) est un état initial (resp. final). La concurrence est inhérente aux objets : il faut vérifier
la synchronisation pour les événements qui peuvent surgir à des moments aléatoires. Dans le cas de
l'exemple, il faut garantir la cohérence des accès concurrents à un compte. L'examen des diagrammes
d'états montre que l'événement mauvais carte bancaire, émis par Consortium, n'est jamais
reçu par GAB, il faut donc l'ajouter ainsi que l'action (imprimer mauvais code bancaire et la
transition (carte rejetée).


Modèle fonctionnel
Suivant : Ajouter les opérations Précédent : Modèle dynamique Père : Analyse
Sous-sections
● Identification des valeurs d'entrée et de sortie
● Construction du diagramme à flot de données

● Description des fonctions
● Identification des contraintes entre objets
● Spécification des critères d'optimisation
Modèle fonctionnel
Le modèle fonctionnel s'intéresse au traitement des données sans tenir compte du séquencement, des
décisions ni de la structure des objets. Il montre les dépendances et les relations entre les valeurs.
Le modèle fonctionnel est représenté par des diagrammes à flot de données où, par comparaison avec les
diagrammes d'état des classes, les traitements correspondent aux activités et aux actions, et les flots
correspondent aux objets et aux valeurs d'attributs.
Identification des valeurs d'entrée et de sortie

Constituer la liste des valeurs d'entrée et de sortie qui sont les paramètres des événements entre le
système et le monde extérieur.
Dans l'exemple toute interaction de ce type passe par le GAB (ou le caissier), d'où les valeurs de la
figure 7.20. Certains événements n'ont pas de paramètres : en entrée ceux qui n'affectent pas le flot de
contrôle, comme annulation, fin et continuer et en sortie les acquittements comme billets
délivrés et carte insérée.
Figure: Valeurs d'entrée et de sortie pour le système

GAB

Modèle fonctionnel
Construction du diagramme à flot de données

Un diagramme à flot de données montre comment les valeurs de sorties sont obtenues à partir des
valeurs d'entrée, il est généralement constitué en couches qui raffinent successivement les traitement non
triviaux : tout traitement non trivial doit être décrit par un sous-diagramme. La couche de plus haut
niveau peut présenter un seul traitement ou une décomposition en entrée, traitement et sortie (cf. fig.
7.21).
Figure: Diagramme de plus haut niveau pour le

GAB
Pour développer le diagramme il faut suivre le cheminement des valeurs de la sortie vers l'entrée de
préférence. Il est important de distinguer les données réservoirs qui servent à stocker des valeurs pour
des traitements ultérieurs, comme compte dans le cas de l'exemple.
Les décisions sur le séquencement des opérations font partie du modèle dynamique et ne doivent pas
figurer ici car certaines opérations, comme la vérification du mot de passe, peuvent être optionnelles ou
s'exclure mutuellement. Néanmoins, les fonctions de décision peuvent être indiquées (par des flèches
sortantes en pointillé) sur le diagramme à flot de données pour souligner un traitement complexe, mais
elles affectent le flot de contrôle et non pas les valeurs des données. Par exemple l'erreur éventuellement
produite par vérifier mot de passe est indiquée, mais la flèche de contrôle du flot vers le
processus mise à jour du compte est laissée comme implicite (cf. fig. 7.22).
Figure: Diagramme à flots de données du traitement

traiter la transaction du GAB

Modèle fonctionnel
Description des fonctions

La description des fonctions doit se concentrer sur ce que fait la fonction et non pas sur la façon de
l'implanter. Elle peut être réalisée de différentes manières : en langage naturel, en pseudo-code, en
formulation mathématique, par des tables de décision, etc. Elle peut aussi avoir une forme procédurale ou
déclarative. C'est cette dernière qui est préférable lors de la phase d'analyse car elle ne suggère pas
d'implantation particulière. Dans le cas contraire on décrit uniquement le but de l'algorithme, laissant le
choix effectif à la réalisation. La figure 7.23 montre la description de la fonction mise à jour du
compte.
Figure: Description de la fonction mise à jour

du compte
Identification des contraintes entre objets

Les contraintes sont des dépendances fonctionnelles entre des objets non liés par une dépendance
entrée-sortie. Elles peuvent s'appliquer à deux objets en même temps, à un même objet à deux instants
différents ou à deux objets différents à deux instants différents. Les conditions d'entrée (resp. de sortie)
sur des fonctions sont des contraintes sur les valeurs d'entrée (resp. de sortie). Il faut établir les instants
ou les conditions sous lesquels les contraintes doivent s'appliquer.
Dans l'exemple aucun solde de compte ne doit être négatif est une contrainte sur un
compte ordinaire. Pour un compte possédant des privilèges un solde négatif ne peut pas
excéder le découvert autorisé. Pour inclure « ce qui se passe en cas de dépassement » les
contraintes doivent être incorporées dans les modèles dynamique et fonctionnel.
Spécification des critères d'optimisation

Il s'agit de préciser les valeurs à minimiser, maximiser ou optimiser, sans être trop précis. En cas de
conflit entre les critères d'optimisation il faut indiquer comment prendre la décision.
Dans le cas du GAB on peut citer les critères suivants : minimiser les échanges de
messages entre cites, minimiser le temps de vérouillage d'un compte et
minimiser le temps de blocage de l'accès à une banque.

Modèle fonctionnel


Ajouter les opérations
Suivant : Itération de l'analyse Précédent : Modèle fonctionnel Père : Analyse
Sous-sections
● Les opérations du modèle objet
● Les opérations des événements

● Les opérations des activités et des actions entre les états
● Les opérations des fonctions
● Les opérations « pense-bête » (shopping-list)
● Simplification des opérations

Les opérations peuvent correspondre à demandes de valeurs d'attributs ou d'associations dans le modèle
objet, comme compte.solde ou carte-bancaire.banque, à des événements dans le modèle
dynamique, comme annulation, ou à des fonctions du modèle fonctionnel, telles que mise à
jour de compte. Dans l'approche OMT la liste est ouverte et il est difficile de savoir où s'arrêter,
mais il faut distinguer les différents types d'opérations car certains langage orienté-objets fournissent
différents mécanismes pour leur implantation.
Les opérations du modèle objet

Elles incluent les lectures/écritures des valeurs d'attributs et des liens associatifs. pendant la phase
d'analyse on suppose que tous les attributs sont accessibles, par exemple GAB.montant-délivré. La
navigation d'un objet à un autre peut être exprimée à l'aide de « pseudo-attributs », comme
compte.banque. L'accès à un lien peut utiliser la notation indexée, telle que
consortium.banque[code-bancaire].compte[numéro-de-compte].
Les opérations des événements

Selon l'architecture du système, les événements peuvent être traités par des gestionnaires d'événements
ou convertis en méthodes. Pendant l'analyse on les présente sous forme d'étiquettes sur les transitions.

Les opérations des activités et des actions entre les états

Les activités du diagramme d'état peuvent être des fonctions définies comme des opérations. Par exemple
vérifier le code bancaire et vérifier le mot de passe.
Les opérations des fonctions

Les fonctions du flot de données, opérant sur un ou plusieurs objets et ayant une structure intéressante
doivent figurer sur le modèle objets.
Pour simplifier, des opérations groupant des morceaux de pseudo-code communs peuvent être ajoutés au
modèle fonctionnel.
Les seules opérations de type sélection de la figure 7.22 sont vérification-du-mot-de-passe
mise-à-jour-du-compte qui peuvent être définies comme des opérations des classes
Clé-d'accès et Compte respectivement. mise-à-jour-du-compte peut être simplifiée par la
définition d'actions simples :
compte::retrait (type, montant) -> résultat
et compte:: depot (type, montant) -> résultat
Les opérations « pense-bête » (shopping-list)

Ce sont les opérations suggérées par le fonctionnement du monde réel, indépendantes de toute
application mais ayant leur propre intérêt. Elle permettent de prévoir des évolutions, en élargissant la
définition d'un objet au-delà des besoin de l'application sans compromettre sa fluidité. Dans le cas de
l'exemple on peut définir : compte::fermer
compte::autoriser-la-carte-bancaire (clé-d'accès-au-compte)
banque::creation-d'un-compte-épragne (client) -> compte
banque::creation-d'un-compte-chèque (client) -> compte
banque::creation-d'un-carte-bancaire (client) -> clé-d'accès
clé-d'accès::supprimer-le-compte(compte)
clé-d'accès::fermer
Simplification des opérations

La généralisation (groupement des opérations semblables) et l'héritage permettent de réduire le nombre
d'opérations distinctes, mais l'introduction de nouvelles super-classes doit rester naturelle. Léxemple du
GAB n'est pas suffisamment complexe pour réclamer de telles simplifications.



Itération de l'analyse
Suivant : Conception du système Précédent : Ajouter les opérations Père : Analyse
Sous-sections
● Affiner le modèle d'analyse
● Reformuler les besoins
Itération de l'analyse
À cause de la complexité des interactions entre les différentes parties d'un système, il est indispensable
d'approcher la solution de manière itérative, en proposant une première approximation qu'on affine a fur
et à mesure que s'accroit notre compréhension du problème. Il ne faut cependant pas pousser l'analyse
trop loin puisqu'elle n'a pas de frontière exacte avec la conception.
Affiner le modèle d'analyse

Une vue globale et l'affinement de la définition des objets permettent de détecter les anomalies, les
oublis, les concepts erronés et, éventuellement les restructurations importantes. Ils permettent aussi
d'améliorer la cohérence, le partage et la robustesse du système. Parmi les indications à rechercher notons
:
Reformuler les besoins

Le modèle d'analyse sert de base à la spécification des besoins qui doivent être formulés clairement. En
plus de ceux définis par le modèle lui même il faut spécifier les contraintes de performance du système et
les méthodes à adopter pour le construire. Le modèle doit être vérifié et corrigé avec le client et les
experts du domaine, en particulier si le contraintes ont été modifiées au cours de l'analyse elle doivent
être reportées sur la description initiale du problème.


Conception du système
Suivant : Introduction Précédent : Itération de l'analyse Père : OMT : méthode d'analyse et
Conception du système
● Introduction
● Décomposer le système
● Couches
● Partitions
● Topologie du système


Introduction
Suivant : Décomposer le système Précédent : Conception du système Père : Conception du système
Introduction
La conception du système implique des décisions sur l'architecture du système. Il s'agit de l'organisation
du systèmes en sous-systèmes, l'allocation de ceux-ci aux ressources logicielles et matérielles, et
d'importantes décisions conceptuelles qui vont former la base de la conception détaillée.
Il existe un certain nombre d'architectures typiquessec:archiType adaptées aux différents types
d'applications. Chacun des sous-modèles, objet, dynamique et fonctionnel, a une importance plus ou
moins grande selon le type de l'application. Dans la pratique on est souvent amené à combiner et/ou à
adapter deux ou plusieurs de ces architectures, il s'agit donc de s'inspirer plutôt que de copier ces
architecture.


Décomposer le système
Suivant : Couches Précédent : Introduction Père : Conception du système
Décomposer le système
Un sous-système fournit un moyen cohérent de se pencher sur un aspect particulier d'un problème. Dans
la pratique, c'est un regroupement d'un petit nombre de composants (classes, associations, événements et
contraintes) qui partagent les mêmes propriétés du point de vue de leur fonctionnalité, de leur
emplacement physique ou ressources et/ou des ressources matérielles et logicielles qu'ils exploitent.
Un sous-système peut être décomposé en modules. Dans les deux cas, les composants (sous-systèmes ou
modules) sont reliés par des interfaces bien définies selon le principe de la modularitésec:modularité.
Dans le cas des sous-systèmes, l'interface définit le protocôle (ou modalités) de communication. On
distingue généralement deux types de protocôles : le client-serveur, et le égal-à-égal. Dans le premier cas
le client demande au serveur d'effectuer un service et de lui rendre le résultat. Le clien doit donc
connaître l'interface du serveur, mais celui-ci n'a pas à coonaître les interfaces de ses clients.
Le protocôle égal-à-égal est plus compliqué : un sous-système peut s'adresser à un autre sous-système s'il
en connaît l'interface, la réponse n'est pas nécessairement immédiate : le deuxième sous système peut
aussi appeler le premier pour lui communiquer le résultat.
Un système peut être décomposé horizontalement, en couches, ou verticalement, en partitions.


Couches
Suivant : Partitions Précédent : Décomposer le système Père : Conception du système
Couches
Une couche est une tranche horizontale permettant de faire abstraction de ce qui se trouve en dessous et
de fournir les bases d'implantation de ce qui se trouve au dessus. Ce qui implique une relation de type
client-serveur du haut vers le bas : chaque couche est client de celle qui la précède et serveur de celle qui
la suit.
Figure: Décomposition en couches : les deux

couches « extrêmes » correspondent normalement à
la description du problème.
Par exemple dans un système de fenêtrage la couche supérieure s'occoupe des opérations sur les fenêtres
qui sont réalisées en termes d'opérations sur des objets géométrique, qui sont à leur tour réalisées par des
opérations sur pixels définies et termes d'opérations d'entrée/sortie sur des périphériques.
Une architecture en couches peut être fermée : une couche ne connaît que celle qui la précède, ou ouverte
une couche peut utiliser toutes ou plusieurs de celles qui la précèdent. Une Ce dernier type permet d'avoir
un code plus compact et plus efficace, mais ne respecte pas le principe de masquage d'informations : une
modification sur une couche basse peut impliquer des modificatins sur l'ensemble du système.
Normalement la description du problème définit les deux couches extrêmes du système : la couche la
plus haute représente le système lui-même (du point de vue de l'utilisateur), et la couche la plus basse
définit les ressources disponibles (matériel, système d'exploitation, etc.). C'est la tâche du concepteur de
définir des couches intermédiaires en fonction de l'écart entre ces deux couches (qui exprime en quelque
sorte la taille et la complexité du système).
Il est conseillé de toujours concevoir une couche de services de bas niveau qui fait abstraction du
matériel utilisé et rend le système portable.


Partitions
Suivant : Topologie du système Précédent : Couches Père : Conception du système
Partitions
Une partition correspond à une « tranche » verticale réalisant un ensemble cohérent de fonctions dans un
système. Par exemple dans un système d'exploitation on peut distinguer des gestionnaires de processus,
de mémoire, de fichier et de communication réseau. Une partition peut avoir connaissance des autres
mais pas en profondeur.
Comme le montre la figure 7.25 La plupart des grands systèmes reposent sur un mélange de couches et
de partitions.
Figure 7.25: Bloc-diagramme d'une application

typique.


Topologie du système
Suivant : Identification des ressources Précédent : Partitions Père : Conception du système
Topologie du système
Pour représenter les intereactions entre les sous-systèmes le concepteur doit fournir un diagramme à flot
de donnéessec:techSpecif qui décrit les échanges entre les sous-systèmes. En général, selon l'architecture
du systèmesec:archiType, ce diagramme représente une organisation plus ou moins simple comme le
pipeline et l'étoile.


Identification des ressources
Suivant : Concurrences intrinsèques Précédent : Topologie du système Père : OMT : méthode d'analyse
et
Identification des ressources
● Concurrences intrinsèques
● Tâches concurrentes


Concurrences intrinsèques
Suivant : Tâches concurrentes Précédent : Identification des ressources Père : Identification des
ressources
Concurrences intrinsèques


Tâches concurrentes
Suivant : Allocation des sous-systèmes aux processeurs/tâches Précédent : Concurrences intrinsèques

Père : Identification des ressources
Tâches concurrentes


Allocation des sous-systèmes aux processeurs/tâches
Suivant : Réservoires de données Précédent : Tâches concurrentes Père : OMT : méthode d'analyse et
Allocation des sous-systèmes aux

processeurs/tâches


Réservoires de données
Suivant : Partage des ressources globales Précédent : Allocation des sous-systèmes aux
processeurs/tâches Père : OMT : méthode d'analyse et
Réservoires de données


Partage des ressources globales
Suivant : Logiciel de contrôle Précédent : Réservoires de données Père : OMT : méthode d'analyse et
Partage des ressources globales


Logiciel de contrôle
Suivant : Conditions limites Précédent : Partage des ressources globales Père : OMT : méthode
d'analyse et
Logiciel de contrôle


Conditions limites
Suivant : Compromis de priorités Précédent : Logiciel de contrôle Père : OMT : méthode d'analyse et
Conditions limites


Compromis de priorités
Suivant : Architectures type Précédent : Conditions limites Père : OMT : méthode d'analyse et
Compromis de priorités


Architectures type
Suivant : Transformation par lots (Pipeline) Précédent : Compromis de priorités Père : OMT : méthode
d'analyse et
Architectures type
● Transformation par lots (Pipeline)

❍ Principe
❍ Exemples
❍ Importance relative des modèles
❍ Étapes de la conception
● Transformation continue
❍ Principe
❍ Exemples
● Interface interactive
❍ Principe
❍ Exemples
● Simulation dynamique
❍ Principe
❍ Exemples
● Systémes temps réel
❍ Principe

Architectures type
❍ Exemples
● Gestionnaire de transactions
❍ Principe
❍ Exemples


Transformation par lots (Pipeline)
Suivant : Transformation continue Précédent : Architectures type Père : Architectures type
Sous-sections
● Principe
● Exemples
● Importance relative des modèles
● Étapes de la conception

Principe
Il s'agit d'une séquence de transformations permettant d'obtenir un résultat (unique) à partir d'un
ensemble de données fournies. Ce type de système ne comporte pas ou peu d'interaction avec l'utilisateur.
Exemples
Compilateur, programme de paye, calculs (dessin, architecture, météorologie, etc.).
Importance relative des modèles

Modèle objet :
dépend de la complexité des données.
Modèle dynamique :
simple ou inexistant.
Modèle fonctionnel :
c'est le plus important car il décrit comment seront transformées les données.
Étapes de la conception
● Éclater les transforamtions : ajouter des détails au modèle fonctionnel pour obtenir les étages de
traitement.
● Définir les classes de données intermédiaires (échangés entre les étages). chaque ensemble de
données sera décrit par un modèle objet cohérent et faiblement couplé aux autres modèles (ex.
l'arbre d'analyse d'un compilateur).

● Développer chaque étage.

● Restructurer le système pour optimisation.


Transformation continue
Suivant : Interface interactive Précédent : Transformation par lots (Pipeline) Père : Architectures type
Sous-sections
● Principe
● Exemples
Principe
Dasn ce type de système les sorites, construites de manière incrémentatle, dépendent activement des
entrées et sont régulièrement mises à jour en fonctions de celles-ci. Cette mise à jour est théoriquement
continue mais a lieu a des intervalles périodiques dans la pratique.
Exemples
Traitement du signal, systèmes de fenetrage, surveillance de processus, etc.

Modèle objet :
plus important que dans le cas précédent, les effets de la modification d'une données doivent être
propagés à travers le pipeline ce qui nécessite la défintion de nouvelles données intermédiaires.
Modèle dynamique :
pas très important car l'architecture du système dépend plus du flot régulier des données que des
interactions, mais la synchronisation des traitement doit être bien bien régulée pour éviter les
goulot d'étranglement.
définit les valeurs en cours de traitement.

● Dessiner un DFD des entrées/sorties, les réservoires de données intérieurs au pipeline déterminent
les paramètres des transformations.
● Définir les objets intermédiaires, par exemple chaque objet graphique a une version représentant
une abstraction appropriée à chaque étage du traitement.
● Décomposer les opérations et ajouter la propagation des modifications. Par exemple la
modification de la position d'un objet implique la modification d'une partie du dessin (nouveaux
objets masqués ou découverts).
● Optimiser, peut nécessiter l'ajout de nouveaux objets.


Interface interactive
Suivant : Simulation dynamique Précédent : Transformation continue Père : Architectures type
Sous-sections
● Principe
● Exemples
Interface interactive
Principe
Exemples
Modèle objet :
Modèle dynamique :


Simulation dynamique
Suivant : Systémes temps réel Précédent : Interface interactive Père : Architectures type
Sous-sections
● Principe
● Exemples
Simulation dynamique
Principe
Exemples


Systémes temps réel
Suivant : Gestionnaire de transactions Précédent : Simulation dynamique Père : Architectures type
Sous-sections
● Principe
● Exemples
Systémes temps réel

Principe
Exemples
Modèle objet :
Modèle dynamique :


Gestionnaire de transactions
Suivant : Conception des objets Précédent : Systémes temps réel Père : Architectures type
Sous-sections
● Principe
● Exemples
Gestionnaire de transactions
Principe
Exemples
Modèle objet :
Modèle dynamique :


Suivant : Management des projets logiciels Précédent : Gestionnaire de transactions Père : OMT :
méthode d'analyse et


Management des projets logiciels
Suivant : Gestion des projets Logiciels Précédent : Conception des objets Père : Support de cours :
Introduction
Management des projets logiciels


Gestion des projets Logiciels
Suivant : Validation, Vérification et tests Précédent : Management des projets logiciels Père : Support
de cours : Introduction
Gestion des projets Logiciels


Validation, Vérification et tests
Suivant : Qualité et assurance qualité Précédent : Gestion des projets Logiciels Père : Support de cours
: Introduction
Validation, Vérification et tests


Qualité et assurance qualité
Suivant : Gestion des configurations Précédent : Validation, Vérification et tests Père : Support de
cours : Introduction
Qualité et assurance qualité


Gestion des configurations
Suivant : Liste des figures Précédent : Qualité et assurance qualité Père : Support de cours :
Introduction
Gestion des configurations


Liste des figures
Suivant : Références Précédent : Gestion des configurations Père : Support de cours : Introduction
Liste des figures

❍ Activités et produits de la conceptions [#!Sommerville:92!#]
❍ Exemple de diagramme de flux de données. Système de Recherche d'Informations
Professionnelles.
❍ Réseau de guichets automatiques bancaires (GAB)
❍ Identification des classes d'objets
❍ Classes du GAB déduites de la description du problème
❍ Classes du GAB déduites de la connaissance du domaine du problème
❍ Élimination des classes inutiles du problème du GAB
❍ Dictionnaires de données pour les classes du GAB
❍ Associations déduites de la description du problème du GAB
❍ Diagramme d'objets initial pour le système GAB
❍ Modèle objets d'un GAB avec attributs
❍ Modèle objets d'un GAB avec héritage
❍ Modèle objets d'un GAB après révision
❍ scénario normal du GAB
❍ scénario du GAB avec un cas d'erreur
❍ Foramt d'une interface du GAB
❍ Suivi d'événements pour un scénario du GAB
❍ Diagramme à flot d'événements pour le GAB
❍ Diagramme d'états de la classe GAB
❍ Diagramme d'états de la classe Consortium
❍ Diagramme d'états de la classe Banque
❍ Valeurs d'entrée et de sortie pour le système GAB
❍ Diagramme de plus haut niveau pour le GAB
❍ Diagramme à flots de données du traitement traiter la transaction du GAB
❍ Description de la fonction mise à jour du compte

Liste des figures
❍ Décomposition en couches : les deux couches « extrêmes » correspondent normalement à la

description du problème.
❍ Bloc-diagramme d'une application typique.


Références
Suivant : Index Précédent : Liste des figures Père : Support de cours : Introduction
Références
1
Christian Bénard.
Les 9 points clés de la conduite d'un projet informatique.
Collection Homme et Technique. Les Éditions d'Organisation, Paris, 1992.
2
Grady Booch.
Object Oriented Design with applications.
Benjamin/Cummings, California, 1991.
3
Grady Booch.
Conception orientée objets et applications.
Addison-Wesley, Paris, Janvier 1992.
4
J. P. Calvez.
Spécification et conception des systèmes, une méthodologie.
Masson, Paris, 1991.
5
B. Coulange.
Réutilisation du logiciel.
6
W. Curtis.
``management and experimentation in software enginnering''.
Proceedings of the IEEE, 68(9), 1980.
7
Ferdinand de Saussure.
Cours de linguistique Générale.
1915.
8
NATO Scientifc Affairs Division.
Software engineering.
Report on a conference sponsred by the nato science comitee, gamisch-partenkirchen, 7-11 october
1968, jan 1969.

Références
9
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides.
Design Patterns - Elements of Reusable Object-Oriented Software.
Addison-Wesley Publishing Company, 1995.
Version francaise publiee par : International Thomson Publishing France, Paris, 1996.
10
Marie-Claude Gaudel, Bruno Marre, Françoise Schlienger, and Gilles Bernot.
précis de génie logiciel.
Enseignement de l'Inforamtique. Masson, Paris, 1996.
11
Patrick Jaulent.
Génie Logiciel : les méthodes.
Armand Colin, Paris, 1990.
12
Jean-Marc Jézéquel and Bertrand Meyer.
Design by contract: The lessons of ariane.
Computer (IEEE), 30(2):129-130, January 1997.
13
R. Kehoe and A. Jarvis.
ISO 9000-3: A Tool for Software Product and Process Improvement.
Springer, New York, 1996.
14
Michel Lai.
UML - La notation unifiée de modélisation en objet. Applications en Java.
Avec CD.
15
Richard C. Lee and William M. Tepfenhart.
UML et C++, Guide pratique du développement orienté objet.
Simon and Schuster Macmillan, 1998.
16
Jean Pierre Martin.
Du bricolage à l'industrialisation : La qualité du ogiciel.
Afnor Gestion. Afnor, Paris, 1987.
17
G. Masini, A. Napoli, D. Colnet, D. Léonard, and K. Tombre.
Les langages à objets.
InterEditions, Paris, 1989.
18
J. McCall.
Factors in Software Quality.

Références
General Electric Eds, 1977.

19
B. Meyer.
Object-Oriented Software Construction.
Prentice Hall International Ltd., UK, 1988.
20
B. Meyer.
Conception et programmation par objets pour du logiciel de qualité.
InterEditions, Paris, 1990.
21
Christophe Pasquier, Philippe Roucoulet, and Marie-Line Lanaspèze.
L'approche objet.
Hermes, Paris, 1995.
22
R. Pressman.
Software Engineering: a Practioner's Approach.
McGrow-hill, Auckland, 1987.
23
J. Rumbaugh, M. Blaha, F. Eddy, W. Premerlani, and W. Lorensen.
OMT. Modélisation et conception orientées objet.
Masson Paris and Prentice Hall London, 1995.
24
I. Sommerville.
Le Génie Logiciel.
Addison-Wesley Publishers, 1992.
25
I. Sommerville.
Software Engineering.
Addison-Wesley Publishers, Auckland, 1992.
26
I.G.L. Technology.
SADT : un langage pour communiquer.
Yerolles, Paris, 1993.
27
M. S. Verrall.
Unity doesn't imply unification or overcoming heterogeneity problems in distributed software
engineering environments.
The Computer Journal, 34(6):522-533, 1991.

Références

Genie Logiciel

Transféré par

Droits d'auteur :

Formats disponibles

Genie Logiciel

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Genie Logiciel

Transféré par

Droits d'auteur :

Formats disponibles

Support de cours : Introduction au Génie Logiciel

Suivant : Préface Père : Ma page d'accueil

http://www-ic2.univ-lemans.fr/~alissali/Enseignement/Polys/GL/gl.html (1 of 5) [31-12-2001 21:47:44]

● The Software Quality Page

Université du Maine - Le Mans

http://www-ic2.univ-lemans.fr/~alissali/Enseignement/Polys/GL/gl.html (2 of 5) [31-12-2001 21:47:44]

● Modèles de développement du logiciel

http://www-ic2.univ-lemans.fr/~alissali/Enseignement/Polys/GL/gl.html (3 of 5) [31-12-2001 21:47:44]

■ Critères de qualité de la conception

http://www-ic2.univ-lemans.fr/~alissali/Enseignement/Polys/GL/gl.html (4 of 5) [31-12-2001 21:47:44]

© Copyright 1998 Mamoun Alissali. Tous droits réservés.

http://www-ic2.univ-lemans.fr/~alissali/Enseignement/Polys/GL/gl.html (5 of 5) [31-12-2001 21:47:44]

© Copyright 1998 Mamoun Alissali. Tous droits réservés.

http://www-ic2.univ-lemans.fr/~alissali/Enseignement/Polys/GL/ACUnode1.html [31-12-2001 21:47:58]

Précédent : Références Père : Support de cours : Introduction

http://www-ic2.univ-lemans.fr/~alissali/Enseignement/Polys/GL/ACUnode95.html (1 of 6) [31-12-2001 21:48:08]

http://www-ic2.univ-lemans.fr/~alissali/Enseignement/Polys/GL/ACUnode95.html (2 of 6) [31-12-2001 21:48:08]

http://www-ic2.univ-lemans.fr/~alissali/Enseignement/Polys/GL/ACUnode95.html (3 of 6) [31-12-2001 21:48:08]

http://www-ic2.univ-lemans.fr/~alissali/Enseignement/Polys/GL/ACUnode95.html (4 of 6) [31-12-2001 21:48:08]

http://www-ic2.univ-lemans.fr/~alissali/Enseignement/Polys/GL/ACUnode95.html (5 of 6) [31-12-2001 21:48:08]

© Copyright 1998 Mamoun Alissali. Tous droits réservés.

http://www-ic2.univ-lemans.fr/~alissali/Enseignement/Polys/GL/ACUnode95.html (6 of 6) [31-12-2001 21:48:08]

Suivant : Position du problème Précédent : Préface Père : Préface

© Copyright 1998 Mamoun Alissali. Tous droits réservés.

http://www-ic2.univ-lemans.fr/~alissali/Enseignement/Polys/GL/ACUnode2.html [31-12-2001 21:48:11]

Suivant : Agencement de la programmation et Précédent : Objectifs Père : Préface

© Copyright 1998 Mamoun Alissali. Tous droits réservés.

http://www-ic2.univ-lemans.fr/~alissali/Enseignement/Polys/GL/ACUnode3.html [31-12-2001 21:48:15]

Suivant : Conclusion Précédent : Position du problème Père : Préface

http://www-ic2.univ-lemans.fr/~alissali/Enseignement/Polys/GL/ACUnode4.html (1 of 2) [31-12-2001 21:48:20]

© Copyright 1998 Mamoun Alissali. Tous droits réservés.

http://www-ic2.univ-lemans.fr/~alissali/Enseignement/Polys/GL/ACUnode4.html (2 of 2) [31-12-2001 21:48:20]

Suivant : Principes du Génie Logiciel Précédent : Agencement de la programmation et Père : Préface

© Copyright 1998 Mamoun Alissali. Tous droits réservés.

http://www-ic2.univ-lemans.fr/~alissali/Enseignement/Polys/GL/ACUnode5.html [31-12-2001 21:48:23]

Suivant : Introduction Précédent : Conclusion Père : Support de cours : Introduction

Principes du Génie Logiciel

© Copyright 1998 Mamoun Alissali. Tous droits réservés.

http://www-ic2.univ-lemans.fr/~alissali/Enseignement/Polys/GL/ACUnode6.html [31-12-2001 21:48:26]

© Copyright 1998 Mamoun Alissali. Tous droits réservés.

http://www-ic2.univ-lemans.fr/~alissali/Enseignement/Polys/GL/ACUnode7.html [31-12-2001 21:48:31]

Suivant : Objectif et nécessité Précédent : Introduction Père : Introduction

© Copyright 1998 Mamoun Alissali. Tous droits réservés.

http://www-ic2.univ-lemans.fr/~alissali/Enseignement/Polys/GL/ACUnode8.html [31-12-2001 21:48:39]

Suivant : Qualité du logiciel Précédent : Définitions Père : Introduction

● non respect des spécifications ;

● non respect des délais.

● EDF a récemment renoncé à la mise en service de nouveaux systèmes de contrôle-commande de

● 10% maintenance adaptative : nouvel environnement, nouveaux utilisateurs ;

● 17% maintenance corrective : correction des bogues ;

http://www-ic2.univ-lemans.fr/~alissali/Enseignement/Polys/GL/ACUnode9.html (1 of 2) [31-12-2001 21:48:44]

● 6% assistance aux utilisateurs ;

© Copyright 1998 Mamoun Alissali. Tous droits réservés.

http://www-ic2.univ-lemans.fr/~alissali/Enseignement/Polys/GL/ACUnode9.html (2 of 2) [31-12-2001 21:48:44]

Suivant : Modélisation Précédent : Objectif et nécessité Père : Principes du Génie Logiciel

● Efficacité : Utilisation optimales des ressources matérielles.

● Facilité d'emploi : facilité d'apprentissage, d'utilisation, de préparation des données,

http://www-ic2.univ-lemans.fr/~alissali/Enseignement/Polys/GL/ACUnode10.html (1 of 2) [31-12-2001 21:48:49]

© Copyright 1998 Mamoun Alissali. Tous droits réservés.