analyticstracking

Favorites Bookmarks Welcome  livre-d-or-nouveau  Blog Lomagman Nous sommes le Mardi 26 Septembre 2017 et il est 21:48:16

 

 
 
 

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

 
Warning: Cannot modify header information - headers already sent by (output started at /home/clients/343274d977c1f129bc0ad0694bf07ce6/web/include_haut.php:290) in /home/clients/343274d977c1f129bc0ad0694bf07ce6/web/include_haut.php on line 2
Logistique Magasinage Manutention : informatique : conception logiciels : umlmodeliser : Formation personnelle, Autoformation

Favorites Bookmarks Welcome  livre-d-or-nouveau  Blog Lomagman Nous sommes le Mardi 26 Septembre 2017 et il est 21:48:16