Système d'inscription aux cours Document d'architecture logicielle Historique des révisions
Document d'architecture logicielle Introduction![]() 1.1 ObjectifCe document fournit une présentation de l'architecture du système, à l'aide d'un certain nombre de vues d'architecture décrivant différents aspects du système. Il a pour vocation de mettre en relief les principales décisions architecturales qui ont été prises par rapport au système. 1.2 PortéeCe document d'architecture logicielle contient une description de l'architecture du système C-Registration. Le système C-Registration est développé par le Wylie College pour permettre l'inscription en ligne aux cours. Ce document a été généré à partir du modèle d'analyse et de conception de C-Registration implémenté dans Rose. La majorité des sections ont été extraites du modèle Rose à l'aide de SoDA et du canevas de document d'architecture logicielle. 1.3 Définitions, acronymes et abréviationsVeuillez consulter le glossaire [4]. 1.4 Références
![]()
![]()
![]() 4.1 Cas d'utilisation importants sur le plan de l'architecture Nom de diagramme : cas d'utilisations importants sur le plan de l'architecture
4.1.1 Fermeture de l'inscription Description : ce cas d'utilisation permet au secrétaire de clôturer le processus d'inscription. Les cours qui n'ont pas suffisamment d'étudiants sont annulés. Les cours doivent contenir au moins trois étudiants. Le système de facturation est informé des étudiants se trouvant dans des cours qui ne sont pas annulés pour pouvoir les facturer. L'acteur principal du cas d'utilisation est le secrétaire. Le système de facturation est un acteur impliqué dans ce cas d'utilisation. 4.1.2 Connexion Description : ce cas d'utilisation décrit comment un utilisateur se connecte au système d'inscription aux cours. Les acteurs qui lancent ce cas d'utilisation sont l'étudiant, le professeur et le secrétaire. 4.1.3 Maintenance des informations des professeurs Description : ce cas d'utilisation permet au secrétaire de maintenir les informations des professeurs dans le système d'inscription. Ceci comprend ajouter, modifier et supprimer des professeurs du système. L'acteur de ce cas d'utilisation est le secrétaire. 4.1.4 Sélection des cours à enseigner Description : ce cas d'utilisation permet à un professeur de sélectionner les cours (cours avec date et heure précisés) qu'il souhaite enseigner dans le catalogue des cours qu'il est autorisé à enseigner pour le semestre suivant. L'acteur qui lance de cas d'utilisation est le professeur. Le système de catalogue de cours est un acteur de ce cas d'utilisation. 4.1.5 Inscription aux cours Description : ce cas d'utilisation permet à un étudiant de s'inscrire aux cours pour le semestre en cours. L'étudiant peut également modifier ou supprimer des cours sélectionnés en cas de modifications au cours de la période d'ajout/suppression au début du semestre. Le système de facturation est informé de toutes les mises à jour. Le catalogue des cours fournit une liste de tous les cours disponibles pour le semestre en cours. L'acteur principal de ce cas d'utilisation est l'étudiant. Le système de catalogue de cours est un acteur dans ce cas d'utilisation. 4.1.6 Affichage des bulletins Description : ce cas d'utilisation permet à un étudiant d'afficher son bulletin pour le semestre terminé. L'étudiant est l'acteur de ce cas d'utilisation. 4.1.7 Soumission des grades Description : ce cas d'utilisation permet à un professeur de soumettre les grades des étudiants pour un ou plusieurs cours complété(s) lors du semestre précédent. L'acteur de ce cas d'utilisation est le professeur. 4.1.8 Maintenance des informations des étudiants
![]() Description de la vue logique de l'architecture. Décrit les classes les plus importantes, leur organisation en module de service et en sous-systèmes et l'organisation de ces sous-systèmes en couches. Décrit également les réalisations de cas d'utilisation les plus importantes, comme les aspects dynamiques de l'architecture. Les diagrammes de classe peuvent être inclus pour illustrer les relations entre les classes, sous-systèmes, couches et modules importants sur le plan de l'architecture. La vue logique du système d'inscription aux cours est composé de trois modules principaux : interface utilisateur, services métier et objets métier. Le module interface utilisateur contient les classes pour les formulaires que les acteurs utilisent pour communiquer avec le système. Des classes frontières permettent la connexion, la maintenance des calendriers, la maintenance des informations des professeurs, la sélection des cours, la soumission des grades, la maintenance des informations des étudiants, la clôture des inscription et l'affichage des bulletins. Le module service métier contient les classes de contrôle de l'interface avec le système financier, du contrôle des inscriptions des étudiants et de gestion des évaluations des étudiants. Le module objets métier contient les classes d'entité pour les artefacts de l'université (cours, calendrier...) et les classes frontières d'interface avec le système de catalogue des cours.
5.1.1 Application couche Cette couche application contient les classes frontières qui représentent les écrans de l'application présentés à l'utilisateur. Cette couche dépend de la couche des objets de processus, reliant le client et le tiers médian. 5.1.2 Services métier couche La couche processus services métier contient les classes de contrôle qui représentent les gestionnaires de cas d'utilisation qui dirigent le comportement de l'application. Cette couche représente la frontière entre le client et le tiers médian. La couche services métier dépend de la couche des objets processus qui relie le client et le tiers médian.
couche La couche logicielle intermédiaire prend en charge l'accès au système de gestion de bases de données relationnel et orienté objet.
![]() Description de la vue de processus de l'architecture. Décrit les tâches (processus et threads) impliqués dans l'exécution du système, leurs interactions et configurations. Décrit également l'allocation des objets et des classes aux tâches. Le modèle de processus illustre les classes d'inscription aux cours organisées en processus exécutables. Les processus existent pour prendre en charge l'inscription des étudiants, les fonctions des professeurs, la clôture des inscriptions et les accès au système de finance et au système de catalogue des cours.
Nom de diagramme : processus 6.1.1 CourseCatalogSystemAccess Ce processus gère l'accès au système de catalogue des cours. Il peut être partagé par plusieurs utilisateurs s'inscrivant aux cours. Un cache des cours récupérés récemment permet d'améliorer les performances. Les threads séparées dans les processus CourseCatalog, CourseCache et OfferingCache permettent de récupérer des données du système existant de manière asynchrone. Mécanismes d'analyse : - interface existante Traçabilité des exigences : - Contraintes de conception : le système doit s'intégrer avec le système existant (base de données de catalogue des cours).
6.1.2 CourseCatalog Le catalogue complet de tous les cours offerts par l'université, y compris les cours des semestres précédents. Cette classe est un adaptateur (voir pattern Gamma). Elle permet de garantir que CourseCatalogSystem peut être accédé par l'interface ICourseCatalog vers le sous-système.
6.1.3 CourseRegistrationProcess Une instance de ce processus est créée pour chaque étudiant qui s'inscrit pour des cours.
6.1.4 RegistrationController Prend en charge le cas d'utilisation permettant aux étudiants de s'inscrire pour les cours du semestre actuel. L'étudiant peut également modifier ou supprimer des cours sélectionnés en cas de modifications au cours de la période d'ajout/suppression au début du semestre. Mécanismes d'analyse : - Distribution
6.1.5 StudentApplication Gère les fonctions étudiant, y compris le traitement de l'interface utilisateur et la coordination avec les processus métier. Une instance de ce processus est créée pour chaque étudiant qui s'inscrit pour des cours.
6.1.6 MainStudentForm Contrôle l'interface utilisateur de l'application Etudiant. Contrôle l'ensemble des formulaires utilisés par l'étudiant.
6.1.7 BillingSystemAccess Ce processus communique avec le système de finance (facturation) pour lancer la facturation des étudiants.
6.1.8 CloseRegistrationProcess Le processus de clôture d'inscription est lancé à la fin de la période d'inscription. Ce processus communique avec le processus contrôlant l'accès au système financier.
6.1.9 BillingSystem Le système financier prend en charge la soumission des factures des étudiants pour les cours auxquels ils se sont inscrits pour le semestre actuel. Mécanismes d'analyse : - interface existante
6.1.10 CloseRegistrationController Le contrôleur de clôture d'inscription contrôle l'accès au système financier. Mécanismes d'analyse : - Distribution
Nom de diagramme : processus vers éléments de conception 6.2.1 CourseCache
6.2.3 Course Une offre précise pour un cours, incluant les jours de la semaine et l'heure. Mécanismes d'analyse : - Persistance - interface existante
6.4 Processus vers implémentation Nom de diagramme : processus vers implémentation
* L'interface Remote permet d'identifier tous les objets distants. Tout objet qui est distant doit implémenter cette interface directement ou indirectement. Seules les méthodes spécifiées dans une interface distante sont disponibles à distance. * Les classes d'implémentation peuvent implémenter un nombre illimité d'interfaces distantes et peuvent étendre d'autres classes d'implémentation distante. 6.4.2 Runnable * l'interface Runnable doit être implémentée par toute classe dont les instances vont être exécutées par une thread. La classe doit définir une méthode sans argument appelée run. * Cette interface a été conçue pour fournir un protocole commun à tous les objets qui veulent exécuter du code lorsqu'ils sont actifs. Par exemple, Runnable est implémenté par la classe Thread. * Etre actif signifie qu'une thread a été lancée et n'a pas encore été arrêtée.
* Une thread est une unité d'exécution d'un programme. La machine virtuelle Java autorise une application à utiliser plusieurs unités d'exécution au même moment. * Chaque thread est dotée d'une priorité. Les threads sont exécutées en fonction de leur priorité. Chaque thread peut être marquée comme serveur ou non. Lorsque le code exécuté par une thread en crée une nouvelle, celle-ci est dotée de la même priorité que celle de la thread dont elle est issue et ne peut être une thread serveur que si le parent est un serveur.
Description de la vue de déploiement de l'architecture. Décrit les différents noeuds physiques des configurations de plate-forme typiques. Décrit également l'allocation des tâches (de la vue de processus) aux noeuds physiques. Cette section est organisée par configuration physique du réseau ; chaque configuration est illustrée par un diagramme de déploiement, suivi par une mise en correspondance des processus aux processeurs. Nom de diagramme : vue de déploiement Les étudiants s'inscrivent aux cours à l'aide d'ordinateurs externes connectés au serveur de l'université par Internet. Les étudiants s'inscrivent aux cours à l'aide d'ordinateurs locaux connectés au serveur de l'université par le réseau local. Ces ordinateurs locaux sont également utilisés par les professeurs pour sélectionner les cours et soumettre les grades. Le secrétaire utilise ces ordinateurs locaux pour maintenir les informations des professeurs et des étudiants. Le serveur d'inscription est le serveur UNIX principal du campus. Toute la faculté et les étudiants ont accès au serveur depuis le réseau LAN du campus. Le système de catalogue des cours est un système existant qui contient le catalogue complet des cours. Il peut être accédé par le serveur de l'université et le LAN. Le système de facturation (système financier) est un système existant qui crée les factures des étudiants pour chaque semestre.
![]()
![]()
|
|