Cours d'Analyse Principes et Méthodes








télécharger 448.36 Kb.
titreCours d'Analyse Principes et Méthodes
page1/7
date de publication02.02.2018
taille448.36 Kb.
typeCours
ar.21-bal.com > droit > Cours
  1   2   3   4   5   6   7
EPFC Bachelier en Informatique

Cours d'Analyse Principes et Méthodes
Analyse Orientée Objet - Modélisation Objet avec UML
(Unified Modeling Language)


Brigitte Herpigny – Bruno Lacroix


Sommaire

Modélisation Objet avec UML

1. Introduction générale

2. Approche objet
2.1. Les objets

2.1.1. Diagrammes d’objets

2.1.2. Diagrammes de collaborations

2.1.3. Diagrammes de séquences
2.2. Les classes

-Classes entités, interfaces, contrôles - stéréotypes

2.2.1. Diagrammes de classes

- Associations

- Agrégations
- Qualifications

- Classes associations

- Généralisations / Spécialisations

- Contraintes sur associations

- Classes abstraites

2.2.2. Règles de bonne modélisation

3. Modèle de cas d’utilisation
3.1. Les acteurs
3.2. Les cas d’utilisation
3.3. Les diagrammes de cas d’utilisation
3.4. La transition vers les objets
3.5. Règles de bonne modélisation

4. Modèle dynamique
4.1. Introduction
4.2. Les automates
4.3. Les états
4.4. Diagrammes d’états-transitions
4.5. Opérations, actions et activités
4.6. Diagrammes d’états imbriqués – Généralisations
4.7. Concurrence et Agrégation d’états
4.8. Diagrammes d’interactions versus Diagrammes d’états
4.9. Règles de bonne modélisation
4.10. Diagrammes d’activités


+ TP ponctuels

+ TP – études de cas

Bibliographie Analyse Orientée Objet - UML


  • Ian Graham, Méthodes Orientées Objet, 2ème édition, 1997, Thomson Publishing



  • Pierre-Alain Muller, Modélisation Objet avec UML, 2ème édition 2000, Eyrolles



  • N. Lopez, J. Migueis, E. Pichon, Intéger UML dans vos Projets, 1998, Eyrolles



  • G. Booch, J. Rumbaugh, I. Jacobson, Le Guide de l'Utilisateur UML, 2000, Eyrolles



  • T. Quatrani, Modélisation UML avec Rational Rose 2000, 2000, Eyrolles



  • J. Rumbaugh et al. , OMT, Modélisation et Conception Orientées Objet, 1995, Masson



  • Pascal Roques, UML par la pratique – 2001 – Eyrolles



  • Craig Larman, UML2 et les design patterns -2005 – Pearson Education


1. Introduction

Les systèmes logiciels actuels sont devenus d'une complexité telle qu'ils nécessitent de véritables méthodes d'élaboration. Celles-ci doivent permettre de modéliser et de construire ces systèmes logiciels de manière fiable et reproductible. Elles permettent également un travail en équipe en facilitant la communication entre tous ses membres, informaticiens et non informaticiens, via un langage commun.

Les méthodes structurées et fonctionnelles se sont imposées les premières. Dans celles-ci, les sous-programmes constituent les éléments structurants.

D'une manière générale, la construction d'un logiciel peut être vue comme une suite d'itérations du genre "divisions/réunions". En effet, l'étude du système doit progresser à différents niveaux d'abstraction et s'intéresser aux détails comme à l'ordonnancement de l'ensemble de manière à faire émerger le comportement macroscopique complexe du système à réaliser.

Il s'agira donc de décomposer pour comprendre (divisions) et de composer pour construire (réunions).

Les décompositions sont traditionnellement dirigées par un critère fonctionnel: décomposer en une hiérarchie de nombreux sous-programmes les plus simples possibles s'appelant les uns les autres. Ces fonctions les plus simples sont alors facilement implémentables dans les langages de programmation.

Ce procédé donne en effet des résultats satisfaisants quand les fonctions peuvent être bien identifiées et qu'elles sont stables dans le temps.

