Cahier des charges

1 - Contexte et définition du projet

On a de plus en plus l'arrivée de plusieurs stagiaires à gérer au sein de l'organisation informatique. Aujourd'hui tout est

consigné dans des archives que l'on oubli. Et cela pose plein de problèmes : on ne peut pas se mettre à chercher le dossier

d'un stagiaire qui a eu à faire son stage des années passées, c'est pas très aisé de retrouver les contacts précédents... De

plus, lorsque l'on doit se renseigner sur le programme suivi par le stagiaire et dans quel service de l'organisation

informatique s’est déroulé son stage, on le fait par email, mais cela devient vite le fouillis : on ne retrouve pas les messages,

chacun possède sa méthode de classement, pas de suivi...). Et comme pour les années à venir la réception ; le tracer du

parcours et le suivi du des stagiaires sont des points à travailler d'urgence.

2 - Objectif du projet

Nous voulons offrir une meilleure organisation des données du stagiaire pendant ; avant ; et après son stage à travers une

application web qui pourra tracer le parcours du stagiaire, les actions ou travaux sur lesquels il a travaillé, ainsi que les

évaluations sur chaque aspect de stage.

3- Description fonctionnelle des besoins

Fonction principale : lister les acteurs et fonctionnalités de base du système

3.1- Les acteurs :

*Encadreur :

-S’authentifier

-Ajouter une tache

-Affecter une tache a un stagiaire

-Lister les taches / lister des taches d’un stagiaire

-Consulter la liste des stagiaires

 -Affecter un thème de stage

*Responsable de la division de l’OI :

-Visualiser le dossier de chaque stagiaire

-Générer les attestations de stage

-Affecter un encadreur a un stagiaire

*Administrateur :

-S’authentifier

-Gérer les stagiaires (Ajouter, modifier, supprimer, et lister)

-Gérer les données de base (Ajouter, modifier, supprimer, et lister)

-Gérer les utilisateurs (Ajouter, modifier, supprimer, et lister)

-Gérer les thèmes de stage (Ajouter, modifier, supprimer et lister)

2.2.1.1 les besoins fonctionnelles

Les besoins fonctionnels se rapportent aux fonctionnalités que l'application en question doit offrir pour satisfaire les utilisateurs. Il

s'agit des fonctionnalités du système. Ce sont les besoins spécifiant un comportement d'entrée/sortie du Système. Dans ce contexte,

notre système doit permettre la :

 Remplir des demandes:

Cette tâche va être effectuée par un agent. Il s’agit de remplir un formulaire de stagiaires.

 Gestion des demandes reçues :

Cette tâche est confiée au responsable (l’administrateur de l’application), ce qui nécessitera une authentification avant toute

utilisation. Elle consiste essentiellement au traitement des demandes reçues.

Le système doit permettre au responsable les fonctionnalités suivantes :

• Affichage de la liste des demandes par ordre d’envoi.

• La recherche (multicritère) des demandes pour le but de consultation, d’édition ou de suppression.
 • L’édition de ces demandes : accepter/refuser ou mettre en attente.

 Gestion des demandes acceptées :

Après toute acceptation, le système insère automatiquement les informations correspondantes au : stage, équipe du travail, stagiaire

et formation dans la base de données et envoie automatiquement un mail d’avis favorable au demandeur contenant un login et mot

de passe, que le système doit générer automatiquement, pour que le stagiaire puisse accéder à son compte personnel par la suite.

Le système devra permettre au responsable de :

• Consulter la liste des stages (effectués ou qui seront effectués) avec la possibilité de les éditer (ajouter les informations du

tuteur, sujet du stage…).

• Mettre à jour les informations.

• Savoir quels sont les stages ayant un rapport.

 Messagerie interne :

Le système doit assurer le contact entre le responsable et les autres utilisateurs.

 Evaluation du stage :

A la fin du stage, le stagiaire est censé rendre un rapport de stage afin de faire le point sur son expérience. Donc, le système doit

permettre aux stagiaires d’importer leurs rapports et au responsable de les évaluer (les stagiaires) à l’aide d’un formulaire à multi

choix.

4-PLANIFICATION DES TACHES

Le déroulement du projet se fera comme suit :

. Une semaine pour la rédaction du cahier de charge

. Deux semaines pour l’analyse

. Un mois pour la réalisation

. Six jours pour les tests et maintenance

