Analyse, Conception des Sommaire

Systèmes Informatiques

Objectifs d’un processus d’ingénierie
Méthode d’analyse et de logicielle
conception • Modèles UML (rappels)
• Processus de développement « Unifié »
Unified Process Une partie du matériau de ce cours est issue du cours de Corinne CAUVET - Université d ’Aix-Marseille

O. Boissier, SMA/G2I/ENS Mines Saint-Etienne, Olivier.Boissier@emse.fr, Octobre 2005

2

Objectifs d ’un processus Activités de développement

de développement (rappel)
• Planification (Étude de la faisabilité)
• Un processus définit QUI fait QUOI, QUAND et • Spécification des besoins
COMMENT pour atteindre un certain objectif. • Analyse (Spécification formelle)
 Construction des modèles d ’un ou plusieurs • Conception (Spécification technique)
systèmes,
• Implémentation (Codage)
 Organisation du projet,
• Tests unitaires
 Gérer le cycle de vie du projet de A à Z,
• Intégration et tests
 Gérer les risques,
• Livraison
 Obtenir de manière répétitive des produits de
qualité constante. • Maintenance

3 4
Développement (rappel) Développement (rappel)
Modèle en cascade Modèle en V
Expression vérifie Validation
Analyse des besoins des besoins

Conception vérifie Validation

Analyse
fonctionnelle

Implémentation Conception vérifie Tests du

Du Système système
vérifie
Tests
Conception Tests des
des composants composants
Maintenance
Implémentation
5 6

Développement (rappel)
Modèle en spirale Sommaire

Analyse

Objectifs d’un processus d’ingénierie
logicielle
Conception Spécifications

Modèles UML (rappels)
• Processus de développement « Unifié »

Implémentation Validation

Tests
7 8
 Diagrammes disponibles
Vocabulaire UML (rappel) (rappel) statique
** Possibilité de représenter le même
diagramme à des niveaux de détail State
State
Diagrams
différents. Diagrammes
Diagrams
Constituants de base Use Case
Use Case de Classes State
Relations Use Case Diagrams
Diagrammes
Diagrams State
Annot. Use Case Diagrams
Diagrammes
Dépendances Diagrams
Diagrammes cas d’utilisation Diagrams
note Associations
Diagrams Objets
Diagrammes
de Séquences
Struct. Group. Généralisation
Cas d ’utilisation Package D. Cas d ’utilisation
Classe Modèle Scenario State
Comp. Sous-système D. de classe Scenario State
Classe Active D. d ’objet
Diagrams
Diagrammes Diagrams
Diagrammes
Interaction Framework
Diagrams Modèles Diagrams
Interface D. de séquence
de collaboration de Composants
Composant Machine d ’état
Collaboration D. de collaboration
Noeud D. d ’état/transition Component
Scenario
D. d ’activité Scenario Component
Diagrams
+ des mécanismes d ’extensions D. de composant
Diagrams
Diagrammes
Diagrams
Etat-transiition
Diagrammes
Diagrams
de déploiement
D. de déploiement Diagrammes
dynamique d’activité
9 10

Diagramme de cas d’utilisation Diagramme de cas d’utilisation

objectifs notation
Cas d’utilisation • Description Cas d’utilisation
Séquences • de ce que l ’application doit (ou ne Séquences Cas
d'utilisation
Collaboration doit pas) être capable de prendre en Collaboration
Classes compte, Classes Acteur
Objets • de la manière dont une organisation Objets Le diagramme est accompagné
ou un système externe doivent d ’un texte organisé décrivant le cas
États/transitions interagir avec le système. États/transitions
Activités Activités d’utilisation et permettant de mettre
• Point de vue de l’utilisateur
Composants Composants en évidence les scénarios (flots
• pour mettre en évidence les services
Déploiement rendus par le système, Déploiement d’événements). Un scénario est à un
• pour fixer le périmètre entre le CAS D ’UTILISATION, ce qu ’un objet est à
système et son environnement. sa classe.

11 12
 Diagramme de séquences Diagramme de séquences
objectifs notation
Cas d’utilisation • Validation des cas d ’utilisation, pour Cas d’utilisation Acteur Objet ou classe

Séquences comprendre la logique de Séquences

l ’application. Autre objet ou
Collaboration Collaboration
Augmenter(3,5) « créer »
classe

Classes • Complète le diagramme des cas Classes

getValue(a)

d’utilisation en mettant en évidence

Objets les objets et leurs interactions d’un Objets 5,5
Modifier(b)
États/transitions point de vue temporel États/transitions
Activités • Outils de documentation, peu Activités
Composants rigoureux, pas tout le temps Composants
Déploiement Déploiement X
« détruire »
nécessaires.
• Pas de flots de contrôle dans un
diagramme de séquence, en faire temps
plutôt un autre.
13 14

Diagramme de collaboration Diagramme de collaboration

objectifs Name notation
Cas d’utilisation Cas d’utilisation
• Faire apparaître les classes, 1:augmenter(3,5)
Séquences Séquences Un acteur Un Objet
spécifier l’usage des
Collaboration Collaboration
Classes
instances, Classes
Objets • Montrer les interactions entre Objets 2 : <<créer>>
3 :modifier
États/transitions objets par leurs liens et les États/transitions
Activités messages échangés Activités
Composants • Mêmes conseils d ’utilisation Composants Un Objet Un Autre Objet
Déploiement que les diagrammes de Déploiement
séquences.

15 16
 Diagramme de classes Diagramme de classes
objectifs notation
Cas d’utilisation • Point central de la modélisation du Cas d’utilisation <<Un stéréotype>>

Séquences système pour décrire ce que le Séquences Une Classe

<<Un stéréotype>>
Une autre
système doit faire (analyse) et +Un attribut public classe
Collaboration Collaboration -Un attribut privé * Une association *