Lorsqu'il n'en est pas ainsi (les fonctionnalités du problème ont changé!), les évolutions des fonctions peuvent impliquer des modifications structurelles très lourdes dans les programmes dues au couplage statique entre l'architecture du programme et les fonctions. Plusieurs études ont d'ailleurs montré que la maintenance adaptative d'un logiciel était la plus grande source d'injection d'erreurs dans un logiciel. (Ainsi, des versions ultérieures de logiciels possèdent souvent certains bugs que les versions précédentes ne possédaient pas!)

Les méthodes objets commencent à émerger dans les années 80. Dans celles-ci les élément structurants seront des objets collaborants entre eux.

Il est à noter que pendant longtemps, on a constaté un mélange des 2 paradigmes (approche fonctionnelle et approche objet) au cours du cycle de vie des logiciels. Ainsi, il était habituel de réaliser une analyse (description du problème) fonctionnelle suivie d'une conception (description de la solution au problème) et d'une programmation objets. Les conséquences en étaient un manque d'abstraction, abstraction limitée à l'encapsulation des objets de bas niveaux.

Les années 90 ont vu une prolifération de méthodes objet (+/- 50). Durant ces années de discussions afin de déterminer ce qui était "objet" et ce qui ne l'était pas, les utilisateurs ont préféré attendre.

Certaines idées dominantes communes animaient néanmoins les divers groupes de chercheurs:

  • notions de classes et associations : James Rumbaugh et sa méthode OMT (object modeling technique)



  • notions de partitions en sous-systèmes : Grady Booch



  • notions de "cas d'utilisations" (interactions entre utilisateur et système): Ivar Jacobson et ses use cases



Fin 1994, Rumbaugh et Booch décident d'unifier leurs méthodes; un an plus tard Jacobson les rejoint.

Ils fixent ainsi des objectifs communs:

  • représenter des systèmes entiers par des concepts O.

  • créer un langage de modélisation utilisable à la fois par les humains et par des machines (besoin d'un véritable "langage de modélisation")



La standardisation d'UML, Unified Modeling Language date de 1997. La définition de la version 1.0 est due à un consortium de partenaires regroupant DEC, HP, i-Logix, IntelliCorp, IBM, ICON, MCI, Microsoft, Oracle, Rational Software, TI, Unisys.
Remarque: UML 1.3, juin 1999
La notation UML est conçue pour servir de langage de modélisation O, indépendamment de la méthode mise en oeuvre (Booch, OMT, ...). En fait, elle sous-tend la méthode.

Le langage UML est composé d'éléments graphiques, chacun avec une sémantique clairement définie. Il peut être utilisé dans tous les domaines informatiques.
La représentation des sytèmes ne se contente habituellement pas d'un seul élément de modèle.

Ces différents modèles proposés peuvent se comparer à des "vues" différents d'une même chose, chacune insistant sur des caractéristiques différentes.

On trouve une comparaison facile dans la construction d'une maison. Celle-ci réclame une série de plans différents selon qu'ils sont destinés au plombier, à l'électricien, au menuisier... Pourtant, il s'agit toujours des plans de la même maison. Parfois, on remarque des informations permettant de naviguer d'une vue à une autre (de manière à ne pas placer les conduites d'eau là où passent les gaines électriques).
De la même manière, UML définit plusieurs modèles pour la représentation des systèmes:

  • un modèle de classes qui capture la structure statique



  • un modèle de cas d'utilisation décrivant les besoins des utilisateurs



  • un modèle d'interactions représentant les scénarios et les flots de messages



  • un modèle de réalisation montrant les unités de travail



  • un modèle de déploiement précisant la répartition des processus



Ceux-ci s'appuient sur 9 diagrammes différents:


  • diagrammes de classes: représentent la structure statique en termes de classes et de relations



  • diagrammes d'objets: représentent la structure statique en termes d'objets et de relations



  • diagrammes de séquence: sont une représentation temporelle des objets et de leurs interactions



  • diagrammes de collaboration: sont une représentation spatiale des objets, des liens et de leurs interactions



  • diagrammes de cas d'utilisation : représentent les fonctions du système du point de vue de l'utilisateur



  • diagrammes d'états-transitions: représentent le comportement d'une classe en termes d'états



  • diagrammes d'activités: représentent le comportement d'une opération en termes d'actions.




  • diagrammes de composants: représentent les composants physiques d'une application



  • diagrammes de déploiement: représentent le déploiement des composants sur les dispositifs matériels




