Université En Ligne

Atelier 2: Objectifs de l’atelier

• Choisir un projet parmi la liste présentée dans le diapo précédent
• Décrire les exigences fonctionnelles en respectant cette description
hiérarchique: Module- Sous module – fonctionnalités
• Décrire les exigences non fonctionnelles avec une quantification

Description du Projet : une plateforme d'université en ligne avec un espace administrateur

et un espace utilisateur. L'objectif principal de cette plateforme est de faciliter la gestion des
activités académiques et l'interaction entre les administrateurs, les enseignants et les
étudiants

Exigences fonctionnelles

Module Espace Administrateur:

Sous Module Administration:
Gestion des Utilisateurs :

● Consultation de liste des utilisateurs .

● Suppression d’un utilisateur.
● Modification d’un utilisateur.

Gestion des Réclamations:

● Consultation des réclamations.

● Suppression d’une réclamation.
● Modification d’une réclamation.

Sous Module Enseignement:

Gestion des Cours :

● Ajout de nouveaux cours.

● Modification des détails des cours.

● Suppression des cours.

● Consultation des cours.

Gestion des Classes:

● Ajout de classes.

● Modification des classes.

 ● Suppression des classes.

● Consultation des classes.

Gestion de Coordination:

● Attribution d'enseignants aux cours.

● Attribution d'étudiants aux classes.

Module Espace Utilisateur:

Sous Module Étudiant :
Gestion des Cours:

● Consultation liste des cours disponibles avec descriptions détaillées.

● Inscription aux cours.
● Suppression d’inscription aux cours.

Matériel de Cours:

● Consultation documents de cours, aux vidéos, aux présentations et aux ressources

pédagogiques.
● Ajouter Commentaire.
● Modification Commentaire.
● Suppression Commentaire.
● Consultation Commentaire.

Gestion Évaluations et Devoirs:

● Consulter le calendrier des évaluations et des devoirs.

● Soumission des devoirs en ligne .
● Consultation des résultats.

Suivi de la Performance :

● Consultation rapports de progrès.

● Consultation des notes .

Support et Aide :

● Accès à des ressources d'aide en ligne.

● Création de tickets d'assistance pour les problèmes techniques ou académiques.

Sous Module Enseignant :

Gestion des Cours :

● Création des détails des cours.

● Modification des détails du cours.
● Consultation des détails du cours.
● Suppression des détails du cours.
Matériel de Cours :

● Ajout documents de cours, de vidéos et d'autres ressources.

● Edition documents de cours
● Suppression documents de cours
● Ajout réponse aux questions des étudiants .
● Modification réponse aux questions des étudiants.
● Suppression réponse aux questions des étudiants .

Évaluations et Devoirs :

● Création de quiz en ligne.

● Modification de quiz .
● Suppression de quiz .
● Évaluation des devoirs soumis par les étudiants.

Suivi des Étudiants :

● Consulter les rapports de progrès des étudiants.

● Envoi de notifications pour les étudiants en retard ou en difficulté.

Exigences non fonctionnelles

Performance Vitesse de Traitement -Le système doit être capable de traiter simultanément au moins
des Requêtes: 500 requêtes sans perte de performance.

-Les pages de cours doivent se charger en moins de 2

secondes, même lorsque l'application est utilisée par un grand
nombre d'étudiants.
 -Les requêtes de base de données complexes, telles que la
génération de rapports, doivent s'exécuter en moins de 5
secondes.

-Les indexes de base de données doivent être régulièrement

Utilisation des ressources entretenues pour maintenir des temps de réponse optimaux.

Optimisation de la Base de Données

Capacité de Montée en -Le système doit être capable de gérer une augmentation de 50
Charge: % du nombre d'utilisateurs actifs sans dégradation significative
des performances.

-Les modules et les fonctionnalités doivent être conçus pour

permettre l'ajout facile de nouvelles fonctionnalités à mesure
que l'université en ligne évolue.

Gestion des Versions: -Les mises à jour du système doivent être gérées de manière
Évolutivité transparente pour les utilisateurs, sans interruption majeure des
services.

-Les données existantes doivent être compatibles avec les

nouvelles versions du logiciel.

Accessibilité: -L'application doit être conforme aux normes d'accessibilité

