UML C-S
Basée sur RUP. Analyse/conception adaptée à leur (celui de C-S) métier. a.k.a. UML-NEPTUNE
Requirements Analysis
Deux type d'acteurs,
- external entity (fournisseurs de données, notamment)
- active actor : interagit avec le système
On recense les acteurs, et les classe. On va les décrire par
- Actif / passif
- Rôle (1) – si plusieurs, faut distinguer par plusieurs acteurs
- Responsabilités (n)
- Facultatif
- acteurs abstraits?
à expliquer
On s'occupe d'abord des acteurs passifs (externes) en un seul diagramme, avec les communications (diagramme de contexte, réalisé avec diagramme de communication). On peut avoir recours à des diagrammes de séquence pour analyser leurs comportements collectifs.
Ensuite, on s'occupe des acteurs actifs; on commence à faire un peu d'analyse d'objet en commençant par des use cases pour tous les acteurs. En parallèle, on développe le modèle métier–avec un ingénieur métier si possible (comme nous avons fait pour le jeux d'échecs).
Pour chaque use case, écrire une documentation
| Résumé |
| Données en entrée |
| Données en sortie |
| pré-condition (use cases finis, états) |
| post condition |
| Description : Texte + diagrammes Activity, Sequence, parfois State Change |
| Diagramme de séquence principal; deux colonnes lifeline: acteur et “le système”. Puis, des diagrammes de séquence secondaires, plus fins des boîtes de cette séquence, explosant (exposant) des classes (pour les découvrir). |
| Exceptions: n'est pas censée arrivée, mais peut et nous avons anticipée |
On peut rajouter un diagramme de collaboration (ou communication) activités pour montrer des relations entre les use cases. Ca permet de déduire des besoins en IHM.
Object Analysis
Architectural Design
On produit dans l'analyse deux gros packages des classes “découvertes” dans l'analyse :
- Applicatives
- Métier
Ensuite, on dessine des Packages de l'architecture (conception) : toutes les classes en vrac, puis groupement visuel (comme avec Meta-Plan). On regarde comment elles communiquent entre elles, les informations qui circulent, et on définit des classes interface en conséquence.
On rentre dans chaque package pour en distiller un diagramme de classe.
On reconnait les classes interfaces (par un diagramme détourné de séquence) et on les met en haut à gauche. Pour chacune, on va faire des diagramme de séquence par service offert. On rajoute des classes de conception en plus des classes d'analyse et classes métier (en pointillé).
Object Design
Physical Design
Modéliser les besoins matériels, architecture physique.
Notes Sur Carrières Possibles
- Architecte système
- Architecte spécialisé
- Expert
- Architecte métier
- Architecte technique
