Chapitre 2 : Analyse & Définition des Besoins

1) Introduction :

Les problèmes qui sont soumis aux ingénieurs logiciels sont souvent d’une complexité extrême. Comprendre la nature
exacte d’un problème s’avère très complexe particulièrement s’il est nouveau et qu’aucun système non automatique
n’existe pour servir de modèle au logiciel à développer.
Il est important de préciser le niveau de détail des besoins exprimés par l’utilisateur. L’information concernant ce problème
doit être assemblée et analysée pour donner une définition compréhensible du problème qui servira pour concevoir et
réaliser le logiciel.
Le processus visant à établir quelles fonctionnalités le système doit fournir et les contraintes auxquelles il sera soumis,
s’appelle l’analyse et la définition des besoins qui est la première grande étape du cycle de vie du logiciel.

Remarque 1 : Le fait de présenter le besoin d’un logiciel pour gérer la comptabilité d’une entreprise, ne suffit pas à
l’ingénieur logiciel de concevoir ce système. Il faudra rassembler et analyser toutes les informations concernant le
problème et une définition compréhensible devra être produite et qui servira par la suite à concevoir et à réaliser le logiciel.

Remarque 2 : Il faut faire la distinction entre un but et un besoin. Ce dernier peut être testé tandis que le but est une
caractéristique plus générale que devrait posséder le système. Exemple : un but pourrait être que le système soit agréable à
utiliser (critère subjectif). Par contre un besoin associé à ce but pourrait être que toutes les commandes utilisateur soient
activées par menu.

Remarque 3 : La tâche de définition des besoins peut parfois être confiée à un analyste dans le cas où un système manuel
doit être automatisé mais souvent cela est fait en concertation avec l’ingénieur logiciel. Par contre, pour les systèmes
complexes, souvent c’est l’ingénieur logiciel qui se charge de cette tâche.

Les résultats de cette 1ère phase sont regroupés dans un document de définition des besoins appelé le cahier des charges du
logiciel qui donc, doit décrire le système que l’on veut bâtir, et ce de manière aussi précise, complète et consistante que
possible. Toute information non pertinente, superflue ou incomplète soit être éliminée an faisant des analyses critiques.

2) Cahier des Charges :

- C’est un document qui contient des indications concernant les phases suivantes du cycle de vie.
- C’est un ensemble de propriétés ou de contraintes, décrites de façon précise, qu’un système logiciel doit satisfaire.
- Ce n’est pas un document de conception ; il doit décrire ce que le système doit faire sans spécifier comment il doit le
faire.
- Les besoins exprimés dans ce document doivent constituer un ensemble complet et cohérent (aucun besoin ne doit être
en conflit avec un autre déjà exprimé).
En pratique, ces propriétés sont extrêmement difficiles à vérifier, particulièrement si les besoins sont exprimés dans un
langage naturel.
Cependant, des notations plus formelles existent qui permettent dans une certaine mesure, de faire des vérifications de
cohérence automatiques.

Remarque : Cette vérification n’est pas facile ; par exemple le cahier de charges d’un système de défense à base de
missiles contenait plus de 8000 besoins distincts couvrant 2500 pages.

Les critères que devrait vérifier tout cahier de charges (selon Heninger, 1980), sont les suivants :
1- il doit spécifier uniquement le comportement externe du système.
2- il doit spécifier les contraintes de réalisation.
3- il doit être facile à mettre à jour.
4- il doit servir d’outil de référence aux programmeurs de maintenance du système.
5- il doit contenir des indications concernant les étapes ultérieures du cycle de vie du système.
6- il doit spécifier les réponses acceptables aux événements non désirables.

3) Structure d’un Cahier des Charges :

Pour pouvoir satisfaire les critères cités précédemment, un cahier des charges doit être structuré comme suit :
1- Introduction : décrit la raison d’être d’un tel système et place celui-ci dans son contexte, en donnant brièvement ses
fonctions et en présentant un justification de son organisation. L’introduction doit également préciser la structure du
document et décrire les notations utilisées.

Page 1
 2- Matériel : si le système est réalisé sur un matériel spécial, cet équipement et ses interfaces doivent être décrits. Si un
