UML, UML2, SysML Application à la modélisation des systèmes

Présentation au sujet: "UML, UML2, SysML Application à la modélisation des systèmes"— Transcription de la présentation:

1 UML, UML2, SysML Application à la modélisation des systèmes
Yann Pollet Conservatoire National des Arts et Métiers Chaire d ’intégration des systèmes

2 Plan Historique d’ UML Profils, extensibilité
Rappels des diagrammes UML 1.x Synthèse et utilisation d’UML en Ingénierie des Systèmes La nouvelle version : UML2 Le langage SysML

3 Qu’est qu’UML? « UML (Unified Modelling Language) est un langage graphique permettant de représenter, spécifier, construire, et documenter les artefacts liés au développement d’un système à logiciel prépondérant UML propose une manière standard de représenter l’ensemble des éléments liés à la conception, depuis les aspects conceptuels avec les processus métier et les fonctions système, jusqu’aux éléments concrets tels que les structures de contrôle, les schémas de base de données, ou encore les composants logiciels réutilisables » Object Management Group

4 Qu’est ce qu’UML? (2) Une notation unifiée standardisée par l’OMG
UML est un langage. Il ne spécifie ni méthodologie ni processus de développement Il peut être utilisé de multiples manières comme support à une méthode (Ex : Rational Unified Process) Il possède certaines caractéristiques d’extensibilité pour s’adapter à des domaines plus spécifiques Une notation unifiée standardisée par l’OMG

5 Principales étapes 2004 UML 2.0 2003 UML 1.5 4 révisions
Janvier 1997 UML 1.0 UML 0.9 Octobre 1995 Modèle unifié 0.8 Booch’93 OMT-2 Autres méthodes Booch’91 OMT-1 OOSE Partenaires Rambaugh Jacobson

6 Les différents diagrammes Extensibilité et Profils
Synthèse UML 1.x Les différents diagrammes Extensibilité et Profils

7 Les différents types de diagrammes
UML 1.x Diagrammes d’implémentation Diagrammes d’interaction Cas d ’utilisation diagrammes de séquences diagrammes de composants diagrammes d’activités diagrammes de classes diagrammes de collaboration diagrammes d’objets diagrammes de déploiement diagrammes d’états diagrammes de paquetage

8 Les composants du langage UML
Cas d’Utilisation : interaction usager –système, autres interactions, limites du système, exigences Visions contextuelle et fonctionnelle Diagrammes de Classes, ou « logique » : entités qui constituent le système Vision structurelle Statecharts, Activités : évolution au cours du temps, flot d’activités Vision dynamique Diagrammes d’Interaction ou de Communication : comment les éléments (objets) vont interagir Vision dynamique Implémentation : logiciel qui va constituer le système Vision organique

9 Extensibilité du langage
Profils, stéréotypes, valeurs étiquetées

10 Profils et extensions Langage générique besoin :
Adaptation aux différentes phases d’un projet Adaptation à des domaines d’applications Lien avec des technologies spécifiques Adaptation par des mécanismes d’extension   Utilisation des « Profils » : Fournir des terminologies adaptées Apporter une syntaxe et des notations graphiques spécialisées Rendre compte d’une sémantique plus précise Ajouter des contraintes Ajouter des informations pour faciliter la transformation vers d’autres modèles

11 Profils Profils « standards » :
UML profile for CORBA UML profile for Enterprise Application Integration UML profile for Enterprise Distributed Object Computing UML profile for System Engineering ….. Définition de nouveaux profils  trois mécanismes d’extension : Stéréotypes Valeurs étiquetées (« Tagged values ») Contraintes Présentation sous forme de packages

12 Stéréotypes Sémantique plus spécifique donnée à un élément de modèle
Désignation spécifique (<< nom >>) Attributs et opérations Liste de contraintes afférentes à son utilisation Possibilité de nouvelle notation graphique

13 <<Acteur>>
Stéréotypes (2) Permet d’ajouter de nouvelles classes d’éléments de modélisation par classification. Respecte la structure d ’un élément défini dans le méta-modèle UML mais lui attache une autre sémantique. Ajout de nouvelles classes d’éléments de modélisation, en plus du noyau prédéfini par UML. Exemple : « acteur » = stéréotype de classe <<Acteur>> Opérateur Opérateur - login - login - password - password + se_loger() + entrer_cmd (cde: Cmd) + se_loger() + entrer_cmd (cde: Cmd) Opérateur

14 Valeurs étiquetées Couples (nom, valeur) associées à un élément du modèle Possibilité d’attacher des propriétés et des informations supplémentaires Intégré dans un symbole de commentaire

15 Contraintes Relations ou assertions qui doivent être vérifiées entre éléments de modèle Chaîne de texte placée entre accolades {contrainte} Expression en texte libre ou de manière formelle en langage OCL (Object Constraint Language)

16 Rappel sur les diagrammes UML 1.x

17 Les Cas d’Utilisation

18 Les Cas d ’Utilisation (Use Cases)
Formalisés par Ivar Jacobson Destinés à l ’expression du besoin Donnent une vision « fonctionnelle externe » du système (contexte) Centrés sur les utilisateurs Formalisme très simple Proche de la notion de Fonction de service Peuvent également servir à la conception des tests de validation

19 Concepts de base ACTEUR CAS D ’UTILISATION
représente un rôle joué par une personne ou une chose qui interagit avec le système mais qui lui est extérieure est caractérisé par un nom qui exprime son rôle une même personne physique peut être modélisée par plusieurs acteurs un acteur représenter plusieurs personnes physiques CAS D ’UTILISATION unité fonctionnelle cohérente assurée par un système ou une classe correspond à un certain type d’interaction entre le système et les acteurs doivent être vus comme des classes dont les instances sont des scénarios ou Usager <<actor>> Autre Système Consulter solde compte

20 Exemple : diagramme de contexte statique du GAB
0..1 1..1 <<actor>> SA Visa Porteur de CB GAB 0..1 1..1 <<actor>> SI Banque Client de la banque 0..1 Porteur de CB Note : « Porteur de CB » et « Client de la banque » sont mutuellement exclusifs Opérateur de maintenance Client de la banque

