REFERENTIEL NORMATIF du CNES

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

Download "REFERENTIEL NORMATIF du CNES"

Transcription

1 REFERENTIEL NORMATIF du CNES Référence : Méthode et Procédure APPROBATION Président du CDN ; date et nom :

2

3 Page i.1 PAGE D'ANALYSE DOCUMENTAIRE TITRE : MOTS CLES : UML Analyse Conception Modélisation RESUME : Ce document MPM décrit les règles et recommandations qui concernent la mise en œuvre du formalisme de description UML, applicable en analyse et en conception de logiciel. SITUATION DU DOCUMENT : Ce document fait partie de la collection des Méthodes et Procédures associées au Référentiel Normatif du CNES (ECSS et MPM). Ce document est affilié à l'assurance Produit des Logiciels. NOMBRE DE PAGES : 59 LANGUE : Française Progiciels utilisés / version : Word 97 SERVICE GESTIONNAIRE : Délégation à l'assurance de la Qualité du Centre Spatial de Toulouse (DTS/AQ) AUTEUR(S) : DATE : 07/10/00 Jean-Charles POUPLARD / Jean-Alain VERON / Isabelle ZENONE RELECTURE / CONTROLE : Pour ACCORD : Le Président du Comité Technique de Normalisation : CNES 2000 Reproduction strictement réservée à l'usage privé du copiste, non destinée à une utilisation collective (article 41-2 de la loi n du 11 Mars 1957).

4 Page i.2 PAGES DES MODIFICATIONS VERSION DATE PAGES MODIFIEES OBSERVATIONS 1 07/10/00 Document initial Document élaboré avec le support de Virtualité Réelle (T. Leydier)

5 Page i.3 SOMMAIRE 1. INTRODUCTION OBJET DOMAINE D'APPLICATION REGLES APPLICABLES GÉNÉRALITÉS VUE CAS D UTILISATION ACTEURS STRUCTURATION DES CAS D UTILISATION DIAGRAMME DES CAS D UTILISATION DESCRIPTION TEXTUELLE DES CAS SCÉNARIOS DIAGRAMME DE COLLABORATION DIAGRAMME DE SEQUENCE AUTRES DIAGRAMMES DE LA VUE DES CAS D UTILISATION VUE LOGIQUE STRUCTURATION DE LA VUE LOGIQUE DIAGRAMMES DE CLASSES, DIAGRAMMES D OBJETS CLASSES OPÉRATIONS ET ATTRIBUTS ASSOCIATIONS VUE DYNAMIQUE GÉNÉRALITÉS DIAGRAMMES ETATS-TRANSITION DIAGRAMMES D ACTIVITÉS VUE DES COMPOSANTS VUE DEPLOIEMENT ANNEXE : INDEX DES REGLES... 51

6

7 Page 1 1. INTRODUCTION Le document «Erreur! Source du renvoi introuvable.» est rattaché à la norme RNC-ECSS-Q-80 «Assurance qualité des logiciels». 2. OBJET Ce document MPM décrit les règles et recommandations qui concernent la mise en œuvre du formalisme de description UML, applicable en analyse et en conception. Ce document est compatible UML 1.3. Il fait partie du référentiel documentaire DDO (Démarche de développement du logiciel orienté objet). 3. DOMAINE D'APPLICATION Ce document est conçu à l'attention de plusieurs types d utilisateurs : le chef de projet qui doit connaître les activités menées lors de l analyse et de la conception, faire les choix nécessaires à partir des règles générales en fonction des spécificités du projet et s'assurer de la mise en œuvre des dispositions retenues, le responsable qualité qui doit avec le chef de projet valider les règles relatives à l analyse et la conception, extraire les recommandations pertinentes pour son projet et éventuellement adapter et compléter les règles en fonction du contexte, le responsable technique qui est chargé de l encadrement technique de l analyse et de la conception, l ingénieur qualité qui doit appliquer les règles de contrôle de la qualité relatives à l analyse et la conception, les équipes chargées de l analyse et/ou de la conception du logiciel qui doivent appliquer les règles et les recommandations retenues.

8 Page 2 4. REGLES APPLICABLES 4.1. GENERALITES Généralités.Vue On utilisera au maximum le concept de vue afin d améliorer la qualité des modèles Le concept de vue apparaît dans UML à plusieurs niveaux : à un niveau macroscopique où l on peut représenter le logiciel sous 5 points de vue standard : vue des cas d utilisation, vue statique, vue dynamique, vue des composants, vue du matériel et des tâches. à un niveau microscopique où il est souvent possible d utiliser plusieurs points de vues, plusieurs éléments de modélisation, plusieurs syntaxes pour représenter les mêmes concepts ou des concepts complémentaires. On utilise généralement un point de vue principal pour conduire une analyse ou une conception : c est le point de vue des utilisateurs en analyse ou le point des concepteurs en conception. On peut compléter une modélisation en utilisant d autres points de vue : par exemple, utiliser le point de vue de l exploitant du logiciel lors de l analyse ou utiliser le point de vue des mainteneurs en phase de conception. A un niveau macroscopique, les vues permettent de mettre l accent sur des visions différentes : elles réduisent la complexité et améliorent la compréhension A un niveau microscopique, le complément par utilisation d autres points de vue permet d améliorer la complétude Beaucoup d incohérences possibles entre les vues sont levées par les outils ou par la syntaxe d UML Généralités.Démarche La modélisation UML sera guidée par la mise en œuvre d une démarche d analyse et de conception afin d éviter toute dérive dans la modélisation UML est un formalisme qui véhicule une sémantique précise mais qui n est pas attaché à une démarche d analyse ou de conception. Il est essentiel de suivre une démarche précise en analyse ou en conception qui va guider précisément l utilisation d UML. Notamment : - Comment utiliser les différentes vues : vue des cas d utilisation, vue logique, vue dynamique, vue des composants, vue déploiement? - Comment utiliser les différents diagrammes? - Comment choisir entre des diagrammes équivalents?

9 Page 3 Exemples - Dans une approche itérative, doit on reprendre, raffiner, compléter ou supprimer un élément de modélisation décrit dans l étape précédente? un acteur présent dans la vue des cas d utilisation, peut se retrouver en tant que classe dans la vue logique un «objet» apparaissant dans un diagramme de séquence pourra apparaître dans la vue logique sous forme de classe Modèle.Exploitation Tout modèle produit devra être facilement exploitable afin d améliorer la communication dans les équipes et faciliter la maintenabilité Le modèle sera structuré à l aide des paquetages : on évitera les organisations «en râteau». On devra pouvoir imprimer tout diagramme sur papier A4, avec une police de caractère standard de taille 8 au minimum. On devra pouvoir visualiser tout diagramme sur un écran 17 sans utilisation des barres de défilement. Dans chaque diagramme, on limitera le nombre d éléments à une dizaine : par exemple, pas plus de 10 classes dans un diagramme de classes, etc. On limitera le nombre de cas d utilisation à un dizaine par sous-systèmes. Tout autre opération courante sur le modèle devra être facilité : recherche, réorganisation, etc.. Modèle.Gestion On analysera les besoins en termes de gestion des modèles (archivage, livraison, gestion de version, gestion de modification) avant de démarrer une modélisation car ces besoins peuvent contraindre l utilisation d UML Les besoins en termes de gestion concernent la granularité de gestion des modèles, la réutilisabilité des modèles. On analyse ces besoins en essayant de voir comment ils peuvent être couverts par les outils. Des besoins en gestion de configuration peuvent conduire à une certaine utilisation des vues et des paquetages

10 Page VUE CAS D UTILISATION La vue des cas d utilisation concerne principalement la phase d analyse : c est la première vue que l on produit et elle guidera l ensemble de la démarche. Elle consiste à décrire ce que fait le logiciel par le biais de la description de scénarios d utilisation. Cette vue est composée principalement de trois types de diagrammes UML : les diagrammes de cas d utilisation les diagrammes de séquence les diagrammes de collaboration. Cette vue peut également contenir d autres diagrammes UML comme des diagrammes de classes qui illustrent la participation des objets aux cas d utilisation ACTEURS VueCas.Mécanismes On définit des mécanismes pour compléter le modèle. Les mécanismes sont : soit des acteurs identifiés à la périphérie du logiciel, mais qui en font partie (on parle d acteurs d interface) soit des agents logiciels (comme des processus) qui sont responsables du déclenchement de cas d utilisation soit un autre sous-système pour le sous-système courant. les mécanismes servent à la modélisation des cas d utilisation même s ils ne sont pas définis en standard dans UML Exemples Dans un logiciel bord de gestion de plate-forme : les gestionnaires identifiés dès la description des exigences comme le gestionnaire de trajectoire sont des agents logiciels un gestionnaire de bus sera un acteur d interface : il fait partie du logiciel et joue un rôle d interface et non un rôle fonctionnel

