L'axe des exigences

RappelCahier des charges

N'hésitez pas à relire le cahier des charges pour vous imprégner du fonctionnement. Toute l'analyse en découle.

DéfinitionDescription de l'axe

Cet axe permet de découvrir le système, avec ses contraintes.

Les diagrammes utilisés sont :

  • Diagramme de déploiement (DEP). Présente les différents éléments matériels/Logiciels composant le système et leurs liaisons, moyens de communication.

  • Diagramme des cas d'utilisation (UCD). Rend compte des usages vues des acteurs principaux ou secondaires. Tout n'est pas forcément décrit.

  • Diagramme des exigences (REQ). Permet de mettre en évidence les exigences connues dans tous les domaines.

Déploiement du système

Diagramme de déploiement
Diagramme de déploiement

Grâce à ce diagramme qui pourrait remplacer un synoptique, nous constatons un grand nombre de moyens de communication.

Nous prenons conscience des liaisons entre les matériels. Nous réalisons la présence d'une carte d'interface et ce qui y est raccordé.

On peut se servir de ce diagramme pour répartir le travail entre les membres d'une équipe, après avoir estimé l'ensemble des tâches à réaliser.

Les cas d'utilisation (UC)

Diagramme des cas d'utilisation
Diagramme des cas d'utilisation

Les cas d'utilisation constituent une première approche des besoins (ou exigences) du système en matière de logiciel et matériel.

Ils permettent de synthétiser les interactions entre le système et les acteurs. Les cas d'utilisation sont exprimés le plus souvent par des verbes d'action.

L'acteur principal est l'exploitant (le plus souvent situé à gauche). Les autres acteurs sont secondaires même si leur présence est indispensable.

En lisant le diagramme, on apprend que l'exploitant peut interagir avec le système pour :

  • Mesurer les températures et humidité.

  • Commander la LED

  • Interagir (communiquer) avec différents acteurs (client, périphérique RS232C, Bouton Poussoir). Pour ce dernier, un simple message affichera l'état du bouton poussoir sur l'IHM.

Notez également que :

  • Le UC Mesurer se spécialise en 2 UC Mesurer I2C et Mesurer SPI.

  • Le UC Commander est particulier car il interagit avec l'exploitant mais vient aussi étendre le UC Mesurer en cas de dépassement d'un seuil d'une des mesures.

L'IHM est un besoin implicite. Cela peut correspondre aux liaisons entre l'exploitant et les cas d'utilisation.

Les données manipulées par le système ne sont pas représentées sur le diagramme (implicite également), ce n'est pas le but et cela alourdirait le diagramme.

Il s'agit d'une première approche des besoins (ou exigences) du système en matière de logiciel et matériel.

On peut également se servir de ce diagramme pour répartir le travail au sein d'une équipe.

ComplémentRelation entre les UCs

<<include>> Indique que l'UC pointé est inclus dans le UC source. Son utilisation sera obligatoire dans l'UC le pointant. Cela permet de factoriser certains besoins, ou de faire apparaître un besoin important sous-jacent.

<<extend>> Indique qu'à un certain moment (qui dépend d'une condition), le UC vient compléter le UC pointé.

Scenarii

La lecture d'un UCD ne permet pas de comprendre tous les besoins du système mais c'est un bon point de départ pour l'analyser.

Chaque UC est décrit par un ensemble de scenarii :

  • Scénario nominal qui décrit le fonctionnement le plus fréquent.

  • Scénario alternatif (si nécessaire) qui décrite une variante intéressante du scénario nominal.

  • Scénario d'erreur (si nécessaire) qui décrit comment réagit le système en cas d'erreur.

Les scenarii seront ensuite décrits sous forme SysML par des diagrammes.

Scenarii de l'UC Communiquer

Scénario nominal de communiquer avec Bouton Poussoir

Lire l'état du bouton poussoir.

Afficher l'état du bouton poussoir.