21 Exemple Distributeur de billets SI Banque Client Technicien Paquetage
regroupe des éléments de modélisation Acteur secondaire Distributeur de billets Nature de l ’interaction <<actor>> SI Banque Consulter solde compte visualise Client Retirer de l ’agent Le technicien éteint le distributeur avant de ravitailler le coffre débite Mettre en marche / arrêter Acteur personne ou système externe à l ’origine d ’une interaction avec le systèmes Technicien Ravitailler le coffre On ne peut retirer de l ’argent que dans la limite du stock Cas d ’utilisation objectif du système motivé par un besoin

22 Liens entre cas d ’utilisation
Trois types de liens entre cas d’utilisation : Extension (<<extends>>) : comportement optionnel du système (variation d’un comportement « normal ») Inclusion (<<includes>>) : un cas intègre le comportement d’un autre (raffinement ou factorisation) Utilisation (<< uses>>) : spécialisation avec héritage (ajout ou remplacement de comportement) Extends ou uses utilisent l’idée de factorisation, mais : Dans l’extension, un acteur réalise le cas de base et ses extensions Dans l’utilisation, il n’y a pas en général d’acteur associé au cas commun

23 Exemple

24 Exemple (2) <<includes>> Virement Identification
Client distant <<uses>> Virement par internet Virement au guichet Client au guichet

25 Cas d ’utilisation et scénarios
Un scénario est une série d ’événements ordonnés dans le temps, simulant une exécution particulière du système Pour chaque cas d ’utilisation, il existe un ou plusieurs scénarios dont la description permet d ’expliciter le comportement du système pour une situation donnée. téléphoner Appelant communication directe ligne occupée sans réponse communication par répondeur ligne en dérangement etc... Appelé Description de chaque scénario : Informelle (texte) Semi-formelle (diagramme)

26 La description des cas d’utilisation
Description textuelle (informelle) :  Use case : “ Retrait en espèce ” : Le guichetier saisit le n° de compte du client L’application valide le compte auprès du système central L’application demande le type d’opération au guichetier Le guichetier sélectionne un retrait d’espèces de 200F Le système “ guichetier ” interroge le système central pour s’assurer que le compte est suffisamment approvisionné Le système central effectue le débit du compte Le système notifie au guichetier qu’il peut délivrer le montant demandé

27 Transition vers les objets
La réalisation d ’un cas d ’utilisation nécessite la collaboration de plusieurs objets Chaque objet de la collaboration participe à la réalisation des scénarios. Chaque scénario peut être décrit par rapport aux interactions entre les objets de la collaboration à travers un diagramme de collaboration ou un diagramme de séquence

28 Les diagrammes de classes

29 Objectifs des Diagrammes de classes
Représenter les « objets » clés du domaine, déterminer le modèle du domaine (validé par le client)  modèle de classe de conception Détailler les classes qui apportent la solution technique au problème  modèle de classes technique modélise la structure des données du problème et les fonctions qui s ’appliquent à celles-ci identifier les liens de « service » entre classes

30 Attributs et opérations
Nom-de-classe attribut : type [= valeur] …... méthode (arguments : type [=défaut], …) : type de retour Nom-de-classe ou Nom-de-classe + attribut public # attribut protégé - attribut privé attribut de classe + opération publique () # opération protégée () - opération privée () opération de classe () Visibilité Public (+) : élément visible de tous les clients de la classe Privé (-) : élément interne Protégé (# ): élément visible des sous-classes seulement Souligné : attributs et méthode de classe Visibilité « + » par défaut

31 Définition de classe : exemple
Assuré numéro Assuré : Entier nom : Chaîne de caractères prénom : SetOf Chaîne de caractères date de naissance : Date date de souscription : Date contrat : type contrat = Régime de base Souscrire (type_contrat) Modifier(nouveau type _contrat) Résilier()

32 Les associations Une association binaire définit un lien de service entre les instances de deux classes Classe A Classe B Rôle A Rôle B Associe > Une instance de la classe A resp. B) utilisera des services / propriétés réalisées par des instances de la classe B (resp. A)  Une instance de la classe A (resp. B) aura une ou plusieurs références sur des instances de la classe B (resp. A) Une association possède deux rôles (formes nominale) et/ou un nom d ’association (forme verbale)

33 Les associations : exemple
Université Personne Employeur Étudiant Établissement Enseignant ou < Étudie dans Université Personne Emploie > Deux types de qualification non exclusifs en principe Attention à la multiplicité des associations entre classes : un seul lien même si les instances communiquent via l ’appel de plusieurs méthodes! Ex : Personne.getNom(), Personne.getDateNaissance() appelés depuis une instance d ’université  un seul lien

34 Associations : nom et rôles
Le nom de l’association évoque sa raison d’être mais ne fournit pas d ’information à propos des instances concernées œuvre est-écrit-par > auteur Livre Ecrivain L ’association peut être détaillée par les rôles Le rôle permet d ’exploiter les liens entre instances Ecrivain 1..1 précédent suivant ordre alphabétique

35 Classe-association Attributs liés à une association (dépendent fonctionnellement des deux classes liées à la fois)  association porteuse d ’attributs Client Code-client {id} ... Produit Code-produit {id} ... porte sur > Commande Numéro-cmde {id} ...

36 Cardinalités des associations
La CARDINALITE ( ou MULTIPLICITE) d ’une association est le nombre d ’instances mises en jeu pour une classe dans le lien avec chaque instance de l ’autre classe On précise généralement la cardinalité minimum et la cardinalité maximum 1..1 : exactement 1 0..* : 0, 1 ou n 0..1 : optionnel 1..4 : spécifié numériquement all : toutes les instances de la classe Femme Homme marié à > 0..1 Roue Automobile 4 1 Manager Projet < affecté à 1..* Ministre Administrés < gouverne all possède >

