IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Framework de modélisation d'un projet en langage UML


précédentsommaire

IV. Modèle d'analyse

Cette partie est la réponse technique au Use Case Model.

Le modèle d'analyse est construit à partir d'un ensemble d'éléments de modélisation (les classes, les composants, les diagrammes de classes, les diagrammes de séquence) et structuré en plusieurs parties.

IV-A. Description des éléments de modélisation du modèle d'analyse

IV-A-1. Les Classes

IV-A-1-a. Multiplicité

1..n : on peut avoir une ou plusieurs classes.

IV-A-1-b. Utilisation d'une classe

À l'instar du Use Case Model, en analyse les classes modélisées ne représentent toujours pas des objets logiciels implémentables, mais résultent de la conceptualisation objet du système attendu.

Certaines de ces classes, les entités, sont directement issues de l'expression des besoins. Leur spécification se poursuit et se précise en analyse.

Les autres classes, services et médiations, sont identifiées au cours de l'analyse essentiellement en fonction des nécessités liées à la modélisation des scénarios.

IV-A-1-c. Contenu

Une classe peut contenir :

  • 1..n attributs ;
  • 1..n opérations.
IV-A-1-d. Documentation d'une classe

Elle doit contenir la définition de la classe et l'ensemble des commentaires et contraintes pertinents portant sur la classe dans son ensemble.

Il est également nécessaire de valoriser certains méta-attributs comme la volumétrie. La volumétrie indique le nombre d'instances possibles de la classe dans le système (il s'agit généralement plus d'un ordre de grandeur que d'une valeur précise).

IV-A-2. Composant

On distingue deux types de composants : les composants métier et les composants services.

Les composants métier modélisent la partie la plus stable du système d'information c'est-à-dire celle susceptible d'évoluer le moins dans le temps. Elle correspond en général aux entités stables du Système d'Information.

À la différence des composants métier, les composants services modélisent la partie la plus instable du système d'information c'est-à-dire celle susceptible d'évoluer le plus dans le temps. Elle correspond en général aux processus métier dont le rôle est d'orchestrer les composants métier.

Les services rendus par un composant service doivent être à terme exprimés à travers des interfaces présentées par le composant, mais réalisées par les entités du composant de manière à renforcer l'encapsulation des objets et donc le faible couplage des composants entre eux.

Exemple : pour un projet Serveur un composant métier peut être constitué de :

  • Classes pour les services simples (SISV pour service simple) ;
  • Classes pour la DAO (Data Access Object) : ce sont les classes pour les accès aux données ;
  • Classes d'objets du domaine : DTO (Data Transfert Object), Criteria.
Figure 8 : Exemple de Composant métier Users
Figure 8 : Exemple de Composant métier Users
IV-A-2-a. Multiplicité

1..n : on peut avoir un ou plusieurs composants.

IV-A-2-b. Convention de nommage

Pour les composants métier : <<composant>> <nom du composant métier>

Pour les composants Services : <<service>> <nom du composant service>

IV-A-2-c. Contenu

Pour un composant métier :

  • 1..n entités représentant les objets métier du composant ;
  • 1..n diagrammes de classes manifestant ces entités et les associations qu'elles partagent avec des entités du même composant ou des entités d'autres composants métier.

Pour un composant service :

  • 1..n contrôles représentant les processus métier du système ;
  • 1..n diagrammes de classes manifestant ces contrôles et les associations qu'ils partagent avec des médiateurs donnant accès aux composants métier.

IV-A-3. Diagramme de Classe

IV-A-3-a. Multiplicité

1..n : on peut avoir un ou plusieurs diagrammes de classe.

IV-A-3-b. Conventions de nommage

Si le diagramme de classes est le seul présent dans le package considéré, son nom doit être <Structure>.

S'il doit y avoir plusieurs diagrammes de classes dans un même package, les noms possibles sont les suivants :

- pour un diagramme présentant une partie de la structuration des classes généralement autour d'une classe donnée, le nom devra être : Structure - <nom de la classe centrale> ;

- si autour d'une même classe plusieurs diagrammes doivent être présentés, le nom de chacun devra être :
Structure - <nom de la classe centrale > - <nom qualifiant l'objectif du diagramme> ;