WCAG (Web Content Accessibility Guidelines) pour garantir
l'accès aux personnes handicapées.
Conformité aux Normes
Utilisabilité d'Accessibilité:

-Les images et les médias doivent être accompagnés de

descriptions textuelles pour les utilisateurs non voyants.

Prise en Charge des -L'application doit fonctionner de manière cohérente sur les
Portabilité Navigateurs et des navigateurs courants tels que Chrome, Firefox, Safari et Edge.
: Dispositifs:

-L'interface utilisateur doit être adaptée aux différentes

résolutions d'écran, y compris les tablettes et les appareils
mobiles.

Protection contre les -L'application doit être protégée contre les attaques courantes,
Sécurité
 Attaques: telles que les injections SQL et les attaques par force brute.

-Les données sensibles, telles que les informations

personnelles des étudiants, doivent être cryptées en transit et
au repos.

Gestion des Identités et -Les utilisateurs doivent avoir des rôles et des autorisations
des Accès: appropriés, limitant l'accès aux informations sensibles.

-La gestion des sessions utilisateur doit être sécurisée pour

empêcher les accès non autorisés.(JWT Auth Token)

Atelier 3: Objectifs de l’atelier:

• Modéliser les exigences fonctionnelles de l’atelier 1 par des packages
• Raffiner le diagramme obtenu en utilisant des sous packages, des composants
et des classes. (utiliser les concepts du cours black box et white box)
• Définir les interactions par des liens de dépendances et des interfaces
• Ajouter des méthodes aux différentes classes

Building Bloc View

LEVEL 0 :
LEVEL 1:

LEVEL 2 : Package Diagram

LEVEL 3 : Component Diagram
Level 4 : Class Diagram
Atelier 4: Objectifs de l’atelier:
• Modéliser la vue de déploiement détaillée conformément aux blocs de
l’atelier 3
• Modéliser la vue de contexte détaillée conformément aux blocs de l’atelier 3
• Modéliser la vue runtime détaillée conformément aux blocs de l’atelier 3

1)Modélisation de la vue de contexte du projet : Système boite noire

: vue générale
Use Case global :
Raffiné : Acteur Admin

Raffiné : Acteur Enseignant

Raffiné : Acteur Étudiant

2) Modélisation de la vue Runtime du projet :

Diagramme de séquence système ( System black box )

Utilisation d’un patron d’architecture MVC ( Model View Controller ) Système boîte
blanche
3) Modélisation de la vue déploiement du projet : Deployment View
Client PC Browser : C'est l'utilisateur final qui interagit avec l'application via un navigateur web. Le client envoie des requêtes HTTP au serveur
web.

Docker Container Web Server : C'est le serveur web qui héberge l'application frontend. Il reçoit les requêtes HTTP du client et renvoie les pages
web correspondantes. Il peut être configuré pour gérer la mise en cache, la sécurité, et d'autres aspects liés à la gestion des requêtes web.

Application Frontend : C'est la partie de l'application qui s'exécute dans le navigateur du client. Elle est généralement écrite en HTML, CSS et
JavaScript, et elle communique avec le serveur web via des requêtes HTTP pour obtenir des données ou envoyer des actions.

Docker Container Backend : Il s'agit de la partie serveur de l'application qui gère la logique métier, la gestion des utilisateurs, les opérations de
base de données, etc. Il communique avec le serveur web et la base de données via des API REST sécurisées (HTTPS).

API REST (HTTPS) : L'API REST est utilisée pour les communications entre le backend et le frontend, ainsi que pour toute interaction entre
l'application et d'autres services tiers. HTTPS est utilisé pour assurer la sécurité des données en transit.

Docker Container Database Server : Il héberge la base de données Oracle utilisée par l'application. Il permet le stockage, la récupération et la
gestion des données de l'application. Le backend communique avec la base de données via JDBC (Java Database Connectivity).

Atelier 4 : Objectifs de l’atelier:

