|
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.
|
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 :
-
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
-
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.
-
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.
-
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 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
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
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.
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 |
Nous sommes le
Samedi 17 Juin 2017 et il est 09:07:46
clés d'accès
Chantal Morlay
Win
zip