11 Page STRUCTURATION DES CAS D UTILISATION VueCas.Structuration La vue des cas d utilisation sera structurée à l aide de paquetages afin d améliorer sa lisibilité. On décrira un paquetage minimum par sous-système On utilisera la décomposition en paquetages pour distribuer le travail de modélisation On pourra utiliser les paquetages pour multiplier les points de vues Chaque paquetage ainsi décrit contiendra un ensemble de cas d utilisation. On appellera ce paquetage un «paquetage de cas». Les outils permettent une bonne gestion des paquetages Les outils supportent au niveau paquetage des éléments de modélisation supplémentaires : on pourra par exemple associer des diagrammes de classe aux paquetages Cas.Paquetage On utilisera les paquetages pour organiser les acteurs Trois solutions sont envisageables : 1 - On regroupera dans un même «paquetage de cas» les acteurs et les cas d utilisation qui sont connectés afin d améliorer la cohérence : Les acteurs et les cas d utilisation vont intervenir dans plusieurs «paquetage de cas». Afin de respecter le principe de limitation du couplage entre les «paquetages de cas», il faut répartir les acteurs dans les «paquetages de cas» où sont rassemblés les cas d utilisation dont les scénarios font intervenir les dits acteurs. Des conflits peuvent apparaître lorsque un acteur est partagé entre deux cas qui sont placés dans deux «paquetage de cas» distincts : soit il est possible de déplacer un des cas, ou d unifier les «paquetages de cas» et le conflit disparaît ; soit cela n est pas possible : on analyse alors quel est le rôle prépondérant de l acteur, par rapport à chacun des cas. 2 - On rassemblera a priori tous les acteurs dans un même paquetage en créant la notion de «paquetage d acteurs». 3 On combinera les deux solutions précédentes. Le regroupement améliore la cohésion et la lisibilité Ce travail structure clairement le modèle

12 Page 6 Ce travail oblige une réflexion sur les rôles profonds des acteurs et permet de bien cerner leurs interactions avec le logiciel VueCas.HiérarchieGénérale L identification des cas donnera lieu à la description formelle d une hiérarchie. La hiérarchie présente, par sous-système, la décomposition en «paquetages de cas» et «cas d utilisation» ; elle fait apparaître les acteurs ; elle montre les diagrammes développés. La description formelle de la hiérarchie fera partie de la documentation du modèle. Cette hiérarchie est initialisée en début d analyse et raffinée au cours de l analyse Cette vue va servir à organiser la documentation «papier» des cas d utilisation : elle sera incluse en début de la documentation d analyse et définira le plan de cette documentation.

13 Page DIAGRAMME DES CAS D UTILISATION <<communique>> Point d extension autre Cas décrit Acteur interne Acteur <<Include>> <<Extend>> Cas utilisé Cas complémentaire Les diagrammes de cas d utilisation mettent en jeu des cas d utilisation et des acteurs. Les acteurs sont en dehors du système à modéliser et interagissent avec ce système par des messages : les message de type <<communique>>. On peut décider d orienter ou de ne pas orienter la relation <<communique>>. Lorsque la relation est orientée, on fait la distinction entre acteur actif qui déclenche un scénario, et acteur passif qui reçoit simplement un message. Il est possible d utiliser un mécanisme : on utilise alors un stéréotype particulier pour le repérer. Un cas d utilisation représente une séquence d actions que le système va exécuter lorsqu il interagit avec un acteur. Cette séquence d action est orientée par la vue que l utilisateur a du logiciel et des services qu il en attend : elle peut décrire des parties propres au fonctionnement interne du logiciel s il s agit de préciser l interaction entre l acteur et le système. Dans ce cas, cette précision n est pas vue comme une description du «COMMENT» mais comme un complément au «QUOI» qui sera éventuellement remis en cause lors de la conception. Le compartiment optionnel «Point d extension» permet de préciser des extension complémentaires propre à un cas. On peut structurer les diagrammes de cas en utilisant deux types de relations : La relation <<Include>> exprime l idée qu un cas d utilisation va utiliser un autre cas d utilisation pour s exécuter.

14 Page 8 La relation <<Extend>> exprime l idée que l on peut compléter l exécution du cas d utilisation courant par des actions complémentaires afin de prendre en compte une alternative. On peut également décrire des hiérarchies de généralisation de cas d utilisation. Cas.Evenements La représentation graphique des cas d utilisation fera apparaître les principaux événements déclenchant Les principaux événements déclenchant seront présentés sur le diagramme à l aide des labels associés aux liens de type communique. On utilisera l orientation des flèches s il y a lieu, pour désigner le récepteur de l événement. On évitera cependant à ne pas nuire à la lisibilité des diagrammes en multipliant les labels à valeur ajoutée nulle. cette information améliore la sémantique des diagrammes de cas

15 Page DESCRIPTION TEXTUELLE DES CAS Cas.Textuelle Chaque cas sera décrit dans le détail sous forme textuelle selon un modèle de description standard La trame comprendra entre autres : L identification du cas d utilisation : numéro d ordre, nom. Cette identification est utilisée en traçabilité. Les acteurs et mécanismes impliqués. Pour les cas d utilisation reliés par des relations de type «Include» ou «Extend», cette rubrique peut être vide. Le contexte d exécution du cas : le contexte opérationnel dans lequel le cas d utilisation va s exécuter. Le point de vue adopté : est-ce le point de vue externe? le point de vue d un développeur? Le déclenchement : quel est l événement (ou les événements) qui déclenche(nt) le cas d utilisation? Les préconditions : on décrit l état du logiciel ou du système avant le déroulement du cas. Cet état se limite généralement à la description des données qui sont utilisées par le cas d utilisation. détaillée du cas : on décrit précisément les interactions acteurs / logiciels, les messages échangés, les actions effectuées. La description fait apparaître des alternatives (variantes ou exceptions) ; ces alternatives sont décrites en fin de description textuelle des cas d utilisation. Les postconditions : on décrit l état du logiciel ou du système après le déroulement du cas. On se limite généralement à la description des données qui sont modifiées par le déroulement du cas d utilisation. Exceptions : on décrit le traitement éventuel des exceptions levées. Une exception est assimilée à un cas d erreur ou à un fonctionnement dégradé. Variantes : on décrit le traitement associé aux variantes détectées. Une variante correspond à un comportement alternatif au comportement standard, sans être une exception. Un modèle de cas est décrit page suivante. la description textuelle des cas d utilisation est très riche par rapport à la vue graphique elle prépare à la recherche des objets suivre une trame standard oblige une certaine rigueur de description

16 Page 10 FICHE DE CAS D UTILISATION1&2 Cas d utilisation Acteurs Contexte d exécution Point de vue Préconditions Déroulement normal détaillée Postconditions Déroulement alternatif Exceptions Variantes 1 Ceci est un exemple de formulaire de description textuelle des cas. Chaque projet devra définir son propre formulaire et pourra ainsi rajouter des champs comme «Contraintes», «Besoins non fonctionnels» 2 La forme précise de cette description devra être adaptée en fonction des post-process effectués sur ces cas : analyse de vocabulaire, traçabilité, etc. On pourra ainsi éviter un représentation sous forme de tableaux, insérer des sentinelles, etc.

17 Page 11 Cas. Lors de la description textuelle des cas d utilisation et des scénarios, on évitera les tournures impersonnelles et les verbes à la forme passive On n utilisera pas de forme impersonnelle, ni de forme passive sans préciser qui fait l action. Une formulation impersonnelle ou passive cache les acteurs, ce qui nuit à l'identification des responsabilités et des objets. Les formes impersonnelles sont moins précises Exception Lors de l analyse, la forme passive peut parfois être utilisée pour exprimer une contrainte ou un besoin en termes d objectifs pour lequel on ne connaît pas l agent : le décrire serait une surspécification qui risque d empiéter sur le conception. Un exemple de ce type est montré dans les cas d utilisation décrits dans l annexe F. Cas.DescMin On utilisera un texte court pour les descriptions : On essaiera de se limiter à 3 ou 4 pages au format A4 pour le cas d utilisation complet. Des méthodes de réduction de texte standard peuvent être appliquées : supprimer les adverbes inutiles, supprimer les constructions littéraires, supprimer les paraphrases. : une description courte limite les incohérences une description courte permet d éviter les paraphrases une description courte permet d éviter le style littéraire Exception : On pourra utiliser la paraphrase pour faciliter l accès des néophytes aux documents pour les termes et concepts qui ne sont pas considérés comme acquis SCENARIOS Un scénario est une instance de cas d utilisation : dans un scénario, l alternative est exclue ou très limitée. La modélisation des scénarios devra être effectuée soit de façon textuelle, soit de façon graphique.

