Le développement d’un logiciel selon l’approche orientée objet consiste à développer un ensemble d’objets qui interagissent pour réaliser les besoins de l’utilisateur.

Un objet est une entité physique (concrète) ou abstraite ayant une identité, un état et un comportement.

Les objets qui partagent les mêmes propriétés et se comportent de la même manière sont représenté par une classe.

On a vu que le diagramme de cas d’utilisation capture les besoins fonctionnels de l’utilisateur.

Pour développer un système, la deuxième question à répondre est quels sont les éléments et les relations entres eux (structure) qui vont réaliser ces objectifs(i.e., répondre à la question qui).

Le diagramme e classe est un diagramme très essentiel(obligatoire) dans le processus de l’analyse et la conception orientées objets. Ce diagramme définit l’architecture (structure générale et détaillée) du système et la structure de chaque objet. Il montre les classes d’objets qui composent le système et les relations existantes entre eux. Il est utilisé aussi pour représenter la structure de haut niveau du système en terme de packages(voir les prochains cours).

Ce diagramme est le résultat de plusieurs itérations du processus de développement et il est important de noter qu’il est trop difficile pour le produire dans une seule itération. La première version de ce diagramme apparaitre au niveau de la phase analyse. A ce stade ce diagramme est nommé diagramme de classes d’analyse (de domaine) et il est utilisé pour représenter la structure du domaine de problème( les types d’objets qui composent le domaine d’étude et la relation en entre eux ).

Ensuite, il est enrichit avec plus de détails (les détails permettant l’implémentation de la solution) en phase de conception. Dans cette phase le diagramme est utilisé pour représenter en détails suffisant la structure de la solution. Il est important de noter que ce diagramme est un enrichissement de diagramme d’analyse. Par exemple au niveau de la conception , on ajoute des objets spécialisés en relation avec la solution informatique tels que les objets de type interface (e.g., bouton, champs…etc), contrôle. On applique certains principes et patrons de conception (voir les cours qui suivent) pour améliorer la conception …etc.

Remarque

Il est important de noter et de rappeler que les diagrammes sont complémentaires et Ils doivent être cohérents les uns avec les autres.

Figure : un diagramme de classe (martin fowler 2003)

2. Description du diagramme de classe

La description du diagramme de classes est basée sur :

• le concept d’objet,

• le concept de classe = attributs + opérations,

• les différents types d’association entre classes.

3. Exemple de diagramme de classe

Un exemple de diagramme de classe simple est présenté par la figure suivante

Figure : un diagramme de classe (martin fowler 2003)

4. Objet

Entité physique ou abstraite caractérisée par une identité, un (des) état(s) et par un comportement.

Objet=identité+état+comportement

5. Classe

Représentation abstraite d’un ensemble d’objets ayant des attributs, associations et un comportement commun.

La classe définit le modèle ou le moule qu’on va utiliser pour construire un objet. Un objet est une instance d’une classe c.à.d. la concrétisation d’une classe.

L’état d’un objet d’une classe correspond aux valeurs de tous ses attributs à un instant donné.

6. Attribut

Propriétés d’un objet.

Par exemple un employé peut être décrit par un id, nom, prénom diplôme…etc.

L’attribut contient une information que nous croyons que le système doit gradé trace d’elle.

Il peut avoir un type, une multiplicité( le nombre de valeur que l’attribut peut contenir e.g. un tableau de valeurs)et une valeur initiale.

Un attribut dérivé (« / ») est un attribut dont la valeur est calculable à partir d’autres information.

7. Opération

Représentation d’un comportement possible de l’objet et elle est implémentée en utilisant des méthodes. Elle peut avoir des paramètres et un type de retour.

8. Représentation de la classe en UML

Exemple

