Modélisation des Systèmes d'Information
Partie 2 : Différentes Méthodes de Développement des Systèmes d’Information
I. SURVOL DES DIFFERENTES METHODES: 1. Les Méthodes Cartésiennes : La Méthode SADT : Méthode d'analyse fonctionnelle La méthode SADT (Structured Analysis Design Technic) est une méthode d'analyse hiérarchique et descendante apparue en 1977 au sein de la société Sof'Tech Inc. C'est une méthode d'analyse par niveaux successifs d'approche descriptive d'un ensemble quel qu'il soit. Elle a été introduite en Europe à partir de 1982. Les auteurs la présentent comme une méthode pour « communiquer des problèmes ». On peut appliquer SADT à la gestion d'une entreprise tout comme à un système automatisé La méthode SADT est fondée sur un formalisme graphique et textuel facile à apprendre. Elle permet d'une part de modéliser le problème posé (informatique, automatique ou autre), avant de chercher à en extraire une solution, et d'autre part d'assurer une communication efficace entre les différents intervenants concernés par le système à analyser.

Historique
Développée à SOFTTECH (U.S.A.) en 1976 ; Utilisée dans des projets industriels à ITT, THOMSON, AÉROSPATIALE etc. Peut être utilisée pour décrire (spécifier) n'importe quel système 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 Un modèle SADT représente une image d'un système qu'on veut appréhender. La technique d'analyse structurée identifie et organise les détails d'un tel système suivant une hiérarchie parfaitement référencée. Un modèle SADT est composé de :
• Diagrammes d'activités ou actigrammes, représentant l'ensemble des activités du système. • Diagrammes de données ou datagrammes, montrant l'ensemble des données du système. • Textes explicatifs sur les diagrammes. • Diagrammes Pour Explication Seulement (PES). • Schéma de la hiérarchie du système analysé. • Glossaire définissant les principaux termes employés. • Conditions d'activation.

Le « langage » SADT est composé de diagrammes (actigrammes et datagrammes) obtenus par raffinements successifs et organisés en hiérarchie. Plus concrètement, il s'agit de boîtes et de flèches utilisées pour représenter les notions suivantes :

1

Les entrées : ce sont les flèches horizontales entrant dans les boîtes. Les sorties : ce sont les flèches horizontales sortant des boîtes. Les mécanismes : ce sont les flèches venant du bas du schéma vers le bas des boîtes. Les contrôles : les flèches venant du haut du schéma et pointant vers le haut des boîtes. 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 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ée, les mécanismes expriment le support de stockage (physique ou logique) de la donnée. Les textes explicatifs Ils accompagnent les diagrammes 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 toutefois 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 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 Les n uds d'un modèle SADT sont numérotés d'une façon précise. Le premier noeud représente le système global. Il porte le numéro particulier A-0 (resp. D-0) pour le modèle des actigrammes (resp. datagrammes). Il sera décomposé sur la feuille A0 (resp. D0) en plusieurs noeuds 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. 2

