Discussion :

[pseudocode]

Bonjour,

j'ai une petite question a vous soumettre, meme si je me doute de la réponse (négative)...

Est-il possible (et judicieux) de faire apparaitre des cas d'utilisation liés aux contraintes de conception ?

Les exemples typiques sont le demarrage/arret du logiciel lié au demarrage/arret du PC, ou l'import/export/purge des données lié aux capacités du systeme de persistance (BdD, taille disque, ...).

L'idée est d'avoir une tracabilité sur ces fonctions qui existeront dans le logiciel final (elles devront apparaitre dans la spec). Mais doit-on les faire remonter au niveau du use-case ? Faut-il creer un nouveau use-case durant la phase de conception ? Votre avis est le bienvenu...

[ego]

En fait, toutes les exigences même fonctionnelles ne se prêtent pas à une formalisation sous forme de UC.
L'import peut donc pas exemple exister au niveau des exigences mais on la formulera avec une formule du genre : "Le système doit permettre l'import de données de type X sous une forme XML tel que définie dans le document XXX-v1.1.xsd"

[Joshua Beharia]

Hello,

un UC doit d'écrire les besoins fonctionnels (n'est-ce pas Nip ? ;o) mais surtout un UC doit d'écrire une fonctionnalité que le system doit fournir à l'utilisateur.

Or pourquoi faire un UC "Démarrage du PC" ? Qu'apporte le system dans ce UC ? Ceci doit être vérifier.

Sinon, les contraintes techniques ou contraintes de conception peuvent apparaitre lors d'une phase d'analyse qd ces contraintes sont dite "métier", c'est à dire que cela ne changera pas et que c'est éprouvé comme solution dans la maison !

@+,
Josh.

[ego]

En grande partie d'accord avec Joshua.
Cependant, tout dépend de la signification exacte de certaines exigences.
Pour reprendre la phrase "le démarrage de l'application au démarrage du PC".
Une telle exigence n'est certainement pas à formaliser sous la forme d'un UC.

Cependant, c'est bien une exigence qui s'applique au système que l'on va produire. Il faudra peut être simplement dire dans la documentation d'installation qu'un raccourci (sous windows) devra être créé dans le répertoire "démarrage" du poste utilisateur (ou tout autre moyen, je ne suis pas un expert windows) mais cela reste une exigence à exprimer pour qu'elle soit prise en compte.

Pour l'histoire de la purge, qui peut paraitre être un point assez technique, c'est peut être aussi un point à prendre en compte. Ce point ne sera probablement pas vu au départ mais quand on va analyser les exigences et que l'on va imaginer une solution, on peut être amené à se dire, "Tiens mes les données vont gonfler; l'espace disque n'est pas infini, il faut prévoir une purge". De là on se retourne vers les gens du métier et on leur demande s'ils n'ont pas des contraintes sur la rétention des données. Imaginez que vous ayez taillé les disques de telle sorte que vous ne pouvez pas conserver plus d'1 mois de données et que le métier à besoin d'au moins 2 mois de données. Il va falloir revoir votre copie côté technique.
Donc de cette idée de purge venu après une première analyse peut déboucher une exigence du genre "Le système permettra de conserver les données sur au moins 2 mois glissants". L'exigence n'est pas "Le système doit purger" mais en faisant des aller-retour entre métier et technique, on découvre parfois d'autres exigences.

[pseudocode]

Je suis tout a fait d'accord avec vous sur le principe. Ces "exigences" apparaissent suite a des choix fait durant la phase de conception.

Ma question c'est: ou est-ce que je fait apparaitre ces exigences dans les 9 diagrammes UML ? Et comment j'assure une tracabilité ?

A priori, je dirais que ces exigences seront représentées par des activités dans les diagrammes d'activités.
- Dois-je les faire remonter aux use-case, afin de discuter des consequences "metier" avec le client ? Si oui, faut-il séparer les use-case "originaux" et les use-case de "contraintes" ?
- Est-ce que je met juste une note sur l'activité pour expliquer que c'est une activité liée aux choix de conception ?
- Est-ce que je passe sous silence ces exigences au niveau UML (hum... ca me parait louche)

[Joshua Beharia]

Re,

pour les contraintes fortes, on peut utiliser OCL (Object Constraint Language).
C'est une surcouched'UML développée à la base par Ibm il me semble. Mais il faut utiliser ceçi avec parcimonie car cela peut te cacher des vrais pbs !

Pour ma part, les contraintes apparaissent dans les diags d'objets (via une note ou un tag sur l'objet) et dans les diag de séquences surtout (idem: note et tag pour les pré/post conditions,...).

Je ne me sers pas de tous les diags donc...

Mais j'insiste bcp sur le diag d'objet car c'est lui qui va fortement influencer ta dynamique !

@+ !

[pseudocode]

Ok... je vais utiliser les notes pour expliquer d'ou viennent ces "fonctions".

merci a tous

[ego]

Certaines exigences transverses ne sont pas spécifiquement liées à un composant particulier mais à l'architecture d'ensemble.
Dans le cas de la rétention de données, on peut peut être quand même attacher l'exigence à un package ou une classe, pas nécessairement à une opération.
Si l'exigence est transverse et qu'elle est prise en charge par l'architecture générale de l'appli, c'est au niveau d'un "Dossier d'architecture" que l'on expliquera cela.

[pseudocode]

Oui, c'est ce que je fais deja... Mais j'essayais d'unifier un peu tous ces documents au travers d'UML, ou au moins avoir une tracabilité.

A mon avis il manque un petit quelquechose en plus du couple MDA/UML pour pouvoir remonter aux origines de ces exigences non-metier

[ego]

La traçabilité c'est l'affaire des outils de gestion des exigences et de leur intégration avec les autres outils comme entre autres les outils de modélisation.
Ce peut être lourd à gérer mais CaliberRM ou RequisitPro savent s'intégrer aux outils de modélisation

[pseudocode]

La traçabilité c'est l'affaire des outils de gestion des exigences et de leur intégration avec les autres outils comme entre autres les outils de modélisation.
Ce peut être lourd à gérer mais CaliberRM ou RequisitPro savent s'intégrer aux outils de modélisation

Oui, mais c'est hors budget pour l'instant

On sort juste du "tout manuscrit" (word+visio). On commence a modeliser l'analyse/conception en UML. Donc on attendra encore un peu pour la generation automatique des documents SRS+SDS a partir de la base UML