GÉNIE LOGICIEL

Chapitre 0 : Introduction

Chapitre 1 : Modèles de Cycles de Vie

Chapitre 2 : Analyse et Définition des Besoins

Chapitre 3 : Diagramme des cas d’utilisation

Chapitre 4 : Diagramme des classes & des objets

Chapitre 5 : Diagramme d’interactions

Chapitre 6 : Diagramme d’états & d’activités

 INTRODUCTION

1\ Crise du logiciel :
Cette crise est apparue dans les années 60 car les méthodes
de développement de l'époque n'étaient plus en adéquation
avec les logiciels qui devenaient de plus en plus complexes,
pour résumer les projets souffraient de :
• Retards dans les livraisons (parfois des années)
• Surcoûts considérables dépassant largement les budgets
• Produits qui ne répondaient pas aux besoins des utilisateurs
(peu fiables, peu performants, difficiles à maintenir, etc)
• Produits peu sûrs comportant parfois des erreurs pouvant
avoir des répercussions graves sur la mission du système

C’est en cette période (1968) qu’est né le terme Génie logiciel

2\ Définition :
Le Génie Logiciel est une science de l’ingénieur qui vise à
proposer des méthodes d’ingénierie, des techniques, des
langages et des outils pour développer des produits logiciels de
bonne qualité, dans les meilleurs délais, et avec les moindres
coûts possibles

3\ Qualités d'un logiciel :

La qualité logicielle est une appréciation globale basée sur de
nombreux critères, on note 2 types de qualités :
1) Qualités Externes : intéressent le client :
• Validité & Fiabilité
• Ergonomie
• Efficacité & Performances
• Maintenabilité

2) Qualités Internes : Intéressent le développeur :

• Réutilisation
• Adaptabilité
• Maintenabilité
• Conception Modulaire

Validité des Besoins : les tâches sont spécifiées à travers des

cas d’utilisations et pour chaque tâche il doit exister une ou
plusieurs fonctionnalités permettant de l’accomplir, il faut que
l’implémentation de la fonction soit appropriée avec le besoin

Fiabilité : désigne la capacité d’un logiciel à maintenir son

niveau de service dans des conditions précises pendant une
certaine durée, beaucoup de bugs sont le symptôme d’un
manque de fiabilité

Efficacité : c’est l’optimisation rationnelle de la gestion des

ressources, c'est-à-dire avoir le bon ratio entre la quantité de
ressources utilisées (moyens matériels, temps, personnel) et la
quantité de résultats délivrés, par exemples : économie de
mémoire, rapidité d'exécution ...
Ergonomie : c’est la facilité d'utilisation, qui porte sur l'effort
nécessaire pour apprendre à manipuler le logiciel, les logiciels
doivent être intuitives, accessibles et bien documentés

Maintenabilité : c’est la facilité du système à être réparé et

modifié, les logiciels ayant une longue durée de vie, doivent
être conçus et réalisés de façon à minimiser les coûts

Portabilité : c'est l'aptitude d'un logiciel de fonctionner dans

différents environnement matériel ou logiciel, en plus de la
facilité d'installation et de configuration

Parmi les qualités citées précédemment, 4 d’entre elles sont

générales (indispensables) :
• Fiabilité
• Efficacité
• Ergonomie
• Maintenabilité

Remarque : il est difficile d'optimiser tous ces facteurs en

même temps car certains s'excluent mutuellement, il est donc
nécessaire de faire des compromis entre les qualités, par
exemple : une belle interface utilisateur peut réduire l'efficacité,
un système efficace en temps réelle augmente les coûts …
 MODÈLES DE CYCLES DE VIE

1\ Définition :
Le cycle de vie d’un logiciel est constitué de l'ensemble des
étapes successives de la fabrication depuis la commande du
logiciel par le maître d'ouvrage jusqu'à sa mise en exploitation
et lancement de la maintenance. On distingue dans tout cycle
de vie 2 sous cycles internes : le cycle de développement et le
cycle de maintenance