matériel standard est utilisé, les configurations minimale et optimale sous lesquelles le système peut s’exécuter,
doivent être définies.
3- Modèle Conceptuel : Ce modèle doit définir une vue à très haut niveau des fonctions majeures du système et de
leurs relations. Ce modèle est bien décrit par une notation graphique (exemple : modèle de flot de données).
4- Besoins fonctionnels : les besoins fonctionnels du système (les services fournis à l’utilisateur) doivent être décrits.
Suivant la nature de ces besoins, la notation utilisée peut être un langage naturel, un langage semi-formel, un langage
formel ou bien un mélange de ces notations.
5- Les besoins en matière de base de données : l’organisation logique des données manipulées par le système et leurs
relations doivent être décrits dans cette section.
6- Besoins non fonctionnels : les contraintes sous lesquelles le logiciel doit opérer, doivent être exprimées et reliées
aux besoins fonctionnels. Exemple : contraintes de temps, espace mémoire, représentation des données, langage de
programmation.
7- Information destinée à la maintenance : cette section doit décrire les hypothèses fondamentales sur lesquelles le
système est fondé ainsi que les changements prévus du fait de l’évolution du matériel, des besoins des utilisateurs,
etc. Dans la mesure du possible, les fonctions et les contraintes particulièrement sujettes aux changements doivent
être indiquées explicitement.
8- Glossaire : doit définir les termes techniques utilisés dans le document et ce de manière précise et sans faire aucune
présupposition sur l’expérience ou la formation du lecteur.
9- Index : il est préférable de fournir plus d’une seule sorte d’index (alphabétique, par chapitre, des fonctions, …).

Remarque : Du fait que les besoins sont susceptibles de changer, il est essentiel que le document d’analyse des besoins
soit organisé de façon qu’il puisse évoluer facilement. Faute de quoi, des changements pourront intervenir dans le système
sans qu’ils soient enregistrés dans le cahier des charges. Cela provoquera un défaut de synchronisation entre le programme
et sa documentation créant ainsi des problèmes immenses aux programmeurs de maintenance.

4) Modèle Conceptuel du Système :

Une fois l’analyse initiale des besoins réalisée, l’étape suivante consiste à produire un modèle conceptuel du système qui
est une vue du système à très haut niveau, dans laquelle les fonctions majeures voulues par l’utilisateur sont identifiées et
leurs relations documentées.
Pour les systèmes très simples, ce modèle peut n’exister que dans l’esprit de l’ingénieur responsable de la définition des
besoins car celui-ci comprend le système dans son ensemble et connaît les fonctions qui doivent être fournies ainsi que les
contraintes imposées à l’exécution de ces fonctions.
Par contre, pour les systèmes complexes, il est nécessaire de définir très tôt un modèle du système qui soit précis et
explicite et d’utiliser ce modèle pour en comprendre le fonctionnement.
Les notations les plus efficaces pour la description du modèle conceptuel du système, sont graphiques. En effet, dessins et
diagrammes sont en général compréhensibles par des utilisateurs mêmes non spécialistes en génie logiciel.
Exemple : Considérons un système bureautique composé d’un courrier électronique, d’un tableur et de services de
préparation de documents et de recherche d’informations.

1ère étape : Identifier les fonctionnalités principales et leurs relations.

Les fonctionnalités principales (courrier électronique, tableur, préparation de documents, recherche d’informations)
peuvent être identifiées, ainsi que les fonctions de support système (communications et bases de données).
Le modèle conceptuel de haut niveau est illustré par le graphe suivant :

Utilisateur

Courrier
électronique Préparation de Tableur
documents
Système de
communication Recherche d’Information

Communications externes
Base de données

Page 2
2ème étape : L’étape suivante du processus de modélisation consiste à prendre chaque fonction principale et en définir un
modèle conceptuel. Exemple : Fonction Courrier.

Utilisateur

Envoyer le
courrier Lire le Faire suivre le
courrier courrier

Classer le Accuser
courrier Recherche
réception d’Information

Système de
communication Base de données

Un modèle similaire peut être dérivé pour chaque fonction principale ; ces modèles peuvent être affinés à plusieurs niveaux
de détails si nécessaire.
Le modèle conceptuel fournit alors un cadre sur lequel la définition des besoins plus détaillée et plus complète peut
s’appuyer mais à condition de ne pas influer trop directement sur la phase de conception.

Remarque : Si le système est complètement nouveau, le modèle conceptuel peut être incomplet car on ne connaît pas
exactement les fonctions souhaitées. Les besoins logiciels dérivés d’un tel modèle sont inévitablement imprécis. Les
besoins plus précis ne peuvent être formulés qu’après avoir fait des expériences de conception de tels systèmes et dont les
résultats permettent au retour d’établir un modèle conceptuel plus complet.