comment il va le faire #Un attribut protégé

Classes (conception). Classes +Une opération publique()

-Une opération privée()

Objets Objets
#Une opération protégée()
1-Une classe-association
• Représentation de la structure
États/transitions États/transitions
-Un attribut porté par l'association

statique du système d’information Une sous-classe

Activités • Modélisation des classes et de Activités Un attribut spécifique
Une opération spécifique()
Composants leurs relations Composants Une classe
agrégat
Déploiement • un Diagramme de package permet Déploiement <<Utilitaire>>
Une classe
de représenter les dépendances utilitaire Une
association
entre les différents package du navigable
système.
17 18

Diagramme d’objets Diagramme d’objets

objectifs notation
Cas d’utilisation Cas d’utilisation
Séquences
• Appelé aussi diagramme Séquences
Un objet : Une :Une classe
classe
Collaboration d’instances, il représente aussi Collaboration
Classes la structure statique Classes
Objets • représentation des instances Objets
États/transitions États/transitions
Activités • S’utilise de manière ponctuelle Activités
Composants pour Composants Un Autre Objet
Déploiement • montrer l’effet d’une interaction, Déploiement
• représenter des structures
complexes (récursives)
19 20
 Diagramme d’états-transitions Diagramme d’états-transitions
objectifs notation
• Représentation du cycle de vie
Cas d’utilisation Cas d’utilisation
Séquences des instances d’une classe Séquences
Le premier état
Entrée/Action
Collaboration • Spécification des états, des Collaboration do/Action
transitions entre ces états et Evénement/Action
Classes Classes Sortie/Action
Objets des actions associées aux Objets
transitions. [garde]évenement/action
États/transitions États/transitions
Activités • S’utilise pour la modélisation de Activités Un autre état
Composants la dynamique de certaines Composants
Déploiement classes Déploiement

21 22

Diagramme d’activités Diagramme d’activités

objectifs notation
Cas d’utilisation • Représentation Cas d’utilisation
Séquences • un processus d’une organisation Séquences
Une activité Une autre activité
Collaboration • du comportement d’opérations d ’une Collaboration
Classes classe Classes
Objets • Plusieurs points de vue Objets
États/transitions • pour analyser un processus États/transitions Une activité résultant
Activités • pour concevoir un objet Activités d'une synchronisation

Composants
Plusieurs acceptions de la notion Composants Une transition

Déploiement d’activité Déploiement
• une opération Une activité nouvelle
• une étape dans une opération
• une action d’un scénario d’un cas
d ’utilisation
23 24
 Diagramme de composants Diagramme de composants
objectifs notation
• Description des composants
Cas d’utilisation logiciels et de leurs Cas d’utilisation
Séquences dépendances Séquences Un composant

Collaboration Collaboration
• Composant : un fichier de
Classes Classes
programme source, une
Objets Objets Une dépendance fait référence aux services
offerts par un composant. La flèche va de
bibliothèque, un programme
États/transitions États/transitions l'utilisateur vers le fournisseur.
exécutable, réutilisable
Activités Activités Un autre

Composants • Utilisé en conception de logiciel Composants

composant

Déploiement pour allouer les classes et Déploiement

objets aux composants

25 26

Diagramme de déploiement Diagramme de déploiement

objectifs notation
Cas d’utilisation • Description Cas d’utilisation
Un noeud
Séquences Séquences
• de la configuration matérielle des unités Un composant
Collaboration de traitements (hard et soft). Collaboration
Classes • de l’architecture technique, des nœuds Classes
Objets et de leur interconnexion Objets
États/transitions • Nœuds de l’architecture : serveurs, États/transitions
Activités postes de travail et périphériques Activités
Composants Composants Un autre noeud
• Les composants sont alloués aux
Déploiement Déploiement
différents nœuds Un autre
composant

27 28
 Liens entre les diagrammes
Sommaire
Diagramme Diagramme Diagramme
Objectifs d’un processus d’ingénierie logicielle
Composants Cas Utilisation Classes

Modèles UML (rappels)

Processus de développement « Unifié »
Diagramme
Cas d’Utilisation
Principes
Déploiement

Recueil des besoins, Analyse, Conception

Utilisation des diagrammes
Diagramme Diagramme
Séquences
Processus piloté par les cas d’utilisation
Etats

Processus centré sur l’architecture
Diagramme
Collaboration
Processus guidé par les Patterns

est utilisé par 29 30

Processus Unifié Principes (1) Processus Unifié Principes (2)

Cas Conseils
• Il n ’existe pas un seul processus de Architecture
d ’utilisation « Patterns »
développement, ni de processus standard.
« piloté par » « centré sur» « guidé par»
• CEPENDANT
des caractéristiques essentielles peuvent être Langage « basé sur » Processus Itératif et
mises en avant : UML Unifié « se déroule » incrémental
• Pilotage par les cas d ’utilisation,
• Focalisation sur l ’architecture,
• Utilisation de « patrons » de conception (Design Patterns),
• Déroulement itératif et incrémental. Processus A Processus B

• Accent mis sur les phases plus que sur les activités * Facteurs organisationnels
d’analyse, conception, … * Facteurs de domaine
* Facteurs techniques
31 32
 Processus Unifié Principes (3) Processus Unifié Principes (4)
Piloté par les cas d’utilisation Centré sur l’architecture
• Le processus de développement est centré sur • L’architecture regroupe les différentes vues du
l’utilisateur. système qui doit être construit.
• Elle doit prévoir la réalisation de tous les cas
d’utilisation.
• Marche à suivre:
• Créer une ébauche grossière de l’architecture.
• Travailler sur les cas d’utilisation représentant les fonctions
essentielles.
• Adapter l’architecture pour qu’elle prenne en compte ces cas
d’utilisation.
• Sélectionner d’autres cas d’utilisation et refaire de même.
A partir des cas d’utilisation , les
développeurs créent une série de
• L’architecture et les cas d’utilisation évoluent de
modèles UML. façon concommitante.
33 34