2\ Modèles de cycles de vie :

On distingue 3 classes, chacune se distingue des autres selon
sa logique d’enchaînement des étapes et la participation des
clients au processus de développement :

1) Modèles Linéaires : le système logiciel est développé dans

sa totalité en appliquant les étapes de manière séquentielle. Le
client intervient uniquement au début et à la fin du cycle de
développement

Exemples : Modèles en Cascade et en V

Avantage : ils permettent de développer des logiciels avec un

bon ratio qualité/coût, quand les besoins sont clairs, stables et
faciles à cerner

Inconvénient : les erreurs de définition des besoins sont

détectées tardivement par le client surtout quand les besoins du
client sont ambigus
2) Modèles évolutifs : le projet est réalisé en appliquant
plusieurs cycles de développement, en faisant intervenir le
client pendant au moins un cycle de développement

Exemples : Modèles par prototypage et par incréments

Avantage : les erreurs de définition des besoins sont détectées

par le client pendant les premières étapes de développement,
cela permet de développer des logiciels de bonne qualité,
quand les besoins du client sont ambigus et difficiles à cerner

Inconvénient : ces modèles sont coûteux en termes de délais et

budgets, de plus ils nécessitent un personnel de
développement qualifié afin d’éviter des risques liés

3) Modèles Hybrides : on décompose le grand système en

plusieurs sous-systèmes, en se basant sur l’analyse du risque
on choisit l’approche appropriée pour chaque sous-système :
• Pour les sous-systèmes ayant des spécifications à hauts
risques : utilisation du prototypage
• Pour les parties bien connues qui ont des besoins stables et
clairs : Modèle linéaire

Avantage : les produits logiciels sont souvent de meilleure

qualité, c’est la meilleure solution pour les grands systèmes

Inconvénient : le coût reste toujours très élevé, le contrôle et

l’intégration des changements sont souvent plus difficiles
3\ Modèle en V :
Dans ce modèle, les premières étapes du développement du
logiciel doivent préparer pour les étapes finales, les données
liées aux activités de validation et de vérification

4\ Maquettage & Prototypage :

On détermine d'abord un ensemble minimum de fonctions elles-
mêmes incomplètes de façon à réaliser rapidement un premier
incrément du logiciel dont on se sert pour analyser son
fonctionnement, l'utilisateur fournit en retour des informations
au concepteur qui modifie le prototype, ce processus
d'évolution de prototypes continue jusqu'à ce que l'utilisateur
soit satisfait du système livré

Prototype jetable / non jetable : quelqu’un qui utilise cette

méthode doit toujours se poser cette question : faut-il garder et
faire évoluer le prototype ou bien le jeter et développer le
logiciel en se basant sur le cahier des charges corrigé ?
La réponse dépend en grande partie de la maintenabilité du
prototype (facilité de le corriger et de le faire évoluer) Les
contraintes de délai et de budget rentrent aussi en compte

5\ Modèle par incréments :

Un seul sous ensemble des composants d’un système est
développé à la fois, un noyau est tout d’abord développé, puis
des incréments sont successivement développés et intégrés

Avantages :
• Chaque développement est moins complexe
• Les intégrations sont progressives
• Il peut y avoir des livraisons et des mises en services après
chaque intégration d’incrément
• Il permet de bien répartir le temps, l’effort de développement
et les effectifs par rapport aux modèles en cascade et en V

Risques :
• Le mauvais choix du noyau
• La mauvaise décomposition du système en incréments
• La mauvaise définition des interfaces entre incréments

6\ Modèle en Spirale :
Chacune des activités de développement est réalisée en
suivant un cycle multi-étape où les objectifs et les contraintes
ainsi que les alternatives doivent être énumérés et précisés au
départ, ensuite chaque alternative subit une série d’examens
et d’analyses de risque afin de choisir la solution optimale
Chaque cycle de la spirale se déroule en 4 phases :

