Introduction aux méthodes d’analyse et de modélisationemmanuel.adam.free.fr/site/IMG/pdf/IntroMethodesGLP.pdf · Emmanuel ADAM – ISTV – Université de Valenciennes et du Hainaut-Cambrésis

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

Emmanuel ADAMEmmanuel ADAM

Institut des Sciences et Techniques de Valenciennes

Emmanuel ADAM – ISTV – Université de Valenciennes et du Hainaut-Cambrésis

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,

– ...


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, ...


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]


Les étapes de développement

1 - Analyse des besoins

2 - Spécification

3 - Conception

4 - Codage

5 - Intégration

6 - Mise en œuvre

7 - Exploitation - Maintenance

40%40%

20%


Analyse des besoins• Etude de faisabilité

• Type d’analyse– orientée processus, orientée rôle, orientée données

• Techniques d’acquisitions– entretiens, observations, questionnaires, ...


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...


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, ...


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


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, ...


Les langages de programmation (2/2)

• Programmation logique– issue de l’IA

– ex : prolog, lisp, scheme…

• Programmation orientée agent ?– Agent = objet autonome communicant


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)


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++, ...)


Atelier de modélisation


éditeur de code

éditeur d'interfaceshomme-machine

compilateur debugger

Atelier de développement


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



• Le modèle cascade

Spécification

Faisabilité, cahier des charges

Conception préliminaire

Conception détaillée

Codage

Intégration

Installation

Exploitation & maintenance



• Le modèle en V

Programmation

Spécification

Faisabilité, cahier des charges

Conception préliminaire


Test d’acceptation

Installation et tests systèmes

Intégration et test d’intégration

Test unitaire



• Le modèle incrémental (évolutif)Faisabilité, cahier des charges

Validation

Spécification

Validation

Conception

Vérification


Vérification

CodageTests unitaires

Intégration

Vérification

Mise en œuvre

Test

Exploitation, Maintenance

Revalidation


Vérification

CodageTests unitaires

Intégration

Mise en œuvre

Itération 2

Itération 1



• Le modèle spirale

prototype1

plan généraldu projet

conceptsd'opération

analyse derisque

prototype2 prototype3prototype

opérationnel

analyse derisque

analyse derisque

analyse derisque

détermination des objectifs,des alternatives,des contraintes

plan dedéveloppement

plan d'intégrationet de test validation de la

conceptionVérification

Validation desbesoins

conceptiondétaillée

Programmation ettest unitaires

Intégration et test

Test Système

Mise en oeuvre

simulation, modélisation, benchmark


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


Quelques méthodes d’analyse,de spécification et de conception

MERISE : orientée BdD

SADT : méthode structurée

1 3

2 4

vue globale du système

1

23

OSSAD : organisation CISAD : coopération

MKSM : gestion des connaissances

OMT : orientée objetUML


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


MERISEModèle Conceptuel de Communication


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


MERISEModèle Organisationnel des traitements


OMT : Object Modeling Technique

• Orientée Objet

• Cycle spirale


• Modélisation : données, dynamique, traitements

• Particularités : – Méthode objet utilisée dans qqs entreprises avant

l’apparition d’UML


OMTModèle de données

Dosssier Technique(DT)

- Référence invention- Domaine de l'invention- Etat de l'art- Caractéristiques de l'invention

- Référence invention,- Résumé de l'invention,- Etat de l'art,- Description de l'invention

Projet de demande de brevet(Prj.Dmd)

- n° de dossier,- noms inventeurs,- mots clés

Dossier de circulation(DdC)

Dossier principal

Avis de brevetabilité(Avis)

- Référence invention- avis

correspond àcorrespond à


OMTDiagramme d’événements


OMTDiagramme d’état


OMTDiagramme de flux de données


UML : Unified Modelling Language

• Langage, fusion des différentes méthodes orientées objets

• supporté par des outils

• +, cf. prochains cours


UMLCas d’utilisation


UMLScénario


UMLDiagramme de séquence


SADT : Structured Analysis and Design Technique

• Méthode structurée

• Cycle cascade


• Modélisation : données, activités

• Particularités : – Actigrammes fortement utilisés


SADTActigrammes


SADTDatagrammes

avis de brevetabilité,recherche

donner un avis

chercher

DossierTechnique

constituer leDossierTechnique(acteur 5)

Projet dedemande

rédiger projetde demande(acteur 4)

dossier decirculation

remplir ledossierde circulation(acteur 4)

dossiervérifié

lire(acteur 5) dossier luvérifer

(acteur 2)compléterle dossier(acteur 3,acteur 4)

dossiercomplété

revérifier(acteur 2)

Dossierrevérifié

dossierprincipal

créerdossierprincipal(acteur 6)

dossierprincipalvérifié

vérifier(acteur 1)


OSSAD : Office Support System Analysis and Design

• Méthode pour modélisation des organisations

• Cycle V


• Modélisation : activités, traitement, données

• Particularités : – 8 formalismes proposés !


OSSADDiagramme A1

Relations entre les fonctions de l’organisme

constituer ledossier

technique

rediger et mettreen forme leprojet dedemande

créer et remplirle dossier decirculation

DossierTechnique

Avis debrevetabilité

Projet dedemande

Dossier decirculation

copier et placerle projet dans

le dossierprincipal

parapher

compléter

Dossier principal


OSSADDiagramme A2

Matrice Activité/Rôle

Constitution du dossier

