Construire un Modèle conceptuel

• Identifier les concepts relatives au cycle de développement courant
• Créer un modèle conceptuel initial
• Distinguer entre des attributs corrects et incorrects
• Ajouter des concepts de spécification quand c'est approprié
• Différencier: concept, type, classe et interface

Première partie les Concepts

Concepts : le chemin vers les Objets

• Le travail de créer de bon concepts à l'analyse est payant en conception et en implémentation
• La Qualité d’un modèle conceptuel vient du fait qu’il représente bien le monde réel.
• Le modèle conceptuel peu être fait pendant la réalisation des Use Case (Chaque activité permettant de mieux faire l ’autre)

Le modèle conceptuel ne contient pas d ’objets

• Le MC doit montrer
  • les Concepts du domaine
  • les associations entre concepts
  • les attributs des concepts
• le MC est matérialisé en UML par des diagrammes

Caisse: Un modèle conceptuel Partiel

Concept Classe

• Pas de Méthodes
• Pas de Concepts logiciels
• Le seul cas de figure ou l ’on parle de logiciel est le cas ou le domaine du système est celui du logiciel.
• Pas de responsabilités dans les concepts !

Concept

• Symbole = mots ou images représentant le concept
• Intention = la définition du concept
• Extension = un jeu d ’exemples auxquels le concept s ’applique.

Décomposition & stratégie

• Les concepts sont un outils de décomposition
• Ils permettent de réduire la complexité ou du moins de simplifier la manipulation des systèmes complexes
• Il faut mieux avoir un modèle conceptuel trop riche (détaillé) que trop pauvre.
• Le silence est plus dangereux que le bruit.

Une Check liste pour les concepts

• Physique tangible
• spécifications, conceptions, descriptions de choses
• lieux
• transactions
• éléments de transactions
• Rôles de personnes
• conteneurs
• éléments dans un conteneur
• appareils

Les Groupes Nominaux

• Une méthode pour la recherche de concepts est d ’associer un concept ou un attribut à chaque groupe nominaux trouvés dans les descriptions du domaine (de la description des UC).
• C ’est léger
• C ’est dangereux du fait de l ’ambiguïté de la langue.
• Mais fait avec précaution cela peut être utile

Reçu Modèle Conceptuel ?

• Reçu = description d ’une vente
  • inutile dans le Modèle conceptuel, en effet il est construit avec les autres éléments
• Reçu = document permettant le remboursement d ’article
  • doit apparaître dans le modèle

Construire un Modèle conceptuel

• Faire la liste des Candidats concepts
• les dessiner en un modèle conceptuel
• Ajouter les associations
• Ajouter les attributs

La stratégie du Cartographe

• Utiliser les Noms existants
• Exclure les éléments non pertinents (FPC)
• Ne rien ajouter !

Privilégier les concepts par rapport aux attributs

• Si X ne peut être identifié comme une chaîne ou une valeur numérique alors c’est un concept sinon c’est un attribut.

Le Vrai et le Faux

• Un modèle conceptuel n ’est ni vrai ni faux
• il est plus ou moins utile
• Le modèle est peut être loin du monde réel quand le système s ’applique a un domaine très abstrait (télécom, langue Naturelle, etc.)

Les Descripteurs

• Supposons que :
  • un Article représente un Objet physique contenu dans le magasin
  • un Article a une description un prix une tva qui ne sont pas enregistrer ailleurs
  • Le personnel est amnésique
  • Tous les exemplaires d ’un article donné sont vendu
• Que ce passe t-il quand un client demande le prix de cet article ?

Les Descripteurs

• Les descripteurs qui sont des descriptions ou des spécifications d ’autres objets doivent apparaître dans le modèle conceptuel

Quand utiliser les descripteurs ?

• Si la destruction de tous les instances implique une perte d ’information
• Si cela permet de réduire la quantité d ’information redondante

Un autre exemple

Terminologie

• Concept : choses du monde réel
• Classe : description d’un ensemble d ’objets qui partagent les mêmes attributs, méthodes, relations et sémantique.
• Type : une classe sans méthodes
• Interface : ensemble des opérations/méthodes visibles (publiques)
• opération: définie sur un concept
• méthode : définie sur une classe

Deuxième partie les Associations

Objectifs

• Identifier les associations du modèle conceptuel
• Distinguer les deux types d ’association
  • need-to-know (doit-savoir)
  • comprehension-only (pour la compréhension)

Association

• Une association est une relation entre concepts qui met en valeur une connexion intéressante ou significative

Associations utiles

• Si la relation doit exister pendant un temps non nul, elle doit être identifiée
• C ’est une association de la liste des associations

Notation UML

Liste des Association les plus communes

• A partie physique de B
• A partie logique de B
• A contenu physiquement dans/sur B
• A contenu logiquement par B
• A est une description de B
• A élément de la transaction B
• A est membre de B
• A partie de l ’organisation B

Concepts ou Associations ?

• Le plus important est de trouvez les concepts
• On doit investir dans la recherche des concepts plus que dans la recherche des associations
• Identifier les relations « need-to-know »
• La transitivité est implicite ne surcharger pas le modèle.

Rôles

• On identifie les deux éléments d ’une association par deux rôles
• Le rôle est défini par
  • un nom
  • une multiplicité
  • une navigabilité
  • une description textuelle si nécessaire

Troisième Partie Ajouter des Attributs