Vis ={+ public, -private ,# protected ;~ package}

public : élément non encapsulé visible par tous. +

private : élément visible seulement dans la classe. -

protected : élément visible dans la classe et dans les sous-classes. #

package : élément encapsulé visible dans les classes du même paquetage.~

Représentation simple d’une classe

9. Classe abstraite

Est une classe qu’on ne peut pas instancier parce que au moins une de ces méthodes est abstraite et sert à définir une classe de base à partir duquel d’autre classes peuvent être dérivées.

Exemple

Une autre notation

10. Association

Relation sémantique entre deux classes. Elle est généralement durable. Elle représente un ensemble de liens entre instances. L’association indique le fait qu’une classe doit avoir accès à l’autre classe pour effectuer ces taches.

Elle peut être bidirectionnelle (navigable dans les deux sens).

Figure 1 exemple d’association

Dans ce cas, dans la phase de l’implémentation des deux classes on doit créer un attribut qui porte une instance de l’autre classe et qui porte souvent le nom du rôle placé à coté de cette classe liée. Ceci augmente le couplage entre les deux classes et rend difficile la gestion de cette association et nous force à la rendre, dans la mesure de possible, unidirectionnelle. Cet objectif est souvent réalisé par l’utilisation d’une association unidirectionnelle (association navigable dans un seul sens).

11. Association unidirectionnelle

Dans ce cas, une seule classe possède un attribut qui fait référence à l’autre classe, ce qui se traduit par le fait que la première classe peut solliciter une deuxième et que l’inverse est impossible (la deuxième classe ne connaît pas la première).

On peut représenter cette relation de 3 manières différentes :

- Une croix du coté de l’objet qui ne peut pas être sollicité.

- Une flèche du coté de l’objet qui peut être sollicité

- Les 2 représentations précédentes à la fois.

Par exemple dans la figure 2 l’association est navigable dans un sens et exprime le fait suivant :

si on cannait l’interrupteur on connait la lampe et pas l’inverse.

Figure 2 association navigable

Figure 3 des navigations possibles et impossibles

Rôle

Nom attribué à une extrémité d’une association ; par extension, manière dont les instances d’une classe voient les instances d’une autre classe au travers d’une association.

Lorsqu’un objet A est lié à un autre objet B par une association, cela se traduit souvent par un attribut supplémentaire dans A qui portera le nom du rôle B. (et inversement)

Multiplicité

Définit le nombre d’objets (min..max) qui peuvent participer à une relation avec un autre objet dans le cadre d’une association. Les Multiplicités fréquentes :

* - any number

0..1 - zero or one

1 - exactly 1

1..* - 1 or more

n - exactly n

n .. m - n through m

12. Types d’association

L’association peut exister entre deux classes (binaire) , plus de deux (n-aire) ou elle peut être réflexive.

On représente l’association n-aire par un losange d’où part un trait allant à chaque classe. La relation n-aire est à éviter à tout prix à cause des ambiguïtés et des difficultés d’interprétation qui peut causer. On peut la remplacer par des associations binaires.

13. Dépendance

Une relation sémantique transitoire entre deux éléments et signifie que l’une des deux utilise l’autre «utilise un ». Cette relation exprime le fait que tout changement dans la classe (élément) indépendante peut affecter la sémantique de la classe dépendante (élément).

La dépendance représente la forme la plus faible de relation entre classes. (Éléments) et exprime le fait que le premier élément interagit brièvement avec le deuxième sans conserver à terme de relation.

Au niveau de l’implémentation cela se manifeste par le passage d’une instance de la classe indépendante comme argument d’une méthode de la classe dépendante ou l’affectation de cette instance à une variable locale mais pas comme valeur d’un attribut de la classe. Donc la durée de vie de l’objet ici est la durée de vie de la méthode.

On UML on utilise une flèche orientée et pointillé pour représenter cette relation

14. Classe d’association

Les informations qui dépendent des deux classes sont généralement placées au niveau d’une nouvelle classe attachée à l’association via un trait en pointillés.

15. Contrainte

Condition qu’un ou plusieurs élément(s) du modèle doivent la respecter. Elle est placée entre accolades { }, et souvent insérée dans une note graphique

Cette condition peut être exprimé en utilisant le langage naturel ou un langage formel dédie a ce propos(e.g OCL, java…).

Contraintes et associations :

On peut écrire des conditions sur l’association.

16. Les énumérations :

Une énumération est un type possédant un nombre fini et arbitraires de valeurs possibles,

construite sur mesure par le développeur, pour typer des variables bien particulières, comme le

représentation des jours de la semaine ou des mois de l’année.

17. Héritage

Relation qui permet de définir une nouvelle classe dite sous-classe (classe spécialisée) en utilisant une classe de base (classe générale) dite super-classe. La sous classe plus ces propres caractéristiques (attributs et méthodes) hérites les propriétés et les méthodes de la classe générale.

18. Associations particulières : composition – agrégation

19. Agrégation

Cas particulier d’association qui représente la relation de contenance.

Le composé (whole) a le composant (part) comme composant.

Le cycle de vie du composé peut être différent au cycle de vie de composant.

Le composant peut être partagé avec d’autre composés.

20. Composition

Une forme forte d’agrégation.

Le composé (whole) a le composant (part) comme composant

Le cycle de vie du composant est contrôlé par le composé.

Le composant fait partie d’un seul composé.

21. Relation de réalisation et notion d'interfaces

Une interface regroupe un ensemble des opérations abstraites.

Une interface représente un contrat à respecter par les classes qui « réalisent » cette interface.

Puisque l’interface n’ a pour objectif que la spécification, au moins un élément d'implémentation (une classe) doit lui être associée. la relation entre cette classe et l’interface est la réalisation.

Graphiquement, on la représente par un trait discontinu terminé par une flèche triangulaire stéréotypé « realize ».

Exemple :

22. Phases de production du diagramme de classes

Il y ‘a plusieurs approches pour produire ce diagramme et il faut choisir celle qui convient à votre problème.

Une des approches est ‘use case réalisation’. Dans cette approche chaque cas d’utilisation est analysé pour produire un diagramme de classe partiel qui représente la structure à utiliser pour réaliser la fonctionnalité décrite par le cas d’utilisation. Le groupe de classes qui réalise le cas est nommé collaboration (voir le détail aux cours prochains).

Tous ces diagrammes sont ensuite groupés pour construire le diagramme de classe du système.

Durant ce cours on va adopter l’approche suivante :

On va construire le diagramme dans une seule itération et en analysant le domaine d’étude.

L’approche à suivre pour le produire est (Rumbaught et blaha 2005) :

1. Identifier les objets et leurs classes

2. Identifier les attributs

3. Identifier les relations

4. Identifier les responsabilités des classes en utilisant l’approche basé sur les cartes CRC ( class Responsability Collaboration)

5. Séparer les responsabilités à des attributs et méthodes

6. Spécifier chaque opération

23. Identifier les objets et les classes

Plusieurs approches peuvent être utilisées d’une manière complémentaire :

1. analyse des abstractions

2. analyse basée sur les scénarios

3. analyse du domaine de problème

4. analyse des entités

5. analyse basée sur les opérations

6. analyse basée sur les cartes CRC

7. l’identification basée sur les noms et les verbes.

On examine 3 approches : 4-6-7

À suivre

آخر تعديل: الأحد، 13 مارس 2022، 8:07 PM