LA DÉMARCHE. La démarche proposée est basée sur un cycle de vie en cascade, et elle est constituée des étapes suivantes: 1.

Transcription

1 DÉMARCHE

2 LA DÉMARCHE La démarche proposée est basée sur un cycle de vie en cascade, et elle est constituée des étapes suivantes: 1. Etude préalable 2. Spécification des exigences (ou expression des besoins) 3. Analyse 4. Conception 5. Implémentation 6. Test

3 1-ETUDE PRÉALABLE OU PRÉLIMINAIRE Première étape d un processus de développement dont l objet est de délimiter le périmètre du projet L étude préliminaire a pour objectifs principaux de : établir un recueil initial des besoins fonctionnels et opérationnels, modéliser le contexte du système, considéré comme une boîte noire, en identifiant les entités externes au système qui interagissent directement avec lui (acteurs), répertoriant les interactions (émission/réception de messages) entre ces acteurs et le système, représentant l ensemble des interactions sur un diagramme de contexte.

4 TÂCHES Définir la liste des exigences fonctionnelles Identifier les acteurs externes Identifier les messages échangés entre les acteurs et le système. Diagramme de contexte Réaliser éventuellement un découpage du système.

5 2-SPÉCIFICATION DES EXIGENCES FONCTIONNELLES 1. description détaillée des exigences fonctionnelles 2. Elaboration du diagramme des cas d utilisation système 3. Diagrammes de séquence système 4. Schéma de navigation générale

6 2.2 DIAGRAMME DE CAS D UTILISATION SYSTÈME Objectif: Décrire les besoins fonctionnels des acteurs du système. Procédure : Identifier les cas d utilisation (métier) Représenter les acteurs (métiers) et les cas d utilisation Définir les dépendances entre les cas d utilisation Description générale des cas d utilisation

7 2.3 DIAGRAMMES DE SÉQUENCE SYSTÈME Objectif: pour chaque cas d utilisation définir les interactions entre les acteurs et le système(boîte noire) Procédure: pour chaque cas d utilisation Placer les acteurs du CU dans le diagramme de séquence Représenter le système sous forme d objet

8 2.4 LE SCHÉMA DE NAVIGATION Objectif : élaborer le schéma de navigation de l application Procédure: Identifier les principaux écrans à partir des cas d utilisation et des DS. Les écrans correspondent à des états Préciser les événements / conditions associés aux transitions entre les écrans

9 3- ANALYSE Objectif: Définir la totalité des cas d utilisation (métier et informatique). Procédure: 3.1 Identifier tous les acteurs du système (métier et informatique) 3.2 Description des cas d utilisation 3.3 Elaboration de l interface utilisateur 3.4 Elaboration des diagrammes de séquence 3.5 Elaboration des diagrammes d état transition 3.6 Elaboration des diagrammes de classes 3.7 Synthèse de l analyse Elaboration du diagramme de classes d analyse

10 ETAPE PRÉCÉDENTE Besoins métiers (fonctionnels), interactions acteurs métiers/système, IHM définies. 10

11 3.1 ÉLABORATION DU DIAGRAMME DE CAS D UTILISATION Identifier tous les acteurs du système en prenant comme base ceux définis dans le DCU système de l activité précédente. Les acteurs informatiques apparaissent à ce niveau de l analyse (ex.administrateur d une application). Définir la totalité des cas d utilisation (métiers et informatiques). Les cas d utilisation informatiques sont des fonctions complémentaires qui n ont pas été identifiées lors de la phase d étude fonctionnelle (ex. un module d administration). Définir les dépendances entre les cas d utilisations. 11

12 3.2 DESCRIPTION DES CAS D UTILISATION Décrire de manière textuelle et détaillée les cas d utilisation. Pour chaque cas d utilisation (CU) : 1. Identifier l objectif du CU. 2. Identifier les acteurs du CU à partir du DCU de la sous-activité précédente. 3. Définir les pré conditions et éventuellement post conditions du CU. 4. Décrire le scénario nominal sous forme de liste d actions avec une numérotation chronologique (1- Action 1, 2- Action 2 ). L objectif du CU doit être atteint au terme du scénario. 5. Décrire le(s) scénario(s) alternatif(s) sous forme de liste d actions avec une numérotation chronologique le reliant au scénario nominal (1a : titre 1, Cas alternatif «a» de l étape 1 du scénario nominal). Le(s) scénario(s) alternatif(s) doit s achever par la satisfaction ou l abandon de l objectif. 12

13 3.3 ÉLABORATION DES DIAGRAMMES DE SÉQUENCE Représenter les interactions entre les acteurs et les objets du système pour tous les cas d utilisation en considérant les différents scénarios décrits. 13

14 3.4 ÉLABORATION DES DIAGRAMMES D ÉTAT-TRANSITION Créer des diagrammes d état-transition pour les objets dont il est nécessaire de comprendre leur cycle de vie. 14