37 Orientation d’une association (navigabilité)
L’orientation des associations fournit un sens de navigation dans le graphe de classes Elle détermine les utilisations entre classes (dépendances) Vol numéro heure_décollage destination heure_atterrissage Avion capacité immatriculation 1..1 0..* < affrété pour Une association peut être mutuellement orientée (pas de flèche) Automobile Personne 1..1 0..* possédé par >

38 Contraintes sur les associations
1 défini par > 2..* Itinéraire CoordonneeGeo pointPassage {ordonnée} 1..* a réservé sur > 0..* Vol Passager {sous-ensemble} 1..* est abonné sur > 0..* 1 enseignant * Personne Université {ou-exclusif} 0..* étudiant *

39 Restriction d ’association (qualification)
contient > Avion Siège 1 * numéro Pour réduire la cardinalité à 1 ... contient > Avion numéro Siège 1 1 numéro « Un avion contient 1 seul siège pour un numéro donné » … ou à plusieurs : contient > Avion rangée Siège 1 4 rangée numéro « Un avion contient 4 rangées pour un numéro donné»

40 Agrégation Association non symétrique : une des classes joue un rôle prédominant par rapport à l ’autre Equipe 0..1 sélection > 22 Caractéristiques : les objets d ’une classe « font partie » d ’un objet d ’une autre classe les valeurs d ’attributs d ’une classe se propagent au niveau des objets d ’une autre classe une action sur un objet d ’une classe implique une action sur les objets d ’une autre classe les objets d ’une classe sont subordonnés aux objets d ’une autre classe Joueur

41 Composition Obj1 Obj2 Composition : forme particulière d ’agrégation
Lorsqu’il y a une relation de composition entre deux classes, l ’existence de la classe composante est conditionnée par celles des instances de la classe composée (durée de vie) 0..1 1..1 1..1 Automobile Moteur 1 1..* 1..* 1..1 1..1 Cylindre Carburateur

42 Généralisation / spécialisation
Véhicule Aérien poids nbre_maxi_passagers decoller( ) voler( ) Modèle de vol rayon de virage altitude maximum vitesse de 1..1 comportement Avion atterrir() Hélicoptère voler() Satellite L ’ensemble des instances possibles d ’une classe héritière est inclus dans l ’ensemble des instances possibles de sa classe mère Toutes les propriétés définies pour une classe demeurent vraies pour ses classes héritières L ’héritage définit toujours des relations d ’inclusions entre classes par ajoutou précision des propriétés des classes mères

43 Contraintes de spécialisation
Avion Motorisation ContexteUtilisation {inclusif} AvionReaction AvionHelice AvionMilitaire AvionCivil Personne {exclusif} Homme Femme Language de programmation {incomplet} Pascal C++ Java COBOL

44 Les diagrammes d ’objets

45 Les diagrammes d ’objets
But : mettre en évidence des liens entre instances utilise les mêmes concepts que les diagrammes de classes utilisés pour illustrer des parties complexes d ’un diagrammes de classes PC : Produit :Fournisseur 1..1 f_principal > f_secours > Trois formes pour nommer un objet : nom_objet nom_objet : nom_de_classe : nom_de_classe (objet quelconque de la classe)

46 Les diagrammes de paquetage

47 Les paquetages Groupement de classes au sein d ’une même unité modulaire  découpage (« packages ») fonctionnel : attribution à différentes équipes structurel : regroupement de classes ayant un lien logique opérationnel : classes liées à un cas d ’utilisation pratique : contrainte de modularité Espace de noms ObjetGeo Site situation Territoire Itineraire Region CoordonneeGeo localisation sommet limite pointPassage centre 1..1 définition périphérie VolumeGeo ZoneGeo base nom-de-paquetage

48 Emboîtements et dépendances
Tout élément appartient à un paquetage Un paquetage peut comprendre d ’autres paquetages On peut définir des relations de dépendances entre paquetages le paquetage de plus haut niveau est le paquetage « racine » du modèle paquetage 1 paquetage 2

49 Visibilité des classes
Un paquetage contient en général: des classes visibles : interface des classes internes invisibles de l ’extérieur : implémentation P On définit la visibilité individuelle de chaque classe par la propriété public (+) ou implementation (-) P Classes d ’interface Classes d ’implémentation

50 Dépendances entre paquetages
Dépendance entre paquetages = au moins une classe du paquetage client utilise les services offerts par au moins une classe du paquetage fournisseur entraîne une relation d ’obsolescence la notation nom-de-paquetage::nom-de-classe permet de désigner une classe utilisée dans un autre paquetage (élément importé) classe exportée P1 utilisation P2 client fournisseur réalisation dépendance

51 Dépendances 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 dans (au moins) une des classes de P1.

52 Dépendances entre paquetages (2)
Deux types de dépendances entre paquetages Client Particulier <<import>> Fournisseur Général Importation Généralisation

53 Interface BD {abstrait}
Paquetages abstraits Un paquetage peut être défini {abstrait} pour préciser qu ’il définit uniquement une interface implémentée par un paquetage spécialisé Ex : Interface Oracle Interface BD {abstrait} Interface MySQL

54 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 paquetage « fils » les éléments publics peuvent être référencés par des éléments appartenant à des paquetage« 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}

55 Services Applicatifs et Objets du Domaine SYSTEME D'EXPLOITATION
Macro-Architecture COUCHE INTERFACE OPERATEUR Tableau de Bord Application n <<facade>> Application 2 Administration POP Interface_Operateur Application 1 COUCHE FEDERATRICE <<facade>> Domaine_Applications Services Applicatifs et Objets du Domaine Logiciels communs <<facade>> Logiciels_Communs COUCHE D'INTERFACE SYSTEME I/F SOUS-SYSTEMES I/F SOUS-SYSTEMES I/F MATERIEL I/F LOGICIEL I/F SOUS-SYSTEMES I/F SOUS-SYSTEMES I/F SOUS-SYSTEMES I/F SOUS-SYSTEMES <<facade>> Interface_Systeme SYSTEME D'EXPLOITATION