- pour un diagramme présentant un arbre de généralisation-spécialisation particulier, le nom devra être :
Classification - <nom de la super-classe>.

IV-A-3-c. Utilisation

Un ou plusieurs diagrammes de classes doivent être fournis pour chacun des packages (cf. IV?2IV-2) présents dans les différentes couches du modèle statique d'analyse. Chacun présente un ensemble cohérent des classes du package éventuellement accompagnées d'un ensemble de classes d'autres packages du modèle avec lesquelles les premières partagent des associations (ou mieux, les interfaces d'autres composants), en fonction de l'objectif exact du diagramme tel qu'il est présenté par son nom et par sa documentation.

Par ailleurs des diagrammes de classes doivent également être utilisés pour représenter graphiquement les packages formant l'architecture logique en couches du système à ses différents niveaux et les relations de dépendance qui les structurent.

IV-A-3-d. Documentation d'un diagramme de classe

Elle doit contenir une description de l'objectif du diagramme c'est-à-dire la raison pour laquelle le diagramme a été créé, de manière à manifester un ensemble particulier de classes avec un ensemble particulier de relations (associations, arbres de généralisation ou de spécialisation) qu'elles partagent.

Figure 9 : Exemple de diagramme de classe de la couche SISV
Figure 9 : Exemple de diagramme de classe de la couche SISV

IV-A-4. Diagramme de Séquence

IV-A-4-a. Multiplicité

1..n : On peut avoir un ou plusieurs diagrammes de séquence.

IV-A-4-b. Conventions de nommage

SC<numéro d'ordre du scénario>-<type du scénario>-<nom du scénario>

Les différents paramètres du nommage ci-dessus sont identiques à ceux définis pour le diagramme de séquence de niveau système du modèle des cas d'utilisation (voir III-1-4III-1-4)

IV-A-4-c. Utilisation d'un diagramme de séquence

En analyse les diagrammes de séquence spécifiés présentent les interactions entre instances des classes. Là où les diagrammes de séquence de niveau système exprimaient les scénarios de déroulement des cas d'utilisation avec une vue <boite noire> sur le système, les diagrammes de séquence du modèle dynamique d'analyse expriment ces mêmes scénarios en s'appuyant sur les objets du système tels qu'ils ont été définis. L'objet système est <explosé> pour faire apparaître ses constituants.

Chacun de ces diagrammes de séquence d'analyse doit être créé dans le package contenant la réalisation de cas d'utilisation correspondant au package de cas d'utilisation qui contient le diagramme de séquence de niveau système auquel il est lié.

Chacun diagramme de séquence présente :

- les acteurs sous la forme d'une ou plusieurs de leurs instances ;

- les objets pertinents du système dans le cadre du scénario c'est-à-dire intervenant effectivement dans son déroulement sous la forme d'instances de classes du modèle statique d'analyse, quelle que soit la nature de ces classes (frontières, services ou entités). Globalement on trouvera dans chacun de ces diagrammes :

  • une instance de l'acteur initiateur du cas d'utilisation dont la réalisation est spécifiée à travers le diagramme de séquence considéré,
  • une ou plusieurs instances de classes frontières, notamment celle de la frontière assurant la médiation avec l'acteur initiateur, mais également toutes celles des frontières représentant les médiateurs avec tous les autres acteurs impliqués dans le scénario considéré,
  • une ou plusieurs instances des classes contrôles responsables des services métier utilisés dans le cadre de la réalisation du scénario considéré,
  • ne ou plusieurs instances des classes entités utilisées ou manipulées utilisées dans le cadre de la réalisation du scénario considéré ;

- l'enchaînement des interactions, des actions et réactions, entre les acteurs et le système sous la forme de messages ordonnancés temporellement entre les instances des acteurs et les constituants du système.

Figure 10 : Diagramme de séquence de SC10-Nominal-Enregistrer un chèque Banque
Figure 10 : Diagramme de séquence de SC10-Nominal-Enregistrer un chèque Banque
Figure 11 : Notes de l'UCR SC10-Nominal-Enregistrer un chèque Banque
Figure 11 : Notes de l'UCR SC10-Nominal-Enregistrer un chèque Banque

IV-B. Contenu du modèle d'analyse