La modélisation de tous les systèmes ne comporte pas nécessairement ces 9 vues.
2. Approche Objet
Avantages:


  • Stabilité de la modélisation par rapport aux entités du monde réel



  • Construction itérative facilitée par un faible couplage statique entre les différents composants ( approche fonctionnelle)



  • possibilité de réutiliser des éléments d'un développement à un autre



  • simplicité du modèle basé sur 5 concepts de base : objets, messages, classes, héritage, polymorphisme)




L'approche O est basée sur une démarche cartésienne rationnelle ainsi que sur une démarche "systémique" qui considère un système comme une totalité organisée dont les éléments solidaires ne peuvent être définis que les uns par rapport aux autres.

Ici, la méthode de décomposition sera basée sur l'intégration de ce que le système est et fait.

exemple: Système d'ascenseur



aller au Rez

Les objets qui sont des abstractions du monde réel intègrent une structure et un comportement.

La modélisation est donc une modélisation statique et dynamique de l'environnement (le "domaine") dans lequel sont définis les besoins.

Les fonctionnalités se représentent comme des formes de collaborations entre les objets qui composent le système et ce couplage devient dynamique.

Si les fonctionnalités changent, l'architecture du système n'est pas modifiée: il suffira d'ajouter les composants nécessaires et de modifier la collaboration entre les composants existants.

2.1 Les objets
Les objets informatiques sont des images simplifiées des objets du monde réel, objets matériels de toutes sortes (chaises, livres,...) ou objets "sans masse" ou même virtuels (comptes en banque, déplacements virtuels d'argent, équations, fenêtres d'un environnement Windows, ...).
Ils sont des unités atomiques réunissant un état (ce qu'il "est") et un comportement (ce qu'il "fait").



L'objet va révéler son rôle dans l'environnement en envoyant des messages à d'autres objets et en s'insérant ainsi dans un scénario de communication.

Notation UML d'un objet:
Un objet est représenté par un rectangle. On en souligne le nom.

Les traits entre les objets symbolisent les liens.

Les rectangles avec coin supérieur droit replié sont des annotations explicatives. Les liens avec ces notes sont alors des traits discontinus.

2.1.1. Diagrammes d'objets : = Vues statiques

représentent les objets participant à une interaction et leurs liens. Les diagrammes d'objets sont toujours des fragments d'un immense diagramme qui indiquerait les relations entre tous les objets.
exemple: Clients d'une banque et leurs comptes


La notation permet d'indiquer un nom générique plutôt que leur nom individuel.

On peut également représenter des objets anonymes avec un ":nom "
exemple : Un objet du "genre" Etudiant


La plupart des liens sont binaires. Néanmoins on peut rencontrer des liens d'arité supérieure.


Un objet = 1 état + 1 comportement + 1 identité

l'état : représente les valeurs instantanées de tous les "attributs" d'un objet. Ceux-ci peuvent prendre des valeurs dans un domaine de définition donné. L'état peut évoluer dans le temps en conséquence de ses comportements passés.





le comportement: regroupe les "compétences" d'un objet et décrit les actions et les réactions de cet objet.

Le comportement d'un objet regroupe donc une série d'opérations qui peuvent être déclenchées en réponse à un stimulus externe = un message envoyé par un autre objet.

Pour recevoir un message d'un autre objet, il faut que celui-ci soit "vu". On représentera cette reconnaissance mutuelle par un lien entre les objets. Les messages voyagent le long des liens, à priori dans les 2 directions. Ils sont représentés par des flèches au dessus des liens et accompagnés d'un nom décrivant le message.

2.1.2. Diagrammes de collaboration :
= Diagrammes des interactions (messages) entre objets en plus de la structure statique (objets, liens).


Paul demande à Nicolas d'étudier. Nicolas demande à Hélène de cuisiner.
Ceci sous-entend bien sûr que Nicolas a la faculté d'étudier (une des ses opérations est "étudier") et que Hélène sait faire la cuisine.

