Favorites Bookmarks Welcome  livre-d-or-nouveau  Blog Lomagman Nous sommes le Jeudi 27 Juillet 2017 et il est 09:04:41

 

 
 
 

uml_modeliser

uml_modeliser

Remonter ]

Découverte du : UML et activités du OMG

Unified Process  présentée par une brève définition.

concept du monde de la création et modélisation de programme orienté objet

( j'apprends du nouveau utile à la compréhension du mécanisme)

contribution d'un apprenant qui nous fait découvrir un élément de configuration et modélisation de logiciel nécessaire à une des voies de création de soft de gestion stock WMS 21/12/02. voir aussi le courriel.

courriel massage:             Bonjour, je suis étudiant et suite à un travail, je recherche toutes documentations traitant de la modéliser un UML gestion de stock . Documentations, URL,Schémas etc. En vous remerciant d'avance.


1.-Texte en version traduite de l'anglaise   2.- Texte en version française (en milieu de page)

Lien et autres téléchargements

Courriel d'internaute:souhaiterais en savoir plus sur la modélisation et la simulation d'une supply chain. 27/04/2003 à la pagedocuments à télécharger et liens sur place.

remonter

Documents sur le sujet :

UML, Unified Modeling Language, est un ensemble de modèles permettant de représenter un système informatique et son utilisation prévue dans l’entreprise clés d'accès Chantal Morlay

/diagrammedutilisation4-OOM-10Oct2002-v3. PDF  

uml_modeling/lecture09.

uml_modeling/uml1.

uml_modeling/uml9.

so présentation. simply object everview

UML for XML Schéma33

UML XML Schémas spécification

uml_modeling/graphviz-1.8.10.tar.gz   Win zip

UML diagrammes de classes_9.pdf

chargement_exemple_adaptable avec copie en format PDF. Etude de cas comme exemple pouvant servir de 

base en informatique de stock. 26/07/2003

Unified Process

Unified Process est une méthode générique de développement de logiciels. Unified Process (UP) est une méthode qui couvre plusieurs aspects d’un projet logiciel. Contrairement aux démarches du début de la décennie, elle prend en compte l’ensemble des intervenants : client, utilisateur, gestionnaire, qualiticien, etc. D’où l’adjectif unified. Dans cet ordre d’idée, les méthodes basées sur les cas d’utilisation ont constitué une étape intermédiaire. Pour comprendre cette démarche, il est donc nécessaire de sortir du cadre strict du développement, au sens technique du terme. Se mettre à la place du client est un moyen d’y parvenir. Ainsi, les phases apparaissent naturellement comme des étapes du projet et non plus comme des activités techniques (analyse, conception,...).

La suite par ce lien : http://tcros.free.fr/UML1_3.htm Unified Process http://www.essi.fr/~hugues/GL/RUP/affichage.html  20 diapos. http://www.essi.fr/~hugues index sujets divers

INTRODUCTION (2) Diapo.

Le Rational Unified Process est un logiciel d'aide au développement qui met en valeur la productivité de l'équipe et fournit les meilleures lignes directrices en matière de conception logiciel à tous les membres de celle-ci.

Il fournit les directives et les exemples appropriés pour toutes les activités critiques du développement, en même temps que les outils permettant de modéliser et de suivre l'exigence de ses directives.

Il est non intrusif et étroitement intégré avec les outils logiciels Rational, permettant à des équipes de développement de profiter des pleins avantages de l'UML, et de l'automatisation du logiciel.

 

Version traduite de l'anglais

OOP et UML

1.-Introduction

2.-Quelques règles de notation

3.-Rapports

4.-Transmission

5.-Agrégation

6.-Dessin d'une classe

7.-Conclusion

8.-Bibliographie                                              

Introduction

Le but de ce document est de vous fournir des informations sur UML et comment l'utiliser.

Quel est UML ?

UML, unifié modelant le langage, est une notation standard pour modeler des objets réels dans un premier temps en développant un programme orienté par objet. Il décrit un à langage conformé pour indiquer, visualiser, construire et documenter les objets façonnés des systèmes logiciels.

Pourquoi modèle ?

Développer un modèle pour un système logiciel avant que vous commenciez réellement à programmer le logiciel, peut être vu en tant qu'ayant un modèle pour un grand bâtiment que vous voulez construire. Il est essentiel d'avoir un. Bien que ceci ne signifie pas que vous devez dessiner un modèle chaque fois une classe simple est présentée dans votre logiciel. Vous devez penser pour vous-même si vous voulez un modèle ou pas.

Quelques notation-règles

Graphiques et leur contenu

La plupart des diagrammes d'UML sont des graphiques contenant des noeuds reliés par des voies d'accès. L'information est la plupart du temps dans la typologie, pas dans la taille ou le placement des symboles. Il y a trois genres de rapports visuels qui sont importants :

remonter

  1.-Connexion (habituellement lignes

  2.-Retenue (2D formes avec des bornes)

  3.-Connexion visuelle (un objet étant près des autres)

La notation d'UML est destinée pour être dessinée sur une 2D surface.

Il y a fondamentalement quatre genres de constructions graphiques utilisées dans la notation d'UML :

  1. Graphismes - un graphisme est une figure graphique d'une taille et d'une forme fixes. Il n'augmente pas pour tenir le contenu. Les graphismes peuvent apparaître dans des symboles de zone, comme programmes finisseurs sur des voies d'accès ou en tant que symboles autonomes qui peuvent ou ne peuvent être reliés aux voies d'accès

  2. 2D symboles - les symboles bidimensionnels ont la longueur variable et la largeur et eux peuvent augmenter pour tenir d'autres choses, telles que des listes, chaînes de caractères ou d'autres symboles. Bon nombre d'entre eux sont divisés en compartiments des sortes semblables ou différentes. Traîner ou effacer un 2D-symbol affecte son contenu et toutes les voies d'accès reliés à lui.

  3. Voies d'accès - ordres de la ligne segments dont les points finaux sont joints. Conceptuellement, une voie d'accès est une entité topologique simple, bien que ses segments puissent être manipulés graphiquement. Un segment peut ne pas exister indépendamment de sa voie d'accès. Des voies d'accès sont toujours attachées à d'autres symboles graphiques aux deux extrémités (aucunes lignes balançantes). Les voies d'accès peuvent avoir des programmes finisseurs, qui sont des graphismes qui apparaissent dans un certain ordre sur l'extrémité de la voie d'accès et qui qualifient la signification du symbole de voie d'accès.

  4. Chaînes de caractères - les divers genres actuels d'information dans "unparsed" la forme. UML suppose que chaque utilisation d'une chaîne de caractères dans la notation a une syntaxe par laquelle elle peut être analysée dans l'information modèle fondamentale. Par exemple, des syntaxes sont données pour des attributs, des exécutions et des transitions. Les chaînes de caractères peuvent exister en tant que les éléments singuliers des symboles ou compartiments des symboles, comme éléments dans une liste en tant qu'étiquettes fixées aux symboles ou aux voies d'accès, ou en tant qu'éléments autonomes dans un diagramme.

remonter

Rapports

Attributs et comportement

Chaque objet a de divers attributs. Un attribut est une paire de name/value. Par exemple, mon âge est 22. Le nom d'attribut est "âge", la valeur est "22". Les objets ont également le comportement. Je peux me tenir, marcher, dormir etc...

Rapports

Il y a différents genres de rapports :

La dépendance est où un objet doit savoir des autres.

Dans un rapport simple de dépendance, tout que nous savons est qu'un objet a la connaissance des autres. Par exemple : si une classe exige les inclusions de l'en-tête pour des autres, cela établit une dépendance.

Nous dessinons une dépendance en utilisant une flèche à tiret. Si a dépend de b soyez sûr les points de flèche à b.

Dans l'association, l'état de l'objet dépend d'un autre objet.

Dans une association nous disons que, en tant qu'élément de comprendre l'état d'un objet, vous devez comprendre le rapport avec le deuxième objet. Il y a beaucoup de types d'association qui modèlent des rapports réels, comme possède (Arjen possède ce vélo), des travaux pour (Raymond fonctionne pour Harry) et ainsi de suite.

Dans une association les deux objets ont une connexion forte, mais ni l'un ni l'autre une n'est une partie de l'autre. Le rapport est plus fort cette dépendance ; il y a une association affectant les deux côtés du rapport.

Une association entre a et b est montrée par une ligne joignant les deux classes :

S'il n'y a aucune flèche sur la ligne, l'association est prise pour être bidirectionnelle. Une association continue est indiquée comme ceci :

Pour améliorer la clarté d'un diagramme de classe, l'association entre deux objets peut être nommée :

 

remonter

Aggegration modèle la relation de whole/part

Des objets se composent souvent d'autres objets. Des voitures se composent des roues de direction, moteurs, transmissions et ainsi de suite. Chacun de ces composants peut être un objet à son propre chef. L'association spéciale d'une voiture à ses pièces de component est connue comme aggegration.

Un rapport d'agrégation est indiqué en plaçant un diamant blanc à la fin de l'association à côté de la classe globale. Si b agrège a, alors a est une partie de b, mais leurs vies sont indépendantes :

La composition modèle un rapport dans lequel un objet est une partie intégrale des autres.

Souvent, les éléments d'un objet jaillissent dans l'existence seulement avec l'objet entier. Par exemple, une personne peut se composer d'un certain nombre de parties comprenant le coeur, les poumons etc... Si vous modeliez une personne, la vie du coeur et des poumons serait directement contrôlée par la vie de l'appel d'agglomération de personne. We cette composition spéciale en rapport.

Dans l'agrégation, les pièces peuvent vivre indépendamment. Tandis que ma voiture se compose de ses roues et pneus et radio, chacun de ces composants a pu avoir existé avant que la voiture ait été créée. En composition, la vie de l'objet contenu est attachée à la vie de l'objet contenant.

La composition est montrée par un diamant noir sur la fin de l'association à côté de la classe composée. Si b se compose d'a, alors b contrôle la vie d'a.

remonter

Transmission

La transmission est un rapport de specialization/generalization entre les objets.

Nous (humains) avons hérité de la capacité de créer des catégories basées sur le comportement et les caractéristiques des choses dans notre environnement. C'est meilleur montré avec un exemple : Si quelque chose respire et des mouvements, nous disons que c'est un animal. Si une de ces choses qui se déplacent et respirent également a jeune de phase et les nourrit, nous disons que c'est un mammifère. Nous savons que les mammifères sont des genres d'animaux, et ainsi nous pouvons prévoir que si nous voyons un mammifère, il dans toute la probabilité respirera et se déplacera autour.

Si un mammifère écorce et remue sa queue, nous disons que c'est un chien. S'il ne cessera pas d'écorcer et passages au sujet de nos pieds exigeant l'attention, nous figurons qu'elle est une terrier. Chacune de ces classifications nous fournit l'information supplémentaire. Quand nous sommes faits, nous avons créé une hiérarchie des types.

Quelques animaux sont des mammifères et certains sont des reptiles. Quelques mammifères sont des chiens et certains sont des chevaux. Chaque type partagera certaines caractéristiques, et ce les aides nous les comprennent et prévoient leur comportement et attributs.

Il y a seulement une bonne voie de dessiner ceci :

remonter

Une fois que nous avons cette catégorisation, nous pouvons voir que la lecture vers le haut de la hiérarchie animale indique la généralisation des caractéristiques partagées.

De la même manière, nous pourrions créer un modèle d'une voiture. Pour faire ainsi, nous nous trouvons dans l'obligation de poser à ourself quelques questions :

Quelle est une voiture ? Que rend une voiture différente d'un camion, à partir d'une personne, d'une roche ? Un des plaisirs de la programmation orientée d'objet est que ces questions nous deviennent appropriées ; la compréhension comment nous percevons et pensons aux objets dans le vrai monde directement associe à la façon dont nous concevons ces objets dans notre modèle.

D'une perspective, une voiture est la somme de ses parties : roue de direction, freins, sièges, phares. Ici, nous pensons en termes d'agrégation. D'une deuxième perspective, un qui est également vrai, une voiture est un type de véhicule.

Puisqu'une voiture est un véhicule, elle se déplace et porte des choses. C'est l'essence d'être un véhicule. Les voitures héritent des mouvements de caractéristiques et portent des choses de leur type de "parent", qui est "véhicule".

Nous savons également que la voiture spécialise des véhicules. Ils sont un genre spécial de véhicule, un qui répond aux caractéristiques fédérales pour des automobiles.

Nous pouvons modeler ce rapport avec la transmission. Nous disons que le type de voiture hérite publiquement du véhicule-type ; qu'une voiture est-un véhicule.

La transmission publique établit a est-un rapport. Il crée une classe de parent (véhicule) et une classe dérivée (voiture) et implique que la voiture est une spécialisation du type véhicule. Tout vrai au sujet d'un véhicule devrait être vrai au sujet d'une voiture, mais l'inverse n'est pas vraie. La voiture peut spécialiser comment elle se déplace, mais elle doit se déplacer.

Quel est un véhicule à moteur ? C'est une spécialisation différente, à un niveau différent d'abstraction. Un véhicule à moteur est n'importe quel véhicule conduit par un moteur. Une voiture est un tel type, un camion est une autre. Nous pouvons modeler ces rapports plus complexes avec la transmission aussi bien.

remonter

 

Quel modèle est meilleur ? Dépend de ce que vous modelez ! Comment décidez-vous quel modèle vous voulez utiliser ? Posez-vous les questions. Y a-t-il quelque chose au sujet du l'"véhicule à moteur" que je veux modeler ? Est-ce que j'aller suis modeler autre, véhicules non motorisés ? Si vous , vous devriez utiliser le deuxième modèle. Pour montrer ceci avec un exemple : Supposez que vous voulez créer deux classes pour les véhicules qui sont hippomobiles.

Transmission publique

Un aspect critique de la transmission publique est qu'il devrait modeler specialization/generalization, et rien autrement ! Si vous voulez hériter de la mise en place, mais n'êtes pas établissement est-un rapport, vous devriez utiliser la transmission privée.

La transmission privée établit mettre en application-dans-limite-de plutôt qu'est-un le rapport.

Transmission multiple

Une des capacités disponibles dans C++, est transmission multiple. La transmission multiple permet à une classe d'hériter de plus d'une classe de base, apportant les membres et les méthodes de deux classes ou plus.

Dans la transmission multiple simple, les deux classes de base sont indépendantes. Et l'exemple de la transmission multiple est montré ci-dessous. En outre notification comment les fonctions sont affichées dans ce modèle.

remonter

Dans ce modèle plutôt simple, la classe de griffon hérite du lion et de l'aigle. Ceci signifie un eatMeat(), un roar(), un squawk() et un fly() de bidon de griffon. Un problème surgit quand le lion et l'aigle partagent une classe de base commune, par exemple animal.

Cette classe de base commune, animal, peut avoir des méthodes de variables de membre des lesquelles le griffon héritera maintenant deux fois. Quand vous appelez la méthode de Sleep() du griffon, le compilateur ne saura pas quel Sleep() vous souhaitez appeler. En tant que créateur de la classe de griffon, vous devez rester averti de ces rapports et être disposé à résoudre les ambiguïtés qu'elles créent. C++ facilite ceci en fournissant la transmission virtuelle.

remonter

 

Sans transmission virtuelle

Avec la transmission virtuelle

Avec la transmission virtuelle, le griffon hérite de juste une copie des membres de l'animal, et l'ambiguïté est résolue. Le problème est que les classes de lion et d'aigle doivent savoir qu'elles peuvent être impliquées dans un rapport multiple de transmission ; le mot-clé virtuel doit être sur leur déclaration de la transmission, pas celle du griffon.

Agrégation

Utilisation de la transmission multiple quand vous avez besoin d'agrégation

Comment savez-vous quand utiliser la transmission multiple et quand l'éviter ? Une voiture devrait-elle hériter de la roue, du pneu et des portes de direction ? Une voiture de police devrait-elle hériter de la propriété et du véhicule municipaux ?

La première directive est que la transmission publique devrait toujours modeler la spécialisation. L'expression commune pour ceci est que la transmission devrait modeler est-un des rapports et l'aggegration devrait modeler a-un des rapports.

Une voiture est-elle une roue de direction ? Clairement pas. Vous pourriez arguer du fait qu'une voiture est une combinaison d'une roue de direction, d'un pneu et d'un ensemble de portes, mais ceci n'est pas modelé dans la transmission. Une voiture n'est pas une spécialisation de ces choses ; c'est une agrégation de ces choses. Une voiture a une roue de direction, elle a des portes et elle a des pneus. Une autre bonne raison pour laquelle vous ne devriez pas hériter de la voiture de la porte est le fait qu'une voiture a habituellement plus d'une porte. Ce n'est pas un rapport qui peut être modelé avec la transmission.

remonter

Une voiture de police est-elle tous deux un véhicule et une propriété municipale ? Clairement elle est tous deux. En fait, elle spécialise tous les deux. En tant que tels, la transmission multiple fait beaucoup du sens ici :

Classes de base et classes dérivées

Les classes dérivées devraient savoir qui leur classe de base est, et elles dépendent de leurs classes de base. Les classes de base, d'autre part, devraient ne savoir rien au sujet de leurs classes dérivées. Ne mettez pas l'en-tête pour les classes dérivées dans vos fichiers de base de classe.

Vous voulez être très soupçonneux de n'importe quelle conception qui nécessite mouler en bas de la hiérarchie de transmission. Vous moulez vers le bas quand vous demandez une flèche indicatrice elle est "vraie" classe (d'exécution) et puis moule cette flèche indicatrice au type dérivé. Dans la théorie, les flèches indicatrices de base devraient être polymorphes, et figurer hors du "vrai" type de la flèche indicatrice et appeler la "bonne" méthode devraient être laissés au compilateur.

L'utilisation la plus commune du moulage vers le bas doit appeler une méthode qui n'existe pas dans la classe de base. La question vous devriez vous demander qu'est pourquoi vous êtes dans une situation où vous devez faire ceci. Si la connaissance du type d'exécution est censée être cachée, pourquoi êtes-vous alors moulant vers le bas ?

Classes simples d'exemple

Vous voulez également vous rendre très compte des classes dérivées pour lesquelles il y a toujours seulement un exemple. Ne le confondez pas avec un singleton, dans lequel l'application a besoin seulement d'un exemple simple d'un type, par exemple seulement un document ou seulement une base de données.

remonter

Dessin d'une classe

Affichage des membres

Supposez que vous voulez créer une classe CFloatPoint, qui a deux membres : X et y, qui sont tous deux de type flotteur de ` ', et une fonction "Empty()" qui remet à l'état initial les deux membres pour évaluer 0.00000.

Tout d'abord, vous dessinez la classe elle-même :

Maintenant, nous voulons que les membres X et y soient visibles dans le modèle :

Comme vous pouvez voir, x et y sont privés (serrure-signe) et ont le type "flotteur".

Maintenant, nous voulons rendre la fonction Empty() visible dans le modèle :

Notes

Supposez-vous devoir fournir quelques informations supplémentaires sur votre classe. Vous pouvez facilement faire ceci avec ajouter une note, qui ressemble à ceci :

remonter

Conclusion

Logiciel utilisé

Modeleur visuel

Maintenez dans l'esprit que ces modèles sont créés avec le modeleur visuel, qui est livré avec l'édition visuelle d'entreprise de studio, ainsi vous pouvez les juger et dessiner vous-même. Je ne vais pas expliquer comment le modeleur visuel travaille ici, regard du manuel ou bibliothèque de MSDN pour plus d'information.

Futures versions de ce document

Je pense que ce document est une bonne chambre p in OOP and UML. Together with the document " Different styles of Programming " they provide a good first-step tutorial in the world of Object Oriented Programming.

There are many features of UML which are not covered in this document. One of them are so-called "use-cases" which is a story on its own. This will be explained in a new document which has yet to be written at this moment.

Alex Marbus

Bibliography

Other popular C++ / MFC articles:

How a C++ compiler implements exception handling
An indepth discussion of how VC++ implements exception handling. Source code includes exception handling library for VC++.

A Smart Pointer Capable of Object Level Thread Synchronization and Reference Counting Garbage Collection
A smart pointer wrapper class

Organic Programming Environment (OPEN)
OPEN is a prototype development exploring a different paradigm for data management. Instead of applications being process-centric, in which processes drive data transfer, the Organic Programming environment uses a data-centric approach. In this paradigm, data initiates processes.

Smoov Code Project Screen Saver
Asynchronous XML Web Client Animated Screen Saver in Win32/MFC

 Site source pour le document original en anglais : http://www.codeproject.com/cpp/oopuml.asp#Introduction 

remonter

Version française

UML (Unified Modeling Language, que l'on peut traduire par "langage de modélisation unifié) est une notation permettant de modéliser un problème de façon standard. Ce langage est né de la fusion de plusieurs méthodes existant auparavant, et est devenu désormais la référence en terme de modélisation objet, à un tel point que sa connaissance est souvent nécessaire pour obtenir un poste de développeur objet.

La notion d'objet

La programmation orientée objet consiste à modéliser informatiquement un ensemble d'éléments d'une partie du monde réel (que l'on appelle domaine) en un ensemble d'entités informatiques. Ces entités informatiques sont appelées objets. Il s'agit de données informatiques regroupant les principales caractéristiques des éléments du monde réel (taille, la couleur, ...).
La difficulté de cette modélisation consiste à créer une représentation abstraite, sous forme d'objets, d'entités ayant une existence matérielle (chien, voiture, ampoule, ...) ou bien virtuelle (sécurité sociale, temps, ...).

remonter

Les méthodes objets

La modélisation objet consiste à créer une représentation informatique des éléments du monde réel auxquels on s'intéresse, sans se préoccuper de l'implémentation, ce qui signifie indépendamment d'un langage de programmation. Il s'agit donc de déterminer les objets présents et d'isoler leurs données et les fonctions qui les utilisent. Pour cela des méthodes ont été mises au point. Entre 1970 et 1990, de nombreux analystes ont mis au point des approches orientées objets, si bien qu'en 1994 il existait plus de 50 méthodes objet. Toutefois seules 3 méthodes ont véritablement émergées:

La méthode OMT de Rumbaugh

La méthode BOOCH'93 de Booch

La méthode OOSE de Jacobson (Object Oriented Software Engineering)

A partir de 1994, Rumbaugh et Booch (rejoints en 1995 par Jacobson) ont unis leurs efforts pour mettre au point la méthode unifiée (unified method 0.8), incorporant les avantages de chacunes des méthodes précédentes.

La méthode unifiée à partir de la version 1.0 devient UML (Unified Modeling Language), une notation universelle pour la modélisation objet. (ainsi que celles d'autres analystes).

UML 1.0 est soumise à l'OMG (Object Management Group) en janvier 1997, mais elle ne sera acceptée qu'en novembre 1997 dans sa version 1.1, date à partir de laquelle UML devient un standard international.

remonter

Voici le récapitulatif de évolutions de ce langage de modélisation :

En 1995: Méthode unifiée 0.8 (intègrant les méthodes Booch'93 et OMT)

En 1995: UML 0.9 (intègrant la méthode OOSE)

En 1996: UML 1.0 (proposée à l'OMG)

En 1997: UML 1.1 (standardisée par l'OMG)

En 1998: UML 1.2

En 1999: UML 1.3

Cette méthode représente un moyen de spécifier, représenter et construire les composantes d’un système informatique. Avec la méthode UML, un objet est par exemple représenté de la façon suivante:

remonter

Intérêt d'une méthode objet

Les langages orientés objet constituent chacun une manière spécifique d'implémenter le paradigme objet. Ainsi, une méthode objet permet de définir le problème à haut niveau sans rentrer dans les spécificités d'un langage. Il représente ainsi un outil permettant de définir un problème de façon graphique, afin par exemple de le présenter à tous les acteurs d'un projet (n'étant pas forcément des experts en un langage de programmation).

De plus, le fait de programmer à l'aide d'un langage orienté objet ne fait pas d'un programmeur un concepteur objet. En effet il est tout à fait possible de produire un code syntaxiquement juste sans pour autant adopter une approche objet. Ainsi la programmation orientée objet implique

en premier lieu une conception abstraite d'un modèle objet (c'est le rôle de la méthode objet)

en second plan l'implémentation à l'aide d'un langage orienté objet (tel que C++/Java/...)

Une méthode objet est donc d'une part une méthode d'analyse du problème (afin de couvrir toutes les facettes du problèmes), d'autre part un langage permettant une représentation standard stricte des concepts abstraits (la modélisation) afin de constituer un langage commun.

La normalisation OMG

Ainsi, il est nécessaire qu'une méthode objet soit définie de manière rigoureuse et unique afin de lever les ambiguités. De nombreuses méthodes objet ont été définies, mais aucune n'a sû s'imposer en raison du manque de standardisation. C'est pourquoi l'ensemble des acteurs du monde informatique a fondé en 1989 l'OMG (Object Management Group), une organisation à but non lucratif, dont le but est de mettre au point des standards garantissant la compatibilité entre des applications programmées à l'aide de langages objet et fonctionnant sur des réseaux hétérogènes (de différents types).

A partir de 1997, UML est devenue une norme de l'OMG, ce qui lui a permis de s'imposer en tant que méthode de développement objet et être reconnue et utilisée par de nombreuses entreprises.

http://www.commentcamarche.net/uml/umlintro.php3  cette page d'introduction à UML.

La suite cliquez ici SVP : http://www.commentcamarche.net/uml/umlcarac.php3 caractéristiques et la suite.

remonter

bonjour, 
le mieux pour l'instant, un site en espagnole :
http://www.cs.ualberta.ca/~pfiguero/soo/uml/
quant à cet intro je pense que vous l'avez déjà :
http://www.commentcamarche.net/uml/umlintro.php3
il est super votre sujet et c'est là dessus que en logistique le modèle production est pris en priorité. de plus le monopole de logiciel MRP ou autres en fait , même SAP, ont des lacunes qui sont dommage et leur souplesse ne concerne aucunement la logistique. ce sont des procédés ancien et tout de même assez lourds dont les adaptations sont confier en entreprise à  des personnes qui ne sont pas concernées à  la gestion de stock. 
très honoré, à bientôt dès que j'ai du nouveau. on a encore vite fait avec dix stylos en poches et un plein de bloc note.;-)) exemple de sous produit de guidage entrée marchandise le lien ci-dessous pour :site en page annexe

Plan de Prélèvement d'échantillons 

remonter

Version française

© Copyright 2002 Jean-François Pillou - Hébergé par Web-solutions.fr.
Ce document issu de CommentCaMarche.net est soumis à la licence GNU FDL

Liens :

http://www.commentcamarche.net/ccmdoc/search.php3?Mot=uml  autre page de téléchargement doc. UML

http://perso.efrei.fr/~charroux/cours/uml/cours_uml.html  format PDF page perso complètes.

http://www.objectsbydesign.com/tools/umltools_byCompany.html  

http://5a7.enst-bretagne.fr/Documents/uml_5a7/  48 diapositives PPT

http://5a7.enst-bretagne.fr/Documents/uml_5a7/sld001.htm  diapo n°1

http://www.rational.com/uml/resources/documentation/formats.jsp  zip et PDF

http://www.rational.com/uml/resources/documentation/index.jsp?SMSESSION=NO  doc

Click here for more information about Visual UML version 3.0 de site :

http://www.visualobject.com

http://www.augustana.ab.ca/~mohrj/courses/2000.winter/csc220/presentations/ch2lect/

http://www-igm.univ-mlv.fr/~dr/DESS/Elaboration/siframes.htm Diapos en français

45 diapos modeling with UML ci-dessous la diapo1

/courses/2000.winter/csc220/presentations/ch2lect/sld001.htm 

http://web.cs.mun.ca/~brown/courses/4718/lec4/ UML exemples

http://uml.free.fr/ celui-ci vous l’avez peut être.

http://java.cnam.fr/public_html/Iagl99/dazy/UML_MVC/UML_MVC.html code

http://mrim.imag.fr/rose/Version98/Pages/Rose.htm  rose ver. évaluation  

 

Méthodes et Outils pour la qualité du logiciel Conception, se faire une idée et pouvoir être à même d'exiger un logiciel adapté et fonctionnel et sur mesure :notamment le Pert, Gantt, COCOMO etc.  Capability Maturity Model bon à savoir.

Formation: http://www.essi.fr/ index

 

remonter

EXEMPLE DE PROJET OMG

Introduction  

Il existe aujourd'hui sur le marché plus de 50 méthodes d'analyse et/ou conception de systèmes logiciels disponibles commercialement ou ayant fait l'objet de publications internationales. Aucune d'elles n'est parfaitement adaptée à toutes les situations et contraintes rencontrées dans les projets de développement informatiques. Généralement, la combinaison de quelques principes méthodologiques issus de méthodes différentes procure les avantages de l'une et de l'autre. 

Au sein du consortium international OMG (Object Management Group) regroupant plus de 800 compagnies, le groupe de travail intitulé "Méthodologie d'analyse / conception orientée objet" vient de publier un document exprimant son intention de publier un appel à propositions dans ce sens. Son objectif est d'être capable, à partir d'un certain nombre de modèles décrivant des méthodes (appelées aussi processus) connues, de constituer un référentiel ou modèle générique. Celui-ci doit être suffisamment complet pour que, par simple instantiation, l'on puisse obtenir autant de nouveaux processus que souhaité. 

L'OMG possède aujourd'hui très peu de compétences dans le domaine des télécommunications et de la spécification de systèmes répartis que sont, par nature, les systèmes et services de télécommunications. L'OMG est même à la recherche d'expertise dans le domaine du modèle de référence pour la spécification de systèmes répartis : RM-ODP (Reference Model for Open Distributed Processing) normalisé à l'UIT-T et à l'ISO. 

L'objectif du projet PILOTE est de contribuer activement à cet effort de modélisation de processus en apportant une dimension nouvelle : celle des télécommunications avec ses implications comme, par ex., la prise en compte de la répartition, l'hétérogénéité, etc. En particulier, le projet PILOTE a pour ambition de fournir le modèle de processus basés sur le modèle de référence RM-ODP, d'étudier, au sein de ce modèle, la prise en compte les contraintes de qualité de service et de vérifier l'adéquation de la notation UML (Unified Modeling Language) normalisée à l'OMG pour modéliser les concepts de modélisation définis dans RM-ODP pour concevoir des systèmes répartis. Enfin, le projet PILOTE se propose de démontrer la faisabilité d'un atelier de création de nouveaux processus à partir du modèle de référence. 

Ce type d'atelier permettra de créer, partager, échanger, adapter des processus de développement de logiciel de télécommunications.  

Le projet PILOTE contribuera de manière pro-active aux travaux de l'OMG en exprimant les besoins spécifiques et contraintes télécoms qui ne sont pas aujourd'hui perçus par les industriels de l'informatique présents à l'OMG. Il est attendu que les résultats du projet PILOTE soient intégrés dans l'appel à proposition que publiera l'OMG afin que ces industriels les prennent en compte dans leurs produits lors de leur réponse à l'appel à proposition. 

Cet appel à proposition sera émis au cours de l'année 2000 ; ceci laisse au projet PILOTE le temps prévu pour travailler. 

remonter

Perspectives d'innovations :  
L'hétérogénéité des méthodes de spécification au sein d'une entreprise est un facteur d'inefficacité du système d'information (utilisation de paradigmes différents, non réutilisation, difficulté à échanger des spécifications, inadéquation des méthodes commerciales au besoin de l'entreprise, etc.). 

La possibilité, au sein d'un projet ou d'une entreprise, de créer sa méthode à partir de briques de base existant dans plusieurs autres méthodes, de créer des spécifications à partir de cette nouvelle méthode, d'échanger des spécifications, n'existe pas encore aujourd'hui. C'est la mission que se donne le projet PILOTE. 

Au-delà, le projet PILOTE a pour volonté de faire prendre en compte les aspects relatifs à la répartition inhérente à tout système de télécommunication, afin d'être capable d'établir des spécifications de services de télécommunications évolutives, par ex. indépendantes de la répartition des composants de services dans le réseau, et de faire évoluer les services existants rapidement, par exemple suite à un changement d'architecture technique, de protocole de communication, etc. Dans ce contexte, la prise en compte des besoins des industriels des télécommunications dans les ateliers de génie logiciel (fournissant des outils de modélisation) qui verront bientôt le jour est primordiale. 

Pour ce faire, PILOTE impactera de manière significative le travail de l'OMG afin que les industriels prennent en compte nos travaux dans leur réponse à l'appel à proposition qui sera publié en l'an 2000. L'objectif du projet PILOTE est d'une part de répondre à l'appel à information qui émis par l'OMG et, d'autre part, de contribuer à l'élaboration de l'appel à proposition qui doit être émis par l'OMG en l'an 2000. 

remonter

Technologies mises en oeuvre et état de l'art :  

1/ Les concepts de modélisation utilisés pour la spécification des systèmes répartis de télécommunications sont ceux de la série de recommandations de l'UIT-T X.901 à X.904 ( "RM-ODP : Reference Model for Open Distributed Processing). 

2/ Une des approches méthodologiques utilisées dans ce projet est décrite dans la recommandation G.851-01 (" Management of the transport network - Application of the RM-ODP framework) de l'UIT-T. 

3/ La notation UML (Unified Modeling Language) retenue ici est normalisée au sein du consortium OMG (Object Management Group). 

4/ Le modèle MOF (Meta Object Facility) normalisée à l'OMG sera également une des bases pour la modélisation. 

5/ Le langage de modélisation OCL (Object Constraint Language) est également normalisé par l'OMG. 

Ce projet a pour volonté d'être précurseur dans ce domaine en spécifiant et développant un outil inédit : un atelier de création de processus. 

remonter

Organisation du projet :  

Sous-projet 1 : Modèle générique de processus. 

Consiste à élaborer un modèle générique des méthodes de spécification de systèmes logiciels connues. On s'attachera à y prendre en compte les aspects purement orientés télécommunications (gestion de la répartition, de l'hétérogénéité des architectures, etc.). 

Sous-projet 2 : Processus pour le réseau de gestion des télécommunications. 

Elabore le modèle de la "méthode ODP" normalisée à l'UIT-T pour la spécification de services de gestion de réseau. Ce modèle peut être vu comme une utilisation particulière du modèle fourni par le sous-projet 1 et servira à l'alimenter. 

Sous-projet 3 : Processus pour le réseau intelligent. 

Elabore le modèle d'une méthode utilisée pour la spécification de services du réseau intelligent. Ce modèle est une autre utilisation du modèle fourni par le sous-projet 1 et servira à l'alimenter. 

Sous-projet 4 : Intégration de la qualité de service dans le couple processus / produit. 

Consiste en une étude sur la possibilité d'introduire certains paramètres de qualité de service dans une démarche d'analyse / conception pour les logiciels de télécommunications. Etudie aussi l'adéquation de la notation UML pour capturer les contraintes de qualité de service et propose des extensions éventuelles. 

Sous-projet 5 : Notations, processus et sémantiques. 

Etudie l'applicabilité de UML (notation normalisée) pour couvrir tous les aspects de la modélisation de processus de développement de logiciel de télécommunications basés sur le cadre architectural défini dans RM-ODP et prenant en compte certains paramètres de qualité de service. 

Sous-projet 6 : Prototypage d'un atelier de création de processus. 

Démontre la faisabilité d'un atelier de création de nouveaux processus, par réutilisation, composition, adaptation, etc de processus existants. 

Valorisation des recherches :  
La valorisation des résultats se fera à plusieurs niveaux : 
 

étude : contributions à l'OMG (groupe de travail sur la méthodologie et sur UML), éventuellement à l'UIT-T Commission 4 (travaux méthodologiques) ; soumission de publications à des conférences internationales, 

produit : à l'issue du projet, un démonstrateur sera réalisé. Il consistera en un atelier de création de processus, avec des possibilités d'échange entre outils, de réutilisation, etc. 

remonter

Résumé 


Le projet PILOTE a pour champ d'application la modélisation de tous les systèmes à caractère réparti, selon deux axes : la démarche et l'outillage. Il existe sur le marché plus de cinquante méthodes d'analyse / conception de logiciel à partir desquelles chaque entreprise peut décliner son processus. Aucune d'elles ne correspondant aux attentes de tout ingénieur méthodologiste au sein des entreprises, l'objectif est de permettre à celui-ci de composer le processus qui lui semble le plus approprié au regard des besoins et contraintes identifiés dans son entreprise / projet. Le projet PILOTE a pour ambition de constituer le modèle générique d'un certain nombre de méthodes connues ou à venir à partir duquel de nouveaux processus pourront être constitués. Les domaines touchés par le projet PILOTE incluent la modélisation des processus de spécification de logiciels industriels des télécommunications, les architectures, formalismes et notations pour la représentation de systèmes de télécommunications, la modélisation de mécanismes de traçabilité des besoins. Pour ce faire, le projet PILOTE se focalise sur la prise en compte de l'architecture en points de vue de RM-ODP (Reference Model for Open Distributed Processing), des méthodes de spécification qui en découlent et des travaux en cours sur l'intégration de la qualité de service dans les processus de spécification de systèmes logiciels. PILOTE s'appuie sur le modèle à objets MOF et la notation UML normalisés à l'OMG (Object Management Group). 
 

La prise en compte de la répartition est généralement peu ou pas couverte par les méthodes d'analyse / conception existantes ; or, les réseaux et services de télécommunications sont intrinsèquement de nature répartie. Il est donc primordial 1/ d'étudier un modèle de processus prenant en compte les besoins spécifiques des télécommunications et 2/ d'inciter fortement l'OMG à considérer ces contraintes spécifiques afin que la future génération d'ateliers de génie logiciel conçus et réalisés par les industriels de l'informatique présents à l'OMG apporte une réponse à nos besoins. Il est important que cette solution ne lèse pas les solutions de télécommunications françaises. PILOTE propose une collaboration nationale renforcée entre constructeurs, opérateurs et industriels de l'informatique pour que l'intégration de leur savoir-faire pèse plus lourd vis-à-vis des concurrents, présents à l'OMG ou en instance d'y adhérer.  

remonter

Ce projet vise à :  

1/ élaborer un modèle de processus générique (i.e. méthode d'analyse / conception de logiciel) s'inspirant de l'architecture du RM-ODP,  
2/ modéliser des processus de spécification de services de télécommunications (par ex. services de gestion de réseau, services du réseau intelligent) afin d'alimenter le modèle de processus décrit en 1/,  
3/ prototyper un atelier d'ingénierie de processus permettant, entre autres, de créer des processus à partir de composants réutilisables,  
4/ étudier les extensions nécessaires au modèle de processus afin de permettre la prise en compte de certaines contraintes de qualité de service (fiabilité, disponibilité, performance, etc.),  
5/étudier l'adéquation de la notation UML normalisée à l'OMG comme notation support dans la définition des produits identifiés dans le modèle de processus,  
6/ se positionner comme force française de contribution active et innovante à l'OMG, et plus particulièrement au "ProcessWorking Group" (travaillant sur l'ingénierie des processus), sous-groupe de "l'Analysis and Design Task Force" , notamment après avoir étudié l'apport de RM-ODP en termes de produits et processus aux travaux de l'OMG (UML, Process Working Group).  

Dans une démarche "processus / produit" (par processus, il faut entendre démarche de méthode d'analyse / conception de logiciel ; par produit, il faut entendre les artefacts créés par ces processus), les points 1, 2 et 3 se focalisent sur les aspects liés aux processus (mais ne s'y restreint pas), le point 5 sur les aspects liés aux produits ; enfin, le point 4 porte sur le couple produit / processus.   

Le projet PILOTE se situe au croisement de problèmes multiples et difficiles, à savoir la définition de processus de développement de logiciel de télécommunication, l'introduction nouvelle dans des processus de mécanismes de prise en compte du caractère réparti des systèmes et services télécoms, de la qualité de service depuis l'expression des besoins jusqu'à l'implantation finale, de la traçabilité trop souvent négligée. Le projet PILOTE compte exploiter les toutes nouvelles techniques de modélisation et notations sur lesquelles l'expertise est rare et disséminée dans les entreprises.  

La complexité du problème ainsi que la rareté des compétences dans les domaines touchés font que seule une structure comme celle du projet PILOTE peut apporter des résultats de bonne qualité.  

remonter

Les domaines d'application choisis par PILOTE représentent une priorité dans l'industrie des télécommunications. Les solutions systèmes et logicielles sont nombreuses. Cependant, on observe une tendance internationale visant à renforcer la participation des clients des produits pour converger plus vite et sans surcoût vers "la solution générique" adaptable aux fluctuations des exigences. L'enjeu économique est tel que les principaux acteurs du marché n'ont pas hésité à remettre en question leur technique de gestion des exigences. Nous pensons qu'il en est de même de leur processus, bien que cet aspect reste extrêmement protégé.  

Pour que les solutions françaises soient compétitives dans le domaine, PILOTE s'atèle à capitaliser le savoir-faire français en conception de systèmes répartis, et à démontrer concrètement, au moyen d'un atelier de génie logiciel et à travers des applications cruciales :  

qu'un tel savoir-faire est absent des solutions défendues actuellement à l'OMG,  

qu'il existe un moyen d'y remédier et  

que ce moyen est une carte à jouer pour réduire les coûts de développement et gagner les marchés.  

Partenaires du projet 

Alcatel CIT 
Bouygues Télécoms 
ENST Paris 
Softeam 
Université de Nantes 
France Télécoms 

Identification 
Projet Précompétitif  
Durée : 18 mois  
Date de Labellisation : 
4 novembre 1998 

Thème de l'appel 

Thème précompétitif 1 : 
Intégration du multimédia dans les réseaux  

Productivité et qualité du processus de développement des logiciels temps réels pour les équipements de télécommunications  

remonter

21.05.2008 16:28:15

  Logistique Magasinage Manutention : informatique : conception logiciels : umlmodeliser : Formation personnelle, Autoformation

Favorites Bookmarks Welcome  livre-d-or-nouveau  Blog Lomagman Nous sommes le Jeudi 27 Juillet 2017 et il est 09:04:41