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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

introduction à la conception Orientée Objet

introduction à la conception Orientée Objet 1 introduction à la conception Orientée Objet IUP GEII 2ème année marcel@univ-tours.fr http://www.blois.univ-tours.fr/ marcel 2 plan cours 1. motivations génie logiciel 2. concepts et techniques orientés

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

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

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

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

Notions de programmation orientée objet

Notions de programmation orientée objet 1 Génie Logiciel Notions de programmation orientée objet Renaud Marlet LaBRI / INRIA http://www.labri.fr/~marlet màj 19/04/2007 2 Les données d'abord (1) Important résultat de l'expérience : Le plus souvent,

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

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

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

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

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

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

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

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

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

UML 1ère partie. Référence: http://uml.developpez.com/lp/cours/uml_free_fr_cours.html UML

UML 1ère partie. Référence: http://uml.developpez.com/lp/cours/uml_free_fr_cours.html UML UML UML 1ère partie Référence: http://uml.developpez.com/lp/cours/uml_free_fr_cours.html LOG2000 Éléments du génie logiciel 2002 Bayomock André-Claude PLAN Définition et historique Vue générale A quoi

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

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

Modélisation objet avec UML

Modélisation objet avec UML Modélisation objet avec UML Le développement des systèmes est une tâche d une grande envergure et un investissement important pour toute entreprise. La modélisation des systèmes déjà existants ou d un

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

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

Méthodologies de développement de logiciels de gestion

Méthodologies de développement de logiciels de gestion Méthodologies de développement de logiciels de gestion Chapitre 5 Traits caractéristiques des deux approches de méthodologie Présentation réalisée par P.-A. Sunier Professeur à la HE-Arc de Neuchâtel http://lgl.isnetne.ch

Plus en détail

SYSTEMES D INFORMATION & CONCEPTION de BdD

SYSTEMES D INFORMATION & CONCEPTION de BdD SYSTEMES D INFORMATION & CONCEPTION de BdD PLAN CONCEPT DE SYSTEME D INFORMATION MODELISATION D UN SYSTEME D INFORMATION MODELISATION CONCEPTUELLE : les METHODES METHODE SYSTEMIQUE METHODE OBJET L3 Informatique

Plus en détail

5 Génie logiciel orienté objet. Modélisation par objets et UML

5 Génie logiciel orienté objet. Modélisation par objets et UML 5 Génie logiciel orienté objet 5.1 Introduction et concepts de base 5.2 Modélisation par objets et UML 5.3 Diagramme de classes 5.4 Diagramme de cas d utilisation 5.5 Diagrammes de collaboration 5.6 Diagramme

Plus en détail

Processus d Informatisation

Processus d Informatisation Processus d Informatisation Cheminement de la naissance d un projet jusqu à son terme, deux grandes étapes : Recherche ou étude de faisabilité (en amont) L utilisateur a une idée (plus ou moins) floue

Plus en détail

Définition des Besoins

