DI GALLO Frédéric
Méthodologie des systèmes d'information - UML
Cours du Cycle Probatoire
Cours dispensé par Annick Lassus.
CNAM ANGOULEME 2000-2001
METHODOLOGIES
DES SYSTEMES
D'INFORMATION :
UML
UP - LE PROCESSUS UNIFIE
I. LE PROCESSUS DE DEVELOPPEMENT : NOUVELLE APPROCHE .5
II. LE PROCESSUS UNIFIE : CADRE GENERAL .6
PROCESSUS UNIFIE EST PILOTE PAR LES CAS D’UTILISATION ..6
3.1) Présentation 6
3.2) Exemple: guichet de banque ..6
PROCESSUS UNIFIE EST CENTRE SUR L’ARCHITECTURE .8
4.1) Liens entre cas d’utilisation et architecture ? ..8
4.2) Marche à suivre : .8
V. LE PROCESSUS UNIFIE EST ITERATIF ET INCREMENTAL ..8
5.1) Avantages d’un processus itératif contrôlé .9
CYCLE DE VIE DU PROCESSUS UNIFIE .9
6.1) Présentation du cycle de vie de UP .10
6.2) Exemple sur les différents modèles ..11
VII. CONCLUSION : UN PROCESSUS INTEGRE .12
I. LES METHODES OBJET ET LA GENESE D'UML .15
1.1) Méthodes ? 15
1.2) A quoi sert UML ? .16
1.4) Les points faibles d'UML ..17
2.1) UML est basé sur un méta-modèle ..18
III.INTRODUCTION A LA NOTATION UML ..19
3.2) Les méthodes objet 19
3.4) La normalisation OMG ..20
4.1) Qu'est-ce qu'un modèle ? ..21
INTRODUCTION AU LANGAGE UML
1.1) Objectifs des cas d’utilisation .33
1.3) Description des cas d’utilisation ..35
1.6) Notion de paquetage 38
II. LE DIAGRAMME DE CLASSES 42
2.2) Les associations .43
3.1) Interaction .48
3.3) Les Messages : 50
METHODOLOGIE – CNAM ANGOULEME 2000-2001
Comparaison des méthodologies UP et Merise:
I. Le processus de développement : nouvelle approche
• Un processus de type séquentiel : développement organisé en phases qui regroupent des étapes, elles mêmes décomposées en tâche.
Dans une approche objet tout change :
• Les découpages ne coïncident pas : les activités (taches, phases, étapes, etc…) se déroulent dans plusieurs dimensions.
UP (Unified Process) est une méthode générique de développement de logiciel. Générique signifie qu'il est nécessaire d'adapter UP au contexte du projet, de l'équipe, du domaine et/ou de l'organisation (exemple: R.UP ou X.UP). C'est, entre parenthèses, plus ou moins vrai pour toute méthode, qu'elle se définisse elle-même comme générique ou pas.
II. Le processus unifié : cadre général
Caractéristiques essentielles du processus unifié :
- Le processus unifié utilise le langage UML (ensemble d'outils et de diagramme),
III. Le processus unifié est piloté par les cas d’utilisation
L’objectif principal d’un système logiciel est de rendre service à ses utilisateurs ; il faut par conséquent bien comprendre les désirs et les besoins des futurs utilisateurs. Le processus de développement sera donc centré sur l'utilisateur. Le terme utilisateur ne désigne pas seulement les utilisateurs humains mais également les autres systèmes. L’utilisateur représente donc une personne ou une chose dialoguant avec le système en cours de développement.
Acteur
3.2) Exemple: guichet de banque
virement entre comptes
On va se demander, en premier, quels sont les utilisateurs du système (pas forcément des utilisateurs physiques, mais plutôt des rôles). Ici, l'employé est aussi un client de la banque. On a donc une personne physique pour deux rôles. Nous ne sommes pas dans une approche de type fonctionnelle mais une approche pilotée par des cas d'utilisation.
Que doit pouvoir faire le système pour chaque utilisateur ?
- A partir du modèle des cas d’utilisation, les développeurs créent une série de modèles de conception et d’implémentation réalisant les cas d’utilisation.
- Enfin, les testeurs testent l’implémentation pour s’assurer que les composants du modèle d’implémentation mettent correctement en œuvre les cas d’utilisation.
IV. Le processus unifié est centré sur l’architecture
Elle subit également l’influence d’autres facteurs :
- les briques de bases réutilisables disponibles pour le développement ;
4.1) Liens entre cas d’utilisation et architecture ?
4.2) Marche à suivre :
- Il travaille ensuite, sur un sous ensemble des cas d’utilisations identifiés, ceux qui représentent les fonctions essentielles du système en cours de développement.
Ce processus se poursuit jusqu’à ce que l’architecture soit jugée stable.
Le développement d’un produit logiciel destiné à la commercialisation est une vaste entreprise qui peut s’étendre sur plusieurs mois. On ne va pas tout développer d’un coup. On peut découper le travail en plusieurs parties qui sont autant de mini projets. Chacun d’entre eux représentant une itération qui donne lieu à un incrément.
Le choix de ce qui doit être implémenté au cours d’une itération repose sur deux facteurs :
• L’itération traite en priorité les risques majeurs.
A chaque itération, les développeurs identifient et spécifient les cas d’utilisations pertinents, créent une conception en se laissant guider par l’architecture choisie, implémentent cette conception sous forme de composants et vérifie que ceux ci sont conformes aux cas d’utilisation. Dés qu’une itération répond aux objectifs fixés le développement passe à l’itération suivante.
Un projet réussi suivra un déroulement direct, établi dés le début par les développeurs et dont ils ne s’éloigneront que de façon très marginale. L’élimination des problèmes imprévus fait partie des objectifs de réduction des risques.
- Permet de limiter les coûts, en termes de risques, aux strictes dépenses liées à une itération.
- Permet d’accélérer le rythme de développement grâce à des objectifs clairs et à court terme.
L’architecture fournit la structure qui servira de cadre au travail effectué au cours des itérations, tandis que les cas d’utilisation définissent les objectifs et orientent le travail de chaque itération. Il ne faut donc pas mésestimer l’un des trois concepts.
Le processus unifié répète un certain nombre de fois une série de cycles.
Chaque cycle se traduit par une nouvelle version du système. Ce produit se compose d’un corps de code source réparti sur plusieurs composants pouvant être compilés et exécutés et s’accompagne de manuels et de produits associés. Pour mener efficacement le cycle, les développeurs ont besoin de construire toutes les représentations du produit logiciel :
Tous ces modèles sont liés. Ensemble, ils représentent le système comme un tout. Les éléments de chacun des modèles présentent des dépendances de traçabilité ; ce qui facilite la compréhension et les modifications ultérieures.
|
Phase |
Description et Enchaînement d’activités |
|
Phase de création |
Traduit une idée en vision de produit fini et présente une étude de rentabilité pour ce produit - Que va faire le système pour les utilisateurs ? - A quoi peut ressembler l’architecture d’un tel système ? - Quels sont l’organisation et les coûts du développement de ce produit ? On fait apparaître les principaux cas d’utilisation. L’architecture est provisoire, identification des risques majeurs et planification de la phase d’élaboration. |
|
Phase d’élaboration |
Permet de préciser la plupart des cas d’utilisation et de concevoir l’architecture du système. L’architecture doit être exprimée sous forme de vue de chacun des modèles. Emergence d’une architecture de référence. A l’issue de cette phase, le chef de projet doit être en mesure de prévoir les activités et d’estimer les ressources nécessaires à l’achèvement du projet. |
|
Phase de construction |
Moment où l’on construit le produit. L’architecture de référence se métamorphose en produit complet, elle est maintenant stable. Le produit contient tous les cas d’utilisation que les chefs de projet, en accord avec les utilisateurs ont décidé de mettre au point pour cette version. Celle ci doit encore avoir des anomalies qui peuvent être en partie résolue lors de la phase de transition. |
|
Phase de transition |
Le produit est en version bêta. Un groupe d’utilisateurs essaye le produit et détecte les anomalies et défauts. Cette phase suppose des activités comme la fabrication, la formation des utilisateurs clients, la mise en œuvre d’un service d’assistance et la correction des anomalies constatées.(où le report de leur correction à la version suivante) |
Cas du guichet de banque…
retirer de l'argent
virement entre comptes
On va essayer de faire apparaître des cas nominaux (classiques) et des scénarios d'exception.
Le processus unifié est basé sur des composants. Il utilise UML et est basé sur les cas d’utilisation, l’architecture et le développement incrémental. Pour mettre en pratique ces idées il faut recourir à un processus multi-facettes prenant en considération les cycles, les phases, les enchaînements d’activités, la réduction des risques, le contrôle qualité, la gestion de projet et la gestion de configuration. Le processus unifié a mis en place un cadre général (framework) intégrant chacune de ces facettes.
APPROCHE DU LANGAGE UML
1.1) Méthodes ? .. 15
1.3) Les points forts d'UML .. 17
2.1) UML est basé sur un méta-modèle . 18
3.1) La notion d'objet .. 19
3.3) Intérêt d'une méthode objet . 19
4.1) Qu'est-ce qu'un modèle ? . 21
Caractéristiques fondamentales des modèles 21
Une démarche itérative et incrémentale ? .. 22 Une démarche pilotée par les besoins des utilisateurs ? . 22 Une démarche centrée sur l'architecture ? 22 Définir une architecture avec UML (détail de la "vue 4+1") .. 23
Activités desmicro-processus d'analyse(niveau d'abstraction
Synthèse de la démarche .. 26
Qu'est-ce qu'un modèle ? . 26
Modélisation d'une classe 29
METHODOLOGIE – CNAM ANGOULEME 2000-2001
I. Les méthodes objet et la genèse d'UML1.1) Méthodes ?
Découpe cartésienne (fonctionnelle et hiérarchique) d'un système.
Modélisation des données + modélisation des traitements (Merise, Axial, IE ).
Prise de conscience de l'importance d'une méthode spécifiquement objet: comment structurer un système sans centrer l'analyse uniquement sur les données ou uniquement sur les traitements (mais sur les deux) ? Plus de 50 méthodes objet sont apparues durant cette période (Booch, Classe-Relation, Fusion, HOOD, OMT, OOA, OOD, OOM, OOSE )! Aucune méthode ne s'est réellement imposée.
?OMT (James Rumbaugh) : vues statiques, dynamiques et fonctionnelles d'un système. Issue du centre de R&D de General Electric. Notation graphique riche et lisible.
?OOSE (Ivar Jacobson) : couvre tout le cycle de développement. Issue d'un centre de développement d'Ericsson, en Suède. La méthodologie repose sur l'analyse des besoins des utilisateurs.
?UML (Unified Modeling Langage), la fusion et synthèse des méthodes dominantes :
?UML est le résultat d'un large consensus (industriels, méthodologistes ).
?UML est issu du terrain.
?UML est ouvert (il est indépendant du domaine d'application et des langages d'implémentation).
- UML évolue mais reste stable !
?Les groupes d'utilisateurs UML favorisent le partage des expériences.
?UML inclut des mécanismes standards d'auto-extension.
>>> UML n'est pas une mode, c'est un investissement fiable !
- UML n'est pas une méthode ou un processus !
?Ce constat vaut aussi pour OMT ou d'autres techniques / langages de modélisation.
?UML a été pensé pour permettre de modéliser les activités de l'entreprise, pas pour les régir (ce n'est pas CMM ou SPICE).
- Impossible de prendre en compte toutes les organisations et cultures d'entreprises.
- Même si un processus constitue un cadre général, il faut l'adapter de manière précise au contexte de l'entreprise.
?UML est fondé sur un métamodèle, qui définit :
- la sémantique de ces éléments (leur définition et le sens de leur utilisation).
?Le métamodèle d'UML permet de classer les concepts du langage (selon leur niveau d'abstraction ou domaine d'application) et expose sa structure.
?UML propose aussi une notation, qui permet de représenter graphiquement les éléments de modélisation du métamodèle.
- UML cadre l'analyse objet, en offrant :
?plusieurs niveaux d'abstraction, qui permettent de mieux contrôler la complexité dans l'expression des solutions objets.
?Sa notation graphique permet d'exprimer visuellement une solution objet.
?Son aspect visuel facilite la comparaison et l'évaluation de solutions.
?gain de précision
?encourage l'utilisation d'outils
?Il cadre l'analyse.
?Son caractère polyvalent et sa souplesse en font un langage universel.
- La mise en pratique d'UML nécessite un apprentissage et passe par une période d'adaptation.
- Le processus (non couvert par UML) est une autre clé de la réussite d'un projet.
II. Caractéristiques de la méthode UML
UML est un moyen d'exprimer des modèles objet en faisant abstraction de leur implémentation, c'est-à-dire que le modèle fourni par UML est valable pour n'importe quel langage de programmation. UML est un langage qui s'appuie sur un métamodèle, un modèle de plus haut niveau qui définit les éléments d'UML (les concepts utilisables) et leur sémantique (leur signification et leur mode d'utilisation). Le métamodèle permet de se placer à un niveau d'abstraction supérieur car il est étudié pour être plus générique que le modèle qu'il permet de construire. Le métamodèle d'UML en fait un langage formel possédant les caractéristiques suivantes:
- un langage universel pouvant servir de support pour tout langage orienté objet
- une représentation visuelle permettant la communication entre acteurs d'un même projet - une notation graphique simple, compréhensible même par des non informaticiens
Lorsqu'une entreprise désire un logiciel, elle le réalise parfois en interne, mais le fait plus généralement réaliser par une société de services. Dans un cas comme dans l'autre il est nécessaire de définir l'ensemble des fonctionnalités que le logiciel doit possèder. Le demandeur du logiciel n'a parfois pas de compétences particulières en informatique et exprime donc ses souhaits sous forme d'un CdCF (Cahier des Charges Fonctionnelles), c'està-dire un document décrivant sous forme textuelle l'ensemble des particularités que le logiciel doit possèder, les conditions qu'il doit remplir (système(s) d'exploitation visé(s)), les écueils à éviter, ainsi que les délais impartis, éventuellement des clauses sur le coût, les langages à utiliser,
Lorsqu'une société obtient le marché et qu'elle décide (si elle a le choix) d'opter pour un langage orienté objet, il lui faut dans un premier temps créer un modèle (c'est là qu'intervient UML) afin:
• d'accorder tous les acteurs du projet (une application de grande envergure est généralement réalisée par modules développés par différentes équipes)
Cette méthode représente un langage permettant de spécifier, représenter et construire les composantes d’un système informatique. Avec la méthode UML, un objet est par exemple représenté de la façon suivante:
Les langages orientés objet constituent chacun une manière spécifique d'implémenter le paradigme objet. Ainsi, une méthode objet permet de définir le problème à haut niveau sans rentrer dans les spécificités d'un langage. Il représente ainsi un outil permettant de définir un problème de façon graphique, afin par exemple de le présenter à tous les acteurs d'un projet (n'étant pas forcément des experts en un langage de programmation).
Une méthode objet est donc d'une part une méthode d'analyse du problème (afin de couvrir toutes les facettes du problèmes), d'autre part un langage permettant une représentation standard stricte des concepts abstraits (la modélisation) afin de constituer un langage commun.
Ainsi, il est nécessaire qu'une méthode objet soit définie de manière rigoureuse et unique afin de lever les ambiguïtés. De nombreuses méthodes objet ont été définies, mais aucune n'a su s'imposer en raison du manque de standardisation. C'est pourquoi l'ensemble des acteurs du monde informatique a fondé en 1989 l'OMG (Object Management Group), une organisation à but non lucratif, dont le but est de mettre au point des standards garantissant la compatibilité entre des applications programmées à l'aide de langages objet et fonctionnant sur des réseaux hétérogènes (de différents types). A partir de 1997, UML est devenue une norme de l'OMG, ce qui lui a permis de s'imposer en tant que méthode de développement objet et être reconnue et utilisée par de nombreuses entreprises.
L'OMG propose notamment l'architecture CORBA (Common Object Request Broker Architecture), un modèle standard pour la construction d'applications à objets distribués (répartis sur un réseau). Pour rester simple, on peut considérer CORBA comme une généralisation de l'architecture clients/serveurs aux objets.
De plus, l'ORB assure une coopération entre objets qui est indépendante des langages de programmation. Le modèle CORBA permet en effet de se focaliser sur les interfaces des objets, qu'on exprime en IDL (Interface Definition Language). L'IDL décrit de manière standard l'interface d'un objet, en faisant abstraction des détails qui relèvent de son d'implémentation. Avec CORBA, il n'est donc pas nécessaire de savoir comment les objets sont codés pour utiliser leurs services. L'utilisation d'IDL comme langage pivot dans la construction d'une architecture, permet de gérer l'hétérogénéité. Cette approche, qui consiste à masquer les couches techniques du réseau (système d'exploitation, processeur, langage de programmation ), permet d'assurer l'interopérabilité de toute application à objets distribués, conforme au modèle CORBA.
UML a été adopté (normalisé) par l'OMG et intégré à l'OMA, car il participe à cette vision et parce qu'il répond à la "philosophie" OMG.
L'abstraction est un des piliers de l'approche objet. Il s'agit d'un processus qui consiste à identifier les caractéristiques intéressantes d'une entité, en vue d'une utilisation précise. L'abstraction désigne aussi le résultat de ce processus, c'est-à-dire l'ensemble des caractéristiques essentielles d'une entité, retenues par un observateur.
Un modèle définit une frontière entre la réalité et la perspective de l'observateur. Ce n'est pas "la réalité", mais une vue très subjective de la réalité.
Modèle économique: peut par exemple permettre de simuler l'évolution de cours boursiers en fonction d'hypothèses macro-économiques (évolution du chômage, taux de croissance ).
- itérative et incrémentale,
D'après les auteurs d'UML, un processus de développement qui possède ces qualités devrait favoriser la réussite d'un projet.
L'idée est simple : pour modéliser (comprendre et représenter) un système complexe, il vaut mieux s'y prendre en plusieurs fois, en affinant son analyse par étapes. Cette démarche devrait aussi s'appliquer au cycle de développement dans son ensemble, en favorisant le prototypage. Le but est de mieux maîtriser la part d'inconnu et d'incertitudes qui caractérisent les systèmes complexes.
Avec UML, ce sont les utilisateurs qui guident la définition des modèles : Le périmètre du système à modéliser est défini par les besoins des utilisateurs (les utilisateurs définissent ce que doit être le système). Le but du système à modéliser est de répondre aux besoins de ses utilisateurs (les utilisateurs sont les clients du système). Les besoins des utilisateurs servent aussi de fil rouge, tout au long du cycle de développement (itératif et incrémental) : à chaque itération de la phase d'analyse, on clarifie, affine et valide les besoins des utilisateurs. A chaque itération de la phase de conception et de réalisation, on veille à la prise en compte des besoins des utilisateurs. A chaque itération de la phase de test, on vérifie que les besoins des utilisateurs sont satisfaits.
Une architecture adaptée est la clé de voûte du succès d'un développement. Elle décrit des choix stratégiques qui déterminent en grande partie les qualités du logiciel (adaptabilité, performances, fiabilité ). Ph. Kruchten propose différentes perspectives, indépendantes et complémentaires, qui permettent de définir un modèle d'architecture (publication IEEE, 1995). Cette vue ("4+1") a fortement inspiré UML :
- La vue logique
- La vue des composants
- La vue des processus
- La vue de déploiement
- La vue des besoins des utilisateurs
1. Optez pour une approche itérative et incrémentale.
3. Prenez grand soin à la définition de l'architecture de votre application (l'approche "4+1" permet de mieux la cerner).
L'entrée de l'analyse à ce niveau, est le dossier d'expression des besoins client. A ce niveau d'abstraction, on doit capturer les besoins principaux des utilisateurs. Il ne faut pas chercher l'exhaustivité, mais clarifier, filtrer et organiser les besoins ! Le but de la conceptualisation est de définir le contour du système à modéliser (de spécifier le "quoi"), de capturer les fonctionnalités principales du système, afin d'en fournir une meilleure compréhension (le modèle produit sert d'interface entre les acteurs du projet), de fournir une base à la planification du projet.
L'entrée de l'analyse à ce niveau, est le modèle des besoins clients (les "cas d'utilisation" UML). Il s'agit de modéliser les éléments et mécanismes principaux du système. On identifie les éléments du domaine, ainsi que les relations et interactions entre ces éléments : les éléments du domaine sont liés au(x) métier(s) de l'entreprise, ils sont indispensables à la mission du système, ils gagnent à être réutilisés (ils représentent un savoir-faire). A ce stade, on organise aussi (selon des critères purement logiques), les éléments du domaine en "catégories" : pour répartir les tâches dans les équipes, regrouper ce qui peut être générique, etc
A ce niveau, on modélise les aspects informatiques du système, sans pour autant rentrer dans les détails d'implémentation. Les interfaces des éléments de modélisation sont définis (cf. encapsulation). Les relations entre les éléments des modèles sont définies. Les éléments de modélisation utilisés peuvent être propres à une version du système.
On y modélise tous les rouages d'implémentation et on détaille tous les éléments de modélisation issus des niveaux supérieurs. Les modèles sont optimisés, car destinés à être implémentés.
- identifiez les classes (d'objets) : recherchez les classes candidates (différentes suivant le niveau d'abstraction) à l'aide de diagrammes d'objets (ébauches), filtrez les classes redondantes, trop spécifiques ou vagues, qui ne représentent qu'une opération ou un attribut, documentez les caractéristiques des classes retenues (persistances, nombre maximum d'instances, etc.).
recherchez les connexions sémantiques et les relations d'utilisation, documentez les relations (nom, cardinalités, contraintes, rôles des classes ), en spécification, filtrez les relations instables ou d'implémentation, définissez la dynamique des relations entre objets (les interactions entre instances de classes et les activités associées).
recherchez les attributs dans les modèles dynamiques (recherchez les données qui caractérisent les états des objets), filtrez les attributs complexes (faites-en des objets) et au niveau spécification, ne représentez pas les valeurs internes propres aux mécanismes d'implémentation, recherchez les opérations parmi les activités et actions des objets (ne pas rentrer dans le détail au niveau spécification).
- validez les modèles : vérifiez la cohérence, la complétude et l'homogénéité des modèles, confrontez les modèles
Il s'agit d'une tâche très complexe, qui nécessite une approche :
- centrée sur l'architecture (définie par la vue "4+1"), car il s'agit de la clé de voûte qui conditionne la plupart des qualités d'une application informatique,
La modélisation consiste à créer une représentation simplifiée d'un problème: le modèle.
• L'analyse, c'est-à-dire l'étude du problème
Le modèle constitue ainsi une représentation possible du système pour un point de vue donné.
Le méta-modèle UML fournit une panoplie d'outils permettant de représenter l'ensemble des) éléments du monde objet (classes, objets, ) ainsi que les liens qui les relie. Toutefois, étant donné qu'une seule représentation est trop subjective, UML fournit un moyen astucieux permettant de représenter diverses projections d'une même représentation grâce aux vues. Une vue est constitué d'un ou plusieurs diagrammes.
• Les vues statiques, c'est-à-dire représentant le système physiquement
• diagrammes de classes
• diagrammes de composants
• Les vues dynamiques, montrant le fonctionnement du système
• diagrammes de collaoration
• diagrammes d'activités
La modélisation objet consiste à créer une représentation abstraite, sous forme d'objets, d'entités ayant une existence matérielle (arbre, personne, téléphone, ) ou bien virtuelle (sécurité sociale, compte bancaire, ). Un objet est caractérisé par plusieurs notions:
• 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
UML propose une manière de représenter les objets de façon graphique, sous forme de rectangle, dans lequel le nom de l'objet est souligné.
Les attributs (propriétés) d'un objet représentent ses caractéristiques. L'ensemble des valeurs des attributs d'un objet constituent son état. UML propose de représenter les attributs d'un objet et les valeurs associées de la manière suivante:
Dans l'approche objet, les objets ne sont pas des corps inertes isolés. Bien au contraire, même s'ils possèdent leurs caractéristiques propres par l'intermédiaire des valeurs de leurs attributs (ce qui constitue ce que l'on appelle l'état), ils ont la possibilité d'interagir entre-eux grâce à leurs méthodes. UML propose de représenter les liens qui existent entre les objets grâce à un trait continu.
Une classe est composée:
• Les méthodes : il s'agit des opérations applicables aux objets
Mieux: deux instanciations de classes pourront avoir tous leurs attributs égaux sans pour autant être un seul et même objet (c'est la différence entre état et identité). C'est le cas dans le monde réel, deux T-shirts peuvent être strictement identique (avoir le même état) et pourtant ils sont distincts (ils ont chacun leur identité propre). D'ailleurs en les mélangeant il serait impossible de les distinguer
En effet, la programmation orientée objet permet de cacher l'implémentation dun objet en ne lui permettant d'accéder aux attributs uniquement par l'intermédiaire de méthodes crées à cet effet (on parle d'interface). Il est ainsi possible de définir des niveaux d'encapsulation, afin de définir le type de classe ayant accès aux attributs.
• 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
• 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é
• + défini un attribut public
• - défini un attribut privé
INTRODUCTION AU LANGAGE UML
1.1) Objectifs des cas d’utilisation 33
1.3) Description des cas d’utilisation . 35a) Exemple : Cas d’utilisation Retirer de l’argent 35
1.4) Structuration des cas d’utilisation .. 36
b) La relation d’extension 37
1.6) Notion de paquetage .. 38
Partie 1: Diagramme de cas d'utilisation - vue de l'administrateur . 38
II. LE DIAGRAMME DE CLASSES .. 42
a) Définition 42
c) Syntaxe . 43
2.2) Les associations 43a) Arité des associations .. 44
c) Identification des associations 44
e) Multiplicité des associations 45
g) Agrégation . 46
i) Généralisation : .. 47
3.1) Interaction 48
3.3) Les Messages : .. 50
Partie III: Diagramme de classe métier pour le cas d'utilisation « regarder » .. 52
3.5) TP de synthèse: Création d'un site Web .. 54
b) La publication des articles: .. 54
METHODOLOGIE – CNAM ANGOULEME 2000-2001
UML est un langage de modélisation avec plusieurs objectifs qui en font un véritable outil de communication:
Les diagrammes d'UML vont mettre en place deux parties:
I. Les cas d’utilisation
Les cas d’utilisation sont une technique de description du système étudié privilégiant le point de vue de l’utilisateur. Il s’agit de la solution UML pour représenter le modèle conceptuel. Les cas d’utilisation décrivent sous la forme d’actions et de réactions, le comportement d’un système du point de vue d’un utilisateur. Les cas d’utilisation servent à structurer les besoins des utilisateurs et les objectifs correspondants du système.
Les cas d’utilisation apportent une solution au problème de la détermination et de la compréhension des besoins. En effet fréquemment, des besoins se contredisent, des oublis et des imprécisions sont réalisés et ainsi l’analyse du système part sur de mauvaises bases. Les cas d’utilisation recentrent l’expression des besoins sur les utilisateurs en partant du principe qu’un système est avant tout construit pour ses utilisateurs. Les cas d’utilisation permettent aux utilisateurs de structurer et d’articuler leurs désirs ; ils les obligent à définir la manière dont ils voudraient interagir avec le système, à préciser quelles informations ils entendent échanger et à décrire ce qui doit être fait pour obtenir le résultat escompté.
Acteur
- Cas d’utilisation : ensemble d’actions réalisées par le système en réponse à une action d’un acteur.
- les cas d’utilisation peuvent être organisés en paquetages,
Exemple :Diagramme de cas d’utilisation d’un guichet automatique bancaire
« Un cas d’utilisation spécifie une séquence d’interactions, avec ses variantes, entre les acteurs et le système, produisant un résultat satisfaisant pour un acteur particulier. ». On peut donc considérer un cas d’utilisation comme une abstraction de plusieurs chemins d’exécution d’une utilisation du système. Pour décrire un cas d’utilisation, il nous faut décrire un maximum de chemins d’exécution possibles pour la séquence d’actions correspondant à ce cas. On étudiera donc un certain nombre de scénarios d’un cas d’utilisation.
A chaque fois qu’une instance d’un acteur déclenche un cas d’utilisation, un scénario est créé : ce scénario suivra un chemin particulier dans la description d’un cas d’utilisation. Un scénario ne contient pas de branche du type « si la condition X est vraie alors faire Y », car pendant l’exécution la condition est soit vraie, soit fausse mais elle aura toujours une valeur.
Nous aurons donc deux niveaux de description :
- Description des scénarios les plus pertinents.
1- Le client de la banque s’identifie
4- Le système vérifie si le retrait est autorisé, si oui il déduit le montant du compte et délivre l’argent, sinon il renvoie un message de rejet de l’opération
Acteur déclencheur : M. Martin
1- M. Martin s’identifie
3- M. Martin choisit son compte chèque et demande 200F
4- Le système délivre deux billets de 100F et demande à ce que M. Martin les saisisse.
5- M. Martin prend l’argent.
Après avoir identifié les acteurs et les cas d’utilisation, il est utile de restructurer l’ensemble des cas d’utilisation que l’on a fait apparaître afin de rechercher lescomportements partagés, les cas particuliers et les généralisations.
- Une relation d’inclusion : formalisée par la dépendance « include »
Etapes de construction:
2. Pour chaque acteur, recherche des cas d'utilisation,
a) La relation d’inclusion :
Un cas d’utilisation A utilise un cas d’utilisation B signifie que :
- A dépend de B,
Exemple :
Remarquez que dans une relation « include », le cas d’utilisation de base utilise systématiquement les enchaînements provenant du cas inclus.
b) La relation d’extension
Considérons l’exemple : le cas d’utilisation B étend le cas d’utilisation A signifie que :
- B connaît A et non l’inverse, c’est à dire que B dépend de A - B n’existe pas tout seul et A existe sans B
Exemple :
La relation d'héritage ou de généralisation entre cas est plus subtile. La version 1.1 de UML ne distinguait d'ailleurs pas <> et généralisation. Cette relation est à prendre au sens classique de spécialisation, inhérent à 'héritage. Ici, la généralisation peut être vue aussi comme un "polymorphisme" de cas.
Dans un système d'agence de voyage, un acteur touriste peut participer à un cas de base qui est "Réserver voyage", qui suppose par exemple des interactions basiques au comptoir de l'agence. Une réservation peut aussi être réalisée par téléphone ou internet. On voit qu'il ne s'agit pas de relation <> car la réservation par Internet n'étend pas les interactions ni les fonctionnalités du cas 'Réserver voyage". Elle les traduit différemment. Les interactions Internet ne sont pas une option des interactions comptoir. Par contre les deux cas "Réserver voyage" et "Réserver voyage par Internet" sont liés : la réservation par Internet est un cas particulier de réservation. De façon générale en objet, une situation de cas particulier se traduit par une relation de généralisation.
1.6) Notion de paquetage
Un paquetage est un ensemble d’éléments de modélisation : des classes, des associations, des objets, des composants…. Dans le cas du guichet bancaire on pourrait faire deux diagrammes de cas d’utilisation, un pour le paquetage utilisation du guichet et un autre pour le paquetage maintenance.
|
TVServices est une société qui met à disposition de ses clients un ensemble de services relatifs à la télévision (accès à des chaînes thématiques, contrôle des utilisations et des utilisateurs, programme électronique détaillé des chaînes accessibles ). Ces services sont commercialisés sous le nom d' « IntelliTélé » Chaque client dispose d'un boîtier électronique situé entre l'antenne satellite et l'installation de télévisualisation (écrans, magnétoscopes ). C'est cet équipement intermédiaire, appelé ciaprès "boîtier 'NS", constamment en veille et relié au réseau téléphonique, qui permet au client: le paiement des services par carte bancaire, et le décodage des images reçues. Et à TVServices, la diffusion automatique des programmes et magazines électroniques (et des publicités ;-); en chargeant les mémoires des boîtiers avec les programmes et magazines, et l'autorisation d'accès aux services; TVS mémorise les informations relatives aux autorisations d'accès aux services (fonction des paiements reçus) dans les boîtiers. Partie 1: Diagramme de cas d'utilisation - vue de l'administrateur Voici unextrait de la brochure commerciale proposant les contrats 'IntelliTélé' « Une fois le contrat signé et l'abonnement aux services de votre choix payé vous recevrez par l'intermédiaire d'un installateur agréé, un "boîtier TVS" préprogrammé avec les autorisations d'accès correspondant à votre contrat. Lors de l'installation, un compte "administrateur" (typiquement, pour une installation familiale, un des parents) est créé qui aura pour tâche de déclarer les futurs utilisateurs du système (identificateur et mot de passe) ainsi que d'administrer leurs droits (types d'émission autorisés, plages horaires autorisées, durée maximale hebdomadaire de visualisation autorisée appelée "crédit hebdomadaire").» |
|
|
Travail à faire: |
|
|
I.l) Expliquer le diagramme ci-dessous par un texte décrivant les informations qu'il contient en les contextualisant dans le cadre de TVServices (deux sens possibles, ambiguïté /). |
|
L'accès aux fonctions d'administration est protégé, le contrôle s'effectuant sur l'identificateur et le mot de passe de l'administrateur. Ce qui explique que l'exécution du cas d'utilisation 'Administrer' nécessite celle du cas d'utilisation 'ContrôleAccèsUtil', dont l'exécution nécessite celle du cas d'utilisation 'Identifier'.
I.2) Quel peut-être l'intérêt de séparer les cas d'utilisation "ContrôleAccèsUtil" et "Identifier" du cas d'utilisation "Administrer"?
acteurs sollicitant le système, "Client" et "Administrateur" sont tous deux "Utilisateur".
|
Partie II: Diagramme de cas d'utilisation - vue de l'utilisateur Voici un extrait de la description faite ci-dessous par un des premiers clients: « Une "IntelliTélé" est un téléviseur-enregistreur,elle (ou 'il' je ne sais pas -) permet de regarder des émissions télédiffusées, et aussi de les enregistrer. C'est un système qui, via un réseau, connaît les possibilités pour lesquelles on a payé. Par exemple, on peut acheter des droits de réception de certaines chaînes payantes ou s'abonner à un service qui envoie régulièrement une analyse détaillée des programmes des principales chaînes. Pour utiliser une "IntelliTélé", on dispose d'un terminal, comme une télécommande, avec un petit écran tactile, qu'on manipule avec un stylet. Dans ce terminal on peut glisser si nécessaire une carte à puce, par exemple pour payer un service. Pour pouvoir utiliser "l'IntelliTélé", il faut s'identifier. Un utilisateur autorisé dispose de droits ; c'est moi qui ai défini les droits d'accès des enfants. Je leur ai interdit des plages horaires et certaines chaînes. Il me reste à interdire certains types de programme (je sais que c'est possible car ils disent que le boîtier connaît la catégorie de chaque émission). Mais c'est vrai je ne vous ai pas encore parlé du boîtier; tenez, voici la présentation de TVServices, la société qui commercialise "L'IntelliTélé", » (Voir la partie I). Travail à faire: En imaginant utiliser une IntelliTélé comme vous le faites (peut-être) de votre récepteur TV/magnétoscope, et en tenant compte de la description ci-dessus, produire un diagramme de cas d'utilisation de l'IntelliTélé vu de l'utilisateur - acteur générique comme défini en 1.3. ciavant. |
1. Mr Martin s'identifie
2. Mr Martin décide d'enregistrer une émission sur M6 en direct
3. Mr Martin éteint la TV
1. Mr Martin s'identifie
3. Le système lui indique qu'il n'a pas les droits d'accès sur cette chaîne.
4. Mr Martin éteint la TV
1. La fille de Mr Martin s'identifie
3. Elle choisit de regarder un dessin animé
II. Le diagramme de classes
Les diagrammes de classes expriment de manière générale la structure statique d’un système, en termes de classes et de relations entre ces classes. Une classe permet de décrire un ensemble d’objets (attributs et comportement), tandis qu’une relation ou association permet de faire apparaître des liens entre ces objets. On peut donc dire :
- un objet est une instance de classe,
- un lien est une instance de relation
Le diagramme de classe est un modèle permettant de décrire de manière abstraite et générale les liens entre objets.
UML permet de définir trois types de stéréotypes pour les classes :
a) les classes « frontière»(interface): classes qui servent à modéliser les interactions entre le système et ses acteurs.
b) les classes « contrôle » : classes qui servent à représenter la coordination, le séquencement, les transactions et le contrôle d’autres objets.
c) les classes « entité » : classes qui servent à modéliser les informations durables et persistantes.
Dans un premier temps c’est à cette dernière catégorie de classes que nous allons nous intéresser. Le diagramme de classe va être un outil nous permettant de représenter le modèle du domaine. Le modèle du domaine saisit les éléments les plus importants pour comprendre le contexte du système :
- les objets métiers (mis en œuvre dans une activité professionnelle tels que les commandes, les contrats..) ,
- les concepts du domaine à modéliser dont le système doit garder une trace,
- les évènements s’étant produits ou devant se produire qui déclencheront un certain comportement des objets.
