Upload
mejdidallel
View
30
Download
0
Embed Size (px)
DESCRIPTION
Cours Projet de Conception OO - Mouna AYARI (1)
Citation preview
Cours: Projet de Conception Orientée ObjetObjet
Licence Fondamentale en InformatiqueLicence Fondamentale en InformatiqueNiveau: 3ème année – 1er semestre
Institut Supérieur d’Informatique et de Mathématiques de Monastir
Année universitaire: 2012 - 2013
Mouna AYARIMouna [email protected]
1Remarque: Ce document doit être complété par les notes de cours !
Objectifs du coursObjectifs du cours
Aider les étudiants à bien assimiler les principes Aider les étudiants à bien assimiler les principes fondamentaux de l’analyse et de la conception orientée objetobjet
Acquérir les compétences nécessaires de modélisation d’un logiciel objet à l’aide de la notation UML et traduire g jle modèle dans un langage Objet
Développer les compétences des étudiants à créer des logiciels bien conçus, robustes et réutilisables
Bien assimiler la démarche de la méthodologie fprocessus unifié et ses dérivés
Introduire la conception architecturale, la notion de t t l t d ti
2
composant et les patrons de conception
Plan du coursPlan du cours
Ch it 1 R l l f d t d b d Chapitre 1: Rappels sur les fondements de base de la conception orientée objet d’un projet
Chapitre 2: Méthodologies de COO – processus unifiéunifié
Chapitre 3: Conception architecturaleC ap t e 3 Co cept o a c tectu a e
3
BibliographieBibliographie
Pascal Roques, "les Cahiers du Programmeur UML2 q , gModéliser une application web",Edition EYROLLES, 4ème édition, 2008
Pascal Roques, "UML2 par la pratique Etudes de cas et exercices corrigés", Edition EYROLLES, 5ème édition, g2006
Antonio Goncalves "les Cahiers du Programmeur Java Antonio Goncalves, les Cahiers du Programmeur Java EE5",Edition EYROLLES, Mai 2007
4
Chapitre 1 Chapitre 1 Rappels sur les fondements de base de la
éconception orientée objet d’un projet
Licence Fondamentale en InformatiqueLicence Fondamentale en InformatiqueNiveau: 3ème année – 1er semestre
Institut Supérieur d’Informatique et de Mathématiques de Monastir
Année universitaire: 2012 - 2013
Mouna AYARIMouna [email protected]
5Remarque: Ce document doit être complété par les notes de cours !
Plan du chapitrePlan du chapitre
Etude préalable de projet Etude préalable de projet Analyse du système et spécification des exigences
du projetdu projet Fondements de base de la conception orientée
objetobjet Modélisation des relations entre les classes
R l l di d déli ti UML Rappel sur les diagrammes de modélisation UML
6
Chapitre 1 Rappels sur les fondements de base de la conception orientée objet d’un projetRappels sur les fondements de base de la conception orientée objet d un projet
1.1. Etude préalable de projet
Licence Fondamentale en InformatiqueLicence Fondamentale en InformatiqueNiveau: 3ème année – 1er semestre
Institut Supérieur d’Informatique et de Mathématiques de Monastir
Année universitaire: 2012 - 2013
Mouna AYARIMouna [email protected]
7Remarque: Ce document doit être complété par les notes de cours !
Avant-projetAvant projet
L’étape d’avant-projet représentej l’étape initiale de tout projet. Elle est appelée également étape d’ Étude préalable du projet Phase d’inception du projet
l'ensemble des étapes préparatoires nécessaires au lancement du projetprojet
Etude préalable du
Lancer le projet
Idée du projetprojet
Abandonner le projet
8
p
Avant-projetAvant projet
Avant-projetp j Il s'agit de définir précisément ce que sera le projet afin
d'aboutir à la mise au point de documents contractuels (faisant lieu d'un contrat) permettant d'engager la maîtrise d'œuvre (responsables de gestion et suivi projet) et la maîtrise d'ouvrage (responsables des activités techniques du projet)d ouvrage (responsables des activités techniques du projet) dans le lancement du projet
Cette phase formalise donc la décision de commencer le pprojet.
9
Etude préalable du projetEtude préalable du projet
L’étude préalable d’un projet intervient avant la phase jd’expression des besoins
La plupart des projets nécessitent un stade initial au cours d l il f t é d à t i tiduquel il faut répondre à certaines questions Quelle est la vision (objectif et contexte) du projet et quelle est
son opportunité?pp Le projet est-i-il réalisable? Faut-il construire et/ou acheter ? Quelle est l’estimation grossière du coût: doit-on envisager des
dizaines de milliers, des centaines de milliers ou des millions de dinars?
Faut-il poursuivre jusqu’à la réalisation du projet ou renoncer?
10
Etude préalable du projetEtude préalable du projet
A l’étape d’avant-projet ou étude préalable du projet, il faut j jétudier quelques peu les besoins. Mais, cette étape n’a pas pour but de définir tous les besoins et élaborer un plan de projetprojet
L’idée est d’effectuer le minimum d’investigations pour formuler une opinion rationnelle et justifiable de la finalité et p jfaisabilité du projet et du nouveau système potentiel associé
L’objectif de cette phase est de décider s’il est raisonnable d’investir dans une étude plus
approfondie (l’objectif de la phase d’élaboration du projet) établir une vision initiale comme des objectifs du projet deétablir une vision initiale comme des objectifs du projet, de
déterminer si celui-ci est faisable (tenant compte des ressources disponibles) ét di l t t d j t t ét bli ti ti
11
étudier le contexte du projet et établir ses motivations
Etude préalable du projetEtude préalable du projet
L’étude préalable permet donc d'identifier les conditions de développement de ces activités : Étude des marchés des produits et services,
Vi bilité t h i é i d j t Viabilité technico-économique du projet, Compétences disponibles/requises, Outils et moyens de financement de l'activité, y , Impact social ...
12
Etude préalable du projetEtude préalable du projet
Etude de marché et de l’existant L’étude préalable consiste principalement à recenser
l’existant c'est-à-dire les solutions informatiques déjà mises en œuvre dans l’entreprise et à recenser les besoins notamment en termes de fonctionnalités nouvelles.
Elle comprend également l’étude des applications similaires Elle comprend également l étude des applications similaires sur le marché
Elle peut être l’occasion d’une étude de rentabilité du projet.
L'étude préalable identifie les contraintes budgétaires, les contraintes d'environnement et les contraintes juridiquescontraintes d'environnement et les contraintes juridiques.
13
Etude préalable du projetEtude préalable du projet
Remarquesq La phase d’étude préalable est relativement courte. Elle ne
dépasse pas généralement quelques semainesD d b j t i tt h dé Dans de nombreux projets si cette phase dépasse une semaine, c’est un signe que son objectif n’a pas été bien compris. Il s’agit de décider si le projet mérite une étude sérieuse ou non
Si la décision de réaliser le projet a été déjà prise et si sa faisabilité est évidente la phase d’étude préalable serafaisabilité est évidente, la phase d étude préalable sera particulièrement brève
La phase d’étude préalable peut inclure un certain volume de programmation destinée à créer des prototypes (interfaces utilisateur) afin d’expliquer et mieux illustrer un certain nombre de besoins
14
Chapitre 1 Rappels sur les fondements de base de la conception orientée objet d’un projetRappels sur les fondements de base de la conception orientée objet d un projet
1.2. Analyse du système et spécification des exigences du projetspécification des exigences du projet
Licence Fondamentale en InformatiqueLicence Fondamentale en InformatiqueNiveau: 3ème année – 3ème semestre
Institut Supérieur d’Informatique et de Mathématiques de Monastir
Année universitaire: 2012 - 2013
Mouna AYARIMouna [email protected]
15Remarque: Ce document doit être complété par les notes de cours !
16
Spécification des besoins/exigencesSpécification des besoins/exigences
Démarche
17
Modèle de cas d’utilisationModèle de cas d utilisation
Démarche identifier les acteurs,
id tifi l d’ tili ti identifier les cas d’utilisation,
structurer les cas d’utilisation en packages,
ajouter les relations entre cas d’utilisation,
finaliser un ou plusieurs diagramme(s) de casfinaliser un ou plusieurs diagramme(s) de cas d’utilisation par paquetage (package)
18
Modèle de cas d’utilisationModèle de cas d utilisation
19
Spécification d’un cas d’utilisationSpécification d un cas d utilisation
Cas d’utilisation Acteur principal [Acteurs secondaires][ ] Objectifs Préconditions Post-conditions Scénario nominal Alternatives Exigences supplémentaires
20
Spécification d’un cas d’utilisationSpécification d un cas d utilisation
Préconditions définissent ce qui doit être vrai en amont du cas
d’utilisation pour que celui-ci puisse démarrer Certaines préconditions triviales n’ont pas besoin
d’être mentionnées (exp. Le système doit être li é él i )alimenté au courant électrique)
Post-conditions Définissent ce qui doit être vrai lorsque le cas
d’utilisation se termine avec succès, qu’il s’agisse d’un é i i l d’ é i lt tifscénario nominal ou d’un scénario alternatif
21
Relations entre cas d’utilisationRelations entre cas d utilisation
Relation d’inclusion formalisée par le mot-clé « include » p Le cas d’utilisation de base en incorpore explicitement un
autre, de façon obligatoire Relation d’extension, formalisée par le mot-clé «
extend » Le cas d’utilisation de base en incorpore implicitement un
autre, de façon optionnelle R l ti d é é li ti / é i li ti Relation de généralisation/spécialisation Les cas d’utilisation descendants héritent de la description
de leur parent commun Chacun d’entre eux peutde leur parent commun. Chacun d entre eux peut néanmoins comprendre des interactions spécifiques supplémentaires
22
Chapitre 1 Rappels sur les fondements de base de la conception orientée objet d’un projetRappels sur les fondements de base de la conception orientée objet d un projet
1.3. Fondements de base de la COO
Licence Fondamentale en InformatiqueLicence Fondamentale en InformatiqueNiveau: 3ème année – 3ème semestre
Institut Supérieur d’Informatique et de Mathématiques de Monastir
Année universitaire: 2012 - 2013
Mouna AYARIMouna [email protected]
23Remarque: Ce document doit être complété par les notes de cours !
Fondements de base de la COOFondements de base de la COO
Introduction
Rappel sur l’approche orientée objet
Principes de l’orientée objets
24
IntroductionIntroduction
Approche fonctionnelle:pp La modélisation est réalisée à partir de fonctions que doit
réaliser le système
Approche orientée objet : On identifie les objets manipulés par le système avec leurs On identifie les objets manipulés par le système, avec leurs
états et leurs comportements
L’idée est connue depuis 1976 L idée est connue depuis 1976
Programmation orientée objet : 1980, version industrielle de SmallTalkSmallTalk
Langages de programmation : Ada, C++, Java
25
IntroductionIntroduction
26
IntroductionIntroduction «Posséder un marteau ne fait pas de vous un architecte»!
Connaître un langage de programmation orientée objet est-il suffisant pour maîtriser la conception et le développement orientés objet? Evidemment non, connaître un langage orienté objet (par exemple
java) est nécessaire mais n’est pas suffisant pour créer un système à objets. Il faut savoir « PENSER en objets »!
UML t l é bj t UML et la « pensée objet » UML: Unified Modeling Langage C’est:
Une notation, un langage de modélisation objet Une description complète, évolutive, publique Un standard utilisé par des AGL (Atelier de Génie Logiciel) Un standard, utilisé par des AGL (Atelier de Génie Logiciel)
Ce n’est pas : Une méthodologie d’analyse ou de conception orientée objet
27
IntroductionIntroduction
Très Important!p C’est inutile d’apprendre un langage de programmation orientée objetd apprendre un langage de programmation orientée objet d’apprendre UML ou un outil de génie logiciel
Si vous n’êtes pas en mesure deSi vous n êtes pas en mesure de Élaborer une excellente conception orientée objet Améliorer une conception existantep
La compétence de « penser et concevoir en objet » p p jest la plus importante et la plus difficile à acquérir
28
IntroductionIntroductionAnalyse versus Conception
L’analyse met l’accent sur une investigation du problème et des besoins plutôt que sur la recherche d’une solution
La conception: sous-entend l’élaboration d’une solution
conceptuelle répondant à besoins plutôt que la
Analyse: Qu’est ce qu’on désire développer?
p p p qmise en œuvre de cette solution
Exclut souvent les détails de bas niveau
Description d’un schéma conceptuel d’objets Quelles sont les fonctions du système?
Spécifier le bon système à construire
Le terme analyse est vaste:
p p jlogiciel et de base de données
La conception se résume au terme: « bien construire un système » Le terme analyse est vaste:
Analyse des besoins (spécification des besoins)
construire un système »
Conception: Conception orientée objet/composant
Analyse orientée objet (spécification et investigation des objets du système)
Conception de la base de données
Conception graphique
29
Rappel sur l’approche orientée objetRappel sur l approche orientée objet
Approche orientée objetsj Privilégier une approche architecturale pour implémenter des
solutions à des problèmes plutôt qu’une approche fonctionnelle visant à résoudre un problème posévisant à résoudre un problème posé
Notion d’ObjetDéfi iti Définition Un objet définit une représentation d’une entité atomique réelle
ou virtuelle dans le but de le piloter ou de le simuler Les objetsou virtuelle, dans le but de le piloter ou de le simuler. Les objets encapsulent une partie des connaissances du monde dans lequel ils évoluent.
Un objet associe données et traitements en ne laissant visible que l’interface de l’objet, c’est à dire les traitements que l’on peut faire dessus
30
peut faire dessus
Rappel sur l’approche orientée objetRappel sur l approche orientée objet
Obj t Id tité Et t C t t Objet = Identité + Etat + Comportement L’Identité : En plus de son état un objet possède une identité qui
permet de le distinguer de manière non ambiguëpermet de le distinguer de manière non ambiguë indépendamment de son Etat.
L’état : regroupement des valeurs instantanées de tous les attributs d’un objet
Le comportement : regroupe toutes les compétences d’un objet (méthodes) et décrit les actions et les réactions de cet objet(méthodes) et décrit les actions et les réactions de cet objet
Objet Un objet possède un état et réagit selon un comportement Un objet possède un état et réagit selon un comportement L’état évolue au cours du temps, en fonction du comportement Les objets échanges des messages
31
Rappel sur l’approche orientée objetRappel sur l approche orientée objet Notion de classe La classe décrit le domaine de définition d’un ensemble
d’objets : C’est un modèle qui définit les données et les traitements communs à une collection d’objets similaires
Chaque objet appartient à une classe Classe : regroupement d ’objets de même type. L’objet est une instance de sa classej
Terminologie orientée objet Les traitements sont appelés méthodes de l’objet Les traitements sont appelés méthodes de l objet Les données sont appelées variables, données membres,
attributs ou propriétésL bj t i f ti t t it à ti d l Les objets informatiques sont construits à partir de la classe par un processus appelé instanciation
Tout objet est instance d’une Classe
32
Rappel sur l’approche orientée objetRappel sur l approche orientée objet Objets
Ahmed, Ibrahim, Nesrine; université de Monastir, université de Sousse, université de Tunis 2
Classe : regroupement d ’objets de même type Classe : regroupement d objets de même type. Personne Université
Objet Classe
Ahmed : PersonnePersonne
Ahmed : Personne
25 ans
Age : intNom, Adresse : string25 ans
Ahmed Ben Foulen
40 rue de la Liberté, Monastir
g
SePrésenter()
Vieillir()
renvoie Nom
33
40 ue e a be té, o ast ()
ChangerNom(…) Age = Age+1
Rappel sur l’approche orientée objet
Les qualificatifs de classe (portée)
Rappel sur l approche orientée objet
Les qualificatifs de classe (portée) Publique : Les fonctions de toutes les classes peuvent accéder aux Les fonctions de toutes les classes peuvent accéder aux
données ou aux méthodes d'une classe définie avec le niveau de visibilité public. Il s'agit du plus bas niveau de protection des donnéesprotection des données.
Protégée : L’accès aux données est réservé aux fonctions des classes L accès aux données est réservé aux fonctions des classes
héritières, c'est-à-dire par les fonctions membres de la classe ainsi que des classes dérivées.
Privée : L'accès aux données est limité aux méthodes de la classe
elle-même Il s'agit du niveau de protection des données leelle même. Il s agit du niveau de protection des données le plus élevé.
34
Rappel sur l’approche orientée objetRappel sur l approche orientée objet
Les qualificatifs d’attribut
Publique : Un attribut publique pourra être accédé (lu et modifié) par tout le monde.) p
Protégée : Un attribut protégé pourra être accédé (lu et modifié) par les classes filles.modifié) par les classes filles.
Privée : Un attribut privée pourra être accédé (lu et modifié) par les méthodes et seulement les méthodes demodifié) par les méthodes et seulement les méthodes de sa classe.
35
Rappel sur l’approche orientée objetRappel sur l approche orientée objet
Les qualificatifs de méthode
Publique : Une méthode publique pourra être utilisée par tout le monde.p
Protégée : Une méthode protégée pourra être utilisée ou redéfinie par les classes héritièresutilisée ou redéfinie par les classes héritières.
Privée : Une méthode privée pourra être utilisée par les méthodes et seulement les méthodes de sales méthodes et seulement les méthodes de sa classe.
36
Principes de l’orientée objetPrincipes de l orientée objet
Objets :j Unités de base organisées en classes et partageant des
traits communs (attribut ou procédures). Entités du monde réel, des concepts de l’application ou du
domaine traité.E l ti Encapsulation : Les structures de données et les détails de
l’implémentation sont cachés aux autres objets dul implémentation sont cachés aux autres objets du système.
La seule façon d’accéder à l’état d’un objet est de lui La seule façon d accéder à l état d un objet est de lui envoyer un message qui va déclencher l’exécution de l’une de ses méthodes.
37
Principes de l’orientée objetPrincipes de l orientée objet
Encapsulationp L’occultation des détails de réalisation
Par défaut les valeurs des attributs d’un objets sontPar défaut les valeurs des attributs d un objets sont encapsulées dans l’objet et ne peuvent pas être manipulées directement par un autre objetD è l d i ibili é é i l i d’ l i Des règles de visibilité précisent la notion d’encapsulation assouplissement du degré d’encapsulation et de protection au
profit de certaines classes bien particulières (exp: classes p p ( pmères/filles, classes amies en C++)
intérêt : réduire le temps d’accès aux attributs Trois niveaux d’encapsulation : privé (-): attribut non vu de l’extérieur de l’objet protégé (#): attribut vu par des classes dérivées
38
protégé (#): attribut vu par des classes dérivées public (+): attribut visible pour toutes les classes
Principes de l’orientée objet -EncapsulationPrincipes de l orientée objet Encapsulation
Regroupement des attributs et des méthodesPersonne
Modularité :
Age : intNom, Adresse : string
protège les données d ’une utilisation erronée
cache les détails desSePrésenter()
cache les détails des méthodes
Vieillir()
ChangerNom(…)
Evolutivité, fiabilité
39
Principes de l’orientée objet - HéritagePrincipes de l orientée objet Héritage
Abstraction Il s'agit d'un processus qui consiste à identifier les
caractéristiques intéressantes d'une entité, en vue d'une utilisation préciseutilisation précise.
L'abstraction désigne aussi le résultat de ce processus, c'est-à-dire l'ensemble des caractéristiques essentielles d' tité t b td'une entité, retenues par un observateur.
Héritage : Héritage : Chaque instance d’une classe possède ses
caractéristiques (attributs+méthodes), mais aussi celles d’ é t ll l ( l è )d’une éventuelle super classe (classe mère).
Permet de décrire un type de lien qui unit les différents objets.
40
j
Principes de l’orientée objet - HéritagePrincipes de l orientée objet Héritage
Relation entre classes Oiseaux est un cas particulier de Animaux Animaux généralise Oiseaux
La classe fille hérite les attributs et les comportements
peut avoir des attributs et des méthodes nouvelles peut avoir des attributs et des méthodes nouvelles peut avoir un comportement modifié
Animaux
Reptiles Oiseaux
41
p
Principes de l’orientée objetPrincipes de l orientée objet
Modularité : Partition du programme qui crée des frontières bien
définies (et documentées) à l’intérieur du programme dans l’objectif d’en réduire la complexitédans l objectif d en réduire la complexité.
Polymorphisme : Polymorphisme : Possibilité de recourir à la même expression pour
dénoter différentes opérations. p L’héritage est une forme particulière de
polymorphisme caractéristique des systèmes orientés objetobjet.
42
Principes de l’orientée objet - PolymorphismePrincipes de l orientée objet - Polymorphisme
Exemplep Tout animal peut se déplacer Il le fait différemment s’il s’agit d’un oiseau ou d’un serpent
Animaux
SeDeplacer()SeDeplacer()
Reptiles Serpents
SeDeplacer(){
SeDeplacer(){
43
{en volant
}
{en glissant
}
Exercice d’applicationExercice d application
Quelles sont les caractéristiques d’une personne?
Quelles sont les comportements génériques d’une
personne?p
Pouvez vous donnez des exemples d’instances d’une
personne?
Donnez des exemples de sous classes Donnez des exemples de sous classes.
44
Solution de l’exercice d’applicationSolution de l exercice d application
45
Solution de l’exercice d’application (suite)Solution de l exercice d application (suite)
46
Principes de l’orientée objet
Trouver les bons objets
Principes de l orientée objet
Trouver les bons objets
Méthode de désagrégation / agrégation : Désagréger un module : {modules} Agréger un {modules} : un module
Désagrégation d’un module : On part d’un tout que l’on éclate en plusieurs parties. Chaque
ti f t à t t t t tibl d’êt àpartie formant à son tour un tout, est susceptible d’être à nouveau éclatée en parties plus petites.
Il est difficile d’exprimer en décomposition logicielle ce qu’est une tipartie.
En conception on fait l’hypothèse que le système est un tout et qu’il est composé de parties cohérentes séparables.
47
Principes de l’orientée objetPrincipes de l orientée objet
Trouver les bons objets
La décomposition est basée sur les entités du domaine du problème.
La désagrégation est très différente de la décomposition fonctionnelle car une fonctionnalité n’est pas une entité du domaine du problème.du domaine du problème.
La granularité de la taille des entités dépend du niveau d’abstraction.
48
Principes de l’orientée objetPrincipes de l orientée objet
Quelques règles d’écriture d’un module
Un module représente un concept et tout le concept. Ne pas regrouper dans un module des opérations Ne pas regrouper dans un module des opérations
qui n’ont pas de raison d’être ensemble Pour concrétiser une idée le choix du nom du Pour concrétiser une idée le choix du nom du
module est un élément puissant d’expression (patron de conception « Design Patterns »).
Phase simpliste : Le choix des méthodes correspond aux verbes.
49
Chapitre 1 Rappels sur les fondements de base de la conception orientée objet d’un projetRappels sur les fondements de base de la conception orientée objet d un projet
1.4. Modélisation des relations entre les classesclasses
Licence Fondamentale en InformatiqueLicence Fondamentale en InformatiqueNiveau: 3ème année – 1er semestre
Institut Supérieur d’Informatique et de Mathématiques de Monastir
Année universitaire: 2012 - 2013
Mouna AYARIMouna [email protected]
50Remarque: Ce document doit être complété par les notes de cours !
Modélisation des relations entre les classesModélisation des relations entre les classes
Exemple de modélisation d’une classeExemple de modélisation d une classe
Bonne pratique de manipulation des attributs
51
Modélisation des relations entre les classesModélisation des relations entre les classes
Association Dépendancep Agrégation/composition
Hé it Héritage Réalisation d’interface
52
Association entre classesAssociation entre classes
Notion d’association Une association est une relation entre deux classes association binaire
i ti i association n-aire Elle décrit les connexions structurelles entre leurs
instances Multiplicité d’une association Exemple InterprétationExemple Interprétation 1..1 ou 1Un et un seul 0..1 zéro ou un seul
0 * * é à l i 0..* ou * zéro à plusieurs 3..4 trois à quatre 4 quatre et seulement quatre
53
Modélisation d’une associationModélisation d une association
• Une association simple entre deux classes représente une relation structurelle entre pairs, p p pc’est à dire entre deux classes de même niveau conceptuel.
• Aucune des deux n’est plus importante que l’autre.
54
Modélisation d’une associationModélisation d une association Niveau d’implémentation L’association se manifeste par la présence de deux
attributs dans chacune des classes en relation C’est la manière dont une association est généralement g
implémentée dans un langage objet quelconque Terminaison d’association(Une terminaison d’association est une extrémité de l’association Une association binaire en(Une terminaison d association est une extrémité de l association. Une association binaire en possède deux, une association n-aire en possède n)
Un attribut peut être considéré comme une association dégénérée dans laquelle une terminaison d’association est dét l ( é é l t l )détenue par un classeur (généralement une classe).
Le classeur détenant cette terminaison d’association devrait théoriquement se trouver à l’autre extrémité, non modélisée, de l’associationl association.
Un attribut est une terminaison d’un cas particulier d’association Les terminaisons d’associations et les attributs sont deux
éléments conceptuellement très proches que l’on regroupe sous
55
éléments conceptuellement très proches que l on regroupe sous le terme de propriété
Modélisation d’une associationModélisation d une association
56
Association n-airesAssociation n aires
Une association n-aire lie plus de deux classesUne association n aire lie plus de deux classes
Si un cours doit pouvoir exister indépendamment d’un lien entre un enseignant et un groupe, ilfaut utiliser le modèle de droite
57
Dépendance entre classesDépendance entre classes
Une dépendance est une relation unidirectionnelle exprimant une dépendance sémantique entre des éléments du modèleéléments du modèle. Elle est représentée par un trait discontinu orienté On utilise souvent une dépendance quand une classe en utiliseOn utilise souvent une dépendance quand une classe en utilise
une autre comme argument dans la signature d’une opération
Un élément A dépend d'un élément B lorsque A utiliseUn élément A dépend d un élément B, lorsque A utilise des services de B Tout changement dans B peut avoir des répercussions sur A
58
Modélisation d’une dépendanceModélisation d une dépendance
Représentation UML p Un trait discontinu partant de la classe dépendante et pointant vers
la classe proposant les services sollicités, se terminant par une pointe de flèche ouverte (c'est ce qui la distingue de la relation depointe de flèche ouverte (c'est ce qui la distingue de la relation de réalisation)
Un contrat dispose d'un service d'impression (méthode impression), qui utilise une méthode (print), dont la spécification est
59
déclarée par l'interface (ou notamment la classe) Printer.
Modélisation d’une dépendanceModélisation d une dépendance
Exemple d’implémentationp pclass Contrat { ... public void impression() {
Printer imprimante = PrinterFactory.getInstance();... imprimante.print(client.getName());
}... } }
le lien entre un objet "contrat" et une "imprimante" est momentané. Il ne dure que le temps d'exécution de la méthode impression
L'imprimante n'a pas lieu d'être un attribut de la classe Contrat, et de ce fait, ce n'est pas une association, mais une simple dépendance
60
dépendance
Agrégation entre classesAgrégation entre classes
Une relation d’agrégationg g permet de modéliser une relation tout/partie où une classe
constitue un élément plus grand (tout) composé d’éléments plus petit (partie
représente une relation d’inclusion structurelle ou comportementale d’un élément dans un ensemble)comportementale d un élément dans un ensemble)
n’entraîne pas de contrainte sur la durée de vie des parties par rapport au tout
Multiplicité 1 .. 1 1 .. n 1 .. * 0 *
61
0 .. *
Modélisation d’une relation d’agrégationModélisation d une relation d agrégation
Représentation UMLp Graphiquement, on ajoute un losange vide () du côté
de l’agrégat
Exemple
62
Relation de compositionRelation de composition
Relation de compositionp La composition est également appelée agrégation
composite Elle décrit une contenance structurelle entre instances de
classes La destruction de l’objet composite implique la destruction La destruction de l objet composite implique la destruction
de ses composants
Une instance de la partie appartient toujours à au plus une Une instance de la partie appartient toujours à au plus une instance de l’élément composite La multiplicité du côté composite ne doit pas être supérieure à 1 p p p p
(i.e. 1 ou 0..1)
63
Modélisation d’une relation de compositionModélisation d une relation de composition
Représentation UMLp Graphiquement, on ajoute un losange plein (✦) du
côté de l’agrégat Exemple
64
Modélisation de agrégation/compositionModélisation de agrégation/composition
Exemplep
65
HéritageHéritage
Relation d’héritage ou de généralisation Relation d héritage ou de généralisation décrit une relation entre une classe générale (classe de base ou
classe parent) et une classe spécialisée (sous-classe) La classe spécialisée (fille) est intégralement cohérente avec la
classe de base, mais comporte des informations supplémentaires (attributs, opérations, associations)supplémentaires (attributs, opérations, associations)
RemarqueRemarque En modélisation UML, la relation d’héritage n’est pas propre
aux classes. Elle s’applique à d’autre éléments du langage comme les paquetages, les acteurs ou les cas d’utilisation.
66
Héritage entre classesHéritage entre classes Propriétés principales de l’héritage entre les classes: La classe fille possède toutes les caractéristiques des ses
classes parents. Une classe fille peut ne pas accéder aux caractéristiques Une classe fille peut ne pas accéder aux caractéristiques
privées de sa classe mère sauf si les attributs de cette dernière sont déclarés comme « protected »U l f t t défi i ( ê i t ) Une classe enfant peut redéfinir (même signature) une ou plusieurs méthodes de la classe parent.
Toutes les associations de la classe parent s’appliquent aux p pp qclasses dérivées.
Une classe peut avoir plusieurs parents, on parle alors d’héritage multipled héritage multiple. Le langage C++ est un des langages objet permettant son
implémentation effectiveLe langage Java ne permet pas l’héritage multiple
67
Le langage Java ne permet pas l héritage multiple
Modélisation d’une relation d’héritageModélisation d une relation d héritage
Représentation UML p Le symbole utilisé pour la relation d’héritage ou de généralisation
est une flèche avec un trait plein dont la pointe est un triangle fermé désignant le cas le plus généralfermé désignant le cas le plus général.
68
InterfaceInterface
Une interface est une entité dont toutes ses méthodes sont, par définition, abstraites regroupe un ensemble de propriétés et d’opérations assurant un
service cohérentservice cohérent
Réalisation d’une interface Une interface doit être réalisée (implémentée) par au moins une classe Une interface doit être réalisée (implémentée) par au moins une classe
(elle peut notamment être réalisée par plusieurs classes Une classe peut réaliser plusieurs interfaces
R é t ti UML Représentation UML Graphiquement, cela est représenté par un trait discontinu terminé par une
flèche triangulaire Notation simplifée :
Une interface peut être représentée par un petit cercle avec le nom de l'interface placé juste en dessous. Le cercle peut être attaché à une ou l i l d'i lé t ti
69
plusieurs classes d'implémentation.
Modélisation de la réalisation d’une interfaceModélisation de la réalisation d une interface
ExempleNotation simplifiéeNotation simplifiée
70
ExemplesExemples
71
ExemplesExemples
Relation de Relation de réalisation
(implémentation) Relation de dépendance
(implémentation)La classe enseignant réalise
l’interface
72
Exercice d’application 1Exercice d application 1 Dégager le diagramme de classes en représentation UML mettant en relief les
relations significatives entre classes décrites par l'extrait de code java suivantrelations significatives entre classes décrites par l extrait de code java suivant
73
Solution de l’exercice d’application 1Solution de l exercice d application 1
74
Exercice d’application 2Exercice d application 2 Etant donné le diagramme de classes suivant, déterminer la squelette du
code java correspondant
75
Solution de l’exercice d’application 2Solution de l exercice d application 2public interface Observer {
bli id d t (Ob bl bj)public class Observable {
public void update(Observable obj);}public class UIGraphe implements Observer {
...vector observateurs;…public void notify() {...
public void update(Observable o) { ...
}
p y() {...
}public void addObserver(Observer o) {
obser ate rs add(o)... }public class Bilan extends Observable {
observateurs.add(o);}…
}... void setChange() {
…}
}
}...
}
76
Chapitre 1 Rappels sur les fondements de base de la conception orientée objet d’un projetRappels sur les fondements de base de la conception orientée objet d un projet
1.5. Rappel sur les diagrammes de modélisation UMLmodélisation UML
Licence Fondamentale en InformatiqueLicence Fondamentale en InformatiqueNiveau: 3ème année – 1er semestre
Institut Supérieur d’Informatique et de Mathématiques de Monastir
Année universitaire: 2012 - 2013
Mouna AYARIMouna [email protected]
77Remarque: Ce document doit être complété par les notes de cours !
Rappel sur la modélisation UMLRappel sur la modélisation UML
Vocabulaire UML (Rappel)( pp )
78
Rappel sur la modélisation UMLRappel sur la modélisation UML
UML: Unified Modeling Langageg g g
C’est: C est: Une notation, un langage de modélisation objet Une description complète évolutive publique Une description complète, évolutive, publique Un standard, utilisé par des AGL
Ce n’est pas : Une méthodologie Une méthodologie
79
Diagrammes UMLDiagrammes UML
Diagramme UML
Diagramme structurel Diagramme comportemental
Vue statique Vue dynamique
80
Diagrammes UMLDiagrammes UML
81
Diagrammes UMLDiagrammes UML
Liens entre les diagrammesg
82
Chapitre 2 Méthodologies de COO –processus unifiéprocessus unifié
Licence Fondamentale en InformatiqueLicence Fondamentale en InformatiqueNiveau: 3ème année – 1er semestre
Institut Supérieur d’Informatique et de Mathématiques de Monastir
Année universitaire: 2012 - 2013
Mouna AYARIMouna [email protected]
Remarque: Ce document doit être complété par les notes de cours !83
Plan du chapitrePlan du chapitre
Introduction
P ifié U ifi d P (UP) Processus unifié: Unified Process (UP)
Rational Unified Process (RUP) Rational Unified Process (RUP)
2TUP (Two Track Unified Process)
84
IntroductionIntroduction
Pourquoi une méthodologie / processus? Le Processus Unifié Itération
Les itérations peuvent être regroupées en 4 phases Phases (création, élaboration, construction, transition)Phases (création, élaboration, construction, transition) Activités
Chaque itération consiste à enchaîner 5 activités :B i Besoins
Analyse Conception Implémentation Tests
85
Pourquoi une méthodologie / Processus?Pourquoi une méthodologie / Processus?
Les techniques (diagrammes d’UML) de Les techniques (diagrammes d UML) de développement de système doivent être organiséessi elles doivent fonctionner ensemble
UML même ne contient rien qui aide à prendre cette décision
86
Pourquoi une méthodologie / Processus?q g /
L'organisation des tâches n'est pas contenue dans les techniquestechniques
Elle doit être décrite à un plus haut niveau d'abstraction
Méthode ou processus d'un projet est la manière particulière avec laquelle les tâches dans ce projet sont p q p jorganisées
La méthodologie est encore plus abstraite : un méta- La méthodologie est encore plus abstraite : un méta-processus qui peut être appliqué à de nombreux projets
87
Processus Méthode ou Méthodologie?Processus, Méthode ou Méthodologie?
Souvent mélangé, comme s'il s'agissait de la même chose, mais ces termes diffèrent réellement
Méthode/Processus = description pas-à-pas des étapesimpliquées dans l'accomplissement d'une tâche particulière
Elle ne peut être la même pour deux projets différents, la méthode est spécifique à un projetméthode est spécifique à un projet.
Méthodologie = ensemble de principes généraux qui guident le choix d'une méthode adaptée à une tâche ouguident le choix d une méthode adaptée à une tâche ou projet spécifique
88
Pourquoi utiliser une méthodologie / Processus?Pourquoi utiliser une méthodologie / Processus?
De nombreux avantages sont avancésAide à produire un produit de meilleure qualité
L i i l i d té Logiciel mieux documenté Plus acceptable par l'utilisateur Plus facile à maintenir/entretenir Logiciel plus homogène
Aide à assurer que les spécifications des utilisateurs sont suiviessont suivies
Aide le manager du projet à contrôler le projetRéduit les coûts de développementRéduit les coûts de développementEncourage la communication entre les personnes
89
UML n'est qu'un langageUML n est qu un langage
Bien qu’issu d’une concertation visant à produire le processus Unifié, UML n'est qu'un langage de modélisationp , q g get non une méthodologie à part entière.
UML définit des notations utiles dans toutes les étapes duUML définit des notations utiles dans toutes les étapes du développement d'un logiciel, de l'analyse des besoins à la livraison de celui-ci, mais il ne propose aucune démarche spécifique pour mener ce développement à terme.
En ce sens, UML peut a priori être utilisé dans le cadre de l'utilisation de toute méthode de développements (par objets).
90
Chapitre 2Méthodologies de COO – processus unifiéMéthodologies de COO – processus unifié
2.1. Processus UnifiéUnified Process (UP)Unified Process (UP)
Licence Fondamentale en InformatiqueLicence Fondamentale en InformatiqueNiveau: 3ème année – 3ème semestre
Institut Supérieur d’Informatique et de Mathématiques de Monastir
Année universitaire: 2012 - 2013
Mouna AYARIMouna [email protected]
91Remarque: Ce document doit être complété par les notes de cours !
Processus Unifié (UP)Processus Unifié (UP)
UP est un processus de type adaptatif, il est Itératif et incrémental Guidé par les besoins (exigences) des utilisateurs Centré sur l’architecture Piloté par les risques Piloté par les risques
On le représente selon l’axe statique et dynamique p q y qdes processus de développement.
92
Phases et itérationsPhases et itérations
UP comporte les quatre phases suivantes: Pré étude: définition du cadre du projet
É Élaboration: établissement d’un plan de projet et d’une architecture solide
Construction: développement du systèmepp y Transition: livraison du système aux utilisateurs finaux
’ é à ’ éIl existe un certain nombre d’itérations à l’intérieur de chaque phase. Une itération représente un cycle de développement logiciel complet
(analyse des besoins version exécutable)( y )
93
Cycle de viey
94
PhasesPhases Pré étudePré étude : On définit le cadre du système et on délimite la
portée du projet Ce cadre comprend:portée du projet. Ce cadre comprend: Les critères de réussite La mise en évidence des risques
L ti ti d é i Les estimations des ressources nécessaires Un plan de phase qui contient un planning des principaux jalons Un prototype exécutable validant le concept
ÉlaborationÉlaboration: consiste à Analyser le domaine du problème
É Établir une architecture solide Développer le plan du projet Éliminer les éléments à risques pour le projetq p p j
95
PhasesPhases ConstructionConstruction: On développe un produit complet et prêt à
transiter vers les utilisateurs, de manière itérative et incrémentale
TransitionTransition: au cours de cette phase on déploie le logiciel pour les utilisateurs, on réajuste le système en corrigeant les éventuels bugs ou on achève certains fonctionnalités quiéventuels bugs ou on achève certains fonctionnalités qui avaient été remises à plus tard
96
Workflows et processusWorkflows et processusModélisation métier décrit la structure et la dynamique de l’entrepriseExigences décrit la méthode basée sur les cas d’utilisation pour
saisir et organiser les exigencesAnalyse et décrit les différentes vues d’une architectureconceptionImplémentation prend en compte le développement logiciel, les tests
unitaires et l’intégrationTests décrit les cas de test, les procédures et les métriques
de recherche d’erreurDéploiement couvre la configuration du système à livrerGestion de configuration
Contrôle les modification et maintient les artefacts d’un projet
Gestion de projet Décrit différents stratégies de travail avec un Gestion de projet Décrit différents stratégies de travail avec un processus itératif
Environnement Couvre l’infrastructure nécessaire demandée pour développer un système
97
pp y
Workflows et artefactsWorkflows et artefactsWorkflows Artefacts
Expression des besoins Vision du projetSpécifications Modèle des cas d’utilisation
Spécifications supplémentairesSpécifications supplémentairesGlossaire
Analyse Modèle du domaineConception Modèle de conception
Architecture logicielleModèle de données
Implémentation Modèle d’implémentationTests Modèle de tests
Dé l i t M dèl d dé l i tDéploiement Modèle de déploiementGestion de projets Plan de développement
Environnement Cas de développement
98
UP est Itératif et incrémentalUP est Itératif et incrémental Le développement d’un logiciel nécessite qu’on le découpe
en plusieurs petits projets.
Chaque projet représente une itération qui donne lieu à un Chaque projet représente une itération qui donne lieu à un incrément.
Une itération désigne la succession des activités de développement
un incrément correspond aux stades de développement du produitp pp p
99
UP est piloté par les uses casesUP est piloté par les uses casesPour servir les attentes des utilisateurs, On centre le processus de Pour servir les attentes des utilisateurs, On centre le processus de développement sur leurs besoinsdéveloppement sur leurs besoinsdéveloppement sur leurs besoins.développement sur leurs besoins.
On fait apparaître ces besoins à l’aide de la technique des cas On fait apparaître ces besoins à l’aide de la technique des cas d’ ili id’ ili id’utilisation :d’utilisation :
en capturant les besoins fonctionnels d’un systèmeen capturant les besoins fonctionnels d’un systèmeyy
en orientant le travail de chaque itérationen orientant le travail de chaque itération
vont guider le processus à travers l’utilisation des différents vont guider le processus à travers l’utilisation des différents modèles UML qui représentent le système.modèles UML qui représentent le système.
100
Cahier des charges
Modèle du domaine
Modèle deConçus par
Analysés par
Modèle de conception
Modèle
Conçus par
Réalisés pard’implémentation
Modèle Structurés par
Modèle de testsTestés parDi d
d’architectureStructurés par
Modèle de déploiement
Déployés parDiagramme des
Uses Case
101
UP est centré sur l’architectureUP est centré sur l architecture
l’architecture doit prévoir la réalisation de tous les uses case et l’architecture doit prévoir la réalisation de tous les uses case et doit évoluer avec eux. doit évoluer avec eux. Elle le fait en tenant compte de facteurs tels que:Elle le fait en tenant compte de facteurs tels que: La plateforme d’exécution La plateforme d’exécution
Matériel, système, BD, réseau,etc.Matériel, système, BD, réseau,etc. Les composants réutilisablesLes composants réutilisablesLes composants réutilisablesLes composants réutilisables
Librairies, caisse à outils, composants du commerce, etc. Librairies, caisse à outils, composants du commerce, etc. Les considérations de déploiement et les besoins non Les considérations de déploiement et les besoins non
f ti lf ti lfonctionnelsfonctionnels La performance, la fiabilité, la robustesse, etc.La performance, la fiabilité, la robustesse, etc.
102
UP est piloté par les risquesUP est piloté par les risques
Un risque est un événement redouté dont Un risque est un événement redouté dont l’occurrence est plus ou moins prévisible.l’occurrence est plus ou moins prévisible.p pp pLe pilotage par les risques c’est:Le pilotage par les risques c’est: Analyser les risques potentiels au plus tôtAnalyser les risques potentiels au plus tôty q p py q p p Hiérarchiser les risquesHiérarchiser les risques Associer un ensemble de uses case à chaque risqueAssocier un ensemble de uses case à chaque risque Déclencher les itérations selon la criticité des uses cases Déclencher les itérations selon la criticité des uses cases
qu’elles regroupentqu’elles regroupentUP ti d i C iUP ti d i C iUP propose une gestion des risques. Ce qui UP propose une gestion des risques. Ce qui constitue une avancée significative.constitue une avancée significative.
103
Adaptations de UPAdaptations de UP
UP est un processus générique de développement. p g q ppIl doit être adaptée au contexte du projet, de l’équipe et de l’organisation concernée.
Il existe donc des adaptations d’UP dont les plusIl existe donc des adaptations d UP dont les plus connues sont: Le Rational Unified Process (RUP)( ) L’eXtreme Programming (XP) Le Two Tracks Unified Process (2TUP)
104
Chapitre 2Méthodologies de COO – processus unifiéMéthodologies de COO – processus unifié
2.2. Processus UnifiéRational Unified Process (RUP)Rational Unified Process (RUP)
Licence Fondamentale en InformatiqueLicence Fondamentale en InformatiqueNiveau: 3ème année – 3ème semestre
Institut Supérieur d’Informatique et de Mathématiques de Monastir
Année universitaire: 2012 - 2013
Mouna AYARIMouna [email protected]
105Remarque: Ce document doit être complété par les notes de cours !
Processus Unifié ou “Unified Software Development Process” (USDP)Process (USDP)
Processus du domaine public pour le développement Orienté-Objet de logicielpp j g
Maintenant largement surpassé par le Processus U ifié R ti l ( i il i d l tUnifié Rational (similaires dans leurs aspects principaux)
106
Processus Unifié - RUPProcessus Unifié RUP
Le Processus Unifié est :guidé par les use-cases,guidé par les use cases,centré sur l'architecture, itératif et incrémental itératif et incrémental.
107
Processus Unifié -RUPProcessus Unifié RUP
L ité ti t êt é 4 hLes itérations peuvent être regroupées en 4 phases : création (objectifs du projet, et coûts),
él b ti (b i ) élaboration (besoins), construction (obtention du produit quasi finalisé),
t iti ( i i t t li i ) transition (mise au point et livraison).
Profil d’un projet typique montrant les tailles relatives des quatre phases108
Processus Unifié - RUPProcessus Unifié RUP
Ch ité ti i t à h î 5 ti ité Chaque itération consiste à enchaîner 5 activitésprincipales : Besoins Besoins, Analyse, Conception,p , Implémentation, Tests.
Différentes activités plus spécifiques peuvent s'enchaîner dans chacune de ces 5 activités principales Elles sontdans chacune de ces 5 activités principales. Elles sont effectuées par différents travailleurs.
109
Organisation en phases, itérations et activitésactivités
Phases
Création Élaboration Construction Transition
Activitésprincipales
Besoins
Analyse
Conception
Implémentation
Tests
Itérations
It. 1 It. 2 It. nIt. n-1… … … … …
110
Répartition du travail en phases, itérations et activités principales
Organisation en phases, itérations et activitésactivités
Phases
Création Élaboration Construction Transition
Activitésprincipales
Besoins
Analyse
Conception
Implémentation
Tests
Itérations
It. 1 It. 2 It. nIt. n-1… … … … …
111
Répartition du travail en phases, itérations et activités principales
Activités de l'analyse des besoinsActivités de l analyse des besoins
L'analyse des besoins regroupe les activitésL analyse des besoins regroupe les activités suivantes :
établir une ébauche du modèle des use cases établir une ébauche du modèle des use-cases, assigner des priorités aux use-cases,
détailler chaque use-case, prototyper l'interface utilisateur, structurer le modèle des use-cases.
112
Enchaînement des activités de l'analyse des besoinsdes besoins
Analystesystème
Ébaucher modèle u-c.
Structurer modèle u-c.
Architecte Assigner priorités u-c.
Spécificateur Dét ill Spécificateurde use-case
Détailler use-case
Concepteur d’interface
Prototyper interface
113
Enchaînement des activités de l'analyse des besoinsdes besoins
Analystesystème
Ébaucher modèle u-c.
Structurer modèle u-c.
Architecte Assigner priorités u-c.
Spécificateur Détailler pde use-case
Détailler use-case
Concepteur d’interface
Prototyper interface
114
Ébauche du modèle des use-casesÉbauche du modèle des use cases
L' l t tè t bl d tt L'analyste système est responsable de cette activité.
A partir notamment de la liste des fonctionnalités, elle consiste à :
identifier les acteurs identifier les acteurs, identifier les use-cases, décrire brièvement chaque use-case décrire brièvement chaque use case, fournir un diagramme global de use-cases, élaborer un glossaire.g
115
Enchaînement des activités de l'analyse des besoinsbesoins
Analystesystème
Ébaucher modèle u-c.
Structurer modèle u-c.y
Architecte Assigner priorités u-c.
Spécificateurde use-case
Détailler use-case
Concepteur d’interface
Prototyper
116
d interface interface
Priorité des use-casesPriorité des use cases
Cette activité fait suite à l'ébauche du modèle des use-cases.
L'architecte établit un ordre de priorité pour la L architecte établit un ordre de priorité pour la réalisation (conception, implémentation, …) des
d l ité ti lté iuse-cases dans les itérations ultérieures.
117
Enchaînement des activités de l'analyse des besoinsbesoins
Analystesystème
Ébaucher modèle u-c.
Structurer modèle u-c.y
Architecte Assigner priorités u-c.
Spécificateurde use-case
Détailler use-case
Concepteur d’interface
Prototyper
118
d interface interface
Description détaillée des use-casesDescription détaillée des use cases
Cette activité fait suite à l'établissement des priorités sur les use-cases.
Un responsable est nommé pour la description détaillée de chaque use-case, il doit :
dé ill l d i i i f i l' l détailler la description sommaire fournie par l'analyste système, par des descriptions textuelles, des diagrammes de séquence ou de collaboration, undiagrammes de séquence ou de collaboration, un diagramme d'état;
rechercher les déroulements anormaux et ti l ibl t l dé iexceptionnels possibles et les décrire.
119
Enchaînement des activités de l'analyse des besoinsdes besoins
Analystesystème
Ébaucher modèle u-c.
Structurer modèle u-c.y
Architecte Assigner priorités u-c.
Spécificateurde use-case
Détailler use-case
Concepteur d’interface
Prototyper
120
d interface interface
Prototypage de l'interface utilisateurPrototypage de l interface utilisateur
Cette activité fait suite à la description détaillée des Cette activité fait suite à la description détaillée des use-cases.
Le concepteur d’interface fournit : une conception logique de l'interface utilisateur
(indépendante de la manière dont elle peut être implémentée),
des croquis de "pages-écrans" en accord avec cette conception logique.
121
Enchaînement des activités de l'analyse des besoinsbesoins
Analystesystème
Ébaucher modèle u-c.
Structurer modèle u-c.
Architecte Assigner priorités u-c.
Spécificateur Dét ill Spécificateurde use-case
Détailler use-case
Concepteur d’interface
Prototyper interface
122
Structurer le modèle des use-casesStructurer le modèle des use cases
C tt ti ité f it it à l d i ti dét illé d Cette activité fait suite à la description détaillée des use-cases.
L'analyste système améliore le modèle des use-y ycases, notamment en identifiant : des descriptions similaires (généralisation),p (g ), des descriptions communes (inclusion), des descriptions optionnelles (extension).des descriptions optionnelles (extension).
123
Organisation en phases itérations et activitésOrganisation en phases, itérations et activités
Phases
Création Élaboration Construction Transition
Activitésprincipales
Besoins
Analyse
Conception
Implémentation
Tests
Itérations
It. 1 It. 2 It. nIt. n-1… … … … …
124
Répartition du travail en phases, itérations et activités principales
Activités de l'analyseActivités de l analyse
L'analyse regroupe les activités suivantes : L analyse regroupe les activités suivantes : analyse architecturale,
analyse de use-case,
analyse de classe, analyse de paquetage.
125
Enchaînement des activités de l'analyseEnchaînement des activités de l analyse
Architecte Analysearchitecturalearchitecturale
Ingénieurde use-case
Analyse de use-case
Ingénieur decomposants
Analysede classe
Analyse depaquetage
126
Enchaînement des activités de l'analyseEnchaînement des activités de l analyse
Architecte Analysearchitecturale
Ingénieurde use-case
Analyse de use-case
I é i dIngénieur decomposants
Analysede classe
Analyse depaquetage
127
Analyse architecturaleAnalyse architecturale
Cette activité est sous la responsabilité de pl'architecte.
A partir du modèle des use cases elle consiste à A partir du modèle des use-cases, elle consiste à fournir : une ébauche des classes d'analyse manifestes une ébauche des classes d analyse manifestes, une ébauche des paquetages d'analyse (en 2 couches:
spécifique et générale aux applications)spécifique et générale aux applications), une première description de l'architecture (exigences).
128
Enchaînement des activités de l'analyseEnchaînement des activités de l analyse
Architecte Analysearchitecturalearchitecturale
Ingénieurde use-case
Analyse de use-case
Ingénieur decomposants
Analysede classe
Analyse depaquetage
129
Analyse de use-caseAnalyse de use case
Cette activité fait suite à l'analyse architecturale elle Cette activité fait suite à l analyse architecturale, elle est effectuée par un ingénieur de use-case.Cela consiste à identifier les classes d'analyse et les Cela consiste à identifier les classes d'analyse et les interactions nécessaires à la réalisation d'un use-casecase. De nouvelles classes d'analyse peuvent être
identifiées, ou bien on peut donner de nouveauxidentifiées, ou bien on peut donner de nouveaux éléments de définition de classes déjà identifiées.
Les interactions peuvent être décrites par des p pdiagrammes de description dynamique.
130
Enchaînement des activités de l'analyseEnchaînement des activités de l analyse
Architecte Analysearchitecturalearchitecturale
Ingénieurde use-case
Analyse de use-case
Ingénieur decomposants
Analysede classe
Analyse depaquetage
131
Analyse de classesAnalyse de classes
C tt ti ité èd l d Cette activité succède aux analyses de use-cases, elle est effectuée par un ingénieur de composants.Ell i à Elle consiste à : identifier les responsabilités d'une classe à partir de la
thè d diffé t ôl ' ll j d lsynthèse des différents rôles qu'elle joue dans les use-cases (opérations),
identifier les attributs et les relations entre classes identifier les attributs et les relations entre classes (associations, généralisation),
formuler éventuellement des exigences sur laformuler éventuellement des exigences sur la conception (taille des attributs, …).
132
Enchaînement des activités de l'analyseEnchaînement des activités de l analyse
Architecte Analysearchitecturalearchitecturale
Ingénieurde use-case
Analyse de use-case
Ingénieur decomposants
Analysede classe
Analyse depaquetage
133
Analyse de paquetagesAnalyse de paquetages
Cette activité fait suite à l'analyse des classes Cette activité fait suite à l analyse des classes, toutes deux sont effectuées par un ingénieur de composantscomposants.
Cela consiste à améliorer la répartition des classes d'analyse en paquetages ébauchées pendantd analyse en paquetages, ébauchées pendant l'analyse architecturale. Il faut : garantir la cohésion des paquetages garantir la cohésion des paquetages, décrire les dépendances entre paquetages et chercher
à les diminuer.
134
Organisation en phases itérations et activitésOrganisation en phases, itérations et activités
Phases
Création Élaboration Construction Transition
Activitésprincipales
Besoins
Analyse
Conception
Implémentation
Tests
Itérations
It. 1 It. 2 It. nIt. n-1… … … … …
135
Répartition du travail en phases, itérations et activités principales
Activités de la conceptionActivités de la conception
La conception regroupe les activités suivantes : La conception regroupe les activités suivantes : conception architecturale,
conception de classe,
conception de use-case, conception de sous-système.
136
Enchaînement des activités de conceptionEnchaînement des activités de conception
Architecte Conceptionarchitecturalearchitecturale
Ingénieurde use-case
Conceptionde use-case
Ingénieur decomposants
Conceptionde classe
Conception desous-sytème
137
Enchaînement des activités de conceptionEnchaînement des activités de conception
Architecte Conceptionarchitecturalearchitecturale
Ingénieurde use-case
Conceptionde use-case
Ingénieur decomposants
Conceptionde classe
Conception desous-sytème
138
Conception architecturaleConception architecturale
L'architecte assume la responsabilité de cette activité.
À partir notamment du modèle des use-cases du À partir notamment du modèle des use-cases, du modèle d'analyse et de la première description de l'architecture issue de l'analyse, il doit en particulier yproduire : une ébauche des sous-systèmes et de leur interface (4
couches)couches), une ébauche des classes et mécanismes de conception, une ébauche du modèle de déploiement (nœuds et une ébauche du modèle de déploiement (nœuds et
configurations réseau).
139
Architecture en 4 couchesArchitecture en 4 couches
spécifiqueà l’application
générale aux applications
sd
ance
s
middleware
épen
d
logiciel système
Dé
140
Enchaînement des activités de conceptionEnchaînement des activités de conception
Architecte Conceptionarchitecturalearchitecturale
Ingénieurde use-case
Conceptionde use-case
Ingénieur decomposants
Conceptionde classe
Conception desous-sytème
141
Conception de classesConception de classes
Cette activité fait suite à la conception architecturale, elle p ,est effectuée par les ingénieurs de composants.
Cette activité consiste à : décrire précisément les opérations et les attributs des
classes de conception, décrire les relations auxquelles elle prend part, décrire ses états imposés (diagramme d'états),p ( g ) expliciter ses méthodes (qui réalisent les opérations)
et la réalisation correcte de ses interfaces,, exprimer les exigences sur son implémentation.
142
Enchaînement des activités de conceptionEnchaînement des activités de conception
Architecte Conceptionarchitecturalearchitecturale
Ingénieurde use-case
Conceptionde use-case
Ingénieur decomposants
Conceptionde classe
Conception desous-sytème
143
Conception de use-caseConception de use case
Cette activité fait suite à la conception architecturale et à la Cette activité fait suite à la conception architecturale et à la conception des classes de conception, elle est effectuée par les ingénieurs de use-case.les ingénieurs de use case.
Cette activité consiste à : reconnaître les classes de conception prenant part à la reconnaître les classes de conception prenant part à la
réalisation d'un use-case, de nouvelles classes de conception peuvent être éventuellement identifiées,p ,
décrire les interactions entre classes en termes de messages, définir les exigences sur les opérations et l'implémentation,dé es e ge ces su es opé at o s et p é e tat o , contrôler et enrichir la description des sous-systèmes et de leur
interface.
144
Enchaînement des activités de conceptionEnchaînement des activités de conception
Architecte Conceptionarchitecturalearchitecturale
Ingénieurde use-case
Conceptionde use-case
Ingénieur decomposants
Conceptionde classe
Conception desous-sytème
145
Conception de sous-systèmesConception de sous systèmes
Cette activité fait suite à la conception des classes et des use-cases, elle est effectuée par les ingénieurs dedes use cases, elle est effectuée par les ingénieurs de composants.
Cette activité consiste à finaliser la description desCette activité consiste à finaliser la description des sous-systèmes et de leur interface, c'est-à-dire à : actualiser les dépendances entre sous-systèmes (et les p y (
minimiser), actualiser leur interface, actualiser le contenu des sous-systèmes.
146
Organisation en phases itérations et activitésOrganisation en phases, itérations et activités
Phases
Création Élaboration Construction Transition
Activitésprincipales
Besoins
Analyse
Conception
Implémentation
Tests
Itérations
It. 1 It. 2 It. nIt. n-1… … … … …
147
Répartition du travail en phases, itérations et activités principales
Résumé: UP (Processus unifié)Résumé: UP (Processus unifié)
Enraciné dans: La méthode de Booch (bonne pour la conception et ( p p
l'implémentation) OMT (bonne pour l'analyse)
Obj (b l'i é i i d b i Objectory (bonne pour l'ingénierie des besoins et l'architecture du système)
UP a rassemblé ces méthodes Aussi volumineux et complexe : temps Aussi volumineux et complexe : temps
d'apprentissage long, ou bien l'adapter au besoin
148
Chapitre 2Méthodologies de COO – processus unifiéMéthodologies de COO – processus unifié
2.3 Méthodologie 2: Processus en Y: 2TUP (Two Track Unified Process)2TUP (Two Track Unified Process)
Licence Fondamentale en InformatiqueLicence Fondamentale en InformatiqueNiveau: 3ème année – 3ème semestre
Institut Supérieur d’Informatique et de Mathématiques de Monastir
Année universitaire: 2012 - 2013
Mouna AYARIMouna [email protected]
149Remarque: Ce document doit être complété par les notes de cours !
DéfinitionDéfinition
2TUP est un processus UP apportant une réponse aux contraintes de changement continuel des systèmes d’information: fonctionnel et techniqued information: fonctionnel et technique
2 Track: processus suivant deux cheminsp Fonctionnel Architecture Technique
SIContraintesContraintesfonctionnellesfonctionnelles
ContraintesContraintestechniquestechniquesqq
150
ExemplesExemples Une entreprise modifie son catalogue de produit en imposant
de nouvelles règles de tarification évolution fonctionnelle.
Cette même entreprise décide de rendre accessible son Cette même entreprise décide de rendre accessible son catalogue via le WEB évolution technique.
Cette entreprise décide finalement de fusionner son catalogue avec une autre entreprise du même secteur évolution fonctionnelles et techniquesévolution fonctionnelles et techniques.
151
Processus en YProcessus en YLa réalisation du système consiste à fusionner les résultats des deux é l ti f ti ll t t h i i d it à dévolutions fonctionnelle et technique: ce qui conduit à un processus de développement en forme de Y
152
Processus en YProcessus en Y
ContraintesContraintesfonctionnellesfonctionnelles
ContraintesContraintestechniquestechniques
Branchefonctionnelle
Branchetechnique
C t d b i C t d b i Capture des besoins fonctionnels
Capture des besoins techniques
Analyse Conception générique
Conception préliminaire prototypeConception préliminaire
Conception détaillée
prototype
Recette
Codage et tests
153
Processus en YProcessus en Y
La branche gauche (fonctionnelle) du Y Capture des besoins fonctionnels p Produit un modèle des besoins focalisée sur le métier des
utilisateursQ lifi l tôt l i d d i tè Qualifie au plus tôt le risque de produire un système inadapté
Permet à la maîtrise d’œuvre de consolider les spécifications et de vérifier la cohérence
L’analyse Précise ce que l’on va réaliser en termes métier Le résultat de l’analyse ne dépend d’aucune technologie
particulièreparticulière
154
Processus en YProcessus en Y
La branche droite (architecture technique) du Y Capture des besoins techniques
Recense toutes les contraintes et les choix dimensionnant la Recense toutes les contraintes et les choix dimensionnant la conception
Identifie les outils et les matériels ainsi que les contraintes d’intégration avec l’existantavec l existant
La conception générique Définit les composants nécessaires à l’élaboration de l’architecture
techniquetechnique Construit le squelette du système et élimine les risques au niveau
technique A pour objectif d’uniformiser et de réutiliser les mêmes mécanismesA pour objectif d uniformiser et de réutiliser les mêmes mécanismes
pour la plupart des systèmes Est indépendante des aspects fonctionnels
155
Processus en YProcessus en YLa branche du milieu La conception préliminaire Intègre le modèle d’analyse dans l’architecture technique
T l t hi d t d tè à Trace la cartographie des composants du système à développer
La conception détailléep Étudie comment réaliser chaque composant
Codage Produit les composants et teste au fur et à mesure les
unités de code réalisées Recette Recette Valide les fonctions du système développé
156
Processus en YProcessus en Y
Les branches du «Y» produisent des modèles préutilisables La branche gauche capitalise la connaissance du métier de
l’entreprise: les fonctions du système d’information sont indépendantes des solutions techniques utilisées.
La branche droite capitalise le savoir faire technique: les techniques utilisées peuvent être réalisées q pindépendamment du besoin fonctionnel
157
Chapitre 3 Conception architecturale
Licence Fondamentale en InformatiqueLicence Fondamentale en InformatiqueNiveau: 3ème année – 1er semestre
Institut Supérieur d’Informatique et de Mathématiques de Monastir
Année universitaire: 2012 - 2013
Mouna AYARIMouna [email protected]
Remarque: Ce document doit être complété par les notes de cours !158
Conception architecturaleConception architecturale
ObjectifsObjectifs Décrire le fonctionnement et les caractéristiques d’un style
architectural Justifier le choix d’une architecture pour la réalisation d’un
logiciel, en tenant compte de ses exigences fonctionnelles et non fonctionnelleset non fonctionnelles
Définir ce qu’est un composant Expliquer le contenu décrit par un diagramme deExpliquer le contenu décrit par un diagramme de
paquetages, de composants et de déploiement (UML) Décrire le modèle d’une architecture avec la notation UML
159
Plan du chapitrePlan du chapitre
Introduction
Modélisation UML d’une conception architecturale
Eléments architecturaux
Styles architecturaux Styles architecturaux Choix d’une architecture Architecture MVCArchitecture MVC Architecture multi-couches Architecture n-niveaux
Développer un modèle architectural
160
IntroductionIntroduction
Q ’ t ’ hit t l i i ll ? Qu’est-ce qu’une architecture logicielle ? L’architecture d’un logiciel est la structure des
structures (modules) d’un systèmestructures (modules) d’un système Elle inclut Les composants logiciels Les composants logiciels Les propriétés externes visibles de ces composants Les relations entre ces composantsCf. [Bass, Clements, and Kazman (1998) ]
161
IntroductionIntroduction
Contrairement aux spécifications produites par l’analyse fonctionnelle le modèle d'architecture ne décrit pas ce que doit
réaliser un système informatique mais plutôt comment il doit être conçu de manière à répondre auxil doit être conçu de manière à répondre aux spécifications.
L’analyse fonctionnelle décrit le « quoi faire » alors que L analyse fonctionnelle décrit le « quoi faire » alors que l’architecture décrit le « comment le faire »
162
IntroductionIntroduction
Qu’est que la description d’une architectureQu est que la description d une architecture logicielle ? La définition de l’architecture logicielle consiste à:La définition de l architecture logicielle consiste à: Décrire l’organisation générale d’un système et sa
décomposition en sous-systèmes ou composants Déterminer les interfaces entre les sous-systèmes Décrire les interactions et le flot de contrôle entre les sous-
systèmesy Décrire également les composants utilisés pour implanter les
fonctionnalités des sous-systèmesL iété d t Les propriétés de ces composants
Leur contenu (e.g., classes, autres composants) Les machines ou dispositifs matériels sur lesquels ces modules
seront déployés163
Introduction Introduction
Pourquoi développer une architecture logicielle ? q pp g Pour permettre à tous de mieux comprendre le
système Pour permettre aux développeurs de travailler sur des
parties individuelles du système en isolation Pour préparer les extensions du système Pour faciliter la réutilisation et la réutilisabilité
164
Introduction Introduction
Utilité d’une architecture logicielle [Garlan 2000] g [ ] Compréhension : facilite la compréhension des grands systèmes
complexes en donnant une vue de haut-niveau de leur structure et de leurs contraintes Les motivation des choix de conceptionet de leurs contraintes. Les motivation des choix de conception sont ainsi mis en évidence
Réutilisation : favorise l’identification des éléments réutilisables, parties de conception, composants, caractéristiques, fonctions ou données communes
Construction : fournit un plan de haut-niveau du développement Co st uct o ou t u p a de aut eau du dé e oppe e tet de l’intégration des modules en mettant en évidence les composants, les interactions et les dépendances
165
Introduction Introduction
Utilité d’une architecture logicielle [Garlan 2000]g [ ] Évolution : met en évidence les points où un système peut être
modifié et étendu. La séparation composant/connecteur facilite une implémentation du type « plug-and-play »
Analyse : offre une base pour l’analyse plus approfondie de la conception du logiciel analyse de la cohérence test deconception du logiciel, analyse de la cohérence, test de conformité, analyse des dépendances
Gestion : contribue à la gestion générale du projet en permettant Gest o co t bue à a gest o gé é a e du p ojet e pe etta taux différentes personnes impliquées de voir comment les différents morceaux du casse-tête seront agencés. L’identification des dépendance entre composants permet d’identifier où lesdes dépendance entre composants permet d identifier où les délais peuvent survenir et leur impact sur la planification générale
166
Modélisation UML d’une architecture d’un système
Vues (structurelles) d’une architecture logicielle
odé sat o U d u e a c tectu e d u systè e
Vues (structurelles) d une architecture logicielle Vue logique. Description logique du système
décomposé en sous-systèmes (modules + interface)p y ( ) UML : diagramme de paquetages
Vue d’implémentation. Description de l’implémentation (physique) du système logiciel en termes de composants et de connecteurs UML : diagramme de composants UML : diagramme de composants
Vue de déploiement. Description de l’intégration et de la distribution de la partie logicielle sur la partiela distribution de la partie logicielle sur la partie matérielle UML: diagramme combiné de composants et de déploiement
167
Rappel : vues d’un systèmeRappel : vues d un systèmeDiagramme de classes
Diagramme de composants
Vue structurelle
de classes
Diagramme combiné de
p
Diagramme de packagesVue structurelle
(modèle statique)
Vue des cas d’utilisation
déploiement/composants
packages
Vue des cas d utilisation(modèle fonctionnel des exigences)
Vue du comportement et des interactionsVue du comportement et des interactions (modèle dynamique) Diagramme de
cas d’utilisationDiagramme de
séquence
comportementinteraction
Diagramme d’activités
Diagramme d’états Diagramme de
i ti
comportementinteraction
d activitéscommunicationcomportement comportementinteraction168
Modélisation UML d’une architecture d’un systèmeodé sat o U d u e a c tectu e d u systè e
Diagramme de paquetages Diagramme de paquetages
169
Modélisation UML d’une architecture d’un systèmeodé sat o U d u e a c tectu e d u systè e
Diagramme de composants
170
Modélisation UML d’une architecture d’un systèmeodé sat o U d u e a c tectu e d u systè e
Diagramme combiné de déploiement/composants
171
Éléments architecturauxÉléments architecturaux
Composant Encapsule un traitement et/ou des données
compA
Encapsule un traitement et/ou des données
Encapsule un sous-ensemble de fonctionnalités et/ou de données du systèmey
Restreint l’accès à ce sous-ensemble au moyen d’une interface définie explicitement
Possède des dépendances explicitement définies pour exprimer les contraintes requises par son contexte d’exécution ou sa réalisation
172
Éléments architecturauxÉléments architecturaux
C C tComposant Unité autonome faisant partie d’un système ou d’un sous-système
i l t t (i i lé t ti ) t i ff
Composant
qui encapsule un comportement (i.e., implémentation) et qui offre une ou plusieurs interfaces publiques
Partie constituante d’un système qui peut être remplacée ou/et Partie constituante d un système qui peut être remplacée ou/et réutilisée
Élément d’implémentation (un sous-système, un fichier exécutable, p ( y , ,une classe d’implémentation (i.e., non abstraite, etc.) muni d’interface(s)
Chaque composant est le représentant d’une ou plusieurs classes qui implémentent un service à l’intérieur du système
173
Éléments architecturauxÉléments architecturaux
ComposantComposant Granularité : Un composant peut représenter quelque chose
d’aussi fin qu’un objet, comme il peut représenter un sous-d aussi fin qu un objet, comme il peut représenter un soussystème complexe
Différence entre composant et instance de composant Différence entre composant et instance de composant Composant : vue de haut niveau d’un élément logiciel qui
compose le système (~classe) Instance de composant: le composant effectivement utilisé (~objet)
Exemples de composants: Binaire exécutable (« executable »), bibliotheque
dynamique/statique («librairy »), un fichier à interpréter («file»)
174
(«file»)…
Éléments architecturauxÉléments architecturaux
Composantp Unité autonome servant de bloc de construction pour le système Les composants implémentent typiquement des services
é ifi à l’ li tispécifiques à l’application La manifestation concrète d’un composant est appelé artéfact
(instance du composant déployée sur le matériel) N’importe quel type de code sur n’importe quel support numérique Code source, fichiers binaires, scripts, fichiers exécutables, bases de
données, applications, etc.données, applications, etc.
OrderOrder.jar
«manifestation»
175
Éléments architecturauxÉléments architecturaux
Interface de composantInterface de composant Permet à un composant d’exposer les moyens à
utiliser pour communiquer avec luiutiliser pour communiquer avec lui
Types d’interfaces Interface offerte : définit la façon de demander l’accès à un Interface offerte : définit la façon de demander l accès à un
service offert par le composant Interface requise : définit le type de services (aide) requis par le
composant
Une interface est attachée à un port du composant Port = point de communication du composant Plusieurs interfaces peuvent être attachées à un même port
176
Éléments architecturauxÉléments architecturaux
Composants et interfaces - Notationp
C d
EntréeCmdesPersonne
Commande PaiementComptes
composantinterface requise interfaces offertes
Commande<<provided interfaces>>EntréeCmdesPaiementComptes
<<required interface>>Person
177
Éléments architecturauxÉléments architecturaux
Dépendances entre composants Dépendances entre composants Dépendance = relation entre deux composants
Types de dépendances Un composant peut dépendre d’un autre composant qui lui
f it i i f tifournit un service ou une information Un composant peut dépendre d’une classe qui implémente une
partie de son comportement. Dépendance de réalisationpartie de son comportement. Dépendance de réalisation Un composant peut dépendre d’un artefact (code source,
fichier .jar, etc.) qui l’implante concrètement. Dépendance de if t timanifestation
178
Éléments architecturauxÉléments architecturaux
port
connecteur
composant
Comp_A Comp_Binterfacefournie
interface requiseq
Classe Cdépendance
«realisation»
configuration
Classe_C
Deux ou plusieurs composants interagissent via un connecteur Chaque élément architectural possède une structure et/ou
comportement pouvant être décrit par un modèle UML appropriécomportement pouvant être décrit par un modèle UML approprié179
Éléments architecturauxÉléments architecturaux
Connecteur Dans les systèmes complexes, les interactions peuvent constituer
un enjeu encore plus important que les fonctionnalités des composants individuelscomposants individuels
Définition : élément architectural qui définit le type d’interactions entre les composants et les règles gouvernant ces interactions
Un connecteur relie les ports de deux ou plusieurs composants Un connecteur décrit un mécanisme de connection indépendant
de l’applicationde l application Représente un concept abstrait, paramétrable et indépendant des
composants spécifiques qu’il relieL tt ib t d t dé i t iété Les attributs du connecteurs décrivent ses propriétés comportementales Exemple: sa capacité, le temps de latence, le type d’interaction
(binaire/n-aire, asymétrique/symétrique, détails du protocole), etc.180
Éléments architecturauxÉléments architecturaux
Connecteur Un connecteur peut avoir un ou plusieurs rôles
Communication :rôle le plus fréquentC di ti t ôl d l l d l t i i d d é t Coordination : contrôle du calcul, de la transmission des données, etc. Orthogonal aux autres rôles
Conversion : permet l’interaction entre composants développés i dé d t d d l diffé t lindépendamment dans des langages différents par exemple
Facilitation : permet l’interaction entre composants conçus pour interragir ensemble. Synchronisation, accès contrôlées aux données partagées, etc.
Selon le(s) rôles qu’il doit remplir et le type de communication souhaitée entre deux composants, choix d’un typep , yp Procedure call (comm + coord) , Data access (comm + conv), Event,
Stream, Linkage, Distributor, Arbitrator, Adaptor (conv)
181
Éléments architecturauxÉléments architecturaux
Composants et relations – notationComposants et relations notation Une flèche de dépendance permet de mettre en
relation des composant via les interfaces requises et p qfournies
Système de commande
RechercheClientRepositoireClients
RechercheClient
AccèsProduit
(3) dépendance(1) composant
AccèsProduit Système d’i t i
AccèsProduit ( ) p
d’inventaire(2) interface
182
Éléments architecturauxÉléments architecturaux
Composants et relations – notationp
Planificateur
réservationsGestionnaired’horaires
réservations
mise à jouraccèsBD
GUI
mise à jour
accèsBDGUI
mise à jour
Réunions_BD
183
Styles architecturaux Styles architecturaux
Un style architecturalUn style architectural un patron décrivant une architecture logicielle
permettant de résoudre un problème particulierp p p Définit Un ensemble de composants et de connecteurs (et leur type) Les règles de configuration des composants et connecteurs
(topologie) Une spécification du comportement du patron Une spécification du comportement du patron Des exemples de systèmes construits selon ce patron
Constitue un modèle éprouvé et enrichi par p pl’expérience de plusieurs développeurs Compréhensibilité, maintenance, évolution, réutilisation,
performance documentation etcperformance, documentation, etc.184
Styles architecturauxStyles architecturaux
Choix d’une architectureChoix d une architecture Dépend des exigences fonctionnelles et non
fonctionnelles du logicielfonctionnelles du logiciel
Choix favorisant la stabilité : l’ajout de nouveaux éléments sera facile et ne nécessitera en général queéléments sera facile et ne nécessitera en général que des ajustements mineurs à l’architecture
Influencé par certains « modèles connus » de Influencé par certains « modèles connus » de décomposition en composants (styles architecturaux) et de mode d’interactions (e.g., orienté objet)( g , j )
185
Architecture Modèle-Vue-Contrôleur (MVC)Architecture Modèle Vue Contrôleur (MVC)
Séparer la couche interface utilisateur des autres parties p pdu système (car les interfaces utilisateurs sont beaucoup plus susceptibles de changer que la base de
i d tè )connaissances du système) Composé de trois types de composants
M dèl bl d d é d d i d Modèle : rassemble des données du domaine, des connaissances du système. Contient les classes dont les instances doivent être vues et manipulées
Vue : utilisé pour présenter/afficher les données du modèle dans l’interface utilisateur
Contrôleur : contient les fonctionnalités nécessaires pour gérer et Contrôleur : contient les fonctionnalités nécessaires pour gérer et contrôler les interactions de l’utilisateur avec la vue et le modèle
186
Architecture Modèle-Vue-ContrôleurArchitecture Modèle Vue Contrôleur
Exp. Génère le Exp Interprète les
Reçoit lesévénements
Vus par les acteurs
pcode html pour le
browser
Exp. Interprète les transmissions http
« post » du browser
Viewcréer et mettre à jour
événements des acteurs
Contrôleurnotifier changementsConsulter l’état(i.e. les données)
Modèle modifier
Exp. Le sous-système
187
p ygérant l’information.
Architecture Modèle-Vue-ContrôleurArchitecture Modèle Vue Contrôleur Modèle : noyau de l’application
Enregistre les vues et les contrôleurs qui en dépendent Notifie les composants dépendants des modifications aux données
Vue : interface (graphique) de l’application Vue : interface (graphique) de l application Crée et initialise ses contrôleurs Affiche les informations destinées aux utilisateurs Implante les procédure de mise à jour nécessaires pour demeurer
cohérente Consulte les données du modèle
Contrôleur : partie de l’application qui prend les décisions Accepte les événement correspondant aux entrées de l’utilisateur
T d it é é t (1) d d d i d é dèl Traduit un événements (1) en demande de service adressée au modèle ou bien (2) en demande d’affichage adressée à la vue
Implémente les procédures indirectes de mise à jour des vues si é inécessaire
188
Architecture Modèle-Vue-ContrôleurArchitecture Modèle Vue Contrôleur Avantages : approprié pour les D’un point de vue conception
systèmes interactifs, particulièrement ceux impliquant plusieurs vues du même modèle
p p Diviser pour régner : les composants
peuvent être conçus indépendamment
Cohésion : meilleure cohésion que si les pde données. Peut être utilisé pour faciliter la maintenance de la cohérence entre les données
qcouches vue et contrôle étaient dans l’interface utilisateur.
Couplage : le nombre de canaux de la cohérence entre les données distribuées
Inconvénient : goulot d’ét l t ibl
communication entre les 3 composants est minimal
Réutilisabilité : la vue et le contrôle peuvent être conçus à partir de d’étranglement possible peuvent être conçus à partir de composants déjà existants
Flexibilité : il est facile de changer l’interface utilisateur
Testabilité : il est possible de tester l’application indépendamment de l’interface
189
Développer un modèle architecturalDévelopper un modèle architectural Diagramme de composants MVC
190
Architecture multi-couchesArchitecture multi couches
Composants : chaque composant réalise un service Une couche offre un service (serveur) aux couches externes (client) Service créé indépendamment du logiciel ou spécifiquement
Met à profit la notion d’abstraction les couches externes sont plus Met à profit la notion d abstraction, les couches externes sont plus abstraites (haut niveau) que les couches internes
Connecteurs : dépendent du protocole d’interaction souhaité p pentre couches Système fermé : une couche n’a accès qu’aux couches adjacentes.
Les connecteurs ne relient que les couches adjacentesLes connecteurs ne relient que les couches adjacentes Système ouvert : toutes les couches ont accès à toutes les autres.
Les connecteurs peuvent relier deux couches quelconques
Exemples : souvent utilisé pour les systèmes implémentant des protocoles de communication (TCP/IP)
191
Architecture multi-couchesArchitecture multi couches
InterfaceApplication programsInterface
utilisateurScreen display
facilitiesLogique
applicativeUser account management
Accès au système
Communication réseau
g
File systemyd’exploitation Accès à la
base de données
e syste
Kernel (handling processes
and swapping192
Architecture multi-couchesArchitecture multi couches D’un point de vue conception Réutilisation : on peut souvent réutiliser des
h dé l é d’ i Diviser pour régner : les couches peuvent être conçues séparément
Cohésion : si elles sont bien conçues, l h é t hé i
couches développées par d’autres et qui proposent le service requis
Flexibilité : il est facile d’ajouter de nouveaux services construits sur les services les couches présenter une cohésion
par couche Couplage : des couches inférieures
bien conçues ne devraient rien savoir
nouveaux services construits sur les services de plus bas niveau
Anticipation du changement : en isolant les composants dans des couches distinctes, le bien conçues ne devraient rien savoir
à propos des couches supérieures et les seules connexions autorisées entre couches se font via les API
psystème devient résistant
Portabilité : tous les services relatifs à la portabilité peuvent être isolés
Abstraction : on n’a pas à connaître les détails d’implémentation des couches inférieuresRé tili bilité l h
Testabilité : les couches peuvent être testées indépendamment
Conception défensive : les API des couches i d d i é i Réutilisabilité : les couches
inférieures peuvent être conçues de façon à offrir des solutions génériques réutilisables
constituent des endroits stratégiques pour insérer des assertions de vérification
193
réutilisables
Architecture n-niveauxArchitecture n niveaux
Pour les systèmes distribuésy Comparable à une architecture par couches… dont les couches
seraient distribuées !N b L’architecture multi couche est généralement utilisée pour décrire N.b. L’architecture multi-couche est généralement utilisée pour décrire la structure interne (non distribuée) d’un composant qui peut lui-même appartenir à une architecture (distribuée) n-partie
P b d l l ti d ti i l d h Par abus de langage, la notion de tier a pris le sens de couche distribuée
Composants : chaque niveaux est représenté par un composant p q p p pqui joue le rôle de client et/ou de serveur
Connecteurs : relient un client à un serveur. Connexion asymétrique Doit supporter les communication distantes (e gasymétrique. Doit supporter les communication distantes (e.g., requêtes RPC, HTTP, TCP/IP)
Exemples Client-serveur, Trois niveaux, Quatre niveaux
194
Architecture n-niveauxArchitecture n niveaux Architecture 2-niveaux (client-serveur ou client lourd)
Client Serveurrequête de service
Architecture 3-niveaux (client léger)
requête de service
NavigateurWeb
Serveursde
base de données
Logiqueapplicativerequête
d irequête d i
Architecture 4-niveaux
de service de servicede B.D.
Client Bases de Logique
ApplicativePrésentationClient données(calculs, business)
(partie web)195
Architecture n-niveauxArchitecture n niveaux
Architecture client-serveurArchitecture client serveur Exemple typique : un système d’informations utilisant
une base de données centrale. (cas spécial de ( pl’architecture avec référentiel) Clients : reçoivent les données de l’utilisateur, initient les
t ti ttransactions, etc. Serveur : exécute les transactions, assure l’intégrité des
données Architecture pair-à-pair = une généralisation de
l’architecture client-serveur Les composants peuvent tous à la fois être client et serveur Conception plus difficile: flot de contrôle plus complexe dû à la
possibilité de deadlocks…possibilité de deadlocks…
196
Architecture n-niveauxArchitecture n niveaux
Architecture 3-niveauxArchitecture 3 niveaux Organisation en trois couches Couche interface: Composé d’objets interfaces (boundary p j ( y
objects) pour interagir avec l’utilisateur (fenêtres, formulaires, pages Web, etc.)
Couche logique applicative : Comporte tous les objets de Couche logique applicative : Comporte tous les objets de contrôle et d’entités nécessaire pour faire les traitements, la vérification des règles et les notifications requises par l’applicationl application
Couche de stockage : réalise le stockage, la récupération et la recherche des objets persistants
Avantage sur l’architecture client-serveur Permet le développement et la modification de différentes
i t f tili t l ê l i li tiinterfaces utilisateurs pour la même logique applicative197
Architecture n-niveauxArchitecture n niveaux
Architecture 3-partiesp
Réseau
Base de Client X
S d donnéescorporative
Serveur de B.D. Unix
Dépôt de
Marché de données
Serveur deServeur Dépôt de données
Client Windows Serveur de B.D. Unix
Serveur Windows NT
Logique applicative
198
Architecture n-niveauxArchitecture n niveaux
Architecture 3-niveaux À noter que la tendance veut que la
partie cliente soit Interface
De plus en plus mince, i.e., le client ne fait qu’afficher un contenu HTML
La logique applicative est alors
Interfacegestionnaire
La logique applicative est alors responsable de créer les pages Web à afficher par le clientGestion
des dossiers Il faut dissocier logique applicative et présentation des données
des dossiers
Base de données clients
199
Architecture n-niveauxArchitecture n niveaux Architecture 4-niveaux
Architecture dont la couche logique applicative est décomposée en Couche Présentation (JSP, servlets)( , )
Présentation du contenu statique: Contenu HTML ou XML affiché par le client
Présentation du contenu dynamique : contenu organisé et créé d i t l b ( it êt ffi hé HTML/XMLdynamiquement par le serveur web (pour ensuite être affiché en HTML/XML par le client)
Couche Logique applicative (calculs purs) : réalise le cœur des traitements de l’applicationtraitements de l application
Avantage sur l’architecture 3-niveaux Permet de supporter un grand nombre de formats de présentation
différents (propres à chaque client) tout en réutilisant certains desdifférents (propres à chaque client), tout en réutilisant certains des objets de présentation entre les clients. Réduction des redondances…
Bien adaptée pour les applications Web devant supporter plusieurs types de clientsyp
200
Architecture n-niveaux Java Server PagesP ti li tArchitecture n niveaux
Architecture 4-niveaux
- Partie cliente- Partie serveur
Serveur de baseServeurClients
Serveur de base de données
InterfaceATM
PrésentationServeur
<<build>>
InterfaceAccès base de données comptes clients<<submit>>
<<build>>
Gestion opérations bancaires
Webdo ées co ptes c e ts
<<submit>>
build
opérations bancairesInterfaceemployé de la banque
<<build>>
submit
<<submit>>de la banque <<submit>>
201
Architecture n-niveauxArchitecture n niveauxD’un point de vue conception d’ajouter de nouveaux clients et Diviser pour régner : de façon
évidente, client et serveur peuvent être développées
serveurs Portabilité : on peut développer
de nouveaux clients pour depeuvent être développées séparément
Cohésion : le serveur peut offrir
de nouveaux clients pour de nouvelles plateformes sans devoir porter le serveur
des services cohésifs au client Couplage : un seul canal de
communication existe souvent
Testabilité : on peut tester le client et le serveur indépendammentcommunication existe souvent
entre client et serveur Réutilisation : il est possible de
t bibli thè d
Conception défensive : on peut introduire des opérations de vérification dans le code traitanttrouver une bibliothèque de
composants, interfaces, etc. pour construire les systèmes
vérification dans le code traitant les messages reçus de part et d’autre
202 Flexibilité : il est assez facile
Développer un modèle architecturalDévelopper un modèle architectural Commencer par faire une esquisse de l’architecture
En se basant sur les principaux requis des cas d’utilisation ; décomposition en sous-systèmes
Déterminer les principaux composants requisp p p q Sélectionner un style architectural
Raffiner l’architecturef Identifier les principales interactions entre les composants et les
interfaces requises Décider comment chaque donnée et chaque fonctionnalité sera
distribuée parmi les différents composants Déterminer si on peut réutiliser un cadriciel existant (réutilisation) ou si
on peut en construire un (réutilisabilité) Considérer chacun des cas d’utilisation et ajuster l’architecture pour
qu’il soit réalisableDétailler l’architecture et la faire évoluer Détailler l’architecture et la faire évoluer
203
Développer un modèle architecturalDévelopper un modèle architectural Commencer par faire une esquisse de l’architecture
En se basant sur les principaux requis des cas d’utilisation ; décomposition en sous-systèmes
Déterminer les principaux composants requisp p p q Sélectionner un style architectural
Raffiner l’architecturef Identifier les principales interactions entre les composants et les
interfaces requises Décider comment chaque donnée et chaque fonctionnalité sera
distribuée parmi les différents composants Déterminer si on peut réutiliser un cadriciel existant (réutilisation) ou si
on peut en construire un (réutilisabilité). Considérer chacun des cas d’utilisation et ajuster l’architecture pour
qu’il soit réalisableDétailler l’architecture et la faire évoluer Détailler l’architecture et la faire évoluer
204
Développer un modèle architecturalDévelopper un modèle architectural
Décrire l’architecture avec UML Décrire l architecture avec UML Tous les diagrammes UML peuvent être utiles pour
dé i l diffé t t d dèl hit t ldécrire les différents aspects du modèle architectural
Trois des diagrammes UML sont particulièrement utile dé i hit t l i i llpour décrire une architecture logicielle
Diagramme de packages Diagramme de composants Diagramme de composants Diagramme de déploiement
205
Développer un modèle architecturalDévelopper un modèle architectural
Diagramme de packagesg p g Paquetage = Collection d’éléments de modélisation UML (e.g.,
classes, use cases, etc.) groupés ensemble car liés logiquementIl f t d i i l hé i i d t Il faut essayer de maximiser la cohésion au sein des paquetages (éléments liés) et minimiser le couplage entre eux
Dépendance : un paquetage est dépendant d’un autreDépendance : un paquetage est dépendant d un autre s’il l’utilise…
Si l Ch tSimpleChat
ClientCommon
OCSF
Client
<<import>>
ClientServer
206
Développer un modèle architecturalDévelopper un modèle architectural
Diagramme de composantsDiagramme de composants Offre une vue de haut niveau de l’architecture du
systèmey Utilisé pour décrire le système d’un point de vue
implémentation Permet de décrire les composants d’un système et les
interactions entre ceux-ci Illustre comment grouper concrètement et
physiquement les éléments (objets, interfaces, etc.) du système au sein de modules qu’on appellesystème au sein de modules qu on appelle composants
207
Développer un modèle architecturalDévelopper un modèle architectural Les composants et le principe de séparation des
préoccupations La séparation des préoccupation est le principe qui assure
l’intégrité fonctionnelle d’un composantl intégrité fonctionnelle d un composant Chaque composant réalise une, et seulement une, fonction au
sein du système, mais peut néanmoins exposer plusieurs méthodes Typiquement chaque composant est défini par uneméthodes. Typiquement, chaque composant est défini par une interface qui constitue son seul moyen d’interagir avec les autres composants
L’utilisation d’une interface pour communiquer avec les autres L utilisation d une interface pour communiquer avec les autres composants du système facilite la maintenance puisqu’on peut alors en changer l’implémentation sans affecter les autres composants (induit un couplage plus faible du composant aveccomposants (induit un couplage plus faible du composant avec le reste du système)
Les classes d’un composant devrait être vues comme un patron cohésif qui implémente la fonctionnalité du composantpatron cohésif qui implémente la fonctionnalité du composant
208
Développer un modèle architecturalDévelopper un modèle architectural
Construction d’un diagramme de composants Construction d un diagramme de composants Diviser pour régner
C hé i f t Cohésion forte Faible couplage
Ab t ti Abstraction Réutilisabilité Réutilisation Etc.
209
Développer un modèle architectural
Exemple d’un diagramme de composants
Développer un modèle architectural
Exemple d un diagramme de composants
210