Cycle d’Ingénieurs en GI – 2ème Année Module: Conception Orientée Objet Enseignant Responsable: Slim KANOUN Maître Assistant au DGIMA - ENIS.

Présentation au sujet: "Cycle d’Ingénieurs en GI – 2ème Année Module: Conception Orientée Objet Enseignant Responsable: Slim KANOUN Maître Assistant au DGIMA - ENIS."— Transcription de la présentation:

1 Cycle d’Ingénieurs en GI – 2ème Année Module: Conception Orientée Objet Enseignant Responsable: Slim KANOUN Maître Assistant au DGIMA - ENIS

2 Chapitre I : Introduction au Génie Logiciel

3 I.1 Notion de Processus de développement de logiciels / Notion de Cycle de vie de logiciels
I.2 Notion de Méthode d’Analyse et de Conception I.3 Notion d’Approche de Développement de Logiciels I.4 Architectures Logicielles et SGBD I.5 Outils Case (Computer Aided Software Engineering) I.6 Culture générale, Connaissances, Compétences et expériences en informatique pour l’ingénieur

4 I.1 Notion de Processus de développement de logiciels / Notion de Cycle de vie de logiciels

5 Expression des besoins
Spécification Analyse Conception Implémentation Test de Vérification Validation Maintenance et Evolution  Documentation et Archivage

6 Expression des besoins
Une organisation cherche à mettre en place une solution informatique pour l’une de ses Expertises métiers (Applications) : Gestion Comptable, Gestion Financière, Gestion Commerciale, Gestion de Ressources Humaines, Gestion d’un Hôpital, Gestion d’un Hôtel, Gestion de Production, Gestion d’Agences (de Voyages, Locations de Voitures, Immobilières, etc), Gestion d’une Compagnie d’Assurance, Gestion d’Institutions Universitaires, Gestion d’Auto-Ecole, Gestion de Pharmacie, Gestion de Chantiers, etc. Comment Faire ?

7 Expression des besoins
Faire appel soit à une Société de Service en Ingénierie Informatique (SSII) ou au Service Informatique (SI) de l’organisation concernée. Une équipe d’Informaticiens ayant des diplômes suivants sera sollicitée : Ingénieurs (Chefs de projet – Bac + 5 ou Bac + 6) Maîtrises (Analystes / Programmeurs – Bac + 4) Licences et Techniciens (Programmeurs – Bac + 3)

8 Expression des besoins Les membres de l’équipe d’Informaticiens
Des dialogues, des discussions, des entrevues, des réunions, des interviews … seront ainsi effectués entre: Les membres de l’équipe d’Informaticiens + Les Experts Métiers

9 Expression des besoins
Identifier : Les problèmes (retards de livraison de marchandises, erreurs de calcul au niveau des factures, augmentation considérable du volume de données à gérer, passage du mono-utilisateur au multi-utilisateurs, etc) Les besoins (éliminer les retards, éliminer les erreurs de calcul, migrer vers un environnement multi-Utilisateurs, etc) Les objectifs (améliorer la qualité du service et l’image de marque, diminuer le nombre d’employés et par conséquent les salaires à payer, etc)

10 Expression des besoins
Analyser : Les moyens humains en terme de connaissances, compétences et expériences, années de formation des cadres informaticiens, etc, si l’organisation concernée dispose d’un Service Informatique Les moyens matériels (bilan des machines PC en terme de mémoires RAM et de processeurs, bilan des machines serveurs, bilan des réseaux, etc) les moyens financiers en terme d’argents associés à la mise en place de la solution informatique

11 Expression des besoins
Il faudra aussi que l’équipe d’informaticiens soit au courant de tous les progiciels proposés par les SSII qui représentent des solutions informatiques pour l’expertise métier en question  Proposer des Recommandations (Solutions informatiques + Conseils) : - Développer sur mesure (Logiciel) au sein de l’entreprise ou par une SSII ? - Acheter de la part des SSII (progiciel) ? Avec Adaptation ou Sans Adaptation ?

