summaryrefslogtreecommitdiffstats
path: root/tde-i18n-es/docs/kdesdk/umbrello/uml_basics.docbook
blob: c416ab80937a1a513537c2380ffeeb3f41de35da (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
<chapter id="uml-basics">
<title
>Introducción a &UML;</title>
<sect1 id="about-uml">
<title
>Acerca de &UML;</title>
<para
>Este capítulo proporciona una introducción rápida a las características básicas de &UML;. Tenga en cuenta que no se trata de un manual de referencia de &UML; sino de una breve introducción. Si desea más información sobre &UML;, o sobre el análisis y diseño del software en general, le recomendamos que lea cualquier de los libros publicados sobre el tema. También hay una buena cantidad de tutoriales en Internet, que puede utilizar como punto de partida. </para>

<para
>El lenguaje unificado de maquetación (&UML;)  sirve para especificar, visualizar y documentar esquemas de sistemas de software orientado a objetos. &UML; no es un método de desarrollo, lo que significa que no sirve para determinar qué hacer en primer lugar o cómo diseñar el sistema, sino que símplemente le ayuda a visualizar el diseño y a hacerlo más accesible para otros. &UML; está controlado por el grupo de administración de objetos (<acronym
>OMG</acronym
>) y es el estándar de descripción de esquemas de software. </para>
<para
>&UML; está diseñado para su uso con software orientado a objetos, y tiene un uso limitado en otro tipo de cuestiones de programación. </para>
<para
>&UML; se compone de muchos elementos de esquematización que representan las diferentes partes de un sistema de software. Los elementos &UML; se utilizan para crear diagramas, que representa alguna parte o punto de vista del sistema. &umbrello; soporta los siguientes tipos de diagramas: </para>

<itemizedlist>

<listitem
><para
><emphasis
><link linkend="use-case-diagram"
>Diagrama de casos de uso</link
></emphasis
> que muestra a los actores (otros usuarios del sistema), los casos de uso (las situaciones que se producen cuando utilizan el sistema) y sus relaciones.</para
> </listitem>

<listitem
><para
><emphasis
><link linkend="class-diagram"
>Diagrama de clases</link
></emphasis
> que muestra las clases y la relaciones entre ellas.</para
> </listitem>

<listitem
><para
><emphasis
><link linkend="sequence-diagram"
>Diagrama de secuencia</link
></emphasis
>  muestra los objetos y sus múltiples relaciones entre ellos.</para
> </listitem>

<listitem
><para
><emphasis
><link linkend="collaboration-diagram"
>Diagrama de colaboración</link
></emphasis
> que muestra objetos y sus relaciones, destacando los objetos que participan en el intercambio de mensajes.</para>
</listitem>

<listitem
><para
><emphasis
><link linkend="state-diagram"
>Diagrama de estado</link
></emphasis
> muestra estados, cambios de estado y eventos en un objeto o en parte del sistema.</para
> </listitem>

<listitem
><para
><emphasis
><link linkend="activity-diagram"
>Diagrama de actividad</link
></emphasis
> que muestra actividades, así como los cambios de una a otra actividad junto con los eventos que ocurren en ciertas partes del sistema.</para
></listitem>

<listitem
><para
><emphasis
><link linkend="state-diagram"
>Diagrama de componentes</link
></emphasis
> que muestra los componentes de mayor nivel de la programación (cosas como Kparts o Java Beans).</para
></listitem>

<listitem
><para
><emphasis
><link linkend="class-diagram"
>Diagrama de implementación</link
></emphasis
> que muestra las instancias de los componentes y sus relaciones.</para
></listitem
> 

</itemizedlist>

</sect1
>   <!-- about-uml -->

<sect1 id="uml-elements"
>  
<title
>Elementos de &UML;</title>
<sect2 id="use-case-diagram">
<title
>Diagrama de casos de uso</title>
<para
>Los diagramas de casos de uso describen las relaciones y las dependencias entre un grupo de <emphasis
>casos de uso</emphasis
> y los actores participantes en el proceso.</para>
<para
>Es importante resaltar que los diagramas de casos de uso no están pensados para representar el diseño y no puede describir los elementos internos de un sistema. Los diagramas de casos de uso sirven para facilitar la comunicación con los futuros usuarios del sistema, y con el cliente, y resultan especialmente útiles para determinar las características necesarias que tendrá el sistema. En otras palabras, los diagramas de casos de uso describen <emphasis
>qué</emphasis
> es lo que debe hacer el sistema, pero no <emphasis
>cómo</emphasis
>.</para>
<para>
<screenshot>
<screeninfo
>Ejemplo de un diagrama de casos de uso.</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="use-case-diagram.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>&umbrello; mostrando un diagrama de casos de uso</phrase>
	  </textobject>
	  <caption>
	    <para
>&umbrello; mostrar un diagrama de casos de uso </para>
	  </caption>
	</mediaobject>
</screenshot>
</para>
<sect3 id="use-case">
<title
>Caso de uso</title>
<para
>Un <emphasis
>caso de uso</emphasis
> describe, &mdash;desde el punto de vista de los actores&mdash;, un grupo de actividades de un sistema que produce un resultado concreto y tangible.</para>
<para
>Los casos de uso son descriptores de las interacciones típicas entre los usuarios de un sistema y ese mismo sistema. Representan el interfaz externo del sistema y especifican qué requisitos de funcionamiento debe tener este (recuerde, únicamente el qué, nunca el cómo). </para>
<para
>Cuando se trabaja con casos de uso, es importante tener presentes algunas secillas reglas: <itemizedlist>
 <listitem
><para
>Cada caso de uso está relacionado como mínimo con un actor.</para
></listitem>
 <listitem
><para
>Cada caso de uso es un iniciador (&ie;, un actor)</para
></listitem>
 <listitem
><para
>Cada caso de uso lleva a un resultado relevante (un resultado con <quote
>valor intrínseco</quote
>)</para>
 </listitem>
 </itemizedlist>
</para>
<para
>Los casos de uso pueden tener relaciones con otros casos de uso. Los tres tipos de relaciones más comunes entre casos de uso son:</para>
<itemizedlist>
<listitem
><para
><emphasis
>&lt;&lt;include&gt;&gt;</emphasis
> que especifica una situación en la que un caso de uso tiene lugar <emphasis
>dentro</emphasis
> de otro caso de uso</para
></listitem>
<listitem
><para
><emphasis
>&lt;&lt;extends&gt;&gt;</emphasis
> que especifica que en ciertas situaciones, o en algún punto (llamado punto de extensión) un caso de uso será extendido por otro.</para
></listitem>
<listitem
><para
><emphasis
>Generalización</emphasis
> que especifica que un caso de uso hereda las características del <quote
>super</quote
> caso de uso, y puede volver a especificar algunas o todas ellas de una forma muy similar a las herencias entre clases. </para>
</listitem>
</itemizedlist>
</sect3>
<sect3 id="actor">
<title
>Actor</title>
<para
>Un actor es una entidad externa (de fuera del sistema) que interacciona con el sistema participando (y normalmente iniciando) en un caso de uso. Los actores pueden ser gente real (por ejemplo, usuarios del sistema), otros ordenadores o eventos externos. </para>
<para
>Los actores no representan a personas <emphasis
>físicas</emphasis
> o a sistemas, sino su <emphasis
>papel</emphasis
>. Esto significa que cuando una persona interacciones con el sistema de diferentes maneras (asumiendo diferentes papeles), estará representado por varios actores. Por ejemplo, una persona que proporciona servicios de atención al cliente telefónicamente y realiza pedidos para los clientes estaría representada por un actor <quote
>equipo de soporte</quote
> y por otro actor <quote
>representante de ventas</quote
>. </para>
</sect3>
<sect3 id="use-case-description">
<title
>Descripción de casos de uso</title>
<para
>Las descripciones de casos de uso son reseñas textuales del caso de uso. Normalmente tienen el formato de una nota o un documento relacionado de alguna manera con el caso de uso, y explica los procesos o actividades que tienen lugar en el caso de uso. </para>
</sect3>
</sect2
> <!-- use-case-diagram -->

<sect2 id="class-diagram">
<title
>Diagrama de clases</title>
<para
>Los diagramas de clases muestran las diferentes clases que componen un sistema y cómo se relacionan unas con otras. Se dice que los diagramas de clases son diagramas <quote
>estáticos</quote
> porque muestran las clases, junto con sus métodos y atributos, así como las relaciones estáticas entre ellas: qué clases <quote
>conocen</quote
> a qué otras clases o qué clases <quote
>son parte</quote
> de otras clases, pero no muestran los métodos mediante los que se invocan entre ellas. </para>
<para>
<screenshot>
<screeninfo
>Ejemplo de un diagrama de clases</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="class-diagram.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>&umbrello; mostrando un diagrama de clases</phrase>
	  </textobject>
	  <caption>
	    <para
>&umbrello; mostrando un diagrama de clases </para>
	  </caption>
	</mediaobject>
</screenshot>
</para>
<sect3 id="class">
<title
>Clase</title>
<para
>Una clase define los atributos y los métodos de una serie de objetos. Todos los objetos de esta clase (instancias de esa clase) tienen el mismo comportamiento y el mismo conjunto de atributos (cada objetos tiene el suyo propio). En ocasiones se utiliza el término <quote
>tipo</quote
> en lugar de clase, pero recuerde que no son lo mismo, y que el término tipo tiene un significado más general. </para>
<para
>En &uml;, las clases están representadas por rectángulos, con el nombre de la clase, y también pueden mostrar atributos y operaciones de la clase en otros dos <quote
>compartimentos</quote
> dentro del rectángulo. </para>
<para>
<screenshot>
<screeninfo
>Una clase en &uml;</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="class.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>Representación visual de una clase en &UML;</phrase>
	  </textobject>
	  <caption>
	    <para
>Representación visual de una clase en &UML; </para>
	  </caption>
	</mediaobject>
</screenshot>
</para>
<sect4 id="attribute">
<title
>Atributos</title>
<para
>En &UML;, los atributos se muestran al menos con su nombre, y también pueden mostrar su tipo, valor inicial y otras propiedades. Los atributos también pueden ser mostrados visualmente: </para>
<itemizedlist>
<listitem
><para
><literal
>+</literal
> Indica atributos <emphasis
>públicos</emphasis
></para
></listitem>
<listitem
><para
><literal
>#</literal
> Indica atributos <emphasis
>protegidos</emphasis
></para
></listitem>
<listitem
><para
><literal
>-</literal
> Indica atributos <emphasis
>privados</emphasis
></para
></listitem>
</itemizedlist>
</sect4>
<sect4 id="operation">
<title
>Operaciones</title>
<para
>La operaciones (métodos) también se muestan al menos con su nombre, y pueden mostrar sus parámetros y valores de retorno. Las operaciones, al igual que los atributos, se pueden mostrar visualmente: <itemizedlist>
<listitem
><para
><literal
>+</literal
> Indica operaciones <emphasis
>públicas</emphasis
></para
></listitem>
<listitem
><para
><literal
>#</literal
> Indica operaciones <emphasis
>protegidas</emphasis
></para
></listitem>
<listitem
><para
><literal
>-</literal
> Indica operaciones <emphasis
>privadas</emphasis
></para
></listitem>
</itemizedlist>
</para>
</sect4>

<sect4 id="templates">
<title
>Plantillas</title>
<para
>Las clases pueden tener plantillas, un valor usado para una clase no especificada o un tipo. El tipo de plantilla se especifica cuando se inicia una clase (&ie; cuando se crea un objeto). Las plantillas existen en C++ y se introducirán en Java 1.5 con el nombre de Genéricos. </para>
</sect4>
</sect3>

<sect3 id="class-associations">
<title
>Asociaciones de clases</title>
<para
>Las clases se puede relaciones (estar asocionadas) con otras de diferentes maneras:</para>
<sect4 id="generalization">
<title
>Generalización</title>
<para
>La herencia es uno de los conceptos fundamentales de la programación orientada a objetos, en la que una clase <quote
>recoge</quote
> todos los atributos y operaciones de la clase de la que es heredera, y puede alterar/modificar algunos de ellos, así como añadir más atributos y operaciones propias.</para>
<para
>En &UML;, una asociación de <emphasis
>generalización</emphasis
> entre dos clases, coloca a estas en una jerarquía que representa el concepto de herencia de una clase derivada de la clase base. En &UML;, las generalizaciones se representan por medio de una línea que conecta las dos clases, con una flecha en el lado de la clase base. <screenshot>
<screeninfo
>Generalización</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="generalization.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>Representación visual de una generalización en &UML;</phrase>
	  </textobject>
	  <caption>
	    <para
>Representación visual de una generalización en &UML; </para>
	  </caption>
	</mediaobject>
</screenshot>
</para>
</sect4>

<sect4 id="uml-associations">
<title
>Asociaciones</title>
<para
>Una asociación representa una relación entre clases, y aporta la semántica común y la estructura de muchos tipos de <quote
>conexiones</quote
> entre objetos.</para>
<para
>Las asociaciones son los mecanismos que permite a los objetos comunicarse entre sí. Describe la conexión entre diferentes clases (la conexión entre los objetos reales se denomina conexión de objetos o <emphasis
>enlace</emphasis
>). </para>
<para
>Las asociaciones pueden tener una papel que especifica el propósito de la asociación y pueden ser unidireccionales o bidireccionales (indicando si los dos objetos participantes en la relación pueden intercambiar mensajes entre sí, o es únicamente uno de ellos el que recibe información del otro). Cada extremo de la asociación también tiene un valor de multiplicidad, que indica cuántos objetos de ese lado de la asociación están relacionados con un objeto del extremo contrario. </para>
<para
>En &UML;, las asociaciones se representan por medio de líneas que conectan las clases participantes en la relación, y también pueden mostrar el papel y la multiplicidad de cada uno de los participantes. La multiplicidad se muestra como un rango [mín...máx] de valores no negativos, con un asterisco (<literal
>*</literal
>) representando el infinito en el lado máximo. <screenshot>
<screeninfo
>Asociación en &UML;</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="association.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>Representación visual de una asociación en &UML;</phrase>
	  </textobject>
	  <caption>
	    <para
>Representación visual de una asociación en &UML; </para>
	  </caption>
	</mediaobject>
</screenshot>
</para>
</sect4>

<sect4 id="aggregation">
<title
>Acumulación</title>
<para
>Las acumulaciones son tipos especiales de asociaciones en las que las dos clases participantes no tienen un estado igual, pero constituyen una relación <quote
>completa</quote
>. Una acumulación describe cómo se compone la clase que asume el rol completo de otras clases que se encargan de las partes. En las acumulaciones, la clase que actúa como completa, tiene una multiplicidad de uno. </para>
<para
>En &UML;, las acumulaciones están representadas por una asociación que muestra un rombo en uno de los lados de la clase completa. <screenshot>
<screeninfo
>Acumulación</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="aggregation.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>Representación visual de una relación de acumulación en &UML;</phrase>
	  </textobject>
	  <caption>
	    <para
>Representación visual de una relación de acumulación en &UML; </para>
	  </caption>
	</mediaobject>
</screenshot>
</para>
</sect4>
<sect4 id="composition">
<title
>Composición</title>
<para
>Las composiciones son asociaciones que representan acumulaciones <emphasis
>muy fuertes</emphasis
>. Esto significa que las composiciones también forman relaciones completas, pero dichas relaciones son tan fuertes que las partes no pueden existir por sí mismas. Únicamente existen como parte del conjunto, y si este es destruido las partes también lo son.</para>
<para
>En &UML;, las composiciones están representadas por un rombo sólido al lado del conjunto. </para>
<para
><screenshot>
<screeninfo
>Composición</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="composition.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>Representación visual de una relación de composición en &UML;</phrase>
	  </textobject>
	</mediaobject>
</screenshot
></para>
</sect4>
</sect3
> <!--class-associations-->

<sect3 id="other-class-diagram-items">
<title
>Otros cmopnentes de los diagrama de clases</title>
<para
>Los diagramas de clases pueden contener más componentes aparte de clases.</para>
<sect4 id="interfaces">
<title
>Interfaces</title>
<para
>Las interfaces son clases abstractas, esto es, instancias que no pueden ser creadas directamente a partir de ellas. Pueden contener operaciones, pero no atributos. Las clases pueden heredarse de las interfaces pudiendo así realizarse instancias a partir de estos diagramas.</para>
<!-- FIXME screenshot -->
</sect4>
<sect4 id="datatype">
<title
>Tipo de datos</title>
<para
>Los tipo de datos son primitivas incluidas en algunos lenguajes de programación. Algunos ejemplos son: bool y float. No pueden tener relación con clases, pero las clases sí pueden relacionarse con ellos.</para>
<!-- FIXME screenshot -->
</sect4>
<sect4 id="enum">
<title
>Enumeraciones</title>
<para
>Las enumeraciones son simples listas de valores. Un ejemplo típico de esto sería una enumeración de los días de la semana. Al igual que los tipos de datos, no pueden relacionarse con las clases, pero las clases sí pueden hacerlo con ellos. </para>
<!-- FIXME screenshot -->
</sect4>
<sect4 id="package">
<title
>Paquetes</title>
<para
>Los paquetes, en lenguajes de programación, representan un espacio de nombres en un diagrama se emplean para representar partes del sistema que contienen más de una clase, incluso cientos de ellas.</para>
<!-- FIXME screenshot -->
</sect4>
</sect3>

</sect2
> <!-- class diagram -->

<sect2 id="sequence-diagram">
<title
>Diagramas de secuencia</title>

<para
>Los diagramas de secuencia muestran el intercambio de mensajes (&ie; la forma en que se invocan) en un momento dado. Los diagramas de secuencia ponen especial énfasis en el orden y el momento en que se envían los mensajes a los objetos.</para>

<para
>En los diagramas de secuencia, los objetos están representados por líneas intermitentes verticales, con el nombre del objeto en la parte más alta. El eje de tiempo también es vertical, incrementándose hacia abajo, de forma que los mensajes son enviados de un objeto a otro en forma de flechas con los nombres de la operación y los parámetros. </para>

<!-- FIXME update screenshot to show synchronous messages -->
<screenshot>
<screeninfo
>Diagrama de secuencia</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="sequence-diagram.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>&umbrello; mostrando un diagrama de secuencia</phrase>
	  </textobject>
	  <caption>
	    <para
>&umbrello; mostrando un diagrama de secuencia </para>
	  </caption>
	</mediaobject>
</screenshot>

<para
>Los mensajes pueden ser o bien síncronos, el tipo normal de llamada del mensaje donde se pasa el control a objeto llamado hasta que el método finalize, o asíncronos donde se devuelve el control directamente al objeto que realiza la llamada. Los mensajes síncronos tienen una caja vertical en un lateral del objeto invocante que muestra el flujo del control del programa.</para>
</sect2
> <!-- sequence diagrams -->

<sect2 id="collaboration-diagram">
<title
>Diagramas de colaboración</title>

<para
>Los diagramas de colaboración muestran las interacciones que ocurren entre los objetos que participan en una situación determinada. Esta es más o menos la misma información que la mostrada por los diagramas de secuencia, pero destacando la forma en que las operaciones se producen en el tiempo, mientras que los diagramas de colaboración fijan el interés en las relaciones entre los objetos y su topología.</para>

<para
>En los diagramas de colaboración los mensajes enviados de un objeto a otro se representan mediante flechas, mostrando el nombre del mensaje, los parámetros y la secuencia del mensaje. Los diagramas de colaboración están indicados para mostrar una situación o flujo programa específicos y son unos de los mejores tipos de diagramas para demostrar o explicar rápidamente un proceso dentro de la lógica del programa. </para>

<screenshot>
<screeninfo
>Colaboración</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="collaboration-diagram.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>&umbrello; mostrando un diagrama de colaboración</phrase>
	  </textobject>
	  <caption>
	    <para
>&umbrello; mostrando un diagrama de colaboración </para>
	  </caption>
	</mediaobject>
</screenshot>

</sect2
> <!-- collaboration diagrams -->

<sect2 id="state-diagram">
<title
>Diagrama de estado</title>
<para
>Los diagramas de estado muestran los diferentes estados de un objeto durante su vida, y los estímulos que provocan los cambios de estado en un objeto. </para
>                              
<para
>Los diagramas de estado ven a los objetos como <emphasis
>máquinas de estado</emphasis
> o autómatas finitos que pueden estar en un conjunto de estados finitos y que pueden cambiar su estado a través de un estímulo perteneciente a un conjunto finito. Por ejemplo, un objeto de tipo <emphasis
>NetServer</emphasis
> puede tener durante su vida uno de los siguientes estados: </para>
<itemizedlist>
<listitem
><para
>Listo</para
></listitem>
<listitem
><para
>Escuchando</para
></listitem>
<listitem
><para
>Trabajando</para
></listitem>
<listitem
><para
>Detenido</para
></listitem>
</itemizedlist>
<para
>y los eventos que pueden producir que el objeto cambie de estado son</para>
<itemizedlist>
<listitem
><para
>Se crea el objeto</para
></listitem>
<listitem
><para
>El objeto recibe un mensaje de escucha</para
></listitem>
<listitem
><para
>Un cliente solicita una conexión a través de la red</para
></listitem>
<listitem
><para
>Un cliente finaliza una solicitud</para
></listitem>
<listitem
><para
>La solicitud se ejecuta y ser termina</para
></listitem>
<listitem
><para
>El objeto recibe un mensaje de detención</para
></listitem>
<listitem
><para
>etc</para
></listitem>
</itemizedlist>
<para>
<screenshot>
<screeninfo
>Diagrama de estado</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="state-diagram.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>&umbrello; mostrando un diagrama de estado</phrase>
	  </textobject>
	  <caption>
	    <para
>&umbrello; mostrando un diagrama de estado </para>
	  </caption>
	</mediaobject>
</screenshot>
</para>
<sect3 id="state">
<title
>Estado</title>
<para
>Los estados son los ladrillos de los diagramas de estado. Un estado pertenece a exactamente una clase y representa un resumen de los valores y atributos que puede tener la clase. Un estado &UML; describe el estado interno de un objeto de una clase particular </para
>                       
<para
>Tenga en cuenta que no todos los cambios en los atributos de un objeto deben estar representados por estados, sino únicamente aquellos cambios que pueden afectar significativamente a la forma de funcionamiento del objeto</para>
<para
>Hay dos tipos especiales de estados: inicio y fin. Son especiales en el sentido de que no hay ningún evento que pueda devolver a un objeto a su estado de inicio, y de la misma forma no hay ningún evento que pueda sacar a un objeto de su estado de fin. </para>
</sect3>

</sect2
> <!-- state diagrams -->

<sect2 id="activity-diagram">
<title
>Diagrama de actividad</title>
<para
>Los diagramas de actividad describen la secuencia de las actividades en un sistema. Los diagramas de actividad son una forma especial de los diagramas de estado, que únicamente (o mayormente) contienen actividades. </para>
<para>
<screenshot>
<screeninfo
>Ejemplo de un diagrama de actividad.</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="activity-diagram.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>&umbrello; mostrando un diagrama de actividad</phrase>
	  </textobject>
	  <caption>
	    <para
>&umbrello; mostrando un diagrama de actividad </para>
	  </caption>
	</mediaobject>
</screenshot>
</para>
<para
>Los diagramas de actividad son similares a los diagramas de flujo procesales, con la diferencia de que todas las actividades están claramente unidas a objetos.</para>

<para
>Los diagramas de actividad siempre están asociados a una <emphasis
>clase</emphasis
>, a una <emphasis
>operación</emphasis
> o a un <emphasis
>caso de uso</emphasis
>.</para>

<para
>Los diagramas de actividad soportan actividades tanto secuenciales como paralelas. La ejecución paralela se representa por medio de iconos de fork/espera, y en el caso de las actividades paralelas, no importa en qué orden sean invocadas (pueden ser ejecutadas simultáneamente o una detrás de otra).</para>
<sect3 id="activity">
<title
>Actividad</title>
<para
>Una actividad es un único paso de un proceso. Una activa es un estado del sistema que actividad interna y, al menos, una transición saliente. Las actividades también pueden tener más de una transición saliente, si tienen diferentes condiciones. </para
> 
<para
>Las actividades pueden formar jerarquías, lo que significa que una actividad puede estar formada de varias actividades <quote
>de detalle</quote
>, en cuyo caso las transiciones entrantes y salientes deberían coincidir con las del diagrama de detalle. </para>

</sect3>
</sect2
> <!-- activity diagram -->

<sect2 id="helper-elements">
<title
>Elementos de ayuda</title>
<para
>Existen unos pocos elementos en &UML; que no tiene un valor semántico real en la maqueta, pero que ayudan a clarificar partes del programa. Estos elementos son </para>
<itemizedlist>
<listitem
><para
>Línea de texto</para
></listitem>
<listitem
><para
>Notas de texto y enlaces</para
></listitem>
<listitem
><para
>Cajas</para
></listitem>
</itemizedlist
>   
<para
>Las líneas de texto son útiles para añadir información textual a un diagrama. Es texto es libre y no tiene ningún significado para la maqueta. </para
>           

<para
>Las notas son útiles para añadir información más detallada de un objeto o una situación específica. Tienen la gran ventaja de que se pueden anclar a los elementos &UML; para mostrar que una nota <quote
>pertenece</quote
> a un objeto o situación específicos </para>

<para
>Las cajas son rectángulos repartidos libremente que pueden usarse para juntar objetos haciendo los diagramas más legibles. No tienen significado lógico en la maqueta</para>

<!-- FIXME, screenshot -->
</sect2
> <!-- helper elements -->

<sect2 id="component-diagram">
<title
>Diagramas de componentes</title>
<para
>Los diagramas de componentes muestran los componentes del software (ya sea las tecnologías que lo forman como Kparts, componentes CORBA, Java Beans o simplemente secciones del sistema claramente distintas) y los artilugios de que está compuesto como los archivos de código fuente, las librerías o las tablas de una base de datos.</para>

<para
>Los componentes pueden tener interfaces (&ie; clases abstractas con operaciones) que permiten asociaciones entre componentes.</para>
</sect2>

<sect2 id="deployment-diagram">
<title
>Diagramas de implementación</title>

<para
>Los diagramas de implementación muestran las instancias existentes al ejecutarse así como sus relaciones. También se representan los nodos que identifican recursos físicos, típicamente un ordenador así como interfaces y objetos (instancias de las clases).</para>

</sect2>

</sect1
> 
</chapter>