56 Synthèse sur les classes et les paquetages
Différence fondamentale entre classes et paquetages : les classes sont des abstractions du problème ou de la solution. Les paquetages sont simplement des mécanismes utilisés pour organiser le modèle la structure d ’organisation en paquetage doit être contrôlée (hiérarchie) le paquetage est l ’unité élémentaire d ’importation (librairie) et de réutilisation les tests d ’intégration peuvent être menés paquetage par paquetage

57 Les diagrammes d ’interaction
Diagrammes de séquences Diagrammes de collaboration

58 Dynamique, comportement
Les diagrammes UML Deux catégories de diagrammes : Statique (structure) Dynamique, comportement Diagramme de cas d'utilisation Diagramme de classes Diagramme à objet Diagramme de composants Diagramme de déploiement Diagramme de collaboration Diagramme de séquence Diagramme état/ transition Diagramme d'activités

59 Diagrammes d ’interaction
Modèles qui décrivent comme des groupes d ’objets collaborent pour la réalisation d ’un comportement global un diagramme d ’interaction schématise le comportement d ’un cas d ’utilisation ou d ’un scénario un diagramme montre les objets impliqués et les messages importants transmis entre les objets pour ce scénario deux formes alternatives (et équivalentes) : le diagramme de séquence et le diagramme de collaboration

60 Diagramme de collaboration
met en évidence les interactions entre différents objets du système extension des diagrammes d ’objets : Unité Centrale : Souris : usager 1: deplacer 2: calculer_position : Ecran 3: positionner_curseur Montre : la structure statique de la collaboration (objets et liens) les interactions entre objets (messages échangés)

61 Exemple : PannneauEditeur : Usager : FenetreGeo : Representation
1: selectionnerSymbole (Symbole) : PannneauEditeur 2: selectionnerCouleur (Couleur) : Usager 3: declencherEdition (ModeEdition) 4:*designerPoint (Coord) : FenetreGeo 7: terminerSaisie ( ) 8: create (SymboleGraphique) 5: create ( ) 6: afficher ( ) : Representation : SymboleGraphique 9: create ( ) : ObjetGeo

62 Diagrammes de séquence
Les diagrammes de séquences montrent les interactions entre objets selon un point de vue temporel. téléphone_appelant : Ligne_ téléphone_appelant : Téléphone téléphonique : Téléphone : Appelé : Appelant décrocher ( ) se_connecter ( ) émettre_tonalité ( ) recevoir_tonalité ( ) composer_numéro( ) établir_liaison ( ) indiquer_sonnerie ( ) sonner ( ) décrocher ( )

63 Exemple : Poignée : Câble : Etrier : Roue : Cycliste 1: tirer ( )
freiner pédaler Cycliste tourner Bicyclette Guidon + freiner() + tourner (angle) Roue + tourner () Système de Freinage + bloquer () Poignée Câble Etrier + tirer () + tendre () + serrer () : Poignée : Câble : Etrier : Roue : Cycliste 1: tirer ( ) 2: tendre ( ) 3: serrer ( ) 4: bloquer ( )

64 Diagrammes d’interaction
 Exemple de diagramme de séquence Guichetier Système guichet Système central Saisie compte Validation compte Demande type d’opération Retrait liquide (220F) Vérification solde compte Débit compte Autorisation délivrance t  Exemple de diagramme de collaboration Système guichet Guichetier Système Central (1) Saisie compte (2) Validation compte (3) Demande type d’opération (4) Retrait espèces (200F) (5) vérification solde compte (6) Débit compte (7) Autorisation délivrance

65 2 façons de modéliser un scénario en UML
Diagrammes d ’interaction 2 façons de modéliser un scénario en UML Diagramme de collaboration ou Diagramme de séquence 1: décrocher ( ) : Appelant 5: composer_numéro( ) : Appelé : Appelant 4: recevoir_tonalité ( ) téléphone_appelant : Téléphone : Ligne_ téléphonique téléphone_appelant : Téléphone téléphone_appelant : Téléphone décrocher ( ) 2: se_connecter ( ) 3: émettre_tonalité ( ) se_connecter ( ) 6: établir_liaison ( ) émettre_tonalité ( ) 7: indiquer_sonnerie ( ) recevoir_tonalité ( ) : Ligne_ téléphonique composer_numéro( ) établir_liaison ( ) 8: sonner ( ) indiquer_sonnerie ( ) sonner ( ) : Appelé téléphone_appelant : Téléphone décrocher ( ) 9: décrocher ( )

66 Diagramme de séquence * Objet : Classe période d ’activité
: Acteur Objet : Classe période d ’activité appel_de_méthode() retour () nouveau : Classe appel_de_méthode2() création d ’objet message_asynchrone () new () [x>0] message_gardé() [x<0] autre_message() * itération () autodélégation destruction d ’objet ligne de vie

67 Contraintes temporelles
: Appelant : Ligne_ téléphonique : Appelé téléphone_appelant : Téléphone décrocher ( ) composer_numéro( ) se_connecter ( ) émettre_tonalité ( ) recevoir_tonalité ( ) établir_liaison ( ) indiquer_sonnerie ( ) sonner ( ) a b c d d’ {b - a < 1 sec.} {c- b < 10 sec.} L ’appel est routé à travers le réseau { d ’ - d < 5 sec.} A ce stade les 2 interlocuteurs peuvent communiquer

68 Formes d ’interactions
appel de méthode simple retour de méthode (optionnel) appel avec délai de transmission envoi de message asynchrone message gardé par une condition : [condition] itération : * contraintes de délai. Ex : {b - a < 1s} périodes d ’activité d ’un objet autodélégation (empilement des activations) objet actif objet : Classe

69 Diagramme de séquence Deux utilisations :
documentation des cas d ’utilisation : description de l ’interaction dans les termes de l ’utilisateur distinction flot de donnée - flot de contrôle en général pas opérée représentation précise des interactions entre objets logiciels passage de la première représentation (externe) à la deuxième (interne)