L'ordre d'envoi des messages est précisé par un n° placé en tête de message.
D'autre part, le comportement à un instant donné dépend de l'état courant qui lui-même peut être modifié par le comportement. Ainsi pour pouvoir étudier, il faut être dans un état "éveillé", sinon l'opération "étudier" n'a pas de sens. Et lorsque l'on reçoit le message de dormir, on passe dans l'état "endormi".


l'identité: En plus de son état, tout objet possède une identité de manière à le distinguer de manière non ambiguë de tous les autres objets, même s'il possède les mêmes valeurs d'attributs.

En phase de modélisation, l'identité ne se représentera pas de manière spécifique mais restera implicite.


3 catégories de comportement: Les acteurs, les serveurs et les agents
Les systèmes informatiques à objets sont donc des collections d'objets qui travaillent en synergie pour réaliser les fonctionnalités de l'application informatique.

En fonction de la direction des messages échangés, on peut dès lors regrouper les objets en 3 grandes catégories.


  • les acteurs sont à l'origine d'une interaction (ils envoient les messages)



  • les serveurs sont uniquement destinataires de messages. Ce sont des objets passifs qui attendent qu'un autre objet ait besoin de leurs services. Automatiquement, le flot de contrôle passé au serveur est récupéré par l'objet actif après exécution du service.



  • les agents peuvent émettre et recevoir des messages et peuvent servir d'intermédiaire entre un client et un serveur que le client ne connaît pas directement.




Remarque: Souvent agent ou acteur dépend de l'angle sous lequel on se place, ou du niveau d'abstraction envisagé.

Dans une école secondaire, une sonnerie signale le changement d'heure de cours. Celle-ci est en réalité reliée à une horloge. En conséquence de la sonnerie, les élèves se déplacent vers d'autres classes.

L'horloge apparaît donc comme un acteur envoyant un message à l'agent sonnerie qui transmet le message aux élèves (serveurs) de se déplacer.

Le concierge pourtant peut considérer l'horloge comme un agent puisqu'il la coupe le WE.

Les élèves eux peuvent considérer la sonnerie comme un acteur qui s'auto-déclenche toutes les heures.


Le concept de message

Les messages vont donc permettre aux objets de communiquer. Ils vont relier dynamiquement ces objets séparés par le processus de décomposition.

Ils regroupent les flots de contrôle et les flots de données au sein d'un concept unique (qui sera mis en oeuvre selon de nombreuses variantes (appel de procédures, événement discret, interruption, ...)). Ils représentent conceptuellement les actions effectuées dans le cadre du Use Case étudié (cf plus loin). Souvent les messages portent le nom d'une opération définie dans la classe (cf + loin) de l'objet destinataire du message.
La notation UML permet de différencier les flots de contrôle (flèches simples) des flots de données (flèches + petits cercles)



