Cours3 Génie Logiciel 1

‫ور ا زا ر ا د راط ا‬ ‫ا‬
Ministère de l’Enseignement Supérieur ‫وزارة اﻝﺘﻌﻠﻴم اﻝﻌﺎﻝﻲ و اﻝﺒﺤث اﻝﻌﻠﻤﻲ‬ Objectifs de la matière
et de la Recherche Scientifique
‫ﺠﺎﻤﻌﺔ ﻗﺎﻝﻤﺔ‬
Université 08 mai 1945 Guelma
Faculté des Mathématiques et de
l’Informatique et des Sciences de la
‫ﻜﻠﻴـﺔ اﻝرﻴﺎﻀﻴﺎت و اﻹﻋﻼم اﻵﻝﻲ وﻋﻠوم اﻝﻤﺎدة‬
• Le module vise à:
Matière ‫اﻹﻋﻼم اﻵﻝﻲ‬:‫ﻗﺴم‬
– Comprendre les principes fondamentaux de l’approche orienté
Département d’Informatique
objet
– Identifier les apports de la modélisation UML
– S’initier aux techniques de modélisation orientées objet.
• Coefficient: 2
Cours: Génie Logiciel 1 • Crédit: 4
DJAKHDJAKHA L. • Mode d’évaluation:
ldjakhdjakha@yahoo.fr – Contrôle continu: 40%
– Examen écrit: 60%
Génie logiciel 1
2
Contenu de la matière Références
• Chapitre 1/ Introduction • Modélisation objet avec UML. Pierre-Alain Muller, -

– Introduction à la modélisation Orienté Objet
– Modélisation, modèle, concepts de modélisation, UML Éditions Eyrolles, 2003
• Chapitre 2/ Modélisation avec UML • Modélisation et conception orientées objet avec UML 2.
– Introduction
– Éléments et mécanismes généraux M. Blaha et J. Rumbaugh. 2ème édition. Pearson
– Les diagrammes UML Education, 2005.
– Paquetages
• Chapitre 3/ Diagramme UML de cas d’utilisation: vue fonctionnelle • Cours UML 2.0 de Laurent Audibert , site
– Intérêt, définition et notation http://www.developpez.com.
• Chapitre 4/ Diagramme UML de classes et d’objets: vue statique
– Diagramme de classes • Shari Lawrence Pfleeger and Joanne M. Atlee, Software
– Diagramme d’objets Engineering, Fourth Edition, Pearson, 2010.
• Chapitre 5/ Diagramme UML: vue dynamique
– Diagramme d’interaction (séquence et collaboration)
• Bern Bruegge and Allen H. Dutoit, Object-Oriented
– Diagramme d’activités Software Engineering – using UML, Patterns and Java,
– Diagramme d’états/transitions Third Edition, Pearson, 2010.
Génie logiciel 1 Génie logiciel 1 4
3
L’informatisation
• L'informatique est au cœur de toutes les grandes entreprises.

• Le système d'information d'une entreprise est composé de
matériels et de logiciels.
Chapitre 1/ Introduction
• Plus précisément, les investissements dans ce système
d'information se répartissent généralement de la manière
1.1. Introduction à la modélisation Orienté Objet suivante :
1.2. Modélisation, modèle, concepts de modélisation, UML – 20 % pour le matériel ,
– 80 % pour le logiciel.
• En effet, depuis quelques années, la fabrication du matériel
est assurée par quelques fabricants seulement.
• Ce matériel est relativement fiable et le marché est
standardisé.
• Les problèmes liés à l'informatique sont essentiellement des
problèmes de logiciel.
Génie logiciel 1
6
2ème Année licence 1

Le logiciel La crise du logiciel (1/3)
• Un logiciel ou une application est un ensemble de

programmes,
• Permet à un ordinateur ou à un système informatique • Les échecs de grands projets durant les années 60 et au
d'assurer une tâche ou une fonction en particulier début des années 70 ont mis en évidence les problèmes
• Exemple : logiciel de comptabilité, logiciel de gestion des de la gestion de projet.
prêts, etc. • Ces projets n'ont pas échoué parce que les
programmeurs étaient incompétents. La faute incombait
en fait aux techniques de gestion des projets mises en
œuvre.

7
La crise du logiciel (2/3) La crise du logiciel (3/3)
En 1979, le gouvernement américain estimait que la

plupart des grands projets avaient échoué : Les symptômes les plus caractéristiques de cette
– Payés mais jamais livrés 47 % crise sont décrits par Booch en 1983 :
– Livrés mais jamais utilisés 30 % – Les logiciels réalisés ne correspondent souvent pas aux
– Abandonnés ou refaits 20 % besoins des utilisateurs,
– Utilisés après modifications 3%
– Les logiciels contiennent trop d'erreurs (la qualité du
– Utilisés en l’état 2% logiciel est insuffisante),
– Les coûts du développement sont rarement prévisibles
– La maintenance des logiciels est une tâche complexe et
coûteuse,
– Les délais de réalisation sont généralement dépassés,
– Les logiciels sont rarement portables.
Génie logiciel 1 9 Génie logiciel 1 10
Naissance du génie logiciel Génie et génie logiciel
• Le génie logiciel existe depuis une quarantaine

d'années seulement.
• Il est né en 1968 à Garmisch (Allemagne) (« 1st Génie : ensemble des connaissances et des
conference on software engineering ». techniques concernant la conception, la mise en
œuvre et les applications de procédés, de
• Il a été défini de toutes pièces par un groupe de dispositifs, de machines propres à un domaine
scientifiques pour répondre à la crise du logiciel donné (Petit Larousse Illustré).
avec quelques idées émergentes :
– La production de logiciel doit être organisée, Génie logiciel : ensemble des activités de
– Contrôle des coûts et de la qualité, etc ... conception et de mise en œuvre des produits et
des procédures tendant à rationaliser la production
du logiciel et son suivi.

La structure organisationnelle
Définition du génie logiciel
d’un projet
Le génie logiciel est l’ensemble des moyens

techniques, industriels et humains qu’il faut réunir
pour spécifier, construire, distribuer et maintenir des Maîtrise d'ouvrage
logiciels qui soient sûrs, conviviaux (facile à utiliser),
évolutifs et économiques.
Les instances du projet
Le but est donc d’améliorer la qualité et la
productivité. Maîtrise d'oeuvre
La maîtrise d’ouvrage Le maître d’ouvrage
• Elle est le client du projet d’informatisation. • Il est le commanditaire de l’opération et, à ce titre, il doit
en définir les enjeux, les objectifs et les exigences
• C’est au sein de la maîtrise d’ouvrage que l’on qualité (avec l’aide de son représentant et de la maîtrise
trouve les experts métier et les groupes de d’œuvre le cas échéant).
validation. • Il est le propriétaire de l’application qui est réalisée.
• Il est le donneur d’ordre et met en place les
• Elle regroupe les acteurs suivants : financements nécessaires.
– Le maître d’ouvrage, • Il décide du déploiement ou non de l’application.
– Le représentant de la maîtrise d’ouvrage
– Les utilisateurs,
– Etc ...
Le représentant de la maîtrise
Les utilisateurs
d’ouvrage
• Il représente le maître d’ouvrage tout au long du • Les utilisateurs ne participent pas au management
projet. de projet mais il paraît néanmoins important de
• Il a pour rôle : rappeler que ce sont les bénéficiaires de
– D’assurer la conduite générale du projet, l’application et, qu’à ce titre, ils sont finalement les
vrais juges de la qualité des produits livrés.
– De veiller au respect des objectifs généraux du projet,
• Plusieurs niveaux d’utilisateurs interviennent dans
– De produire l'expression des besoins, l’élaboration des produits :
– De gérer les enveloppes financières, – L’utilisateur final utilise l’application quotidiennement. Il
– De valider les documents relatifs au projet ainsi que apporte les besoins d’ergonomie et d’organisation de son
les maquettes et les prototypes, poste de travail,
– De préparer et exécuter la recette de l’application, – Le responsable du service utilisateur donne son avis sur
les choix organisationnels,
– De mettre en place les mesures d’accompagnement – Les utilisateurs de niveau hiérarchique supérieur
du changement. définissent les objectifs stratégiques.

La maîtrise d’œuvre Le maître d’œuvre
• Elle est responsable de la réalisation de

l’application pour la maîtrise d’ouvrage. • Il est garant de la qualité des produits finis.
• C’est le prestataire du projet choisi par la • Il affecte les moyens sur le projet.
maîtrise d’ouvrage. • Il est responsable du suivi contractuel avec le maître
d’ouvrage et, le cas échéant, avec les sous-traitants.
• Elle regroupe les acteurs suivants :
– Le maître d’œuvre,
– L’équipe projet qui peut regrouper de nombreuses
compétences si le projet est complexe et s’il s’agit
d’un développement objet : le chef de projet, le
spécificateur, l’architecte, le développeur fonctionnel,
le développeur technique, le qualiticien, ...
Le chef de projet L’analyste

• Il détermine le périmètre fonctionnel et les acteurs (au
sens UML) de la future application.
• Le chef de projet est responsable de la mise en œuvre • Il rédige les spécifications fonctionnelles générales et
du projet en respectant les délais, les coûts et les détaillées.
exigences de qualité, fixés dans le cadre d’un
• Il identifie les flux de données à gérer.
engagement de résultat contractualisé avec la maîtrise
d’ouvrage.
• Il doit gérer au mieux les ressources humaines et
matérielles qui sont affectées sur le projet.
L’architecte Le développeur fonctionnel
• Il recense les besoins techniques. • Il réalise les applications décrites dans les spécifications
• Il élabore les architectures logicielle et applicative. fonctionnelles, en tenant compte de l’architecture
• Il identifie les besoins en produits tiers (composants applicative, des frameworks techniques et des règles de
techniques et fonctionnels) et frameworks techniques. développement.
• Il développe donc les classes métier dans un
développement objet.

Le développeur technique Le qualiticien
• Il réalise les bibliothèques de composants et les • Il définit les dispositions d’assurance qualité formalisées
frameworks techniques en collaboration avec dans le plan d’assurance qualité.
l’architecte. • Il veille à la mise en application de ces dispositions.
• Il développe donc les classes techniques de bas niveau • Il définit les actions correctives si les dispositions ne sont
dans un développement objet. pas appliquées.
• Il vérifie et rend compte de la mise en application de ces
actions.
Le comité de pilotage Le comité de suivi
• Il est constitué :
– Du maître d’ouvrage qui en assure la présidence et de son
représentant, • Il est composé au minimum du représentant de la
– Des représentants des utilisateurs de l’application, maîtrise d’ouvrage et du chef de projet.
– Du maître d’œuvre et du chef de projet, • Il est en charge du pilotage opérationnel du projet,
– Des maîtres d’ouvrage des applications communicantes. s’assure que le projet poursuit les objectifs initiaux et
• Il lance officiellement le projet et valide les livrables détecte les dérives éventuelles.
stratégiques du projet (analyse et conception • Il analyse périodiquement les livrables et, en fonction
fonctionnelles, conception technique). des résultats, met à jour le planning de suivi.
• Il valide le produit final sur la base de la recette et de
l’expérimentation en site pilote et autorise la mise en
exploitation.
Plan qualité Qu’est-ce qu’une norme ?
Le plan qualité est un document qui présente :

« Document établi par consensus et approuvé par un
• le produit, le projet et/ou le contrat auquel il s’applique,
organisme reconnu, qui fournit, pour des usages
• les objectifs relatifs à la qualité du projet, du produit et/ou
du contrat exprimés en termes mesurables chaque fois communs et répétés, des règles, des lignes directrices
que cela est possible, ou des caractéristiques, pour des activités ou leurs
• les exclusions spécifiques, résultats, garantissant un niveau d’ordre optimal dans
• la période de validité, un contexte donné. »
• Etc ...

Les instances de normalisation Norme ISO 9126
Il y a de nombreuses instances de normalisation
qui ont des compétences géographiques • Objet : évaluation des produits logiciels -
différentes : caractéristiques qualité et directives pour leur
– 2 organisations de normalisation de niveau international : utilisation - parue en octobre 1992 (amendée par
la CEI (Commission Electrotechnique Internationale) et une norme équivalente en septembre 2002).
l'ISO (Organisation Internationale de Normalisation), • Cette norme recense six "caractéristiques qualité"
– Quelques organisations de normalisation de niveau normalisées : capacité fonctionnelle, fiabilité,
régional : le CENELEC (Comité Européen de facilité d'utilisation, rendement, maintenabilité et
Normalisation Electrotechnique), le COPANT (Pan
American Standards Commission), ...
portabilité.
– Quelques organisations de normalisation de niveau • Ces caractéristiques comprennent notamment la
national : l’AFNOR (Association Française de capacité d’intégration de l’existant, l’ergonomie,
Normalisation), l’ANSI (American National Standards l’évolutivité fonctionnelle, dimensionnelle (nombre
Institute), ... de personnes) et matérielle (nombre de serveurs).
Fiabilité (reliability)
Capacité fonctionnelle (functionality)
Ensemble d'attributs portant sur l'existence d'un

Ensemble d'attributs portant sur l'aptitude du logiciel
ensemble de fonctions et leurs propriétés à maintenir son niveau de service dans des
données. Les fonctions sont celles qui satisfont conditions précises et pendant une période
aux besoins exprimés ou implicites : déterminée :
– Aptitude (... à la tâche), – Maturité (fréquence des défaillances, densité des défauts),
– Exactitude (précision), – Tolérance aux fautes (... aux défaillances, stabilité du
– Interopérabilité (possibilités d’interaction avec produit),
d’autres systèmes), – Possibilité de récupération (en cas de défaillance).
– Conformité réglementaire (... aux lois, aux normes),
– Sécurité (d’accès).
Facilité d'utilisation (usability) Rendement (efficiency)
Ensemble d'attributs portant sur l'effort nécessaire Ensemble d'attributs portant sur le rapport existant
pour l'utilisation et l'évaluation individuelle de cette entre le niveau de service d'un logiciel et la quantité
utilisation par un ensemble défini ou implicite de ressources utilisées, dans des conditions
d'utilisateurs : déterminées :
– Facilité de compréhension, – Comportement par rapport au temps (temps de réponse),
– Facilité d'apprentissage, – Comportement par rapport aux ressources (mémoire,
– Facilité d'exploitation (trouver de nouvelles fonctions). stockage des données en persistance).

Maintenabilité (maintenability) Portabilité (portability)
Ensemble d'attributs portant sur l'effort Ensemble d'attributs portant sur l'aptitude du
nécessaire pour faire des modifications logiciel à être transféré d'un environnement à
données: l'autre :
– Facilité d'analyse (trouver la source d’erreurs), – Facilité d'adaptation (... à différents environnements),
– Facilité de modification, – Facilité d'installation,
– Stabilité (risque d’effets imprévus après modification), – Conformité aux règles de portabilité,
– Facilité de validation (... après modification). – Interchangeabilité (substitution par un autre logiciel
similaire).
Qu’est-ce qu’un modèle?
• Un modèle est une représentation abstraite et simplifiée

(i.e. qui exclut certains détails), d'une entité (phénomène,
processus, système, etc.) du monde réel en vue:
Chapitre 1/ Introduction
– de le décrire,
– de l'expliquer ou
1.1. Introduction à la modélisation Orienté Objet
– de le prévoir.
1.2. Modélisation, modèle, concepts de modélisation, UML
• Concrètement, un modèle permet de réduire la complexité
d'un phénomène en éliminant les détails qui n'influencent
pas son comportement de manière significative.
• Il reflète ce que le concepteur croit important pour la
compréhension et la prédiction du phénomène modélisé.
• Les limites du phénomène modélisé dépendant des objectifs
du modèle.
Génie logiciel 1
40
Pourquoi modéliser? (1/2) Pourquoi modéliser? (1/2)
• Modéliser un système avant sa réalisation permet de • Dans le domaine de l'ingénierie du logiciel, le modèle
mieux comprendre le fonctionnement du système. permet de mieux répartir les tâches et d'automatiser
• C'est également un bon moyen de maîtriser sa certaines d'entre elles.
complexité et d'assurer sa cohérence. • C'est également un facteur de réduction des coûts et
• Un modèle est un langage commun, précis, qui est des délais.
connu par tous les membres de l'équipe et il est donc, à • Le choix du modèle a donc une influence capitale sur les
ce titre, un vecteur privilégié pour communiquer. solutions obtenues.
• Selon les modèles employés, la démarche de
modélisation n'est pas la même.
Génie logiciel 1 Génie logiciel 1

