Vous êtes sur la page 1sur 3

PROPOSITION DE CORRECTION DE LA NORMALE DE ARCHITECTURE LOGICIELLE

Connaissance du cours :
1- 5 critères de qualité logiciel :
 Maintenabilité : Capacité d’un logiciel à être facilement modifie et entretenu
 Fiabilité : Capacité d’un logiciel à fonctionner de manière fiable et à produire des
résultats précis.
 La sécurité : Capacité d’un logiciel à protéger les données et les systèmes contre les
menaces externes.
 La portabilité : Capacité d’un logiciel à pouvoir fonctionner sur différents
environnements
 La convivialité : Capacité d’un logiciel à être facilement compris et utiliser par les
utilisateurs
2- Les cinq principaux types de lien entre les composants d’un logiciel sont :
 Lien de dépendance
 Lien d’interface
 Lien de flux de donnée
 Lien de référence
3- L’architecture peut impacter sur la qualité du logiciel en : affectant plusieurs aspect clés
talque la maintenabilité, la fiabilité, la performance, la sécurité et la convivialité du logiciel.

4- Description brève de quatre types d’architecture logicielle


 Architecture en couche : cette architecture divise le système en couche, chaque couche
représentant une fonctionnalité spécifique.
 Architecture oriente service (SOA) : cette architecture est base sur l’utilisation de
service pour communiquer entre les composants logiciels.
 Architecture micros services : cette architecture est une variante de SOA qui se
concentre sur des services plus petits plus modulaires.
 Architecture évènementielle : cette architecture est axée sur la gestion des évènements
dans le système.
5- Description brève de deux évènements figurant dans la métrologie agile Scrum :
 La revue de sprint : elle a lieu à la fin de chaque sprint et permet à l’équipe de
présenter les fonctionnalités développées pendant le sprint et de recueillir des
commentaires des parties prenantes.
 La rétrospective de sprint : elle a lieu à la fin de chaque sprint et permet à l’équipe de
réfléchir à la façon dont le print s’est déroulé et d’identifier les opportunités
d’amélioration pour le prochain sprint.

PROBLEME :
PARTIE A :

1- Le module de gestion de données de base (articles, utilisateur) des notes, sera celui qui fournira les
données au module de gestion de stock. Car le module de gestion des stocks a besoin d’accéder aux
données de base pour pouvoir gérer efficacement les stocks, les commandes…

2- L’architecture appropriée serait l’architecture oriente service (SOA), car elle permettrait de
découpler les différents modules de l’application et les rende indépendante les uns des autres. Donc le
module de gestion de base sera exposé sous forme de service pour permettre au module de gestion des
stocks d’y accéder, ce qui permettra une meilleure évolutivité de l’application.

PARTIE B :
1- les composants principaux de cette application sont :
 Module de gestion des utilisateurs : elle permettra aux clients, aux vendeurs et aux
responsables de se connecter à l’application avec des interfaces personnalisées.
 Module de gestion des ventes : pour permettre aux clients d’acheter des billets ou des
abonnements, aux vendeurs de guichets d’effectuer des ventes groupées, aux
responsables de consulter l’état des billets et d’élaborer un tableau de bord
 Module de gestion de paiement : pour permettre aux clients d’effectuer des paiements
par carte bancaire ou paiement mobile en toute sécurité
 Module de gestion de billets : pour suivre l’état des billets vendus, leurs disponibilité et
leur utilisation.

* Diagramme de composants :

Application

Utilisateur

Ventes

Paiement

Gestion des billets


2- L’architecture approprier pour cette application pourrait être une architecture micro service,
car elle permettra de coupler les différents modules de l’application et de les rendre indépendant les uns
des autres. Ce qui permettra de déployer indépendamment les modules afin d’optimiser les
performances de l’application.

Vous aimerez peut-être aussi