5) Besoins fonctionnels :
Habituellement, la plus grande partie du document de définition des besoins logiciels est consacrée à la définition des
besoins fonctionnels.
Les besoins fonctionnels définissent les services attendus par l’utilisateur. En général, l’utilisateur ne se soucie pas de
savoir comment ces services seront utilisés. L’ingénieur logiciel doit donc éviter l’introduction de concepts de réalisation
dans cette section du document de définition des besoins.
En principe, les besoins fonctionnels doivent constituer un ensemble complet et cohérent. La complétude signifie que tous
les services requis par l’utilisateur doivent être spécifiés, et la cohérence que les définitions des besoins ne doivent pas être
contradictoires.
Dans les systèmes grands et complexes, il est impossible d’atteindre les propriétés de complétude et de cohérence dans la
version initiale du document de définition des besoins.
Au fur et à mesure que les problèmes sont découverts pendant les revues ou plus tard dans le cycle de vie, le document de
définition des besoins, doit être modifié.
Il y a trois façons d’exprimer les besoins fonctionnels :
1- dans un langage naturel,
2- dans un langage structuré comportant quelques règles sans définition précise de sa syntaxe et sa sémantique.
3- Dans un langage de spécification formel ayant une définition rigoureuse de sa syntaxe et sa sémantique.
Le langage naturel est le plus utilisé car il est le plus expressif et le plus compréhensible par les utilisateurs et les
développeurs à la fois.
Les langages structurés sont utilisés car ils permettent la construction d’outils logiciels de vérification de cohérence et de
complétude.
La dernière approche est toujours au stade de recherche et est très peu utilisée en industrie.

5.1) Définition des besoins en langage naturel :

¾ Présenter les besoins dans des paragraphes constitués de texte en langage naturel.
¾ Les besoins sont imprécis, descriptifs et de très haut niveau (ce qui est le cas des systèmes novateurs).
¾ Les besoins fonctionnels et non fonctionnels et les buts ne sont pas clairement distingués.
¾ Dans un paragraphe donné, on peut regrouper l'expression de plusieurs besoins distincts dans une seule phrase. Ceci
rend les vérifications de complétude et de cohérence très difficiles.

Page 3
Exemple : La BD doit permettre l'accès aux objets d'une même version par l'utilisation d'un nom incomplet (simplement en
connaissant le contexte racine de la version).

Problèmes :
Bien que les langages naturels constituent probablement le seul moyen d’exprimer des besoins de haut niveau, des défauts
sont constatés lors d’expression des besoins à l’aide de paragraphes non structurés:
- Ils reposent sur l'expérience linguistique partagée du lecteur et du rédacteur du document. Ce dernier suppose que les
termes utilisés ont le même sens pour lui et pour le lecteur. Cela conduit à des ambiguïtés dangereuses.
- Ils ne permettent pas d'exprimer l'architecture fonctionnelle d'un système de façon claire et concise. L'architecture
fonctionnelle (Schoman et Ross, 77) est une description des activités du système et des entités en interaction à
l'intérieur du système.
- Ils sont trop souples (différencient des besoins proches, …).
- Ils ne permettent pas de séparer efficacement les besoins.

5.2) Définition des besoins en langage structuré :

Pour corriger les désavantages des langages naturels, un bon nombre de notations ont été développées pour exprimer les
besoins de manière détaillée et précise.
Ces notations reposent sur le langage naturel pour définir les besoins de façon expressive. Cependant au lieu de l'utiliser de
façon non structurée, ils imposent une certaine structure en limitant les expressions du langage naturel qu'il est permis
d'utiliser, et pour certains de ces langages, en les enrichissant d'une notation graphique.

Exemple : PSL/PSA, SADT, RSL.

SADT (Shoman et Ross, 1977): Technique d’analyse structurée reposant essentiellement sur le graphisme. Elle est
destinée non seulement à exprimer les besoins mais aussi à partitionner, structurer, exprimer et communiquer des idées.
RSL (Bell, 1977) : est méthode (de spécification des systèmes temps réel) dont les instructions sont traitables
automatiques. L’information dérivée de ces instructions est assemblée dans une base de données appelée le modèle
sémantique abstrait du système (MSAS). Un ensemble d’outils automatiques traite l’information contenue dans MSAS pour
générer des simulateurs, produire des rapports et vérifier la cohérence et la complétude des besoins exprimés.