12 Expression des besoins
Exemples de recommandations: Recommandation 1: Développer sur mesure au sein du SI de l’organisation concernée: Prix nécessaire ? Durée prévue ? Technologies à utiliser ? Cadres informaticiens qui va développer ? Besoins de formation des cadres informaticiens ? Recommandation 2: Développer sur mesure chez une des SSII: il faudra présenter pour chaque SSII le Prix demandé ? La Durée prévue ? Technologies à Utiliser ? Recommandation 3: Acheter un progiciel de la SSII 1: Prix ? Fonctionnalités ? Technologies ?

13 Expression des besoins
Exemples de recommandations: Recommandation 4: Acheter un progiciel de la SSII 2: Prix ? Fonctionnalités ? Technologies ? Recommandation 5: Acheter un progiciel de la SSII 3: Prix ? Fonctionnalités ? Technologies ? … Recommandation n: Acheter un progiciel de la SSII n: Prix ? Fonctionnalités ? Technologies ?

14 Expression des besoins
L’équipe d’informaticiens ne pourra jamais prendre une décision finale pour adopter l’une des recommandations proposées qu’après l’étape de Spécification (Elaboration du cahier des charges de développement de logiciels / Rapport de Spécification)

15 Spécification Identifier la liste exhaustive des utilisateurs / experts métiers (ceux qui vont utiliser la solution informatique pour effectuer leurs travaux) Identifier les Fonctionnalités (Acheter un produit, Approvisionner un produit, Affecter une chambre, Elaborer une facture, Régler une facture, etc) de l’expertise métier à informatiser et les décrire sous forme de texte (Phrases et Paragraphes) Cahier de charges (Rapport de spécification) Choix finale d’une recommandation sur la base du cahier de charges: Acheter (Avec Adaptation ou sans Adaptation) ou Développer sur mesure

16 Analyse Elaborer les (Modèles / Diagrammes d’Analyse) : Modélisation de l’expertise métier: Modèles / Diagrammes d’Analyse (100 % Expertise Métier: Sans prendre en compte considération les choix technologiques) Au cours de cette étape, on n’a pas encore choisi ni Architecture (ni Langage de Programmation), ni SGBD, …

17 Conception Choisir les Architectures Logicielles (JEE, .NET, 1 ou 2 ou 3 ou 4-Tiers, CORBA, etc) et / ou le SGBD Elaborer les Modèles / Diagrammes de Conception: Modèles / Diagrammes d’Analyse + Choix technologiques (Architectures, SGBD, etc) Elaboration des Algorithmes et des Structures de données à partir des modèles / diagrammes de Conception  ArchitectureS et SGBD  Modèles / Diagrammes de Conception  Les Algorithmes et les Structures de Données

