Système d'inscription aux cours

Document d'architecture logicielle
Version 1.0

Historique des révisions

Date

Version

Description

Auteur

21/03/1999 1.0 Document d'architecture logicielle généré à l'aide du canevas Rational SoDA et du modèle Rational Rose. S. Johnson
 
 
 
 
 
 
 
 
 
 
 
 

 

 

Table des matièresHaut de la page.

1.  Introduction

2.   Représentation architecturale

3.   Objectifs de l'architecture et contraintes

4.   Vue des cas d'utilisation

5.   Vue logique

6.   Vue du processus

7.   Vue de déploiement

8.   Taille et performances

9.   Qualité

Document d'architecture logicielle

IntroductionHaut de la page.

1.1 Objectif

    Ce 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ée

    Ce 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éviations

    Veuillez consulter le glossaire [4].

1.4 Références

    Les références applicables sont :

      1. Spécification de l'interface de facturation des cours, WC93332, 1985, Presses du Wylie College.
      2. Spécifications de la base de données de catalogue des cours, WC93422, 1985, Presses du Wylie College.
      3. Document de vision du système d'inscription aux cours, WyIT387, V1.0, 1998, Wylie College IT.
      4. Glossaire du système d'inscription aux cours, WyIT406, V2.0, 1999, Wylie College IT.
      5. Spécification de cas d'utilisation du système d'inscription aux cours - fermeture de l'inscription, WyIT403, V2.0, 1999, Wylie College IT.
      6. Spécification de cas d'utilisation du système d'inscription aux cours - connexion, WyIT401, V2.0, 1999, Wylie College IT.
      7. Spécification de cas d'utilisation du système d'inscription aux cours - maintenance des informations de professeurs, WyIT407, Version 2.0, 1999, Wylie College IT.
      8. Spécification de cas d'utilisation du système d'inscription aux cours - inscription aux cours, WyIT402, Version 2.0, 1999, Wylie College IT.
      9. Spécification de cas d'utilisation du système d'inscription aux cours - sélection des cours à enseigner, WyIT405, Version 2.0, 1999, Wylie College IT.
      10. Spécification de cas d'utilisation du système d'inscription aux cours - maintenance des informations des étudiants, WyIT408, Version 2.0, 1999, Wylie College IT.
      11. Spécification de cas d'utilisation du système d'inscription aux cours - soumission des grades, WyIT409, Version 2.0, 1999, Wylie College IT.
      12. Spécification de cas d'utilisation du système d'inscription aux cours - affichage des bulletins, WyIT410, Version 2.0, 1999, Wylie College IT.
      13. Plan de développement du système d'inscription aux cours, WyIT418, V1.0, 1999, Wylie College IT.
      14. Plan d'itération du système d'inscription aux cours, itération d'élaboration E1, WyIT420, V1.0, 1999, Wylie College IT.
      15. Spécification supplémentaire du système d'inscription aux cours, WyIT400, V1.0, 1999, Wylie College, IT.
2.  Représentation architecturaleHaut de la page.
    Ce document présente l'architecture dans une série de vues, vue des cas d'utilisation, vue logique, vue processus et vue de déploiement. Ce document ne décrit pas de vue d'implémentation séparée. Ces vues se basent sur un modèle UML (Unified Modeling Language) sous-jacent développé à l'aide de Rational Rose.
3.  Objectifs de l'architecture et contraintesHaut de la page.

Certaines exigences clés et certaines contraintes système ont une influence considérable sur l'architecture. A savoir :

    1. Le système de catalogue de cours existant du Wylie College doit être utilisé pour récupérer les informations sur les cours pour le semestre. Le système C-Registration doit prendre en charge le format des données et le système de gestion de bases de données du système de catalogue des cours existant [2].
    2. Le système doit communiquer avec le système financier existant du Wylie College pour facturer les étudiants. Cette interface est définie dans la spécification de l'interface de facturation des cours [1].
    3. Tous les fonctions étudiants, professeurs et secrétaire doivent être disponibles depuis les ordinateurs du campus et les ordinateurs connectés depuis Internet.
    4. Le système C-Registration doit protéger les données et empêcher les accès non autorisés. Tous les accès distants doivent être protégés par identification et contrôle de mot de passe.
    5. Le système C-Registration sera implémenté comme système client serveur. La partie client sera sur les ordinateur et la partie serveur fonctionnera sur le serveur UNIX du Wylie College. [3]
    6. Toutes les exigences de performances et de charge, définies dans le document de Vision [3] et dans la spécification supplémentaire [15], doivent être prises en considération lors du développement de l'architecture.

4.  Vue de cas d'utilisationHaut de la page.

Description de la vue de cas d'utilisation de l'architecture logicielle. La vue de cas d'utilisation est un paramètre important dans la sélection des scénarios et/ou cas d'utilisation sur lesquels l'itération se concentrera. Elle décrit l'ensemble des scénarios et/ou cas d'utilisation qui représentent des fonctions centrales ou importantes. Elle décrit également l'ensemble des scénario et/ou cas d'utilisation qui couvrent de nombreux éléments de l'architecture ou qui illustrent et sollicitent un point délicat particulier de l'architecture.

