Introduction aux méthodes d analyse et de modélisation

Transcription

1 Introduction aux méthodes d analyse et de modélisation Emmanuel ADAM Institut des Sciences et Techniques de Valenciennes

2 Le Génie Logiciel, Pourquoi? Apparu en 1968 pour construire des logiciels fiables, respecter les délais, travailler en équipe, décomposer la complexité, assurer la qualité, permettre la réutilisation,...

3 Le Génie Logiciel pour des problèmes complexes Ajouter un programmeur sans organisation ne fait que ralentir la mise en œuvre du projet. Problème de nb de communications : (Loi de Brooks) Problème de communication (compréhension) malentendus, erreurs d interprétation,...

4 Quelques définitions le génie logiciel est l'art de spécifier, de concevoir, de réaliser, et de faire évoluer, avec des moyens et dans des délais raisonnables, des programmes, des documentations et des procédures de qualité en vu d'utiliser un ordinateur pour résoudre certains problèmes. [MC Gaudel & co, 96] Le génie logiciel se caractérise par une approche rigoureuse et systématique de la construction de logiciels ne pouvant être maîtrisés par une seule personne. [JP Fournier 00]

5 Les étapes de développement 1 - Analyse des besoins 2 - Spécification 3 - Conception 4 - Codage 40% 40% 5 - Intégration 20% 6 - Mise en œuvre 7 - Exploitation - Maintenance

6 Etude de faisabilité Type d analyse Analyse des besoins orientée processus, orientée rôle, orientée données Techniques d acquisitions entretiens, observations, questionnaires,...

7 Spécification (inspiré de IEEE Std 830 & [Jaulent 90]) Première description du futur système (le quoi, Ce qu il doit faire) Les fonctions générales, Les caractéristiques des utilisateurs, Contraintes (développement, exploitation, maintenance), Interfaces (homme-machine, logiciel/matériel, logiciel/logiciel), Objets, entités constituant le système. Garder une trace des différentes spécifications (justification) Ne pas oublier le glossaire! Dans une annexe, placer les références aux documents utilisés Ne pas faire de choix d implémentation à ce niveau...

8 Conception Augmenter la spécification pour se rapprocher de l implémentation, du codage Conception Architecturale Décomposer le système en sous-systèmes Définir les interfaces, les liens entres les composants Conception détaillée Détailler le fonctionnement des composants définir quelques algos, la représentation des données,...

9 Le codage et l intégration Ne représente que 15 à 20% du temps dans un projet complexe et bien structuré Ne pas oublier de gérer les différentes versions des composants L intégration nécessite une bonne définition préalables des interfaces entre composants

10 Les langages de programmation (1/2) Programmation impérative programmation structurée, basé sur des algos, ex : fortran, pascal, c, ADA, Programmation applicative programmation fonctionnelle et déclarative, programmation objet ex : Lisp, Caml, Smalltalk, C++, Java,...

11 Les langages de programmation (2/2) Programmation logique issue de l IA ex : prolog, lisp, scheme Programmation orientée agent? Agent = objet autonome communicant

12 Mise en œuvre Porter le logiciel sur le système client Vérifier l adéquation avec le système visé Validation De manière générale, il faut tenter de valider à tout niveau (spécifications & conceptions) test unitaires (composants) test d intégration (logiciel complet) test système (logiciel sur site)

13 Les AGL: des outils d aide AGL = Atelier de Génie Logiciel Atelier de modélisation Une méthode n existe que si elle est supportée par un outil Atelier de développement facilite la programmation (Visual Basic, Visual C++,...)

14 Atelier de modélisation

15 Atelier de développement éditeur de code compilateur debugger éditeur d'interfaces homme-machine

16 Les différents modèles de développement Enchaînement des étapes Le modèle cascade Le modèle en V Le modèle évolutif Le modèle spirale

17 Les différents modèles de développement Le modèle cascade Faisabilité, cahier des charges Spécification Conception préliminaire Conception détaillée Codage Intégration Installation Exploitation & maintenance

18 Les différents modèles de développement Le modèle en V Faisabilité, cahier des charges Installation et tests systèmes Spécification Test d acceptation Conception préliminaire Intégration et test d intégration Conception détaillée Test unitaire Programmation

19 Les différents modèles de développement Le modèle incrémental (évolutif) Faisabilité, cahier des charges Spécification Validation Itération 2 Conception Validation Conception détaillée Vérification Conception détaillée Vérification Vérification Itération 1 Codage Tests unitaires Codage Tests unitaires Intégration Intégration Vérification Mise en œuvre Mise en œuvre Test Exploitation, Maintenance Revalidation