18 Page 12 La modélisation textuelle d un scénario s effectue en complétant la rubrique «textuelle des cas d utilisation». Les diagrammes utilisés pour modéliser les scénarios sont les diagrammes de séquence et les diagrammes de collaboration On donne par la suite une liste de règles pour choisir le type de diagramme le plus approprié. De façon générale, on peut décomposer un scénario soit : en interactions entre objets : on suit alors la voie qui conduit à un diagramme de collaboration en séquences d activités : on préfère alors le diagramme de séquence Dans certains cas, les deux diagrammes pourront être décrits car il seront complémentaires. Scénarios.PointDeVue La modélisation d un scénario doit s effectuer selon un point de vue identifié Le point de vue choisi doit être décrit : dans le cas d une modélisation graphique, on devra faire figurer ce point de vue sous forme de note attachée au diagramme. Ce point de vue oriente le diagramme et illustre ce sur quoi on veut mettre l accent. Un diagramme de séquence ou un diagramme de collaboration n exprime pas tout le scénario mais seulement un point de vue Scénarios.NiveauPrécision Pour chaque description graphique de scénario, on devra définir a priori son niveau de précision Le niveau de précision exigé peut être faible ou fort. S il est faible, on voudra simplement représenter graphiquement un enchaînement d événements ou de messages, ou montrer un lien de collaboration entre objets. En phase d analyse, on a généralement un besoin de précision faible, sauf pour exprimer des contraintes opérationnelles limitées. S il est fort, on voudra présenter des contraintes de synchronisation, de délais très précises ou présenter le mode de dialogue entre objets. Cette précision pourra être intéressante en conception. Le niveau de précision n influe pas sur le type de diagramme choisi, mais sur l utilisation du formalisme : niveau faible : on utilisera pour chaque diagramme les éléments de modélisation les plus simples : par exemple dans un diagramme de séquence, on n utilisera pas les dates, les activités, etc.

19 Page 13 niveau fort : on pourra utiliser toute la puissance d UML. Par exemple, on utilisera toutes les finesses de représentation d un diagramme de séquence (dates, activités) La modélisation proposée par UML pour les interactions est très riche : ce serait une erreur d utiliser cette richesse indépendamment du besoin de précision requis pour la description SeqCollab.Cohérence Lorsque la cohérence entre un diagramme de collaboration et un diagramme de séquence n est pas assurée par l outil de modélisation, on devra choisir entre un diagramme de séquence ou un diagramme de collaboration Les diagrammes de séquence et de collaboration expriment les mêmes idées avec des nuances. Assurer la cohérence signifie par exemple, que le changement de l ordonnancement des actions sur un diagramme de séquence doit entraîner une re-numérotation des séquences sur le diagramme de collaboration. Dans le cas où l outil support assure la cohérence, on pourra en revanche multiplier les diagrammes ce qui permet de multiplier les points de vue. La duplication d information est dangereuse si la cohérence n est pas assurée automatiquement La possibilité d avoir divers points de vue cohérents est un plus incontestable

20 Page DIAGRAMME DE COLLABORATION Le diagramme de collaboration met l accent sur l interaction entre les objets : on relie les objets et acteurs qui communiquent par des flèches, en indiquant le message et éventuellement son numéro d ordre dans la séquence. 1 : Message 1 Acteur : Objet A Objet A L2 {local} 2 : Message 2 Objet B : Classe B 5 : Message 4 L1 {global} 3 : Message 3 Objet C 4 : Réflexif Objet BC Il est possible de représenter sur un diagramme de collaboration d autres informations : on représente les agrégations par une boîte englobante : sur le schéma, les objets B et C sont rassemblés dans l agrégation objet BC on peut représenter les classes auxquelles appartiennent les objets dans le cas où ces classes ont été définies : l objet B appartient à la classe B on peut présenter la notion d instance multiple pour un objet : c est le cas pour l objet A. on peut associer d autres propriétés aux objets comme leur persistance ou leur activité (les objets actifs ont leur propre fil (thread) et sont représentés avec un contour épais) on peut définir le mode de transmission de chaque message : simple (le cas général), synchrone, asynchrone, avec time out, etc. La différence entre modes de transmission est marquée par le type de flèche. on peut préciser la nature des liens entre objets : s agit-il d un lien par donnée membre, par paramètre, par donnée globale?

21 Page 15 la séquence peut être exprimée de façon assez complète : on peut préciser des conditions de synchronisation, des séquences parallèles, etc. SeqCollabo.Communication On choisira un diagramme de collaboration plutôt qu un diagramme de séquence lorsque l on veut mettre en évidence la communication entre les objets plutôt que l organisation des événements dans le temps Il y a deux façons d exprimer la communication dans un diagramme de collaboration : de façon simple et immédiate : en exprimant les liens entre les acteurs et les objets. Ces liens sont la base de la communication ; ils se traduisent par des messages échangés entre les objets de façon plus élaborée, en précisant sur le diagramme des informations qui viennent expliquer la nature de la collaboration. Par exemple : le mode de transmission ou de réception de ces messages : simple, synchrone, asynchrone, dérobant ou avec time-out la nature des liens entre objets : s agit-il d un lien par donnée membre, par paramètre, par donnée globale? les conditions de déclenchement des messages l organisation graphique des objets sur un diagramme de collaboration permet de mettre en lumière les types de collaboration les diagrammes de séquence permettent de représenter les messages échangés mais sont pauvres si l on veut décrire le mode de transmission ou d échange SeqCollabo.CompositeActif On choisira un diagramme de collaboration plutôt qu un diagramme de séquence lorsque l on veut mettre en évidence la participation d un objet composite ou d un objet actif dans un scénario Les diagrammes de collaboration permettent de représenter l agrégation d objets en rassemblant différents objets dans une boîte. Les diagrammes de collaboration permettent également de mettre en évidence la participation d un objet actif dans un scénario Un objet actif possède son propre fil (thread) de contrôle. On peut le représenter sur un diagramme de séquence par un trait épais. Un diagramme de collaboration peut ainsi être utilisé pour donner une première vue de l organisation des objets, comme on pourrait le faire dans un diagramme de classe.

22 Page 16 Il est difficile d exprimer une relation de composition sur un diagramme de séquence Il est difficile d exprimer l activité éventuelle d un objet (au sens actif ou passif) sur un diagramme de séquence Collaboration.Simplicité On n utilisera pas, sauf fort besoin de précision exigé, les notions de message précédent, de condition de déclenchement, de récurrence, d actions et de résultats que l on peut associer aux messages. Il est possible dans UML de décrire très précisément les messages échangés en leur associant des notions élaborées comme : le message précédent une condition de déclenchement une récurrence de déclenchement une action à effectuer lors de la transmission du message un résultat associé à cette action Par exemple, le label d un message pourra être : MessagePrec / [ x > 10 ] 4 : y :=search () qui signifie que : le message d ordre de séquence 4 ne sera déclenché que si le MessagePrec a été déclenché et x>10 de plus, lors du déclenchement, la fonction search viendra mettre à jour la donnée y Rares sont les analystes et les concepteurs qui connaissent ces possibilités Tous les outils ne supportent pas cette richesse d expression Cette richesse d expression peut conduire à des incohérences : incohérence entre précédent et numérotation des séquences Si l on a besoin de ce type d information, on pourra préférer l utilisation des diagrammes états transitions qui seront plus formels Cela alourdit les diagrammes

23 Page DIAGRAMME DE SEQUENCE Les objets : Objet A : Objet C Acteur t0 Message 1 [x>0] Message 2 : Objet B t1-t0<100 ms [x <=0] Message 3 Réflexif t1 Message 4 Le temps Un diagramme de séquence montre les interactions entre les objets en fonction du temps. Les objets communiquent par messages : un message va d un objet vers un autre. Il peut être éventuellement réflexif. Une ligne de message horizontale montre une transmission immédiate du message ; une ligne inclinée montre une transmission avec un délai. Le déclenchement d un message peut être conditionné : message 2 n est effectivement déclenché que si x>0. Chaque objet a une ligne de vie symbolisée par un trait pointillé. L objet B est créé par le déclenchement du message 2 et détruit lors de l exécution du scénario : la croix symbolise sa fin de vie. Les boîtes blanches représentent les périodes de temps au cours desquelles l objet est actif (on parle d activation). Il est possible d associer des dates comme t0 et t1 et des contraintes sur les dates comme (t1- t0<100ms).

24 Page 18 SeqCollabo.Enchaînement On choisira un diagramme de séquence plutôt qu un diagramme de collaboration lorsque l on veut mettre en évidence l organisation des événements dans le temps et l enchaînement des événements du scénario La visualisation du temps et des séquences est immédiate sur un diagramme de séquence La visualisation des créations et des destructions d instances est immédiate Séquence.PrécisionFaible Lorsque le besoin de précision exigé pour un scénario est faible, on utilisera une expression très simplifiée pour les diagrammes de séquence On focalisera le diagramme sur les événements et leur enchaînement par rapport à leur réception On n utilisera pas les lignes de vie, le temps et les dates, les activités. On ne fera pas la distinction entre classes et objets. On appellera ce type de diagramme un diagramme de suivi des événements. Ce type de diagramme est très utile en analyse lorsque le besoin de précision est faible Séquence.ConstrDestr Lorsque le besoin de précision exigé est fort, les lignes de vie devront représenter les constructions et destructions d objets Cette règle concerne les objets transitoires qui sont construits et détruits dans le scénario décrit dans le diagramme. On peut ainsi facilement distinguer les objets transitoires Séquence.Activation Lorsque le besoin de précision exigé est fort, on utilisera les durées d activation L activation est utilisée pour représenter la durée pendant laquelle les objets exécutent des actions qui sont soient liées à la réception d un message entrant à son traitement, soit liées à la préparation d un message sortant.