Le modèle d'analyse est composé de quatre packages principaux :

  • le package des composants métier ;
  • le package des médiations ;
  • le package des composants services ;
  • le package des Uses Case Realization.

Chacun de ces packages représente une unité de regroupement d'entités fortement cohérentes autour d'un concept central dont on envisage qu'elles rendent collectivement des services

IV-B-1. Package des composants métier

C'est dans ce package qu'on regroupe tous les composants métier du système. Rappelons que les composants métier représentent la partie la plus stable du système.

IV-B-1-a. Multiplicité

1..n : on peut avoir un ou plusieurs packages de composants.

IV-B-1-b. Nommage

Ce package porte le nom <<layer>>BusinessComponent. À l'intérieur de <<layer>>BusinessComponent on trouve tous nos composants métier.

IV-B-1-c. Documentation

Elle doit contenir une description de l'intention du package c'est-à-dire des composants regroupés dans le package.

Pour un projet Serveur on peut par exemple avoir comme l'illustre la figure 12, un package de composants métier :

Figure 12 : Exemple d'un package de composant métiers pour un projet serveur
Figure 12 : Exemple d'un package de composant métier pour un projet serveur

IV-B-2. Package des composants services

C'est dans ce package qu'on regroupe tous les composants service du système. Rappelons que les composants service représentent la partie la plus instable du système c'est-à-dire celle en charge d'orchestrer les services proposés par la couche de composants métier.

IV-B-2-a. Multiplicité

1..n : on peut avoir un ou plusieurs packages services.

IV-B-2-b. Nommage

Pour un projet serveur le package des services est symbolisé par <<layer>>Services. À l'intérieur on retrouve tous nos composants services (cf IV-1-2IV-1-2).

Pour un projet front-end ce pourrait être les classes d'actions qui sont en charge d'orchestrer les services offerts par le serveur. Les classes d'actions peuvent dans ce cas être regroupées dans <<layer>><Front-End Action>.

Figure 13 : Exemple de Services d'un projet Serveur.
Figure 13 : Exemple de Services d'un projet Serveur.

IV-B-3. Package des médiations

On y met les médiations entre les différents composants du système ainsi qu'entre le système et les acteurs extérieurs.

IV-B-3-a. Multiplicité

1..n : on peut avoir un ou plusieurs packages de médiation.

IV-B-3-b. Nommage

<<interface>><nom du regroupement des médiations>

IV-B-3-c. Contenu

1..n frontières (classes stéréotypées avec le stéréotype standard <boundary>) représentant les objets médiateurs des interactions entre les composants ainsi qu'entre le système et ses acteurs.

Pour un projet Serveur on peut avoir un médiateur pour l'accès aux composants service : SVCOFinder. Il peut aussi exister un médiateur pour l'accès aux composants métier : SISVFinder. Il peut enfin exister un médiateur pour l'accès aux entités d'accès aux données : DAOController.

Figure 14 : package médiation d'un projet Serveur
Figure 14 : package médiation d'un projet Serveur

IV-B-4. Package Use Case Realization

Le contenu de ce package forme le modèle dynamique d'analyse.

IV-B-4-a. Package des Regroupements de réalisation des cas d'utilisation

Un tel package regroupe un sous-ensemble des réalisations de cas d'utilisation correspondant aux sous-ensembles de cas d'utilisation identifiés dans le modèle des cas d'utilisation.

IV-B-4-a-i. Multiplicité

1..n : on peut avoir un ou plusieurs packages de regroupement des réalisations de cas d'utilisation.

IV-B-4-a-ii. Convention de Nommage

<<UCR Package>> <nom du regroupement de réalisations de cas d'utilisation>

Un package de regroupement des réalisations de cas d'utilisation doit être créé par package de regroupement de cas d'utilisation du modèle des cas d'utilisation en portant le même nom que ce dernier.

IV-B-4-a-iii. Contenu
  • 1..n packages de réalisation de cas d'utilisation (voir figure 15).
  • 1 diagramme de cas d'utilisation manifestant la traçabilité des cas d'utilisation par leurs réalisations respectives.
Figure 15 : Package d'UCR
Figure 15 : Package d'UCR
IV-B-4-b. Package de réalisation de cas d'utilisation

