From All4Dev

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.

UML en action