Diagrammes de PACKAGES:

Présentation au sujet: "Diagrammes de PACKAGES:"— Transcription de la présentation:

1 Diagrammes de PACKAGES:
Structuration du modèle

2 STRUCTURATION DU MODELE Place dans le processus de développement
Besoins des utilisateurs Modélisation des cas d’utilisation Modélisation « Métier » Maquette IHM Modélisation de conception détaillée Modélisation dynamique Modélisation objet Scénarios d’utilisation Structuration Modélisation de l’architecture Modélisation des interactions Code

3 STRCTURATION DU MODELE Organiser le développement
Comment partager le travail?

4 DIAGRAMMES DE CLASSES Extrait du méta-modèle UML 1.1
client * Elément de Modèle fournisseur Nom : Nom * * * Propriété Paramètre Dépendance portée : TypeDomaine visibilité :TypeVisibilité valeurDéfaut: Expression mode : ModeTransmission généralisation sous-type 1 propriétés {ordered} Elément Généralisable * * paramètre {ordered} Généralisation racine : boolean feuile: boolean abstrait : boolean * spécialisation super-type 1 * 0..1 propriétaire Association réalisation 1 * * 1 PropriétéStructurelle spécification type PropriétéComportementale {ordered} Classifier {ordered} 2 * 1 cardinalité : Cardinalité portée : TypeDomaine * Rôle type propriété rôle type Navigable :boolean agrégation: TypeAgrég. cardinalité : Cardinalité portée : TypeDomaine 1 * 1 Attribut valeurInit: Expression Opération Méthode * spécification Interface Classe Data Type Classe Association

5 STRUCTURATION DU MODELE Retour au modèle «Géographie»
ObjetGeo base Site Itineraire ZoneGeo VolumeGeo localisation définition Territoire Region limite périphérie 3..* sommet 2..* CoordonneeGeo pointPassage 1..1 1..1 centre situation Qu’est-ce qu ’une « Coordonnée Géo » ?

6 STRUCTURATION DU MODELE Extension du modèle
La classe "CoordonnéeGéo" est en relation avec des notions liées à la Géographie. CoordonneeGeo - latitude - longitude 0..* - altitude + altitudeTerrain( ) référence 0..* fourniture d'altitude systemeGeodesique origineAltitude 1 1 MNT Ellipsoide + estimerAltitude( ) * WGS84 ED50 DegreCarre

7 STRUCTURATION DU MODELE Besoins et objectifs
Comment gérer la complexité des grands logiciels? Comment partager et distribuer le travail ? Comment planifier le développement? Comment définir la stratégie d’intégration? Comment sous-traiter certaines parties du logiciel? .... La classe d’objets est une unité trop restreinte en taille et en fonctionnalités N.B.. La plupart des langages de programmation par objets ne possèdent aucune structure syntaxique permettant de regrouper un ensemble de classes. NECESSITE DE REGROUPEMENT EN PAQUETAGES (PACKAGES)

8 DIAGRAMMES DE PACKAGES Structuration du modèle « Géographie »
AffichageGeo Symbologie ObjetsGeo Geographie

9 STRUCTURATION DU MODELE Principes généraux
Identifier les classes selon une approche descendante (Général   Détaillé) puis organiser les éléments de modèle en sous-ensembles selon une approche ascendante (Détaillé   Global). Constituer les sous-ensembles en regroupant les classes qui traitent de notions proches l ’une de l ’autre (réduction du couplage, augmentation de la cohésion). Organiser les sous-ensembles par niveaux d ’abstraction en commençant par les notions fondamentales ou essentielles puis en détaillant progressivement le contenu du modèle pour faire apparaître les notions secondaires et les cas particuliers (approche pédagogique). Rechercher un équilibre de taille entre tous les sous-ensembles d ’un même niveau d ’abstraction. Eviter de dépasser 7 2 notions par niveau d ’abstraction (règle de Miller).

10 STRUCTURATION DU MODELE Limites de la structuration hiérarchique
LA HIERARCHIE EST UN MOYEN SÛR D ’ORGANISER LES CONCEPTS, LES PRODUITS, LES MOYENS, LES HOMMES, etc. MAIS La structuration hiérarchique peut aller à l’encontre de la factorisation certaines feuilles de l ’arbre de décomposition correspondent aux mêmes notions Plusieurs types de relations hiérarchiques doivent être traités dans un même modèle Associations orientées, Agrégation/décomposition, Généralisation/Spécialisation peuvent déterminer des hiérarchies différentes sur les mêmes classes Plusieurs hiérarchies doivent cohabiter dans un même modèle hiérarchies imbriquées (modèle en couches) ou hiérarchies orthogonales (plan support ou hiérarchies parallèles) Les inter-dépendances entre notions peuvent être de nature complexe il existe des associations mutuelles entre classes d ’objets

