\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 2)}\\
\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 3\\
\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 avons procédé à l'analyse des besoins. Dans une première partie, nous avons fait l'introduction de celle-ci avec le diagramme de cas d'utilisation et le diagramme de classes, posant ainsi une base structurelle à l'étude de ce projet. Ce livrable finalise l'analyse avec trois autres types de diagrammes : les diagrammes d'activité, les diagrammes de séquence, et les diagrammes d'états-transitions.\\

Le rapport suivant délivrera l'analyse dans son entièreté, c'est-à-dire qu'il inclura les cinq types de diagrammes présentés dans l'analyse. Ce choix a été déterminé d'une part pour la complétude et la cohérence du travail ainsi présenté, et d'autre part pour accueillir une mise à jour au niveau des deux premiers types de diagrammes.\\

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).\\

\newpage

\noindent Dans ce compte-rendu, nous détaillerons :
\begin{itemize}
		\item Le diagramme de cas d'utilisation
		\item Le diagramme de classes
		\item Les diagrammes d'activité
		\item Les diagrammes de séquence
		\item Les diagrammes d'états-transitions\\
\end{itemize}

\noindent Ce livrable dipose de cette répartition des taches :
\begin{itemize}	
		\item Diagrammes d'activité : Christian, Sonia
		\item Diagrammes de séquence : Yann
		\item Diagrammes d'états-transitions : Pierre-Alexandre
		\item Rédaction du rapport : Sonia, Christian\\
\end{itemize}

