1. Quesako ?

Modélisation orientée objet

Selon le paradigme orienté objet, un système est un ensemble d’objets en interaction. Le diagramme de classe en est une représentation statique. On y définit la structure des objets, et les différents types de relations entre ces objets leur permettant de coopérer.

Exemple de diagramme de classe d’analyse :

Élaboration du diagramme de classe

Dans un projet informatique, il faut trouver les classes, attributs et associations. En collaboration avec un expert du domaine, les classes candidates sont généralement découvertes parmi les concepts du domaine métier du système.

Le cahier des charges et autres spécifications (cas d’utilisation par exemple) sont des sources d’information. Les substantifs ou groupes nominaux permettent de trouver les attributs. Ils peuvent être ajoutés tout au long du cycle de vie d’un projet (implémentation comprise). Les relations correspondent souvent à des verbes ou constructions verbales (Attention ! Certains attributs peuvent être en réalité des relations). Un ébauche du diagramme de classe est proposée en éliminant les classes redondantes, en utilisant l’héritage pour factoriser comportements et propriétés, …

Une fois le diagramme de classe ébauché, d’autres technique méthodologique vont permettre de l’affiner et de l’enrichir tout au long du cycle de développement du projet. Un modèle est rarement correct dès la première ébauche, la modélisation est itérative.

3 points de vue pour guider la modélisation

Les trois points de vue suivants ont était proposés par Cook et Daniels (1994) :

1. Le point de vue spécification Il met l’accent sur les interfaces des classes plutôt que sur leurs contenus.
2. Le point de vue conceptuel Il capture les concepts du domaine et leurs relations, indépendamment de la manière d’implémenter ces concepts ou ces relations et des langages.
3. Le point de vue implémentation Il détaille le contenu et l’implémentation de chacune des classes.

2. Premiers éléments de modèle

2.a Les propriétés d’une classe

• Nom Une classe a un nom. Le nom d’une classe correspond au type des objets instanciés à partir de cette classe.
• Attributs Les attributs sont les propriétés structurelles partagées par tous les objets/toutes les instances d’une même classe. Ce sont des attributs d’instance (à ne pas confondre avec les attributs de classe, soulignés dans l’exemple et vus plus bas).

L’ensemble des valeurs des attributs correspond à l’état de la classe.

• Opérations Les opérations sont des propriétés comportementales. L’implémentation des méthodes décrit le comportement possible des objets de cette classe. Tous les objets/toutes les instances d’une même classe sont capables de réaliser ses opérations.
• Associations Les associations sont des attributs représentés par une association avec une autre classe (choix d’UML). Le nom de l’attribut est indiqué sur la terminaison de l’association, ainsi que sa cardinalité représentant le nombre d’objets “portés” par cette association.

Deux représentations possibles (c’est pour cela qu’on peut parler d’attributs) :

2.b Diagramme d’objet

Ce diagramme d’objet est conforme au diagramme de classe de la section précédente. Le diagramme d’objet permet de représenter un cas particulier d’instanciation du diagramme de classe, voire un contre-exemple. Cela participe à une meilleur compréhension de l’architecture.

Remarque : un objet de la classe A peut être nommé unObjet:A ou simplement :A ou pour signifier qu’il est de type A.

3. Le diagramme de classe, pas à pas …

3.a Visibilité des propriétés

Les attributs et méthodes d’une classes peuvent être privés, publics ou protégés. Afin de respecter le principe d’encapsulation des objets, les attributs d’une classe doivent être privés et donc inaccessibles. Des opérations permettent d’accéder ou de modifier ces attributs selon des règles d’accès correspondant aux besoins de l’application. Ce sont les getters et setters.

Les différents niveaux de visibilité sont les suivants :

• Public Les propriétés publiques d’une classe sont accessibles depuis n’importe quelle autre classe. Le signe + est utilisé devant le nom de la propriété.
• Protected Les propriétés protégées d’une classe sont accessibles par la classe elle-même et les sous-classes qui en dérivent par héritage (cf plus loin). Le signe # est utiliser devant le nom de la propriété.
• Package Les propriétés de visibilité de paquetage ne sont accessibles que par les classes du même paquetage. Le signe ~ est utilisé devant le nom de la propriété.
• Private Les propriétés privées d’une classe ne sont pas accessibles en dehors de cette classe. Le signe - est utiliser devant le nom de la propriété.

3.b Propriétés des attributs

Ci-dessous, l’ensemble des propriétés possibles pour décrire un attribut :

• Attribut dérivé C’est un attribut dont la valeur se calcule/se dérive à partir de la valeur des autres attributs. Il n’est pas nécessaire de stocker sa valeur.

Exemple :

3.C Propriétés d’une association

Ci-dessous, l’ensemble des propriétés possibles pour décrire un attribut.

• Le nom Une association est nommée par un verbe, avec éventuellement un signe < ou > pour indiquer le sens de lecture.
• Nom de rôle Nom donné à une terminaison d’association. C’est une propriété de la classe, comme vu précédemment.
• Visibilité Même principe qu’un attribut.
• Cardinalité Indique le nombre d’éléments portés par l’association. Exemples : 1 / 0..1 / 3..7 / 0..* / 1..* / *

Une voiture a un à deux propriétaires ! Si on avait mis 0..1 : une voiture aurait pu être sans propriétaire. Une personne peut ne pas avoir de voiture et peut en avoir autant qu’elle le veut.

• Navigabilité Contraint la navigation d’une association. On ne peut pas connaître les véhicules d’une personne.