41 42

Le cycle de vie d’un logiciel Les étapes de cycle de vie (1/5)
• Le cycle de vie d'un logiciel (en anglais software lifecycle), Le cycle de vie du logiciel comprend généralement au
désigne toutes les étapes du développement d'un logiciel, de
sa conception à sa disparition. minimum les étapes suivantes :
• L'objectif d'un tel découpage est de permettre de définir des • Analyse des besoins et faisabilité
jalons intermédiaires permettant :
• la validation du développement logiciel, c'est-à-dire la conformité du c'est-à-dire l'expression, le recueil et la formalisation
logiciel avec les besoins exprimés, et des besoins du demandeur (le client) et de l'ensemble
• la vérification du processus de développement, c'est-à-dire des contraintes, puis l'estimation de la faisabilité de ces
l'adéquation des méthodes mises en œuvre.
• L'origine de ce découpage provient du constat que les erreurs besoins ;
ont un coût d'autant plus élevé qu'elles sont détectées • Spécifications ou conception générale
tardivement dans le processus de réalisation.
• Le cycle de vie permet : il s'agit de l'élaboration des spécifications de
• de détecter les erreurs au plus tôt et ainsi l'architecture générale du logiciel
• de maîtriser la qualité du logiciel, les délais de sa réalisation et les
coûts associés.

43 44
Les étapes de cycle de vie (2/5) Les étapes de cycle de vie (3/5)
• Conception détaillée • Intégration

cette étape consiste à définir précisément chaque sous- l'objectif est de s'assurer de l'interfaçage des différents
ensemble du logiciel ; éléments (modules) du logiciel. Elle fait l'objet de tests
• Codage (Implémentation ou programmation) d'intégration consignés dans un document ;
c'est la traduction dans un langage de programmation des • Qualification (ou recette)
fonctionnalités définies lors de phases de conception ; c'est-à-dire la vérification de la conformité du logiciel aux
• Tests unitaires spécifications initiales ;
ils permettent de vérifier individuellement que chaque • Documentation
sous-ensemble du logiciel est implémenté conformément elle vise à produire les informations nécessaires pour
aux spécifications ; l'utilisation du logiciel et pour des développements
ultérieurs ;

45 46
Les étapes de cycle de vie (4/5) Les étapes de cycle de vie (5/5)
• Mise en production • La séquence et la présence de chacune de ces activités

c'est le déploiement sur site du logiciel ; dans le cycle de vie dépendent du choix d'un modèle
• Maintenance de cycle de vie entre le client et l'équipe de
développement.
elle comprend toutes les actions correctives
(maintenance corrective) et évolutives (maintenance
évolutive) sur le logiciel. • Le cycle de vie permet de prendre en compte, en plus
des aspects techniques, l'organisation et les aspects
humains.

47 48

Le cycle de vie du logiciel Le modèle en cascade (1/2)
• Le cycle de vie du logiciel débute par la décision de • Le cycle de vie en cascade a été décrit par
réaliser le logiciel et se termine par la décision de ne Royce dès 1970.
plus le garder en exploitation. • Il présente le développement logiciel comme
• Il y a trois principaux modèles de cycle de vie : une suite de phases qui s’enchaînent dans un
– Les cycles de vie linéaires, déroulement linéaire, depuis l’analyse des
– Les cycles de vie en « V », besoins jusqu’à la livraison du produit au client.
– Les cycles de vie itératifs et incrémentaux. • Le développement en cascade est en général
rythmé par la génération de documents qui
servent de validation pour le passage d’une
phase à l’autre : ce sont les livrables ou produits
finis documentaires.
• Chaque phase est donc achevée avant que ne
débute la suivante.
Le modèle en cascade (2/2)

Les limites des cycles de vie
Étude de faisabilité
linéaires
Validation
Analyse des besoins • Des difficultés surviennent s’il est impossible d’obtenir de
Validation l’utilisateur un énoncé complet et cohérent de ses
Conception globale besoins.
Validation • L’environnement du logiciel peut être tellement mouvant
Conception détaillée qu’il est difficile de construire le logiciel sur des
Validation spécifications figées.
Codage
Tests unitaires
Intégration
Vérification du produit
Le modèle en « V » (1/7) Le modèle en « V » (2/7)
• « V » signifie que le développement du logiciel et le Spécifications

Scenarii de tests du système
Validation via les
développement des tests sont directement corrélés. du système tests d’acceptation
• Cette approche permet de vérifier la conformité à ce qui

devrait être fait et non ce qui a été fait. Conception préliminaire
Scenarii de tests des sous-systèmes
Intégration des sous-systèmes et
(sous-systèmes) modules, tests correspondants
• Les tests fonctionnels sont donc spécifiés lors de
l’analyse, les tests d’intégration lors de la conception et
les tests unitaires pendant la phase de codage. Conception détaillée
Scenarii de tests
des modules Tests unitaires des modules
(modules)
Codage des modules

Spécification du système, par

exemple via des diagrammes de flots
de données. Conception préliminaire
avec les choix de découpage
en sous-systèmes et la
Ce niveau de spécifications permet de
préparer la phase de validation du description des principales
système via des tests de validation. fonctions (modules) de ces
En effet, tous les scenarii de tests du sous-systèmes.
système sont déjà décrits.
Ce niveau de conception
permet de préparer les tests
d’intégration des sous-
systèmes. En effet, tous les
scenarii de tests
correspondants sont
cohérents avec les principes
d’utilisation de ressources
entre sous-systèmes .
Conception préliminaire,
sur la base des choix amont
de découpage en sous-
systèmes, avec les choix de
Conception détaillée, sur la base des choix
découpage en modules et la
amont de découpage en modules, avec la
description des principaux
description des traitements des modules.
traitements de ces modules.
Ce niveau de conception permet de préparer les
Ce niveau de conception
tests unitaires de chaque module. En effet, tous
permet de préparer les tests
les scenarii de tests des modules sont cohérents
d’intégration des modules.
avec les algorithmes prédéfinis.
En effet, tous les scenarii de
tests correspondants sont
cohérents avec les principes
d’utilisation de ressources
entre modules .
Le modèle en « W » (1/2)
Le modèle en « V » (7/7)
• Ce modèle est une variante du modèle en « V ».
• Le cycle de développement ne commence que quand

les problèmes ou les besoins sont parfaitement connus
(cf. module de communication selon la méthode Merise).
Codage des modules

• Un cycle en « W » peut être couplé à un cycle en « V »,
quand il est nécessaire de décomposer le système en
sous-systèmes.

Le modèle en « W » (2/2) Les limites des cycles de vie en
«V»
Exigences
brutes
Spécification des
IHM du système
Validation ou tests
d’acceptation
• Les cycles de vie sont trop longs.
• Les relations entre les clients et les fournisseurs
ne sont pas suffisamment formalisées.
Vérification des Conception des Intégration et tests
flux logiques sous-systèmes des sous-systèmes • Ils ne gèrent pas les risques.
• L’intégration est trop tardive dans le cycle de vie.
Conception des Intégration et tests
modules des modules
• La documentation est réalisée d’abord et le
2ème cycle de Goldberg logiciel après …
Codage et
tests unitaires
Le modèle incrémental (1/2) Le modèle incrémental (2/2)
Spécification Conception Conception

du logiciel détaillée Codage
globale
Intégration
Validation Vérification Installation
Test unitaire
Test fonctionnel
Recette
• Il est adapté à un développement et à une mise en Incrément 1
production par lots. Conception (noyau)
détaillée Codage
• Les phases s’achèvent par une activité de contrôle ou Vérification

Intégration
Installation
Test unitaire
de test. Test fonctionnel
Recette
Incrément 2
Conception
détaillée Codage
Intégration
Vérification Vérification Installation
Test unitaire
Test fonctionnel
Recette
Incrément 3
Le modèle en spirale (1/2) Le modèle en spirale (2/2)
• Ce modèle complexe est dû à Boehm.

• Il apporte une vue évolutive au modèle en cascade
au travers d’une approche fondée sur l’analyse et
la gestion des risques, puis la conception et la
réalisation de prototypes évolutifs en fonction de
l’avancement du projet.
• Le développement présente quatre grandes phases
qui se succèdent au fur et à mesure de la
construction de la spirale,
• Au dernier tour de la spirale, le produit est
totalement défini, les risques résolus et le produit
développé.

Les avantages des cycles de vie
itératifs et incrémentaux
Conclusion
• Ces processus sont basés sur l’évolution de • Il n’y a pas de modèle idéal car tout dépend des
circonstances.
prototypes exécutables : • Le modèle en cascade ou en V est risqué pour les
– L’utilisateur est placé devant des situations développements innovants car les spécifications et la
d’utilisation concrètes. Il est partenaire du projet. conception risquent d’être inadéquats et souvent remis
– L’intégration est progressive et permet d’éviter l’effet en cause.
« big bang » à l’approche de la date de livraison. • Le modèle incrémental est risqué car il ne donne pas
beaucoup de visibilité sur le processus complet.
– Les progrès se mesurent par des programmes
• Le modèle en spirale est un canevas plus général qui
démontrables et non par des documents ou inclut l’évaluation des risques.
estimations. • Souvent, un même projet peut mêler différentes
• Le découpage par incréments permet de réduire approches, comme le prototypage pour les sous-
systèmes à haut risque et la cascade pour les sous
la complexité du système en la ventilant dans systèmes bien connus et à faible risque.
les incréments.
Méthode d’analyse et de conception (1/3) Méthode d’analyse et de conception (2/3)
Les méthodes d'analyse et de conception fournissent une • La distinction entre composition et décomposition :
méthodologie et des notations standards qui aident à
Elle met en opposition d'une part les méthodes
concevoir des logiciels de qualité. Il existe différentes
ascendantes qui consistent à construire un logiciel par
manières pour classer ces méthodes, dont :
composition à partir de modules existants et, d'autre part,
les méthodes descendantes qui décomposent
récursivement le système jusqu'à arriver à des modules
programmables simplement ;