1) Détermination des objectifs du cycle, des alternatives pour

les atteindre et des contraintes

2) Analyse des risques, évaluation des alternatives et

éventuellement maquettage

3) Développement et vérification de la solution retenue

4) Revue des résultats et planification du cycle suivant

 ANALYSE & DÉFINITION DES BESOINS

1\ Définition :
Les problèmes soumis aux ingénieurs logiciels sont souvent
d’une complexité extrême, il est donc important de préciser en
détails les besoins exprimés par l’utilisateur
L’analyse et définition des besoins est un processus visant à
établir quelles fonctionnalités le système doit fournir et les
contraintes auxquelles il sera soumis, c’est la première grande
étape du cycle de vie d’un logiciel

2\ Cahier des charges :

Le résultat de l’analyse & définition des besoins est le cahier
des charges, il doit décrire le futur système logiciel que l’on veut
bâtir de manière précise et complète tout en éliminant les
informations non pertinentes, superflue ou incomplète. Ce n’est
pas un document de conception, il doit juste décrire ce que le
système doit faire sans spécifier comment il doit le faire

Critères du cahier des charges :

• spécifier uniquement le comportement externe du système
• spécifier les contraintes de réalisation
• doit être facile à mettre à jour
• servir d’outil de référence aux programmeurs de maintenance
• contenir des indications concernant les étapes ultérieures du
cycle de vie du système
• spécifier les réponses acceptables aux événements non
désirables
3\ Structure d’un cahier des charges :

1) Introduction : décrit la raison d’être d’un tel système et place

celui-ci dans son contexte, donne brièvement ses fonctions,
précise la structure du document …

2) Matériel : définit le matériel utilisé par le système

3) Modèle conceptuel : définit une vue à très haut niveau des

fonctions majeures et de leurs relations, décrit par une notation
graphique

4) Besoins fonctionnels : décrit les services fournis à l’utilisateur

5) Les besoins en matière de base de données : décrit

l’organisation logique des données manipulées par le système
et leurs relations

6) Besoins non fonctionnels : décrit les contraintes sous

lesquelles le logiciel doit opérer, et les relier aux besoins
fonctionnels, par exemple : contraintes de temps, espace
mémoire, représentation des données, langage de
programmation …

7) Information destinée à la maintenance : décrit les hypothèses

fondamentales sur lesquelles le système est fondé ainsi que les
changements prévus du fait de l’évolution du matériel, des
besoins des utilisateurs …
8) Glossaire : définit les termes techniques utilisés dans le
document et ce de manière précise et sans faire aucune
présupposition sur l’expérience ou la formation du lecteur

9) Index : une liste alphabétique (ou par chapitre) des termes

ou sujets importants abordés dans le cahier des charges,
accompagnés des numéros de page correspondants

4\ Besoins fonctionnels :
Définissent les services attendus par l’utilisateur. En principe, ils
doivent constituer un ensemble complet et cohérent. il y’a 3
façons d’exprimer les besoins fonctionnels :

1) Langage naturel : c’est le plus utilisé car il est le plus

expressif et le plus compréhensible par les utilisateurs et les
développeurs à la fois

2) Langage structuré : repose sur le langage naturel mais suit

une certaine structure pour définir les besoins, peut même
disposer d’une notation graphique, le plus connu est l’UML

3) Langages formel : toujours au stade de recherche et est très

peu utilisée en réalité

5\ Besoins non fonctionnels :

Correspond à une restriction ou à une contrainte placée sur une
des fonctions du système comme par exemple : contraintes sur
le temps de réponse maximum, limitations sur l'espace
mémoire nécessaire …
 DIAGRAMME DES CAS D’UTILISATION

1\ Définition :
L’UML (Unified Modeling language) est un langage de
modélisation qui permet de modéliser selon une approche
orientée objet les éléments et les comportements des systèmes