5.3) Langages de spécification :

Ce sont des langages qui reposent sur des bases théoriques (mathématiques) solides, leur syntaxes et sémantiques étant
définies d’une manière formelle et rigoureuse. Leur avantage est de permettre une analyse et vérification des propriétés
voulues de manière automatique. Par contre, leur nature formelle qui exige de solides connaissances théoriques pré-
requises, rend leur adoption très difficile par les développeurs de logiciels. De plus, ces langages rencontrent des problèmes
techniques (explosion combinatoire) qui ne sont pas entièrement maîtrisés.

6) Besoins non fonctionnels :

Un besoin non fonctionnel correspond à une restriction ou à une contrainte placée sur une des fonctions du système.

Exemple : contraintes sur le temps de réponse maximum, limitations sur l'espace mémoire nécessaire, restrictions sur la
représentation des données.

Bien que les besoins fonctionnels et non fonctionnels soient tous deux susceptibles d'évoluer, les besoins non fonctionnels
sont particulièrement affectés par les modifications de la technologie du matériel (surtout dans les projets de grands
systèmes ayant une durée de développement et d'exploitation de plusieurs années).

Les changements matériels qui peuvent se produire lorsque le logiciel est en cours de développement, peuvent être
anticipés. Les besoins non fonctionnels qui dépendent du matériel peuvent être spécifiés en supposant des performances qui
ne seront effectives qu'en fin de projet. Ce type d'anticipation ne peut être fait pour des changements concernant la période
d'exploitation.
En conséquence, il est important que ces besoins liés au matériel soient spécifiés de telle façon qu'ils puissent être
facilement modifiés.
Les besoins non fonctionnels peuvent rentrer en conflit et interagir les uns avec les autres et même avec des besoins
fonctionnels.

Exemple : conflit entre vitesse d'exécution et occupation mémoire.

Donc, il faut que ces conflits apparaissent clairement lors de la définition des besoins non fonctionnels afin de trouver les
compromis possibles.

Page 4
7) Validation des Besoins :

Une fois que les besoins sont définis, il faut les valider comme suit :
La cohérence des besoins doit être établie. Aucun besoin ne peut être en conflit avec un autre besoin.
L'ensemble des besoins exprimés doit être complet. Il doit comprendre toutes les fonctions et contraintes souhaitées par
l'utilisateur du système.
Les besoins doivent être réalistes vis à vis de la technologie des matériels et logiciels. Il est possible d'anticiper quelque peu
l'évolution du matériel mais pour ce qui est du logiciel, les développements sont beaucoup moins prévisibles.
Les besoins des utilisateurs doivent être valides. Un utilisateur peut penser qu'un système doit fournir certains services,
mais une analyse poussée peut faire apparaître la nécessité de fournir des fonctionnalités supplémentaires ou différentes.

Remarque : les erreurs dans cette étape seront propagées aux phases de conception et réalisation du système. Pour les
corriger, il faut procéder à des modifications qui s'avèrent souvent très coûteuses. Boehm (1974) rapporte que pour
quelques grands systèmes, il a été nécessaire de récrire jusqu'à 95% du code pour tenir compte des changements dans la
définition des besoins.

Une revue de définition des besoins constitue le moyen de validation le plus efficace. Pendant une revue, les besoins sont
étudiés à la fois par les utilisateurs et par les développeurs afin de déceler toute anomalie ou contradiction. Ce travail est
facilité s'il existe des outils d'analyse.

Analyseur de mots-clés : (Boehm;1974)

Etant donné un ensemble de mots clés tels que "protection", "mémoire", "accès", … le système extrait les paragraphes
définissant des besoins contenant ces mots clés. Les paragraphes extraits sont alors comparés pour vérifier que les besoins
ne sont pas en conflit.

Remarque 1 : d'autres outils automatiques permettent de vérifier qu'il n'existe pas de termes différents pour désigner le
même objet, ou comparent les entrées et les sorties des fonctions.
Remarque 2 : Des outils appelés simulateurs permettent, à partir de descriptions formelles (mathématiques) d’un futur
système, de simuler son exécution afin de vérifier certaines propriétés importantes.