Processus Unifié Principes (5) Processus Unifié Principes (5)

Itératif et incrémental Itératif et incrémental
• Segmentation du travail
• Découpe du projet en “mini-projet” :
• Concentration sur les besoins et les risques,
des ITÉRATIONS qui donne lieu à un INCRÉMENT.
• Chaque itération comprend un certain nombre de cas • Les premières itérations sont des prototypes
d’utilisation et doit traiter en priorité les risques majeurs. • expérimentation et validation des technologies,
• Une itération reprend les livrables dans l’état où les a laissé • planification,
l’itération précédente et les enrichit progressivement
(incrémental). • Les prototypes définissent le noyau de
• Les itérations sont regroupées dans une phase. Chaque l ’architecture.
phase est ponctuée par un jalon qui marquera la décision
que les objectifs (fixés préalablement) ont été remplis.

35 36
 Processus Unifié Principes (5) Phases
Itératif et incrémental Pré-étude Elaboration Construction Transition

temps

• Ordonnancement des itérations basé sur les Vision

priorités entre cas d ’utilisation et sur l ’étude • Pré-étude :
du risque Pré-Etude • Délimiter la portée du système,
• Définir les frontières et identifier les interfaces
Pré-Etude Pré-Etude • Développer les cas d’utilisation
Définition de
• Décrire et esquisser l’architecture candidate
l ’itération
Evaluation • Identifier les risques les plus sérieux
Elaboration Elaboration • Démontrer que le système proposé est en mesure de résoudre les problèmes
Elaboration ou de prendre en charge les objectifs fixés
Intégration  Vision : Glossaire, Détermination des parties prenantes et des utilisateurs,
Intégration Intégration Détermination de leurs besoins, Besoins fonctionnels et non fonctionnels,
Construction Construction Construction Contraintes de conception
37 38

Phases Phases
Pré-étude Elaboration Construction Transition Pré-étude Elaboration Construction Transition

temps temps

Vision Architecture Vision Architecture Premières

fonctionnalités
• Elaboration :
• Spécification des fondements de l’architecture, créer une architecture de • Construction :
référence • Extension de l’identification, de la description et de la réalisation des cas
• Identifier les risques, ceux qui sont de nature à bouleverser le plan, le coût et d’utilisation
le calendrier, • Finalisation de l’analyse, de la conception, de l’implémentation et des tests
• Définir les niveaux de qualité à atteindre, • Préservation de l’intégrité de l’architecture
• Formuler les cas d’utilisation pour couvrir environ 80% des besoins • Surveillance des risques critiques et significatifs identifiés dans les dex
fonctionnels et de planifier la phase de construction, premières phases et réduction des risques
• Planification du projet, élaborer une offre abordant les questions de calendrier,  Produit
de personnel et de budget
 Architecture : Document d’architecture Logicielle, Différentes vues selon la partie
prenante, Une architecture candidate, Comportement et conceptiondes
composants du système 39 40
 Phases
Pré-étude Elaboration Construction Transition Activités (1)
temps
• Modélisation métier :
• Compréhension de la structure et la dynamique de l ’organisation
Vision Architecture Premières Livraison
fonctionnalités Produit • Comprendre les problèmes posés dans le contexte de
l ’organisation
• Transition : • Conception d’un glossaire
• Préparation des activités
• Recommandations au client sur la mise à jour de l’environnement logiciel • Recueil et expression des besoins :
• Elaboration des manuels et de la documentation concernant la version du • Auprès des clients et parties prenantes du projet
produit • Ce que le système doit faire
• Adaptation du logiciel • Expression des besoins dans les cas d ’utilisation
• Correction des anomalies liées au béta test • Spécifications des cas d ’utilisation en scénarios
• Dernières corrections • Limites fonctionnelles du projet
• Spécifications non fonctionnelles
 Livraison du produit aux utilisateurs • Planification et prévision de coût
• Production de Maquettes de l’IHM
41 42

Activités (1)
Production de maquettes IHM Activités (2)
• La production de maquettes peut être réalisée avec • Analyse et conception :
n’importe quel outil graphique : • Transformation des besoins utilisateurs en modèles UML
• ce sont de simples dessins d ’écrans et descriptions de contenu de • Modèle d ’analyse et modèle de conception
fenêtres ; • Implémentation :
• prototype d ’interface généré par un outil • Développement itératif
• Intéressant pour décrire les interfaces avec des acteurs non • Découpage en couches
humains et notamment les notions de protocoles de communication. • Composants d ’architecture
• Pourquoi si tôt dans le processus ? • Retouche des modèles et des besoins
• Unités indépendantes, équipes différentes
• Aide à la description et validation des Cas d’Utilisation
• moyen de communication avec le client • Test, Déploiement, Configuration et gestion des
• permet l ’identification de classes changements, Gestion de projet, Environnement,
• montre au client la progression du travail Déploiement
43 44
 Itérations (2) Une itération
Itérations (1) dans la phase
d'élaboration
Enchaînement des Phases
Pré-étude Elaboration Construction Transition Activités d’Ingénierie Pré-étude Elaboration Construction Transition

Modélisation Métier
Prelim ... Arch ... Cons Cons ... Trans ... Recueil des besoins
Iteration Iteration Iteration Iteration Iteration Analyse & Conception
Implémentation
Test
Release Release Release Release Release Release Release Release Déploiement

