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

Save this PDF as:
 WORD  PNG  TXT  JPG

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cours d Analyse, Algorithmique Elements de programmation

Cours d Analyse, Algorithmique Elements de programmation 1 de 33 Cours d Analyse, Algorithmique Elements de programmation Florent Hivert Mél : Florent.Hivert@lri.fr Adresse universelle : http://www.lri.fr/ hivert 2 de 33 Données et instructions Un programme

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

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

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

Projet Informatique. Philippe Collet. Licence 3 Informatique S5 2014-2015. http://deptinfo.unice.fr/twiki/bin/view/linfo/projetinfo201415

Projet Informatique. Philippe Collet. Licence 3 Informatique S5 2014-2015. http://deptinfo.unice.fr/twiki/bin/view/linfo/projetinfo201415 Projet Informatique Philippe Collet Licence 3 Informatique S5 2014-2015 http://deptinfo.unice.fr/twiki/bin/view/linfo/projetinfo201415 Réalisation d'un développement de taille conséquente? r Firefox? Ph.

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

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

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

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

Programmation avancée en C

Programmation avancée en C Département Informatique Nom : Prénom : Année scolaire : 2007 2008 Date : 23 juin 2008 Module INF446 Session de juin Programmation avancée en C Contrôle de connaissance 1 de 45 minutes ÅERCI de répondre

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

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

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

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

Informations de l'unité d'enseignement Implantation. Cursus de. Intitulé. Code. Cycle 1. Bloc 2. Quadrimestre 2. Pondération 4. Nombre de crédits 4

Informations de l'unité d'enseignement Implantation. Cursus de. Intitulé. Code. Cycle 1. Bloc 2. Quadrimestre 2. Pondération 4. Nombre de crédits 4 Informations de l'unité d'enseignement Implantation Cursus de Intitulé Code Institut Paul Lambin Bachelier en informatique de gestion Programmation Avancée en Java I2020 Cycle 1 Bloc 2 Quadrimestre 2 Pondération

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

Technologie Web. Conception de sites Web. Alexandre Pauchet. INSA Rouen - Département ASI. INSA - ASI TechnoWeb : Rappels UML 1/21

Technologie Web. Conception de sites Web. Alexandre Pauchet. INSA Rouen - Département ASI. INSA - ASI TechnoWeb : Rappels UML 1/21 INSA - ASI TechnoWeb : Rappels UML 1/21 Technologie Web Conception de sites Web Alexandre Pauchet INSA Rouen - Département ASI BO.B.RC.18, pauchet@insa-rouen.fr INSA - ASI TechnoWeb : Rappels UML 2/21

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

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

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

Diagramme de Classe UML et Base de Données Relationnelle-objet

Diagramme de Classe UML et Base de Données Relationnelle-objet Ecole des Hautes Etudes Commerciales HEC Alger Diagramme de Classe UML et Base de Données Relationnelle-objet par Amina GACEM Module Informatique 1ière Année Master Sciences Commerciales Plan Introduction

Plus en détail

Méthode de Test. Pour WIKIROUTE. Rapport concernant les méthodes de tests à mettre en place pour assurer la fiabilité de notre projet annuel.