69 70
Méthode d’analyse et de conception (3/3) Méthodes fonctionnelles ou structurées (1/3)
La distinction entre fonctionnelle (dirigée par le traitement)

et orientée objet :
- Dans la stratégie fonctionnelle (également qualifiée de
structurée) un système est vu comme un ensemble
hiérarchique d'unités en interaction, ayant chacune une
fonction clairement définie.
- Les fonctions disposent d'un état local, mais le système a un
état partagé, qui est centralisé et accessible par l'ensemble
des fonctions.
- Les stratégies orientées objet considèrent qu'un système est
un ensemble d'objets interagissant.
- Chaque objet dispose d'un ensemble d'attributs décrivant son
état et l'état du système est décrit (de façon décentralisée)
par l'état de l'ensemble.

71 72

Méthodes fonctionnelles ou structurées (2/3) Méthodes fonctionnelles ou structurées (3/3)
• Les méthodes fonctionnelles (également qualifiées de méthodes • L'approche fonctionnelle dissocie le problème de la
structurées) trouvent leur origine dans les langages procéduraux.
représentation des données, du problème du traitement
• Elles mettent en évidence les fonctions à assurer et proposent une
approche hiérarchique descendante et modulaire. de ces données.
• Ces méthodes utilisent intensivement les raffinements successifs • Sur la figure diapo 71, les données du problème sont
pour produire des spécifications dont l'essentiel est sous forme de représentées sur la gauche. Des flèches transversales
notation graphique en diagrammes de flots de données.
• Le plus haut niveau représente l'ensemble du problème (sous forme matérialisent la manipulation de ces données par des
d'activité, de données ou de processus, selon la méthode). sous-fonctions.
• Chaque niveau est ensuite décomposé en respectant les • Cet accès peut-être direct (c'est parfois le cas quand les
entrées/sorties du niveau supérieur.
données sont regroupées dans une base de données),
• La décomposition se poursuit jusqu'à arriver à des composants
maîtrisables ou peut être réalisé par le passage de paramètre depuis
le programme principal.

73 74
L’approche orienté objet Notions d’objet
• L'approche objet considère le logiciel comme une Un objet est caractérisé par plusieurs notions :
• L'identité
collection d'objets dissociés, identifiés et possédant des l'objet possède une identité, qui permet de le distinguer des autres
caractéristiques. objets, indépendamment de son état. On construit généralement cette
identité grâce à un identifiant découlant naturellement du problème (par
• Une caractéristique est : exemple un produit pourra être repéré par un code, une voiture par un
– soit un attribut (i.e. une donnée caractérisant l'état de l'objet), numéro de série, etc.) ;
• Les attributs
– soit une entité comportementale de l'objet (i.e. une fonction).
il s'agit des données caractérisant l'objet. Ce sont des variables
• La fonctionnalité du logiciel émerge alors de l'interaction stockant des informations sur l'état de l'objet ;
entre les différents objets qui le constituent. • Les méthodes
les méthodes d'un objet caractérisent son comportement, c'est-à-dire
• L'une des particularités de cette approche est qu'elle l'ensemble des actions (appelées opérations) que l'objet est à même
rapproche les données et leurs traitements associés au de réaliser. Ces opérations permettent de faire réagir l'objet aux
sollicitations extérieures (ou d'agir sur les autres objets). De plus, les
sein d'un unique objet. opérations sont étroitement liées aux attributs, car leurs actions
peuvent dépendre des valeurs des attributs, ou bien les modifier.

75 76
Modélisation Orienté Objet Des Méthodes de modélisation
• La difficulté de cette modélisation consiste à créer une • L’apparition du paradigme objet à permis la naissance
représentation abstraite, sous forme d'objets, d'entités de plusieurs méthodes de modélisation
ayant une existence matérielle (chien, voiture, ampoule, – OMT (Object Modeling Technique), OOSE, Booch, Fusion, …
personne…) ou bien virtuelle (client, temps…). • Chacune de ces méthodes fournie une notation
• La Conception Orientée Objet (COO) est la méthode qui graphique et des règles pour élaborer les modèles
conduit à des architectures logicielles fondées sur les • Certaines méthodes sont outillées
objets du système, plutôt que sur la fonction qu'il est
censé réaliser.

77

UML
Trop de Méthodes En résumé (1/2)
• Entre 89 et 94 : le nombre de méthodes • UML signifie « Unified Modeling Language » ou Langage

orientées objet est passé de 10 à plus de 50 de modélisation unifié en français.
• C’est un langage de modélisation qui permet de
• Toutes les méthodes avaient pourtant
représenter graphiquement les besoins des utilisateurs.
d’énormes points communs (objets, méthode, On utilise pour cela des diagrammes.
paramètres, …) • UML est une démarche qui se base sur une approche
• Au milieu des années 90, G. Booch, I. Jacobson objet.
et J. Rumbaugh ont chacun commencé à • Cette approche s’appuie sur 4 principes fondamentaux.
adopter les idées des autres. Les 3 auteurs ont
souhaité créer un langage de modélisation unifié
c’est l’UML
En résumé (2/2)
Chapitre 2/ Modélisation avec UML
• L’approche objet nécessite une démarche itérative et
incrémentale, c’est-à-dire que le concepteur doit faire
des allers-retours entre les diagrammes initiaux et,
1. Introduction
2. Éléments et mécanismes généraux
• Les besoins du client et des utilisateurs perçus au fur
et à mesure de la conception du logiciel afin de le 3. Les diagrammes UML
modifier si nécessaire. 4. Paquetages
• L’approche objet est guidée par les besoins du client.
• L’approche objet est centrée sur le diagramme de
classes qui décrit aussi bien des actions que des
informations dans une même entité. Les autres
diagrammes nous aident à voir clair dans les besoins et
dans la solution qui est à développer. Ils permettent de
compléter le diagramme de classes.
Génie logiciel 1 81
1. Introduction (1/2) Introduction (2/2)
• Le rôle de la maîtrise d’ouvrage va croissant depuis • Au début des années 90, les méthodes objets ont
quelques années et exige des connaissances et un cherché à s’implanter. Succès mitigé : après avoir
savoir-faire spécifiques. sérieusement investi sur une méthodologie, les
• L’art de produire un cahier des charges porte même un entreprises freinent tout changement qui n’est pas
nom, l’ingénierie des besoins (requirements solidement justifié.
engineering). • La donne commence à changer et UML (Unified
• Il y a plus de vingt ans, la méthode Merise était parmi les Modeling Language, Langage de modélisation unifié) se
premières à prendre en compte le point de vue des présente aujourd’hui comme une alternative sérieuse.
gestionnaires, en proposant des modèles pour
représenter les aspects conceptuels (le sens des
informations, la structuration du système de gestion) et
organisationnels (choix d’informatisation, choix de
répartition du travail…).

Un peu d’histoire pour mieux comprendre (1/5) Un peu d’histoire pour mieux comprendre (2/5)
UML est le résultat de la fusion de trois méthodes • La méthode OMT, Object Modeling Technique, a été
d’analyse orientées objet : OOD, OMT et OOSE. mise au point à General Electric.
• La méthode OOD, Object Oriented Design, de G.Booch • Ses auteurs ont puisé leur inspiration:
a été conçue à la demande du Ministère de la Défense – d’une part dans les langages à objets pour des applications
des USA. d’informatique industrielle (automates, contrôle de processus...),
– L’objectif était de préparer de façon rigoureuse la structuration – d’autre part dans les techniques de modélisation conceptuelle
des programmes écrits en langage ADA ou C++. des méthodes d’analyse des années 80.
• OMT représente un système comme un assemblage
d’éléments auxquels on attache des comportements,
c’est-à-dire des opérations pouvant être déclenchées à
la réception d’un message envoyé par d’autres
composants.
Un peu d’histoire pour mieux comprendre (3/5) Un peu d’histoire pour mieux comprendre (4/5)
• La méthode OOSE, Object Oriented Software • La société Rational Software a réuni les auteurs
Engineering, est d’origine universitaire (informatique principaux de ces trois méthodes pour qu’ils se mettent
temps réel) et industrielle (Ericsson). d’accord sur un langage de modélisation dans l’espoir
• Son originalité consiste à faire reposer l’analyse sur une qu’il devienne une référence.
expression par l’utilisateur de la façon dont il pense • Sa réussite fut d’être retenu comme norme de
utiliser le futur système. modélisation par l’OMG, après avoir reçu le soutien de
plusieurs grands constructeurs informatiques et éditeurs
de logiciels. Ce langage a passé par différents stades
et est encore en évolution.
• OMG: Object Management Group, organisme de normalisation pour le monde objet : www.omg.com
• Editeurs logiciels, Notamment DEC, HP, i-Logix, Intellicorp, IBM, ICON Computing, MCI Systemhouse, Microsoft
Oracle, TI et Unisys. Aucun d’eux n’était jusque-là un acteur public dans le domaine méthodologique.
Date Stade d’UML Acteurs Action

1991 G.Booch
J.Rumbaugh
Élaboration de méthodes orientées objet 2. Eléments et Mécanismes généraux
1994 Rational Software Rapprochement de G.Booch et J.Rumbaugh
1995 Méthode unifiée 0.8 G.Booch

• On construit des modèles de systèmes complexes
J.Rumbaugh
rassemblés par Rational Software
parce que nous ne pouvons pas comprendre un
1996 UML 0.9 G.Booch
système dans sa totalité.
J.Rumbaugh
I.Jacobson • Des techniques de modélisation performantes sont
rassemblés par Rational Software
nécessaires face à l’augmentation de la complexité des
Fin 1996 OMG Appel d’offres pour une méthodologie systèmes.
Début 1997 UML 1.0 G.Booch Soumission à l’OMG
J.Rumbaugh
I.Jacobson Remarque : l’OMG a reçu une offre concurrente
• Il y a de nombreux facteurs à la réussite d’un projet et
rassemblés par Rational Software d’UML
avoir une méthodologie rigoureuse est un facteur
ainsi que d’autres partenaires (Digital, HP,
Microsoft…) essentiel.
Fin 1997 UML 1.1 Les auteurs d’UML 1.0 et ceux de l’offre Rapprochement et standardisation de la nouvelle
concurrente (dont Softeam) version par l’OMG
Mars 1999 UML 1.3 Task Force constituée par l’OMG Amélioration de la version 1.1
En cours UML 2.0 Revision Task Force, constituée par l’OMG Amélioration de la version 1.3

Eléments et Mécanismes généraux Notion d’objet
Un langage de modélisation doit comprendre : • Un objet est une entité identifiable du monde réel qui
• éléments du modèle – des concepts de modélisation contient à la fois des données et des traitements (les
fondamentaux et une sémantique ; données sont appelées attributs et les traitements
• une notation – une interprétation visuelle des éléments opérations ou méthodes).
du modèle ; • Un objet peut avoir :
– une existence physique comme un cheval, un livre, …
• aide en ligne (lignes de guidage) – idiomes de l’usage.
– Ou ne pas en avoir comme un texte du loi, …
Abstraction Abstraction
• L’abstraction est un principe très important en
modélisation. • L'abstraction est une simplification indispensable au
processus de modélisation.
• Elle consiste à retenir uniquement les propriétés
pertinentes d’un objet pour un problème précis. • Un objet UML est donc une abstraction de l'objet du
monde réel par rapport aux besoins du système, dont
• Les objets utilisés en UML sont des abstractions d’objets on ne retient que les éléments essentiels.
du monde réel.
• Exemples:
– on s’intéresse aux chevaux pour l’activité de course. Les
propriétés d’aptitude de vitesse, d’âge et d’équilibre mental ainsi
que l’élevage d’origine sont pertinentes pour cette activité et sont
retenues.
Classe d’objets
• Un ensemble d'objets similaires, c'est-à-dire possédant Les classes se désignent par un nom (1re partie),
la même structure et le même comportement et contiennent des attributs (2ème partie) et des méthodes
constitués des mêmes attributs et méthodes, forme associées (3ème partie) :
une classe d'objets. La structure et le comportement • les attributs sont des propriétés caractéristiques de la
peuvent alors être définis en commun au niveau de la classe. Les attributs peuvent être privés, publics,
classe. protégés. Ils sont le plus souvent privés. Les classes
• Chaque objet d'une classe, encore appelé instance de respectent le principe d’encapsulation des données ;
classe, se distingue par son identité propre et possède • les méthodes sont des procédures spécifiques à une
des valeurs spécifiques pour ses attributs. classe. Elles sont le plus souvent publiques. Elles
peuvent être privées : on parle dans ce cas de méthodes
d’implémentation.

Classe d’objets
• Exemple • On dit qu’un objet est une instance de classe, c’est à

L'ensemble des chevaux constitue la classe Cheval qui dire une valeur particulière de la classe (notion
possède la structure et le comportement suivants: d’instanciation).
• Le cheval Jorphée est une instance de la classe Cheval.
Notion d’objet, notion de classe • Représentation UML d’un objet

