Réseaux et systèmes répartis C3

Transcription

1 CAMOS CNAM Objet 1 : Techniques orientées objet et gestion de projet Plan du jour Présentation des langages orientés objets : notions nécessaires à la compréhension d un langage orienté objet Analyse et design orientés objet Environnement de la gestion de projet 2 Informatique, réseaux, systèmes, multimédia / 1

2 CAMOS CNAM Introduction Les systèmes informatiques actuels sont de plus en plus souvent conçus suivant un mode de conception orienté objet avant d être mis en œuvre à l aide de langages orientés objet Pourquoi existe-t-il un besoin d introduire une nouvelle façon de faire? Cela vaudra-t-il les efforts consentis? 3 Langages informatiques Les premiers langages informatiques étaient très proches de l électronique Assembleurs ou même binaire dans le pire des cas L informatique a évolué grâce à l apparition des compilateurs et des interpréteurs Deuxième et troisième génération de langages informatique Fortran, Basic, COBOL 4 Informatique, réseaux, systèmes, multimédia / 2

3 CAMOS CNAM Langages informatiques (2) Les langages informatiques de troisième génération ont évolué vers les langages de quatrième génération Les instructions des langages 4GL sont très puissantes / expressives La complexité est cachée au programmeur MAIS : ces langages sont avant tout issus de formalismes mathématiques peu soucieux des complexités du monde et donc de l analyse 5 Naissance des langages orientés objet Du point de vue de l analyse, l homme a plutôt tendance à utiliser des classifications (taxonomies) Elles permettent de diviser le monde en groupes et sous-groupes : le monde devient plus facile à appréhender et à modéliser (ex : recherches web) Les classifications peuvent être variées et fondées sur des analyses statistiques, par composantes principales, ou, de façon moins formelle, par distinction de caractéristiques textuelles 6 Informatique, réseaux, systèmes, multimédia / 3

4 CAMOS CNAM Naissance des langages orientés objet (2) L informatique s intéresse également à la simulation mais Comment représenter efficacement le monde lorsque l on a que des piles, des files et des tableaux? Comment représenter les interactions entre les acteurs du monde lorsque le mode de programmation le plus répandu ne prône que pour un enchaînement déterministe et fini d actions? La solution se présente à partir de 1962 : SIMULA 7 Naissance des langages orientés objet (3) SIMULA : SIMUlation LAnguage Simula est principalement fait pour supporter l exécution d univers basés sur des interactions faites à travers des évènements discrets Événements discrets : Quelque chose arrive Quelqu un s en rend compte Il informe une ou plusieurs autres entités qui réagissent en fonction de leurs états internes en : Fournissant l information demandée Créant d autres évènements 8 Informatique, réseaux, systèmes, multimédia / 4

5 CAMOS CNAM Naissance des langages orientés objet (4) Le langage SIMULA repose sur l échange de messages entre entités indépendantes effectuant des traitements autonomes ATTENTION : Certaines entités peuvent être d un même type et peuvent ainsi effectuer des traitements similaires en ayant des états internes différents à un moment donné Les langages orientés objet empruntent deux idées de bases aux langages de simulation Les entités (objets) Les messages 9 Caractéristiques des objets Être capable de définir des objets ne donne pas de règles pour les définir correctement Règle «Apple PIE» Abstraction Polymorphisme Héritage (Inheritance) Encapsulation 10 Informatique, réseaux, systèmes, multimédia / 5

6 CAMOS CNAM Caractéristiques des objets : Abstraction L abstraction est une généralisation L abstraction permet d ignorer ou de cacher les détails, permettant d extraire des points communs entre différentes entités L abstraction la plus intéressante pour les langages orientés objet est utilisée par les types de données abstraits, ADT, Abstract Data Types 11 Types de donnée abstraits Un ADT est abstrait Un ADT s utilise à travers ses structures et ses fonctions mais les agissements de ces fonctions ne sont pas connus du programmeur L important est que soit connus les fonctions et leurs comportements : la manière dont elles sont implémentées doit rester sans importance Un ADT respecte une sorte de contrat, deux ADTs respectant le même contrat sont interchangeables 12 Informatique, réseaux, systèmes, multimédia / 6

7 CAMOS CNAM Types de donnée abstraits (2) Décrit un ensemble de propriétés essentielles sans sur-spécifier la représentation interne On veut juste pouvoir s en servir, on ne veut pas savoir comment c est fait L interface d un ADT fournit une liste d opérations et non pas une description de l implémentation Dit «quoi» plutôt que «comment» 13 Types de donnée abstraits (3) 14 Informatique, réseaux, systèmes, multimédia / 7