Définition des Besoins 1 Génie Logiciel (d'après A.-M. Hugues) Définition des Besoins Renaud Marlet LaBRI / INRIA http://www.labri.fr/~marlet màj 22/03/2007 2 Position dans le cycle de vie Contexte : un problème posé chez le

Plus en détail

P R O G R A M M E E T I N S T R U C T I O N S O F F I C I E L L E S

P R O G R A M M E E T I N S T R U C T I O N S O F F I C I E L L E S P R O G R A M M E E T I N S T R U C T I O N S O F F I C I E L L E S POUR L ENSEIGNEMENT DE L INFORMATIQUE MPSI première année I. Objectifs de la formation II-1 Développement de compétences et d aptitudes

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

GÉNIE LOGICIEL (SOFTWARE ENGINEERING)

GÉNIE LOGICIEL (SOFTWARE ENGINEERING) GÉNIE LOGICIEL (SOFTWARE ENGINEERING) 6ÈME PARTIE TEST DU LOGICIEL (SOFTWARE TESTING) Faculté des Sciences et Techniques http://perso.univ-st-etienne.fr/jacquene/gl/ Francois.Jacquenet@univ-st-etienne.fr

Plus en détail

Spécification par la modélisation

Spécification par la modélisation Spécification par la modélisation Objectifs : Être en mesure de spécifier par les modèles UML. Comprendre l importance des cas d utilisation (UC). Comprendre les méthodes d'identification des UCs. Comprendre

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

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

COMMENT DÉFINIR L ORIENTÉ OBJET

COMMENT DÉFINIR L ORIENTÉ OBJET COMMENT DÉFINIR L ORIENTÉ OBJET De manière superficielle, le terme «orienté objet», signifie que l on organise le logiciel comme une collection d objets dissociés comprenant à la fois une structure de

Plus en détail

Principes de Paquetage. Packaging et Marketing

Principes de Paquetage. Packaging et Marketing Génie Logiciel Conception Principes de Paquetage Packaging et Marketing La conception Définition Générale : Activité créatrice qui consiste à élaborer un projet, ou une partie des éléments le constituant,

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

Plan. Partie 2 : UML. Module Génie Logiciel : Cours d'analyse Orientée Objet.

Plan. Partie 2 : UML. Module Génie Logiciel : Cours d'analyse Orientée Objet. Partie II : UML Plan Partie 2 : UML 1 - Présentation d'uml 2 - Les diagrammes de cas d'utilisation 3 - Les diagrammes de classes et d'objets 4 - Les diagrammes d'interaction 5 - Les diagrammes de comportement

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

Développement de logiciels par objets avec UML (Unified Modeling Language) Pr. Jean-Marc Jézéquel IRISA - Univ. Rennes I

Développement de logiciels par objets avec UML (Unified Modeling Language) Pr. Jean-Marc Jézéquel IRISA - Univ. Rennes I 1 Développement de logiciels par objets avec UML (Unified Modeling Language) Pr. Jean-Marc Jézéquel IRISA - Univ. Rennes I Campus de Beaulieu F-35042 Rennes Cedex Tel : +33 299 847 192 Fax : +33 299 842

Plus en détail

Exposé de M.C.O. Thème. La methode orientée objet OMT (Object Modeling Technic)

Exposé de M.C.O. Thème. La methode orientée objet OMT (Object Modeling Technic) Exposé de M.C.O Thème La methode orientée objet OMT (Object Modeling Technic) 1 Plan du travail Introduction Le cycle de vie Formalismes de représentation UML Les outils d assistance OMT et UML Conclusion

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

É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

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

REFERENTIEL NORMATIF du CNES

REFERENTIEL NORMATIF du CNES REFERENTIEL NORMATIF du CNES Référence : Méthode et Procédure Annexe Technique à la MP RNC-CNES-Q-80-529 APPROBATION Président du CDN ; date et nom : Page i.1 PAGE D'ANALYSE DOCUMENTAIRE TITRE : MOTS

Plus en détail

Cours de base d Ingéniérie des applications objet. Introduction

Cours de base d Ingéniérie des applications objet. Introduction 1 IMPORTANCE DES OBJETS DANS L INFORMATIQUE LOGICIELLE1 Cours de base d Ingéniérie des applications objet. Introduction Support de Cours Christophe Dony Université Montpellier-II Contenu du cours - concepts

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

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

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

METHODOLOGIE : INGENIERIE DES SYSTEMES

METHODOLOGIE : INGENIERIE DES SYSTEMES METHODOLOGIE : INGENIERIE DES SYSTEMES L ingénierie de systèmes regroupe l ensemble des activités de pilotage des projets de construction effective d un système en s appuyant sur sa décomposition architecturale

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

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

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

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

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

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

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

MODÉLISATION DES BESOINS

MODÉLISATION DES BESOINS MODÉLISATION DES BESOINS Diagrammes de cas d utilisation Cas d'utilisation : Use Case (Jacobson) Permettent déxprimer les attentes/besoins des utilisateurs Permettent de définir les limites du système

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

Dossier d'étude technique

Dossier d'étude technique Centre national de la recherche scientifique Direction des systèmes d'information REFERENTIEL QUALITE Guide méthodologique Dossier d'étude technique Référence : CNRS/DSI/conduite-projet/developpement/technique/guide-etude-technique

Plus en détail

L approche Bases de données

L approche Bases de données L approche Bases de données Cours: BD. Avancées Année: 2005/2006 Par: Dr B. Belattar (Univ. Batna Algérie) I- : Mise à niveau 1 Cours: BDD. Année: 2013/2014 Ens. S. MEDILEH (Univ. El-Oued) L approche Base

Plus en détail

Conception et Programmation par Objets GLIN404. Langages et paradigmes de programmation

Conception et Programmation par Objets GLIN404. Langages et paradigmes de programmation Conception et Programmation par Objets GLIN404 Marianne Huchard, Clémentine Nebut LIRMM / Université de Montpellier 2 2013 Langages et paradigmes de programmation Le raisonnement classicatoire paradigme

Plus en détail

DEMARCHE OU PROCESSUS LOGICIEL

DEMARCHE OU PROCESSUS LOGICIEL DEMARCHE OU PROCESSUS LOGICIEL PROCESSUS LOGICIEL Définition Un processus définit une séquence d étapes, en partie ordonnées, qui concourent à l obtention d un système logiciel ou à l évolution d un système

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é Analyse des besoins et spécification Delphine Longuet delphine.longuet@lri.fr Analyse des besoins et spécification Objectif

Plus en détail

GESTION DE PROJETS Spécifications conception. 05/09/2007 V2.0 Gestion de Projets T. Fricheteau 1

GESTION DE PROJETS Spécifications conception. 05/09/2007 V2.0 Gestion de Projets T. Fricheteau 1 GESTION DE PROJETS Spécifications conception 05/09/2007 V2.0 Gestion de Projets T. Fricheteau 1 GESTION DE PROJETS Plan du cours: - Synchronisation des phases d Etude, - Dossier de Spécifications Générales,

Plus en détail

Plan. Exemple: Application bancaire. Introduction. OCL Object Constraint Language Le langage de contraintes d'uml

Plan. Exemple: Application bancaire. Introduction. OCL Object Constraint Language Le langage de contraintes d'uml OCL Object Constraint Language Le langage de contraintes d'uml Plan 1. Introduction 2. Les principaux concepts d'ocl Object Constraint Language 1 Object Constraint Language 2 Exemple: une application bancaire

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

Analyse et conception des Systèmes d Information. La démarche Merise : La Production Logicielle

Analyse et conception des Systèmes d Information. La démarche Merise : La Production Logicielle Analyse et conception des Systèmes d Information La démarche Merise : La Production Logicielle La production du logiciel Place, objectifs et principes directeurs Christophe.Nicolle@u-bourgogne.fr Introduction

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 des Systèmes d Information Jean-Yves Antoine

Modélisation des Systèmes d Information Jean-Yves Antoine Modélisation des Systèmes d Information Jean-Yves Antoine http://www.info.univ-tours.fr/~antoine Processus de développement logiciel Jean-Yves Antoine U. Bretagne Sud - UFR SSI - IUP Vannes année 2001-2002

Plus en détail

LES OUTILS D ALIMENTATION DU REFERENTIEL DE DB-MAIN

LES OUTILS D ALIMENTATION DU REFERENTIEL DE DB-MAIN LES OUTILS D ALIMENTATION DU REFERENTIEL DE DB-MAIN Les contenues de ce document sont la propriété exclusive de la société REVER. Ils ne sont transmis qu à titre d information et ne peuvent en aucun cas

Plus en détail

vendredi 8 février 2008 QUALITÉ DU LOGICIEL

vendredi 8 février 2008 QUALITÉ DU LOGICIEL QUALITÉ DU LOGICIEL La qualité du logiciel Qualité d'un logiciel? de manière informelle : respect des spécifications. Particularités des logiciels par rapport à des produits matériels : Un logiciel a de

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

Georgieva Diana Bourgouin Adrien Licence 3 ~ Faculté des Sciences et des Techniques UML ~ Bibliothèque. Projet UML.

Georgieva Diana Bourgouin Adrien Licence 3 ~ Faculté des Sciences et des Techniques UML ~ Bibliothèque. Projet UML. Projet UML Cas Bibliothèque Page 1 sur 35 S6 ~ 2008-2009 Sommaire I. Introduction 3 II. Modélisation A. Cas d utilisation 1. Première approche 4-6 2. Cas d utilisation avant la modélisation des diagrammes

Plus en détail

Compilation séparée. Compilation séparée. ENSIIE: Programmation avancée, Compilation séparée, Modularité, Spécifications algébriques 1

Compilation séparée. Compilation séparée. ENSIIE: Programmation avancée, Compilation séparée, Modularité, Spécifications algébriques 1 Compilation séparée Compilation séparée ENSIIE: Programmation avancée, Compilation séparée, Modularité, Spécifications algébriques 1 Compilation séparée Modularité GCC : 4 millions de lignes de code Noyau

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

Héritage en java : Calculatrice SDC

Héritage en java : Calculatrice SDC Programmation orientée objet L3 MIAGE Héritage en java : Calculatrice SDC Travail à rendre : le code complet du projet SDC sous forme d une archive tar.gz. L archive comportera trois répertoires : un répertoire

Plus en détail

Présentation du langage et premières fonctions

Présentation du langage et premières fonctions 1 Présentation de l interface logicielle Si les langages de haut niveau sont nombreux, nous allons travaillé cette année avec le langage Python, un langage de programmation très en vue sur internet en

Plus en détail

IFT3913 Qualité du logiciel et métriques. Chapitre 5 Mesure de la qualité du logiciel

IFT3913 Qualité du logiciel et métriques. Chapitre 5 Mesure de la qualité du logiciel IFT3913 Qualité du logiciel et métriques Chapitre 5 Mesure de la qualité du logiciel Plan du cours Introduction Théorie de la mesure Qualité du logiciel Mesure du produit logiciel Mesure de la qualité

Plus en détail

Cours d introduction à l informatique. Partie 2 : Comment écrire un algorithme? Qu est-ce qu une variable? Expressions et instructions

Cours d introduction à l informatique. Partie 2 : Comment écrire un algorithme? Qu est-ce qu une variable? Expressions et instructions Cours d introduction à l informatique Partie 2 : Comment écrire un algorithme? Qu est-ce qu une variable? Expressions et instructions Qu est-ce qu un Une recette de cuisine algorithme? Protocole expérimental

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

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