25 Page 19 on peut ainsi analyser les durées d exécution et préparer la décomposition en tâches et fils (threads) Séquence.DatesEtTemps Lorsque le besoin de précision exigé est fort, on utilisera les lignes de message non horizontale, les dates et les contraintes de date, pour représenter des types de synchronisation ou de communication très particuliers Une ligne de message horizontale montre une transmission immédiate du message ; une ligne penchée montre une transmission avec un délai. Il est possible d associer des dates sur l axe des temps et d exprimer des contraintes sur ces dates. on peut ainsi formaliser des contraintes temporelles très précises Séquence.Branchements On évitera les branchements afin de ne pas compliquer les diagrammes de séquence Les branchements permettent de rajouter des conditions dans les diagrammes de séquence afin de décrire des alternatives. On évitera ce type de tournure qui complique la mise en séquence : on préférera se concentrer sur le scénario nominal en décrivant les alternatives à l aide de notes associées au diagramme. Tous les outils ne supportent pas la notion de branchement Les branchements impliquent la description de conditions, ce qui complique les diagrammes

26 Page 20 Séquence.OrgStandard Un diagramme de séquence doit avoir une organisation standard afin d être robuste et facilement compréhensible Un diagramme exploitable est un diagramme facilement compréhensible, maintenable, qui exprime une séquence que l on peut comprendre et assimiler à première vue. Parmi les organisations standard, on peut citer : l approche par contrôleur : dans cette approche, le premier objet contrôle tous les suivants l approche par délégation : dans cette approche, chaque objet contrôle l objet suivant auquel il délègue une partie des traitements l approche mixte contrôleur - délégation : dans cette approche, on combine les deux schémas précédents sans mélanger contrôle et délégation Les tournures standard sont facilement compréhensibles Les tournures standard sont robustes

27 Page AUTRES DIAGRAMMES DE LA VUE DES CAS D UTILISATION VueCas.DiagObjetPart On pourra compléter la vue des cas d utilisation par des diagrammes de classe qui montrent les objets participants à un cas afin de montrer les liens entre les objets et les besoins exprimés par l utilisateur Ces diagrammes sont des diagrammes de classes, où l on montre par cas d utilisation la structure et les relations des objets participants aux cas d utilisation. Pour ces diagrammes, on ne fera apparaître que les informations directement liées aux cas d utilisation auxquels ils sont attachés. Ils permettent par exemple lors d une revue de fin de spécification de donner une première vue aux utilisateurs des objets mis en œuvre, ou d expliquer aux utilisateurs l introduction de certains objets. Cette utilisation ne devra pas cependant être exagérée : en effet, les classes doivent être identifiées en prenant les cas dans leur globalité, et non pas cas par cas. Ce diagramme doit donc être réalisé après l identification des classes de plus, ce diagramme sera délicat à maintenir en phase de conception et encore plus lors de la maintenance enfin, ce diagramme ne pourra pas être considéré comme un élément de traçabilité entre la vue des cas d utilisation et la vue logique Dans ce contexte, une bonne solution est de produire ce diagramme dans un objectif de présentation, de description ou de synthèse précis (pour préparer une revue par exemple) en phase d analyse et de ne pas le conserver dans la documentation du modèle.

28 Page VUE LOGIQUE La vue logique est la représentation formelle de la décomposition statique. Elle est essentiellement composée des diagrammes de classes et d informations textuelles qui sont associées aux éléments modélisés : sous-systèmes, paquetages, classes, opérations, attributs, relations STRUCTURATION DE LA VUE LOGIQUE Logique.Décomposition Structurer la vue logique en paquetages en respectant les décompositions en sous-systèmes et catégories La notion de paquetage en UML permet de structurer les vues : mais cette notion n a de sens qu en termes de structuration du modèle. En ce qui concerne la vue logique, on peut dire que les paquetages vont permettre de structurer le modèle logique. Le principe de cette règle consiste à faire coïncider la structuration de la vue logique (niveau modèle) et la structuration de la décomposition statique (niveau conceptuel). Les règles à suivre pour décomposer statiquement le logiciel sont décrites dans l annexe C de la MP DDO "Principes de mise en œuvre des concepts objets". La décomposition statique fait apparaître des hiérarchies : systèmes, sous-systèmes, catégories, classes. La vue logique devra donc être structurée selon ces mêmes principes. UML ne contient pas le concept de catégorie, mais propose des stéréotypes associés aux paquetages

29 Page DIAGRAMMES DE CLASSES, DIAGRAMMES D OBJETS Mère +Visible:int = 10 # Protégé : float = 0.7 +Get (in x: int = 0) # Display () {abtrait} Classe Fille 1 Classe Fille 2 1 Classe Contenue Attributs Attributs Attributs Opérations Opérations Opérations + rôle Classe association Attributs Classe dépendante + rôle 2 1 Opérations Attributs Opérations Catégorie Classe reliée Attributs Opérations Objet : Classe dépendante Attributs Les diagrammes de classes représentent les classes, leurs propriétés et leurs relations. Les diagrammes d objets sont comparables aux diagrammes de classes mais représentent des instances. Chaque classe ou objet est représenté par une boîte qui contient des «compartiments». Le compartiment «nom» est le premier : il décrit le nom de la classe ou de l objet, auquel on peut joindre des propriétés comme «la classe est-elle abstraite ou pas?». On peut également utiliser un stéréotype pour identifier le type de la classe (exemple de la classe Mère). Les compartiments suivants sont des listes : on peut les utiliser pour décrire des listes d opérations, d attributs, de responsabilités, d exceptions, etc. Les outils apportent des limitations à l utilisation des listes et proposent généralement des listes standard. La description des attributs comprend un nom, un type, une valeur par défaut, une cardinalité. On peut préciser si l attribut est public (+), privé (-) ou protégé (#). Un attribut peut être dérivé d un autre attribut. Les outils utilisés peuvent proposer des représentations graphiques plus adaptées à la représentation de ces propriétés. La description des opérations comprend un nom, un type de retour, une liste de paramètres. On peut préciser si l opération est publique (+), privée (-) ou protégée (#). Pour chaque paramètre, on peut décrire un nom, un type, un mode (in, out ou in-out) et une valeur de défaut. On peut préciser si l opération est abstraite ou pas. Les outils utilisés peuvent là aussi proposer des représentations graphiques plus adaptées à la représentation de ces propriétés. Les classes peuvent être paramétrables.

30 Page 24 La description d une classe peut se limiter à son interface (classe d interface). Des classes particulières, les utilitaires sont utilisés pour rassembler des opérations de bas niveau afin d exprimer une notion de bibliothèque de fonction ou pour exprimer une cohésion de coïncidence. Lors de la description d un objet sur un diagramme de classe, on peut donner le nom de la classe associée : «objet : classe». Les diagrammes permettre de représenter les relations d héritage (entre mère et fille), les relations d agrégation, les associations, les compositions et les liens de dépendance. Les relations d héritage sont représentées par le lien de généralisation. Les agrégations peuvent être représentées par des liens caractéristiques : on peut également utiliser la notion d objet composite pour exprimer une contenance. Les associations supportent un nom, un rôle pour chaque extrémité et une cardinalité. On peut décrire des «qualifiers» associés aux associations qui sont des attributs spécifiques qui vont permettre de compléter la description des relations, ou qui vont préparer l implémentation. Lorsque la relation est complexe ou que de l information complémentaire doit lui être affectée, on peut attacher une classe à la relation. Les liens de dépendance peuvent être de différente nature : lien de traçabilité pour exprimer une dépendance entre deux éléments de modélisation correspondant à deux époques de la modélisation lien d instanciation lien d utilisation pour exprimer un appel, l utilisation d un attribut Enfin les liens de réalisation permettent d exprimer l implémentation (par exemple l implémentation d une interface). Classe.SousSystème Un diagramme de classes sera utilisé pour exprimer la décomposition en sous systèmes. Ce diagramme est le seul élément de modélisation associé au plus haut niveau de la vue logique. Les autres éléments sont associés aux paquetages fils. Ce diagramme est le diagramme introductif à la vue Classe.Paquetage Chaque paquetage pourra contenir des diagrammes de classe standard : le diagramme principal, le diagramme d interface ou le diagramme de synthèse