Si l’association ‘possede’ était dirigée vers la classe Personne, la classe Personne ne possèderait pas de propriété vehicule. Si l’assocation ‘possede’ était dirigée vers la classe Voiture, il ne serait pas possible de retrouver le propriétaire à partir d’un véhicule.

3.d Cas particuliers d’associations

Association qualifiée

L’association qualifiée restreint la portée d’une association à quelques éléments ciblés (1 ou plusieurs attributs). Un objet qualifié et une valeur de qualificatif génère un objet cible lié unique.

Les cases d’un échiquier sont identifiées par leurs deux coordonnées. Un client d’une banque est identifié par son numéro de compte.

Classe d’association

La classe d’association permet de mettre des propriétés, ou du comportement sur une association.

Il y a une seule note de contrôle continu par couple élève-module.

3.e Agrégation et Composition

Agrégation

La relation d’agrégation est une relation d’inclusion structurelle ou comportementale.

La signification est uniquement conceptuelle et ne fait pas de différence au niveau implémentation par rapport à une association normal. Il n’y a aucune incidence sur la durée de vie des objets contenus, ni de contrainte sur les multiplicités.

Composition

La relation de composition est une relation Composé — composant.

Contrairement à l’agrégation, le partage d’un composant par plusieurs composé est impossible. C’est cela qui permet de les différencier.

Les cycles de vie du composé et de ses composants sont liés. Si on détruit un carré, on détruit automatiquement tous ses points

La composition impose une contrainte sur les cardinalités du côté du losange plein : 0..1 ou 1, puisqu’une instance ne peut pas être partagée.

Q. Dans l’exemple, il n’est pas possible de spécifier les cardinalités du côté du losange (0..1 ou 1), pourquoi ?

3.f Généralisation ou héritage

La relation d’héritage est une relation de type “est du type de” ou encore “est une sorte de”. Les classes filles (appelées encore dérivées, ou sous classes) héritent de toutes les propriétés de la classe mère (appelée encore de base ou super classe) : attributs, opérations, associations.

Ainsi, l’héritage permet de réutiliser des classes existantes, mais le couplage entre classes et sous-classes est très fort !

La classe Client est abstraite, car pas complètement définie. Pour pouvoir créer un objet client, il faut savoir si c’est une personne morale ou une personne physique. Par polymorphisme, l’attribut acheteur de la classe Commande est de type Client.

Remarque : la délégation permet aussi de réutiliser le comportement d’une autre classe.

3.g Classe abstraite

La classe abstraite est une classe générique pas complètement implémentée. Elle ne peut pas être instanciée car une partie de la définition de la classe est manquante. Une classe abstraite est nommée en italic, ou grâce au mot clé {abstract}.

La classe abstraite contient des méthodes abstraites qui seront implémentées par les classes filles. Une classe concrète est une classe fille d’une classe abstraite qui complète la classe abstraite dont elle hérite.

3.h Attributs et méthodes statiques

Les attributs et méthodes statiques sont appliqués à la classe plutôt qu’aux instances de cette classe. Ils sont dits “attributs et méthodes de classe”.

Tout invocation d’une méthode statique par l’intermédiaire d’un objet se fait sur la classe de cet objet. La valeur d’un attribut statique est la même pour toutes les instances de la classe.

Pour générer une nouvelle référence, on demande à la classe Commande le dernier numéro affecté.

3.i Type énuméré

Ça peut être utile.

4. Paquetages et interfaces / Architecture logicielle

4.a Interface

L’interface est une vue externe, totale ou partielle d’un objet. Elle définit les services accessibles (offerts) aux utilisateurs de l’objet.

La définition d’interface avant la conception d’une classe ou un sous-système est une sorte de contrat. Il définit les méthodes qui doivent être implémenté pour que le reste du système fonctionne.

Dans cet exemple, la classe commande utilise le concept de List, sans doute pour implémenter la liste des lignes de commande.

Relations avec et entre interfaces

• Relation d’implémentation Les opérations listées dans l’interface sont implémentées par l’élément lié. La représentation graphique est une flèche d’héritage, mais en pointillés.
• Relation d’utilisation Un élément peut utiliser une interface. On l’indique dans le diagramme par une flèche de dépendance, en pointillés.
• Héritage d’interface L’héritage entre interface peut être multiple

Exemple :

L’implémentation d’interface peut être représentée par une forme simplifiée (lollipop) comme l’interface ServiceGestion de l’exemple.

4.b Paquetage

La notion de paquetage permet la partition des modèles et le regroupement des éléments de modélisation de types différents. En découpant le système (ensemble des classes du système) en sous-systèmes, la notion de paquetage permet de concevoir l’architecture logicielle.

Critères de regroupement des classes

Les critères de regroupement peuvent être purement logique, ou basé sur un découpage fonctionnel du au domaine métier. L’architecture du Système est alors un ensemble de paquetages et de relations de dépendance entre ces paquetages.

Le stéréotype <<subsystem>> peut être appliqué.

Espace de nommage

Dans cet exemple, deux classes portent le même nom. Elles sont pourtant bien distinctes, car appartenant à deux paquetages différents. Le paquetage est un espace de nommage. (On peut faire le parallèle avec les répertoires qui organisent les systèmes de fichiers)

Relation de dépendance

La classe ClasseB du paquetage paquetageB est liée par une association dirigée à la classe ClasseA du paquetageA. Le paquetageB est alors dépendance du paquetageA.

Exemple :