Scénario nominal de communiquer avec Périphérique RS232C

Initialiser la liaison série.

Pré-Condition : Information arrivée.

Post-Condition : Afficher le message.

Pré-Condition : Information entrée.

Post-Condition : ÉCRIRE le message.

Scénario nominal de communiquer avec client TCP/IP

Pré-Condition : client connecté au serveur.

Post-Condition :

ÉCRIRE message de bienvenue

RÉPÉTER

  ÉCRIRE "Entrez le numéro de la mesure à lire : "

  LIRE numéro de la mesure

  ÉCRIRE valeur de la mesure

TANT QUE client connecté

Scenarii de l'UC Mesurer

Scénario nominal de Mesurer I2C

BOUCLE

  LIRE la mesure de température

  Mémoriser (UC) la mesure dans le segment de mémoire partagé

  LIRE l'humidité

  Mémoriser (UC) la mesure dans le segment de mémoire partagé

FIN BOUCLE

Scénario nominal de Mesurer SPI

BOUCLE

  LIRE la mesure de température

  Mémoriser (UC) la mesure dans le segment de mémoire partagé

FIN BOUCLE

Scénario alternatif de Mesurer

Pré-Condition : Dépassement du seuil d'une des mesures

Post-Condition :

  Forcer l'allumage de la LED

  Interdire la commande manuelle de la LED

Pré-Condition : Toutes les mesures en dessous du seuil

Post-Condition :

  Forcer l'extinction de la LED

  Autoriser la commande manuelle de la LED

Scenarii de l'UC Transférer

Scénario nominal de transférer vers le serveur

Toutes les N secondes, émettre la valeur des mesures (protocole à préciser).

Scénario d'erreur de transférer vers le serveur

Pré-Condition : Impossible de se connecter au serveur.

Post-Condition : Affichage d'un message d'erreur.

Scénario nominal de transférer vers l'écran LCD (I2C)

Toutes les N secondes, écrire la valeur des mesures (protocole à préciser).

Scénario nominal de transférer vers le SGBD

Connexion au SGBD.

Requête d'écriture des mesures dans la base de données.

Scénario d'erreur de transférer vers le SGBD

Pré-Condition : Impossible de se connecter au SGBD.

Post-Condition : Affichage d'un message d'erreur.

Scénario de l'UC Commander

Scénario nominal de Commander la LED

Pré-Condition : Commande manuelle autorisée ET ordre allumage

Post-Condition : Allumage de la LED

Pré-Condition : Commande manuelle autorisée ET ordre extinction

Post-Condition : Extinction de la LED

RemarqueInitialisation

Notez que les scenarii ne décrivent pas l'initialisation des différentes parties du système, à moins que cela soit une phase obligatoire ou délicate. Sinon, c'est également implicite.

Les exigences

Diagramme des exigences
Diagramme des exigences

Les exigences d'un système peuvent être nombreuses et précises dès le départ. On peut les classer dans différentes catégories :

  • Matérielle

  • Logicielle

  • Forme

  • Financière

  • etc.

Lorsqu'il y en a beaucoup, il est intéressant de faire un diagramme par catégorie.

Notre diagramme ci-dessus est simple et sûrement incomplet.

En effet, au cours du développement peuvent apparaître d'autres exigences. Pour ne pas noyer le lecteur, seules les exigences importantes ayant un impact sur la réalisation seront indiquées.

Diagramme de séquence système

Diagramme de séquence système (ssd)
Diagramme de séquence système (ssd)

Ce diagramme décrit le fonctionnement dynamique nominal (le plus courant ou plus intéressant) du système et donne une vue d'ensemble du fonctionnement du système.

Il est utile afin de cerner rapidement le fonctionnement attendu, même si ce diagramme ne représente pas exhaustivement le fonctionnement du système.

Les scenarii détaillés, seront décrits dans le reste de l'analyse.