DIAGRAMME DE COMPOSANT+DIAGRAMME DE DÉPLOIEMENT +Design Patterns+RUP
1. DIAGRAMME DE COMPOSANT (DCP). 1
3. DIAGRAMME DE DÉPLOIEMENT (DPL). 3
4. DIAGRAMME DE PAQUETAGE (DPA). 5
7. Une méthode simple et générique. 8
Refrences :
Ce cours est inspiré de plusieurs ressources la majorité des parties sont des copier /coller.
1. DIAGRAMME DE COMPOSANT (DCP)
Composant
Un composant logiciel est une unité logicielle autonome au sein d'un système global ou
d'un sous-système. Un composant doit fournir un service bien précis.
C'est un classeur structuré particulier, muni d'une ou plusieurs interfaces requises ou offertes.
Le diagramme de composant permet de représenter les composants logiciels d’un
système ainsi que les liens existant entre ces composants.
Les composants logiciels peuvent être de deux origines : soit des composants
métiers propres à une entreprise soit des composants disponibles sur le marché
comme par exemple les composants EJB, CORBA, .NET, WSDL.
Les diagrammes de composants représentent l'architecture logicielle du système.
Les composants peuvent être décomposés en sous-composants, le cas échéant.
Les liens entre composants sont spéciés à l'aide de dépendances entre leurs interfaces.
Le câblage interne d'un composant est spécié par les connecteurs de délégation.
Un tel connecteur connecte un port externe du composant avec un port de l'un de ses
sous-composants internes.
2. DIAGRAMME DE DÉPLOIEMENT (DPL)
Architecture matérielle
En dernier lieu, un système doit s'exécuter sur des ressources matérielles dans un environnement matériel particulier.
UML permet de représenter un environnement d'exécution ainsi que des ressources physiques
(avec les parties du système qui s'y exécutent) grâce aux diagrammes de déploiement.
L'environnement d'exécution ou les ressources matérielles sont appelés noeuds .
Les parties d'un système qui s'exécutent sur un noeud sont appelées artefacts .
Le diagramme de déploiement permet de représenter l’architecture physique supportant l’exploitation du système. Cette architecture comprend des nœuds correspondant
aux supports physiques (serveurs, routeurs…) ainsi que la répartition des artefacts logiciels (bibliothèques, exécutables…) sur ces nœuds. C’est un véritable réseau constitué
de nœuds et de connexions entre ces nœuds qui modélise cette architecture.
Nœud
Un nœud correspond à une ressource matérielle de traitement sur laquelle des artefacts seront mis en œuvre pour l’exploitation du système. Les nœuds peuvent être
i interconnectés pour former un réseau d’éléments physiques.
Artefact
Un artefact est la spécification d’un élément physique qui est utilisé ou produit par
le processus de développement du logiciel ou par le déploiement du système. C’est
donc un élément concret comme par exemple : un fichier, un exécutable ou une
table d’une base de données.
Un artefact peut être relié à d’autres artefacts par notamment des liens de dépendance.
3. DIAGRAMME DE PAQUETAGE (DPA)
Paquetage
Un paquetage regroupe des éléments de la modélisation appelés aussi membres,
portant sur un sous-ensemble du système. Le découpage en paquetage doit traduire
un découpage logique du système à construire qui corresponde à des espaces de
nommage homogènes. Les éléments d’un paquetage peuvent avoir une visibilité déclarée soit de type
public (+) soit privé (-).
Un paquetage peut importer des éléments d’un autre paquetage. Un paquetage
peut être fusionné avec un autre paquetage.
4. Design Patterns
Un concept issu de l'architecture
Christopher Alexander, architecte, dénit en 1977 les patrons de conception comme
La description d'un problème rémanent et de sa solution
Une solution pouvant être utilisée des millions de fois sans être deux fois identique
Une forme de conception, pattern, modèle, patron de conception
Ce concept attire les chercheurs en COO dès les années 80
Design Patterns of Reusable Object-Oriented
GOF : Erich Gamma, Richard Helm, Ralph Johson et John Vlissides
Addison-Wesley, 1995
Patron de conception logicielle
Un patron de conception (design pattern) est la description d'une solution classique à un
problème récurent.
Il décrit une partie de la solution. . .
avec des relations avec le système et les autres parties.
C 'est une technique d 'architecture logicielle.
Ce n'est pas
Une brique : l'application d'un pattern dépend de l'environnement
Une règle : un pattern ne peut pas s'appliquer mécaniquement
Une méthode : ne guide pas une prise de décision ; un pattern est la décision prise
Documentation d'un patron de conception
Les principaux éléments de description d'un pattern sont :
Le nom du pattern résume le problème de design.
Son intention est une courte description des objectifs du pattern, de sa raison d'être.
Les indication d'utilisation décrivent les cas où le pattern peut être utile.
La motivation montre un cas particulier dans lequel le patron peut être utilisé.
La structure est une représentation graphique des classes du modèle.
Avantages des patrons de conception
Capitalisation de l'expérience : réutilisation de solutions qui ont prouvé leur e‑cacité
Rendre la conception beaucoup plus rapide
Elaboration de constructions logicielles de meilleure qualité grâce à un niveau
d'abstraction plus élevé
Réduction du nombre d'erreurs, d'autant que les patrons sont examinés avec attention
avant d'être publiés
Communication plus aisée
Ecrire du code facilement compréhensible par les autres
Apprentissage en suivant de bons exemples
Inconvénients des patrons de conception
Nécessité d'un eort de synthèse conséquent
Reconnaître, abstraire. . .
Nécessité d'un apprentissage et d'expérience
Les patterns se dissolvent en étant utilisés
Les patrons sont nombreux (23 dans l'ouvrage du GOF, d'autres sont publiés régulièrement)
Lesquels sont semblables ?
Les patrons sont parfois de niveaux diérents : certains patterns s 'appuient sur d
'autres...
5. Mise en oeuvre d’UML
9.1 Introduction
9.1.1 UML n’est pas une méthode
Méthode = Démarche + Langage
La méthode MERISE fournit :
Un langage de modélisation graphique (MCD, MPD, MOT, MCT...)
ET Une démarche à adopter pour développent un logiciel.
UML n'est qu'un langage :
Il spécie comment décrire des cas d'utilisation, des classes, des interactions
Mais ne préjuge pas de la démarche employée.
Méthodes s'appuyant sur UML :
RUP (Rational Unied Process) - par les auteurs d'UML ;
XP (eXtreme Programming) - pouvant s'appuyer sur UML.
La problématique que pose la mise en oeuvre d’UML est simple : comment passer de l’expression des besoins au code de l’application ? Cette problématique est parfaitement illustrée par la figure 9.1.
6. Une méthode simple et générique
une méthode simple et générique qui se situe à mi-chemin entre UP (Unified Process), qui constitue un cadre général très completde processus de développement, et XP (eXtreme Programming) qui est une approche minimaliste à lamode centrée sur le code. Cette méthode est issue de celle présentée par Roques (2002) dans son livre
« UML - Modéliser un site e-commerce » qui résulte de plusieurs années d’expérience sur de nombreuxprojets dans des domaines variés. Elle a donc montré son efficacité dans la pratique et est :
– conduite par les cas d’utilisation, comme UP, mais bien plus simple ;
– relativement légère et restreinte, comme XP, mais sans négliger les activités de modélisation en analyse et conception ;
– fondée sur l’utilisation d’un sous-ensemble nécessaire et suffisant du langageUML(modéliser 80%des problèmes en utilisant 20% d’UML).
9.2 Identification des besoins et spécification des fonctionnalités
9.2.1 Identification et représentation des besoins : diagramme de cas d’utilisation
9.2.2 Spécification détaillée des besoins : diagrammes de séquence système
9.2.3 Maquette de l’IHM de l’application (non couvert par UML)
9.3 Phases d’analyse
9.3.1 Analyse du domaine : modèle du domaine
9.3.2 Diagramme de classes participantes
les dialogues, les contrôles et les entités ainsi que leurs relations.
Les classes de dialogues – Les classes qui permettent les interactions entre l’IHM et les utilisateurs sont qualifiées de dialogues. Ces classes sont directement issues de l’analyse de la maquette présentéesection 9.2.3. Il y a au moins un dialogue pour chaque association entre un acteur et un cas
d’utilisation du diagramme de cas d’utilisation de la section 9.2.1. En général, les dialogues vivent
seulement le temps du déroulemet du cas d’utilisation concerné.
Les classes de contrôles – Les classes qui modélisent la cinématique de l’application sont appelées
contrôles. Elles font la jonction entre les dialogues et les classes métier en permettant au différentes
vues de l’application de manipuler des informations détenues par un ou plusieurs objets métier.
Elles contiennent les règles applicatives et les isolent à la fois des dialogues et des entités.
Les classes entités – Les classes métier, qui proviennent directement du modèle du domaine (cf. section
9.3.1), sont qualifiées d’entités. Ces classes sont généralement persistantes, c’est-à-dire qu’elles survivent à l’exécution d’un cas d’utilisation particulier et qu’elles permettent à des données et des relations d’être stockées dans des fichiers ou des bases de données. Lors de l’implémentation, ces classes peuvent ne pas se concrétiser par des classes mais par des relations, au sens des bases de
données relationnelles (cf. section 9.5.2).
9.3.3 Diagrammes d’activités de navigation
9.4 Phase de conception
9.4.1 Diagrammes d’interaction
9.4.2 Diagramme de classes de conception
9.5 Phase d’implémentation
9.5.1 Implémentation en Java
9.5.2 Implémentation en SQL
7. Rational Unied Process
RUP est une démarche de développement qui est souvent utilisé conjointement au langage UML.
Rational Unied Process est
Piloté par les cas d'utilisation ;
Centré sur l'architecture ;
Itératif et incrémental.
RUP est itératif et incrémental
Chaque itération prend en compte un certain nombre de cas d'utilisation.
Les risques majeurs sont traités en priorité.
Chaque itération donne lieu à un incrément et produit une nouvelle version exécutable.
RUP est piloté par les cas d'utilisation
La principale qualité d'un logiciel est son utilité :
Adéquation du service rendu par le logiciel avec les besoins des utilisateurs.
Le développement d'un logiciel doit être centré sur l'utilisateur.
Les cas d'utilisation permettent d'exprimer ces besoins :
Détection et description des besoins fonctionnels ;
Organisation des besoins fonctionnels.
RUP est centré sur l'architecture
Modélisation de diérentes pespectives indépendantes et complémentaires.
Architecture en couches et vues de Krutchen.
Organisation en phases du développement
Initialisation :
Dénition du problème.
Elaboration :
Planication des activités, aectation des ressources, analyse.
Construction :
Développement du logiciel par incréments successifs.
Transition :
Recettage et déploiement.
Organisation en activités de développement
Chaque phase comprend plusieurs itérations
Pour chacune des itérations, on se livre à plusieurs activités :
Modélisation métier ;
Expression des besoins ;
Analyse ;
Conception ;
Implémentation ;
Test ;
Déploiement.
Principaux diagrammes UML par activité
Expression des besoins et modélisation métier :
Modèles métier, domaine, cas d'utilisation ;
Diagramme de séquences ;
Diagramme d'activité.
Analyse
Modèles métier, cas d'utilisation ;
Diagramme des classes, de séquences et de déploiement.
Conception
Diagramme des classes, de séquences ;
Diagramme état/transition ;
Diagramme d'activité ;
Diagramme de déploiement et de composant.