Analyse et conception de systèmes d information

Transcription

1 Analyse et conception de systèmes d information Présentation réalisée par P.-A. Sunier Professeur à la HE-Arc de Neuchâtel Juin 2005 [SJB-02] Chapitre 3 1

2 Références Ce document a été reproduit de Satzinger : Analyse et Conception de Systèmes d'information, 2ième édition, 2004, ISBN avec la permission des Éditions Reynald Goulet inc. Àl'usage exclusif du Professeur Pierre-André Sunier. Tout autre usage est interdit. [SJB-02] Juin 2005 [SJB-02] Chapitre 3 2

3 Utilisation de la présentation Cette présentation est destinée à mon enseignement exclusif selon la permission de l éditeur, les Éditions Reynald Goulet inc. Tout utilisation ou reproduction de cette présentation doit être demandée auprès de l éditeur P.-A. Sunier Juin 2005 [SJB-02] Chapitre 3 3

4 Chapitre 3 Les approches du développement de systèmes Juin 2005 [SJB-02] Chapitre 3 4

5 [p72] Objectifs Différences entre un modèle, un outil, une technique et une méthodologie Approche classique et approche orientée objets Fluctuations du CCDS Tendances actuelles: modèle en spirale, programmation extrême et processus unifié (UP) Ateliers de génie logiciel (AGL) Juin 2005 [SJB-02] Chapitre 3 5

6 [p72] Plan 1. Méthodologie, modèles, outils et techniques 2. Deux approches du développement de systèmes 3. Variantes du cycle chronologique de développement des systèmes 4. Tendances actuelles dans le développement 5. Outils du développement de systèmes Juin 2005 [SJB-02] Chapitre 3 6

7 [p73-74] Survol Deux grandes approches courantes au développement de systèmes d affaires: L approche classique Développement structuré Techniques de l information L approche orientée objets Les deux approches utilisent le CCDS comme cadre de gestion des projets Voir notre projet de recherche [ISNet-43] «Atelier de génie logiciel - Approche fonctionnelle ou orienté objets» Notre terminologie «Approche fonctionnelle» correspond à l approche classique de l ouvrage de Satzinger Juin 2005 [SJB-02] Chapitre 3 7

8 [p77] 1 Méthodologie, modèles, outils et techniques Une méthodologie inclut un ensemble de techniques dont on se sert pour réaliser des activités au sein de chacune des phases du CCDS. Ces activités comprennent la complétion de divers modèles les développeurs utilisent des outils logiciels pour les aider dans leur tâche. Méthodologie Techniques Modèles Outils Juin 2005 [SJB-02] Chapitre 3 8

9 [p74] Méthodologie Démarche complète, incluant des modèles, des outils et des techniques à suivre pour réaliser chaque activité dans le cycle chronologique de développement d un système. Juin 2005 [SJB-02] Chapitre 3 9

10 [p74] Modèles Représentation d un aspect important quelconque du monde réel. Quelques modèles: Ordinogramme Modèle entités-associations (E-A) Cas d utilisation PERT & Gantt Organigramme Juin 2005 [SJB-02] Chapitre 3 10

11 Modélisation ESNIG 5.4 Modélisation [Guinier-92] La modélisation n est qu une représentation d un système réel quelle qu en soit sa forme: physique, graphique, mathématique, verbale ou mentale. Cette représentation intelligible est indispensable pour assurer la compréhension de systèmes naturels complexes. 15/03/2004 SSI Juin 2005 [SJB-02] Chapitre 3 11

12 Objets immatériels ESNIG 3.2 Objets immatériels [Bouchy] L une des difficultés majeures de l ingénierie des systèmes d information est que lesdits systèmes sont des objets plus ou moins immatériel. Personne n a jamais vu un système d information et ce système n est visible qu à partir de ses représentations: documentation, modèles, etc. 15/03/2004 SSI Juin 2005 [SJB-02] Chapitre 3 12

13 [p75-76] Outils Outil Support logiciel qui aide à créer des modèles ou d autres composantes nécessaires au projet. Outil CASE Outil de génie logiciel assisté par ordinateur (AGL - Atelier de génie logiciel) conçu pour aider l analyste système à réaliser des tâches de développement Juin 2005 [SJB-02] Chapitre 3 13