31 Page 25 Le premier diagramme de classe sera nommé «Principal». Il montrera l ensemble des classes ou catégories filles et leur principaux liens internes. Le deuxième diagramme de classe sera nommé «Interface». Il montrera l ensemble des relations entre les classes de la catégorie courante et les classes externes (n appartenant pas à cette catégorie). Le troisième diagramme de classe concerne les paquetages qui regroupent d autres paquetages (comme les sous-système) : il décrit les relations entre les paquetages contenus. Il sera nommé synthèse. En pratique, le diagramme principal sera systématique. Le diagramme d interface sera réservé à l expression de l interface d un paquetage afin de préparer l intégration de ce paquetage avec les autres parties du logiciel. On décrira par exemple systématiquement un paquetage d interface pour chaque sous système, ou par chaque unité d intégration (développement séparé réalisé en parallèle par une autre équipe par exemple). Le diagramme de synthèse est utilisé au sein d une même unité d intégration. On utilisera un seul paquetage de plus haut niveau pour exprimer l interface entre l ensemble des paquetages de l unité d intégration. Paquetage Externe 1 Paquetage Externe 2 Diagramme d interface Paquetage Paquetage Externe 3 Paquetage Interne 1 Paquetage Interne 2 Diagramme de synthèse Paquetage Interne 4 Paquetage Interne 3 la standardisation améliore la lisibilité : l ensemble du modèle est plus homogène la standardisation améliore la complétude : chaque analyste ou concepteur devra développer un diagramme principal et un diagramme d interface

32 Page 26 l objectif du diagramme «Principal» est de donner un point d entrée simple et uniforme à la catégorie pour exprimer ce qu elle contient l objectif du diagramme «Interface» est de détailler les relations entre les paquetages Classe.DiagSpec Des diagrammes de classes spécifiques pourront être ajoutés à tout paquetage afin d exprimer une idée ou d insister sur un élément de modélisation On pourra avoir par exemple : un diagramme associé à un scénario précis : on montre les classes qui participent au scénario et leurs liens un diagramme qui montre une hiérarchie d héritage un diagramme qui exprimer une agrégation un diagramme qui exprimera une relation les outils de modélisation assurent la cohérence entre les diagrammes différents points de vue contribuent à l amélioration de la qualité de l analyse ou de la conception Classe.Légereté On évitera d alourdir les diagrammes de classes par la présentation de toute la classe, de tous les attributs et de toutes les opérations UML permet de choisir pour chaque diagramme, pour chaque classe ou pour chaque objet, le niveau de détail de représentation, et plus précisément les opérations que l on veut présenter, les attributs que l on veut présenter, etc. On pourra par exemple limiter la vue graphique d une classe à son seul stéréotype et son nom. On ne visualisera pour une classe que les compartiments non vides. on pourra réserver la vue graphique pour les relations : héritage, agrégation, associations les attributs sont décrits dans la partie textuelle de la modélisation. Un diagramme avec un point de vue particulier pourra présenter certains attributs pour expliciter leur rôle les opérations vont apparaître plutôt sur les diagrammes de collaboration ou de séquence ou sur les diagrammes de classes éventuellement associés aux cas d utilisation.

33 Page 27

34 Page CLASSES La vue logique devra décrire les caractéristiques de chaque classe sous forme de rubriques afin de compléter les vues graphiques. On décrira notamment : le type de la classe : classe simple, métaclasse, classe abstraite son stéréotype UML, ses parents dans la relation d héritage la cardinalité de son ensemble d instance (instance unique ou non) son autonomie de traitement : classe active, passive la liste des attributs la liste des opérations la liste des relations auxquelles la classe participe Certaines informations sont déduites de la modélisation graphique (les relations par exemple). Les autres sont à renseigner par le biais de texte ou de boites de dialogue. Classe.Utilitaire Une bonne décomposition ne doit pas contenir de classe utilitaire, signe d un défaut de cohésion En UML, le concept d utilitaire est utilisé pour rassembler des données et des opérations dans une classe. Ces données et opérations deviennent alors globales, et peuvent être utilisées par toutes les autres classes. Les classes utilitaires sont marquées par le stéréotype utilitaire. On réservera ce concept à la réutilisation d une bibliothèque composée d un ensemble de fonctions. Une classe utilitaire exprime une cohésion très faible.

35 Page OPERATIONS ET ATTRIBUTS Opérations.Analyse En phase d analyse, on se contente de décrire des responsabilités afin de ne pas compliquer la modélisation La description de responsabilités pour une classe consiste à décrire des services rendus par la classe. Les services sont décrits avec suffisamment de précision afin de couvrir un besoin exprimé par les utilisateurs potentiels du service. A ce niveau, on ne décrit généralement pas de paramètres, pas de valeurs de retours, pas d attributs : les responsabilités sont souvent exprimés comme des verbes, avec ou sans complément. La description se limite donc à une liste de services : ces services pourront être traduits en conception par des opérations dans le cas ou l on conserve la même décomposition. On ne doit pas anticiper la phase de conception où l on transformera l ensemble des responsabilités, en un ensemble d opérations et d attributs Opérations.Conception En phase de conception, la vue logique devra décrire les caractéristiques de chaque opération afin d améliorer la complétude et préparer la phase de codage En phase de conception, on décrit précisément les opérations de chaque classe. Cette description est effectuée en fonction des possibilités de l outil support à la modélisation, de ses capacités en génération de code et du langage cible (C++, ADA, JAVA, autre). On décrira notamment : sa visibilité sa signature (type de retour, paramètres, mode de passage) le protocole d appel les exceptions éventuelles levées et traitées par l opération les préconditions et postconditions la description des opérations est utilisée pour générer les squelettes de code pour chaque fonction

36 Page 30 Attributs.Conception En phase de conception, la vue logique devra décrire les caractéristiques de chaque attribut afin d améliorer la complétude et préparer la phase de codage En phase de conception, on décrit précisément les attributs de chaque classe. Comme pour les opérations, cette description est effectuée en fonction des possibilités de l outil support à la modélisation, de ses capacités en génération de code et du langage cible (C++, ADA, JAVA, autre). On décrira notamment : sa visibilité et son mode («statique» par exemple) son type sa valeur par défaut (associé au constructeur par défaut = initialisation sur démarrage à froid) ses autres valeurs d initialisation possibles (initialisation sur démarrage à chaud, réinitialisation, etc.) un lien éventuel avec des opérations d accès la description des attributs est utilisée pour compléter la génération du code