Problème :
L'étape de validation des besoins, nécessite une étroite coopération de la part des utilisateurs. Or, beaucoup d'eux ne
comprennent pas clairement leurs besoins et ne peuvent pas comparer un besoin effectif à sa traduction fonctionnelle
surtout dans le cas d'un nouveau système grand et complexe.
Ils ne peuvent alors valider leurs besoins qu'en évaluant un logiciel existant.

Prototypage
Ceci à conduit à l'adoption de l'approche évolutive du développement des systèmes en utilisant la technique du prototypage
(jetable ou non).
On présente à l'utilisateur un système incomplet à partir d'une spécification grossière et on procède à des expérimentations
pour améliorer la spécification.
Pour la suite, deux options se posent : le prototype (jetable) peut être abandonné pour reconstruite complètement le système
réel à partir de zéro ou bien le prototype (non jetable) est lui même transformé progressivement en un produit final.

Prototypage de l'interface utilisateur

Avec l'avènement des interfaces utilisateurs graphiques ( Macintosh d'Apple, Windows pour les PC, X-Windows pour les
plate-formes Unix ), l'effort engagé dans la conception et la réalisation d'une interface utilisateur représente une partie
significative des coûts de développement d'une application.

D'où l'approche "Conception centrée sur l'utilisateur" qui prône le développement d'un prototype et l'implication de
l'utilisateur dans la phase de conception de l'interface.

Page 5
 Suite Chapitre 2 : La Méthode SADT
Structured Analysis and Design Technique

1) Introduction

Spécifier un problème informatique, c’est le poser aussi précisément que possible en s’interdisant de penser prématurément
à sa réalisation [Meyer B.]. Autrement dit, spécifier c’est définir ce que le problème doit faire et non comment le faire.
C’est dans ce cadre que s’inscrit la méthode SADT particulièrement adaptée à la phase de spécification fonctionnelle de
produits ou de systèmes intégrant ou non du logiciel.
Née en 1976 aux USA où elle a été mise au point par la société SOFTECH avec ITT, cette méthode a acquis une renommée
internationale aussi bien au niveau des grands groupes industriels ou des organismes nationaux ou internationaux que des
départements informatiques de société pour lesquelles l’informatique n’est qu’un outil.
SADT est une méthode générale qui cherche à favoriser la communication entre les demandeurs et les utilisateurs, d’une
part, et les concepteurs et les réalisateurs, d’autre part. Le père de SADT, D.T. Ross avait présenté SADT en 1977 dans un
article intitulé « SADT, un langage pour communiquer les idées ».
SADT, étant une méthode de spécification fonctionnelle, conduit à la réalisation d’un ou plusieurs modèles du système.
Un modèle est une description abstraite d’un système, destinée à en préciser certaines caractéristiques. Le but du
processus de modélisation est d’identifier les caractéristiques intéressantes d'une entité que l’on cherche à faciliter la
compréhension, l’analyse et la simulation.
Un modèle correct est celui qui permet de trouver les réponses aux bonnes questions.

Différents champs d’application de SADT :

- cahier des charges.
- Organisation (systèmes d’information,…)
- Systèmes complexes (productique, contrôle de processus, systèmes aéronautiques et spatiaux, …)
- Besoins en logiciels.

2) Les concepts fondamentaux de SADT

2.1) Modélisation (pour comprendre)

SADT aborde un système en le modélisant afin d’obtenir un enchaînement d’actions et de données moins complexes que
celles de départ. Ça correspond à une vue éclatée du système.
Remarque : plusieurs modèles SADT peuvent être nécessaires pour exprimer des points de vue différents (utilisateurs,
maintenancier, …).

2.2) Démarche d’analyse

SADT est une méthode qui analyse le système de
manière :
- descendante
- modulaire
- hiérarchique
™ On commence par la description la plus
générale et la plus abstraite possible du système
(représenter par une seule boîte),
™ Ensuite, on éclate celle-ci en plusieurs boîtes
initiales,
™ Les nouvelles boîtes (moins complexes que
celles de départ) étant à leur tour décomposées
en plusieurs boîtes, etc.
™ A chaque étape de décomposition, des éléments
des détails sont traités Î introduction graduelle
des détails.

Remarque : SADT limite le nombre de boîtes

nouvelles introduites à chaque étape entre 3 et 6,
pour des raisons d’efficacité.