Chacun de ces packages représente une unité de modélisation cohérente détenant la spécification de la réalisation d'un cas d'utilisation sur la base des objets identifiés dans le système. La réalisation d'un cas d'utilisation consiste à <éclater> l'entité <Système> présente sur les diagrammes de séquence du cas d'utilisation origine afin de faire apparaître les classes boundary, service et métier qui constituent le système.

IV-B-4-b-i. Multiplicité

1..n : on peut avoir un ou plusieurs packages de réalisation de cas d'utilisation.

IV-B-4-b-ii. Convention de Nommage

<<Use Case Realization>> <nom de la réalisation de cas d'utilisation>

Un package de réalisation de cas d'utilisation doit être créé par package de cas d'utilisation du modèle des cas d'utilisation en portant le même nom que ce dernier (à l'exception du préfixe qui doit être <UCR-> et non <UC-x->.

IV-B-4-b-iii. Contenu
  • 1 réalisation de cas d'utilisation (cas d'utilisation stéréotypé)
  • 1..n diagrammes de séquence manifestant chacun un scénario de réalisation du cas d'utilisation (nominal, alternatif ou d'erreur) faisant intervenir des instances des classes identifiées dans le modèle d'analyse.
Figure 16 : Contenu d'un package de réalisation de cas d'utilisation
Figure 16 : Contenu d'un package de réalisation de cas d'utilisation

V. Cas pratique : Modélisation UML d'un projet simple

V-A. Spécifications fonctionnelles du projet

GestClient est une application de gestion des clients. L'application doit permettre à un utilisateur de rôle Administrateur de :

  • créer un client ;
  • rechercher un ou des clients selon certains critères ;
  • modifier un client ;
  • désactiver un client.

Ce projet va comporter une partie serveur et une partie front-end. La partie serveur va exposer ses services au front-end, ce dernier pouvant par exemple être une winapp ou une webapp.

V-B. Modélisation de la partie serveur : GestClient.Server

V-B-1. Use Case Model

V-B-1-a. Package Actor

On distingue un acteur externe qui est ici le Front-end.

V-B-1-b. Package Context

On distingue l'application serveur et la base de données.

V-B-1-c. Package Use Cases

Nous avons un seul package de gestion des clients : <<UC Package>>CLIENT-Gestion des clients. Ce package contient 5 use cases tel que le présente la figure ci-dessous :

Figure 32 : UC Package Gestion des clients
Figure 32 : UC Package Gestion des clients


Ci-dessous le diagramme de cas d'utilisation du <<UC Package>>CLIENT-Gestion des clients

Figure 33 : Diagramme de cas d'utilisation du UC Package CLIENT-Gestion des clients
Figure 33 : Diagramme de cas d'utilisation du UC Package CLIENT-Gestion des clients


Pour chaque UC, on distingue un diagramme de séquence pour le cas nominal, comme le montre la figure ci-dessous :

Figure 34 : Diagramme de séquence Nominal du UC Package CLIENT-Gestion des clients
Figure 34 : Diagramme de séquence Nominal du UC Package CLIENT-Gestion des clients


La figure ci-dessous montre le diagramme de cas nominal du use case UC-CLIENT-004-Rechercher Client

Figure 35 : diagramme de cas nominal du use case UC-CLIENT-004-Rechercher Client
Figure 35 : diagramme de cas nominal du use case UC-CLIENT-004-Rechercher Client

V-B-2. Modèle d'analyse

V-B-2-a. Data Model

C'est dans cette partie qu'on conçoit le modèle de donnée du projet.
Le Data Model fera l'objet d'un article ultérieur.

V-B-2-b. Package des composants métier

Nous avons un seul composant métier : <<composant>>Client. Ce composant comprend un ensemble d'éléments présentés par la figure ci-dessous :

Figure 36 : composant Client
Figure 36 : composant Client
  • <<domain>>ClientCriteria : contient les critères de recherche d'un client
  • <<domain>>ClientDTO : encapsule des données d'un client
  • <<interface>>IClientDAO : pour l'accès à la base de données
  • <<interface>>IClientSISV : service simple implémentant la logique métier.
V-B-2-c. Package des composants services