– les objets sont identifiés dans le système et portent un nom
– Les classes sont créées en regroupant les objets ayant les
mêmes propriétés, mêmes comportements
NomObjet : Classe
– Un objet est une instance d’une classe
– Représentation UML d’une classe valeur attrib 1
valeur attrib 2
valeur attrib 3
Nom classe Elève
n°elève: entier
attributs Elève
nomElève: car
adresse: car Elev2005001: Elève Elev2005001 : Elève
opérations
inscrire() 2005001 2005001 2005001
mouhamed mouhamed mouhamed
1 rue de 19 juin 1 rue de 19 juin 1 rue de 19 juin
Exemple Encapsulation et abstraction (1/3)
– Lorsqu'il court, un cheval va effectuer différents mouvements • On dit que les informations (qui sont des données) et les
comme lever les jambes, lever la tête, lever la queue. Ces comportements (qui sont les traitements ou encore
mouvements sont internes au fonctionnement de l'animal et
n'ont pas à être connus à l'extérieur. Ce sont des méthodes
méthodes ou opérations) d’un objet sont encapsulés.
privées. Ces opérations accèdent à une partie interne du cheval En effet celles-ci sont à l’intérieur d’une entité (objet).
: ses muscles, son cerveau et sa vue. Cette partie interne est • Intérêt de l’encapsulation : On peut protéger le
représentée sous la forme d'attributs privés. contenu des classes d’une manipulation maladroite et ou
mal intentionnée.
• Un objet est caractérisé par ses données et ses
traitements mais il est aussi caractérisé par une partie
publique, une partie privée et une partie implémentation,
c’est ce que l’on appelle l’abstraction.

Encapsulation et abstraction (2/3) Encapsulation et abstraction (3/3)
• On dit que les données ont un accès privé c’est à dire • Si les traitements sont publics, ceux-ci appartiennent à
que seuls les traitements de cet objet peuvent, le cas l’objet et peuvent être appelés et modifier les données.
échéant, modifier ces données (attention les données • Si les traitements sont privés, alors seuls des
peuvent être aussi publiques mais cela n’a aucun traitements publics appartenant à l’objet pourront
intérêt). déclencher l’exécution des traitements privés (à
• Les traitements extérieurs à l’objet ne peuvent pas condition qu’ils figurent dans le codage).
modifier les données de l’objet. • Les traitements privés sont appelés méthodes
• Les traitements ont un accès privé ou public. d’implémentation .
Héritage (1/2) Héritage (2/2)
• On parle d’héritage lorsque l’on a affaire à des objets et • Intérêts de l’héritage : L’héritage permet la réutilisation
des classes et de généralisation / spécialisation du code.
uniquement pour des classes. • En effet lorsque l’on va instancier une classe
spécialisée, le code des attributs et des méthodes de la
• On distingue deux types d’héritage : classe héritée ne seront pas implémentés à nouveau.
– l’héritage simple , • L’autre avantage de l’héritage et qu’il permet
– l’héritage multiple. l’organisation hiérarchique des classes. C’est à dire qu’il
• On va factoriser les attributs et les méthodes communs à rend plus aisé l’exploration et la maintenance d’une
plusieurs classes dans une classe principale : on parle bibliothèque de classe pour une équipe de
de généralisation. développement.
• Les classes dérivées deviennent des sous-classes : on
parle de spécialisation.
Encapsulation Polymorphisme (1/2)
• L'encapsulation consiste à masquer des attributs et • Le polymorphisme est la possibilité pour un même
des méthodes de l'objet vis-à-vis des autres objets. message de déclencher des traitements différents,
• En effet, certains attributs et méthodes ont pour seul suivant les objets auxquels il est adressé.
objectif des traitements internes à l'objet et ne doivent • Le mécanisme de polymorphisme permet donc de
pas être exposés aux objets extérieurs. donner le même nom à des traitements différents.
• Encapsulés, ils sont appelés les attributs et méthodes
privés de l'objet.
• L'encapsulation est une abstraction puisque l'on simplifie
la représentation de l'objet vis-à-vis des objets
extérieurs.
• Cette représentation simplifiée est constituée des
attributs et méthodes publiques de l'objet.

Polymorphisme (2/2)
• Intérêt du polymorphisme : Le polymorphisme permet UML exprime ses concepts à travers différents
de donner le même nom à des traitements différents ou diagrammes graphiques qui correspondent à des vues
encore, permet le choix dynamique d’un traitement en particulières du système :
fonction de l’objet auquel il est appliqué (en effet le choix • la vue logique. Elle fait référence aux diagrammes de
de la méthode polymorphe à exécuter est déterminé à classes (class diagrams). C’est au niveau de cette vue
l’exécution du programme. que l’on va utiliser la plupart des concepts objets ;
• C’est pour cela qu’on dit qu’elle est dynamique, par
opposé à statique qui est déterminé lors de la
compilation).
3. Les principaux diagrammes UML (1/2)
• la vue des cas d’utilisation (vue fonctionnelle) qui fait • Diagramme des cas d’utilisation
référence aux diagrammes des cas d’utilisation (use – Besoins des utilisateurs
cases diagrams) et des acteurs. On va s’intéresser aux • Diagramme de classes
fonctionnalités du système ; – Description statique des données et des traitements
• la vue des composants (components view). Elle • Diagrammes d’objets
représente l’ensemble des composants logiciels ainsi – Instances des classes
que les tâches ; • Diagramme états-transitions
• la vue de déploiement (deployment view). Elle décrit – États des objets selon les événements
les différentes ressources matérielles et l’implantation du • Diagramme d’activités
logiciel dans ces ressources.
– Vue des enchaînements des activités d’un cas d’utilisation ou
d’une opération
Les principaux diagrammes UML (2/2) Diagramme de classes
• Diagramme de séquence • C’est un diagramme qui montre une collection

– Scénario d’un cas d’utilisation : chronologie des opérations d’éléments statiques (classes), leur contenu et les
• Diagramme de collaboration relations entre eux.
– Scénario d’un cas d’utilisation: activités des objets et des • Dans UML les diagrammes des classes constituent la
messages échangés vue logique (car normalement indépendante du langage
• Diagramme des composants de programmation cible) du système.
– Représentation des composants logiciels d’un système
• Diagramme de déploiement
– Description de l’architecture technique du système

Intérêts des diagrammes de classes
• rassembler les données utilisées par le système dans des entités • les relations interclasses : Elles sont appelées
encapsulées : les classes (collections d’objets d’attributs associations.
communs) ;
• définir les opérations qui permettent de manipuler ces données • On a défini différents types d’associations :
(uniquement que lorsque qu’elles sont nécessaires), celles-ci seront – association simple,
intégrées aux classes ; – agrégation,
• de réaliser une vision des éléments statiques du système, c’est à – héritage (spécialisation, généralisation),
dire de recenser les parties des structures qui ne se modifieront pas – dépendance.
avec le temps (par opposition aux diagrammes dynamiques qui sont
les diagrammes d’états-transitions ou les diagrammes d’activités) ;
• mettre en œuvre les concepts objets (en particulier l’héritage, qui
permet la réutilisation du code).
Association
• les noms d’association : ceux sont les noms des • Les associations binaires sont représentées par des
relations interclasses ; lignes connectant les symboles des classes.
• les multiplicités : associées aux associations, les • Les associations ternaires (et plus) sont représentées
multiplicités permettent de déterminer le nombre par un diamant connecté par des lignes aux symboles
d’occurrence d’une classe par rapport à une autre classe des classes.
en utilisant le nom de rôle ; • La terminaison d'une association où elle se connecte à
• la navigation : c’est le sens de lecture du nom de rôle une classe est appelée "rôle d'association".
d’une association donnée. L’association est symbolisée • La plupart de l'information intéressante à propos d'une
par une ligne qui lie deux classes. La navigation est association, est attachée à ses rôles (entre autres, la
symbolisée par une flèche qui indique le sens de lecture cardinalité).
du nom d’association.
• Association entre classes • Agrégation

– Liens entre les instances – Association entre une classe de type « ensemble » avec
– Rôle de l’association et son sens plusieurs classes de type « éléments »
– Cardinalité des instances associées
Salle
Nom classe X Nom classe Y 1

Nom association
* 1..2 *
1..2 Chaises tableau équipement
X * Y A une instance X correspond 1 à 2 instances de Y
A une instance Y correspond 0 à n instances de X

• Composition Association qualifiée (1/2)
– Agrégation avec une contrainte de durée de vie
• Un composant n’appartient qu’à un seul composé • Une association entre deux classes A et B,
• La desctriction d’un composé entraîne celle de ses
composants dont le nombre d'objets de classe B est
restreint par rapport à un objet de classe A
Hôtel sur la base d'un ou plusieurs attributs, peut
être représentée en UML par la définition
1 d'attributs qualifiants (nommé qualifier en
anglais).
• Par exemple, dans la relation pouvant
1..* exister entre une banque et ses clients,
Chambre
le numéro de compte constitue unattribut
qualifiant qui identifie de manière unique, un
client particulier de la banque où le compte
bancaire a été ouvert.
Association qualifiée (2/2) • Généralisation et spécialisation

– Généralisation: création d’une superclasse à partir de classes
• En effet, un client est identifié dans sa banque par – Spécialisation: création de sous classes à partir d’une classe
l'intermédiaire de son numéro de compte. Au plus, il
n'existe qu'un seul client pour une banque et un numéro Spécialisation
Animal
de compte donnés.
• La déclaration d'un attribut qualifiant est à effectuer au
niveau de l'association qui relie les deux classes et non
pas au niveau de la classe du côté de laquelle sont
affichés les attributs qualifiants (voir le rectangle accolé
à la classe Banque et contenant l'attribut Cheval Chien
qualifiant numCompte).
généralisation
• Extension et restriction de classe

• Héritage multiple
– Extension: ajout de propriétés dans une sous classe
– Une classe hérite de deux classes parentes
– Restriction: masquage de propriétés dans une sous classe
Appareil
élève
n°élève
nom
adresse Chauffage Appareil Electrique
extension restriction
Élève salarié
Élève prospect
n°élève
nom …. PoelA Chauffage FourA
adresse nom Mazout Electrique microOndes
entreprise adresse

• Contraintes de généralisation CONTRAINTES DE GENERALISATION:
– Chevauchement : deux sous classes avec des instances • Une classe peut être spécialisée selon plusieurs critères.
identiques • Certaines contraintes peuvent être posées sur les relation de
– Disjoint : les instances d’une sous classe ne peuvent être dans généralisations.
une autre sous classe • Par défaut, la généralisation symbolise une décomposition
– Complète : la généralisation ne peut être étendue exclusive.
– Incomplète : la généralisation peut être étendue
VEHICULE
Personne
motorisation milieu
Etudiant {chevauchement} Enseignant

A MOTEUR A VOILE MARIN TERRESTRE AERIEN
CONTRAINTES DE GENERALISATION : CONTRAINTES DE GENERALISATION :

CHAMPIGNON
• { INCOMPLET DISJOINT} ( = {EXCLUSION}) • { COMPLET DISJOINT} ( = {PARTITION} )

{exclusion} • Un champignon peut être : • Une personne est :
» Soit un agaricus – Soit Mineure
PERSONNE
» Soit un Boletus – Soit majeure
» Ou Aucun des deux. – Mais pas les deux.
Agaricus Boletus
{partition}
MINEUR MAJEUR
Pied Bleu Bolet de Loup
CONTRAINTES DE GENERALISATION: CONTRAINTES D’ASSOCIATIONS:
• { COMPLET RECOUVREMENT} ( = {TOTALITE} ) • { INCOMPLET RECOUVREMENT} ( = {AUCUNE

• Un Musicien est obligatoirement : CONTRAINTE} )
– Soit un compositeur • Une Société peut être :

MUSICIEN Société
– Soit un interprète – Client
– Soit les deux. – Fournisseur
– Ou autre chose…
{Totalité} {aucune contrainte}
Compositeur Interprète Client Fournisseur

Polymorphisme Diagramme des cas d’utilisation
– Description de l’interaction entre l’utilisateur et le système
Forme • Une opération est polymorphe lorsque : – Recensement des besoins des utilisateurs
– Descriptions textuelles + diagrammes de tous les cas d’utilisation
surface
• Elle est appelée sous forme générique
au niveau de la Super-Classe,
CalculerSurface() • Elle est spécifiée au niveau de chaque système inscription
Sous-Classe
inscrire élève
inscription
Cercle Carré élève

R Cote
Pi Cas d’un élève qui s’inscrit Plusieurs acteurs
CalculerSurface(){
Plusieurs cas
CalculerSurface(){
Sf = pi * R * R; Sf = cote*cote;
} }
scolarité
Diagramme états-transitions – Suite d’états et de transitions avec

– Montre les états simples, les transitions et les états composites
imbriqués • Début:
– L’état d’un objet à un instant t peut changé à l’instant t+1 • Fin:
– Le passage d’un état à un autre est une transition • Ti : transition – Ci : condition – Ai : action
– La condition de passage est appelée « garde »
Etat-Transition
Transition [condition]
État 1 État 2 T1[C1]/A1 T2[C2]/A2
État 1 État 2 État 3
inscription [paiement ok]