8 CAMOS CNAM Types de donnée abstraits (4) Un ADT permis de disposer d un «bloc» de code complet, précis et disposant d une description et de spécifications claires et sans ambiguïtés Un ADT permet de ne pas être dépendant de la représentation physique interne Beaucoup moins de problèmes de portage Plus facile de changer de plate-forme 15 Types de donnée abstraits (5) 16 Informatique, réseaux, systèmes, multimédia / 8

9 CAMOS CNAM Caractéristiques des objets : Encapsulation Un type de donnée abstrait correspond au regroupement d un ensemble de caractéristiques (données) et de comportements (traitements) Même si les détails sont cachés, il est possible d obtenir certaines données et d utiliser certains traitements grâce à une interface (définition) claire et précise Ce regroupement correspond à l encapsulation 17 Caractéristiques des objets : Héritage L héritage est le mécanisme qui permet de réaliser l abstraction Exemple : si la taxonomie précise que «dauphin» est un «mammifère», alors «dauphin» héritera de toutes les caractéristiques et de tous les comportements des «mammifères» Suite de l exemple : «cheval» héritera des mêmes caractéristiques et comportements Note : au départ, la notion de type de donnée abstrait n incluait pas l héritage 18 Informatique, réseaux, systèmes, multimédia / 9

10 CAMOS CNAM Caractéristiques des objets : Héritage (2) Du plus spécifique au plus général : abstraction (des fonctionnalités) On ne retrouve que les caractéristiques communes à tous les éléments spécifiques Du plus général au plus spécifique : héritage (et spécialisation) De nouvelles caractéristiques apparaissent lorsque l on crée de nouveaux éléments 19 Caractéristiques des objets : Héritage (3) spécialisation abstraction Mammifère Cheval Dauphin 20 Informatique, réseaux, systèmes, multimédia / 10

11 CAMOS CNAM Caractéristiques des objets : Polymorphisme Le polymorphisme est une conséquence de l héritage : des objets qui héritent d une même classe plus abstraite peuvent définir un même comportement de manière différente Exemple : les mammifères se déplacent mais un dauphin et un cheval ne se déplacent pas de la même manière Pourtant, il sera possible de demander de manière uniforme à tous les mammifères d un système de se déplacer : la réalisation de l action est déléguée par la classe abstraite mammifère aux classes concrètes 21 Environnement des langages orientés objet Les langages orientés objet utilisent de manière extensives les concepts des types de données abstraits et de l héritage Un langage orienté objet est plus ou moins propre Il incorpore un nombre plus ou moins grand de concepts théoriques orientés objet Un langage orienté objet n est pas grand chose sans un ensemble consistant de librairies 22 Informatique, réseaux, systèmes, multimédia / 11

12 CAMOS CNAM Environnement des langages orientés objet : librairies 23 Librairies Les librairies sont des compléments aux compilateurs, elles existent depuis les origines de l informatique Elles peuvent être précompilées (abstraction de l implémentation ) Elles facilitent le travaillent dès qu on en a une bonne connaissance Il faut malheureusement acquérir cette connaissance! Cela prend plus ou moins de temps en fonction de la taille de la librairie Environnement des langages orientés objet : librairies (2) Librairies (suite) Les langages à objets ne seraient rien sans de bonnes librairies puisqu il faudrait réinventer le monde à chaque fois La définition de librairies est facilitée par la notion de types de données abstraits Une librairie associée à un langage orienté objet pourra mettre à disposition des données et des traitements standards On y prend ce dont on a besoin 24 Informatique, réseaux, systèmes, multimédia / 12

13 CAMOS CNAM Environnement des langages orientés objet : librairies (3) En C++ : Standard Template Library En Java Classes de l environnement de base Gestion de l affichage, gestion des connexions réseaux, gestion des entrées/sorties, gestion de l appel de procédures à distance, gestion de la sécurité Classes de l environnement d entreprise Gestion des messageries utilisateur et applicatives, gestion des appels à des objets distants 25 Environnement des langages orientés objet : frameworks Les Application frameworks sont des applications teintées d abstraction : Le flot général d une application est respectée Possèdent différents points d entrées sous forme de classes abstraites (non exécutables / instantiables) Les classes abstraites peuvent être spécialisées pour réaliser un traitement dont l objectif est défini par la classe abstraite mais dont l algorithmique sera choisi en fonction d un problème/contexte précis. On prend ce que l on veut dans une librairie, on remplit les cases vides dans un framework 26 Informatique, réseaux, systèmes, multimédia / 13