Page 6
2.3) Niveaux d’abstraction (séparer le Quoi du Comment)
Toute spécification de système consiste à séparer les 3 niveaux d’abstraction que sont :
- Niveau Conceptuel Æ (le quoi, le pourquoi)
- Niveau Organisationnel Æ (le Qui, le Ou et le Quand)
- Niveau Opérationnel Æ (le Comment).
SADT permet de répondre aux deux premiers niveaux d’abstraction. Ceci afin de garantir que le problème soit clairement
compris avant que les détails d’une solution ne soient arrêtés.

2.4) Modéliser la Réalité

Le système est composé de données (objets) et d’activités (Actions). Donc SADT met l’accent sur les deux aspects à la fois
pour représenter la réalité dans sa totalité. Ainsi, SADT demande la création de deux diagrammes :
„ Celui des activités (Actigrammes) représenté par des boîtes manipulant des données véhiculées sur des flèches.
„ Celui des données (Datagrammes) également représenté par des boîtes où les flèches montrent, cette fois, les
activités qui créent et utilisent les données.
Une fois ceci fait, on procède à vérifier la correspondance entre la décomposition des activités et celle des données, en
s’assurant que tous les éléments de l’un existent, et sont utilisés de manière cohérente par l’autre.

2.5) Formalisation graphique

Le langage naturel n’est pas suffisamment précis pour exprimer une compréhension efficace. Donc, pour tirer profit des
avantages d’une analyse structurée, il est impératif d’employer une représentation graphique dont les principes sont :
- exposer les détails de façon progressive et contrôlée,
- encourager la concision et la précision,
- concentrer l’attention sur les interfaces des modules,
- favoriser l’utilisation des outils d’analyse.

2.6) Travail en équipe

Personne n’a la capacité de comprendre totalement tous les aspects d’un système dans les détails normalement impartis.
Un travail d’équipe, discipliné et bien coordonné est donc nécessaire et chaque membre de l’équipe doit pouvoir
communiquer ses idées, ses décisions, quels que soient l’étape et le niveau de l’analyse (Modèle Auteur – Lecteur).

Chef de Projet
Comité de Experts

Auteurs Bibliothécaire Lecteurs

2.7) Consigner par écrit

Les documents (digrammes) produits sont communiqués aux autres membres de l’équipe afin d’être revus et commentés.
Les commentaires sont faits par écrit par chaque lecteur et soumis à l’auteur du diagramme qui à son tour porte par écrit ses
réactions aux remarques et aux suggestions faites par le lecteur. S’il y a désaccord sur un point important, l’auteur et le
lecteur en discuteront, mais consigneront les résultats de la discussion par écrit.
Les observations des lecteurs ne contiennent pas seulement une liste d’erreurs à corriger, mais forment dans l’esprit de son
auteur une liste de questions qui ne trouveront réponses que par un supplément d’informations ou d’analyses.

Conclusion : ces 7 principes sont à la base de la méthodologie SADT.

3) Diagramme d’activités (Actigrammes)

Données de contrôle

L’actigramme, identifié par un verbe d’action :

- crée, génère une donnée en sortie
Données Données
- transforme, modifie, change l’état d’une donnée d’entrée
d’entrée de sortie
- sollicite la donnée d’entrée
et ce à partir de directives de contrôle, en s’appuyant sur les
potentialités des mécanismes.
Mécanismes ou supports de l’activité

Page 7
Donnée de contrôle : SADT permet de distinguer parmi les données sollicitées par l’activité, celles qui ne sont pas
modifiées (les données de contrôle), mais qui influencent son comportement, de celles qui sont créées, générées,
transformées, sollicitées (données d’entrée) par l’activité. Donc une donnée de contrôle n’est pas modifiable et exprime une
contrainte sur la façon dont l’activité sollicite l’entrée. On peut la considérer comme étant un paramètre contrôlant la
transformation de la donnée d’entrée en donnée de sortie.
Influence déclenchante
Données de contrôle sur l’activité concernée
Influence inhibitrice
Mécanismes ou supports de l’activité : Ces mécanismes sont utilisées pour exprimer les moyens de réaliser la fonction /
activité (qui réalise telle ou telle fonction).
Précision Temps d’exécution
Type d’opération

Opérandes Calculer Résultats Règles Définir la méthode Méthode

Mathématiques de calcul de calcul
Méthode de Calculette Livres
calcul scolaires Abaques
Actigramme « Calculer » Actigramme « Définir la méthode de Calcul »

Un mécanisme dans un modèle peut être lui-même représenté (défini) par un autre modèle.

4) Diagramme de données (Datagrammes)