Configuration Mgmt
Une itération est une séquence d’activités selon un plan pré-établi et
Management
des critères d’évaluation, résultant en un produit exécutable. Environment
Preliminary Iter. Iter. Iter. Iter. Iter. Iter. Iter.
Enchaînement des Iteration(s) #1 #2 #n #n+1 #n+2 #m #m+1

activités Support Iterations

45 46

Modèles
Sommaire
Recueil Modèles des

Objectifs d’un processus d’ingénierie logicielle Besoins Use Case

Modèles UML (rappels)
Modèles

Processus de développement « Unifié » Analyse d’Analyse

Principes

Recueil des besoins, Analyse, Conception Modèles de Modèles de
Conception

Utilisation des diagrammes Conception Déploiement

Processus piloté par les cas d’utilisation

Processus centré sur l’architecture Implémentation Modèles

Processus guidé par les Patterns D’implémentation
Test Modèles
47
de test 48
 Recueil des besoins Recueil des besoins

Rôle
Recueil des besoins • Identifier les différents intervenants : client(s), utilisateurs,
• L ’une des étapes les plus importantes maître d’œuvre, développeurs, ...
• Identifier le rôle de chacun, éventuellement leur associer des
• déterminante pour la suite priorités
• sert à la définition des aspects contractuels • Identifie les services que le système devrait fournir et définit
• L ’une des étapes les plus difficiles les contraintes sur le système.
• intervenants multiples : client, utilisateurs, • Réunit toute l'information du domaine disponible pour les
membres du projet.
développeurs…
• Établit une base contractuelle sur laquelle le client et
• le problème n’est pas encore formalisé l'organisation du projet s'appuient lors des négociations.
• Règle d’or à respecter : Les informaticiens sont • Permet l'estimation des coûts et des échéanciers
aux services du client, pas l’inverse • Procure les critères de validation et vérification
• Facilite le transfert des connaissances et la gestion des
Section issue du cours de J.M. Favre IMAG 02
configurations
49 50
• Sert de base aux améliorations futures.

Recueil des besoins Recueil des besoins

Exigences (1) Exigences (2)

• Selon IEEE 610.12, une exigence est :
• Une condition ou une capacité nécessaire à un utilisateur pour résoudre un
problème ou atteindre un objectif
• Une condition ou une capacité que doit posséder un système afin de • Exigences fonctionnelles
satisfaire aux termes d'un contrat, d’une norme ou d’une spécification
formellement imposée. • à quoi sert le système
• La représentation documentée de cette condition ou capacité.
• ce que doit faire le système, les fonctions utiles
• Selon IEEE 830, une spécification d’exigences comprend :
• Les fonctionnalités : services et fonctions que le système doit fournir. • Exigences non fonctionnelles
• Les interfaces externes : identification des interactions avec les utilisateurs
et les autres systèmes avec lesquels le nouveau système doit s'intégrer. • performance, sûreté, confidentialité, portabilité,
• La performance : contraintes d'opération du système en disponibilité et en
temps réponse. etc.
• Les attributs du système : caractéristiques intrinsèques telles que la
portabilité, l'exactitude, la maintenabilité, la sécurité, etc. • chercher des critères mesurables
• Les contraintes de conception: contraintes sur la façon de développer le
système.
51 52
 Recueil des besoins Recueil des besoins
Exigences non Etapes :
fonctionnelles vue d’ensemble
• Exigences qui ne concernent pas spécifiquement le • Capture des besoins
comportement du système. • collecte des informations : interviews, lecture de
• Elles identifient des contraintes internes et externes du système. documentation
• Elles doivent avoir des valeurs quantitatives.
• chercher à comprendre : (1) le domaine (2) le problème
• Types d’exigences non fonctionnelles
• Utilisabilité : Capacité pour un utilisateur d’exécuter une tâche dans • Définition des besoins
un temps donné après une formation d’une durée déterminée. • restitution dans un langage compréhensible par le client
• Performance : Temps d’attente < 10s. • identification, structuration, définition d'un dictionnaire
• Fiabilité : Système critique
• Disponibilité : 24/7 • Spécification des besoins
• Sécurité : Accès personnalisés, connexions sécurisées • spécification détaillée des besoins, plus formel
• Maintenabilité : Modularité, commentaires, complexité, interfaces • utile pour le client, mais aussi pour les développeurs
• Portabilité : Utilisable avec plusieurs systèmes d’exploitation
53 54

Recueil des besoins Recueil des besoins

Etapes : Etapes :
Capture des besoins (1) Capture des besoins (2)
• Objectifs : comprendre le domaine, comprendre le
problème  Réagir et être actif !
 Collecter le maximum d ’informations • Établir la liste des documents consultés, les classer
• Lecture des documents fournis, Consulter les • Élaborer une liste de questions précises
documents pertinents au système
• les numéroter, les dater, …
• Interviews du client, des utilisateurs, …discuter avec le
• faire référence aux documents concernés
client ou l’utilisateur afin de bâtir une compréhension
commune des exigences du système. • Écrire un ou plusieurs documents et les diffuser
• Réunions de travail • Provoquer les réunions et les mener
• Collecter des exemples pour valider • établir l’ordre du jour
• Étudier les systèmes existants le cas échéant, • prendre des notes
• faire systématiquement des comptes rendus écrits
• observer l’exécution des tâches des utilisateurs que le
système doit soutenir. 55 56
 Recueil des besoins Recueil des besoins
