LANGAGE UML Parfait YAO [email protected] Sommaire Chapitre 1 : Concept Objet............................................................................................................... 4 1. Introduction ............................................................................................................................. 4 2. De la programmation classique vers la programmation orientée objet ................... 4 3. Objet et Classe ........................................................................................................................ 5 3.1. Objet ................................................................................................................................. 5 3.2. Classe................................................................................................................................ 5 3.3. Rapport ............................................................................................................................ 5 3.4. Attributs........................................................................................................................... 5 3.5. Méthodes ......................................................................................................................... 5 3.6. Signature ......................................................................................................................... 6 4. Encapsulation et Interface ................................................................................................... 6 5. Association et Agrégation de classe................................................................................... 7 6. 5.1. Association ...................................................................................................................... 7 5.2. Agrégation/Composition de classe ............................................................................ 7 Généralisation et Spécialisation de classe ....................................................................... 8 6.1. Généralisation ................................................................................................................ 8 6.2. Spécialisation de classe ............................................................................................... 8 7. Polymorphisme ....................................................................................................................... 9 8. Persistance ............................................................................................................................ 10 9. Avantages du développement avec les langages objet ............................................... 10 Chapitre 2 : UML 2 ............................................................................................................................ 12 1. Généralité .............................................................................................................................. 12 2. Objectifs ................................................................................................................................. 13 3. Diagramme de cas d’utilisation ........................................................................................ 13 4. 3.1. Cas d'utilisation ............................................................................................................ 13 3.2. Acteur............................................................................................................................. 13 3.3. Relations entre cas d’utilisation .............................................................................. 14 3.4. Relations entre acteurs................................................................................................ 14 3.5. Acteurs principaux et secondaires .......................................................................... 15 3.6. Description des cas d'utilisation .............................................................................. 15 Diagramme de classes ......................................................................................................... 16 4.1. Classes et objets .......................................................................................................... 16 4.2. Attributs et méthodes ................................................................................................ 16 4.3. Encapsulation, visibilité ............................................................................................. 17 4.4. Package (paquetage) .................................................................................................. 17 4.5. Héritage ......................................................................................................................... 18 4.6. Classe abstraite ............................................................................................................. 18 4.7. Interface ........................................................................................................................ 19 4.8. Associations .................................................................................................................. 19 5. Diagramme de séquences................................................................................................... 21 5.1. Ligne de vie................................................................................................................... 22 5.2. Messages synchrones et asynchrones ..................................................................... 22 6. Diagramme d’activités ........................................................................................................ 22 6.1. Formalisme.................................................................................................................... 22 6.2. Les transitions .............................................................................................................. 23 6.3. Nœud initial .................................................................................................................. 23 6.4. Nœud final ou Nœud de fin d'activité .................................................................... 23 6.5. Nœud de décision (decision node) .......................................................................... 23 6.6. Nœud de fusion (merge node).................................................................................. 23 6.7. Nœud de bifurcation ou de débranchement (fork node) .................................. 23 6.8. Nœud d’union ou de jointure (join node) ............................................................. 23 7. Diagramme d'états-transitions .......................................................................................... 25 7.1. Etat d’un objet ............................................................................................................. 25 7.2. Transition ...................................................................................................................... 25 7.3. Evénement déclencheur ............................................................................................ 25 8. Diagramme de déploiement .............................................................................................. 25 8.1. Nœud .............................................................................................................................. 25 8.2. Artefact .......................................................................................................................... 26 8.3. Manifest ......................................................................................................................... 26 9. Diagramme d’objets ............................................................................................................ 27 10. Rational Unified Process (RUP) ..................................................................................... 27 10.1. Organisation en phases du projet ....................................................................... 28 10.2. Organisation en activités de développement................................................... 28 Chapitre 1 : Concept Objet 1. Introduction Ces dernières années il y a eu une utilisation plus large des langages de programmation objet de référence comme C++, C# et Java et ensuite à l’introduction des concepts objet dans d’autres langages comme par exemple VB.NET, PHP, Perl et même Cobol. La mise en place d’importantes applications liées à Internet (applications web) constitue une des principales explications de ce phénomène. Les concepts majeurs sont : • • • • • • objet et classe, encapsulation et interface, association et agrégation de classes, généralisation et spécialisation de classe, polymorphisme, persistance. 2. De la programmation classique vers la programmation orientée objet La programmation classique telle que étudiée au travers des langages C, Pascal, etc… définie un programme comme étant un ensemble de données sur lesquelles agissent des procédures et des fonctions. Programmer dans ce cas revenait à : - définir un certain nombre de variables (structures, tableaux…) - écrire des procédures pour les manipuler sans associer explicitement les unes aux autres. Exécuter un programme se réduit alors à appeler ces procédures dans un ordre décrit par le séquençage des instructions en leur fournissant les données nécessaires à l’accomplissement de leurs tâches. Dans cette approche, l’on est en droit de se poser les questions suivantes : 1. Cette séparation (données, procédures) est-elle utile ? 2. Pourquoi ne pas considérer que les programmes sont avant tout des ensembles objets informatiques caractérisé par les opérations qu’ils connaissent ? Les langages objets sont nés pour répondre à ces questions. Ils sont fondés sur la connaissance d’une seule catégorie d’entités informatiques : les objets. Un objet incorpore des aspects statiques et dynamiques au sein d’une même notion. Un programme est constitué d’un ensemble d’objets chacun disposant d’une partie procédures et d’une partie données. Les objets interagissent par envoi de messages. 3. Objet et Classe 3.1. Objet Un objet représente une entité du monde réel (ou du monde virtuel pour les objets immatériels) qui se caractérise par un ensemble de propriétés (attributs), des états significatifs et un comportement. Un objet est responsable de ses comportements (actions). 3.2. Classe Une classe est l’abstraction d’un ensemble d’objets qui possèdent une structure identique (liste des attributs) et un même comportement (liste des opérations). 3.3. Rapport L’instanciation d’une classe est la création d’un objet particulier de la classe. 3.4. Attributs Les attributs d’un objet sont l’ensemble des informations se présentant sous forme de variable et permettant de représenter l’état de l’objet. 3.5. Méthodes Une méthode est une fonction ou procédure liée à un objet. La liste des méthodes définies au sein d’un objet constitue l’interface de l’objet pour l’utilisateur. 3.6. Signature La signature d’une méthode représente la précision de son nom, du type de ses arguments et du type de donnée retournée. Exemple ❖ La voiture de Théodore a pour numéro d’immatriculation 6838ET01, elle pèse 2T, elle est blanche, elle a 145 000 kilomètres au compteur. Cette voiture peut démarrer, s’arrêter, accélérer, décélérer, et tourner. ❖ Considérons l’employé Syriac, n° 1245, embauché en tant qu’ingénieur travaillant sur le site DANGA. Dans les 2 cas, l’objet est caractérisé par la liste de ses attributs et son état est représenté par les valeurs de ses attributs. Le comportement est caractérisé par les opérations qu’ils peuvent exécuter. Cas 1 : CLASSE OBJET Voiture numIm : 6838ET01 numIm poids couleur poids : 2T couleur : blanche kilometrage : 145000 kilométrage demarrer() arreter() accelerer() decelerer() tourner() 4. Encapsulation et Interface L’approche objet/classe se caractérise par le regroupement dans une même classe de la description de la structure des attributs et de la description des opérations. Objet/Classe a deux aspects : • • Interface : vue externe de l’objet ; Corps : implémentation des comportements (opérations) et des attributs. Les données ne sont accessibles qu’à partir d’opérations définies dans la classe. Le principe d’encapsulation renforce l’autonomie et l’indépendance de chaque classe et donne une potentialité accrue de définition de classe réutilisable d’un objet, un utilisateur ne connaît que l’interface. L’implémentation est masquée et non accessible à l’utilisateur. Un utilisateur/programmeur peut utiliser une classe (créer/manipuler des objets de la classe) sans connaître le corps de la classe [sans être concepteur de la classe]. Si la classe est correctement définie, l’utilisateur « bridé » ne peut pas violer l’intégrité de l’objet [par exemple, transformer une liste ordonnée en une liste non-ordonnée]. Le concepteur peut modifier le corps d’une classe. Si l’interface de la classe n’est pas modifiée alors les utilisateurs (programmes) de la classe ne doivent pas être pas affectés par les modifications du corps. Il existe quatre visibilités prédéfinies : Public ou + : tout élément qui peut voir le conteneur peut également voir l’élément indiqué. Protected ou # : seul un élément situé dans le conteneur ou un de ses descendants peut voir l’élément indiqué. Private ou - : seul un élément situé dans le conteneur peut voir l’élément. Package ou ∼ ou rien : seul un élément déclaré dans le même paquetage peut voir l’élément. 5. Association et Agrégation de classe 5.1. Association L’association représente une relation entre plusieurs classes. Elle correspond à l’abstraction des liens qui existent entre les objets dans le monde réel. Les multiplicités (ou cardinalités) et les rôles des objets participant aux relations complètent la description d’une association. 5.2. Agrégation/Composition de classe L’agrégation est une forme particulière d’association entre plusieurs classes. Elle exprime le fait qu’une classe est composée d’une ou plusieurs autres classes. La relation composant-composé ou la relation structurelle représentant l’organigramme d’une entreprise sont des exemples types de la relation d’agrégation. Une agrégation est une association qui représente une relation d’inclusion structurelle ou comportementale d’un élément dans un ensemble. Graphiquement, on ajoute un losange vide ( ) du côté de l’agrégat. La composition, également appelée agrégation composite, décrit une contenance structurelle entre instances. Ainsi, la destruction de l’objet composite implique la destruction de ses composants. Une instance de la partie appartient toujours à au plus une instance de l’élément composite : la multiplicité du côté composite ne doit pas être supérieure à 1 (i.e. 1 ou 0..1). Graphiquement, on ajoute un losange plein (♦) du côté de l’agrégat. Exemple 6. Généralisation et Spécialisation de classe 6.1. Généralisation La généralisation de classes consiste à factoriser dans une classe, appelée superclasse, les attributs et/ou opérations des classes considérées. Appliquée à l’ensemble des classes, elle permet de réaliser une hiérarchie des classes. 6.2. Spécialisation de classe La spécialisation représente la démarche inverse de la généralisation puisqu’elle consiste à créer à partir d’une classe, plusieurs classes spécialisées. Chaque nouvelle classe créée est dite spécialisée puisqu’elle comporte en plus des attributs ou opérations de la super-classe (disponibles par héritage) des attributs ou opérations qui lui sont propres. Une classe spécialisée porte aussi le nom de sous-classe. La spécialisation de classe se construit en deux temps : d’abord par héritage des opérations et des attributs d’une super-classe et ensuite par ajout d’opérations et/ou d’attributs spécifiques à la sous-classe. La généralisation-spécialisation est un des mécanismes les plus importants de l’approche objet qui facilite la réutilisation des classes. 7. Polymorphisme Le polymorphisme est la capacité donnée à une même opération de s’exécuter différemment suivant le contexte de la classe où elle se trouve. Ainsi une opération définie dans une super-classe peut s’exécuter de manière différente selon la sous-classe où elle est héritée. En fait lors de l’exécution, l’appel de l’opération va automatiquement déclencher l’exécution de l’opération de la sous-classe concernée. Dans le déroulement de l’exécution de l’opération de la sous-classe, il est possible de faire appel à l’opération de la super-classe qui contient en général la partie commune applicable aux deux sous-classes. Exemple abstract class Forme() { abstract float aire() ; } class Carre extends Forme() { float cote; float aire() { return cote * cote; } } class Cercle extends Forme() { float rayon; float aire() { return Math.PI*rayon*rayon; } } 8. Persistance La persistance est le mécanisme permettant de conserver l'état d'un objet (données stockées dans ses attributs) au-delà de l'exécution du programme qui l'a créé. Elle permet de sauvegarder des objets dans des bases de données ou des fichiers, puis de les restaurer ultérieurement. Par défaut dans l’approche objet, aucun objet n’est persistant. Les modèles décrivent le système en exécution en mémoire centrale (vive) et ne tiennent pas compte a priori de l’état du système qui doit être stocké sur disque. La gestion de la mémoire incombe au programmeur avec notamment le problème de la libération des espaces. 9. Avantages du développement avec les langages objet Par rapport à une approche fonctionnelle associée à un développement classique mené à l’aide de langages procéduraux, on est en droit de s’interroger sur les avantages qu’apporte réellement le développement à l’aide d’un langage objet comme par exemple C++, C# ou Java. En fait, deux avantages prépondérants sont mis en général en avant lorsque l’on choisit une approche objet : • La modularité – Par construction, étant donné que l’on conçoit des classes représentant une entité de taille limitée en données et en opérations, il est plus aisé de construire des systèmes modulables que si l’on élabore une seule base de données d’une part et un seul logiciel d’autre part. • La réutilisabilité – La définition d’un système à l’aide de classe ayant chacune la responsabilité d’un sous-ensemble de données et des opérations associées favorise fortement la potentialité de trouver des classes réutilisables. La réutilisation de classe se réalise soit sur le plan métier à l’intérieur d’une même entreprise dans des applications différentes, soit sur le plan technique à l’échelle de tous les développements réalisés à l’aide d’un même langage. Sur ce dernier aspect, c’est toute l’approche du développement par composant qui est en jeu. Au-delà de ces deux avantages majeurs et compte tenu de la plus grande modularité dans la construction d’une application à l’aide d’objets, la maintenance élémentaire de chaque classe est en soi plus simple à réaliser que celle d’un logiciel unique traitant toutes les données d’un système. Il importe bien entendu dans l’approche objet de construire son système en veillant à minimiser le nombre de relations entre classes. Chapitre 2 : UML 2 1. Généralité Les méthodes utilisées dans les années 1980 pour organiser la programmation impérative (notamment Merise) étaient fondées sur la modélisation séparée des données et des traitements. Au début des années 1990, la programmation par objets prend de l'importance, la nécessité d'une méthode qui lui soit adaptée devient évidente. En 1994, un consensus se fait autour de trois méthodes : • • • OMT de James Rumbaugh (General Electric) fournit une représentation graphique des aspects statique, dynamique et fonctionnel d'un système ; OOD de Grady Booch, définie pour le Department of Defense, introduit le concept de paquetage (package) ; OOSE d'Ivar Jacobson (Ericsson) fonde l'analyse sur la description des besoins des utilisateurs (cas d'utilisation, ou use cases). Officiellement UML (Unified Modeling Language) est né en 1994. UML v2.0 date de 2005, il s'agit d'une version majeure apportant des innovations radicales et étendant largement le champ d'application d'UML. UML 2.0 comporte treize (13) types de diagrammes répartis en deux (2) grands groupes: ➢ Diagrammes structurels ou diagrammes statiques (UML Structure) ✓ diagramme de classes (Class diagram) ✓ diagramme d'objets (Object diagram) ✓ diagramme de composants (Component diagram) ✓ diagramme de déploiement (Deployment diagram) ✓ diagramme de paquetages (Package diagram) ✓ diagramme de structures composites (Composite structure diagram) ➢ Diagrammes comportementaux ou diagrammes dynamiques (UML Behavior) ✓ diagramme de cas d'utilisation (Use case diagram) ✓ diagramme d'activités (Activity diagram) ✓ diagramme d'états-transitions (State machine diagram) ➢ Diagrammes d'interaction (Interaction diagram) ✓ diagramme de séquence (Sequence diagram) ✓ diagramme de communication (Communication diagram) ✓ diagramme global d'interaction (Interaction overview diagram) ✓ diagramme de temps (Timing diagram) 2. Objectifs Les principaux diagrammes nécessaires à la modélisation d’un système informatique orienté objet sont: • Les diagrammes de cas d’utilisation • Le diagramme de classes • Le diagramme d’objets • Le diagramme de séquence • Le diagramme d’activités • Le diagramme d’état-transition • Le diagramme de déploiement 3. Diagramme de cas d’utilisation Il représente la structure des grandes fonctionnalités nécessaires aux utilisateurs du système. Le diagramme de cas d'utilisation modélise les besoins des utilisateurs, il permet de : • Faire l'inventaire des fonctionnalités attendues ; • Organiser les besoins entre eux, de manière à faire apparaître des relations. 3.1. Cas d'utilisation Un cas d'utilisation est un service rendu à l'utilisateur, il implique des séries d'actions plus élémentaires. 3.2. Acteur Un acteur est une entité extérieure au système modélisé, et qui interagit directement avec le système Un cas d'utilisation est l'expression d'un service réalisé de bout en bout, avec un déclenchement, un déroulement et une fin, pour l'acteur qui l'initie. Exemple de diagramme de cas d'utilisation 3.3. Relations entre cas d’utilisation • Inclusion : le cas A inclut le cas B (B est une partie obligatoire de A) • Extension : le cas B étend le cas A (B est une partie optionnelle de A) • Généralisation : le cas A est une généralisation du cas B (B est une sorte de A) 3.4. Relations entre acteurs Une seule relation est possible : la généralisation 3.5. Acteurs principaux et secondaires L'acteur est dit principal pour un cas d'utilisation lorsque l'acteur est à l'initiative des échanges nécessaires pour réaliser le cas d'utilisation. L’acteur secondaire est sollicité par le système alors que l’acteur principal est à l'initiative des interactions. Le plus souvent, les acteurs secondaires sont d'autres systèmes informatiques avec lesquels le système développé est interconnecté. 3.6. Description des cas d'utilisation Chaque cas d'utilisation doit être documenté pour qu'il n'y ait aucune ambiguïté concernant son déroulement et ce qu'il recouvre précisément. Description textuelle I. • • • • • • II. Identification : Nom du cas : Payer avec CB Objectif : Détailler les étapes permettant à client de payer par carte bancaire Acteurs : Client, Banque (secondaire) Date : 18/09/2024 Responsables : Toto Version : 1.0 Séquencements : • Déclencheur Le cas d'utilisation commence lorsqu'un client demande le paiement par carte bancaire • Préconditions Le client a validé sa commande • Scénario (enchaînement) nominal 1. Le client saisit les informations de sa carte bancaire 2. Le système vérifie la carte auprès du système bancaire 3. Le système demande au système bancaire de débiter le client 4. Le système notifie au client le bon déroulement de la transaction • Scénarios (enchaînements) alternatifs 1. En (2) : si les informations sont erronées, elles sont redemandées au client • Scénarios d’erreurs (d’exception) 1. En (2) : Après 3 tentatives erronées, le système annule la commande • Post-conditions - La commande est validée - Le compte de l'entreprise est crédité III. Rubriques optionnelles • Contraintes non fonctionnelles : - Fiabilité : les accès doivent être sécurisés - Confidentialité : les informations concernant le client ne doivent pas être divulguées • Contraintes liées à l'interface homme-machine : - Toujours demander la validation des opérations bancaires • Interfaces homme-machine Produire des maquettes de l’interface graphique 4. Diagramme de classes Le diagramme de classes permet de spécifier la structure et les liens entre les objets dont le système est composé. 4.1. Classes et objets Une classe est la description d'un type d'objets concrets ayant une sémantique, des attributs, des méthodes et des relations en commun. Elle spécifie l'ensemble des caractéristiques qui composent des objets de même type. Une classe est composée d'un nom, d'attributs et de méthodes. 4.2. Attributs et méthodes Les attributs et les méthodes sont les propriétés d'une classe. Leur nom commence par une minuscule. • • Un attribut décrit une donnée de la classe, son type est précisé ; Une méthode est un service offert par la classe (un traitement que les objets correspondant peuvent effectuer). Modélisation d’une classe Exemple de diagramme de classe 4.3. Encapsulation, visibilité L'encapsulation permet de définir des niveaux de visibilité des éléments d'un conteneur. Il existe quatre visibilités prédéfinies: • • • • Public ou « + » : propriété ou classe visible partout Protected ou « # » : propriété ou classe visible dans la classe et par tous ses descendants Private ou « - » : propriété ou classe visible uniquement dans la classe Package ou « ~ » : propriété ou classe visible uniquement dans le paquetage 4.4. Package (paquetage) Les packages contiennent des éléments de modèle de haut niveau, comme des classes, des diagrammes de cas d'utilisation ou d'autres packages. On organise les éléments modélisés en packages et sous-packages. 4.5. Héritage L'héritage une relation de spécialisation/généralisation. Les éléments spécialisés héritent de la structure et du comportement des éléments généraux (attributs et méthodes). Exemple : Par héritage d'Article, un Livre a d'office un prix, une désignation et une opération acheter(), sans qu'il soit nécessaire de le préciser. Une classe peut avoir plusieurs classes parents. On parle alors d'héritage multiple. C++ l’implante effectivement, Java ne le permet pas. 4.6. Classe abstraite Une méthode est dite abstraite lorsqu'on connaît sa signature mais pas la manière dont elle peut être réalisée. Il appartient aux classes enfants d’implémenter les méthodes abstraites. Une classe est dite abstraite lorsqu'elle définit au moins une méthode abstraite ou lorsqu'une classe parent contient une méthode abstraite non encore réalisée. 4.7. Interface Le rôle d'une interface est de regrouper un ensemble d'opérations assurant un service cohérent offert par un classeur et une classe en particulier. Les classes implémentant une interface doivent implémenter toutes les opérations décrites dans l'interface 4.8. Associations Une association est une relation structurelle entre objets. Une association est souvent utilisée pour représenter les liens possibles entre objets de classes données. 4.8.1. Multiplicités des associations La notion de multiplicité permet le contrôle du nombre d'objets intervenant dans chaque instance d'une association. Exemple : un article n'appartient qu'à une seule catégorie (1) ; une catégorie concerne plus de 0 articles, sans maximum (*). 4.8.2. Association unidirectionnelle Elle restreint la navigabilité d'une association à un seul sens à l'aide d'une flèche. Le sens est interprété lors de l’implémentation des classes. Exemple : Connaissant un article on connaît les commentaires, mais pas l'inverse. 4.8.3. Association réflexive Parfois il arrive que les deux extrémités de l'association pointent vers le même classeur. Dans ce cas, l'association est dite « réflexive » 4.8.4. Classe-association Une association peut être raffinée et avoir ses propres attributs, qui ne sont disponibles dans aucune des classes qu'elle lie. Dans le modèle objet, seules les classes peuvent avoir des attributs, cette association devient alors une classe appelée « classe-association » 4.8.5. Association n-aire Une association n-aire lie plus de deux classes. Sa notation avec un losange central peut éventuellement accueillir une classe-association. 4.8.6. Association de type agrégation Une agrégation est une forme particulière d'association, elle représente la relation d'inclusion d'un élément dans un ensemble. L'ensemble est l'agrégat et la partie l'agrégé. On représente l'agrégation par l'ajout d'un losange vide du côté de l'agrégat. 4.8.7. Association de type composition La relation de composition décrit une contenance structurelle entre instances. On utilise un losange plein. La destruction et la copie de l'objet composite (l'ensemble) impliquent respectivement la destruction ou la copie de ses composants (les parties). La composition est aussi dite « agrégation forte ». 5. Diagramme de séquences Le diagramme de séquences permet de décrire comment les éléments du système interagissent entre eux et avec les acteurs: • • Les objets au cœur d'un système interagissent en s'échangeant des messages ; Les acteurs interagissent avec le système au moyen d'IHM (Interfaces Homme-Machine). Il faut, au minimum, représenter le scénario nominal de chacun des cas d'utilisation par un diagramme de séquence qui rend compte de l'interaction entre l'acteur, ou les acteurs, et le système. 5.1. Ligne de vie Une ligne de vie représente un participant à une interaction (objet, acteur ou système). Une ligne de vie est une instance, donc il y a nécessairement les deux points (:) dans son libellé. 5.2. Messages synchrones et asynchrones Un message synchrone bloque l’expéditeur jusqu’à la réponse du destinataire. Le flot de contrôle passe de l’émetteur au récepteur. • • Si un objet A envoie un message synchrone à un objet B, A reste bloqué tant que B n’a pas terminé. On peut associer aux messages d’appel de méthode un message de retour (en pointillés) marquant la reprise du contrôle par l’objet émetteur du message synchrone. Un message asynchrone n’est pas bloquant pour l’expéditeur. Le message envoyé peut être pris en compte par le récepteur à tout moment ou ignoré. 6. Diagramme d’activités Le diagramme d'activités offre une manière graphique et non ambiguë de modéliser les traitements. Il permet ainsi de représenter graphiquement le comportement d'une méthode ou le déroulement d'un cas d'utilisation. 6.1. Formalisme Les nœuds activités Un nœud d'activité est un type d'élément abstrait permettant de représenter les étapes le long du flot d'une activité. 6.2. Les transitions Le passage d'une activité vers une autre est matérialisé par une transition. Graphiquement les transitions sont représentées par des flèches en traits pleins qui connectent les activités entre elles. 6.3. Nœud initial Un nœud initial est un nœud de contrôle à partir duquel le flot débute lorsque l’activité enveloppante est invoquée. 6.4. Nœud final ou Nœud de fin d'activité Graphiquement, un nœud de fin d'activité est représenté par un cercle vide contenant un petit cercle plein. 6.5. Nœud de décision (decision node) Un nœud de décision est un nœud de contrôle qui permet de faire un choix entre plusieurs flots sortants. Il possède un arc entrant et plusieurs arcs sortants. 6.6. Nœud de fusion (merge node) Un nœud de fusion est un nœud de contrôle qui rassemble plusieurs flots alternatifs entrants en un seul flot sortant. 6.7. Nœud de bifurcation ou de débranchement (fork node) Un nœud de bifurcation, également appelé nœud de débranchement est un nœud de contrôle qui sépare un flot en plusieurs flots concurrents. 6.8. Nœud d’union ou de jointure (join node) Un nœud d’union, également appelé nœud de jointure est un nœud de contrôle qui synchronise des flots multiples Exemples de diagrammes d’activités 7. Diagramme d'états-transitions Le diagramme d'états-transitions représente la façon dont évoluent les objets appartenant à une même classe. Il décrit le comportement interne d'un objet à l'aide d'un automate à états finis. 7.1. Etat d’un objet L’état est une étape dans le cycle de vie d’un objet. C’est la situation d’un objet que l’on désire connaître et gérer. Chaque diagramme d’états-transitions comprend: 7.2. Transition Les états sont reliés par des connexions unidirectionnelles appelées transitions. C’est le passage d’un objet d’un état à un autre, elle est déclenchée par un événement. 7.3. Evénement déclencheur Les transitions d'un diagramme d'états-transitions sont déclenchées par des événements déclencheurs. L'événement déclencheur est indiqué à côte de la flèche représentant la transition. Exemples de diagramme d’états-transitions 8. Diagramme de déploiement Un diagramme de déploiement décrit la disposition physique des ressources matérielles qui composent le système et montre la répartition des composants sur ces matériels. 8.1. Nœud Un nœud est une ressource sur laquelle des artefacts peuvent être déployés pour être exécutés. Les nœuds peuvent être associés comme des classes et on peut spécifier des multiplicités 8.2. Artefact Un artefact correspond à un élément concret existant dans le monde réel (document, exécutable, fichier, tables de bases de données, script…) 8.3. Manifest On dit qu'un artefact peut manifester, c'est-à-dire résulter et implémenter, un ensemble d'éléments de modèle. On appelle manifestation « Manifest » la relation entre un élément de modèle et l'artefact qui l'implémente. Exemples de diagramme de déploiement 9. Diagramme d’objets Le diagramme d'objets représente les objets d'un système à un instant donné. Il permet de: • • • Illustrer le modèle de classes en montrant un exemple qui explique le modèle Préciser certains aspects du système en mettant en évidence des détails imperceptibles dans le diagramme de classes Exprimer une exception en modélisant des cas particuliers, des connaissances non généralisables. Diagramme de classes Diagramme d’objets cohérent Diagramme d’objets incohérent 10. Rational Unified Process (RUP) RUP est une démarche de développement qui est souvent utilisé conjointement au langage UML. Rational Unified Process (RUP) est à l'origine du processus unifié (PU) ou « unified process (UP) » et est à ce titre l'implémentation la plus connue. Rational Unified Process est: • • • Piloté par les cas d'utilisation; Itératif et incrémental; Centré sur l'architecture. 10.1. Organisation en phases du projet Les phases du développement sont les grandes étapes du projet. Le projet commence en phase d'initialisation et se termine en phase de transition. • Initialisation ou cadrage : Définition du produit et les objectifs du projet. • Elaboration : Planification des activités, définition des exigences, affectation des ressources, analyse de la faisabilité. • Construction : Développement du logiciel par incréments successifs, mise en œuvre du produit. • Transition Livrer, diffuser ou déployer le produit de sorte qu'il soit prêt à être utilisé. Cette phase inclut les recettes et la formation des utilisateurs si nécessaire. 10.2. Organisation en activités de développement Chaque phase comprend plusieurs itérations et pour chacune des itérations, on se livre à plusieurs activités : • Modélisation métier Mieux comprendre la structure et la dynamique de l'organisation, cartographier les processus métier de l'organisation cliente. • Expression des besoins Cibler les besoins des utilisateurs et du client grâce à une série d'interviews. C’est l’activité de recueil et d'expression des besoins qui débouche sur ce que doit faire le système. • Analyse Transformer les besoins utilisateurs en modèles UML. C’une la première ébauche du modèle de conception • Conception Modéliser comment le système va fonctionner avec les choix technologique. Le système est analysé et on produit une proposition d'architecture. • Implémentation Mise en œuvre et implémentation de l'architecture, des classes, et exécution de tests unitaires, intégration du système. • Test Planification des tests, conception des tests, mise en œuvre des tests, exécution des tests d'intégration, exécution de tests systèmes, et évaluation des tests. • Déploiement Déployer les développements une fois réalisés. Livrer, diffuser ou déployer le livrable.