14 CAMOS CNAM Environnement des langages orientés objet : frameworks (2) Exemples de frameworks Un algorithme de tri Il garantit qu un ensemble d objets sera trié selon un algorithme de tri particulier, Il laisse au développeur le soin de définir la fonction de comparaison entre deux objets. Un serveur web Il garantit de fournir une réponse à une demande (correcte) de page, Il laisse la possibilité de «pluguer» des modules de transformation pour certains types de pages. 27 Environnement des langages orientés objet : frameworks (3) La distinction entre librairies et frameworks pourraient être simple dans des langages procéduraux. Elle est beaucoup plus floue avec les langages orientés objet : Résultat de l encapsulation des données et des traitements au sein de mêmes entitées Distinction encore possble en tenant compte de la classe principale / mère : est-ce une donnée ou un traitement? 28 Informatique, réseaux, systèmes, multimédia / 14

15 CAMOS CNAM Environnement des langages orientés objet : composants «Un composant logiciel est une unité de composition logicielle avec des interfaces spécifiées contractuellement et des dépendances contextuelles explicites. Un composant logiciel peut être déployé indépendamment mais peut également être utilisé par des tiers» Szyperski et Pfister, ECOOP Environnement des langages orientés objet : composants (2) Les composants ont une définition floue! Certains composants sont réutilisables : Sun Java Beans Microsoft ActiveX Certains composants sont distribuables sur plusieurs machines (serveurs et clients) : Sun Enterprise Java Beans Microsoft DCOM (architecture de base) 30 Informatique, réseaux, systèmes, multimédia / 15

16 CAMOS CNAM Environnement des langages orientés objet : composants (3) En fait, les composants respectent des règles qui leur permettent d être utilisés dans un contexte (c est dans la définition!). Un composant réutilisable est capable de dialoguer avec le reste d une application en respectant un certain protocole. Un composant distribuable identifie clairement les parties allant sur le client et celles allant sur le serveur, en respectant le protocole de communication entre les deux. 31 Une notation pour le design objet : UML UML n est pas une invention ab nihilo UML est en fait la fusion de plusieurs méthodologies orientées objet dont chacune avait ses forces et ses faiblesses Au début du cycle de conception de l UML, de plus en plus de méthodologies ont été analysées et le meilleur en a été gardé UML peut presque, aujourd hui, être qualifié de synthèse des modélisations objet 32 Informatique, réseaux, systèmes, multimédia / 16

17 CAMOS CNAM Une notation pour le design objet : UML (2) UML est un VRAI standard La conception d UML a commencé en dehors du monde de la normalisation L UML a ensuite été soumis à l OMG, l Object Management Group L OMG est également responsable, entre autre chose, de CORBA UML n est cependant pas toujours implémenter complètement, certains «oubliant» des types de diagrammes 33 Une notation pour le design objet : UML (3) UML n est pas une langue morte Au delà du fait qu elle soit de plus en plus utilisée, cette langue évolue encore La norme UML 2 sortira avant la fin de l année, après 1 année de pre-release UML participe désormais à une intégration très large au sein de l OMG UML en XML : XMI, XML Metadata Interchange MDA : Model Driven Architecture ; UML/XMI comme base pour la définition d applications et l échange de modèles entre entreprises (CORBA, J2EE,.Net, services web) 34 Informatique, réseaux, systèmes, multimédia / 17

18 CAMOS CNAM Une notation pour le design objet : UML : élaboration UML 2.0 draft** OMG UML UML UML Partenaires UML UML /1997 Autres méthodes UML Unified Method Méthode OOSE 35 Méthode Booch Méthode OMT Origines d UML Les trois méthodes de base de l UML sont : Méthode Booch : Grady Booch Méthode OMT (Object Modeling Technique) : James Rumbaugh Méthode OOSE (Object Oriented Software Engineering) : Ivar Jacobson Booch, Jacobson et Rumbaugh travaillent ensemble chez Rational (et donc IBM) Étonnamment, Rational Rose est pour l heure le produit leader de modélisation UML 36 Informatique, réseaux, systèmes, multimédia / 18