Les Actigrammes :
• La boîte représente une action (indiquée par un verbe à l'infinitif). • Les entrées sont transformées en sorties par l'action ou servent à alimenter l’action. Elles ne sont donc pas forcément modifiées mais sont nécessaires au fonctionnement de l’action. Elles sont interprétées comme étant des données. • Le mécanisme effectue la transformation (nous pouvons interpréter ainsi : « le mécanisme est le processeur », l'action étant « le processus »). • Le contrôle n'est pas transformé par l'action mais permet la transformation. Le contrôle peut être vu soit comme des paramètres ou soit comme un déclencheur. Données de contrôle

Données d'entrée

AGIR

Données de sortie

Unité de traitement

• • • •

Les datagrammes
La boîte représente les données (indiquées par un nom). Les entrées représentent les actions qui produisent les données de la boîte. Les sorties représentent les actions qui utilisent les données de la boîte. Le mécanisme est le support des données.

On peut ajouter des étiquettes aux flèches en les reliant par un zigzag. En outre, les flèches qui relient les boîtes représentent les contraintes fonctionnelles qui existent entre les boîtes, mais ne représentent en aucun cas un flux de commande et n'ont pas de signification séquentielle (n'impliquent pas de notion d'ordre d'exécution dans le temps). Activités de contrôle

Activités Productrices

DONNEE

Activités Consommatrice s

Unité de stockage

3

Analyse descendante
La méthode d’analyse descendante permet de comprendre pourquoi un système existe, ou doit être conçu, quelles fonctions il doit remplir et enfin, comment elles sont réalisées. Et cela, quelle qu’en soit la complexité. La méthode, appuyée par un modèle graphique, procède par approche descendante en ce sens que l’on va du plus général au plus détaillé, en s’intéressant aux activités du système. Plusieurs modèles SADT correspondant à différents points de vue du système sont souvent établis pour une meilleure compréhension. En particulier, la perception d'un système n'est pas la même pour l'utilisateur, le concepteur ou le programmeur. De la même manière, plusieurs modèles SADT différents peuvent être conçus pour répondre à une même demande. Les deux principes de base sont : 1. Procéder par analyse descendante : Le premier niveau du modèle est en général très abstrait, et progressivement les activités et les moyens nécessaires à leur réalisation sont détaillés. 2. Délimiter le cadre de l’analyse : afin d’aborder l’analyse et la description du système, il est fondamental de préciser le contexte (limite du système), le point de vue et l’objectif de l’analyse.

Description de la méthode
La première phase est la modélisation du système décrit précédemment qui en montre les fonctions. Le contexte est identifié par les flèches qui entrent ou sortent de cette boîte mère. La décomposition en éléments, ou sous-fonctions de cette boîte-mère permet d’affiner la perception du système et sa structure. Cette décomposition doit faire apparaître de trois à six éléments maximum. Ces éléments ou boîtes sont des activités. Les flèches qui les relient représentent les contraintes qui existent entre elles, mais ne représentent en aucun cas un flux de commande et n’ont pas de signification séquentielle (n’impliquent pas de notions d’ordre d’exécution dans le temps). Les diagrammes ainsi construits sont des actigrammes ou encore diagrammes d’activité. Si le niveau de décomposition ne permet pas une totale compréhension du système, on procède à une nouvelle construction d’actigrammes correspondant aux boîtes à analyser plus en détail. On définit ainsi successivement : La boîte-mère A-0 (lire A moins zéro). Le diagramme enfant de premier niveau A0. Les diagrammes enfants de chaque boîte du diagramme précédent (qui devient diagrammemère) soit : A1, A2, A23,... Les principales règles régissant la construction des diagrammes sont : Chaque flèche entrant ou sortant de sa boîte-mère doit se retrouver sur le diagramme enfant. Les flèches sont affectées d’un label indiquant leur nature. Celui-ci peut être remplacé par un code dont la signification est donnée en marge. Les supports peuvent ne pas être mentionnés si cela n’éclaire pas la compréhension. On ne mentionne que les éléments nécessaires à ce que l’on veut montrer. 4

C1

C2

E

BOITE MERE
C1 E

A-0

S

Plus général

1 2 3
C2

C2

A0
S

A3
S

Plus détaillée

Démarche
1. On commence par le diagramme de plus haut niveau A-0 (A moins zéro) représentant la finalité du système. 2. Ensuite, on descend dans les niveaux en traçant le diagramme de niveau A0 (A zéro) puis A1 et ainsi de suite en respectant la hiérarchie des niveaux. On décrit de cette manière les sous-fonctions du système ce qui permet d'en affiner la perception et la structure. Si le niveau de décomposition ne permet pas une totale compréhension du système, on procède à une nouvelle construction d'actigrammes. Enfin, il est fondamental que le modèle circule entre les partenaires du projet afin qu'un consensus soit clairement établi avant de passer au début de la phase de conception et d’implémentation.

Règles d'écritures des diagrammes
• Chaque flèche entrant ou sortant de sa boîte-mère doit se retrouver sur le diagramme enfant. • Les flèches sont affectées d'un label indiquant leur nature. • Les supports peuvent ne pas être mentionnés si cela n'éclaire pas la compréhension. • Il est recommandé de décomposer une boîte en trois boîtes au minimum et sept boîtes au 5

maximum. • Il est recommandé de présenter les boîtes suivant une même diagonale. • Les flèches parenthésées, également appelées « flèches tunnel », indiquent qu'un flux de données est présent dans une partie du modèle bien qu'il ne soit pas dessiné. On trouve deux types de flèches tunnel : • La flèche tunnel dont les parenthèses entourent l'extrémité de la flèche qui est connectée à une boîte, qui signifie que cette flèche existe implicitement dans toutes les boîtes résultant de la décomposition de celle-ci.

( )

• La flèche tunnel dont les parenthèses se trouvent à l'autre extrémité, donc près des frontières du diagramme, qui signifie que cette flèche existe implicitement dans toutes les boîtes qui sont hiérarchiquement au dessus de la boîte concernée ; c'est-à-dire sa boîte mère, grand-mère, ... jusqu'à A0 compris. ( )

Exemple de décomposition

Dico Entrées utilisateur

Analyser la syntaxe

Dico enrichi

Affichage

6

Dico

Lire et préparer Dico A1

Dico préparé Afficher écran Traiter info et compléter Dico A2 Dico enrichi Sauver Dico A3
A0

Entrées utilisateur

Dico enrichi et sauvé

Dico (Sous forme texte)

Lire le Dico A11

catégories

Transformer catégories en liste A12 expression Transformer en liste de listes A13
A1

Dico préparé (en liste de listes)

7

Position de SADT dans la gestion d'un projet

SADT va permettre d'aider à la gestion d'un projet. Par son rôle d'analyse, il sera possible de l'utiliser à tous niveaux de la conception du SA au codage (programmation du système automatisé). SADT est avant tout un langage de communication. Cette communication se fait à différents niveaux. Au niveau de l'élaboration du projet tout d'abord en permettant par son formalisme à chacun de participer, ensuite lors d'explications à des intervenants extérieurs son formalisme permet à chacun d'appréhender le SA.

Objectifs d'une analyse S.A.D.T :
L'objectif de cette étude doit mener les intervenants (ingénieurs, techniciens, opérateurs) à un tout qui soit cohérent et homogène avec le système à étudier. Dans n'importe quel système automatisé, circulent un certain nombre de flux de données. Les flux les plus caractéristiques sont : - les flux de pièces : flux qui caractérisent la valeur ajoutée à un produit. - Les flux d'informations : ces flux vont permettre à l'outil de production de pouvoir évoluer. - Les flux énergétiques. - les flux divers (copeaux, fluides de coupe, rejets divers, etc...). 8

L'analyse SADT va permettre d'organiser ces flux de données pour donner une vision globale du système puis par une analyse des niveaux successifs, permettre de préciser de plus en plus finement le rôle de chacun des éléments du système. La finesse de cette description dépendra directement des besoins des utilisateurs.

Conclusions
SADT est un outil graphique de représentation. SADT oblige à consigner par écrit les décisions d'une équipe de travail. Ceci permet progressivement de créer une documentation complète. c) SADT est un travail d'équipe qui demande discipline et coordination. Le SADT est un produit pour communiquer et pour être diffusé. d) Son formalisme conduit à une représentation structurée ascendante ou descendante. e) Si SADT est utilisé complètement (Actigrammes et Datagrammes) il permet de programmer directement un système automatisé.
a) b)