2\ Cas d’utilisation :
Les cas d’utilisation décrivent sous la forme d’actions et de
réactions le comportement d’un système du point de vue d’un
utilisateur, le modèle des cas d’utilisation comprend : les
acteurs, le système et les cas d’utilisation eux-mêmes

Acteur : représente un rôle joué par une personne ou une

chose qui interagit avec un système pour activer une
fonctionnalité (cas d’utilisation)
3\ Scénarios :
Les cas d’utilisation doivent être vus comme des classes dont
les instances sont les scénarios, chaque fois qu’un acteur
interagit avec le système, le cas d’utilisation instancie un
scénario, un use case comprend au moins 2 scénarios : un où
tout se passe bien (nominal) et un autre où il y a problème

Un cas d’utilisation décrit de manière abstraite une famille de

scénarios

4\ Relations dans un diagramme cas d’utilisation :

il existe 4 types de relations :

• Relation de communication
• Relation d’inclusion
• Relation d’extension
• Relation de généralisation
1) Relation de Communication : représente une interaction
entre un acteur et un cas d'utilisation, elle indique que les
entités impliquées communiquent entre-elles

2) Relation d’inclusion (include) : utilisée pour montrer qu'un

cas d'utilisation inclut le comportement d'un autre cas
d'utilisation

3) Relation d'extension (extend) : indique qu'un cas d'utilisation

peut être étendu par un autre cas d'utilisation dans certaines
conditions
4) Lien de généralisation : un lien de généralisation entre 2 cas
d’utilisation signifie que le cas d’utilisation spécialisé est plus
spécifique que le cas d’utilisation général, c’est l’équivalent de
l’héritage en POO
 DIAGRAMME DES CLASSES & DES OBJETS

1\ Définition :
La classe décrit le domaine de définition d’un ensemble
d’objets, chaque objet appartient à une classe, les généralités
sont contenues dans la classe et les particularités sont
contenues dans les objets, les objets informatiques sont
construits à partir de la classe, par un processus appelé
instanciation, de ce fait, tout objet est une instance de classe

Encapsulation : par défaut, les valeurs d’attributs d’un objet

sont encapsulées dans l’objet et ne peuvent pas être manipulés
directement par les autres objets. Toutes les interactions entre
les objets sont effectuées en déclenchant les diverses
opérations déclarées dans la spécification de la classe

Visibilité : détermine si d’autres classes peuvent l’utiliser cette

caractéristique, en UML, on utilise 4 niveaux de visibilité :
1) Public (+)
2) Protected (#)
3) Private (-)
4) Package (~)
A chaque famille de liens entre objets correspond une relation
entre les classes de ces mêmes objets, 2 types de relations :
1) Associations
2) Agrégations

2\ Association :
Exprime une connexion sémantique bidirectionnelle entre
classes, les associations se représentent de la même manière
que les liens

Rôles : il est possible de préciser le rôle d’une classe au sein

d’une association, un nom de rôle peut être spécifié de part et
d’autre de l’association
Multiplicité : les rôles portent une information qui précise le
nombre d’instances qui participent à la relation

Classes d’associations : une classe d’association encapsule les

informations concernant une association
Associations réflexives : Une association est réflexive si elle
s’applique à des objets d’une même classe

Relations n-aires : les relations n-aires sont modélisables, on

les détecte lorsqu'il est nécessaire d'avoir un identifiant multiple

Contraintes : c’est une relation sémantique quelconque entre

les éléments de modélisation qui définit des propositions devant
être maintenues à vraies pour garantir la validité du système
Stéréotype : permet aux utilisateurs
(méthodologistes, constructeurs d’outils,
analystes et concepteurs) d’ajouter de
nouvelles classes d’éléments de modélisation
en plus du noyau prédéfini par UML

Interfaces : décrit le comportement d’une classe, d’un

composant, d’un sous-système, d’un paquetage ou de tout
autre classificateur, elle possède uniquement la spécification
d’un comportement visible, sous forme d’un ensemble
d’opérations (pas d’attributs et d’associations) et ne fournit
aucune implémentation de ses services

