Cours Projet de Conception OO - Mouna AYARI (1)

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






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






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


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


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 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


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


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





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


1.3. Fondements de base de la COO






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


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


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


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


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


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


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


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


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



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


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


1.4. Modélisation des relations entre les classesclasses






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


1.5. Rappel sur les diagrammes de modélisation UMLmodélisation UML






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


81


Liens entre les diagrammesg

82

Chapitre 2 Méthodologies de COO –processus unifiéprocessus unifié





Remarque: Ce document doit être complété par les notes de cours !83


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


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)






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


2.2. Processus UnifiéRational Unified Process (RUP)Rational Unified Process (RUP)






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



Besoins

Analyse

Conception

Implémentation

Tests

Itérations

It. 1 It. 2 It. nIt. n-1… … … … …

111


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


Analystesystème




Spécificateur Détailler pde use-case

Détailler use-case



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


Structurer modèle u-c.y


Spécificateurde use-case

Détailler use-case


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


Analystesystème





Détailler use-case


Prototyper

118


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


Analystesystème





Détailler use-case


Prototyper

120


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


Analystesystème




Spécificateur Dét ill Spécificateurde use-case

Détailler use-case



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



Besoins

Analyse

Conception

Implémentation

Tests

Itérations

It. 1 It. 2 It. nIt. n-1… … … … …

124


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


Architecte Analysearchitecturale


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




Analyse de use-case


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




Analyse de use-case


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




Analyse de use-case


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


Phases



Besoins

Analyse

Conception

Implémentation

Tests

Itérations

It. 1 It. 2 It. nIt. n-1… … … … …

135


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


Conceptionde use-case


Conceptionde classe

Conception desous-sytème

137






Conceptionde classe


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






Conceptionde classe


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






Conceptionde classe


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






Conceptionde classe


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


Phases



Besoins

Analyse

Conception

Implémentation

Tests

Itérations

It. 1 It. 2 It. nIt. n-1… … … … …

147


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


2.3 Méthodologie 2: Processus en Y: 2TUP (Two Track Unified Process)2TUP (Two Track Unified Process)






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


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


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


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





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


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


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


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


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


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


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


Diagramme de composants

170


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


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


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»)…


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


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


Composants et interfaces - Notationp

C d

EntréeCmdesPersonne

Commande PaiementComptes

composantinterface requise interfaces offertes

Commande<<provided interfaces>>EntréeCmdesPaiementComptes

<<required interface>>Person

177


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


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


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


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


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


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 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 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 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 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


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


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


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


Exemple d’un diagramme de composants


Exemple d un diagramme de composants

210

Documents

Cours Projet de Conception OO - Mouna AYARI (1)