11 STRUCTURATION DU MODELE Paquetage (Package)
De même qu’une classe est la représentation d ’un concept, un paquetage est la représentation d ’un domaine. Un paquetage est un regroupement fini d’éléments du modèle. Un paquetage peut être considéré comme la spécification d ’un domaine particulier. Paquetage Elément de Modèle 0..* 0..* Classe Association Généralisation Dépendance

12 STRUCTURATION DU MODELE Règles de structuration en paquetages
Les critères de décomposition/regroupement en paquetages ne sont pas définis à priori. Un paquetage regroupe des éléments de modèle. Un paquetage ne peut pas être instancié. Le nom d’un élément est unique pour un paquetage mais il peut exister des éléments de même nom dans des paquetages différents. Une classe appartient à un et un seul paquetage. Les éléments d ’un même paquetage doivent être cohésifs mais les éléments appartenant à des paquetages différents doivent être aussi indépendants que possible.

13 DIAGRAMMES DE PACKAGES Liens entre paquetages
Pour qu’un paquetage P1 ait accès aux classes d ’un paquetage P2, il faut qu’il existe une dépendance de P1 vers P2. Voyage Réservation Passager Passager Siège Siège 0..* 0..* 1..* 1..* réservation place Affrètement 1..1 1..1 1..1 1..1 Vol Vol Avion Avion Il y a dépendance entre P1 et P2 lorsqu’(au moins) une des classes de P2 est référencée par (au moins) une des classes de P1.

14 DIAGRAMMES DE PACKAGES Dépendances entre paquetages
Il existe 2 types de dépendances entre paquetages: Client Particulier <<import>> Fournisseur Général Importation Généralisation

15 STRUCTURATION DU MODELE Visibilités des classes
Un paquetage définit la visibilité des éléments qu ’il contient les éléments privés ne peuvent être référencés que par d ’autres éléments du même paquetage les éléments protégés peuvent être référencés par les éléments du même paquetage ou les éléments de paquetages « fils ». les éléments publics peuvent être référencés par des éléments appartenant à des paquetages « importateurs ». Avion + altitude_courante :float + cap_courant : float + train_sortie : boolean + décoller () + monter () + descendre () + virer () + atterrir () Les classes publiques constituent l’interface du paquetage: elles correspondent à des notions d ’un domaine pouvant être exploitées pour la définition d ’un autre domaine. Les autres classes (privées et protégées) constituent l’implémentation. 1..1 1..1 2..n 2..n 0..1 0..1 Moteur {private} Aile {private} Train d'atterrissage {private}

16 STRUCTURATION DU MODELE Classes importées
ObjetGeo VolumeGeo Site Itineraire ZoneGeo Base altitudeMin altitudeMax 1..1 1..1 Territoire Région rayon localisation définition limite sommet periphérie 3..* pointPassage Geographie::CoordonneeGeo Centre 2..* situation 1..1 1..1 La classe "CoordonnéeGéo" se situe dans le paquetage "Geographie"

17 STRUCTURATION DU MODELE Propriétés d ’un paquetage
Un paquetage constitue le contexte de définition de chacune de ses classes Avionique Vol Ornithologie Vol Un paquetage est un regroupement de classes dont il règle les visibilités. Le contexte d ’un paquetage permet de définir des notions et des propriétés spécifiques du domaine (noms, types, constantes, etc.) Les paquetages permettent de présenter une vue synthétique du modèle.

18 STRUCTURATION DU MODELE Utilisation des paquetages en conception
Le paquetage peut être assimilé à un MODULE. (= unité de développement et d ’intégration) Il convient de respecter certaines règles de structuration. A B A B C

19 DIAGRAMMES DE PACKAGES Vue externe
VOL PHASE ADAPTATION_TRAJ TRAJECTOIRE CALCUL_ESA VECTORISATION_OBSTACLE ENVIRONNEMENT ELEMENT_TRAJECTOIRE GEOMETRIE_ESA COUPE_HORIZONTALE METEO SEGMENT_TRAJECTOIRE OBSTACLE BALISAGE

20 STRUCTURATION DU MODELE Exemple
étape 1..* Segment Vol + heureDécollage + heureAtterrissage + distance Vol + numéro_vol + programmer () + annuler () + différer () vol origine destination lieuEscale 0..1 affectation 1..1 hôtesse employé 1..* Pilote + nombre_heure_vol + grade Hôtesse Compagnie + nom + nationalité MembreEquipage emploi Avion + modèle + numéro_série + nombreHeuresVol + état + réviser () avion_affrété pilote étape Segment Vol + heureDécollage + heureAtterrissage + distance Vol + numéro_vol + programmer () + annuler () + différer () départ arrivée affrètement fournisseur service Aéroport + ville + ouvrir () + fermer() co-pilote employé 1..* Pilote + nombre_heure_vol + grade Hôtesse Compagnie + nom + nationalité MembreEquipage emploi compagnieAérienne aéroport véhiculeAérien