Etapes : Etapes :
Définition des besoins (1) Définition des besoins (2)
• Restituer les informations sous forme synthétique • Les besoins doivent être compris par tous
• Scénarios et cas d’utilisation : • utiliser la langue naturelle
• Identifier une séquence d'actions effectuées par le système qui • Faire des phrases courtes,
résultent en un résultat observable, • Eviter le conditionnel, le futur, les termes ambigus ou subjectifs, ...
• Utiliser et simuler l'utilisation du système afin d’expliciter et de • Parler en termes de rôles plutôt que de personnes
clarifier Exigences • Numéroter les paragraphes si nécessaire, Utilisation de références
• Ce qui n’est pas écrit n’existe pas ! précises
• Elaborer un dictionnaire
• Préciser les besoins, pas la solution • utiliser des schémas si nécessaire
• Préciser ce que doit faire le système • tout schéma doit être commenté et comporter une
• et aussi ce qu’il n’est pas sensé faire. légende
• mais surtout pas comment il doit le faire.
• Structurer le document de définition
• Etablir des priorités • suivre un plan standard si disponible
• Arriver à un consensus avec le client 57 • numéroter les sections, références, index, … 58

Recueil des besoins Recueil des besoins

Etapes : Etapes :
Définition des besoins (3) Définition des besoins (4)
• Définir un dictionnaire
• Indispensable d'avoir un langage commun
• définition d'un vocabulaire précis • Conseils pour la construction du dictionnaire :
• client, équipe de développement, utilisateurs • Partir de la description du problème
• Utilisation dans les documents et aussi le logiciel !
• analyse des besoins (clients)
• Repérer les groupes nominaux -> notion
• base pour le développement du logiciel (développeurs) • Repérer les groupes verbaux -> action ou notion
• base pour l'interface du logiciel (utilisateurs)
• Eliminer les synonymes
• Technique simple mais efficace !
• Intérêt : • Eliminer les termes inutiles
• Outil de dialogue, Informel, facile à réaliser, facile à faire évoluer • Donner des définitions simples
• Permet de décrire la terminologie du domaine
• réutilisable dans un autre projet • Permet de se concentrer sur l'essentiel
• Permet de détecter les ambiguïtés
• Doit être complété et mis à jour !
• Montre l'essentiel du domaine d'application
• Permet d'assurer la traçabilité
59 60
 Recueil des besoins Recueil des besoins
Etapes : Etapes :
Définition des besoins (5) Spécification des besoins
Notion Définition Nom. Info. Type entité

Action de piloter un avion en • Interface entre le client et les développeurs

Pilotage enchaînant des manoeuvres Pilotage paquetage
élémentaires • doit être compris par les deux
Organe d’interaction entre Classe • définit dans le détail ce qui doit être réalisé
Instrument Instrument
le pilote et l’avion abstraite
Manche à Intrument permettant au MancheABa • doit être précis car contractuel
Classe
balai pilote de diriger l’avion lai
• Utilisation de techniques semi-formelles
Action Définition Nom info. Type entité
• ex. diagrammes de cas d'utilisation UML
Action permettant
Augmenter d’injecter du carburant • ex. diagrammes de classes UML
IncrGaz opération
les gaz pour augmenter la vitesse
de l’avion
61 62

Recueil des besoins Analyse

Intervenants et étapes Modèle d’Analyse

Modèle d ’analyse

* *
Packages d ’analyse

Réalisation de cas d ’utilisation

Classes d ’analyse Diagrammes de classes
 Responsabilités Diagrammes de collaboration
 attributs
 associations
63 64
 Analyse Analyse
Modèle d’Analyse vs Modèle
des cas d’utilisation Classes d’Analyse
Modèle des cas d ’utilisation Modèle d ’analyse
• Formulé dans le langage du
• classes candidates à partir des descriptions des
• Formulé dans le langage du UC
client
développeur
• Structure la vue externe du • 3 types de classes :
• Structure la vue interne du
système
système • Classes entité
• Structuré avec les cas
• Structuré avec des paquetages • classes données du système (durée de vie plus longue que celle
d ’utilisation
et des stéréotypes des UC)
• Contrat entre le client et les
• Indication aux développeurs
développeurs : ce que le
de la forme du système (pour
• Classes frontière
système doit faire et ne pas • interfaces entre acteur et système
conception et implémentation)
faire • Classes contrôle
• Esquisse une réalisation des
• Exprime les caractéristiques
caractéristiques du système • encapsulent le comportement d ’un UC
du système

65 66

Classes d’analyse :
Analyse
Classes d’analyse : Analyse

Classes Entités Classes Frontières

• informations dont la durée de vie dépasse celle des UC
• méthodes pour manipuler ces informations
• s’identifient en structurant judicieusement les informations
impliquées dans chaque UC en classes et attributs
• pas trop nombreuses (utiliser les UC, les autres sources
servent pour confirmation)
• apparaissent couramment dans plusieurs UC
• Les responsabilités et attributs différent d ’un UC à l ’autre
• Une fois l ’ensemble de classes de chaque UC identifié, on
peut les combiner
67
• connectent les autres classes du système à un acteur
• convertit les entrées des acteurs en événements ou en messages internes
• transforme les messages de sortie pour qu ’ils soient compris des acteurs
• des parties d ’un UC deviendront le comportement interne de la classe
frontière
• Etapes du UC qui dépendent du type d ’interface
• conversion d ’information
• fonctionnalités qui changent si l ’interface utilisateur change
• identification dans le cas d ’acteur humains: souvent une IHM
• on ne modélise la classe frontière qu’au niveau des événements internes
au système
• Ne pas confondre classe frontière et acteur
• les objets d ’entrée-sortie font partie du système
• les acteurs sont des objets extérieurs au système qui manipulent les
objets d ’entrée-sortie
• Si le système nécessite de contenir des informations concernant les
acteurs, on utilise une classe Entité, et on la nomme en conséquence
(DétailsClient) 68
 Analyse Analyse
Classes d’analyse : Description des classes
Classes Contrôle d’analyse

• Contiennent un scénario de UC • Mettre à jour les spécifications des classes et de leurs

• liaison entre interface et objets entité attributs au fur et à mesure que le modèle évolue

