Étude préliminaire
From All4Dev
Contents |
Objectifs
Il s'agit de commencer à déterminer les besoins fonctionnels en considérant le système comme une boîte noire, pour étudier la place du système à l'intérieur du système métier plus globale de l'entreprise cliente. On procède en deux étapes:
- identifications des acteurs
- développement de modèles UML contexte pour délimiter fonctionnellement le système à développer.
Éléments utilisés
- acteurs, stéréotype de classe
- message, événement
- contexte dynamique, diagramme de collaboration
- contexte statique, diagramme de classes
Identification des acteurs
Définition
Représente une abstraction d'un rôle joué par des entités externes.
Un acteur peut être représenté en notation UML par stéréotype prédéfini de classe.
Actions: un acteur peut
- émettre/recevoir des messages qui interagissent avec le système pour
- consulter, modifier l'état du système
Pièges
- les acteurs communiquent directement avec le système;
- les acteurs se trouvent à l'extérieur du système;
- confondre un rôle et une entité concrète:
- une même entité concrète peut avoir plusieurs rôles
- un rôle peut être tenu par plusieurs entités concrètes.
Conseils
- Éliminez les acteurs «physiques» au profit des «logiques»: un acteur doit avoir une autonomie de décision et bénéficier de l'utilisation du système. Donc ne pas mettre acteur des simples dispositifs comme: terminaux, balance, lecteur de carte, etc.
Identification des messages
Définition
- spécification d'une communication entre objets,
- transporte de l'information,
- intention de déclencher une activité chez le récepteur.
- la réception d'un message est un évènement
Méthodes et Conseils
- Pour chaque acteur: quels sont les messages qui déclenchent une action ou un changement d'état du système,
- Pour le système: quels sont les message émis pour un acteur, porteur d'information utilisée par le destinataire.
Pièges
- Ne pas étudier les messages entre acteurs
Représentation du contexte dynamique
Par l'utilisation d'un diagramme de collaboration:
- système étudié est au centre,
- autour les acteurs,
- liens entre le système et chacun des acteurs,
- sur chaque lien, les messages en entrée, et en sorties, sans numérotation.
- décrire sur une feuille à part le contenu des messages plus en détail.
- distinguer les messages
- synchrones
- asynchrones
- périodiques.
Pour simplifier on pourra:
- ne pas représenter les simples consultation sans effet de bord
- les actions de connexions/deconnexion
Représentation du contexte statique
Optionnel, pour mettre en évidence les différences de multiplicité entre les acteurs, lorsqu'il y a beaucoup d'acteurs.
Utilisation d'un diagramme de classes avec uniquement des acteurs du système et le système, en spécifiant le nombre d'instances d'acteurs reliés au système à un moment donné.
Expression de la décomposition en systèmes fonctionnels au niveau du contexte
Pour les très grands systèmes, lorsque l'on connaît déjà la décomposition en grands sous-systèmes:
- élaborer le modèle de contexte dynamique du système comme précédemment;
- traiter le système comme un objet composite, réprésenter les différents sous-systèmes dans une inclusion graphique;
- répartir les flots de messages entrant/sortant du système vers les sous-systèmes;
- ajouter les messages principaux entre les sous-systèmes
Résumé de la phase préliminaire
- Établissement d'un recueil initial des besoins fonctionnels et opérationnels
- modèliser le contexte du système, considéré comme une boîte noire:
- identifier les entités externes du systèmes qui interagissent avec lui: les acteurs
- répertorier les interactions (émission/réception des messages) entre ces acteurs et le système
- représenter l'ensemble des interactions sur un modèle de contexte dynamiqe, éventuellement sur un modèle de contexte statique, ou décomposé pour faire apparaître les principaux sous système fonctionnels.