14 [p76] Techniques Ensemble de lignes directrices qui aident l analyste à réaliser une activité ou une tâche de développement de système. Quelques techniques: Gestion de projets Interview des utilisateurs Modélisation des données Programmation structurée Analyse et conception orienté objets Juin 2005 [SJB-02] Chapitre 3 14

15 [p78-84] 2 Deux approches du développement de systèmes L approche classique L approche classique comprend de nombreuses variantes axées sur les techniques utilisées pour développer des systèmes d information au moyen de la programmation structurée et modulaire. Développement structuré de système Techniques de l information (TI) L approche orientée objets L approche orientée objets considère un système d information comme une collection d objets interdépendants qui fonctionnent de concert pour exécuter des tâches. Juin 2005 [SJB-02] Chapitre 3 15

16 [p78] Développement structuré de système (a) Approche structurée Méthode de développement d un système utilisant des techniques d analyse structurée, de conception structurée et de programmation structurée. SADT - Structure Analys and Design Technique Juin 2005 [SJB-02] Chapitre 3 16

17 [p78] Développement structuré de système (b) ~ Programmation structurée Amélioration de la qualité des programmes ~ Conception structurée Intégration de programmes ~ Analyse structurée Clarifier les spécifications du système Juin 2005 [SJB-02] Chapitre 3 17

18 [p79] Programmation structurée (a) Programme structuré Programme ou module de programme ayant un début et une fin, et dans lequel chaque étape de son exécution est faite de structures séquentielles, décisionnelles ou répétitives. Juin 2005 [SJB-02] Chapitre 3 18

19 [p79] Programmation structurée (b) Programmation descendante Division de programmes complexes en une hiérarchie de modules de programmes. Juin 2005 [SJB-02] Chapitre 3 19

20 [p80] Conception structurée Technique qui fournit des lignes directrices permettant de décider de quoi doit être composé l ensemble de programmes, ce que chaque programme doit faire et comment les programmes doivent être organisés hiérarchiquement. Les modules et les arrangements modulaires sont représentés graphiquement au moyen d un modèle nommé structogramme. Juin 2005 [SJB-02] Chapitre 3 20

21 [p80] Structogramme Juin 2005 [SJB-02] Chapitre 3 21

22 [p81] Analyse structurée Technique qui aide le développeur à définir ce que le système doit faire (les spécifications de traitement), les données que le système doit stocker et utiliser (les spécifications de données), quelles entrées et sorties sont requises et comment les fonctions travaillent ensemble pour exécuter des tâches. Juin 2005 [SJB-02] Chapitre 3 22

23 [p81] Modèles graphiques Diagramme de flux de données (DFD) «Modèle» graphique montrant les entrées, les processus, le stockage et les sorties d un système réalisé en analyse structurée. Diagramme entité-association (EA) «Modèle» graphique des données requises par un système, incluant les éléments sur lesquels de l information est stockée et les relations entre eux. Ce type de diagramme est produit en analyse structurée et en techniques de l information. Juin 2005 [SJB-02] Chapitre 3 23

24 [p82] Diagramme de flux de données Juin 2005 [SJB-02] Chapitre 3 24

25 [p82] Diagramme entité-association Juin 2005 [SJB-02] Chapitre 3 25

26 [p83] De l analyse structurée à la programmation structurée Analyse structurée Événements Diagrammes de flux de données Diagrammes entitéassociation Conception structurée Structogrammes qui définissent les modules de programme à partir des diagrammes de flux de données Programmation structurée Programmer chaque module au moyen de construits de programmation structurée Juin 2005 [SJB-02] Chapitre 3 26

27 [p83] Techniques de l information (TI) Méthode de développement de système classique centrée sur la planification stratégique, la modélisation des données et les outils automatisés. Elle est considérée être plus rigoureuse et complète que l approche structurée. Juin 2005 [SJB-02] Chapitre 3 27

28 [p83-84] Eléments clés des TI Le type de données nécessaire pour diriger une entreprise change très peu avec le temps, à l opposé des processus de collecte des données qui eux changent souvent. L outil CASE aide à automatiser la plus grande partie du travail Dans de nombreux cas, l outil CASE peut automatiquement générer un code final du programme. Juin 2005 [SJB-02] Chapitre 3 28