19 CAMOS CNAM Composants d UML UML comprend un ensemble de diagrammes assez différents dont chacun a un rôle Plus ou moins général Plus ou moins large Statique ou dynamique UML peut être vu à travers un diagramme baptisé 4+1 Une vue centrale, quatre vues annexes 37 Composants d UML (2) Utilisateur final - Fonctionnalités - Vocabulaire Vue logique (design) Vue composants Développeurs - Développement et gestion du logiciel Vue Cas d utilisation Analystes/Testeurs -Comportement 38 Vue processus Intégration de système - Performance - Capacité d extension - Capacité de charge Vue déploiement Ingénierie de système - Topologie - Déploiement et installation -Communication Informatique, réseaux, systèmes, multimédia / 19

20 CAMOS CNAM Composants d UML (3) Diagramme de classes Diagramme d objets Diagramme d activités Diagramme de séquences Diagramme de collaboration Diagramme d états-transitions Vue structurelle Vue comportementale Vue utilisateur Diagramme de cas d utilisation Vue d implémentation Diagramme de composants Diagramme de déploiement Vue environnementale 39 UML : Use Case Les Use Case (cas d utilisation) permettent de faire l étude préalable des fonctionnalités recherchées par dialogue avec l utilisateur Les Use Case Diagrams sont un support à la modélisation et à la discussion L information est surtout informelle Scénarios (documents texte d explication), copies d écran, etc Statique et dynamique 40 Informatique, réseaux, systèmes, multimédia / 20

21 CAMOS CNAM UML : Use Case (2) navigue «utilise» internaute se connecte paie son abonnement 41 UML : Class Diagram Les diagrammes de classes permettent de définir la taxonomie (classification) des différents objets nécessaires au bon fonctionnement du système Les diagrammes de classes sont statiques Les diagrammes de classes permettent de faire la distinction entre l appartenance à un groupe et la composition d un objet 42 Informatique, réseaux, systèmes, multimédia / 21

22 CAMOS CNAM UML : Class Diagram, aparte Avant toute modélisation objet, il faut clairement faire la distinction entre «est un» (is-a) et «a un» (has-a) Un cheval est un mammifère, un homme est un mammifère Un homme a des jambes Une fourmi a des pattes Ces deux mécanismes sont à la base de la définition des classes 43 UML : Class Diagram (2) Animal Insecte Mammifère 1 2,4 Jambe Cheval Homme 1 1..* Vêtement 1..* 1 Famille 44 Informatique, réseaux, systèmes, multimédia / 22

23 CAMOS CNAM UML : Class Diagram (3) Dans un diagramme de classe, on marque le lien is-a par l héritage Le lien has-a est beaucoup plus raffiné, il est possible de noter : Une association Une aggrégation Une composition Il est également possible de marquer des cardinalité et des sens de navigation 45 UML : Class Diagram (4) Association : deux objets sont liés mais de manière relativement indépendante. La relation est très relâchée. Tarif Etape Enumeration getzones() Price getprix( Zone ) * * prix zone 46 Informatique, réseaux, systèmes, multimédia / 23

24 CAMOS CNAM UML : Class Diagram (5) Aggrégation : plus forte que l association, elle marque un lien de composition fort. Les constituants peuvent exister sans l aggrégat mais cela n a alors plus beaucoup d intérêt. Pot_Échappement 1 Silencieux 0..2 Tuyau 47 UML : Class Diagram (6) Composition : il s agit du lien le plus fort : les constituants ne peuvent pas exister sans l aggrégat. DistributeurDeTickets 3 SélecteurDestination Note : le choix de l aggrégation ou de la composition dépend du contexte / de l univers où se fait la modélisation 48 Informatique, réseaux, systèmes, multimédia / 24

25 CAMOS CNAM UML : Class Diagram (7) Lors de la définition d un héritage entre classes, il faut toujours commencer par le plus général pour descendre vers le plus particulier Autrement dit : ne pas faire de hiérarchies inversées La racine d un arbre doit être un objet très général C est grâce à cela que l on peut réutiliser 49 UML : Class Diagram (8) Directeur Employé Manager Manager 50 Employé Note : les diagrammes de classes et les organigrammes de fonction n ont donc rien à voir! Directeur Informatique, réseaux, systèmes, multimédia / 25

26 CAMOS CNAM UML : Class Diagram (9) Des classes peuvent être regroupées en package (paquetage) Un package est un groupe de classes dont le rôle est similaire ou qui possèdent la même appartenance Package des mammifères Package de connexion réseau Un package permet d obtenir un niveau d abstraction (il cache la foule ) 51 UML : Class Diagram (10) Éléments dynamiques Collaborations Use Cases Statechart Activity Gestion du modèle Common Behavior Foundation 52 Informatique, réseaux, systèmes, multimédia / 26