• Les objets de contrôle ont une durée de vie
égale à celle du UC
• Les UC simples n’ont pas besoins de classe
contrôle
• on place le comportement dans les classes entité et
frontière
• Rôle de la classe par rapport au problème
• Détails de la vie des objets
• Responsabilités des classes décrites plus tard, une fois la
réalisation des UC terminée
• Chaque attribut est documenté

69 70

Analyse Analyse
Réalisation des cas Réalisation des cas
d’utilisation (1) d’utilisation (2)

• Construire la réalisation des UC • Une fois les classes identifiées et

• créer les diagrammes de collaboration et des décrites pour chaque UC, elles sont
descriptions de flux d’événements utilisées pour réaliser les cas
• Générer des diagrammes de classe pour d ’utilisation
chaque UC • analyse du UC dans le comportement et la
• trouver les associations entre classes structure
nécessaires à chaque réalisation de UC • à partir des diagrammes de collaboration et de
classe

71 72
 Analyse Analyse
Réalisation des cas Réalisation des cas
d’utilisation (3) d’utilisation (4)

• Les diagrammes d’interactions sont • Les diagrammes de classes sont basés

basés sur l’analyse des interactions sur l ’analyse des classes
• instances des acteurs, les objets de l ’analyse et • classes, associations et attributs impliqués dans
les liaisons impliquées dans un UC particulier un UC donné
• Ils montrent la séquence d’événements entre
objets dans des scénarii de UC
• Le comportement est décrit dans les description
des UC

73 74

Analyse Analyse

Analyse des interactions Analyse des classes

• Les diagrammes de collaboration • L’analyse de classes est l ’étape du processus

montrent les interactions entre objets
• acteurs, objets et liaisons
• Séquences numérotées de messages qui se
propagent entre les objets pour réaliser le UC
qui attache les diagrammes de classes à
chaque réalisation de UC
• classes, attributs et associations
• identification et documentation des responsabilités de
chaque classe

• En analyse, on utilise les stéréotypes des
classes d ’analyse (entité, frontière et contrôle)
• Les classes et leurs instances apparaissent
souvent dans plusieurs réalisations de UC
• Elles ont alors des responsabilités, attributs et
associations propres à chaque UC

75 76
 Analyse Analyse
Identification des
responsabilités Identification des propriétés
• Pour chaque classe, trouver les • Ajouter les attributs et leurs types aux
réalisations de UC où elles apparaît classes
• lister les responsabilités (permet de choisir les • souvent trouvés lors de l’identification des
méthodes et signatures)
classes
• chaque flèche qui arrive à un objet de la classe
invoque une partie des responsabilités de cette • lister et décrire chaque attributs à partir de
classe chaque réalisation de UC
• cf diagrammes d’interactions (collaborations et
séquences)

77 78

Analyse Analyse

Identification des propriétés Identification des relations

• Remarques :
• les attributs des classes qui s’interfacent à des
humains sont souvent des champs de données
comme ceux des boîtes de dialogue
• les attributs de classes qui s ’interfacent à des
équipements sont souvent des valeurs ou les états
de capteurs, ou les paramètres d’un protocole de
communication
• les attributs des classes contrôle sont des données
temporaires de UC
• Observer les liaisons dans les
diagrammes de collaboration :
• chaque liaison peut être une instance d ’une
association sous-jacente
• elle peut même dans certains cas impliquer une
agrégation ou une généralisation

79 80
 Analyse Analyse

Identification des relations Diagramme de classes

• Toutes les liaisons du diagramme ne sont • Une association est une référence entre deux
pas des associations classes, utiliser :
• les descriptions de UC et les descriptions de scénarios
• certaines peuvent être temporaires
• les diagrammes d ’interaction
• Créer un diagramme de classe contenant • la modélisation métier
les classes, les associations et les • Les associations doivent être documentées dans
attributs pertinents pour chaque les descriptions des réalisations des UC
réalisation de use-case

81 82

Analyse Conception

Diagramme de classes Modèle de Conception

• Types d’association : Modèle de conception
• association
• connexion logique de longue durée entre 2 classes * *
Sous-système de conception
• associations les plus importantes, elles permettent de trouver
toutes les relations entre les classes et donc construisent le
modèle de classe
• une association temporaire Interface
• elle n ’existe que pour qu’une classe envoie un message
spécifique à une autre
Classes de conception Réalisation de cas d ’utilisation
• type d ’association rencontrée très souvent dans les descriptions
 méthodes Diagrammes de classes
de UC
 visibilités des attributs Diagrammes de séquences
• trouver les associations statiques sous-jacentes.

83 84
 Conception
Modèle d’analyse vs
Modèle de conception Sommaire
Modèle d ’analyse Modèle de conception
Objectifs d’un processus d’ingénierie logicielle

Modèles UML (rappels)
• Modèle conceptuel • Modèle physique
Processus de développement « Unifié »
• Autorise plusieurs • Spécifique à une

Principes
conceptions implantation
• Peu de stéréotypes de • Stéréotypes dépendant de
Recueil des besoins, Analyse, Conception
classes l’environnement cible
Utilisation des diagrammes
• Peu de couches d’implantation
Processus piloté par les cas d’utilisation
• Plusieurs couches
Processus centré sur l’architecture

Processus guidé par les Patterns

85 86

Utilisation des diagrammes (1) Utilisation des diagrammes (2)