15 3.5 ÉLABORATION DES INTERFACES UTILISATEUR Modéliser les interfaces utilisateur de tous les cas d utilisation. Pour chaque cas d utilisation (CU) : 1. Identifier toutes les «entrées» de l IHM qui correspondent aux paramètres des messages du DS pour chaque CU. 2. Représenter les éléments d entrées sous forme de composants IHM : zone de saisie, liste de choix, boutons radios 3. Ajouter à l IHM, les composants de validation (boutons). 4. Représenter les «sorties» de l IHM qui correspondent aux résultats des messages du DS pour chaque CU. 15

16 3.6 ÉLABORATION DES DIAGRAMMES DE CLASSE Définir les classes participantes pour chaque cas d utilisation. 1. Identifier les classes du CU en prenant comme base les objets définis dans le diagramme de séquence du CU et les concepts métiers. 2. Préciser les attributs des classes à partir de ceux identifiés dans le DS (paramètres des messages) et des entrées de l IHM. 3. Préciser les opérations des classes à partir des messages du DS et des actions et activités du DET. Un message «entrant» d un objet correspond à une opération de la classe sollicitée. 4. Déterminer les relations entre les classes : nom de l association, multiplicité, type d association (composition, agrégation, association qualifiée, dépendance, héritage ). 16

17 3.6 SYNTHÈSE DE L ANALYSE Élaboration du diagramme de classe récapitulatif Objectif: Regrouper l ensemble des classes dans un seul diagramme. Procédure 1. Fusionner l ensemble des diagrammes de classes participantes de tous les CU. 2. Fusionner, pour les mêmes classes, les attributs et opérations de chaque classe 3. Mettre en commun toutes les associations entre les classes définies dans les diagrammes de classes participantes.

18 CONCEPTION Transformer l architecture logique du modèle d analyse (PIM) en une architecture technique (également appelée architecture physique) du modèle de conception (PSM) Diagrammes UML Classes, séquence, DET, activités, communication, diagrammes de composants, diagrammes de déploiement. Le choix de l architecture technique doit prendre en compte les exigences non fonctionnelles imposées lors de l expression des besoins: Contraintes de performances. Environnement technique cible. Etat de l art de la technologie.

19 ETAPE 1: ARCHITECTURE TECHNIQUE L architecture technique représente la façon dont les éléments matériels et logiciels sont organisés au sein du système informatique d une organisation. Sur le plan matériel, elle comprend : des ordinateurs, postes de travail et serveurs, des composants réseau : commutateurs, routeurs, des médias de communication : câbles, ondes.

20 ARCHITECTURE TECHNIQUE Une application informatique assure généralement trois fonctions : le dialogue avec l utilisateur (couche présentation), le traitement de l information (couche métier), l accès aux données (couche données). Ces trois fonctions peuvent être prises en charge par différents composants situés sur un ou plusieurs ordinateurs reliés en réseau.

21 COUCHES ET NIVEAUX (LAYERS AND TIERS) Le découpage en couches est un découpage logique Le découpage en niveaux et un découpage physique

22 ETAPE 2: DIAGRAMMES DE SÉQUENCE DE CONCEPTION Pour chaque cas d utilisation (CU) Reporter le ou les acteurs du DCU impliqués dans le scénario. Représenter les objets du système impliqués dans le scénario en prenant comme base ceux identifiés dans le modèle d analyse, en utilisant la classification d Ivar Jacobson: Objets «Dialogue». Objets «Contrôleur». Objets «Entité». Objets techniques (Collection, Date ) identifiés uniquement lors de cette étape. Représenter les messages (synchrones/asynchrones) entre les acteurs et les objets et entre les objets eux-mêmes. La chronologie des échanges doit être respectée.

23 CLASSES DU CAS D UTILISATION Pour chaque cas d utilisation (CU) : 1 Représenter les classes du CU en prenant comme base les objets définis dans le diagramme de séquence technique du CU. Répartir les classes en plusieurs catégories : Classes «Dialogue». Classes «Contrôleur». Classes «Entité» Classes techniques (Collection, Date ) identifiés uniquement lors de cette étape. 2 Préciser les attributs des classes et leurs caractéristiques (visibilité, type, valeur initiale ) à partir de ceux identifiés dans le diagramme de séquence (paramètres des messages). 3 Préciser les opérations des classes et leurs caractéristiques (paramètres avec type, type de résultat) à partir des messages du diagramme de séquence. 4 Déterminer les relations entre les classes : Nom de l association. Multiplicité. Type d association (composition, agrégation, association qualifiée, dépendance, héritage ). Contraintes (ordonnées, non ordonnées ).

24 ETAPE 5: ÉLABORATION DU DIAGRAMME DE PAQUETAGE Regrouper l ensemble des classes en paquetages Regrouper l ensemble des classes par ensemble homogène. Chaque package correspond à un découpage fonctionnel ou technique (architecture en couches) Déterminer les dépendances entre les paquetages.