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

 

Développons en Java   2.30  
Copyright (C) 1999-2022 Jean-Michel DOUDOUX    (date de publication : 15/06/2022)

[ Précédent ] [ Sommaire ] [ Suivant ] [Télécharger ]      [Accueil ]

 

102. Java et UML

 

chapitre    1 0 2

 

Niveau : niveau 2 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 :

 

102.1. La présentation d'UML

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 :

  • des cas d'utilisations
  • de séquence
  • de collaboration
  • d'états-transitions
  • d'activité
  • de classes
  • d'objets
  • de composants
  • de déploiement

UML regroupe ces neufs diagrammes dans trois familles :

  • les diagrammes statiques (diagrammes de classes, d'objet et de cas d'utilisation)
  • les diagrammes dynamiques (diagrammes d'activité, de collaboration, de séquence, d'état-transitions et de cas d'utilisation)
  • les diagrammes d'architecture : (diagrammes de composants et de déploiements)

 

102.2. Les commentaires

Utilisable dans chaque diagramme, UML propose une notation particulière pour indiquer des commentaires.

Exemple :

 

102.3. Les cas d'utilisations (use cases)

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 :

  • d'acteurs : ce sont des entités qui utilisent le système à représenter
  • les cas d'utilisation : ce sont des fonctionnalités proposées par le système

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 :

  • la généralisation : cette relation peut être vue comme une relation d'héritage. Un cas d'utilisation enrichit un autre cas en le spécialisant

  • l'extension (stéréotype <<extend>>) : le cas d'utilisation complète un autre cas d'utilisation
  • l'inclusion (stéréotype <<include>>) : le cas d'utilisation utilise un autre 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).

 

102.4. Le diagramme de séquence

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 :

  • synchrone : l'émetteur attend une réponse du récepteur



  • asynchrone : l'émetteur poursuit son exécution sans attendre de réponse


Un diagramme de séquence peut aussi représenter le cycle de vie d'un objet.

Exemple :

 

 

102.5. Le diagramme de collaboration

Il permet de modéliser la collaboration entre les différents objets.

 

 

 

 

102.6. Le diagramme d'états-transitions

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 :

  • entrée (entry) : action réalisée à l'entrée dans l'état
  • sortie (exit) : action réalisée à la sortie de l'état
  • faire (do) : activité exécutée durant l'état

Exemple :

Il est aussi possible de définir des actions internes.

 

102.7. Le diagramme d'activités

 

 

 

 

102.8. Le diagramme de classes

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 :

  • la première partie contient le nom de la classe
  • la seconde contient les attributs de la classe
  • la dernière contient les méthodes de la classe

Exemple :

Exemple :
public class MaClasse {
}

 

102.8.1. Les attributs d'une classe

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;
}

 

102.8.2. Les méthodes d'une classe

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.

 

102.8.3. L'implémentation d'une interface

Exemple :

Exemple :
public class MaClasse implements MonInterface {
    public int champPublic = 0;
    protected double champProtected = 0;
    private boolean champPrive = false;

    public operation() {

    }
}

 

102.8.4. La relation d'héritage

Exemple :

Exemple :
public class MaClasseFille extends MaClasse {

}

 

102.9. Le diagramme d'objets

 

 

 

102.10. Le diagramme de composants

 

 

 

 

102.11. Le diagramme de déploiement

 

 

 


[ Précédent ] [ Sommaire ] [ Suivant ] [Télécharger ]      [Accueil ]

78 commentaires Donner une note à l´article (5)

 

Copyright (C) 1999-2022 Jean-Michel DOUDOUX. Vous pouvez copier, redistribuer et/ou modifier ce document selon les termes de la Licence de Documentation Libre GNU, Version 1.1 ou toute autre version ultérieure publiée par la Free Software Foundation; les Sections Invariantes étant constitués du chapitre Préambule, aucun Texte de Première de Couverture, et aucun Texte de Quatrième de Couverture. Une copie de la licence est incluse dans la section GNU FreeDocumentation Licence. La version la plus récente de cette licence est disponible à l'adresse : GNU Free Documentation Licence.