1. ACSI
Modélisation par Objets
À destination des étudiants du
2e année IUT Nice-Sophia Antipolis
Mireille Blay-Fornarino
IUT Nice-Sophia Antipolis
blay@unice.fr
http://www.polytech.unice.fr/~blay
Site web du module :
http://anubis.polytech.unice.fr/iut/
1
5. Parlons-nous le même langage ?
Modélisation & 0bjets
Quiz
Sur la base du
Essentials of Visual Modeling with UML 2.0
Module 3a: VM Quiz Show
3
IBM
6. Question
Un modèle. . .?
A. doit être structurel et comportemental.
B. est inutile si les membres d’une équipe savent
programmer
C. est une simplification de la réalité.
D. est une excuse pour retarder le développement
Réponse :
4
7. Question
Pourquoi modéliser? Pour ...
A. Aider à visualiser un système
B. Documenter nos décisions
C. Comprendre et cerner les besoins fonctionnels et
techniques
D. Faciliter la planification
E. Toutes ces réponses
Réponse :
5
8. Question
A votre connaissance, à partir d’un modèle,
avec des outils, on peut. . .?
A. obtenir une bonne note
B. produire de la documentation
C. produire des squelettes de code
D. produire du code
E. valider une spécification
F. simuler un système
G.autre
Réponse :
6
9. Question
La modélisation s’arrête quand ?
A. on commence à développer
B. le prof n’est plus là pour l’exiger
C. tout le système a été modélisé
D. on a fini de représenter la réalité
E. on n’a plus d’argent
F. le système s’arrête
Réponse :
7
10. Question
La technologie objet est . . . ?
A. Une nouvelle théorie cherchant à se faire accepter.
B. Un nouveau langage dynamique inventé par Grady
Booch.
C. basée sur des principes de décomposition
fonctionnelle
D. Un ensemble de principes guidant le développement
du logiciel
E. faire compliqué quand on peut faire simple
Réponse :
8
11. Question
Un objet . . . ?
A. a un état défini par la valeur de ses attributs
B. a une identité qui doit correspondre à une clef dans
une BD
C. est identifié par une référence
D. peut recevoir des messages
Réponse :
9
12. Question
Pour communiquer avec un objet,
je ....?
A. lui envoie des messages
B. le stocke dans une base de données
C. modifie la valeur de ses attributs
Réponse :
10
13. Question
Une classe . . . ?
A. est une encapsulation d’un objet;
B. représente la hiérarchie d’un objet;
C. représente un ensemble d’objets;
D. est une instance d’un objet;
E. est une définition abstraite d’un object.
Réponse :
11
14. Question
Une classe définit . . . ?
A. les données portées par les objets
B. les comportements des objets
C. la manière de créer un objet
Réponse :
12
15. Question
Pour créer un objet, je dois ....?
A. demander à un autre objet de le créer
B. demander à sa classe
C. demander à une base de données
D. lui parler
E. lui envoyer un message
Réponse :
13
16. Question
Soit la méthode findAllStudents(), elle est définie
comme :
A. une méthode de Student :
appel : Student s; s.findAllStudents();
B. une méthode de la classe Course :
appel : Course c; d.findAllStudents();
C. une méthode «static» de Student :
appel : Student.findAllStudents();
D. autre
14
Réponse :
17. Question
L’encapsulation . . . ?
A. est souvent vue comme un moyen de cacher les
données dans des entités logicielles
B. empêche les codes de s’abîmer
C. facilite les modifications d’implémentations
D. engendre une gestion difficile de l’évolution
Réponse :
15
18. Question
Quelle phrase traduit le mieux la
Généralisation . . . ?
A. “Est une partie de”
B. “Est une sorte de”
C. “Est un réplica de”
D. “Est un héritage de”
Réponse :
16
19. Question
L’héritage . . . ?
A. permet de déclarer des propriétés une fois et
que les sous-classes les connaissent.
B. offre la possibilité de toucher dans l'âge adulte
les sommes qu'on vous a refusées dans votre
jeunesse.
C. améliore la productivité
D. améliore la maintenance
E. accroît la complexité
Réponse :
17
20. Intro. Intro. UML Démarche
Plan
Problèmes du développement logiciel
Histoire brève jusqu’aux limites de la programmation structurée
Du bidouillage au Génie logiciel
Introduction à UML
Un peu d’histoire
Survol
De Merise à UML (plus tard)
Présentation du Module : démarche générale
09/10 18
21. I. Quels sont les problèmes
du développement logiciel?
19
22. I. Quels sont les problèmes
du développement logiciel?
Un peu d’histoire
20
23. Intro. ✓histoire Intro. UML Démarche
La gestion progressive de la complexité
Premiers programmes en langage machine
Les premiers programmes, écrits en langage machine,
dépendaient fortement de l'architecture des ordinateurs
utilisés.
sub $sp, $sp, 4
sw r,0($sp)
09/10 21
24. Intro. ✓histoire Intro. UML Démarche
La gestion progressive de la complexité
Programmation en langages évolués
Lorsque le nombre d'architectures différentes a augmenté, un premier
effort a été produit pour séparer les concepts manipulés dans
les langages de leur représentation dans la machine et a abouti
à la création de langages comme FORTRAN.
PROGRAM DEGRAD
!
! Imprime une table de conversion degrés -> radians
! =================================================
!
! Déclaration des variables
INTEGER DEG
REAL RAD, COEFF
!
! En-tête de programme
WRITE ( *, 10)
10 FORMAT (' ',20('*') / &
& ' * Degres * Radians *' / &
& ' ', 20('*') )
!
! Corps de programme
COEFF = (2.0 * 3.1416) / 360.0
DO DEG = 0, 90
RAD = DEG * COEFF
WRITE ( *, 20) DEG, RAD
20 FORMAT (' * ',I4,' * ',F7.5,' *')
END DO
!
! Fin du tableau
WRITE ( *, 30)
30 FORMAT (' ',20('*') )
!
! Fin de programme
STOP
09/10 22 END PROGRAM DEGRAD
25. Intro. ✓histoire Intro. UML Démarche
La gestion progressive de la complexité
Méthode d’analyse par décomposition
La complexité croissante des programmes a de nouveau suscité un effort
pour mieux structurer les programmes (abandon du goto et de la
programmation spaghetti)
Les méthodes d'analyse consistait alors à «diviser pour mieux régner»,
i.e. à découper les tâches en modules indépendants.
Niklaus Wirth va plus loin : les programmes sont la «somme» d'une
structure de données et d'un ensemble distinct d'algorithmes chargés de
les manipuler.
➡ La programmation structurée étaient alors synonyme de
programmation dirigée par les traitements.
function ConstruitPhrase(phrase:string):string;
var s : string;
begin
readln(s);
ConstruitPhrase:=phrase+', '+s;
end;
var
Phrase : string;
begin
Phrase:=''; {initialiser à chaîne vide}
{premier mot}
writeln('Entrez un mot :');
09/10 23 Phrase:=ConstruitPhrase(Phrase);
26. Intro. ✓histoire Intro. UML Démarche
La gestion progressive de la complexité
L’explosion des besoins
Le coût du matériel informatique a fortement décru et ce matériel est devenu
un bien de consommation courant (tant dans des entreprises et des universités
que chez les particuliers).
La clientèle s'est diversifiée, les besoins ont explosé.
09/10 24
27. Intro. ✓histoire Intro. UML Démarche
Limites de la programmation structurée
La diffusion de la structure des données
dans le code
La programmation structurée nécessite de faire des hypothèses sur les
données à traiter. La structure physique des données à traiter est
diffusée dans une part importante du code.
Une simple modification des exigences des utilisateurs ou une
modification des données peut entraîner d'importantes modifications au
niveau des codes chargés de les traiter.
Par exemple, en 1982, les postes américaines sont passés du code
postal à 5 chiffres à celui à 9 chiffres. Beaucoup de programmes
gérant des fichiers d'adresses ont dû être récrits à grands frais.
09/10 25
28. Intro. ✓histoire Intro. UML Démarche
Et après
Encapsuler, assembler, réutiliser
Pour répondre à ces besoins croissants, la
programmation a connu une évolution et une
montée en abstraction encore plus importante :
09/10 26
29. Intro. ✓histoire Intro. UML Démarche
Et après
Encapsuler, assembler, réutiliser
Pour répondre à ces besoins croissants, la
programmation a connu une évolution et une
montée en abstraction encore plus importante :
Objets, Composants, Services, Composants as
Services, Génération des codes à partir de modèles,
Frameworks, Usines logicielles, ....
09/10 26
30. Intro. ✓histoire Intro. UML Démarche
Et après
Encapsuler, assembler, réutiliser
Pour répondre à ces besoins croissants, la
programmation a connu une évolution et une
montée en abstraction encore plus importante :
Objets, Composants, Services, Composants as
Services, Génération des codes à partir de modèles,
Frameworks, Usines logicielles, ....
Mais le plus important des changements de
«méthodes» de développement...
09/10 26
31. I. Quels sont les problèmes
du développement logiciel?
Du bidouillage au génie logiel
27
32. Intro. Intro. UML Démarche
Problématique du génie logiciel
➡ Programming-in-the-Small
Problème de la qualité interne d'un composant
➡ Programming-in-the-Large
Faire face à la construction de systèmes de plus en plus gros :
non spécifique au logiciel, mais aggravé par sa “mollesse”.
Problème de gestion de la complexité, de communication, etc.
Maîtrise du processus de développement: délais, coûts, qualité.
Programming-in-the-Duration
Problème de la maintenance corrective et évolutive.
Notion de ligne de produits.
Pr. Jean-Marc Jézéquel
09/10 28
33. Intro. ✓Prog. Small ✓Validation Intro. UML Démarche
Programming-in-the-Small
Problème de la validité du logiciel
Acquérir une valeur positive n
Tant que n > 1 faire
si n est pair
alors n := n / 2 Prouver que le prog. termine pour tout n?
sinon n := 3n+1 -> Indécidabilité de certaines propriétés
Sonner alarme;
Recours au test
– ici, si machine 32 bits, 2^31 = 10^10 cas de tests
– 5 lignes de code => 10 milliards de tests !
Pr. Jean-Marc Jézéquel
09/10 29
34. Intro. ✓Prog. Small ✓Validation Intro. UML Démarche
Programming-in-the-Small
Produire des programmes prouvés
C’est possible…
On peut construire des programmes de tel manière qu’ils
soient prouvables
En partie automatisable (Atelier B, etc.)
Outils spécifiques
…mais coûteux
Preuve au moins aussi complexe que le code
Autant de chances de se tromper dans la preuve…
En pratique :
Réservé à des (petits) sous-systèmes (très) critiques
Recours aux tests pour le reste
09/10 30
35. Intro. ✓Prog. Small ✓Validation Intro. UML Démarche
Programming-in-the-Small
Syntaxe JML Préconditions :
/** Ce qui doit être satisfait
* @param double x réel positif pour appeler la méthode
* @result double racine carrée de x
*/
/*@
@ requires x >= 0.0 ; Assertions
@ ensures x == result * result ;
@*/
public static double sqrt(double x) {
Postconditions :
Ce qui est satisfait en cas de retour
normal
Invariant =
propriété toujours vraie quelque soit l’état du système
09/10 31
36. Intro. ✓Prog. Large ✓Complexité Intro. UML Démarche
Programming-in-the-Large
Gérer la complexité due à la taille
a) c)
b) d)
Si l'automobile avait suivi le même développement que l'ordinateur, une Rolls-Royce coûterait aujourd'hui 100$, pourrait rouler un
million de kilomètres avec un litre d'essence, et exploserait une fois par an en tuant tout le monde à bord. Robert Cringely.
Pr. Jean-Marc Jézéquel
09/10 32
37. Intro. Intro. UML Démarche
Exemple Windows Vista …
65 millions de lignes de code, 6 années de développement,
9000 développeurs (54 000 années développeurs)
http://www.clubic.com/article-66145-1-microsoft-windows-vista-rtm-dossier.html
… sur les vingt années d'existence de Windows, Vista aura été le système d'exploitation
dont le cycle de développement fut le plus long ! Et pour cause, puisqu'après avoir
démarré le développement de Longhorn en 2001, Microsoft a du remettre à plat
l'intégralité du projet en 2004, réalisant alors que celui-ci était par trop complexe et
tentaculaire. En repartant de zéro, Microsoft a entièrement révisé son cahier des charges
en supprimant au passage certaines fonctionnalités pourtant très attendues de Vista ; on
pense bien sûr au système de fichiers WinFS qui est ainsi tombé purement et simplement
aux oubliettes. C'est au maître d'œuvre de Vista, Jim Allchin, que l'on doit cette décision,
certainement très difficile à prendre vu ses implications pour l'époque. Lorsque, fin 2004,
les équipes à la tête de Microsoft décident de repartir de zéro, c'est pratiquement tout le
travail des 9 000 développeurs mobilisés sur Windows Vista qui est à recommencer…
09/10 33
38. Intro. ✓Prog. Large ✓Complexité Intro. UML Démarche
Programming-in-the-Large
Augmentation exponentielle de la taille du logiciel
09/10 34
39. Intro. ✓Prog. Large ✓Complexité Intro. UML Démarche
Programming-in-the-Large
Echecs logiciels
Premier vol d’Ariane 5 (1996)
ATT (1990):
interruption du service téléphonie
pendant 5 heures à l'Est des Etats-Unis.
Aéroport de Denver, 1993-1995:
logiciel de suivi des bagages,
coût 3 milliards de $, retard de 18 mois.
National Cancer Institute, Panama
City,2000 : Logiciel non adapté aux
médecins => 8 morts, 20 personnes Out of range
“surexposées”.
etc., etc.
09/10 35
40. Intro. ✓Prog. Large ✓Diviser Intro. UML Démarche
Gestion de la complexité due à la taille :
diviser pour résoudre
Aspects techniques
en s'appuyant techniquement sur la modularité
« Encapsulation et masquage d'information, faible couplage »
Importance de la notion d’Objets
Aspects organisationnels
S’organiser au delà de la réalisation : méthodes
« Analyse, conception »
« Validation et vérification »
Ingénierie de la conduite de projet = compromis entre
respect des délais
respect des coûts
réponse aux besoins/assurance qualité
Problèmes de gestion de ressources (humaines, etc.) et
de synchronisation entre tâches
09/10 36
41. Intro. ✓Prog. Durée Intro. UML Démarche
Programming-in-the-Duration
Gestion de l’évolution d'un système
D’après Swanson & Beath (Maintaining
Information Systems in Organizations, 1989)
Durée de vie moyenne d’un système : 6.6 ans
26% des systèmes sont âgés de plus de 10 ans
Problème de la maintenance corrective et évolutive
Adaptation aux changements des besoins
Adaptation aux changements de l’environnement
Support nouvelles plateformes, bug « an 2000 »
09/10 37
42. Intro. ✓Prog. Durée ✓Maintenance Intro. UML Démarche
Programming-in-the-Duration
Problème de la maintenabilité
Exemple critique dû à M. Jackson
Barques à louer sur un lac
Enregistrement des départs (S) et retours (E) sur un
terminal, avec horodatage automatique
On veut chaque jour un rapport avec :
le nombre de sessions
la durée moyenne d'une session
09/10 38
43. Intro. ✓Prog. Durée ✓Maintenance Intro. UML Démarche
Programming-in-the-Duration
Approche « droit au but »
Décomposition fonctionnelle en 1980
Structured Analysis and Design technique : SADT
Le système a une fonction…
Décomposée récursivement en sous-fonctions…
Jusqu’à tomber sur des fonctions élémentaires
Reliées par flots de données
∑(
09/10 39
45. Intro. ✓Prog. Durée✓Maintenance Intro. UML Démarche
Programming-in-the-Duration
Maintenance
Demandes de modifications :
durée de la session la plus longue
un état pour le matin, un autre pour le soir
corriger la perte de S ou de E
09/10 41
46. Intro. ✓Prog. Durée✓Maintenance Intro. UML Démarche
Programming-in-the-Duration
Maintenance
Demandes de modifications :
durée de la session la plus longue
un état pour le matin, un autre pour le soir
corriger la perte de S ou de E
Dans la réalité, c’est pire!
Nokia rapporte à propos de son infrastructure GSM
50% des exigences (besoins numérotés) ont changé après le gel du
cahier des charges
60% de ceux-ci ont changé au moins 2 fois!
C’est le cas général plutôt que l’exception
Cahier des charges figé = rêve des années 70
09/10 41
47. Exemple Windows Vista …
Vista prêt à en découdre avec les failles de sécurité!
C'est inévitable. La découverte de failles devrait s'accélérer avec le lancement en
grandeur réelle de Windows Vista. Microsoft s'y prépare…
…« Les failles sont inhérentes au développement logiciel. Elles reposent sur des
erreurs de programmation. Or, détecter absolument toutes les erreurs est
impossible même avec des moyens financiers comme ceux dont dispose
Microsoft »…
8 000 dollars pour chaque trou de sécurité!
… Idefense Labs, une filiale de Verisign, va encore plus loin. Elle promet
8 000 dollars (assortis d'un bonus oscillant entre 2 000 et 4 000 dollars selon la
qualité des explications fournies) à qui découvrira une faille critique dans Vista ou
Internet Explorer 7…
… « La démarche est pertinente dans la mesure où elle permet de mobiliser les
chercheurs du monde entier à moindre frais »… 42
Grimaldi 2010
49. Intro. ✓Prog. Durée ✓Vers l’objet Intro. UML Démarche
La découpe fonctionnelle d'un problème
informatique : une approche intuitive
Factorisation
09/10 44
50. Intro. ✓Prog. Durée ✓Vers l’objet Intro. UML Démarche
Le revers de la médaille :
maintenance complexe en cas d'évolution
09/10 45
->
51. Intro. ✓Prog. Durée ✓Vers l’objet Intro. UML Démarche
Le revers de la médaille :
maintenance complexe en cas d'évolution
La séparation des données et des
traitements : le piège !
09/10 45
->
52. Intro. ✓Prog. Durée ✓Vers l’objet Intro. UML Démarche
Réunir données et traitements :
Programmation par objets
09/10 46
53. Intro. ✓Prog. Durée ✓Vers l’objet Intro. UML Démarche
Vision objet du système
informatique (1)
➡ Le système d ’informatique est modélisé comme un ensemble
d ’objets, avec leurs propriétés et leurs comportements, qui
collaborent entre eux
• Un objet est une entité aux frontières précises
• Un ensemble d'attributs caractérise l'état de l'objet.
• Un ensemble d'opérations (méthodes ou comportements) en définit le
comportement.
09/10 47
54. Intro. ✓Prog. Durée ✓Vers l’objet Intro. UML Démarche
Vision objet du système
informatique (2)
➡ Un objet est une instance de classe (une occurrence d'un type
abstrait).
➡ Une classe est un type de données abstrait (modèle) ,
caractérisé par des propriétés (attributs et méthodes)
communes à des objets et permettant de créer des objets
possédant ces propriétés.
09/10 48
55. Intro. ✓Prog. Durée ✓Vers l’objet Intro. UML Démarche
Vision objet du
système informatique (3)
➡ Héritage (et polymorphisme)
L'héritage est un mécanisme de transmission des propriétés
d'une classe (ses attributs et méthodes) vers une sous-
classe.
09/10 49
56. Intro. ✓Prog. Durée ✓Vers l’objet Intro. UML Démarche
Vision objet du système
informatique (4)
➡ Héritage (et polymorphisme)
Le polymorphisme représente la faculté d'une méthode
à pouvoir s'appliquer à des objets de classes
différentes.
09/10 50
58. Intro. ✓Prog. Durée Intro. UML Démarche
Programming-in-the-Duration
Solution : approche par modélisation
Aspects techniques
Assurer une meilleure continuité entre
Domaine du problème
Domaine des solutions
Définir les fonctionnalités
Prévoir les scénarios de tests
Maintenance traitée comme le développement initial
Aspects organisationnels
Traçabilité Utilisation de
Gestion contrôlée des changements Méthodes
«Agiles»
09/10 52
59. Intro. Intro. UML Démarche
Problématique du génie logiciel
WHAT IS SOFTWARE ENGINEERING?
The IEEE Computer Society defines software engineering as
“(1) The application of a systematic, disciplined, quantifiable
approach to the development, operation, and maintenance
of software; that is, the application of engineering to
software.
(2) The study of approaches as in (1).”
http://www.swebok.org/
09/10 53
62. Intro. Intro. UML ✓Histoire Démarche
Pourquoi UML ?
➡ Objectifs : spécifier, construire, visualiser et documenter les
systèmes à base de logiciel
Pour communiquer, travailler à plusieurs
Pour comprendre la « big picture »
Par approche orientée objets
Avec différents modèles pour différentes vues
➡ UML : Langage et non simple notation graphique (ni méthode)
➡ UML est Indépendant des méthodologies
09/10 56
63. Intro. Intro. UML ✓Histoire Démarche
Un peu d’histoire :
La guerre des Méthodes
Booch, OMT, Coad/Yourdon, Fusion,SADT, OOSE,
Schlaer/Mellor, HOOD…
UML: un méta-langage de modélisation pour unifier les
modèles utilisés dans les méthodes
09/10 57
64. Intro. Intro. UML ✓Histoire Démarche
Et un langage unique, un !
Un cocktail de notations éprouvées.
(...mais pas toutes, p. ex. RdP,
SADT/IDEF0, DFD, etc.)
Auteurs : Grady Booch, Ivar Jacobson, James Rumbaugh.
Standardisation OMG (Object Management Group) en 1997
Promoteurs :
Rational Software, Oracle
Hp, Microsoft, IBM
09/10 58
65. Intro. Intro. UML ✓Histoire Démarche
http://www.omg.org/spec/UML/2.3/Superstructure/PDF/ 758 pages
UML 2.3 May 2010
Commentaires du
public
09/10 59
67. Intro. Intro. UML Démarche
Qu’est-ce qu’UML ?
un support à la modélisation
➡ Modèle : simplification de la réalité dont les buts sont
Visualiser Spécifier la
le système structure et le
comportement
du système
Aider à la
construction Documenter
du système les décisions
09/10 61
68. Intro. Intro. UML ✓Histoire Démarche
Qu’est-ce qu’UML ?
➡ UML est un langage «visuel»
➡ Il supporte
La visualisation
La spécification
La construction
La documentation
Jean-Paul Rigault 2005
09/10 62
69. Intro. Intro. UML ✓Histoire Démarche
Qu’est-ce qu’UML ?
➡ UML est un langage «visuel»
➡ Il supporte
La visualisation Syntaxe et sémantique
La spécification Descriptions graphiques et textuelles
La construction Architecture et comportement
Génération de code
La documentation
Jean-Paul Rigault 2005
09/10 62
70. Intro. Intro. UML ✓Histoire Démarche
Qu’est-ce qu’UML ?
➡ UML est un langage «visuel»
➡ Il supporte
La visualisation Syntaxe et sémantique
La spécification Descriptions graphiques et textuelles
La construction Architecture et comportement
Génération de code
La documentation
On ne décrit pas l’univers tout entier…
Le logiciel joue un rôle majeur
Jean-Paul Rigault 2005
09/10 62
71. Intro. Intro. UML ✓Histoire Démarche
Qu’est-ce qu’UML ?
➡ UML est un langage «visuel»
➡ Il supporte
La visualisation Syntaxe et sémantique
La spécification Descriptions graphiques et textuelles
La construction Architecture et comportement
Génération de code
La documentation
On ne décrit pas l’univers tout entier…
Le logiciel joue un rôle majeur
UML n’est pas une méthodologie de développement, contrairement
à RUP (Rational Unified Process).
Jean-Paul Rigault 2005
09/10 62
72. Intro. Intro. UML ✓Histoire Démarche
Qu’est-ce qu’UML ?
Axes de modélisation d’un système
Statique (ce que le système EST)
Dynamique
(comment le système Fonctionnel
EVOLUE) (ce que le système
FAIT)
09/10 63
73. Intro. Intro. UML ✓Histoire Démarche
Qu’est-ce qu’UML ?
Axes de modélisation d’un système
Statique (ce que le système EST)
• diagramme de classes
• diagramme d’objets
• diagramme de composants
• diagramme de déploiement
Dynamique
(comment le système Fonctionnel
EVOLUE) (ce que le système
FAIT)
09/10 63
74. Intro. Intro. UML ✓Histoire Démarche
Qu’est-ce qu’UML ?
Axes de modélisation d’un système
Statique (ce que le système EST)
• diagramme de classes
• diagramme d’objets
• diagramme de composants
• diagramme de déploiement
Dynamique
(comment le système Fonctionnel
EVOLUE) (ce que le système
FAIT)
• diagramme de cas d’utilisation
• diagramme de collaboration
09/10 63
75. Intro. Intro. UML ✓Histoire Démarche
Qu’est-ce qu’UML ?
Axes de modélisation d’un système
Statique (ce que le système EST)
• diagramme de classes
• diagramme d’objets
• diagramme de composants
• diagramme de déploiement
Dynamique
(comment le système Fonctionnel
EVOLUE) (ce que le système
• diagramme de séquences FAIT)
• diagramme de collaboration • diagramme de cas d’utilisation
• diagramme d’états-transitions • diagramme de collaboration
• diagramme d’activités
09/10 63
76. Intro. Intro. UML ✓Histoire Démarche
Les points forts d'UML
UML est un langage normalisé
gain de précision
gage de stabilité
encourage l'utilisation d'outils
UML est un support de communication performant
Il cadre l'analyse.
Il facilite la compréhension de représentations abstraites
complexes.
Son caractère polyvalent et sa souplesse en font un langage
universel.
09/10 64
77. Intro. Intro. UML ✓Histoire Démarche
Les points faibles d'UML
La mise en pratique d'UML nécessite un apprentissage et
passe par une période d'adaptation.
Le processus (non couvert par UML) est une autre clé de la
réussite d'un projet.
09/10 65
79. Intro. Intro. UML ✓Survol Démarche
Qu’est-ce qu’UML ?
Diagrammes des cas d’utilisation
Ce diagramme montre ce que que fait le système et qui l’utilise
Entrer
DébloquerLesPortes
PorteurDeCarte Capteur
AIncendie
Sortir
ListerLes
TentativesDeFraudes
GérerLesCartes
Gardien Administrateur
SystèmeDeContrôleDAcces
09/10 67
80. Intro. Intro. UML ✓Survol Démarche
Qu’est-ce qu’UML ?
Diagrammes de séquence
Ce diagramme montre les flots de communications
paul le distrib. la carte de P. la reserve la banque le compte de P.
retirer(500)
lireN°Compte()
retirerDeLArgent(500,88219)
débiter(500)
sortirDesBillets(5)
sortirBillets ()
09/10 68
81. Intro. Intro. UML ✓Survol Démarche
Qu’est-ce qu’UML ?
Diagrammes de collaboration
6 : prendreBillet()
la reserve de billets
5 : sortirDesBillets(5)
1 : retirer(500) 3 : retirerDeLArgent 4 : débiter(500)
le distributeur (500,88219)
la banque
paul
88219 2 : lireN°Compte()
le compte de paul
la carte de P.
09/10 69
82. Intro. Intro. UML ✓Survol Démarche
Qu’est-ce qu’UML ?
Diagrammes de classes
Compte Banque
1..4 1..* 1..* 1..*
Client numéro
titulaires numéro
solde nom
1 signataire ... 0..*
1 Consortium
CarteBleue
0..* 0..* 1
Code
retraitMax AcceptéPar> 0..*
Distributeur
1..*
Ce diagramme montre les classes et les relations entre elles
09/10 70
83. Intro. Intro. UML ✓Survol Démarche
Qu’est-ce qu’UML ?
Diagrammes d’objets
EstAcceptéPar>
: Distributeur
: CarteBleue
signataire
titulaires
fred : Client c4 : Compte : Banque : Consortium
: CarteBleue
signataire
paul : Client c1 : Compte : Banque
titulaires
titulaires
pierre : Client c2 : Compte
: Consortium
titula
ires
titulaires
marie : Client c3 : Compte : Banque
signataire
: CarteBleue
EstAcceptéPar>
Ce diagramme montre les instances
sophie : Client
EstAcceptéPar>
: Distributeur
et les liens entre elles à l’exécution.
09/10 71
84. Intro. Intro. UML ✓Survol Démarche
Qu’est-ce qu’UML ?
Diagrammes d’états
carte insérée
En attente En attente du code
carte retirée mauvais code code frappé
En attente retrait carte En vérification
code bon
Pour expliciter
les attentes
montant incorrect En attente du montant
d’évènements &
les différents montant correct
états d’un objet.
billets retirés
En distribution
09/10 72
85. Intro. Intro. UML ✓Survol Démarche
Qu’est-ce qu’UML ?
Divers modes d’utilisation
➡ Mode esquisse (sketch)
Informelle, incomplète
Souvent manuelle (tableau)
➡ Mode plan (blue print)
Diagrammes détaillés
Production de documents
Pro- et rétro-ingénierie
➡ Mode langage de programmation
Spécification complète et exécutable
Pas vraiment disponible actuellement !
Jean-Paul Rigault 2005
09/10 73
86. Intro. Intro. UML ✓Survol De Merise à UML
Unified Process (UP)
➡ UML se veut indépendant de toute méthodologie
➡ Cependant, il est mieux adapté à un processus (tel le RUP)
dirigé par les cas d’utilisation (use-case driven)
centré sur l’architecture (architecture centric)
itératif et incrémental
➡ Le UP propose en outre
des techniques de modélisation pour les différentes phases et
activités
une organisation des rôles et des flots lors du processus de
développement
A venir dans
09/10 74 le cours
88. Intro. Intro. UML Démarche
Approche dirigée par les cas
09/10 76
89. Intro. Intro. UML Démarche
Approche dirigée par les cas
1. Établir le dictionnaire
09/10 76
90. Intro. Intro. UML Démarche
Approche dirigée par les cas
1. Établir le dictionnaire
2. Identification des acteurs qui agissent sur le système à étudier.
09/10 76
91. Intro. Intro. UML Démarche
Approche dirigée par les cas
1. Établir le dictionnaire
2. Identification des acteurs qui agissent sur le système à étudier.
3. Définition et description des cas d'utilisation qui montreront les
interactions entre les acteurs actifs externes et le système vu comme une
boîte noire.
09/10 76
92. Intro. Intro. UML Démarche
Approche dirigée par les cas
1. Établir le dictionnaire
2. Identification des acteurs qui agissent sur le système à étudier.
3. Définition et description des cas d'utilisation qui montreront les
interactions entre les acteurs actifs externes et le système vu comme une
boîte noire.
4. Pour chaque cas d'utilisation seront décrits les principaux flux qui
visualisent la chronologie des échanges entre les acteurs et le système
09/10 76
93. Intro. Intro. UML Démarche
Approche dirigée par les cas
1. Établir le dictionnaire
2. Identification des acteurs qui agissent sur le système à étudier.
3. Définition et description des cas d'utilisation qui montreront les
interactions entre les acteurs actifs externes et le système vu comme une
boîte noire.
4. Pour chaque cas d'utilisation seront décrits les principaux flux qui
visualisent la chronologie des échanges entre les acteurs et le système
5. Capturer les concepts du domaine
09/10 76
94. Intro. Intro. UML Démarche
Approche dirigée par les cas
1. Établir le dictionnaire
2. Identification des acteurs qui agissent sur le système à étudier.
3. Définition et description des cas d'utilisation qui montreront les
interactions entre les acteurs actifs externes et le système vu comme une
boîte noire.
4. Pour chaque cas d'utilisation seront décrits les principaux flux qui
visualisent la chronologie des échanges entre les acteurs et le système
5. Capturer les concepts du domaine
6. A chaque flux sera associé un diagramme de séquence qui mettra en avant
l'aspect temporel des interactions entre les objets de l'application qui
participent au scénario
09/10 76
95. Intro. Intro. UML Démarche
Approche dirigée par les cas
1. Établir le dictionnaire
2. Identification des acteurs qui agissent sur le système à étudier.
3. Définition et description des cas d'utilisation qui montreront les
interactions entre les acteurs actifs externes et le système vu comme une
boîte noire.
4. Pour chaque cas d'utilisation seront décrits les principaux flux qui
visualisent la chronologie des échanges entre les acteurs et le système
5. Capturer les concepts du domaine
6. A chaque flux sera associé un diagramme de séquence qui mettra en avant
l'aspect temporel des interactions entre les objets de l'application qui
participent au scénario
7. Ces diagrammes serviront alors de base à la construction des diagrammes
de séquence de conception et les diagrammes de classes qui visualisent
l'architecture du logiciel, la hiérarchie et les associations entre classes
09/10 76
97. Intro. Intro. UML Démarche
1) Dictionnaire
Personne identifiée par la galerie à l'origine d'une ou plusieurs
Artiste œuvres.
Création d’un artiste destinée à être vendue sur le site.
Œuvre
Client Internaute qui possède un compte sur le site.
Galerie Lieu d'exposition et de vente d'œuvres d'art moins une œuvre.
Gérant Responsable du magasin, initialise les caisses,
Personne en charge du suivi du site ayant la possibilité de gérer
Administrateur l'ajout de nouveaux artistes, œuvres et de modifier les
informations concernant un artiste et/
09/10 78
98. Intro. Intro. UML Démarche
2) Acteurs et diagrammes de contexte
09/10 79
99. Intro. Intro. UML Démarche
3) Diagramme des cas d'utilisation
uses case diagram
09/10 80
100. Intro. Intro. UML Démarche
4) Description complète d'un cas d’utilisation
Acheter des oeuvres
Acteurs : Client
Objectif : Décrire un achat d’oeuvre
par le Client
Aperçu : Un Client sélectionne des
oeuvres qu’il met dans son
panier. Le Client demande à
passer commande. Le
système vérifie la
disponibilité des oeuvres et
bloque leur vente. Il calcule le
montant de la comma ces
09/10
produits, 81
annonce le total,
101. Intro. Intro. UML Démarche
5) Capturer les concepts du domaine
Acheter des oeuvres
Acteurs : Client
Objectif : Décrire un achat d’oeuvre
par le Client
Aperçu : Un Client sélectionne des
oeuvres qu’il met dans son
panier. Le Client demande à
passer commande. Le
système vérifie la
disponibilité des oeuvres et
bloque leur vente. Il calcule le
montant de la comma ces
09/10
produits, annonce le total,
82
102. Intro. Intro. UML Démarche
5) Capturer les concepts du domaine
09/10 83
105. Intro. Intro. UML Démarche
Diagramme de classes :
Niveau Conception
09/10 86
106. Intro. Intro. UML Démarche
Diagramme de classes :
Niveau Conception : Tables
(partiel)
09/10 87
107. Intro. Intro. UML Démarche
Bibliographie
Ce cours a été monté en utilisant de nombreux supports
dont je remercie chaleureusement ici les auteurs
D’autres références se trouvent sur le site du module.
Merise: 5ème Partie Dossier "SAM l'Informaticien" du 5 Mars au 18 Mars 2001
par Stéphane Lambert http://www.vediovis.fr/index.php?page=merise5
Introduction au langage UML, SUPINFO
De Merise à UML, Nasser Kettani, Dominique Mignet, Eyrolles
http://www.compucycles.com/nouveausite/articles/Merise/Article_07.htm
UML-MERISE Etude Comparative, OSITEC-Consultants, 2004-2005
Modélisation Orientée objet, M.Grimaldi – janvier 2010
09/10 88
Hinweis der Redaktion
\n
\n
\n
\n
A : non un modèle ne supporte pas forcément une définition struc/comp : il peut servir à exprimer des besoins\nB : \n
E\n
A : vous l’avez deja fait? avec quel outil?\nB : comment quelle doc ?\n\n
\n
Sur le E nous reviendrons après...\n
Chaque objet a sa propre identité ; deux objets sont distincts même si toutes les valeurs de leurs attributs sont identiques. Cela se comprend aisément puisque la place mémoire occupée par chaque objet est distincte.\nPour reconnaître un objet et lever toute ambiguïté, on utilise, en général, un identifiant particulier : notre numéro de sécurité sociale par exemple, le numéro de la plaque d'immatriculation, une clé utilisée dans une base de données, …\n
A class is a description of a set of objects that share the same attributes, operations, relationships, and semantics.\nA class is not an object. It is an abstract definition of an object. It defines the structure and behavior of each object in the class.\n
A class is a description of a set of objects that share the same attributes, operations, relationships, and semantics.\nA class is not an object. It is an abstract definition of an object. It defines the structure and behavior of each object in the class.\n
A class is a description of a set of objects that share the same attributes, operations, relationships, and semantics.\nA class is not an object. It is an abstract definition of an object. It defines the structure and behavior of each object in the class.\n
A class is a description of a set of objects that share the same attributes, operations, relationships, and semantics.\nA class is not an object. It is an abstract definition of an object. It defines the structure and behavior of each object in the class.\n
A class is a description of a set of objects that share the same attributes, operations, relationships, and semantics.\nA class is not an object. It is an abstract definition of an object. It defines the structure and behavior of each object in the class.\n
les modeles ac compsants...\n\nC c’est clari la D dépend de ce qu’est l’évolution...\n
Image 4.png\n
[Philippe Bouvard]\n
\n
\n
\n
\n
\n
\n
les modules sont consideres comme des boites noires\n
\n
« Maintenance » n'est un pas terme très adapté car un logiciel informatique ne s'use pas comme une voiture, il faudrait plutôt parler d'adaptation ou de correction d'erreurs.\n
« Maintenance » n'est un pas terme très adapté car un logiciel informatique ne s'use pas comme une voiture, il faudrait plutôt parler d'adaptation ou de correction d'erreurs.\n
« Maintenance » n'est un pas terme très adapté car un logiciel informatique ne s'use pas comme une voiture, il faudrait plutôt parler d'adaptation ou de correction d'erreurs.\n
« Maintenance » n'est un pas terme très adapté car un logiciel informatique ne s'use pas comme une voiture, il faudrait plutôt parler d'adaptation ou de correction d'erreurs.\n
« Maintenance » n'est un pas terme très adapté car un logiciel informatique ne s'use pas comme une voiture, il faudrait plutôt parler d'adaptation ou de correction d'erreurs.\n
\n
\n
La maîtrise des processus d'élaboration du logiciel se décline en trois axes :\n Programming-in-the-Small, c'est à dire la maîtrise de la construction d'éléments de logiciels corrects. Comme nous allons le voir au paragraphe 1.2.1, ce n'est pas aussi simple que cela en a l'air.\n Programming-in-the-Large, c'est à dire la maîtrise de la complexité structurelle due à la taille des objets construits. Bien évidement, cette complexité n'est pas le propre de l'informatique : on retrouvera le même type de problèmes (et de solutions) partout où il faut gérer de grands projets, par exemple le génie civil.\n Programming-in-the-Variability, c'est à dire la maîtrise de la malléabilité du logiciel (l'aspect \n du software). Un système logiciel n'est en eet pas rigide, il évolue dans le temps (maintenance évolutive) et dans l'espace (variantes régionales ou fonctionnelles : c'est la notion de lignes de produits).\nAvant de voir ce qu'apporte l'approche objet dans la réalisation des systèmes logiciels, il convient de bien comprendre la nature des problèmes posés sur ces trois axes.\n
La maîtrise des processus d'élaboration du logiciel se décline en trois axes :\n Programming-in-the-Small, c'est à dire la maîtrise de la construction d'éléments de logiciels corrects. Comme nous allons le voir au paragraphe 1.2.1, ce n'est pas aussi simple que cela en a l'air.\n Programming-in-the-Large, c'est à dire la maîtrise de la complexité structurelle due à la taille des objets construits. Bien évidement, cette complexité n'est pas le propre de l'informatique : on retrouvera le même type de problèmes (et de solutions) partout où il faut gérer de grands projets, par exemple le génie civil.\n Programming-in-the-Variability, c'est à dire la maîtrise de la malléabilité du logiciel (l'aspect \n du software). Un système logiciel n'est en eet pas rigide, il évolue dans le temps (maintenance évolutive) et dans l'espace (variantes régionales ou fonctionnelles : c'est la notion de lignes de produits).\nAvant de voir ce qu'apporte l'approche objet dans la réalisation des systèmes logiciels, il convient de bien comprendre la nature des problèmes posés sur ces trois axes.\n
1.2.1 La programmation, c'est facile!\nIl semble que personne ne s'étonne de trouver sur les rayonnages des librairies de nombreux livres avec des titres accrocheurs du type Teach Yourself X in 24 hours ou\nX for complete dummies lorsque X est un langage de programmation ; alors qu'on a du\nmal à trouver l'équivalent lorsque X est quelque chose comme Brain Surgery ou Nuclear\nEngineering.\nIl s'agit du paradoxe bien connu qui existe entre l'apparente facilité de la programmation\nd'une petite application et la diculté de la construction de grands systèmes\ninformatiques, diculté qui avait donné naissance à la notion de ((crise du logiciel)) dès\nla n des années 1960. Ce paradoxe est sans doute lié à la diérence entre la simplicité\napparente du texte d'un programme et la l'infinie complexité potentielle de son exécution.\nSans même aller chercher jusqu'à Turing et les problèmes d'indécidabilité inhérent\nà l'informatique, on peut facilement exhiber [19] de très petits programmes ayant des\ncomportements inniment complexes, comme par exemple :\nEntrer un nombre naturel n ;\nTant que n est différent de 1 faire\nSi n est pair alors n := n/2 sinon n := (3n+1)/2 ;\nFait.\nNous invitons le lecteur qui voudrait se faire une idée de la complexité sous-jacente\nde ce programme à essayer de prouver qu'il se termine quelque soit le nombre qu'on\nlui donne en entrée. De manière générale, la vérication formelle de programmes informatiques,\nmême apparemment simples, peut se révéler dicile, voire impossible. Seule\nl'utilisation de techniques de construction systématique de programmes (fondées sur\nl'utilisation d'éléments de spécications formelles) permet de s'aranchir dans une certaine\nmesure de ces dicultés.\n
\n
1.2.1 La programmation, c'est facile!\nIl semble que personne ne s'étonne de trouver sur les rayonnages des librairies de nombreux livres avec des titres accrocheurs du type Teach Yourself X in 24 hours ou\nX for complete dummies lorsque X est un langage de programmation ; alors qu'on a du\nmal à trouver l'équivalent lorsque X est quelque chose comme Brain Surgery ou Nuclear\nEngineering.\nIl s'agit du paradoxe bien connu qui existe entre l'apparente facilité de la programmation\nd'une petite application et la diculté de la construction de grands systèmes\ninformatiques, diculté qui avait donné naissance à la notion de ((crise du logiciel)) dès\nla n des années 1960. Ce paradoxe est sans doute lié à la diérence entre la simplicité\napparente du texte d'un programme et la l'infinie complexité potentielle de son exécution.\nSans même aller chercher jusqu'à Turing et les problèmes d'indécidabilité inhérent\nà l'informatique, on peut facilement exhiber [19] de très petits programmes ayant des\ncomportements inniment complexes, comme par exemple :\nEntrer un nombre naturel n ;\nTant que n est différent de 1 faire\nSi n est pair alors n := n/2 sinon n := (3n+1)/2 ;\nFait.\nNous invitons le lecteur qui voudrait se faire une idée de la complexité sous-jacente\nde ce programme à essayer de prouver qu'il se termine quelque soit le nombre qu'on\nlui donne en entrée. De manière générale, la vérication formelle de programmes informatiques,\nmême apparemment simples, peut se révéler dicile, voire impossible. Seule\nl'utilisation de techniques de construction systématique de programmes (fondées sur\nl'utilisation d'éléments de spécications formelles) permet de s'aranchir dans une certaine\nmesure de ces dicultés.\n
Il apparaît donc qu'il est relativement simple d'écrire sur un coin de table un petit\nprogramme ((marchant à peu près)) (d'où le succès d'outils comme Visual Basic, Perl,\nTcl/Tk, etc.), alors qu'il est relativement coûteux, et donc pas toujours rentable, d'essayer\nd'obtenir d'un logiciel, surtout quand il possède une nature répartie, des qualités\nde correction, abilité, robustesse, etc.\nPratiquement n'importe qui est capable de construire la passerelle de la gure 1.2\nSEUL\n(a). De bons bricoleurs pourront aller plus loin (pont suspendu en (b)), mais déjà pour\nle petit pont en (c), cela demande plus de talent (et à l'échelle de l'humanité, cela a\ndemandé quelques milliers d'années d'évolution). \nQuant au Golden Gate (en 1.2 (d)),\nsa réalisation a demandé d'autre talents que le bricolage. En bref, pas plus qu'un grand\npont moderne n'est l'extrapolation d'une passerelle, ou un gratte-ciel celle d'une niche\nde chien bricolée, un grand logiciel ne s'obtient pas avec les mêmes méthodes qu'un\npetit programme.\n\n1.3.2 Gérer la complexité structurelle due à la taille\nOr, la taille des logiciels augmente de manière exponentielle : elle est multipliée par\n10 tous les 10 ans parce que les systèmes qu'on développe sont de plus en plus complexes\n(voir gure 1.3).\nSi l'automobile avait suivi le même développement que l'ordinateur, une\nRolls-Royce coûterait aujourd'hui 100$, pourrait rouler un million de kilom\nètres avec un litre d'essence, et exploserait une fois par an en tuant tout\nle monde à bord. Robert Cringely.\nMême si en moyenne le sort des projets informatiques n'est pas particulièrement\nbrillant (voir gure 1.4), chaque décennie, on a donc trouvé le moyen de gagner un\nordre de grandeur sur la complexité de ce qu'on savait faire, ce qui comparé à d'autres\ndomaines n'est pas si mal!\nPour maîtriser cette complexité, on a abordé le problème à la fois sur un plan\ntechnique et organisationnel.\n
\n
pas forcément un bon critère\non peut prendre les specifications, les docs, ...\n\n10^8 = 100 million vista derrier est plus petit...\n
Réseau de téléphone longue distance d’AT&T (1990)\n􀂄 9 heures d’interruption de service\n􀂄 Mauvais placement d’une instruction break en C\n􀂄 La syntaxe concrète importe !\n􀂄 Défaut de test\n􀂄 La duplication des commutateurs n’a encore servi à rien,\npuisque les secondaires exécutaient le même programme que\nles primaires\n\nAréoport de Denver, 1994:\nSystème « pharaonique »\n􀂄 4000 véhicules (telecars),\n3 terminaux, plus de 30 km\nde circuit, 300 ordinateurs\n􀂄 193 M$ (12 % du coût total)\n􀂄 Toutes les compagnies\ndevaient être desservies\nChaos total lors des tests\n􀂄 Bagages détruits (même\n« mâchés » !)\n􀂄 Crashes, collisions,\ndétérioration des rails…\n􀂄 Blocage des telecars par les\nbagages qu’ils détruisaient…\n\n\nSystème de téléphone des USA (1991)\n􀂄 Perturbation des communications à Los Angeles, San Franciso,\nWashington, Baltimore…\n􀂄 Des millions d’abonnés mécontents\n􀂄 Trois (3 !) lignes de code modifiées sur plusieurs millions, pas la\npeine de tester, n’est-ce pas ? D’autant plus que la première\nphase de test avait duré 13 semaines et que le client n’est pas\ndisposé à attendre une seconde fois…\n􀂄 Absence de test de non-régression\n\n\n(suite 1)\n􀂄 Une erreur de conversion\n(overflow) 64 bits →\n16 bits\ndans un module (IRS) chargé\nd’estimer l’accélération et la\nvitesse provoque une exception\nAda pour laquelle il n’est prévue\naucun « handler »\n􀂄 Le système interprète les données\nde l’exception comme des\ndonnées normales (aberrantes\névidemment)\n􀂄 Le module qui a levé l’exception avait tourné de manière\nsatisfaisante pendant 10 ans sur Ariane 4\n􀂄 On savait qu’il n’y a pas d’overflow avec Ariane 4\n􀂄 Mais la dynamique d’Ariane 5 est différente !\n􀂄 Une simple simulation aurait révélé le problème…\n􀂄 Comble d’ironie, le module en question était inutile à cette\nphase du vol !\n􀂄 Enfin le système IRS était doublé, mais les deux calculateurs\nexécutaient le même programme : l’exception a donc\nsimplement été levée deux fois !\n\n\n\nTherapy planning software created by the U.S. firm Multidata Systems International, allows the therapist to interactively 'draw' on a computer screen and decide upon the placement of metal shields designed to protect healthy tissue from radiation when being treated with a Cobalt-60 radiotherapy machine. A problem arises in that the software will only allow the placement of four shields and the doctors want to use five. To get around this they discover that they can draw only one block with a hole it in to get (what they believe) will be the same shielding effect. However, due to a bug in the software, if the hole is drawn in one way, the correct dose of radiotherapy is calculated, but if drawn in another way, a double dose is calculated and delivered. According to the International Atomic Energy Agency (IAEA) in 2001, at least five patients die and another 15 developed serious health problems as a direct consequence of the bug. The three doctors, who failed to double check the software calculations are charged with second-degree murder!\n
\n
"… only 28 percent of software projects in 2000 succeeded outright …" (2) \n"… Some 23 percent were cancelled, and the remainder were substantially late …"(2) \nThe following statistics are a result of the year 2000 \n\nStandish Group in 2005 \n\n\n1) Chartier-Kastler. Et même 70% d’après le DoD en 1988.\n3) Jones, 94 \n4) En fait, le retard est en général proportionnel à la taille du projet.\n\nLes erreurs classiques sont les suivantes:\n1) humaines\nmanque de motivation, personnel sous-qualifié, personnes à problèmes insurmontables, héroïsme (prise de risques extrêmes), augmentation d’effectif sur un projet en retard, conditions de travail (bureau bruyant), friction entre développeurs et clients, exigences irréalistes, absence de soutien au projet.\n2) procédures\nPlanification insuffisante, ou trop optimiste, abandonnée sous la pression. Sous-estimation des étapes en amont du projet, négligence de la qualité (tests superficiels), défaillance de la sous-traitance.\n3) produit\nExcès de spécifications, instabilité des fonctionnalités demandées, excès de zèle des programmeurs, surenchères (planning assoupli en échange de fonctionnalités nouvelles), développement axé recherche.\n4) technologie\nCroyance aux techniques miracles, ou surestimation, changement d’outils en cours de route, mauvaise gestion de configuration.\n
\n
\n
Notion de ligne de produits\n Anticiper des familles de besoins\n
\n
Approche modulaire et hiérarchique\n Permet de gérer toute taille de problème\n
remplacer starttime et endtime par currentTime\n
\n
\n
\n
\n
La construction d’un logiciel est une suite d’itérations du genre division réunion decomposer pour comprendre\nRéunir pour construire.\nLa decomposition est traditionnelement dirigée par les fonctionnalités\nLA COMPOSITION EST ALORS gérée par la hierarchie et la fonction.\n\nExemple de découpe fonctionnelle d'un logiciel dédié à la gestion d'une bibliothèque : \nLe logiciel est composé d'une hiérarchie de fonctions, qui ensemble, fournissent les services désirés, ainsi que de données qui représentent les éléments manipulés (livres, etc…). Logique, cohérent et intuitif.\n\n\nLe "plus" de l'approche fonctionnelle : la factorisation des comportementsUne découpe fonctionnelle "intelligente" consiste à factoriser certains comportements communs du logiciel. En d'autres termes : pour réaliser une fonction du logiciel, on peut utiliser un ensemble d'autres fonctions, déjà disponibles, pour peu qu'on rende ces dernières un tant soit peu génériques. Génial !\n
La fonction induit la structure.\nFactoriser les comportements n'a malheureusement pas que des avantages. Les fonctions sont devenues interd&#xE9;pendantes&#xA0;: une simple mise &#xE0; jour du logiciel &#xE0; un point donn&#xE9;, peut impacter en cascade une multitude d'autres fonctions. On peut minorer cet impact, pour peu qu'on utilise des fonctions plus g&#xE9;n&#xE9;riques et des structures de donn&#xE9;es ouvertes. Mais respecter ces contraintes rend l'&#xE9;criture du logiciel et sa maintenance plus complexe.En cas d'&#xE9;volution majeure du logiciel (passage de la gestion d'une biblioth&#xE8;que &#xE0; celle d'une m&#xE9;diath&#xE8;que par exemple), le sc&#xE9;nario est encore pire. M&#xEA;me si la structure g&#xE9;n&#xE9;rale du logiciel reste valide, la multiplication des points de maintenance, engendr&#xE9;e par le cha&#xEE;nage des fonctions, rend l'adaptation tr&#xE8;s laborieuse. Le logiciel doit &#xEA;tre retouch&#xE9; dans sa globalit&#xE9;&#xA0;:\nExaminons le probl&#xE8;me de l'&#xE9;volution de code fonctionnel plus en d&#xE9;tail...Faire &#xE9;voluer une application de gestion de biblioth&#xE8;que pour g&#xE9;rer une m&#xE9;diath&#xE8;que, afin de prendre en compte de nouveaux types d'ouvrages (cassettes vid&#xE9;o, CD-ROM, etc...), n&#xE9;cessite :\nde faire &#xE9;voluer les structures de donn&#xE9;es qui sont manipul&#xE9;es par les fonctions, \nd'adapter les traitements, qui ne manipulaient &#xE0; l'origine qu'un seul type de document (des livres). \nIl faudra donc modifier toutes les portions de code qui utilisent la base documentaire, pour g&#xE9;rer les donn&#xE9;es et les actions propres aux diff&#xE9;rents types de documents.Il faudra par exemple modifier la fonction qui r&#xE9;alise l'&#xE9;dition des "lettres de rappel" (une lettre de rappel est une mise en demeure, qu'on envoie automatiquement aux personnes qui tardent &#xE0; rendre un ouvrage emprunt&#xE9;). Si l'on d&#xE9;sire que le d&#xE9;lai avant rappel varie selon le type de document emprunt&#xE9;, il faut pr&#xE9;voir une r&#xE8;gle de calcul pour chaque type de document.En fait, c'est la quasi-totalit&#xE9;&#xA0;de l'application qui devra &#xEA;tre adapt&#xE9;e, pour g&#xE9;rer les nouvelles donn&#xE9;es et r&#xE9;aliser les traitements correspondants. Et cela, &#xE0; chaque fois qu'on d&#xE9;cidera de g&#xE9;rer un nouveau type de document&#xA0;!&#xA0;\n&#xA0;\nstruct Document{&#xA0; char nom_doc[50];&#xA0; Type_doc type;&#xA0; Bool est_emprunte;&#xA0; char emprunteur[50];&#xA0; struct tm date_emprunt;} DOC[MAX_DOCS]; &#xA0;\n&#xA0;\nvoid lettres_de_rappel(){&#xA0; /* ... */&#xA0; for (i = 0; i < NB_DOCS; i++)&#xA0; {&#xA0; &#xA0; if (DOC[i].est_emprunte)&#xA0; &#xA0; {&#xA0; &#xA0; &#xA0; switch(DOC[i].type)&#xA0; &#xA0; &#xA0; {&#xA0; &#xA0; &#xA0; case LIVRE:&#xA0; &#xA0; &#xA0; &#xA0; delai_avant_rappel = 20;&#xA0; &#xA0; &#xA0; &#xA0; break;&#xA0; &#xA0; &#xA0; case CASSETTE_VIDEO:&#xA0; &#xA0; &#xA0; &#xA0; delai_avant_rappel = 7;&#xA0; &#xA0; &#xA0; &#xA0;&#xA0;break;&#xA0; &#xA0; &#xA0; case CD_ROM:&#xA0; &#xA0; &#xA0; &#xA0;&#xA0;delai_avant_rappel = 5;&#xA0; &#xA0; &#xA0; &#xA0;&#xA0;break;&#xA0; &#xA0; &#xA0; }&#xA0; &#xA0; }&#xA0; }/* ... */} &#xA0;\n&#xA0; &#xA0;void mettre_a_jour(int ref)&#xA0; &#xA0;{&#xA0; &#xA0; &#xA0;/* ... */&#xA0; &#xA0; &#xA0;switch(DOC[ref].type)&#xA0; &#xA0; &#xA0;{&#xA0; &#xA0; &#xA0; &#xA0;case LIVRE:&#xA0; &#xA0; &#xA0; &#xA0; &#xA0;maj_livre(DOC[ref]);&#xA0; &#xA0; &#xA0; &#xA0; &#xA0;break;&#xA0; &#xA0; &#xA0; &#xA0;case CASSETTE_VIDEO:&#xA0; &#xA0; &#xA0; &#xA0; &#xA0;maj_k7(DOC[ref]);&#xA0; &#xA0; &#xA0; &#xA0; &#xA0;break;&#xA0; &#xA0; &#xA0; &#xA0;case CD_ROM:&#xA0; &#xA0; &#xA0; &#xA0; &#xA0;maj_cd(DOC[ref]);&#xA0; &#xA0; &#xA0; &#xA0; &#xA0;break;&#xA0; &#xA0; &#xA0;}&#xA0; &#xA0; &#xA0;/* ... */&#xA0; &#xA0;} \n\n&#xF071;&#xA0;\n1&#xE8;re am&#xE9;lioration : rassembler les valeurs qui caract&#xE9;risent un type, dans le typeUne solution relativement &#xE9;l&#xE9;gante &#xE0; la multiplication des branches conditionnelles et des redondances dans le code (cons&#xE9;quence logique d'une trop grande ouverture des donn&#xE9;es), consiste tout simplement &#xE0; centraliser dans les structures de donn&#xE9;es, les valeurs qui leurs sont propres&#xA0;:&#xA0;\nstruct Document{&#xA0; char nom_doc[50];&#xA0; Type_doc type;&#xA0; Bool est_emprunte;&#xA0; char emprunteur[50];&#xA0; struct tm date_emprunt;&#xA0; int delai_avant_rappel;} DOC[MAX_DOCS]; &#xA0;\nvoid lettres_de_rappel(){&#xA0; /* ... */&#xA0; for (i = 0; i < NB_DOCS; i++)&#xA0; {&#xA0; &#xA0; if (DOC[i].est_emprunte) /* SI LE DOC EST EMPRUNTE */&#xA0; &#xA0; {&#xA0; &#xA0; &#xA0; /* IMPRIME UNE LETTRE SI SON&#xA0; &#xA0; &#xA0; DELAI DE RAPPEL EST DEPASSE */&#xA0; &#xA0; &#xA0; if (date() >= (DOC[i].date_emprunt + DOC[i].delai_avant_rappel))&#xA0; &#xA0; &#xA0; &#xA0; &#xA0; imprimer_rappel(DOC[i]);&#xA0; &#xA0; }&#xA0; }}Quoi de plus logique ? En effet, le "d&#xE9;lai avant &#xE9;dition d'une lettre de rappel" est bien une caract&#xE9;ristique propre &#xE0; tous les ouvrages g&#xE9;r&#xE9;s par notre application. Mais cette solution n'est pas encore optimale !&#xA0;\n&#xA0;\n&#xF071;&#xA0;\n2&#xE8;me am&#xE9;lioration : centraliser les traitements associ&#xE9;s &#xE0; un type, aupr&#xE8;s du typePourquoi ne pas aussi rassembler dans une m&#xEA;me unit&#xE9; physique les types de donn&#xE9;es et tous les traitements associ&#xE9;s ?Que se passerait-il par exemple si l'on centralisait dans un m&#xEA;me fichier, la structure de donn&#xE9;es qui d&#xE9;crit les documents et la fonction de calcul du d&#xE9;lai avant rappel ? Cela nous permettrait de retrouver en un clin d'oeil le bout de code qui est charg&#xE9; de calculer le d&#xE9;lai avant rappel d'un document, puisqu'il se trouve au plus pr&#xE8;s de la structure de donn&#xE9;es concern&#xE9;e.Ainsi, si notre m&#xE9;diath&#xE8;que devait g&#xE9;rer un nouveau type d'ouvrage, il suffirait de modifier une seule fonction (qu'on sait retrouver instann&#xE9;ment), pour assurer la prise en compte de ce nouveau type de document dans le calcul du d&#xE9;lai avant rappel. Plus besoin de fouiller partout dans le code...&#xA0;\nstruct Document{&#xA0; char nom_doc[50];&#xA0; Type_doc type;&#xA0; Bool est_emprunte;&#xA0; char emprunteur[50];&#xA0; struct tm date_emprunt;&#xA0; int delai_avant_rappel;} DOC[MAX_DOCS];&#xA0; int calculer_delai_rappel(Type_doc type){&#xA0; switch(type)&#xA0; {&#xA0; &#xA0; case LIVRE:&#xA0; &#xA0; &#xA0; return 20;&#xA0; &#xA0; case CASSETTE_VIDEO:&#xA0; &#xA0; &#xA0; return 7;&#xA0; &#xA0; case CD_ROM:&#xA0; &#xA0; &#xA0; return 5;&#xA0; &#xA0; /* autres "case" bienvenus ici ! */&#xA0; }} \nEcrit en ces termes, notre logiciel sera plus facile &#xE0; maintenir et bien plus lisible. Le stockage et le calcul du d&#xE9;lai avant rappel des documents, est d&#xE9;sormais assur&#xE9; par une seule et unique unit&#xE9; physique (quelques lignes de code, rapidement identifiables).Pour acc&#xE9;der &#xE0; la caract&#xE9;ristique "d&#xE9;lai avant rappel" d'un document, il suffit de r&#xE9;cup&#xE9;rer la valeur correspondante parmi les champs qui d&#xE9;crivent le document. Pour assurer la prise en compte d'un nouveau type de document dans le calcul du d&#xE9;lai avant rappel, il suffit de modifier une seule fonction, situ&#xE9;e au m&#xEA;me endroit que la structure de donn&#xE9;es qui d&#xE9;crit les documents :&#xA0;\nvoid ajouter_document(int ref){&#xA0; DOC[ref].est_emprunte = FAUX;&#xA0; DOC[ref].nom_doc = saisir_nom();&#xA0; DOC[ref].type = saisir_type();&#xA0; DOC[ref].delai_avant_rappel = calculer_delai_rappel(DOC[ref].type);}void afficher_document(int ref){&#xA0; printf("Nom du document: %s\\n",DOC[ref].nom_doc);&#xA0; /* ... */&#xA0; printf("Delai avant rappel: %d jours\\n",DOC[ref].delai_avant_rappel);&#xA0; /* ... */}\n
La fonction induit la structure.\nFactoriser les comportements n'a malheureusement pas que des avantages. Les fonctions sont devenues interd&#xE9;pendantes&#xA0;: une simple mise &#xE0; jour du logiciel &#xE0; un point donn&#xE9;, peut impacter en cascade une multitude d'autres fonctions. On peut minorer cet impact, pour peu qu'on utilise des fonctions plus g&#xE9;n&#xE9;riques et des structures de donn&#xE9;es ouvertes. Mais respecter ces contraintes rend l'&#xE9;criture du logiciel et sa maintenance plus complexe.En cas d'&#xE9;volution majeure du logiciel (passage de la gestion d'une biblioth&#xE8;que &#xE0; celle d'une m&#xE9;diath&#xE8;que par exemple), le sc&#xE9;nario est encore pire. M&#xEA;me si la structure g&#xE9;n&#xE9;rale du logiciel reste valide, la multiplication des points de maintenance, engendr&#xE9;e par le cha&#xEE;nage des fonctions, rend l'adaptation tr&#xE8;s laborieuse. Le logiciel doit &#xEA;tre retouch&#xE9; dans sa globalit&#xE9;&#xA0;:\nExaminons le probl&#xE8;me de l'&#xE9;volution de code fonctionnel plus en d&#xE9;tail...Faire &#xE9;voluer une application de gestion de biblioth&#xE8;que pour g&#xE9;rer une m&#xE9;diath&#xE8;que, afin de prendre en compte de nouveaux types d'ouvrages (cassettes vid&#xE9;o, CD-ROM, etc...), n&#xE9;cessite :\nde faire &#xE9;voluer les structures de donn&#xE9;es qui sont manipul&#xE9;es par les fonctions, \nd'adapter les traitements, qui ne manipulaient &#xE0; l'origine qu'un seul type de document (des livres). \nIl faudra donc modifier toutes les portions de code qui utilisent la base documentaire, pour g&#xE9;rer les donn&#xE9;es et les actions propres aux diff&#xE9;rents types de documents.Il faudra par exemple modifier la fonction qui r&#xE9;alise l'&#xE9;dition des "lettres de rappel" (une lettre de rappel est une mise en demeure, qu'on envoie automatiquement aux personnes qui tardent &#xE0; rendre un ouvrage emprunt&#xE9;). Si l'on d&#xE9;sire que le d&#xE9;lai avant rappel varie selon le type de document emprunt&#xE9;, il faut pr&#xE9;voir une r&#xE8;gle de calcul pour chaque type de document.En fait, c'est la quasi-totalit&#xE9;&#xA0;de l'application qui devra &#xEA;tre adapt&#xE9;e, pour g&#xE9;rer les nouvelles donn&#xE9;es et r&#xE9;aliser les traitements correspondants. Et cela, &#xE0; chaque fois qu'on d&#xE9;cidera de g&#xE9;rer un nouveau type de document&#xA0;!&#xA0;\n&#xA0;\nstruct Document{&#xA0; char nom_doc[50];&#xA0; Type_doc type;&#xA0; Bool est_emprunte;&#xA0; char emprunteur[50];&#xA0; struct tm date_emprunt;} DOC[MAX_DOCS]; &#xA0;\n&#xA0;\nvoid lettres_de_rappel(){&#xA0; /* ... */&#xA0; for (i = 0; i < NB_DOCS; i++)&#xA0; {&#xA0; &#xA0; if (DOC[i].est_emprunte)&#xA0; &#xA0; {&#xA0; &#xA0; &#xA0; switch(DOC[i].type)&#xA0; &#xA0; &#xA0; {&#xA0; &#xA0; &#xA0; case LIVRE:&#xA0; &#xA0; &#xA0; &#xA0; delai_avant_rappel = 20;&#xA0; &#xA0; &#xA0; &#xA0; break;&#xA0; &#xA0; &#xA0; case CASSETTE_VIDEO:&#xA0; &#xA0; &#xA0; &#xA0; delai_avant_rappel = 7;&#xA0; &#xA0; &#xA0; &#xA0;&#xA0;break;&#xA0; &#xA0; &#xA0; case CD_ROM:&#xA0; &#xA0; &#xA0; &#xA0;&#xA0;delai_avant_rappel = 5;&#xA0; &#xA0; &#xA0; &#xA0;&#xA0;break;&#xA0; &#xA0; &#xA0; }&#xA0; &#xA0; }&#xA0; }/* ... */} &#xA0;\n&#xA0; &#xA0;void mettre_a_jour(int ref)&#xA0; &#xA0;{&#xA0; &#xA0; &#xA0;/* ... */&#xA0; &#xA0; &#xA0;switch(DOC[ref].type)&#xA0; &#xA0; &#xA0;{&#xA0; &#xA0; &#xA0; &#xA0;case LIVRE:&#xA0; &#xA0; &#xA0; &#xA0; &#xA0;maj_livre(DOC[ref]);&#xA0; &#xA0; &#xA0; &#xA0; &#xA0;break;&#xA0; &#xA0; &#xA0; &#xA0;case CASSETTE_VIDEO:&#xA0; &#xA0; &#xA0; &#xA0; &#xA0;maj_k7(DOC[ref]);&#xA0; &#xA0; &#xA0; &#xA0; &#xA0;break;&#xA0; &#xA0; &#xA0; &#xA0;case CD_ROM:&#xA0; &#xA0; &#xA0; &#xA0; &#xA0;maj_cd(DOC[ref]);&#xA0; &#xA0; &#xA0; &#xA0; &#xA0;break;&#xA0; &#xA0; &#xA0;}&#xA0; &#xA0; &#xA0;/* ... */&#xA0; &#xA0;} \n\n&#xF071;&#xA0;\n1&#xE8;re am&#xE9;lioration : rassembler les valeurs qui caract&#xE9;risent un type, dans le typeUne solution relativement &#xE9;l&#xE9;gante &#xE0; la multiplication des branches conditionnelles et des redondances dans le code (cons&#xE9;quence logique d'une trop grande ouverture des donn&#xE9;es), consiste tout simplement &#xE0; centraliser dans les structures de donn&#xE9;es, les valeurs qui leurs sont propres&#xA0;:&#xA0;\nstruct Document{&#xA0; char nom_doc[50];&#xA0; Type_doc type;&#xA0; Bool est_emprunte;&#xA0; char emprunteur[50];&#xA0; struct tm date_emprunt;&#xA0; int delai_avant_rappel;} DOC[MAX_DOCS]; &#xA0;\nvoid lettres_de_rappel(){&#xA0; /* ... */&#xA0; for (i = 0; i < NB_DOCS; i++)&#xA0; {&#xA0; &#xA0; if (DOC[i].est_emprunte) /* SI LE DOC EST EMPRUNTE */&#xA0; &#xA0; {&#xA0; &#xA0; &#xA0; /* IMPRIME UNE LETTRE SI SON&#xA0; &#xA0; &#xA0; DELAI DE RAPPEL EST DEPASSE */&#xA0; &#xA0; &#xA0; if (date() >= (DOC[i].date_emprunt + DOC[i].delai_avant_rappel))&#xA0; &#xA0; &#xA0; &#xA0; &#xA0; imprimer_rappel(DOC[i]);&#xA0; &#xA0; }&#xA0; }}Quoi de plus logique ? En effet, le "d&#xE9;lai avant &#xE9;dition d'une lettre de rappel" est bien une caract&#xE9;ristique propre &#xE0; tous les ouvrages g&#xE9;r&#xE9;s par notre application. Mais cette solution n'est pas encore optimale !&#xA0;\n&#xA0;\n&#xF071;&#xA0;\n2&#xE8;me am&#xE9;lioration : centraliser les traitements associ&#xE9;s &#xE0; un type, aupr&#xE8;s du typePourquoi ne pas aussi rassembler dans une m&#xEA;me unit&#xE9; physique les types de donn&#xE9;es et tous les traitements associ&#xE9;s ?Que se passerait-il par exemple si l'on centralisait dans un m&#xEA;me fichier, la structure de donn&#xE9;es qui d&#xE9;crit les documents et la fonction de calcul du d&#xE9;lai avant rappel ? Cela nous permettrait de retrouver en un clin d'oeil le bout de code qui est charg&#xE9; de calculer le d&#xE9;lai avant rappel d'un document, puisqu'il se trouve au plus pr&#xE8;s de la structure de donn&#xE9;es concern&#xE9;e.Ainsi, si notre m&#xE9;diath&#xE8;que devait g&#xE9;rer un nouveau type d'ouvrage, il suffirait de modifier une seule fonction (qu'on sait retrouver instann&#xE9;ment), pour assurer la prise en compte de ce nouveau type de document dans le calcul du d&#xE9;lai avant rappel. Plus besoin de fouiller partout dans le code...&#xA0;\nstruct Document{&#xA0; char nom_doc[50];&#xA0; Type_doc type;&#xA0; Bool est_emprunte;&#xA0; char emprunteur[50];&#xA0; struct tm date_emprunt;&#xA0; int delai_avant_rappel;} DOC[MAX_DOCS];&#xA0; int calculer_delai_rappel(Type_doc type){&#xA0; switch(type)&#xA0; {&#xA0; &#xA0; case LIVRE:&#xA0; &#xA0; &#xA0; return 20;&#xA0; &#xA0; case CASSETTE_VIDEO:&#xA0; &#xA0; &#xA0; return 7;&#xA0; &#xA0; case CD_ROM:&#xA0; &#xA0; &#xA0; return 5;&#xA0; &#xA0; /* autres "case" bienvenus ici ! */&#xA0; }} \nEcrit en ces termes, notre logiciel sera plus facile &#xE0; maintenir et bien plus lisible. Le stockage et le calcul du d&#xE9;lai avant rappel des documents, est d&#xE9;sormais assur&#xE9; par une seule et unique unit&#xE9; physique (quelques lignes de code, rapidement identifiables).Pour acc&#xE9;der &#xE0; la caract&#xE9;ristique "d&#xE9;lai avant rappel" d'un document, il suffit de r&#xE9;cup&#xE9;rer la valeur correspondante parmi les champs qui d&#xE9;crivent le document. Pour assurer la prise en compte d'un nouveau type de document dans le calcul du d&#xE9;lai avant rappel, il suffit de modifier une seule fonction, situ&#xE9;e au m&#xEA;me endroit que la structure de donn&#xE9;es qui d&#xE9;crit les documents :&#xA0;\nvoid ajouter_document(int ref){&#xA0; DOC[ref].est_emprunte = FAUX;&#xA0; DOC[ref].nom_doc = saisir_nom();&#xA0; DOC[ref].type = saisir_type();&#xA0; DOC[ref].delai_avant_rappel = calculer_delai_rappel(DOC[ref].type);}void afficher_document(int ref){&#xA0; printf("Nom du document: %s\\n",DOC[ref].nom_doc);&#xA0; /* ... */&#xA0; printf("Delai avant rappel: %d jours\\n",DOC[ref].delai_avant_rappel);&#xA0; /* ... */}\n
\n
\n
\n
\n
\n
\n
\n
Un mod&#xE8;le est une abstraction de la r&#xE9;alit&#xE9;L'abstraction est un des piliers de l'approche objet.&#xA0; \nIl s'agit d'un processus qui consiste &#xE0; identifier les caract&#xE9;ristiques int&#xE9;ressantes d'une entit&#xE9;, en vue d'une utilisation pr&#xE9;cise. \nL'abstraction d&#xE9;signe aussi le r&#xE9;sultat de ce processus, c'est-&#xE0;-dire l'ensemble des caract&#xE9;ristiques essentielles d'une entit&#xE9;, retenues par un observateur.&#xA0; \nUn mod&#xE8;le est une vue subjective mais pertinente de la r&#xE9;alit&#xE9;&#xA0; \nUn mod&#xE8;le d&#xE9;finit une fronti&#xE8;re entre la r&#xE9;alit&#xE9; et la perspective de l'observateur. Ce n'est pas "la r&#xE9;alit&#xE9;", mais une vue tr&#xE8;s subjective de la r&#xE9;alit&#xE9;. \nBien qu'un mod&#xE8;le ne repr&#xE9;sente pas une r&#xE9;alit&#xE9; absolue, un mod&#xE8;le refl&#xE8;te des aspects importants de la r&#xE9;alit&#xE9;, il en donne donc une vue juste et pertinente.&#xA0; \nQuelques exemples de mod&#xE8;les&#xA0; \nMod&#xE8;le m&#xE9;t&#xE9;orologique :&#xE0; partir de donn&#xE9;es d'observation (satellite ...), permet de pr&#xE9;voir les conditions climatiques pour les jours &#xE0; venir. \nMod&#xE8;le &#xE9;conomique&#xA0;:peut par exemple permettre de simuler l'&#xE9;volution de cours boursiers en fonction d'hypoth&#xE8;ses macro-&#xE9;conomiques (&#xE9;volution du ch&#xF4;mage, taux de croissance...). \nMod&#xE8;le d&#xE9;mographique&#xA0;:d&#xE9;finit la composition d'un panel d'une population et son comportement, dans le but de fiabiliser des &#xE9;tudes statistiques, d'augmenter l'impact de d&#xE9;marches commerciales, etc...&#xA0; \nCaract&#xE9;ristiques fondamentales des mod&#xE8;lesLe caract&#xE8;re abstrait d'un mod&#xE8;le doit notamment permettre&#xA0;:&#xA0; \nde faciliter la compr&#xE9;hension du syst&#xE8;me &#xE9;tudi&#xE9;> Un mod&#xE8;le r&#xE9;duit la complexit&#xE9; du syst&#xE8;me &#xE9;tudi&#xE9;. \nde simuler le syst&#xE8;me &#xE9;tudi&#xE9;> Un mod&#xE8;le repr&#xE9;sente le syst&#xE8;me &#xE9;tudi&#xE9; et reproduit ses comportements. \nUn mod&#xE8;le r&#xE9;duit (d&#xE9;compose) la r&#xE9;alit&#xE9;, dans le but de disposer d'&#xE9;l&#xE9;ments de travail exploitables par des moyens math&#xE9;matiques ou informatiques&#xA0;:mod&#xE8;le / r&#xE9;alit&#xE9; ~ &#xA0;digital / analogique \n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
POO : programmation orient&#xE9; objet.\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
La communication est fondamentale dans un projet. On ne va pas lire des milliers de lignes de code pour comprendre ce que les autres font !\nLa big picture: comprendre vite un projet: fonctionnalit&#xE9;s attendues, architecture du syst&#xE8;me, patterns&#x2026;\nContinuer son apprentissge OO: transmettre le savoir grace &#xE0; un langage adapt&#xE9;...\n\n UML : Support des syst&#xE8;mes concurrents et r&#xE9;partis, &#xE0; base de composants\n
\n
Attention &#xE0; la diff&#xE9;rence entre langage de mod&#xE9;lisation et m&#xE9;thode\nM&#xE9;thode: l&#xA0;&#x2019;utilisateur sait ce qu&#xA0;&#x2019;il a &#xE0; faire, comment le faire, quand le faire et pourquoi il faut le faire. Les m&#xE9;thodes utilisent des mod&#xE8;les pour d&#xE9;crire un point particulier.\nLangage de mod&#xE9;lisation d&#xE9;crit les symboles utilis&#xE9; par un mod&#xE8;les et les r&#xE8;gles d&#xA0;&#x2019;&#xE9;criture li&#xE9;s &#xE0; ces symboles.\nUn langage de mod&#xE9;lisation ne d&#xE9;finit donc pas de proc&#xE9;d&#xE9;s.\nUML est un donc un m&#xE9;ta-langage de mod&#xE9;lisation utilis&#xA0;&#xE9; pour d&#xE9;crire des langages de mod&#xE9;lisation.\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
M&#xEA;me si l'Esp&#xE9;ranto est une utopie, la n&#xE9;cessit&#xE9; de s'accorder sur des modes d'expression communs est vitale en informatique. UML n&#xA0;'est pas &#xE0; l'origine des concepts objets, mais en constitue une &#xE9;tape majeure, car il unifie les diff&#xE9;rentes approches et en donne une d&#xE9;finition plus formelle.\n2) Les auteurs d'UML sont tout &#xE0; fait conscients de l'importance du processus, mais l'acceptabilit&#xE9; industrielle de la mod&#xE9;lisation objet passe d'abord par la disponibilit&#xE9; d'un langage d'analyse objet performant et standard. \n\n Or, l'int&#xE9;gration d'UML dans un processus n'est pas triviale et am&#xE9;liorer un processus est une t&#xE2;che complexe et longue.\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
Pr&#xE9;-&#xE9;tude : D&#xE9;finition de la port&#xE9;e du projet et d&#xE9;veloppement des cas \n&#x2022;&#x202F; Vision : Glossaire, D&#xE9;termination des parties prenantes et des utilisateurs, D&#xE9;termination \nde leurs besoins, Besoins fonctionnels et non fonctionnels, Contraintes de conception \n&#x2022;&#x202F; Elaboration : Planification du projet, sp&#xE9;cification des caract&#xE9;ristiques, des fondements de \nl&#x2019;architecture \n&#x2022;&#x202F; Architecture : Document d&#x2019;architecture Logicielle, Diff&#xE9;rentes vues selon la partie \nprenante, Une architecture candidate, Comportement et conception des composants du \nsyst&#xE8;me \n&#x2022;&#x202F; Construction : Construction du produit \n&#x2022;&#x202F; Transition : Pr&#xE9;paration du produit pour les utilisateurs \n\n\n
\n
\n
Pr&#xE9;sentationL&#x2019;objectif principal d&#x2019;un syst&#xE8;me logiciel est de rendre service &#xE0; ses utilisateurs ; il faut par cons&#xE9;quent bien comprendre les d&#xE9;sirs et les besoins des futurs utilisateurs. Le processus de d&#xE9;veloppement sera donc centr&#xE9; sur l'utilisateur. Le terme utilisateur ne d&#xE9;signe pas seulement les utilisateurs humains mais &#xE9;galement les autres syst&#xE8;mes. L&#x2019;utilisateur repr&#xE9;sente donc une personne ou une chose dialoguant avec le syst&#xE8;me en cours de d&#xE9;veloppement.\nLes cas d&#x2019;utilisation font appara&#xEE;tre les besoins fonctionnels et leur ensemble constitue le mod&#xE8;le des cas d&#x2019;utilisation qui d&#xE9;crit les fonctionnalit&#xE9;s compl&#xE8;tes du syst&#xE8;me.\n\nStrat&#xE9;gie des cas d&#x2019;utilisationQue doit pouvoir faire le syst&#xE8;me pour chaque utilisateur ?Les cas d&#x2019;utilisation ne sont pas un simple outil de sp&#xE9;cification des besoins du syst&#xE8;me. Ilsvont compl&#xE8;tement guider le processus de d&#xE9;veloppement &#xE0; travers l&#x2019;utilisation de mod&#xE8;lesbas&#xE9;s sur l&#x2019;utilisation du langage UM\n\nA partir du mod&#xE8;le des cas d&#x2019;utilisation, les d&#xE9;veloppeurs cr&#xE9;ent une s&#xE9;rie de mod&#xE8;les de conception et d&#x2019;impl&#xE9;mentation r&#xE9;alisant les cas d&#x2019;utilisation. Chacun des mod&#xE8;les successifs est ensuite r&#xE9;vis&#xE9; pour en contr&#xF4;ler la conformit&#xE9; par rapport au mod&#xE8;le des cas d&#x2019;utilisation.\nEnfin, les testeurs testent l&#x2019;impl&#xE9;mentation pour s&#x2019;assurer que les composants du mod&#xE8;le d&#x2019;impl&#xE9;mentation mettent correctement en &#x153;uvre les cas d&#x2019;utilisation. Les cas d&#x2019;utilisation garantissent la coh&#xE9;rence du processus de d&#xE9;veloppement du syst&#xE8;me. S&#x2019;il est vrai que les cas d&#x2019;utilisation guident le processus de d&#xE9;veloppement, ils ne sont pas s&#xE9;lectionn&#xE9;s de fa&#xE7;on isol&#xE9;e, mais doivent absolument &#xEA;tre d&#xE9;velopp&#xE9;s "en tandem" avec l&#x2019;architecture du syst&#xE8;me.\n\nLe processus unifi&#xE9; est centr&#xE9; sur l&#x2019;architectureD&#xE8;s le d&#xE9;marrage du processus, on aura une vue sur l'architecture &#xE0; mettre en place. L&#x2019;architecture d&#x2019;un syst&#xE8;me logiciel peut &#xEA;tre d&#xE9;crite comme les diff&#xE9;rentes vues du syst&#xE8;me qui doit &#xEA;tre construit. L&#x2019;architecture logicielle &#xE9;quivaut aux aspects statiques et dynamiques les plus significatifs du syst&#xE8;me. L&#x2019;architecture &#xE9;merge des besoins de l&#x2019;entreprise, tels qu&#x2019;ils sont exprim&#xE9;s par les utilisateurs et autres intervenants et tels qu&#x2019;ils sont refl&#xE9;t&#xE9;s par les cas d&#x2019;utilisation.\nElle subit &#xE9;galement l&#x2019;influence d&#x2019;autres facteurs :- la plate-forme sur laquelle devra s&#x2019;ex&#xE9;cuter le syst&#xE8;me ;- les briques de bases r&#xE9;utilisables disponibles pour le d&#xE9;veloppement ;- les consid&#xE9;rations de d&#xE9;ploiement, les syst&#xE8;mes existants et les besoins nonfonctionnels (performance, fiabilit&#xE9;..)\nLiens entre cas d&#x2019;utilisation et architecture ?Tout produit est &#xE0; la fois forme et fonction. Les cas d&#x2019;utilisation doivent une fois r&#xE9;alis&#xE9;s, trouver leur place dans l&#x2019;architecture. L&#x2019;architecture doit pr&#xE9;voir la r&#xE9;alisation de tous les cas d&#x2019;utilisation. L&#x2019;architecture et les cas d&#x2019;utilisation doivent &#xE9;voluer de fa&#xE7;on concomitante.Marche &#xE0; suivre :L&#x2019;architecte cr&#xE9;e une &#xE9;bauche grossi&#xE8;re de l&#x2019;architecture, en partant de l&#x2019;aspect qui n&#x2019;est pas propre aux cas d&#x2019;utilisation (plate forme..). Bien que cette partie de l&#x2019;architecture soit ind&#xE9;pendante des cas d&#x2019;utilisation, l&#x2019;architecte doit avoir une compr&#xE9;hension globale de ceux ci avant d&#x2019;en esquisser l&#x2019;architecture.\nIl travaille ensuite, sur un sous-ensemble des cas d&#x2019;utilisations identifi&#xE9;s, ceux qui repr&#xE9;sentent les fonctions essentielles du syst&#xE8;me en cours de d&#xE9;veloppement.\nL&#x2019;architecture se d&#xE9;voile peu &#xE0; peu, au rythme de la sp&#xE9;cification et de la maturation des cas d&#x2019;utilisation, qui favorisent, &#xE0; leur tour, le d&#xE9;veloppement d&#x2019;un nombre croissant de cas d&#x2019;utilisation. Ce processus se poursuit jusqu&#x2019;&#xE0; ce que l&#x2019;architecture soit jug&#xE9;e stable.Le processus unifi&#xE9; est it&#xE9;ratif et incr&#xE9;mentalLe d&#xE9;veloppement d&#x2019;un produit logiciel destin&#xE9; &#xE0; la commercialisation est une vaste entreprise qui peut s&#x2019;&#xE9;tendre sur plusieurs mois. On ne va pas tout d&#xE9;velopper d&#x2019;un coup. On peut d&#xE9;couper le travail en plusieurs parties qui sont autant de mini projets. Chacun d&#x2019;entre eux repr&#xE9;sentant une it&#xE9;ration qui donne lieu &#xE0; un incr&#xE9;ment. Une it&#xE9;ration d&#xE9;signe la succession des &#xE9;tapes de l&#x2019;encha&#xEE;nement d&#x2019;activit&#xE9;s, tandis qu&#x2019;un incr&#xE9;ment correspond &#xE0; une avanc&#xE9;e dans les diff&#xE9;rents stades de d&#xE9;veloppement.\nLe choix de ce qui doit &#xEA;tre impl&#xE9;ment&#xE9; au cours d&#x2019;une it&#xE9;ration repose sur deux facteurs :- Une it&#xE9;ration prend en compte un certain nombre de cas d&#x2019;utilisation qui ensemble,am&#xE9;liorent l&#x2019;utilisabilit&#xE9; du produit &#xE0; un certain stade de d&#xE9;veloppement.- L&#x2019;it&#xE9;ration traite en priorit&#xE9; les risques majeurs.\nUn incr&#xE9;ment constitue souvent un additif.A chaque it&#xE9;ration, les d&#xE9;veloppeurs identifient et sp&#xE9;cifient les cas d&#x2019;utilisations pertinents, cr&#xE9;ent une conception en se laissant guider par l&#x2019;architecture choisie, impl&#xE9;mentent cette conception sous forme de composants et v&#xE9;rifie que ceux ci sont conformes aux cas d&#x2019;utilisation. D&#xE9;s qu&#x2019;une it&#xE9;ration r&#xE9;pond aux objectifs fix&#xE9;s le d&#xE9;veloppement passe &#xE0; l&#x2019;it&#xE9;ration suivante.Pour rentabiliser le d&#xE9;veloppement il faut s&#xE9;lectionner les it&#xE9;rations n&#xE9;cessaires pour atteindre les objectifs du projet. Ces it&#xE9;rations devront se succ&#xE9;der dans un ordre logique. Un projet r&#xE9;ussi suivra un d&#xE9;roulement direct, &#xE9;tabli d&#xE9;s le d&#xE9;but par les d&#xE9;veloppeurs et dont ils ne s&#x2019;&#xE9;loigneront que de fa&#xE7;on tr&#xE8;s marginale. L&#x2019;&#xE9;limination des probl&#xE8;mes impr&#xE9;vus fait partie des objectifs de r&#xE9;duction des risques.\nAvantages d&#x2019;un processus it&#xE9;ratif contr&#xF4;l&#xE9;Permet de limiter les co&#xFB;ts, en termes de risques, aux strictes d&#xE9;penses li&#xE9;es &#xE0; une it&#xE9;ration.Permet de limiter les risques de retard de mise sur le march&#xE9; du produit d&#xE9;velopp&#xE9; (identification des probl&#xE8;mes d&#xE8;s les premiers stades de d&#xE9;veloppement et non en phase de test comme avec l&#x2019;approche &#xAB; classique &#xBB;).Permet d&#x2019;acc&#xE9;l&#xE9;rer le rythme de d&#xE9;veloppement gr&#xE2;ce &#xE0; des objectifs clairs et &#xE0; court terme.Permet de prendre en compte le fait que les besoins des utilisateurs et les exigences correspondantes ne peuvent &#xEA;tre int&#xE9;gralement d&#xE9;finis &#xE0; l&#x2019;avance et se d&#xE9;gagent peu &#xE0; peu des it&#xE9;rations successives.L&#x2019;architecture fournit la structure qui servira de cadre au travail effectu&#xE9; au cours des it&#xE9;rations, tandis que les cas d&#x2019;utilisation d&#xE9;finissent les objectifs et orientent le travail de chaque it&#xE9;ration. Il ne faut donc pas m&#xE9;sestimer l&#x2019;un des trois concepts.Le cycle de vie du processus unifi&#xE9;Le processus unifi&#xE9; r&#xE9;p&#xE8;te un certain nombre de fois une s&#xE9;rie de cycles. Tout cycle se conclut par la livraison d&#x2019;une version du produit aux clients et s&#x2019;articule en 4 phases : cr&#xE9;ation, &#xE9;laboration, construction et transition, chacune d&#x2019;entre elles se subdivisant &#xE0; son tour en it&#xE9;rations.\n\n\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
MERISE ET UML: APPROCHE SYSTEMIQUE \n \nLa m&#xE9;thode MERISE s'int&#xE9;resse aux syst&#xE8;mes ouverts en \nrelation permanente avec leur environnement ( &#xE0; partir du \nniveau 3. Cf. Cours de syst&#xE9;mique ). Trois propri&#xE9;t&#xE9;s \nmajeures sont alors consid&#xE9;r&#xE9;es. \n\nGLOBALITE \nContrairement au mod&#xE8;le Cart&#xE9;sien, le comportement d'un \nsyst&#xE8;me n'est pas la somme des comportements de ses \nparties \n\nRETROACTION \nLe syst&#xE8;me r&#xE9;agit &#xE0; toute stimulation en g&#xE9;n&#xE9;rant des \nr&#xE9;sultats selon des boucles d'actions-r&#xE9;actions mises en \noeuvre au sein de ses composants. ( feed-back d'ordre 3 ) \n\nFINALITE \nLe syst&#xE8;me ne peut &#xEA;tre stabilis&#xE9; que si on lui fournit des \nvaleurs acceptables pr&#xE9;alablement d&#xE9;finies. \n\nL'APPROCHE UML \nL'approche par les CAS D'UTILISATION constitue de fait une \napproche SYSTEMIQUE. Les ACTEURS et les MESSAGES \n&#xE9;chang&#xE9;s sont pris en compte. \n\nCOMMENTAIRES \nLa Ma&#xEE;trise des concepts de la syst&#xE9;mique \n ( ENVIRONNEMENT, ENTREES, SORTIES, OBJECTIFS, \nSTRUCTURE et PROCESSUS ) permet de r&#xE9;aliser une \napproche constructive et consciente des cas d'utilisation. Elle \nfacilite la d&#xE9;termination des CAS D'UTILISATION selon un \ndouble process TOP-DOWN et BOTTOM-UP. L'avantage est \nque le PROCESSUS m&#xE9;tier du syst&#xE8;me est mieux d&#xE9;crit et \nplus compr&#xE9;hensible par les utilisateurs. \n\nFINALITES:Raisons d'&#xEA;tre, vocation d'un syst&#xE8;me. Se d&#xE9;clinent et se formalisent en BUTS. Elles ne sont pas op&#xE9;ratoires. ( Cf. FACTEURS ). Par \nexemple: "Recentrer l'activit&#xE9; de l'entreprise sur son m&#xE9;tier de base qui est la vente de contrats d'assurances". \n\nBUT:Formalisation des FINALITES. Elles se d&#xE9;clinent en OBJECTIFS qui eux, doivent &#xEA;tre op&#xE9;ratoires. ( Cf. CRITERES ). Par exemple: "Recentrer \nles r&#xE9;sultats de la compagnie sur les primes d'assurances plut&#xF4;t que sur les march&#xE9;s financiers" \n\nOBJECTIFS:Concr&#xE9;tisation des BUTS sur la base de crit&#xE8;res d'&#xE9;valuations auxquels sont affect&#xE9;s des niveaux quantifi&#xE9;s &#xE0; atteindre. ( Cf. \nMETRIQUES ). Par exemple: "Les cotisations d'assurances doivent contribuer &#xE0; 60% du r&#xE9;sultat de la compagnie ". \n\nACTEURS:Classe st&#xE9;rotyp&#xE9;e repr&#xE9;sentant une abstraction faisant partie de l'ENVIRONNEMENT du syst&#xE8;me &#xE9;tudi&#xE9;. \nOSITEC-Consultants 40/45 18/03/2005\n
* La conception du syst&#xE8;me d'information se fait par &#xE9;tapes, afin d'aboutir &#xE0; un syst&#xE8;me d'information fonctionnel refl&#xE9;tant une r&#xE9;alit&#xE9; physique. Il s'agit donc de valider une &#xE0; une chacune des &#xE9;tapes en prenant en compte les r&#xE9;sultats de la phase pr&#xE9;c&#xE9;dente. D'autre part, les donn&#xE9;es &#xE9;tant s&#xE9;par&#xE9;es des traitements, il faut v&#xE9;rifier la concordance entre donn&#xE9;es et traitements afin de v&#xE9;rifier que toutes les donn&#xE9;es n&#xE9;cessaires aux traitements sont pr&#xE9;sentes et qu'il n'y a pas de donn&#xE9;es superflues.\nCette succession d'&#xE9;tapes est appel&#xE9;e cycle d'abstraction pour la conception des syst&#xE8;mes d'information :\nL'expression des besoins est une &#xE9;tape consistant &#xE0; d&#xE9;finir ce que l'on attend du syst&#xE8;me d'information automatis&#xE9;, il faut pour cela :\nfaire l'inventaire des &#xE9;l&#xE9;ments n&#xE9;cessaires au syst&#xE8;me d'information\nd&#xE9;limiter le syst&#xE8;me en s'informant aupr&#xE8;s des futurs utilisateurs\nCela va permettre de cr&#xE9;er le MCC (Mod&#xE8;le conceptuel de la communication) qui d&#xE9;finit les flux d'informations &#xE0; prendre en compte.\nL'&#xE9;tape suivante consiste &#xE0; mettre au point le MCD (Mod&#xE8;le conceptuel des donn&#xE9;es) et le MCT (Mod&#xE8;le conceptuel des traitements) d&#xE9;crivant les r&#xE8;gles et les contraintes &#xE0; prendre en compte.\nLe mod&#xE8;le organisationnel consiste &#xE0; d&#xE9;finir le MOT (Mod&#xE8;le organisationnel des traitements) d&#xE9;crivant les contraintes dues &#xE0; l'environnement (organisationnel, spatial et temporel).\nLe mod&#xE8;le logique repr&#xE9;sente un choix logiciel pour le syst&#xE8;me d'information.\nLe mod&#xE8;le physique refl&#xE8;te un choix mat&#xE9;riel pour le syst&#xE8;me d'information.\n****** \n\n\n\n
* La conception du syst&#xE8;me d'information se fait par &#xE9;tapes, afin d'aboutir &#xE0; un syst&#xE8;me d'information fonctionnel refl&#xE9;tant une r&#xE9;alit&#xE9; physique. Il s'agit donc de valider une &#xE0; une chacune des &#xE9;tapes en prenant en compte les r&#xE9;sultats de la phase pr&#xE9;c&#xE9;dente. D'autre part, les donn&#xE9;es &#xE9;tant s&#xE9;par&#xE9;es des traitements, il faut v&#xE9;rifier la concordance entre donn&#xE9;es et traitements afin de v&#xE9;rifier que toutes les donn&#xE9;es n&#xE9;cessaires aux traitements sont pr&#xE9;sentes et qu'il n'y a pas de donn&#xE9;es superflues.\nCette succession d'&#xE9;tapes est appel&#xE9;e cycle d'abstraction pour la conception des syst&#xE8;mes d'information :\nL'expression des besoins est une &#xE9;tape consistant &#xE0; d&#xE9;finir ce que l'on attend du syst&#xE8;me d'information automatis&#xE9;, il faut pour cela :\nfaire l'inventaire des &#xE9;l&#xE9;ments n&#xE9;cessaires au syst&#xE8;me d'information\nd&#xE9;limiter le syst&#xE8;me en s'informant aupr&#xE8;s des futurs utilisateurs\nCela va permettre de cr&#xE9;er le MCC (Mod&#xE8;le conceptuel de la communication) qui d&#xE9;finit les flux d'informations &#xE0; prendre en compte.\nL'&#xE9;tape suivante consiste &#xE0; mettre au point le MCD (Mod&#xE8;le conceptuel des donn&#xE9;es) et le MCT (Mod&#xE8;le conceptuel des traitements) d&#xE9;crivant les r&#xE8;gles et les contraintes &#xE0; prendre en compte.\nLe mod&#xE8;le organisationnel consiste &#xE0; d&#xE9;finir le MOT (Mod&#xE8;le organisationnel des traitements) d&#xE9;crivant les contraintes dues &#xE0; l'environnement (organisationnel, spatial et temporel).\nLe mod&#xE8;le logique repr&#xE9;sente un choix logiciel pour le syst&#xE8;me d'information.\nLe mod&#xE8;le physique refl&#xE8;te un choix mat&#xE9;riel pour le syst&#xE8;me d'information.\n****** \n\n\nVUE LOGIQUE \nVUE DES \nPour MERISE, la cr&#xE9;ation d'un PRODUIT artificiel \n( application ) doit suivre un cycle formel ( Gestation, \nNaissance, Maturit&#xE9; et Mort ) pour le PRODUIT et un cycle \ntechnique pour son &#xE9;laboration ( SD, EBG, EBD, CT, \nPRODUCTION, INTEGRATION, MISE EN OEUVRE et \nMAINTENANCE ). La d&#xE9;marche est formalis&#xE9;e et m&#xE9;thodifi&#xE9;e \nCYCLE D'ABSTRACTION \nLes trois niveaux retenus correspondent &#xE0; des degr&#xE9;s de \nstabilit&#xE9; et d'invariance diff&#xE9;rents du SI ( Conceptuel avec les \nRG et le QUOI FAIRE, Logique avec les RO et le QUI FAIT, le \nOU on FAIT et QUAND on fait et Physique avec les RP et le \nCOMMENT FAIRE ). On peut donc &#xE9;tudier le syst&#xE8;me \nprogressivement en allant du g&#xE9;n&#xE9;ral au Particulier ( TOP - \nDOWN ). \nCYCLE DE DECISION \nLe cycle de d&#xE9;cision permet d'organiser l'intervention des \npersonnes de l'entreprise en fonction de la hi&#xE9;rachie des \nd&#xE9;cisions &#xE0; prendre. MERISE est une m&#xE9;thode participative \no&#xF9; chaque Acteur est amen&#xE9; &#xE0; formuler ses besoins en \nfonction de ses niveaux de pr&#xE9;ocuppations. Le cycle de \nCYCLE DE VIE \nUML ne d&#xE9;finit pas de cycle de vie. Il est implicite et correspond &#xE0; \nun cycle it&#xE9;ratif et incr&#xE9;mental guid&#xE9; par les CAS D'UTILISATION. \net centr&#xE9; sur les vues. \nCYCLE D'ABSTRACTION \nUML permet de mod&#xE9;liser les diff&#xE9;rents niveaux du SI . \n( Conceptuel, Organisationnel et Physique ). Pour cette partie \nUML propose diff&#xE9;rents mod&#xE8;les ( CAS d'UTILISATION, \nPAQUETAGES, CLASSES, COMPOSANTS et NOEUDS ). UML \nlaisse le soin &#xE0;l'informaticen de pr&#xE9;senter ces mod&#xE8;les de \nmani&#xE8;re coh&#xE9;rente par rapport au niveau d'abstraction. \nCYCLE DE DECISION \nComme MERISE, UML associe &#xE9;troitement les utilisateurs aux \nprises de d&#xE9;cisions. La mise en eouvre d'UML doit \ns'accompagner d'un cycle de d&#xE9;cision complet avec points de \ncontr&#xF4;les et jalons. \n\n\n\n
\n
* La conception du syst&#xE8;me d'information se fait par &#xE9;tapes, afin d'aboutir &#xE0; un syst&#xE8;me d'information fonctionnel refl&#xE9;tant une r&#xE9;alit&#xE9; physique. Il s'agit donc de valider une &#xE0; une chacune des &#xE9;tapes en prenant en compte les r&#xE9;sultats de la phase pr&#xE9;c&#xE9;dente. D'autre part, les donn&#xE9;es &#xE9;tant s&#xE9;par&#xE9;es des traitements, il faut v&#xE9;rifier la concordance entre donn&#xE9;es et traitements afin de v&#xE9;rifier que toutes les donn&#xE9;es n&#xE9;cessaires aux traitements sont pr&#xE9;sentes et qu'il n'y a pas de donn&#xE9;es superflues.\nCette succession d'&#xE9;tapes est appel&#xE9;e cycle d'abstraction pour la conception des syst&#xE8;mes d'information :\nL'expression des besoins est une &#xE9;tape consistant &#xE0; d&#xE9;finir ce que l'on attend du syst&#xE8;me d'information automatis&#xE9;, il faut pour cela :\nfaire l'inventaire des &#xE9;l&#xE9;ments n&#xE9;cessaires au syst&#xE8;me d'information\nd&#xE9;limiter le syst&#xE8;me en s'informant aupr&#xE8;s des futurs utilisateurs\nCela va permettre de cr&#xE9;er le MCC (Mod&#xE8;le conceptuel de la communication) qui d&#xE9;finit les flux d'informations &#xE0; prendre en compte.\nL'&#xE9;tape suivante consiste &#xE0; mettre au point le MCD (Mod&#xE8;le conceptuel des donn&#xE9;es) et le MCT (Mod&#xE8;le conceptuel des traitements) d&#xE9;crivant les r&#xE8;gles et les contraintes &#xE0; prendre en compte.\nLe mod&#xE8;le organisationnel consiste &#xE0; d&#xE9;finir le MOT (Mod&#xE8;le organisationnel des traitements) d&#xE9;crivant les contraintes dues &#xE0; l'environnement (organisationnel, spatial et temporel).\nLe mod&#xE8;le logique repr&#xE9;sente un choix logiciel pour le syst&#xE8;me d'information.\nLe mod&#xE8;le physique refl&#xE8;te un choix mat&#xE9;riel pour le syst&#xE8;me d'information.\n****** \n\nMerise propose une approche descendante o&#xF9; le syst&#xE8;me \nr&#xE9;ell est d&#xE9;coup&#xE9; en ACTIVITES ( MCC, MCD, MCT ) elles \nm&#xEA;mes d&#xE9;coup&#xE9;es en FONCTIONS ( MOT, MLD et MOC ). Les \nFONCTIONS sont compos&#xE9;es de RG elles m&#xEA;mes regroup&#xE9;es \nen OPERATIONS. Ces RG au niveau conceptuel g&#xE9;n&#xE8;rent \ndes MODULES d&#xE9;compos&#xE9;s en MODULES plus simples pour \nobtenir des MODULES &#xE9;l&#xE9;mentaires. Les limites de cette \napproche r&#xE9;sident dans la REUTILISABILITE. Il existe aussi \ndes diff&#xE9;rences entre des modules plus "utilisateurs" \n( Calculs de dates, calcul de validit&#xE9; de compte via une cl&#xE9; \netc.. ) et des modules plus "techniques" ( module d'acc&#xE8;s &#xE0; \nun SGBD, Module de cr&#xE9;ation de liste sur &#xE9;cran ). \nL'approche fonctionnelle est une sp&#xE9;cificit&#xE9; MERISE \ndont UML se d&#xE9;marque. Dans UML, les FONCTIONS \nc&#xE8;dent le pas aux CAS D'UTILISATION qui permettent \nde situer les besoins des Utilisateurs dans un contexte \nr&#xE9;el. A chaque sc&#xE9;nario correspondent des \ndiagrammes d'interactions ( SEQUENCE et \nCOLLABORATION ) entre les OBJETS et non pas des \nFONCTIONS. Pour compl&#xE9;ter , UML introduit des \ndiagrammes d'ACTIVITES. Cette approche rend le \nsyst&#xE8;me le plus ind&#xE9;pendant possible des besoins en \ndonnant naissance &#xE0; des COMPOSANTS r&#xE9;utilisables. \nNous avons affaire ici &#xE0; la v&#xE9;ritable diff&#xE9;rence ( culturelle et conceptuelle ) entre MERISE et UML. Cette diff&#xE9;rence impose \nque l'informaticien "pense" diff&#xE9;remment. \n\n\n\n
* La conception du syst&#xE8;me d'information se fait par &#xE9;tapes, afin d'aboutir &#xE0; un syst&#xE8;me d'information fonctionnel refl&#xE9;tant une r&#xE9;alit&#xE9; physique. Il s'agit donc de valider une &#xE0; une chacune des &#xE9;tapes en prenant en compte les r&#xE9;sultats de la phase pr&#xE9;c&#xE9;dente. D'autre part, les donn&#xE9;es &#xE9;tant s&#xE9;par&#xE9;es des traitements, il faut v&#xE9;rifier la concordance entre donn&#xE9;es et traitements afin de v&#xE9;rifier que toutes les donn&#xE9;es n&#xE9;cessaires aux traitements sont pr&#xE9;sentes et qu'il n'y a pas de donn&#xE9;es superflues.\nCette succession d'&#xE9;tapes est appel&#xE9;e cycle d'abstraction pour la conception des syst&#xE8;mes d'information :\nL'expression des besoins est une &#xE9;tape consistant &#xE0; d&#xE9;finir ce que l'on attend du syst&#xE8;me d'information automatis&#xE9;, il faut pour cela :\nfaire l'inventaire des &#xE9;l&#xE9;ments n&#xE9;cessaires au syst&#xE8;me d'information\nd&#xE9;limiter le syst&#xE8;me en s'informant aupr&#xE8;s des futurs utilisateurs\nCela va permettre de cr&#xE9;er le MCC (Mod&#xE8;le conceptuel de la communication) qui d&#xE9;finit les flux d'informations &#xE0; prendre en compte.\nL'&#xE9;tape suivante consiste &#xE0; mettre au point le MCD (Mod&#xE8;le conceptuel des donn&#xE9;es) et le MCT (Mod&#xE8;le conceptuel des traitements) d&#xE9;crivant les r&#xE8;gles et les contraintes &#xE0; prendre en compte.\nLe mod&#xE8;le organisationnel consiste &#xE0; d&#xE9;finir le MOT (Mod&#xE8;le organisationnel des traitements) d&#xE9;crivant les contraintes dues &#xE0; l'environnement (organisationnel, spatial et temporel).\nLe mod&#xE8;le logique repr&#xE9;sente un choix logiciel pour le syst&#xE8;me d'information.\nLe mod&#xE8;le physique refl&#xE8;te un choix mat&#xE9;riel pour le syst&#xE8;me d'information.\n****** \n\nMerise propose une approche descendante o&#xF9; le syst&#xE8;me \nr&#xE9;ell est d&#xE9;coup&#xE9; en ACTIVITES ( MCC, MCD, MCT ) elles \nm&#xEA;mes d&#xE9;coup&#xE9;es en FONCTIONS ( MOT, MLD et MOC ). Les \nFONCTIONS sont compos&#xE9;es de RG elles m&#xEA;mes regroup&#xE9;es \nen OPERATIONS. Ces RG au niveau conceptuel g&#xE9;n&#xE8;rent \ndes MODULES d&#xE9;compos&#xE9;s en MODULES plus simples pour \nobtenir des MODULES &#xE9;l&#xE9;mentaires. Les limites de cette \napproche r&#xE9;sident dans la REUTILISABILITE. Il existe aussi \ndes diff&#xE9;rences entre des modules plus "utilisateurs" \n( Calculs de dates, calcul de validit&#xE9; de compte via une cl&#xE9; \netc.. ) et des modules plus "techniques" ( module d'acc&#xE8;s &#xE0; \nun SGBD, Module de cr&#xE9;ation de liste sur &#xE9;cran ). \nL'approche fonctionnelle est une sp&#xE9;cificit&#xE9; MERISE \ndont UML se d&#xE9;marque. Dans UML, les FONCTIONS \nc&#xE8;dent le pas aux CAS D'UTILISATION qui permettent \nde situer les besoins des Utilisateurs dans un contexte \nr&#xE9;el. A chaque sc&#xE9;nario correspondent des \ndiagrammes d'interactions ( SEQUENCE et \nCOLLABORATION ) entre les OBJETS et non pas des \nFONCTIONS. Pour compl&#xE9;ter , UML introduit des \ndiagrammes d'ACTIVITES. Cette approche rend le \nsyst&#xE8;me le plus ind&#xE9;pendant possible des besoins en \ndonnant naissance &#xE0; des COMPOSANTS r&#xE9;utilisables. \nNous avons affaire ici &#xE0; la v&#xE9;ritable diff&#xE9;rence ( culturelle et conceptuelle ) entre MERISE et UML. Cette diff&#xE9;rence impose \nque l'informaticien "pense" diff&#xE9;remment. \n\n\n\n
* La conception du syst&#xE8;me d'information se fait par &#xE9;tapes, afin d'aboutir &#xE0; un syst&#xE8;me d'information fonctionnel refl&#xE9;tant une r&#xE9;alit&#xE9; physique. Il s'agit donc de valider une &#xE0; une chacune des &#xE9;tapes en prenant en compte les r&#xE9;sultats de la phase pr&#xE9;c&#xE9;dente. D'autre part, les donn&#xE9;es &#xE9;tant s&#xE9;par&#xE9;es des traitements, il faut v&#xE9;rifier la concordance entre donn&#xE9;es et traitements afin de v&#xE9;rifier que toutes les donn&#xE9;es n&#xE9;cessaires aux traitements sont pr&#xE9;sentes et qu'il n'y a pas de donn&#xE9;es superflues.\nCette succession d'&#xE9;tapes est appel&#xE9;e cycle d'abstraction pour la conception des syst&#xE8;mes d'information :\nL'expression des besoins est une &#xE9;tape consistant &#xE0; d&#xE9;finir ce que l'on attend du syst&#xE8;me d'information automatis&#xE9;, il faut pour cela :\nfaire l'inventaire des &#xE9;l&#xE9;ments n&#xE9;cessaires au syst&#xE8;me d'information\nd&#xE9;limiter le syst&#xE8;me en s'informant aupr&#xE8;s des futurs utilisateurs\nCela va permettre de cr&#xE9;er le MCC (Mod&#xE8;le conceptuel de la communication) qui d&#xE9;finit les flux d'informations &#xE0; prendre en compte.\nL'&#xE9;tape suivante consiste &#xE0; mettre au point le MCD (Mod&#xE8;le conceptuel des donn&#xE9;es) et le MCT (Mod&#xE8;le conceptuel des traitements) d&#xE9;crivant les r&#xE8;gles et les contraintes &#xE0; prendre en compte.\nLe mod&#xE8;le organisationnel consiste &#xE0; d&#xE9;finir le MOT (Mod&#xE8;le organisationnel des traitements) d&#xE9;crivant les contraintes dues &#xE0; l'environnement (organisationnel, spatial et temporel).\nLe mod&#xE8;le logique repr&#xE9;sente un choix logiciel pour le syst&#xE8;me d'information.\nLe mod&#xE8;le physique refl&#xE8;te un choix mat&#xE9;riel pour le syst&#xE8;me d'information.\n****** \n\nL'APPROCHE MERISE \nMerise propose de consid&#xE9;rer le syst&#xE8;me r&#xE9;el selon deux points de vues: \nUn point de vue statique ( les DONNEES ) et un point de vue dynamique \n ( Les TRAITEMENTS ). Cela permet d'avoir deux vues diff&#xE9;rentes &#xE0; valider. \nCette validation permet de contr&#xF4;ler que les besoins exprim&#xE9;s sont bien \ntraduits en termes d'informations et que ces derni&#xE8;res sont bien toutes \nutilis&#xE9;es. La validation consiste &#xE0; v&#xE9;rifier l'EXISTENCE des informations, \ndes ENTITES et des RELATIONS; la coh&#xE9;rence des CARDINALITES et des \nCONTRAINTES ainsi que l'exhaustivit&#xE9; des actions &#xE9;l&#xE9;mentaires sur les \nCOMPOSANTS. Ce qui permet de lier les DONNEES et les TRAITEMENTS. \nL'APPROCHE UML \nL'approche OBJET associe les INFORMATIONS et les TRAITEMENTS. \nDe cette fa&#xE7;on, un certain niveau de coh&#xE9;rence est assur&#xE9;. Il s'agit ici \nd'un autre point cl&#xE9; de diff&#xE9;rence. En effet, l'approche UML permet de \nmod&#xE9;liser les syt&#xE8;mes complexes et d'exprimer de mani&#xE8;re \nINTEGREE la structure et la dynamique avec un m&#xEA;me concept plus \nproche de la r&#xE9;alit&#xE9; des choses. Cette approche &#xE9;tant renforc&#xE9;e par \nles CAS D'UTILISATION qui se traduisent par des COLLABORATIONS \nentre les OBJETS. \nL'APPROCHE MERISE PAR LES ECHANGES \nMerise pour la d&#xE9;termination du champ de l'&#xE9;tude, utilise le concept de \nFLUX entre ACTEURS. ( MCC avec ACTEURS et MESSAGES ou GRAPHE de \nFLUX ). Les Mod&#xE8;les de FLUX mettent en jeu les ACTEURS et leurs \nECHANGES avec le syst&#xE8;me &#xE0; construire vu de l'EXTERIEUR. Si l'on veut \ntenir compte d'ACTEURS internes, il convient de d&#xE9;terminer un SOUS- \nSYSTEME, les autres STRUCTURES du syst&#xE8;me premier devenant des \nACTEURS analysables en termes d'ECHANGES. ( Cf. cours de MP ) \nL'APPROCHE UML PAR LES ECHANGES \nDans UML, l'entreprise est d&#xE9;crite d'abord sous forme de PROCESSUS \n"m&#xE9;tiers" et ensuite sous forme de TRAVAILLEURS \n ( R&#xF4;les ) qui interagisent dans l'ex&#xE9;cution du Processus. Les \nACTIVITES de ces travailleurs sont ensuite d&#xE9;crites dans les \ndiagrammes d'ACTIVITES.Ceci permet de fournir une vision simplfi&#xE9;e \net de haut niveau de l'organisation tout en d&#xE9;crivant s&#xE9;par&#xE9;ment les \nd&#xE9;tails des activit&#xE9;s et des &#xE9;changes. . \nL'APPROCHE MERISE DU GENERAL AU PARTICULIER \nMerise est une m&#xE9;thode de type "descendante" ( TOP -DOWN ). La vision \nglobale du syst&#xE8;me est affin&#xE9;e par int&#xE9;grations successives des diff&#xE9;rentes \norientations retenues, class&#xE9;es selon le s&#xE9;quencement du cycle \nd'abstraction. Dans les faits, les premi&#xE8;res &#xE9;tapes s'appuient dur l'&#xE9;tude de \nl'EXISTANT ( Interviewes et documentation ). Les MCC, MCD et MCT \nsynth&#xE9;tisent ces travaux. Le travail est ensuite compl&#xE9;t&#xE9; par les \nOBJECTIFS fournis du syst&#xE8;me cible et d&#xE9;clin&#xE9;s en mod&#xE8;les \norganisationnels ( MLD, MOT et MOC ) pour ensuite produire les mod&#xE8;les \nphysiques ( MPD et MPT ) rarement d&#xE9;crits en pratique. \nL'APPROCHE UML \nUML permet aussi bien une approche descendante ( TOP-DOWN ) que \nmontante ( BOTTOM-UP). Les diff&#xE9;rents diagrammes fournissent des \nsupports pour mat&#xE9;rialiser une d&#xE9;marche progressive allant du global \nvers le d&#xE9;taill&#xE9;, pour passer du SYSTEME D'INFORMATIONS au \nSYSTEME INFORMATIQUE. Un des avantages d'UML r&#xE9;side dans le \nfait que le concept de base ( l'OBJET ) peut &#xEA;tre d&#xE9;clin&#xE9; sur tout le \ncycle d'abstraction. \n\n\n\n\n
Merise s'appuie sur des concepts de DOMAINES, d'ACTEURS, \nde FLUX, de mod&#xE8;les li&#xE9;s aux niveaux CONCEPTUELS et \nORGANISATIONNELS pour d&#xE9;crire le METIER \nind&#xE9;pendamment de ses STRUCTURES. Le DOMAINE est \nd&#xE9;fini comme le ou les PROCESSUS m&#xE9;tiers candidats &#xE0; \nl'&#xE9;tude et en relation avec d'autres domaines ( par exemple, le \ndomaine de la GESTION COMMERCIALE en relation avec le \ndomaine de la FABRICATION ). Un domaine est subdivis&#xE9; en \nPROCESSUS ( Gestion des Tarifs, Gestion des Clients, Gestion \ndes ventes, Gestion du budget, etc... ). Il est n&#xE9;anmoins \npossible de "calquer" la d&#xE9;finition des domaines sur les \nACTIVITES de l'entreprise. Par exemple, il pourrait exister un \ndomaine VPC et un domaine VENTE EN MAGASINS. Ce qui ne \npermet pas, selon MERISE, une factorisation ais&#xE9;e des \nFONCTIONNALITES. \nPour UML, la d&#xE9;finition du DOMAINE est un pr&#xE9;alable. Et, \nles DOMAINES &#xE9;tudi&#xE9;s d&#xE9;rivent directement des \nACTIVITES de l'entreprise. Ce qui permet de trouver des \nsc&#xE9;narios de d&#xE9;veloppements. Comme nous ne sommes \nplus en approche FONCTIONNELLE, l'approche est plus \nais&#xE9;e. Un objet CLIENT reste le m&#xEA;me que nous soyons en \nGestion Commerciale ou en Gestion de Production. La \nsp&#xE9;cialisation de ces OBJETS venant par la d&#xE9;rivation et \nl'h&#xE9;ritage associ&#xE9;es aux CLASSES. \n\n
\n
\n
* La conception du syst&#xE8;me d'information se fait par &#xE9;tapes, afin d'aboutir &#xE0; un syst&#xE8;me d'information fonctionnel refl&#xE9;tant une r&#xE9;alit&#xE9; physique. Il s'agit donc de valider une &#xE0; une chacune des &#xE9;tapes en prenant en compte les r&#xE9;sultats de la phase pr&#xE9;c&#xE9;dente. D'autre part, les donn&#xE9;es &#xE9;tant s&#xE9;par&#xE9;es des traitements, il faut v&#xE9;rifier la concordance entre donn&#xE9;es et traitements afin de v&#xE9;rifier que toutes les donn&#xE9;es n&#xE9;cessaires aux traitements sont pr&#xE9;sentes et qu'il n'y a pas de donn&#xE9;es superflues.\nCette succession d'&#xE9;tapes est appel&#xE9;e cycle d'abstraction pour la conception des syst&#xE8;mes d'information :\nL'expression des besoins est une &#xE9;tape consistant &#xE0; d&#xE9;finir ce que l'on attend du syst&#xE8;me d'information automatis&#xE9;, il faut pour cela :\nfaire l'inventaire des &#xE9;l&#xE9;ments n&#xE9;cessaires au syst&#xE8;me d'information\nd&#xE9;limiter le syst&#xE8;me en s'informant aupr&#xE8;s des futurs utilisateurs\nCela va permettre de cr&#xE9;er le MCC (Mod&#xE8;le conceptuel de la communication) qui d&#xE9;finit les flux d'informations &#xE0; prendre en compte.\nL'&#xE9;tape suivante consiste &#xE0; mettre au point le MCD (Mod&#xE8;le conceptuel des donn&#xE9;es) et le MCT (Mod&#xE8;le conceptuel des traitements) d&#xE9;crivant les r&#xE8;gles et les contraintes &#xE0; prendre en compte.\nLe mod&#xE8;le organisationnel consiste &#xE0; d&#xE9;finir le MOT (Mod&#xE8;le organisationnel des traitements) d&#xE9;crivant les contraintes dues &#xE0; l'environnement (organisationnel, spatial et temporel).\nLe mod&#xE8;le logique repr&#xE9;sente un choix logiciel pour le syst&#xE8;me d'information.\nLe mod&#xE8;le physique refl&#xE8;te un choix mat&#xE9;riel pour le syst&#xE8;me d'information.\n****** \n\n\n\n
* La conception du syst&#xE8;me d'information se fait par &#xE9;tapes, afin d'aboutir &#xE0; un syst&#xE8;me d'information fonctionnel refl&#xE9;tant une r&#xE9;alit&#xE9; physique. Il s'agit donc de valider une &#xE0; une chacune des &#xE9;tapes en prenant en compte les r&#xE9;sultats de la phase pr&#xE9;c&#xE9;dente. D'autre part, les donn&#xE9;es &#xE9;tant s&#xE9;par&#xE9;es des traitements, il faut v&#xE9;rifier la concordance entre donn&#xE9;es et traitements afin de v&#xE9;rifier que toutes les donn&#xE9;es n&#xE9;cessaires aux traitements sont pr&#xE9;sentes et qu'il n'y a pas de donn&#xE9;es superflues.\nCette succession d'&#xE9;tapes est appel&#xE9;e cycle d'abstraction pour la conception des syst&#xE8;mes d'information :\nL'expression des besoins est une &#xE9;tape consistant &#xE0; d&#xE9;finir ce que l'on attend du syst&#xE8;me d'information automatis&#xE9;, il faut pour cela :\nfaire l'inventaire des &#xE9;l&#xE9;ments n&#xE9;cessaires au syst&#xE8;me d'information\nd&#xE9;limiter le syst&#xE8;me en s'informant aupr&#xE8;s des futurs utilisateurs\nCela va permettre de cr&#xE9;er le MCC (Mod&#xE8;le conceptuel de la communication) qui d&#xE9;finit les flux d'informations &#xE0; prendre en compte.\nL'&#xE9;tape suivante consiste &#xE0; mettre au point le MCD (Mod&#xE8;le conceptuel des donn&#xE9;es) et le MCT (Mod&#xE8;le conceptuel des traitements) d&#xE9;crivant les r&#xE8;gles et les contraintes &#xE0; prendre en compte.\nLe mod&#xE8;le organisationnel consiste &#xE0; d&#xE9;finir le MOT (Mod&#xE8;le organisationnel des traitements) d&#xE9;crivant les contraintes dues &#xE0; l'environnement (organisationnel, spatial et temporel).\nLe mod&#xE8;le logique repr&#xE9;sente un choix logiciel pour le syst&#xE8;me d'information.\nLe mod&#xE8;le physique refl&#xE8;te un choix mat&#xE9;riel pour le syst&#xE8;me d'information.\n****** \n\n\n\n
* La conception du syst&#xE8;me d'information se fait par &#xE9;tapes, afin d'aboutir &#xE0; un syst&#xE8;me d'information fonctionnel refl&#xE9;tant une r&#xE9;alit&#xE9; physique. Il s'agit donc de valider une &#xE0; une chacune des &#xE9;tapes en prenant en compte les r&#xE9;sultats de la phase pr&#xE9;c&#xE9;dente. D'autre part, les donn&#xE9;es &#xE9;tant s&#xE9;par&#xE9;es des traitements, il faut v&#xE9;rifier la concordance entre donn&#xE9;es et traitements afin de v&#xE9;rifier que toutes les donn&#xE9;es n&#xE9;cessaires aux traitements sont pr&#xE9;sentes et qu'il n'y a pas de donn&#xE9;es superflues.\nCette succession d'&#xE9;tapes est appel&#xE9;e cycle d'abstraction pour la conception des syst&#xE8;mes d'information :\nL'expression des besoins est une &#xE9;tape consistant &#xE0; d&#xE9;finir ce que l'on attend du syst&#xE8;me d'information automatis&#xE9;, il faut pour cela :\nfaire l'inventaire des &#xE9;l&#xE9;ments n&#xE9;cessaires au syst&#xE8;me d'information\nd&#xE9;limiter le syst&#xE8;me en s'informant aupr&#xE8;s des futurs utilisateurs\nCela va permettre de cr&#xE9;er le MCC (Mod&#xE8;le conceptuel de la communication) qui d&#xE9;finit les flux d'informations &#xE0; prendre en compte.\nL'&#xE9;tape suivante consiste &#xE0; mettre au point le MCD (Mod&#xE8;le conceptuel des donn&#xE9;es) et le MCT (Mod&#xE8;le conceptuel des traitements) d&#xE9;crivant les r&#xE8;gles et les contraintes &#xE0; prendre en compte.\nLe mod&#xE8;le organisationnel consiste &#xE0; d&#xE9;finir le MOT (Mod&#xE8;le organisationnel des traitements) d&#xE9;crivant les contraintes dues &#xE0; l'environnement (organisationnel, spatial et temporel).\nLe mod&#xE8;le logique repr&#xE9;sente un choix logiciel pour le syst&#xE8;me d'information.\nLe mod&#xE8;le physique refl&#xE8;te un choix mat&#xE9;riel pour le syst&#xE8;me d'information.\n****** \n\n\n\n
* La conception du syst&#xE8;me d'information se fait par &#xE9;tapes, afin d'aboutir &#xE0; un syst&#xE8;me d'information fonctionnel refl&#xE9;tant une r&#xE9;alit&#xE9; physique. Il s'agit donc de valider une &#xE0; une chacune des &#xE9;tapes en prenant en compte les r&#xE9;sultats de la phase pr&#xE9;c&#xE9;dente. D'autre part, les donn&#xE9;es &#xE9;tant s&#xE9;par&#xE9;es des traitements, il faut v&#xE9;rifier la concordance entre donn&#xE9;es et traitements afin de v&#xE9;rifier que toutes les donn&#xE9;es n&#xE9;cessaires aux traitements sont pr&#xE9;sentes et qu'il n'y a pas de donn&#xE9;es superflues.\nCette succession d'&#xE9;tapes est appel&#xE9;e cycle d'abstraction pour la conception des syst&#xE8;mes d'information :\nL'expression des besoins est une &#xE9;tape consistant &#xE0; d&#xE9;finir ce que l'on attend du syst&#xE8;me d'information automatis&#xE9;, il faut pour cela :\nfaire l'inventaire des &#xE9;l&#xE9;ments n&#xE9;cessaires au syst&#xE8;me d'information\nd&#xE9;limiter le syst&#xE8;me en s'informant aupr&#xE8;s des futurs utilisateurs\nCela va permettre de cr&#xE9;er le MCC (Mod&#xE8;le conceptuel de la communication) qui d&#xE9;finit les flux d'informations &#xE0; prendre en compte.\nL'&#xE9;tape suivante consiste &#xE0; mettre au point le MCD (Mod&#xE8;le conceptuel des donn&#xE9;es) et le MCT (Mod&#xE8;le conceptuel des traitements) d&#xE9;crivant les r&#xE8;gles et les contraintes &#xE0; prendre en compte.\nLe mod&#xE8;le organisationnel consiste &#xE0; d&#xE9;finir le MOT (Mod&#xE8;le organisationnel des traitements) d&#xE9;crivant les contraintes dues &#xE0; l'environnement (organisationnel, spatial et temporel).\nLe mod&#xE8;le logique repr&#xE9;sente un choix logiciel pour le syst&#xE8;me d'information.\nLe mod&#xE8;le physique refl&#xE8;te un choix mat&#xE9;riel pour le syst&#xE8;me d'information.\n****** \n\n\n\n
* La conception du syst&#xE8;me d'information se fait par &#xE9;tapes, afin d'aboutir &#xE0; un syst&#xE8;me d'information fonctionnel refl&#xE9;tant une r&#xE9;alit&#xE9; physique. Il s'agit donc de valider une &#xE0; une chacune des &#xE9;tapes en prenant en compte les r&#xE9;sultats de la phase pr&#xE9;c&#xE9;dente. D'autre part, les donn&#xE9;es &#xE9;tant s&#xE9;par&#xE9;es des traitements, il faut v&#xE9;rifier la concordance entre donn&#xE9;es et traitements afin de v&#xE9;rifier que toutes les donn&#xE9;es n&#xE9;cessaires aux traitements sont pr&#xE9;sentes et qu'il n'y a pas de donn&#xE9;es superflues.\nCette succession d'&#xE9;tapes est appel&#xE9;e cycle d'abstraction pour la conception des syst&#xE8;mes d'information :\nL'expression des besoins est une &#xE9;tape consistant &#xE0; d&#xE9;finir ce que l'on attend du syst&#xE8;me d'information automatis&#xE9;, il faut pour cela :\nfaire l'inventaire des &#xE9;l&#xE9;ments n&#xE9;cessaires au syst&#xE8;me d'information\nd&#xE9;limiter le syst&#xE8;me en s'informant aupr&#xE8;s des futurs utilisateurs\nCela va permettre de cr&#xE9;er le MCC (Mod&#xE8;le conceptuel de la communication) qui d&#xE9;finit les flux d'informations &#xE0; prendre en compte.\nL'&#xE9;tape suivante consiste &#xE0; mettre au point le MCD (Mod&#xE8;le conceptuel des donn&#xE9;es) et le MCT (Mod&#xE8;le conceptuel des traitements) d&#xE9;crivant les r&#xE8;gles et les contraintes &#xE0; prendre en compte.\nLe mod&#xE8;le organisationnel consiste &#xE0; d&#xE9;finir le MOT (Mod&#xE8;le organisationnel des traitements) d&#xE9;crivant les contraintes dues &#xE0; l'environnement (organisationnel, spatial et temporel).\nLe mod&#xE8;le logique repr&#xE9;sente un choix logiciel pour le syst&#xE8;me d'information.\nLe mod&#xE8;le physique refl&#xE8;te un choix mat&#xE9;riel pour le syst&#xE8;me d'information.\n****** \n\n\n\n
* La conception du syst&#xE8;me d'information se fait par &#xE9;tapes, afin d'aboutir &#xE0; un syst&#xE8;me d'information fonctionnel refl&#xE9;tant une r&#xE9;alit&#xE9; physique. Il s'agit donc de valider une &#xE0; une chacune des &#xE9;tapes en prenant en compte les r&#xE9;sultats de la phase pr&#xE9;c&#xE9;dente. D'autre part, les donn&#xE9;es &#xE9;tant s&#xE9;par&#xE9;es des traitements, il faut v&#xE9;rifier la concordance entre donn&#xE9;es et traitements afin de v&#xE9;rifier que toutes les donn&#xE9;es n&#xE9;cessaires aux traitements sont pr&#xE9;sentes et qu'il n'y a pas de donn&#xE9;es superflues.\nCette succession d'&#xE9;tapes est appel&#xE9;e cycle d'abstraction pour la conception des syst&#xE8;mes d'information :\nL'expression des besoins est une &#xE9;tape consistant &#xE0; d&#xE9;finir ce que l'on attend du syst&#xE8;me d'information automatis&#xE9;, il faut pour cela :\nfaire l'inventaire des &#xE9;l&#xE9;ments n&#xE9;cessaires au syst&#xE8;me d'information\nd&#xE9;limiter le syst&#xE8;me en s'informant aupr&#xE8;s des futurs utilisateurs\nCela va permettre de cr&#xE9;er le MCC (Mod&#xE8;le conceptuel de la communication) qui d&#xE9;finit les flux d'informations &#xE0; prendre en compte.\nL'&#xE9;tape suivante consiste &#xE0; mettre au point le MCD (Mod&#xE8;le conceptuel des donn&#xE9;es) et le MCT (Mod&#xE8;le conceptuel des traitements) d&#xE9;crivant les r&#xE8;gles et les contraintes &#xE0; prendre en compte.\nLe mod&#xE8;le organisationnel consiste &#xE0; d&#xE9;finir le MOT (Mod&#xE8;le organisationnel des traitements) d&#xE9;crivant les contraintes dues &#xE0; l'environnement (organisationnel, spatial et temporel).\nLe mod&#xE8;le logique repr&#xE9;sente un choix logiciel pour le syst&#xE8;me d'information.\nLe mod&#xE8;le physique refl&#xE8;te un choix mat&#xE9;riel pour le syst&#xE8;me d'information.\n****** \nLe MCD et le diagramme de classes poss&#xE8;dent beaucoup de\npoints communs et une approche de structuration similaire:\n&#x2022; Au niveau des entit&#xE9;s/classes: contrainte de partition, contrainte\nd&#x2019;exclusion, contrainte de totalit&#xE9;, l&#x2019;identifiant est implicite en UML.\n&#x2022; Au niveau des associations: contrainte de partition, d&#x2019;exclusion, de\ntotalit&#xE9;, d&#x2019;inclusion, d&#x2019;unicit&#xE9;, association d&#x2019;association, cardinalit&#xE9;s.\n En UML le diagramme de classes est utilis&#xE9; au cours de\nl&#x2019;ensemble du processus:\n&#x2022; Les classes contiennent les op&#xE9;rations (services),\n&#x2022; Les classes sont analys&#xE9;es du point de vue des responsabilit&#xE9;s,\n&#x2022; Les contraintes sont exprim&#xE9;es dans un langage de contrainte (OCL),\n&#x2022; UML propose des st&#xE9;r&#xE9;otypes,\n&#x2022; UML n&#x2019;implique pas l&#x2019;utilisation d&#x2019;un formalisme de normalisation sur les\nclasses, mais des r&#xE8;gles sont &#xE0; respecter pour &#xE9;viter les erreurs.\n\n\n
* La conception du syst&#xE8;me d'information se fait par &#xE9;tapes, afin d'aboutir &#xE0; un syst&#xE8;me d'information fonctionnel refl&#xE9;tant une r&#xE9;alit&#xE9; physique. Il s'agit donc de valider une &#xE0; une chacune des &#xE9;tapes en prenant en compte les r&#xE9;sultats de la phase pr&#xE9;c&#xE9;dente. D'autre part, les donn&#xE9;es &#xE9;tant s&#xE9;par&#xE9;es des traitements, il faut v&#xE9;rifier la concordance entre donn&#xE9;es et traitements afin de v&#xE9;rifier que toutes les donn&#xE9;es n&#xE9;cessaires aux traitements sont pr&#xE9;sentes et qu'il n'y a pas de donn&#xE9;es superflues.\nCette succession d'&#xE9;tapes est appel&#xE9;e cycle d'abstraction pour la conception des syst&#xE8;mes d'information :\nL'expression des besoins est une &#xE9;tape consistant &#xE0; d&#xE9;finir ce que l'on attend du syst&#xE8;me d'information automatis&#xE9;, il faut pour cela :\nfaire l'inventaire des &#xE9;l&#xE9;ments n&#xE9;cessaires au syst&#xE8;me d'information\nd&#xE9;limiter le syst&#xE8;me en s'informant aupr&#xE8;s des futurs utilisateurs\nCela va permettre de cr&#xE9;er le MCC (Mod&#xE8;le conceptuel de la communication) qui d&#xE9;finit les flux d'informations &#xE0; prendre en compte.\nL'&#xE9;tape suivante consiste &#xE0; mettre au point le MCD (Mod&#xE8;le conceptuel des donn&#xE9;es) et le MCT (Mod&#xE8;le conceptuel des traitements) d&#xE9;crivant les r&#xE8;gles et les contraintes &#xE0; prendre en compte.\nLe mod&#xE8;le organisationnel consiste &#xE0; d&#xE9;finir le MOT (Mod&#xE8;le organisationnel des traitements) d&#xE9;crivant les contraintes dues &#xE0; l'environnement (organisationnel, spatial et temporel).\nLe mod&#xE8;le logique repr&#xE9;sente un choix logiciel pour le syst&#xE8;me d'information.\nLe mod&#xE8;le physique refl&#xE8;te un choix mat&#xE9;riel pour le syst&#xE8;me d'information.\n****** \nLe MCD et le diagramme de classes poss&#xE8;dent beaucoup de\npoints communs et une approche de structuration similaire:\n&#x2022; Au niveau des entit&#xE9;s/classes: contrainte de partition, contrainte\nd&#x2019;exclusion, contrainte de totalit&#xE9;, l&#x2019;identifiant est implicite en UML.\n&#x2022; Au niveau des associations: contrainte de partition, d&#x2019;exclusion, de\ntotalit&#xE9;, d&#x2019;inclusion, d&#x2019;unicit&#xE9;, association d&#x2019;association, cardinalit&#xE9;s.\n En UML le diagramme de classes est utilis&#xE9; au cours de\nl&#x2019;ensemble du processus:\n&#x2022; Les classes contiennent les op&#xE9;rations (services),\n&#x2022; Les classes sont analys&#xE9;es du point de vue des responsabilit&#xE9;s,\n&#x2022; Les contraintes sont exprim&#xE9;es dans un langage de contrainte (OCL),\n&#x2022; UML propose des st&#xE9;r&#xE9;otypes,\n&#x2022; UML n&#x2019;implique pas l&#x2019;utilisation d&#x2019;un formalisme de normalisation sur les\nclasses, mais des r&#xE8;gles sont &#xE0; respecter pour &#xE9;viter les erreurs.\n\n\n
Agence de r&#xE9;gulation des march&#xE9;s\n\n* La conception du syst&#xE8;me d'information se fait par &#xE9;tapes, afin d'aboutir &#xE0; un syst&#xE8;me d'information fonctionnel refl&#xE9;tant une r&#xE9;alit&#xE9; physique. Il s'agit donc de valider une &#xE0; une chacune des &#xE9;tapes en prenant en compte les r&#xE9;sultats de la phase pr&#xE9;c&#xE9;dente. D'autre part, les donn&#xE9;es &#xE9;tant s&#xE9;par&#xE9;es des traitements, il faut v&#xE9;rifier la concordance entre donn&#xE9;es et traitem\n\nents afin de v&#xE9;rifier que toutes les donn&#xE9;es n&#xE9;cessaires aux traitements sont pr&#xE9;sentes et qu'il n'y a pas de donn&#xE9;es superflues.\nCette succession d'&#xE9;tapes est appel&#xE9;e cycle d'abstraction pour la conception des syst&#xE8;mes d'information :\nL'expression des besoins est une &#xE9;tape consistant &#xE0; d&#xE9;finir ce que l'on attend du syst&#xE8;me d'information automatis&#xE9;, il faut pour cela :\nfaire l'inventaire des &#xE9;l&#xE9;ments n&#xE9;cessaires au syst&#xE8;me d'information\nd&#xE9;limiter le syst&#xE8;me en s'informant aupr&#xE8;s des futurs utilisateurs\nCela va permettre de cr&#xE9;er le MCC (Mod&#xE8;le conceptuel de la communication) qui d&#xE9;finit les flux d'informations &#xE0; prendre en compte.\nL'&#xE9;tape suivante consiste &#xE0; mettre au point le MCD (Mod&#xE8;le conceptuel des donn&#xE9;es) et le MCT (Mod&#xE8;le conceptuel des traitements) d&#xE9;crivant les r&#xE8;gles et les contraintes &#xE0; prendre en compte.\nLe mod&#xE8;le organisationnel consiste &#xE0; d&#xE9;finir le MOT (Mod&#xE8;le organisationnel des traitements) d&#xE9;crivant les contraintes dues &#xE0; l'environnement (organisationnel, spatial et temporel).\nLe mod&#xE8;le logique repr&#xE9;sente un choix logiciel pour le syst&#xE8;me d'information.\nLe mod&#xE8;le physique refl&#xE8;te un choix mat&#xE9;riel pour le syst&#xE8;me d'information.\n****** \nLe MCD et le diagramme de classes poss&#xE8;dent beaucoup de\npoints communs et une approche de structuration similaire:\n&#x2022; Au niveau des entit&#xE9;s/classes: contrainte de partition, contrainte\nd&#x2019;exclusion, contrainte de totalit&#xE9;, l&#x2019;identifiant est implicite en UML.\n&#x2022; Au niveau des associations: contrainte de partition, d&#x2019;exclusion, de\ntotalit&#xE9;, d&#x2019;inclusion, d&#x2019;unicit&#xE9;, association d&#x2019;association, cardinalit&#xE9;s.\n En UML le diagramme de classes est utilis&#xE9; au cours de\nl&#x2019;ensemble du processus:\n&#x2022; Les classes contiennent les op&#xE9;rations (services),\n&#x2022; Les classes sont analys&#xE9;es du point de vue des responsabilit&#xE9;s,\n&#x2022; Les contraintes sont exprim&#xE9;es dans un langage de contrainte (OCL),\n&#x2022; UML propose des st&#xE9;r&#xE9;otypes,\n&#x2022; UML n&#x2019;implique pas l&#x2019;utilisation d&#x2019;un formalisme de normalisation sur les\nclasses, mais des r&#xE8;gles sont &#xE0; respecter pour &#xE9;viter les erreurs.\n\n\n
* La conception du syst&#xE8;me d'information se fait par &#xE9;tapes, afin d'aboutir &#xE0; un syst&#xE8;me d'information fonctionnel refl&#xE9;tant une r&#xE9;alit&#xE9; physique. Il s'agit donc de valider une &#xE0; une chacune des &#xE9;tapes en prenant en compte les r&#xE9;sultats de la phase pr&#xE9;c&#xE9;dente. D'autre part, les donn&#xE9;es &#xE9;tant s&#xE9;par&#xE9;es des traitements, il faut v&#xE9;rifier la concordance entre donn&#xE9;es et traitements afin de v&#xE9;rifier que toutes les donn&#xE9;es n&#xE9;cessaires aux traitements sont pr&#xE9;sentes et qu'il n'y a pas de donn&#xE9;es superflues.\nCette succession d'&#xE9;tapes est appel&#xE9;e cycle d'abstraction pour la conception des syst&#xE8;mes d'information :\nL'expression des besoins est une &#xE9;tape consistant &#xE0; d&#xE9;finir ce que l'on attend du syst&#xE8;me d'information automatis&#xE9;, il faut pour cela :\nfaire l'inventaire des &#xE9;l&#xE9;ments n&#xE9;cessaires au syst&#xE8;me d'information\nd&#xE9;limiter le syst&#xE8;me en s'informant aupr&#xE8;s des futurs utilisateurs\nCela va permettre de cr&#xE9;er le MCC (Mod&#xE8;le conceptuel de la communication) qui d&#xE9;finit les flux d'informations &#xE0; prendre en compte.\nL'&#xE9;tape suivante consiste &#xE0; mettre au point le MCD (Mod&#xE8;le conceptuel des donn&#xE9;es) et le MCT (Mod&#xE8;le conceptuel des traitements) d&#xE9;crivant les r&#xE8;gles et les contraintes &#xE0; prendre en compte.\nLe mod&#xE8;le organisationnel consiste &#xE0; d&#xE9;finir le MOT (Mod&#xE8;le organisationnel des traitements) d&#xE9;crivant les contraintes dues &#xE0; l'environnement (organisationnel, spatial et temporel).\nLe mod&#xE8;le logique repr&#xE9;sente un choix logiciel pour le syst&#xE8;me d'information.\nLe mod&#xE8;le physique refl&#xE8;te un choix mat&#xE9;riel pour le syst&#xE8;me d'information.\n****** \nLe MCD et le diagramme de classes poss&#xE8;dent beaucoup de\npoints communs et une approche de structuration similaire:\n&#x2022; Au niveau des entit&#xE9;s/classes: contrainte de partition, contrainte\nd&#x2019;exclusion, contrainte de totalit&#xE9;, l&#x2019;identifiant est implicite en UML.\n&#x2022; Au niveau des associations: contrainte de partition, d&#x2019;exclusion, de\ntotalit&#xE9;, d&#x2019;inclusion, d&#x2019;unicit&#xE9;, association d&#x2019;association, cardinalit&#xE9;s.\n En UML le diagramme de classes est utilis&#xE9; au cours de\nl&#x2019;ensemble du processus:\n&#x2022; Les classes contiennent les op&#xE9;rations (services),\n&#x2022; Les classes sont analys&#xE9;es du point de vue des responsabilit&#xE9;s,\n&#x2022; Les contraintes sont exprim&#xE9;es dans un langage de contrainte (OCL),\n&#x2022; UML propose des st&#xE9;r&#xE9;otypes,\n&#x2022; UML n&#x2019;implique pas l&#x2019;utilisation d&#x2019;un formalisme de normalisation sur les\nclasses, mais des r&#xE8;gles sont &#xE0; respecter pour &#xE9;viter les erreurs.\n\n\n
Dans Merise le CVO traduit les diff&#xE9;rents &#xE9;tats que peut prendre l'entit&#xE9;, leur succession, les &#xE9;v&#xE9;nements d&#xE9;clencheurs:\n&#x2022; Les &#xE9;tats sont mat&#xE9;rialis&#xE9; par les diff&#xE9;rentes valeurs d'une propri&#xE9;t&#xE9; de\nl'entit&#xE9;,\n&#x2022; Les &#xE9;v&#xE9;nements sont aussi utilis&#xE9;s dans les traitements et apparaissent\ndans les flux du mod&#xE8;le de communication,\n&#x2022; Le CVO est bas&#xE9; sur les r&#xE9;seaux de Petri.\n UML fournit un diagramme &#xE9;tats-transitions qui correspond\ndirectement au CVO:\n&#x2022; Il s'agit des mod&#xE8;les les plus proches,\n&#x2022; UML propose des concepts de sous-&#xE9;tats, de macro-&#xE9;tats, d'&#xE9;tats\nparall&#xE8;les et d&#xE9;taille d'avantage les actions et les op&#xE9;ration\n\n\n
Dans Merise le CVO traduit les diff&#xE9;rents &#xE9;tats que peut prendre l'entit&#xE9;, leur succession, les &#xE9;v&#xE9;nements d&#xE9;clencheurs:\n&#x2022; Les &#xE9;tats sont mat&#xE9;rialis&#xE9; par les diff&#xE9;rentes valeurs d'une propri&#xE9;t&#xE9; de\nl'entit&#xE9;,\n&#x2022; Les &#xE9;v&#xE9;nements sont aussi utilis&#xE9;s dans les traitements et apparaissent\ndans les flux du mod&#xE8;le de communication,\n&#x2022; Le CVO est bas&#xE9; sur les r&#xE9;seaux de Petri.\n UML fournit un diagramme &#xE9;tats-transitions qui correspond\ndirectement au CVO:\n&#x2022; Il s'agit des mod&#xE8;les les plus proches,\n&#x2022; UML propose des concepts de sous-&#xE9;tats, de macro-&#xE9;tats, d'&#xE9;tats\nparall&#xE8;les et d&#xE9;taille d'avantage les actions et les op&#xE9;ration\n\n\n
* La conception du syst&#xE8;me d'information se fait par &#xE9;tapes, afin d'aboutir &#xE0; un syst&#xE8;me d'information fonctionnel refl&#xE9;tant une r&#xE9;alit&#xE9; physique. Il s'agit donc de valider une &#xE0; une chacune des &#xE9;tapes en prenant en compte les r&#xE9;sultats de la phase pr&#xE9;c&#xE9;dente. D'autre part, les donn&#xE9;es &#xE9;tant s&#xE9;par&#xE9;es des traitements, il faut v&#xE9;rifier la concordance entre donn&#xE9;es et traitements afin de v&#xE9;rifier que toutes les donn&#xE9;es n&#xE9;cessaires aux traitements sont pr&#xE9;sentes et qu'il n'y a pas de donn&#xE9;es superflues.\nCette succession d'&#xE9;tapes est appel&#xE9;e cycle d'abstraction pour la conception des syst&#xE8;mes d'information :\nL'expression des besoins est une &#xE9;tape consistant &#xE0; d&#xE9;finir ce que l'on attend du syst&#xE8;me d'information automatis&#xE9;, il faut pour cela :\nfaire l'inventaire des &#xE9;l&#xE9;ments n&#xE9;cessaires au syst&#xE8;me d'information\nd&#xE9;limiter le syst&#xE8;me en s'informant aupr&#xE8;s des futurs utilisateurs\nCela va permettre de cr&#xE9;er le MCC (Mod&#xE8;le conceptuel de la communication) qui d&#xE9;finit les flux d'informations &#xE0; prendre en compte.\nL'&#xE9;tape suivante consiste &#xE0; mettre au point le MCD (Mod&#xE8;le conceptuel des donn&#xE9;es) et le MCT (Mod&#xE8;le conceptuel des traitements) d&#xE9;crivant les r&#xE8;gles et les contraintes &#xE0; prendre en compte.\nLe mod&#xE8;le organisationnel consiste &#xE0; d&#xE9;finir le MOT (Mod&#xE8;le organisationnel des traitements) d&#xE9;crivant les contraintes dues &#xE0; l'environnement (organisationnel, spatial et temporel).\nLe mod&#xE8;le logique repr&#xE9;sente un choix logiciel pour le syst&#xE8;me d'information.\nLe mod&#xE8;le physique refl&#xE8;te un choix mat&#xE9;riel pour le syst&#xE8;me d'information.\n****** \nDans Merise le CVO traduit les diff&#xE9;rents &#xE9;tats que peut prendre\nl'entit&#xE9;, leur succession, les &#xE9;v&#xE9;nements d&#xE9;clencheurs:\n&#x2022; Les &#xE9;tats sont mat&#xE9;rialis&#xE9; par les diff&#xE9;rentes valeurs d'une propri&#xE9;t&#xE9; de\nl'entit&#xE9;,\n&#x2022; Les &#xE9;v&#xE9;nements sont aussi utilis&#xE9;s dans les traitements et apparaissent\ndans les flux du mod&#xE8;le de communication,\n&#x2022; Le CVO est bas&#xE9; sur les r&#xE9;seaux de Petri.\n UML fournit un diagramme &#xE9;tats-transitions qui correspond\ndirectement au CVO:\n&#x2022; Il s'agit des mod&#xE8;les les plus proches,\n&#x2022; UML propose des concepts de sous-&#xE9;tats, de macro-&#xE9;tats, d'&#xE9;tats\nparall&#xE8;les et d&#xE9;taille d'avantage les actions et les op&#xE9;ration\n\n\n
* La conception du syst&#xE8;me d'information se fait par &#xE9;tapes, afin d'aboutir &#xE0; un syst&#xE8;me d'information fonctionnel refl&#xE9;tant une r&#xE9;alit&#xE9; physique. Il s'agit donc de valider une &#xE0; une chacune des &#xE9;tapes en prenant en compte les r&#xE9;sultats de la phase pr&#xE9;c&#xE9;dente. D'autre part, les donn&#xE9;es &#xE9;tant s&#xE9;par&#xE9;es des traitements, il faut v&#xE9;rifier la concordance entre donn&#xE9;es et traitements afin de v&#xE9;rifier que toutes les donn&#xE9;es n&#xE9;cessaires aux traitements sont pr&#xE9;sentes et qu'il n'y a pas de donn&#xE9;es superflues.\nCette succession d'&#xE9;tapes est appel&#xE9;e cycle d'abstraction pour la conception des syst&#xE8;mes d'information :\nL'expression des besoins est une &#xE9;tape consistant &#xE0; d&#xE9;finir ce que l'on attend du syst&#xE8;me d'information automatis&#xE9;, il faut pour cela :\nfaire l'inventaire des &#xE9;l&#xE9;ments n&#xE9;cessaires au syst&#xE8;me d'information\nd&#xE9;limiter le syst&#xE8;me en s'informant aupr&#xE8;s des futurs utilisateurs\nCela va permettre de cr&#xE9;er le MCC (Mod&#xE8;le conceptuel de la communication) qui d&#xE9;finit les flux d'informations &#xE0; prendre en compte.\nL'&#xE9;tape suivante consiste &#xE0; mettre au point le MCD (Mod&#xE8;le conceptuel des donn&#xE9;es) et le MCT (Mod&#xE8;le conceptuel des traitements) d&#xE9;crivant les r&#xE8;gles et les contraintes &#xE0; prendre en compte.\nLe mod&#xE8;le organisationnel consiste &#xE0; d&#xE9;finir le MOT (Mod&#xE8;le organisationnel des traitements) d&#xE9;crivant les contraintes dues &#xE0; l'environnement (organisationnel, spatial et temporel).\nLe mod&#xE8;le logique repr&#xE9;sente un choix logiciel pour le syst&#xE8;me d'information.\nLe mod&#xE8;le physique refl&#xE8;te un choix mat&#xE9;riel pour le syst&#xE8;me d'information.\n****** \nDans Merise le CVO traduit les diff&#xE9;rents &#xE9;tats que peut prendre\nl'entit&#xE9;, leur succession, les &#xE9;v&#xE9;nements d&#xE9;clencheurs:\n&#x2022; Les &#xE9;tats sont mat&#xE9;rialis&#xE9; par les diff&#xE9;rentes valeurs d'une propri&#xE9;t&#xE9; de\nl'entit&#xE9;,\n&#x2022; Les &#xE9;v&#xE9;nements sont aussi utilis&#xE9;s dans les traitements et apparaissent\ndans les flux du mod&#xE8;le de communication,\n&#x2022; Le CVO est bas&#xE9; sur les r&#xE9;seaux de Petri.\n UML fournit un diagramme &#xE9;tats-transitions qui correspond\ndirectement au CVO:\n&#x2022; Il s'agit des mod&#xE8;les les plus proches,\n&#x2022; UML propose des concepts de sous-&#xE9;tats, de macro-&#xE9;tats, d'&#xE9;tats\nparall&#xE8;les et d&#xE9;taille d'avantage les actions et les op&#xE9;ration\n\n\n
On trouve les concepts d'&#xE9;v&#xE9;nements, de r&#xE8;gles de gestion, de\nsynchronisation et d'op&#xE9;rations qui r&#xE9;utilisent la notion de flux:\n&#x2022; Les flux doivent &#xEA;tre compl&#xE8;tement d&#xE9;crits,\n&#x2022; Les flux entrants sont des activateurs qui d&#xE9;clenchent des traitements,\n&#x2022; Les flux sortants placent le SI dans un nouvel &#xE9;tat.\n En UML, &#xE9;v&#xE9;nements internes et externes apparaissent au\nniveau des diagrammes s&#xE9;quences/activit&#xE9;s.\n&#x2022; Les r&#xE8;gles de gestion apparaissent dans les contraintes OCL et dans les\nm&#xE9;thodes des classes,\n&#x2022; Les synchronisations apparaissent dans les diagrammes d'activit&#xE9;s et\nd'&#xE9;tats-transitions,\n&#x2022; Les op&#xE9;rations sont repr&#xE9;sent&#xE9;es dans les diagrammes d'activit&#xE9;s.\n En r&#xE9;sum&#xE9;: pour retrouver les informations d'un MCT, il faut\njongler avec diff&#xE9;rents diagrammes en UML !!!\n\n\n
On trouve les concepts d'&#xE9;v&#xE9;nements, de r&#xE8;gles de gestion, de\nsynchronisation et d'op&#xE9;rations qui r&#xE9;utilisent la notion de flux:\n&#x2022; Les flux doivent &#xEA;tre compl&#xE8;tement d&#xE9;crits,\n&#x2022; Les flux entrants sont des activateurs qui d&#xE9;clenchent des traitements,\n&#x2022; Les flux sortants placent le SI dans un nouvel &#xE9;tat.\n En UML, &#xE9;v&#xE9;nements internes et externes apparaissent au\nniveau des diagrammes s&#xE9;quences/activit&#xE9;s.\n&#x2022; Les r&#xE8;gles de gestion apparaissent dans les contraintes OCL et dans les\nm&#xE9;thodes des classes,\n&#x2022; Les synchronisations apparaissent dans les diagrammes d'activit&#xE9;s et\nd'&#xE9;tats-transitions,\n&#x2022; Les op&#xE9;rations sont repr&#xE9;sent&#xE9;es dans les diagrammes d'activit&#xE9;s.\n En r&#xE9;sum&#xE9;: pour retrouver les informations d'un MCT, il faut\njongler avec diff&#xE9;rents diagrammes en UML !!!\n\n\n
On trouve les concepts d'&#xE9;v&#xE9;nements, de r&#xE8;gles de gestion, de\nsynchronisation et d'op&#xE9;rations qui r&#xE9;utilisent la notion de flux:\n&#x2022; Les flux doivent &#xEA;tre compl&#xE8;tement d&#xE9;crits,\n&#x2022; Les flux entrants sont des activateurs qui d&#xE9;clenchent des traitements,\n&#x2022; Les flux sortants placent le SI dans un nouvel &#xE9;tat.\n En UML, &#xE9;v&#xE9;nements internes et externes apparaissent au\nniveau des diagrammes s&#xE9;quences/activit&#xE9;s.\n&#x2022; Les r&#xE8;gles de gestion apparaissent dans les contraintes OCL et dans les\nm&#xE9;thodes des classes,\n&#x2022; Les synchronisations apparaissent dans les diagrammes d'activit&#xE9;s et\nd'&#xE9;tats-transitions,\n&#x2022; Les op&#xE9;rations sont repr&#xE9;sent&#xE9;es dans les diagrammes d'activit&#xE9;s.\n En r&#xE9;sum&#xE9;: pour retrouver les informations d'un MCT, il faut\njongler avec diff&#xE9;rents diagrammes en UML !!!\n\n\n
On trouve les concepts d'&#xE9;v&#xE9;nements, de r&#xE8;gles de gestion, de\nsynchronisation et d'op&#xE9;rations qui r&#xE9;utilisent la notion de flux:\n&#x2022; Les flux doivent &#xEA;tre compl&#xE8;tement d&#xE9;crits,\n&#x2022; Les flux entrants sont des activateurs qui d&#xE9;clenchent des traitements,\n&#x2022; Les flux sortants placent le SI dans un nouvel &#xE9;tat.\n En UML, &#xE9;v&#xE9;nements internes et externes apparaissent au\nniveau des diagrammes s&#xE9;quences/activit&#xE9;s.\n&#x2022; Les r&#xE8;gles de gestion apparaissent dans les contraintes OCL et dans les\nm&#xE9;thodes des classes,\n&#x2022; Les synchronisations apparaissent dans les diagrammes d'activit&#xE9;s et\nd'&#xE9;tats-transitions,\n&#x2022; Les op&#xE9;rations sont repr&#xE9;sent&#xE9;es dans les diagrammes d'activit&#xE9;s.\n En r&#xE9;sum&#xE9;: pour retrouver les informations d'un MCT, il faut\njongler avec diff&#xE9;rents diagrammes en UML !!!\n\n\n
* La conception du syst&#xE8;me d'information se fait par &#xE9;tapes, afin d'aboutir &#xE0; un syst&#xE8;me d'information fonctionnel refl&#xE9;tant une r&#xE9;alit&#xE9; physique. Il s'agit donc de valider une &#xE0; une chacune des &#xE9;tapes en prenant en compte les r&#xE9;sultats de la phase pr&#xE9;c&#xE9;dente. D'autre part, les donn&#xE9;es &#xE9;tant s&#xE9;par&#xE9;es des traitements, il faut v&#xE9;rifier la concordance entre donn&#xE9;es et traitements afin de v&#xE9;rifier que toutes les donn&#xE9;es n&#xE9;cessaires aux traitements sont pr&#xE9;sentes et qu'il n'y a pas de donn&#xE9;es superflues.\nCette succession d'&#xE9;tapes est appel&#xE9;e cycle d'abstraction pour la conception des syst&#xE8;mes d'information :\nL'expression des besoins est une &#xE9;tape consistant &#xE0; d&#xE9;finir ce que l'on attend du syst&#xE8;me d'information automatis&#xE9;, il faut pour cela :\nfaire l'inventaire des &#xE9;l&#xE9;ments n&#xE9;cessaires au syst&#xE8;me d'information\nd&#xE9;limiter le syst&#xE8;me en s'informant aupr&#xE8;s des futurs utilisateurs\nCela va permettre de cr&#xE9;er le MCC (Mod&#xE8;le conceptuel de la communication) qui d&#xE9;finit les flux d'informations &#xE0; prendre en compte.\nL'&#xE9;tape suivante consiste &#xE0; mettre au point le MCD (Mod&#xE8;le conceptuel des donn&#xE9;es) et le MCT (Mod&#xE8;le conceptuel des traitements) d&#xE9;crivant les r&#xE8;gles et les contraintes &#xE0; prendre en compte.\nLe mod&#xE8;le organisationnel consiste &#xE0; d&#xE9;finir le MOT (Mod&#xE8;le organisationnel des traitements) d&#xE9;crivant les contraintes dues &#xE0; l'environnement (organisationnel, spatial et temporel).\nLe mod&#xE8;le logique repr&#xE9;sente un choix logiciel pour le syst&#xE8;me d'information.\nLe mod&#xE8;le physique refl&#xE8;te un choix mat&#xE9;riel pour le syst&#xE8;me d'information.\n****** \n\nMod&#xE8;les organisationnels\n Le niveau organisationnel des traitements utilisent plusieurs concepts:\n&#x2022; Les fonctions: issues de la d&#xE9;composition des r&#xE8;gles de gestion. Une fonction est activ&#xE9;e par\nun &#xE9;v&#xE9;nement, elle fournit un r&#xE9;sultat et un mod&#xE8;le de donn&#xE9;es sp&#xE9;cifiques. Seules les\nfonctions &#xE9;l&#xE9;mentaires sont d&#xE9;crites (CMSV).\n&#x2022; Flux organisationnels: notion de consommation des &#xE9;v&#xE9;nements,\n&#x2022; Proc&#xE9;dure fonctionnelle: ensemble coh&#xE9;rent de fonctions affect&#xE9; &#xE0; des types d'acteurs avec\nun profil (automatisation, fr&#xE9;quence, p&#xE9;riodicit&#xE9;, etc.)\n&#x2022; Type d'acteur: ensemble de personnes exer&#xE7;ant les m&#xEA;mes actions sur le SI.\n&#x2022; Le MOT suit un certain nombre de r&#xE8;gles de construction.\n En UML, les aspects dynamiques apparaissent la encore dans les diagrammes\nd'activit&#xE9;s/s&#xE9;quences:\n&#x2022; Servent directement pour le passage du m&#xE9;tier au syst&#xE8;me informatique,\n&#x2022; Les &#xE9;changes et les attentes apparaissent clairement dans les activit&#xE9;s,\n&#x2022; Merise offre une vision plus globale de l'organisation.\n Le niveau MOD:\n&#x2022; On d&#xE9;crit les propri&#xE9;t&#xE9;s de chaque donn&#xE9;es (confidentialit&#xE9;, visibilit&#xE9;) et la localisation sur\nles diff&#xE9;rents sites.\n&#x2022; On retrouve cela en UML dans la notion de travailleur d'interface, de contr&#xF4;le et dans\nl'approche architecture logicielle.\n\n\n\n
* La conception du syst&#xE8;me d'information se fait par &#xE9;tapes, afin d'aboutir &#xE0; un syst&#xE8;me d'information fonctionnel refl&#xE9;tant une r&#xE9;alit&#xE9; physique. Il s'agit donc de valider une &#xE0; une chacune des &#xE9;tapes en prenant en compte les r&#xE9;sultats de la phase pr&#xE9;c&#xE9;dente. D'autre part, les donn&#xE9;es &#xE9;tant s&#xE9;par&#xE9;es des traitements, il faut v&#xE9;rifier la concordance entre donn&#xE9;es et traitements afin de v&#xE9;rifier que toutes les donn&#xE9;es n&#xE9;cessaires aux traitements sont pr&#xE9;sentes et qu'il n'y a pas de donn&#xE9;es superflues.\nCette succession d'&#xE9;tapes est appel&#xE9;e cycle d'abstraction pour la conception des syst&#xE8;mes d'information :\nL'expression des besoins est une &#xE9;tape consistant &#xE0; d&#xE9;finir ce que l'on attend du syst&#xE8;me d'information automatis&#xE9;, il faut pour cela :\nfaire l'inventaire des &#xE9;l&#xE9;ments n&#xE9;cessaires au syst&#xE8;me d'information\nd&#xE9;limiter le syst&#xE8;me en s'informant aupr&#xE8;s des futurs utilisateurs\nCela va permettre de cr&#xE9;er le MCC (Mod&#xE8;le conceptuel de la communication) qui d&#xE9;finit les flux d'informations &#xE0; prendre en compte.\nL'&#xE9;tape suivante consiste &#xE0; mettre au point le MCD (Mod&#xE8;le conceptuel des donn&#xE9;es) et le MCT (Mod&#xE8;le conceptuel des traitements) d&#xE9;crivant les r&#xE8;gles et les contraintes &#xE0; prendre en compte.\nLe mod&#xE8;le organisationnel consiste &#xE0; d&#xE9;finir le MOT (Mod&#xE8;le organisationnel des traitements) d&#xE9;crivant les contraintes dues &#xE0; l'environnement (organisationnel, spatial et temporel).\nLe mod&#xE8;le logique repr&#xE9;sente un choix logiciel pour le syst&#xE8;me d'information.\nLe mod&#xE8;le physique refl&#xE8;te un choix mat&#xE9;riel pour le syst&#xE8;me d'information.\n****** \n\n\n\n
* La conception du syst&#xE8;me d'information se fait par &#xE9;tapes, afin d'aboutir &#xE0; un syst&#xE8;me d'information fonctionnel refl&#xE9;tant une r&#xE9;alit&#xE9; physique. Il s'agit donc de valider une &#xE0; une chacune des &#xE9;tapes en prenant en compte les r&#xE9;sultats de la phase pr&#xE9;c&#xE9;dente. D'autre part, les donn&#xE9;es &#xE9;tant s&#xE9;par&#xE9;es des traitements, il faut v&#xE9;rifier la concordance entre donn&#xE9;es et traitements afin de v&#xE9;rifier que toutes les donn&#xE9;es n&#xE9;cessaires aux traitements sont pr&#xE9;sentes et qu'il n'y a pas de donn&#xE9;es superflues.\nCette succession d'&#xE9;tapes est appel&#xE9;e cycle d'abstraction pour la conception des syst&#xE8;mes d'information :\nL'expression des besoins est une &#xE9;tape consistant &#xE0; d&#xE9;finir ce que l'on attend du syst&#xE8;me d'information automatis&#xE9;, il faut pour cela :\nfaire l'inventaire des &#xE9;l&#xE9;ments n&#xE9;cessaires au syst&#xE8;me d'information\nd&#xE9;limiter le syst&#xE8;me en s'informant aupr&#xE8;s des futurs utilisateurs\nCela va permettre de cr&#xE9;er le MCC (Mod&#xE8;le conceptuel de la communication) qui d&#xE9;finit les flux d'informations &#xE0; prendre en compte.\nL'&#xE9;tape suivante consiste &#xE0; mettre au point le MCD (Mod&#xE8;le conceptuel des donn&#xE9;es) et le MCT (Mod&#xE8;le conceptuel des traitements) d&#xE9;crivant les r&#xE8;gles et les contraintes &#xE0; prendre en compte.\nLe mod&#xE8;le organisationnel consiste &#xE0; d&#xE9;finir le MOT (Mod&#xE8;le organisationnel des traitements) d&#xE9;crivant les contraintes dues &#xE0; l'environnement (organisationnel, spatial et temporel).\nLe mod&#xE8;le logique repr&#xE9;sente un choix logiciel pour le syst&#xE8;me d'information.\nLe mod&#xE8;le physique refl&#xE8;te un choix mat&#xE9;riel pour le syst&#xE8;me d'information.\n****** \n\n\n\n
* La conception du syst&#xE8;me d'information se fait par &#xE9;tapes, afin d'aboutir &#xE0; un syst&#xE8;me d'information fonctionnel refl&#xE9;tant une r&#xE9;alit&#xE9; physique. Il s'agit donc de valider une &#xE0; une chacune des &#xE9;tapes en prenant en compte les r&#xE9;sultats de la phase pr&#xE9;c&#xE9;dente. D'autre part, les donn&#xE9;es &#xE9;tant s&#xE9;par&#xE9;es des traitements, il faut v&#xE9;rifier la concordance entre donn&#xE9;es et traitements afin de v&#xE9;rifier que toutes les donn&#xE9;es n&#xE9;cessaires aux traitements sont pr&#xE9;sentes et qu'il n'y a pas de donn&#xE9;es superflues.\nCette succession d'&#xE9;tapes est appel&#xE9;e cycle d'abstraction pour la conception des syst&#xE8;mes d'information :\nL'expression des besoins est une &#xE9;tape consistant &#xE0; d&#xE9;finir ce que l'on attend du syst&#xE8;me d'information automatis&#xE9;, il faut pour cela :\nfaire l'inventaire des &#xE9;l&#xE9;ments n&#xE9;cessaires au syst&#xE8;me d'information\nd&#xE9;limiter le syst&#xE8;me en s'informant aupr&#xE8;s des futurs utilisateurs\nCela va permettre de cr&#xE9;er le MCC (Mod&#xE8;le conceptuel de la communication) qui d&#xE9;finit les flux d'informations &#xE0; prendre en compte.\nL'&#xE9;tape suivante consiste &#xE0; mettre au point le MCD (Mod&#xE8;le conceptuel des donn&#xE9;es) et le MCT (Mod&#xE8;le conceptuel des traitements) d&#xE9;crivant les r&#xE8;gles et les contraintes &#xE0; prendre en compte.\nLe mod&#xE8;le organisationnel consiste &#xE0; d&#xE9;finir le MOT (Mod&#xE8;le organisationnel des traitements) d&#xE9;crivant les contraintes dues &#xE0; l'environnement (organisationnel, spatial et temporel).\nLe mod&#xE8;le logique repr&#xE9;sente un choix logiciel pour le syst&#xE8;me d'information.\nLe mod&#xE8;le physique refl&#xE8;te un choix mat&#xE9;riel pour le syst&#xE8;me d'information.\n****** \n\n\n\n
\n
\n
UML nous le verrons plus tard\n
UML nous le verrons plus tard\n
UML nous le verrons plus tard\n
UML nous le verrons plus tard\n
UML nous le verrons plus tard\n
UML nous le verrons plus tard\n
Le feedback continu est un &#xE9;l&#xE9;ment cl&#xE9; du succ&#xE8;s.\nDe la part le retour des utilisateurs, des tests, . . .\nA chaque it&#xE9;ration, on s'adapte en se basant sur le feedback et les le&#xE7;ons de la derni&#xE8;re it&#xE9;ration, et on converge doucement vers de meilleurs : \nConception, Plans, Exigences, Estimations.\n
Des unit&#xE9;s logicielles "bo&#xEE;te-noire" avec une API\nFonctionnent g&#xE9;n&#xE9;ralement dans une (locale ou distante) architecture &#xE0; base de composants: EJB, COM, .NET, JavaBeans\nLe UP encourage la bonne pratique suivante: \nAcqu&#xE9;rir des composants existants afin d'acc&#xE9;l&#xE9;rer le d&#xE9;veloppement\nEtablir une culture d'acquisition ou d'achat de composants, plut&#xF4;t que de d&#xE9;velopper toutes les parties du logiciel.\n
La gestion des risques est une d&#xE9;marche proactive, alors que la gestion des probl&#xE8;mes est une d&#xE9;marche r&#xE9;active.\nIl ne faut pas confondre risque et probl&#xE8;me.\nUn probl&#xE8;me est un risque qui s&#x2019;est r&#xE9;v&#xE9;l&#xE9;.\n
Par exemple : \nL&#x2019;int&#xE9;gration, l&#x2019;architecture\nLa gestion des ressources humaines n&#xE9;cessite une attention particuli&#xE8;re : Besoins ? Profils ? Organisation de l&#x2019;&#xE9;quipe projet ? Communication et management de l&#x2019;&#xE9;quipe\n
\n
\nQui a entendu parler du Standish Group ? \nLe Standish Group International, Inc. est une soci&#xE9;t&#xE9; d&#x2019;&#xE9;tudes de march&#xE9; et de conseil sp&#xE9;cialis&#xE9;e dans la conception de logiciels strat&#xE9;giques et le commerce &#xE9;lectronique. (Rendez-vous sur le site www.standishgroup.com.) \nSon fondateur, Jim Johnson, s&#x2019;est rendu en Su&#xE8;de pour expliquer, au cours d&#x2019;une conf&#xE9;rence, la responsabilit&#xE9; des L4G dans l&#x2019;&#xE9;chec de projets informatiques dans les entreprises. Et, &#xE0; sa grande surprise, apr&#xE8;s avoir pos&#xE9; au public la question suivante : &#xAB;&#xA0;pourquoi vos projets &#xE9;chouent-ils ?&#xA0;&#xBB;, il s&#x2019;est entendu r&#xE9;pondre : &#xAB;&#xA0;parce que les exigences sont mal d&#xE9;finies&#xA0;&#xBB;. Pour approfondir le sujet, Jim Johnson s&#x2019;est alors livr&#xE9; &#xE0; une &#xE9;tude formelle des ateliers informatiques des grandes entreprises et a fait appara&#xEE;tre quelques r&#xE9;sultats int&#xE9;ressants sur des projets &#xAB;&#xA0;remis en question&#xA0;&#xBB; ou compromis.\nLes projets remis en question subissaient des d&#xE9;passements de budgets et de d&#xE9;lais, tandis que les projets compromis &#xE9;taient purement et simplement annul&#xE9;s. En cherchant &#xE0; savoir ce qui avait provoqu&#xE9; l&#x2019;annulation ou la remise en question du projet, le Standish Group en a appris plus long sur les probl&#xE8;mes recens&#xE9;s ci-dessus. Remarquez que les probl&#xE8;mes li&#xE9;s &#xE0; la gestion des exigences figurent en t&#xEA;te des causes ayant conduit &#xE0; l&#x2019;&#xE9;chec du projet. \n
\n
\n
\n
\n
1) le cycle de vie, c&#x2019;est le cycle de d&#xE9;veloppement + la phase de sp&#xE9;cification et la phase de maintenance.\n\n2) Cycle de d&#xE9;veloppementCycle de vie\nsp&#xE9;cification+planification20% 8%\n &#xE9;tudier le probl&#xE8;me\n analyser les besoins\n sp&#xE9;cifier actions et donn&#xE9;es\nconception+ d&#xE9;veloppement30%12%\n d&#xE9;composer le projet\n affiner les parties, les coder\n documenter la conception\ntests + validation50%20%\n v&#xE9;rifier les fonctions\n tester les performances\n optimiser\nop&#xE9;ration + maintenance60%\n formation des utilisateurs\n appliquer le logiciel\n maintenance corrective et &#xE9;volutive\n portage du programme ailleurs\n
1) le cycle de vie, c&#x2019;est le cycle de d&#xE9;veloppement + la phase de sp&#xE9;cification et la phase de maintenance.\n\n2) Cycle de d&#xE9;veloppementCycle de vie\nsp&#xE9;cification+planification20% 8%\n &#xE9;tudier le probl&#xE8;me\n analyser les besoins\n sp&#xE9;cifier actions et donn&#xE9;es\nconception+ d&#xE9;veloppement30%12%\n d&#xE9;composer le projet\n affiner les parties, les coder\n documenter la conception\ntests + validation50%20%\n v&#xE9;rifier les fonctions\n tester les performances\n optimiser\nop&#xE9;ration + maintenance60%\n formation des utilisateurs\n appliquer le logiciel\n maintenance corrective et &#xE9;volutive\n portage du programme ailleurs\n
\n=========================\nL'Extreme Programming repose sur des cycles rapides de d&#xE9;veloppement (des it&#xE9;rations de quelques semaines) dont les &#xE9;tapes sont les suivantes&#xA0;:\n&#x2022;une phase d'exploration d&#xE9;termine les sc&#xE9;narios clients qui seront fournis pendant cette it&#xE9;ration&#xA0;;\n&#x2022;l'&#xE9;quipe transforme les sc&#xE9;narios en t&#xE2;ches &#xE0; r&#xE9;aliser et en tests fonctionnels&#xA0;;\n&#x2022;chaque d&#xE9;veloppeur s'attribue des t&#xE2;ches et les r&#xE9;alise avec un bin&#xF4;me&#xA0;;\n&#x2022;lorsque tous les tests fonctionnels passent, le produit est livr&#xE9;.\nLe cycle se r&#xE9;p&#xE8;te tant que le client peut fournir des sc&#xE9;narios &#xE0; livrer. G&#xE9;n&#xE9;ralement le cycle de la premi&#xE8;re livraison se caract&#xE9;rise par sa dur&#xE9;e et le volume important de fonctionnalit&#xE9;s embarqu&#xE9;es. Apr&#xE8;s la premi&#xE8;re mise en production, les it&#xE9;rations peuvent devenir plus courtes (une semaine par exemple).\nLa programmation comme discipline collective [modifier]\nTout en mettant l'accent sur les bonnes pratiques de programmation, XP pr&#xE9;conise un d&#xE9;roulement par it&#xE9;rations courtes et g&#xE9;r&#xE9;es collectivement, avec une implication constante du client. Il en d&#xE9;coule une red&#xE9;finition de la relation entre client et fournisseur avec de surprenants r&#xE9;sultats en termes de qualit&#xE9; de code, de d&#xE9;lais et de satisfaction de la demande du client.\n\n
1) le cycle de vie, c&#x2019;est le cycle de d&#xE9;veloppement + la phase de sp&#xE9;cification et la phase de maintenance.\n\n2) Cycle de d&#xE9;veloppementCycle de vie\nsp&#xE9;cification+planification20% 8%\n &#xE9;tudier le probl&#xE8;me\n analyser les besoins\n sp&#xE9;cifier actions et donn&#xE9;es\nconception+ d&#xE9;veloppement30%12%\n d&#xE9;composer le projet\n affiner les parties, les coder\n documenter la conception\ntests + validation50%20%\n v&#xE9;rifier les fonctions\n tester les performances\n optimiser\nop&#xE9;ration + maintenance60%\n formation des utilisateurs\n appliquer le logiciel\n maintenance corrective et &#xE9;volutive\n portage du programme ailleurs\n
1) le cycle de vie, c&#x2019;est le cycle de d&#xE9;veloppement + la phase de sp&#xE9;cification et la phase de maintenance.\n\n2) Cycle de d&#xE9;veloppementCycle de vie\nsp&#xE9;cification+planification20% 8%\n &#xE9;tudier le probl&#xE8;me\n analyser les besoins\n sp&#xE9;cifier actions et donn&#xE9;es\nconception+ d&#xE9;veloppement30%12%\n d&#xE9;composer le projet\n affiner les parties, les coder\n documenter la conception\ntests + validation50%20%\n v&#xE9;rifier les fonctions\n tester les performances\n optimiser\nop&#xE9;ration + maintenance60%\n formation des utilisateurs\n appliquer le logiciel\n maintenance corrective et &#xE9;volutive\n portage du programme ailleurs\n
1) le cycle de vie, c&#x2019;est le cycle de d&#xE9;veloppement + la phase de sp&#xE9;cification et la phase de maintenance.\n\n2) Cycle de d&#xE9;veloppementCycle de vie\nsp&#xE9;cification+planification20% 8%\n &#xE9;tudier le probl&#xE8;me\n analyser les besoins\n sp&#xE9;cifier actions et donn&#xE9;es\nconception+ d&#xE9;veloppement30%12%\n d&#xE9;composer le projet\n affiner les parties, les coder\n documenter la conception\ntests + validation50%20%\n v&#xE9;rifier les fonctions\n tester les performances\n optimiser\nop&#xE9;ration + maintenance60%\n formation des utilisateurs\n appliquer le logiciel\n maintenance corrective et &#xE9;volutive\n portage du programme ailleurs\n
1) le cycle de vie, c&#x2019;est le cycle de d&#xE9;veloppement + la phase de sp&#xE9;cification et la phase de maintenance.\n\n2) Cycle de d&#xE9;veloppementCycle de vie\nsp&#xE9;cification+planification20% 8%\n &#xE9;tudier le probl&#xE8;me\n analyser les besoins\n sp&#xE9;cifier actions et donn&#xE9;es\nconception+ d&#xE9;veloppement30%12%\n d&#xE9;composer le projet\n affiner les parties, les coder\n documenter la conception\ntests + validation50%20%\n v&#xE9;rifier les fonctions\n tester les performances\n optimiser\nop&#xE9;ration + maintenance60%\n formation des utilisateurs\n appliquer le logiciel\n maintenance corrective et &#xE9;volutive\n portage du programme ailleurs\n
1) le cycle de vie, c&#x2019;est le cycle de d&#xE9;veloppement + la phase de sp&#xE9;cification et la phase de maintenance.\n\n2) Cycle de d&#xE9;veloppementCycle de vie\nsp&#xE9;cification+planification20% 8%\n &#xE9;tudier le probl&#xE8;me\n analyser les besoins\n sp&#xE9;cifier actions et donn&#xE9;es\nconception+ d&#xE9;veloppement30%12%\n d&#xE9;composer le projet\n affiner les parties, les coder\n documenter la conception\ntests + validation50%20%\n v&#xE9;rifier les fonctions\n tester les performances\n optimiser\nop&#xE9;ration + maintenance60%\n formation des utilisateurs\n appliquer le logiciel\n maintenance corrective et &#xE9;volutive\n portage du programme ailleurs\n
DEFINITION GENERALE DE CHAQUE PHASE\nD&#xE9;finir la compr&#xE9;hension du besoin, le cadre du d&#xE9;veloppement par rapport au syst&#xE8;me existant mais aussi la liste des contraintes. A ce stade, il faut aussi d&#xE9;finir les utilisateurs externes au logiciel et ses grands packages de service.\nanalyse d&#xE9;taill&#xE9;e permet de sp&#xE9;cifier pr&#xE9;cis&#xE9;ment l'ensemble des services fournis par le logiciel.\nEn phase d'analyse il faut toujours rester dans une vision externe du logiciel.\nConception Cette phase se d&#xE9;compose en \n&#xE9;tude technique initiale permettant de d&#xE9;finir l'architecture technique du logiciel et les principes d'impl&#xE9;mentation.\nconception pr&#xE9;liminaire permettant de formaliser l'architecture technique avec l'ensemble des concepts techniques.\nconception d&#xE9;taill&#xE9;e permettant de pr&#xE9;ciser les services techniques et de pr&#xE9;parer la phase de d&#xE9;veloppement.\nD&#xE9;veloppement des composants Cette phase regroupe les activit&#xE9;s de codage (ou impl&#xE9;mentation des services), de mise au point des composants et leur test unitaire.\nInt&#xE9;gration Cette phase regroupe les activit&#xE9;s d'assemblage des composants et de tests des sous-ensembles du logiciel afin de valider l'architecture technique.\nValidation Cette phase permet de v&#xE9;rifier la conformit&#xE9; du logiciel &#xE0; ses sp&#xE9;cifications.\n
Il s&#x2019;agit du cycle classique. C&#x2019;est aussi le cycle en cascade, o&#xF9; les fl&#xE8;ches vont dans les deux sens (on v&#xE9;rifie &#xE0; chaque &#xE9;tape la conformit&#xE9; aux sp&#xE9;cifications de l&#x2019;&#xE9;tape pr&#xE9;c&#xE9;dente).\n\nLes fl&#xE8;ches bleues montrent les tests qui correspondent aux phases initiales.\n\nLe risque essentiel est d&#xFB; au temps qui s&#xE9;pare l&#x2019;expression des besoins de la phase de validation: on peut s&#x2019;apercevoir apr&#xE8;s de longs mois que le produit n&#x2019;est pas ce que voulait r&#xE9;ellement le client. \n
\n
Source anonyme IBM, sans doute bas&#xE9;e sur une longue exp&#xE9;rience de la gestion de projet ;-)\n
Frederick Winslow Taylor (20&#xA0;mars&#xA0;1856, Germantown (Pennsylvanie) - 21&#xA0;mars&#xA0;1915, Philadelphie (Pennsylvanie) &#xE9;tait un ing&#xE9;nieur am&#xE9;ricain qui a mis en application l'organisation scientifique du travail, qui est la base de la r&#xE9;volution industrielle du XXe&#xA0;si&#xE8;cle.\nSes travaux de recherche ont conduit au d&#xE9;veloppement du travail &#xE0; la cha&#xEE;ne, &#xE0; la parcellisation des t&#xE2;ches, en transformant les ouvriers et les employ&#xE9;s &#xE0; ne devenir que de simples machines de guerre dans d'immenses entreprises m&#xE9;canis&#xE9;es. Pour Taylor, le r&#xF4;le de l'encadrement consiste &#xE0; indiquer aux employ&#xE9;s la meilleure mani&#xE8;re de r&#xE9;aliser une t&#xE2;che, de leur fournir les outils et formations appropri&#xE9;s, et de leur d&#xE9;livrer des objectifs et incitations en vue d'atteindre la performance. Selon ses d&#xE9;tracteurs, il a introduit dans le monde du travail une s&#xE9;paration radicale entre ceux qui con&#xE7;oivent et ceux qui produisent. Pour Taylor, l&#x2019;ouvrier n&#x2019;est pas l&#xE0; pour penser, mais pour ex&#xE9;cuter des gestes savamment calcul&#xE9;s pour lui. Il est encourag&#xE9; &#xE0; &#xEA;tre performant par un syst&#xE8;me de primes. Tout travail intellectuel doit &#xEA;tre &#xE9;limin&#xE9; de l&#x2019;atelier pour &#xEA;tre concentr&#xE9; dans les bureaux de planification et d&#x2019;organisation de l&#x2019;entreprise.\n\n
CYCLES DE VIE TRADITIONNELS\nle cycle "en cascade" (ou "waterfall") d&#xE9;finit les phases d'analyse (d&#xE9;crire le "quoi"), de conception (d&#xE9;finir "comment" le syst&#xE8;me sera r&#xE9;alis&#xE9; et comment il se d&#xE9;compose) de codage (r&#xE9;alisation de chaque composant), de test unitaire (validation de chaque composant), d'int&#xE9;gration (assemblage des composants), de validation (v&#xE9;rification de la conformit&#xE9; du produit par rapport &#xE0; sa sp&#xE9;cification).\nle cycle en "V" est une variante du cycle "en cascade", il fait la distinction entre les phases de construction du logiciel et les phases de v&#xE9;rification. Il &#xE9;tablit &#xE9;galement les liens entre ces phases de construction et les phases de v&#xE9;rification.\nEn g&#xE9;n&#xE9;ral, ces types de cycle de vie mettent l'accent sur les liens entre phases et les moyens de passage de l'une &#xE0; l'autre, y compris lors de retour arri&#xE8;re.\nCYCLE EN SPIRALE\nLes cycles de vie traditionnels ne garantissent pas totalement les incoh&#xE9;rences entre phases et n'assurent pas que le cycle de vie puisse &#xEA;tre appliqu&#xE9; int&#xE9;gralement (par exemple, si l'analyse est trop vague ou incoh&#xE9;rente, la phase de conception sera difficile &#xE0; r&#xE9;aliser ce qui n&#xE9;cessitera de nombreux retours en phase d'analyse. De plus, cette situation engendre des impossibilit&#xE9;s dans le contr&#xF4;le du d&#xE9;roulement du projet. Pour palier ces manques, Barry&#xA0;Boehm a d&#xE9;fini le cycle en spirale qui ponctue chaque phase par une analyse des risques encourus sur la phase suivante. Si les risques sont importants, l'&#xE9;quipe aura recourt &#xE0; du prototypage.\nL'objectif &#xE9;tant de se lancer dans un d&#xE9;veloppement traditionnel seulement lorsque tous les risques sont ma&#xEE;tris&#xE9;s.\nAPPROCHE ORIENTEE OBJET\nAvec une op&#xE9;ration telle que UML, l'&#xE9;quipe formalise le probl&#xE8;me avec le m&#xEA;me mod&#xE8;le tout au long du cycle de vie. Ceci n&#xE9;cessite &#xE9;videmment de proposer une solution m&#xE9;thodologique compl&#xE8;te.\n\n\n\nRaffinement it&#xE9;ratif\nPremi&#xE8;re it&#xE9;ration\nCommencer au centre de la spirale, planifier le projet, et recueillir les besoins initiaux.\nEffectuer une analyse de risques bas&#xE9;e sur les besoins initiaux, prendre la d&#xE9;cision appropri&#xE9;e, et continuer si c'est positif.\nCr&#xE9;er un prototype initial du syst&#xE8;me\nL'usager &#xE9;value ( et le d&#xE9;veloppeur) le prototype\n\nDeuxi&#xE8;me it&#xE9;ration\nLe feedback de l'&#xE9;valuation est utilis&#xE9; pour raffiner les besoins et on planifie davantage le projet.\nEffectuer une analyse de risques bas&#xE9;e sur les besoins r&#xE9;vis&#xE9;s, prendre la d&#xE9;cision appropri&#xE9;e, et continuer si c'est positif.\nCr&#xE9;er un deuxi&#xE8;me prototype, bas&#xE9; sur le prototype initial ou en construire un &#xE0; partir de z&#xE9;ro.\nL'usager &#xE9;value ( et le d&#xE9;veloppeur) le deuxi&#xE8;me prototype\n\nN-i&#xE8;me it&#xE9;rations\nR&#xE9;p&#xE9;ter la deuxi&#xE8;me it&#xE9;ration si d&#xE9;sir&#xE9;\n\nApr&#xE8;s la derni&#xE8;re d&#xE9;cision\nD&#xE9;velopper (ing&#xE9;ni&#xE9;riser) le syst&#xE8;me\n\nD&#x2019;apr&#xE8;s Ing&#xE9;ni&#xE9;rie du logiciel, Ecole polytechnique de Montr&#xE9;al\n\n\nAnalyse des risques \nRisques humains: d&#xE9;faillance du personnel ; surestimation des comp&#xE9;tences, \ntravailleur solitaire, h&#xE9;ro&#xEF;sme, manque de motivation.. \nRisques processus: pas de gestion de projet, calendrier et budget irr&#xE9;alistes, \ncalendrier abandonn&#xE9; sous la pression des clients, insuffisance de donn&#xE9;es, \nvalidit&#xE9; des besoins, d&#xE9;veloppement de fonctions inappropri&#xE9;es, d&#xE9;veloppement \nd'interfaces utilisateurs inappropri&#xE9;es&#x2026; \nRisques Technologiques: changement de technologie en cours de route, \nprobl&#xE8;mes de performance, exigences d&#xE9;mesur&#xE9;es par rapport &#xE0; la technologie, \nincompr&#xE9;hension des fondements de la technologie&#x2026; \n\n
3 modes d&#x2019;organisations possibles en choissant de fixer deux facteurs pour la production des incr&#xE9;ments : \n Production des incr&#xE9;ments asservie sur 2 parmi 3 :\n p&#xE9;riode (e.g. release toutes les 2 semaines)\n fonctionnalit&#xE9;s (releases d&#xE9;coup&#xE9;s suivant use-cases)\n niveau de qualit&#xE9; (probl&#xE8;me de la mesure)\n\nMod&#xE8;le par incr&#xE9;ment\n\n\nDans les mod&#xE8;les pr&#xE9;c&#xE9;dents un logiciel est d&#xE9;compos&#xE9; en composants d&#xE9;velopp&#xE9;s s&#xE9;par&#xE9;ment et int&#xE9;gr&#xE9;s &#xE0; la fin du processus.\nDans les mod&#xE8;les par incr&#xE9;ment un seul ensemble de composants est d&#xE9;velopp&#xE9; &#xE0; la fois&#xA0;: des incr&#xE9;ments viennent s&#x2019;int&#xE9;grer &#xE0; un noyau de logiciel d&#xE9;velopp&#xE9; au pr&#xE9;alable. Chaque incr&#xE9;ment est d&#xE9;velopp&#xE9; selon l&#x2019;un des mod&#xE8;les pr&#xE9;c&#xE9;dents.\nLes avantages de ce type de mod&#xE8;le sont les suivants&#xA0;:\n&#x2022;chaque d&#xE9;veloppement est moins complexe ;\n&#x2022;les int&#xE9;grations sont progressives ;\n&#x2022;il est ainsi possible de livrer et de mettre en service chaque incr&#xE9;ment ;\n&#x2022;il permet un meilleur lissage du temps et de l&#x2019;effort de d&#xE9;veloppement gr&#xE2;ce &#xE0; la possibilit&#xE9; de recouvrement (parall&#xE9;lisation) des diff&#xE9;rentes phases.\nLes risques de ce type de mod&#xE8;le sont les suivants&#xA0;:\n&#x2022;remettre en cause les incr&#xE9;ments pr&#xE9;c&#xE9;dents ou pire le noyau ;\n&#x2022;ne pas pouvoir int&#xE9;grer de nouveaux incr&#xE9;ments.\nLes noyaux, les incr&#xE9;ments ainsi que leurs interactions doivent donc &#xEA;tre sp&#xE9;cifi&#xE9;s globalement, au d&#xE9;but du projet. Les incr&#xE9;ments doivent &#xEA;tre aussi ind&#xE9;pendants que possibles, fonctionnellement mais aussi sur le plan du calendrier du d&#xE9;veloppement.\n\n\n\n
3 modes d&#x2019;organisations possibles en choissant de fixer deux facteurs pour la production des incr&#xE9;ments : \n
3 modes d&#x2019;organisations possibles en choissant de fixer deux facteurs pour la production des incr&#xE9;ments : \n