Élève prospect Élève inscrit T4[C4]/A4
État 4
Diagramme d’activités • Exemple diagramme d’activités

– Description des activités d’un cas d’utilisation ou d’une opération
– Diagramme de type : état-action
Transition avec condition
– Exécution d’activités différentes selon le résultat de l’activité Dépôt dossier « transition gardée »
précédente [refus]
– Exécution synchronisée : plusieurs activités en // avant de Vérification
passer à l’activité suivante [accepté]

[à compléter]
[retour]
Paiement
Dossier renvoyé
[forfait entreprise]
[individuel]
convention
Carte délivrée
Transition sans condition
« transition automatique »

Diagramme de séquence • Exemple diagramme de séquence
– Interactions entre objets et chronologie des échanges entre ces
objets
– Base: les cas d’utilisation
– Échange de messages pour déclencher une opération
– Mention des objets créés ou détruits lors des exécutions
– Spécification des contraintes de temps : durée
– Messages synchrones :
– Messages asynchrones :
Diagramme de collaboration
– Relations entre les objets et messages échangés
[orientation] 1: établir plan plan de formation
– Diverses informations mentionnées sur le diagramme
3: créer dossier
• synchronisation : les préalables à l’envoi du message;
2 : double du plan
• n° du message : ordre chronologique du message;
• condition du déclenchement de l’envoi;
devis dossier
• type d’envoi: séquentiel ou parallèle; 5 : remise 4 : calculer prix()
élève
• résultat : valeur retournée…
9 : remise carte() Carte élève 8: délivrer carte()

7 : maj paiement ()
6 : payer ()
régisseur
Diagramme de composants
– Description des composants du système Diagramme de déploiement
– Description de l’architecture physique des composants matériels du système
– Décomposition en sous-système, programme, processus, tâche,
module – Un nœud = un composant matériel = un cube
– Lien entre les cubes = communication entre les nœuds
– Classes de composants = noms des classes
– Objets de composants = noms soulignés des instances
– Deux types de noeuds:
• Processeur
• Périphérique au processeur
Système Scolarité • Diagramme de déploiement d’un système d’inscription

Inscriptions Examens Système et sous-systèmes
Poste Intranet Serveur

scolarité Scolarité
TCP/IP
BD
scolarité

4. Packages Packages
• Un package permet de grouper des éléments

• Un package sert d’espace de désignation (espace de
nom)
• Un package peut inclure d’autres package
• Un package peut importer d’autres package
• L’héritage entre package est possible
Les outils de modélisation UML
• Plusieurs logiciels, citons

– Rational Rose, IBM
– Together, Borland
– Rhapsody Modeler, I-Logix
– Win Design Diagramme de cas d’utilisation
– Visio, Microsoft
– Poseidon UML , Gentleware
– PowerAMC/PowerDesigner , Sybase Chapitre 3/ Diagramme UML de cas
– Plugin Omondo , Eclipse d’utilisation: vue fonctionnelle
– ArgoUML Intérêt, définition et notation
– Visual Paradigm
Et tous les autres….
Diagramme de cas d’utilisation Définition
Le diagramme de cas d’utilisation représente la structure

Frontière du sujet Borne interactive d’une banque des grandes fonctionnalités nécessaires aux utilisateurs
du système.
Cas d’utilisation
Acteur
association

Les éléments d’un diagramme de cas
Rôle de diagramme de cas d’utilisation
d’utilisation (1/8)
• Donne une vue du système dans son environnement • Acteur
extérieur,
Un acteur est l’archétype de l’utilisateur
• Définit la relation entre l’utilisateur et les éléments que
le système met en œuvre, (personne, processus externe, ...) qui
• Est la base du modèle UML. interagit avec le système,
Les éléments d’un diagramme de cas Les éléments d’un diagramme de cas
d’utilisation (2/8) d’utilisation (3/8)
• Représentation d’un Acteur • L’acteur principal :
– Directement concerné par le cas d’utilisation décrit,
– Sollicite le système pour obtenir un résultat perceptible,
• Un acteur secondaire :
– Est sollicité pour des informations complémentaires,
– Nécessaire au déroulement du cas d’utilisation décrit
• Lorsqu’un cas d’utilisation introduit au moins un acteur • Un cas d’utilisation qui n’est pas
secondaire, les associations reliant les acteurs aux cas
d’utilisation sont stéréotypées : directement relié à un acteur est un cas
– <<principal>> ou d’utilisation interne.
– <<secondaire>> selon le cas.

• Représentation d’un cas d’utilisation • Une note
– Une note permet l’ajout d’une information textuelle à un
diagramme.
– Cette information peut être un commentaire, un corps de
méthode ou une contrainte.
Les éléments d’un diagramme de cas Les relations dans un diagramme de cas
• Représentation d’une note • La relation d’association
– Les notes sont représentées par un rectangle – Une relation d’association est un lien de
avec le coin supérieur droit replié sur communication entre un acteur et un cas
lui-même. d’utilisation.
– On peut relier une note à un élément en
utilisant une ligne pointillée.
Les relations dans un diagramme de cas Les relations dans un diagramme de cas
• Représentation d’une relation d’association • La relation d’inclusion
– Un trait continu – La relation d’inclusion spécifie qu’un cas
d’utilisation est nécessairement une partie
d’un autre cas d’utilisation.

• Représentation d’une relation d’inclusion • Rôle de la relation d’inclusion
– Une flèche discontinue stéréotypée – Décomposer un cas complexe en sous-cas
<<inclusion>> plus simples,
– Factoriser une partie d’un cas d’utilisation
commune à d’autres cas d’utilisation.
• La relation d’extension • Représentation de la relation d’extension
– La relation d’extension spécifie qu’un cas – Une flèche discontinue stéréotypée
d’utilisation est éventuellement une partie <<extension>>
d’un autre cas d’utilisation
• Remarque • La relation de généralisation/spécialisation
– Le point d’extension explicite le contexte – La relation de généralisation/spécialisation est
d’occurrence de l’extension la transposition aux cas d’utilisation de la
– Une condition liée à un point d’extension est notion d’héritage dans le paradigme
spécifiée dans une note objet