Un datagramme, crée à partir d’activités d’entrée (génératrices) sous le contrôle d’activités de création, une donnée,
manipulée, observée, consommée par l’activité de sortie (utilisatrice) sous le contrôle d’activités de manipulation,
d’observation ou d’utilisation

Activités de contrôle : influent sur la création et sur l’utilisation des données créées.

Mécanismes ou supports de la donnée : expriment pour un datagramme, le dispositif de mémorisation de données.

Activités de contrôle
Sélectionner le type
d’ é i
Saisir Opérande Afficher
Activités Datagramme Activités
Génératrices utilisatrice Registre de
s calculette
Datagramme « Opérande »
Mécanismes ou supports de la donnée

5) Remarques sur le formalisme SADT

(1) Label de propriétés : c’est une information courte (souvent numérique) associée à une activité ou une donnée.

Chaque 100 ms 64 caractères

Interroger les Identité du
terminaux Identité du Client Enregistrer
terminal appelant
Cette activité est déclenchée Cette donnée occupe un champs
toutes les 100 ms de 64 caractères

(2) Boîtes et flèches : Les boîtes sont les constituants de la décomposition, les flèches sont les contraintes de liaison entre
les boîtes (ni commandes, ni séquencements).

(3) Connexions entre les boîtes : La sortie d’une boîte peut devenir l’entrée ou le contrôle d’une ou plusieurs autres boîtes
(schéma « producteur – consommateur »).

Page 8
 Nécessité ou plaisir
du voyage
Itinéraire, Destination
Cartes et guides Faire l’itinéraire &
décider destination (1)
Valise
prête
Valise vide Préparer la valise
(2)
Vêtements

Divers Charger la voiture

(3)
Voiture vide
Partir
Voiture prête (4)

A0 - Partir en voyage

(4) Les flèches à double sens:

- Une flèche à double sens visualise le flot de données dans les 2 directions.
- Un petit point est mis sur le côté droit ou en dessous de l’extrémité de la flèche pour rappeler qu’elle est bidirectionnelle.
- Les 2 étiquettes sont séparées par une barre (contenu direct / inverse).

Manger Manger Vaisselle sale /

Vaisselle sale Vaisselle propre

Laver Laver
Vaisselle propre

Erreurs d’analyse Spécifications

Spécifications fonctionnelles / Erreurs
Analyser Analyser d’analyse
fonctionnelles
Concevoir Concevoir

(5) Le Rebouclage d’une flèche :

Le Rebouclage d’une flèche montre dans un actigramme la mise à jour d’une donnée.

(6) Conservation des données : ( ) Données existant sur

Afin d’éliminer les encombrements inutiles, on utilise
toutes les boîtes des
dans certains cas des parenthèses pour spécifier une
diagrammes fils mais
utilisation globale ou locale de certaines flèches.
n’y apparaissant pas

(7) Connexion Parent - Enfant :

Avec la décomposition, il y a introduction graduelle des détails pour dérouler un scénario complet, les connexions entre le
diagramme père et les diagrammes enfants doivent être claires, chaque fois que l’on fait une transition de l’un à l’autre.
Ainsi, une flèche entrant sur la boîte mère (entrée ou contrôle) se retrouvera en entrée du diagramme enfant alors qu’une
flèche quittant la boîte mère se retrouvera en sortie du diagramme enfant.

Page 9
 D1
A D3
D2

D1 D31
A1 D3
D4
D5
D12 A2
D32
D2 A3
(8) Liste hiérarchique et numérotation des diagrammes :
Système de référence basé sur l’arbre hiérarchique.

A-0

A1

A2
A0 A3

A11 A31
A12 A32
A1 A13 A33
A3

(9) Glossaire :
Le glossaire explique les sens des termes techniques, des termes généraux utilisés, des abréviations …

(10) Conditions d’activation :

N° Boîte / N° activation Précondition Æ Postcondition

3/1 E1 & C1 Æ C1 & S1 Erreurs détectées

Module C1
Le module modifié est disponible en sortie de l’activité
E1 Module C1 Jeux de
« Modifier » que s’il n’y a pas d’erreurs détectées. Modifier
S1 modifié tests
(3) S1
4/1 E1 & C1 Æ S1 ou E1 & S2 Tester
Le module testé en sortie de l’activité « Tester » (4) S2
implique qu’il n’est plus en entrée. Module à Module
tester testé

Page 10