70 Exemple 1 L ’opérateur reçoit un message contenant une
:Editeur de Situation :Serveur de Renseignement :Editeur de Compte-Rendu :Messagerie :Capteur :Préparation Mission :Opérateur NCGS L ’opérateur reçoit un message contenant une demande de renseignement sur la situation courante ® lire_messages_reçus() Il élabore la situation demandée ® élaborer_situation () extraire_situation() le renseignement est sélectionné ® aucun renseignement n ’étant disponible, l ’opérateur envisage la planification d ’une nouvelle mission ® demander_nouvelle_mission() il émet un ordre de mission ® planifier_mission() lorsque la mission est terminée, les données brutes sont mises à disposition par le sous-système d ’exploitation ®. fournir_données_brutes() L ’opérateur peut maintenant élaborer le renseignement demandé ®. élaborer_renseignement() un nouveau renseignement est enregistré dans la base® enregistrer_renseignement() l ’opérateur met à jour la situation courante pour visualiser les nouveaux renseignements mis à disposition.® Mettre_a_jour_situation() une nouvelle situation est extraite de la base pour comparaison avec la précédente ® extraire_situation() . L ’opérateur édite et précise la situation en ajoutant de nouvelles informations® editer_situation() un nouveau renseignement est élaboré ® elaborer_renseignement() l ’opérateur valide la situation ® valider_situation() ceci provoque l ’enregistrement de la nouvelle situation, ® enregistrer_renseignement() la génération de données formatées représentant la situation, ® formater_données () la réponse de l ’opérateur à la demande de renseignement. ® répondre() il attache les données formatées à sa réponse ® attacher_données() il valide la réponse pour la transmettre au demandeur ® valider_message()

71 Exemple 2 Gestion Centralisée Gestion distribuée
Modélisation des scénarios correspondant à différentes implémentations possibles Gestion Centralisée centralDir:Theater_Directory :CommunicationServer Le commandement crée une nouvelle mission et met à jour l ’annuaire du théâtre dont il est responsable® :Commandment :NCGS_Operator update() L ’opérateur de la NCGS accède aux informations de l ’annuaire de théâtre en s’y connectant à travers le réseau. ® remote_connect_to_dataserver() Gestion distribuée centralDir:Theater_Directory :CommunicationServer localDir:Theater_Directory Le commandement crée une nouvelle mission et met à jour l ’annuaire du théâtre dont il est responsable® :Commandment :NCGS_Operator update() Le contenu de l ’annuaire est exporté dans un fichier® export_data() Le fichier central est transféré vers la NCGS® transfer_file() L ’opérateur de la NCGS importe les données dans son anuuaire local et peut y accéder sans restriction®. import_data()

72 Comparaison diagramme de séquence - diagramme de collaboration
Équivalence entre les deux formes de représentation diagramme de séquence : aptitude à montrer l ’ordre dans lesquels les choses se produisent diagramme de collaboration : aptitude à visualiser les interconnexions entre objets avec flux d’information utilisation pour : la documentation des cas d ’utilisation description des interactions entre objets

73 Les diagrammes d ’Etats ou Statecharts

74 Diagrammes d’états Notation UML pour les Statecharts de Harel
Modélisation de la dynamique d’un système complet, d’un sous-système, ou d’un objet d’une classe donnée, en réponse aux sollicitations d’autres objets une transition représente un passage supposé instantané d ’un état vers un autre deux états prédéfinis : État initial et État final ©Yann POLLET

75 Transitions Spécification de transition : 3 parties optionnelles
Nom-événement [garde] / Action Événements : externes : échanges entre objets internes : émis et reçus au sein du même objet 4 types d ’événements : appel : invocation synchrone d ’un objet temporisation satisfaction de condition un transition peut ne pas avoir d ’événement associé (déclenchée lors d’une fin d ’activité, état fugitif) evt [cond] / Act Etat1 Etat2 ©Yann POLLET

76 Exemple Diagramme d ’états d ’une classe Police d ’assurance
En souscription Abandonnée En cours Résiliée Suspendue Refus client Délai expiré Signature client Demande client (résiliation) Demande client (suspension) Trop de sinistres Date fin suspension Demande client (fin suspension)

77 Transitions (2) Garde ou condition :
Une transaction peut être conditionnelle la condition porte sur des informations accessibles de l ’objet : paramètres, attributs les gardes doivent être mutuellement exclusives En cours Résiliée Sinistre [nombreSinistres = 5] Sinistre [nombreSinistres < 5] PoliceAssurance - nombreSinistres +signer() +faireDemande(motif) +déclarerSinistre()

78 Les traitements Actions sur transitions :
action élémentaire, supposée instantanée formée d ’un une ou plusieurs opérations de la classe une transition peut déclencher l ’exécution d ’une action En souscription Abandonnée Délai expiré/ comptabiliserEchec PoliceAssurance - nombreSinistres - tauxEchec +comptabiliserEchec() ….

79 Les traitements (2) Actions figurant dans un état : déclenchées par :
l ’entrée dans l ’état (Entry) Ex : à l ’entrée dans l ’état « En cours », édition du contrat sert à factoriser un action associée à plusieurs transitions menant à l ’état la sortie de l ’état (Exit) Ex : en sortie de l ’état « Suspendue », notification à l ’assuré une transition interne (laissant l ’objet dans le même état) (On event) Ex : relancer client dans l ’état « En souscription » une semaine avant le délai d ’expiration En souscription Entry / édition Suspendue Exit / notification Suspendue On event DélaiProche / relancer

80 Les activités Une activité est une action qui dure ou se répète
elle ne peut être attachée qu ’à un état (et non à une transition) syntaxe analogue à celle d ’une action avec mention d ’événement remplacé par le mot clé « do » l ’activité dure tant que l ’objet est dans l ’état concerné elle n ’est interrompue que par des transitions internes et ne s ’arrête qu ’à la sortie de l ’état on peut faire référence à un traitement détaillé dans la suite de l ’analyse Ex : Employé En activité Do / effectuer mission

