V.3. Codification
84
85
V.4. Presentation des interfaces
86
87
V.5. Test
En informatique, un test désigne une procédure
de vérification partielle d'un système. Son objectif principal
est d'identifier un nombre maximum de comportements problématiques du
logiciel afin d'en augmenter la qualité (si les problèmes
identifiés lors des tests sont corrigés). Néanmoins, le
test peut aussi avoir pour objectif d'apporter des informations quant à
cette qualité afin de permettre la prise en décisions.
Les tests permettent de vérifier :
? La bonne implémentation de toutes les exigences
(fonctionnelles et techniques) ; ? Le fonctionnement correct des interactions
entre les objets ;
? La bonne intégration de tous les composants dans le
logiciel.
88
Maintenant pour notre travail les tests ci-après ont
été effectué pour vérifie la cohérence, la
fiabilité de donnée :
? Nous avons commencé à test le nom de
l'utilisateur et mot de passe. Il se dégage qu'un utilisateur qui n'est
pas identifié au préalable il ne peut pas accéder dans le
système. Après trois tentatives de nom et mot dépasse
erroné, le système se bloc ;
? Nos champs ont été disposé d'une
manière à ce qu'une valeur vide ne puisse pas être
enregistrée quand vous essayez d'enregistrer un formulaire sur lequel un
champ a une valeur vide le système vous renvoi un message d'erreur qui
stipule « saisir d'abord la valeur de champs qui est vide avant
d'enregistre » ;
? etc.
V.6. Diagramme de déploiement
Le diagramme de déploiement permet de
représenter l'architecture physique supportant l'exploitation du
système. Cette architecture comprend des noeuds correspondants aux
supports physiques (serveurs, routeurs, ...) ainsi que la répartition
des artefacts logiciels (bibliothèques, exécutables, ...) sur les
noeuds. C'est un véritable réseau constitué de noeuds et
de connexion entre ces noeuds qui modélise cette architecture.
Dans UML, les diagrammes de déploiement
modélisent l'architecture physique d'un système. Les diagrammes
de déploiement affichent les relations entre les composants logiciels et
matériels du système, d'une part, et la distribution physique du
traitement, d'autre part.
Les cas d'utilisation sont centrés sur les besoins des
utilisateurs. Ils aident à construire le bon système. Les cas
d'utilisation ne fournissent pas pour autant la bonne manière de faire
le système, ni la forme de l'architecture logicielle : ils disent ce
qu'un système doit faire, non comment il doit le faire.
La vue des cas d'utilisation est une description fonctionnelle
des besoins, structurée par rapport à des acteurs. Le passage
à l'approche objet s'effectue en associant une collaboration à
chaque cas d'utilisation.
Une collaboration décrit les objets du domaine, les
connexions entre ces objets et les messages échangés par les
objets. Chaque scénario, instance du cas d'utilisation
réalisé par la collaboration se représente par une
interaction entre les objets décrits dans le contexte de la
collaboration.
| 