Nous disposons d'un composant de services :

Figure 37 : service Client
Figure 37 : service Client
V-B-2-d. Package des médiations

On distingue trois médiateurs permettant de mettre en relation des différentes couches de l'application :

Figure 38 : layer Médiations
Figure 38 : layer Médiations
  • DAOController : médiateur pour l'accès aux services de la couche DAO
  • SISVFinder : médiateur pour l'accès aux services de la couche SISV
  • SVCOFinder : médiateur pour l'accès aux services de la couche SVCO
V-B-2-e. Package des réalisations des cas d'utilisation

Pour chaque use case on a un « Use Case Realization » correspondant tel que le présente la figure ci-dessous :

Figure 39 : Use Case Realization gestion des clients
Figure 39 : Use Case Realization gestion des clients


La figure ci-dessous présente le diagramme de cas réalisation nominal de création d'un client :

Figure 40 : SC10-Nominal-Creer un client
Figure 40 : SC10-Nominal-Creer un client

V-B-3. Téléchargement du projet UML de la partie serveur de l'exemple

Le projet UML de la partie serveur de l'exemple est disponible sur le lien suivant : projet UML du serveurprojet UML du serveur

Il a été fait à l'aide de l'outil Enterprise Architect dont une version d'évaluation est disponible sur le lien suivant : Enterprise Architect 30 days trialEnterprise Architect 30 days trial

V-C. Modélisation du Front End : GestClient.FrontEnd

V-C-1. User Interface Model

Cette partie est réservée à la modélisation des interfaces utilisateurs d'un projet front-end. Le User Interface Model fera l'objet d'un article ultérieur.

V-C-2. Use Case Model

V-C-2-a. Package Actor

On distingue un acteur humain qui est ici l'administrateur.

V-C-2-b. Package Context

C'est le bloc constitué par la winform.

V-C-2-c. Package Use Cases

On distingue trois regroupements de cas d'utilisation :

  • <<UC Package>>Connexion : traite les cas d'utilisations liés au module de Connexion ;
  • <<UC Package>>Gestion des clients : traite des cas d'utilisations liés au module de Clients ;
  • <<UC Package>>Welcome : traite des cas d'utilisations liés au module de page d'accueil (ou Welcome).
Figure 17 : UC packages du projet GestClient.FrondEnd
Figure 17 : UC packages du projet GestClient.FrondEnd
V-C-2-c-i. <<UC Package>>-Connexion

Il contient à son tour le regroupement <<UC Package>>LOGIN-Connexion comme le montre la figure 18.

Figure 18 : UC Package - Connexion
Figure 18 : UC Package - Connexion


<<UC Package>>LOGIN-Connexion contient les UC suivants :

  • UC-LOGIN-001-Initialiser et afficher la page de login ;
  • UC-LOGIN-002-S'authentifier via le login et le mot de passe ;
  • UC-LOGIN-003-Fermer la page de login.

Tous ces UC étendent le 'UC-LOGIN-000-Se connecter' qui est quant à lui un UC abstrait.

Figure 19 : UC Package LOGIN-Connexion
Figure 19 : UC Package LOGIN-Connexion


La figure 20 nous montre le diagramme de cas d'utilisation pour <<UC package>>LOGIN-Connexion

Figure 20 : diagramme de cas d'utilisation pour <<UC package>>LOGIN-Connexion
Figure 20 : diagramme de cas d'utilisation pour <<UC package>>LOGIN-Connexion


Dans chaque UC on distingue un diagramme de séquence pour le cas nominal, comme le montrent la figure 21 et la figure 22

Figure 21 : Diagrammes de séquence Nominal du UC Package LOGIN-Connexion
Figure 21 : Diagrammes de séquence Nominal du UC Package LOGIN-Connexion


La figure 22 montre le diagramme de séquence « Nominal SC10-Nominal-S'authentifier via login et pwd ».

Figure 22 : SC10-Nominal-Connexion : Use Case S'authentifier via login et pwd
Figure 22 : SC10-Nominal-Connexion : Use Case S'authentifier via login et pwd

V-C-3. Modèle d'analyse

V-C-3-a. Data Model

C'est dans cette partie qu'on conçoit le modèle de donnée du projet. Le Data Model fera l'objet d'un article ultérieur.