81 Les traitements : exemple
Classe « Commande » En préparation Entry / choisir un fournisseur Entry / déterminer quantité à commander Entry / calculer montant On event nouveau tarif / calculer montant On event nouveau besoin / Mettre à jour la commande Exit / enregistrer la date d ’expiration Exit / Envoyer la commande Do : publier détail commande En attente expédition Commande

82 Hiérarchie des états Difficulté de construction de diagramme pour des traitements complexes décomposition d ’un super-état en plusieurs sous-états Ex : Etat « En activité » d ’un employé décomposé en sous-états « en fonction » et « en congés » En activité En fonction En congés chaque sous-état « hérite » des de la description du super-état sémantique des Statecharts de Harel mécanisme de généralisation / spécialisation comparé à celui des classes introduction d ’un état noté « H » qui désigne le dernier état visité

83 Hiérarchie d ’état : exemple
En activité Lustrage reprise H délai (2 mn) En attente Lavage arrêt d ’urgence délai (4 mn) délai (2 mn) séchage délai (2 mn) arrêt d ’urgence ©Yann POLLET

84 Une agrégation d’états traduit généralement un amalgame de classes...
L ’agrégation d’état est la composition d’états à partir de plusieurs autres états Etat courant Situation Etat Civil décédé décédé naissance Etat de veille mort célibataire célibataire mort mort mort endormi endormi divorcé divorcé endormissement réveil mariage divorce veuf veuf remariage éveillé éveillé remariage marié marié décès conjoint Une agrégation d’états traduit généralement un amalgame de classes... Individu biologique Individu de l'état civil ©Yann POLLET

85 Communications Communication entre objets ou sous-systèmes : envoi d ’événements entre les automates correspondants concept très général : appel de méthode, interruption, événement dans une application temps réel, ... notation d ’une action : ^cible.Événement(Arguments) syntaxe complète d ’une transition : Événement(arguments) [garde] / action^cible.événement(arguments) Téléviseur Télécommande basculé Bouton Enfoncé ^Téléviseur.basculé Attente Arrêt Attente basculé ©Yann POLLET

86 Autre exemple Actif time-out numérotation (digit n) [incomplet]
do / emmètre message numérotation (digit n) [incomplet] attente (15s) attente (15s) décrocher /attendre_tonalité tonalité do / emmètre tonalité numérotation (digit n) Composition numérotation (digit n) [invalide] numérotation (digit n) [valide] Invalide do / emmètre message Inactif connexion occupé occupé do / emmètre tonalité connecté Raccrocher/déconnecter Sonnerie do / emmètre sonnerie En conversation appelé décroche / converser

87 Les diagrammes d ’Activités

88 Objectifs des diagrammes d ’interaction
Modélisation d ’un ensemble d ’activités synchronisées Modélisation : du comportement global du système ou d ’un sous-système dans son contexte  d’un scénario d ’utilisation (fonction de service, processus) d ’une fonction (méthode de classe) Principales notions : Action et activité Transitions nœuds de décision flux d ’objets couloirs d ’activités

89 Actions et activités Û Action Activité Attente opération élémentaire,
ininteruptible Activité décomposée en actions peut être interrompue représentée par un autre diagramme Attente pas d ’activité, attente d ’événements Action Action1 Action2 Activité Activité E1 do: activité E2 terminée Û

90 Préparation de la commande
Transitions Action relient les actions / activités (flot de contrôle) déclenchées par des événements : fin de l ’activité précédente (transition automatique) objet dans un certain état satisfaction d ’une condition une transition peut être assortie d ’une condition de garde (bloque la transaction tant qu ’elle n ’est pas vérifiée) Préparation de la commande Envoi de la commande [fin de journée]

91 Contrôler le produit reçu
Nœuds de décision une transition entrante et plusieurs transitions sortantes expression logique (garde) sur chaque transition sortante les gardes doivent être exclusives (flot non indéterminé) et couvrir toutes les possibilités (flot non gelé) itérations réalisées comme dans un organigramme ou avec l ’opérateur ‘ * ’ Contrôler le produit reçu Stocker le produit Renvoyer le produit [produit bon] [else]

92 Concurrence et synchronisation
Barre de synchronisation : indique le parallélisme séparation de deux flots de contrôle (fork) rendez-vous (join) Exprimer demande de crédit Rechercher dans la catalogue Sélectionner un produit à proposer Evaluer le risque client Afficher la réponse

93 Différents cas de transitions
Commencer Mesurer température [pas assez chaud] [trop chaud] Continuer chauffer refroidir Établir communication Passer à table Servir repas Emettre Recevoir Manger

94 Exemple Programmer Vol Réserver Affréter avion Nommer équipage Prendre
réservation [réservations insuffisantes] [réservations terminées] Annuler Vol Débuter embarquement

95 comptabiliser la vente
Flux d’objets Il est possible de faire apparaître les objets dans un diagramme d ’activité on peut représenter la ligne de vie des objets (comme dans un diagramme de séquence) on peut indiquer les créations, destructions, changement d ’états ou de valeurs d ’attributs [Fin de journée] Envoyer la commande Préparer commande :Commande [Ouverte] :Commande [Envoyée] comptabiliser la vente

96 comptabiliser la vente
Couloirs d ’activités Introduction des acteurs responsables de chaque activité Service achats Responsable service achats Application comptabilité Préparer la commande Envoyer la commande :Commande [Ouverte] :Commande [Envoyée] comptabiliser la vente

97 Couloirs d ’activités (2)
Client Vendeur Expéditeur Se renseigner Etablir un devis :Commande [Passée] Commander Facturer :Commande [Passée] Payer Livrer :Bon Livraison

98 Les diagrammes d’implémentation
Diagrammes de composants Diagrammes de déploiement

99 Diagramme de composants
Un composant est une entité physique qui réside sur un nœud matériel et qui peut être exécuté, ou participer à l’exécution Les classes représentent des abstractions logiques, les composants sont des entités réelles (code, fichier, table, ….) Les composants représentent le moyen physique d’implanter des classes Les diagrammes de composants décrivent les éléments physiques et leurs relations