21 STRUCTURATION DU MODELE Procédé de structuration
Mettre le modèle “ à plat” A B C D E B A C E D Regrouper les classes “terminales” pour chaque “branche” du modèle. Regrouper les classes en utilisation mutuelle. Regrouper les classes se rapportant aux mêmes notions (héritage). Construire la structure des schémas.

22 DIAGRAMMES DE PACKAGES Représentation des paquetages
Chaque paquetage peut faire l ’objet d ’un ou plusieurs diagrammes séparés. Un paquetage peut être formalisé dans son contexte hiérarchique (vue externe) dans son contenu (vue interne)

23 DIAGRAMMES DE PACKAGES Hiérarchie (1)
ObjetsGeo:: ObjetGeo Calque FenetreGeo 0..* 1..* Fond 1 fondCourant support surcharge theme * Symbologie :: SymboleGraphique Representation entiteRepresentee forme affichage semantique Carto Image AffichageGeo ObjetsGeo Symbologie SymboleGraphique Icone FigureGeometrique Polygone Cercle Polyligne

24 DIAGRAMMES DE PACKAGES Vue externe
systeme de mise sous vide groupe canalisation enceinte dispositif mise VidePrimaire à l'air dispositifs de vide

25 DIAGRAMME DE CLASSES Vue interne de package

26 DIAGRAMME DE CLASSES Vue de synthèse (mixte)

27 STRUCTURATION DU MODELE Hiérarchie d ’inclusion des paquetages
Un paquetage peut regrouper plusieurs paquetages se rapportant à un même thème (paquetage « façade ») Un paquetage « façade » peut se décomposer en paquetages et en classes. On dit qu’un paquetage P1 dépend d’un paquetage P2 si P1 ou l ’un des éléments qu ’il contient dépend de P2 ou l ’un des éléments qu ’il contient. En conception de logiciel, la structuration des paquetages « façades » n ’est pas nécessairement soumise aux mêmes règles hiérarchiques que celle des paquetages de classes.

28 STRUCTURATION DU MODELE Hiérarchie (2)
IHM SYSTEME Carto VISUALISATION GEO Geographie AffichageGeo ObjetsGeo Symbologie

29 STRUCTURATION DU MODELE Architecture Pattern: modèle « en couches »
Applications <<layer>> Objets Métiers Objets techniques Système & Interface Applications opérationnelles = IHM Noyau « Métier » = Objets et procédures du domaine Noyau « Technique » = encapsulation de COTS ou de « briques de base » Interfaces Système = interactions avec les sous-systèmes et équipements

30 STRUCTURATION DU MODELE Architecture Pattern: modèle « 3-tier »
acquisition consultation noyau IHM traitement Image production visualisation banque de données Image annuaire gestion des droits Services Utilisateurs Services Métier Services Données

31 STRUCTURATION DU MODELE Architecture statique: Exemple
gestionDialogueHM (from Applications) administration préparationMission (from Applications) (from Applications) commandeCtrlVol (from Applications) commandeCtrlCU exploitationDonnees (from Applications) (from Applications) mission systemeSurveillance (from Objets Métiers) (from Objets Métiers) renseignement (from Objets Métiers) imagerie environnement (from Objets Métiers) (from Objets Métiers) gestionDonnées communication visuCartoGeo (from Objets techniques) (from Objets techniques) (from Objets techniques) communicationExterne InterfacePorteur InterfaceCapteur (from Systeme & Interface) (from Systeme & Interface) (from Systeme & Interface) systemeExploitation (from Systeme & Interface)

32 STRUCTURATION DU MODELE Exemple de structure « métier »
L05 S/S SPOT5 (from Logical View) traitements sousEtapesSPOT parametres modeles referentielTerrestre images satellites ephemerides

33 STRUCTURATION DU MODELE Exemple de hiérarchie

34 STRUCTURATION DU MODELE Extrait du Méta-modèle UML 1.1
GeneralizableElement (from Core)

35 STRUCTURATION DU MODELE Approche globale de structuration
Si le domaine à modéliser ne peut être analysé d ’un seul bloc, identifier et délimiter les paquetages « façade » selon une approche globalement descendante. Pour chacun des paquetages identifiés, recenser les classes et ébaucher un premier modèle « synthétique  ». Organiser les classes en paquetages en regroupant les classes se rapportant à des notions proches l ’une de l ’autre, isolant les parties terminales du modèle respectant les principes de hiérarchie limitant le nombre de classes par paquetage précisant les caractéristiques des classes et les liens entre classes recherchant la meilleure solution par rapport aux exigences de développement (modularité, répartition du travail, planning, etc..)