27 CAMOS CNAM UML : Exercice #1 Créer un diagramme de classes dans le domaine des transports en commun Définissez une arborescence des moyens de transport Définissez les constituants et l environnement de ces moyens de transport N utilisez pas les packages 53 UML : Exercice #2 Système d enregistrement d une conférence Créez la hiérarchie incorporant : Les organisateurs Les orateurs invités Les orateurs principaux Les orateurs annexes Les participants inscrits industriels Les participants inscrits académiques (profs) Les participants inscrits étudiants 54 Informatique, réseaux, systèmes, multimédia / 27

28 CAMOS CNAM UML : Exercice #2 (2) Que se passe-t-il si : Un organisateur est orateur annexe Un étudiant est orateur principal Un orateur principal décide de ne pas présenter ses travaux mais assiste tout de même en tant que participant inscrit académique 55 UML : Exercice #2 (3) Donc : Un héritage simple est parfois insuffisant mais L héritage multiple apporte beaucoup de complications et d illisibilité L introduction / la création d associations peut être bénéfique Mais il faut alors définir des conditions d utilisation des associations 56 Informatique, réseaux, systèmes, multimédia / 28

29 CAMOS CNAM UML : Object Diagram Les diagrammes d objets montrent les instances et les liens entre objets À la différence du diagramme de classes, le diagramme d objets est dynamique Il illustre des situations (snapshots) Il permet de présenter les structures des objets et des données Il est en fait presque dynamique 57 UML : Object Diagram (2) c : Compagnie d1 : Département nom = "ventes" d2 : Département nom = " R&D" p : Personne nom = "Dupont" id = 2718 emploi ="vendeur" : Adresse adresse = "rue" 58 Informatique, réseaux, systèmes, multimédia / 29

30 CAMOS CNAM UML : Component diagram Les diagrammes de composants permettent de représenter la structure physique de l implémentation Organisation du code source Compilation d exécutables Bases de données physiques Ils sont proches des choix techniques Ils sont statiques 59 UML : Component diagram (2) find.html index.html find.exe nateng.dll dbacs.exe 60 Informatique, réseaux, systèmes, multimédia / 30

31 CAMOS CNAM UML : Activity diagram Les diagrammes d activités permettent d obtenir une vision orientée métier d un processus Montre l enchaînement des actions, les synchronisations, les responsabilités des acteurs Note : ils ont de plus en plus de succès pour les modélisations de workflows 61 UML : Activity diagram (2) Client Ventes Comptabilité Stocks Informer du renvoi Renvoyer article Article [renvoyé] Donner # remboursement Réception article Stockage article Rembourser article Article [disponible] 62 Informatique, réseaux, systèmes, multimédia / 31

32 CAMOS CNAM UML : Sequence diagram Les diagrammes de séquences permettent de raffiner les use case en : Permettant d identifier les objets participants De trouver des objets manquants De marquer les enchaînements Ils marquent également des durées d exécution Ils sont dynamiques 63 UML : Sequence diagram (2) Client sélectionboisson() Distributeur de boissons introductionargent() récupérationmonnaie() récupérationboisson() 64 Informatique, réseaux, systèmes, multimédia / 32

33 CAMOS CNAM UML : Collaboration diagram Les diagrammes de collaboration permettent de représenter les interactions entre classes Ils présentent les flux de contrôle Ils illustrent la coordination entre les objets de structure et les objets de contrôle Ils sont dynamiques (orientés messages) 65 UML : Collaboration diagram (2) c : Client 1 : crée 2 : prépareaction( a, d, o ) 3 : détruit d2 : Département p : ODBCProxy 2.1 : affecte( d, 3.14 ) 2.2 : affecte( a, "CO" ) 66 Informatique, réseaux, systèmes, multimédia / 33

34 CAMOS CNAM UML : Statechart diagram Les diagrammes d états-transitions correspondent à une version allégée des diagrammes d activité Plus d illustration de responsabilités, de synchronisation Ils pourraient typiquement être utilisés en automatique pour modéliser le comportement d un automate Ils sont dynamiques (orientés évènements) 67 UML : Statechart diagram (2) touches 1 & 2 Heures clignotent touche 2 Incrément heures touche 1 touches 1 & 2 Minutes clignotent touche 2 Incrément minutes touche 1 Arrêt clignotement touches 1 & 2 Secondes clignotent touche 2 Incrément secondes 68 Informatique, réseaux, systèmes, multimédia / 34