5-CONTRAINTES DU PROJET
Pour réaliser notre application de suivi des stagiaires, nous de devons respecter trois (3) contraintes à savoir :

Contrainte de cout
Nous devons respecter le prix fixer dans l’étude financières et éviter une surestimation ou une sous-estimation de ces prix ; le

budget d’un projet inclut des couts fixes et variables, notamment du matériel. Le contrôle des couts est indispensable à la

réussite du projet.

Contrainte du temps 

Nous devons réaliser ce projet pendant une période bien déterminer et on doit respecter les objectifs fixés ; l’équipe de gestion

du projet doit définir le calendrier réaliste permettant de mener à bien chaque phase du projet. De plus l’équipe de projet doit

analyser le déroulement des étapes passées, de noter les tendances et impacts sur les plans futurs, et de communiquer les

informations a toutes à toutes les personnes concernées.

Contrainte de portée

Après le prix et un délai fixer, nous devons produire une application de bonne qualités à nos utilisateurs, une application flexible

et réutilisable et surtout évolutive. Fournir une documentation claire de la portée complète du projet dès le début de celui-ci,

notamment l’ensemble des exigences.

6-RESSOURCES NECCESSAIRES A LA REALISATION DU PROJET

6.1-Ressources matérielles :

Ici la présence de machine (ordinateur, ordinateur serveur) est requise, matériel de bureau (stylo, format, crayon). Bien
évidemment des machines ayant des propriétés au choix du développeur.

6.2-Ressources logicielles :

. Microsoft Word : Edition des documents &rapports

. SYSBASE /POWER AMC : Outil de modélisation

. VISUAL STUDIO : Environnement de développement

. SQL SERVEUR: SGBD

. Google Chrome: Navigateur web

. IIS 10 : Serveur Web

6.3-Delais de réalisation :

La réalisation du projet prendra 10 à 12 semaines.

7-LES LIVRABLES
Comme livrables nous pouvons citer : 

.Le rapport de production de l’application ;

.Une application web de suivi des stagiaires;
.Le guide d’utilisation de l’application à produire.

CONCLUSION
Parvenue à la fin de notre étude où il était question d’établir les éléments qui nous permettront de réaliser notre
projet, nous avons précisé les objectifs, décrit les fonctionnalités de l’application à produire. Un accent a aussi été
porté sur les contraintes et les ressources nécessaires à la réalisation de ce projet et enfin un planning prévisionnel a
été proposé. Cette étude préalable qui constitue notre cahier des charges est le point de départ projet.

ar l’ajoutdes sujets de discussion, ainsi que l’ajout des réponsesaux sujets ajoutés. Le BackOffice est la partie ou est
assuré le paramétrage de notre application. Cette partie intégrera la gestion des stages, la gestion des encadreurs, la
gestion des étudiants, la gestion des membres de jury et la gestion des p.