• Appliquer un patron d’architecture à la vue building blocs de l’atelier 3 tout en
gardant le découpage fonctionnel
• En déduire les conséquences sur les autres vues
• Proposer l’application de patrons de conception ou de techniques de
conception au diagramme de classe du projet
Patron d'Architecture - q) :
- Modèle (Model) : Dans cette vue building blocs, les éléments du modèle représentent la
gestion des données et la logique métier. Les classes de données, telles que Enseignant,
Classe, Cours, Note, etc., résident dans le Modèle. Elles ne traitent que des opérations de
données et de logique métier.
- Vue (View) : Les éléments de la vue sont responsables de l'interface utilisateur et de
l'affichage des données. Par exemple, les interfaces utilisateur pour l'inscription, la
connexion, la liste des cours, les détails des cours, les réclamations. ,Chaque interface
correspond à une vue distincte.
- Contrôleur (Controller) : Les éléments du Contrôleur sont responsables de la gestion des
interactions utilisateur, du traitement des actions de l'utilisateur et de la coordination avec le
Modèle.

Conséquence sur les autres Vues :

- Consistance de l'architecture : Les autres vues doivent également adopter le modèle MVC
pour assurer la cohérence architecturale. Chacune devrait avoir ses propres Modèle, Vue et
Contrôleur correspondants, alignés avec les fonctionnalités spécifiques de chaque vue.

Diagramme de séquence avec mvc

BUILDING BLOCK :
LEVEL 0 :

LEVEL 1:

LEVEL 2 :
LEVEL 3 : 1) Admin
2)Enseignant

LEVEL 4 :
Patrons de Conception :
Strategy Design pattern : Ce patron de conception est de type comportemental. Il
définit une famille d’algorithmes qui peuvent être exécutés et choisit lors de
l'exécution d'un programme.
Lorsque vous créez une instance de Matériel Cours, vous attribuez une stratégie
spécifique en fonction du type de contenu que vous souhaitez gérer. La méthode
manageContent() et DisplayContent() sera appelée sur cette stratégie pour gérer le
contenu de manière appropriée.Cela permet de gérer différents types de matériaux
de cours en utilisant des stratégies spécifiques, conformément au patron de
conception Stratégie.
Factory Design pattern : La fabrique (factory method) est un patron de conception
créationnel utilisé en programmation orientée objet. Elle permet d'instancier des objets
dont le type est dérivé d'un type abstrait. La classe exacte de l'objet n'est donc pas
connue par l'appelant.
Diagramme de Classe Après l’application des patrons de conception:
Atelier 6 Objectifs de l’atelier
• Proposer un arbre FCM pour l’analyse qualitative et quantitative du projet
conformément aux exigences non fonctionnelles de l’atelier 1
• Déduire des scénarios de test pour les exigences non fonctionnelles.

Arbre FCM de qualité:

 Scénarios de test

Scénario de test de performance (Recherche de cours) :

Elément Détails

Stimulus Effectuer une recherche avec un mot-clé

Source user

Environnement mode normale

Artefact barre de recherche

Réponse Les cours correspondants au mot-clé sont affichés

Métrique de Les résultats de recherche apparaissent en moins de 3

réponse secondes.
Scénario de test d'évolutivité (Augmentation des utilisateurs) :

Elément Détails

Stimulus Lancement d'une mise à jour majeure de l'application universitaire en

ligne.

Source Équipe de développement.

Environnement Mode de test de mise à jour

Artefact Application universitaire en ligne (ancienne version).

Réponse L'équipe de développement déploie la nouvelle version de

l'application universitaire en ligne.

Métrique de Le test est réussi si la grosse mise à jour se fait sans interruption
réponse pour les utilisateurs, si les données actuelles restent utilisables, et si
la nouvelle version est accessible sans soucis majeurs. Toute erreur
sera notée pour être corrigée.

Scénario de test de sécurité (Limitation de requêtes) :

Elément Détails

Stimulus Envoyer 100 requêtes par seconde

Source equipe sécurité

Environnement mode normale

Artefact serveur

Réponse Le système détecte une tentative de DDoS et bloque l'adresse IP

source

Métrique de Adresse IP bloquée en moins de 10 secondes.

réponse

Scénario de test de Portabilité (Changement d’appareil) :

Elément Détails

Stimulus Ouvrir l’application à partir d’un autre appareil

Source Equipe de test

Environnement mode normale

Artefact Application universitaire en ligne (dernière version)

Réponse L'équipe de test lance l’application sur 5 appareils différents

Métrique de Le scénario de test est réussi et l’application est bien fonctionnelle et

réponse l’interface est mise à l'échelle des appareils mobiles, tablettes ,
ordinateurs sur différentes résolutions.