35 CAMOS CNAM UML : Deployment diagram Les diagrammes de déploiement permettent de capturer la topologie du système sur laquelle est déployée l application Permet de définir La distribution des composants De pré-identifier les éventuels goulots d étranglement 69 UML : Deployment diagram (2) serveur primaire serveur données imprimante réseau serveur serveur serveur 70 Informatique, réseaux, systèmes, multimédia / 35

36 CAMOS CNAM UML de base et ses extensions Comme nous l avons vu, UML comporte 9 types de diagrammes différents UML 2 en aura Ces diagrammes ont TOUS leur utilité Cependant, certains peuvent être inutiles dans un projet UML comporte également un ensemble de fonctionnalités supplémentaires dans la notation Stéréotypes de classe : permettent de montrer l appartenance à un modèle «technique» Profils : extensions persistance, temps-réel, etc. qui permettent de définir une sémantique et donc de réaliser des vérifications 71 Points forts d UML Du fait de sa standardisation par l OMG, la méthode est supportée par de nombreux outils. Grâce à cela, une course aux fonctionnalités s est instaurée Prise en compte des bases de données existantes Génération automatique de squelettes de code Possibilité d importer ou d exporter dans un vocabulaire XML 72 Informatique, réseaux, systèmes, multimédia / 36

37 CAMOS CNAM Analyse et conception La réalisation de systèmes et de programmes orientés objet diffère du mode de réalisation suivi par l analyse fonctionnelle et technique Vrai pour l analyse Vrai pour la conception Vrai pour l évolution d un projet La gestion de projet «à la MERISE» ne convient pas tout à fait 73 Méthodologies Modèle en spirale : un «waterfall itératif» Incrémentations successives, les premières pouvant être «purement» formelles Un des meilleurs modèles : Marche tout aussi bien pour de petits projets que pour les grands Permet le prototypage durant toutes les phases : le logiciel n est pas fini mais fait «comme si» Besoin important de management et d analyse du risque 74 Informatique, réseaux, systèmes, multimédia / 37

38 CAMOS CNAM Méthodologies (2) Modèle en spirale planning analyse de risque discussion avec l utilisateur ingénierie 75 évaluation par l utilisateur développement et déploiement Méthodologies (3) Une méthodologie ne suffit pas! Les méthodologies sont exposées dans les livres, Elles sont toujours assez abstraites Elles sont assez peu pratiques Elles sont presque toujours ressenties comme imposées par ceux qui les utilisent Elles ne tiennent généralement pas compte de la taille du projet («one size fit all») 76 Informatique, réseaux, systèmes, multimédia / 38

39 CAMOS CNAM Processus Besoin d un processus de développement Ils sont mis en place en fonction de l existant de l organisation Ils donnent des guides clairs et utilisables car ils sont adaptés à la réalité quotidienne d une entreprise Ils permettent à chacun d améliorer sa manière de travailler et d interagir 77 Processus (2) RUP, Rational Unified Process, provient de chez Rational Il est basé sur l Objectory Process de Jacobson, modèle assez académique Il est intéressant et pleins de bonnes idées Beaucoup des outils le supportant sont vendus par Rational 78 Informatique, réseaux, systèmes, multimédia / 39

40 CAMOS CNAM Processus (3) 4 grandes phases : Étude : définition des besoins Élaboration : besoins détaillés, analyse et design de haut niveau pour créer une architecture de départ et un planning Construction : plusieurs itérations pour produire un logiciel testé et répondant aux besoins Transition : test système et formation des utilisateurs 79 Processus (4) Etude Elaboration Construction Transition Plannification Analyse Architecture Design Implémentation Intégration Test / Acceptation 80 Itération Préliminaire Itération #1 Itération #2 Itération #n+1 Itération # Itération #m Itération #m+1 Itération #m+2 Informatique, réseaux, systèmes, multimédia / 40

41 CAMOS CNAM Processus (5) Il existe une autre méthodologie de gestion de projet (suite de processus) : PMBOK Project Management Body Of Knowledge Un document décrivant PMBOK a été rédigé par le PMI, Project Management Institute Le PMBOK 2000 se trouve assez facilement sur Internet... Décrit les processus, la gestion du scope, du planning, des coûts, des risques, UML, RUP et après... UML, et l approche orientée objet en général, prônent une approche composant Cette approche présente des lacunes, partiellement résolues par l approche orientée aspect (AOP) RUP peut entraîner des lourdeurs de gestion de projet : il faut parfois des approches légères Extreme Programming (XP), Agile Par contre, le senior management veut parfois avoir une vision globale CMM, ITIL, COBIT, SPICE, Zachman 82 Informatique, réseaux, systèmes, multimédia / 41