La modélisation objet consiste en une représentation abstraite du monde réel en un ensemble d'entités appelées «
Objets ». Un objet peut aussi bien représenter des éléments physiques du monde réel (Enseignant, Voiture, Salle,...)
que des éléments abstraits (Date, Unité d'Enseignement,...). La puissance de l'approche objet réside dans le fait que
les objets encapsulent des propriétés et des comportements (Méthodes) au contraire des méthodes systémiques
(MERISE,...) qui séparent les données des traitements.

Un des points forts de l'approche objet consiste à se concentrer sur la modélisation des systèmes, indépendamment
de la technologie qui sera utilisée pour la réalisation. Cette propriété très intéressante permet aux chefs d'entreprises,
soit d'arrêter le processus de développement du logiciel, soit de le modifier selon leurs besoins, et cela en étant
encore à l'étape de modélisation (sans faire de dépenses en terme de déploiements technologiques).

UML (Unified Modelling Language) représente un intermédiaire simple et efficace entre concepteurs intervenant dans
le projet et futurs utilisateurs du nouveau système. En effet, les différents diagrammes qu'il propose, simplifient d'une
part le processus de développement aux concepteurs, et permettent, d'autre part, aux utilisateurs et chefs
d'entreprises de suivre les étapes de développement du système et de valider ainsi chacune d'elles.

UML présente neuf (09) diagrammes (dans sa version 2 il présente treize diagrammes), chacun étant utilisé pour
mettre en évidence un aspect bien défini du système.

Selon Pascal Rocque, les neuf diagrammes UML se répartissent selon trois axes de modélisation : fonctionnel, statique
et dynamique.

Figure 1 : Les Diagrammes UML par axes de modélisation

Ces diagrammes, d'une utilité variable selon les cas, ne sont pas nécessairement tous produits à l'occasion d'une
modélisation. Les plus utiles pour la maîtrise d'ouvrage sont les diagrammes d'activités, de cas d'utilisation, de classes,
d'objets, de séquence et d'états-transitions. Les diagrammes de composants, de déploiement et de communication
sont surtout utiles pour la maîtrise d'oeuvre à qui ils permettent de formaliser les contraintes de la réalisation et la
solution technique.

L'analyse objet est basée sur une perception tridimensionnelle selon trois axes :

Ø Une analyse fonctionnelle : Elle décrit le savoir-faire de l'objet.

Ø Une analyse dynamique : Elle décrit le cycle de vie de l'objet au cours de l'application (les étapes par lesquelles
passe l'objet ainsi que les évènements qui lui sont envoyés).

Ø Une analyse statique : Elle représentant la description structurelle des objets.

La phase d'analyse, a pour objectif de décrire de manière précise, concise, correcte et compréhensible un modèle du
monde réel. Avant de construire quelque chose de complexe, comme une maison, un logiciel ou un système
d'exploitation, le constructeur doit appréhender les besoins ainsi que l'environnement dans lequel le système existe.
Le but de l'analyse orienté objet est de modéliser le système du monde réel afin qu'il soit compréhensible [RUM ;
1997].

2.2 - Cas d'utilisation (use cases)

C'est un ensemble d'actions réalisées par le système en réponse à une action (Sollicitation) d'un acteur, c'est donc une
vue du système dans son environnement extérieur.

Il mobilise donc un service rendu par le système, sans imposer le mode de réalisation de ce service. On le représente
par une ellipse contenant le nom du cas :

II.2.3 - Le diagramme des cas d'utilisation

L'ensemble des use cases décrit les objectifs (but) du système ; il constitue le diagramme des cas d'utilisation dont la
représentation graphique est la suivante :
La figure (Figure 4) suivante illustre le diagramme de cas d'utilisation de notre système d'administration et de sécurité
de SIGESTAG.

Ils y sont représentés dans ce diagramme des cas d'utilisation, le système (avec sa frontière), les acteurs et les
associations entre acteurs et cas d'utilisation.

Figure 4 :Le diagramme de cas d'utilisation de notre système

Pour outiller les cas d'utilisation, la description textuelle est indispensable, car elle seule permet de communiquer
facilement et précisément avec les utilisateurs. La description textuelle est également l'occasion de s'entendre sur la
terminologie employée, ainsi que d'identifier le contexte d'exécution de l'un ou de l'autre des enchainements. En
revanche, le texte présente des désavantages puisqu'il est difficile de montrer comment les enchainements se
succèdent ; en outre la maintenance des évolutions s'avère souvent périlleuse.

Il est donc recommandé de compléter la description textuelle par un ou plusieurs diagrammes dynamiques, qui
apporteront un niveau supérieur de formalisation.

II.2.4 -Description textuelle de quelques cas d'utilisation

II.2.4.1 - Cas d'utilisation : ajouter stagiaire

Le tableau 1 suivant présente la description textuelle du cas d'utilisation Ajouter stagiaire, pour enrichir le diagramme
de cas d'utilisation :

Nom

Ajouter stagiaire

Résumé

Ce cas d'utilisation permet à l'administrateur d'ajouter un nouveau stagiaire dans la base de données

Acteurs primaires
Administrateur

Acteurs secondaires

Aucun(SGDB)

Pré - condition

Le stagiaire n'est pas inscrit

Scénario nominal

1. L'administrateur clique sur le lien d'ajout de stagiaire

2. Le système lui propose l'interface d'enregistrement

3. L'administrateur entre les données puis clique sur le bouton d'envoi

4. Le système contrôle les informations entrées

5. Le système envoie un message de confirmation de l'ajout à l'administrateur.

Scénario alternatif

A1 : les informations entrées sont incorrectes

L'enchainement A1 commence au point 4

6- Le système informe l'utilisateur de l'erreur et réaffiche la page d'enregistrement

Le scénario reprend au point 3

Scénario d'erreur

Post - condition

Le système a enregistré un nouvel stagiaire dans la base de données. Un nouvel utilisateur vient d'être ajouté.

Tableau 1 : description textuelle du cas d'utilisationAjouter stagiaire

II.2.4.2 - Cas d'utilisation : Connexion

Nom

Connexion

Résumé

Ce cas d'utilisation permet à un utilisateur de se connecter à la plateforme et d'avoir accès à son compte.

Acteurs primaires

Utilisateur

Acteurs secondaires

Aucun (SGBD)

Pré - condition
Avoir les informations (email, mot de passe) enregistrées dans la base de données du système

Scénario nominal

1. L'utilisateur lance l'application

2. Le système affiche l'interface de connexion

3. L'utilisateur saisie les informations de son compte

4. Le système vérifie les informations entrées

5. Le système affiche la page d'accueil (utilisateur, administrateur)

Scénario alternatif

A1 : les informations du compte sont incorrectes

L'enchainement A1 commence au point 4

5- Le système informe l'utilisateur de l'erreur

Le scénario reprend au point 2

Scénario d'erreur

Post - condition

L'utilisateur est connecté à la plateforme de notre application.

Tableau 2 : Description textuelle du cas d'utilisation Connexion

II.2.4.3 - Cas d'utilisation : ajouter stage

Le tableau 1 suivant présente la description textuelle du cas d'utilisation Ajouter stage, pour enrichir le diagramme de
cas d'utilisation :

Nom

Ajouter stage

Résumé

Ce cas d'utilisation permet à l'administrateur d'ajouter un nouveau stage dans la base de données

Acteurs primaires

Administrateur

Acteurs secondaires

Aucun(SGDB)

Pré - condition

Le stagiaire est déjà inscrit

Scénario nominal

1. L'administrateur clique sur le lien d'ajout de stage

2. Le système lui propose l'interface d'enregistrement

3. L'administrateur entre les données puis clique sur le bouton d'envoi

4. Le système contrôle les informations entrées puis envoie un message de confirmation de l'ajout à l'administrateur.

Scénario alternatif

Scénario d'erreur

Post - condition

Le système a enregistré un nouvel stage dans la base de données.

Tableau 3 : Description textuelle du cas d'utilisation Ajouterstage

II.2.4.4 - Cas d'utilisation : Modifier stagiaire

Le tableau 1 suivant présente la description textuelle du cas d'utilisation Modifier stagiaire, pour enrichir le
diagramme de cas d'utilisation :

Nom

Modifier stagiaire

Résumé

Ce cas d'utilisation permet à l'administrateur de modifierun stagiaire dans la base de données

Acteurs primaires

Administrateur

Acteurs secondaires

Aucun(SGDB)

Pré - condition

Le stagiaire est déjà inscrit

Scénario nominal

1. L'administrateur clique sur le lien de modification de stagiaire

2. Le système lui propose l'interface de modification

3. L'administrateur entre les données puis clique sur le bouton d'envoi

4. Le système contrôle les informations entrées puis envoie un message sur l'état de la modification à l'administrateur.

Scénario alternatif

Scénario d'erreur

Post - condition

Le système a modifié un stagiaire dans la base de données.

Tableau 4: Description textuelle du cas d'utilisation Modifierstagiaire

II.2.4.5 - Cas d'utilisation : Rechercher stagiaire

Le tableau 1 suivant présente la description textuelle du cas d'utilisation Rechercher stagiaire, pour enrichir le
diagramme de cas d'utilisation :

Nom

Rechercher stagiaire

Résumé

Ce cas d'utilisation permet à l'administrateur de rechercherunstagiaire dans la base de données

Acteurs primaires

Administrateur

Acteurs secondaires

Aucun(SGDB)

Pré - condition

- La base de données doit être renseignée

- La base de données doit être mise à jour

Scénario nominal
1. L'administrateur clique sur le lien de recherche de stagiaire

2. Le système lui propose l'interface de recherche

3. L'administrateur choisit le critère de recherche puis entre les données ettape sur latoucheentrée

4. le système fouille le résultat avec lesdonnées choisies

5. le système affiche le résultat de recherche

Scénario alternatif

A1: pas de résultat

A1 commence au point 4 du scénario nominal

5- le système informe l'administrateur de l'indisponibilité du résultat

le scénario reprend au point 2

Scénario d'erreur

Post - condition

La recherche a abouti à un résultat valable

désiré par l'administrateur.

Tableau 5 : description textuelle du cas d'utilisation Rechercher stagiaire

II.2.4.5 - Cas d'utilisation : Imprimer carte stagiaire

Le tableau 1 suivant présente la description textuelle du cas d'utilisation Imprimer carte stagiaire, pour enrichir le
diagramme de cas d'utilisation :

Nom

Inscription

Résumé

Ce cas d'utilisation permet à l'administrateur de rechercher un stagiaire dans la base de données

Acteurs primaires

Administrateur

Acteurs secondaires

Aucun(SGDB)

Pré - condition

- La base de données doit être renseignée

- La base de données doit être mise à jour

Scénario nominal

1. L'administrateur clique sur le lien de recherche de stagiaire

2. Le système lui propose l'interface de recherche

3. L'administrateur choisit le critère de recherche puis entre les données ettape sur latoucheentrée

4. le système fouille le résultat avec lesdonnées choisies

5. le système affiche le résultat de recherche

Scénario alternatif

A1: pas de résultat

A1 commence au point 4 du scénario nominal

5- le système informe l'administrateur de l'indisponibilité du résultat

le scénario reprend au point 2

Scénario d'erreur

Post - condition

La recherche a abouti à un résultat valable

désiré par l'administrateur.

Tableau 6 : description textuelle du cas d'utilisation Imprimer carte stagiaire

II.3 Analyse statique

Dans cette section, nous abordons les modèles du domaine, c'est-à-dire le diagramme de classes statique. Ces
derniers sont utilisés pour modéliser l'aspect statique du système. Ils mettent en avant sa structure statique qu'ils
représentent avec des classes, le vocabulaire utilisé dans le système qu'ils présentent sous forme d'attributs de
classes, ainsi que les relations statiques qui existent entre elles.

II.3.1 Les classes et les objets

Une classe est la représentation d'un ensemble d'éléments (objets) dotés des propriétés, des opérations et d'une
sémantique commune. Elle représente des éléments variés pouvant être concrets (voiture, élève,...) ou abstraits
(commande, livraison,...).

II.3.2 Le diagramme de classe

Nous avons dit plus haut que le diagramme des cas d'utilisation montre le système du point de vue de ses acteurs. Le
diagramme de classe montre plutôt la structure interne. Il exprime de manière générale la structure statique d'un
système, en termes de classes et de relations (associations) entre ces dernières.

Représentation : les classes sont représentées par des rectangles compartimentés :

- le 1er compartiment représente le nom de la classe

- le 2ème compartiment représente les attributs de la classe

- le 3ème compartiment représente les opérations de la classe

NOM DE LA CLASSE

-Attribut1: type

-Attribut2: type

-Attribut3: type

- methode1 (argument): type retour

- methode2 (argument): type retour

Formalisme :

Devant chaque attribut ou méthode est placée une visibilité. UML définit 3 niveaux de visibilité pour les attributs et
méthodes :

1. public (+) : l'élément est visible pour tous les clients de la classe

2. protégé (#) : l'élément est visible pour les sous-classes de la classe

3. privé (-) : l'élément n'est visible que par les objets de la classe dans laquelle il est déclaré.

On ne peut parler de classes sans mentionner les associations : l'association est la relation la plus courante et la plus
riche du point de vue sémantique.

Une association est une relation statique n-aire (le plus souvent : elle est binaire) : c'est-à-dire qu'elle relie plusieurs
classes entre elles. Sur le diagramme, elle est représentée comme l'indique le schéma suivant :

Classe B

Classe A

Nom de la relation

a..b x..y

Cardinalités

La cardinalité ou multiplicité définit le nombre d'instances de l'association pour une instance de la classe. Nous
représentons toutes les cardinalités possibles qu'on peut avoir dans le tableau suivant :
Cardinalités

Signification

Un et un seul

0..1

Zéro ou un

N ou *

Entier naturel

M..N

De M à N

0..*

De zéro à plusieurs

1..*

De un à plusieurs

Tableau 7 : différents sortes de cardinalités

II.3.3 Les données II.4.3.1 - les tables

De notre analyse, on a retenu les classes ci-dessous :

· UTILISATEUR

· STAGIAIRE

· STAGE

· ENCADREUR

· ETABLISSEMENT

· PROBLEME

· SOLUTION

· DOMAINE

· NIVEAU

Classe

Attribut

Description

Type

Taille
Matricule

Le matricule du stagiaire, c'est aussi l'identifiant de ce dernier

Varchar

Nom

Le nom du stagiaire

Varchar

255

Prénom

Le prénom du stagiaire

Varchar

255

DateNaissance

La date de naissance du stagiaire

Date
LieuNaissance

Le lieu de naissance du stagiaire

varchar

255

Tel

Le numéro de téléphone du stagiaire

int

13

Email

L'adresse électronique du stagiaire

Varchar

100

Pwd

Le mot de passe du stagiaire

Varchar
50

Photo

Photo du stagiaire pour la traçabilité

Varchar

255

STAGE

Id_stage

L'identifiant du stage

Int

10

Convention

Le nom du fichier de la convention du stage sur le serveur

Date

DateDebut

La date de début du stage

Date

DateFin

La date de la fin du stage

Thème

Le thème sur lequel porte le stage

Note

La moyenne des notes obtenues dans les différentes rubriques

Rapport

Le nom du fichier du rapport ou mémoire de stage

ENCADREUR

Id_employe
L'identifiant de l'encadreur qui se trouve dans la base de données du système de gestion du personnel

Int

ETABLISSEMENT

Id_etablissement

L'identifiant de la fonction

Int

Nom

Le nom de l'établissement

Ville

Le nom de la ville où se trouve l'établissement

Email
L'adresse électronique de l'établissement

Tel

Le numéro de téléphone de l'établissement

Fax

Le numéro du fax de l'établissement

BP

La boîte postale de l'établissement

PROBLEME

Id_pb

L'identifiant du problème

Int

2
Titre

Le titre du problème

Int

Description

La description du problème

Fichier_description

Le fichier de description détaillé du problème

Date_soumission

La date de soumission du problème

Int

SOLUTION
Id_solution

L'identifiant du module

Int

Description

La description de la solution

Fichier_solution

Fichier contenant la description détaillée de la solution

Date_reponse

La date de dépôt de la réponse

Varchar

255

DOMAINE

Id_domaine
L'identifiant du domaine

Int

nom

Le nom du domaine

Varchar

255

NIVEAU

Id_niveau

L'iedntifiant du nivau

Int

Designation

La désignation du niveau

Varchar
255

Tableau 8 : Dictionnaires des données

II.4.3.2 - Diagramme de classe

Nous allons définir ci-dessous les différentes classes qui interviennent dans notre système et les interactions entre
elles. La figure (Figure 4) présente le diagramme des classes au niveau conceptuel du système que nous mettons en
place.

Figure 5 : Diagramme de classes

II.4 Analyse dynamique

Dans cette section nous allons donner quelques diagrammes de séquences de notre système. En effet, l'étude
dynamique est une étape importante dans la définition des objets et la compréhension de leur fonctionnement dans
le système, elle se base sur plusieurs modèles.

Relativement à notre système nous allons nous baser sur un modèle dynamique : Les diagrammes de séquences (les
scénarios des diagrammes de cas d'utilisation vont nous permettre d'élaborer ces diagrammes de séquences).

II.4.1 - Le diagramme de séquence

Ils montrent les objets impliqués par l'interaction avec les messages échangés (séquentiellement, en parallèle, de
manière synchrone ou asynchrone...) entre ces objets.

Le diagramme de séquence permet de mettre en évidence les interactions entre les différents objets du système. Dans
le cadre de l'analyse, il est utilisé :

- pour préciser le contexte dans lequel chaque objet évolue

- pour mettre en évidence les dépendances entre les différents objets impliqués dans l'exécution d'un processus ou
d'un cas d'utilisation.

Un diagramme de séquence fait apparaître les interactions entre des objets et les messages qu'ils échangent ; il
permet de visualiser les messages par une lecture de haut en bas.

Les éléments du diagramme de séquence sont :

Tableau 9: Elément du diagramme de séquence

Les diagrammes de séquences permettent de représenter des collaborations entre objets selon un point de vue
temporel, on y met l'accent sur la chronologie des envois de messages. On décrit le contexte ou l'état des objets, la
représentation se concentre sur l'expression des interactions.

II.4.1.1 - Diagramme de séquence : Connexion compte

La figure (Figure 6) ci-dessous montre le processus de connexion au système.

Donc la phase d'analyse permet de s'accorder sur « Ce que doit faire le système ? »

II.1.1 Élaboration du schéma de contexte du domaine d'étude

Objectif : positionner le système à étudier au sein de l'entreprise

· Point de départ : Esquisse fonctionnelle du besoin exprimé

· Point d'arrivée : Système à étudier positionné par rapport aux processus de l'entreprise et périmètre fonctionnel
défini.