29 [p84] Approche «classique» L approche des techniques de l information (TI) perfectionne de nombreux concepts de l approche structurée dans une méthodologie rigoureuse et complète. Les deux approches se fondent en une approche dite «classique» Juin 2005 [SJB-02] Chapitre 3 29

30 [p84] Approche orientée objets Approche de développement qui voit un système d information comme une collection d objets interdépendants qui fonctionnent de concert pour exécuter des tâches. Objet Élément du système informatique qui peut répondre à des messages. Juin 2005 [SJB-02] Chapitre 3 30

31 [p84] Analyse orientée objets (OOA) Définir tous les types d objets qui exécutent le travail dans le système et montrer comment ces objets interagissent pour exécuter des tâches. Juin 2005 [SJB-02] Chapitre 3 31

32 [p84] Conception orientée objets (OOD) Définir tous les types d objets nécessaires pour communiquer avec les utilisateurs et les périphériques du système et raffiner la définition de chaque type d objet de façon à pouvoir l implanter dans un langage ou un environnement spécifique. Juin 2005 [SJB-02] Chapitre 3 32

33 [p84] Programmation orientée objets (OOP) Écrire des instructions dans un langage de programmation pour définir ce que fait chaque type d objets, y compris les messages que les objets se transmettent les uns aux autres. Juin 2005 [SJB-02] Chapitre 3 33

34 [p85] Diagramme de classe «Modèle» graphique utilisé dans l approche orientée objets pour montrer toutes les classes d objets existants dans un système. Juin 2005 [SJB-02] Chapitre 3 34

35 [p86] Complémentarité des approches «classique» et «orienté objets» De nombreux systèmes développés aujourd hui combinent les technologies classiques et orientées objets. Certains environnements de développement intégré (IDE) combinent aussi les technologies classiques et orientées objets dans le même outil. Par exemple, on utilise souvent la programmation orientée objets pour l interface utilisateur et la programmation procédurale pour le reste. Juin 2005 [SJB-02] Chapitre 3 35

36 [p86] 3 Variantes du CCDS Le cycle de vie du développement de systèmes présentés dans ce livre est un cycle générique. Nous insistons toutefois sur le fait que les futurs analystes en rencontreront de nombreuses variantes au cours de leur carrière. Variantes de noms de phases Variantes fondées sur l itération Variantes fondées sur la prépondérance de l humain Variantes fondées sur la rapidité de développement Juin 2005 [SJB-02] Chapitre 3 36

37 [p87] Variantes de noms de phases (a) Phase de planification du projet Spécifications de planification figées Phase d analyse Spécifications d analyse figées Ce modèle en cascade est fondé sur des projets concrets d ingénierie - construction de ponts, de gratte-ciel, voire de navettes spatiales- qui se déroulent dans un ordre précis. Phase de conception Phase de mise en oeuvre Spécifications de conception figées Système fini livré tel que spécifié Juin 2005 [SJB-02] Chapitre 3 37

38 [p88] Variantes de noms de phases (b) Exemple primitif de CCDS Techniques de l information Rational Unified Process CCDS avec noms d activités dans les phases Phase de planification Phase d analyse Phase de conception Étude de faisabilité Examen du système Analyse Conception Planification de la stratégie d information Analyse du domaine de la gestion Conception du système Inception Élaboration Organiser le projet Étudier la faisabilité Étudier et analyser le système actuel Modéliser et prioriser les exigences Produire des options et proposer la meilleure solution Phase de mise en oeuvre Phase de support Mise en oeuvre Révision et maintenance Conception technique Construction Transition Production Construction Transition Concevoir le système Obtenir les matériels et logiciels nécessaires Construire et tester le nouveau système Installer et exploiter le nouveau système Juin 2005 [SJB-02] Chapitre 3 38

39 [p88-89] Variantes fondées sur l itération Construction incrémentale Approche de développement qui réalise des parties d un système en une ou plusieurs itérations et les met en fonction pour les utilisateurs. Analyse Conception Analyse Mise en oeuvre Conception Mise en oeuvre Juin 2005 [SJB-02] Chapitre 3 39

40 [p91] 4 Tendances actuelles dans le développement Risque et modèle en spirale Programmation extrême (XP) Rational Unified Process (RUP) Juin 2005 [SJB-02] Chapitre 3 40