Remarque : Une relation exprime une forme de couplage entre

abstractions, par défaut, l’association représente un couplage
faible car les classes associées restent relativement
indépendantes l’une de l’autre
3\ Agrégation :
C’est un type particulier d’association qui exprime un couplage
plus fort entre classes, une des classes joue un rôle plus
important que l’autre dans la relation. L’agrégation permet de
représenter des relations de type maître et esclaves

Composition : c’est une forme d’agrégation avec un couplage

plus important, ce couplage de composition indique que les
composants ne sont pas partageables et que la destruction de
l’agrégat entraîne la destruction des composants agrégés

Remarque : pour faire la différence entre agrégation et

composition, on doit se poser ces 2 questions :

1) La suppression du grand implique la suppression du petit ?

2) est-ce que le petit peut appartenir à plusieurs grand ?

Non & Oui  agrégation

Oui & Non  composition

Exemples :

Si une équipe est dissoute, les membres continuent d’avoir une

existence propre donc c’est une agrégation

Si un livre est détruit, ses chapitres sont détruits également

donc c’est une composition
4\ Hiérarchies de classes :
Les hiérarchies de classes ou classifications permettent de
gérer la complexité en ordonnant les objets au sein
d’arborescences de classes d’abstraction croissante

Généralisation : il s’agit de prendre des classes existantes et de

créer de nouvelles classes qui regroupent leurs parties
communes, il faut aller du plus spécifique vers le plus général
Spécialisation : il s’agit de sélectionner des classes existantes
et d’en dériver de nouvelles classes plus spécialisées, en
spécifiant simplement les différences

5\ Généralisation :
Consiste à factoriser les éléments communs d’un ensemble de
classes dans une classe plus générale appelée super-classe
Les classes sont ordonnées selon une hiérarchie, une super-
classe est une abstraction de ses sous-classes

Règles de généralisation :
- La généralisation ne porte ni nom particulier ni valeur de
multiplicité
- Une classe ne peut pas dériver d’elle-même (relation non
réflexive)
- si une classe B dérive d’une classe A, alors la classe A ne
peut pas dériver de la classe B (relation non symétrique)
- Si C dérive d’une classe B qui dérive elle-même d’une classe
A alors C dérive également de A (relation transitive)
Généralisation multiple : pour utiliser cette
généralisation, il faut que les langages de
programmation supportent l’héritage
multiple, par exemple le C++ le supporte,
le JAVA lui ne le supporte pas

6\ Autres concepts :

Classe abstraite : ce type de classe ne donne pas directement

des objets, elle sert juste de spécification plus abstraite pour
des objets instances de ses sous-classes, le principal intérêt de
cette démarche est de réduire le niveau de détails dans les
descriptions des sous-classes
L'héritage : c’est une technique permettant de construire une
classe en se basant sur une ou plusieurs autres classes, elle
permet le partage d'attributs, d'opérations, et parfois de
contraintes au sein d'une hiérarchie de classes, les classes
enfants héritent des caractéristiques de leurs parents, cela
facilite la réutilisation du code et favorise une organisation
logique et hiérarchique des fonctionnalités dans un programme

Polymorphisme : un nom d’objet peut désigner des instances

de classes différentes issues d’une même arborescence
Diagramme des Objets : ce diagramme est un outil de
recherche et de test, il peut aider à comprendre un problème ou
à valider un diagramme de classes en représentant des
exemples, il est constitué de 2 éléments : les objets et les liens
 DIAGRAMME D’INTERACTIONS

1\ Définition :
Les diagrammes d'interaction sont une catégorie des
diagrammes UML qui fournissent une vision du déroulement
des opérations et des échanges entre les objets, mettant
l'accent sur la manière dont ces objets collaborent pour
accomplir une tâche spécifique, Il existe 2 diagrammes :
• Les diagrammes de communication (collaboration)
• Les diagrammes de séquence

2\ Diagramme de communication (collaboration) :