Méthode de Test. Pour WIKIROUTE. Rapport concernant les méthodes de tests à mettre en place pour assurer la fiabilité de notre projet annuel. Méthode de Test Pour WIKIROUTE Rapport concernant les méthodes de tests à mettre en place pour assurer la fiabilité de notre projet annuel. [Tapez le nom de l'auteur] 10/06/2009 Sommaire I. Introduction...

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

Introduction au Génie Logiciel

Introduction au Génie Logiciel Introduction au Génie Logiciel Lydie du Bousquet Lydie.du-bousquet@imag.fr En collaboration avec J.-M. Favre, I. Parissis, Ph. Lalanda Qu est-ce que le logiciel? programme, ensemble d instructions Caractéristiques

Plus en détail

Chapitre 2. Classes et objets

Chapitre 2. Classes et objets Chapitre 2: Classes et Objets 1/10 Chapitre 2 Classes et objets Chapitre 2: Classes et Objets 2/10 Approche Orientée Objet Idée de base de A.O.O. repose sur l'observation de la façon dont nous procédons

Plus en détail

Gestion multi-stocks

Gestion multi-stocks Gestion multi-stocks Dans l architecture initiale du logiciel IDH-STOCK, 11 champs obligatoires sont constitués. Ces champs ne peuvent être supprimés. Ils constituent l ossature de base de la base de données

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

Talend Technical Note

Talend Technical Note Mars 2011 Page 1 sur 5 Le MDM offre un hub central de contrôle et une vision unique des données maître de l'entreprise, quelles que soient les disparités entre les systèmes source. Il assure que les données

Plus en détail

<< Crédit Club Auto >>

<< Crédit Club Auto >> Abbas Ahmad Année 2010/2011 Matin Bayramov Analyse et Modélisation des Systèmes Informatique (AMSI) Projet de Modélisation UML > Professeur encadrant : M. GUILLAUME PAQUETTE Projet

Plus en détail

Norme de documentation des programmes

Norme de documentation des programmes 1. Introduction Norme de documentation des programmes Auteur : Marc Frappier Collaborateurs Benoit Fraikin Gabriel Girard Jean Goulet Gérard Houdeville Luc Lavoie Version : 1.02 30 août 2004 Département

Plus en détail

Conseil, Etudes et Edition de logiciels NORMES & CONVENTIONS DE DEVELOPPEMENT JAVA ET SQL

Conseil, Etudes et Edition de logiciels NORMES & CONVENTIONS DE DEVELOPPEMENT JAVA ET SQL Conseil, Etudes et Edition de logiciels NORMES & CONVENTIONS DE DEVELOPPEMENT JAVA ET SQL Table des matières Système d'exploitation... 3 Environnement de développement intégré... 3 Le workspace... 3 Le

Plus en détail

Abstraction: introduction. Abstraction et liaison dans les langages de programmation. Abstraction: principe. Abstraction: terminologie. N.

Abstraction: introduction. Abstraction et liaison dans les langages de programmation. Abstraction: principe. Abstraction: terminologie. N. Abstraction et liaison dans les langages de programmation LIN2: Paradigmes de programmation N. Hameurlain Abstraction: introduction L'importance de l abstraction découle de sa capacité de cacher les détails

Plus en détail

Génie logiciel avec UML. Notions sur le langage UML adapté pour les cours du programme Techniques de l informatique

Génie logiciel avec UML. Notions sur le langage UML adapté pour les cours du programme Techniques de l informatique Génie logiciel avec UML Notions sur le langage UML adapté pour les cours du programme Techniques de l informatique Claude Boutet Session hiver 2008 Modélisation de systèmes Table des matières TABLE DES

Plus en détail

Use Cases. Introduction

Use Cases. Introduction Use Cases Introduction Avant d aborder la définition et la conception des UC il est bon de positionner le concept du UC au sein du processus de développement. Le Processus de développement utilisé ici

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

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

Programmation Objet - Cours II

Programmation Objet - Cours II Programmation Objet - Cours II - Exercices - Page 1 Programmation Objet - Cours II Exercices Auteur : E.Thirion - Dernière mise à jour : 05/07/2015 Les exercices suivants sont en majorité des projets à

Plus en détail

REFERENTIEL NORMATIF du CNES

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

Plus en détail

IFT3913 Qualité du logiciel et métriques. Chapitre 2

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

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

Cours du Master PISE. Jean-Baptiste.Yunes@univ-paris-diderot.fr http://www.liafa.univ-paris-diderot.fr/~yunes/ 2015

Cours du Master PISE. Jean-Baptiste.Yunes@univ-paris-diderot.fr http://www.liafa.univ-paris-diderot.fr/~yunes/ 2015 Cours du Master PISE Jean-Baptiste.Yunes@univ-paris-diderot.fr http://www.liafa.univ-paris-diderot.fr/~yunes/ 2015 1 UML? Un langage de modélisation simple qui limite les ambiguïtés indépendant des langages

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

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

Topologie du web - Valentin Bourgoin - http://www.valentinbourgoin.net. Méthodes agiles & SCRUM

Topologie du web - Valentin Bourgoin - http://www.valentinbourgoin.net. Méthodes agiles & SCRUM Méthodes agiles & SCRUM 1/ Pourquoi les méthodes agiles? Définition d une méthode agile. Fondamentaux. Quand les utiliser? 2/ SCRUM En quoi est-ce une méthode agile? Sprints et releases. Le Product Owner.

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

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

Plateforme de capture et d analyse de sites Web AspirWeb

Plateforme de capture et d analyse de sites Web AspirWeb Projet Java ESIAL 2A 2009-2010 Plateforme de capture et d analyse de sites Web AspirWeb 1. Contexte Ce projet de deuxième année permet d approfondir par la pratique les méthodes et techniques acquises

Plus en détail