Introduction rapide à 'objet et à UML

3 817 vues

Publié le

Version simple de l'introduction au cours.

Publié dans : Formation
0 commentaire
2 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
3 817
Sur SlideShare
0
Issues des intégrations
0
Intégrations
8
Actions
Partages
0
Téléchargements
136
Commentaires
0
J’aime
2
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • \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 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épendantes : une simple mise à jour du logiciel à un point donné, peut impacter en cascade une multitude d'autres fonctions. On peut minorer cet impact, pour peu qu'on utilise des fonctions plus génériques et des structures de données ouvertes. Mais respecter ces contraintes rend l'écriture du logiciel et sa maintenance plus complexe.En cas d'évolution majeure du logiciel (passage de la gestion d'une bibliothèque à celle d'une médiathèque par exemple), le scénario est encore pire. Même si la structure générale du logiciel reste valide, la multiplication des points de maintenance, engendrée par le chaînage des fonctions, rend l'adaptation très laborieuse. Le logiciel doit être retouché dans sa globalité :\nExaminons le problème de l'évolution de code fonctionnel plus en détail...Faire évoluer une application de gestion de bibliothèque pour gérer une médiathèque, afin de prendre en compte de nouveaux types d'ouvrages (cassettes vidéo, CD-ROM, etc...), nécessite :\nde faire évoluer les structures de données qui sont manipulées par les fonctions, \nd'adapter les traitements, qui ne manipulaient à 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érer les données et les actions propres aux différents types de documents.Il faudra par exemple modifier la fonction qui réalise l'édition des "lettres de rappel" (une lettre de rappel est une mise en demeure, qu'on envoie automatiquement aux personnes qui tardent à rendre un ouvrage emprunté). Si l'on désire que le délai avant rappel varie selon le type de document emprunté, il faut prévoir une règle de calcul pour chaque type de document.En fait, c'est la quasi-totalité de l'application qui devra être adaptée, pour gérer les nouvelles données et réaliser les traitements correspondants. Et cela, à chaque fois qu'on décidera de gérer un nouveau type de document ! \n \nstruct Document{  char nom_doc[50];  Type_doc type;  Bool est_emprunte;  char emprunteur[50];  struct tm date_emprunt;} DOC[MAX_DOCS];  \n \nvoid lettres_de_rappel(){  /* ... */  for (i = 0; i < NB_DOCS; i++)  {    if (DOC[i].est_emprunte)    {      switch(DOC[i].type)      {      case LIVRE:        delai_avant_rappel = 20;        break;      case CASSETTE_VIDEO:        delai_avant_rappel = 7;        break;      case CD_ROM:        delai_avant_rappel = 5;        break;      }    }  }/* ... */}  \n   void mettre_a_jour(int ref)   {     /* ... */     switch(DOC[ref].type)     {       case LIVRE:         maj_livre(DOC[ref]);         break;       case CASSETTE_VIDEO:         maj_k7(DOC[ref]);         break;       case CD_ROM:         maj_cd(DOC[ref]);         break;     }     /* ... */   } \n\n \n1ère amélioration : rassembler les valeurs qui caractérisent un type, dans le typeUne solution relativement élégante à la multiplication des branches conditionnelles et des redondances dans le code (conséquence logique d'une trop grande ouverture des données), consiste tout simplement à centraliser dans les structures de données, les valeurs qui leurs sont propres : \nstruct Document{  char nom_doc[50];  Type_doc type;  Bool est_emprunte;  char emprunteur[50];  struct tm date_emprunt;  int delai_avant_rappel;} DOC[MAX_DOCS];  \nvoid lettres_de_rappel(){  /* ... */  for (i = 0; i < NB_DOCS; i++)  {    if (DOC[i].est_emprunte) /* SI LE DOC EST EMPRUNTE */    {      /* IMPRIME UNE LETTRE SI SON      DELAI DE RAPPEL EST DEPASSE */      if (date() >= (DOC[i].date_emprunt + DOC[i].delai_avant_rappel))          imprimer_rappel(DOC[i]);    }  }}Quoi de plus logique ? En effet, le "délai avant édition d'une lettre de rappel" est bien une caractéristique propre à tous les ouvrages gérés par notre application. Mais cette solution n'est pas encore optimale ! \n \n \n2ème amélioration : centraliser les traitements associés à un type, auprès du typePourquoi ne pas aussi rassembler dans une même unité physique les types de données et tous les traitements associés ?Que se passerait-il par exemple si l'on centralisait dans un même fichier, la structure de données qui décrit les documents et la fonction de calcul du délai avant rappel ? Cela nous permettrait de retrouver en un clin d'oeil le bout de code qui est chargé de calculer le délai avant rappel d'un document, puisqu'il se trouve au plus près de la structure de données concernée.Ainsi, si notre médiathèque devait gérer un nouveau type d'ouvrage, il suffirait de modifier une seule fonction (qu'on sait retrouver instannément), pour assurer la prise en compte de ce nouveau type de document dans le calcul du délai avant rappel. Plus besoin de fouiller partout dans le code... \nstruct Document{  char nom_doc[50];  Type_doc type;  Bool est_emprunte;  char emprunteur[50];  struct tm date_emprunt;  int delai_avant_rappel;} DOC[MAX_DOCS];  int calculer_delai_rappel(Type_doc type){  switch(type)  {    case LIVRE:      return 20;    case CASSETTE_VIDEO:      return 7;    case CD_ROM:      return 5;    /* autres "case" bienvenus ici ! */  }} \nEcrit en ces termes, notre logiciel sera plus facile à maintenir et bien plus lisible. Le stockage et le calcul du délai avant rappel des documents, est désormais assuré par une seule et unique unité physique (quelques lignes de code, rapidement identifiables).Pour accéder à la caractéristique "délai avant rappel" d'un document, il suffit de récupérer la valeur correspondante parmi les champs qui décrivent le document. Pour assurer la prise en compte d'un nouveau type de document dans le calcul du délai avant rappel, il suffit de modifier une seule fonction, située au même endroit que la structure de données qui décrit les documents : \nvoid ajouter_document(int ref){  DOC[ref].est_emprunte = FAUX;  DOC[ref].nom_doc = saisir_nom();  DOC[ref].type = saisir_type();  DOC[ref].delai_avant_rappel = calculer_delai_rappel(DOC[ref].type);}void afficher_document(int ref){  printf("Nom du document: %s\\n",DOC[ref].nom_doc);  /* ... */  printf("Delai avant rappel: %d jours\\n",DOC[ref].delai_avant_rappel);  /* ... */}\n
  • La fonction induit la structure.\nFactoriser les comportements n'a malheureusement pas que des avantages. Les fonctions sont devenues interdépendantes : une simple mise à jour du logiciel à un point donné, peut impacter en cascade une multitude d'autres fonctions. On peut minorer cet impact, pour peu qu'on utilise des fonctions plus génériques et des structures de données ouvertes. Mais respecter ces contraintes rend l'écriture du logiciel et sa maintenance plus complexe.En cas d'évolution majeure du logiciel (passage de la gestion d'une bibliothèque à celle d'une médiathèque par exemple), le scénario est encore pire. Même si la structure générale du logiciel reste valide, la multiplication des points de maintenance, engendrée par le chaînage des fonctions, rend l'adaptation très laborieuse. Le logiciel doit être retouché dans sa globalité :\nExaminons le problème de l'évolution de code fonctionnel plus en détail...Faire évoluer une application de gestion de bibliothèque pour gérer une médiathèque, afin de prendre en compte de nouveaux types d'ouvrages (cassettes vidéo, CD-ROM, etc...), nécessite :\nde faire évoluer les structures de données qui sont manipulées par les fonctions, \nd'adapter les traitements, qui ne manipulaient à 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érer les données et les actions propres aux différents types de documents.Il faudra par exemple modifier la fonction qui réalise l'édition des "lettres de rappel" (une lettre de rappel est une mise en demeure, qu'on envoie automatiquement aux personnes qui tardent à rendre un ouvrage emprunté). Si l'on désire que le délai avant rappel varie selon le type de document emprunté, il faut prévoir une règle de calcul pour chaque type de document.En fait, c'est la quasi-totalité de l'application qui devra être adaptée, pour gérer les nouvelles données et réaliser les traitements correspondants. Et cela, à chaque fois qu'on décidera de gérer un nouveau type de document ! \n \nstruct Document{  char nom_doc[50];  Type_doc type;  Bool est_emprunte;  char emprunteur[50];  struct tm date_emprunt;} DOC[MAX_DOCS];  \n \nvoid lettres_de_rappel(){  /* ... */  for (i = 0; i < NB_DOCS; i++)  {    if (DOC[i].est_emprunte)    {      switch(DOC[i].type)      {      case LIVRE:        delai_avant_rappel = 20;        break;      case CASSETTE_VIDEO:        delai_avant_rappel = 7;        break;      case CD_ROM:        delai_avant_rappel = 5;        break;      }    }  }/* ... */}  \n   void mettre_a_jour(int ref)   {     /* ... */     switch(DOC[ref].type)     {       case LIVRE:         maj_livre(DOC[ref]);         break;       case CASSETTE_VIDEO:         maj_k7(DOC[ref]);         break;       case CD_ROM:         maj_cd(DOC[ref]);         break;     }     /* ... */   } \n\n \n1ère amélioration : rassembler les valeurs qui caractérisent un type, dans le typeUne solution relativement élégante à la multiplication des branches conditionnelles et des redondances dans le code (conséquence logique d'une trop grande ouverture des données), consiste tout simplement à centraliser dans les structures de données, les valeurs qui leurs sont propres : \nstruct Document{  char nom_doc[50];  Type_doc type;  Bool est_emprunte;  char emprunteur[50];  struct tm date_emprunt;  int delai_avant_rappel;} DOC[MAX_DOCS];  \nvoid lettres_de_rappel(){  /* ... */  for (i = 0; i < NB_DOCS; i++)  {    if (DOC[i].est_emprunte) /* SI LE DOC EST EMPRUNTE */    {      /* IMPRIME UNE LETTRE SI SON      DELAI DE RAPPEL EST DEPASSE */      if (date() >= (DOC[i].date_emprunt + DOC[i].delai_avant_rappel))          imprimer_rappel(DOC[i]);    }  }}Quoi de plus logique ? En effet, le "délai avant édition d'une lettre de rappel" est bien une caractéristique propre à tous les ouvrages gérés par notre application. Mais cette solution n'est pas encore optimale ! \n \n \n2ème amélioration : centraliser les traitements associés à un type, auprès du typePourquoi ne pas aussi rassembler dans une même unité physique les types de données et tous les traitements associés ?Que se passerait-il par exemple si l'on centralisait dans un même fichier, la structure de données qui décrit les documents et la fonction de calcul du délai avant rappel ? Cela nous permettrait de retrouver en un clin d'oeil le bout de code qui est chargé de calculer le délai avant rappel d'un document, puisqu'il se trouve au plus près de la structure de données concernée.Ainsi, si notre médiathèque devait gérer un nouveau type d'ouvrage, il suffirait de modifier une seule fonction (qu'on sait retrouver instannément), pour assurer la prise en compte de ce nouveau type de document dans le calcul du délai avant rappel. Plus besoin de fouiller partout dans le code... \nstruct Document{  char nom_doc[50];  Type_doc type;  Bool est_emprunte;  char emprunteur[50];  struct tm date_emprunt;  int delai_avant_rappel;} DOC[MAX_DOCS];  int calculer_delai_rappel(Type_doc type){  switch(type)  {    case LIVRE:      return 20;    case CASSETTE_VIDEO:      return 7;    case CD_ROM:      return 5;    /* autres "case" bienvenus ici ! */  }} \nEcrit en ces termes, notre logiciel sera plus facile à maintenir et bien plus lisible. Le stockage et le calcul du délai avant rappel des documents, est désormais assuré par une seule et unique unité physique (quelques lignes de code, rapidement identifiables).Pour accéder à la caractéristique "délai avant rappel" d'un document, il suffit de récupérer la valeur correspondante parmi les champs qui décrivent le document. Pour assurer la prise en compte d'un nouveau type de document dans le calcul du délai avant rappel, il suffit de modifier une seule fonction, située au même endroit que la structure de données qui décrit les documents : \nvoid ajouter_document(int ref){  DOC[ref].est_emprunte = FAUX;  DOC[ref].nom_doc = saisir_nom();  DOC[ref].type = saisir_type();  DOC[ref].delai_avant_rappel = calculer_delai_rappel(DOC[ref].type);}void afficher_document(int ref){  printf("Nom du document: %s\\n",DOC[ref].nom_doc);  /* ... */  printf("Delai avant rappel: %d jours\\n",DOC[ref].delai_avant_rappel);  /* ... */}\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Un modèle est une abstraction de la réalitéL'abstraction est un des piliers de l'approche objet.  \nIl s'agit d'un processus qui consiste à identifier les caractéristiques intéressantes d'une entité, en vue d'une utilisation précise. \nL'abstraction désigne aussi le résultat de ce processus, c'est-à-dire l'ensemble des caractéristiques essentielles d'une entité, retenues par un observateur.  \nUn modèle est une vue subjective mais pertinente de la réalité  \nUn modèle définit une frontière entre la réalité et la perspective de l'observateur. Ce n'est pas "la réalité", mais une vue très subjective de la réalité. \nBien qu'un modèle ne représente pas une réalité absolue, un modèle reflète des aspects importants de la réalité, il en donne donc une vue juste et pertinente.  \nQuelques exemples de modèles  \nModèle météorologique :à partir de données d'observation (satellite ...), permet de prévoir les conditions climatiques pour les jours à venir. \nModèle économique :peut par exemple permettre de simuler l'évolution de cours boursiers en fonction d'hypothèses macro-économiques (évolution du chômage, taux de croissance...). \nModèle démographique :définit la composition d'un panel d'une population et son comportement, dans le but de fiabiliser des études statistiques, d'augmenter l'impact de démarches commerciales, etc...  \nCaractéristiques fondamentales des modèlesLe caractère abstrait d'un modèle doit notamment permettre :  \nde faciliter la compréhension du système étudié> Un modèle réduit la complexité du système étudié. \nde simuler le système étudié> Un modèle représente le système étudié et reproduit ses comportements. \nUn modèle réduit (décompose) la réalité, dans le but de disposer d'éléments de travail exploitables par des moyens mathématiques ou informatiques :modèle / réalité ~  digital / analogique \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • POO : programmation orienté 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és attendues, architecture du système, patterns…\nContinuer son apprentissge OO: transmettre le savoir grace à un langage adapté...\n\n UML : Support des systèmes concurrents et répartis, à base de composants\n
  • \n
  • Attention à la différence entre langage de modélisation et méthode\nMéthode: l ’utilisateur sait ce qu ’il a à faire, comment le faire, quand le faire et pourquoi il faut le faire. Les méthodes utilisent des modèles pour décrire un point particulier.\nLangage de modélisation décrit les symboles utilisé par un modèles et les règles d ’écriture liés à ces symboles.\nUn langage de modélisation ne définit donc pas de procédés.\nUML est un donc un méta-langage de modélisation utilis é pour décrire des langages de modélisation.\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Même si l'Espéranto est une utopie, la nécessité de s'accorder sur des modes d'expression communs est vitale en informatique. UML n 'est pas à l'origine des concepts objets, mais en constitue une étape majeure, car il unifie les différentes approches et en donne une définition plus formelle.\n2) Les auteurs d'UML sont tout à fait conscients de l'importance du processus, mais l'acceptabilité industrielle de la modélisation objet passe d'abord par la disponibilité d'un langage d'analyse objet performant et standard. \n\n Or, l'intégration d'UML dans un processus n'est pas triviale et améliorer un processus est une tâche complexe et longue.\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Pré-étude : Définition de la portée du projet et développement des cas \n•  Vision : Glossaire, Détermination des parties prenantes et des utilisateurs, Détermination \nde leurs besoins, Besoins fonctionnels et non fonctionnels, Contraintes de conception \n•  Elaboration : Planification du projet, spécification des caractéristiques, des fondements de \nl’architecture \n•  Architecture : Document d’architecture Logicielle, Différentes vues selon la partie \nprenante, Une architecture candidate, Comportement et conception des composants du \nsystème \n•  Construction : Construction du produit \n•  Transition : Préparation du produit pour les utilisateurs \n\n\n
  • \n
  • \n
  • PrésentationL’objectif principal d’un système logiciel est de rendre service à ses utilisateurs ; il faut par conséquent bien comprendre les désirs et les besoins des futurs utilisateurs. Le processus de développement sera donc centré sur l'utilisateur. Le terme utilisateur ne désigne pas seulement les utilisateurs humains mais également les autres systèmes. L’utilisateur représente donc une personne ou une chose dialoguant avec le système en cours de développement.\nLes cas d’utilisation font apparaître les besoins fonctionnels et leur ensemble constitue le modèle des cas d’utilisation qui décrit les fonctionnalités complètes du système.\n\nStratégie des cas d’utilisationQue doit pouvoir faire le système pour chaque utilisateur ?Les cas d’utilisation ne sont pas un simple outil de spécification des besoins du système. Ilsvont complètement guider le processus de développement à travers l’utilisation de modèlesbasés sur l’utilisation du langage UM\n\nA partir du modèle des cas d’utilisation, les développeurs créent une série de modèles de conception et d’implémentation réalisant les cas d’utilisation. Chacun des modèles successifs est ensuite révisé pour en contrôler la conformité par rapport au modèle des cas d’utilisation.\nEnfin, les testeurs testent l’implémentation pour s’assurer que les composants du modèle d’implémentation mettent correctement en œuvre les cas d’utilisation. Les cas d’utilisation garantissent la cohérence du processus de développement du système. S’il est vrai que les cas d’utilisation guident le processus de développement, ils ne sont pas sélectionnés de façon isolée, mais doivent absolument être développés "en tandem" avec l’architecture du système.\n\nLe processus unifié est centré sur l’architectureDès le démarrage du processus, on aura une vue sur l'architecture à mettre en place. L’architecture d’un système logiciel peut être décrite comme les différentes vues du système qui doit être construit. L’architecture logicielle équivaut aux aspects statiques et dynamiques les plus significatifs du système. L’architecture émerge des besoins de l’entreprise, tels qu’ils sont exprimés par les utilisateurs et autres intervenants et tels qu’ils sont reflétés par les cas d’utilisation.\nElle subit également l’influence d’autres facteurs :- la plate-forme sur laquelle devra s’exécuter le système ;- les briques de bases réutilisables disponibles pour le développement ;- les considérations de déploiement, les systèmes existants et les besoins nonfonctionnels (performance, fiabilité..)\nLiens entre cas d’utilisation et architecture ?Tout produit est à la fois forme et fonction. Les cas d’utilisation doivent une fois réalisés, trouver leur place dans l’architecture. L’architecture doit prévoir la réalisation de tous les cas d’utilisation. L’architecture et les cas d’utilisation doivent évoluer de façon concomitante.Marche à suivre :L’architecte crée une ébauche grossière de l’architecture, en partant de l’aspect qui n’est pas propre aux cas d’utilisation (plate forme..). Bien que cette partie de l’architecture soit indépendante des cas d’utilisation, l’architecte doit avoir une compréhension globale de ceux ci avant d’en esquisser l’architecture.\nIl travaille ensuite, sur un sous-ensemble des cas d’utilisations identifiés, ceux qui représentent les fonctions essentielles du système en cours de développement.\nL’architecture se dévoile peu à peu, au rythme de la spécification et de la maturation des cas d’utilisation, qui favorisent, à leur tour, le développement d’un nombre croissant de cas d’utilisation. Ce processus se poursuit jusqu’à ce que l’architecture soit jugée stable.Le processus unifié est itératif et incrémentalLe développement d’un produit logiciel destiné à la commercialisation est une vaste entreprise qui peut s’étendre sur plusieurs mois. On ne va pas tout développer d’un coup. On peut découper le travail en plusieurs parties qui sont autant de mini projets. Chacun d’entre eux représentant une itération qui donne lieu à un incrément. Une itération désigne la succession des étapes de l’enchaînement d’activités, tandis qu’un incrément correspond à une avancée dans les différents stades de développement.\nLe choix de ce qui doit être implémenté au cours d’une itération repose sur deux facteurs :- Une itération prend en compte un certain nombre de cas d’utilisation qui ensemble,améliorent l’utilisabilité du produit à un certain stade de développement.- L’itération traite en priorité les risques majeurs.\nUn incrément constitue souvent un additif.A chaque itération, les développeurs identifient et spécifient les cas d’utilisations pertinents, créent une conception en se laissant guider par l’architecture choisie, implémentent cette conception sous forme de composants et vérifie que ceux ci sont conformes aux cas d’utilisation. Dés qu’une itération répond aux objectifs fixés le développement passe à l’itération suivante.Pour rentabiliser le développement il faut sélectionner les itérations nécessaires pour atteindre les objectifs du projet. Ces itérations devront se succéder dans un ordre logique. Un projet réussi suivra un déroulement direct, établi dés le début par les développeurs et dont ils ne s’éloigneront que de façon très marginale. L’élimination des problèmes imprévus fait partie des objectifs de réduction des risques.\nAvantages d’un processus itératif contrôléPermet de limiter les coûts, en termes de risques, aux strictes dépenses liées à une itération.Permet de limiter les risques de retard de mise sur le marché du produit développé (identification des problèmes dès les premiers stades de développement et non en phase de test comme avec l’approche « classique »).Permet d’accélérer le rythme de développement grâce à des objectifs clairs et à court terme.Permet de prendre en compte le fait que les besoins des utilisateurs et les exigences correspondantes ne peuvent être intégralement définis à l’avance et se dégagent peu à peu des itérations successives.L’architecture fournit la structure qui servira de cadre au travail effectué au cours des itérations, tandis que les cas d’utilisation définissent les objectifs et orientent le travail de chaque itération. Il ne faut donc pas mésestimer l’un des trois concepts.Le cycle de vie du processus unifiéLe processus unifié répète un certain nombre de fois une série de cycles. Tout cycle se conclut par la livraison d’une version du produit aux clients et s’articule en 4 phases : création, élaboration, construction et transition, chacune d’entre elles se subdivisant à son tour en ité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
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • MERISE ET UML: APPROCHE SYSTEMIQUE \n \nLa méthode MERISE s'intéresse aux systèmes ouverts en \nrelation permanente avec leur environnement ( à partir du \nniveau 3. Cf. Cours de systémique ). Trois propriétés \nmajeures sont alors considérées. \n\nGLOBALITE \nContrairement au modèle Cartésien, le comportement d'un \nsystème n'est pas la somme des comportements de ses \nparties \n\nRETROACTION \nLe système réagit à toute stimulation en générant des \nrésultats selon des boucles d'actions-réactions mises en \noeuvre au sein de ses composants. ( feed-back d'ordre 3 ) \n\nFINALITE \nLe système ne peut être stabilisé que si on lui fournit des \nvaleurs acceptables préalablement définies. \n\nL'APPROCHE UML \nL'approche par les CAS D'UTILISATION constitue de fait une \napproche SYSTEMIQUE. Les ACTEURS et les MESSAGES \néchangés sont pris en compte. \n\nCOMMENTAIRES \nLa Maîtrise des concepts de la systémique \n ( ENVIRONNEMENT, ENTREES, SORTIES, OBJECTIFS, \nSTRUCTURE et PROCESSUS ) permet de réaliser une \napproche constructive et consciente des cas d'utilisation. Elle \nfacilite la détermination des CAS D'UTILISATION selon un \ndouble process TOP-DOWN et BOTTOM-UP. L'avantage est \nque le PROCESSUS métier du système est mieux décrit et \nplus compréhensible par les utilisateurs. \n\nFINALITES:Raisons d'être, vocation d'un système. Se déclinent et se formalisent en BUTS. Elles ne sont pas opératoires. ( Cf. FACTEURS ). Par \nexemple: "Recentrer l'activité de l'entreprise sur son métier de base qui est la vente de contrats d'assurances". \n\nBUT:Formalisation des FINALITES. Elles se déclinent en OBJECTIFS qui eux, doivent être opératoires. ( Cf. CRITERES ). Par exemple: "Recentrer \nles résultats de la compagnie sur les primes d'assurances plutôt que sur les marchés financiers" \n\nOBJECTIFS:Concrétisation des BUTS sur la base de critères d'évaluations auxquels sont affectés des niveaux quantifiés à atteindre. ( Cf. \nMETRIQUES ). Par exemple: "Les cotisations d'assurances doivent contribuer à 60% du résultat de la compagnie ". \n\nACTEURS:Classe stérotypée représentant une abstraction faisant partie de l'ENVIRONNEMENT du système étudié. \nOSITEC-Consultants 40/45 18/03/2005\n
  • * La conception du système d'information se fait par étapes, afin d'aboutir à un système d'information fonctionnel reflétant une réalité physique. Il s'agit donc de valider une à une chacune des étapes en prenant en compte les résultats de la phase précédente. D'autre part, les données étant séparées des traitements, il faut vérifier la concordance entre données et traitements afin de vérifier que toutes les données nécessaires aux traitements sont présentes et qu'il n'y a pas de données superflues.\nCette succession d'étapes est appelée cycle d'abstraction pour la conception des systèmes d'information :\nL'expression des besoins est une étape consistant à définir ce que l'on attend du système d'information automatisé, il faut pour cela :\nfaire l'inventaire des éléments nécessaires au système d'information\ndélimiter le système en s'informant auprès des futurs utilisateurs\nCela va permettre de créer le MCC (Modèle conceptuel de la communication) qui définit les flux d'informations à prendre en compte.\nL'étape suivante consiste à mettre au point le MCD (Modèle conceptuel des données) et le MCT (Modèle conceptuel des traitements) décrivant les règles et les contraintes à prendre en compte.\nLe modèle organisationnel consiste à définir le MOT (Modèle organisationnel des traitements) décrivant les contraintes dues à l'environnement (organisationnel, spatial et temporel).\nLe modèle logique représente un choix logiciel pour le système d'information.\nLe modèle physique reflète un choix matériel pour le système d'information.\n****** \n\n\n\n
  • * La conception du système d'information se fait par étapes, afin d'aboutir à un système d'information fonctionnel reflétant une réalité physique. Il s'agit donc de valider une à une chacune des étapes en prenant en compte les résultats de la phase précédente. D'autre part, les données étant séparées des traitements, il faut vérifier la concordance entre données et traitements afin de vérifier que toutes les données nécessaires aux traitements sont présentes et qu'il n'y a pas de données superflues.\nCette succession d'étapes est appelée cycle d'abstraction pour la conception des systèmes d'information :\nL'expression des besoins est une étape consistant à définir ce que l'on attend du système d'information automatisé, il faut pour cela :\nfaire l'inventaire des éléments nécessaires au système d'information\ndélimiter le système en s'informant auprès des futurs utilisateurs\nCela va permettre de créer le MCC (Modèle conceptuel de la communication) qui définit les flux d'informations à prendre en compte.\nL'étape suivante consiste à mettre au point le MCD (Modèle conceptuel des données) et le MCT (Modèle conceptuel des traitements) décrivant les règles et les contraintes à prendre en compte.\nLe modèle organisationnel consiste à définir le MOT (Modèle organisationnel des traitements) décrivant les contraintes dues à l'environnement (organisationnel, spatial et temporel).\nLe modèle logique représente un choix logiciel pour le système d'information.\nLe modèle physique reflète un choix matériel pour le système d'information.\n****** \n\n\nVUE LOGIQUE \nVUE DES \nPour MERISE, la création d'un PRODUIT artificiel \n( application ) doit suivre un cycle formel ( Gestation, \nNaissance, Maturité et Mort ) pour le PRODUIT et un cycle \ntechnique pour son élaboration ( SD, EBG, EBD, CT, \nPRODUCTION, INTEGRATION, MISE EN OEUVRE et \nMAINTENANCE ). La démarche est formalisée et méthodifiée \nCYCLE D'ABSTRACTION \nLes trois niveaux retenus correspondent à des degrés de \nstabilité et d'invariance diffé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 étudier le système \nprogressivement en allant du général au Particulier ( TOP - \nDOWN ). \nCYCLE DE DECISION \nLe cycle de décision permet d'organiser l'intervention des \npersonnes de l'entreprise en fonction de la hiérachie des \ndécisions à prendre. MERISE est une méthode participative \noù chaque Acteur est amené à formuler ses besoins en \nfonction de ses niveaux de préocuppations. Le cycle de \nCYCLE DE VIE \nUML ne définit pas de cycle de vie. Il est implicite et correspond à \nun cycle itératif et incrémental guidé par les CAS D'UTILISATION. \net centré sur les vues. \nCYCLE D'ABSTRACTION \nUML permet de modéliser les différents niveaux du SI . \n( Conceptuel, Organisationnel et Physique ). Pour cette partie \nUML propose différents modèles ( CAS d'UTILISATION, \nPAQUETAGES, CLASSES, COMPOSANTS et NOEUDS ). UML \nlaisse le soin àl'informaticen de présenter ces modèles de \nmanière cohérente par rapport au niveau d'abstraction. \nCYCLE DE DECISION \nComme MERISE, UML associe étroitement les utilisateurs aux \nprises de décisions. La mise en eouvre d'UML doit \ns'accompagner d'un cycle de décision complet avec points de \ncontrôles et jalons. \n\n\n\n
  • \n
  • * La conception du système d'information se fait par étapes, afin d'aboutir à un système d'information fonctionnel reflétant une réalité physique. Il s'agit donc de valider une à une chacune des étapes en prenant en compte les résultats de la phase précédente. D'autre part, les données étant séparées des traitements, il faut vérifier la concordance entre données et traitements afin de vérifier que toutes les données nécessaires aux traitements sont présentes et qu'il n'y a pas de données superflues.\nCette succession d'étapes est appelée cycle d'abstraction pour la conception des systèmes d'information :\nL'expression des besoins est une étape consistant à définir ce que l'on attend du système d'information automatisé, il faut pour cela :\nfaire l'inventaire des éléments nécessaires au système d'information\ndélimiter le système en s'informant auprès des futurs utilisateurs\nCela va permettre de créer le MCC (Modèle conceptuel de la communication) qui définit les flux d'informations à prendre en compte.\nL'étape suivante consiste à mettre au point le MCD (Modèle conceptuel des données) et le MCT (Modèle conceptuel des traitements) décrivant les règles et les contraintes à prendre en compte.\nLe modèle organisationnel consiste à définir le MOT (Modèle organisationnel des traitements) décrivant les contraintes dues à l'environnement (organisationnel, spatial et temporel).\nLe modèle logique représente un choix logiciel pour le système d'information.\nLe modèle physique reflète un choix matériel pour le système d'information.\n****** \n\nMerise propose une approche descendante où le système \nréell est découpé en ACTIVITES ( MCC, MCD, MCT ) elles \nmêmes découpées en FONCTIONS ( MOT, MLD et MOC ). Les \nFONCTIONS sont composées de RG elles mêmes regroupées \nen OPERATIONS. Ces RG au niveau conceptuel génèrent \ndes MODULES décomposés en MODULES plus simples pour \nobtenir des MODULES élémentaires. Les limites de cette \napproche résident dans la REUTILISABILITE. Il existe aussi \ndes différences entre des modules plus "utilisateurs" \n( Calculs de dates, calcul de validité de compte via une clé \netc.. ) et des modules plus "techniques" ( module d'accès à \nun SGBD, Module de création de liste sur écran ). \nL'approche fonctionnelle est une spécificité MERISE \ndont UML se démarque. Dans UML, les FONCTIONS \ncèdent le pas aux CAS D'UTILISATION qui permettent \nde situer les besoins des Utilisateurs dans un contexte \nréel. A chaque scénario correspondent des \ndiagrammes d'interactions ( SEQUENCE et \nCOLLABORATION ) entre les OBJETS et non pas des \nFONCTIONS. Pour compléter , UML introduit des \ndiagrammes d'ACTIVITES. Cette approche rend le \nsystème le plus indépendant possible des besoins en \ndonnant naissance à des COMPOSANTS réutilisables. \nNous avons affaire ici à la véritable différence ( culturelle et conceptuelle ) entre MERISE et UML. Cette différence impose \nque l'informaticien "pense" différemment. \n\n\n\n
  • * La conception du système d'information se fait par étapes, afin d'aboutir à un système d'information fonctionnel reflétant une réalité physique. Il s'agit donc de valider une à une chacune des étapes en prenant en compte les résultats de la phase précédente. D'autre part, les données étant séparées des traitements, il faut vérifier la concordance entre données et traitements afin de vérifier que toutes les données nécessaires aux traitements sont présentes et qu'il n'y a pas de données superflues.\nCette succession d'étapes est appelée cycle d'abstraction pour la conception des systèmes d'information :\nL'expression des besoins est une étape consistant à définir ce que l'on attend du système d'information automatisé, il faut pour cela :\nfaire l'inventaire des éléments nécessaires au système d'information\ndélimiter le système en s'informant auprès des futurs utilisateurs\nCela va permettre de créer le MCC (Modèle conceptuel de la communication) qui définit les flux d'informations à prendre en compte.\nL'étape suivante consiste à mettre au point le MCD (Modèle conceptuel des données) et le MCT (Modèle conceptuel des traitements) décrivant les règles et les contraintes à prendre en compte.\nLe modèle organisationnel consiste à définir le MOT (Modèle organisationnel des traitements) décrivant les contraintes dues à l'environnement (organisationnel, spatial et temporel).\nLe modèle logique représente un choix logiciel pour le système d'information.\nLe modèle physique reflète un choix matériel pour le système d'information.\n****** \n\nMerise propose une approche descendante où le système \nréell est découpé en ACTIVITES ( MCC, MCD, MCT ) elles \nmêmes découpées en FONCTIONS ( MOT, MLD et MOC ). Les \nFONCTIONS sont composées de RG elles mêmes regroupées \nen OPERATIONS. Ces RG au niveau conceptuel génèrent \ndes MODULES décomposés en MODULES plus simples pour \nobtenir des MODULES élémentaires. Les limites de cette \napproche résident dans la REUTILISABILITE. Il existe aussi \ndes différences entre des modules plus "utilisateurs" \n( Calculs de dates, calcul de validité de compte via une clé \netc.. ) et des modules plus "techniques" ( module d'accès à \nun SGBD, Module de création de liste sur écran ). \nL'approche fonctionnelle est une spécificité MERISE \ndont UML se démarque. Dans UML, les FONCTIONS \ncèdent le pas aux CAS D'UTILISATION qui permettent \nde situer les besoins des Utilisateurs dans un contexte \nréel. A chaque scénario correspondent des \ndiagrammes d'interactions ( SEQUENCE et \nCOLLABORATION ) entre les OBJETS et non pas des \nFONCTIONS. Pour compléter , UML introduit des \ndiagrammes d'ACTIVITES. Cette approche rend le \nsystème le plus indépendant possible des besoins en \ndonnant naissance à des COMPOSANTS réutilisables. \nNous avons affaire ici à la véritable différence ( culturelle et conceptuelle ) entre MERISE et UML. Cette différence impose \nque l'informaticien "pense" différemment. \n\n\n\n
  • * La conception du système d'information se fait par étapes, afin d'aboutir à un système d'information fonctionnel reflétant une réalité physique. Il s'agit donc de valider une à une chacune des étapes en prenant en compte les résultats de la phase précédente. D'autre part, les données étant séparées des traitements, il faut vérifier la concordance entre données et traitements afin de vérifier que toutes les données nécessaires aux traitements sont présentes et qu'il n'y a pas de données superflues.\nCette succession d'étapes est appelée cycle d'abstraction pour la conception des systèmes d'information :\nL'expression des besoins est une étape consistant à définir ce que l'on attend du système d'information automatisé, il faut pour cela :\nfaire l'inventaire des éléments nécessaires au système d'information\ndélimiter le système en s'informant auprès des futurs utilisateurs\nCela va permettre de créer le MCC (Modèle conceptuel de la communication) qui définit les flux d'informations à prendre en compte.\nL'étape suivante consiste à mettre au point le MCD (Modèle conceptuel des données) et le MCT (Modèle conceptuel des traitements) décrivant les règles et les contraintes à prendre en compte.\nLe modèle organisationnel consiste à définir le MOT (Modèle organisationnel des traitements) décrivant les contraintes dues à l'environnement (organisationnel, spatial et temporel).\nLe modèle logique représente un choix logiciel pour le système d'information.\nLe modèle physique reflète un choix matériel pour le système d'information.\n****** \n\nL'APPROCHE MERISE \nMerise propose de considérer le système ré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érentes à valider. \nCette validation permet de contrôler que les besoins exprimés sont bien \ntraduits en termes d'informations et que ces dernières sont bien toutes \nutilisées. La validation consiste à vérifier l'EXISTENCE des informations, \ndes ENTITES et des RELATIONS; la cohérence des CARDINALITES et des \nCONTRAINTES ainsi que l'exhaustivité des actions élé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çon, un certain niveau de cohérence est assuré. Il s'agit ici \nd'un autre point clé de différence. En effet, l'approche UML permet de \nmodéliser les sytèmes complexes et d'exprimer de manière \nINTEGREE la structure et la dynamique avec un même concept plus \nproche de la réalité des choses. Cette approche étant renforcé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étermination du champ de l'étude, utilise le concept de \nFLUX entre ACTEURS. ( MCC avec ACTEURS et MESSAGES ou GRAPHE de \nFLUX ). Les Modèles de FLUX mettent en jeu les ACTEURS et leurs \nECHANGES avec le système à construire vu de l'EXTERIEUR. Si l'on veut \ntenir compte d'ACTEURS internes, il convient de déterminer un SOUS- \nSYSTEME, les autres STRUCTURES du systè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écrite d'abord sous forme de PROCESSUS \n"métiers" et ensuite sous forme de TRAVAILLEURS \n ( Rôles ) qui interagisent dans l'exécution du Processus. Les \nACTIVITES de ces travailleurs sont ensuite décrites dans les \ndiagrammes d'ACTIVITES.Ceci permet de fournir une vision simplfiée \net de haut niveau de l'organisation tout en décrivant séparément les \ndétails des activités et des échanges. . \nL'APPROCHE MERISE DU GENERAL AU PARTICULIER \nMerise est une méthode de type "descendante" ( TOP -DOWN ). La vision \nglobale du système est affinée par intégrations successives des différentes \norientations retenues, classées selon le séquencement du cycle \nd'abstraction. Dans les faits, les premières étapes s'appuient dur l'étude de \nl'EXISTANT ( Interviewes et documentation ). Les MCC, MCD et MCT \nsynthétisent ces travaux. Le travail est ensuite complété par les \nOBJECTIFS fournis du système cible et déclinés en modèles \norganisationnels ( MLD, MOT et MOC ) pour ensuite produire les modèles \nphysiques ( MPD et MPT ) rarement décrits en pratique. \nL'APPROCHE UML \nUML permet aussi bien une approche descendante ( TOP-DOWN ) que \nmontante ( BOTTOM-UP). Les différents diagrammes fournissent des \nsupports pour matérialiser une démarche progressive allant du global \nvers le détaillé, pour passer du SYSTEME D'INFORMATIONS au \nSYSTEME INFORMATIQUE. Un des avantages d'UML réside dans le \nfait que le concept de base ( l'OBJET ) peut être décliné 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èles liés aux niveaux CONCEPTUELS et \nORGANISATIONNELS pour décrire le METIER \nindépendamment de ses STRUCTURES. Le DOMAINE est \ndéfini comme le ou les PROCESSUS métiers candidats à \nl'é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é en \nPROCESSUS ( Gestion des Tarifs, Gestion des Clients, Gestion \ndes ventes, Gestion du budget, etc... ). Il est néanmoins \npossible de "calquer" la dé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ée des \nFONCTIONNALITES. \nPour UML, la définition du DOMAINE est un préalable. Et, \nles DOMAINES étudiés dérivent directement des \nACTIVITES de l'entreprise. Ce qui permet de trouver des \nscénarios de développements. Comme nous ne sommes \nplus en approche FONCTIONNELLE, l'approche est plus \naisée. Un objet CLIENT reste le même que nous soyons en \nGestion Commerciale ou en Gestion de Production. La \nspécialisation de ces OBJETS venant par la dérivation et \nl'héritage associées aux CLASSES. \n\n
  • \n
  • \n
  • * La conception du système d'information se fait par étapes, afin d'aboutir à un système d'information fonctionnel reflétant une réalité physique. Il s'agit donc de valider une à une chacune des étapes en prenant en compte les résultats de la phase précédente. D'autre part, les données étant séparées des traitements, il faut vérifier la concordance entre données et traitements afin de vérifier que toutes les données nécessaires aux traitements sont présentes et qu'il n'y a pas de données superflues.\nCette succession d'étapes est appelée cycle d'abstraction pour la conception des systèmes d'information :\nL'expression des besoins est une étape consistant à définir ce que l'on attend du système d'information automatisé, il faut pour cela :\nfaire l'inventaire des éléments nécessaires au système d'information\ndélimiter le système en s'informant auprès des futurs utilisateurs\nCela va permettre de créer le MCC (Modèle conceptuel de la communication) qui définit les flux d'informations à prendre en compte.\nL'étape suivante consiste à mettre au point le MCD (Modèle conceptuel des données) et le MCT (Modèle conceptuel des traitements) décrivant les règles et les contraintes à prendre en compte.\nLe modèle organisationnel consiste à définir le MOT (Modèle organisationnel des traitements) décrivant les contraintes dues à l'environnement (organisationnel, spatial et temporel).\nLe modèle logique représente un choix logiciel pour le système d'information.\nLe modèle physique reflète un choix matériel pour le système d'information.\n****** \n\n\n\n
  • * La conception du système d'information se fait par étapes, afin d'aboutir à un système d'information fonctionnel reflétant une réalité physique. Il s'agit donc de valider une à une chacune des étapes en prenant en compte les résultats de la phase précédente. D'autre part, les données étant séparées des traitements, il faut vérifier la concordance entre données et traitements afin de vérifier que toutes les données nécessaires aux traitements sont présentes et qu'il n'y a pas de données superflues.\nCette succession d'étapes est appelée cycle d'abstraction pour la conception des systèmes d'information :\nL'expression des besoins est une étape consistant à définir ce que l'on attend du système d'information automatisé, il faut pour cela :\nfaire l'inventaire des éléments nécessaires au système d'information\ndélimiter le système en s'informant auprès des futurs utilisateurs\nCela va permettre de créer le MCC (Modèle conceptuel de la communication) qui définit les flux d'informations à prendre en compte.\nL'étape suivante consiste à mettre au point le MCD (Modèle conceptuel des données) et le MCT (Modèle conceptuel des traitements) décrivant les règles et les contraintes à prendre en compte.\nLe modèle organisationnel consiste à définir le MOT (Modèle organisationnel des traitements) décrivant les contraintes dues à l'environnement (organisationnel, spatial et temporel).\nLe modèle logique représente un choix logiciel pour le système d'information.\nLe modèle physique reflète un choix matériel pour le système d'information.\n****** \n\n\n\n
  • * La conception du système d'information se fait par étapes, afin d'aboutir à un système d'information fonctionnel reflétant une réalité physique. Il s'agit donc de valider une à une chacune des étapes en prenant en compte les résultats de la phase précédente. D'autre part, les données étant séparées des traitements, il faut vérifier la concordance entre données et traitements afin de vérifier que toutes les données nécessaires aux traitements sont présentes et qu'il n'y a pas de données superflues.\nCette succession d'étapes est appelée cycle d'abstraction pour la conception des systèmes d'information :\nL'expression des besoins est une étape consistant à définir ce que l'on attend du système d'information automatisé, il faut pour cela :\nfaire l'inventaire des éléments nécessaires au système d'information\ndélimiter le système en s'informant auprès des futurs utilisateurs\nCela va permettre de créer le MCC (Modèle conceptuel de la communication) qui définit les flux d'informations à prendre en compte.\nL'étape suivante consiste à mettre au point le MCD (Modèle conceptuel des données) et le MCT (Modèle conceptuel des traitements) décrivant les règles et les contraintes à prendre en compte.\nLe modèle organisationnel consiste à définir le MOT (Modèle organisationnel des traitements) décrivant les contraintes dues à l'environnement (organisationnel, spatial et temporel).\nLe modèle logique représente un choix logiciel pour le système d'information.\nLe modèle physique reflète un choix matériel pour le système d'information.\n****** \n\n\n\n
  • * La conception du système d'information se fait par étapes, afin d'aboutir à un système d'information fonctionnel reflétant une réalité physique. Il s'agit donc de valider une à une chacune des étapes en prenant en compte les résultats de la phase précédente. D'autre part, les données étant séparées des traitements, il faut vérifier la concordance entre données et traitements afin de vérifier que toutes les données nécessaires aux traitements sont présentes et qu'il n'y a pas de données superflues.\nCette succession d'étapes est appelée cycle d'abstraction pour la conception des systèmes d'information :\nL'expression des besoins est une étape consistant à définir ce que l'on attend du système d'information automatisé, il faut pour cela :\nfaire l'inventaire des éléments nécessaires au système d'information\ndélimiter le système en s'informant auprès des futurs utilisateurs\nCela va permettre de créer le MCC (Modèle conceptuel de la communication) qui définit les flux d'informations à prendre en compte.\nL'étape suivante consiste à mettre au point le MCD (Modèle conceptuel des données) et le MCT (Modèle conceptuel des traitements) décrivant les règles et les contraintes à prendre en compte.\nLe modèle organisationnel consiste à définir le MOT (Modèle organisationnel des traitements) décrivant les contraintes dues à l'environnement (organisationnel, spatial et temporel).\nLe modèle logique représente un choix logiciel pour le système d'information.\nLe modèle physique reflète un choix matériel pour le système d'information.\n****** \n\n\n\n
  • * La conception du système d'information se fait par étapes, afin d'aboutir à un système d'information fonctionnel reflétant une réalité physique. Il s'agit donc de valider une à une chacune des étapes en prenant en compte les résultats de la phase précédente. D'autre part, les données étant séparées des traitements, il faut vérifier la concordance entre données et traitements afin de vérifier que toutes les données nécessaires aux traitements sont présentes et qu'il n'y a pas de données superflues.\nCette succession d'étapes est appelée cycle d'abstraction pour la conception des systèmes d'information :\nL'expression des besoins est une étape consistant à définir ce que l'on attend du système d'information automatisé, il faut pour cela :\nfaire l'inventaire des éléments nécessaires au système d'information\ndélimiter le système en s'informant auprès des futurs utilisateurs\nCela va permettre de créer le MCC (Modèle conceptuel de la communication) qui définit les flux d'informations à prendre en compte.\nL'étape suivante consiste à mettre au point le MCD (Modèle conceptuel des données) et le MCT (Modèle conceptuel des traitements) décrivant les règles et les contraintes à prendre en compte.\nLe modèle organisationnel consiste à définir le MOT (Modèle organisationnel des traitements) décrivant les contraintes dues à l'environnement (organisationnel, spatial et temporel).\nLe modèle logique représente un choix logiciel pour le système d'information.\nLe modèle physique reflète un choix matériel pour le système d'information.\n****** \n\n\n\n
  • * La conception du système d'information se fait par étapes, afin d'aboutir à un système d'information fonctionnel reflétant une réalité physique. Il s'agit donc de valider une à une chacune des étapes en prenant en compte les résultats de la phase précédente. D'autre part, les données étant séparées des traitements, il faut vérifier la concordance entre données et traitements afin de vérifier que toutes les données nécessaires aux traitements sont présentes et qu'il n'y a pas de données superflues.\nCette succession d'étapes est appelée cycle d'abstraction pour la conception des systèmes d'information :\nL'expression des besoins est une étape consistant à définir ce que l'on attend du système d'information automatisé, il faut pour cela :\nfaire l'inventaire des éléments nécessaires au système d'information\ndélimiter le système en s'informant auprès des futurs utilisateurs\nCela va permettre de créer le MCC (Modèle conceptuel de la communication) qui définit les flux d'informations à prendre en compte.\nL'étape suivante consiste à mettre au point le MCD (Modèle conceptuel des données) et le MCT (Modèle conceptuel des traitements) décrivant les règles et les contraintes à prendre en compte.\nLe modèle organisationnel consiste à définir le MOT (Modèle organisationnel des traitements) décrivant les contraintes dues à l'environnement (organisationnel, spatial et temporel).\nLe modèle logique représente un choix logiciel pour le système d'information.\nLe modèle physique reflète un choix matériel pour le système d'information.\n****** \nLe MCD et le diagramme de classes possèdent beaucoup de\npoints communs et une approche de structuration similaire:\n• Au niveau des entités/classes: contrainte de partition, contrainte\nd’exclusion, contrainte de totalité, l’identifiant est implicite en UML.\n• Au niveau des associations: contrainte de partition, d’exclusion, de\ntotalité, d’inclusion, d’unicité, association d’association, cardinalités.\n En UML le diagramme de classes est utilisé au cours de\nl’ensemble du processus:\n• Les classes contiennent les opérations (services),\n• Les classes sont analysées du point de vue des responsabilités,\n• Les contraintes sont exprimées dans un langage de contrainte (OCL),\n• UML propose des stéréotypes,\n• UML n’implique pas l’utilisation d’un formalisme de normalisation sur les\nclasses, mais des règles sont à respecter pour éviter les erreurs.\n\n\n
  • * La conception du système d'information se fait par étapes, afin d'aboutir à un système d'information fonctionnel reflétant une réalité physique. Il s'agit donc de valider une à une chacune des étapes en prenant en compte les résultats de la phase précédente. D'autre part, les données étant séparées des traitements, il faut vérifier la concordance entre données et traitements afin de vérifier que toutes les données nécessaires aux traitements sont présentes et qu'il n'y a pas de données superflues.\nCette succession d'étapes est appelée cycle d'abstraction pour la conception des systèmes d'information :\nL'expression des besoins est une étape consistant à définir ce que l'on attend du système d'information automatisé, il faut pour cela :\nfaire l'inventaire des éléments nécessaires au système d'information\ndélimiter le système en s'informant auprès des futurs utilisateurs\nCela va permettre de créer le MCC (Modèle conceptuel de la communication) qui définit les flux d'informations à prendre en compte.\nL'étape suivante consiste à mettre au point le MCD (Modèle conceptuel des données) et le MCT (Modèle conceptuel des traitements) décrivant les règles et les contraintes à prendre en compte.\nLe modèle organisationnel consiste à définir le MOT (Modèle organisationnel des traitements) décrivant les contraintes dues à l'environnement (organisationnel, spatial et temporel).\nLe modèle logique représente un choix logiciel pour le système d'information.\nLe modèle physique reflète un choix matériel pour le système d'information.\n****** \nLe MCD et le diagramme de classes possèdent beaucoup de\npoints communs et une approche de structuration similaire:\n• Au niveau des entités/classes: contrainte de partition, contrainte\nd’exclusion, contrainte de totalité, l’identifiant est implicite en UML.\n• Au niveau des associations: contrainte de partition, d’exclusion, de\ntotalité, d’inclusion, d’unicité, association d’association, cardinalités.\n En UML le diagramme de classes est utilisé au cours de\nl’ensemble du processus:\n• Les classes contiennent les opérations (services),\n• Les classes sont analysées du point de vue des responsabilités,\n• Les contraintes sont exprimées dans un langage de contrainte (OCL),\n• UML propose des stéréotypes,\n• UML n’implique pas l’utilisation d’un formalisme de normalisation sur les\nclasses, mais des règles sont à respecter pour éviter les erreurs.\n\n\n
  • Agence de régulation des marchés\n\n* La conception du système d'information se fait par étapes, afin d'aboutir à un système d'information fonctionnel reflétant une réalité physique. Il s'agit donc de valider une à une chacune des étapes en prenant en compte les résultats de la phase précédente. D'autre part, les données étant séparées des traitements, il faut vérifier la concordance entre données et traitem\n\nents afin de vérifier que toutes les données nécessaires aux traitements sont présentes et qu'il n'y a pas de données superflues.\nCette succession d'étapes est appelée cycle d'abstraction pour la conception des systèmes d'information :\nL'expression des besoins est une étape consistant à définir ce que l'on attend du système d'information automatisé, il faut pour cela :\nfaire l'inventaire des éléments nécessaires au système d'information\ndélimiter le système en s'informant auprès des futurs utilisateurs\nCela va permettre de créer le MCC (Modèle conceptuel de la communication) qui définit les flux d'informations à prendre en compte.\nL'étape suivante consiste à mettre au point le MCD (Modèle conceptuel des données) et le MCT (Modèle conceptuel des traitements) décrivant les règles et les contraintes à prendre en compte.\nLe modèle organisationnel consiste à définir le MOT (Modèle organisationnel des traitements) décrivant les contraintes dues à l'environnement (organisationnel, spatial et temporel).\nLe modèle logique représente un choix logiciel pour le système d'information.\nLe modèle physique reflète un choix matériel pour le système d'information.\n****** \nLe MCD et le diagramme de classes possèdent beaucoup de\npoints communs et une approche de structuration similaire:\n• Au niveau des entités/classes: contrainte de partition, contrainte\nd’exclusion, contrainte de totalité, l’identifiant est implicite en UML.\n• Au niveau des associations: contrainte de partition, d’exclusion, de\ntotalité, d’inclusion, d’unicité, association d’association, cardinalités.\n En UML le diagramme de classes est utilisé au cours de\nl’ensemble du processus:\n• Les classes contiennent les opérations (services),\n• Les classes sont analysées du point de vue des responsabilités,\n• Les contraintes sont exprimées dans un langage de contrainte (OCL),\n• UML propose des stéréotypes,\n• UML n’implique pas l’utilisation d’un formalisme de normalisation sur les\nclasses, mais des règles sont à respecter pour éviter les erreurs.\n\n\n
  • * La conception du système d'information se fait par étapes, afin d'aboutir à un système d'information fonctionnel reflétant une réalité physique. Il s'agit donc de valider une à une chacune des étapes en prenant en compte les résultats de la phase précédente. D'autre part, les données étant séparées des traitements, il faut vérifier la concordance entre données et traitements afin de vérifier que toutes les données nécessaires aux traitements sont présentes et qu'il n'y a pas de données superflues.\nCette succession d'étapes est appelée cycle d'abstraction pour la conception des systèmes d'information :\nL'expression des besoins est une étape consistant à définir ce que l'on attend du système d'information automatisé, il faut pour cela :\nfaire l'inventaire des éléments nécessaires au système d'information\ndélimiter le système en s'informant auprès des futurs utilisateurs\nCela va permettre de créer le MCC (Modèle conceptuel de la communication) qui définit les flux d'informations à prendre en compte.\nL'étape suivante consiste à mettre au point le MCD (Modèle conceptuel des données) et le MCT (Modèle conceptuel des traitements) décrivant les règles et les contraintes à prendre en compte.\nLe modèle organisationnel consiste à définir le MOT (Modèle organisationnel des traitements) décrivant les contraintes dues à l'environnement (organisationnel, spatial et temporel).\nLe modèle logique représente un choix logiciel pour le système d'information.\nLe modèle physique reflète un choix matériel pour le système d'information.\n****** \nLe MCD et le diagramme de classes possèdent beaucoup de\npoints communs et une approche de structuration similaire:\n• Au niveau des entités/classes: contrainte de partition, contrainte\nd’exclusion, contrainte de totalité, l’identifiant est implicite en UML.\n• Au niveau des associations: contrainte de partition, d’exclusion, de\ntotalité, d’inclusion, d’unicité, association d’association, cardinalités.\n En UML le diagramme de classes est utilisé au cours de\nl’ensemble du processus:\n• Les classes contiennent les opérations (services),\n• Les classes sont analysées du point de vue des responsabilités,\n• Les contraintes sont exprimées dans un langage de contrainte (OCL),\n• UML propose des stéréotypes,\n• UML n’implique pas l’utilisation d’un formalisme de normalisation sur les\nclasses, mais des règles sont à respecter pour éviter les erreurs.\n\n\n
  • Dans Merise le CVO traduit les différents états que peut prendre l'entité, leur succession, les événements déclencheurs:\n• Les états sont matérialisé par les différentes valeurs d'une propriété de\nl'entité,\n• Les événements sont aussi utilisés dans les traitements et apparaissent\ndans les flux du modèle de communication,\n• Le CVO est basé sur les réseaux de Petri.\n UML fournit un diagramme états-transitions qui correspond\ndirectement au CVO:\n• Il s'agit des modèles les plus proches,\n• UML propose des concepts de sous-états, de macro-états, d'états\nparallèles et détaille d'avantage les actions et les opération\n\n\n
  • Dans Merise le CVO traduit les différents états que peut prendre l'entité, leur succession, les événements déclencheurs:\n• Les états sont matérialisé par les différentes valeurs d'une propriété de\nl'entité,\n• Les événements sont aussi utilisés dans les traitements et apparaissent\ndans les flux du modèle de communication,\n• Le CVO est basé sur les réseaux de Petri.\n UML fournit un diagramme états-transitions qui correspond\ndirectement au CVO:\n• Il s'agit des modèles les plus proches,\n• UML propose des concepts de sous-états, de macro-états, d'états\nparallèles et détaille d'avantage les actions et les opération\n\n\n
  • * La conception du système d'information se fait par étapes, afin d'aboutir à un système d'information fonctionnel reflétant une réalité physique. Il s'agit donc de valider une à une chacune des étapes en prenant en compte les résultats de la phase précédente. D'autre part, les données étant séparées des traitements, il faut vérifier la concordance entre données et traitements afin de vérifier que toutes les données nécessaires aux traitements sont présentes et qu'il n'y a pas de données superflues.\nCette succession d'étapes est appelée cycle d'abstraction pour la conception des systèmes d'information :\nL'expression des besoins est une étape consistant à définir ce que l'on attend du système d'information automatisé, il faut pour cela :\nfaire l'inventaire des éléments nécessaires au système d'information\ndélimiter le système en s'informant auprès des futurs utilisateurs\nCela va permettre de créer le MCC (Modèle conceptuel de la communication) qui définit les flux d'informations à prendre en compte.\nL'étape suivante consiste à mettre au point le MCD (Modèle conceptuel des données) et le MCT (Modèle conceptuel des traitements) décrivant les règles et les contraintes à prendre en compte.\nLe modèle organisationnel consiste à définir le MOT (Modèle organisationnel des traitements) décrivant les contraintes dues à l'environnement (organisationnel, spatial et temporel).\nLe modèle logique représente un choix logiciel pour le système d'information.\nLe modèle physique reflète un choix matériel pour le système d'information.\n****** \nDans Merise le CVO traduit les différents états que peut prendre\nl'entité, leur succession, les événements déclencheurs:\n• Les états sont matérialisé par les différentes valeurs d'une propriété de\nl'entité,\n• Les événements sont aussi utilisés dans les traitements et apparaissent\ndans les flux du modèle de communication,\n• Le CVO est basé sur les réseaux de Petri.\n UML fournit un diagramme états-transitions qui correspond\ndirectement au CVO:\n• Il s'agit des modèles les plus proches,\n• UML propose des concepts de sous-états, de macro-états, d'états\nparallèles et détaille d'avantage les actions et les opération\n\n\n
  • * La conception du système d'information se fait par étapes, afin d'aboutir à un système d'information fonctionnel reflétant une réalité physique. Il s'agit donc de valider une à une chacune des étapes en prenant en compte les résultats de la phase précédente. D'autre part, les données étant séparées des traitements, il faut vérifier la concordance entre données et traitements afin de vérifier que toutes les données nécessaires aux traitements sont présentes et qu'il n'y a pas de données superflues.\nCette succession d'étapes est appelée cycle d'abstraction pour la conception des systèmes d'information :\nL'expression des besoins est une étape consistant à définir ce que l'on attend du système d'information automatisé, il faut pour cela :\nfaire l'inventaire des éléments nécessaires au système d'information\ndélimiter le système en s'informant auprès des futurs utilisateurs\nCela va permettre de créer le MCC (Modèle conceptuel de la communication) qui définit les flux d'informations à prendre en compte.\nL'étape suivante consiste à mettre au point le MCD (Modèle conceptuel des données) et le MCT (Modèle conceptuel des traitements) décrivant les règles et les contraintes à prendre en compte.\nLe modèle organisationnel consiste à définir le MOT (Modèle organisationnel des traitements) décrivant les contraintes dues à l'environnement (organisationnel, spatial et temporel).\nLe modèle logique représente un choix logiciel pour le système d'information.\nLe modèle physique reflète un choix matériel pour le système d'information.\n****** \nDans Merise le CVO traduit les différents états que peut prendre\nl'entité, leur succession, les événements déclencheurs:\n• Les états sont matérialisé par les différentes valeurs d'une propriété de\nl'entité,\n• Les événements sont aussi utilisés dans les traitements et apparaissent\ndans les flux du modèle de communication,\n• Le CVO est basé sur les réseaux de Petri.\n UML fournit un diagramme états-transitions qui correspond\ndirectement au CVO:\n• Il s'agit des modèles les plus proches,\n• UML propose des concepts de sous-états, de macro-états, d'états\nparallèles et détaille d'avantage les actions et les opération\n\n\n
  • On trouve les concepts d'événements, de règles de gestion, de\nsynchronisation et d'opérations qui réutilisent la notion de flux:\n• Les flux doivent être complètement décrits,\n• Les flux entrants sont des activateurs qui déclenchent des traitements,\n• Les flux sortants placent le SI dans un nouvel état.\n En UML, événements internes et externes apparaissent au\nniveau des diagrammes séquences/activités.\n• Les règles de gestion apparaissent dans les contraintes OCL et dans les\nméthodes des classes,\n• Les synchronisations apparaissent dans les diagrammes d'activités et\nd'états-transitions,\n• Les opérations sont représentées dans les diagrammes d'activités.\n En résumé: pour retrouver les informations d'un MCT, il faut\njongler avec différents diagrammes en UML !!!\n\n\n
  • On trouve les concepts d'événements, de règles de gestion, de\nsynchronisation et d'opérations qui réutilisent la notion de flux:\n• Les flux doivent être complètement décrits,\n• Les flux entrants sont des activateurs qui déclenchent des traitements,\n• Les flux sortants placent le SI dans un nouvel état.\n En UML, événements internes et externes apparaissent au\nniveau des diagrammes séquences/activités.\n• Les règles de gestion apparaissent dans les contraintes OCL et dans les\nméthodes des classes,\n• Les synchronisations apparaissent dans les diagrammes d'activités et\nd'états-transitions,\n• Les opérations sont représentées dans les diagrammes d'activités.\n En résumé: pour retrouver les informations d'un MCT, il faut\njongler avec différents diagrammes en UML !!!\n\n\n
  • On trouve les concepts d'événements, de règles de gestion, de\nsynchronisation et d'opérations qui réutilisent la notion de flux:\n• Les flux doivent être complètement décrits,\n• Les flux entrants sont des activateurs qui déclenchent des traitements,\n• Les flux sortants placent le SI dans un nouvel état.\n En UML, événements internes et externes apparaissent au\nniveau des diagrammes séquences/activités.\n• Les règles de gestion apparaissent dans les contraintes OCL et dans les\nméthodes des classes,\n• Les synchronisations apparaissent dans les diagrammes d'activités et\nd'états-transitions,\n• Les opérations sont représentées dans les diagrammes d'activités.\n En résumé: pour retrouver les informations d'un MCT, il faut\njongler avec différents diagrammes en UML !!!\n\n\n
  • On trouve les concepts d'événements, de règles de gestion, de\nsynchronisation et d'opérations qui réutilisent la notion de flux:\n• Les flux doivent être complètement décrits,\n• Les flux entrants sont des activateurs qui déclenchent des traitements,\n• Les flux sortants placent le SI dans un nouvel état.\n En UML, événements internes et externes apparaissent au\nniveau des diagrammes séquences/activités.\n• Les règles de gestion apparaissent dans les contraintes OCL et dans les\nméthodes des classes,\n• Les synchronisations apparaissent dans les diagrammes d'activités et\nd'états-transitions,\n• Les opérations sont représentées dans les diagrammes d'activités.\n En résumé: pour retrouver les informations d'un MCT, il faut\njongler avec différents diagrammes en UML !!!\n\n\n
  • * La conception du système d'information se fait par étapes, afin d'aboutir à un système d'information fonctionnel reflétant une réalité physique. Il s'agit donc de valider une à une chacune des étapes en prenant en compte les résultats de la phase précédente. D'autre part, les données étant séparées des traitements, il faut vérifier la concordance entre données et traitements afin de vérifier que toutes les données nécessaires aux traitements sont présentes et qu'il n'y a pas de données superflues.\nCette succession d'étapes est appelée cycle d'abstraction pour la conception des systèmes d'information :\nL'expression des besoins est une étape consistant à définir ce que l'on attend du système d'information automatisé, il faut pour cela :\nfaire l'inventaire des éléments nécessaires au système d'information\ndélimiter le système en s'informant auprès des futurs utilisateurs\nCela va permettre de créer le MCC (Modèle conceptuel de la communication) qui définit les flux d'informations à prendre en compte.\nL'étape suivante consiste à mettre au point le MCD (Modèle conceptuel des données) et le MCT (Modèle conceptuel des traitements) décrivant les règles et les contraintes à prendre en compte.\nLe modèle organisationnel consiste à définir le MOT (Modèle organisationnel des traitements) décrivant les contraintes dues à l'environnement (organisationnel, spatial et temporel).\nLe modèle logique représente un choix logiciel pour le système d'information.\nLe modèle physique reflète un choix matériel pour le système d'information.\n****** \n\nModèles organisationnels\n Le niveau organisationnel des traitements utilisent plusieurs concepts:\n• Les fonctions: issues de la décomposition des règles de gestion. Une fonction est activée par\nun événement, elle fournit un résultat et un modèle de données spécifiques. Seules les\nfonctions élémentaires sont décrites (CMSV).\n• Flux organisationnels: notion de consommation des événements,\n• Procédure fonctionnelle: ensemble cohérent de fonctions affecté à des types d'acteurs avec\nun profil (automatisation, fréquence, périodicité, etc.)\n• Type d'acteur: ensemble de personnes exerçant les mêmes actions sur le SI.\n• Le MOT suit un certain nombre de règles de construction.\n En UML, les aspects dynamiques apparaissent la encore dans les diagrammes\nd'activités/séquences:\n• Servent directement pour le passage du métier au système informatique,\n• Les échanges et les attentes apparaissent clairement dans les activités,\n• Merise offre une vision plus globale de l'organisation.\n Le niveau MOD:\n• On décrit les propriétés de chaque données (confidentialité, visibilité) et la localisation sur\nles différents sites.\n• On retrouve cela en UML dans la notion de travailleur d'interface, de contrôle et dans\nl'approche architecture logicielle.\n\n\n\n
  • * La conception du système d'information se fait par étapes, afin d'aboutir à un système d'information fonctionnel reflétant une réalité physique. Il s'agit donc de valider une à une chacune des étapes en prenant en compte les résultats de la phase précédente. D'autre part, les données étant séparées des traitements, il faut vérifier la concordance entre données et traitements afin de vérifier que toutes les données nécessaires aux traitements sont présentes et qu'il n'y a pas de données superflues.\nCette succession d'étapes est appelée cycle d'abstraction pour la conception des systèmes d'information :\nL'expression des besoins est une étape consistant à définir ce que l'on attend du système d'information automatisé, il faut pour cela :\nfaire l'inventaire des éléments nécessaires au système d'information\ndélimiter le système en s'informant auprès des futurs utilisateurs\nCela va permettre de créer le MCC (Modèle conceptuel de la communication) qui définit les flux d'informations à prendre en compte.\nL'étape suivante consiste à mettre au point le MCD (Modèle conceptuel des données) et le MCT (Modèle conceptuel des traitements) décrivant les règles et les contraintes à prendre en compte.\nLe modèle organisationnel consiste à définir le MOT (Modèle organisationnel des traitements) décrivant les contraintes dues à l'environnement (organisationnel, spatial et temporel).\nLe modèle logique représente un choix logiciel pour le système d'information.\nLe modèle physique reflète un choix matériel pour le système d'information.\n****** \n\n\n\n
  • * La conception du système d'information se fait par étapes, afin d'aboutir à un système d'information fonctionnel reflétant une réalité physique. Il s'agit donc de valider une à une chacune des étapes en prenant en compte les résultats de la phase précédente. D'autre part, les données étant séparées des traitements, il faut vérifier la concordance entre données et traitements afin de vérifier que toutes les données nécessaires aux traitements sont présentes et qu'il n'y a pas de données superflues.\nCette succession d'étapes est appelée cycle d'abstraction pour la conception des systèmes d'information :\nL'expression des besoins est une étape consistant à définir ce que l'on attend du système d'information automatisé, il faut pour cela :\nfaire l'inventaire des éléments nécessaires au système d'information\ndélimiter le système en s'informant auprès des futurs utilisateurs\nCela va permettre de créer le MCC (Modèle conceptuel de la communication) qui définit les flux d'informations à prendre en compte.\nL'étape suivante consiste à mettre au point le MCD (Modèle conceptuel des données) et le MCT (Modèle conceptuel des traitements) décrivant les règles et les contraintes à prendre en compte.\nLe modèle organisationnel consiste à définir le MOT (Modèle organisationnel des traitements) décrivant les contraintes dues à l'environnement (organisationnel, spatial et temporel).\nLe modèle logique représente un choix logiciel pour le système d'information.\nLe modèle physique reflète un choix matériel pour le système d'information.\n****** \n\n\n\n
  • * La conception du système d'information se fait par étapes, afin d'aboutir à un système d'information fonctionnel reflétant une réalité physique. Il s'agit donc de valider une à une chacune des étapes en prenant en compte les résultats de la phase précédente. D'autre part, les données étant séparées des traitements, il faut vérifier la concordance entre données et traitements afin de vérifier que toutes les données nécessaires aux traitements sont présentes et qu'il n'y a pas de données superflues.\nCette succession d'étapes est appelée cycle d'abstraction pour la conception des systèmes d'information :\nL'expression des besoins est une étape consistant à définir ce que l'on attend du système d'information automatisé, il faut pour cela :\nfaire l'inventaire des éléments nécessaires au système d'information\ndélimiter le système en s'informant auprès des futurs utilisateurs\nCela va permettre de créer le MCC (Modèle conceptuel de la communication) qui définit les flux d'informations à prendre en compte.\nL'étape suivante consiste à mettre au point le MCD (Modèle conceptuel des données) et le MCT (Modèle conceptuel des traitements) décrivant les règles et les contraintes à prendre en compte.\nLe modèle organisationnel consiste à définir le MOT (Modèle organisationnel des traitements) décrivant les contraintes dues à l'environnement (organisationnel, spatial et temporel).\nLe modèle logique représente un choix logiciel pour le système d'information.\nLe modèle physique reflète un choix matériel pour le systè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 élément clé du succès.\nDe la part le retour des utilisateurs, des tests, . . .\nA chaque itération, on s'adapte en se basant sur le feedback et les leçons de la dernière itération, et on converge doucement vers de meilleurs : \nConception, Plans, Exigences, Estimations.\n
  • Des unités logicielles "boîte-noire" avec une API\nFonctionnent généralement dans une (locale ou distante) architecture à base de composants: EJB, COM, .NET, JavaBeans\nLe UP encourage la bonne pratique suivante: \nAcquérir des composants existants afin d'accélérer le développement\nEtablir une culture d'acquisition ou d'achat de composants, plutôt que de développer toutes les parties du logiciel.\n
  • La gestion des risques est une démarche proactive, alors que la gestion des problèmes est une démarche réactive.\nIl ne faut pas confondre risque et problème.\nUn problème est un risque qui s’est révélé.\n
  • Par exemple : \nL’intégration, l’architecture\nLa gestion des ressources humaines nécessite une attention particulière : Besoins ? Profils ? Organisation de l’équipe projet ? Communication et management de l’équipe\n
  • \n
  • \nQui a entendu parler du Standish Group ? \nLe Standish Group International, Inc. est une société d’études de marché et de conseil spécialisée dans la conception de logiciels stratégiques et le commerce électronique. (Rendez-vous sur le site www.standishgroup.com.) \nSon fondateur, Jim Johnson, s’est rendu en Suède pour expliquer, au cours d’une conférence, la responsabilité des L4G dans l’échec de projets informatiques dans les entreprises. Et, à sa grande surprise, après avoir posé au public la question suivante : « pourquoi vos projets échouent-ils ? », il s’est entendu répondre : « parce que les exigences sont mal définies ». Pour approfondir le sujet, Jim Johnson s’est alors livré à une étude formelle des ateliers informatiques des grandes entreprises et a fait apparaître quelques résultats intéressants sur des projets « remis en question » ou compromis.\nLes projets remis en question subissaient des dépassements de budgets et de délais, tandis que les projets compromis étaient purement et simplement annulés. En cherchant à savoir ce qui avait provoqué l’annulation ou la remise en question du projet, le Standish Group en a appris plus long sur les problèmes recensés ci-dessus. Remarquez que les problèmes liés à la gestion des exigences figurent en tête des causes ayant conduit à l’échec du projet. \n
  • \n
  • \n
  • \n
  • \n
  • 1) le cycle de vie, c’est le cycle de développement + la phase de spécification et la phase de maintenance.\n\n2) Cycle de développementCycle de vie\nspécification+planification20% 8%\n étudier le problème\n analyser les besoins\n spécifier actions et données\nconception+ développement30%12%\n décomposer le projet\n affiner les parties, les coder\n documenter la conception\ntests + validation50%20%\n vérifier les fonctions\n tester les performances\n optimiser\nopération + maintenance60%\n formation des utilisateurs\n appliquer le logiciel\n maintenance corrective et évolutive\n portage du programme ailleurs\n
  • 1) le cycle de vie, c’est le cycle de développement + la phase de spécification et la phase de maintenance.\n\n2) Cycle de développementCycle de vie\nspécification+planification20% 8%\n étudier le problème\n analyser les besoins\n spécifier actions et données\nconception+ développement30%12%\n décomposer le projet\n affiner les parties, les coder\n documenter la conception\ntests + validation50%20%\n vérifier les fonctions\n tester les performances\n optimiser\nopération + maintenance60%\n formation des utilisateurs\n appliquer le logiciel\n maintenance corrective et évolutive\n portage du programme ailleurs\n
  • \n=========================\nL'Extreme Programming repose sur des cycles rapides de développement (des itérations de quelques semaines) dont les étapes sont les suivantes :\n•une phase d'exploration détermine les scénarios clients qui seront fournis pendant cette itération ;\n•l'équipe transforme les scénarios en tâches à réaliser et en tests fonctionnels ;\n•chaque développeur s'attribue des tâches et les réalise avec un binôme ;\n•lorsque tous les tests fonctionnels passent, le produit est livré.\nLe cycle se répète tant que le client peut fournir des scénarios à livrer. Généralement le cycle de la première livraison se caractérise par sa durée et le volume important de fonctionnalités embarquées. Après la première mise en production, les ité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éconise un déroulement par itérations courtes et gérées collectivement, avec une implication constante du client. Il en découle une redéfinition de la relation entre client et fournisseur avec de surprenants résultats en termes de qualité de code, de délais et de satisfaction de la demande du client.\n\n
  • 1) le cycle de vie, c’est le cycle de développement + la phase de spécification et la phase de maintenance.\n\n2) Cycle de développementCycle de vie\nspécification+planification20% 8%\n étudier le problème\n analyser les besoins\n spécifier actions et données\nconception+ développement30%12%\n décomposer le projet\n affiner les parties, les coder\n documenter la conception\ntests + validation50%20%\n vérifier les fonctions\n tester les performances\n optimiser\nopération + maintenance60%\n formation des utilisateurs\n appliquer le logiciel\n maintenance corrective et évolutive\n portage du programme ailleurs\n
  • 1) le cycle de vie, c’est le cycle de développement + la phase de spécification et la phase de maintenance.\n\n2) Cycle de développementCycle de vie\nspécification+planification20% 8%\n étudier le problème\n analyser les besoins\n spécifier actions et données\nconception+ développement30%12%\n décomposer le projet\n affiner les parties, les coder\n documenter la conception\ntests + validation50%20%\n vérifier les fonctions\n tester les performances\n optimiser\nopération + maintenance60%\n formation des utilisateurs\n appliquer le logiciel\n maintenance corrective et évolutive\n portage du programme ailleurs\n
  • 1) le cycle de vie, c’est le cycle de développement + la phase de spécification et la phase de maintenance.\n\n2) Cycle de développementCycle de vie\nspécification+planification20% 8%\n étudier le problème\n analyser les besoins\n spécifier actions et données\nconception+ développement30%12%\n décomposer le projet\n affiner les parties, les coder\n documenter la conception\ntests + validation50%20%\n vérifier les fonctions\n tester les performances\n optimiser\nopération + maintenance60%\n formation des utilisateurs\n appliquer le logiciel\n maintenance corrective et évolutive\n portage du programme ailleurs\n
  • 1) le cycle de vie, c’est le cycle de développement + la phase de spécification et la phase de maintenance.\n\n2) Cycle de développementCycle de vie\nspécification+planification20% 8%\n étudier le problème\n analyser les besoins\n spécifier actions et données\nconception+ développement30%12%\n décomposer le projet\n affiner les parties, les coder\n documenter la conception\ntests + validation50%20%\n vérifier les fonctions\n tester les performances\n optimiser\nopération + maintenance60%\n formation des utilisateurs\n appliquer le logiciel\n maintenance corrective et évolutive\n portage du programme ailleurs\n
  • 1) le cycle de vie, c’est le cycle de développement + la phase de spécification et la phase de maintenance.\n\n2) Cycle de développementCycle de vie\nspécification+planification20% 8%\n étudier le problème\n analyser les besoins\n spécifier actions et données\nconception+ développement30%12%\n décomposer le projet\n affiner les parties, les coder\n documenter la conception\ntests + validation50%20%\n vérifier les fonctions\n tester les performances\n optimiser\nopération + maintenance60%\n formation des utilisateurs\n appliquer le logiciel\n maintenance corrective et évolutive\n portage du programme ailleurs\n
  • DEFINITION GENERALE DE CHAQUE PHASE\nDéfinir la compréhension du besoin, le cadre du développement par rapport au système existant mais aussi la liste des contraintes. A ce stade, il faut aussi définir les utilisateurs externes au logiciel et ses grands packages de service.\nanalyse détaillée permet de spécifier précisé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écompose en \nétude technique initiale permettant de définir l'architecture technique du logiciel et les principes d'implémentation.\nconception préliminaire permettant de formaliser l'architecture technique avec l'ensemble des concepts techniques.\nconception détaillée permettant de préciser les services techniques et de préparer la phase de développement.\nDéveloppement des composants Cette phase regroupe les activités de codage (ou implémentation des services), de mise au point des composants et leur test unitaire.\nIntégration Cette phase regroupe les activité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érifier la conformité du logiciel à ses spécifications.\n
  • Il s’agit du cycle classique. C’est aussi le cycle en cascade, où les flèches vont dans les deux sens (on vérifie à chaque étape la conformité aux spécifications de l’étape précédente).\n\nLes flèches bleues montrent les tests qui correspondent aux phases initiales.\n\nLe risque essentiel est dû au temps qui sépare l’expression des besoins de la phase de validation: on peut s’apercevoir après de longs mois que le produit n’est pas ce que voulait réellement le client. \n
  • \n
  • Source anonyme IBM, sans doute basée sur une longue expérience de la gestion de projet ;-)\n
  • Frederick Winslow Taylor (20 mars 1856, Germantown (Pennsylvanie) - 21 mars 1915, Philadelphie (Pennsylvanie) était un ingénieur américain qui a mis en application l'organisation scientifique du travail, qui est la base de la révolution industrielle du XXe siècle.\nSes travaux de recherche ont conduit au développement du travail à la chaîne, à la parcellisation des tâches, en transformant les ouvriers et les employés à ne devenir que de simples machines de guerre dans d'immenses entreprises mécanisées. Pour Taylor, le rôle de l'encadrement consiste à indiquer aux employés la meilleure manière de réaliser une tâche, de leur fournir les outils et formations appropriés, et de leur délivrer des objectifs et incitations en vue d'atteindre la performance. Selon ses détracteurs, il a introduit dans le monde du travail une séparation radicale entre ceux qui conçoivent et ceux qui produisent. Pour Taylor, l’ouvrier n’est pas là pour penser, mais pour exécuter des gestes savamment calculés pour lui. Il est encouragé à être performant par un système de primes. Tout travail intellectuel doit être éliminé de l’atelier pour être concentré dans les bureaux de planification et d’organisation de l’entreprise.\n\n
  • CYCLES DE VIE TRADITIONNELS\nle cycle "en cascade" (ou "waterfall") définit les phases d'analyse (décrire le "quoi"), de conception (définir "comment" le système sera réalisé et comment il se décompose) de codage (réalisation de chaque composant), de test unitaire (validation de chaque composant), d'intégration (assemblage des composants), de validation (vérification de la conformité du produit par rapport à sa spé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érification. Il établit également les liens entre ces phases de construction et les phases de vérification.\nEn général, ces types de cycle de vie mettent l'accent sur les liens entre phases et les moyens de passage de l'une à l'autre, y compris lors de retour arrière.\nCYCLE EN SPIRALE\nLes cycles de vie traditionnels ne garantissent pas totalement les incohérences entre phases et n'assurent pas que le cycle de vie puisse être appliqué intégralement (par exemple, si l'analyse est trop vague ou incohérente, la phase de conception sera difficile à réaliser ce qui nécessitera de nombreux retours en phase d'analyse. De plus, cette situation engendre des impossibilités dans le contrôle du déroulement du projet. Pour palier ces manques, Barry Boehm a dé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'équipe aura recourt à du prototypage.\nL'objectif étant de se lancer dans un développement traditionnel seulement lorsque tous les risques sont maîtrisés.\nAPPROCHE ORIENTEE OBJET\nAvec une opération telle que UML, l'équipe formalise le problème avec le même modèle tout au long du cycle de vie. Ceci nécessite évidemment de proposer une solution méthodologique complète.\n\n\n\nRaffinement itératif\nPremière itération\nCommencer au centre de la spirale, planifier le projet, et recueillir les besoins initiaux.\nEffectuer une analyse de risques basée sur les besoins initiaux, prendre la décision appropriée, et continuer si c'est positif.\nCréer un prototype initial du système\nL'usager évalue ( et le développeur) le prototype\n\nDeuxième itération\nLe feedback de l'évaluation est utilisé pour raffiner les besoins et on planifie davantage le projet.\nEffectuer une analyse de risques basée sur les besoins révisés, prendre la décision appropriée, et continuer si c'est positif.\nCréer un deuxième prototype, basé sur le prototype initial ou en construire un à partir de zéro.\nL'usager évalue ( et le développeur) le deuxième prototype\n\nN-ième itérations\nRépéter la deuxième itération si désiré\n\nAprès la dernière décision\nDévelopper (ingéniériser) le système\n\nD’après Ingéniérie du logiciel, Ecole polytechnique de Montréal\n\n\nAnalyse des risques \nRisques humains: défaillance du personnel ; surestimation des compétences, \ntravailleur solitaire, héroïsme, manque de motivation.. \nRisques processus: pas de gestion de projet, calendrier et budget irréalistes, \ncalendrier abandonné sous la pression des clients, insuffisance de données, \nvalidité des besoins, développement de fonctions inappropriées, développement \nd'interfaces utilisateurs inappropriées… \nRisques Technologiques: changement de technologie en cours de route, \nproblèmes de performance, exigences démesurées par rapport à la technologie, \nincompréhension des fondements de la technologie… \n\n
  • 3 modes d’organisations possibles en choissant de fixer deux facteurs pour la production des incréments : \n Production des incréments asservie sur 2 parmi 3 :\n période (e.g. release toutes les 2 semaines)\n fonctionnalités (releases découpés suivant use-cases)\n niveau de qualité (problème de la mesure)\n\nModèle par incrément\n\n\nDans les modèles précédents un logiciel est décomposé en composants développés séparément et intégrés à la fin du processus.\nDans les modèles par incrément un seul ensemble de composants est développé à la fois : des incréments viennent s’intégrer à un noyau de logiciel développé au préalable. Chaque incrément est développé selon l’un des modèles précédents.\nLes avantages de ce type de modèle sont les suivants :\n•chaque développement est moins complexe ;\n•les intégrations sont progressives ;\n•il est ainsi possible de livrer et de mettre en service chaque incrément ;\n•il permet un meilleur lissage du temps et de l’effort de développement grâce à la possibilité de recouvrement (parallélisation) des différentes phases.\nLes risques de ce type de modèle sont les suivants :\n•remettre en cause les incréments précédents ou pire le noyau ;\n•ne pas pouvoir intégrer de nouveaux incréments.\nLes noyaux, les incréments ainsi que leurs interactions doivent donc être spécifiés globalement, au début du projet. Les incréments doivent être aussi indépendants que possibles, fonctionnellement mais aussi sur le plan du calendrier du développement.\n\n\n\n
  • 3 modes d’organisations possibles en choissant de fixer deux facteurs pour la production des incréments : \n
  • 3 modes d’organisations possibles en choissant de fixer deux facteurs pour la production des incréments : \n
  • Introduction rapide à 'objet et à UML

    1. 1. ACSIModélisation par Objets À destination des étudiants de1e année IUT Nice-Sophia Antipolis (S2) 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
    2. 2. 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 Présentation du Module : démarche générale09/10 2
    3. 3. I. Quels sont les problèmesdu développement logiciel? 3
    4. 4. I. Quels sont les problèmesdu développement logiciel? Un peu d’histoire 4
    5. 5. 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 larchitecture des ordinateurs utilisés. sub     $sp, $sp, 4 sw      r,0($sp)09/10 5
    6. 6. Intro. ✓histoire Intro. UML Démarche La gestion progressive de la complexité Programmation en langages évolués  Lorsque le nombre darchitectures 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 STOP09/10 6 END PROGRAM DEGRAD
    7. 7. 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 danalyse 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» dune structure de données et dun ensemble distinct dalgorithmes 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 7 Phrase:=ConstruitPhrase(Phrase);
    8. 8. 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 sest diversifiée, les besoins ont explosé.09/10 8
    9. 9. 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 dimportantes 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 dadresses ont dû être récrits à grands frais.09/10 9
    10. 10. 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 10
    11. 11. 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 10
    12. 12. 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 10
    13. 13. I. Quels sont les problèmesdu développement logiciel? Du bidouillage au génie logiel 11
    14. 14. Intro. Intro. UML Démarche Problématique du génie logiciel ➡ Programming-in-the-Small Problème de la qualité interne dun 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équel09/10 12
    15. 15. 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équel09/10 13
    16. 16. 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 reste09/10 14
    17. 17. 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ème09/10 15
    18. 18. Intro. ✓Prog. Large ✓Complexité Intro. UML Démarche Programming-in-the-Large Gérer la complexité due à la taille a) c) b) d) Si lautomobile avait suivi le même développement que lordinateur, une Rolls-Royce coûterait aujourdhui 100$, pourrait rouler un million de kilomètres avec un litre dessence, et exploserait une fois par an en tuant tout le monde à bord. Robert Cringely. Pr. Jean-Marc Jézéquel09/10 16
    19. 19. 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 dexistence de Windows, Vista aura été le système dexploitation dont le cycle de développement fut le plus long ! Et pour cause, puisquaprès avoir démarré le développement de Longhorn en 2001, Microsoft a du remettre à plat linté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. Cest au maître dœuvre de Vista, Jim Allchin, que lon 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, cest pratiquement tout le travail des 9 000 développeurs mobilisés sur Windows Vista qui est à recommencer…09/10 17
    20. 20. Intro. ✓Prog. Large ✓Complexité Intro. UML Démarche Programming-in-the-Large Augmentation exponentielle de la taille du logiciel09/10 18
    21. 21. 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 à lEst 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 19
    22. 22. Intro. ✓Prog. Large ✓Diviser Intro. UML Démarche Gestion de la complexité due à la taille : diviser pour résoudre Aspects techniques en sappuyant techniquement sur la modularité « Encapsulation et masquage dinformation, 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âches09/10 20
    23. 23. Intro. ✓Prog. Durée Intro. UML Démarche Programming-in-the-Duration Gestion de l’évolution dun 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 21
    24. 24. 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 dune session09/10 22
    25. 25. 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 23
    26. 26. Intro. ✓Prog. Durée ✓Maintenance Intro. UML Démarche Programming-in-the-Duration Réalisation currentTime; currentTime;09/10 24
    27. 27. 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 E09/10 25
    28. 28. 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 7009/10 25
    29. 29. Exemple Windows Vista …Vista prêt à en découdre avec les failles de sécurité!Cest inévitable. La découverte de failles devrait saccélérer avec le lancement engrandeur réelle de Windows Vista. Microsoft sy prépare……«  Les failles sont inhérentes au développement logiciel. Elles reposent sur deserreurs de programmation. Or, détecter absolument toutes les erreurs estimpossible même avec des moyens financiers comme ceux dont disposeMicrosoft »…8 000 dollars pour chaque trou de sécurité!… Idefense Labs, une filiale de Verisign, va encore plus loin. Elle promet8 000 dollars (assortis dun bonus oscillant entre 2 000 et 4 000 dollars selon laqualité des explications fournies) à qui découvrira une faille critique dans Vista ouInternet Explorer 7…… « La démarche est pertinente dans la mesure où elle permet de mobiliser leschercheurs du monde entier à moindre frais »… 26 Grimaldi 2010
    30. 30. Intro. ✓Prog. Durée✓Maintenance Intro. UML Démarche Programming-in-the-Duration Coût de la Maintenance09/10 27
    31. 31. Intro. ✓Prog. Durée ✓Vers l’objet Intro. UML Démarche La découpe fonctionnelle dun problème informatique : une approche intuitive Factorisation09/10 28
    32. 32. Intro. ✓Prog. Durée ✓Vers l’objet Intro. UML Démarche Le revers de la médaille : maintenance complexe en cas dévolution09/10 29 ->
    33. 33. 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 29 ->
    34. 34. Intro. ✓Prog. Durée ✓Vers l’objet Intro. UML Démarche Réunir données et traitements : Programmation par objets09/10 30
    35. 35. 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 dattributs caractérise létat de lobjet.• Un ensemble dopérations (méthodes ou comportements) en définit lecomportement.09/10 31
    36. 36. 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 dun 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 32
    37. 37. Intro. ✓Prog. Durée ✓Vers l’objet Intro. UML Démarche Vision objet du système informatique (3) ➡ Héritage (et polymorphisme) Lhéritage est un mécanisme de transmission des propriétés dune classe (ses attributs et méthodes) vers une sous- classe.09/10 33
    38. 38. 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é dune méthode à pouvoir sappliquer à des objets de classes différentes.09/10 34
    39. 39. Intro. Intro. UML Démarche Approche orientée-objet Illustration de Jean-Marc Estay (IMA)09/10 35
    40. 40. 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 36
    41. 41. 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 37
    42. 42. III. Introduction à UML 38
    43. 43. III. Introduction à UML UML, histoire, généralité 39
    44. 44. 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éthodologies09/10 40
    45. 45. 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éthodes09/10 41
    46. 46. 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, IBM09/10 42
    47. 47. 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 public09/10 43
    48. 48. Intro. Intro. UML ✓Histoire Démarche Ingénierie Électrique Ingénierie du Bâtiment Ingénierie Ingénierie09/10 Mécanique 44 Logicielle Grimaldi 2010
    49. 49. 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écisions09/10 45
    50. 50. 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 200509/10 46
    51. 51. 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 200509/10 46
    52. 52. 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 200509/10 46
    53. 53. 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 200509/10 46
    54. 54. 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 47
    55. 55. 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 47
    56. 56. 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 collaboration09/10 47
    57. 57. 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és09/10 47
    58. 58. Intro. Intro. UML ✓Histoire Démarche Les points forts dUML UML est un langage normalisé gain de précision gage de stabilité encourage lutilisation doutils UML est un support de communication performant Il cadre lanalyse. Il facilite la compréhension de représentations abstraites complexes. Son caractère polyvalent et sa souplesse en font un langage universel.09/10 48
    59. 59. Intro. Intro. UML ✓Histoire Démarche Les points faibles dUML La mise en pratique dUML nécessite un apprentissage et passe par une période dadaptation. Le processus (non couvert par UML) est une autre clé de la réussite dun projet.09/10 49
    60. 60. III. Introduction à UML survol 50
    61. 61. 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ôleDAcces09/10 51
    62. 62. 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 52
    63. 63. 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 53
    64. 64. 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 elles09/10 54
    65. 65. 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 55
    66. 66. 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 distribution09/10 56
    67. 67. 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 200509/10 57
    68. 68. 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 dans09/10 58 le cours
    69. 69. V. Démarche générale suivie dans le cadre de ce module 59
    70. 70. Intro. Intro. UML Démarche Approche dirigée par les cas09/10 60
    71. 71. Intro. Intro. UML Démarche Approche dirigée par les cas 1. Établir le dictionnaire09/10 60
    72. 72. 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 60
    73. 73. 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 dutilisation qui montreront les interactions entre les acteurs actifs externes et le système vu comme une boîte noire.09/10 60
    74. 74. 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 dutilisation qui montreront les interactions entre les acteurs actifs externes et le système vu comme une boîte noire. 4. Pour chaque cas dutilisation seront décrits les principaux flux qui visualisent la chronologie des échanges entre les acteurs et le système09/10 60
    75. 75. 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 dutilisation qui montreront les interactions entre les acteurs actifs externes et le système vu comme une boîte noire. 4. Pour chaque cas dutilisation seront décrits les principaux flux qui visualisent la chronologie des échanges entre les acteurs et le système 5. Capturer les concepts du domaine09/10 60
    76. 76. 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 dutilisation qui montreront les interactions entre les acteurs actifs externes et le système vu comme une boîte noire. 4. Pour chaque cas dutilisation 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 laspect temporel des interactions entre les objets de lapplication qui participent au scénario09/10 60
    77. 77. 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 dutilisation qui montreront les interactions entre les acteurs actifs externes et le système vu comme une boîte noire. 4. Pour chaque cas dutilisation 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 laspect temporel des interactions entre les objets de lapplication qui participent au scénario 7. Ces diagrammes serviront alors de base à la construction des diagrammes de séquence de conception et des diagrammes de classes qui visualisent larchitecture du logiciel, la hiérarchie et les associations entre classes09/10 60
    78. 78. 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 dutilisation qui montreront les interactions entre les acteurs actifs externes et le système vu comme une boîte noire. 4. Pour chaque cas dutilisation 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 laspect temporel des interactions entre les objets de lapplication qui participent au scénario 7. Ces diagrammes serviront alors de base à la construction des diagrammes de séquence de conception et des diagrammes de classes qui visualisent larchitecture du logiciel, la hiérarchie et les associations entre classes 8. La structure de la BD peut alors être abordée.09/10 60
    79. 79. Exemple: Une ludothèque 61
    80. 80. Intro. Intro. UML Démarche Ludothèque Les adhérents peuvent emprunter des jeux en s’adressant à un conseiller qui enregistre l’emprunt. Les jeux empruntés sont rendus à un conseiller.... Un adhérent peut réserver des jeux. Une réservation précise l’emprunteur, le jeu et la date de la demande de réservation. L’adhérent est averti quand le jeu revient en rayon. Pour organiser un événement le conseiller spécialisé doit alors donner les informations suivantes : les jeux à tester, le nombre maximal et minimal de participants attendus, la date, et l’heure de début de l’événement. Un adhérent peut s’inscrire pour participer à un événement à condition qu’il y ait encore de la place. Un adhérent peut payer sa cotisation en ligne par un système de paiement externe Un internaute peut consulter les jeux et s’inscrire.09/10 62
    81. 81. Intro. Intro. UML Démarche Ludothèque Les adhérents peuvent emprunter des jeux en s’adressant à un conseiller qui enregistre l’emprunt. Les jeux empruntés sont rendus à un conseiller.... Un adhérent peut réserver des jeux. Une réservation précise l’emprunteur, le jeu et la date de la demande de réservation. L’adhérent est averti quand le jeu revient en rayon. Pour organiser un événement le conseiller spécialisé doit alors donner les informations suivantes : les jeux à tester, le nombre maximal et minimal de participants attendus, la date, et l’heure de début de l’événement. Un adhérent peut s’inscrire pour participer à l’événement en en faisant la demande à un conseiller spécialisé, à condition qu’il y ait encore de la place. Un adhérent peut payer sa cotisation en ligne par un système09/10 de paiement externe 63
    82. 82. Intro. Intro. UML Démarche Ludothèque : Dictionnaire Adhérents : Personne connue du système par son nom, prénom, date de naissance, adresse postale, date du dernier paiement de la cotisation et adresse email éventuelle. Conseiller : Personne identifiée qui a des droits sur le système. Réservation : Une réservation précise l’emprunteur, le jeu et la date de la demande de réservation. L’adhérent est averti quand le jeu revient en rayon. Evénement : temps de démonstration et de jeux organisé à l’avance. Il précise les informations suivantes : les jeux à tester, le nombre maximal et minimal de participants attendus, la date, et l’heure de début de l’événement. Jeux : Un jeu est caractérisé par un identifiant, un nombre de joueurs, ...09/10 64
    83. 83. Intro. Intro. UML Démarche Acteurs et diagramme de contexte09/10 65
    84. 84. Intro. Intro. UML Démarche Diagramme de cas d’utilisation09/10 66
    85. 85. Intro. Intro. UML Démarche 4) Description complète dun cas d’utilisation Emprunter un jeu Acteurs : Conseiller Objectif : Décrire l’emprunt d’un jeux par un Conseiller Aperçu : Un Conseiller passe le lecteur de code barre sur le jeu; Le Conseiller saisit l’identifiant de l’adhérent. Le système vérifie la droit d’emprunter de l’adhérent. Il enregistre l’emprunt.09/10 67
    86. 86. Intro. Intro. UML Démarche 5) Capturer les concepts du domaine Emprunter un jeu Acteurs : Conseiller Objectif : Décrire l’emprunt d’un jeux par un Conseiller Aperçu : Un Conseiller passe le lecteur de code barre sur le jeu; Le Conseiller saisit l’identifiant de l’adhérent. Le système vérifie la droit d’emprunter de l’adhérent. Il enregistre l’emprunt.09/10 68
    87. 87. Intro. Intro. UML Démarche 5) Capturer les concepts du domaine09/10 69
    88. 88. Intro. Intro. UML Démarche Scénarios : Niveau Analyse09/10 70
    89. 89. Intro. Intro. UML Démarche Scénarios : Niveau Conception09/10 71
    90. 90. Intro. Intro. UML Démarche Diagramme de classes : Niveau Conception09/10 72
    91. 91. Intro. Intro. UML Démarche Diagramme de classes : Niveau Conception : Tables (partiel)09/10 73
    92. 92. Exemple: Une galerie d’art virtuelle 74
    93. 93. 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 lInformaticien" 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 201009/10 75

    ×