Introduction - Lab

23/02/2016
lab-sticc.univ-brest.fr/~babau/
Ingénierie du Développement Logiciel
dirigée par les modèles
Jean-Philippe Babau
Département Informatique, UFR Sciences, UBO
Laboratoire Lab-STICC
UBO
Plan du cours
•
Introduction à l’ingénierie pour le développement logiciel
•
Organisation du cours
•
Introduction à la modélisation UML
•
Introduction au MDE (M2 TIIL et M2 SIAM)
[email protected]
2
1
23/02/2016
UBO
Construire un pont
2
1
Pont Sublicius, Rome, 650 avant JC
3
4
le Ponte dei Salti (Lavertezzo, Suisse)
Viaduc de Millau
Mike Lehmann, Mike Switzerland March 2008
[email protected]
UBO
1
3
Des outils pour la construction et pour
l’organisation de la construction
4
2
3
[email protected]
4
2
23/02/2016
UBO
Construire une maison : documents et suivi
•
Un projet : une idée de maison
•
Des normes et règlements
– Déclarations obligatoires
– Documents de conformité
•
Des
–
–
–
•
Des études techniques
– Résistance des matériaux
– Capacité d’isolation
•
Des documents spécifiques
– Contrats, actes, déclarations, plans, …
– Pour le notaire, l’état, le paysagiste, les techniciens, les constructeurs, les vendeurs
•
Gestion du chantier
– Planning, revues à base des contrats et des plans
plans
Contrat de construction de maison individuelle « avec fourniture de plans »
Schéma électrique, eau, chauffage, aération
Plan cadastral
[email protected]
5
UBO
Construire un avion : des modèles spécifiques
•
Aérodynamique
– Modèles physiques de l’écoulement
– Modèles physiques de la structure
•
Motorisation
– Modèles de combustion
– Modèles thermiques
•
Systèmes de pilotage et de navigation
– Normes de sécurité
– Normes de communication
•
Informatique
– Embarquée et débarquée (suivi)
•
–
–
•
: sous-partie du système
Communications embarqué / débarqué
Aide à la conception
SI des entreprises
Intervenants hétérogènes
– Métiers
– Cultures et langues
Quels modèles
: outils?de manipulation des modèles physiques
: outils de suivi des projets et des personnes
[email protected]
6
3
23/02/2016
UBO
Construire un système
•
Des systèmes de plus en plus complexes … à produire de plus en plus vite
•
•
Des outils de conception et modélisation de plus en plus complexes
Des schémas hétérogènes et spécifiques
•
Des acteurs divers et différents aux points de vue divers et différents
•
Faire les bons choix au bon moment
•
•
Maitriser la gestion de projet
Automatisation des étapes et des processus
•
•
Des documents pour contractualiser et communiquer
Des outils pour le suivi
–
–
–
des systèmes personnalisables
pour évaluer, étudier
couts, délais, interaction avec les divers partenaires
[email protected]
UBO
Construire un logiciel
•
Des systèmes de plus en plus complexe … à produire de plus en plus vite
•
•
Des outils de conception et modélisation de plus en plus complexes
Des schémas hétérogènes et spécifiques
•
Des acteurs divers et différents aux points de vue divers et différents
•
•
Faire les bons choix au bon moment
Intégrer une vision Métier et une vision Informatique
•
•
Maitriser la gestion de projet informatique
– Processus spécifiques
Automatisation des étapes et des processus
•
•
Des documents pour contractualiser et communiquer
Des outils pour le suivi
–
des systèmes personnalisables
–
pour évaluer, étudier
–
7
couts, délais, interaction avec les divers partenaires
[email protected]
8
4
23/02/2016
UBO
Maitrise du développement
•
•
•
En 2004, le Standish Group a évalué à 34% la
part des projets qui aboutissent dans les
conditions prévues, soit 18% de plus qu’il y a 10
ans.
15% sont arrêtés avant la fin, soit 16% de moins
qu’il y a 10 ans.
51% sont en retard ou ont un coût supérieur au
budget, soit 2% de moins qu’il y a 10 ans.
[email protected]
UBO
•
9
Quantification des activités
Répartition des activités
– Analyse et conception 45%
– Réalisation et tests unitaires : 35%
• Codage 15 à 20% du total
– Intégration et validation : 25%
•
Dérives dans les estimations
– Étude préalable : de 10 à 25 %
– Conception : de 10% à 35 %
– Réalisation : de 30% à 40%
– Mise en œuvre : de 5% à 20%
[email protected]
10
5
23/02/2016
UBO
•
Les points clés de la construction de logiciel
Intégrer les besoins des utilisateurs
– Relation client / fournisseur
– Considérer l’ensemble des exigences de nature hétérogène
• prix
• délais
• fonctionnalités
• performance
• sécurité
• formation
• déploiement
• maintenance
– Valider les solutions vis-à-vis des attentes du client
[email protected]
UBO
11
Les points clés de la construction de logiciel
•
Choisir (ou développer) les bons outils
– Pour le développement
– Pour le déploiement
•
Evaluer les solutions
– Etude de l’existant
– Solutions faisables
• Cout, complexité, disponibilité, …
– Choix justifiées sur des critères objectifs
– Proposer des solutions de bonne qualité
• En augmentant la réutilisation
• En s’appuyant sur des règles métier
• En suivant un processus maitrisé et reproductible (normes qualité)
•
Maitriser le déroulement du projet
– Développement
– Déploiement
– Maintenance corrective et évolutive
[email protected]
12
6
23/02/2016
UBO
Les défis
•
Maitriser le processus de développement
– Étude, conception, développement, livraison et suivi
•
Maitriser le lien Informatique et Métier
– Echanger des informations dans les deux sens
– Intégrer les concepts et les approches spécifiques métier au logiciel
– Expliquer l’impact du traitement automatique de l’information au métier
• Changement d’outil => impact fort sur le système et son utilisation
• Exemple : intégration d’un simulateur de conduite
– Impact sur l’apprentissage
– Impact sur les constructeurs (tests en situation limite)
•
Maitriser la communication technique
– On ne communique pas avec un code …
[email protected]
UBO
Le développement d’un logiciel concerne
•
Le client du produit développé
•
Les utilisateurs
•
Les administratifs
– Coté client
– Coté fournisseur
•
Les administrateurs
– Coté client
– Coté fournisseur
•
Les instituts de normalisation
informaticiens
13
•
•
Le chef de projet
Les développeurs
– Les architectes
– Les codeurs
– Les testeurs
– Les intégrateurs
•
Les fournisseurs d’outils et de
matériel
•
Les vendeurs
•
Les formateurs
[email protected]
14
7
23/02/2016
UBO
Construire un logiciel=>
intégration de divers aspects
[email protected]
UBO
•
15
Diverses préoccupations
Cycle de développement
– Préoccupations du développeur
– Préoccupations de la maintenance
– Préoccupations de la gestion de projet
[email protected]
16
8
23/02/2016
UBO
Quelques aspects liés au développement
•
Les fonctionnalités
– Données et services
•
Le comportement
– Comportement réactif
– Sureté et vivacité
•
La communication
– Protocoles
•
Les
–
–
–
machines d’exécution
Machines et réseaux
OS
Middlewares
•
Les
–
–
–
aspects non fonctionnels
Temps réel
Sécurité
Ressources (consommation, …)
[email protected]
17
UBO
Quelques aspects liés au développement
•
La structure
– Modules
– Paquetage
– Composants
– Déploiement
•
La correction des programmes
– Tests
– Preuves (sémantique formelle)
•
Le développement
– Outils d’édition, de génération, de mise au point
•
La méthodologie
– Cycle de vie
– Guide de style
– Design pattern
– Suivi de versions
[email protected]
18
9
23/02/2016
UBO
Limites de la compréhension humaine =>
séparation des préoccupations
•
Analyser un problème complexe
– Décomposition du problème en sous-problèmes
• Analyse architecturale
• Décomposition fonctionnelle (SA-RT) et décomposition objet (UML)
– Modularité et abstraction
– « Separation of concern »
• Dijskstra, " On the role of scientific thought" 1974
• Reade, " Elements of Functional Programming “, 1989
– « Composition of concern »
• Assembler des briques de base
• Fusionner des aspects
[email protected]
UBO
19
Un point de préoccupation
•
Une activité qui produit
– des informations (modèles)
•
Pas de document produit : pas d’activité
•
Modèles distincts mais reliés
– Traçabilité des concepts
[email protected]
20
10
23/02/2016
UBO
Des informations pour des activités
•
Décrire les exigences
– Fonctionnalités attendues
– Modèle du domaine
– Intégration et déploiement du SI
•
Accompagner Le développement
– Analyser la structure (architecture)
– Décrire le comportement
– Choix des outils
– Méthodes de développement
•
Assurer le suivi
– Formation des utilisateurs et des installateurs
– Gestion d’erreurs (maintenance corrective)
– Évolutions (maintenance évolutive)
– Suivi de versions
[email protected]
21
UBO
Limites de la compréhension humaine =>
abstraction
•
Lao Tseu
– "Trop de précision tue"
•
Nombre maximal de « token » dans un schéma
– De 3 à 7 au maximum, mais plutôt 3 à 4
– Limité par les capacités de compréhension du lecteur
• Toujours inférieur aux capacités du producteur des modèles concernés
• Le producteur connait son modèle, le lecteur le découvre
•
Des modèles simples
– Attention : il faut savoir faire « simple mais pas simpliste »
[email protected]
22
11
23/02/2016
UBO
Modélisation pour appréhender la complexité
“Modeling, in the broadest sense, is the cost-effective use of something in place of
something else for some cognitive purpose. It allows us to use something that is
simpler, safer or cheaper than reality instead of reality for some purpose;”
“a model represents reality for the given purpose; the model is an abstraction of
reality in the sense that it cannot represent all aspects of reality. This allows us to
deal with the world in a simplified manner, avoiding the complexity, danger and
irreversibility of reality”
Jeff Rothenberg « The Nature of Modeling » ,1989
[email protected]
UBO
23
Introduction sur la notion de modèles
« la recherche d’une théorie nouvelle implique un niveau d’abstraction plus élevé .
… La généralisation scientifique nous conduit à une plus grande intégration de
la connaissance. …. Nous établissons un modèle, ou une succession de
modèles reproduisant, sous une forme ou sous une autre, certains aspects de la
situation présente. … Lord Kelvin disait qu’il lui était impossible de comprendre
un phénomène s’il n’avait auparavant construit un simple modèle mécanique le
représentant. … Le premier et principal intérêt du modèle est d’aider à expliquer
en partie une théorie plus avancée dans les termes d’une théorie connue»
E.-H Hutten, Les concepts de la physique, Paris, Dunod 1969, trad. F. Eldin, pp 74 -75, 77-78
[email protected]
24
12
23/02/2016
UBO
Modèles et abstraction
•
Accroitre le niveau d’abstraction pour le concepteur
– Assembleur -> langage de programmation
– Langage de programmation -> modèles
•
Abstraction d’un aspect du développement
– Organisation du code
– Sécurité
– Supports d’exécution
– Suivi de version
– …
•
Un modèle est une représentation d’un aspect (c’est une abstraction)
– Une vue de quelque chose
[email protected]
UBO
25
Des modèles pour …
– Communiquer
– Documenter
• Rapports, contrats
– Expliquer
• Présentations
• Groupes de travail
– Réfléchir
• Schémas, dessins, graphiques
– Evaluer des propriétés
• Point de vue sur le système vis-à-vis d’une problématique donnée
[email protected]
26
13
23/02/2016
UBO
•
Communiquer
Gérer la difficulté de communiquer
– Être précis
• Termes connus et définis
• Concision dans l’expression
• Faire relire
– Être clair
• Pas trop simple (simpliste), pas trop compliqué
• Faire relire
– Être exhaustif
• Faire valider
[email protected]
UBO
•
27
Représentations
Textuel
– Langage naturel : tout le monde
– Langages de programmation : les programmeurs
– XML : les machines
•
Graphique
– Généralement lié à une représentation textuelle : les spécialistes du domaine
• Semi- graphique : certaines parties sont textuelles
•
Mathématique
– Basé sur des théories mathématiques : les mathématiciens
[email protected]
28
14
23/02/2016
UBO
•
Formalisation
Modèle informel
– Il existe des interprétations différentes d’un même modèle
– Langage naturel
•
Modèle formel
–
–
–
–
•
Il n’existe qu’une interprétation unique pour un modèle donné
Grammaire bien formée
Sémantique sous-jacente
Traitement automatique possible (résultat prévisible a priori)
Modèle semi-formel
– Certaines parties sont formellement décrites et d’autres non
[email protected]
UBO
Bilan
•
Nombreuses activités
•
Nombreux intervenants
•
Nombreux documents
•
Qualité de la communication
•
•
Abstraction et séparation des préoccupations
Travail en équipe
•
•
•
•
•
•
29
Spécification, documentation, architecture, gestion de projet
Points de vue différents, spécialités différentes
Pour les informaticiens et les non informaticiens
On ne communique pas avec un code
Organisation et suivi
Manipuler des modèles (documents) et avoir de la méthode
– Production et communication autour des modèles
– Organisation des activités
• QQOQCCP : Qui fait Quoi Quand, Où Comment Combien et Pourquoi
• Intégration des modèles
[email protected]
30
15
23/02/2016
UBO
Plan du cours
•
Introduction à l’ingénierie pour le développement logiciel
•
Organisation du cours
•
Introduction à la modélisation UML
•
Introduction au MDE (M2 TIIL et M2 SIAM)
[email protected]
UBO
31
Objectifs de l’UE
•
Maitriser les concepts de base de l'ingénierie logicielle
•
Savoir décrire des exigences
•
Savoir modéliser à l'aide de diagrammes UML les diverses
productions des étapes du développement
•
Connaitre et utiliser les outils support du développement logiciel
•
Savoir établir un plan de tests
[email protected]
32
16
23/02/2016
UBO
Intervenants
NEDELEC Olivier
[email protected]
BABAU Jean-Philippe
[email protected]
PAULY Yann
[email protected]
LALLALI Mounir
[email protected]
[email protected]
UBO
33
Evaluation
•
cours / TD / TP ( 48h )
– Éléments de base pour le CC et le projet qui suit l’UE
•
CC : un projet fil rouge
•
•
1 examen écrit ( 2/3 de la note )
1 contrôle continu (1/3 de la note )
•
Planning prévisionnel
– Cours répartis sur 8 semaines du 08/01 au 28/02
– Examen écrit prévu le 25/03
[email protected]
34
17
23/02/2016
UBO
Plan du cours
•
Contexte
– Production industrielle de logiciels
•
Phase 1 : introduction aux concepts de base en ingénierie logicielle
(O Nedelec)
– Cycle de vie du logiciel
– Activités d'analyse
– Formalisation d'exigences
– Organisation
– Qualité
[email protected]
UBO
35
Plan du cours
•
Phase 2 : outils de gestion de projet de développement logiciel (Y.
Pauly)
•
Gestion de configuration
•
Intégration continue (qualité de code, automatisation du processus,
suivi de bugs,…)
•
Mise en place et utilisation des outils
[email protected]
36
18
23/02/2016
UBO
Plan du cours
•
Phase 3 : analyse et conception (JP Babau)
•
Modélisation des processus, des données, des traitements
– UML
•
Organisation du code
– Architecture logicielle
– Les Design patterns
[email protected]
UBO
•
Phase 4 : test logiciel (M.Lallali)
•
Notions de base sur le test
•
Test objet
•
Test basés sur les modèles
•
Introduction à la preuve
37
Plan du cours
[email protected]
38
19
23/02/2016
UBO
Plan du cours
•
Phase 5 : le projet (JP Babau, J Rivière, Y Pauly)
– Client, utilisateurs, fournisseur, experts (revue de pairs)
•
Projet par équipe (6 personnes)
•
Une semaine pour répondre au besoin
•
Gestion de projet
– Suivi des tâches
– Deux jalons
– Gestion des documents
– Démos
[email protected]
UBO
39
Plan du cours
•
Introduction à l’ingénierie pour le développement logiciel
•
Organisation du cours
•
Introduction à la modélisation UML
[email protected]
40
20
23/02/2016
UBO
OMG
L’ensemble des acteurs du monde informatique a fondé en 1989 l'OMG (Object
Management Group), une organisation à but non lucratif, dont le but est de mettre au
point des standards garantissant la compatibilité entre des applications programmées à
l'aide de langages objet et fonctionnant sur des réseaux hétérogènes (de différents types)
•
http://www.omg.org/
•
des standards de l’OMG
–
–
–
Modélisation
• SysML : modélisation système
• UML: modélisation logicielle
• SPEM : modélisation de processus
• OCL : modélisation de contraintes
MOF
• méta-modélisation
Interopérabilité et communications
• CORBA, CCM : modèles d’interopérabilité
• DDS : modèles d’échange de données pour systèmes embarqués temps- réel
• Échanges de données
• XML et XMI : format d’échange de données (texte)
• CWM
[email protected]
UBO
41
Membres de l’OMG
•
Contributeurs
– Microsoft, HP, IBM, Oracle, Thalès, Eclipse Fundation, …
•
Utilisateurs
– EADS, Boeing, Adobe, France Telecom R&D, …
•
Editeurs
– NEC, Nokia, Tri-Pacific Software, Hitachi, …
•
Universitaires
– INRIA, ENSIETA, …
[email protected]
42
21
23/02/2016
UBO
UML : la genèse
•
Modélisation de logiciel
•
Paradigme fonctionnel
– SADT, SA, SA-RT
– Pas d’encapsulation des données
– Structuration hiérarchique des actions, mais pas des concepts
– Modélisation orientée par le problème et non par le domaine
• Moins de réutilisation
•
Paradigme objet
– Encapsulation des données
– Modularité via les objets et structuration des concepts via les classes
– Modélisation orientée par le domaine
[email protected]
UBO
43
Modèles objet
•
en 1994 il existait plus de 50 méthodes objet, dont 3 principales
– des méthodes graphiques
– la méthode OMT de Rumbaugh
– la méthode BOOCH'93 de Booch
– la méthode OOSE de Jacobson (Object Oriented Software Engineering)
•
1994, Rumbaugh et Booch (rejoints en 1995 par Jacobson) mettent au point la méthode unifiée
(unified method 0.8), incorporant les avantages de chacunes des méthodes précédentes
•
La méthode unifiée à partir de la version 1.0 devient UML (Unified Modeling Language), une
notation universelle pour la modélisation objet
•
http://www.smartdraw.com/resources/tutorials/
[email protected]
44
22
23/02/2016
UBO
UML et l’OMG
•
UML 1.0 est soumise à l'OMG (Object Management Group) en
janvier 1997, et est acceptée en novembre 1997 dans sa version 1.1,
date à partir de laquelle UML devient un standard international
•
Des versions depuis
–
–
–
–
–
–
–
–
–
1995: Méthode unifiée 0.8 (Booch'93 et OMT)
1995: UML 0.9 (+ la méthode OOSE)
1996: UML 1.0 (proposée à l'OMG)
1997: UML 1.1 (standardisée par l'OMG)
1998: UML 1.2
1999: UML 1.3
2000: UML 1.4
2003: UML 1.5
Nov. 2007: UML2.1.2
[email protected]
UBO
45
Des points de vue différents …
•
Des diagrammes différents
– 14 types de diagrammes UML
•
3 types de diagramme
– Structure : modélisation des aspects statiques
– Comportement : modélisation des aspects dynamiques
– Modélisation des aspects non fonctionnels
• les profils UML (QoS, MARTE)
[email protected]
46
23
23/02/2016
UBO
•
Diagrammes statiques
–
–
–
–
–
–
•
Diagrammes UML
diagramme de classes (Class diagram)
diagramme d’objets (Object diagram)
diagramme de composants (Component diagram)
diagramme de déploiement (Deployment diagram)
diagramme de paquetages (Package diagram)
diagramme de structures composites (Composite structure diagram)
Diagrammes dynamiques
–
–
–
–
diagramme de cas d’utilisation (Use case diagram)
diagramme d’activités (Activity diagram)
diagramme d’états-transitions (State machine diagram)
diagrammes d’interaction (Interaction diagram)
• diagramme de séquence (Sequence diagram)
• diagramme de communication (Communication diagram)
• diagramme global d’interaction (Interaction overview diagram)
• diagramme de temps (Timing diagram)
[email protected]
UBO
•
47
Utilisation des diagrammes UML
Documentation
– Juste des schémas graphiques
– Pour expliquer : rapport, présentation
– Pour réfléchir : modèle d’un point de vue
•
Vérification
– Validité d’un schéma
– Formalisation via une sémantique formelle
[email protected]
48
24
23/02/2016
UBO
•
Utilisation des diagrammes UML
Expression et analyse des besoins
– Modélisation métier
• Diagrammes d’activité, diagrammes de classe
– Besoins fonctionnels
• Cas d’utilisation, diagramme de séquence
•
Conception
– Architecture globale
• Aspects statiques : diagrammes de classe, de package, de composants
• Aspect dynamique : diagramme de séquence
•
Conception détaillée
– Raffinement de l’architecture en modules
• Aspects statiques : diagrammes de classe, de package, de composants
• Aspect dynamique : diagrammes de comportement, de séquence
[email protected]
UBO
•
49
Utilisation des diagrammes UML
Réalisation
– Lien avec un langage de programmation (Java)
• Diagramme de classe
– Environnement complet de modélisation/programmation
• Édition des diagrammes avec vérification, génération de code
• Reverse code/modèle
•
Déploiement
– Modèle d’exécution
• diagramme de déploiement
•
Documentation
– Tout diagramme utile
•
Intégration via une méthode
– Quel diagramme à quel moment et quels sont les liens entre les diagrammes
– UML n’est pas une méthode
[email protected]
50
25
23/02/2016
UBO
•
Utilisation des diagrammes UML
Un seul modèle mais plusieurs points de vue
– Un point de vue = un diagramme
[email protected]
UBO
•
51
Documentation sur les diagrammes
Norme délivrée par l’OMG
– OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2
– Description de chaque concept (une classe)
• Description description textuelle
• Attributes attributs spécifiques (modélisation objet)
• Additional Operations opérations spécifiques
• Associations liens avec d’autres concepts
• Contraints contraintes exprimée en OCL sur la description du concept
• Semantic précision sur le comportement lié au concept
• Semantic Variation point point de variation libre, sémantique non établie
• Notation règles de représentation graphique ou textuelle
• Presentation options points de variation dans la représentation
• Style Guidelines style de la présentation
• Examples
[email protected]
52
26
23/02/2016
UBO
•
Interprétation des diagrammes
Exemple : DataType
• Description A data type is a type whose instances are identified only by their value. A
DataType may contain attributes to support the modeling of structured data types.
• Attributes No additional attributes
• Associations ownedAttribute: Property[*] The Attributes owned by the DataType. This
is an ordered collection. Subsets Classifier::attribute and Element::ownedMember
• Contraints No additional constraints
• Semantic All copies of an instance of a data type and any instances of that data type
with the same value are considered to be the same instance. Instances of a data type
that have attributes (i.e., is a structured data type) are considered to be the same if
the structure is the same and the values of the corresponding attributes are the same.
If a data type has attributes, then instances of that data type will contain attribute
values matching the attributes.
• Semantic variation point Any restrictions on the capabilities of data types, such as
constraining the types of their attributes, is a semantic variation point.
• Notation A data type is denotated using the rectangle symbol with keyword
«dataType» or, when it is referenced by (e.g., an attribute) denoted by a string
containing the name of the data type.
• Examples
[email protected]
UBO
•
53
Interprétation des diagrammes
Exemples issus de la norme
– Constraints
• An association specializing another association has the same number of ends as the
other association.
self.parents()->forAll(p | p.memberEnd.size() = self.memberEnd.size())
• An element may not directly or indirectly own itself.
not self.allOwnedElements()->includes(self)
– Semantic variation point
• The order and way in which part instances in a composite are created is not defined
– Presentation Options pour les associations
• When two lines cross, the crossing may optionally be shown with a small semicircular jog
to indicate that the lines do not intersect (as in electrical circuit diagrams)
– Style Guidelines
• Lines may be drawn using various styles, including orthogonal segments, oblique
segments, and curved segments. The choice of a particular set of line styles is a user
choice.
[email protected]
54
27
23/02/2016
UBO
•
Sémantique opérationnelle de la communication
–
•
Interprétation des diagrammes
UML2 superstructure : “the manner of transmitting the request object, the amount of
time required to transmit it, the order in which the transmissions reach their receiver
objects, and the path for reaching the receiver objects are undefined”
Sémantique de consommation des messages par un objet
– Envoi/réception de messages entre objets
– Quid de la politique de stockage et de consommation des messages
• Non défini par UML
[email protected]
UBO
•
55
Solutions pour une interprétation unique
Via les outils
– Les outils proposent une implémentation et donc … une interprétation
• usuellement une politique FIFO pour la gestion des messages
•
Via des extensions d’UML
– Profil spécifique
• Profil SDL : messages usuels traités en FIFO et messages urgents
– Formalisation d’UML
• pUML (precise UML)
– Préciser la sémantique via un modèle formel
• Automate communicants pour le comportement
[email protected]
56
28
23/02/2016
UBO
Extensions d’UML par profils
•
Mécanisme standard d’extension d’UML
•
Ensemble cohérent de stéréotypes, de valeur marquées
(taggedvalue) et de contraintes
•
Principe général : on n’ajoute pas de méta classes (pas de nouveaux
concepts ou diagrammes) mais des annotations aux méta-classes
(diagrammes) UML existantes.
[email protected]
UBO
57
UML
•
Avant UML : beaucoup de langages de modélisation objets, mais aussi des
langages de modélisation fonctionnel, composant, système, …
•
Objectif d’UML : offrir un langage de modélisation universel …
– « esperanto » de la modélisation
– Définition et représenation des concepts (mots) de base du modeleur logiciel
•
•
•
Des évolutions au cours du temps
Des différences d’interprétation (variation points)
Des spécialisations par extensions (profils)
•
Au final beaucoup de sous-langages … mais une base commune
[email protected]
58
29
23/02/2016
UBO
•
•
•
•
UML
UML est standardisé par l’OMG
• Interopérabilité
• Formation
UML est le langage de modélisation orienté objet le plus connu et le plus utilisé au monde
UML s’applique à plusieurs domaines
UML n’est pas une méthode, c’est un langage de modélisation
– Méthode UP
•
Peu d’utilisateurs connaissent le standard, ils ont une vision outillée d’UML
– 5% forte compréhension, 45% faible compréhension, 50% aucune compréhension
•
•
UML est fortement critiqué car pas assez formel
UML est trop complexe
– 14 diagrammes et les extensions (profil)
–
UML est outillé
• Édition et vérification, génération de code
• IBM a racheté Rational
• Eclipse Modeling Tools (papyrus)
[email protected]
59
UBO
Des modèles …
« One and three chairs », Joseph Kossuth, 1965
[email protected]
30
23/02/2016
UBO
Bibliographie
•
OMG et UML
– http://www.omg.org/
– http://www.uml.org/
•
Cours de Jean-Marc Jézéquel
– http://www.irisa.fr/prive/jezequel/enseignement/
Cours de Laurent Audibert
– http://laurent-audibert.developpez.com/Cours-UML/html/
Cours d’Olivier Caron
– http://www2.lifl.fr/~carono/
Cours de Cédric Dumoulin
– http://www2.lifl.fr/~dumoulin/enseign/
•
•
•
•
Jean-Marie Nicolle
– « Histoire des méthodes scientifiques », Paris, Bréal 2006
[email protected]
61
31