Bibliographie http://www.cyber.uhp-nancy.fr/demos/MAIN-002/chap_deux/pourq.html http://philippe.berger2.free.fr/automatique/cours/sadt/sadt.htm http://www.univ-pau.fr/~nancy/sadt/ http://www.ac-reunion.fr/pedagogie/si/Ressources/les_dossiers_techniques_par_syst.htm
Michel Lissandre, "Maîtriser SADT", Armand Colin, 1990, 219 pages, ISBN 2200420226 "SADT, un langage pour communiquer", IGL Technology, Eyrolles, 1989, 336 pages, ISBN 2212081855

9

2. Les Méthodes Systémiques :
2.1. Présentation de la méthode MERISE: MERISE est une méthode de conception, de développement et de réalisation de projets informatiques. Le but de cette méthode est d'arriver à concevoir un système d'information. La méthode MERISE est basée sur la séparation des données et des traitements à effectuer en plusieurs modèles conceptuels et physiques. La séparation des données et des traitements assure une longévité au modèle. En effet, l'agencement des données n'a pas à être souvent remanié, tandis que les traitements le sont plus fréquemment. La méthode MERISE date de 1978-1979, et fait suite à une consultation nationale lancée en 1977 par le ministère de l'Industrie dans le but de choisir des sociétés de conseil en informatique afin de définir une méthode de conception de systèmes d'information. Les deux principales sociétés ayant mis au point cette méthode sont le CTI (Centre Technique d'Informatique) chargé de gérer le projet, et le CETE (Centre d'Etudes Techniques de l'Equipement) implanté à Aix-en-Provence. 2.2. Cycle d'abstraction de conception des systèmes d'information: La conception du système d'information se fait par étapes, afin d'aboutir à un système d'information fonctionnel reflétant une réalité physique. Il s'agit donc de valider une à une chacune des étapes en prenant en compte les résultats de la phase précédente. D'autre part, les données étant séparées des traitements, il faut vérifier la concordance entre données et traitements afin de vérifier que toutes les données nécessaires aux traitements sont présentes et qu'il n'y a pas de données superflues. Cette succession d'étapes est appelée cycle d'abstraction pour la conception des systèmes d'information :

10

L'expression des besoins est une étape consistant à définir ce que l'on attend du système d'information automatisé, il faut pour cela :
• •

faire l'inventaire des éléments nécessaires au système d'information délimiter le système en s'informant auprès des futurs utilisateurs

Cela va permettre de créer le MCC (Modèle Conceptuel de la Communication) qui définit les flux d'informations à prendre en compte. L'étape suivante consiste à mettre au point le MCD (Modèle Conceptuel des Données) et le MCT (Modèle conceptuel des traitements) décrivant les règles et les contraintes à prendre en compte. Le modèle organisationnel consiste à définir le MOT (Modèle Organisationnel des Traitements), décrivant les contraintes dues à l'environnement (organisationnel, spatial et temporel). Le modèle logique représente un choix logiciel pour le système d'information. Le modèle physique reflète un choix matériel pour le système d'information. 3. l’Approche Objet : 3.1. Introduction : Aujourd'hui, en programmation, il existe 2 principaux modèles de représentation du monde : Le modèle fonctionnel (que nous venons de voir). Le modèle objet (que nous allons étudier). Dans une approche fonctionnelle, vos programmes sont composés d'une série de fonctions, qui assurent ensemble certains services. Il s'agit d'une approche logique, cohérente et intuitive de la programmation. Cette approche a un avantage certain appelé la factorisation des comportements (c'est à dire que pour créer une fonction d'une application, rien ne vous empêche d'utiliser un autre ensemble de fonctions (qui sont donc déjà écrites)). Mais, l'approche fonctionnelle a aussi ses défauts, comme par exemple une maintenance complexe en cas d'évolution de votre application (une simple mise à jour de l'application à un point donné peut avoir un impact en cascade sur d'autres fonctions de notre application). L'application sera alors retouchée dans sa globalité. L'approche fonctionnelle n'est pas adaptée au développement d'applications qui évoluent sans cesse et dont la complexité croit continuellement (plusieurs dizaines de milliers de lignes de code). Exemple: les langages Pascal, C, Algol, etc. L'approche objet répond aux limites de l'approche fonctionnelle par le concept d’encapsulation (qui applique le principe d’abstraction) des données et des opérations qui les manipulent dans les objets, c’est-à-dire qu’un objet n’est accessible que par ces opérations visibles (son interface externe) et son implémentation (les structures de données associées) est cachée. Elle apporte l’indépendance entre les programmes, les données et les procédures parce que les programmes peuvent partager les mêmes objets sans avoir à se connaître. 11

