Diagrammes de PACKAGES: Structuration du modèle

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

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

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

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

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

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)

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

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

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

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

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.

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.

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

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}

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"

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.

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

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

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

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.

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)

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

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

DIAGRAMME DE CLASSES Vue interne de package

DIAGRAMME DE CLASSES Vue de synthèse (mixte)

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.

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

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

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

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)

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

STRUCTURATION DU MODELE Exemple de hiérarchie

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

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

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

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

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

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.

STRUCTURATION DU MODELE Sous-systèmes

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.

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

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

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

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.

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

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