GL

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


Avertissement  Ce document est en cours d'élaboration ce qui ne me permet pas d'en diffuser que la version HTML. HTML. En attendant une version papier présentable, voici, en plus des références bibliographiques, quelques quelques sites WEB qui peuvent intéresser le lecteur : q Programmation - Objets - Modélisation de la connaissance q The Software Quality Page q Object-Oriented Information Sources q The Method Engineering Encyclopaedia q The Virtual Library - Computer Programming Pr ogramming Languages

Université du Maine - Le Mans

q

q

Préface r Objectifs r Position du problème r Agencement de la programmation et de la conception r Conclusion Principes du Génie Logiciel r Introduction s Définitions s Objectif et nécessité r Qualité du logiciel r Modélisation

Support de cours : Introduction au Génie Logiciel q

q

q

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


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

q

q

q


Conditions limites r Compromis de priorités r Architectures type s Transformation par lots ( Pipeline) s Transformation continue s Interface interactive s Simulation dynamique s Systémes temps réel s Gestionnaire de transactions r 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 r

q q q q q q q q

© Copyright 1998 Mamoun Alissali. Tous droits réservés. Commentaires et suggestions 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 q q q q

Objectifs Position du problème Agencement de la programmation et de la conception Conclusion


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 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 : q les bases de l'informatique (programmation, algorithmique et structures de données) sont indispensables; q la programmation orientée-objet est complexe et nécessite une attention particulière ; q 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 term es 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 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 dessus 2. Cette description générique peut être instanciée pour chaque nouvel objet pour décrire ses caractéristiques propres 3. Mais en même temps deux objets ayant exactement les mêmes caractéristiques sont quand même deux objets différents 4. 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 f aire 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 offr ent un avantage ceratin mais ils ne sont indispensables ni à la conception ni à la réalisation 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 ( 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 q

q q

Introduction r Définitions r Objectif et nécessité Qualité du logiciel Modélisation


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

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


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 .

Masson, Paris, 1996. 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 Improvement .

Springer, New York, 1996. 14

Michel Lai. UML - La notation unifiée de modélisation en objet. Applications en Java.

Masson, Paris, 1997. 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, L ondon, 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.

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

Références

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

Modèle fonctionnel

Suivant : Ajouter les opérations Précédent : Modèle dynamique Père : Analyse Sous-sections q q q q q

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 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 GAB

système

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). 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 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 m aniè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 messages entre cites, minimiser le temps de vérouillage d'un minimiser le temps de blocage de l'accès à une banque.

de compte et

Modèle fonctionnel


Analyse des besoins

Suivant : Modèles du cycle de vie Précédent : Les activités Père : Les activités Sous-sections q q q q q q

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 ( le cahier des charges) il faut étudier : q le domaine d'application ; q l'état actuel de l'environnement du futur système ; q le rôle du système ; q les ressources disponibles et requises ; q les contraintes d'utilisation ; q les performances attendues ; q ... 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). r endent). 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 : q tous les chemins d'accès logiques ; q la plage de validité des données et en particulier les « conditions limites » ; q la conformité des résultats aux spécifications. Par ailleurs, on distingue différents niveaux de test : q les tests unitaires pour les composants isolés ; q les tests d'intégration pour un assemblage de composants ;

Analyse des besoins q

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.


Identité : notion d'objet

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

des objets

 Identité : notion d'objet 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, m arque, 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

Identité : notion d'objet

é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.


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 s ituation 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 fonctionnellecha:concFctl et l'analyse et la conception orientées objetcha:OMT.


Le cycle de vie du logiciel

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

 Le cycle de vie du logiciel Comme tout produit complexe , le cycle de vie du logiciel passe par les phases (ou étapes) suivantes : q Étude de faisabilité ; q Spécifications ; q Production ; q Contrôles ; q Essais ; q Contrôle de la production ; Vente/utilisation/entretien ; q 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 (cf.2.4 et 1.3)) permettant de prendre en compte, en plus des aspects techniques, l'organisation et les aspects 1.3 humains. Il est important de noter qu'une étape, telle que la conception, peut faire intervenir plusieurs activité s, 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 à : q à chaque niveau de décomposition, bien décrire le problème et sa décomposition en sous-problèmes ; q 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 ; q concevoir (et utiliser) des solutions réutilisables.

Le cycle de vie du logiciel


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 q q

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 q q q q

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 q q q q q q

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


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.


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.


Modèle objet

Suivant : Modèle dynamique Précédent : Analyse Père : Analyse Sous-sections q q q q q q q q

q q

q

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 r La généralisation r La spécialisation r Remarque r Étude des figures 7.9 et 7.10 Vérification des chemins d'accès Itération de la modélisation objet r Détection de manque d'objets r Indices Groupement des classes en modules r 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 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 7.3)) et on exploite nos connaissances sur le domaine de l'application (fig. 7.4 7.4). ).  Classes du GAB déduites de la description du problème

Figure 7.3:

 Classes du GAB déduites de la connaissance du domaine du problème

Figure 7.4:

