summaryrefslogtreecommitdiffstats
path: root/tde-i18n-sv/docs/kdesdk/umbrello/uml_basics.docbook
blob: 719dbab3aee4000b55c0c9f75e4e47e39110b35c (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
<chapter id="uml-basics">
<title
>Grundläggande &UML;</title>
<sect1 id="about-uml">
<title
>Om &UML;</title>
<para
>Det här kapitlet ger en snabb översikt av grunderna i &UML;. Kom ihåg att det här inte är en heltäckande &UML;-handledning, utan bara en kortfattad introduktion till &UML; som kan läsas som &UML;-handledning. Om du skulle vilja lära dig mer om Unified Modelling Language, eller om allmän analys och konstruktion av programvara, hänvisas du till några av de många böcker som är tillgängliga i ämnet. Det finns också många handledningar på Internet, som du kan använda som startpunkt. </para>

<para
>Unified Modelling Language (&UML;) är ett diagrambaserat språk eller notation för att specificera, visualisera och dokumentera modeller av objektorienterad programvara. &UML; är inte en utvecklingsmetod, vilket betyder att det inte talar om för dig vad du ska göra först och vad du ska göra därefter, eller hur du ska konstruera system, men det hjälper till att visualisera konstruktionen och kommunicera med andra. &UML; styrs av Object Management Group (<acronym
>OMG</acronym
>), och är industristandard för att beskriva modeller av programvara. </para>
<para
>&UML; är konstruerat för design av objektorienterad programvara, och har begränsad användning för andra programmeringsparadigmer. </para>
<para
>&UML; är uppbyggt av många modelleringselement som representerar olika delar av programsystemet. &UML;-elementen används för att skapa diagram, som representerar en viss del, eller en synvinkel av systemet. Följande sorters diagram stöds av &umbrello;: </para>

<itemizedlist>

<listitem
><para
><emphasis
><link linkend="use-case-diagram"
>Användningsfallsdiagram</link
></emphasis
> visar aktörer (människor eller andra användare av systemet), användningsfall (scenarion då de använder systemet), och deras samband</para
> </listitem>

<listitem
><para
><emphasis
><link linkend="class-diagram"
>Klassdiagram</link
></emphasis
> visar klasser, och sambanden mellan dem</para
> </listitem>

<listitem
><para
><emphasis
><link linkend="sequence-diagram"
>Sekvensdiagram</link
></emphasis
> visar objekt och deras samband, med betoning på utbyte av meddelanden mellan objekt i kronologisk ordning</para
> </listitem>

<listitem
><para
><emphasis
><link linkend="collaboration-diagram"
>Samarbetsdiagram</link
></emphasis
> visar objekt och deras samband, med betoning på objekten som deltar i utbytet av meddelanden</para>
</listitem>

<listitem
><para
><emphasis
><link linkend="state-diagram"
>Tillståndsdiagram</link
></emphasis
> visar tillstånd, tillståndsändringar och händelser för ett objekt eller en del av systemet</para
> </listitem>

<listitem
><para
><emphasis
><link linkend="activity-diagram"
>Aktivitetsdiagram</link
></emphasis
> visar aktiviteter, tillstånd och tillståndsändringar hos objekt och händelser som sker i någon del av systemet</para
></listitem>

<listitem
><para
><emphasis
><link linkend="component-diagram"
>Komponentdiagram</link
></emphasis
> visar programmeringskomponenter på hög nivå (som Kparts eller Java Beans).</para
></listitem>

<listitem
><para
><emphasis
><link linkend="deployment-diagram"
>Utplaceringsdiagram</link
></emphasis
> visar komponenternas instanser och deras inbördes förhållanden.</para
></listitem
> 

</itemizedlist>

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

<sect1 id="uml-elements"
>  
<title
>&UML;-element</title>
<sect2 id="use-case-diagram">
<title
>Användningsfallsdiagram</title>
<para
>Användningsfallsdiagram beskriver samband och beroenden mellan en grupp <emphasis
>användningsfall</emphasis
> och aktören som deltar i processen.</para>
<para
>Det är viktigt att observera att användningsfallsdiagram inte är lämpade att representera konstruktionen, och kan inte beskriva systemets innanmäte. Användningsfallsdiagram är avsedda att möjliggöra kommunikation med framtida användare av systemet, och med kunden. De är till särskild hjälp för att avgöra vilka funktioner som krävs att systemet ska ha. Med andra ord talar användningsfallsdiagram om <emphasis
>vad</emphasis
> systemet ska göra, men de anger inte &mdash; och kan inte ange &mdash; <emphasis
>hur</emphasis
> detta ska åstadkommas.</para>
<para>
<screenshot>
<screeninfo
>Ett exempel på användningsfallsdiagram.</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="pics/use-case-diagram.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>&umbrello; som visar ett användningsfallsdiagram</phrase>
	  </textobject>
	  <caption>
	    <para
>&umbrello; som visar ett användningsfallsdiagram </para>
	  </caption>
	</mediaobject>
</screenshot>
</para>
<sect3 id="use-case">
<title
>Användningsfall</title>
<para
>Ett <emphasis
>användningsfall</emphasis
> beskriver &mdash; från aktörernas synvinkel &mdash; en samling aktiviteter i ett system, som ger upphov till ett konkret, påtagligt resultat.</para>
<para
>Användningsfall är beskrivningar av typisk växelverkan mellan användarna av ett system och systemet själv. De representerar systemets yttre gränssnitt, och anger en sorts krav på vad systemet ska göra (kom ihåg, bara vad, inte hur). </para>
<para
>Vid arbete med användningsfall, är det viktigt att komma ihåg några enkla regler: <itemizedlist>
 <listitem
><para
>Varje användningsfall hör ihop med minst en aktör</para
></listitem>
 <listitem
><para
>Varje användningsfall har ett ursprung (dvs. en aktör)</para
></listitem>
 <listitem
><para
>Varje användningfall leder till ett relevant resultat (ett resultat med <quote
>affärsvärde</quote
>).</para>
 </listitem>
 </itemizedlist>
</para>
<para
>Användningfall kan också ha samband med andra användningfall. De tre mest typiska sorters samband mellan användningfall är:</para>
<itemizedlist>
<listitem
><para
><emphasis
>&lt;&lt;include&gt;&gt;</emphasis
> (innehåller), vilket anger att användningsfallet äger rum <emphasis
>inne i</emphasis
> ett annat användningsfall</para
></listitem>
<listitem
><para
><emphasis
>&lt;&lt;extends&gt;&gt;</emphasis
> (utökar), vilket anger att i vissa fall, eller vid något tillfälle (som kallas en utökningspunkt), kommer ett användningsfall att utökas av ett annat.</para
></listitem>
<listitem
><para
><emphasis
>Generalisering</emphasis
> anger att ett användningfall ärver egenskaperna för <quote
>super</quote
>-användningsfallet, och kan överskrida några av dem, eller lägga till nya på samma sätt som arv mellan klasser. </para>
</listitem>
</itemizedlist>
</sect3>
<sect3 id="actor">
<title
>Aktör</title>
<para
>En aktör är en extern enhet (utanför systemet) som växelverkar med systemet genom att delta i (och ofta inleda) ett användningsfall. Aktörer kan i verkligheten vara människor (till exempel användare av systemet), andra datorsystem eller yttre händelser. </para>
<para
>Aktörer representerar inte <emphasis
>fysiska</emphasis
> människor eller system, utan deras <emphasis
>roll</emphasis
>. Det betyder att när en person växelverkar med systemet på olika sätt (antar olika roller) representeras han med flera aktörer. En person som till exempel ger kundstöd via telefon och tar emot beställningar från kunden till systemet, skulle representeras av aktören <quote
>kundstödspersonal</quote
> och aktören <quote
>försäljningsassistens</quote
>. </para>
</sect3>
<sect3 id="use-case-description">
<title
>Beskrivning av användningsfall</title>
<para
>En beskrivning av ett användningsfall är en textbaserad berättelse om användningsfallet. Det är ofta i form av en anteckning eller ett dokument som på något sätt är länkat till användningsfallet, och förklarar processerna eller aktiviteterna som äger rum i användningsfallet. </para>
</sect3>
</sect2
> <!-- use-case-diagram -->

<sect2 id="class-diagram">
<title
>Klassdiagram</title>
<para
>Klassdiagram visar de olika klasserna som bygger upp ett system och hur de relateras till varandra. Klassdiagram sägs vara <quote
>statiska</quote
> diagram, eftersom de visar klasserna, tillsammans med deras metoder och attribut, samt det statiska förhållandet mellan dem: vilka klasser som <quote
>känner till</quote
> andra klasser, eller vilka klasser som <quote
>är en del</quote
> av andra klasser, men visar inte metodanrop mellan dem. </para>
<para>
<screenshot>
<screeninfo
>Ett exempel på ett klassdiagram</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="pics/class-diagram.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>&umbrello; som visar ett klassdiagram</phrase>
	  </textobject>
	  <caption>
	    <para
>&umbrello; som visar ett klassdiagram </para>
	  </caption>
	</mediaobject>
</screenshot>
</para>
<sect3 id="class">
<title
>Klass</title>
<para
>En klass definierar attributen och metoderna för en mängd objekt. Alla objekt av klassen (instanser av klassen) delar samma beteende, och har samma mängd attribut (varje objekt har sin egen uppsättning). Termen <quote
>typ</quote
> används ibland istället för klass, men det är viktigt att nämna att de två inte är samma sak, och att typ är en mer generell term. </para>
<para
>Klasser i &UML; representeras av rektanglar, med klassens namn, och kan också visa klassens attribut och operationer i två <quote
>fack</quote
> inne i rektangeln. </para>
<para>
<screenshot>
<screeninfo
>En klass i &UML;</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="pics/class.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>Visuell representation av en klass i &UML;</phrase>
	  </textobject>
	  <caption>
	    <para
>Visuell representation av en klass i &UML; </para>
	  </caption>
	</mediaobject>
</screenshot>
</para>
<sect4 id="attribute">
<title
>Attribut</title>
<para
>Attribut i &UML; visas åtminstone med sina namn, och kan också visas med typ, ursprungligt värde och andra egenskaper. Attribut kan också visas med synlighet: </para>
<itemizedlist>
<listitem
><para
><literal
>+</literal
> Betyder <emphasis
>öppna</emphasis
> (public) attribut</para
></listitem>
<listitem
><para
><literal
>#</literal
> Betyder <emphasis
>skyddade</emphasis
> (protected) attribut</para
></listitem>
<listitem
><para
><literal
>-</literal
> Betyder <emphasis
>privata</emphasis
> (private) attribut</para
></listitem>
</itemizedlist>
</sect4>
<sect4 id="operation">
<title
>Operationer</title>
<para
>Operationer (metoder) visas också åtminstone med sina namn, och kan också visas med parametrar och returtyper. Operationer, precis som attribut, kan visas med sin synlighet: <itemizedlist>
<listitem
><para
><literal
>+</literal
> Betyder <emphasis
>öppna</emphasis
> (public) operationer</para
></listitem>
<listitem
><para
><literal
>#</literal
> Betyder <emphasis
>skyddade</emphasis
> (protected) operationer</para
></listitem>
<listitem
><para
><literal
>-</literal
> Betyder <emphasis
>privata</emphasis
> (private) operationer</para
></listitem>
</itemizedlist>
</para>
</sect4>

<sect4 id="templates">
<title
>Mallar</title>
<para
>Klasser kan ha mallar, ett värde som används för en ospecificerad klass eller typ. Malltypen anges när klassen initieras (dvs. ett objekt skapas). Mallar finns i modern C++ och kommer att introduceras i Java 1.5, där de kallas Generics. </para>
</sect4>
</sect3>

<sect3 id="class-associations">
<title
>Klassassociationer</title>
<para
>Klasser kan relateras till (associeras med) varandra på olika sätt:</para>
<sect4 id="generalization">
<title
>Generalisering</title>
<para
>Arv är ett av de grundläggande koncepten i objektorienterad programmering, där en klass <quote
>erhåller</quote
> alla attribut och operationer från klassen den ärver från, och kan överskrida/ändra några av dem, samt lägga till fler egna attribut och operationer.</para>
<para
>En <emphasis
>generalisering</emphasis
> mellan två klasser i &UML;, placerar dem i en hierarki som representerar arvkonceptet för en härledd klass från en basklass. Generaliseringar i &UML; representeras med en linje som binder samman de två klasserna, med en pil på basklassens sida. <screenshot>
<screeninfo
>Generalisering</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="pics/generalization.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>Visuell representation av en generalisering i &UML;</phrase>
	  </textobject>
	  <caption>
	    <para
>Visuell representation av en generalisering i &UML; </para>
	  </caption>
	</mediaobject>
</screenshot>
</para>
</sect4>

<sect4 id="uml-associations">
<title
>Associationer</title>
<para
>En association representerar ett samband mellan klasser, och ger den allmänna semantiken och strukturen för många typer av <quote
>förbindelse</quote
> mellan objekt.</para>
<para
>Associationer är mekanismen som tillåter att objekt kommunicerar med varandra. De beskriver förbindelsen mellan olika klasser (förbindelsen mellan de verkliga objekten kallas objektförbindelse, eller <emphasis
>länk</emphasis
>). </para>
<para
>Associationer kan ha en roll, som anger associationens syfte, och kan vara enkelriktade eller ömsesidiga (anger om två objekt som deltar i sambandet kan skicka meddelanden till det andra, eller om bara ett av dem känner till det andra). Varje ända av associationen har också ett mångfaldsvärde, som bestämmer hur många objekt på denna sida av associationen som kan relatera till ett objekt på andra sidan. </para>
<para
>Associationer i &UML; representeras som linjer som binder samman klasserna som deltar i sambandet, och kan också visa rollen och mångfalden för var och en av deltagarna. Mångfald visas som ett intervall [minimum..maximum] med icke-negativa värden, med en asterisk (*) på maximumsidan som representerar oändlighet. <screenshot>
<screeninfo
>&UML;-association</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="pics/association.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>Visuell representation av en association i &UML;</phrase>
	  </textobject>
	  <caption>
	    <para
>Visuell representation av en association i &UML; </para>
	  </caption>
	</mediaobject>
</screenshot>
</para>
</sect4>

<sect4 id="aggregation">
<title
>Aggregering</title>
<para
>Aggregeringar är särskilda sorters associationer, där de två deltagande klasserna inte har en likvärdig status, utan utgör ett <quote
>helhet-del</quote
> samband. En aggregering beskriver hur klassen som intar rollen som helhet, är sammansatt av (har) andra klasser, som intar rollerna som delar. Klassen som fungerar som helhet har alltid mångfalden ett, för aggregeringar. </para>
<para
>Aggregeringar i &UML; representeras av en association som visar en romb på sidan som hör till helheten. <screenshot>
<screeninfo
>Aggregering</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="pics/aggregation.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>Visuell representation av en aggregeringsrelation i &UML;</phrase>
	  </textobject>
	  <caption>
	    <para
>Visuell representation av en aggregeringsrelation i &UML; </para>
	  </caption>
	</mediaobject>
</screenshot>
</para>
</sect4>
<sect4 id="composition">
<title
>Sammansättning</title>
<para
>Sammansättningar är associationer som representerar <emphasis
>mycket starka</emphasis
> aggregeringar. Det betyder att sammansättningar också formar helhet-del samband, men att sambandet är så starkt att delarna inte kan existera för sig själv. De finns bara inne i helheten, och om helheten förstörs, försvinner också delarna.</para>
<para
>Sammansättning i &UML; representeras av en ifylld romb på sidan som hör till helheten. </para>
<para
><screenshot>
<screeninfo
>Sammansättning</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="pics/composition.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>Visuell representation av en sammansättningsrelation i &UML;</phrase>
	  </textobject>
	</mediaobject>
</screenshot
></para>
</sect4>
</sect3
> <!--class-associations-->

<sect3 id="other-class-diagram-items">
<title
>Andra objekt i klassdiagram</title>
<para
>Klassdiagram kan innehålla flera andra objekt förutom klasser.</para>
<sect4 id="interfaces">
<title
>Gränssnitt</title>
<para
>Gränssnitt är abstrakta klasser vilket betyder att instanser inte direkt kan skapas från dem. De kan innehålla operationer men inga attribut. Klasser kan ärva från gränssnitt (via en realisationsassociation) och instanser kan därefter skapas av diagrammen.</para>
<!-- FIXME screenshot -->
</sect4>
<sect4 id="datatype">
<title
>Datatyper</title>
<para
>Datatyper är primitiver som typiskt är inbyggda i ett programspråk. Vanliga exempel omfattar heltal och en boolesk typ. De kan inte ha samband med klasser, men klasser kan ha samband med dem.</para>
<!-- FIXME screenshot -->
</sect4>
<sect4 id="enum">
<title
>Uppräkningstyper</title>
<para
>Uppräkningstyper är enkla listor med värden. Ett typiskt exempel är en uppräkningstyp av veckodagar. Medlemmar i en uppräkningstyp kallas uppräkningsvärden. Som datatyper kan de inte ha samband med klasser, men klasser kan ha samband med dem.</para>
<!-- FIXME screenshot -->
</sect4>
<sect4 id="package">
<title
>Paket</title>
<para
>Paket representerar namnrymder i ett programspråk. I ett diagram används de för att representera delar i ett system som innehåller mer än en klass, kanske hundratals klasser.</para>
<!-- FIXME screenshot -->
</sect4>
</sect3>

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

<sect2 id="sequence-diagram">
<title
>Sekvensdiagram</title>

<para
>Sekvensdiagram visar utbyte av meddelanden (dvs. metodanrop) mellan flera objekt, i en specifik, tidsbegränsad situation. Sekvensdiagram lägger särskild vikt vid ordningen och tiden då meddelanden till objekt skickas.</para>

<para
>Objekt representeras av vertikala streckade linjer i sekvensdiagram, med objektets namn överst. Tidsaxeln är också vertikal, och ökar neråt, så att meddelanden skickas från ett objekt till ett annat i form av pilar med operationer och parameternamn. </para>

<!-- FIXME update screenshot to show synchronous messages -->
<screenshot>
<screeninfo
>Sekvensdiagram</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="pics/sequence-diagram.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>&umbrello; som visar ett sekvensdiagram</phrase>
	  </textobject>
	  <caption>
	    <para
>&umbrello; som visar ett sekvensdiagram </para>
	  </caption>
	</mediaobject>
</screenshot>

<para
>Meddelanden kan antingen vara synkrona, den normala typen för meddelandeanrop där kontrollen övergår till det anropade objektet till metoden har kört färdigt, eller asynkront där kontrollen direkt återgår till anropande objekt. Synkrona meddelanden har en vertikal ruta vid sidan om det anropade objektet, för att visa programflödet.</para>
</sect2
> <!-- sequence diagrams -->

<sect2 id="collaboration-diagram">
<title
>Samarbetsdiagram</title>

<para
>Samarbetsdiagram visar växelverkan mellan objekt som deltar i en speciell situation. Det här är mer eller mindre samma information som visas i sekvensdiagram, men där läggs vikten vid hur växelverkan sker i tiden, medan samarbetsdiagram lägger vikten vid sambanden mellan objekten och deras topologi.</para>

<para
>I samarbetsdiagram representeras meddelanden från ett objekt till ett annat med pilar, som visar meddelandets namn, parametrar och meddelandesekvensen. Samarbetsdiagram är särskilt lämpade att visa ett särskilt programflöde eller situation, och är bland de bästa diagramtyperna för att snabbt demonstrera eller förklara en process i programmets logik. </para>

<screenshot>
<screeninfo
>Samarbete</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="pics/collaboration-diagram.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>&umbrello; som visar ett samarbetsdiagram</phrase>
	  </textobject>
	  <caption>
	    <para
>&umbrello; som visar ett samarbetsdiagram </para>
	  </caption>
	</mediaobject>
</screenshot>

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

<sect2 id="state-diagram">
<title
>Tillståndsdiagram</title>
<para
>Tillståndsdiagram visar de olika tillstånd ett objekt har under sin livstid, och de stimuli som orsakar att objektet ändrar sitt tillstånd. </para
>                              
<para
>Tillståndsdiagram ser objekt som <emphasis
>tillståndsmaskiner</emphasis
> eller finita automater, som kan vara i något av en mängd begränsade tillstånd och som kan ändra sina tillstånd via något av ett begränsat antal stimuli. Ett objekt av typen <emphasis
>Nätserver</emphasis
>, kan till exempel vara i något av följande tillstånd under sin livstid: </para>
<itemizedlist>
<listitem
><para
>Klar</para
></listitem>
<listitem
><para
>Lyssnar</para
></listitem>
<listitem
><para
>Arbetar</para
></listitem>
<listitem
><para
>Stoppad</para
></listitem>
</itemizedlist>
<para
>och händelserna som kan göra att ett objekt byter tillstånd är</para>
<itemizedlist>
<listitem
><para
>Objektet skapas</para
></listitem>
<listitem
><para
>Objektet tar emot meddelandet att lyssna</para
></listitem>
<listitem
><para
>En klient begär en anslutning via nätverket</para
></listitem>
<listitem
><para
>En klient avslutar en begäran</para
></listitem>
<listitem
><para
>En begäran körs och avslutas</para
></listitem>
<listitem
><para
>Objektet tar emot meddelandet att stoppa</para
></listitem>
<listitem
><para
>etc</para
></listitem>
</itemizedlist>
<para>
<screenshot>
<screeninfo
>Tillståndsdiagram</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="pics/state-diagram.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>&umbrello; som visar ett tillståndsdiagram</phrase>
	  </textobject>
	  <caption>
	    <para
>&umbrello; som visar ett tillståndsdiagram </para>
	  </caption>
	</mediaobject>
</screenshot>
</para>
<sect3 id="state">
<title
>Tillstånd</title>
<para
>Tillstånd är byggblocken i tillståndsdiagram. Ett tillstånd hör till exakt en klass, och representerar en summering av de värden klassens attribut kan inta. Ett &UML;-tillstånd beskriver det interna tillståndet för ett objekt av en viss klass. </para
>                       
<para
>Observera att inte varje ändring av något av ett objekts attribut ska representeras som ett tillstånd, utan bara de ändringar som väsentligt kan påverka objektets arbete.</para>
<para
>Det finns två speciella typer av tillstånd: start och slut. De är speciella på det sättet att det inte finns någon händelse som kan göra att ett objekt återgår till sitt starttillstånd, och på samma sätt finns det ingen händelse som gör det möjligt för ett objekt att lämna sitt sluttillstånd när det väl har nåtts. </para>
</sect3>

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

<sect2 id="activity-diagram">
<title
>Aktivitetsdiagram</title>
<para
>Aktivitetsdiagram beskriver en följd av händelser i ett system, med hjälp av aktiviteter. Aktivitetsdiagram är en speciell form av tillståndsdiagram, som bara (eller i huvudsak) innehåller aktiviteter. </para>
<para>
<screenshot>
<screeninfo
>Ett exempel på aktivitetsdiagram</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="pics/activity-diagram.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>&umbrello; som visar ett aktivitetsdiagram</phrase>
	  </textobject>
	  <caption>
	    <para
>&umbrello; som visar ett aktivitetsdiagram </para>
	  </caption>
	</mediaobject>
</screenshot>
</para>
<para
>Aktivitetsdiagram liknar procedurella flödesdiagram, med skillnaden att alla aktiviteter är klart länkade till objekt.</para>

<para
>Aktivitetsdiagram hör alltid ihop med en <emphasis
>klass</emphasis
>, en <emphasis
>operation</emphasis
> eller ett <emphasis
>användningsfall</emphasis
>.</para>

<para
>Aktivitetsdiagram stöder sekvens- samt parallella aktiviteter. Parallell körning representeras med ikonen Dela upp/samla ihop, och det är inte viktigt för aktiviteter som kör parallellt i vilken ordning de utförs (de kan köras samtidigt eller en i taget).</para>
<sect3 id="activity">
<title
>Aktivitet</title>
<para
>En aktivitet är ett enda steg i en process. En aktivitet är ett tillstånd i systemet med intern aktivitet och åtminstone en utgående övergång. Aktiviteter kan också ha mer än en utgående övergång, om de har olika villkor. </para
> 
<para
>Aktiviteter kan bygga upp hierarkier, vilket betyder att en aktivitet kan bestå av flera <quote
>detaljaktiviteter</quote
>, där inkommande och utgående övergångar måste passa ihop med de inkommande och utgående övergångarna i detaljdiagrammet. </para>

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

<sect2 id="helper-elements">
<title
>Hjälpelement</title>
<para
>Det finns några få element i &UML; som inte har något verkligt semantiskt värde för modellen, men som hjälper till att klargöra delar av diagrammen. Dessa element är </para>
<itemizedlist>
<listitem
><para
>Textrader</para
></listitem>
<listitem
><para
>Anteckningar och ankare</para
></listitem>
<listitem
><para
>Rutor</para
></listitem>
</itemizedlist
>   
<para
>Textrader är användbara för att lägga till kort textinformation i ett diagram. Det är fristående text, och har ingen betydelse i själva modellen. </para
>           

<para
>Anteckningar är användbara för att lägga till mer detaljerad information om ett objekt eller en särskild situation. De har den stora fördelen att anteckningar kan ankras vid &UML;-element för att visa att anteckningen <quote
>hör till</quote
> ett särskilt objekt eller situation. </para>

<para
>Rutor är fristående rektanglar som kan användas för att gruppera objekt tillsammans, för att göra diagram mer läsbara. De har ingen logisk mening i modellen.</para>

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

<sect2 id="component-diagram">
<title
>Komponentdiagram</title>
<para
>Komponentdiagram visar programkomponenter (antingen komponentteknologier som Kparts, CORBA-komponenter eller Java Beans eller bara delar av systemet som är klart urskiljbara) och artefakterna de består av, som källkodsfiler, programbibliotek eller relationsdatabastabeller.</para>

<para
>Komponenter kan ha gränssnitt (dvs. abstrakta klasser med operationer) som tillåter association mellan komponenter.</para>
</sect2>

<sect2 id="deployment-diagram">
<title
>Utplaceringsdiagram</title>

<para
>Utplaceringsdiagram visar komponentinstanserna vid körning och deras associationer. De omfattar noder, som är fysiska resurser, typiskt en enskild dator. De visar också gränssnitt och objekt (klassinstanser).</para>

</sect2>

</sect1
> 
</chapter>