Conception. Génie Logiciel. Renaud Marlet. LaBRI / INRIA (d'après A.-M. Hugues) màj 17/04/2007
|
|
- Éloïse Grenier
- il y a 8 ans
- Total affichages :
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
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étailUniversité 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étailAnalyse,, 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étailPrésentation générale de la méthode orientée objet : O.M.T. (Rumbaugh & al.)
Présentation générale de la méthode orientée objet : O.M.T. (Rumbaugh & al.) Bernard ESPINASSE Professeur à l'université d'aix-marseille Plan Introduction Les modèles d'omt Le Modèle Objet (MO) Le Modèle
Plus en détailConception, architecture et urbanisation des systèmes d information
Conception, architecture et urbanisation des systèmes d information S. Servigne Maître de Conférences, LIRIS, INSA-Lyon, F-69621 Villeurbanne Cedex e-mail: sylvie.servigne@insa-lyon.fr 1. Introduction
Plus en détailCours 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étailbasé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étailLes diagrammes de modélisation
L approche Orientée Objet et UML 1 Plan du cours Introduction au Génie Logiciel L approche Orientée Objet et Notation UML Les diagrammes de modélisation Relations entre les différents diagrammes De l analyse
Plus en détailIFT2255 : 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étailUML (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étailCycle 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étailGestion 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étailLe 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étailArchitecture d'entreprise : Guide Pratique de l'architecture Logique
Guides Pratiques Objecteering Architecture d'entreprise : Guide Pratique de l'architecture Logique Auteur : Version : 1.0 Copyright : Softeam Equipe Conseil Softeam Supervisée par Philippe Desfray Softeam
Plus en détail3. 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étailLES INTERFACES HOMME-MACHINE
LES INTERFACES HOMME-MACHINE 1 ère Partie : Introduction aux Interfaces Homme-Machine 2 ème Partie : Notions de base sur les Sciences Cognitives 3 ème Partie : Recommandations ergonomiques 4 ème Partie
Plus en détailTP n 2 Concepts de la programmation Objets Master 1 mention IL, semestre 2 Le type Abstrait Pile
TP n 2 Concepts de la programmation Objets Master 1 mention IL, semestre 2 Le type Abstrait Pile Dans ce TP, vous apprendrez à définir le type abstrait Pile, à le programmer en Java à l aide d une interface
Plus en détailLe Guide Pratique des Processus Métiers
Guides Pratiques Objecteering Le Guide Pratique des Processus Métiers Auteur : Version : 1.0 Copyright : Softeam Equipe Conseil Softeam Supervisée par Philippe Desfray Softeam 21 avenue Victor Hugo 75016
Plus en détailIntroduction au génie logiciel
Introduction au génie logiciel Guillaume Laurent ENSMM 2007 G. Laurent (ENSMM) Introduction au génie logiciel 2007 1 / 36 Plan du cours 1 Problématique du génie logiciel 2 Méthodes de développement logiciel
Plus en détailMODELISATION UN ATELIER DE MODELISATION «RATIONAL ROSE»
MODELISATION UN ATELIER DE MODELISATION «RATIONAL ROSE» Du cours Modélisation Semi -Formelle de Système d Information Du Professeur Jean-Pierre GIRAUDIN Décembre. 2002 1 Table de matière Partie 1...2 1.1
Plus en détailAnalyse et Conception objet du logiciel Analyse et conception objet du logiciel : Méthode de conception objet et notation UML.
Analyse et conception objet du logiciel : Méthode de conception objet et notation UML Rémy Courdier Email : Remy.Courdier@univ-reunion.fr Rémy Courdier V2.1 1 Plan du cours Introduction au Génie Logiciel
Plus en détailC++ 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étailGuichet 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étailMéthodes de développement. Analyse des exigences (spécification)
1 / 16 Méthodes de développement Analyse des exigences (spécification) 1 -Objectifs de l'analyse des exigences... 2 2 - Approfondissement et formalisation du besoin... 2 2.1 Séparation des besoins, contraintes
Plus en détailCours Gestion de projet
Cours Gestion de projet Méthodes de conduite de projet Version Date Auteur V1.8 Septembre 2007 Pascal HEYER 1 Méthodes de conduite de projet Ce document est publié sous la licence libre Creative Commons-BY-NC-SA
Plus en détailMé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étailProcessus 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étailLe Processus RUP. H. Kadima. Tester. Analyst. Performance Engineer. Database Administrator. Release Engineer. Project Leader. Designer / Developer
Le Processus RUP Database Administrator Project Leader H. Kadima Performance Engineer Release Engineer Analyst Designer / Developer Tester Table des matières 1. De l artisanat à l industrialisation de
Plus en détailDé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étailGénéralités sur le Langage Java et éléments syntaxiques.
Généralités sur le Langage Java et éléments syntaxiques. Généralités sur le Langage Java et éléments syntaxiques....1 Introduction...1 Genéralité sur le langage Java....1 Syntaxe de base du Langage...
Plus en détailSommaire. Conduite de projet Méthode d analyse et de conception. Processus unifié. Objectifs d un processus de développement
Conduite de projet Méthode d analyse et de conception Processus unifié G. Picard SMA/G2I/ENS Mines Saint-Etienne gauthier.picard@emse.fr Octobre 2009 Sommaire!!Objectifs d un processus d ingénierie logicielle!
Plus en détailProjet Active Object
Projet Active Object TAO Livrable de conception et validation Romain GAIDIER Enseignant : M. Noël PLOUZEAU, ISTIC / IRISA Pierre-François LEFRANC Master 2 Informatique parcours MIAGE Méthodes Informatiques
Plus en détailGénérer du code à partir d une description de haut niveau
Cedric Dumoulin Générer du code à partir d une description de haut niveau Ce projet vise à fournir un environnement de développement permettant de modéliser des UI Android à un haut niveau d abstraction,
Plus en détailUML (Diagramme de classes) Unified Modeling Language
UML (Diagramme de classes) Unified Modeling Language Sommaire Introduction Objectifs Diagramme de classes Classe (Nom, attribut, opération) Visibilité et portée des constituants d une classe Association
Plus en détailGénie Logiciel. Rappels. C. Crochepeyre Génie Logiciel Rappels 1
Génie Logiciel Rappels C. Crochepeyre Génie Logiciel Rappels 1 INTRODUCTION GL: ingénierie appliquée au logiciel informatique Objectif: la qualité diminution du coût du logiciel et fiabilité Besoin: complexité
Plus en détailProgrammation Orientée Objet
Université de Pau et des Pays de l Adour Institut Universitaire de Technologie des Pays de l Adour Département Réseaux et Télécommunications 371, rue du Ruisseau BP 201 40004 Mont-de-Marsan Cedex tél :
Plus en détailLANGAGUE JAVA. Public Développeurs souhaitant étendre leur panel de langages de programmation
ING 01 LANGAGUE JAVA Durée : 21 heures 1090 HT / jour Dates : à définir en 2012 Concevoir et développer des programmes en langage Java Comprendre le fonctionnement de la machine virtuelle S approprier
Plus en détailNom de l application
Ministère de l Enseignement Supérieur et de la Recherche Scientifique Direction Générale des Etudes Technologiques Institut Supérieur des Etudes Technologiques de Gafsa Département Technologies de l Informatique
Plus en détailChap 4: Analyse syntaxique. Prof. M.D. RAHMANI Compilation SMI- S5 2013/14 1
Chap 4: Analyse syntaxique 1 III- L'analyse syntaxique: 1- Le rôle d'un analyseur syntaxique 2- Grammaires non contextuelles 3- Ecriture d'une grammaire 4- Les méthodes d'analyse 5- L'analyse LL(1) 6-
Plus en détailVérification et Validation
Vérification et Validation Génie Logiciel Master 1 II Mihaela Sighireanu Objectifs I. Introduire la vérification et la validation (V&V) du logiciel et comprendre leurs différences. II.Définir le plan de
Plus en détailChapitre 1 : Introduction aux bases de données
Chapitre 1 : Introduction aux bases de données Les Bases de Données occupent aujourd'hui une place de plus en plus importante dans les systèmes informatiques. Les Systèmes de Gestion de Bases de Données
Plus en détailGESTION DE PROJET SÉANCE 2 : LES CYCLE DE VIE D'UN PROJET
GESTION DE PROJET SÉANCE 2 : LES CYCLE DE VIE D'UN PROJET 1 Tianxiao LIU Licence Professionnelle Réseaux & Sécurité Université de Cergy-Pontoise http://depinfo.u-cergy.fr/~tliu/lpg.php PLAN Objectif et
Plus en détailLES 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étailINITIATION AU LANGAGE C SUR PIC DE MICROSHIP
COURS PROGRAMMATION INITIATION AU LANGAGE C SUR MICROCONTROLEUR PIC page 1 / 7 INITIATION AU LANGAGE C SUR PIC DE MICROSHIP I. Historique du langage C 1972 : naissance du C dans les laboratoires BELL par
Plus en détailmodélisation solide et dessin technique
CHAPITRE 1 modélisation solide et dessin technique Les sciences graphiques regroupent un ensemble de techniques graphiques utilisées quotidiennement par les ingénieurs pour exprimer des idées, concevoir
Plus en détailConception des bases de données : Modèle Entité-Association
Conception des bases de données : Modèle Entité-Association La modélisation d un problème, c est-à-dire le passage du monde réel à sa représentation informatique, se définit en plusieurs étapes pour parvenir
Plus en détailPlan. 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étailSommaire. G. Pujolle, F. Ravat, C. Soulé-Dupuy, G. Zurfluh
NOTATION UML AVEC RATIONAL ROSE G. Pujolle, F. Ravat, C. Soulé-Dupuy, G. Zurfluh Sommaire 1 GÉNÉRALITES...2 1.1 ENVIRONNEMENT LOGICIEL...2 1.2 LES VUES DU LOGICIEL ROSE...3 1.3 ORGANISATION RECOMMANDÉE...3
Plus en détailIngénierie des Modèles. Méta-modélisation
Ingénierie des Modèles Méta-modélisation Eric Cariou Master Technologies de l'internet 2 ème année Université de Pau et des Pays de l'adour UFR Sciences Pau Département Informatique Eric.Cariou@univ-pau.fr
Plus en détailEncapsulation. L'encapsulation consiste à rendre les membres d'un objet plus ou moins visibles pour les autres objets.
Encapsulation L'encapsulation consiste à rendre les membres d'un objet plus ou moins visibles pour les autres objets. La visibilité dépend des membres : certains membres peuvent être visibles et d'autres
Plus en détailBusiness Process Modeling (BPM)
Business Process Modeling (BPM) Mineure SOA Cécile Hardebolle cecile.hardebolle@supelec.fr Programme 8 nov. 15 nov. Introduction. Enjeux, rôle de l'architecte SI Partie n 1 du cas d'étude Architecture
Plus en détailQu'est-ce que le BPM?
Qu'est-ce que le BPM? Le BPM (Business Process Management) n'est pas seulement une technologie mais, dans les grandes lignes, une discipline de gestion d'entreprise qui s'occupe des procédures contribuant
Plus en détailURBANISME DES SYSTÈMES D INFORMATION
FAYCAL AYECH GL2. INSAT 2010/2011 INTRODUCTION AUX SYSTÈMES D INFORMATIONS URBANISME DES SYSTÈMES D INFORMATION De l Urbanisme à L Urbanisation des SI Urbanisme : Mise en œuvre des politiques urbaines
Plus en détailGénie Logiciel Orienté Objet UML
Licence Professionnelle en Informatique Génie Logiciel Orienté Objet UML E. Grislin-Le Strugeon E. Adam UVHC ISTV Plan Concepts orientés objet Principes des méthodes OO Qu est-ce que UML? Caractéristiques
Plus en détailCONCEPTION Support de cours n 3 DE BASES DE DONNEES
CONCEPTION Support de cours n 3 DE BASES DE DONNEES Auteur: Raymonde RICHARD PRCE UBO PARTIE III. - LA DESCRIPTION LOGIQUE ET PHYSIQUE DES DONNEES... 2 A. Les concepts du modèle relationnel de données...
Plus en détailMéthodes fonctionnelles : Structured Analysis - Structured Design (SA - SD)
Méthodes fonctionnelles : Structured Analysis - Structured Design (SA - SD) Bernard ESPINASSE Professeur à l'université d'aix-marseille Plan SA - Analyse Structurée (Structured Analysis) Notations des
Plus en détailAnalyse des Besoins (Spécifications)
1 Génie Logiciel (d'après A.-M. Hugues) Analyse des Besoins (Spécifications) Renaud Marlet LaBRI / INRIA http://www.labri.fr/~marlet màj 17/04/2007 Analyse des besoins : 2 Contexte : Position dans le cycle
Plus en détailEbauche Rapport finale
Ebauche Rapport finale Sommaire : 1 - Introduction au C.D.N. 2 - Définition de la problématique 3 - Etat de l'art : Présentatio de 3 Topologies streaming p2p 1) INTRODUCTION au C.D.N. La croissance rapide
Plus en détailCours STIM P8 TD 1 Génie Logiciel
Cours STIM P8 TD 1 Génie Logiciel Compléments sur UML Intervenant : Anil CASSAM CHENAI Date : 02/02/2012 Objectifs du complément Ce complément sera approfondi en parallèle de plusieurs TD/Cours. Rappels
Plus en détailRational Unified Process
Rational Unified Process For Christiane DAVOINE-GUHUR Société GICAB - Vannes Christiane.Davoine@CA-GICAB.fr Table des Matières 1 INTRODUCTION... 1 2 LES COMPOSANTS ET LES GRANDS PRINCIPES DU PROCESSUS...
Plus en détailConception d'un système d'information WEB avec UML Par Ass SERGE KIKOBYA
Conception d'un système d'information WEB avec UML Par Ass SERGE KIKOBYA I. Introduction Suite à une demande des étudiants, il m'est apparu intéressant de montrer, à travers un exemple concret, comment
Plus en détailMineure Architectures Orientées Services SOA Business Process Modeling (BPM) Mineure SOA. Business Process Modeling (BPM)
Mineure SOA Business Process Modeling (BPM) Idir AIT SADOUNE idir.aitsadoune@supelec.fr Idir AIT SADOUNE - Plan 1 Notion de processus? 2 Modélisation des processus? 3 Langages
Plus en détailRappel. Analyse de Données Structurées - Cours 12. Un langage avec des déclaration locales. Exemple d'un programme
Rappel Ralf Treinen Université Paris Diderot UFR Informatique Laboratoire Preuves, Programmes et Systèmes treinen@pps.univ-paris-diderot.fr 6 mai 2015 Jusqu'à maintenant : un petit langage de programmation
Plus en détailMaster MIDO 2ème année. Spécification et Conception en UML Maude Manouvrier
Master MIDO 2ème année Spécification et Conception en UML Maude Manouvrier Spécifications initiales Analyse Conception du système Conception des classes Bibliographie Modélisation et conception orientées
Plus en détailPlateforme 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étailFICHE UE Licence/Master Sciences, Technologies, Santé Mention Informatique
NOM DE L'UE : Algorithmique et programmation C++ LICENCE INFORMATIQUE Non Alt Alt S1 S2 S3 S4 S5 S6 Parcours : IL (Ingénierie Logicielle) SRI (Systèmes et Réseaux Informatiques) MASTER INFORMATIQUE Non
Plus en détailÉvaluation et implémentation des langages
Évaluation et implémentation des langages Les langages de programmation et le processus de programmation Critères de conception et d évaluation des langages de programmation Les fondations de l implémentation
Plus en détailGL - 2 2.1 Le Génie Logiciel
GL - 2 2.1 Le Génie Logiciel Lydie du Bousquet Lydie.du-bousquet@imag.fr En collaboration avec J.-M. Favre, I. Parissis, Ph. Lalanda 1 Rappels La production logicielle est une activité complexe de façon
Plus en détail2. Activités et Modèles de développement en Génie Logiciel
2. Activités et Modèles de développement en Génie Logiciel Bernard ESPINASSE Professeur à l'université d'aix-marseille Plan Les Activités du GL Analyse des besoins Spécification globale Conceptions architecturale
Plus en détailProgramme et contenus 2010-2011. Licence d'informatique de Lille, parcours MIAGE, en alternance ou en formation continue 01-04-2011 (13:40)
Programme et contenus 2010-2011 L3 MIAGE FA/FC Licence d'informatique de Lille, parcours MIAGE, en alternance ou en formation continue 01-04-2011 (13:40) PROGRAMME ET CONTENUS 2010-2011 Séminaire de rentrée
Plus en détailChapitre VI- La validation de la composition.
Chapitre VI- La validation de la composition. Objectifs du chapitre : Expliquer les conséquences de l utilisation de règles de typage souples dans SEP. Présenter le mécanisme de validation des connexions
Plus en détailMéthodes de Conception Orientés Objet (MCOO) SOMMAIRE
SOMMAIRE Sommaire... 1 INTRODUCTION... 3 I. Particularités d UML... 4 I.1 UML est une norme... 5 I.2 UML est un langage de modélisation objet... 5 I.3 UML est un support de communication... 6 I.4 UML est
Plus en détailRÉUSSIR L AUTOMATISATION DU PROCESSUS DE TEST FONCTIONNEL
UN LIVRE BLANC DE BORLAND RÉUSSIR L AUTOMATISATION DU PROCESSUS DE TEST FONCTIONNEL L'automatisation du processus de test fonctionnel optimise la qualité des logiciels et maximise leur valeur opérationnelle.
Plus en détailAlgorithmes d'apprentissage
Algorithmes d'apprentissage 1 Agents qui apprennent à partir d'exemples La problématique : prise de décision automatisée à partir d'un ensemble d'exemples Diagnostic médical Réponse à une demande de prêt
Plus en détailPourquoi l apprentissage?
Pourquoi l apprentissage? Les SE sont basés sur la possibilité d extraire la connaissance d un expert sous forme de règles. Dépend fortement de la capacité à extraire et formaliser ces connaissances. Apprentissage
Plus en détailInstitut Supérieure Aux Etudes Technologiques De Nabeul. Département Informatique
Institut Supérieure Aux Etudes Technologiques De Nabeul Département Informatique Support de Programmation Java Préparé par Mlle Imene Sghaier 2006-2007 Chapitre 1 Introduction au langage de programmation
Plus en détailCINEMATIQUE DE FICHIERS
ANDRE ANTHONY BRUNEAU Vincent JOUANNIN ROMAIN MAZEAUD MARINE RIOCHET Tony Groupe 609 CINEMATIQUE DE FICHIERS Mini-projet: Gestion de Ventes d'articles Enseignant: MONCEAUX Laura Année 2011 / 2012 TABLE
Plus en détailProjet 2. Gestion des services enseignants CENTRE D ENSEIGNEMENT ET DE RECHERCHE EN INFORMATIQUE. G r o u p e :
CENTRE D ENSEIGNEMENT ET DE RECHERCHE EN INFORMATIQUE Projet 2 Gestion des services enseignants G r o u p e : B E L G H I T Y a s m i n e S A N C H E Z - D U B R O N T Y u r i f e r M O N T A Z E R S i
Plus en détailCours 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étailCLAIRE, UN OUTIL DE SIMULATION ET DE TEST DE LOGICIELS CRITIQUES. Jean GASSINO, Jean-Yves HENRY. Rapport IPSN/Département d'évaluation de sûreté N 280
FR9704668 PC CLAIRE, UN OUTIL DE SIMULATION ET DE TEST DE LOGICIELS CRITIQUES Jean GASSINO, Jean-Yves HENRY eci Rapport IPSN/Département d'évaluation de sûreté N 280 Octobre 1996 INSTITUT DE PROTECTION
Plus en détailDéveloppement d un interpréteur OCL pour une machine virtuelle UML.
ObjeXion Software Prototyping made easy SA au capital de 500 000 F Siret 421 565 565 00015 APE 722Z Téléphone : 03 89 35 70 75 Télécopie : 03 89 35 70 76 L embarcadère 5, rue Gutemberg 68 800 Vieux-Thann,
Plus en détailTechnologie 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étailCours Composant 2. Qualité logicielle et spécications algébriques
UPMC Paris Universitas Master Informatique STL Cours Composant 2. Qualité logicielle et spécications algébriques c 2005-2008 Frédéric Peschanski UPMC Paris Universitas 24 février 2008 c 2005-2008 Frédéric
Plus en détailDiagramme de classes
Diagramme de classes Un diagramme de classes décrit les classes et leurs relations (associations, généralisation/spécialisation, ). classe association méthodes attributs héritage Diagramme de classes :
Plus en détailchapitre 4 Nombres de Catalan
chapitre 4 Nombres de Catalan I Dénitions Dénition 1 La suite de Catalan (C n ) n est la suite dénie par C 0 = 1 et, pour tout n N, C n+1 = C k C n k. Exemple 2 On trouve rapidement C 0 = 1, C 1 = 1, C
Plus en détailBases de Données. Plan
Université Mohammed V- Agdal Ecole Mohammadia d'ingénieurs Rabat Bases de Données Mr N.EL FADDOULI 2014-2015 Plan Généralités: Définition de Bases de Données Le modèle relationnel Algèbre relationnelle
Plus en détailAnnexe : La Programmation Informatique
GLOSSAIRE Table des matières La Programmation...2 Les langages de programmation...2 Java...2 La programmation orientée objet...2 Classe et Objet...3 API et Bibliothèque Logicielle...3 Environnement de
Plus en détailMEGA Application Portfolio Management. Guide d utilisation
MEGA Application Portfolio Management Guide d utilisation MEGA 2009 SP5 R7 2ème édition (novembre 2012) Les informations contenues dans ce document pourront faire l objet de modifications sans préavis
Plus en détailBaccalauréat technologique
Baccalauréat technologique Épreuve relative aux enseignements technologiques transversaux, épreuve de projet en enseignement spécifique à la spécialité et épreuve d'enseignement technologique en langue
Plus en détailDéveloppement d'un projet informatique
Développement d'un projet informatique par Emmanuel Delahaye (Espace personnel d'emmanuel Delahaye) Date de publication : 27 janvier 2008 Dernière mise à jour : 25 avril 2009 Cet article présente un certain
Plus en détailObjectif : Passer de l analyse métier et fonctionnelle à la définition des applications qui
Formation PARTIE 1 : ARCHITECTURE APPLICATIVE DUREE : 5 h Objectif : Passer de l analyse métier et fonctionnelle à la définition des applications qui automatisent les fonctions Définir une architecture
Plus en détailCommuniqué de Lancement
Direction du Marketing Produits Sage - Division Mid Market Communiqué de Lancement Rapprochement Bancaire 1000 Produit : Rapprochement Bancaire 1000 Bases de Données : Oracle - MS/SQL Server Microsoft
Plus en détailRésumé CONCEPTEUR, INTEGRATEUR, OPERATEUR DE SYSTEMES CRITIQUES
Aristote ----- Cloud Interopérabilité Retour d'expérience L A F O R C E D E L I N N O V A T I O N Résumé Les systèmes d'information logistique (SIL) sont des outils qui amènent des gains de productivité
Plus en détailBut de cette introduction à la gestion de projets :
But de cette introduction à la gestion de projets : Présenter quelques méthodes de conception logicielle. Replacer la conception de bases de données dans un contexte plus vaste. Présenter quelques méthodes
Plus en détailRECOMMANDATION UIT-R SM.1048. (Question UIT-R 68/1)
Rec. UIT-R SM.1048 1 RECOMMANDATION UIT-R SM.1048 DIRECTIVES DE CONCEPTION D'UN SYSTÈME DE BASE POUR LA GESTION AUTOMATISÉE DU SPECTRE (Question UIT-R 68/1) Rec. UIT-R SM.1048 (1994) L'Assemblée des radiocommunications
Plus en détailProjet de Veille Technologique
Projet de Veille Technologique Programmation carte à puce - JavaCard Ing. MZOUGHI Ines (i.mzoughi@gmail.com) Dr. MAHMOUDI Ramzi (mahmoudr@esiee.fr) TEST Sommaire Programmation JavaCard Les prérequis...
Plus en détailDescription de la formation
Description de la formation Modalités Ce parcours de formation est un parcours en alternance, d une durée de 2ans, à raison d une semaine de formation par mois, soit 770 heures et de trois semaines de
Plus en détailCours de Java. Sciences-U Lyon. Java - Introduction Java - Fondamentaux Java Avancé. http://www.rzo.free.fr
Cours de Java Sciences-U Lyon Java - Introduction Java - Fondamentaux Java Avancé http://www.rzo.free.fr Pierre PARREND 1 Octobre 2004 Sommaire Java Introduction Java Fondamentaux Histoire de Java Machine
Plus en détailIndustrialiser la chaîne complète de fabrication 1ère partie - Les bénéfices de la solution logicielle IBM VisualAge Pacbase / Rational
IBM Software Group Industrialiser la chaîne complète de fabrication 1ère partie - Les bénéfices de la solution logicielle IBM VisualAge Pacbase / Rational Fernard Bonaguidi fernand.bonaguidi@fr.ibm.com
Plus en détailBesoins utilisateurs. Quelle démarche pour passer des besoins au code? Code. chapitre1 UNIFIED MODELING LANGUAGE. package LogiqueMetier.
chapitre1 Besoins utilisateurs Quelle démarche pour passer des besoins au code?? UNIFIED MODELING LANGUAGE package LogiqueMetier.Gestion; import LogiqueMetier.Catalogue.Livre; import java.util.*;public
Plus en détail