Comment schématiser un modèle SCENARIbuilder ?

Objectifs

• Réfléchir à une manière de schématiser un modèle documentaire créé avec SCENARIbuilder
• Fournir un ensemble de règles d'écriture/lecture des schémas

Pourquoi schématiser

• Donner une vue d'ensemble d'un modèle documentaire: ils peuvent devenir très complexes
• A un instant t : parce qu'un modèle bouge, on ne peut constamment mettre à jour ses schémas
• Pour permettre à un nouveau modélisateur de mieux "rentrer dans le modèle". Ceci ne fonctionnera que si celui-ci comprends les règles de schématisations. Certains s'y retrouvent plus par d'autres méthodes: en parcourant directement le modèle dans SCENARIbuilder ou en parcourant un contenu existant dans SCENARIchain

Outils

• Dia, logiciel gratuit et pas très user-friendly pour créer des diagrammes de classe. Efficace et suffisant.

Attention: ci après, règles proposées pouvant être discutées!

Généralités

Pour commencer à schématiser un modèle qu'on ne connait pas, on peut partir du wspdef. En général sa structure permet de se faire déjà une idée du modèle, des items publics. S'il existe des générateurs on peut repérer immédiatements les models qui servent de racine. Ensuite on naviguera dans le modèle en utilisant l'onglet édition et l'affichage de l'arborescence ascendante d'un item.

Outils graphiques

• classe: On peut spécifier un nom, un stéréotype, un commentaire pour une classe. Mais aussi la couleur de son cadre, la couleur de son texte. Elle peut avoir des attributs. Chaque attribut a un nom, un type et une valeur par défaut. Elle peut encore avoir des opérations (sur ses attributs par exemple)
• liens d'héritage: la flèche est triangulaire et vide. On pourra jouer sur sa couleur selon le contexte d'utilisation.
• liens d'agrégation: une classe fait partie d'une autre classe. On peut définir si c'est une composition (losange plein) ou une agrégation (losange vide), ainsi qu'une multiplicité: 1, *, 1..*
• petits paquetage

On utilisera plusieurs pages de schémas pour éclater le modèle, selon un principe de layers (ie: de couches), en séparant les items par niveaux d'imbrication. On pourra faire un schémas synthétisant les différents layers du modèle documentaire.

cardinalités

• 1 : requis, un seul
• étoile: plusieurs, optionnel
• 1..* set requis
• rien: optionnel, un seul

Les métas

Une méta complexe sera schématisée par une classe, dont le texte est écrit en bleu.

• field = un attribut
• nom = nom du champ
• type = enum, string, le nom du model si refItem ou otherType et que ce model n'appartient pas au schémas
• required/optional = valeur: 1 pour requis.
• refItem et othertype = utiliser un lien d'aggrégation (refItem) ou de composition (otherType) pointant vers l'item concerné.
• construction du titre: utiliser les opérations.
• subData = définir une autre méta, et les liées ensembles par un lien de composition
• group et set: utiliser une nouvelle classe nommée "SET:nom du set" ou "GROUP:nom du groupe", abstraite, dont en commentaire on précisera la méta qui le contient, cadré vert, écrit en bleu, lien de composition avec la méta qui le contient.

Les métas qui ne seront pas schématisées sont: sTitle, title, resMeta pour la bibliothèque utc/sc3. Elles seront référencés en attribut d'un .model. Les métas complexes seront liées à leur(s) classes par un lien de composition bleu.

Les autres items

• code = nom de la classe
• stéréotype = classe issue d'une extension (ex Assment) ou d'une bibliothèque...
• parts = en attributs si les items n'apparaissent pas dans le schémas, sinon lien d'agrégation (externalisation) ou de composition (internalisation).
• parts en attribut: le code de la part en name, le nom du model en type, la cardinalité en valeur.
• SET/ALTERNATIVE si parts en classes: utilisée une classe intermédiaire nommée "SET" ou "ALTERNATIVE", abstraite, dont en commentaire on précisera l'item qui le contient. Le cadre est VERT.
• SET si parts en attribut: utiliser la cardinalité *
• ALTERNATIVE et allowedModel si parts en attributs: utilise le pipe | au niveau des types pour différencier les différents model
• parts en classes: les liens d'aggrégation et de compositions portent le code de la part, et sa cardinalité.
• allowedModel pour les parts en classes: créer une classe du nom de la part, cadrée verte, lien de composition avec l'item conteneur (multiplicité 1 si required) , flèches en vert d'héritage entre cette classe et les allowedModel concernés.

Cas complexe: imbrication d'alternatives et de sets, set requis et parts du set optionnel, etc. Dans ce cas on n'utilisera pas les parts en attributs mais en classes. On peut alors utiliser un petit paquetage cadré de gris pour référencer un item complexe issu d'un autre schéma.

Remarque sur userDependant Il peut être intéressant de savoir quand un item est usrD, notamment lorsque l'on supprime des classes interne depuis le wspdef. J'ai opté pour la notation suivante

• sur les fleches: protégé + usrD au niveau de la composition/agrégation
• dans les attributs: protégé

Ainsi, dans les attributs, on aura "privé" pour ce qui est internalisé et "public" pour ce qui est externalisé. Ce n'est pas exactement la même chose que pour les fleches à ce niveau là (puisque pour les liens, on utilise le vocabulaire des diagrammes de classes: compostions et agrégations).

Evolutions du schémas

On peut faire ressortir les évolutions en cours en changeant la couleur de l'écriture d'une classe (en rouge par exemple)

De même pour les évolutions futures, potentielles (cadre rouge par exemple).