Les cas d'utilisation de C-Registration sont :

- Connexion

- Inscription aux cours

- Maintenance des informations des étudiants

- Maintenance des informations des professeurs

- Sélection des cours à enseigner

- Soumission des grades

- Affichage des bulletins

- Fermeture de l'inscription.

Ces cas d'utilisation sont initiés par l'étudiant, le professeur ou le secrétaire. De plus, ils comprennent également des interactions avec les acteurs externes catalogue des cours et système de facturation.

4.1  Cas d'utilisation importants sur le plan de l'architecture

Description dans le contenu ci-dessous

      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 : ce cas d'utilisation permet au secrétaire de maintenir les informations des étudiants sur le système d'inscription. Ceci comprend ajouter, modifier et supprimer des étudiants du système. L'acteur de ce cas d'utilisation est le secrétaire.

5.  Vue logiqueHaut de la page.

    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  Aperçu de l'architecture - couches module et sous-système

Légende ci-dessus en titre

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.

5.1.3 Logiciel intermédiaire

        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.

5.1.4 Réutilisation de base

    Le module réutilisation de base comprend les classes supportant les fonctions de listes et les patterns.

     

6.  Vue de processusHaut de la page.

    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.

6.1 Processus

Légende ci-dessous dans le texte

 

      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

       

6.2 Processus vers éléments de conception

Titre ci-dessous dans le texte

 

      Nom de diagramme : processus vers éléments de conception

6.2.1 CourseCache

Le thread CourseCache permet de récupérer des éléments du système de catalogue de cours de manière asynchrone.

6.2.2 OfferingCache

Le thread OfferingCashe permet de récupérer des éléments du système de catalogue de cours de manière asynchrone.

         

6.2.3 Course

Une classe offerte par l'université.

Mécanismes d'analyse :

- Persistance

- interface existante

 

6.2.4 CourseOffering

      Une offre précise pour un cours, incluant les jours de la semaine et l'heure.

      Mécanismes d'analyse :

      - Persistance

      - interface existante

       

6.3 Dépendances modèle de processus vers modèle de conception

Légende dans le texte ci-dessous

Nom de diagramme : dépendances du modèle de processus vers modèle de conception

 

6.4 Processus vers implémentation

Légende dans le texte ci-dessous

Nom de diagramme : processus vers implémentation

6.4.1 Remote

        * 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.

6.4.3 Thread

        * 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.

         

7.  Vue de déploiementHaut de la page.

    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.

    Décrit par le contenu ci-dessus

    Nom de diagramme : vue de déploiement

7.1 Ordinateur externe

      Les étudiants s'inscrivent aux cours à l'aide d'ordinateurs externes connectés au serveur de l'université par Internet.

7.2 Ordinateur

      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.

7.3 Serveur d'inscription

      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.

7.4 Catalogue des cours

      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.

7.5 Système de facturation

    Le système de facturation (système financier) est un système existant qui crée les factures des étudiants pour chaque semestre.

     

8.  Taille et performancesHaut de la page.

    L'architecture choisie prend en charge les exigences clé de taille et de performances définies dans la spécification supplémentaire [15] :

      1. Le système doit pouvoir accepter jusqu'à 2000 utilisateurs simultanés pour la base de données centrale à tout moment et jusqu'à 500 utilisateurs simultanés sur les serveurs locaux à tout moment.
      2. Le système doit donner accès à la base de données de catalogue des cours avec moins de 10 secondes d'attente.
      3. Le système doit terminer 80% de toutes les transactions en moins de 2 minutes.
      4. La partie client ne peut exiger plus de 20 Mo d'espace disque et 32 Mo de mémoire RAM.

    L'architecture sélectionnée prend en charge les exigences de taille et de rapidité en appliquant une architecture client-serveur. La partie client est implémentée sur les ordinateurs locaux ou distants. Les composants ont été conçus pour que la partie client ne requière que le strict minimum d'espace disque et de mémoire sur l'ordinateur.

9.  QualitéHaut de la page.

    L'architecture logicielle prend en charge les exigences de qualité décrites dans la spécification supplémentaire [15] :

      1. L'interface utilisateur de bureau est compatible Windows 95/98.
      2. L'interface utilisateur du système C-Registration devra être simple d'utilisation et pouvoir être utilisée par un utilisateur type dans formation supplémentaire.
      3. Chaque fonction du système C-Registration devra disposer d'une aide en ligne pour l'utilisateur. L'aide en ligne doit inclure des instructions pas à pas sur l'utilisation du système. L'aide en ligne doit inclure les définitions des termes et des abréviations.
      4. Le système C-Registration doit être disponible 24 heures par jour, 7 jours sur 7. Il ne peut être hors service pour plus de 4 % du temps.
      5. Les périodes de panne ne pourront être espacées de moins de 300 heures.
      6. Les mises à jours de la partie client de C-Registration seront téléchargeables depuis le serveur UNIX sur Internet. Cette fonction permet aux étudiants d'accéder facilement aux mises à jour du système.



        

 
Copyright  (c) IBM Corp. 1987, 2004. Tous droits réservés. 

Exemple de projet web d'inscription aux cours
Version 2001.03