L'axe des exigences
Rappel : Cahier des charges
N'hésitez pas à relire le cahier des charges pour vous imprégner du fonctionnement. Toute l'analyse en découle.
Définition : Description 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
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)
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ément : Relation 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.
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é |
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 |
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 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 |
Remarque : Initialisation
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
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
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.