20 Les différents modèles de développement Le modèle spirale analyse de risque analyse de risque détermination des objectifs, des alternatives, des contraintes plan d'intégration et de test plan général du projet plan de développement analyse de risque analyse de risque prototype1 prototype2 concepts d'opération Validation des besoins validation de la conception Vérification Mise en oeuvre prototype3 prototype opérationnel simulation, modélisation, benchmark Test Système conception détaillée Programmation et test unitaires Intégration et test

21 Les formalismes Représenter le système (initial ou visé) 4 types de modèle : modèle des données modèle des flux de données modèle de traitement modèle dynamique

22 Quelques méthodes d analyse, de spécification et de conception MERISE : orientée BdD OMT : orientée objet UML OSSAD : organisation CISAD : coopération vue globale du système SADT : méthode structurée MKSM : gestion des connaissances

23 MERISE Orientée Base de données Cycle cascade Approche descendante Modélisation : données & activités, traitements Particularités : modèles conceptuels, organisationnels, logique et physique

24 MERISE Modèle Conceptuel de Communication

25 MERISE Modèle Conceptuel des Données : Modèle Entité-Relation

26 MERISE Modèle Organisationnel des traitements

27 OMT : Object Modeling Technique Orientée Objet Cycle spirale Approche descendante Modélisation : données, dynamique, traitements Particularités : Méthode objet utilisée dans qqs entreprises avant l apparition d UML

28 OMT Modèle de données Dossier principal Dossier de circulation (DdC) - n de dossier, - noms inventeurs, - mots clés Avis de brevetabilité (Avis) - Référence invention - avis correspond à Dosssier Technique (DT) - Référence invention - Domaine de l'invention - Etat de l'art - Caractéristiques de l'invention correspond à Projet de demande de brevet (Prj.Dmd) - Référence invention, - Résumé de l'invention, - Etat de l'art, - Description de l'invention

29 OMT Diagramme d événements

30 OMT Diagramme d état

31 OMT Diagramme de flux de données

32 UML : Unified Modelling Language Langage, fusion des différentes méthodes orientées objets supporté par des outils +, cf. prochains cours

33 UML Cas d utilisation

34 UML Scénario

35 UML Diagramme de séquence

36 SADT : Structured Analysis and Design Technique Méthode structurée Cycle cascade Approche descendante Modélisation : données, activités Particularités : Actigrammes fortement utilisés

37 SADT Actigrammes

38 SADT Datagrammes donner un avis chercher constituer le Dossier Technique (acteur 5) avis de brevetabilité, recherche Dossier Technique rédiger projet de demande (acteur 4) Projet de demande remplir le dossier de circulation (acteur 4) dossier de circulation vérifer (acteur 2) dossier vérifié lire (acteur 5) dossier lu compléter le dossier (acteur 3, acteur 4) dossier complété revérifier (acteur 2) Dossier revérifié créer dossier principal (acteur 6) dossier principal vérifier (acteur 1) dossier principal vérifié

39 OSSAD : Office Support System Analysis and Design Méthode pour modélisation des organisations Cycle V Approche descendante Modélisation : activités, traitement, données Particularités : 8 formalismes proposés!

40 OSSAD Diagramme A1 Relations entre les fonctions de l organisme parapher créer et remplir le dossier de circulation Dossier de circulation Avis de brevetabilité constituer le dossier technique Dossier Technique rediger et mettre en forme le projet de demande Projet de demande compléter copier et placer le projet dans le dossier principal Dossier principal

41 OSSAD Diagramme A2 Matrice Activité/Rôle Acteur 6 Acteur 5 Acteur 4 Acteur 3 Acteur 2 Acteur 1 Constitution du dossier Rédaction du projet de demande Création du dossier de circulation Création du dossier principal Modification du dossier de circulation Modification du texte du brevet Modification et envoi du dossier principal

42 OSSAD Exemple de Diagramme D1 : Relations entre rôles acteur 2 Dossier de Circulation acteur 4 Dossier Technique acteur 5 Dossier de Circulation acteur 3 demande n Dossier de Circulation n dossier Dossier de Circulation Dossier de Circulation acteur 6 Dossier de Circulation Dossier Principal acteur 1

43 OSSAD Exemple de diagramme D2 : Relations entre procédures Dossier Technique Rôle 5 Projet de demande Rédaction du projet de demande Création du dossier de circulation dossier de Circulation dossier de Circulation Création du dossier principal dossier de Circulation dossier principal Modification du dossier de circulation Modification et Classement du dossier pricipal dossier de Circulation