Sélection des classes pertinentes Certaines classes peuvent être éliminées, on peut les classer dans différentes catégories (fig. 7.5 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 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 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 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 r essources communes, il peut être établi par deux méthodes : é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 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 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 m odule 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

l'exemple il peut être décomposé en :

pour


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 q q q q

Énonces informels Présentations formatées Techniques graphiques ou semi-formelles Techniques formelles

 Techniques de spécification É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 de spécification

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) 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 cr itical 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.


Classification : notion de classe

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

Caratéristiques des objets Sous-sections q q

Attributs Opérations et méthodes

 Classification : notion de classe 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 m embre 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 6.2.3). ).

Classification : notion de classe


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 f orme 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.


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 q

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 ( 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 : q enchaînement et itération : se déroulent essentiellement de gauche à droite. q 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 : q obligation de concevoir les jeux de test et leurs résultats ; q réflexion et retour sur la description en cours ; q 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 : q assurance qualité ; q production ; q contrôle technique ; q gestion ; q 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

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


Héritage : notion de paratge

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

Caratéristiques des objets

 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 r ajouter 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.


Modèle dynamique

Suivant : Modèle fonctionnel Précédent : Modèle objet Père : Analyse Sous-sections q q q

q q

Préparation des scénarios Format d'interface Identification des événements r 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 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 7.13)) il faut éviter de décrire directement le modèle général (à cause de sa complexité). Il faut f aut 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 7.14), ), par exemple la séquence 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 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 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 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).


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, ( 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 s ous-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.


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 : q il fait une large place à l'analyse des besoins, à la conception et à la validation ; q 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 ; q 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. , il donne lieu à la production de documents intermédiaires q pour pallier au problème de l' invisibilité permettant de contrôler un logiciel en cours de développement ; q 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.


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 q q q

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

 Modèles par incrément 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 q q q q

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 q q

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.

Modèles par incrément

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


Modularité

Suivant : Critères de qualité de la Précédent : Qualité de la conception Père : Qualité de la conception Sous-sections q q

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 [20]] (cf exemple) : q Interfaces explicites : chaque fois que deux modules m odules A et B communiquent, cela doit ressortir clairement du texte de A, de B ou des deux. q Petites interfaces (couplage faible) : si deux modules communiquent, ils doivent échanger aussi peu d'informations que possible. ser vent à la communication avec d'autres q Masquage de l'information : seules les informations qui servent modules doivent être publiques (visibles de l'extérieur du module). q Peu d'interfaces : un module doit communiquer avec aussi peu d'autres que possible. q 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 : q ouvert : s'il est encore disponible pour des extensions/modifications ;  q 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é.


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 r evue 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 rem et 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 : q faisabilité et analyse des besoins : validation ; q conception du produit et conception détaillée : vérification ; q intégration : test d'intégration et test d'acceptation ; q installation : test du système.


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 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 ( 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 7.3)) ; Conception des objets