• Met en évidence les liens entre les objets et les messages
échangés, mais sans détailler la chronologie de ces échanges
• Ce diagramme offre une vue plus globale des collaborations
entre objets, mettant l'accent sur les relations et les interactions
plutôt que sur la séquence temporelle des messages
• Les objets sont représentés par des rectangles, et les liens
entre eux sont indiqués par des lignes avec des flèches
représentant les messages
Itération d’un message :

La place de l’utilisateur :
Syntaxe d’un message :

Enrichissement des messages :

3\ Diagramme de séquences :
• Un diagramme de séquence montre quels sont les objets qui
participent à une interaction et quels sont les messages qu’ils
échangent d’un point de vue temporel

Dimension d’un diagramme de séquence :

• La dimension horizontale  les instances ou les objets
• La dimension verticale  le temps

Ligne de vie : à chaque objet est associé une ligne de vie qui
est considérée comme un axe temporel, l’évolution du temps se
lit de haut en bas
Période d’activation : la ligne de vie indique les périodes
d’activité de l’objet, l'objet est actif afin d’exécuter une action,
on peut aussi ajouter des contraintes ou des notes

Message synchrone : l’émetteur est bloqué et attend que

l’appelé ait fini de traiter le message

Message asynchrone : l’émetteur n’est pas bloqué et peut

continuer son exécution
Message de retour : si une méthode qui a été activée (par un
message) doit retourner des valeurs à la fin de son activation,
cela se fait par un message retour, le récepteur d’un message
synchrone rend la main à l’émetteur du message en lui
envoyant un message de retour, Le message retour porte
souvent le nom de l’élément retourné

Message de création d’objet : est matérialisée par un message

spécifique, appel d’un constructeur, généralement accompagné
du stéréotype create
Message de destruction d’objet : est représentée par une croix
à la fin de sa ligne de vie, il porte le stéréotype destroy

Syntaxe des messages synchrones et asynchrones : ce type de

message est caractérisé par nom qui est le nom de la méthode
appelée ou du signal envoyé, nous pouvons lui ajouter
facultativement une numérotation séparée du nom du message
par " : " et les paramètres passés à la méthode ou au signal
entre parenthèses après le nom du message
Le message de retour peut se contenter d’un simple nom,
comme on peut préciser plus de détail en utilisant la syntaxe
suivante : numéro : attribut = nom (paramètres)
Ou encore :
numéro : attribut = nom (paramètres) : valeur de retour

Remarques :
• Lorsqu’un objet est déjà activé il peut quand même recevoir
d’autres messages
• Un objet peut s’envoyer un message à lui-même
• Cela se représente par un dédoublement de la bande
d’activation
Contrainte temporelle : des repères temporels avec des
contraintes peuvent être placés le long de la ligne de vie, par
exemple un message avec un temps de propagation non
négligeable peut être représenté par une flèche oblique ou en
l'écrivant explicitement

4\ Fragment d’interaction combiné :

C’est une partie du diagramme de séquence délimitée par un
rectangle associée à une étiquette dans le coin supérieur
gauche, l’étiquette contient un opérateur d’interaction qui
permet de décrire des modalités d’exécution des messages à
l’intérieur du cadre. Les conditions de choix des opérandes sont
données par des expressions booléennes entre [ ]
Il existe principalement 8 opérateurs utilisés :
• option • parallel • alternative • critical region
• Loop • break • strict • weak

• L’opérateur option (opt) comporte un opérande et une

condition de garde associée, le sous fragment s’exécute si la
condition de garde est vraie et ne s’exécute pas dans le cas
contraire

• L’opérateur alternatives (alt) est un opérateur conditionnel

possédant plusieurs opérandes séparés par des pointillés …
C’est l’équivalent d’une exécution à choix multiples
Chaque opérande détient une condition, seul le sous-fragment
dont la condition est vraie est exécuté
La condition else est exécutée que si aucune autre condition
n’est valide
• L’opérateur de boucle (loop) exécute des itérations tant que la
garde qui lui est associée est vraie, la garde s’écrit de la façon
suivante : loop [min, max, condition]