37 Page ASSOCIATIONS Ce chapitre contient des règles propres à la mise en œuvre d UML lors de l utilisation de relations. Elles complètent les règles plus générales sur les associations décrites dans l annexe C de la MPM DDO Chapitre «Vérification». Associations.NomRôles Les noms de rôles doivent être uniques et distincts des noms des attributs de la classe opposée (i.e. de la classe située à l autre extrémité de l association). Toutes les associations issues d'une même classe doivent avoir, à leur extrémité, des noms de rôle différents et distincts des noms des attributs de la classe opposée. Pour éviter des conflits de nom (en particulier à la génération de code) : un rôle correspond implicitement à un attribut de la classe associée. Association.Classes Lors de la description d un association complexe, on utilisera une classe supplémentaire pour modéliser l association UML permet d associer une classe association à une association afin de préciser des propriétés complémentaires. Si un attribut est une caractéristique d'une association entre deux classes, il est plus lisible de le définir comme un attribut de la classe association et non de l'une des classes. Définir un attribut d'association dans une des classes est une implémentation possible qu'il est prématuré de considérer dans un diagramme d'analyse ou même de conception. Le diagramme est plus évolutif : en effet, si la cardinalité de l'association est transformée en "plusieurs-plusieurs", il n'est plus possible de conserver l'attribut de l'association dans l'une des classes. Exemple On définit l'association "télémesure" entre la classe "Satellite" et la classe "Station". Dans l'application considérée, l'association est 1-n, car un seul satellite peut envoyer de la TM à un ensemble de stations. Cette association est définie par une clé, qui permet à la station de décrypter les données encryptées par le satellite. Pour assurer la confidentialité des données (les stations sont localisées dans des pays différents), la clé est différente pour chaque couple (satellite, station ). Un modèle où l'attribut "clé" serait défini dans la classe station serait moins évolutif car la cardinalité de l'association ne pourrait pas être transformée en n-n (une station peut recevoir de la

38 Page 32 télémesure en provenance de plusieurs satellites et la clé n'est pas la même pour chaque satellite) 4.4. VUE DYNAMIQUE GENERALITES La vue dynamique consiste à compléter la vue logique et la vue des cas d utilisation par des informations plus précises qui visent à décrire la dynamique du logiciel et de certaines classes. En termes de modèles, la vue dynamique consiste généralement à compléter la vue statique par un ensemble de nouveaux éléments de modélisation : diagramme états - transitions diagramme d activités ou à compléter des diagrammes existants : diagramme de séquence diagramme de collaboration La rajout d éléments de modélisation pour exprimer la dynamique sera effectué à trois niveaux Niveau Classe : on décrit le fonctionnement interne d une classe Niveau Paquetage : on décrit le fonctionnement interne d un paquetage Niveau Logiciel ou Sous Système : on décrit le fonctionnement interne d un sous système ou le fonctionnement du logiciel complet VueDynamique.Dynamique Pour les objets dynamiquement complexes, les objets actifs ou pour les comportements complexes, une description précise de la dynamique sera effectuée avec des diagrammes d activité ou des diagramme états transitions Un objet actif est un objet qui possède son propre fil (thread) de contrôle. Un objet dynamiquement complexe est un objet qui présente des contraintes de synchronisation très précises concernant ses opérations. Un comportement complexe est un comportement qui fait intervenir des conditions externes multiples exprimées sous forme de réception d événements ou qui fait intervenir plusieurs fils (threads) ou tâches.

39 Page 33 VueDynamique.NiveauRigueur Pour chaque description dynamique effectuée, on devra définir a priori son niveau de rigueur exigé afin de choisir le moyen de représentation le plus adapté On peut définir deux niveaux de rigueur pour une description dynamique : niveau fort : il s agit de décrire très précisément la dynamique complète de la classe ; cette modélisation pourra éventuellement faire l objet d une preuve formelle ou d une génération de code niveau faible : il s agit de décrire une partie du comportement d une classe afin d apporter un complément d information Le choix du moyen de modélisation dépendra du niveau de rigueur déterminé : niveau fort : on choisira un formalisme UML limité (diagramme états - transitions limité à l expression de transitions et d actions sur état), ou une modélisation parallèle avec un formalisme plus approprié comme les réseaux de Pétri ou LDS. Notons que l utilisation d UML-RT oblige à une meilleure rigueur dans l expression des diagrammes états - transitions niveau faible : on pourra choisir un formalisme UML complet (diagramme états transitions ou diagramme d activités).

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

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

Plus en détail

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

MODELISATION UN ATELIER DE MODELISATION «RATIONAL ROSE»

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

Plus en détail

Diagramme de classes

Diagramme 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étail

Les diagrammes de modélisation

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

Plus en détail

Chapitre I : le langage UML et le processus unifié

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

Plus en détail

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

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

Plus en détail

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

Nom de l application

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

Plus en détail

Démarches d urbanisation : réorganiser le Système d Information en structurant ses fonctions dans des blocs fonctionnels communicants.

Démarches d urbanisation : réorganiser le Système d Information en structurant ses fonctions dans des blocs fonctionnels communicants. Plan du chapitre Master Informatique et Systèmes Urbanisation des Systèmes d Information Architecture d Entreprise 04 Architecture du SI : identifier et décrire les services, structurer le SI 1 2 3 4 5

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

Urbanisation des Systèmes d Information Architecture d Entreprise. 04 Architecture du SI : identifier et décrire les services, structurer le SI

Urbanisation des Systèmes d Information Architecture d Entreprise. 04 Architecture du SI : identifier et décrire les services, structurer le SI Plan du chapitre Master Informatique et Systèmes Urbanisation des Systèmes d Information Architecture d Entreprise 04 Architecture du SI : identifier et décrire les services, structurer le SI 1 2 3 1.1

Plus en détail

UML et les Bases de Données

UML et les Bases de Données CNAM UML et les Bases de Données UML et les Bases de Données. Diagramme de classes / diagramme d objets (UML)...2.. Premier niveau de modélisation des données d une application...2.2. Les éléments de modélisation...2.2..

Plus en détail

UML (Diagramme de classes) Unified Modeling Language

UML (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étail

Cours STIM P8 TD 1 Génie Logiciel

Cours 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étail

Le Guide Pratique des Processus Métiers

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

Plus en détail

Sommaire. G. Pujolle, F. Ravat, C. Soulé-Dupuy, G. Zurfluh

Sommaire. 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é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

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

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

Plus en détail

Patrons de Conception (Design Patterns)

Patrons de Conception (Design Patterns) Patrons de Conception (Design Patterns) Introduction 1 Motivation Il est difficile de développer des logiciels efficaces, robustes, extensibles et réutilisables Il est essentiel de comprendre les techniques

Plus en détail

Sciences de Gestion Spécialité : SYSTÈMES D INFORMATION DE GESTION

Sciences de Gestion Spécialité : SYSTÈMES D INFORMATION DE GESTION Sciences de Gestion Spécialité : SYSTÈMES D INFORMATION DE GESTION Classe de terminale de la série Sciences et Technologie du Management et de la Gestion Préambule Présentation Les technologies de l information

Plus en détail

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

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

Plus en détail

Développement spécifique d'un système d information

Développement spécifique d'un système d information Centre national de la recherche scientifique Direction des systèmes d'information REFERENTIEL QUALITE Procédure Qualité Développement spécifique d'un système d information Référence : CNRS/DSI/conduite-proj/developpement/proc-developpement-si

Plus en détail

Table des matières Sources

Table des matières Sources Table des matières Modélisation objet avec UML... 2 Introduction... 2 Modèle de système informatique :... 2 Pourquoi UML pour la modélisation Objet?... 3 Représentation dynamique du système... 5 Le diagramme

Plus en détail

Objectif : Passer de l analyse métier et fonctionnelle à la définition des applications qui

Objectif : 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étail

UML Diagramme de communication (communication diagram) Emmanuel Pichon 2013

UML Diagramme de communication (communication diagram) Emmanuel Pichon 2013 UML Diagramme de communication (communication diagram) 2013 Diagramme de communication (communication diagram) Utilisation / objectifs Sens Ce diagramme présente des objets, des acteurs, des liens et des

Plus en détail

Traduction des Langages : Le Compilateur Micro Java

Traduction des Langages : Le Compilateur Micro Java BARABZAN Jean-René OUAHAB Karim TUCITO David 2A IMA Traduction des Langages : Le Compilateur Micro Java µ Page 1 Introduction Le but de ce projet est d écrire en JAVA un compilateur Micro-Java générant

Plus en détail

RAPPORT DE CONCEPTION UML :

RAPPORT DE CONCEPTION UML : Carlo Abi Chahine Sylvain Archenault Yves Houpert Martine Wang RAPPORT DE CONCEPTION UML : Bamboo Ch@t Projet GM4 Juin 2006 Table des matières 1 Introduction 2 2 Présentation du logiciel 3 2.1 Précisions

Plus en détail

GL - 2 2.1 Le Génie Logiciel

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

Projet Active Object

Projet 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étail

RTDS G3. Emmanuel Gaudin emmanuel.gaudin@pragmadev.com

RTDS G3. Emmanuel Gaudin emmanuel.gaudin@pragmadev.com RTDS G3 Emmanuel Gaudin emmanuel.gaudin@pragmadev.com PragmaDev Dédiée au développement d un AGL pour le développement des applications temps réel et embarquées. Réseau de partenaires: Formations, Service,

Plus en détail

Modélisation des données

Modélisation des données Modélisation des données Le modèle Entité/Association Le MCD ou modèle Entité/Association est un modèle chargé de représenter sous forme graphique les informations manipulées par le système (l entreprise)

Plus en détail

Proposition de sujet de thèse CIFRE EUROCOPTER / LGI2P

Proposition de sujet de thèse CIFRE EUROCOPTER / LGI2P EUROCOPTER SAS Groupe EADS Marignane Ecole des Mines d Alès Laboratoire de Génie Informatique et d Ingénierie de Production LGI2P Nîmes Proposition de sujet de thèse CIFRE EUROCOPTER / LGI2P Titre Domaine

Plus en détail

Rational Unified Process

Rational 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étail

INF 1250 INTRODUCTION AUX BASES DE DONNÉES. Guide d étude

INF 1250 INTRODUCTION AUX BASES DE DONNÉES. Guide d étude INF 1250 INTRODUCTION AUX BASES DE DONNÉES Guide d étude Sous la direction de Olga Mariño Télé-université Montréal (Québec) 2011 INF 1250 Introduction aux bases de données 2 INTRODUCTION Le Guide d étude

Plus en détail

Conception 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 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étail

Sommaire. Conduite de projet Méthode d analyse et de conception. Processus unifié. Objectifs d un processus de développement

Sommaire. 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étail

Entrepôt de données 1. Introduction

Entrepôt de données 1. Introduction Entrepôt de données 1 (data warehouse) Introduction 1 Présentation Le concept d entrepôt de données a été formalisé pour la première fois en 1990 par Bill Inmon. Il s agissait de constituer une base 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

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

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

Plus en détail

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

D une part, elles ne peuvent faire table rase de la richesse contenue dans leur système d information.

D une part, elles ne peuvent faire table rase de la richesse contenue dans leur système d information. PACBASE «Interrogez le passé, il répondra présent.». Le Module e-business Les entreprises doivent aujourd hui relever un triple défi. D une part, elles ne peuvent faire table rase de la richesse contenue

Plus en détail

Expression des contraintes. OCL : Object C o n t r a i n t L a n g u a g e

Expression des contraintes. OCL : Object C o n t r a i n t L a n g u a g e P r o b l é m a t i q u e OCL : O b j e c t C o n s t r a i n t L a n g u a g e Le langage de contraintes d UML Les différents diagrammes d UML permettent d exprimer certaines contraintes graphiquement

Plus en détail

Chapitre 1 : Introduction aux bases de données

Chapitre 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étail

Programme «Analyste Programmeur» Diplôme d état : «Développeur Informatique» Homologué au niveau III (Bac+2) (JO N 176 du 1 août 2003) (34 semaines)

Programme «Analyste Programmeur» Diplôme d état : «Développeur Informatique» Homologué au niveau III (Bac+2) (JO N 176 du 1 août 2003) (34 semaines) Programme «Analyste Programmeur» Diplôme d état : «Développeur Informatique» Homologué au niveau III (Bac+2) (JO N 176 du 1 août 2003) (34 semaines) Module 1 : Programmer une application informatique Durée

Plus en détail

GOL502 Industries de services

GOL502 Industries de services GOL502 Industries de services Conception d un service Partie IIb Version 2013 Introduction Conception d un service partie IIb Nous verrons dans ce chapitre Modélisation d un service; Langage de modélisation

Plus en détail

SIMULER ET CONCEVOIR LE TRAVAIL FUTUR

SIMULER ET CONCEVOIR LE TRAVAIL FUTUR SIMULER ET CONCEVOIR LE TRAVAIL FUTUR Utilisation du logigramme d activité dans un projet informatique, pour simuler les compétences futures, et évaluer la charge de travail. WWW.ANACT.FR OUTIL DE SIMULATION

Plus en détail

Réussir la modélisation UML des phases amont Techniques de «pré-modélisation» : un pont vers le modèle

Réussir la modélisation UML des phases amont Techniques de «pré-modélisation» : un pont vers le modèle Réussir la modélisation UML des phases amont Techniques de «pré-modélisation» : un pont vers le modèle Softeam 2004 Philippe Desfray (voir A propos de l auteur) Présentation Réussir le développement d

Plus en détail

Méthodes d évolution de modèle produit dans les systèmes du type PLM

Méthodes d évolution de modèle produit dans les systèmes du type PLM Résumé de thèse étendu Méthodes d évolution de modèle produit dans les systèmes du type PLM Seyed Hamedreza IZADPANAH Table des matières 1. Introduction...2 2. Approche «Ingénierie Dirigée par les Modèles»

Plus en détail

Génie Logiciel avec Ada. 4 février 2013

Génie Logiciel avec Ada. 4 février 2013 Génie Logiciel 4 février 2013 Plan I. Généralités II. Structures linéaires III. Exceptions IV. Structures arborescentes V. Dictionnaires I. Principes II. Notions propres à la POO I. Principes Chapitre

Plus en détail

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

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

Plus en détail

Contrôleur de communications réseau. Guide de configuration rapide DN1657-0606

Contrôleur de communications réseau. Guide de configuration rapide DN1657-0606 K T - N C C Contrôleur de communications réseau Guide de configuration rapide DN1657-0606 Objectif de ce document Ce Guide de configuration rapide s adresse aux installateurs qui sont déjà familiers avec

Plus en détail

Messagerie asynchrone et Services Web

Messagerie asynchrone et Services Web Article Messagerie asynchrone et Services Web 1 / 10 Messagerie asynchrone et Services Web SOAP, WSDL SONT DES STANDARDS EMERGEANT DES SERVICES WEB, LES IMPLEMENTATIONS DE CEUX-CI SONT ENCORE EN COURS

Plus en détail

OASIS www.oasis-open.org/committees/xacml/docs/docs.shtml Date de publication

OASIS www.oasis-open.org/committees/xacml/docs/docs.shtml Date de publication Statut du Committee Working Draft document Titre XACML Language Proposal, version 0.8 (XACML : XML Access Control Markup Language) Langage de balisage du contrôle d'accès Mot clé Attestation et sécurité

Plus en détail

Master 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 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étail

LANGAGUE JAVA. Public Développeurs souhaitant étendre leur panel de langages de programmation

LANGAGUE 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étail

TUTORIEL Qualit Eval. Introduction :

TUTORIEL Qualit Eval. Introduction : TUTORIEL Qualit Eval Introduction : Qualit Eval est à la fois un logiciel et un référentiel d évaluation de la qualité des prestations en établissements pour Personnes Agées. Notre outil a été spécifiquement

Plus en détail

URBANISME DES SYSTÈMES D INFORMATION

URBANISME 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étail

Apprendre la Programmation Orientée Objet avec le langage Java (avec exercices pratiques et corrigés)

Apprendre la Programmation Orientée Objet avec le langage Java (avec exercices pratiques et corrigés) Introduction à la POO 1. Histoire de la POO 9 2. Historique du 12 La conception orientée objet 1. Approche procédurale et décomposition fonctionnelle 13 2. La transition vers l'approche objet 14 3. Les

Plus en détail

Conception des bases de données : Modèle Entité-Association

Conception 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étail

OCL - Object Constraint Language

OCL - Object Constraint Language OCL - Object Constraint Language Laëtitia Matignon laetitia.matignon@univ-lyon1.fr Département Informatique - Polytech Lyon Université Claude Bernard Lyon 1 2012-2013 Laëtitia Matignon SIMA - OCL - Object

Plus en détail

Votre infrastructure est-elle? La collaboration informatique. améliore la performance globale

Votre infrastructure est-elle? La collaboration informatique. améliore la performance globale Votre infrastructure est-elle? La collaboration informatique améliore la performance globale Des processus automatisés Travail isolé ou processus de groupe : où en êtes-vous? Le travail en équipe a toujours

Plus en détail

Concevoir et déployer un data warehouse

Concevoir et déployer un data warehouse Concevoir et déployer un data warehouse Ralph Kimball Éditions Eyrolles ISBN : 2-212-09165-6 2000 2 Le cycle de vie dimensionnel Avant d étudier de plus près les spécificités de la conception, du développement

Plus en détail

Styler un document sous OpenOffice 4.0

Styler un document sous OpenOffice 4.0 Mars 2014 Styler un document sous OpenOffice 4.0 Un style est un ensemble de caractéristiques de mise en forme (police, taille, espacement, etc.) qui sert à structurer un document en l organisant de manière

Plus en détail

Comparaison de trois techniques de modélisation de processus: ADONIS, OSSAD et UML

Comparaison de trois techniques de modélisation de processus: ADONIS, OSSAD et UML Olivier Glassey Jean-Loup Chappelet Comparaison de trois techniques de modélisation de processus: ADONIS, OSSAD et UML Working paper de l'idheap 14/2002 UER: Management public / Systèmes d'information

Plus en détail

CORBA. (Common Request Broker Architecture)

CORBA. (Common Request Broker Architecture) CORBA (Common Request Broker Architecture) Projet MIAGe Toulouse Groupe 2 1 CORBA, introduction (1/4) Les systèmes répartis permettent de créer des applications basées sur des composants auto-gérables,

Plus en détail

Génie Logiciel Avancé Cours 3 Le modèle à objets

Génie Logiciel Avancé Cours 3 Le modèle à objets Génie Logiciel Avancé Cours 3 Le modèle à objets Stefano Zacchiroli zack@pps.univ-paris-diderot.fr Laboratoire PPS, Université Paris Diderot - Paris 7 URL http://upsilon.cc/zack/teaching/1112/gla/ Copyright

Plus en détail

MEGA ITSM Accelerator. Guide de démarrage

MEGA ITSM Accelerator. Guide de démarrage MEGA ITSM Accelerator Guide de démarrage MEGA 2013 1ère édition (janvier 2013) Les informations contenues dans ce document pourront faire l objet de modifications sans préavis et ne sauraient en aucune

Plus en détail

Langage et Concepts de Programmation Objet. 1 Attributs et Méthodes d instance ou de classe. Travaux Dirigés no2

Langage et Concepts de Programmation Objet. 1 Attributs et Méthodes d instance ou de classe. Travaux Dirigés no2 Langage et Concepts de Programmation Objet Travaux Dirigés no2 Pôle Informatique École Nationale Supérieure des Mines de St-Etienne Vous trouverez plus de détails sur les concepts abordés lors de ce TD

Plus en détail

Le logiciel pour le courtier d assurances

Le logiciel pour le courtier d assurances Le logiciel pour le courtier d assurances Introduction - Présentation 2 Intégration totale 3 Paperless Office 3 Traitement Unifié de l information 4 Outils commerciaux 5 Communication 6 Intégration AS/2

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

Information utiles. cinzia.digiusto@gmail.com. webpage : Google+ : http://www.ibisc.univ-evry.fr/ digiusto/

Information utiles. cinzia.digiusto@gmail.com. webpage : Google+ : http://www.ibisc.univ-evry.fr/ digiusto/ Systèmes de gestion de bases de données Introduction Université d Evry Val d Essonne, IBISC utiles email : cinzia.digiusto@gmail.com webpage : http://www.ibisc.univ-evry.fr/ digiusto/ Google+ : https://plus.google.com/u/0/b/103572780965897723237/

Plus en détail

Manuel d utilisation du site web de l ONRN

Manuel d utilisation du site web de l ONRN Manuel d utilisation du site web de l ONRN Introduction Le but premier de ce document est d expliquer comment contribuer sur le site ONRN. Le site ONRN est un site dont le contenu est géré par un outil

Plus en détail

Rédiger pour le web. Objet : Quelques conseils pour faciliter la rédaction de contenu à diffusion web

Rédiger pour le web. Objet : Quelques conseils pour faciliter la rédaction de contenu à diffusion web Rédiger pour le web Objet : Quelques conseils pour faciliter la rédaction de contenu à diffusion web Sommaire 1. Rédiger des contenus... 2 Lire à l écran : une lecture contraignante... 2 Ecrire des phrases

Plus en détail

M1 : Ingénierie du Logiciel

M1 : Ingénierie du Logiciel M1 : Ingénierie du Logiciel UNIVERSITE PIERRE & MARIE CURIE (PARIS VI) Examen Réparti 2eme partie 16 Mai 2013 (2 heures avec documents : tous SAUF ANNALES CORRIGEES). Barème indicatif sur 20,5 points (max

Plus en détail

Chapitre 5 LE MODELE ENTITE - ASSOCIATION

Chapitre 5 LE MODELE ENTITE - ASSOCIATION Chapitre 5 LE MODELE ENTITE - ASSOCIATION 1 Introduction Conception d une base de données Domaine d application complexe : description abstraite des concepts indépendamment de leur implémentation sous

Plus en détail

ils entretiennent entre eux des flux, ils partagent des perceptions sur l environnement

ils entretiennent entre eux des flux, ils partagent des perceptions sur l environnement Les modèles de Flux Introduction L analyse systémique fournie une modélisation de l organisation échangeant et transformant des flux Cette modélisation du S.I. reste trop générale Il faut découper l organisation

Plus en détail

Créer et partager des fichiers

Créer et partager des fichiers Créer et partager des fichiers Le rôle Services de fichiers... 246 Les autorisations de fichiers NTFS... 255 Recherche de comptes d utilisateurs et d ordinateurs dans Active Directory... 262 Délégation

Plus en détail

Travaux soutenus par l ANR. Jean-François CAPURON (DGA) Bruno LEGEARD (Smartesting)

Travaux soutenus par l ANR. Jean-François CAPURON (DGA) Bruno LEGEARD (Smartesting) Travaux soutenus par l ANR Jean-François CAPURON (DGA) Bruno LEGEARD (Smartesting) 03 Avril 2012 1. Test de sécurité et génération de tests à partir de modèle 2. Le projet SecurTest à DGA Maîtrise de l

Plus en détail

WEB15 IBM Software for Business Process Management. un offre complète et modulaire. Alain DARMON consultant avant-vente BPM alain.darmon@fr.ibm.

WEB15 IBM Software for Business Process Management. un offre complète et modulaire. Alain DARMON consultant avant-vente BPM alain.darmon@fr.ibm. WEB15 IBM Software for Business Process Management un offre complète et modulaire Alain DARMON consultant avant-vente BPM alain.darmon@fr.ibm.com Claude Perrin ECM Client Technical Professional Manager

Plus en détail

Chapitre 3 - VODEL, un langage de description d architectures logicielles statiques et dynamiques

Chapitre 3 - VODEL, un langage de description d architectures logicielles statiques et dynamiques Chapitre 3 - VODEL, un langage de description d architectures logicielles statiques et dynamiques «Examine soigneusement chaque voie. Essaye aussi souvent que tu le crois nécessaire. Puis pose toi la seule

Plus en détail

Introduction aux concepts d ez Publish

Introduction aux concepts d ez Publish Introduction aux concepts d ez Publish Tutoriel rédigé par Bergfrid Skaara. Traduit de l Anglais par Benjamin Lemoine Mercredi 30 Janvier 2008 Sommaire Concepts d ez Publish... 3 Système de Gestion de

Plus en détail

Comprendre Merise et la modélisation des données

Comprendre Merise et la modélisation des données Comprendre Merise et la modélisation des données Tables des matières Avant-propos 1- Introduction 1-1 Principes fondateurs 1-2 Bases conceptuelles 1-3 Place de Merise dans le cycle de développement informatique

Plus en détail

La pratique. Elaborer un catalogue de services

La pratique. Elaborer un catalogue de services La pratique Elaborer un catalogue de services Création : juillet 2006 Mise à jour : août 2009 A propos A propos du document Ce document pratique est le résultat de la mise en oeuvre du référentiel ITIL

Plus en détail

AIDE MEMOIRE. Forprev. De l habilitation à la gestion de sessions. Page 1 sur 55

AIDE MEMOIRE. Forprev. De l habilitation à la gestion de sessions. Page 1 sur 55 2013 AIDE MEMOIRE Forprev De l habilitation à la gestion de sessions Page 1 sur 55 Bienvenue, Vous êtes, ou souhaitez être, habilité à dispenser des formations relevant du dispositif de démultiplication

Plus en détail

SITE WEB E-COMMERCE ET VENTE A DISTANCE

SITE WEB E-COMMERCE ET VENTE A DISTANCE Développement d une application JAVA EE SITE WEB E-COMMERCE ET VENTE A DISTANCE PLAN PROJET Binôme ou monôme (B/M): M Nom & Prénom : AIT NASSER Btissam Email : aitnasser.btissam123@gmail.com GSM : Organisme

Plus en détail

TP1 : Initiation à Java et Eclipse

TP1 : Initiation à Java et Eclipse TP1 : Initiation à Java et Eclipse 1 TP1 : Initiation à Java et Eclipse Systèmes d Exploitation Avancés I. Objectifs du TP Ce TP est une introduction au langage Java. Il vous permettra de comprendre les

Plus en détail

Génie logiciel pour le commerce électronique Hiver 2003 Prof.: Julie Vachon

Génie logiciel pour le commerce électronique Hiver 2003 Prof.: Julie Vachon Génie logiciel pour le commerce électronique Hiver 2003 Prof.: Julie Vachon Travail pratique #1 «Réalisation d'une plateforme de vente aux enchères électronique» À réaliser individuellement ou en équipe

Plus en détail

LECTURE CRITIQUE. Accompagner les enseignants et formateurs dans la conception d une formation en ligne

LECTURE CRITIQUE. Accompagner les enseignants et formateurs dans la conception d une formation en ligne LECTURE CRITIQUE Accompagner les enseignants et formateurs dans la conception d une formation en ligne Christian Ernst E-learning. Conception et mise en œuvre d un enseignement en ligne Guide pratique

Plus en détail

WINDOWS SHAREPOINT SERVICES 2007

WINDOWS SHAREPOINT SERVICES 2007 WINDOWS SHAREPOINT SERVICES 2007 I. TABLE DES MATIÈRES II. Présentation des «content types» (Type de contenu)... 2 III. La pratique... 4 A. Description du cas... 4 B. Création des colonnes... 6 C. Création

Plus en détail

MEGA ITSM Accelerator. Guide de Démarrage

MEGA ITSM Accelerator. Guide de Démarrage MEGA ITSM Accelerator Guide de Démarrage MEGA 2009 SP4 1ère édition (juin 2010) Les informations contenues dans ce document pourront faire l objet de modifications sans préavis et ne sauraient en aucune

Plus en détail

INDUSTRIALISATION ET RATIONALISATION

INDUSTRIALISATION ET RATIONALISATION INDUSTRIALISATION ET RATIONALISATION A. LA PROBLEMATIQUE La mission de toute production informatique est de délivrer le service attendu par les utilisateurs. Ce service se compose de résultats de traitements

Plus en détail

PROGRAMME DU CONCOURS DE RÉDACTEUR INFORMATICIEN

PROGRAMME DU CONCOURS DE RÉDACTEUR INFORMATICIEN PROGRAMME DU CONCOURS DE RÉDACTEUR INFORMATICIEN 1. DÉVELOPPEMENT D'APPLICATION (CONCEPTEUR ANALYSTE) 1.1 ARCHITECTURE MATÉRIELLE DU SYSTÈME INFORMATIQUE 1.1.1 Architecture d'un ordinateur Processeur,

Plus en détail

Avertissement. La Gestion Electronique de Documents

Avertissement. La Gestion Electronique de Documents Sommaire Les plus de GEDExpert... p 1.3 Mise en place Fichiers de bases... p 1.4 Mise en place Plan de classement... p 1.8 La fiche dossier... p 1.13 L acquisition de documents... p 1.19 Les liens avec

Plus en détail

Manuel Utilisateur. Boticely

Manuel Utilisateur. Boticely Manuel Utilisateur Boticely Auteur : Logica Version : 1.4 Droit d auteur Ce texte est disponible sous contrat Creative Commons Paternité - Pas d'utilisation Commerciale - Partage des Conditions Initiales

Plus en détail

Brève étude de la norme ISO/IEC 27003

Brève étude de la norme ISO/IEC 27003 RECOMMANDATIONS Brève étude de la norme ISO/IEC 27003 Décembre 2011 CLUB DE LA SECURITE DE L INFORMATION FRANÇAIS 11, rue de Mogador 75009 PARIS Tel : 01 53 25 08 80 Fax : 01 53 08 81 clusif@clusif.asso.fr

Plus en détail

Qu'est-ce que le BPM?

Qu'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étail