utilise Diagrammes Diagrammes
Modèles des cas d’utilisation Modèles des cas d’utilisation
Use Case Use Case
Diagrammes Diagrammes Diagrammes Diagrammes
Objets utilise Objets
Modèles de Classes Modèles de Classes
d’Analyse Diagrammes d’Analyse Diagrammes
utilise de Composants de Composants
Modèles de Modèles de utilise
Diagrammes Diagrammes
Conception de déploiement
Conception de déploiement
utilise
utilise
Modèles de Diagrammes Modèles de Diagrammes
Déploiement de Séquences Déploiement de Séquences
utilise
utilise Diagrammes Diagrammes
Modèles de collaboration Modèles de collaboration
D’implémentation Diagrammes D’implémentation utilise Diagrammes
Etat-transiition Etat-transiition
Modèles Modèles
de test Diagrammes de test Diagrammes
d’activité 87 d’activité 88
 Utilisation des diagrammes (3) Utilisation des diagrammes (4)
Diagrammes Diagrammes
Modèles des cas d’utilisation Modèles des cas d’utilisation
Use Case Use Case
Diagrammes Diagrammes Diagrammes Diagrammes
Modèles de Classes Objets Modèles de Classes Objets
utilise
d’Analyse Diagrammes d’Analyse Diagrammes
de Composants de Composants
Modèles de Modèles de
Diagrammes Diagrammes
Conception de déploiement
Conception utilise de déploiement
utilise
Modèles de Diagrammes Modèles de utilise Diagrammes
utilise de Séquences de Séquences
Déploiement Déploiement
utilise Diagrammes Diagrammes
utilise
Modèles de collaboration Modèles de collaboration
D’implémentation utilise Diagrammes D’implémentation Diagrammes
Etat-transiition Etat-transiition
Modèles Modèles
de test Diagrammes de test Diagrammes
d’activité 89 d’activité 90

Utilisation des diagrammes (5) Utilisation des diagrammes (6)

Diagrammes Diagrammes
Modèles des cas d’utilisation Modèles des cas d’utilisation
Use Case Use Case
Diagrammes Diagrammes Diagrammes Diagrammes
Modèles de Classes Objets Modèles de Classes Objets
d’Analyse Diagrammes d’Analyse utilise Diagrammes
de Composants de Composants
Modèles de Modèles de
Diagrammes Diagrammes
Conception de déploiement
Conception de déploiement
utilise
Modèles de Diagrammes Modèles de Diagrammes
utilise de Séquences de Séquences
Déploiement Déploiement utilise
Diagrammes Diagrammes
Modèles de collaboration Modèles de collaboration
utilise
D’implémentation Diagrammes D’implémentation utilise Diagrammes
Etat-transiition Etat-transiition
Modèles Modèles utilise
de test Diagrammes de test Diagrammes
d’activité 91 d’activité 92
 Processus piloté par les cas
Sommaire d’utilisation (1)
Phases
Workflows Ingénierie Pré-étude Elaboration Construction Transition

Objectifs d’un processus d’ingénierie logicielle Modélisation Métier

Modèles UML (rappels) Recueil des besoins

Analyse & Conception

Processus de développement « Unifié » Implémentation
• les analystes identifient la

Principes Test plupart des UC pour

Recueil des besoins, Analyse, Conception Déploiement délimiter le système, et

Utilisation des diagrammes Workflows Support détaillent les plus

Processus piloté par les cas d’utilisation Configuration Mgmt
importants

Processus centré sur l’architecture Management
Environment

Processus guidé par les Patterns Preliminary Iter. Iter. Iter. Iter. Iter. Iter. Iter.
Iteration(s) #1 #2 #n #n+1 #n+2 #m #m+1

Iterations
93 94

Processus piloté par les cas Processus piloté par les cas
d’utilisation (2) d’utilisation (3)
Phases Phases
Workflows Ingénierie Pré-étude Elaboration Construction Transition Workflows Ingénierie Pré-étude Elaboration Construction Transition

Modélisation Métier Modélisation Métier

Recueil des besoins Recueil des besoins
Analyse & Conception Analyse & Conception
Implémentation
• les analystes trouvent les Implémentation • le reste des UC est
Test UC restant (objectif : Test exprimé et implémenté
Déploiement 80%) et les décrivent pour Déploiement
Workflows Support estimer l ’effort de Workflows Support
Configuration Mgmt Configuration Mgmt
Management
développement en fin de Management
Environment phase Environment
Preliminary Iter. Iter. Iter. Iter. Iter. Iter. Iter. Preliminary Iter. Iter. Iter. Iter. Iter. Iter. Iter.
Iteration(s) #1 #2 #n #n+1 #n+2 #m #m+1 Iteration(s) #1 #2 #n #n+1 #n+2 #m #m+1

Iterations Iterations
95 96
Processus piloté par les cas Processus piloté par les cas
d’utilisation (4) d ’utilisation (5)
Phases
Workflows Ingénierie Pré-étude Elaboration Construction Transition
Modèle
Modélisation Métier des cas
Recueil des besoins d’utilisation
spécialisé par
Analyse & Conception
Modèle réalisé par
Implémentation • sauf changement, d’Analyse
Test aucun UC ne doit Modèle de
distribué par
Déploiement
rester à découvrir Conception réalisé par
Workflows Support
Modèle de vérifié par
Configuration Mgmt
Déploiement
Management
Modèle
Environment d ’implantation
Preliminary Iter. Iter. Iter. Iter. Iter. Iter. Iter.
Iteration(s) #1 #2 #n #n+1 #n+2 #m #m+1 Modèle de
Iterations • Les cas d ’utilisation sont le fil Test

97
conducteur de toutes les activités 98

Processus piloté par les cas Processus dirigé par les cas
d ’utilisation (6) d ’utilisation (7) : org. travail

• Découpage et organisation du travail selon

les cas d ’utilisation :
Analyse Conception et Test
Réalisation

Les cas d ’utilisations relient ces tâches ensemble

Architectes
Experts du domaine Concepteurs Intégrateurs et
Programmeurs testeurs

99 100
 Processus dirigé par les cas