18 Implémentation : Programmation (Production de codes sources)
Test de vérification : Détection des erreurs (erreurs de programmation + erreurs métiers) Validation : Evaluation de la satisfaction des experts métirs Maintenance et Evolution : Maintenance Corrective (issues des erreurs de programmation et des erreurs métiers après le déploiement du logiciel pendant quelques mois + Maintenance Evolutive (issues de nouveaux besoins exprimés par les experts métiers

19 Méthode d’Analyse et de Conception / Processus de Modélisation?
Expression des besoins Spécification Analyse : Modèles / Diagrammes d’Analyse ? Conception: Modèles / Diagrammes de Conception ? Implémentation Test de vérification Validation Maintenance et Evolution Méthode d’Analyse et de Conception / Processus de Modélisation?

20 I.2 Notion de Méthode d’Analyse et de Conception / Processus de Modélisation

21 Avec quel Modèle / Diagramme, faudra t-il commencer ?
Avec quel modèle / Diagramme, faudra t-il finir ? Comment découler un tel diagramme à partir d’un autre ?  Besoin d’une Méthode / un Processus pour guider l’Analyse et la Conception et élaborer les modèles / Diagrammes

22 Une Méthode d’Analyse et de Conception
= Une démarche en plusieurs étapes + Un Formalisme de Représentation (FR) / Un Langage de Modélisation (LM) / Un Ensemble de Notification (EN) pour Elaborer les Modèles / Diagrammes

23 Une démarche en plusieurs étapes
= Etape 1 : Elaborer de 1 à N Modèles / Diagrammes Etape 2 : Elaborer de 1 à N Modèles / Diagrammes . . . Etape n : Elaborer de 1 à N Modèles / Diagrammes

24 Un Langage de Modélisation (LM)
= Des Notifications Graphiques (RG): Rectangle, Triangle, Cercle, Losange, etc + Règles de Construction de Modèles / Diagrammes

25 Notification graphique ?
Pour une approche donnée, il s’agit de représenter chaque concept par une notification graphique Par exemple : pour l’approche objet: On pourrai représenter une classe par un rectangle On pourrai représenter l’héritage par un triangle

26 Diagramme d’UML + Expertise Métier = Diagramme concret qui modélise presque la réalité de l’expertise métier au sein de l’organisation en question

27 Règles de construction de modèles / Diagrammes :
Règles d’associations entre les notifications graphiques pour construire les modèles / Diagrammes

28 Méthode d’Xavier CASTELLANI (USA) =
Etapes : Etude d’opportunité , Analyse fonctionnelle, Analyse organique + Réalisation + Un Langage de Modélisation pour élaborer les deux modèles suivantes: Modèle fonctionnel Modèle organique

29 Un Langage de Modélisation pour élaborer les 6 modèles suivantes:
Méthode MERISE : Méthode d’Elaboration et de Réalisation Informatique de Systèmes d’Entreprises (France) = Etapes: Etude préalable, Analyse détaillée, analyse technique, réalisation et maintenance + Un Langage de Modélisation pour élaborer les 6 modèles suivantes:

30 MCT: Modèle Conceptuel de Traitements
MCD: Modèle Conceptuel de Données (Modèle Entité / Association) MOT: Modèle Organisationnel de Traitements MLD: Modèle Logique de Données (Modèle Relationnel) MOpT: Modèle Opérationnel de Traitements MPD: Modèle Physique de Données

31 Méthode OMT : Object Modeling Technique (USA)
= Etapes: Analyse, Conception du système, Conception des objets, + Un Langage de Modélisation pour élaborer les modèles : Modèle Statique (Modèle objet) Modèle Dynamique Modèle Fonctionnel

32 Modélisation : Analyse et Conception
Implantation : Implémentation : Programmation : Codage : Production de codes sources

33 LP ? MAC ? Expression des besoins Spécification
Analyse: Modèles / Diagrammes d’Analyse Conception: Modèles / Diagrammes de Conception Implémentation: Codes Sources ? Test de vérification Validation Maintenance et Evolution LP ? MAC ?

34 Méthode d’Analyse et de Conception + Langage de Programmation (LP) :
Approche ? Il faudra choisir une approche parmi trois en se basant essentiellement sur la complexité, la taille, et l’évolutivité de l’expertise métier à informatiser: Approche fonctionnelle Approche Systémique Approche Orientée Objet

35 I.3 Notion d’Approche de développement de logiciels

36 Approche Fonctionnelle =
Analyse et Conception Fonctionnelle (Modélisation des Traitements) avec une Méthode d’Analyse et de Conception Fonctionnelle comme celle d’Xavier CASTELLANI + Implémentation Fonctionnelle avec un Langage de Programmation Fonctionnelle (en C, Pascal, Basic, Fortran, Cobol, …) Persistance des données : Fichiers avec un SGF

37 Approche Systémique = Analyse et Conception Systémique (Modélisation des Traitements et Modélisation des Données Séparément) avec une Méthode d’Analyse et de Conception Systémique comme MERISE + Implémentation Fonctionnelle (PL / SQL d’ORACLE, TRANSACT-SQL de SQL-Server, etc) ou (C&Pro*C et Cobol&Pro*Cobol d’ORACLE) Persistance des données: Base de Données avec un SGBD ou Fichiers avec un SGF

38 Approche Orientée Objet =
Analyse et Conception Orientée Objet (Modélisation de la Communication entres Objets de Classes par envoi de messages) avec une Méthode d’Analyse et de Conception Orientée Objet comme OMT + Implémentation Orientée Objet (JAVA, C++, C#, Delphi, …) Persistance des données: Base de Données avec un SGBD ou Fichiers avec un SGF

39 I.4 Architectures Logicielles et SGBD

40 Commun Language Runtime
Choix d’une Architecture pour développer et distribuer le logiciel: JEE et .NET ou d’un SGBD Soit une Implémentation OO: Architecture ?  Architecture CORBA ? Soit une Implémentation Fonctionnelle: PL / SQL d’ORACLE ou TRANSACT – SQL de SQL – SERVER ? JAVA JDBC, Servlets et JSP, RMI, … Paquetages de Classes JAVA Virtual Machine C#, C++, Delphi, J#, VB ADO, ASP, DCOM, … Paquetages de Classes Commun Language Runtime

41 Mono-Utilisateur : 1-Tier
Choix de l’Architecture du logiciel pour gérer la Monté en Charge (Augmentation du nombre d’Utilisateurs) et la Taille fonctionnelle de l’Application : Mono-Utilisateur : 1-Tier Multi-Utilisateurs : 2-Tiers (Clients – Serveur) ou 3-Tiers ou 4-Tiers Un logiciel comporte toujours trois principales couches: Couche 1: Présentation (Interface Graphique ) Couche 2: Application (Expertise Métier) Couche 3: Persistance (Données)

42 Architecture 1-Tier (1 Utlisateur)
Les trois couches sur une même machine : un seul poste (PC) Couche 1: Présentation (Interface Graphique ) Couche 2: Application (Expertise Métier) Couche 3: Persistance (Données)

43 Couche 3: Persistance (Données) SQL
Architecture 2-Tiers (moins que 100 Utilisateurs connectés en même temps) La couche présentation sur des postes clients (PC) et les deux couches application et persistance sur une ou plusieurs même(s) machine(s) serveur(s) Couche 1: Présentation (Interface Graphique ) généralement en ORACLE FORMS ou en JAVA Couche 2: Application (Expertise Métier) généralement en PL / SQL d’ORACLE ou TRANSACT-SQL de SQL SERVER de MICROSOFT) Couche 3: Persistance (Données) SQL

44 Architecture 3-tiers (Plus que 100 Utilisateurs)
Couche 1: Présentation (Interface Graphique ) sur des Postes Clients (PC) Classes d’Interface (JAVA.AWT ou JAVA.SWING par exemple) Couche 2: Application (Expertise Métier en OO) sur une ou plusieurs machine(s) serveur(s) Classes métiers + Serveur d’Application Couche 3: Persistance (Données) sur une ou plusieurs machine(s) serveur(s) Classes de persistance (JAVA.SQL par exemple + SGBD configuré en tant que serveur de données) JDBC (JAVA DATABASE CONNECTIVITY)

45 Solution libre actuellement très utilisée au niveau des entreprises
Architecture 3-tiers Solution libre actuellement très utilisée au niveau des entreprises JSF (JAVA SERVER FACES) SPRING HIBERNATE

46 Architecture 4-tiers (Application WEB)
Le serveur WEB et Serveur d’Application peuvent être jumelés dans un même logiciel ou deux logiciels différents et peuvent être installé sur une même machine serveur ou sur deux machines différentes Couche 1: Présentation (Interface Graphique ) Couche 2: Serveur WEB Couche 3: Application (Expertise Métier en OO) Classes métiers + Serveur d’Application Couche 4: Persistance (Données)

47 Exemple de Serveurs d’Application propriétaires (il faudra acheter):
IBM WebSphere Application Server ORACLE- BEA Weblogic Application Server ORACLE Application Server BORLAND Application Server ORACLE – SUN Java System Application Server Citrix Novell Application Server Sybase Application Server

48 Exemple de Serveurs d’Application libres (Open Source) :
Apache Tomcat (Serveur WEB) JBoss JOnAS Serveur d‘Application Open Source proposé par OW2 GlassFish Serveur d‘Application Open Source de Sun - Oracle Geronimo Nirva Application Platform Zobolle Zope

49 I.5 Outils CASE (Computer Aided Software Engineering)

50 Environnement de développement
Outils facilitant la programmation, la génération automatique de codes sources pour des interfaces graphiques dessinées, la compilation, l’édition des liens, le débogage, etc Exemples: Visual Studio.net, Eclipse, NetBeans, Jbuilder, Jdevelopper, Kawa, C++ Builder, Turbo C++, …

51 Ateliers de Génie Logiciel
Outils facilitant aux informaticiens l’Elaboration des diagrammes, la génération automatique de codes sources à partir de diagrammes, la génération automatique de diagrammes à partir de codes sources (Reverse Engineering), etc Exemples: Entreprise Architect, Visual Paradigm, Paradigm Plus, Power AMC, Windev, Webdev, StarUML, ArgoUML, FUJABA, Eclipse + Plug - in (Omondo, Domino, Plug – in de IBM, etc)

52 I.6 Culture générale, connaissances, compétences et expériences nécessaires pour l’ingénieur en informatique

53 Programmation Orientée Aspect
Technologie AJAX: Asynchronous Javascript and XML Différence entre PHP et JSP et ASP Différence entre .NET et JEE, entre JSE, JEE, JME Model Driven Architecture (MDA): Architecture dirigée par les modèles Model-View-Controller (MVC): Modèle-Vue- Controleur Design Patterns: Patrons de Conception Customer RelationShip Management (CRM): Progiciel de Gestion de la Relation avec les Clients

54 WEB-Service et Service Oriented Architecture (SOA) : Service WEB et Architecture Orientée Service
Informatique Décisionnelle (Business Intelligence): DataWareHouse et DataMining (ORACLE WAREHOUSE BUILDER, ORACLE DISCOVERER, PENTAHO, …) Informatique Embarquée: LINUX embarqué, WINDOWS CE, WINDOWS Mobile, Architecture Android Open Source, General Public Licence (GPL), Licence Publique Générale (LPG), Association AFUL: Association Francophone des Utilisateurs de Logiciels Libres

55 Audit Informatique ? ISACA : Information Systems Audit and Control Association AFAI : Association Française de l’Audit et du Conseil Informatiques CISA : Certified Information System Auditor CISM : Certified Information Security Manager CGEIT : Certified in the Governance of Enterprise Information Technology Conseil Informatique ?

56 ERP: Entreprise Resource Planning: PGI : Progiciel de Gestion Intégré
ANSI: Agence Nationale de la Sécurité Informatique ANCE: Agence Nationale de Certification Electronique Cloud Computing: l’Informatique dans les nuages: Virtualisation des Systèmes d’Information des entreprises Processus de développement de logiciels: processus en Cascade, processus en V, processus en W, processus en Spirale, processus Agiles (XP, RUP, SCRUM, etc)

57 Certification d’équipes d’informaticiens (SSII):
CMM: Capability Maturity Model et CMMI: Capability Maturity Model Integration du SEI: Software Engineering Institute – USA ITIL: Information Technology Infrastructure Library de l’OGC : Office of Government Commerce et ensuite Cabinet Office

58 Certification de logiciels: Il faudra avoir des compétences en terme de Test et de Qualité de Logiciels, il faudra disposer de logiciels de test de logiciels, il faudra connaître les standards ISO pour le développement de logiciels (normes de codage, etc). ITSQB (International Software Testing Qualifications Board)

59 Organismes certificateurs de logiciels: AFNOR: Association Française de NORmalisation
ANSI: American National Standard Institute ISO: International Standard Organisation INNORPI: Institut National de la NORmalisation et de la Propriété Intellectuelle

60 OCUP (OMG Certified UML Professional) – Object Management Group
Certification de personnes : OCUP (OMG Certified UML Professional) – Object Management Group JEE - ORACLE – SUN .NET, SQL – SERVER – MICROSOFT ORACLE (SQL, Administration des BD, …) - ORACLE

61 Organismes certificateurs de personnes en Tunisie
CIFODE’COM: Centre d’Information, de Formation, de Documentation et d’Etudes en Technologies des Communications SmartFutur Solutions ADVANCIA, … 3C: Cabinet de Certification des Compétences à Sfax, site web: formation.com/

62 Métiers de l’Informatique
Intégration Progicielle Ingénierie Logicielle M E T I R Consulting Infrastructure & Production: Administration Système, Administration de Bases de Données

63 Structuration du marché Informatique Fournisseurs de Technologies
X Structuration du marché Informatique Cabinet de Conseil Editeurs SSII Fournisseurs de Technologies

64 Axes très demandés par le marché informatique:
- Ingénierie Logicielle - CMMI - Test de Logiciel – ITSQB (International Software Testing Qualifications Board) - Réseaux et Sécurité – CISCO, etc - Systèmes et Bases de Données (UNIX, WINDOWS, ORACLE, SQL – SERVER, etc)

65 Chapitre II : Genèse d’UML et RUP

66 Méthode d’Analyse et de Conception OO
Méthode OOD (Object Oriented Development) de Grady Booch Méthode OMT (Object Modeling Technique) de James Rumbaugh Méthode OOSE (Object Oriented Software Engineering) d’Ivar Jacobson Méthode OOAD de Shlaer et Mellor Méthode OOA (Object Oriented Analysis) de Coad et Yourdon MERISE/2 (1990) et puis Méthode OOM : Orientation Objet dans MERISE date de 1992 Méthode O* Méthode MCO d’Xavier Castellani

67 Au cours de la période : 1990 - 1997
Pour l’approche fonctionnelle et l’approche systémique : Apparition de 20 Méthodes d’Analyse et de Conception Pour l’approche Orientée Objet :   Plus de 150 Méthodes d’Analyse et de Conception Aucune méthode ne s'est réellement imposée Les trois méthodes les plus utilisées sont : OMT, OOD et OOSE

68 Méthodes d’Analyse et Conception Orientées Objets dominantes
OOD: Object Oriented Development Proposée 1981 par Grady BOOCH Diagrammes pour la Conception: Diagramme de classes, Diagramme d’instances, Diagramme d’états / transitions, Diagrammes pour l’Implémentation: Diagrammes de modules, Diagramme de processus - Définie pour le DOD (USA), afin de rationaliser le développement d'applications ADA, puis C++ - Ne couvre pas l’étape de Spécification et l’étape d’Analyse: Centré sur l’étape Conception et l’étape d’Implémentation

69 Méthodes d’Analyse et Conception Orientées Objets dominantes
OMT: Object Modeling Technique Proposée en 1991 par James RUMBAUGH - Modèles: Modèle statique (Modèle Objet), Modèle Dynamique et Modèle fonctionnel - Issue du centre de Recherche et Développement de General Electric au USA. - Ne couvre pas l’étape de Spécification: Centré sur l’étape d’Analyse et l’étape de Conception - Notation graphique riche et lisible : 80 % des notifications graphiques d’UML sont du LM d’OMT

70 Méthodes d’Analyse et Conception Orientées Objets dominantes
OOSE: Object Oriented Software Engineering Proposé en 1995 par Ivar JACOBSON - Modèles: Modèle de Besoins (Cas d’Utilisation), Modèle d’Analyse, Modèle de Conception, Modèle d’Implantation, Modèle de Test - Issue d'un centre de développement d'Ericsson, en Suède. - Couvre pratiquement toutes les étapes du processus de développement de logiciels - JACOBSON est le seul qui a proposé un modèle à élaborer au niveau de l’étape de Spécification  

71 Méthode OMT de James RUMBAUGH :
Langage de Modélisation 1 (LM 1) + Démarche 1 Méthode OOD de Grady BOOCH : Langage de Modélisation 2 (LM 2) + Démarche 2 Méthode OOSE de Ivar JACOBSON : Langage de Modélisation 3 (LM 3) + Démarche 3 … Nième méthode : Langage de Modélisation N (LM N) + Démarche N

72 SSII 1 a modélisée un logiciel de gestion commerciale avec OMT (LM de OMT)
SSII 2 a modélisée un logiciel de gestion commerciale avec OOD (LM de OOD) SSII 3 a modélisée un logiciel de gestion commerciale avec OOSE (LM de OOSE) Les informaticiens de SSII 1 et de SSII 2 et de SSII 3 veulent se réunir sur une même table pour se mettre d’accord sur une modélisation unique qui récapitule les trois différentes modélisations Comment faire ? Solution: UML

73 En 1994, on recensait plus de 50 Méthodes d’Analyse et de Conception Orientées Objets (50 Langages de Modélisation) !!!??? Dans le but de remédier à cette dispersion que les « poids-lourds » des Méthodes d’Analyse et de Conception Orientées objets ont décidé de se rassembler En Octobre 1994, Grady BOOCH et James RUMBAUGH se sont réunis au sein de la société RATIONAL SOFTWARE dans le but de travailler à l’élaboration d’une Méthode Commune en unifiant leurs deux méthodes OOD et OMT et en corrigeant les défauts et en comblant les déficits

74 Au niveau de la Conférence OOPSLA’ (Object Oriented Programming Systems, Languages and Applications Conference): la grande conférence sur la programmation orientée objet: Grady BOOCH et James RUMBAUGH présentent UNIFIED METHOD V 0.8

75 Réaction des industriels :
- Proposer une méthode unifiée en vue d’un standard c’est comme la proposition d’une nouvelle méthode comme les autres méthodes utilisées déjà depuis des années - unifier et standardiser une méthode  unifier et standardiser des étapes à suivre pour modéliser (démarche, processus)  unifier et standardiser les habitudes de tous les informaticiens dans le monde !!!???

76 Message passé à BOOCH et RUMBAUGH: Les informaticiens ont du mal à changer leurs habitudes  ils veulent bien garder les étapes à suivre (la démarche) des méthodes qu’ils ont eu l’habitude de suivre mais pas de problèmes si on leurs change le Langage de Modélisation Les travaux de BOOCH et de RUMBAUGH ne visaient plus à constituer une méthode unifiée (unified method), mais un langage unifié (unified language) Fin 1995, Ivar JACOBSON rejoint BOOCH et RUMBAUGH chez RATIONAL SOFTWARE et l’UML (Unified Modeling Language) 0.9 a vu le jour

77 Les initiatives de BOOCH, RUMBAUGH et JACOBSON ont été soutenues par de nombreuses sociétés comme : MICROSOFT, ORACLE, HP, IBM, etc) UML 1.0 a été déposé en Janvier 1997 à l’OMG (Object Management Group) en vue de la standardisation d’un Langage de Modélisation. Une version améliorée de UML 1.0 (UML 1.1) a été soumise à l’OMG en Septembre 1997 Après une étude approfondie, UML 1.1 a été accepté en Novembre 1997 par l’OMG en tant que standard (norme) sous la référence UML 1.1.

78 Différentes Versions d’UML
UML 1.X Novembre UML 1.1, Juin UML 1.2 Mars UML 1.3, Septembre UML 1.4, Septembre UML 1.4.2, Mars UML 1.5 UML 2.X Juillet UML 2.0, Août UML 2.1.1, Novembre UML 2.1.2, Février UML 2.2, Mai UML 2.3, Mars UML 2.4 – Beta 2

79 OMG: Object Management Group
Organisme à but non lucratif fondé en 1989 Constitué de plus de 700 entreprises Connu pour la norme CORBA Site WEB:

80 UML Unified : Unifié Modeling : Analyse et Conception Language : UML est un Langage de Modélisation et ne pas une Méthode d’Analyse et de Conception / Processus de Modélisation

81 Les diagrammes d’UML sont plus étendus que les modèles / Diagrammes des méthodes OMT, OOSE, OOD en nombre et en vision (sémantique) Les travaux de RUMBAUGH, BOOCH et JACOBSON ne visaient pas que l’unification des notifications graphiques mais visaient aussi la proposition de diagrammes plus riches et plus intéressants que les diagrammes de leurs méthodes OMT, OOD et OOSE en ajoutant de nouveaux diagrammes si nécessaire

82 UML = LM de OMT Union + Choix LM d’OOD LM d’OOSE

83 4 principales phases ont conduit à UML:
Fragmentation: Chacun propose son LM Unification par RUMBAUGH, BOOCH et JACOBSON Standardisation par l’OMG Industrialisation par les entreprises

84 Collaboration Diagram
9 Diagrammes d’UML 1.X Use Case Diagram Activity Diagram Sequence Diagram Collaboration Diagram State Machine Diagram Class Diagram Object Diagram Component Diagram Deployment Diagram

85 9 Diagrammes d’UML 1.X + Changements
4 Nouveaux Diagrammes

86 13 Diagrams d’UML 2.X Activity Diagram Sequence Diagram
Use Case Diagram Activity Diagram Sequence Diagram Communication Diagram State Machine Diagram Class Diagram Object Diagram Component Diagram Deployment Diagram Composite Structure Diagram Package Diagram Timing Diagram Interaction Overview Diagram

87 Langage de modélisation / Méthode (Processus de modélisation)
Le Langage de modélisation a été unifié et standardisé et industrialisé Depuis novembre 1997 : les informaticiens ont utilisé la notation suivantes: Langage de modélisation / Méthode (Processus de modélisation) Exemples: UML / OMT UML / OOSE UML / OOD, …

88 3 Modèles de la méthode OMT
Modèle Objet ou Statique Modèle Fonctionnel Modèle Dynamique 9 Diagrammes d’UML 1.X Diagramme de Classes Diagramme d’Activités Diagramme d’Etat / Transition + Diagramme de Séquence Diagramme d’Objets ? Diagramme de Cas d’Utilisation ? Diagramme de Collaboration ? Diagramme de composants ? Diagramme de déploiement ?

89 Comment faire ? Solution : UP / RUP
Les informaticiens ont rencontré des problèmes d’agencement de diagrammes: Avec quel diagramme on commencera ? Avec quel diagramme on terminera Comment découler un tel diagramme à partir d’un autre ? Quelle est la relation entre un tel diagramme et un autre ? OMT ou OOD ou OOSE (3, 5, 5 Diagrammes / Modèles) / UML (9 Diagrammes) ? Comment faire ? Solution : UP / RUP

90 Méthode OMT de James RUMBAUGH :
Langage de Modélisation 1 (LM 1) + Démarche 1 Méthode OOD de Grady BOOCH : Langage de Modélisation 2 (LM 2) + Démarche 2 Méthode OOSE de Ivar JACOBSON : Langage de Modélisation 3 (LM 3) + Démarche 3 … Nième méthode : Langage de Modélisation N (LM N) + Démarche N

91 RUP : UP + Améliorations de Rational Software
Démarche de OMT Union & Choix Démarche d’OOD Démarche d’OOSE RUP : UP + Améliorations de Rational Software

92 3 principales phases ont conduit à UP :
Fragmentation: chacun sa méthode Unification par RUMBAUGH, BOOCH et JACOBSON Industrialisation par les entreprises  Un processus pourra être toujours unifié mais jamais être standardisé

93  La notion de Méthode d’Analyse et de Conception a disparu:
UP / RUP se base sur les étapes du processus de développement de logiciels et défini les diagrammes d’UML à élaborer au niveau de chaque étape  La notion de Méthode d’Analyse et de Conception a disparu: Conclusion: UML / RUP

94 Extensions d’UML

95 Pour les applications WEB (Hypermédias)
Avant UML : - Méthode RMM : Relationship Management Methodology [Isakowitz et al., 1995] - Méthode OOHDM : Object Oriented Hypermedia Design Methodology - Méthode AWIS-M : Adaptative Web-based Information System – Method [Gnaho 2000] - Méthode HyperTIM : Hypermedia Task oriented Information Modeling [Wettengel 01] - Langage WebML : Web Modeling Language [Ceri 00]

96 Après l’apparition d’UML :
- Koch en 2000 a proposé UML-based Web Engineering ( Conallen a proposé en 2000 Web – UML dans son livre « Concevoir des applications web avec UML, EDITIONS EYROLLES, 2000 »

97 Pour la Modélisation et l’Analyse des Systèmes Temps Réels et Embarqués:
UML - MARTE (UML profile for Modeling and Analysis of Real-Time and Embedded Systems), Projet d’extension de Charles André Laboratoire I3S (Laboratoire d'Informatique, Signaux et Systèmes de Sophia-Antipolis) de Nice en France Cette extension a été acceptée en tant que standard par l’OMG depuis Juin 2007 (