Documentation : INTRODUCTION AU GÉNIE …€¦ · les phases de spécification et de conception du...
39
Formation Académique STI2D – Documentation : Introduction au génie logiciel et à l'orienté objet Documentation : INTRODUCTION AU GÉNIE LOGICIEL ET A L'ORIENTE OBJET Objectifs : Connaître les différentes phases du cycle de vie d'un logiciel Comprendre la place de la modélisation UML au sein du cycle de vie du logiciel Comprendre la modélisation objet et le concept de classe Sommaire I - GÉNÉRALITÉS........................................................................................................................................ 1 I.1. Introduction............................................................................................................................... 1 I.2. La qualité d'un logiciel.............................................................................................................. 2 I.3. La modélisation.......................................................................................................................... 2 II - ÉTAPES DU DÉVELOPPEMENT LOGICIEL................................................................................................ 3 II.1. Les principales étapes du développement logiciel:................................................................... 3 II.2. Différents cycles de développement......................................................................................... 3 II.3. Processus de développement UP............................................................................................... 4 III - MÉTHODE ORIENTÉE OBJET................................................................................................................. 5 III.1. L'approche fonctionnelle.......................................................................................................... 5 III.2. Les limites de l'approche fonctionnelle dans la modélisation logicielle..................................... 6 III.3. L'approche orientée objet........................................................................................................ 6 III.4. La notion de classe.................................................................................................................. 6 I - GÉNÉRALITÉS I.1. Introduction L’élaboration d’un projet industriel correspond à un besoin exprimé dans un cahier des charges. Le demandeur est maître d’ouvrage (MOA), le réalisateur du projet est le maître d’œuvre (MOE). De l’élaboration du cahier des charges à la livraison du produit, différentes étapes vont se succéder. Elles vont définir, pour un projet informatique, le cycle de vie du logiciel: Module Méthode et Analyse 1/8
Transcript of Documentation : INTRODUCTION AU GÉNIE …€¦ · les phases de spécification et de conception du...
Formation Académique STI2D – Documentation : Introduction au génie logiciel et à l'orienté objet
Documentation :INTRODUCTION AU GÉNIE LOGICIEL
ET A L'ORIENTE OBJETObjectifs :
Connaître les différentes phases du cycle de vie d'un logiciel Comprendre la place de la modélisation UML au sein du cycle de vie du logiciel Comprendre la modélisation objet et le concept de classe
SommaireI - GÉNÉRALITÉS........................................................................................................................................ 1
I.1. Introduction............................................................................................................................... 1
I.2. La qualité d'un logiciel..............................................................................................................2
I.3. La modélisation.......................................................................................................................... 2
II - ÉTAPES DU DÉVELOPPEMENT LOGICIEL................................................................................................3
II.1. Les principales étapes du développement logiciel:...................................................................3
II.2. Différents cycles de développement.........................................................................................3
II.3. Processus de développement UP...............................................................................................4
III - MÉTHODE ORIENTÉE OBJET................................................................................................................. 5
III.1. L'approche fonctionnelle..........................................................................................................5
III.2. Les limites de l'approche fonctionnelle dans la modélisation logicielle.....................................6
III.3. L'approche orientée objet........................................................................................................6
III.4. La notion de classe.................................................................................................................. 6
I - GÉNÉRALITÉS
I.1. Introduction
L’élaboration d’un projet industriel correspond à un besoin exprimé dans un cahier des charges. Le demandeur est maître d’ouvrage (MOA), le réalisateur du projet est le maître d’œuvre (MOE). De l’élaboration du cahier des charges à la livraison du produit, différentes étapes vont se succéder. Elles vont définir, pour un projet informatique, le cycle de vie du logiciel:
Module Méthode et Analyse 1/8
Formation Académique STI2D – Documentation : Introduction au génie logiciel et à l'orienté objet
Remarque : Le prototype maquette est souvent appelé en informatique produit version β.
La norme ISO/CEI 12207 (reprise par l’AFNOR sous l’appellation Z67-150) de novembre 1995 décrit et définit les processus et activités du cycle de vie du logiciel (document de référence en ingénierie du logiciel).
I.2. La qualité d'un logiciel
La qualité d'un logiciel est intimement lié au cycle de vie du logiciel. L'assurance qualité, dans le processus de développement d'un logiciel, est une démarche préventive dont l’objectif est d’éviter les problème de non-conformité à la spécification (fabrique-t-on un produit correct?) et de non réponse au besoin (fabrique-t-on le bon produit?).
Le processus qualité est normalisé : ISO 9000-3 (règles d'application de ISO 9001- développement et maintenance d’un produit - au logiciel). L’ISO 9004 permet de normaliser le contrôle qualité.
Les verbes associés à la qualité sont : PRÉCONISER, ASSISTER, SURVEILLER.
La validité, la fiabilité, la réutilisabilité, la portabilité, l'intégrité sont autant de facteurs associés à la qualité logicielle.
I.3. La modélisation
Un modèle est une représentation abstraite d'un système réel. L'objectif d'un modèle est de décrire le système et d'expliquer son fonctionnement.
Modéliser un système permet aux différents acteurs du projet informatique de représenter ,avec un langage commun, la solution envisagée avant la phase de réalisation.
La modélisation est mise en œuvre dans les phases de spécification (QUOI FAIRE?) et de conception préliminaire et détaillée (COMMENT FAIRE?) du développement logiciel.
Module Méthode et Analyse 2/8
Formation Académique STI2D – Documentation : Introduction au génie logiciel et à l'orienté objet
II - ÉTAPES DU DÉVELOPPEMENT LOGICIEL
II.1. Les principales étapes du développement logiciel:
II.2. Différents cycles de développement
Le cycle en V (AFNOR Z67-150) :
Le problème majeur du cycle de développement en V est qu'il ne permet pas d'allers / retours entre le cahier des charges et la conception .
Une phase doit être complètement achevée avant d'en attaquer une autre. Il n'y donc pas de possibilité de maquettage ou prototypage intermédiaires
Les évolutions du CDC ne peuvent être prises en compte pendant la construction.
Ce type de cycle de développement n'est adapté qu'aux systèmes orientés fonctionnels (voir ultérieurement).
Le cycle en spirale ( AFNOR Z67-111 ):
Module Méthode et Analyse 3/8
Phase SignificationSpécifications Expression technique du besoin avec description de
l’environnement, modélisation des données et des fonctions, sans considérations informatiques; c'est le "quoi
faire".Conception préliminaire
Établissement de l’architecture informatique globale d’une application; c'est le "comment faire".
Conception détaillée ou globale
Établissement d’une façon de procéder pour construire totalement ou en partie ou/et pour paramétrer l'application.
Fabrication Fabrication, intégration ou paramétrage de l'application.
Tests Tests de fonctionnement (tests unitaires, test d’intégration) et tests de validation (conformité du produit
/ besoins).
Formation Académique STI2D – Documentation : Introduction au génie logiciel et à l'orienté objet
Le cycle en spirale est basé sur des itérations.
Chaque itération comportera de la spécification (conduite par l'expérimentation), de la conception, de la fabrication et du test.
Une itération se termine par une livraison (interne ou externe).
Chaque itération est abordée en prenant en compte les leçons de l'itération précédente afin de converger progressivement vers la meilleure solution.
Le modèle en spirale est dit « proche du risque » : il faut éviter les facteurs qui ne permettent pas d'atteindre l'objectif visé. Les risques peuvent être l'élaboration de fonctionnalités inappropriées, des problèmes de coût, des problèmes de calendrier, des problèmes de performance...
II.3. Processus de développement UP
UP (Unified Process) est un processus de développement logiciel itératif et incrémental qui s'inspire du cycle en spirale précédent :
Module Méthode et Analyse 4/8
Formation Académique STI2D – Documentation : Introduction au génie logiciel et à l'orienté objet
Selon la définition il est « itératif et incrémental, centré sur l’architecture, conduit par les cas d’utilisation et piloté par les risques » :
Itératif et incrémental : découpage du projet en itérations (petites périodes) permettant de mieux suivre l’avancement global car une partie exécutable du système final est produite à la fin de chacune d’elles. On vient intégrer des composants à chaque incrément sur un noyau existant.
Centré sur l’architecture : décomposition du « système complexe » en parties modulaires (maintenance et évolutivité facilitées).
Piloté par les risques : les itérations sont guidées par les risques qui doivent être identifiés et levés le plus tôt possible.
Conduit par les cas d’utilisation : le développement du projet est mené en tenant compte des besoins et des exigences des utilisateurs.
Le langage de modélisation employé par UP est UML. Il sera utilisé durant les phases de spécification et de conception du développement logiciel.
III - MÉTHODE ORIENTÉE OBJET
III.1. L'approche fonctionnelle
Une approche fonctionnelle ou structurée est centrée sur les fonctionnalités que le système doit assurer. Le système est décomposé en sous-fonction, qui sont elles mêmes décomposées en sous-fonctions, etc … :
Entre les sous-fonctions circulent des flots de données qui caractérisent les entrées et les sorties de ces dernières. La modélisation des données est séparée de la modélisation des sous-fonctions vues précédemment.
Module Méthode et Analyse 5/8
Représentation graphique d'une approche fonctionnelle - Extrait du site http://laurent-audibert.developpez.com
Formation Académique STI2D – Documentation : Introduction au génie logiciel et à l'orienté objet
III.2. Les limites de l'approche fonctionnelle dans la modélisation logicielle
L'approche fonctionnelle (appelée aussi procédurale) possède des facteurs rédhibitoires dès lors que l'on spécifie et conçoit des projets informatiques conséquents :
L'ajout de nouvelles fonctionnalités nécessite au minimum de modifier les sous-fonctions existantes, au pire de modifier la structure hiérarchique établie en III.1
Il n'existe pas de modularité ce qui rend le travail d'une équipe projet difficile La modification des données est répercutée sur un nombre significatif de
sous-fonctions Il existe une forte interdépendance des sous-fonctions
III.3. L'approche orientée objet
Dans une approche orientée objet, le système n'est plus vu comme une ensemble de sous-fonctions mais comme un ensemble d'objets.
La question posée n'est plus « Que doit faire le système? » mais « Sur quoi agit le système ? ». Une méthode orientée objet (OO) se focalise sur les objets que le système va mettre en œuvre plutôt que sur les fonctionnalités qu'il doit offrir.
Un objet sera caractérisé par :
une identité et un état (caractérisé par des attributs) qui lui seront propres et qui le distingueront d'autres objets de la « même famille » à un instant donné.
des fonctionnalités qui lui seront rattachées et qui détermineront son comportement. Ces fonctionnalités permettent les interactions avec d'autres objets et sont accessibles par le biais de méthodes.
Exemples d'objet:
Une fenêtre d'une interface homme machine est un objet caractérisé par les attributs longueur, largeur, position, couleur de fond et offre différentes fonctionnalités (méthodes) permettant de l'ouvrir, la réduire, la fermer. L'objet fenêtre possède des valeurs d'attributs (par exemple fond blanc, largeur de 200 pixels, ….) et un état (réduite, fermée,... )qui lui est propre à un instant donné.
Un capteur de température est un objet caractérisé par un attribut température et une fonctionnalité (méthode) permettant d'obtenir la température. L'objet capteur de température possède une valeur d'attribut (par exemple 20°) qui lui est propre à un instant donné.
Une horloge est un objet caractérisé par les attributs heure,minute,seconde et offre différentes fonctionnalités (méthodes) permettant d'obtenir l'horodatage, d'initialiser les différents attributs, … L'objet horloge possède des valeurs d'attributs (par exemple 17h23mn40s) qui lui sont propres à un instant donné.
III.4. La notion de classe
Module Méthode et Analyse 6/8
Formation Académique STI2D – Documentation : Introduction au génie logiciel et à l'orienté objet
En modélisation orientée objet (et en programmation orientée objet), une classe est une représentation abstraite d'un ensemble d'objets (abstrait ou pas) qui ont les mêmes propriétés et dont le comportement est identique.
Dans un système technique informatisé une classe peut être la représentation abstraite :
d'un élément concret : utilisateur d'un système, moteur, vanne, capteur, automate…
d'un composant graphique d'interface homme machine : bouton, fenêtre, boîte de dialogue, ...
d'un concept abstrait : protocole de communication, gestion du stockage d'informations dans un fichier, tâche d'acquisition...
d'un ensemble de données informatiques : table de base de données, fichier, liste, …
Chaque instance (objet) de classe possède ses propres caractéristiques (propriétés) et se trouve dans un état qui lui est propre à moment donné.
Une classe possèdera deux types de membres : des attributs : variables propres à la classe qui permettront de stocker des
informations sur l'état d'un objet des méthodes : opérations que l'objet peut réaliser et qui permettent de
connaître ou modifier son état.
Représentation UML des classes associées aux objets vus en III.3 :
Instances / objets associés :
Un objet offre des services accessibles par le biais de ses méthodes, la partie attribut étant protégée (interdite ou restreinte pour garantir la protection de l'information) : c'est le concept d'encapsulation.
Module Méthode et Analyse 7/8
Formation Académique STI2D – Documentation : Introduction au génie logiciel et à l'orienté objet
L'implémentation des méthodes est cachée aux utilisateurs extérieurs à la classe. La maintenance évolutive d'une application orientée objet est ainsi facilitée car « l'interface » que l'objet propose est stable.
Module Méthode et Analyse 8/8
Formation Académique STI2D – Documentation : SysML - Le diagramme des exigences
Documentation :SysML – LE DIAGRAMME DES
EXIGENCESObjectifs :
Comprendre la notion d'exigence Connaître la syntaxe des diagrammes des exigences
SommaireI - DÉFINITIONS ET FORMALISME............................................................................................................... 1
I.1. Exigence.................................................................................................................................... 1
I.2. Formalisme................................................................................................................................ 1
I.3. Diagramme des exigences......................................................................................................... 2
II - RELATIONS ENTRE EXIGENCES............................................................................................................. 2
II.1. Relation de contenance.............................................................................................................2
II.2. Relation de raffinement.............................................................................................................2
II.3. Relation de dérivation...............................................................................................................2
I - DÉFINITIONS ET FORMALISME
I.1. Exigence
Extrait de « Sysml par l'exemple » : « Une exigence permet de spécifier une capacité ou une contrainte qui doit être satisfaite par un système. Elle peut spécifier une fonction que le système devra réaliser ou une condition de performance, de fiabilité de sécurité, ...».
I.2. Formalisme
Une exigence est identifiée par un stéréotype « requirement », un nom et deux propriétés situés dans un deuxième compartiment.
Les deux propriétés d'une exigence sont un identifiant numérique et un texte décrivant l'exigence.
Exemple d'exigences pour le robot ROOMBA :
Il est possible de définir des propriétés supplémentaires comme :
Module Méthode et Analyse 1/4
Formation Académique STI2D – Documentation : SysML - Le diagramme des exigences
la priorité de l'exigence (haute, moyenne, basse) la source (service) demandant cette exigence le risque de l'exigence (haut, moyen, bas) le statut de l'exigence (proposée, validée, implémentée, …)
Exemple d'exigence complémentaires pour le robot ROOMBA :
I.3. Diagramme des exigences
Le diagramme des exigences permet de représenter l'ensemble des exigences du système modélisé. Cela permet d'établir un contrat entre le MOA (maître d'ouvrage) et le MOE (maître d'œuvre) du système.
On formalise par son biais les pré-requis du système sous forme de fonctionnalités qu'il doit satisfaire.
Un diagramme des exigences est identifié par le terme req (requirements) inscrit dans un cartouche.
II - RELATIONS ENTRE EXIGENCES
Les exigences peuvent être reliées entre elles par des relations de contenance, de raffinement ou de dérivation.
II.1. Relation de contenance
La contenance (symbolisée par une croix cerclée côté conteneur) permet de décomposer une exigence en une ou plusieurs exigences unitaires.
Exemple de relation de dépendance pour le robot ROOMBA :
Module Méthode et Analyse 2/4
Formation Académique STI2D – Documentation : SysML - Le diagramme des exigences
II.2. Relation de raffinement
La relation de raffinement (stéréotype « refine ») permet d'ajouter des précisions à une exigence comme donner des valeurs limites par exemple.
Exemple de relation de raffinement pour le robot ROOMBA :
II.3. Relation de dérivation
Une relation de dérivation (stéréotype « deriveReqt ») permet de relier une exigence d'un niveau général à une exigence d'un niveau plus spécialisée mais exprimant la même contrainte (exigences système → exigences sous-système).
Exemple de relation de dérivation pour le robot ROOMBA :
Module Méthode et Analyse 3/4
Formation Académique STI2D – Documentation : SysML - Le diagramme des exigences
Module Méthode et Analyse 4/4
Formation Académique STI2D – Documentation : SysML - Le diagramme des cas d'utilisation
DOCUMENTATION :SysML – LE DIAGRAMME DES CAS
D'UTILISATIONObjectifs :
Être capable de comprendre le rôle d'un diagramme des cas d'utilisation dans une analyse SysML
Connaître la syntaxe associée aux cas d'utilisation
SommaireI - UTILISATION.......................................................................................................................................... 1
II - NOTATIONS........................................................................................................................................... 1
III - RELATIONS ENTRE LES CAS D'UTILISATION..........................................................................................2
III.1. Relation «include».................................................................................................................... 2
III.2. Relation «extend».................................................................................................................... 3
III.3. Relation d'héritage / de généralisation.....................................................................................3
III.4. Exemple de diagramme des cas d'utilisation............................................................................4
IV - NOTION DE SCÉNARIO......................................................................................................................... 6
I - UTILISATION
Le diagramme des cas d'utilisation permet de modéliser le comportement d'un système du point de vue de l'utilisateur et de comprendre les besoins de ce dernier. Dans ce diagramme sont établies les frontières du système et les interactions avec son environnement. C'est le premier diagramme à être établi dans une analyse utilisant SysML comme langage de modélisation.
Le diagramme des cas d'utilisation met en relation des acteurs avec des cas d'utilisation. Les acteurs sont des entités (personne, logiciel, matériel,...) qui utilisent / interagissent avec l'application à développer. Les acteurs ne font pas partie de l'application et ne sont donc pas développés.
II - NOTATIONS
Représentation :
Module Méthode et Analyse 1/6
Formation Académique STI2D – Documentation : SysML - Le diagramme des cas d'utilisation
Un acteur est représenté par une forme humaine. Il peut être aussi représenté par une classe possédant le stéréotype <<actor>> pour les acteurs logiciels.
Le cas d'utilisation est symbolisé par une figure ovale à laquelle on associe un verbe ou une expression verbale symbolisant le cas d'utilisation.
Exemple d'acteur :
Exemple de cas d'utilisation :
Exemple de diagramme des cas d'utilisation :
III - RELATIONS ENTRE LES CAS D'UTILISATION
III.1. Relation «include»
La relation include entre les cas d'utilisation signifie que le cas d'utilisation source comprend obligatoirement le cas inclus.
Module Méthode et Analyse 2/6
Formation Académique STI2D – Documentation : SysML - Le diagramme des cas d'utilisation
Dans l'exemple précédent, le cas d'utilisation source « Envoyer des messages » comprend obligatoirement le cas inclus « S'authentifier » (il faut s'authentifier pour envoyer des messages). L'acteur Utilisateur est relié de fait au cas inclus.
III.2. Relation «extend»
La relation extend permet de spécifier que le cas d'utilisation source est une extension possible du cas d'utilisation destination. Il n'y a aucun caractère obligatoire à effectuer le cas source.
Le cas d'utilisation « Joindre un fichier » est une extension possible du cas d'utilisation « Envoyer un message ». Cela signifie que l'utilisateur peut éventuellement joindre un fichier.
III.3. Relation d'héritage / de généralisation
La relation d'héritage entre cas d'utilisation permet de définir une forme plus spécifique de traitement dans le cas source (cas dérivé).
Le cas d'utilisation « source » hérite de toutes les caractéristiques et de toutes les associations du cas d'utilisation «parent».
Module Méthode et Analyse 3/6
Formation Académique STI2D – Documentation : SysML - Le diagramme des cas d'utilisation
Dans l'exemple précédent, « Envoyer des messages via internet » est une spécialisation d' «Envoyer des messages». Le cas d'utilisation « Envoyer des messages via internet » hérite de toutes les caractéristiques et toutes les associations de « Envoyer des messages ».
L'héritage est la seule relation possible entre acteurs :
Dans l'exemple précédent, l'internaute «est une sorte» d'utilisateur ayant la possibilité supplémentaire d'envoyer les messages via internet.
III.4. Exemple de diagramme des cas d'utilisation
Soit un stade d'eau vive, système permettant la gestion d'une rivière artificielle destinée à l'entraînement de kayakistes.
Le débit de la rivière artificielle est variable, réglé grâce à une vanne appelée vanne omniflot. Le stade d'eau vive est situé en bord de mer. La rivière artificielle est alimentée par une réserve d'eau remplie lors des marées hautes.
La rétention de l'eau dans le réservoir est assurée par une vanne de remplissage appelée « vanne stock vide » dans l'exemple suivant :
Module Méthode et Analyse 4/6
Formation Académique STI2D – Documentation : SysML - Le diagramme des cas d'utilisation
Afin de modéliser les besoins d'un tel système, on peut établir le diagramme des cas d'utilisation suivant (une solution parmi d'autres):
Le responsable du site peut gérer une séance d'entraînement dans le stade.
Pour autoriser une séance d'entraînement, le responsable doit impérativement obtenir les horaires d'utilisation du stade.
Les horaires d'utilisation du stade (réserve pleine et marée basse) sont déterminés en fonction des horaires des marées, stockés sur le serveur du Service Hydrographique et Océanographique de la Marine.
Module Méthode et Analyse 5/6
Schéma issu du sujet de BTS IRIST session 2000
Formation Académique STI2D – Documentation : SysML - Le diagramme des cas d'utilisation
Si la séance est possible, le responsable lance la régulation du débit en fonction d'une consigne (fonction de la difficulté attendue de la séance).
A la fin de la séance, le responsable du stade peut prendre le contrôle manuel des vannes afin de les affaler pour vider l'eau résiduelle.
Il peut éventuellement durant la séance obtenir des images du stade via des caméras.
Remarque : certaines modélisations font apparaître dans le diagramme des cas d'utilisation des acteurs qui font partie du système mais dont la représentation facilite la compréhension ( cas de Vanne_Stockage, Vanne_Omniflot et Reservoir dans l'exemple suivant) :
IV - NOTION DE SCÉNARIO
Les scénarios sont des « instances » des cas d’utilisation. Ils permettent de décrire des exemples de fonctionnement liés au cas d'utilisation spécifié. Afin de modéliser un scénario, il est possible d'employer un type de diagramme d'interaction ou de comportement parmi les diagrammes suivants :
diagramme d’activité diagramme de séquence (prépondérance de l'aspect temporel) diagramme de communication (prépondérance de l'aspect circulation de
l'information / messages)
Module Méthode et Analyse 6/6
Formation Académique STI2D – Documentation : SysML - Le diagramme de séquence
DOCUMENTATION :SysML – LE DIAGRAMME DE
SÉQUENCE Objectifs :
Connaître la syntaxe des diagrammes de séquence Être capable de différentier les types de messages Connaître le concept et la syntaxe des fragments combinés
SommaireI - UTILISATION.......................................................................................................................................... 1
II - DIFFÉRENTS TYPES DE MESSAGES........................................................................................................2
II.1. Messages synchrones et asynchrones.......................................................................................2
II.2. Messages de création / destruction d'objets..............................................................................3
III - LES FRAGMENTS COMBINÉS ............................................................................................................... 4
III.1. Introduction.............................................................................................................................. 4
III.2. Fragment alt............................................................................................................................. 4
III.3. Fragment opt........................................................................................................................... 5
III.4. Fragment loop.......................................................................................................................... 5
III.5. Fragment par........................................................................................................................... 6
III.6. Fragment critical...................................................................................................................... 6
III.7. Fragment strict......................................................................................................................... 7
I - UTILISATION
Le diagramme de séquence permet de décrire un scénario de cas d'utilisation («instance» du cas d'utilisation).
Il donne une représentation temporelle (haut vers le bas) de l'échange des messages entre les objets qui participent à la réalisation du cas d'utilisation étudié.
Un objet (instance) dans un diagramme de séquence est caractérisé par :
sa ligne de vie (ligne en pointillée) son identifiant (nom de l'objet) le nom de la classe dont il est l'instance
L'identifiant et le nom de la classe sont mentionnés dans un rectangle avec la syntaxe suivante :
nom_instance : nom_classe
Syntaxe :
Module Méthode et Analyse 1/7
Formation Académique STI2D – Documentation : SysML - Le diagramme de séquence
Les instances vont communiquer entre elles via des messages échangés entre lignes de vie. Les messages échangés entre les objets participants au diagramme de séquence peuvent représenter :
l'occurrence d'un évènement un appel de méthode la création ou la destruction d'un objet
II - DIFFÉRENTS TYPES DE MESSAGES
II.1. Messages synchrones et asynchrones
Les messages peuvent être de deux types :
Les messages synchrones : l’émetteur du message est bloqué jusqu’à ce que l’appelé ait fini de traiter le message. Il est possible (optionnel) de faire figurer sur le diagramme un message de retour symbolisé par une flèche pointillée (accusé de réception).
Les messages asynchrones : l’émetteur n’est pas bloqué après l’envoi du message et peut continuer son exécution.
Syntaxe :
Module Méthode et Analyse 2/7
Formation Académique STI2D – Documentation : SysML - Le diagramme de séquence
Remarques :
La présence d'un acteur est souvent requise car le diagramme de séquence permet de spécifier le scénario possible d'un cas d'utilisation.
Le déroulement temporel du cas d'utilisation est imposé par la représentation graphique (du haut vers le bas)
Les appels de méthodes entre instances sont symbolisés par des messages synchrones auxquels ont peut passer des paramètres (paramètres de la méthode).
Il faut qu'il y ait cohérence entre le diagramme de séquence et le diagramme de classes du modèle : les méthodes appelées dans le diagramme de séquence devront automatiquement être présentes dans le diagramme de classes. La flèche du message pointera sur l'instance dont est membre la méthode associée au message .
Exemple : Diagramme de séquence (non détaillé) du cas d'utilisation « Réguler le débit» du diagramme des cas d'utilisation vu précédemment (système stade d'eau vive).
Description : Le responsable du stade démarre la séance. L'instance de Seance appelle alors la méthode réguler() de l'instance de VanneRegulee avec 14m3 /s comme paramètre (débit voulu).
Ensuite, tant que la hauteur de vanne est supérieure à 0 (garde [hauteurVanne > 0], l'instance de VanneRegulee :
appelle la méthode hauteurEauUtile() de l'instance de Reservoir afin d'obtenir la hauteur d'eau utilse permettant d'obtenir le débit voulu
appelle sa propre méthode calculerHauteurVanne() afin de calculer la hauteur de vanne permettant d'obtenir le débit voulu
Module Méthode et Analyse 3/7
Formation Académique STI2D – Documentation : SysML - Le diagramme de séquence
appelle sa propre méthode ouvrir(), héritée de Vanne, afin d'ouvrir la vanne permettant à la hauteur permettant d'obtenir le débit voulu
Remarque : Les rectangles verticaux superposés aux lignes de vie correspondent aux périodes d'activité des instances.
II.2. Messages de création / destruction d'objets
Syntaxe :
Ces messages permettent respectivement de créer l'objet (instanciation d'un objet par allocation dynamique de mémoire au sens logiciel) et de le détruire.
III - LES FRAGMENTS COMBINÉS
III.1. Introduction
Un fragment combiné permet, pour l'ensemble ou un sous-ensemble d'un diagramme de séquence, de spécifier des conditions d'exécution sous forme de structures de contrôle.
Chaque condition d'exécution est symbolisée par un opérateur.
Ces opérateurs sont au nombre de 12 sous UML 2.0. Seuls les opérateurs principaux seront abordés ici :
opérateurs de choix et de boucle : alt (structure conditionnelle), opt (option), loop (itération)
opérateurs de gestion d'envoi parallèle de messages : par (déroulement parallèle d'activités), critical (section critique)
opérateur fixant l'ordre d'envoi des messages : strict
III.2. Fragment alt
Le fragment alt (opérateur alternative) est un opérateur conditionnel se
Module Méthode et Analyse 4/7
Formation Académique STI2D – Documentation : SysML - Le diagramme de séquence
rapprochant d'une structure switch. Un bloc du fragment est exécuté si sa garde est vraie. Le bloc dont la garde est else est exécuté si aucune garde n'est vérifiée.
Dans l'exemple précédent si la [condition] est vérifiée, le bloc associé est exécuté (le bloc else dans le cas contraire).
III.3. Fragment opt
Le fragment opt (opérateur option) permet d'effectuer un bloc si une garde est vraie.
Dans l'exemple précédent, le bloc est excuté si la [condition] est vérifiée.
III.4. Fragment loop
Module Méthode et Analyse 5/7
Formation Académique STI2D – Documentation : SysML - Le diagramme de séquence
Le fragment loop (opérateur loop) permet d'effectuer une bloc un nombre de fois donné. Les limites minimum et maximum de la boucle sont données entre parenthèses.
Dans l'exemple précédent, le bloc sera exécuté n fois.
III.5. Fragment par
Le fragment par (opérateur parallel) possède généralement deux blocs (mais peut en avoir plus) effectués simultanément. Il permet donc les exécution concurrentes.
III.6. Fragment critical
Module Méthode et Analyse 6/7
Formation Académique STI2D – Documentation : SysML - Le diagramme de séquence
Le fragment critical (opérateur critical region) permet de rendre « atomique » l'exécution du fragment : les interactions décrites dans ce fragment ne peuvent être interrompues par d'autres interactions du diagramme.
III.7. Fragment strict
Le fragment strict (opérateur strict sequencing) impose un ordre d'exécution des interactions y compris pour les diagrammes faisant intervenir des lignes de vie « indépendante ».
Dans l'exemple précédent, le message 3 ne pourra être émis que si le message 2 l'a été, bien que les lignes de vie soient indépendantes.
Module Méthode et Analyse 7/7
Formation Académique STI2D – Documentation : SysML - Le diagramme de définition de blocs
Documentation :SysML – LE DIAGRAMME DE
DÉFINITION DE BLOCSObjectifs :
Comprendre la notion de bloc Connaître la syntaxe des diagrammes de définition de blocs
SommaireI - DÉFINITIONS.......................................................................................................................................... 1
I.1. Le diagramme de définition de blocs.........................................................................................1
I.2. Représentation d'un bloc........................................................................................................... 2
II - LES RELATIONS ENTRE BLOCS.............................................................................................................. 4
II.1. Association................................................................................................................................ 4
II.2. Informations d’association........................................................................................................5
II.3. La composition.......................................................................................................................... 6
II.4. L'agrégation.............................................................................................................................. 6
II.5. L'héritage.................................................................................................................................. 7
I - DÉFINITIONS
I.1. Le diagramme de définition de blocs
Un diagramme de blocs permet de modéliser la structure d'un système en faisant apparaître les blocs et les liens structurels existants entre ces blocs.
Un bloc est l'élément de base dans la modélisation de la structure d'un système sous SysML.
Le bloc est la représentation abstraite d'un système ou d'un sous-système, d'un élément matériel, de données, d'une personne, d'un module logiciel ….
Les instances qui découlent de ces blocs vont interagir afin de réaliser un scénario de cas d'utilisation.
Les messages échangés dans le diagramme de séquence correspondent aux opérations associées aux blocs.
Exemple de diagramme de blocs permettant de modéliser une partie d'un système de régulation de débit dans un stade d'eau vive (extrait du sujet de BTS IRIST – 2000) :
Module Méthode et Analyse 1/8
Formation Académique STI2D – Documentation : SysML - Le diagramme de définition de blocs
I.2. Représentation d'un bloc
Module Méthode et Analyse 2/8
Formation Académique STI2D – Documentation : SysML - Le diagramme de définition de blocs
Un bloc est caractérisé par le stéréotype <<block>>.
Les caractéristiques du bloc sont décrites dans des compartiments. Les trois types de compartiments sont :
Le compartiment opérations qui permet de définir le comportement du bloc.
Les compartiments propriétés qui permettent de définir les caractéristiques structurelles du bloc. Ces caractéristiques peuvent être des valeurs(« values »), des parties (« parts ») ou des références (« reference »).
Le compartiment contraintes qui permet de définir les contraintes associées au bloc (ces contraintes se retrouveront ensuite dans le diagramme paramétrique associé au diagramme de bloc interne).
Les propriétés sont communes à toutes les instances d'un même bloc mais chaque instance possédera une identité propre caractérisée par exemple par des valeurs « courantes » (ex : une instance de VanneRegulee aura son propre débit).
Afin d'assurer le principe d'encapsulation, il est possible de spécifier le niveau de visibilité des opérations et des propriétés d'un bloc :
Type d’accès
Représentation SysML
Signification
public + Une instance de bloc extérieure peut accéder à une opération ou une propriété publique du bloc
protégé # Seule une opération du bloc ou une opération d'un bloc descendant (voir héritage / généralisation) peut accéder à
une opération ou une propriété protégée du blocprivé - Seule une opération du bloc peut accéder à une opération
ou une propriété privée du bloc
Exemple : Vanne du système « stade d'eau vive »:
Module Méthode et Analyse 3/8
y
O
D Niveau d’eau réservoir
Vérin
Vanne
B
C
hv
H
â
A
Toit de laVanne
Formation Académique STI2D – Documentation : SysML - Le diagramme de définition de blocs
La modélisation de la vanne sous forme de bloc est la suivante :
Le bloc Vanne possède 4 valeurs protégées OA, OD, AC, AB (appelées values : ce sont les propriétés principales de la vanne) et 3 opérations publiques qui permettent :
d'ouvrir la vanne à une certaine hauteur (opération Ouvrir(hv:float) ) de fermer la vanne ( opération Fermer() ) d'affaler la vanne ( opération Affaler() )
Le bloc Vanne possède aussi une contrainte : c'est ici une équation qui permet d'obtenir la valeur de y (déplacement du vérin) à partir de la hauteur de vanne voulue.
Les « parties » (« parts ») représentent les relations de compositions (voir paragraphe suivant) que le bloc entretient avec les blocs avec lesquels il est relié.
II - LES RELATIONS ENTRE BLOCS
II.1. Association
Une association décrit une connexion bidirectionnelle entre blocs. C'est une «abstraction» des liens entre les instances de blocs correspondants. La plupart des associations sont «binaires» (impliquent deux blocs).
L’exemple suivant signifie qu’une VanneRegulee va utiliser le Reservoir pour obtenir par exemple la hauteur d'eau utile.
Module Méthode et Analyse 4/8
Formation Académique STI2D – Documentation : SysML - Le diagramme de définition de blocs
II.2. Informations d’association
Plusieurs informations peuvent être ajoutées afin de clarifier la relation :
Le nom d'association (utilisé dans l’exemple) : il apparaît souvent sous forme verbale afin de préciser la sémantique de la relation et la lisibilité d'un diagramme de blocs.
Le rôle (reservoir. dans l’exemple) : placé à l’extrémité de l’association, il permet de décrire comment un bloc «voit» un autre bloc au travers de la relation.
La navigabilité : bien que les associations soient navigables dans les deux directions, il peut arriver qu’une navigabilité soit restreinte. Une navigabilité restreinte est représentée par une association terminée par une flèche ouverte. Par exemple, une instance de VanneRegulee doit pouvoir référencer une instance de Reservoir, l’inverse étant inutile.
La multiplicité : permet de préciser combien d’instances d’un bloc peuvent se rattacher à une seule instance du bloc associé. C’est un élément restrictif permettant de spécifier un nombre d’objets.
1 Multiplicité un et un seul0..1 Multiplicité zéro ou und..f Multiplicité de d à f, f et d étant des entiers
naturels)* Multiplicité de zéro à plusieurs
0..* Idem1..* Multiplicité de un à plusieurs
Dans l’exemple fourni précédemment, une instance de VanneRegulee est associée à une instance de Reservoir, et une instance de Reservoir est associée à une instance de VanneRegulee.
Module Méthode et Analyse 5/8
Formation Académique STI2D – Documentation : SysML - Le diagramme de définition de blocs
II.3. La composition
Une composition (représentée par un losange noir) permet de modéliser une relation de contenance (structurelle) entre deux blocs. C'est la représentation graphique des parties (« parts ») :
La durée de vie du bloc composant est directement liée à la durée de vie du bloc composé. Le composant est créé par le composé et toute disparition du composé entraîne la disparition du composant.
La composition implique du côté du composé une multiplicité de 1. Dans le cas précédent, une instance de Vanne sera composée de 2 instances de CapteurTor. La destruction de l'instance de Vanne entraîne automatiquement la destruction des instances de CapteurTor.
II.4. L'agrégation
L’agrégation permet de définir un couplage moins fort que la composition. La contenance n'est plus structurelle : elle permet d'indiquer une prédominance d'un bloc par rapport à un autre mais les durées de vie de ces deux blocs ne sont pas liées.
Une agrégation est représentée par un losange vide du côté de l’agrégat (composé) :
Une instance du bloc Bouée sera reliée à une instance du bloc Reservoir. La
Module Méthode et Analyse 6/8
Formation Académique STI2D – Documentation : SysML - Le diagramme de définition de blocs
durée de vie d'une instance de Bouée n'est pas liée à la durée de vie de l'instance de Reservoir à laquelle elle est rattachée. Le bloc Reservoir joue un rôle néanmoins prépondérant : il « subordonne » le bloc Bouée dont une instance « flottera » à sa surface.
L'agrégation apporte une précision sémantique par rapport à l'association. Les relations d'agrégation se retrouvent dans la partie référence (« references ») des propriétés du bloc.
II.5. L'héritage
L’héritage englobe deux concepts que sont :
la généralisation : factorisation des éléments communs à un ensemble de blocs dérivés dans un bloc de base.
la spécification : extension dans un bloc dérivé des caractéristiques d'un bloc de base.
La relation d’héritage est à mettre en œuvre si l’on peut signifier que le bloc dérivé « est une sorte de » bloc de base.
La notation SysML de l'héritage est un trait plein terminé par une flèche pleine qui indique la bloc de base / mère.
Dans l'exemple suivant, Vanne est le bloc de base et VanneRegulee est le bloc dérivé (VanneRegulee est une sorte de Vanne) :
Module Méthode et Analyse 7/8
Formation Académique STI2D – Documentation : SysML - Le diagramme de définition de blocs
Le bloc dérivé possède toutes les caractéristiques / propriétés du bloc de base et peut :
ajouter ses propres caractéristiques surdéfinir / surcharger des caractéristiques héritées disposer de toutes les associations existantes sur le bloc de base / mère
Dans l'exemple précédent, les opérations ouvrir(), fermer() et affaler() seront aussi des opérations du bloc VanneRegulee.
Module Méthode et Analyse 8/8
Formation Académique STI2D – Documentation : SysML - Le diagramme états / transitions
Documentation :SysML – LE DIAGRAMME ÉTATS /
TRANSITIONSObjectifs :
Comprendre le contexte d'utilisation des diagrammes états / transitions Connaître la syntaxe des diagrammes états / transitions
SommaireI - DÉFINITION ET UTILISATION................................................................................................................... 1
II - FORMALISME GÉNÉRAL......................................................................................................................... 1
II.1. Notion d'état............................................................................................................................. 1
II.2. Notion d'évènement.................................................................................................................. 2
II.3. Actions et activités.................................................................................................................... 2
II.4. Point de décision :..................................................................................................................... 3
III - CONCEPTS AVANCÉS........................................................................................................................... 4
III.1. État composé .......................................................................................................................... 4
III.2. Concurrence dans les états......................................................................................................4
I - DÉFINITION ET UTILISATION
Un diagramme d'états / transitions permet de spécifier le comportement réactif d'un objet par le biais d'un « automate » à états finis (nombre fini d'états distincts). Il représente les états que peut prendre l'objet et les différents événements pouvant être pris en compte dans un état précis.
On dit aussi que ce diagramme permet de représenter le « comportement interne d'une classe ». Seuls les objets ayant une forte réactivité sont spécifiés à l'aide d'un diagramme états / transitions.
Comparativement à un diagramme de séquence qui n'offre qu'une vue partielle correspondant à un scénario, le diagramme états transitions permet de spécifier la totalité des comportements de l'objet associé. Cependant, il ne permet pas d'avoir une vision globale du système.
II - FORMALISME GÉNÉRAL
II.1. Notion d'état
Chaque objet est à un moment donné dans un état particulier (représenté par un rectangle aux coins arrondis), identifié par un nom. Les états sont reliés entre eux par des connexions unidirectionnelles appelées transitions :
Module Méthode et Analyse 1/6
Formation Académique STI2D – Documentation : SysML - Le diagramme états / transitions
Il existe deux états spécifiques qui sont :
l'état initial : état dans lequel se trouve l'objet à sa création (unique) l'état final : état correspondant à la destruction de l'objet. Il peut exister
plusieurs états finaux ou pas d'état final du tout.
Dans l'exemple précédent, à l'initialisation de l'objet, ce dernier se trouve dans l'état « Etat 1 ». Lorsque l'on quitte l'état « Etat 2 » sur occurrence de l'évènement « évènement fin », l'objet se trouve dans l'état final (objet détruit).
Exemple du diagramme état transition spécifiant le fonctionnement d'une messagerie via internet (exemple volontairement simplifié):
II.2. Notion d'évènement
Un évènement est une information instantanée servant de déclencheur au passage d'un état à un autre.
Une condition booléenne (garde) peut être rattachée à l'évènement afin de valider ou non le déclenchement d'une transition, une fois que l'évènement associé se soit produit :
Dans le cas précédent, l'objet passera de l'état « Etat 1 » à l'état « Etat 2 » sur occurrence de l'évènement « évènement 1 » uniquement si la garde « condition » est validée.
Module Méthode et Analyse 2/6
Formation Académique STI2D – Documentation : SysML - Le diagramme états / transitions
Exemple :
A noter que l'on peut rencontrer des rétro-transitions comme celle associée à l'événement « Etat 1 ».
II.3. Actions et activités
On peut associer une action à chaque transition. Cette action sera exécutée lorsque cette transition sera franchie. L'action peut correspondre à :
l'envoi d'un signal l'appel d'une opération une instruction
Il est possible de spécifier dans un compartiment associé des transitions internes à un état :
une action d'entrée (entry) : exécutée dès l'entrée dans l'état. une action de sortie (exit) : exécutée à la sortie de l'état. une activité (do) : exécutée tant que l'objet se trouve dans l'état associé et dès
que l'action liée à entry est terminée.
Remarque : le déclenchement d'une transition interne ne modifie pas l'état actif contrairement à une rétro-transition.
Exemple :
Module Méthode et Analyse 3/6
Formation Académique STI2D – Documentation : SysML - Le diagramme états / transitions
II.4. Point de décision :
Un point de décision est un point de choix proposant une alternative au franchissement d'une transition :
Une fois le point de décision atteint, les gardes en sortie sont évaluées afin de déterminer l'état suivant. Dans l'exemple, si l'on se trouve dans l'état « Etat 1 », sur occurrence de l'évènement « évènement », on passe dans l'état « Etat 2 » si la garde est vraie. Sinon, on passe dans l'état « Etat 3 ».
III - CONCEPTS AVANCÉS
III.1. État composé
Un état composé (ou super état) est un état qui, de part sa complexité, demande à être spécifié par un diagramme d'états transitions particulier :
Ce super état pourra être représenté par une notation abrégée, afin de pouvoir être utilisé dans un diagramme de plus haut niveau :
Module Méthode et Analyse 4/6
Formation Académique STI2D – Documentation : SysML - Le diagramme états / transitions
Remarques :
Si une transition a pour cible le bord d'un état composé, elle est considérée comme étant reliée à l'état initial de ce dernier.
Si une transition a pour source le bord d'un état composé, elle est franchissable depuis n'importe quel état faisant partie de l'état composé.
Un bord d'état composé peut être coupé par une transition pour atteindre / quitter un état particulier.
Exemple :
III.2. Concurrence dans les états
Module Méthode et Analyse 5/6
Formation Académique STI2D – Documentation : SysML - Le diagramme états / transitions
Certains états composés peuvent être qualifiés d'orthogonaux : ils comportent dans ce cas plusieurs régions au sein desquelles les états s'exécutent en concurrence.
La concurrence a été induite ici par une barre de synchronisation (représentation de points de synchronisation ou « points de rencontre » ). Les transitions associées à une barre de synchronisation sont franchies en même temps.
Depuis l'état initial, on atteint directement l'état « Etat 3 » et l'état « Etat 5 » de l'état composé. Ils se dérouleront en parallèle (concurrence).
L'état composé sera terminé lorsque chaque région aura atteint son état final respectif (soit l'état « Etat 4 » et l'état « Etat 5 ») et que les transitions associées pourront être franchies. On se retrouvera alors dans l'état « Etat 6 ».
Exemple :
Remarque : l'exemple n'est pas représentatif du fonctionnement réel d'une messagerie. A noter toutefois la différence entre les évènements fermeture et déconnexion qui permettent de quitter l'état Utilisation messagerie.
Module Méthode et Analyse 6/6