Les 3 paramètres min, max et condition sont optionnel

Exemples :
Loop [3 ]: la séquence s’exécute 3 fois
Loop [1, 3, code=faux] : la séquence s’exécute 1 fois puis un
maximum de 2 autres fois si code = faux

• Si la condition du break est vraie, on exécute le fragment

associé et on ignore le reste du fragment, sinon on passe
directement à la suite du fragment englobant
• Un fragment d’interaction avec l’opérateur de traitements
parallèles (par) contient au moins 2 sous fragments séparés par
des pointillés qui s’exécutent simultanément

• Avec l’opérateur strict es fragments s’exécutent les uns après

les autres
• L’opérateur ref est utilisé pour faire référence à une interaction
dans la définition d’une autre interaction, cela permet la
réutilisation d’une définition dans des contextes différents

 Exemple
 Diagramme d’états & d’activités

1\ Diagrammes d’états-transitions :
Les diagrammes d’états-transitions visualisent des automates
d’états finis, du point de vue des états et des transitions, ils
représentent généralement le comportement de classes

Exemple : automate lié au cycle de vie d’un livre

Les états initiaux et finaux : un diagramme d’états-transitions ne

doit pas contenir d’ambiguïté, cela signifie qu’il faut toujours
décrire l’état initial du système, en revanche, il est possible
d’avoir plusieurs états finaux qui correspondent chacun à une
condition de fin différente, ou bien carrément aucun état final
Transitions : connexions unidirectionnelles qui relie les états
entre eux, le passage d’un état à l’autre s’effectue lorsqu’une
transition est déclenchée par un événement

Remarques :
• Tout message est un événement impliqué dans l’interaction
de deux objets
• Tout événement n’est pas un message, car il n’est pas
forcément émis par un objet

On a 4 types d’événement :

• Signal : c’est une spécification d’un stimulus asynchrone entre

deux instances, souvent un gestionnaire d’exceptions

• Appel : réception d’un appel d’opération

• Temporel : expiration d’une temporisation

• Modification : expression logique qui change d’état

Garde : c’est une condition booléenne qui valide ou non le

déclenchement d’une transition dors de l’occurrence d’un
événement
Activité : c’est une opération continue dans le temps, elle prend
un certain temps pour se réaliser, elle est liée à un état
Le nom d’une activité s’inscrit à l’intérieur du rectangle aux
coins arrondis représentant l’état, précédé de la notation do

Action : c’est une opération instantanée, elle est réalisée de

façon immédiate, et peut être associée aussi bien à l’état d’un
objet qu’à une transition, elle peut intervenir soit :

• en entrée d’état (préfixe entry)

• en sortie (préfixe exit)

• en réponse à un événement (on event)

• au cours d’une transition, dans ce cas, le nom de l’action

figure après la liste des gardiens, précédé du signe /

Interruption des activités : contrairement aux actions, les

activités peuvent être interrompues à tout moment, dès qu’une
transition de sortie de l’état est déclenchée
Transitions composites :

États disjoints : un état peut se décomposer en plusieurs sous-

états disjoints, les sous-états héritent des caractéristiques de
leur état composite, en particulier des transitions externes
États concurrents : un état peut être composé de plusieurs
sous-états concurrents appelés régions (orthogonales)
Communication entre objets : les envois de messages entre
deux objets sont visualisés par l’envoi d’un événement entre les
automates d’états-finis des classes d’objets concernés, la
syntaxe d’un envoi d’événement vers une classe est :
^[Link]énement(Arguments)

Création et destruction d’objets :

• La création d’un objet se représente par l’envoi d’un
événement de création à la classe de l’objet
• La destruction est effective lorsque le flot de contrôle de
l’automate atteint un état final non emboîté

Diagramme d’activité   Résumé des titres