Conception. Génie Logiciel. Renaud Marlet. LaBRI / INRIA (d'après A.-M. Hugues) màj 17/04/2007

Dimension: px
Commencer à balayer dès la page:

Download "Conception. Génie Logiciel. Renaud Marlet. LaBRI / INRIA http://www.labri.fr/~marlet. (d'après A.-M. Hugues) màj 17/04/2007"

Transcription

1 1 Génie Logiciel (d'après A.-M. Hugues) Conception Renaud Marlet LaBRI / INRIA màj 17/04/2007

2 2 Position dans le cycle de vie Contexte : étant donnée une spécification (ce que doit faire le produit) Phase de conception : architecture du produit (comment il est structuré pour faire ce qu'il doit faire) document de conception globale / détaillée (si cycle de vie en V : + plan d'intégration) Phase suivante : codage

3 Cycle de vie : 3 modèle en V (rappel) (Expression des besoins) (Validation des besoins) Spécifications Qualification Conception globale Conception détaillée Tests d'intégration Tests unitaires Programmation

4 4 Deux niveaux de détail Conception globale (ou préliminaire) choix fondamentaux d'architecture logicielle en lien éventuel avec l'architecture matérielle Conception détaillée description précise de chaque module algorithmes mis en œuvre traitements effectués en cas d'erreur

5 5 Conception détaillée Souvent escamotée petite taille des modules description précise des algorithmes pas nécessaire Pas traitée dans ce cours (on verra des exemples au cas par cas)

6 6 Objectifs de la conception Séparation des problèmes permet d'appréhender un problème complexe Décomposition modulaire du logiciel permet le développement en parallèle (test y compris) facilite la maintenance (corrective ou évolutive) documentation et isolation des comportements localisation des modifications facilite la réutilisation

7 7 Importance de la conception Influence considérable sur la réalisation du logiciel en particulier sur la qualité Erreur dans la conception (mauvaise architecture) édifice chroniquement branlant surcoûts récurrents pour palier les défauts

8 Facteurs de qualité 8 de la conception / architecture (1) Correction aptitude à réaliser les tâches spécifiées Robustesse aptitude à fonctionner dans des conditions anormales Extensibilité aptitude à s'adapter aux changements de spécification Réutilisabilité aptitude à resservir dans de nouvelles applications

9 Facteurs de qualité 9 de la conception / architecture (2) Compatibilité aptitude à être combinée avec d'autres logiciels Efficacité bonne utilisation des ressources Portabilité facilité d'adaptation à différents environnements Vérifiabilité facilité à être vérifiée

10 Facteurs de qualité 10 de la conception / architecture (3) Sécurité... Intégrité : aptitude à protéger ses composants (y compris ses données) contre des modifications non autorisées Confidentialité : aptitude à masquer des informations privées (à des agents non autorisés)...

11 Facteurs de qualité 11 de la conception / architecture (4) Les facteurs de qualité s'excluent souvent mutuellement ex. : efficace vs. portable, sûr,... ex. : robuste vs. vérifiable faire des compromis

12 12 Quelques chiffres Bonne conception facilité de maintenance Coûts de maintenance : 42% modification des besoins utilisateur / solutions proposées 18% modification du format des données 13% correction d'erreurs en urgence 9% correction d'erreurs de routine 6% modification de matériel 5% documentation 4% amélioration de l'efficacité 3% autre

13 13 Facilité de maintenance Coût de maintenance principal = modification de spécification (60%) Pouvoir effectuer les modifications de manière aussi simple que possible Permettre et exploiter la traçabilité des spécifications Un outil méthodologique : la modularité

14 14 Plusieurs notions de module Module logique élément du découpage logique de la solution du problème Module de compilation/chargement bloc de code pouvant être compilé/chargé séparément ex. : fichier C (types, variables, fonctions), classe Java (champs, méthodes), script shell (variables, fonctions) Module du langage de programmation bloc de code nommé pouvant être utilisé (appelé,...) ex. : fonction, classe, fichier d'inclusion C (.h),...

15 15 Identifier des modules Objectif : forte cohésion à l'intérieur du module faible couplage entre les modules 30 nœuds, 66 arêtes 2,2 arêtes par nœud

16 16 Identifier des modules Objectif : forte cohésion à l'intérieur du module faible couplage entre les modules intra-module : 5 à 7 nœuds ; 2 arêtes / nœud inter-module : 5 modules ; 1,2 arêtes / module

17 17 Critères de modularité (comment analyser la modularité) Décomposabilité modulaire Composabilité modulaire Compréhensibilité modulaire Continuité modulaire Protection modulaire Pas toujours facile à satisfaire ( contre-exemples) être pragmatique, faire au mieux

18 Décomposabilité modulaire 18 Définition (critère de modularité) Le module découpe un problème complexe en problèmes plus petits, solubles isolément (décomposition souvent récursive) Exemple modules issus d'une conception descendante Contre-exemple module d'initialisation globale

19 Composabilité modulaire 19 Définition (critère de modularité) Les modules peuvent facilement être utilisés et combinés, éventuellement dans des contextes différents de ceux pour lesquels ils ont été initialement développés Exemple bibliothèque de sous-programmes

20 Compréhension modulaire 20 Définition (critère de modularité) La compréhension d'un module ne nécessite pas la compréhension des autres Contre-exemple dépendances séquentielles : modules conçus de façon à fonctionner dans un certain ordre ( peu recommandable)

21 Continuité modulaire 21 Définition (critère de modularité) Des petites modifications de spécification n'amènent pas à revoir l'ensemble du logiciel (~ extensibilité, évolutivité) Exemple constantes symboliques, références uniformes Contre-exemple utilisation de la représentation physique des données, de leur adresse mémoire,...

22 Protection modulaire 22 Définition (critère de modularité) Si une condition anormale se produit pendant l'exécution du module, elle reste localisée au module (ou à quelques modules voisins) Exemple validation des données d'entrées au plus tôt Contre-exemple exceptions inter-modules (lieu de traitement d'erreur séparé du lieu de production de l'erreur)

23 Principes de modularité 23 (règles à respecter) Unités modulaires du langage Contrôle des tailles Découpage logique Minimisation des interfaces Simplification des interfaces Interfaces explicites Masquage de l'information Pas toujours facile à satisfaire ( contre-exemples) être pragmatique, faire au mieux

24 Unités modulaires du langage 24 Principe (principe de modularité à respecter) module = unité syntaxique du langage bloc de code nommé pouvant être utilisé (appelé,...) modules compilables séparément prise en compte partielle du langage dès la conception Exemple classes Java, C++ ; fichier C Contre-exemple sous-programmes non compilables séparément

25 25 Contrôle des tailles (principe de modularité à respecter) Principe Un module ne doit être ni trop gros (sinon le découper en sous-modules) Exemple ni trop petit (sinon ça ne mérite pas d'être un module) trop gros : un unique module pour une API graphique trop petit : un module pour remettre un tableau à zéro Contre-exemple modules naturellement gros : lecture/écriture d'image, arithmétique entière en précision arbitraire,...

26 Découpage logique 26 Principe (principe de modularité à respecter) Un module doit autant que possible correspondre à un découpage logique du problème Ne pas découper arbitrairement un module sous prétexte qu'il est trop gros Exemple modules qui suivent un modèle conceptuel Contre-exemple cas de contraintes matérielles ou logicielles imposant un découpage en petites unités

27 Minimisation des interfaces 27 Principe (principe de modularité à respecter) Tout module doit communiquer avec aussi peu d'autres modules que possible S'il y a N modules, le nombre d'interconnexions doit être plus proche de N-1 que de N(N-1)/2 Critères protection, continuité

28 Simplification des interfaces 28 Principe (principe de modularité à respecter) Les modules doivent échanger aussi peu de données que possible Exemples faible nombre d'arguments des fonctions/méthodes transmission de pointeurs restreinte Contre-exemple variables globales Critères continuité, protection

29 Interfaces explicites 29 Principe (principe de modularité à respecter) Lorsque deux modules communiquent, cela doit se voir clairement dans le texte de l'un et/ou de l'autre Contre-exemple modules communicant par partage de données (ex. variables globales) sans communication apparente (ex. appel de procédure sans argument) Critères décomposabilité, composabilité

30 Masquage de l'information 30 Principe (principe de modularité à respecter) Toute information d'un module est privée, sauf son interface explicite Exemples en C : n'est visible à l'extérieur d'un fichier que ce qui est déclaré «extern» (variables, fonctions) Critères continuité (le contenu d'un module peut changer sans que les autres modules doivent être modifiés)

31 Et aussi (principes de modularité à respecter) Autres principes : Éviter (minimiser) les dépendances circulaires Éviter une trop grande profondeur d'appel Si possible, définir des modules à comportement prévisible (dépendant uniquement des entrées, sans mémorisation interne, sans état, déterministes)...

32 32 Modularité Comment effectuer un découpage en modules? (étant donnés les éléments d'un dossier d'analyse des besoins)

33 33 Approche fonctionnelle descendante À partir d'un graphe de flot de données, on dérive : une architecture modulaire un graphe d'appel ( ) Principe : concevoir les fonctions de haut niveau affiner jusqu'à obtenir une conception suffisamment détaillée

34 34 Graphe d'appel A y y z z B C D x u v w unité E F appel donnée transmise Attention : l'ordre des appels n'est pas représenté

35 35 Exemple : vérificateur d'orthographe Algorithme à implémenter : extraire tous les mots d'un document en faire un liste triée et sans doublons rechercher chaque mot de la liste dans le dictionnaire si le mot apparaît dans le dictionnaire, rien à faire sinon, demander à l'utilisateur si l'utilisateur décide que le mot est correct, il est entré dans le dictionnaire sinon il est inclus dans la liste résultante des mots mal orthographiés ( N.B. Il existe des méthodes bien plus efficaces!)

36 36 Diagramme de flot de données entrée utilisateur obtenir nom de fichier nom du document documents lire et séparer en mots liste de mots mots triés sans doublons trier, unifier entrée utilisateur dictionnaire rechercher nouveaux mots mots inconnus mots inconnus traiter mots inconnus faire confirmer réponse utilisateur mots mal orthographiés

37 Un exemple de graphe d'appel 37 (très plat) vérifier orthographe nom fichier mots mots triés mots inconnus mots inconnus réponse utilisateur obtenir nom de fichier lire et séparer en mots trier et unifier rechercher dans dico faire confirmer traiter mots inconnus

38 Un exemple de 38 (mauvais) graphe d'appel vérifier orthographe obtenir nom de fichier vérifier fichier lire et séparer en mots vérifier mots trier et unifier vérifier avec dico rechercher dans dico gérer mots inconnus faire confirmer traiter mots inconnus

39 Un autre exemple de 39 (mauvais) graphe d'appel vérifier orthographe trouver mots mal othographiés traiter mots inconnus trouver mots inconnus faire confirmer obtenir mots triés et unifiés rechercher dans dico obtenir mots trier et unifier obtenir nom de fichier lire et séparer en mots

40 Un autre exemple de (meilleur) 40 graphe d'appel mots vérifier orthographe mots mots inconnus mots inconnus obtenir mots nom fichier mots mots rechercher dans dico mots triés mots mots inconnus inconnus traiter mots inconnus réponse utilisateur nouveaux mots obtenir nom de fichier lire et séparer en mots trier et unifier compulser dico faire confirmer mettre à jour dico

41 Approches descendantes, 41 montantes, et réutilisation Approches descendantes (top-down) fournissent un découpage (au moins logique) d'un problème complexe mais ne se préoccupent pas de réutilisabilité (indépendance des parties découpées) Approches montantes (bottom-up) définition de composants simples et de leur composition plus grand souci de réutilisabilité pertinence incertaine : pas de garantie de l'existence d'un véritable besoin de réutilisation le convergence vers une solution du problème

42 42 Approche fonctionnelle descendante Il existe une méthode «mécanique» employée dans l'industrie Mais si employée trop mécaniquement : ignore types abstraits ( ) et masquage de l'information grande sensibilité aux petits changements difficile d'isoler des sous-systèmes communs difficile de réutiliser des composants disponibles... car trop détachée de la nature logique du programme

43 Critique de l'approche 43 fonctionnelle descendante Ce qui se passe souvent en pratique : on garde une décomposition vague espoir d'une clarification près des feuilles résolution du problème en même temps qu'est structurée la solution quand on s'approche des feuilles, on commence à ajouter plein de hacks ( ) pour que la décomposition tienne introduction d'un couplage fort (sensibilité au changement) échec possible

44 44 Méthodologie Garder l'esprit de l'analyse descendante concevoir les abstractions ( ) de haut niveau affiner jusqu'à une conception suffisamment détaillée Mais appliquer des heuristiques s'appuyer sur le modèle conceptuel découper en modules de même niveau d'abstraction veiller à respecter tous les principes de modularité Si de la réutilisabilité est recherchée combiner avec un peu d'approche montante

45 45 Les données d'abord Important résultat de l'expérience : Le plus souvent, il vaut mieux organiser un système autour des données qu'autour des fonctions Importance du lien avec le modèle conceptuel objets, attributs, opérations pour les manipuler Programmation orientée objet (OO)

46 46 (Parenthèse) Notions de programmation orientée objet ( ) idées les plus importantes exemples en Java comment faire de la programmation objet en C

47 47 Type abstrait (1) Un type déclaration/définition selon le langage ex. : interface Java, (pointeur vers) structure C Une interface déclaration de constantes d'un certain type et de fonctions (publiques) qui opèrent sur des objets de ce type ex. : interface Java, fichier d'inclusion «.h»

48 48 Type abstrait (2) Une (ou plusieurs) implémentation qui satisfait l'interface définition des constantes et fonctions (publiques) autres données et fonctions invisibles (privées) ex. : classe Java, fichier «.c» qui implémente «.h»

49 49 Type abstrait (3) Intérêt on peut modifier le contenu d'une implémentation sans changer ses utilisations (via l'interface) on peut remplacer une implémentation par une autre (par ex. plus efficace, suivant le contexte) = notion très importante en génie logiciel

50 Méthodes de conception 50 orientée objet Méthode de Booch (1986) : définir le problème ( ) développer une stratégie informelle de résolution identifier les objets et leurs attributs identifier les opérations sur ces objets établir les interfaces pour ces opérations implémenter les objets éventuellement répéter le processus récursivement

51 51 Définition du problème (méthode de Booch) Définir le problème en une seule phrase grammaticalement correcte ex. «compter les feuilles d'un arbre binaire complet» Se concentrer sur ce qui est vraiment important Ne pas essayer de résoudre le problème Éviter les phrases imprécises

52 52 Stratégie informelle (1) (méthode de Booch) Exprimer les éléments essentiels de la solution en un seul «paragraphe» grammaticalement correct (S'exprimer dans un langage compris de tous) (Pas plus de quelques heures) Ce travail doit être revu et corrigé

53 53 Stratégie informelle (2) (méthode de Booch) Compter les feuilles d'un arbre binaire complet : Maintenir une pile des parties d'arbre qui n'ont pas encore été comptées. Initialement obtenir un arbre et le mettre sur une pile vide ; le compteur de feuilles est initialisé à zéro. Tant que la pile n'est pas vide, enlever un arbre de la pile et l'examiner. Si l'arbre consiste en une seule feuille, incrémenter le compteur de feuilles et jeter cet arbre. Sinon, l'arbre possède deux sous-arbres ; séparer l'arbre en son sous-arbre droit et son sous-arbre gauche, et remettre ces arbres sur la pile. Une fois que la pile est vide, imprimer le compteur de feuilles.

54 54 Stratégie informelle (3) (méthode de Booch) Compter les feuilles d'un arbre binaire complet Maintenir une pile des parties d'arbre qui n'ont pas encore été comptées. Initialement obtenir un arbre et le mettre sur une pile vide ; le compteur de feuilles est initialisé à zéro. Tant que la pile n'est pas vide, enlever un arbre de la pile et l'examiner. Si l'arbre consiste en une seule feuille, incrémenter le compteur de feuilles et jeter cet arbre. Sinon, l'arbre possède deux sous-arbres ; séparer l'arbre en son sous-arbre droit et son sous-arbre gauche, et mettre ces arbres sur la pile. Une fois que la pile est vide, imprimer le compteur de feuilles.

55 55 Identification des objets et attributs (méthode de Booch) Souligner dans le texte les formes nominales ex., «la mise à jour des capteurs est effectuée chaque seconde» Éliminer les noms qui ne font pas partie du domaine de la solution ex. seconde Considérer comme opération les noms représentant une activité ex. mise à jour Les noms qui restent correspondent à des objets ex. capteur Regrouper les objets de même type Associer des identificateurs aux objets (conventions de nommage) Associer des attributs aux objets et aux types (adjectifs) ex., «les capteurs sont lus toutes les 100 ms» : fréquence de lecture

56 56 Isoler les noms et adjectifs (méthode de Booch) Compter les feuilles d'un arbre binaire complet Maintenir une pile des parties d'arbre qui n'ont pas encore été comptées. Initialement obtenir un arbre et le mettre sur une pile vide ; le compteur de feuilles est initialisé à zéro. Tant que la pile n'est pas vide, enlever un arbre de la pile et l'examiner. Si l'arbre consiste en une seule feuille, incrémenter le compteur de feuilles et jeter cet arbre. Sinon, l'arbre possède deux sous-arbres ; séparer l'arbre en son sous-arbre droit et son sous-arbre gauche, et mettre ces arbres sur la pile. Une fois que la pile est vide, imprimer le compteur de feuilles.

57 57 Identification des objets et attributs (méthode de Booch) Objets Noms : compteur de feuilles, pile, feuille, arbre, sous-arbre, partie d'arbre Objets : Attributs compteur_de_feuilles, pile, arbre Adjectifs : vide (pile), gauche (sous-arbre), droit (sous-arbre), seule (feuille) Attributs : pile : est_vide [ booléen] arbre : a_une_seule_feuille [ booléen], sous-arbre_gauche [ arbre], sous-arbre_droit [ arbre]

58 58 Identification des opérations (méthode de Booch) Souligner les formes verbales elles correspondent à des opérations (sauf être / avoir / appartenance attributs) Associer un identificateur à chaque opération convention de nommage Associer à chaque opération un objet ou un type (sur lequel elle est effectuée) ex. «mettre la chaîne de caractère dans la liste» : opération sur une liste, pas sur une chaîne ni sur un caractère Associer des conditions et attributs aux opérations en examinant les compléments et formes adverbiales ex., «déclencher l'alarme quand les valeurs sont trop hautes» Identifier les relations entre opérations ex., «allouer un buffer à l'ouverture d'un fichier»

59 59 Isoler les formes verbales (méthode de Booch) Compter les feuilles d'un arbre binaire complet Maintenir une pile des parties d'arbre qui n'ont pas encore été comptées. Initialement obtenir un arbre et le mettre sur une pile vide ; le compteur de feuilles est initialisé à zéro. Tant que la pile n'est pas vide, enlever un arbre de la pile et l'examiner. Si l'arbre consiste en une seule feuille, incrémenter le compteur de feuilles et jeter cet arbre. Sinon, l'arbre possède deux sous-arbres ; séparer l'arbre en son sous-arbre droit et son sous-arbre gauche, et mettre ces arbres sur la pile. Une fois que la pile est vide, imprimer le compteur de feuilles.

60 60 Identification des opérations (méthode de Booch) Opérations Verbes : initialement obtenir (un arbre), mettre sur (la pile), initialiser à zéro (le compteur), enlever (un arbre de la pile), examiner (un arbre), incrémenter (le compteur), jeter (arbre), séparer (arbre) consister en (une seule feuille), posséder (deux sous-arbres) Opérations pile : empiler (arbre), dépiler (arbre) compteur_de_feuilles : initialiser_à_zéro, incrémenter, imprimer Attributs (rappel) pile : est_vide [ booléen] arbre : a_une_seule_feuille [ booléen], sous-arbre_gauche [ arbre], sous-arbre_droit [ arbre]

61 61 Spécification et regroupement (méthode de Booch) Définir les spécifications des types, objets et opérations visibles Déterminer les dépendances et l'imbrication des unités (ex. objets inclus dans d'autres) Identifier les regroupements possibles (ex. opérations sur un même type d'objet) Rechercher l'héritage (objets et types d'objets admettant plus ou moins d'opérations) et la généricité (parties communes des objets et opérations, et parties variables paramétrables)

62 62 Analyse et clarification (méthode de Booch) Examiner les variantes possibles (identifications, regroupements) Expliquer les choix de conception Donner toutes les indications nécessaires à la réalisation

63 63 Autres méthodes... (non détaillées ici) Merise (MCD) HOOD (Hierarchical Object Oriented Design) Modèles à trois plans : (plans structure, communication, comportement) (vue temps-contrôle, vue fonctionnelle, vue données) OMT OOA-OOD Shlaer et Mellor

64 Remarques sur la phase de 64 conception Analyse des besoins et conception sont étroitement mêlées point de départ : formulation du problème élaboration/formulation d'une solution structuration logicielle de cette solution C'est le cas également avec UML ( )

65 65 UML Langage de modélisation UML = Unified Modeling Language notations normalisées Pour la résolution de problèmes orientée objet Mais c'est une notation, pas une méthode!

66 66 Modèle Modèle = abstraction du problème sous-jacent objets qui interagissent par envoi de messages attributs des objets (valeurs état de l'objet) opérations/comportements des objets objets de mêmes type = instances d'une classe

67 67 (Principaux) diagrammes UML Diagramme de cas d'utilisation (use case) Diagramme de classe Diagramme d'objet Diagramme de séquence Diagramme de collaboration Diagramme d'états (statechart) Diagramme d'activité Diagramme de composants Diagramme de déploiement

68 68 Diagramme de cas d'utilisation (1) ~ Scénario Ce que le système fait, vu de l'extérieur Le «quoi», pas le «comment» (d'après Borland) Ex. : prise de rendez-vous à la clinique

69 69 Diagramme de cas d'utilisation (2) (d'après Borland)

70 70 Diagramme de cas d'utilisation (3) Expression de besoins/exigences [angl. requirements] nouveau cas d'utilisation nouvelles exigences Communication aisée avec le client simplicité de notation Génération de tests ensemble de scénarios ensemble de cas de test

71 71 Diagramme de classe (1) Aperçu du système classes et relations entre elles Vue statique existence d'interactions mais pas d'information sur le comportement effectif

72 72 Diagramme de classe (2) (d'après Borland) Ex. : commande client pour une vente au détail aggregation

73 73 Diagramme de package (d'après Borland) Package = collection d'éléments reliés logiquement

74 74 Diagramme d'objets (1) (d'après Borland) Montre les instances et non les classes Utile pour expliquer les relations récursives Ex. : département d'université pouvant comporter des (sous-(sous-))départements diagramme de classe :

75 75 Diagramme d'objets (2) (d'après Borland) Instantiation du diagramme de classe précédent

76 76 Diagramme de séquence (1) Diagramme d'interaction : vue dynamique comment les objets collaborent entre eux Déroulement des opérations quelles opérations et quand Ex. : réservation d'une chambre d'hôtel ( )

77 77 Diagramme de séquence (2) (d'après Borland)

78 78 Diagramme de collaboration (1) Diagramme d'interaction : vue dynamique comment les objets collaborent entre eux Focalisation sur le rôle des objets (pas sur le temps ou l'ordre) Ex. : réservation d'une chambre d'hôtel ( )

79 79 Diagramme de collaboration (2) (d'après Borland)

80 80 Diagramme d'état (1) Vue du comportement et des états des objets états, et transitions qui créent des changements d'état = diagramme états-transitions vu précédemment (cf. cours sur l'analyse des besoins) Ex. : login sur un système bancaire entrée du numéro de sécurité sociale (SSN) [Social Security Number] numéro d'identification (code PIN) [Personal Identification Number]

81 81 Diagramme d'état (2) (d'après Borland)

82 82 Diagramme d'activité (1) Flot d'activité d'un processus (et non d'un objet) fork et join Dépendances entre activités Ex. retrait d'argent dans un distributeur

83 83 Diagramme d'activité (2) (d'après Borland)

84 84 Diagramme de déploiement (1) Configuration physique logicielle et matérielle Ex. : transaction immobilière

85 85 Diagramme de déploiement (2) (d'après Borland)

86 86 UML et précision Tous les niveaux de formalisation : informel : cas d'utilisation semi-formel : modèles statiques et dynamiques formel : OCL (object constraint language)

87 87 UML et cycle de vie Définition des besoins : diagramme de cas d'utilisation Analyse des besoins diagrammes d'état, d'activité Conception diagrammes d'état, d'activité diagrammes de classe, d'objet, de package diagrammes de séquence, de collaboration diagrammes de déploiement

88 88 À retenir Conception séparation des problèmes / décomposition modulaire Méthodologie globalement descendante, parfois montante Principes de modularité à respecter découpage logique ; taille équilibrée ; masquage de l'information ; interface minimale, simple et explicite Organiser le système autour des données (!) Notion de type abstrait UML : notations normalisées, vues différentes

Modélisation Principe Autre principe

Modélisation Principe Autre principe Modélisation Principe : un modèle est une abstraction permettant de mieux comprendre un objet complexe (bâtiment, économie, atmosphère, cellule, logiciel, ). Autre principe : un petit dessin vaut mieux

Plus en détail

Positionnement de UP

Positionnement de UP UNIFIED PROCESS Positionnement de UP Unified Process Langage Méthode Outil logiciel UML UP RUP 6 BONNES PRATIQUES développement itératif gestion des exigences architecture basée sur des composants modélisation

Plus en détail

Modélisation Orientée Objet / UML

Modélisation Orientée Objet / UML Modélisation Orientée Objet / UML Laurent Henocque http://laurent.henocque.free.fr/ Enseignant Chercheur ESIL/INFO France http://laurent.henocque.perso.esil.univmed.fr/ mis à jour en Octobre 2006 Licence

Plus en détail

Chapitre I : le langage UML et le processus unifié

Chapitre I : le langage UML et le processus unifié I. Introduction Les méthodes d analyse orientées objet sont initialement issues des milieux industriels. La préoccupation dominante de leurs auteurs est le génie logiciel, c est-àdire les principes et

Plus en détail

Analyse,, Conception des Systèmes Informatiques

Analyse,, Conception des Systèmes Informatiques Analyse,, Conception des Systèmes Informatiques Méthode Analyse Conception Introduction à UML Génie logiciel Définition «Ensemble de méthodes, techniques et outils pour la production et la maintenance

Plus en détail

Université de Bangui. Modélisons en UML

Université de Bangui. Modélisons en UML Université de Bangui CRM Modélisons en UML Ce cours a été possible grâce à l initiative d Apollinaire MOLAYE qui m a contacté pour vous faire bénéficier de mes connaissances en nouvelles technologies et

Plus en détail

Programmabilité du réseau avec l'infrastructure axée sur les applications (ACI) de Cisco

Programmabilité du réseau avec l'infrastructure axée sur les applications (ACI) de Cisco Livre blanc Programmabilité du réseau avec l'infrastructure axée sur les applications (ACI) de Cisco Présentation Ce document examine la prise en charge de la programmabilité sur l'infrastructure axée

Plus en détail

Un peu d'organisation. Conception et Programmation par Objets HLIN406. Sommaire. Pourquoi vous parler de conception par objets? Notion de modélisation

Un peu d'organisation. Conception et Programmation par Objets HLIN406. Sommaire. Pourquoi vous parler de conception par objets? Notion de modélisation Un peu d'organisation Conception et Programmation par Objets HLIN406 Marianne Huchard, Clémentine Nebut LIRMM / Université de Montpellier 2 Premières semaines Contrôle des connaissances Supports 2015 Sommaire

Plus en détail

MÉTHODOLOGIES DE CONCEPTION ET NOTATION GRAPHIQUE

MÉTHODOLOGIES DE CONCEPTION ET NOTATION GRAPHIQUE MÉTHODOLOGIES DE CONCEPTION ET NOTATION GRAPHIQUE m Notations : diagrammes m Diagrammes de transition d'états m Méthodes d'analyse de flot de m Conventions pour diagrammes données objet m Diagrammes de

Plus en détail

IFT2255 : Génie logiciel

IFT2255 : Génie logiciel IFT2255 : Génie logiciel Chapitre 6 - Analyse orientée objets Section 1. Introduction à UML Julie Vachon et Houari Sahraoui 6.1. Introduction à UML 1. Vers une approche orientée objet 2. Introduction ti

Plus en détail

Cours de Génie Logiciel

Cours de Génie Logiciel Cours de Génie Logiciel Sciences-U Lyon Diagrammes UML (2) http://www.rzo.free.fr Pierre PARREND 1 Avril 2005 Sommaire Les Diagrammes UML Diagrammes de Collaboration Diagrammes d'etats-transitions Diagrammes

Plus en détail

Architecture Logicielle

Architecture Logicielle Architecture Logicielle Chapitre 3: UML pour la description et la documentation d une architecture logicielle Année universitaire 2013/2014 Semestre 1 Rappel L architecture d un programme ou d un système

Plus en détail

Processus de développement UP

Processus de développement UP Chapitre 1 Processus de développement UP I. Pourquoi UP? II. Définition III. Activités et phases IV. Modèles mis en place 1. Pourquoi UP? Les notions de base acquises dans le module ACOO1, notamment la

Plus en détail

Le génie Logiciel (suite)

Le génie Logiciel (suite) Le génie Logiciel (suite) Lors du cours précédent, on a étudié différents cycles de vie, dont la cascade, ou la spirale. Analyse des besoins L analyse des besoins est une étape menant à l élaboration de

Plus en détail

Modèle d implémentation

Modèle d implémentation Modèle d implémentation Les packages UML: Unified modeling Language Leçon 5/6-9-16/10/2008 Les packages - Modèle d implémentation - Méthodologie (RUP) Un package ou sous-système est un regroupement logique

Plus en détail

IFT2251 : Génie logiciel

IFT2251 : Génie logiciel 4.1. Introduction à UML IFT2251 : Génie logiciel 1. Approches de développement 2. Introduction à UML (une méthodologie basée sur l approche orientée aspect) 3. Rappel de quelques concepts objets Chapitre

Plus en détail

Yannick Prié UFR Informatique Université Claude Bernard Lyon 1 M1 MIAGE SIMA / M1 Informatique MIF17 2008 2009

Yannick Prié UFR Informatique Université Claude Bernard Lyon 1 M1 MIAGE SIMA / M1 Informatique MIF17 2008 2009 Yannick Prié UFR Informatique Université Claude Bernard Lyon 1 M1 MIAGE SIMA / M1 Informatique MIF17 2008 2009 Notion de méthode de conception de SI Méthodes OO de conception Généralités sur les méthodes

Plus en détail

Fonctionnement du serveur Z39.50

Fonctionnement du serveur Z39.50 Fonctionnement du serveur Z39.50 Table des matières 1 Configuration du serveur...2 1.1 Comportement du serveur...2 1.2 Configuration de la traduction z39.50 -> base de données...2 1.3 Configuration du

Plus en détail

Description et illustration du processus unifié

Description et illustration du processus unifié USDP Description et illustration du processus unifié Définit un enchaînement d activités Est réalisé par un ensemble de travailleurs Avec des rôles, des métiers Avec pour objectifs de passer des besoins

Plus en détail

Génie logiciel. Concepts fondamentaux. Bruno MERMET, Université du Havre 1

Génie logiciel. Concepts fondamentaux. Bruno MERMET, Université du Havre 1 Génie logiciel Concepts fondamentaux Bruno MERMET, Université du Havre 1 Nécessité du Génie Logiciel Bruno MERMET, Université du Havre 2 Développement d un logiciel Caractéristiques souhaitées : Adéquation

Plus en détail

UML (Paquetage) Unified Modeling Language

UML (Paquetage) Unified Modeling Language UML (Paquetage) Unified Modeling Language Sommaire Introduction Objectifs Paquetage Espace de nommage d un paquetage Dépendances entre paquetages 2 Notion introduite véritablement par UML car superficiellement

Plus en détail

Programme de la licence informatique, université de Caen http://www.info.unicaen.fr

Programme de la licence informatique, université de Caen http://www.info.unicaen.fr Programme de la licence informatique, université de Caen http://www.info.unicaen.fr Unité Systèmes d'information CM : 45h - TD : 60h - TP : 12h - Coeff 2 Systèmes de Gestion de Bases de Données Modéliser

Plus en détail

Cycle de vie du logiciel. Unified Modeling Language UML. UML: définition. Développement Logiciel. Salima Hassas. Unified Modeling Language

Cycle de vie du logiciel. Unified Modeling Language UML. UML: définition. Développement Logiciel. Salima Hassas. Unified Modeling Language Unified Modeling Language UML Salima Hassas Version Cycle de vie du logiciel Client Besoins Déploiement Analyse Test Conception Cours sur la base des transparents de : Gioavanna Di Marzo Serugendo et Frédéric

Plus en détail

Présentation générale de la méthode orientée objet : O.M.T. (Rumbaugh & al.)

Présentation générale de la méthode orientée objet : O.M.T. (Rumbaugh & al.) Présentation générale de la méthode orientée objet : O.M.T. (Rumbaugh & al.) Bernard ESPINASSE Professeur à l'université d'aix-marseille Plan Introduction Les modèles d'omt Le Modèle Objet (MO) Le Modèle

Plus en détail

Génie logiciel avancé

Génie logiciel avancé Université Paris-Sud L3 MIAGE apprentissage Année 2014-2015 Génie logiciel avancé Introduction Delphine Longuet delphine.longuet@lri.fr Logiciel : définitions Ensemble d'entités nécessaires au fonctionnement

Plus en détail

basée sur le cours de Bertrand Legal, maître de conférences à l ENSEIRB www.enseirb.fr/~legal Olivier Augereau Formation UML

basée sur le cours de Bertrand Legal, maître de conférences à l ENSEIRB www.enseirb.fr/~legal Olivier Augereau Formation UML basée sur le cours de Bertrand Legal, maître de conférences à l ENSEIRB www.enseirb.fr/~legal Olivier Augereau Formation UML http://olivier-augereau.com Sommaire Introduction I) Les bases II) Les diagrammes

Plus en détail

Machine de Turing. Informatique II Algorithmique 1

Machine de Turing. Informatique II Algorithmique 1 Machine de Turing Nous avons vu qu un programme peut être considéré comme la décomposition de la tâche à réaliser en une séquence d instructions élémentaires (manipulant des données élémentaires) compréhensibles

Plus en détail

Méthodes fonctionnelles : SADT

Méthodes fonctionnelles : SADT Méthodes fonctionnelles : SADT Bernard ESPINASSE Professeur à l'université d'aix-marseille Plan Introduction Principes de base Représentations graphiques Actigrammes & Datagrammes Conventions simplificatrices

Plus en détail

Projet : Plan Assurance Qualité

Projet : Plan Assurance Qualité Projet : Document : Plan Assurance Qualité 2UP_SPEC_DEV1 VERSION 1.00 Objet Ce document a pour objectif de définir la démarche d analyse et de conception objet ainsi les activités liées. Auteur Eric PAPET

Plus en détail

1. Les fondements de l informatique 13

1. Les fondements de l informatique 13 Introduction à l'algorithmique 1. Les fondements de l informatique 13 1.1 Architecture de Von Neumann 13 1.2 La machine de Turing 17 1.3 Représentation interne des instructions et des données 19 1.3.1

Plus en détail

Éléments d UML pour le projet (Unified Modeling Language)

Éléments d UML pour le projet (Unified Modeling Language) Éléments d UML pour le projet (Unified Modeling Language) C Crochepeyre UML 1 PLAN 1. Introduction 2. Préliminaires 3. Les règles UML 4. Les diagrammes UML 5. Outils de modélisation UML 6. L étude préalable

Plus en détail

Conception, architecture et urbanisation des systèmes d information

Conception, architecture et urbanisation des systèmes d information Conception, architecture et urbanisation des systèmes d information S. Servigne Maître de Conférences, LIRIS, INSA-Lyon, F-69621 Villeurbanne Cedex e-mail: sylvie.servigne@insa-lyon.fr 1. Introduction

Plus en détail

Introduction à la conception d'une base de données Walter RUDAMETKIN

Introduction à la conception d'une base de données Walter RUDAMETKIN Introduction à la conception d'une base de données Walter RUDAMETKIN Bureau F011 Walter.Rudametkin@polytech-lille.fr Étapes de la conception d'une base de données Analyse de la situation existante et des

Plus en détail

Figure 1. Structure répartie

Figure 1. Structure répartie Chapitre I: Applications Réparties et Middleware 1. Définition d une application répartie Une application répartie est constituée d un ensemble de processus (d objets, d agents, d acteurs) s exécutant

Plus en détail

Algorithmique - Techniques fondamentales de programmation Exemples en Python (nombreux exercices corrigés) - BTS, DUT informatique

Algorithmique - Techniques fondamentales de programmation Exemples en Python (nombreux exercices corrigés) - BTS, DUT informatique Introduction à l'algorithmique 1. Les fondements de l informatique 13 1.1 Architecture de Von Neumann 13 1.2 La machine de Turing 17 1.3 Représentation interne des instructions et des données 19 1.3.1

Plus en détail

SGBDR et conception d'un système d'information avec MERISE

SGBDR et conception d'un système d'information avec MERISE 1 SGBDR et conception d'un système d'information avec MERISE Séminaires Codes & Travaux @ IRISA 26 Avril 2007 Anthony ASSI Ingénieur Expert R&D Plateforme Bio Informatique / Equipe Symbiose 2 SGBDR : Système

Plus en détail

3. SPÉCIFICATIONS DU LOGICIEL. de l'expression des besoins à la conception. Spécifications fonctionnelles Analyse fonctionnelle et méthodes

3. SPÉCIFICATIONS DU LOGICIEL. de l'expression des besoins à la conception. Spécifications fonctionnelles Analyse fonctionnelle et méthodes PLAN CYCLE DE VIE D'UN LOGICIEL EXPRESSION DES BESOINS SPÉCIFICATIONS DU LOGICIEL CONCEPTION DU LOGICIEL LA PROGRAMMATION TESTS ET MISE AU POINT DOCUMENTATION CONCLUSION C.Crochepeyre Génie Logiciel Diapason

Plus en détail

Architecture d'entreprise : Guide Pratique de l'architecture Logique

Architecture d'entreprise : Guide Pratique de l'architecture Logique Guides Pratiques Objecteering Architecture d'entreprise : Guide Pratique de l'architecture Logique Auteur : Version : 1.0 Copyright : Softeam Equipe Conseil Softeam Supervisée par Philippe Desfray Softeam

Plus en détail

Les formations. Développeur Logiciel. ENI Ecole Informatique

Les formations. Développeur Logiciel. ENI Ecole Informatique page 1/8 Titre professionnel : Inscrit au RNCP de Niveau III (Bac + 2) (J.O. du 19/02/13) 24 semaines + 8 semaines de stage (uniquement en formation continue) Développer une application orientée objet

Plus en détail

GÉNIE LOGICIEL (SOFTWARE ENGINEERING)

GÉNIE LOGICIEL (SOFTWARE ENGINEERING) GÉNIE LOGICIEL (SOFTWARE ENGINEERING) 5ÈME PARTIE UML (UNIFIED MODELING LANGUAGE) Faculté des Sciences et Techniques http://labh-curien.univ-st-etienne.fr/~fj/gl Francois.Jacquenet@univ-st-etienne.fr Plan

Plus en détail

ISTA H.H www.developpez.c.la Diagramme d activité SOMMAIRE

ISTA H.H www.developpez.c.la Diagramme d activité SOMMAIRE SOMMAIRE I. Définition... 2 II. Intérêts des diagrammes d activité... 5 III. Quand employer le diagramme d activité?... 5 IV. Avantage et Inconvénient... 6 V. Les étapes de constructions... 7 VI. Comment

Plus en détail

TP n 2 Concepts de la programmation Objets Master 1 mention IL, semestre 2 Le type Abstrait Pile

TP n 2 Concepts de la programmation Objets Master 1 mention IL, semestre 2 Le type Abstrait Pile TP n 2 Concepts de la programmation Objets Master 1 mention IL, semestre 2 Le type Abstrait Pile Dans ce TP, vous apprendrez à définir le type abstrait Pile, à le programmer en Java à l aide d une interface

Plus en détail

Mongi TRIKI Docteur en Informatique Université Paris Dauphine

Mongi TRIKI Docteur en Informatique Université Paris Dauphine Université Méditerranéenne Libre de Tunis Faculté Méditerranéenne Privée des Sciences Informatiques, Economiques et de Gestion de Tunis Département d Informatique LICENCE INFORMATIQUE Guide du Stagiaire

Plus en détail

Les diagrammes de modélisation

Les diagrammes de modélisation L approche Orientée Objet et UML 1 Plan du cours Introduction au Génie Logiciel L approche Orientée Objet et Notation UML Les diagrammes de modélisation Relations entre les différents diagrammes De l analyse

Plus en détail

Le génie logiciel. maintenance de logiciels.

Le génie logiciel. maintenance de logiciels. Le génie logiciel Définition de l IEEE (IEEE 1990): L application d une approche systématique, disciplinée et quantifiable pour le développement, l opération et la maintenance de logiciels. Introduction

Plus en détail

Gestion de Projet. Génie Logiciel. Renaud Marlet. LaBRI / INRIA. http://www.labri.fr/~marlet. (d'après A.-M. Hugues) màj 19/04/2007

Gestion de Projet. Génie Logiciel. Renaud Marlet. LaBRI / INRIA. http://www.labri.fr/~marlet. (d'après A.-M. Hugues) màj 19/04/2007 1 Génie Logiciel (d'après A.-M. Hugues) Gestion de Projet Renaud Marlet LaBRI / INRIA http://www.labri.fr/~marlet màj 19/0/007 Est-ce bien nécessaire? Principes de gestion = beaucoup d'évidences Pourtant

Plus en détail

Environnements de Développement

Environnements de Développement Institut Supérieur des Etudes Technologiques de Mahdia Unité d Enseignement: Environnements de Développement Mme BEN ABDELJELIL HASSINE Mouna m.bnaj@yahoo.fr Développement des systèmes d Information Syllabus

Plus en détail

Direction Générale des Études Technologiques. Institut Supérieur des Etudes Technologiques de Djerba Département Technologies de l informatique

Direction Générale des Études Technologiques. Institut Supérieur des Etudes Technologiques de Djerba Département Technologies de l informatique Direction Générale des Études Technologiques Institut Supérieur des Etudes Technologiques de Djerba Département Technologies de l informatique Génie Logiciel Mejdi BLAGHGI m.blaghgi@gmail.com Chapitre

Plus en détail

0- Le langage C++ 1- Du langage C au langage C++ 2- Quelques éléments sur le langage. 3- Organisation du cours

0- Le langage C++ 1- Du langage C au langage C++ 2- Quelques éléments sur le langage. 3- Organisation du cours 0- Le langage C++ 1- Du langage C au langage C++ 2- Quelques éléments sur le langage 3- Organisation du cours Le présent cours constitue une introduction pour situer le langage C++, beaucoup des concepts

Plus en détail

CONCEPTS ET MISE EN PRATIQUE POUR LA VALIDATION DE GRANDS SYSTÈMES

CONCEPTS ET MISE EN PRATIQUE POUR LA VALIDATION DE GRANDS SYSTÈMES MODEL-BASED TESTING (MBT) CONCEPTS ET MISE EN PRATIQUE POUR LA VALIDATION DE GRANDS SYSTÈMES Le Model-Based Testing est une pratique de test en plein développement dans l'industrie pour accroitre l'efficacité

Plus en détail

C++ COURS N 2 : CLASSES, DONNÉES ET FONCTIONS MEMBRES Classes et objets en C++ Membres d'une classe Spécification d'une classe Codage du comportement

C++ COURS N 2 : CLASSES, DONNÉES ET FONCTIONS MEMBRES Classes et objets en C++ Membres d'une classe Spécification d'une classe Codage du comportement C++ COURS N 2 : CLASSES, DONNÉES ET FONCTIONS MEMBRES Classes et objets en C++ Membres d'une classe Spécification d'une classe Codage du comportement des objets d'une classe Utilisation d'une classe Droit

Plus en détail

PASCAL ROQUES. UML par. la pratique. Groupe Eyrolles, 2001, 2002, 2004, 2005, 2006, 2009. ISBN : 978-2-212-12508-5

PASCAL ROQUES. UML par. la pratique. Groupe Eyrolles, 2001, 2002, 2004, 2005, 2006, 2009. ISBN : 978-2-212-12508-5 est f o E Y R O L L E S PASCAL ROQUES UML par la pratique Groupe Eyrolles, 2001, 2002, 2004, 2005, 2006, 2009. ISBN : 978-2-212-12508-5 Sommaire Introduction 9 Objectifs du livre... 9 Structure de l ouvrage...

Plus en détail

Présentation du projet:

Présentation du projet: : Le but du projet est de réaliser le fonctionnement d'un jeu d échec valide. Plus spécifiquement, il consiste à implémenter l'organisation générale du jeu, et le suivi des règles du mouvement des pièces.

Plus en détail

Développement itératif, évolutif et agile

Développement itératif, évolutif et agile Document Développement itératif, évolutif et agile Auteur Nicoleta SERGI Version 1.0 Date de sortie 23/11/2007 1. Processus Unifié Développement itératif, évolutif et agile Contrairement au cycle de vie

Plus en détail

Structures de données non linéaires

Structures de données non linéaires Structures de données non linéaires I. Graphes Définition Un graphe (simple) orienté G est un couple (S, A), où : S est un ensemble dont les éléments sont appelés les sommets. A est un ensemble de couples

Plus en détail

Cours de Génie Logiciel

Cours de Génie Logiciel Cours de Génie Logiciel Sciences-U Lyon MDE Model Driven Engineering http://www.rzo.free.fr Pierre PARREND 1 Mai 2005 Sommaire MDE : principe MDE et le génie logiciel MDE et UML MDE et les Design Patterns

Plus en détail

Introduction au développement du logiciel

Introduction au développement du logiciel Introduction au développement du logiciel Vers le génie logiciel Université de Nantes Master Miage M1 Plan 1 Introduction 2 Génie logiciel 3 Projet informatique 4 Méthode de développement 5 Qualité Bibliographie

Plus en détail

MODELISATION UN ATELIER DE MODELISATION «RATIONAL ROSE»

MODELISATION UN ATELIER DE MODELISATION «RATIONAL ROSE» MODELISATION UN ATELIER DE MODELISATION «RATIONAL ROSE» Du cours Modélisation Semi -Formelle de Système d Information Du Professeur Jean-Pierre GIRAUDIN Décembre. 2002 1 Table de matière Partie 1...2 1.1

Plus en détail

IFT2251 : Génie logiciel

IFT2251 : Génie logiciel Julie Vachon, Hiver 2006 IFT2251 : Génie logiciel Chapitre 5. Conception Section 3. Principes et qualités Conception : principes et qualités 1. L activité de conception 2. Principes de conception 3. Concevoir

Plus en détail

Diagrammes de classe UML

Diagrammes de classe UML labsticc.univ-brest.fr/pages_perso/babau/ Diagrammes de classe UML Jean-Philippe Babau Département Informatique, UFR Sciences, Laboratoire Lab-STICC 2 1 Plan Introduction aux diagrammes de classe Description

Plus en détail

LES INTERFACES HOMME-MACHINE

LES INTERFACES HOMME-MACHINE LES INTERFACES HOMME-MACHINE 1 ère Partie : Introduction aux Interfaces Homme-Machine 2 ème Partie : Notions de base sur les Sciences Cognitives 3 ème Partie : Recommandations ergonomiques 4 ème Partie

Plus en détail

Programmation Orientée Objet. Ecrire beaucoup de lignes de code, même très propres, ne suffit pas

Programmation Orientée Objet. Ecrire beaucoup de lignes de code, même très propres, ne suffit pas 2 Modélisation Construire un bon logiciel : Répondre aux objectifs fixés (satisfaire le client) Avoir une base architecturale solide qui permette l évolution Mettre en place un processus de développement

Plus en détail

Thèmes. Modélisation d applications industrielles avec UML. Motivations à l origine d UML. Introduction au formalisme UML.

Thèmes. Modélisation d applications industrielles avec UML. Motivations à l origine d UML. Introduction au formalisme UML. Modélisation d applications industrielles avec UML ACOO Analyse, Conception et développement Orientés Objet de logiciels de commande Thèmes Motivations à l origine d UML. Introduction au formalisme UML.

Plus en détail

Algorithmique et programmation. Cours d'algorithmique illustré par des exemples pour le picbasic

Algorithmique et programmation. Cours d'algorithmique illustré par des exemples pour le picbasic Algorithmique et programmation Cours d'algorithmique illustré par des exemples pour le picbasic Même s'il est possible d'écrire un programme petit à petit par touches successives, le résultat est souvent

Plus en détail

PRINCIPES et METHODES de SPECIFICATION et de CONCEPTION GLOBALE des SYSTEMES INFORMATISES 10/20/02 1

PRINCIPES et METHODES de SPECIFICATION et de CONCEPTION GLOBALE des SYSTEMES INFORMATISES 10/20/02 1 PRINCIPES et METHODES de SPECIFICATION et de CONCEPTION GLOBALE des SYSTEMES INFORMATISES 10/20/02 1 CYCLE de VIE des SYSTEMES INFORMATISES Expression du besoin Développement du «système» Exploitation

Plus en détail

Introduction au génie logiciel

Introduction au génie logiciel Introduction au génie logiciel Guillaume Laurent ENSMM 2007 G. Laurent (ENSMM) Introduction au génie logiciel 2007 1 / 36 Plan du cours 1 Problématique du génie logiciel 2 Méthodes de développement logiciel

Plus en détail

UML Diagramme de classes (class diagram) pour le recueil et l analyse des besoins. Emmanuel Pichon 2013 V1.1

UML Diagramme de classes (class diagram) pour le recueil et l analyse des besoins. Emmanuel Pichon 2013 V1.1 UML Diagramme de classes (class diagram) pour le recueil et l analyse des besoins 2013 V1.1 Objectif Diagramme de classes (class diagram) pour le recueil des besoins et l analyse Présenter un ensemble

Plus en détail

Nom de l application

Nom de l application Ministère de l Enseignement Supérieur et de la Recherche Scientifique Direction Générale des Etudes Technologiques Institut Supérieur des Etudes Technologiques de Gafsa Département Technologies de l Informatique

Plus en détail

1. Introduction. 2. Diagramme des exigences

1. Introduction. 2. Diagramme des exigences 1. Introduction La complexité des systèmes techniques est telle que, sans outils de représentations abstraites et progressivement enrichies, les intervenants d un projet auraient de nombreuses difficultés

Plus en détail

Méthodes de développement. Analyse des exigences (spécification)

Méthodes de développement. Analyse des exigences (spécification) 1 / 16 Méthodes de développement Analyse des exigences (spécification) 1 -Objectifs de l'analyse des exigences... 2 2 - Approfondissement et formalisation du besoin... 2 2.1 Séparation des besoins, contraintes

Plus en détail

Introduction pratique au Développement orienté Modèle Pierre Parrend, Mars 2005

Introduction pratique au Développement orienté Modèle Pierre Parrend, Mars 2005 MDA : Un Tutoriel Introduction pratique au Développement orienté Modèle Pierre Parrend, Mars 2005 1 Sommaire Table des matières 1 Sommaire 1 2 Introduction 2 2.1 A qui s adresse ce tutoriel......................

Plus en détail

Analyse et conception d un modèle de qualité logicielle

Analyse et conception d un modèle de qualité logicielle Analyse et conception d un modèle de qualité logicielle Karine Mordal Thèse dirigée par Françoise Balmas Laboratoire LIASD, Université Paris 8 3 Décembre 2012 Les projets de recherche Le contexte Le projet

Plus en détail

Rational Unified Process

Rational Unified Process Rational Unified Process Hafedh Mili Rational Unified Process 1. Principes de base 2. Les phases 3. Les activités (workflows) Copyright Hafedh Mili 2005 2 1 Rational Unified Process Processus de développement

Plus en détail

GPA 789 : Analyse et Conception Orientées Objet. ETS Mickaël Gardoni Bureau A 3588 tel 84 11. Mise en Œuvre UML version du 24 avril 2009

GPA 789 : Analyse et Conception Orientées Objet. ETS Mickaël Gardoni Bureau A 3588 tel 84 11. Mise en Œuvre UML version du 24 avril 2009 GPA 789 : Analyse et Conception Orientées Objet ETS Mickaël Gardoni Bureau A 3588 tel 84 11 Mise en œuvre UML 1/ 25 Introduction Mise en œuvre d UML UML n est pas une méthode 2/ 25 1 UML n est qu un langage

Plus en détail

Algorithmique et Analyse d Algorithmes

Algorithmique et Analyse d Algorithmes Algorithmique et Analyse d Algorithmes L3 Info Cours 5 : Structures de données linéaires Benjamin Wack 2015-2016 1 / 37 La dernière fois Logique de Hoare Dichotomie Aujourd hui Type Abstrait de Données

Plus en détail

Système. Introduction aux systèmes informatiques

Système. Introduction aux systèmes informatiques Introduction aux systèmes informatiques Système Un système est une collection organisée d'objets qui interagissent pour former un tout Objets = composants du système Des interconnexions (liens) entre les

Plus en détail

Unité de formation 1 : Structurer une application. Durée : 3 semaines

Unité de formation 1 : Structurer une application. Durée : 3 semaines PROGRAMME «DEVELOPPEUR LOGICIEL» Titre professionnel : «Développeur Logiciel» Inscrit au RNCP de niveau III (Bac+2) (JO du 23 Octobre 2007) (32 semaines) Unité de formation 1 : Structurer une application

Plus en détail

pedigree d'un cheval Zoe ; son père est Tonnerre et sa mère Belle ; mère de Belle est Rose et père de Belle est Eclair jean jean marc paul luc

pedigree d'un cheval Zoe ; son père est Tonnerre et sa mère Belle ; mère de Belle est Rose et père de Belle est Eclair jean jean marc paul luc Chap. 3 Les arbres binaires Un arbre est un ensemble de nœuds, organisés de façon hiérarchique, à partir d'un nœud distingué, appelé racine. La structure d'arbre est l'une des plus importantes et des plus

Plus en détail

Guichet automatique de banque

Guichet automatique de banque Guichet automatique de banque Mastère 2004 1 Guichet automatique de banque : GAB Objectif : Illustrer la vue fonctionnelle et particulièrement la définition des cas d utilisation. 1. Spécification du problème

Plus en détail

Cours Gestion de projet

Cours Gestion de projet Cours Gestion de projet Méthodes de conduite de projet Version Date Auteur V1.8 Septembre 2007 Pascal HEYER 1 Méthodes de conduite de projet Ce document est publié sous la licence libre Creative Commons-BY-NC-SA

Plus en détail

IFT2251 Introduction au génie logiciel Hiver 2006 (4 crédits) Prof. : Julie Vachon. Plan de cours

IFT2251 Introduction au génie logiciel Hiver 2006 (4 crédits) Prof. : Julie Vachon. Plan de cours IFT2251 Introduction au génie logiciel Hiver 2006 (4 crédits) Prof. : Julie Vachon ** Début des cours : le lundi 9 janvier 2006 ** Plan de cours 1. Introduction Les exigences et les attentes à l égard

Plus en détail

Partie I : Automates et langages

Partie I : Automates et langages 2 Les calculatrices sont interdites. N.B. : Le candidat attachera la plus grande importance à la clarté, à la précision et à la concision de la rédaction. Si un candidat est amené à repérer ce qui peut

Plus en détail

Design Patterns. Pourquoi utiliser des patterns? Pourquoi utiliser des patterns? Les patterns vue de loin. D où viennent les design patterns?

Design Patterns. Pourquoi utiliser des patterns? Pourquoi utiliser des patterns? Les patterns vue de loin. D où viennent les design patterns? Noël NOVELLI ; Université de la Méditerranée ; LIF et Département d Informatique Case 901 ; 163 avenue de Luminy 13 288 MARSEILLE cedex 9 Design Patterns D où viennent les design patterns? D où viennent

Plus en détail

IFT2251 Introduction au génie logiciel Plan de cours. 2. Description du cours et objectifs généraux

IFT2251 Introduction au génie logiciel Plan de cours. 2. Description du cours et objectifs généraux IFT2251 Introduction au génie logiciel Plan de cours Été 2008 Yann-Gaël Guéhéneuc 1. Introduction Les exigences et les attentes à l égard de la qualité logicielle sont de plus en plus grandes. La taille

Plus en détail

Le Guide Pratique des Processus Métiers

Le Guide Pratique des Processus Métiers Guides Pratiques Objecteering Le Guide Pratique des Processus Métiers Auteur : Version : 1.0 Copyright : Softeam Equipe Conseil Softeam Supervisée par Philippe Desfray Softeam 21 avenue Victor Hugo 75016

Plus en détail

CSC4002 : Introduction à la conception et à la programmation orientées objet illustrées avec UML et JAVA

CSC4002 : Introduction à la conception et à la programmation orientées objet illustrées avec UML et JAVA CSC4002 : Introduction à la conception et à la programmation orientées objet illustrées avec UML et JAVA Denis Conan et Jean-Luc Raffy CSC 4002 Octobre 2015 CSC4002 : Introduction à la conception et à

Plus en détail

CONDUITE D'UN PROJET ET QUALITÉ. (1 ère partie)

CONDUITE D'UN PROJET ET QUALITÉ. (1 ère partie) 151 1 (1 ère partie) Pour devenir un bon programmeur, il faut généralement passer par trois stades : - Le premier stade consiste à s'initier aux règles de base de l'algorithmique et à maîtriser les bases

Plus en détail

Formation UML 2 les diagrammes de séquences, d états-transitions et d activités

Formation UML 2 les diagrammes de séquences, d états-transitions et d activités Formation UML 2 les diagrammes de séquences, d états-transitions et d activités Travaux dirigés 2ème exercice 11 au 13 février 2014 Hervé DOMALAIN CPII/DOSO/ED FORMATION UML 2 LES DIAGRAMMES DE SEQUENCES,

Plus en détail

Le langage UML : Les diagrammes de séquence. Lydie du Bousquet Lydie.du-bousquet@imag.fr

Le langage UML : Les diagrammes de séquence. Lydie du Bousquet Lydie.du-bousquet@imag.fr Le langage UML : Les diagrammes de séquence Lydie du Bousquet Lydie.du-bousquet@imag.fr 1 Modélisation des interactions Les objets d un système ont un comportement Ils interagissent entre eux Dynamique

Plus en détail

Les évolutions des méthodes de développement de logiciels. Depuis Merise de l'eau est passée sous les ponts

Les évolutions des méthodes de développement de logiciels. Depuis Merise de l'eau est passée sous les ponts Les évolutions des méthodes de développement de logiciels Depuis Merise de l'eau est passée sous les ponts Programmation Orientée Objets Encapsulation des données et des traitements Polymorphisme Modularité

Plus en détail

Le Processus Unifié appliqué au projet MOOCS

Le Processus Unifié appliqué au projet MOOCS Le Processus Unifié appliqué au projet MOOCS Violaine Louvet GTN, 7 mai 2003, Orsay Le Processus Unifie applique au projet MOOCS p. 1 L objet Objet = entité regroupant des données (attributs) et des services

Plus en détail

Modélisation objet Le langage UML

Modélisation objet Le langage UML Modélisation objet Le langage UML Brahim HAMID La base de contrôle Robot Zone à explorer brahim.hamid@irit.fr brahim.hamid@univ-tlse2.fr http://mass-cara.univ-tlse2.fr/~brahimou/ens/uml 1 Les méthodes

Plus en détail

SOA et Services Web. 23 octobre 2011. SOA: Concepts de base

SOA et Services Web. 23 octobre 2011. SOA: Concepts de base SOA et Services Web 23 octobre 2011 1 SOA: Concepts de base 2 Du client serveur à la SOA N est Nest pas une démarche entièrement nouvelle: années 1990 avec les solutions C/S Besoins d ouverture et d interopérabilité

Plus en détail

Introduction à l'analyse et à la modélisation des processus. Eric Papet Co-fondateur SSII DEV1.0 Architecte Logiciel & Sécurité Lead Auditor 27001

Introduction à l'analyse et à la modélisation des processus. Eric Papet Co-fondateur SSII DEV1.0 Architecte Logiciel & Sécurité Lead Auditor 27001 Introduction à l'analyse et à la modélisation des processus Eric Papet Co-fondateur SSII DEV1.0 Architecte Logiciel & Sécurité Lead Auditor 27001 Les composants d'une méthode d'analyse La conception d'un

Plus en détail

Le Processus RUP. H. Kadima. Tester. Analyst. Performance Engineer. Database Administrator. Release Engineer. Project Leader. Designer / Developer

Le Processus RUP. H. Kadima. Tester. Analyst. Performance Engineer. Database Administrator. Release Engineer. Project Leader. Designer / Developer Le Processus RUP Database Administrator Project Leader H. Kadima Performance Engineer Release Engineer Analyst Designer / Developer Tester Table des matières 1. De l artisanat à l industrialisation de

Plus en détail

Génie Logiciel 1. Julie Dugdale. Julie.Dugdale@upmf-grenoble.fr Daniel Bardou@upmf-grenoble.fr

Génie Logiciel 1. Julie Dugdale. Julie.Dugdale@upmf-grenoble.fr Daniel Bardou@upmf-grenoble.fr Génie Logiciel 1 Julie Dugdale Julie.Dugdale@upmf-grenoble.fr Daniel Bardou@upmf-grenoble.fr Tous les cours seront sur le Bureau Virtuel (cours, TDs, Génie Logiciel 1-2 etc.) Introduction et information

Plus en détail

Formation Conception orientée objet

Formation Conception orientée objet Objectif La programmation orientée objet (POO) est un paradigme de programmation informatique qui consiste en la définition et l'interaction de briques logicielles appelées objets. Un objet représente

Plus en détail

Etudes de cas. Etude de cas LIBENLIGNE

Etudes de cas. Etude de cas LIBENLIGNE Etudes de cas Etude de cas LIBENLIGNE 1 - Présentation générale 2 - Site marchand 3 - La phase d'initialisation 4 - La phase d'élaboration : itération n 1 5 - La phase d'élaboration : itération n 2 1 -

Plus en détail