d ’utilisation (8) : conclusion
• Les cas d'utilisation recentrent l'expression des besoins
sur les utilisateurs
• Outil d ’aide à l ’identification et à la structuration des
besoins. On structure la démarche par rapport aux
interactions d'une seule catégorie d'utilisateurs à la fois.
• Outil d ’aide à l ’analyse et à la conception objet. On
s ’intéresse à un ensemble de classes qui collaborent dans
un certain contexte (celui du cas d ’utilisation)
• Description de la structure de la collaboration
• Description du comportement de la collaboration
• Outil de communication
Sommaire

Objectifs d’un processus d’ingénierie logicielle

Modèles UML (rappels)

Processus de développement « Unifié »

Principes

Recueil des besoins, Analyse, Conception

Utilisation des diagrammes

Processus piloté par les cas d’utilisation

Processus centré sur l’architecture

Processus guidé par les Patterns

101 102

Processus centré sur Processus centré sur (1)

l’architecture (1) l ’architecture : moyens UML
La description de l ’architecture est explicite. C ’est un artefact
• Recherche de la forme générale du système du processus
dès le début, Les choix d ’architecture sont pris très tôt dans le processus
La notion de paquetage permet d’organiser la spécification
• Approche systématique pour trouver une Forte cohésion
« bonne » architecture qui soit : Faible couplage
Notion de couches
• support des cas d ’utilisation, Composition de paquetages
• adaptable aux changements,
• pour et avec la réutilisation, Couche application

• compréhensible intuitivement.
Couche service
103 104
 Processus centré sur (2) Processus centré sur (3)
l ’architecture : moyens UML l ’architecture : moyens UML
• Des diagrammes spécifiques • R1 : les packages stéréotypés ou non peuvent se décomposer en
packages et/ou classes,
• Diagramme de déploiement • R2 : un package contient une classe d ’interface modélisant les services
• nœuds physiques et connexions offerts,
• Diagramme de composants • R3 : une classe d ’interface représente l ’ensemble des méthodes et
• composants logiciels et dépendances d ’attributs publics fournis par les classes du package,
• fichier,table de base de données, exécutable, librairie de fonctions, • R4 : les packages actifs contiennent au moins une classe active,
document • R5 : une classe active a un comportement propre, elle est décrite par
• Respect de règles d ’architecture et structuration un diagramme d ’états/transitions, et elle fournit des méthodes
contraintes,
des modèles à tous les niveaux du processus. • R6 : une méthode est contrainte par un protocole (synchrone,
asynchrone, …) ou un état interne (géré par une machine à états).

105 106

Processus centré sur Processus centré sur (3)

l ’architecture (2) l ’architecture : vue logique
• Abstraction et encapsulation,
• Modélisation des éléments et mécanismes
• Plusieurs manières de voir un système : principaux du système,
• Expression des aspects statiques et dynamiques
• Utilisation :
Vue
Vue logique
logique Vue des
Vue des processus
processus • diagrammes d ’objets et de classes
• diagrammes de collaborations
Vue des cas • interactions,
d ’utilisation • paquetages « catégories »
Vue de
Vue de réalisation
réalisation Vue
Vue de
de déploiement
déploiement

107 108
 Processus centré sur (4) Processus centré sur (5)
l ’architecture : vue réalisation l ’architecture : vue processus
• Identification des modules qui réalisent les classes • Importante dans les environnements multi-tâches,
de la vue logique, • Décomposition en flots d ’exécution et
• Organisation des modules dans l ’environnement synchronisation entre ces flots,
de développement
• Eléments manipulés :
• Eléments manipulés :
• tâches
• modules,
• sous-programmes, • threads,
• tâches (en tant qu ’unités de programme) • processus,
• paquetage « sous-systèmes » • interactions.

109 110

Processus centré sur (6) Processus centré sur (7)

l ’architecture : vue déploiement l’architecture : vue Use Case
• Importante dans les environnements • Besoins des utilisateurs, justification de
distribués, l ’architecture,
• Ressources matérielles et l ’implantation • Colle entre les autres vues
(distribution) du logiciel dans ces ressources, • Eléments manipulés :
• Eléments manipulés : • acteurs,
• nœuds, • cas d ’utilisation,
• modules, • classes,
• programmes principaux. • diagrammes de collaboration.

111 112
 Processus centré sur
l ’architecture (10)
Classes, Objets,
Collaboration, Séquences
Vision Logique
Utilisateus finaux
Fonctionalités
Etats-Transitions
Activité
Vision Processus
Intégrateurs système
Performance
Changement d’échelles
Throughput
Composants
Vision Implémentation
Cas d ’utilisation Programmeurs
Gestion du logiciel
Vision
cas d’utilisation Déploiement
Vision Déploiement
Ingénieur système
Topologie du système
Installation
Communication
Sommaire

Objectifs d’un processus d’ingénierie logicielle

Modèles UML (rappels)

Processus de développement « Unifié »

Principes

Recueil des besoins, Analyse, Conception

Utilisation des diagrammes

Processus piloté par les cas d’utilisation

Processus centré sur l’architecture

Processus guidé par les Patterns

Conceptuel Physique
115 116

Processus guidé par les Processus guidé par les

« patterns » (1) « patterns » (2)
La notion de patron (ou « pattern ») Le « composite pattern »

Nom_du_Pattern Le nom « Composite Pattern »

Un problème
récurrent de Le problème Représenter des objets complexes
conception O.O.
• Construction récursive de hiérarchies
Une solution exprimée Les bénéfices • Considérer de manière homogène les nœuds
en UML simples et complexes
Les bénéfices * Element
Les « bonnes » pratiques, les « bonnes » solutions
La solution
La plupart des patrons visent la réutilisabilité et
l ’extensibilité Objet- Objet-
Un moyen de transférer des compétences 117 complexe simple 118