• Représentation d’une relation de • La multiplicité
généralisation/spécialisation – La multiplicité permet de spécifier le nombre
– Une flèche dont la pointe (un triangle fermé) d’interactions entre un acteur et un cas
est dirigée vers l’élément le plus général d’utilisation.
• Les différentes multiplicités
Symbole Signification
–* plusieurs
–n exactement n
– n..m entre n et m
Documentation d’un cas d’utilisation (1/4) Documentation d’un cas d’utilisation (2/4)
• Description succincte : ce que le UC apporte en terme de fonctionnalités
• Scénarios décrivant le déroulement des opérations,
• Intervenants dans l'élaboration du UC : analystes, utilisateurs, spécialistes pour le cas normal. C'est une description en langage
du domaine, client clair des interactions entre les éléments intervenants
• Date de création et dates de mises à jour, avec l'énoncé des modifications pour mener le UC à bien. On y identifie le ou les
• Quels sont les utilisateurs (acteurs) susceptibles d'enclencher le UC
• Quels sont les effets qui en résultent (mise à jour d'une base, envoi d'un
acteurs, ainsi que les autres UC éventuellement
document, écriture dans un fichier, …) enclenchés.
• Fréquence d'utilisation : apériodique, 1 x/jour, .. • Scénarios décrivant les cas "alternatifs" , avec la
• Quelles sont les préconditions pour pouvoir enclencher ce UC (réalisation
d’un autre UC, base de données inexistante, etc…) condition de déclenchement
• Technique de déploiement : enclenché via le web, via un terminal, en • Scénarios décrivant les cas d'exception (panne
intranet, en C/S
réseau, serveur arrêté, …) avec la condition de
déclenchement.
Documentation d’un cas d’utilisation (3/4) Documentation d’un cas d’utilisation (4/4)
• Définition des tests qui serviront à valider la réalisation du UC, • Cette liste est donnée à titre indicatif et toutes les
appelés parfois "Test cases" : complets et détaillés ! ! !
• Informations nécessaires avant d'enclencher le UC (qui seront
rubriques ne doivent pas être complétées, surtout en
demandées) première analyse.
• Contraintes préalables (techniques, personnelles, temps • Cette liste peut varier suivant le contexte stratégique.
d'exécution maximum, etc.)
• Estimation des risques : niveau de connaissance du domaine du • D’autres rubriques peuvent être rajoutées.
problème traité par le UC, niveau de compétence de l'équipe de
designers, niveau de compétence de l'équipe de programmeurs
• Importance de ce UC pour les utilisateurs/clients. Ce point et le
point qui précède serviront à classer les UC, pour un ordre
"chronologique"
• Le dictionnaire des abstractions et des actions associées aux
scénarios (des noms et des verbes…)

Exemple : Inscription à une formation Exemple : Inscription à une formation
• Description : le UC permet à l'administratif d'inscrire un candidat à • Fréquence d'utilisation : apériodique

la prochaine session d'une formation On doit pouvoir trouver ses • Technique de déploiement : accessible via un PC dans le bureau des administratifs
informations s'il est déjà client, sinon on les demande. Si la • Préconditions : la liste des formations doit exister sinon ce UC n‘a pas de sens.
prochaine session est complète, on peut l'inscrire dans une liste • Scénario normal :
d'attente. – On présente la liste des formations. Après choix on affiche la date de la prochaine session.
– Si pas de session, message. Si le candidat est d'accord, on demande son nom et on
• Intervenants : cherche s'il est déjà client.
– Analyste : Mr. x – Si oui, on récupère ses coordonnées, sinon on les encode.
– Client : XX Formation • Scénario alternatif : .
– Si la prochaine session est complète. On peut l'inscrire dans une liste d'attente.
• Date de création : 3 Avril 2016 – Celle-ci sera utilisée pour créer la liste des inscrit de la prochaine session créée.
• Mises à jour : 13 Avril 2016, description simple • Scénario d'exception :
– …
• Acteurs : enclenché par un Administratif
• Effets :
– complète la liste des inscrits pour la session choisie.
– Ajout dans la liste des clients si nouveau client
Exemple : Inscription à une formation

Scénario normal
• Tests : on testera avec un nouveau client, un client existant, une formation sans
session, une session non complète et une session complète. • Le scénario normal (ou principal) est également
• Informations nécessaires : les coordonnées du client (nom, prénom, date de
naissance, n° SS, adresse, téléphone, [Email], [coordonnées employeur] appelé « happy path », ou « scénario de base »,
• Contraintes : un minimum d'interactions et d'encodage de la part de l'utilisateur.
• Risques : « cheminement type ».
– connaissance du domaine : bonne
– compétence designer : moyenne • Il décrit le scénario type qui satisfait les intérêts
– compétence programmeurs : bonne
• Importance du UC : grande des parties intéressées.
• Dictionnaire abstractions: ListeFormations, Formation, Sessions, ListeClients,
Inscription, ListeAttente, FicheInscriptionSession • Souvent, il ne comprend pas de conditions ni de
• Dictionnaire opérations : consulterFormations, consulterSession, inscrireClient,
rechercheClient, inscrireListeAttente branchements. On reporte ces traitements
conditionnels dans les scénarios alternatifs.
Exemple : Scénario normal d’un paiement

Scénario normal électronique
1. L’acheteur introduit sa carte dans le terminal.
• Le scénario est composé d’étapes, lesquelles 2. Le commerçant encode le montant.
sont de trois sortes : 3. L’acheteur contrôle le montant sur l'écran.
4. Le terminal affiche le message « Code »
– Une interaction entre acteurs; 5. L’acheteur introduit son code secret.
6. Le terminal contacte le réseau Banksys pour la vérification de la validité de la carte
– Une validation (généralement par le système); bancaire et la vérification du code secret (c’est Banksys qui effectue la vérification).
– Un changement d’état du système (enregistrement ou 7. Banksys contacte la banque de l’acheteur et vérifie que le montant est disponible.
8. Banksys envoie le 'OK' au terminal.
modifications, par exemple). 9. Banksys donne l'ordre à la société de clearing (Clearing House) de transférer l'argent
du compte de l’acheteur à celui du commerçant.
• En général, la première étape d’un cas 10. L'écran affiche un message signalant que le paiement est en ordre.
d’utilisation n’obéit pas à cette classification 11. L’acheteur reprend sa carte.
12. Le terminal imprime la souche relative à la transaction.
mais indique l’événement qui déclenche le 13. Le commerçant remet à l’acheteur la preuve de paiement.
scénario (« le client arrive à la caisse et … »)

Exemple : Scénario alternatif d’un paiement
Scénario alternatif électronique
• Les scénarios alternatifs sont très importants et 1.L’acheteur introduit sa carte dans le terminal.
forment généralement la plus grande partie du 1.La carte est illisible ; le terminal affiche le message « carte illisible » et la
transaction est annulée.
texte. 2.La carte est lisible ; passage au point 2.
• Ils indiquent tous les autres scénarios ou 2.Le commerçant encode le montant.
1.Le commerçant s’est trompé dans l’encodage du montant ; il annule le
branchement possibles, tant en cas de succès montant ; retour au point 2.
qu’en cas d’échec. 2.Le montant a été correctement encodé ; passage au point 3.
3.L’acheteur contrôle le montant sur l'écran.
• L’ensemble formé par le scénario normal et les 1.Le montant affiché est incorrect :
scénarios alternatifs doit satisfaire « presque » 1.L’acheteur ignore l’erreur (erreur en sa faveur) ; passage au point 4.
2.L’acheteur signale l’erreur au commerçant ; retour au point 2.1
tous les intérêts des parties prenantes. 2.Le montant affiché est correct ; passage au point 4.
• Le scénarios alternatifs sont des branches qui 4.Le terminal affiche le message « Code ».
partent du scénario de base : ils doivent donc
être numérotés en fonction de la numérotation
de celui-ci.
Exemple : Scénario alternatif d’un Exemple : Scénario alternatif d’un

paiement électronique (suite) paiement électronique (fin)
5. L’acheteur introduit son code secret. 7. Banksys contacte la banque de l’acheteur et vérifie que la
6. Le terminal contacte le réseau Banksys pour la vérification de la validité de la carte transaction est autorisée (rappelons que les règles peuvent varier
bancaire et la vérification du code secret (c’est Banksys qui effectue la vérification). d’une banque et d’un client à l’autre).
1. Vérification de la validité de la carte bancaire.
1. Le numéro de carte est incorrect; le terminal et l’écran du commerçant affichent le message « carte 1. La transaction est refusée; le terminal et l’écran du commerçant
incorrecte » et la transaction est annulée. affichent le message « Transaction refusée » ; la transaction est
2. La carte a été verrouillée ; le terminal et l’écran du commerçant affichent le message « carte verrouillée » annulée.
et la transaction est annulée (le service « Perte et vol de cartes » de Banksys est averti).
3. La carte a été volée ; le terminal affiche le message et l’écran du commerçant affichent « carte 2. La transaction est acceptée; passage au point 8.
verrouillée » et la transaction est annulée (le service « Perte et vol de cartes » de Banksys est averti).
4. La carte bancaire est valide ; passage au point 6.2 8. Banksys envoie le 'OK' au terminal.
2. Vérification du code secret de l’acheteur. 9. Banksys donne l'ordre à la société de clearing (Clearing House) de
1. Le code est incorrect :
1. C’est le premier code incorrect de la transaction ; le terminal affiche le message « code incorrect, 2ème essai » ; retour transférer l'argent du compte de l’acheteur à celui du commerçant.
au point 4.
2. C’est le deuxième code incorrect de la transaction ; le terminal affiche le message « code incorrect, dernier essai » ;
retour au point 4.
10. L'écran affiche un message signalant que le paiement est en ordre.
3. C’est le troisième code incorrect de la transaction ; la carte est bloquée; le terminal et l’écran du commerçant affichent le
message « code incorrect : carte bloquée » ; la transaction est annulée.
11. L’acheteur reprend sa carte.
2. Le code est correct ; passage au point 7. 12. Le terminal imprime la souche relative à la transaction.
Comment découvrir les cas d’utilisation Comment découvrir les cas d’utilisation
• On définit des cas d’utilisation pour permettre aux acteurs principaux • Étape 1 : choisir les limites du système
d’atteindre leurs buts. La procédure de base est donc la suivante :
– Délimiter le système. S’agit-il d’une application logicielle, de l’ensemble – Définir ce qui est extérieur au système
matériel et application, de cet ensemble plus la personne qui l’utilise ou • Acteurs principaux et auxiliaires,
de toute une organisation ?
– Identifier les acteurs principaux, à savoir ceux qui atteignent leurs buts • Système (système de paiement électronique)
en utilisant les services du système.
– Identifier les buts de chaque acteur principal.
– Définir des cas d’utilisation qui correspondent aux objectifs des
utilisateurs et les nommer conformément à ces buts.
• En développement itératif, tous les buts et les cas d’utilisation ne
sont naturellement pas entièrement et correctement identifiés
d’emblée : il s’agit un processus de recherche évolutif.

• Étape 2 et 3 : Identifier les acteurs principaux et • Questions qui permettent d’identifier acteurs et buts :
– Qui démarre et arrête le système ?
auxiliaires et leurs buts. – Qui est responsable de la gestion des utilisateurs et de la sécurité ?
– Parfois ce sont les buts qui révèlent les acteurs, parfois c’est – Existe-t-il un processus de surveillance qui restaure le système s’il
l’inverse. tombe en panne ?
– Comment les mises à jour logicielles sont-elle gérées ?
– Principe de base : se concentrer sur la recherche des acteurs – Qui assure l’administration du système ?
principaux, ce qui fournira le cadre des investigations ultérieures. – Le « temps » est-il un acteur (événement temporel) ?
– Qui évalue l’activité ou les performances du système ?
– Qui évalue les journaux ? Sont-ils récupérés à distance ?
– Outre les acteurs principaux humains, y a-t-il des systèmes externes,
logiciels ou matériels qui font appel aux services du système ?
– Qui reçoit les notifications en cas d’erreur ou de panne ?
– …
• Dans un atelier d’expression des besoins, vous pouvez • Étape 4 : définir les cas d’utilisation.
poser ces deux questions : – On définit généralement un cas d’utilisation pour
– Que faites-vous ? (orientée cas d’utilisation) chaque but utilisateur, et on le nomme d’après ce but.
• Exemple : si le but est de traiter une vente, le cas
– Quels sont vos buts dont les résultats ont une valeur mesurable d’utilisations se nomme « traiter une vente »
? • Nommez les cas d’utilisation par un verbe à l’infinitif.
– Préférez la seconde question. – Exception à la règle « un cas d’utilisation par but »
consiste à regrouper les opérations de gestion
(création, récupération, modification, …) en un seul
cas d’utilisation nommé par convention « Gérer… »
Diagrammes des cas d’utilisation Affinement des cas d’utilisation
L e s A c t e u r s e t le s U s e - C a s e s e n p r e m iè r e a n a ly s e
T . B . 1 5 ju in 2 0 0 1
• Détailler et organiser les cas d’utilisation :
– En ajoutant des relations d’inclusion et/ou d’extension.
– En regroupant en « packages » pour définir des blocs
G é r e r le s f o r m a t io n s fonctionnel de plus haut niveau.
A d m in is t r a t if
In s c r ip tio n à u n e s e s s io n
r e q u ie r t le s in f o r m a t io n s
F a c tu r a tio n
A s s ig n e r le s f o r m a t e u r s a u x
C lie n t s f o r m a t io n s
C o n s u lte r l e p la n n in g d e s
F o r m a te u r s
f o r m a t io n s

Diagrammes des cas d’utilisation
Structuration des cas d’utilisation
en packages
< < e xte nd > > R e c h e r c h e r u n e F o r m a t io n
< < in c lu d e > >
• Plusieurs stratégies possibles :

< < e x te n d > >
G é r e r le s f o rm a tio n s
M o d if ie r u n e F o rm a tio n
– Regroupement par acteur;
A d m in is t r a tif < < e x te n d > > – Regroupement par domaine fonctionnel…
< < in c lu d e > >
r e q u ie r t le s in fo rm a tio n s
< < e xte nd > > A jo u te r u n e F o r m a tio n
In s c r ip tio n à u n e s e s s io n
C lie n t s
S u p p r im e r u n e F o rm a t io n
A s s ig n e r le s fo rm a t e u r s a u x
s e s s io n s
F a c t u r a t io n
C o n s u lt e r le p la n n in g d e s
F o rm a te u r f o rm a tio n s
En résumé
• Le diagramme d’utilisation permet : Chapitre 4/ Diagramme UML de classes et

– d’exprimer simplement les besoins des utilisateurs
d’objets: vue statique
– d’analyser les besoins des utilisateurs
– de déterminer les interfaces du système
1. Diagramme de classes
• Ne pas confondre utilisateur et acteur 2. Diagramme d’objets
Introduction Classe et instance de classe
- Une instance est une réalisation concrète d’un concept abstrait.
Par exemple :
-La construction du diagramme de classes constitue l’objectif - le téléphone de Jules est une instance du concept abstrait Téléphone
de toute démarche de modélisation « objet » - l’amitié qui lie Jean et Marie est une instance du concept abstrait Amitié
- Une classe est un concept abstrait représentant des éléments variés comme :
- Le diagramme de cas d’utilisation montre un système du point
de vue des acteurs, • des éléments concrets (ex : des avions),
• des éléments abstraits ( ex : des commandes de marchandises ou services),
- Le diagramme de classes en montre la structure interne du • des composants d’une application (ex : les boutons des boîtes de dialogue),
système. • des structures informatiques (ex : des tables de hachage),
• des éléments comportementaux (ex : des tâches), etc.
- Il fournit une représentation abstraite des objets du système
qui vont interagir pour réaliser les cas d’utilisation. Tout système orienté objet est organisé autour des classes.
- Le diagramme de classes modélise les concepts du Une classe est la description formelle d’un ensemble d’objets ayant en commun:
domaine d’application ainsi que les concepts internes créés • une sémantique (sens)
• des caractéristiques (propriétés et comportements).
dans le cadre de l’implémentation d’une application.
2ème Année LMD Génie Logiciel 1 197 2ème Année LMD Génie Logiciel 1 198

Objet: instance de classe Caractéristiques d’une classe: État d’un objet
-Un objet est une instance d’une classe. C’est une entité discrète •Attributs et Terminaisons d’associations décrivent l’état d’un
dotée : objet.
• Les attributs reçoivent des données dépourvues de
d’une identité
d’un état
sémantique
d’un comportement • Les associations sont utilisées pour connecter les classes
• La terminaison de l’association (du côté de la classe cible)
Les objets sont des éléments individuels d’un système en cours est une propriété de la classe
d’exécution. • Les attributs prennent des valeurs lorsque la classe est
instanciée.
• L’instance d’une association est appelée un lien.
Caractéristiques d’une classe: Comportement

Représentation graphique
d’un objet
• Les opérations décrivent les éléments individuels d’un comportement que l’on
peut invoquer. Ce sont des fonctions qui peuvent:
Une classe est un « classificateur ». Elle est représentée par un rectangle divisé
en trois à cinq compartiments:
• prendre des valeurs en entrée
• modifier les attributs
• Le premier indique le nom de la classe
• produire des résultats
• Le deuxième ses attributs
• Le troisième ses opérations
• Une opération est la spécification (i.e. déclaration) d’une méthode. Par abus
de langage (impérialisme Java!) les opérations sont parfois appelées méthodes.
Avec éventuellement:
Il y a donc une ambiguïté sur le terme méthode.
• Un compartiment des responsabilités pour énumérer l’ensemble de tâches devant
• Les attributs, les terminaisons d’associations et les opérations constituent donc
être assurées par la classe mais pour lesquelles on ne dispose pas encore assez
les caractéristiques d’une classe (et de ses instances).
d’informations.
• Un compartiment des exceptions pour énumérer les situations exceptionnelles
devant être gérées par la classe.
Représentation graphique Encapsulation visibilité interface
L’encapsulation: mécanisme consistant à rassembler les données et les

opérations au sein d’une structure en cachant l’implémentation de l’objet,
Interdit l’accès aux données par un autre moyen que les services proposés.
Les services accessibles (offerts) aux utilisateurs de l’objet définissent l’interface
de l’objet (sa vue externe).
• permet donc de garantir l’intégrité des données contenues dans l’objet.

• permet de définir des niveaux de visibilité des éléments d’un conteneur.
La visibilité déclare la possibilité pour un élément de modélisation de

référencer un élément qui se trouve dans un espace de noms différents de celui
de l’élément qui établit la référence.
Représentation UML d’une classe Elle fait partie de la relation entre un élément et le conteneur qui l’héberge,
ce dernier pouvant être un paquetage, une classe ou un autre espace de noms.
Il existe quatre visibilités prédéfinies:

Visibilité Visibilité
• Public ou + :
tout élément qui peut voir le conteneur peut également
voir l’élément indiqué.
• Protected ou # :
seul un élément situé dans le conteneur ou un de ses
descendants peut voir l’élément indiqué.
• Private ou - :
seul un élément situé dans le conteneur peut voir
l’élément.
• Package ou ∼ ou rien :
seul un élément déclaré dans le même paquetage peut
voir l’élément.
Relations de visibilité Nom d’une classe
• Le nom de la classe doit évoquer le concept décrit par la classe.

• Il commence par une majuscule.
• On peut ajouter des informations comme:
• le nom de l’auteur de la modélisation,

• la date,
• etc.
Pour indiquer qu’une classe est abstraite, il faut ajouter le stéréotype

<<abstract>>.
La syntaxe de base de la déclaration d’un nom d’une classe est la suivante :
[ <Nom_du_paquetage_1>:: ... ::<Nom_du_paquetage_N> ]

<Nom_de_la_classe>
[ { [abstract], [<auteur>], [<date>], ... } ]
Les attributs Les attributs
• Chaqueinstance d’une classe possède sa propre copie des attributs de la classe.

Les valeurs des attributs peuvent donc différer d’un objet à un autre.
• Il est parfois nécessaire de définir un attribut de classe (static en

Java ou en C++) qui garde une valeur unique et partagée par toutes les
instances de la classe.
• Les instances ont accès à cet attribut mais n’en possèdent pas une copie.
• Un attribut de classe n’est donc pas une propriété d’une instance mais une propriété
de la classe
• Graphiquement, un attribut de classe est souligné.

Attributs dérivés Les opérations
• Les attributs dérivés peuvent être calculés à partir d’autres attributs et de formules
de calcul. • Dans une classe, une opération (même nom et même types de
•Lors de la conception, un attribut dérivé peut être utilisé comme marqueur pour
déterminer les règles à lui appliquer. paramètres) doit être unique.
• Les attributs dérivés sont symbolisés par l’ajout d’un « / » devant leur nom. • Quand le nom d’une opération apparaît plusieurs fois avec des
paramètres différents, on dit que l’opération est surchargée.
• La déclaration d’une opération contient les types des paramètres et le
type de la valeur de retour, sa syntaxe est la suivante :
<visibilité> <nom_opération> ([<paramètre_1>, ... , <paramètre_N>]) :

[<type_renvoyé>] [{<propriétés>}]
Paramètre d’opération Opération de classe
La syntaxe de définition d’un paramètre (<paramètre>) est la suivante :
[<direction>] <nom_paramètre>:<type> ['['<multiplicité>']'] [=<valeur_par_défaut>] •Comme pour les attributs de classe, il est possible de
La direction peut prendre l’une des valeurs suivante : déclarer des opérations de classe.
in
: Paramètre d’entrée passé par valeur. Les modifications du paramètre ne sont
pas disponibles pour l’appelant. C’est le comportement par défaut. • Une opération de classe ne peut manipuler que des
out
: Paramètre de sortie uniquement. Il n’y a pas de valeur d’entrée et la valeur attributs de classe et ses propres paramètres.
finale est disponible pour l’appelant.
inout
: Paramètre d’entrée/sortie. La valeur finale est disponible pour l’appelant. • Cette méthode n’a pas accès aux autres attributs
Le type du paramètre (<type>) peut être • Graphiquement, une opération de classe est soulignée.
• un nom de classe,
• un nom d’interface,
• un type de donné prédéfini.
Classe active Notion d’association
• Une association est une relation entre deux classes (association binaire) ou plus
• Uneclasse est passive par défaut, elle sauvegarde les données et offre (association n-aire), qui décrit les connexions structurelles entre leurs instances.
des services aux autres. • Une association indique donc qu’il peut y avoir des liens entre des instances des
classes associées.
• Une classe active initie et contrôle le flux d’activités.
• Graphiquement, une classe active est représentée comme une classe

standard dont les lignes verticales du cadre, sur les côtés droit et gauche,
sont doublées.

Notion d’association Terminaison d’association
(remarque)
Deux modélisations de la notion d’association Propriétaire d’une terminaison d’association
La question de savoir s’il faut modéliser les associations en tant que tel a longtemps La possession d’une terminaison d’association par le classeur situé à l’autre
fait débat. UML a tranché pour la première version car elle se situe plus à un niveau extrémité de l’association peut être spécifié graphiquement par l’adjonction
conceptuel (par opposition au niveau d’implémentation) d’un petit cercle plein (point) entre la terminaison d’association et la classe
Il n’est pas indispensable de préciser la possession des terminaisons
d’associations.
Terminaison d’association = propriété Association binaire et n-aire
Dans le cas d’une classe, les propriétés sont constituées par les attributs et les éventuelles
terminaisons d’association que possède la classe. • Une association binaire est matérialisée par un trait plein entre les classes
Associées.
Dans le cas d’une association, les propriétés sont constituées par les terminaisons d’association • Elle peut être ornée d’un nom, avec éventuellement un sens de lecture (▸ ou ◂).
que possède l’association. • Quand les deux extrémités de l’association pointent vers la même classe,
l’association est dite réflexive.
Une propriété peut être paramétrée par les éléments suivants :
nom :
Comme un attribut, une terminaison d’association peut être nommée. Le nom est situé à
proximité de la terminaison.
Le nom d’une terminaison d’association est appelée nom du rôle.
visibilité :
Comme un attribut, une terminaison d’association possède une visibilité.
multiplicité :
Comme un attribut, une terminaison d’association peut posséder une multiplicité.
Elle est mentionnée à proximité de la terminaison.
navigabilité :
Pour un attribut, la navigabilité est implicite, navigable, et toujours depuis la
classe vers l’attribut.
Pour une terminaison d’association, la navigabilité peut être précisée
Association binaire et n-aire Multiplicité ou cardinalité
• Une association n-aire lie plus de deux classes. • La multiplicité associée à une terminaison d’association déclare le nombre d’objets
• La ligne pointillé d’une classe-association peut être reliée au losange par une susceptibles d’occuper la position définie par la terminaison d’association.
ligne discontinue pour représenter une association n-aire dotée d’attributs, • Dans une association binaire la multiplicité sur la terminaison cible contraint
d’opérations ou d’associations. le nombre d’objets de la classe cible pouvant être associés à un seul objet donné
• On représente une association n-aire par un grand losange avec un chemin de la classe source (la classe de l’autre terminaison de l’association).
partant vers chaque classe participante • Dans une association n-aire, la multiplicité apparaissant sur le lien de chaque
• Le nom de l’association, le cas échéant, apparaît à proximité du losange. classe s’applique sur une instance de chacune des classes.
(ambiguité des associations ternaires!)
Quelques exemples de multiplicités:
1 un et un seul
0..1 zéro ou un
m .. n de m à n
* de zéro à plusieurs
0..* de zéro à plusieurs
1..* de un à plusieurs
4..6 de quatre à six
1..3,12 de un à trois ou douze

Navigabilité Navigabilité
• La navigabilité indique s’il est possible de traverser une association. Deux modélisations équivalentes.
• On représente graphiquement la navigabilité par une flèche du côté de la
terminaison navigable et on empêche la navigabilité par une croix du côté de
la terminaison non navigable.
• Par défaut, une association est navigable dans les deux sens.
Une classe UML est-elle toujours en Première Forme Normale?
Qualification Classe-association
• Quand une classe est liée à une autre classe par une association, on peut • Parfois, une association doit posséder des propriétés.
restreindre la portée de l’association à quelques éléments ciblés de la classe. • Les associations ne pouvant posséder de propriété, il faut introduire un nouveau
• Ces éléments ciblés (un ou plusieurs attributs) sont appelés un qualificatif. concept pour modéliser cette situation : la classe-association.
• Un qualificatif permet donc de sélectionner un spécifique dans l’ensemble des • Une classe-association possède les caractéristiques des associations et
objets candidats e l’association. des classes.
• L’objet sélectionné par la valeur du qualificatif est appelé objet cible. • Elle se connecte à deux ou plusieurs classes et possède également des attributs
• L’association est appelée association qualifiée. et des opérations.
• Un qualificatif agit toujours sur une association dont la multiplicité est plusieurs • Une classe-association est caractérisée par un trait discontinu entre la classe
du côté cible. et l’association qu’elle représente
Classe-association Agrégation et composition
Une association simple entre deux classes représente une relation structurelle
Exemple d’auto-association sur classe-association. entre deux classes de même niveau conceptuel : aucune des deux n’est plus
importante que l’autre.
Agrégation
Une agrégation est une association qui représente une relation d’inclusion
structurelle ou comportementale d’un élément dans un ensemble.
Lorsque l’on souhaite modéliser une relation tout/partie où une classe constitue
un élément plus grand (tout) composé d’éléments plus petit (partie), il faut utiliser
une agrégation.
Graphiquement, on ajoute un losange vide (♦) du côté de l’agrégat. Contrairement
à une association simple, l’agrégation est transitive.

Agrégation Composition
Objet, Fichier, Texte sont agrégés à la classe Email

Composition
La composition, également appelée agrégation composite, décrit une contenance

structurelle entre instances.
La destruction de l’objet composite implique la destruction de ses composants.
Une instance de la partie appartient toujours à au plus une instance de l’élément
Composite.
La multiplicité du côté composite ne doit pas être supérieure à 1 (i.e. 1 ou 0..1).
Graphiquement, on ajoute un losange plein du côté de l’agrégat.
Composition Généralisation et Héritage
Un Email est (obligatoirement) composé de Destinataires

La généralisation décrit une relation entre :
• une classe générale (classe de base ou classe parent)

• une (ou des) classe spécialisée (sous-classe).
La classe spécialisée est intégralement cohérente avec la classe de base,

mais comporte des informations supplémentaires (attributs, opérations, associations).
Dans le langage UML, cette relation de généralisation se traduit par le concept

d’héritage. On parle également de relation d’héritage.
L’héritage permet la classification des objets (taxinomie).
Le symbole utilisé pour la relation d’héritage ou de généralisation est une flèche

avec un trait plein dont la pointe est un triangle fermé désignant le cas le plus
général
Généralisation et Héritage Généralisation / Spécialisation
Spécialisation
Démarche descendante, qui consiste à capturer les particularités

d'un ensemble d'objets, non discriminés par les classes déjà identifiées.
La Spécialisation consiste à étendre les propriétés d'une classe,
sous forme de sous-classes, plus spécifiques.
Généralisation
Démarche ascendante, qui consiste à capturer les particularités

communes d'un ensemble d'objets, issus de classes différentes.
La Généralisation consiste à factoriser les propriétés d'un ensemble
de classes, sous forme d'une super-classe, plus abstraite.

Principe de substitution de Propriétés principales de
Liksow l’héritage
• La classe enfant possède toutes les caractéristiques des ses classes parents,
• L'héritage permet la classification des objets. mais elle ne peut accéder aux caractéristiques privées de cette dernière.
• Une classe enfant peut redéfinir (même signature) une ou plusieurs opérations
• Une bonne classification est stable dans le temps et extensible de la classe parent.
• Parfois, les critères de classification sont subjectifs. • Sauf indication contraire, un objet utilise les opérations les plus spécialisées
dans la hiérarchie des classes.
• Le principe de substitution de Liksow, (1987) permet de déterminer • Toutes les associations de la classe parent s’appliquent aux classes dérivées.
• Une instance d’une classe peut être utilisée partout où une instance de sa classe
si une relation d'héritage est bien employée pour la classification : parent est attendue.
• Une classe peut avoir plusieurs parents, on parle alors d’héritage multiple
• Le langage C++ est un des langages objet permettant son implémentation
effective, le langage Java ne le permet pas.
Si Y hérite de X, cela signifie que "Y est une sorte de X "
Héritage multiple Dépendance
Une classe peut avoir plusieurs parents, on parle alors d’héritage multiple • C’est une relation unidirectionnelle exprimant une dépendance sémantique entre
des éléments du modèle.
• Elle est représentée par un trait discontinu orienté.
• Elle indique que la modification de la cible peut impliquer une modification
de la source.
• La dépendance est souvent stéréotypée pour mieux expliciter le lien sémantique
entre les éléments du modèle
• On utilise souvent une dépendance quand une classe en utilise une autre comme
argument dans la signature d’une opération.
Interfaces 2. Diagramme d’objet
Une interface est représentée comme une classe excepté l’absence du mot-clef
abstract et l’ajout du stéréotype << interface >> • Un diagramme d’objets représente des objets (i.e. instances de classes) et leurs
Elle est réalisée par au moins une classe (peut l’être par plusieurs). liens (i.e. instances de relations) pour donner une vue de l’état d’un système à un
Graphiquement, elle est représentée par un trait discontinu terminé par une flèche instant donné.
triangulaire et le stéréotype « realize » ou le stéréotype <<use>>. • Un diagramme d’objets peut être utilisé pour :
• illustrer le modèle de classes par un exemple qui explique le modèle ;

• préciser certains aspects du système en mettant en évidence des détails
imperceptibles dans le diagramme de classes ;
• exprimer une exception en modélisant des cas particuliers ou des
connaissances non modélisables dans un diagramme de classe (OCL);
• prendre une image d’un système à un moment donné.
Le diagramme de classes modélise les règles et le diagramme d’objets modélise

des faits.

Représentation Représentation
• Graphiquement, un objet se représente comme une classe.

• Le compartiment des opérations n’est pas utile. • Dans un diagrammes d’objets, les relations du diagramme de classes deviennent
• Le nom de la classe dont l’objet est une instance est précédé d’un << : >> des liens.
et est souligné. • La relation de généralisation ne possède pas d’instance, elle n’est donc jamais
• Pour différencier les objets d’une même classe, leur nom peut être ajouté représentée dans un diagramme d’objets.
devant le nom de la classe. • Graphiquement, un lien se représente comme une relation, mais, s’il y a un nom,
•Les attributs reçoivent des valeurs. il est souligné.
• On ne représente pas les multiplicités.
Dépendance d’instanciation Dépendance d’instanciation
La relation de dépendance d’instanciation (stéréotypée << instanceof >>) décrit

la relation entre un classeur et ses instances. Elle relie, en particulier, les liens
aux associations et les objets aux classes.
Extrait du Méta Modèle UML
1 Diagrammes d’interaction
Chapitre 5/ Diagramme UML: vue dynamique • Les diagrammes d’interaction sont utilisés
1. Diagramme d’interaction (séquence pour modéliser les aspects dynamiques
et collaboration) d’un système
2. Diagramme d’activités
– Ils aident à visualiser comment le système
3. Diagramme d’états/transitions
exécute ses tâches.
– Un diagramme d’interaction est souvent
construit à partir d’un diagramme de classes
et d’un cas-type (d’utilisation)
• L’objectif est de montrer comment un
ensemble d’objets peut réaliser une tâche
demandée par un acteur
2ème Année LMD Génie Logiciel 1/ Cahpitre 5 246

Les éléments se trouvant dans un diagramme
Interactions et messages
d’interaction
– Un diagramme d’interaction montre comment un – Des instances de classes
ensemble d’objets et d’acteurs communiquent • Représentés par des rectangles comme dans les
ensemble afin:
diagrammes d’instances (d’objets)
• de réaliser un cas-type
• de réaliser une certaine fonctionnalité
– L’ensemble des différentes étapes à accomplir – Acteurs
s’appelle une interaction. • Représentés par des personnages-allumettes
– Un diagramme d’interaction montre différents types comme dans les diagramme de cas-type
de communication entre objets, acteurs et sous-
systèmes: – Messages
• E.g. appel à des méthodes, information envoyés
sur un réseau • Représentés par des flèches horizontales
• Ceux-ci sont appelés messages.
2ème Année LMD Génie Logiciel 1/ Cahpitre 5 247 2ème Année LMD Génie Logiciel 1/ Cahpitre 5 248
Création d’un diagramme d’interaction Un exemple de diagramme de séquence
• Un diagramme de classes et des cas-type

doivent d’abord être élaborés
– Il existe deux sortes de diagramme d’interaction
• Diagramme de séquence
• Diagramme de collaboration
Diagramme de séquence – avec des messages

Diagramme de séquence
répétés
• Un diagramme de séquence montre la séquence temporelle – Une itération à travers plusieurs objets s’indique à l’aide d’un
d’échange de message entre l’acteur et les objets réalisant une astérisque précédent le nom du message
certaines tâche
– Les objets sont disposés horizontalement
– L’acteur qui initie l’interaction se trouve généralement à
l’extrême gauche
– La dimension verticale représente le temps
– Une ligne verticale, appelée ligne de vie, est accrochée à
chaque objet ou acteur
– La ligne de vie s’épaissie pour devenir une boite d’activation
lorsque l’objet est actif, i.e., durant la période d’activation.
– Un message est représenté par une flèche joignant deux boites
d’activation.
• Un message a un nom et peut aussi avoir une liste
d’arguments et une valeur de retour.

Diagramme de collaboration – un exemple Diagramme de collaboration
• Un diagramme de collaboration illustre

comment les objets coopèrent dans la
réalisation d’une interaction
– Un diagramme de collaboration est un graphe dont
les objets sont les sommets.
– Des liens de communication sont ajoutés entre ces
objets
– Les messages sont associés à ces liens.
• Représentés par des flèches
– L’ordonnancement temporel est indiqué à l’aide d’une
numérotation
Encore le même exemple, avec plus de détails Liens de communication
– Un lien de communication existe entre 2 objets

lorsqu’à un moment il est possible d’envoyer un
message d’un objet à un autre.
– Plusieurs situations peuvent rendre cet échange

possible:
1. Les classes sont en association

– Il s’agit là de la situation la plus commune
– Si tous les messages sont envoyés dans la
même direction, l’association peut alors être
rendue unidirectionnelles
D’autres liens de communication possibles D’autres liens de communication possibles
2. Le récepteur est contenu dans une variable locale 4. Le récepteur est un objet global
de la méthode émettrice – Ceci se produit lorsque la référence à l’objet
– Ceci se produit fréquemment lorsque l’objet a peut être obtenue à l’aide d’une méthode
été créé par la méthode émettrice ou lorsqu’un statique
résultat précédent a retourné un objet . – Le stéréotype a utiliser est «global», ou [G]
– Le stéréotype à utiliser est «local» ou [L].
5. Les objets communiquent à travers un réseau
3. Une référence à l’objet récepteur a été reçu – Nous suggérons d’utiliser «network».
comme paramètre par la méthode émettrice
– Le stéréotype à utiliser est «parameter» or [P].

Comment choisir entre un diagramme de Comment choisir entre un diagramme de
séquence et un diagramme de collaboration séquence et un diagramme de collaboration
• Les diagrammes de séquence • Diagramme de collaboration
– Rendent explicite la séquence temporelle dans – Peuvent être vus comme la prolongation d’un
l’interaction diagramme de classes
• Les cas-type ont aussi un tel ordre temporel • Préférable lorsque l’interaction est déduite du
• Les diagrammes de séquence constituent donc le diagramme de classes
choix naturel lorsque l’interaction est construite à • Sont aussi très utiles pour valider des diagrammes
partir d’un cas-type. de classes
– Facilite une écriture détaillée des messages

• Moins d’espace est généralement disponible dans
un diagramme de collaboration
2 Diagrammes d’état Les états
• Un diagramme d’état décrit le comportement d’un système, d’une – A tout instant, le système se trouve dans un état
partie d’un système ou d’un objet.
– A tout instant, un système ou un objet se trouve dans un certain – Il demeura dans cet état jusqu’à l’occurrence d’un événement
état. provoquant un changement d’état
• Être dans un état donné signifie que le système se
comportera d’une façon spécifique en réponse aux – Un état se représente à l’aide d’un rectangle arrondi contenant le
événements se produisant. nom de cet état
– Certains événements vont provoquer des changements d’états
– États spéciaux:
• Dans ce nouvel état, le système se comportera de façon
différente. • Un disque noir représente l’état initial
• Un disque noir entouré d’un cercle représente un état final
– Un diagramme d’état est un graphe dans lequel les états sont
des nœuds et dont les arcs représentent les transitions.
Transitions Exercice
– Une transition représente un changement d’état en réponse à un • Le but de l’exercice est de décrire les différents états de
événement la situation professionnelle d’une personne et les
• Cette transition est considérée instantanée transitions correspondantes. La personne peut, par
exemple, être étudiante, salariée, sans activité,
– L’étiquette associée à une transition est l’événement causant ce indépendante ou retraitée.
changement d’état
• Au début de sa situation professionnelle, une personne
est étudiante. Ne prenez pas en compte les activités
simultanées comme la possibilité d’être simultanément
salarié et indépendant.
• Construisez le diagramme d’états-transitions
correspondant (utilisez les conditions de garde pour
différencier les possibilités multiples).

Exercice Diagramme d’état – un exemple avec
conditions et délais
Diagramme d’état – un exemple avec transition

Les activités dans les diagramme d’état
conditionnelle
– Une activité peut être lancée lorsque le système se trouve dans
un état
• Une activité a une durée
• En réponse à la terminaison de l’activité, le système peut

effectuer un changement d’état
• Les transitions peuvent aussi se produire lorsque l’activité est

en cours:
– L’activité se termine alors et le changement d’état
s’effectue
Diagramme d’état – un exemple avec activité Les actions dans un diagramme d’état
– Une action se réalise de façon instantanée

• Lorsqu’une une transition se produit
• Lorsque le système entre dans un certain état
• Lorsque le système sort d’un certain état

Diagramme d’état – un exemple avec actions Diagramme d’état – un autre exemple
Diagramme d’état – un exemple avec sous-

Sous-états et diagrammes imbriqués
états
• Un diagramme d’état peut être imbriqué dans un autre.
– Les états dans un diagramme interne sont des sous-états
3 Diagrammes d’activité Exercice
– Un diagramme d’activité est similaire à un diagramme • L’authentification d’un utilisateur à un système

d’état. informatique consiste en deux étapes :
• Les transitions sont causées par la terminaison d’une – La saisie du nom
activité.
– La saisie du mot de passe
– Un diagramme d’activité • Représentez en UML les activités nécessaires que doit
• peut servir à mieux comprendre la succession des réaliser le système d’information pour authentifier un
étapes qu’un système doit accomplir afin de réaliser utilisateur en faisant l’hypothèse que l’utilisateur saisisse
une certaine tâche
correctement son nom et son mot de passe. On suppose
• peut aussi servir à mieux comprendre les cas-type et la
façon dont ils sont interreliés que ces deux étapes sont réalisées chronologiquement.
• est le plus souvent associé à plusieurs classes • Ajoutez une alternative pour tester si le nom et le mot de
– L’une des forces des diagrammes d’activité est de passe sont corrects.
représenter des activités concurrentes.

Exercice Exercice
• Ajoutez une alternative

pour tester si le nom et le
mot de passe sont
corrects.
Représentation de la concurrence Représentation de la concurrence
– La concurrence dans un diagramme d’activité se représente à • Un point de rencontre (join) a de multiples transitions
l’aide de points de rencontre, de fourchettes et de rendez-vous. entrantes et une transition sortante
– La transition sortante s’effectue lorsque toutes les
• Une fourchette (fork) a une transition entrante et plusieurs transitions entrantes se sont produites
transitions sortantes – Chacune des transitions entrantes s’effectue dans un fil
– L’exécution se sépare alors en différents fils d’exécution d’exécution distinct.
– Lorsque qu’une transition entrante se produit, le fil
• Un rendez-vous a plusieurs transitions entrantes et sortantes correspondant est bloqué jusqu’à ce que les autres
transitions soient complétées.
– Lorsque toutes les transitions entrante ont été effectué
alors seulement peuvent être lancée les transitions
sortantes
Allées Diagramme d’activité – un exemple avec allées
• Un diagramme d’activité est souvent associé à plusieurs

classes
– Le partitionnement des activités à travers les différentes classes
peut être explicitement montré à l’aide d’allées (swimlanes)

Cours3 Génie Logiciel 1

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Cours3 Génie Logiciel 1

Transféré par

Droits d'auteur :

Formats disponibles

‫ور ا زا ر ا د راط ا‬ ‫ا‬

Contenu de la matière Références

• Chapitre 1/ Introduction • Modélisation objet avec UML. Pierre-Alain Muller, -

• L'informatique est au cœur de toutes les grandes entreprises.

2ème Année licence 1

• Un logiciel ou une application est un ensemble de

Génie logiciel 1 Génie logiciel 1 8

La crise du logiciel (2/3) La crise du logiciel (3/3)

En 1979, le gouvernement américain estimait que la

Génie logiciel 1 9 Génie logiciel 1 10

Naissance du génie logiciel Génie et génie logiciel

• Le génie logiciel existe depuis une quarantaine

2ème Année licence 2

Le génie logiciel est l’ensemble des moyens

Génie logiciel 1 13 Génie logiciel 1 14

La maîtrise d’ouvrage Le maître d’ouvrage

Génie logiciel 1 15 Génie logiciel 1 16

2ème Année licence 3

• Elle est responsable de la réalisation de

Génie logiciel 1 19 Génie logiciel 1 20

Le chef de projet L’analyste

Génie logiciel 1 21 Génie logiciel 1 22

L’architecte Le développeur fonctionnel

Génie logiciel 1 23 Génie logiciel 1 24

2ème Année licence 4

Génie logiciel 1 25 Génie logiciel 1 26

Le comité de pilotage Le comité de suivi

Génie logiciel 1 27 Génie logiciel 1 28

Plan qualité Qu’est-ce qu’une norme ?

Le plan qualité est un document qui présente :

Génie logiciel 1 29 Génie logiciel 1 30

2ème Année licence 5

Ensemble d'attributs portant sur l'existence d'un

Facilité d'utilisation (usability) Rendement (efficiency)

Génie logiciel 1 35 Génie logiciel 1 36

2ème Année licence 6

Génie logiciel 1 37 Génie logiciel 1 38

Qu’est-ce qu’un modèle?

• Un modèle est une représentation abstraite et simplifiée

Pourquoi modéliser? (1/2) Pourquoi modéliser? (1/2)

Génie logiciel 1 Génie logiciel 1

2ème Année licence 7

Génie logiciel 1 Génie logiciel 1

• Conception détaillée • Intégration

Génie logiciel 1 Génie logiciel 1

• Mise en production • La séquence et la présence de chacune de ces activités

Génie logiciel 1 Génie logiciel 1

2ème Année licence 8

Le modèle en cascade (2/2)

Génie logiciel 1 51 Génie logiciel 1 52

Le modèle en « V » (1/7) Le modèle en « V » (2/7)

• « V » signifie que le développement du logiciel et le Spécifications

• Cette approche permet de vérifier la conformité à ce qui

Codage des modules

Génie logiciel 1 53 Génie logiciel 1 54

2ème Année licence 9

Spécification du système, par

Génie logiciel 1 55 Génie logiciel 1 56

Le modèle en « V » (5/7) Le modèle en « V » (6/7)

Génie logiciel 1 57 Génie logiciel 1 58

• Le cycle de développement ne commence que quand

Codage des modules

Génie logiciel 1 59 Génie logiciel 1 60

2ème Année licence 10