REFERENTIEL NORMATIF du CNES
|
|
- Élise St-Amand
- il y a 8 ans
- Total affichages :
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 http://olivier-augereau.com Sommaire Introduction I) Les bases II) Les diagrammes
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é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é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é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étailChapitre 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é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é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é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étailDé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é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étailUrbanisation 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étailUML 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é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é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é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é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é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é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étailPatrons 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étailSciences 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é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étailDé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étailTable 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é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étailUML 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étailTraduction 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étailRAPPORT 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é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é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é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étailRTDS 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étailModé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étailProposition 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é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étailINF 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é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é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étailEntrepô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é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é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é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étailD 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étailExpression 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é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étailProgramme «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étailGOL502 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étailSIMULER 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étailRé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étailMé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étailGé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é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étailContrô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étailMessagerie 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étailOASIS 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é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é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étailTUTORIEL 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é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étailApprendre 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é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étailOCL - 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étailVotre 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étailConcevoir 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étailStyler 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étailComparaison 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étailCORBA. (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étailGé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étailMEGA 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étailLangage 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étailLe 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é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étailInformation 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étailManuel 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étailRé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étailM1 : 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étailChapitre 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étailils 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étailCré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étailTravaux 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étailWEB15 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étailChapitre 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étailIntroduction 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étailComprendre 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étailLa 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étailAIDE 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étailSITE 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étailTP1 : 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étailGé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étailLECTURE 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étailWINDOWS 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étailMEGA 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étailINDUSTRIALISATION 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étailPROGRAMME 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étailAvertissement. 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étailManuel 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étailBrè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é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étail