41 [p91] Risque et modèle en spirale le modèle en spirale recommande d identifier les facteurs de risques à étudier et atténuer. La première itération devrait porter sur la partie du système qui semble avoir le facteur de risque le plus élevé. Juin 2005 [SJB-02] Chapitre 3 41

42 [p92] Programmation extrême (XP) De bien des façons, la programmation extrême est très semblable aux autres approches itératives et incrémentales Elle exige que toute la programmation soit réalisée par des équipes de deux programmeurs chacune, travaillant ensemble à une station de travail lors de l écriture et des essais du code. Juin 2005 [SJB-02] Chapitre 3 42

43 [p93] Rational Unified Process (RUP) Le RUP renforce six des pratiques modernes de développement logiciel communes à de nombreuses méthodologie de développement: Le développement itératif La définition et la gestion des besoins L utilisation d architectures à base de composants La modélisation visuelle La vérification de la qualité La gestion des changements Juin 2005 [SJB-02] Chapitre 3 43

44 [p94] 5 Outils du développement de systèmes Quelle que soit la méthodologie adoptée, il est indispensable d utiliser des outils automatisés pour améliorer la vitesse et la qualité du travail de développement chaque fois que cela est possible. Outils CASE Microsoft Visio Oracle Designer Rational Rose Juin 2005 [SJB-02] Chapitre 3 44

45 [p94] Outils CASE (a) Un outil CASE, appelé aussi atelier de génie logiciel (AGL) en français, contient une base de données d information sur le projet. Cette base, que l on nomme référentiel, stocke des informations sur le système, dont des modèles, des descriptions et des références servant à lier les modèles ensemble. Juin 2005 [SJB-02] Chapitre 3 45

46 [p95] Outils CASE (b) Générateur de diagrammes Générateur de conception Outil de dessins Générateur de code Ingénierie inverse Référentiel de l outil CASE Générateur de base de données Contrôle des erreurs Prototypage Sécurité & gestion des version Requête et générateur de rapports Juin 2005 [SJB-02] Chapitre 3 46

47 [p95] Outils CASE (c) UpperCASE (supérieurs) Analyse Conception (haut niveau) - Modèles conceptuels LowerCASE (inférieurs) Conception (bas niveau) - Modèles logiques Génération de code - Modèles physiques ICASE (intégrés) Soutien pour la totalité du cycle de vie du développement Juin 2005 [SJB-02] Chapitre 3 47

48 [p95] Outils CASE (d) Désignation courante des outils CASE par les fournisseurs: Outils de modélisation visuelle; Outil intégré de développement d applications Outils d ingénierie aller-retour Juin 2005 [SJB-02] Chapitre 3 48

49 [p95] Microsoft Visio (a) Visio est accompagné d une collection de gabarits dessinés comprenant les symboles courants Même si les gabarits fournissent un référentiel restreint pour le stockage des définitions et descriptions d éléments de diagramme, Visio n offre cependant pas de référentiel complet pour un projet de développement de systèmes. Juin 2005 [SJB-02] Chapitre 3 49

50 [p95] Microsoft Visio (b) Uniquement un gabarit de symboles pour le dessin d ordinogramme. Juin 2005 [SJB-02] Chapitre 3 50

51 [p95] Microsoft Visio (c) Un gabarit de symboles et un référentiel minimal pour la solution UML. Juin 2005 [SJB-02] Chapitre 3 51

52 [p96] Oracle Designer (a) Oracle Designer comprend un référentiel complet ainsi que des fonctions de production de diagrammes et de génération de code. Ce produit est un exemple d outils CASE intégré supportant l approche classique du développement de systèmes. Juin 2005 [SJB-02] Chapitre 3 52

53 [p97] Oracle Designer (b) Juin 2005 [SJB-02] Chapitre 3 53

54 [p96] Rational Rose (a) Rational Rose, un produit de Rational software (IBM), est conçu spécifiquement pour l approche orienté objets. On y réfère le plus souvent comme un outil de modélisation visuelle plutôt que comme un outil CASE. Juin 2005 [SJB-02] Chapitre 3 54

55 [p97-98] Rational Rose (b) Juin 2005 [SJB-02] Chapitre 3 55