\chapter{Diagramme de cas d'utilisation}

\begin{figure}[h]
\begin{center}
\includegraphics[width=15cm]{img/dg1.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/dg2.jpg}
\caption{Diagramme de classes}
\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é. Peut être lié à un \textit{Eleve} lorsqu'il est choisi lors d'une session de QCM.
        \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 sa date. Le score sera obtenu en fonction des réponses données (lien entre \textit{Eleve} et \textit{Réponse}).\\
\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{Diagrammes d'activité}

Les différents diagrammes d'activités présentés ci-dessous montrent les interactions entre le logiciel et l'utilisateur.

\section{Définir utilisateurs}

\begin{figure}[h]
\centering
\includegraphics[width=12cm]{img/dg31.jpg}
\caption{Diagramme d'activités : définir utilisateurs}
\end{figure}

Ici, l'administrateur crée les différents utilisateurs. Si l'utilisateur créé est un enseignant, il renseigne également les modules auxquels il est rattaché. Puis il est enregistré dans la base de données.\\

\section{Définir QCM}

\begin{figure}[h]
\centering
\includegraphics[width=12cm]{img/dg32.jpg}
\caption{Diagramme d'activités : définir QCM}
\end{figure}

Le professeur définit le QCM par son libellé. Puis il saisit la première question. Viennent ensuite les différentes propositions de réponse. Pour chaque réponse entrée, on précise si elle est vraie ou fausse. Quand il n'y a plus de réponses à saisir, on passe à la saisie de la question suivante, et ainsi de suite jusqu'à ce que toutes les questions soient rentrées.\\

\newpage

\section{Définir sessions QCM}

\begin{figure}[h]
\centering
\includegraphics[width=12cm]{img/dg33.jpg}
\caption{Diagramme d'activités : définir sessions QCM}
\end{figure}

L'enseignant crée la session de QCM avec date de début, de fin, le nombre de répétitions, la promotion ainsi que le QCM proposé.\\

\newpage

\section{Consulter session QCM}

\begin{figure}[h]
\centering
\includegraphics[width=12cm]{img/dg34.jpg}
\caption{Diagramme d'activités : consulter session QCM}
\end{figure}

L'enseignant consulte la session QCM et peut accéder aux scores et/ou aux statistiques.\\

\newpage

\section{Répondre session QCM}

\begin{figure}[h]
\centering
\includegraphics[width=12cm]{img/dg35.jpg}
\caption{Diagramme d'activités : répondre session QCM}
\end{figure}

Le logiciel affiche la question et les réponses proposées. L'étudiant sélectionne la ou les réponses qu'il souhaite cocher, celles-ci sont ensuite enregistrées par le logiciel (après validation préalable de l'étudiant par exemple). L'opération se répète jusqu'à la dernière question du QCM.\\

\newpage

\section{Consulter résultats session}

\begin{figure}[h]
\centering
\includegraphics[width=12cm]{img/dg36.jpg}
\caption{Diagramme d'activités : consulter résultats session}
\end{figure}

L'élève sélectionne la session qu'il veut consulter (on s'assurera d'ailleurs qu'il ne puisse accéder qu'aux sessions auxquelles il a participé). Puis le logiciel affiche les différentes réponses sélectionnées par l'élève (avec pour chaque question, la réponse de l'élève et la bonne réponse dans le cas où il a mal répondu) ainsi que le score total.\\

\newpage

\section{Définir modules}

\begin{figure}[h]
\centering
\includegraphics[width=12cm]{img/dg37.jpg}
\caption{Diagramme d'activités : définir modules}
\end{figure}

L'administrateur définit le nom du module et, le cas échéant, les différents modules prérequis. Une fois cette saisie terminée, il saisit le syllabus.\\

\newpage

\section{Définir promotions}

\begin{figure}[h]
\centering
\includegraphics[width=12cm]{img/dg31.jpg}
\caption{Diagramme d'activités : définir promotions}
\end{figure}

L'administrateur définit la promotion en renseignant le cycle et l'année scolaire.\\ 

\newpage

\chapter{Diagrammes de séquence}%wip

Les diagrammes de séquence sont une version améliorée des diagrammes d'activité. Ils sont un intermédiaire entre ceux-ci et le code, puisqu'ils utilisent directement les classes et leurs méthodes.\\

\newpage

\section{Définir QCM}
%image de la partie du diag here puis expli
\begin{figure}[h]
\centering
\includegraphics[width=12cm]{img/dg41.jpg}
\caption{Diagramme de séquences : définir QCM}
\end{figure}

On retrouve le même cheminement que dans le diagramme d'activité. Toutefois, la description se fait avec les méthodes des classes QCM, Question et Réponse (ici, les setters). L'encadré "loop" indique que l'on répète ce qui est dans le cadre tant que la condition décrite est vraie. Par exemple, pour la boucle avec la condition "n < nbReponses", on répète ce qui est à l'intérieur (i.e. "setLibelle" et "setEstVrai") tant que le nombre de boucles n est inférieur au nombre total de réponses nbReponses de la question. Autrement dit, on fixe le libellé et la valeur de véracité de la réponse autant de fois qu'il y a de réponses à la question.\\

\newpage

\section{Répondre session QCM}
%same
\begin{figure}[h]
\centering
\includegraphics[width=12cm]{img/dg42.jpg}
\caption{Diagramme de séquences : répondre session QCM}
\end{figure}
Avant de laisser l'élève répondre à la session, deux choix sont possibles :
\begin{itemize}
\item soit il y répond pour la première fois
\item soit il y souhaite revenir sur ses réponses après sauvegarde
\end{itemize}

Dans tous les cas, il faut s'assurer que l'étudiant ne peut répondre qu'avant la date de fin de la session. Le bloc "opt" est utile dans notre cas, puisqu'il symbolise que le contenu du cadre "opt" ne peut être effectué que si la condition associée est vérifiée (ici, que la date actuelle est inférieure à la date de fin).L'élève peut ainsi récupérer les questions et réponses associées, et ensuite répondre au questionnaire.\\

\newpage

\section{Définir modules}
%same
\begin{figure}[h]
\centering
\includegraphics[width=12cm]{img/dg43.jpg}
\caption{Diagramme de séquences : définir modules}
\end{figure}
Après avoir défini le libellé et le syllabus du module, l'administrateur définit quels modules sont des prérequis pour le module considéré tant que la liste n'est pas totalement établie.

\chapter{Diagrammes d'états-transitions}

Suite à l'étude du cahier des charges et donc, par ce biais, l'étude des classes et objets de ce projet, nous avons conclu que seule la session de QCM a une vie suffisamant intéressante pour susciter un étude sous la forme de diagramme.

\section{Session de QCM}

\begin{figure}[h]
\centering
\includegraphics[width=12cm]{img/dg5.jpg}
\caption{Diagramme d'états-transitions : Session de QCM}
\end{figure}
Ce diagramme résume la vie de la session de QCM. Lors de sa création, la session de QCM est fermée, et selon sa date d'ouverture, la session sera ouverte puis refermée. Il est possible de rendre cette session uniquement pendant la periode où cette dernière est ouverte. Une fois la date de fermeture atteinte, la session est fermée qu'elle soit rendue ou non. Le professeur ayant créé la session de QCM est le seul pouvant supprimer ce dernier, et cela à n'importe quel moment.

\chapter*{Conclusion} 

Toute cette partie d'analyse nous permet désormais d'avoir une vision d'ensemble sur le projet. Cette vision transitionnera notre travail vers la phase de conception, à savoir le détaillage de fonctions complexes pour enfin concrétiser la théorie en l'implémentant dans le programme en Java.\\

Tout comme les deux premiers diagrammes nous ont permis de nous représenter la structure du programme, les derniers types de diagrammes cadrent le fonctionnement des entités définies auparavant entre elles. Elles font ainsi l'exposé de comment les classes définies dans le diagramme de classes vont interagir pour pouvoir se plier aux besoins de l'utilisateur.\\

Les diagrammes présentés sont flexibles, et sujets à d'autres modifications durant la phase d'implémentation. En effet, la phase d'analyse n'effectue pas obligatoirement l'étude des limitations d'un langage tel que le Java, et il peut également y avoir d'autres litiges tels que la sécurité du programme ou le souci d'intuitivité parmi d'autres.\\

En conclusion, cette analyse constitue la charpente du résultat final : elle sera définitivement le point d'appui du fonctionnement du programme résultant, mais ne sera pas exclusive dans sa composition. C'est sur cette analyse que s'enchaîne les jalons suivants, c'est-à-dire les phases de conception et de programmation.

\end{document}