Rédaction du projet de demande

Création du dossier de circulation

Création du dossier principal

Modification du dossier de circulationA

cteu

r 6

Modification du texte du brevet

Modification et envoi du dossierprincipal

Act

eur 5

Act

eur 4

Act

eur 3

Act

eur 2

Act

eur 1


OSSADExemple de Diagramme D1 : Relations entre rôles

acteur 5acteur 4acteur 2

acteur 1

Dossier TechniqueDossier deCirculation

Dossier deCirculation

acteur 3Dossier deCirculation




DossierPrincipal

acteur 6

n° dossier

demande n°


OSSADExemple de diagramme D2 : Relations entre procédures

Rédaction duprojet dedemande

Création dudossier decirculation

Création dudossier principal

Modification etClassement dudossier pricipal

dossier deCirculation

DossierTechnique

Projet dedemande


Modification dudossier decirculation


dossier principal

Rôle 5



OSSADFiche représentant une tâche

Fiche TâcheNom de la tâche + (Id) :

(Decription) :

remplir Dossier de Circulation par acteur 4(Ta402)

Liens (arborescence) :

/ asc. (Procédure)

\ desc. (Opérations)

Création du dossier de Circulation (Pr003)

Demander n° dossier (Op402),Remplir (Op403)

Relations avec tâches :

par ressources entrantes

par ressources sortantes

Rédaction du Projet / Acteur 4,Création du dossier principal / Acteur 6

Projet de demande (Doc001)

Farde de Circulation (Doc002)


OSSADFiche représentant une donnée

Fiche RessourceNom de la ressource + (Id) :

(Decription) :

Projet de demande (doc001)

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)

projet de demande de dépôt de brevet

Mettre en forme le projet (Op452)


OSSADDiagramme d ’une procédure


CISAD : Cooperative Information System Analysis and design

• Étend OSSAD en permettant la prise en compte de la coopération


CISADExemple de modèle descriptif de rôle adapté (type D1)

Agentserviceprêt(2)

Client(1)

Chef deservice

demande

dossier Conditions

Offre

Agentserviceprêt(1)

Client(2)

Plan A Plan C

Plan B


CISADMatrice de Grudin pour la modélisation des communications

site 1 ... site imprévisible

rôle A rôle B ... rôle A rôle B ... rôle A rôle B ...

rôle A

rôle B

...

rôle A

rôle B

...

rôle A

rôle B

...

site 1

site ...

siteimprévisible

Synchrone Asynchrone et momentimprévisible

Asynchrone et momentprévisible


CISADExemple de modèles d’argumentation

A : Constitution de l'ordre du jour

Question

Demandede sujet

proposition sujet 1

proposition sujet 2

proposition sujet 3

justification

justification

justification

options critères

régulateur Participants à la réunion (n)

C : Conversation / Débat

Question

Questionsur le sujet

proposition desolution 1

arguments positifsoptions critères

régulateur Participants à la réunion (n)

proposition desolution 2

arguments négatifsarguments positifs

arguments négatifs


CISADUn exemple de représentation de la conversation

A : constitutionde l'ordre du jour

Accord

Sujet proposé

ParticipantRégulateur

Acceptation

Demande de sujetB : Convocationdes participants

Accord pour répondre

Réponse participation


Prise en compte

Convocation

Réunion

Accord pour participation

Exécution


Validation de la réunion

Organisation d'une réunion

Prise en compte

Démarrage sur un sujetC : Conversation

/ Débat

Annonce de l'intérêt

Proposition de solution / résolution


E : Evaluation dela réunion

Accord pour évaluer

Avis sur la réunion


Prise en compte de la réponse

Demande d'évaluation

D : Question /Réponse

Veut répondre

Réponse

Participant(n-1)

Participant(1)

Prise en compte de la réponse

Prépare une question


MKSM : Methodology for Knowledge System Management

• Méthode pour la gestion des connaissances

• Cycle V


• 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.


MKSMModèle du domaine: représentation d ’un processus

Champ Actifdépartement de propriété

Industrielle

Système Sourceacteur 5

Système Cibleacteur 4

Action Sourceconstitution d'un

dossier technique

Action Ciblerédaction d'un

projet de demande

conséquenceemission d'un projet

de demande

FluxDossier Technique

événement déclencheurréception d'un bulletin d'avispositif

Champ Actifdépartement de propriété

Industrielle

Système Sourceacteur 5

Système Cibleacteur 3

Action Sourceprendre connaissance des

modifications sur la demande debrevet

Action Ciblecompléter le dossier de circulation

conséquenceemission d'un

dossier de circulation

FluxDossier de circulation

événement déclencheurréception d'un dossier decirculation


MKSM Modèle de concepts : Exemple d ’un réseau de concepts

dossier principal

projet de demande

référence àl'invention

résumé del'invention état de l'art description

dossier technique

référence àl'invention

domaine del'invention état de l'art caractéristiques

de l'invention

texte texte texte texte texte texte texte texte


MKSMModèle de tâches

vérifier le dossier de circulation(par acteur 2)

retourner le dossier(à acteur 4)

transmettre ledossier (à acteur 6)

des corrections sontà apporter le dossier est correct


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, …)


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.

Documents

Introduction aux méthodes d’analyse et de modélisationemmanuel.adam.free.fr/site/IMG/pdf/IntroMethodesGLP.pdf · Emmanuel ADAM – ISTV – Université de Valenciennes et du Hainaut-Cambrésis