Catégorie de Concepts Exemples
objets physiques ou tangibles (ou des choses)
Terminal de point de vente, Maison, Voiture, Mouton, personne, Avion
endroits Magasin, bureau, aéroport, bureau de
police, … documents, spécifications, dessins,
ou descriptions de choses
Spécification de l’Article, Description du Module, Description du Vol
transactions Vente, paiement, réservation
rôle des personnes Caissier, étudiant, docteur, pilote
Unité 3: Analyse Orientée-Objet
conteneurs d’autres choses Magasin, bibliothèque, Avion choses dans un conteneur Produit, livre, Passager autres ordinateurs ou de systèmes
électro-mécaniques externes à notre système
Système de contrôle de carte de crédit, Système de contrôle du trafic aérien
concepts abstraits faim, Acrophobie
organisations Département de Ventes, Club, …
Evénements et incidents historiques Vente, vol qualifié, Réunion, vol, crash, atterrissage
Processus (souvent pas représentés en tant que concept, mais parfois oui)
Vendre un produit, Réserver un Siège
règles et politiques Politique de Retour d’un produit, Politique d’Annulation
catalogues Catalogue de Produits, Catalogue de
Pièces dossiers de financement, le travail, les
contrats, les questions juridiques
Reçu, Contrat de Travail, trace de Maintenance
instruments et services financiers Stock
manuels, livres Manuel d’utilisation, Manuel de Réparation
Cette stratégie consiste à créer une liste de concepts candidats par rapport aux exigences de la description du client, des rapports d›enquête initiale, les définitions des fonctions du système, et les cas d›utilisation. Une autre technique simple et utile pour l’identification des concepts est d’identifier le nom et syntagmes nominaux dans les descriptions textuelles d’un domaine de problème, et les considérer comme des concepts ou des attributs candidats.
Attention:
Des précautions doivent être prises si ces méthodes sont utilisées; la correspondance mécanique nom pour nom des concepts n’est pas possible, les mots dans les langues naturelles sont ambigus, et les catégories conceptuelles peuvent comprendre des concepts qui sont soit attributs, des événements ou des opérations qui ne devraient pas être modélisés comme des classes. Nous devrions nous concentrer sur les objets / classes impliquées dans la réalisation des cas d›utilisation.
Considérer notre cas du système Terminal de vente, des cas d’utilisation Acheter des articles
Figue. 3.7: Modèle conceptuel initial pour le domaine de point de vente Les lignes directrices suivantes sont utiles pour identifier les concepts:
• Il est préférable d’indiquer sur un modèle conceptuel beaucoup trop de concepts, que d’en spécifier trop peu.
• Ne pas exclure un concept tout simplement parce que les exigences ne montrent pas un besoin évident de retenir des informations à ce sujet.
• Il est fréquent d’omettre des concepts pendant la phase initiale d’identification, et de les découvrir plus tard, lors de l’examen des attributs ou associations, ou pendant la phase de conception. Dans ce cas ils sont ajoutés au
modèle conceptuel.
• Notez un concept en tant que candidat dans le modèle conceptuel quand vous n’êtes pas sûr qu’il ne doit pas être inclus.
• En règle générale, un modèle conceptuel n’est pas tout à fait correct ou tout à fait faux, mais plus ou moins utiles; il est un outil de communication.
3.3.3 Les associations dans un modèle conceptuel
Un modèle conceptuel avec des concepts totalement indépendants seulement est évidemment inutile, comme des objets de différentes classes doivent être liés les uns aux autres afin qu’ils puissent interagir et collaborer entre eux pour mener à bien les processus. Dans UML, une association est une relation entre deux classes qui spécifient comment des instances des classes peuvent être reliées entre eux et travailler ensemble. Dans le même sens que les instances d›une classe sont des objets, les instances de l›association sont les liens entre les objets des deux classes - ce que signifie que les objets de la même classe «partagent les mêmes relations».
Multiplicité
En ce qui concerne une association entre les classes, une information importante est de savoir comment le nombre d’objets d’une classe (dite “A”) peut être associée à un objet d’une autre classe (dite “B”), à un moment donné. Nous utilisons la multiplicité pour représenter cette information. Un exemple montre les expressions de multiplicité et leur signification.
Unité 3: Analyse Orientée-Objet
Figue. 3.8: Exemple d’expression de multiplicité
La détermination de la multiplicité expose souvent à l’occultation des contraintes intégrées dans le modèle. Par exemple, que l’association qui relie personne et compagnie dans la figure précédente soit un à plusieurs ou plusieurs à plusieurs, cela dépendra de l›application.
Les objets peuvent avoir plusieurs sortes de relation, et les classes (ou concepts) peuvent avoir toutes sortes d’associations dans un domaine de problème donné. Une association doit remplir les objectifs suivants.
Une association entre deux classes doit fournir des connexions physiques ou conceptuelles entre les objets des classes.
Seuls les objets qui sont associés entre eux peuvent collaborer les uns avec les autres à travers les liens.
Le rôle d’une liaison entre les objets peut être décrit comme suit:
“Un lien représente l’association spécifique par lequel un objet (le client) applique les services d’un autre objet (le fournisseur), ou par lequel un objet peut accéder à un autre objet”.
Comme l’identification des concepts, une liste de catégorie d’association peut être utile. La liste présentée dans le tableau 3.12 contient des catégories communes qui sont généralement considérés.