100 Représentation des composants
Elément de base = composant Par défaut, chaque classe ou paquetage du modèle logique est figuré par deux composants : spécification : interface de la classe, corps : réalisation

101 Représentation des composants (2)
Tâches : composants possédant un flot d’exécution propre Peuvent être contenues dans d’autres composants Sous-programmes : Regroupement de procédures ou de fonctions ne possède qu’un corps

102 Dépendances Indique une utilisation de services
Peut être stéréotypé pour préciser un choix de réalisation qui entraîne la dépendance

103 Autres notions Sous-systèmes Modélisation du code source
Regroupement de tous les composants nécessaires à la compilation, au test, à la documentation Paquetage stéréotypé Modélisation du code source Modélisation des « livraisons » Bases de données physiques Systèmes adaptatifs Agents mobiles Utilisation conjointe des diagrammes de collaboration

104 Diagrammes de déploiement
Définissent la répartition des composants sur les nœuds d’exécution physiques Utiles pour décrire les systèmes embarquées, les architectures client serveur et n-tiers, les systèmes distribués en général (topologie du système) Lien avec les dispositifs physiques extérieurs au logiciel (capteurs, actionneurs, …) Possibilité d’utiliser des formes graphiques spécifiques à un type d’élément

105 Diagrammes de déploiement (2)
Un diagramme contient : Des nœuds Des relations de dépendances et d’association Des connexions physiques entre nœuds On peut également montrer les composants qui résident sur les nœuds Lien avec des diagrammes de collaboration : Nom classe {localisation : nom noeud}

106 Exemple

107 Exemple (2) la

108 Synthèse sur les diagrammes UML 1.x
Utilisation en Ingénierie des Systèmes

109 Synthèse sur les diagrammes UML
Niveau contextuel (système en boite noire, processus) Diagrammes de séquences Diagrammes d’activités Cas d’utilisation Niveau analyse et conception Diagrammes de classes, d’objets Diagrammes de collaboration Diagrammes d’état Diagrammes de paquetages Diagrammes de séquences Diagrammes d’activités

110 Diagrammes UML Niveau contextuel (système en boite noire, processus)
Diagrammes de séquences Diagrammes d’activités Cas d’utilisation Niveau analyse et conception Diagrammes de classes, d’objets Diagrammes de collaboration Diagrammes d’état Diagrammes de paquetages Diagrammes de séquences Diagrammes d’activités Vision structurelle + lien avec les fonctions Flux de données et de contrôle entre objets Vision dynamique + lien avec les fonctions

111 Diagrammes d’activités
Les modèles de base D Dynamique Diagrammes d’états Diagrammes d’activités S F Diagrammes de collaboration, de séquences Diagrammes de classes, d’objets Fonctions Sémantique structure Cas d’utilisation ©Yann POLLET

112 Les activités de modélisation
Analyse du contexte, cahier des charges, spécifications Analyse du système, niveau conceptuel Analyse des processus, identification des services Identification des classes du domaine Processus métier Structuration en paquetages Aspects dynamiques Analyse des scénarios par cas, flux d’informations Coopération d’objets

113 La nouvelle version du standard de l’OMG
UML 2 La nouvelle version du standard de l’OMG

114 UML 2 Nouvelle version du standard de l’OMG (2004)
Prise en compte des retour d’expérience issus de l’utilisation de UML 1.x 13 diagrammes au total De nouvelles fonctionnalités ajoutées Nouveaux diagrammes : Diagrammes de Structure composite Diagrammes d’Interaction (« Interaction Overview diagram ») Diagrammes de Temps (« Timing diagram ») Une assise conceptuelle solide : définition à partir d’un méta méta modèle (MOF)

115 Les diagrammes UML 2 Diagrammes de cas d’utilisation (UML 1.x)
Interactions fonctionnelles avec l’extérieur du système Diagrammes de classes (UML 1.x) Structure logique du système Extension UML 2 : « Nesting » de classes Diagrammes d’objets(UML 1.x) Illustration d’exemples Diagrammes de structures composites (UML 2) Description interne d’objets complexes et de ses points d’interaction Diagrammes de paquetages (UML 1.x) Structuration du modèle global en unités logiques

116 Les diagrammes UML 2 (2) Diagrammes de composants (UML 1.x)
Description des éléments physiques qui constituent le système Diagrammes de déploiement (UML 1.x) Répartition des éléments dans l’architecture physique Diagrammes d’états (UML 1.x) Spécifie la dynamique d’un objet Diagrammes d’activités (UML 1.x) Enchaînement des actions utilisées dans un processus Extension UML 2: Réception d’événements Fin d’une branche d’un diagramme sans terminer toute l’activité (fin de flot)

117 Les diagrammes UML 2 (3) Diagrammes de séquence (UML 1.x)
Interactions entre objets avec représentation séquentielle des messages Extension UML 2 : Les fragments permettent d’isoler une partie d’un diagramme qui pourra être exécutée sous certaines conditions Diagrammes de communication (UML 2) Echanges d’information (collaboration) entre les objets Diagrammes d’interaction (UML 2) Variante du diagramme d’activité. Les diagrammes d’interaction (séquences, communication, timing) sont inclus dans un diagramme d’activité Diagrammes de temps (UML 2) Décrit le changement d’état ou de valeur d’un élément à travers le temps en mettant en évidence les contraintes de temps et de durée (Temps Réel)

118 Les diagrammes de structures composites

119 Les structures composites
Buts : Faire apparaître la structure interne d’un « classifieur » décomposé en parties (« parts ») Modéliser ses points d’interaction avec le reste du système (interfaces)

120 Concepts Partie : sous-élément d’un classifieur Port :
Elément typé représentant une partie visible d’un classifieur Lieu d’une interaction avec l’environnement Peut spécifier un service fourni ou requis Représenté par un rectangle avec un nom

121 Interface Analogue à une classe, avec des restrictions
Toutes les opérations sont publiques et abstraites Tous les attributs sont des constantes Une classe peut implémenter des interfaces multiples Deux représentations graphiques

