| Développons en Java 2.30 | |
| Copyright (C) 1999-2022 Jean-Michel DOUDOUX | (date de publication : 15/06/2022) |
|
|
 |
 |
 |
 |
| Niveau : |  Elémentaire |
Le but d'UML est de modéliser un système en utilisant des objets. L'orientation objet de Java ne peut qu'inciter à l'utiliser avec UML. La modélisation proposée par UML repose sur 9 diagrammes.
Ce chapitre contient plusieurs sections :
UML qui est l'acronyme d'Unified Modeling Language est aujourd'hui indissociable de la conception objet. UML est le résultat de la fusion de plusieurs méthodes de conception objet des pères d'UML qui étaient : Jim Rumbaugh (OMT), Grady Booch (Booch method) et Ivar Jacobson (use case).
UML a été adopté et normalisé par l'OMG (Object Management Group) en 1997.
D'une façon général, UML est une représentation standardisée d'un système orienté objet.
UML n'est pas une méthode de conception mais une notation graphique normalisée de présentation de certains concepts pour modéliser des systèmes objets. En particulier, UML ne précise pas dans quel ordre et comment concevoir les différents diagrammes qu'il défini. Cependant, UML est indépendant de toute méthode de conception et peut être utilisé avec n'importe lequel de ces processus.
Un standard de présentation des concepts permet de faciliter le dialogue entre les différents acteurs du projet : les autres analystes, les développeurs et même les utilisateurs.
UML est composé de neuf diagrammes :
UML regroupe ces neufs diagrammes dans trois familles :
Utilisable dans chaque diagramme, UML propose une notation particulière pour indiquer des commentaires.
Exemple :
Ils sont développés par Ivar Jacobson et permettent de modéliser des processus métiers en les découpant en cas d'utilisations.
Ce diagramme permet de représenter les fonctionnalités d'un système. Il se compose :
Un acteur n'est pas une personne désignée : c'est une entité qui joue un rôle dans le système. Il existe plusieurs types de relations qui associent un acteur et un cas d'utilisation :
Les cas d'utilisation sont particulièrement intéressants pour recenser les différents acteurs et les différentes fonctionnalités d'un système.
La simplicité de ce diagramme lui permet d'être rapidement compris par des utilisateurs non-informaticiens. Il est d'ailleurs très important de faire participer les utilisateurs tout au long de son évolution.
Le cas d'utilisation est ensuite détaillé en un ou plusieurs scénarios. Un scénario est une suite d'échanges entre des acteurs et le système pour décrire un cas d'utilisation dans un contexte particulier. C'est un enchaînement précis et ordonné d'opérations pour réaliser le cas d'utilisation.
Si le scénario est trop "volumineux", il peut être judicieux de découper le cas d'utilisation en plusieurs et d'utiliser les relations appropriées.
Un scénario peut être représenté par un diagramme de séquence ou sous une forme textuelle. La première forme est très visuelle
Exemple :
La seconde facilite la représentation des opérations alternatives.
Les cas d'utilisation permettent de modéliser des concepts fonctionnels. Ils ne précisent pas comment chaque opération sera implémentée techniquement. Il faut rester le plus abstrait possible dans les concepts qui s'approchent de la partie technique.
Le découpage d'un système en cas d'utilisation n'est pas facile car il faut trouver un juste milieu entre un découpage fort (les scénarios sont importants) et un découpage faible (les cas d'utilisation se réduisent à une seule opération).
Il permet de modéliser les échanges de messages entre les différents objets dans le contexte d'un scénario précis.
Il permet de représenter les interactions entre différentes entités. Il s'utilise essentiellement pour décrire les scénarios d'un cas d'utilisation (les entités sont les acteurs et le système) ou décrire des échanges entre objets.
Dans le premier cas, les interactions sont des actions qui sont réalisées par une entité.
Dans le second cas, les itérations sont des appels de méthodes.
Les itérations peuvent être de deux types :
Un diagramme de séquence peut aussi représenter le cycle de vie d'un objet.
Exemple :
Il permet de modéliser la collaboration entre les différents objets.
Un diagramme d'état permet de modéliser les différents états d'une entité, en générale une classe. L'ensemble de ces états est connu.
Ce diagramme se compose de plusieurs éléments principaux :
|
|
état intermédiaire |
|
|
état initial |
|
|
état final |
|
|
une transition |
Exemple :
Les transitions sont des événements qui permettent de passer d'un état à un autre : chaque transition possède un sens qui précise l'état de départ et l'état d'arrivée (du côté de la flèche). Une transition peut avoir un nom qui permet de la préciser.
Exemple :
Il est possible d'ajouter une condition à une transition. Cette condition est une expression booléenne placée entre crochets qui sera vérifiée lors d'une demande de transition. Cette condition est indiquée entre crochets.
Exemple :
Dans un état, il est possible de préciser des actions ou des activités qui sont des traitements à réaliser. Celles-ci sont décrites avec une étiquette qui désigne le moment de l'exécution.
Une action est un traitement cours. Une activité est un traitement durant tout ou partie de la durée de maintient de l'état.
Plusieurs étiquettes standard sont définies :
Exemple :
Il est aussi possible de définir des actions internes.
Ce schéma représente les différentes classes : il détaille le contenu de chaque classe mais aussi les relations qui peuvent exister entre les différentes classes.
Une classe est représentée par un rectangle séparé en trois parties :
Exemple :
| Exemple : |
public class MaClasse {
} |
Pour définir un attribut, il faut préciser son nom suivi du caractère ":" et du type de l'attribut.
Le modificateur d'accès de l'attribut doit précéder son nom et peut prendre les valeurs suivantes :
| Caractère | Rôle |
| + | accès public |
| # | accès protected |
| - | accès private |
Une valeur d'initialisation peut être précisée juste après le type en utilisant le signe "=" suivi de la valeur.
Exemple :
| Exemple : |
public class MaClasse {
public int champPublic = 0;
protected double champProtected = 0;
private boolean champPrive = false;
} |
Les modificateurs sont identiques à ceux des attributs.
Les paramètres de la méthode peuvent être précisés en les indiquant entre les parenthèses sous la forme nom : type.
Si la méthode renvoie une valeur son type doit être précisé après un signe ":".
Exemple :
| Exemple : |
public class MaClasse {
public void methode1(int valeur){
}
protected String methode2(){
}
private void methode3(){
}
} |
Il n'est pas obligatoire d'inclure dans le diagramme tous les attributs et toutes les méthodes d'une classe : seules les entités les plus significatives et utiles peuvent être mentionnées.
Exemple :
| Exemple : |
public class MaClasse implements MonInterface {
public int champPublic = 0;
protected double champProtected = 0;
private boolean champPrive = false;
public operation() {
}
} |
Exemple :
| Exemple : |
public class MaClasseFille extends MaClasse {
} |
|
|