42 CAMOS CNAM Programmation Orientée Aspects La décomposition d un système en composants distincts n est pas remise en cause Mais cette approche n est pas parfaite du point de vue technique Les études initiales (Xerox, où Smalltalk est né) ayant conduit à l AOP ont prouvées que la répétition de code technique dans les composants alourdissait beaucoup le programme final Le résultat est très lourd et lent bien que «assez» facile à maintenir Le programme équivalent optimisé peut être beaucoup plus rapide mais beaucoup plus dur à maintenir Il est donc nécessaire de trouver un compromis 83 Programmation Orientée Aspects (2) 84 Le code technique doit être séparé des fonctions métier d un système Le code technique concerne la persistance, la sécurité, l affichage; bref, tout le code optimisable Sur l exemple initial (système de traitement d images noir et blanc, Xerox!) : Version composants (facile à comprendre et inefficace) : lignes de code Version optimisée (perforante mais difficile à lire) : 768 lignes de code Version AOP : 1039 lignes de code Informatique, réseaux, systèmes, multimédia / 42

43 CAMOS CNAM Programmation Orientée Aspects (3) Dans l approche orientée aspect, il faut donc identifier les aspects et les placer dans des «procédures» adhoc après les avoir sortis du code (pas forcément dans le même langage de programmation Une fois les aspects isolés, on réintroduit les aspects dans le code compilé par «tissage» ou «entrelacement» Étape d «aspect weaving» Il existe plusieurs implémentations disponibles en Java : AspectJ, AspectWerkz, Spring, dynaaop 85 Programmation Orientée Aspects (4) Besoins exprimés Logique métier Persistance Entrelaceur Identification des aspects Sécurité Logging Décomposition des aspects Recomposition des aspects 86 Informatique, réseaux, systèmes, multimédia / 43

44 CAMOS CNAM Lourdeurs Les normes de modélisation, les processus de gestion de projet, l amélioration des habitudes de travail par l intermédiaire de références telles que RUP ou d autres processus Tout ceci a un prix et demande du temps Tout ceci est lourd et difficile Tout ceci nécessite l adhésion de tous Une fois en place, de telles méthodes se révèlent gagnantes mais : 87 Lourdeurs (2) Tout ceci en vaut-il toujours «la chandelle»? Une petite structure de développement ou une petite société peut-elle s autoriser de mettre en place de telles procédures, administrativement lourde? Certains ont eu une réaction négative et ont eu une volonté d allègement des processus 88 Informatique, réseaux, systèmes, multimédia / 44

45 CAMOS CNAM extreme Programming XP est une méthodologie de développement objet allégée d un point de vue administratif Il faut considérer XP comme une organisation de gestion de projet applicable: Aux petites équipes Aux équipes effectuant un travail assez autarcique et ayant donc relativement peu d interconnections avec des équipes extérieures Aux équipes dont les travaux seront peu réutilisés par l extérieur et où différents niveaux de documentation ne sont pas nécessaires 89 extreme Programming (2) 90 Quatre valeurs mises en exergue : Communication : Travail en groupe (2 programmeurs pour 1 poste) Simplicité : Toujours faire au plus simple Temps de réponse : Répondre rapidement aux questions Courage : Pour se remettre en question après les choix Activités de base : Codage, pour la communication et l apprentissage Tests, automatisés, unitaires et système, «tout ce qui ne peut pas être mesuré n existe pas» ( ) Écoute, des autres développeurs, des clients Design, tant du système à développer que de l équipe qui le développe Informatique, réseaux, systèmes, multimédia / 45

46 CAMOS CNAM Agile Model Driven Development Ni plus ni moins qu un concurrent de XP Valeurs : communication, courage, dialogue, humilité et simplicité Élabore sur XP en prônant : l usage des outils les plus simples Le refus de la course à la technologie avec l introduction répétée des dernières nouveautés Le travail à l instinct, en respectant les modèles objets Plus lourd ou plus léger que l air? Les approches de type XP ou AGILE ne satisfont pas un point pourtant critique à la survie d un projet informatique : le client, ou le manager, ne comprend rien de ce qui se passe Il faut donc des méthodes et des outils pour le rassurer en lui présentant des informations qu il maîtrise Ce sont principalement des modèles abstraits de management et des outils d audit et de contrôle 92 Informatique, réseaux, systèmes, multimédia / 46

47 CAMOS CNAM CMM, Capability Maturity Model CMM est sponsorisé par le Department Of Defense et est géré par le Software Engineering Institute du CMU Prône une approche progressive à la gestion du système d information avec l identification de 5 niveaux de maturité Ces niveaux requiert l existence de processus Pour être validé de CMM 1 à CMM 5, il faut faire venir des auditeurs, qui donnent la note! 93 CMM, Capability Maturity Model (2) Les niveaux CMM 1, initial : l organisation reconnaît qu il y a un problème. Pas de processus standardisés, tout est ad-hoc et désorganisé. CMM 2, repeatable : des processus sont identifiés mais pas définis, les individus les suivent approximativement et commettent des erreurs. CMM 3, defined : les processus sont définis et standardisés mais les individus les suivent approximativement. CMM 4, managed : les processus sont suivis par les individus et peuvent être monitorés. Ils sont améliorés constamment. CMM 5, optimised : les processus ont été améliorés jusqu à atteindre un grand niveau d efficacité, intégrant les best practices. Le rôle de l IT est ici déterminant 94 Informatique, réseaux, systèmes, multimédia / 47

48 CAMOS CNAM ITIL : IT Information Library ITIL permet de faire le management IT de manière structurée ITIL couvre : Availability Management, Capacity Management, Change Management, Configuration Management, Financial Management, Incident Management, IT Service Continuity Management, Problem Management, Release Management, Security Management, Service Level Management, Service/Help Desk Bref tout ce que vous voudriez avoir au jour le jour COBIT : Control OBjectives for Information and related Technology Il s agit d une norme d audit des SI définit par l ISACA, Information System Audit and Control Association COBIT définit 4 grands domaines IT à contrôler au travers de 34 processus et de 318 objectifs de contrôle, des KGI (Key Goal Indicators), des KPI (Key Performance Indicators) et des CSF (critical Success Factor) 96 Informatique, réseaux, systèmes, multimédia / 48

49 CAMOS CNAM COBIT (2) M1 Monitor the processes M2 Assess internal control adequacy M3 Obtain independent assurance M4 Provide for independent audit 97 Business Objectives DS1 Define and manage service levels DS2 Manage third-party services DS3 Manage performance and capacity DS4 Ensure continuous service DS5 Ensure systems security DS6 Identify and allocate costs DS7 Educate and train users DS8 Assist and advise customers DS9 Manage the configuration DS10 Manage problems and incidents DS11 Manage data DS12 Manage facilities DS13 Manage operations MONITORING DELIVERY AND SUPPORT IT RESOURCES INFORMATION effectiveness efficiency confidentiality integrity availability compliance reliability data application systems technology facilities people PLANNING AND ORGANISATION AQUISITION AND IMPLEMENTATION PO1 Define a strategic IT Plan PO2 Define the information architecture PO3 Determine the technological direction PO4 Define the IT organisation & relationships PO5 Manage the IT investment PO6 Communicate mgmnt aims & direction PO7 Manage human resources PO8 Ensure compliance with external req. PO9 Assess risks PO10 Manage Projects PO11 Manage Quality AI1 Identify automated solutions AI2 Acquire and maintain application software AI3 Acquire and maintain technology infrastructure AI4 Develop and maintain procedures AI5 Install and accredit systems AI6 Manage changes SPICE : Software Process Improvement and Capability determination Une norme établie sous les auspices de l ISO Identifie des pratiques (de base et génériques) et des processus Relation client Ingénierie Management Organisation Support SPICE définit également 6 niveaux de «capacité» similaires aux 5 niveaux de CMM 98 Informatique, réseaux, systèmes, multimédia / 49

50 CAMOS CNAM Zachman Zachman (de Monsieur Zachman) est le summum de la vue synthétique Une entreprise, ou un système d information de manière plus limitative, est vue à travers une matrice Chaque élément de la matrice permet d identifier un sujet qui nécessitera des études, des orientations, un financement et... un contrôle 99 Zachman (2) What How Where Who When Why Scope = Planner s view Contextual Enterprise Model = Owner s view Conceptual System Model = Designer s view Logical Technology Model = Builder s view Physical Detailed representation = Subcontractor s view As Built Functioning Enterprise = User's view Functioning 100 Informatique, réseaux, systèmes, multimédia / 50

51 CAMOS CNAM Questions / Remarques 101 Informatique, réseaux, systèmes, multimédia / 51