: raffiner les structures s tructures de données et les algorithmes en y ajoutant les détails d'implantation et en tenant compte de l'environnement (7.12 ( 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 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


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 : q la distinction composition/décompostion composition/décompostion 2.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 ». ; q 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.


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 s ur un mélange de couches et de partitions.  Figure 7.25:

Bloc-diagramme d'une application typique.


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.


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.

q

Cycle auteur/lecteur


Footnotes

... chaises1 Notions d'objet et de de classe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

... dessus2 Notion de propriété. . . . . . . . . . .

Footnotes

. . . . . . . . . . . . . . . . . . . .

... propres3 Notion d'instanciation. . . . . . . . . . . . . . . . . . . . . . . .

Footnotes

. . . . . . .

... différents4 Principe de l'identité, l'orienté-objet rejette les artifices informatiques tels que la clef et l'identifiant. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

... >>5 Concept de l'héritage. . .

Footnotes

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

... activités2.1 L'étude préalable ne fait pas vraiment partie du projet. Elle est faite par les commanditaires et produit le cahier des charges. . . . . . . . . . . . . . .

Footnotes

. . . . . . . . . . . . . . . .

... composition/décompostion 2.2 Avec cette classification certains auteurs préfèrent parler d'« approches », ceci met en évidence le fait que dans la pratique on utilise ces deux types de méthode (ou d'approche) conjointement. La première comme stratégie générale et la deuxième selon l'expérience du concepteur. . . . . . . . . . . . . . . . . . . . . . . . . .

Footnotes

. . . . .

... l'ensemble2.3 Ici aussi on fait souvent appel aux deux sortes de stratégies de conception. Le choix de l'une ou de l'autre dépend d'un ensemble de facteurs dont la nature du problème. Généralement la conception objet se montre plus appropriée aux niveaux très haut et très bas de la conception. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

... (pseudo-langage) 4.1 Un langage de description de programmes ou pseudo-langage est un langage basé sur les langages de programmation existants mais autorisent l'utilisation de la langue naturelle et d'instructions supplémentaires. Il permet d'expliquer les intentions plutôt que les implantations. .

Footnotes

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

... cibles7.1 Une comparaison entre le diagramme de suivi d'événements et le diagramme d'états montre que, dans certains cas, un événement est noté comme activité , je n'ai pas réussi à trouver une explication satisfaisante dans le livre (M.A.). . . . . . . . . . . . .

Footnotes

. . . . . . . . . . . . . . . . . .


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 q

La description de la conception

 Processus de conception de logiciel 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 usqu'à 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 : q Étude et compréhension du problème (analyse et spécifications) : examiner le problème sous différents angles. q Identifier les caractéristiques d'au moins une solution possible. Il est souvent utile (et parfois indispensable) d'évaluer plusieurs solutions. q 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 4.1,, on peut raffiner description donnée précédemment (cf. 2.3 2.3)) du processus de conception comme suit : q Conception de l'architecture : identifier les sous-systèmes et leurs relations. q 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. q Conception de l'interface : pour chaque sous-système, concevoir et documenter (de manière claire) l'interface avec les autres sous-systèmes. q Conception des composants de chaque sous-système. q Conception détaillée des structures de données. q 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é m algré 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.

Processus de conception de logiciel

 [ 25]] Figure: Activités et produits de la conceptions [25

La description de la conception Une conception est utilisée de différentes manières : q pour produire des implantations ; q comme moyen de communication entre les concepteurs de différents sous-systèmes ; q comme référence pour l'entretien du système. q ... 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) ( 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.)


Mamoun ALISSALIMaître de Conférence

Mamoun ALISSALI Maître de Conférence Page en cours de construction Dernière mise à jour le 29 février 2000

English version

q

q

q

Activités de recherche r Projets r Publications r Liens pour Chercheurs Activités d'enseignement r Enseignements r Supports de cours r Projets des étudiants Autres activités r Organisation du séminaire du LIUM s Les exposés s Exposés des années précédentes r Gestion de l'installation locale (LA)T EX

Mamoun ALISSALIMaître de Conférence q q

Mes coordonnées Quelques unes de mes pages WEB préférées

Accueil

Recherche

Enseignement

Mes pages ont été visitées Dernière mise à jour le 29 f\'evrier 2000.

Séminaires l'IC2

Coordonnées

Liens

Page d'accueil de

suggestions.. fois depuis le 29 février 2000. Commentaires et suggestions

The Software Quality Page


Your connection to the world of software quality, standards and process improvement.

Register NOW! 10th International Conference on Software Quality October 16-18, 2000, New Orleans

Call for Papers! Software Quality Professional A new journal from the American Society for Quality Subscribe to Software Quality Professional

Visit the Software Quality Page Bookstore


Software Engineering Stories Van Vleck's Software Engineering Stories

Year 2000 Problem Mitre's Y2K site

Software Test Object-Oriented Testing Software Testing - Usenet Software Testing Newsletter Testing Techniques Newsletter Tester's Network

Software Inspections and Reviews Software Inspection Training Technical Review Archive

Software Metrics

Software Quality & Liability Cem Kaner's Software Liability Site

Software Standards IEEE Standards

ISO ISO Online (ISO 9000 & 14000)

General - Quality, SW Quality & Process Deming Electronic Network QFD Institute

Practical SW Measurement

Quality Function Deployment

SW Measurement Lab

USAF SW Tech Support Center

Object Oriented SW Metrics SW Metrics & Static Analysis

Software Process

Software and Quality Organizations American Society for Quality ASQ Software Division


Boston-SPIN

Association for Computing Machinery

CMM

Australian SW Quality Research Inst

CMM Level 2 Focus Group

British Computer Society

Cleanroom SW Engineering

European Software Institute

Cleanroom SW Eng Tutorial

IEEE Computer Sociey

The Dilbert Perspective

Inst for the Cert of Computing Prof

SEI Interactive

Society for Software Quality

Software Process Newsletter

Software Engineering Institute

Software Productivity Centre

National Research Center of Canada

SPAWAR Software Eng. Process Office

SW Assurance Tech Center

SPICE

SW Inspections and Review Org

TRILLIUM

Software Productivity Centre

New England Area Groups ACM Greater Boston Chapter ASQ Boston Section

Software Program Managers Network Software Quality Group (New Zealand) Software Quality Institute

Boston SPIN New England SW Quality Assurance Forum Software Quality Group of New England Software Inspection Training

visitors since 12/2/1995


SWaNH SW Eng & Quality SIG

return to top of page WebMaster: John Pustaver, Software Quality Consultant Send your comments and requests for information to:[email protected] to:[email protected] © SWQuality, Inc. (formerly Creative Data Systems, Inc.), Sudbury, Massachusetts, USA 1995-2000

Index to Object-Oriented Information Sources

[ Software Composition Group | OO Info Sources | OO Bibliography | Oscar's Who's Who ]

Object-Oriented Information Sources This page collects pointers to various information sources on the World Wide Web related to Object-Oriented languages and systems. First installed June 30, 1993. The Object FAQ may also be helpful.

Please note: This Database is deprecated. We refer to Cetus Links - Thousands of Links on Objects and Components instead. Search

Case Sensitive Search

Use Perl regex instead

Some pre-packaged queries:

General OO Information Resources Bibliographies Books Calls for Papers (Journals and Meetings Meetings)) Companies and Products Frequently Asked Questions FTP Archives (publications) Programming Languages Newsgroups Special Interest Groups Research Groups (home pages) Search Engines Systems Teaching Java This page received four stars from Magellan