La programmation orientée objet consiste à modéliser informatiquement un ensemble d'éléments d'une partie du monde réel (que l'on appelle domaine) en un ensemble d'entités informatiques. Ces entités informatiques sont appelées objets. Il s'agit de données informatiques regroupant les principales caractéristiques des éléments du monde réel (taille, couleur, ...). L'approche objet est une idée qui a désormais fait ses preuves. Simula a été le premier langage de programmation à implémenter le concept de classes en 1967 ! En 1976, Smalltalk implémente les concepts d'encapsulation, d'agrégation, et d'héritage (les principaux concepts de l'approche objet). D'autre part, de nombreux langages orientés objets ont été mis au point dans un but universitaire (Eiffel, Objective C, Loops, etc.). La difficulté de cette modélisation consiste à créer une représentation abstraite, sous forme d'objets, d'entités ayant une existence matérielle (chien, voiture, ampoule, ...) ou bien virtuelle (sécurité sociale, temps, ...). L’approche objet a introduit indépendamment de tout langage de programmation à l’objet trois concepts de base : objet, classe et héritage entre classes. Les concepts objet et classe sont interdépendants, c’est-à-dire qu’un objet est une instance d’une classe et la classe décrit la structure et le comportement communs d’objets (ses instances). L'objet: Un objet est une abstraction d’un élément du monde réel. Il possède des informations, par exemple nom, prénom, adresse, etc., et se comporte suivant un ensemble d’opérations qui lui sont applicables. De plus, un ensemble d'attributs caractérisent l'état d'un objet, et l'on dispose d'un ensemble d'opérations (les méthodes) qui permettent d'agir sur le comportement de notre objet. Un objet est l'instance d'une classe, et une classe est un type de données abstrait, caractérisé par des propriétés (ses attributs et ses méthodes) communes à des objets, qui permet de créer des objets possédant ces propriétés. Objet = identité + état (attributs) + comportement (méthodes) • L’identité : L’objet possède une identité, qui permet de le distinguer des autres objets, indépendamment de son état. On construit généralement cette identité grâce à un identifiant découlant naturellement du problème (par exemple un produit pourra être repéré par un code, une voiture par un numéro de série, ...) • Les attributs : Il s’agit des données caractérisant l’objet. Ce sont des variables stockant des informations d’état de l’objet • Les méthodes (appelées parfois fonctions membres): Les méthodes d’un objet caractérisent son comportement, c’est-à-dire l’ensemble des actions (appelées opérations) que l’objet est à même de réaliser. Ces opérations permettent de faire réagir l’objet aux sollicitations extérieures (ou d’agir sur les autres objets). De plus, les opérations sont étroitement liées aux attributs, car leurs actions peuvent dépendre des valeurs des attributs, ou bien les modifier. La notion de classe: On appelle classe la structure d’un objet, c’est-à-dire la déclaration de l’ensemble des entités qui composeront un objet. Les objets de même nature ont en général la même 12