122 Interface exposée Rattachée à une classe Fournie ou requise
Fournie = affirmation que le classifieur fournit bien les opérations définies  lien de réalisation Requise = affirmation que le classifieur est capable de communiquer avec un autre classifieur qui fournit les services correspondants

123 Connecteur « délégué » Un connecteur délégué est utilisé pour indiquer la manière interne de fonctionner des ports et interfaces externes Représenté par une relation et le stéréoptype << delegate>>

124 Collaboration Définit un ensemble de rôle coopératifs utilisés de manière collective pour fournir un service Illustre une fonctionnalité spécifique Figuré graphiquement par une ellipse en traits pointillés

125 Collaboration (2) Role binding : relie la collaboration à un classifieur qui tient un rôle Représentation : la collaboration est utilisée dans le classifieur Occurrence : la collaboration « représente » le fonctionnement du classifieur

126 Les diagrammes de composants UML2

127 Diagrammes de composants
Décrit les éléments physiques, logiciels ou non, qui constituent le système (composants et relations) Granularité plus grosse que les classes Connecteur d’assemblage : relie les interfaces (fournies, requises) Relation de dépendance Les diagrammes de composants offre un mécanisme de groupement plus riche que celui des Packages

128 Diagrammes de composants (2)
Représentation d’un composant = stéréotype Interfaces requises Composants avec ports

129 Une extension d’UML pour l’Ingénierie des Systèmes
SysML Une extension d’UML pour l’Ingénierie des Systèmes

130 Objectifs de SysML SysML = System Modelling Language
Unifier les différents langages utilisés dans l’ingéniérie des systèmes Application aux systèmes technologiques comme aux systèmes à logiciel prépondérant Faciliter la communication avec les ingénieurs du logiciels  Utilisation d’UML comme base d’extension

131 Historique de SysML Initiative conjointe de l’INCOSE (International Council on System Engineering) et de l’OMG « UML profile for System Engineering » Cahier des charges pour un langage de modélisation adapté à l’IS, formalisé par une RFP (Request for Proposal) en mars 2003 Première spécification de SysML (version 0.3) en janvier 2004 Version 0.9 de la spécification en janvier 2005 Division en 2 groupes « SysML partners » et « SysML Submission team »

132 Taxonomie des diagrammes
Rouge : diagrammes sans modifications ou apports majeurs Orange : diagrammes avec modifications conséquentes Jaune : nouveaux diagrammes spécifiques à SysML

133 Diagramme de Classes Permet de décrire la structure d’un système, sous différents aspects et à différents niveaux, ou encore l’environnement du système Extensions SysML : Reprise de l’intégralité des diagrammes de classes UML2 Décrit des éléments à un niveau beaucoup plus élevé ( attributs souvent non représentés) Assembly Diagram Deux extensions : « dependencySet » : regroupement de relations de dépendance « Root notation » : indique si une classe est à l’origine d’un hiérarchie

134 Diagramme de Classes. Exemple

135 Assembly Diagram Permet de modéliser un système comme un ensemble de composants modulaires interconnectés facilite la réutilisation de composants Sous-ensemble du diagramme de structure composite : Notion de parties, connecteurs et ports Pas de notion d’interfaces requises et fournies Extension : « NestedConnectorEnd »

136 Assembly Diagram. Exemples

137 Parametric Diagram Fournit des mécanismes pour intégrer des modèles de performance et de fiabilité Les parametric constraints décrivent un réseau de contraintes sur les propriétés du système Identifient les critères de performance à suivre tout au long du cycle de vie Nouveau diagramme Va plus loin qu’ OCL avec une notation dédiée à l’expression de contraintes

138 Parametric Diagram. Exemples
Définition de contraintes Utilisation des contraintes dans un Asseembly Diagram

139 Requirement Diagram Permet l’expression d’exigences
Une exigence peut spécifier une fonction à réaliser ou une condition à laquelle il devra satisfaire Nouveau diagramme (une exigence est définie par un stéréotype) appliqué à la définition d’une classe

140 Requirement Diagram. Exemple

141 Requirement Diagram. Exemple (2)

142 Diagramme d’activité Modélise la synchronisation des activités et les étapes essentielles de décision (comportements) Intègre à la fois le flot de contrôle et le flot d’e/s Extensions SysML Extension des contrôles : interdiction possible d’actions déjà réalisées Gestion des flux : expressions de restrictions sur les débits ou vitesse des flots (information, énergie, matière) Deux option pour le traitement d’une valeur nouvelle (« Overwrite » et « NoBuffer ») Probabilités : permet d’associer une probabilité à une transition

143 Diagramme d’activité. Exemples
Système de contrôle de freinage d’un véhicule Détail de l’opérateur de contrôle

144 Timing Diagram, Sequence Diagram, Interaction overview diagram
décrit le changement d’état d’un éléments à travers le temps représente un repère temps – (état, activité, ou propriété) Sequence diagram : interaction entre les objets Interaction overview diagram : variante du digramme d’activité avec inclusion de diagrammes d’interaction

145 Diagramme d’interaction
Timing Diagram, Sequence Diagram, Interaction overview diagram. Exemples Diagramme de temps Diagramme de séquence Diagramme d’interaction

146 Diagramme de cas d’utilisation
Permet de décrire l’interaction du système avec l’environnement En particulier l’usage du système par les usagers Reprise intégrale du diagramme de Use Case dans SysML

147 Diagramme de cas d’utilisation. Exemples

148 Diagramme d’états Décrit la dynamique du système ou d’une de ses parties sous la forme de Satecharts Diagramme inchangé en SysML

149 Diagramme d’états. Exemple

150 Les outils du marché

151 Conclusion Utilisation de SysML en Ingénierie Système
Analyse des Exigences : Capture des exigences  Requirement Diagram Description des cas d’utilisation  Use Case Diagram Analyse fonctionnelle du système : Flot fonctionnel : diagramme d’activité Assembly diagrams, diagrammes de séquence, diagrammes d’état Conception d’architecture physique : Sous-systèmes et organes : Assembly diagrams Complément par les Parametric diagrams