Enter multiple keywords

Index to Object-Oriented Information Sources

SCG Webmaster

The WWW Virtual Library: Computing, Programming Languages

Virtual Library

Computing

Computer Programming Languages. Below are pointers to some on-line reference ref erence information about computer languages. Subsections are maintained by different individuals. Mail [email protected] for additions to this list. ABC r A Short Introduction to the ABC Language with links to other ABC resources. Ada r Information on the language Ada is at Ada WWW. r AdaSAGE training and user group information. Basic, Visual. Usenet Frequently Asked Questions. BETA Frequently Asked Questions. C r The Degener C collection of papers and information about C. r The VMS/C help is good on the language and run-time functions . r Usenet Frequently Asked Questions. C++ C++ documentation and sources, and C++ for physicists. Elisp Emacs lisp language -- full documentation. Cecil Cecil is a new purely object-oriented language intended to support rapid construction of high-quality, extensible software. Cecil combines multi-methods with a simple object model, module-based encapsulation, and optional static type checking. COBOL COmercial Buisness Oriented Language. FAQ. Dylan Dylan is a new Object Oriented Dynamic Language (OODL). Dylan combines the features f eatures of static and dynamic languages. FAQ. Eclipse ECLiPSe combines Sepia's extended Prolog technology with MegaLog's persistent knowledge

The WWW Virtual Library: Computing, Programming Languages

base functionality, a substantial subset of CHIP's constraints handling facilities, several new constraints libraries, and soon or-parallelism as featured in ElipSys. Eiffel Eiffel is an advanced object-oriented programming language that emphasizes the design and construction of high-quality and reusable software. Elf Elf is a constraint logic programming language based on the LF Logical Framework. It is intended as a uniform meta-language for specifying, implementing, and proving properties of programming languages and logics. Erlang Concurrent functional programming language for large industrial real-time systems. Dynamically typed. Forth Forth is an embeded stack language. r Peter Knaggs collection of Forth links. r Forth Interest Group (FIG) are aimed at the home/hobist user. FORTRAN r Nag Fortran 90 Libraries . r CM/FORTRAN index. r The Fortran Market. r FAQ. Functional Programming Functional programming references Dept. of Computer Science, James Cook University. Haskell. Functional programming language. Yale Archive. . Lisp r Usenet Frequently Asked Questions (with answers) r Association of LISP Users. r CMU LISP Repository. Occam. r Occam programming language based on CSP . r Parallel Computing Archive at HENSA/Unix Oz The Oz Programming System Oz is a concurrent constraint programming language. Perl A powerful scripting and string manipulation language.

The WWW Virtual Library: Computing, Programming Languages r r

FAQ - Frequenly Asked Questions. Perl5. Information on the new object-oriented version of popular string manipulation and scripting languages.