De manière générale, UML offre une syntaxe extrêmement complète pour les messages:
synchronisation sequence ':' résultat ':=' nom arguments
L'expression de synchronisation permet de préciser les envois d'autres messages qui doivent avoir été satisfaits préalablement.
La séquence indique le niveau d'emboîtement de l'envoi du message au sein de l'interaction et contient des notations d'itérations éventuelles et de conditions.
Le résultat est constitué d'une liste de valeurs retournés par le message.
Le nom du message (une opération de l'objet destinataire bien souvent)
les arguments= liste des paramètres du message.

exemples:

  • 4: Afficher(x,y) -- msg simple

  • 3.3.1 : Afficher (x,y) --msg imbriqué

  • 4.2 age:=soustraire(aujourd'hui,ddn)

  • [age >=18 ans] 6.2 : voter() --msg conditionnel

  • 4.a,b.6/c.1 : allumer(lampe) --synchro avec d'autres flots d'exécution

  • 1* : laver() --itération


5 catégories principales de messages

  • les constructeurs : créent des objets

  • les destructeurs : détruisent des objets

  • les sélecteurs : renvoient tout ou une partie de l'état d'un objet

  • les modificateurs : modifient tout ou une partie de l'état d'un objet

  • les itérateurs : visitent l'état d'un objet



Remarque : Un objet est dit actif quand il possède le flot de contrôle. Il peut alors activer des objets passifs pendant le temps d'un opération en leur envoyant un message. Une fois le message traité, le flot de contrôle est rendu à l'objet actif. Dans un environnment multitâche, plusieurs objets peuvent être actifs simultanément.

Lorsque plusieurs objets communiquent simultanément, il est important de discuter la notion de synchronisation afin entre autres de protéger l'accès à des objets partagés (exemple une imprimante)

2 grandes catégories d'envoi de messages



  • envoi de message synchrone : ne déclenche une opération que quand le destinataire accepte le message. Avec un tel envoi, l'expéditeur accepte d'attendre.
    Notation UML : flèche barré d'une croix - UML2



    Exemple: Un "expéditeur" téléphone à un destinataire. Il attend que le destinataire décroche pour lui transmettre le message.




  • envoi de message asynchrone : n'interrompt en rien l'activité de l'expéditeur. Celui-ci envoie le message et ne se préoccupe plus de rien. Il ne sait pas quand ni même si le message sera traité par le destinataire.
    Notation UML : demi flèche - UML2
    Exemple: Un expéditeur envoie une lettre par la poste à un destinataire.





On distingue également:


  • envoi de message simple : convient quand un seul objet est actif à la fois (un seul flot d'exécution). Le passage du contrôle s'effectue lors de l'envoi du message d'un objet actif vers un objet passif.
    Notation UML : flèche simple




  • envoi de message dérobant : ne déclenche une opération que si le destinataire s'est préalablement mis en attente du message. Le destinataire accepte d'attendre.
    Notation UML : flèche qui se retourne vers l'expéditeur





  • envoi de message minuté : bloque l'expéditeur pendant un temps donné en attendant la réception par le destinataire. Au bout du temps spécifié, si le destinataire ne s'est pas manifesté, l'expéditeur est libéré.
    Notation UML: flèche surmontée d'un petit cercle symbolisant une montre.
    Exemple: Un expéditeur téléphone à un destinataire. Il décide de patienter 5 sonneries que le destinataire décroche. Après cela, il raccroche.







Les diagrammes de collaboration qui représentent bien spatialement des situations avec un nombre de messages réduit deviennent extrêment confus lorsque les messages se multiplient:


Ici nous avons en plus illustré un message réflexif (8:) d'un objet à lui-même. De tels messages peuvent également indiquer un point d'entrée dans une activité de plus bas niveau qui s'exerce au sein de l'objet.

  1   2   3   4   5   6   7

similaire:

Cours d\Cours d'Analyse : principes et méthodes

Cours d\Chapitre 2 : Les Méthodes d’analyse de la Cellule – Bernard Rousset

Cours d\0 Urbanisme (2). Note du 22/3/02
«analyse des contenus des cours existants et futurs» afin de «formuler une proposition d’un ensemble de cours structuré et complémentaire...

Cours d\L´évolution des sciences a travers le temps et les civilisations
«la connaissance claire et certaine de quelque chose, fondée soit sur des principes évidents et des démonstrations, soit sur des...

Cours d\Analyse de la situation d’effondrement progressif du cours du baril du brut
«les cours du pétrole peuvent être manipulés. L’Arabie Saoudite a commencé à faire chuter les prix. Ceci est de la manipulation politique....

Cours d\Mme Bezeau est une conseillère principale qui a plus de 26 ans d'expérience...

Cours d\Cours 1 : Principes du diagnostic anatomo-pathologique des tumeurs
«je vois une tuméfaction» car cela n’est pas forcément grave, dans ce cas on fait une biopsie pour faire le diagnostic

Cours d\Cours d’analyse des organisations
«la nécessité d’un concept d’organisation qui ne se réduise pas àcelui de structure» (Le Moigne 1977 d’après F. Varella p17)

Cours d\Le cours de
«phénomène le plus évident de la vie économique» (cf. A. Benachenhou : Introduction à l’analyse économique, opu, Alger, 1976, p....

Cours d\Méthodes de construction de dériveurs légers








Tous droits réservés. Copyright © 2016
contacts
ar.21-bal.com