structure et le même comportement. La classe factorise les caractéristiques communes de ces objets et permet de les classifier. Un objet est donc, une instanciation d’une classe, c’est la raison pour laquelle on pourra parler indifféremment d’objet ou d’instance (éventuellement d’occurrence). Toutes les instances d'une classe constituent l'extension de la classe. Classe = instanciation + attributs (variables d'instances) + opérations • L’instanciation : L’objet possède une identité, qui permet de le distinguer des autres objets, indépendamment de son état. L'instanciation représente la relation entre un objet et sa classe d'appartenance qui a permis de le créer. • Les attributs: (appelés aussi variables d'instances ou données membres) Il s'agit des données représentant l'état de l'objet. Ils ont un nom et soit un type de base (simple ou construit) soit une classe (l'attribut référençant un objet de la même classe ou une autre classe). • Les opérations: (appelées parfois méthodes ou fonctions membres) Il s'agit des opérations applicables aux objets de la classe. Elles peuvent modifier tout ou en partie l'état d'un objet et retourner des valeurs calculées à partir de cet état. Exemple: Si on définit la classe voiture, les objets Peugeot 406, Renault 18 seront des instanciations de cette classe. Il pourra éventuellement exister plusieurs objets Peugeot 406, différenciés par leur numéro de série. Mieux: deux instanciations de classes pourront avoir tous leurs attributs égaux sans pour autant être un seul et même objet. C'est le cas dans le monde réel, deux T-shirts peuvent être strictement identiques et pourtant ils sont distincts. D'ailleurs en les mélangeant il serait impossible de les distinguer... L’encapsulation: Le concept d’encapsulation est un mécanisme consistant à rassembler les données et les méthodes au sein d’une structure en cachant l’implémentation de l’objet, c’est-à-dire en empêchant l’accès aux données par un autre moyen que les services proposés. L'utilisateur d'une classe n'a pas forcément à savoir de quelle façon sont structurées les données dans l'objet, cela signifie qu'un utilisateur n'a pas à connaître l'implémentation. Ainsi, en interdisant l'utilisateur de modifier directement les attributs, et en l'obligeant à utiliser les fonctions définies pour les modifier (appelées interfaces). L’encapsulation permet donc de garantir l’intégrité des données contenues dans l’objet (on pourra par exemple s'assurer que le type des données fournies est conforme à nos attentes, ou encore que les données se trouvent bien dans l'intervalle attendu).. L’encapsulation permet de définir des niveaux de visibilité des éléments de la classe. Ces niveaux de visibilité définissent les droits d’accès aux données selon que l’on y accède par une méthode de la classe elle-même, d’une classe héritière, ou bien d’une classe quelconque. Il existe trois niveaux de visibilité : • Publique : Les fonctions de toutes les classes peuvent accéder aux données ou aux méthodes d’une classe définie avec le niveau de visibilité public. Il s’agit du plus bas niveau de protection des données. • Protégée : l’accès aux données est réservé aux fonctions des classes héritières, c’està-dire par les fonctions membres de la classe ainsi que des classes dérivées. • Privée : l’accès aux données est limité aux méthodes de la classe elle-même. Il s’agit du niveau de protection des données le plus élevé. 13

La notion d'héritage: L’héritage (en anglais inheritance) est un principe propre à la programmation orientée objet, permettant de créer une nouvelle classe à partir d’une classe existante. Le nom d’"héritage" (ou parfois dérivation de classe) provient du fait que la classe dérivée (la classe nouvellement créée) contient les attributs et les méthodes de sa superclasse (la classe dont elle dérive). L’intérêt majeur de l’héritage est de pouvoir définir de nouveaux attributs et de nouvelles méthodes pour la classe dérivée, qui viennent s’ajouter à ceux et celles héritées. Par ce moyen on crée une hiérarchie de classes de plus en plus spécialisées. Cela a comme avantage majeur de ne pas avoir à repartir de zéro lorsque l'on veut spécialiser une classe existante. De cette manière il est possible d'acheter dans le commerce des librairies de classes, qui constituent une base, pouvant être spécialisées à loisir (on comprend encore un peu mieux l'intérêt pour l'entreprise qui vend les classes de protéger les données membres grâce à l'encapsulation...). Hiérarchie des classes: La hiérarchie des classes ou l'association (relationship) est un concept essentiel pour la modélisation des données. On peut représenter sous forme de hiérarchie de classes, parfois appelée arborescence de classes, la relation de parenté qui existe entre les différentes classes. La hiérarchie ou arborescence commence par une classe générale appelée superclasse (classe de base, classe parent, classe ancêtre, classe mère ou classe père). Puis les classes dérivées (classe fille ou sous-classe) deviennent de plus en plus spécialisées. Ainsi, on peut généralement exprimer la relation qui lie une classe fille à sa mère par la phrase "est un" (de l'anglais "is a"). Héritage multiple: Certains langages orientés objet, tels que le C++, permettent de faire de l’héritage multiple. Ce qui signifie qu’ils offrent la possibilité de faire hériter une classe de deux superclasses. Ainsi, cette technique permet de regrouper au sein d’une seule et même classe les attributs et les méthodes de plusieurs classes. L'héritage multiple représente le mécanisme par lequel une sous-classe hérite des propriétés de plus d'une super-classe. Polymorphisme: Le nom de polymorphisme vient du grec et signifie qui peut prendre plusieurs formes. Cette caractéristique essentielle de la programmation orientée objet caractérise la possibilité de définir plusieurs fonctions de même nom mais possédant des paramètres différents (en nombre et/ou en type), si bien que la bonne fonction sera choisie en fonction de ses paramètres lors de l’appel. Le polymorphisme représente la faculté d'une opération de s'appliquer à des objets de classes différentes. On distingue généralement trois types de polymorphisme :
• • •