Postscript. Internet PostScript Resources. Prolog . The logic programming language Prolog. Python Python is an object-oriented scripting and prototyping language which some prefer over Perl, TCL or Scheme. Python, developed at CWI in Amsterdam, is free, extensible, and runs on Unix, DOS and Mac. The Unix version has optional X11 and Motif interfaces and considerable multimedia support for SGI and Sun platforms. All documentation and sources for Python are now available on-line via the World-Wide-Web as well as via ftp . REXX Procedural language designed to be used as a macro language by arbitrary application programs. SGML Biased comments and a few pointers . The newsgroup . Sisal A high-performance functional language with implicit parallelism for scientific programming. TCL/TK Seperate page. TeX Sebastian Rahtz's archive in the UK , George D. Greenwade's archive in Texas, and one in Israel . Peter Flynn's in Ireland . VHDL VHDL Internation Users' Forum a non-profit industry group dedicated to the upkeep and adoption of the VHDL language. Visual Languages and Visual Programming Serarate page. WEB (cweb, fweb) See Literate programming . Z. Z (pronounced `zed') formal specification notation. See Also: q STING about new languages.

The WWW Virtual Library: Computing, Programming Languages q q q q

Programming Language Research. The Language List of around 2000 computer languages. Computing Languages Lists held at NCSA. Interface Technologies On-line Training Center. Comercial WWW based training center covering several programming languages.

[email protected]

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) r are) 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.

q q

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

 Objectif et nécessité 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 : q augmentation des coûts ; q difficultés d'évolution ; q non fiabilité ; q non respect des spécifications ; q 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 : s 'est perdue dans l'espace à cause d'une erreur de programme q la sonde Mariner vers Vénus s'est FORTRAN ; q 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 ; q 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) ; q le développement du compilateur PL1 de Control Data n'a jamais abouti ; q EDF a récemment renoncé à la mise en service de nouveaux systèmes de contrôle-commande de ses centrales 1400 méga-watts ; q la SNCF a rencontré des difficultés importantes pour la mise en service du système Socrate. q 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 [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 : q 34% maintenance évolutive : modification des spécifications initiales ; q 10% maintenance adaptative : nouvel environnement, nouveaux utilisateurs ; q 17% maintenance corrective : correction des bogues ; q 16% maintenance perfective : améliorer les performance sans changer les spécifications ;

Objectif et nécessité q q q q

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

 Qualité du 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é m ené à 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 [ 19]] : q Validité : aptitude d'un produit logiciel à remplir exactement ses fonctions, définies par le cahier des charges et les spécifications. s pécifications. q Fiabilité (ou robustesse) : aptitude d'un produit logiciel à fonctionner dans des conditions anormales. q Extensibilité : facilité avec laquelle un logiciel se prête à une modification ou à une extension des fonctions qui lui sont demandées. q Réutilisabilité : aptitude d'un logiciel à être réutilisé, en tout ou en partie, dans de nouvelles applications. q Compatibilité : facilité avec laquelle un logiciel peut être combiné avec d'autres logiciels. q Efficacité : Utilisation optimales des ressources matérielles. q Portabilité : facilité avec laquelle un logiciel peut être transférée sous différents environnements matériels et logiciels. q Vérifiabilité : facilité de préparation des procédures de test. q Intégrité : aptitude d'un logiciel à protéger son code et ses données contre des accès non autorisés. q 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é.

Qualité du logiciel


Modèles de développement du logiciel

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

 Modèles de développement du logiciel q q q

q

q

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

Modèles de développement du logiciel

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

q


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.

q

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


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 q q

q

q

Modèle de la cascade Modèle en V r Relations entre phases et activités selon le modèle en V Modèle en spirale r Risques majeurs du développement du logiciel r Exemple : Console de contrôle de lumière Modèles par incrément r Avantages r Risques r 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 la complexité toujours croissantes des logiciels.

q

langages de programmation, et surtout

Techniques de spécification r Énonces informels r Présentations formatées r Techniques graphiques ou semi-formelles r Techniques formelles


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

Conception 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 [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.

q q

Méthodes d'analyse et de conception Méthodes fonctionnelles r Analyse structurée r Analyse « temps réel » r Méthodes de conception fonctionnelle f onctionnelle


Méthodes fonctionnelles

Suivant : SADT: méthode d'analyse fonctionnelle et Précédent : Méthodes d'analyse et de Père : Conception du logiciel

conception

Sous-sections q q q

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

Méthodes fonctionnelles 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 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 ef fet : q ajout des diagramme de flot de contrôle et spécifications de contrôle : information d'activation/désactivation d'activation/désactivation des processus ; q utilisation des diagrammes états/transitions.

Méthodes fonctionnelles

 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 : q flux de données : modélisation des transformations des données. q entité-association ( relation) : structure logique des données. q 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 q

q q

q

Présentation générale r Historique Le Modèle SADT La syntaxe des diagrammes SADT r Actigrammes r Datagrammes s Remarques r Les textes explicatifs r Les diagrammes pour explication seulement r Liste hiérarchique et numérotation des diagrammes r Glossaires r Conditions d'activation r Processus de liens Travail en équipe r 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 q

Historique


Historique

Suivant : Le Modèle SADT Précédent : Présentation générale Père : Présentation générale

Historique q q q q

Développée à S OFTTECH (U.S.A.) en 1976 ; utilisée dans des projets industriels à ITT, T HOMSON, AÉROSPATIALE etc. peut être utilisée pour décrire (spécifier) n'importe quel système (cf. (cf.3.1.1 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: q Diagrammes d'activités ou actigrammes, représentant l'ensemble des activités du système. q Diagrammes de données ou datagrammes, montrant l'ensemble des données du système. q Textes explicatifs sur les diagrammes. q Diagrammes Pour Explication Seulement (PES). q Schéma de la hiérarchie du système analysé. q Glossaire définissant les principaux termes employés. q 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 q q

q q q q q q

Actigrammes Datagrammes r 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 q

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 q

q

q

q

q q

q

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.

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

Datagrammes

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

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 r epré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 © Copyright 1998 Mamoun Alissali. Tous droits réservés. Commentaires et suggestions suggestions.. Dernière mise à jour le 18 janvier 2000.

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 lecteur s. s. 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.


Conception du logiciel

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

Introduction

 Conception du logiciel q

Qualité de la conception r Modularité s Principes de Modularité s Principe d'ouverture/fermeture r Critères de qualité de la conception s Cohésion s Couplage s Compréhensibilité s Adaptabilité r Processus de conception de logiciel s 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 s atisfaction 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 1.2). ). Par la suite on considérera de préférence les facteurs qui facilitent f acilitent la gestion du produit tout le long de son cycle de vie. Il s'agit s 'agit essentiellement de l'extensibilité, la réutilisabilité, la compatibilité, 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é .

q

q

q

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


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 q q q q

Cohésion Couplage Compréhensibilité Adaptabilité

 Critères de qualité de la conception 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 : q sa cohésion ; q l'appellation : utilisation de noms significatifs ; q la documentation : établir un lien entre le monde m onde réel et le composant ; (parenthèse : documentation d'un projet C/Unix). q la complexité (une composante complexe nécessite un effort de documentation supplémentaire).

Critères de qualité de la conception

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.


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 [ 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 : q diagramme de flux de données ; q diagrammes de structure du logiciel ; q 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).

q q

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 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 progrramm ation qu'il soit d'application, plutôt que leur représentation terminale dans un langage de progrrammation 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 (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.

q q

Première définition Caratéristiques des objets r Identité : notion d'objet r Classification : notion de classe s Attributs s Opérations et méthodes r Polymorphisme : notion de surcharge r Héritage : notion de paratge



Suivant : Identité : notion d'objet Précédent : Première définition Père : Approche orientée objet

 Caratéristiques des objets q q

q q

Identité : notion d'objet Classification : notion de classe r Attributs r Opérations et méthodes Polymorphisme : notion de surcharge Héritage : notion de paratge


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 q q

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


Identification des valeurs d'entrée et de sortie s Construction du diagramme à flot de données s Description des fonctions s Identification des contraintes entre objets s Spécification des critères d'optimisation r Ajouter les opérations s Les opérations du modèle objet s Les opérations des événements s Les opérations des activités et des actions entre les états s Les opérations des fonctions s Les opérations « pense-bête » ( shopping-list ) s Simplification des opérations r Itération de l'analyse s Affiner le modèle d'analyse s Reformuler les besoins Conception du système r Introduction r Décomposer le système r Couches r Partitions r Topologie du système Identification des ressources r Concurrences intrinsèques r 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 r Transformation par lots ( Pipeline) s Principe s

q

q

q q q q q q q


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

q


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 :

q

q

Modèle objet r Identification des objets r Sélection des classes pertinentes r Préparation d'un dictionnaire de données r Identification des associations r Sélection des bonnes associations r Identification des attributs r Sélection des attributs r Affinage en utilisant l'héritage s La généralisation s La spécialisation s Remarque s Étude des figures 7.9 et 7.10 r Vérification des chemins d'accès r Itération de la modélisation objet s Détection de manque d'objets s Indices r Groupement des classes en modules s Exemple Modèle dynamique r Préparation des scénarios

Analyse

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

q

q

q


Ajouter les opérations

Suivant : Itération de l'analyse Précédent : Modèle fonctionnel Père : Analyse Sous-sections q q q q q q

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

 Ajouter les 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 f onctions 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.

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


Dernière mise à jour le 18 janvier 2000.

Itération de l'analyse

Suivant : Conception du système Précédent : Ajouter les opérations Père : Analyse Sous-sections q q

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 perm ettent 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 q q q q q

Introduction Décomposer le système Couches Partitions Topologie du système


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 q q

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 © Copyright 1998 Mamoun Alissali. Tous droits réservés. Commentaires et suggestions suggestions.. Dernière mise à jour le 18 janvier 2000.

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 © Copyright 1998 Mamoun Alissali. Tous droits réservés. Commentaires et suggestions suggestions.. Dernière mise à jour le 18 janvier 2000.

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 © Copyright 1998 Mamoun Alissali. Tous droits réservés. Commentaires et suggestions suggestions.. Dernière mise à jour le 18 janvier 2000.

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 © Copyright 1998 Mamoun Alissali. Tous droits réservés. Commentaires et suggestions suggestions.. Dernière mise à jour le 18 janvier 2000.

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 © Copyright 1998 Mamoun Alissali. Tous droits réservés. Commentaires et suggestions suggestions.. Dernière mise à jour le 18 janvier 2000.

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 © Copyright 1998 Mamoun Alissali. Tous droits réservés. Commentaires et suggestions suggestions.. Dernière mise à jour le 18 janvier 2000.

Conditions limites

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

 Conditions limites © Copyright 1998 Mamoun Alissali. Tous droits réservés. Commentaires et suggestions suggestions.. Dernière mise à jour le 18 janvier 2000.

Compromis de priorités

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

 Compromis de priorités © Copyright 1998 Mamoun Alissali. Tous droits réservés. Commentaires et suggestions suggestions.. Dernière mise à jour le 18 janvier 2000.

Architectures type

Suivant : Transformation par lots (Pipeline) Précédent : Compromis de priorités Père : OMT : méthode

d'analyse et

 Architectures type q

q

q

q

q

Transformation par lots (Pipeline) r Principe r Exemples r Importance relative des modèles r Étapes de la conception Transformation continue r Principe r Exemples r Importance relative des modèles r Étapes de la conception Interface interactive r Principe r Exemples r Importance relative des modèles r Étapes de la conception Simulation dynamique r Principe r Exemples r Importance relative des modèles r Étapes de la conception Systémes temps réel r Principe

Architectures type

Exemples r Importance relative des modèles r Étapes de la conception Gestionnaire de transactions r Principe r Exemples r Importance relative des modèles r Étapes de la conception r

q


Transformation par lots (Pipeline)

Suivant : Transformation continue Précédent : Architectures type Père : Architectures type Sous-sections q q q q

Principe Exemples Importance relative des modèles Étapes de la conception

 Transformation par lots (Pipeline ) 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 s ystè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 q

q

É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 m odèle objet cohérent et faiblement couplé aux autres modèles (ex. l'arbre d'analyse d'un compilateur).

Transformation par lots (Pipeline) q q

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 q q q q


 Transformation continue 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.

Importance relative des modèles 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. Modèle fonctionnel :

définit les valeurs en cours de traitement.

Transformation continue

tapes de la conception q

q

q

q

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 q q q q


 Interface interactive Principe Exemples Importance relative des modèles Modèle objet : Modèle dynamique : Modèle fonctionnel :

Étapes de la conception © Copyright 1998 Mamoun Alissali. Tous droits réservés. Commentaires et suggestions suggestions.. Dernière mise à jour le 18 janvier 2000.

Simulation dynamique

Suivant : Systémes temps réel Précédent : Interface interactive Père : Architectures type Sous-sections q q q q


 Simulation dynamique Principe Exemples Importance relative des modèles Étapes de la conception © Copyright 1998 Mamoun Alissali. Tous droits réservés. Commentaires et suggestions suggestions.. Dernière mise à jour le 18 janvier 2000.

Systémes temps réel

Suivant : Gestionnaire de transactions Précédent : Simulation dynamique Père : Architectures type Sous-sections q q q q


 Systémes temps réel Principe Exemples Importance relative des modèles Modèle objet : Modèle dynamique : Modèle fonctionnel :


Gestionnaire de transactions

Suivant : Conception des objets Précédent : Systémes temps réel Père : Architectures type Sous-sections q q q q


 Gestionnaire de transactions Principe Exemples Importance relative des modèles Modèle objet : Modèle dynamique : Modèle fonctionnel :


Conception des objets

Suivant : Management des projets logiciels Précédent : Gestionnaire de transactions Père : OMT :

méthode d'analyse et

 Conception des objets © Copyright 1998 Mamoun Alissali. Tous droits réservés. Commentaires et suggestions suggestions.. Dernière mise à jour le 18 janvier 2000.

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 © Copyright 1998 Mamoun Alissali. Tous droits réservés. Commentaires et suggestions suggestions.. Dernière mise à jour le 18 janvier 2000.

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 © Copyright 1998 Mamoun Alissali. Tous droits réservés. Commentaires et suggestions suggestions.. Dernière mise à jour le 18 janvier 2000.

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 © Copyright 1998 Mamoun Alissali. Tous droits réservés. Commentaires et suggestions suggestions.. Dernière mise à jour le 18 janvier 2000.

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é © Copyright 1998 Mamoun Alissali. Tous droits réservés. Commentaires et suggestions suggestions.. Dernière mise à jour le 18 janvier 2000.

Gestion des configurations

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

Introduction

 Gestion des configurations © Copyright 1998 Mamoun Alissali. Tous droits réservés. Commentaires et suggestions suggestions.. Dernière mise à jour le 18 janvier 2000.

Liste des figures

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

Liste des figures r r

r r r r r r r r r r r r r r r r r r r r r r r

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 tr aitement traiter la transaction du GAB Description de la fonction mise à jour du compte

Liste des figures r

r

Décomposition en couches : les deux couches « extrêmes » correspondent normalement à la description du problème. Bloc-diagramme d'une application typique.


Mamoun ALISSALILecturer

Mamoun ALISSALI Lecturer Page under construction Last update 29 février 2000

Version française

q

q

q q q

Research activities r Projects r Publications r Links for researchers Teaching activities r Teaching r Courses r Student Projects Other activities My coordoninates Some of my preferred links

Home

Research

Teaching

My pages has been visited Last update 29 f\'evrier 2000.

Seminars

Coordoninates

Links

IC2 Home Page

times since Feb. 29, 2000. Mail me. me .

Activités de recherche

Sous-sections q q q

Projets Publications Liens pour Chercheurs

 Activités de recherche Mamoun Alissali

Thème : Interface Vocale et Systèmes de Traitement Automatique de la Parole

 Projets COMPOST

Environnement de développpement pour la Synthèse de la parole. Réalisé au cours de ma thèse de doctorat à l'ICP. Co-financé par le CNET et le projet ESPRIT Multiworks. Le serveur Compost de synthèse en temps réel est accessible : à l'Institut l'Institut de la Communication Parlée Au LIUM

(en cours de réalisation). AMIBE

Applications Multimodales pour Interfaces et Bornes Évoluées. Projet GDR-PRC Communication Homme-Machine. Interface vocale en EIAO


 Publications Asynchronous Integration of Visual Information in an Automatic Speech Recognition System

ICSLP 96, Philadelphia, USA. (Version ( Version Postscript) Postscript) Asynchronous Integration of Audio and Visual Sources in Bi-modal Automatic Speech Recognition

EUSIPCO 96, Trieste, Italy. (Version ( Version Postscript) Postscript) Intégration Asynchrone des Informations Auditives et Visuelles dans un Système de Reconniassance de la Parole

XXIèmes Journées d'Étude sur la Parole. P arole. Avignon, France, 1996. Le compilateur de règles Compost et son application pour l'analyse syntactico-prosodique dans un système de synthèse à partir du texte

XXèmes Journées d'Étude sur la Parole. Trégastel, France, septembre 1994. Prosodic Parsing Based on Parsing of Minimal Syntactic Structures

The Second ESCA Workshop on Speech Synthesis. Arden House, USA. 1994. Architecture logicielle pour la synthèse de la parole

Premier Colloque des Jeunes Chercheurs en Sciences Cognitives. La Motte d'Aveillans, France, mars 1994. Architecture logicielle pour la synthèse multilingue de la parole

Thèse de Docteur Ingénieur de l'INPG. Grenoble, France, mars 1993. COMPOST: A Client-Server Model for Applications Using Text-to-Speech

EuroSpeech'93, Berlin, Germany. (Version ( Version Postscript) Postscript) COMPOST : un Serveur de Synthèse de Parole Multilingue

Revue du Traitement du Signal, Vol. 9, no. 4, 1992.

 Liens pour Chercheurs Fondation Kastler

Accueil de chercheurs étrangers (guide bilingue français/anglais).


Accueil

Recherche

Enseignement


Séminaires l'IC2

Coordonnées

Liens

Page d'accueil de

fois depuis le 29 février 2000. Commentaires et suggestions suggestions..

Activités d'enseignement

Sous-sections q q q

Enseignements Supports de cours Projets des étudiants

 Activités d'enseignement Mamoun Alissali

 Enseignements DEA

Systèmes de Traitement Automatique de la Parole. DRT

Génie Logiciel. Licence MIME

Projets Logiciels. DEUG MIME

Génie Logiciel et Projets Logiciels. CNAM Cycle B

Génie Logiciel. DEUG MIAS 2n

Introduction à l'Informatique.

 Supports de cours En accès direct (ou en cours) :


Introduction au Génie Logiciel Algorithmique en C/UNIX Exemples Scripts C-Shell Programmes et petits logiciels en C

 Projets des étudiants Dossiers d'analyse de projets, en SADT et OMT, réalisés par les étudiants. Attention : Ces dossiers sont présentés tels que, mes corrections n'y figurent pas pour l'instant IUP MIME Licence MIME 1997/98

Projets en cours. (accès restreint) DEUG MIME 1997/98

Projets en cours. (accès restreint) DEUG MIME 1996/97

Conception d'un logiciel d'aide à OMT. Sont disponibles les analyses des sous-systèmes : Modèle objet (1) Modèle objet (2) Modèle dynamique

(à cause de problèmes techniques ce document ne contient pas les figures) CNAM 1996/97

Analyse OMT d'un annuaire électronique : équipe 1 équipe 2

Accueil

Recherche

Enseignement

Séminaires l'IC2

Coordonnées

Liens

Page d'accueil de




Autres activités

Sous-sections q

q

Organisation du séminaire du LIUM r Les exposés r Exposés des années précédentes Gestion de l'installation locale (LA)T EX

 Autres activités  Organisation du séminaire du LIUM Le séminaire a lieu dans les locaux de l'IC 2tous les jeudis de 13h30 à 14h30. Il s'adresse principalement aux chercheurs du LIUM et aux étudiants du DEA CHM-IE, mais il est ouvert au public. Merci de me le signaler si vous souhaitez y assister.

Les exposés Titre, coordonnées de l'intervenant et souvent le résumé.

Exposés des années précédentes

 Gestion de l'installation locale (LA)TEX Voir le guide local. local.

Accueil

Recherche

Enseignement

Séminaires l'IC2

Coordonnées

Liens

Page d'accueil de

Autres activités



Mes coordonnées

 Mes coordonnées Mamoun ALISSALI LIUM UNIVERSITE DU MAINE Avenue Olivier Messiaen 72085 LE MANS CEDEX 9 (33-2) -02-43 83 38 47 (33-2) -02-43 83 38 68 e-mail : [email protected]

Accueil

Recherche

Enseignement


Séminaires l'IC2

Coordonnées

Liens

Page d'accueil de


Quelques unes de mes pages WEB préférées

 Quelques unes de mes pages WEB préférées Method Engineering Encyclopaedia

Exemples de différentes méthodes d'analyse et de conception de logiciels (en anglais !).

UNIX Reference Desk

L'informatique sans Microsoft

Non seulement c'est possible, mais c'est mieux !!

CTAN

Archives et navigateur T EX/LATEX.

Syria Online

Un site qui présente mon pays d'origine, avec plein de photos dont une bonne quantité de la capitale, Damas Damas,, et quelques unes de ma ville d'origine, Yabrud Yabrud..

Guitar Playing.

Accueil

Recherche

Enseignement

Séminaires l'IC2

Coordonnées

Liens

Page d'accueil de

Quelques unes de mes pages WEB préférées



Séminaire du LIUM

Séminaire du LIUM Responsable M. ALISSALI Année Universitaire 1999/2000

Sommaire q q q q q

Octobre 1999 Novembre 1999 Décembre 1999 Février 2000 Mars 2000

[email protected]

GL

Recommend Documents