44 OSSAD Fiche représentant une tâche Nom de la tâche + (Id) : (Decription) : Fiche Tâche remplir Dossier de Circulation par acteur 4 (Ta402) Liens (arborescence) : / asc. (Procédure) \ desc. (Opérations) Relations avec tâches : par ressources entrantes par ressources sortantes Création du dossier de Circulation (Pr003) Demander n dossier (Op402), Remplir (Op403) Rédaction du Projet / Acteur 4, Création du dossier principal / Acteur 6 Projet de demande (Doc001) Farde de Circulation (Doc002)

45 OSSAD Fiche représentant une donnée Fiche Ressource Nom de la ressource + (Id) : (Decription) : Projet de demande (doc001) projet de demande de dépôt de brevet Liens (arborescence) : / asc. (Super Ress.) \ desc. (Rubriques) néant référence invention, résumé, état de l'art, description de l'invention Relations avec opérations : Origine : Destination : Rédiger le projet de demande (Op451) Mettre en forme le projet (Op452)

46 OSSAD Diagramme d une procédure

47 CISAD : Cooperative Information System Analysis and design Étend OSSAD en permettant la prise en compte de la coopération

48 CISAD Exemple de modèle descriptif de rôle adapté (type D1) Plan B Chef de service dossier Conditions Agent service prêt(1) Agent service prêt(2) demande Offre Client(1) Client(2) Plan A Plan C

49 CISAD Matrice de Grudin pour la modélisation des communications site 1 site... site imprévisible rôle A rôle B... rôle A rôle B... rôle A rôle B... site 1... site imprévisible rôle A rôle B... rôle A rôle B... rôle A rôle B... Synchrone Asynchrone et moment prévisible Asynchrone et moment imprévisible

50 CISAD Exemple de modèles d argumentation A : Constitution de l'ordre du jour régulateur Participants à la réunion (n) Question Demande de sujet options proposition sujet 1 proposition sujet 2 proposition sujet 3 critères justification justification justification C : Conversation / Débat régulateur Participants à la réunion (n) Question Question sur le sujet options proposition de solution 1 proposition de solution 2 critères arguments positifs arguments négatifs arguments positifs arguments négatifs

51 CISAD Un exemple de représentation de la conversation Demande de sujet Accord A : constitution Régulateur Participant de l'ordre du jour Acceptation Sujet proposé Convocation Accord pour répondre B : Convocation Régulateur Participant des participants Prise en compte Réponse participation Organisation d'une réunion Régulateur Validation de la réunion Réunion Accord pour participation Exécution Participant Démarrage sur un sujet Annonce de l'intérêt C : Conversation Régulateur Participant / Débat Prise en compte Proposition de solution / résolution Demande d'évaluation Accord pour évaluer E : Evaluation de Régulateur Participant la réunion Prise en compte de la réponse Avis sur la réunion Prépare une question Participant (1) Prise en compte de la réponse D : Question / Réponse Veut répondre Réponse Participant (n-1)

52 MKSM : Methodology for Knowledge System Management Méthode pour la gestion des connaissances Cycle V Approche descendante Modélisation : traitement, activités, données Particularités : s arrête à la modélisation du système réel, passe la main à OMT pour la spécification du système informatique.

53 MKSM Modèle du domaine: représentation d un processus événement déclencheur réception d'un bulletin d'avis positif Champ Actif département de propriété Industrielle conséquence emission d'un projet de demande Système Source acteur 5 Action Source constitution d'un dossier technique Flux Dossier Technique Système Cible acteur 4 Action Cible rédaction d'un projet de demande événement déclencheur réception d'un dossier de circulation Champ Actif département de propriété Industrielle conséquence emission d'un dossier de circulation Système Source acteur 5 Système Cible acteur 3 Action Source prendre connaissance des modifications sur la demande de brevet Flux Dossier de circulation Action Cible compléter le dossier de circulation

54 MKSM Modèle de concepts : Exemple d un réseau de concepts dossier principal dossier technique projet de demande référence à l'invention domaine de l'invention état de l'art caractéristiques de l'invention référence à l'invention résumé de l'invention état de l'art description texte texte texte texte texte texte texte texte

55 MKSM Modèle de tâches vérifier le dossier de circulation (par acteur 2) des corrections sont à apporter le dossier est correct retourner le dossier (à acteur 4) transmettre le dossier (à acteur 6)

56 Autre modèle : le réseau de Petri Outil mathématique pour la représentation de la dynamique de systèmes à événements discrets Il existe de nombreuses extensions (temporisés, colorés, objets, )

57 Conclusion Il existe de nombreuses méthodes Les méthodes doivent être choisies en fonction du besoin, du domaine et surtout suite à une «bonne» analyse devant contenir TOUTES les informations utiles. L analyse est la base de tout projet, Ne pas hésiter à coupler les méthodes si cela est nécessaire et de façon rigoureuse.