Le polymorphisme ad hoc (également surcharge ou overloading) Le polymorphisme d'héritage (également redéfinition, spécialisation ou overriding) Le polymorphisme paramétrique (également généricité ou template)

Le polymorphisme ad hoc: Le polymorphisme ad hoc permet d'avoir des fonctions de même nom, avec des fonctionnalités similaires, dans des classes sans aucun rapport entre elles (si ce n'est bien sur d'être des filles de la classe objet). Par exemple, la classe complexe, la classe image et la classe lien peuvent avoir chacune une fonction "afficher". Cela permettra de ne pas avoir à se soucier du type de l'objet que l'on a si on souhaite l'afficher à l'écran. 14

Le polymorphisme ad hoc permet ainsi de définir des opérateurs dont l'utilisation sera différente selon le type des paramètres qui lui sont passés. Il est donc possible par exemple de surcharger l'opérateur + et de lui faire réaliser des actions différentes selon qu'il s'agit d'une opération entre deux entiers (addition) ou entre deux chaînes de caractères (concaténation). Le polymorphisme d'héritage: La possibilité de redéfinir une méthode dans des classes héritant d'une classe de base s'appelle la spécialisation. Il est alors possible d'appeler la méthode d'un objet sans se soucier de son type intrinsèque : il s'agit du polymorphisme d'héritage. Ceci permet de faire abstraction des détails des classes spécialisées d'une famille d'objet, en les masquant par une interface commune (qui est la classe de base). Imaginons un jeu d'échec comportant des objets roi, reine, fou, cavalier, tour et pion, héritant chacun de l'objet pièce. La méthode mouvement () pourra, grâce au polymorphisme d'héritage, effectuer le mouvement approprié en fonction de la classe de l'objet référencé au moment de l'appel. Cela permettra notamment au programme de dire piece.mouvement sans avoir à se préoccuper de la classe de la pièce. Le polymorphisme paramétrique: Le polymorphisme paramétrique, appelé généricité, représente la possibilité de définir plusieurs fonctions de même nom mais possédant des paramètres différents (en nombre et/ou en type). Le polymorphisme paramétrique rend ainsi possible le choix automatique de la bonne méthode à adopter en fonction du type de donnée passée en paramètre. Le polymorphisme rend possible le choix automatique de la bonne méthode à adopter en fonction du type de donnée passée en paramètre. Ainsi, on peut par exemple définir plusieurs méthodes homonymes addition () effectuant une somme de valeurs: - int addition (int, int) pourra retourner la somme de deux entiers. - float addition (float, float) pourra retourner la somme de deux flottants. - char addition (char, char) pourra définit au gré de l’auteur la somme de deux caractères. - etc. …. On appelle signature le nombre et le type (statique) des arguments d'une fonction. C'est donc la signature d'une méthode qui détermine quelle méthode sera appelée. 3.2. Les avantages de l’approche objet: La modélisation des objets de l’application: Consiste à modéliser informatiquement un ensemble d’éléments d’une partie du monde réel en un ensemble d’entités informatiques. Ces entités informatiques sont appelées objet. La modularité et la réutilisabilité: La programmation modulaire permet la réutilisation du code, via l'écriture de librairies. L’extensibilité: Pour une meilleure productivité des développeurs et une plus grande qualité des applications). La maîtrise de la complexité d’un système repose sur trois principes : • • L’abstraction (voir le comportement des objets indépendamment de leur représentation interne). La décomposition (des objets complexes en objets plus simples) 15

•

La connexion (des objets suivant leurs interactions)

