Analyse et conception orientée
objet
BELEM Mahamadou
[email protected]
1
Objectifs du cours
Objectifs du cours
Définir la notion de spécification
Définir les différents types de
spécification
Comprendre les différentes étapes de
spécification
2
Qu’est-ce que la spécification ?
L’ingénierie de la spécification est un
processus permettant de définir
Les services que doit rendre le système
Les contraintes sous lesquelles il doit opérer
L’ingénierie de la spécification consiste donc
établir une communication entre les clients et
les concepteurs du systèmes.
Comme tout processus de communication, il
s’agit donc d’un échange d’informations ayant
pour support u n canal de communication
entre plusieurs entités.
Qu’est-ce que le spécification ?
Exigences
Selon IEEE 610.12, une exigence est :
Une condition ou une capacité nécessaire
à un utilisateur pour résoudre un
problème ou atteindre un objectif
Une condition ou une capacité que doit
posséder un système afin de satisfaire
aux termes d'un contrat, d’une norme ou
d’une spécification formellement
imposée.
La représentation documentée de cette
condition ou capacité.
Qu’est-ce que le spécification ?
Exigences
Selon IEEE 830, une spécification d’exigences
comprend :
Les fonctionnalités : services et fonctions que le système
doit fournir.
Les interfaces externes : identification des interactions
avec les utilisateurs et les autres systèmes avec lesquels
le nouveau système doit s‘intégrer.
La performance : contraintes d'opération du système en
disponibilité et en temps réponse.
Les attributs du système : caractéristiques intrinsèques
telles que la portabilité, l'exactitude, la maintenabilité,
la sécurité, etc.
Les contraintes de conception: contraintes sur la façon
de développer le système
Différentes natures de la spécification
Deux grandes catégories de spécifications :
Les spécifications fonctionnelles:
on définit les services du système en termes de relation entre les
sorties et les entrées.
On définit comment le système doit réagir à des entrées particulières;
Comment le système doit se comporter dans des situations
particulières.
Les spécifications non fonctionnelles:
ce sont les contraintes et les propriétés remplies par le système dans
son intégralité, comme, par exemple, la performance, la robustesse,
la sécurité, la confidentialité, la portabilité, etc..
Les contraintes sur le processus de développement, les standards,
etc.
Différentes natures de la spécification
Les spécifications non fonctionnelles
Exigences qui ne concernent pas spécifiquement le
comportement du système.
Elles identifient des contraintes internes et externes du
système .
Elles doivent avoir des valeurs quantitatives.
Types d’exigences non fonctionnelles
Utilisabilité : Capacité pour un utilisateur d’exécuter une
tâche dans un temps donné après une formation d’une
durée déterminée.
Performance : Temps d’attente < 10s.
Fiabilité : Système critique
Disponibilité : 24/7
Sécurité : Accès personnalisés, connexions sécurisées
Maintenabilité : Modularité, commentaires, complexité,
interfaces
Portabilité : Utilisable avec plusieurs systèmes
d’exploitation
Différentes natures de la spécification
Besoins d’utilisabilité
font référence aux aspects généraux de l’interface
utilisateur
Ex : standard utilisé
définition de la configuration minimale du navigateur
(application Web)
Besoins de performance
décrivent les performances d’exécution du système,
généralement en termes de temps de réponse.
Ex : (application Web) Temps de chargement d’une
page : Le chargement d’une page Web dans le
navigateur ne devrait pas prendre plus de 15 secondes
en condition normale.
Différentes natures de la spécification
Besoins de disponibilité/fiabilité
Concernent le niveau de disponibilité qui
doit être explicitement défini pour les
applications critiques
Ex : exigence de disponibilité 24/24, 7/7
sauf période de maintenance (à spécifier...)
Besoins de sécurité
Peuvent définir les niveaux d’accès
possibles au système pour les utilisateurs
du système et les systèmes externes.
Ex : Toute information confidentielle fournie
par les clients via l’Internet sera cryptée
avec le système XYZ ou par l’algorithme, la
méthode....ABC..
Différentes natures de la spécification
Besoins matériels
définissent les configurations matérielles
minimales nécessaires au fonctionnement du
système
Ex : Pentium 4, 2G, carte graphique...Résolution...
Besoins de déploiement
décrivent la façon dont l’application sera livrée à
l’utilisateur final
ex : Tous les logiciels du côté client vont être
téléchargés et installés à partir du navigateur, sans
que le poste du client ne soit redémarré ou
configuré manuellement
Les processus de la définition de la
spécification
Explicitation
Validation de
Etude de et analyse
Spécification la
faisabilité des besoins
spécification
Rapport de Modèles de Spécification Cahier de
faisabilité système du système charges
Spécification
des besoins
Les processus de la définition de la
spécification
Basée sur l’analyse des informations, la collecte d’information
et la rédaction des rapports
L’étude de faisabilité dresse une vue d’ensemble du rôle du
système dans son éventuel environnement d’utilisation en vue
d’évaluer sa pertinence.
Elle permettre de décider si l’étude mérite d’être approfondie
ou non.
Questions à poser à cette étape
Que feriez-vous si le système n’était pas implémenté ?
Quels problèmes rencontrez-vous avec les systèmes
existants ?
Pourquoi un nouveau système améliorerait cette situation ?
Quelle contribution directe apporterait un tel système sur
votre travail ?
Les différentes étapes
Explicitation
Validation de
Etude de et analyse
Spécification la
faisabilité des besoins
spécification
Rapport de Modèles de Spécification du Cahier de
faisabilité système système charges
Spécification des
besoins
Analyse des besoins
Cette étape est conditionnée par l’étude de faisabilité
Objectifs : comprendre le domaine, comprendre le
problème
Parfois appelé élicitation des exigences ou découverte
des exigences.
Elle, Implique le personnel technique travaillant avec
les clients afin de se renseigner sur le domaine
d'application, les services que le système devrait
fournir et les contraintes opérationnelles du système.
Peut impliquer les utilisateurs finaux, des gestionnaires,
des ingénieurs impliqués dans l'entretien, les experts
du domaine, des syndicats, etc. Ils sont appelés parties
prenantes ou stakeholders.
Analyse des besoins
Problèmes recurrents pendant la phase de capture des
besoins
Les interlocuteurs ne savent pas souvent ce qu’ils veulent
exactement
Les interlocuteurs expriment leurs exigences dans leurs propres
termes
Les interlocuteurs peuvents exprimer des exigences conflictuelles
Les facteurs organisationels et politiques peuvent influencer
l’analyse des besoins
Les exigences peuvent changer pendant le processus. De
nouveaux interlocuteurs peuvent émerger et le contexte peut
changer.
Les différentes étapes
Explicitation
Validation de
Etude de et analyse
Spécification la
faisabilité des besoins
spécification
Rapport de Modèles de Spécification Cahier de
faisabilité système du système charges
Spécification
des besoins
Spécification
Interface entre le client et les développeurs
doit être compris par les deux
définit dans le détail ce qui doit être réalisé
doit être précis car contractuel
Utilisation de techniques semi-formelles
e.g. diagrammes de cas d'utilisation UML
e.g. diagrammes de classes UML
Les différentes étapes
Explicitation
Validation de
Etude de et analyse
Spécification la
faisabilité des besoins
spécification
Rapport de Modèles de Spécification Cahier de
faisabilité système du système charges
Spécification
des besoins
Validation de la spécification
Elle permet de comparer les besoins explicités
avec les besoins réellement exprimés par les
utilisateurs
Elle permet d’identifier des erreurs
Pour une bonne conceptualisation
Et éviter des coût élevés de développement en
évitant des retours en arrière
Validation de la spécification
Points de vérifications
Vérification de la validité: une fois ses besoins explicités, il se peut
qu’un acteur revienne sur ses déclarations et ré-exprimé ses besoins
différemment.
Vérification de la cohérence: les besoins exprimés dans le cahier des
charges ne doivent pas être contradictoires.
Vérification de la complétude: le cahier des charges doit, tant que
possible, contenir la totalité des besoins des acteurs.
Vérification du réalisme: on doit vérifier que les besoins peuvent être
effectivement satisfaits à l’aide de la technologie existante et en
respectant le budget et les délais.
Vérifiabilité: on doit s’assurer que les besoins sont exprimés sous une
forme vérifiable, avec le moins d’ambiguités possibles, de façon à ce
que le document puisse faire office de contrat
Validation de la spécification
Procédés de vérifications
Relecture systématique (reviews) du cahier des
charges par un ou plusieurs tiers.
Écriture d’un prototype (cf. les processus évolutifs)
Génération de cas des tests exécutables (test cases).
(cf.Extreme Programming)
Bibliographie
http://fr.wikipedia.org/wiki/
Unified_Modeling_Language#Les_diagrammes?
http://laurent-piechocki.developpez.com/uml/tutoriel/lp/
cours/i-p7.html
Pierre Bommel, Cours UML,
Pascal Roques, UML 2 par la pratique
Eric Cariou, OCL:Object Constraint Language, 2003
Michel Tollenaeré, Management des Systèmes
d’Information (MSI)
Laurent Henocque, UML2: Les diagrammes
Object-Oriented Software Engineering
Practical Software Development using UML and Java
SWE 205 - Introduction to Software Engineering
22