36 STRUCTURATION DU MODELE Suppression des utilisations mutuelles
Il faut s ’efforcer de limiter toute utilisation mutuelle entre classe. C1 C2 L ’utilisation mutuelle entre 2 classes de 2 paquetages distincts est proscrite car elle induit une utilisation mutuelle entre paquetages (ce qui est contraire au principe de hiérarchie). On peut toujours éviter l’utilisation mutuelle entre classe sans perte d ’information... C’2 C2 C’1 C’2 C2 C1 C2 C1 C1

37 STRUCTURATION DU MODELE Exemple de transformation
Coordonnée SymboleGraphique 1..1 0..* position objet_à_afficher ObjetGraphique Symbole position 1..1 Coordonnée 0..* objet_a_afficher

38 STRUCTURATION DU MODELE Autre exemple
Avion Aeronautique::Pilote 0..1 conducteur Avionique::Avion avion_affreté Vol 1..1 Pilote pilote_affecté Avionique Aéronautique Avionique Avion Aéronautique VehiculeAérien avion_affreté Vol 1..1 Pilote 0..1 pilote_affecté conducteur Aéronautique::VehiculeAérien

39 STRUCTURATION DU MODELE Autres types de paquetages
paquetage « Façade » Ne contient aucun élément propre mais permet de référencer les éléments de modélisation d ’autres paquetages. Il peut être utilisé pour fournir une « vue publique » du contenu de plusieurs paquetages. paquetage « Stub » Représente un paquetage qui n ’est pas totalement décrit. Un « Stub » définit spécifiquement la partie publique du paquetage sans rien d ’autre. paquetage « Système » Représente une collection de modèles qui se rapportent tous à un même système. C ’est le plus haut niveau de spécification du système. Un système peut se décomposer en sous-systèmes (i.e. un paquetage « système » peut contenir d  ’autres paquetages « système ») paquetage « Framework » Représente un « pattern » regroupant des ensembles de classes se rapportant à une collaboration et pouvant être réutilisées d ’application en application.

40 STRUCTURATION DU MODELE Sous-systèmes

41 QUELQUES RECOMMANDATIONS Identification des paquetages de classes
Un paquetage est un regroupement cohérent de classes. (notions communes aux différentes classes). Un paquetage ne devrait pas contenir plus de 7  2 classes (théoriquement) . Dès qu’un groupe de classes sans dépendance mutuelle avec d’autres groupes de classes a été déterminé, il est possible de définir un paquetage . La structure hiérarchique des paquetages correspond généralement à la structure globale de l’application. Un paquetage est une unité modulaire. Il doit être possible de remplacer un paquetage par un autre ou d’ajouter un nouveau paquetage dans le cadre d’une évolution ou d’une adaptation.

42 DIAGRAMMES DE PACKAGES Structuration des cas d’utilisation
Les cas d ’utilisation peuvent être associés à l ’ensemble du modèle à un paquetage à une classe Ils peuvent être organisés en paquetages lorsqu’ils sont nombreux pour délimiter des domaines pour les isoler des classes pour travailler en équipe

43 DIAGRAMMES DE PACKAGES Architecture fonctionnelle et cas d ’utilisation
Segment Sol Elaboration produits Diffusion Météorologue Diffusion Traitement Contrôle Qualité Emission/Réception Acquisition Archivage Visualisation Réception des TM Satellite Emission des TC Supervision Opérateur Centre de Mission Contrôle Suivi Programmation

44 DIAGRAMMES DE PACKAGES Exemple d ’architecture fonctionnelle
Recherche Administration des données Traduction Gestion de la Sécurité Administration du système Saisie des

45 QUELQUES RECOMMANDATIONS Itération et affinage
Un modèle est rarement correct à l’issue de la première formalisation. L’introduction d’un nouveau phénomène ou la prise en compte d’une nouvelle propriété peut amener une remise en cause importante du modèle. Un modèle doit, systématiquement, être soumis aux commentaires et critiques de personnes n’ayant pas participé à son élaboration. Une bonne façon d’éprouver un modèle est de l’envisager suivant différents points de vue. Un bon modèle est facile à implémenter et performant du point de vue de son “fonctionnement” mais il doit rester proche de la sémantique du domaine couvert. L’expérience et la communication sont les deux principaux ingrédients d’une bonne modélisation.

46 QUELQUES RECOMMANDATIONS Guide de style
Le nom de classe doit être centré dans le rectangle qui la représente. Le nom de classe doit commencer par une lettre majuscule. Les noms d ’attributs et d ’opérations doivent être cadrés à gauche dans le rectangle qui les contient. Les noms d ’attributs et d ’opérations doivent commencer par une lettre minuscule. La notation « hongroise » peut être utilisée pour tous les noms. (Exemples: CompteBancaire, monCompte, calculerSolde(), etc.)

47 Exercice Structurer le modèle du jeu d’échec et modéliser les packages de classes techniques