3.3. Les méthodes objet: La modélisation objet consiste à créer une représentation informatique des éléments du monde réel, sans se préoccuper de l’implémentation, ce qui signifie indépendamment d’un langage de programmation. Il s’agit donc de déterminer les objets présents et d’isoler leurs données et les fonctions qui les utilisent. Pour cela, des méthodes de conception et de développement orientées objet ont été mises au point. Entre 1970 et 1990, de nombreux analystes ont mis au point des approches orientées objets, si bien qu’en 1994 il existait plus de 50 méthodes objet. Toutefois seules 3 méthodes ont véritablement émergées : • La méthode OMT de Rumbaugh • La méthode BOOCH’93 de Booch • La méthode OOSE de Jacobson A partir de 1994, Rumbaugh et Booch (rejoints en 1995 par Jacobson) ont unis leurs efforts pour mettre au point la méthode UML (Unified Modeling Language), qui permet de définir une notation standard en incorporant les avantages de chacune des méthodes précédentes (ainsi que celles d’autres analystes). 4. Présentation générale de la méthode OMT: 4.1. Introduction: OMT (Object Modeling Technique) utilise trois modèles pour décrire un système : objet, dynamique et fonctionnel. Ces trois modèles sont complémentaires et inter-reliés. Le modèle objet est fondamental et préalable aux deux autres. OMT permet de modéliser un système selon trois points de vue complémentaires, chacun capturant des aspects essentiels du système, tous requis pour une description complète: • • • Le modèle objet est le point de vue des données. Le modèle dynamique est le point de vue du contrôle et des comportements. Le modèle fonctionnel est le point de vue des transformations apportées aux données.

Un logiciel combine normalement ces trois aspects: il transforme (modèle 3) des données (modèle 1) d'une façon ordonnée dans le temps (modèle 2). 4.2. Esprit de la méthode: • • Modélisation d'objets du monde réel. Utilisation de ces objets pour concevoir un système indépendamment des langages d'implantation. Meilleure compréhension des besoins Spécification et conception plus précise Meilleure maintenabilité des systèmes réalisés La même méthode (concepts + notations) peut être utilisée tout au long du cycle de développement. Il n'est donc pas nécessaire de traduire une formulation en une autre à chaque étape, comme le nécessitent d'autres approches. un jeu de concepts orientés objet une notation graphique indépendante du langage de programmation, utilisable pour : analyser les besoins 16

4.3. Avantages: • • • •

4.4. Les outils: • •

spécifier et concevoir implanter la solution 4.5. Le cycle de vie logiciel (abrégé): • • • • définition des besoins spécification des besoins spécification de conception programmation

4.6. Généralité de la méthode: OMT n'est pas une méthode dédiée explicitement à la programmation orientée objet. On montre l'intérêt de la méthode pour spécifier des applications dont le langage cible n'est pas orienté objet. OMT permet l'échange clair et non ambigu des idées. 4.7. Aspect fondamentaux de OMT: • • • • • • l'accent est mis sur l'utilisation des objets pour modéliser le monde réel plutôt que comme un mécanisme d'un langage particulier. les relations inter objets sont élevées à un rang aussi élevé que les classes moins d'accent est mis sur l'héritage et les méthodes les mécanismes subtils liés à l'héritage sont laissés de côté un accent particulier est mis sur le typage, les classes, la modélisation la terminologie utilisée est celle qui domine quand elle existe

4.8. Exercices: Tous les objets ont une identité et sont identifiables. D'un point de vue informatique, il n'est pas toujours évident de prévoir tout ce qui permet de les distinguer. Pour chacun de ces collections d'objets, décrire de quelle façon on pourrait les distinguer : • • • • • • tous les humains, dans l'idée de leur envoyer du courrier tous les humains, pour des enquêtes criminelles tous les clients qui possèdent un coffre dans une banque tous les téléphones d'Algérie tous les clients d'une compagnie de téléphone, pour la facturation toutes les adresses électroniques

5. Les trois modèles de OMT: OMT utilise trois modèles pour décrire un système : objet, dynamique et fonctionnel QUOI : le modèle objet définit la structure statique des objets et leurs inter-relations classes liens héritage QUAND : le modèle dynamique décrit les interactions entre les objets diagrammes de transition d'états contrôle (conditions de déclenchement d'une opération) événements, messages COMMENT : le modèle fonctionnel décrit les transformations appliquées aux données diagrammes de flots de données processus Ces trois modèles sont complémentaires et interreliés. Le modèle objet est fondamental et préalable aux deux autres. 17