V-C-3-b. Package des composants métier

Le package des composants métier <<Layer>>BusinessComponent contient tous les composants métier du projet.
Dans le cas du projet front-end nous avons le <<Composant>>Client qui contient une <<interface>>IClientSVCO : il s'agit d'un service fourni par le serveur.

Figure 23 : <<Layer>>BusinessComponent
Figure 23 : <<Layer>>BusinessComponent
V-C-3-c. Package des composants services

Comme c'est une application front-end, ici on parle de « <<Layer>>Front-End Controller » et on y présente tous les contrôleurs de l'application. Les contrôleurs sont regroupés par modules :

  • <controller>Client dans le module Client ;
  • <controller>Login dans le module Connexion ;
  • <controller>Welcome dans le module Welcome.
Figure 24 : <<layer>>Frond-End Controller
Figure 24 : <<layer>>Frond-End Controller
Figure 25 : Diagramme de classes  des contrôleurs
Figure 25 : Diagramme de classes des contrôleurs


<controller>Login contient <<control>>LoginController. Ce contrôleur contient les méthodes suivantes :

  • EnterFromLoginPwd() : méthode publique qui effectue l'authentification sur la base du login et mot de passe.
  • Fermer() : méthode publique pour fermer la page de login et quitter l'application.
V-C-3-d. Package des médiations

Ici sont représentées les médiations entre les différents composants du système ainsi qu'entre le système et les acteurs extérieurs.
On distingue :

  • les écrans de l'application : médiation entre l'utilisateur et l'application ;
  • la médiation entre le FrondEnd et le BackEnd ;
  • la médiation entre les actions des utilisateurs et leurs traitements.
Figure 26 : Package des médiations
Figure 26 : Package des médiations
V-C-3-e. Package des réalisations des cas d'utilisation

Les différents packages recensés pour ce projet sont :

  • <<UCR Package>>-Connexion : traite les cas d'utilisations liés au module de Connexion ;
  • <<UCR Package>>-Gestion des clients : traite des cas d'utilisations liés au module de Clients ;
  • <<UCR Package>>-Welcome : traite des cas d'utilisations liés au module de page d'accueil.

Ces packages sont organisés comme le présente la figure 27 ci-dessous :

Figure 27 : UCR packages du projet GestClient.FrondEnd
Figure 27 : UCR packages du projet GestClient.FrondEnd
V-C-3-e-i. <<UCR Package>>-Connexion

Il est organisé comme présenté dans les figures ci-dessous :

Figure 28 : UCR Package Connexion
Figure 28 : UCR Package Connexion


<<UCR package>>LOGIN-Connexion contient les Use Case de réalisation ci-dessous :

Figure 29 : UCR Package LOGIN-Connexion
Figure 29 : UCR Package LOGIN-Connexion


Chaque UCR contient un diagramme de séquence représentant le cas Nominal.

Figure 30 : UCR package LOGIN-Connexion
Figure 30 : UCR package LOGIN-Connexion
Figure 31 : SC10-Nominal-Connexion : use case S'authentifier via login et pwd
Figure 31 : SC10-Nominal-Connexion : use case S'authentifier via login et pwd

V-C-4. Téléchargement du projet UML de la partie front-end de l'exemple

Le projet UML de la partie front-end de l'exemple est disponible sur le lien suivant : projet UML du front-endprojet UML du front-end

Il a été fait à l'aide de l'outil Enterprise Architect dont une version d'évaluation est disponible sur le lien suivant : Enterprise Architect 30 days trialEnterprise Architect 30 days trial

Koossery Technology est une entreprise spécialisée dans les développements de projets au forfait (.NET & Java J2ee) et dispose pour cela d'une cellule Architecture Technique et Outillages ainsi que d'une Usine Logicielle.

Koossery Technology dispose aussi d'un Centre de Service GED-ECM-BPM Alfresco, jBPM pour adresser les projets GED-ECM-BPM sur la base des plate-formes Alfresco et jBoss BPM.

Tous nos remerciements au comité de relecture developpez.com

Vos réactions par l'intermédiaire de ce fil : 8 commentaires Donner une note à l´article (5)


précédentsommaire