\documentclass[a4paper,12pt]{report} \usepackage[utf8]{inputenc} \usepackage[T1]{fontenc} \usepackage[francais]{babel} \usepackage{indentfirst} %\usepackage{layout} %\usepackage{geometry} %\usepackage{setspace} \usepackage{soul} \usepackage{ulem} %\usepackage{eurosym} \usepackage{graphicx} %\usepackage{bookman} %\usepackage{charter} %\usepackage{newcent} %\usepackage{lmodern} %\usepackage{mathpazo} %\usepackage{mathptmx} %\usepackage{url} %\usepackage{verbatim} %\usepackage{moreverb} %\usepackage{listings} %\usepackage{fancyhdr} \usepackage{wrapfig} %\usepackage{color} %\usepackage{colortbl} \usepackage{amsmath} \usepackage{amssymb} \usepackage{mathrsfs} \usepackage{eurosym} %\usepackage{asmthm} %\usepackage{makeidx} \usepackage[babel=true]{csquotes} \addto\captionsfrench{\renewcommand{\chaptername}{Partie}} \begin{document} \begin{titlepage} \begin{figure}[h] \begin{center} %\includegraphics[width=5cm]{eisti.jpg} \end{center} \end{figure} \vfill \begin{center} \begin{Huge} \bsc{Génie Logiciel 2 :\\ Analyse (partie 1)}\\ \end{Huge} \vspace*{6cm} \begin{Large} Christian \bsc{Ingouff}\\ Pierre-Alexandre \bsc{Tyndal}\\ Sonia \bsc{Seddiki}\\ Yann \bsc{Charbonnier}\\ \vspace*{1cm} EISTI\\ \end{Large} \vspace*{0.33cm} 2013/2014\\ Semestre 2\\ Jalon 2\\ \end{center} \end{titlepage} \tableofcontents \chapter{Présentation du jalon} % Dire de quoi ça parle grosso merdo %\section{Contexte} Après avoir reformulé avec précision les contraintes et attentes définies par l'utilisateur, nous sommes maintenant en mesure de procéder à l'analyse. Cette phase est assez longue, d'autant plus que nous ne disposons pas encore de tous les outils théoriques nécessaires à son étude exhaustive. C'est pourquoi elle sera traitée en deux rapports successifs.\\ La phase d'analyse est importante. En effet, elle permet de modéliser de manière plus claire les attentes exprimées dans le cahier des charges, mais aussi de les rendre plus exploitables pour la suite du projet. Il est capital de distinguer clairement la phase d'analyse des phases de conception et réalisation. Ici, il s'agit de faire apparaître les fonctionnalités, contraintes, interactions que nous allons créer par la suite. Il n'est donc pas question de s'interroger sur les solutions techniques mises en oeuvre pour répondre au problème.\\ Le modèle d'analyse choisi pour ce projet est l'analyse orientée objet, réalisée grâce au langage de modélisation UML (Unified Modeling Language).\\ \noindent Dans ce premier compte-rendu, nous détaillerons : \begin{itemize} \item Le diagramme de cas d'utilisation \item Le diagramme de classes\\ \end{itemize} \noindent Pour ce travail, la répartition des tâches s'est effectuée comme suit : \begin{itemize} \item Diagramme de cas d'utilisation : Christian \item Diagramme de classes : Yann, Pierre-Alexandre \item Rédaction du rapport : Sonia, Christian\\ \end{itemize} \chapter{Diagramme de cas d'utilisation} \begin{figure}[h] \begin{center} \includegraphics[width=13cm]{img/diag-usecase.jpg} \caption{Diagramme de cas d'utilisation} \end{center} \end{figure} \newpage Ce diagramme décrit les différents cas d'utilisation de notre logiciel. Il le fait interagir avec des utilisateurs selon une liste d'opérations éventuellement liées entre elles. Ainsi, le diagramme présenté suit le raisonnement décrit ci-dessous.\\ % Décrire le diagramme en suivant à peu près l'énoncé (pdf du sidebar) Nous observons 3 types d'utilisateurs : \begin{itemize} \item L'administrateur \item L'enseignant \item L'élève\\ \end{itemize} Un administrateur peut : \begin{itemize} \item Définir des utilisateurs (administrateurs, enseignants ou élèves) \item Définir des promotions (listes d'élèves) \item Définir des modules (que gèrent les enseignants)\\ \end{itemize} Un professeur peut : \begin{itemize} \item Définir des QCM \item Définir des sessions de QCM, auparavant créés \item Consulter le statut d'une session de QCM \begin{itemize} \item Visualiser les réponses et le score d'un élève à cette session \item Visualiser les statistiques globales de la session\\ \end{itemize} \end{itemize} Un élève peut : \begin{itemize} \item Répondre à des sessions de QCM, auparavant créées \item Consulter les résultats de sa session de QCM \end{itemize} \chapter{Diagramme de classes} \section{Diagramme} \begin{figure}[h] \centering \includegraphics[width=13cm]{img/diag-class.jpg} \caption{Diagramme de cas d'utilisation} \end{figure} \newpage Ce diagramme décompose les besoins à l'aide de définitions de classes, ainsi que d'interactions entre ces classes. Le raisonnement ci-dessous explique le lien entre les classes et les interactions présentées et les besoins de notre projet.\\ % Décrire diagramme classes pareillement (baratin de justification etc...) \noindent Nous avons les classes suivantes : \begin{itemize} \item \textbf{Utilisateur} : défini par un nom et un prénom. Créé par un \textit{Administrateur}. \item \textbf{Administrateur, Enseignant, Eleve} : les 3 types d'utilisateurs (généralisations de \textit{Utilisateur}) \item \textbf{Module} : les enseignants doivent gérer un ou des modules (1..*). Un module peut être géré par un ou plusieurs enseignants (0..*). Défini par un libellé, un syllabus et un prédicat de complétion. Créé par un \textit{Administrateur}. \item \textbf{Promotion} : liste d'élèves (agrégation de \textit{Eleve}). Créé par un \textit{Administrateur}. \item \textbf{QCM} : défini par un libellé et un prédicat de confidentialité. Il est créé par un \textit{Enseignant}. Il est composé de : \begin{itemize} \item \textbf{Question} : défini par un libellé. Contient un ensemble (agrégation) de : \begin{itemize} \item \textbf{Réponse} : défini par un libellé et un prédicat de véracité. \end{itemize} \end{itemize} \item \textbf{Session} : définie par une date de début et de fin et par un nombre de répétition. Elle se passe dans le cadre d'un \textit{Module} et est limitée à une \textit{Promotion}. Elle est créée par un \textit{Enseignant}. \item \textbf{Rendu} : un \textit{Eleve} répond à une \textit{Session} à l'aide d'un rendu. Il est défini par une date et enregistre les \textit{Réponses} données par l'élève. Le score sera obtenu en fonction des réponses données.\\ \end{itemize} Pour un \textit{Module} x, un module "père" est un module prérequis (nécessitant qu'il soit "complété") pour x et un module "fils" est un module qui requiert x.\\ Les statistiques globales pour une session consultables par l'enseignant sont la moyenne, l'écart-type et la fréquence de bonnes réponses par question. Le contenu de ces fonctions, ainsi que le calcul du score d'un élève à un QCM sera développé dans la partie Conception de notre projet. \newpage \section{OCL} \noindent Certains attributs sont soumis à des conditions que nous insérons ici à l'aide d'OCL.\\ \begin{verbatim} context Session::répétition: integer init: 1 \end{verbatim} Le nombre indiquant la répétition dans une session de QCM vaut 1 par défaut.\\ \begin{verbatim} context Session inv: (self.qcm.estPrivé) implies (self.créateur = self.qcm.créateur) \end{verbatim} Si un QCM est privé, ce QCM ne peut être utilisé que par son créateur. Nous traduisons ceci par l'égalité entre le créateur de la session et le créateur du QCM.\\ \begin{verbatim} context Session inv: (self.promotion = self.interviewé.promotion) \end{verbatim} Une session de QCM ne peut être accessible qu'à une seule promotion. Il faut donc vérifier l'appartenance de chaque interviewé qui désire répondre à la promotion correspondante.\\ \begin{verbatim} context Session inv: self.interviewé->count(r : Rendu | r.session = self) <= self.répétition \end{verbatim} On ne peut au maximum répondre qu'au nombre de fois spécifié par le nombre indiquant la répétition. Cette condition vérifie si le nombre de rendus est bien inférieur à ce nombre.\\ \begin{verbatim} context Rendu inv: (self.dateRendu > self.session.dateDébut) AND (self.dateRendu < self.session.dateFin) \end{verbatim} Une session n'est accessible qu'après la date de début et avant la date de fin.\\ \chapter*{Conclusion} % "En résumé, nous avons fait ceci cela, et ça nous a apporté ceci cela" La première partie de cette phase d'analyse nous a donc permis de modéliser deux approches importantes de notre modèle :\\ \begin{itemize} \item Les futurs utilisateurs du logiciel ainsi que leurs différentes interactions \item Les différentes classes prises en compte et les relations s'opérant entre elles\\ \end{itemize} Ces deux diagrammes nous donnent une vision plus détaillée des doléances du cahier des charges, ce qui facilitera la conception, la rendant également plus complète. En effet, la précision de la description du modèle montre l'utilité de nouvelles fonctions qui n'étaient pas forcément explicitées par le client (par exemple, la création d'un système d'authentification pour savoir qui utilise le logiciel, et notamment son statut pour lui accorder les droits d'accès adéquats).\\ Par ailleurs, la décomposition sous forme de classes nous donne la base de notre code Java : création des classes, des accesseurs, prise en compte des contraintes, etc.\\ Toutefois, ces diagrammes ne sont pas figés. Ils sont destinés à être complétés, remaniés à mesure que l'analyse avance, voire à être modifiés dans la phase de conception. Par exemple, lors de l'élaboration de l'interface, il faudra changer le diagramme de classes en conséquence, pour choisir quels objets seront "visibles" par l'utilisateur.\\ % je pense que c'est bien fourni comme conclusion là :) % "Ca va vous aider à faire ceci cela, et ceci cela Le suite de notre travail portera sur les diagrammes d'activité, de séquence et d'états-transitions. Après une analyse surtout structurelle du projet, ces diagrammes vont fournir une description fonctionnelle de notre programme, qui nous aidera, à la fin, à visualiser comment concevoir notre programme afin d'avancer dans notre projet. \end{document}