OMT permet de modéliser un système selon trois points de vue complémentaires, chacun capturant des aspects essentiels du système, tous requis pour une description complète: • Le modèle objet est le point de vue des données. • Le modèle dynamique est le point de vue du contrôle, des comportements. • Le modèle fonctionnel est le point de vue des transformations apportées aux données. Un logiciel combine normalement ces trois aspects : Il transforme (modèle 3) des données (modèle 1) d'une façon ordonnée dans le temps (modèle 2). • Chaque modèle comporte des références aux deux autres ; ces liens sont limités et explicites • Chaque modèle peut être examiné d'une façon relativement indépendante des deux autres • Chaque modèle évolue durant le cycle de développement : Pendant l'analyse un modèle du domaine applicatif est réalisé sans idée d'implantation Pendant la conception, ce modèle est complété par des éléments relatifs au domaine de la solution Pendant l'implantation, ces deux aspects sont réalisés ATTENTION : le terme "modèle" recouvre deux réalités distinctes, généralement claires par le contexte: • La vue du système : modèle objet, dynamique, fonctionnel. On devrait dire sous modèle • Une étape dans le développement : analyse, conception, implantation 5.1. Le modèle objet: (Le "Quoi?") Ce modèle décrit la structure des objets d'un système : • • • • Leur identité Leurs relations Leurs attributs Leurs opérations

Les objets sont les éléments sur lesquels les autres modèles s'appuient. Ce sont les atomes (au sens grec : insécable) de nos modèles a l'issue de l'analyse le modèle objet comporte des termes familiers aux personnes du domaine, et normalement aucune référence informatique. Par contre, le modèle de conception comporte des références informatiques. Bien évidement le modèle objet est représenté par des diagrammes décrivant les différentes classes, hiérarchisées, et comportant les attributs et les opérations utiles 5.2. Le modèle dynamique: (Le "Quand?") Le modèle dynamique décrit les interactions entre les objets. Il décrit les aspects d'un système où interviennent : • • • • • • Le temps Les séquences Les événements Séquences d'événements Les états qui définissent le contexte pour des événements L'organisation des événements et des états

Le modèle dynamique décrit également le contrôle (conditions de déclenchement d'une opération). Les séquences d'opérations ont lieu sans se préoccuper de: • • Ce qu'elles font Ce sur quoi elles opèrent 18

•

Comment elles sont programmées Le modèle dynamique est représenté graphiquement à l'aide de diagrammes d'états. Chaque diagramme décrit les états et séquences d'événements permises pour une classe d'objets. Ces diagrammes comportent des références aux autres modèles : • • Les actions correspondent aux fonctions du modèle fonctionnel Les événements deviennent des opérations sur des objets du modèle objet

a) Diagrammes d'état:

5.3. Le modèle fonctionnel: (Le "Comment?") Ce modèle décrit les aspects d'un système concernés par des changements de valeurs : • • • • Fonctions Applications Contraintes Dépendances fonctionnelles

Ce modèle décrit ce que fait un système, sans considération pour quand ou comment il le fait. Le modèle fonctionnel est représenté par des Diagrammes de Flux de Données (DFD). Les DFD montrent : • • Les dépendances entre valeurs Le calcul de données de sortie en fonction de données en entrée et de traitements sans considérer quand, ni si les fonctions correspondantes sont exécutées.

5.4. Relations entre les modèles: On a vu que chaque modèle décrit un aspect d'une réalité, avec des références aux deux autres modèles. Le modèle objet décrit les structures de données utilisées par les modèles dynamique et fonctionnel. Les opérations du modèle objet correspondent à des événements du modèle dynamique et à des fonctions du modèle fonctionnel. Le modèle dynamique décrit la structure de contrôle des objets. Il montre les décisions qui dépendent de valeurs dans l'objet et qui provoquent des actions qui changent cet état et appellent des fonctions. Le modèle fonctionnel décrit les fonctions invoquées par des opérations du modèle objet et des actions du modèle dynamique. Les fonctions opèrent sur des données décrites dans le modèle objet. Le modèle fonctionnel décrit aussi des contraintes sur les valeurs des objets 5.5. Difficultés: On ne sait pas toujours décider si une information doit ou non figurer dans un modèle. Ceci est normal car un modèle décrit ses frontières de façon toujours brutale au début, et certaines limites doivent être déplacées. Certaines propriétés d'un système peuvent parfois être mal représentées par OMT. C'est également normal, aucune méthode ne peut être complète. Dans ce cas, le recours à tout autre langage ou méthode (graphique ou non, spécifique au domaine ou non) est souhaitable ou même nécessaire. 5.6. Exercices: 1) Parmi les caractéristiques d'un pneu on trouve sa taille, son composant, sa construction interne, dessin, prix, poids, durée de vie. Quels facteurs sont importants pour celui qui : • achète un pneu pour sa voiture? • réalise un système de simulation de performance d'un système anti-glissement pour voitures? • construit une balançoire à laide d'un pneu?

19

2) Décider quel modèle (objet, dynamique, fonctionnel) est pertinents pour les aspects suivants d'un programme de jeu aux échecs. Le jeu et les pièces sont visualisés sur un écran. Les coups de l'humain sont décrits par un curseur et une souris • • • • l'interface utilisateur qui décrit les coups représentation d'une configuration de pièces sur le plateau de jeu représentation d'une séquence de coups possibles validation d'un coup joué par l'humain

20