Connaitre les bases de la notation UML.
Pour réaliser l'analyse et générer les composants nécessaires à Plone nous allons utiliser l'outil ArchGenXML en version 2.
Nous réaliserons dans un premier temps un diagramme de classes, qui permettra de décrire le plan documentaire de notre application, puis nous associerons à nos documents des "workflows" sous forme de diagramme d'états transitions.
Mais avant cela nous allons réaliser un bref rappel des notions UML utilisées dans la suite.
UML est la fusion de différentes notations issues des méthodes de génie logiciel orienté objet antérieures aux années 1995. La version 1.0 a officiellement été publiée en 1997 par l'OMG (Object Management Group) qui est l'organisme responsable de sa standardisation. Depuis 2007, la version officielle est la 2.1.2.
Historiquement, son usage intervenait dans la phase de conception pour permettre de "visualiser" ce que sera et fera le logiciel. Comme les feuillets des plans d'un architecte en bâtiment, différents diagrammes composent une vue spécifique de la solution apportée au problème.
Le lecteur doit parcourir plusieurs vues et donc lire plusieurs diagrammes pour se créer son image mentale du logiciel.
Cette abstraction n'est malheureusement pas évitable, puisque un logiciel est composé à la fois de parties statiques, telle que le code exécutable, de données dynamiques telles que les entrées sorties, et de comportements.
Les vues sont des regroupements abstraits des diagrammes qui sont eux les "dessins" représentant les interactions entre les éléments constitutifs du logiciel. Ces diagrammes permettent de visualiser l'interaction entre les éléments de l'architecture qui sont regroupés dans un "modèles d'éléments" et constitués des cas d'utilisations, classes, associations, attributs, etc.
Actuellement, les courants de l'IDM (Ingénierie Dirigée par les Modèles), font que son usage est présent tout au long du cycle de vie du logiciel, et l'on met à jour le logiciel en modifiant le modèle puis en générant à nouveau l'application. Les outils de génération se chargent de fusionner l'existant avec les nouvelles fonctionnalités.
Initialement, la conception orientée objet cherchait à résoudre un problème en le découpant non pas en un ensemble de fonctionnalités dont le tout forme un arbre ayant pour racine une fonction "main", mais en boites travaillant ensemble par l'échange de messages et dont le comportement global réalise la tâche attendue.
La description de ces boites forme un tout homogène de données et de fonctions appelée interface, c'est une abstraction.
La définition d'un type de boite respectant une interface donnée est nommée "classe" si elle est simple, et composant si pour respecter le contrat de l'interface elle encapsule la collaboration de plusieurs classes et peut à elle seule être considérée comme une application.
L'exécution d'une classe est appelée instance, elle possède alors ses propres valeurs d'attributs à commencer par son occupation mémoire ce qui la distingue des autres instances de la même classe.
Mais revenons à UML.
UML se base sur trois types de briques pour permettre la modélisation d'une architecture :
Nous n'allons détailler ici que les éléments d'UML que nous utiliserons.
C'est un types d'éléments qui partagent les mêmes propriétés (attributs, méthodes, relations, sémantique).
Si les propriétés définies par la classe sont immuables et ne dépendent pas des éléments, on parle d'attributs ou de variables de classe et de méthodes de classes, inversement si leur contenu dépend de l'élément on parle d'attribut ou de variable d'instances et de méthodes.
Les propriétés d'une classe ont une visibilité, c'est-à-dire que l'accès aux propriétés d'une classe par une autre est contrôlé.
Représentation des classes
C'est un ensemble de méthodes qui définissent le comportement attendu d'une classe en laissant aux classes issues de cette interface de choisir l'implémentation.
Représentation des interfaces
C'est un élément concret actif ou passif appartenant à une classe. Si la classe de l'objet est connue, on parle alors d'instance de cette classe. L'objet possède toutes les propriétés de sa classe et définie les valeurs des attributs d'instances.
Représentation des objets
C'est une classe externe au système agissant ou réagissant au système.
Ainsi tous les intervenants sur le système sont des acteurs.
Représentation des acteurs
C'est une classe formant un tout cohérent et suffisant permettant de réaliser un ensemble de fonctionnalités, c'est la boite noire par excellence.
Représentation des composants
Lorsque plusieurs instances de classes réalisent un comportement global par échange de messages, on dit qu'ils forment une collaboration et que les objets y remplissent un rôle.
La collaboration permet donc de visualiser la réalisation des exigences fonctionnelles.
Représentation des collaborations
C'est un comportement du système dont est témoin un acteur, il est réalisé par des collaborations.
Représentation des cas d'utilisations
Elles sont constituées par l'envoi de messages ou d'événements provoquant des actions chez le récepteur.
L'appel d'une méthode de classe correspond à l'envoi d'un message dont le nom est suivi de parenthèses.
Représentation des messages
Ils permettent de constituer des automates décrivant le comportement d'une classe ou d'une méthode.
Représentation des états dans un diagramme d'états
Les activités sont des comportements exécutables séquentiellement ou parallèlement.
Représentation des activités dans un diagramme d'activités
C'est une relation sémantique indiquant que tout changement de l'élément indépendant peut affecter l'élément dépendant.
Représentation des dépendances
Elle permet d'indiquer une relation entre deux éléments.
La nature de la relation est donnée par le texte situé dessus. Un lien peut être précisé aux extrémités par le nombre et le rôle de chacun des éléments.
Un lien de contenance est symbolisé par l'agrégation.
Représentation des associations
Cette relation permet de définir des niveaux d'abstraction entre les classes, le but est de permettre de manipuler de façon homogène des ensembles d'objets qui partagent les mêmes propriétés. Cette factorisation des traitements s'appelle le polymorphisme.
Représentation des généralisations
Cette relation indique que la classe implémente les comportements définis dans l'interface qu'elle réalise.
Représentation des réalisations
Cette relation joint deux états et permet d'expliciter les conditions à respecter et les traitements à réaliser lors des changements d'états.
Alors que UML permet de créer 13 types de diagrammes nous n'allons n'en utiliser que trois pour la génération de notre produit. Les autres diagrammes servirons à la documentation de notre architecture.
Les diagrammes qui servirons à la génération sont :
- Le diagramme de classes
- Le diagramme d'états transitions
- Le diagramme d'activités
Ce diagramme permet de mettre en évidence la structure des classes c'est-à-dire les attributs et méthodes présents dans les classes, les relations entre classes.
Ainsi, il fait apparaitre les hiérarchies de classes (héritage, abstraction, interface), les compositions et agrégations (un instance d'une classe contenant des instances d'autres classes), les dépendances, les "packages".
Par convention on limite le nombre de classes visibles dans un diagramme de classes. On va alors réaliser différents diagrammes de classes qui chacun doit montrer un aspect du problème en n'affichant que les attributs, méthodes et associations concernés par cet aspect.
Diagramme de classes
Il regroupe les objets et permet de les représenter avec leur liens à un moment donné.
Diagramme d'objets
Il regroupe les cas d'utilisations et les acteurs concernés.
Diagramme de cas d'utilisations
Il permet de visualiser l'enchainement des messages entre objets. L'ordre de lecture est de haut en bas.
Diagramme de séquences
C'est une représentation symétrique du diagramme de séquence.
Il est utilisé pour modéliser les changements d'états d'un élément.
Nous l'utiliserons pour modéliser les workflows de nos types de contenu.
Il permet de voir l'enchainement des tâches du système ou des traitements déclenchés par les acteurs.
Il montre les liens entre composants.
Il permet de voir l'intégration.