<para>Dette kapitel giver en hurtig oversigt over det basale i &UML;. Husk at dette ikke er en fuldstændig &UML;-vejledning. Hvis du vil lære dig mere om Unified Modelling Language, eller om almen analyse og konstruktion af programmel, henvises du til en af de mange bøger som er tilgængelige om emnet. Der er også mange vejledninger på internettet, som du kan bruge som et startpunkt. </para>
<para>Unified Modelling Language (&UML;) er et diagrambaseret sprog eller notation til at specificere, visualisere og dokumentere modeller af objektorienteret programmel. &UML; er ikke en udviklingsmetode, hvilket betyder at den ikke fortæller for dig hvad du skal gøre først og hvad du skal gøre derefter, eller hvordan du skal konstruere dit system, men den hjælper til at visualisere konstruktionen og kommunikere med andre. &UML; styres af Object Management Group (<acronym>OMG</acronym>), og er en industristandard for at beskrive modeller af programmel. </para>
<para>&UML; er konstrueret for design af objektorienteret programmel, og har begrænset brug for andre programmeringsparadigmer. </para>
<para>&UML; er opbygget af mange modelleringselementer som repræsenterer forskellige dele af programmelsystemet. UML-elementerne bruges til at oprette diagrammer, som repræsenterer en vis del, eller en synspunkt for systemet. Følgende slags diagrammer understøttes af &umbrello;: </para>
<listitem><para><emphasis><link linkend="use-case-diagram">Brugstilfælde-diagrammer</link></emphasis> viser aktører (mennesker eller andre brugere af systemet), brugstilfælde (scenarier når de bruger systemet), og deres forhold</para> </listitem>
<listitem><para><emphasis><link linkend="class-diagram">Klassediagrammer</link></emphasis> viser klasser, og forholdene mellem dem</para> </listitem>
<listitem><para><emphasis><link linkend="sequence-diagram">Sekvensdiagrammer</link></emphasis> viser objekter og deres og en sekvens af metodekald de laver til andre objekter.</para> </listitem>
<listitem><para><emphasis><link linkend="collaboration-diagram">Samarbejdsdiagrammer</link></emphasis> viser objekter og deres forhold, med betoning på objekter som deltager i udveksling af meddelelser</para>
<listitem><para><emphasis><link linkend="state-diagram">Tilstandsdiagrammer</link></emphasis> viser tilstande, tilstandsændringer og begivenheder for et objekt eller en del af systemet</para> </listitem>
<listitem><para><emphasis><link linkend="activity-diagram">Aktivitetsdiagrammer</link></emphasis> viser aktiviteter, tilstander og tilstandsændringer for objekter og begivenheder som sker i en del af systemet</para></listitem>
<listitem><para><emphasis><link linkend="component-diagram">Komponentdiagrammer</link></emphasis> viser programmeringskomponenter på højt niveau (såsom Kparts eller Java Beans).</para></listitem>
<listitem><para><emphasis><link linkend="deployment-diagram">Udplaceringsdiagrammer</link></emphasis> viser komponenternes instanser og deres indbyrdes forhold.</para></listitem>
<para>Brugstilfældediagrammer beskriver forhold og afhængighed mellem en gruppe <emphasis>brugstilfælde</emphasis> og aktører som deltager i processen.</para>
<para>Det er vigtigt at observere at brugstilfældesdiagrammer ikke er passende til at repræsentere konstruktioner, og ikke kan beskrive systemets indre dele. Brugstilfældediagrammer er beregnede til at muliggøre kommunikation med fremtidige brugere af systemet, og med kunden. De er til særlig hjælp for at afgøre hvilke funktioner som det kræves at systemet skal have. Med andre ord fortæller brugstilfældediagrammer om <emphasis>hvad</emphasis> systemet skal gøre, men de angiver ikke — og kan ikke angive — <emphasis>hvordan</emphasis> dette skal opnås.</para>
<para>Et <emphasis>brugstilfælde</emphasis> beskriver — fra aktørernes synvinkel — en samling aktiviteter i et system, som giver anledning til et konkret, væsentligt resultat.</para>
<para>Brugstilfælde er beskrivelser af typisk vekselvirken mellem brugerne af et system og systemet selv. De repræsenterer systemets ydre grænseflade, og angiver en slags krav på hvad systemet skal gøre (husk, kun hvad, ikke hvordan). </para>
<para>Ved arbejde med brugstilfælde, er det vigtigt at huske nogle enkle regler: <itemizedlist>
<listitem><para>Hvert brugstilfælde hører sammen med mindst en aktør</para></listitem>
<listitem><para>Hvert brugstilfælde har et ophav (dvs. en aktør)</para></listitem>
<listitem><para>Hvert brugstilfælde leder til et relevant resultat (et resultat med <quote>forretningsværdi</quote>).</para>
<listitem><para><emphasis><<include>></emphasis> (indeholder), hvilket angiver at brugstilfældet finder sted <emphasis>inde i</emphasis> et andet brugstilfælde</para></listitem>
<listitem><para><emphasis><<extends>></emphasis> (udvider), hvilket angiver at i visse tilfælde, eller i et tilfælde (som kaldes et udvidelsespunkt), bliver et brugstilfælde udvidet af et andet.</para></listitem>
<listitem><para><emphasis>Generalisering</emphasis> angiver at et brugstilfælde arver egenskaberne for <quote>super</quote>-brugstilfældet, og kan sætte nogen af dem ud af kraft, eller tilføje nye på samme måde som arv mellem klasser. </para>
<para>En aktør er en ekstern enhed (udenfor systemet) som vekselvirker med systemet ved at deltage i (og ofte indlede) et brugstilfælde. Aktører kan i virkeligheden være mennesker (for eksempel brugere af systemet), andre maskinesystemer eller ydre begivenheder. </para>
<para>Aktører repræsenterer ikke <emphasis>fysiske</emphasis> mennesker eller systemer, men deres <emphasis>rolle</emphasis>. Det betyder at når en person vekselvirker med systemet på forskellige måder (antager forskellige roller) repræsenteres han ved flere aktører. En person som for eksempel giver kundeunderstøttelse via telefon og tager imod bestillinger fra kunden til systemet, vil blive repræsenteret af en aktør <quote>Kundeunderstøttelsespersonale</quote> og af en aktør <quote>Salgsrepræsentant</quote>. </para>
<para>En beskrivelse af et brugstilfælde er en tekstbaseret beretning om brugstilfældet. Det er ofte i form af en note eller et dokument som på en eller anden måde er linket til brugstilfældet, og forklarer processerne eller aktiviteterne som finder sted i brugstilfældet. </para>
<para>Klassediagrammer viser de forskellige klasser som opbygger et system og hvordan de relateres til hinanden. Klassediagrammer siges at være <quote>statiske</quote> diagrammer, fordi de viser klasserne, sammen med deres metoder og attributter, samt det statiske forhold mellem dem: hvilke klasser der <quote>kender til</quote> andre klasser, eller hvilke klasser der <quote>er en del</quote> af andre klasser, men viser ikke metodekald mellem dem. </para>
<para>En klasse definerer attributterne og metoderne for en mængde af objekter. Alle objekter af klassen (instanser af klassen) deler samme opførsel, og har samme mængde af attributter (hvert objekt har sin egen mængde). Udtrykket <quote>type</quote> bruges ind imellem i stedet for klasse, men det er vigtigt at nævne at de to ikke er det samme, og at type er et mere generelt udtryk. </para>
<para>Klasser i &UML; repræsenteres af rektangler, med klassens navn, og kan også vise klassens attribut og operationer i to <quote>afdelinger</quote> inde i rektanglet. </para>
<para>Attributter i UML vises i det mindste med deres navne, og kan også vises med type, oprindelig værdi og andre egenskaber. Attribut kan også vises med synlighed: </para>
<para>Operationer (metoder) vises også i det mindste med deres navne, og kan også vises med parametre og returtyper. Operationer, præcis som attributter, kan vises med deres synlighed: <itemizedlist>
<listitem><para><literal>+</literal> Står for <emphasis>åbne</emphasis> (public) operationer</para></listitem>
<listitem><para><literal>#</literal> Står for <emphasis>beskyttede</emphasis> (protected) operationer</para></listitem>
<listitem><para><literal>-</literal> Står for <emphasis>private</emphasis> (private) operationer</para></listitem>
<para>Klasser kan have skabeloner, en værdi som bruges for en uspecificeret klasse eller type. Skabelontypen angives når klassen initieres (dvs. et objekt laves). Skabeloner findes i moderne C++ og vil blive introduceret i Java 1.5, hvor de kaldes Generics. </para>
<para>Arv er et af de grundlæggende begreber i objektorienteret programmering, hvor en klasse <quote>opnår</quote> alle attributter og operationer fra klassen den arver fra, og kan overskride/ændre nogen af dem, samt tilføje flere egne attributter og operationer.</para>
<para>En <emphasis>generalisering</emphasis> mellem to klasser i &UML;, placerer dem i et hierarki som repræsenterer arvebegrebet for en afledt klasse fra en basisklasse. Generaliseringer i &UML; repræsenteres med en linje som binder de to klasser sammen, med en pil på basisklassens side. <screenshot>
<para>En association repræsenterer et forhold mellem klasser, og giver den fælles semantik og struktur for mange typer af <quote>forbindelser</quote> mellem objekter.</para>
<para>Associationer er mekanismen som tillader at objekter kommunikerer med hinanden. De beskriver forbindelsen mellem forskellige klasser (forbindelsen mellem de virkelige objekter kaldes objektforbindelser, eller <emphasis>link</emphasis>). </para>
<para>Associationer kan have en rolle, som angiver associationens formål, og kan være ensrettede eller gensidige (indikerer om de to objekter som deltager i forholdet kan sende meddelelser til hinanden, eller om kun et af dem kender til det andet). Hver eneste af associationerne har også en multiplicitet, som bestemmer hvor mange objekter på denne side af associationen kan relateres til et objekt på den anden side. </para>
<para>Associationer i &UML; repræsenteres som linjer som binder de klasser sammen som deltager i forholdet, og kan også vise rollen og multipliciteten for hver af deltagerne. Multiplicitet vises som et interval [minimum..maksimum] med ikke-negative værdier, med en stjerne (*) på maksimumsiden som repræsenterer uendeligt. <screenshot>
<para>Aggregeringer er en særlig slags association, hvor de to deltagende klasser ikke har en ligeværdig status, men udgør et <quote>helhed-del</quote> forhold. En aggregering beskriver hvordan klassen som intager rollen som helhed, er sammensat af (har) andre klasser, som intager rollerne som dele. Klassen der virker som helhed har altid multiplicitet en, for aggregeringer. </para>
<para>Aggregeringer i &UML; repræsenteres ved en association som viser en rombe på den side som hører til helheden. <screenshot>
<para>Sammensætninger er associationer som repræsenterer <emphasis>meget stærke</emphasis> aggregeringer. Det betyder at sammensætninger også former helhed-del forhold, men at forholdet er så stærkt at delene ikke kan eksistere for sig selv. De findes kun inde i helheden, og hvis helheden forstyrres, forsvinder delene også.</para>
<para>Sammensætninger i &UML; repræsenteres af en udfyldt rombe på siden af helheden. </para>
<para>Grænseflade er abstrakte klasser hvilket betyder at instanser ikke direkte kan skabes fra dem. De kan indehold operationer men ingen attributter. Klasser kan arve fra grænseflader (via en realisationsassociation) og instanser kan derefter laves af disse diagrammer.</para>
<para>Datatyper er primitiver som typisk er indbyggede i et programsprog. Almindelige eksempler omfatter heltal og en boolesk type. De kan ikke have forhold til klasser, men klasser kan have forhold til dem.</para>
<para>Gentagelsestyper er enkle lister med værdier. Et typisk eksempel er en nummereringstype af ugedage. Tilvalgene for en gentagelsestype kaldes Enum Literals. Som datatyper kan de ikke have forhold til klasser, men klasser kan have forhold til dem.</para>
<para>Pakker repræsenterer navnerum i et programsprog. I et diagram bruges de til at repræsentere dele af et system som indeholder mere end en klasse, måske hundredvis af klasser.</para>
<para>Sekvensdiagrammer viser udveksling af meddelelser (dvs. metodekald) mellem flere objekter, i en specifik, tidsbegrænset situation. Sekvensdiagrammer lægger særlig vægt på rækkefølgen og tiden når meddelelserne til objekter sendes.</para>
<para>Objekter repræsenteres af lodrette stregede linjer i sekvensdiagrammer, med objektets navn øverst. Tidsakslen er også lodret, og vokser nedad, så meddelelser sendes fra et objekt til et andet i form af pile med operationer og parameternavn. </para>
<para>Meddelelser kan enten være synkrone, den normale type for meddelelseskald hvor kontrollen overgår til det kaldte objekt til metoden er kørt færdigt, eller asynkrone hvor kontrollen går direkte tilbage til det kaldende objekt. Synkrone meddelelser har et lodret felt ved siden af det kaldte objektet, for at vise programkontrollen.</para>
<para>Samarbejdsdiagrammer viser vekselvirkningen mellem objekter som deltager i en speciel situation. Dette er mere eller mindre samme information som vises i sekvensdiagrammer, men hvor vægten lægges på hvordan vekselvirkningen sker i tiden, mens samarbejdsdiagrammer lægger vægten på forholdet mellem objekterne og deres topologi.</para>
<para>I samarbejdsdiagrammer repræsenteres meddelelser fra et objekt til et andet med pile, som viser meddelelsens navn, parametre og meddelelsesekvensen. Samarbejdsdiagrammer er særligt passende til at vise en særlig programflydning eller situation, og er blandt de bedste diagramtyper til hurtigt at demonstrere eller forklare en process i programmets logik. </para>
<para>Tilstandsdiagrammer viser de forskellige tilstande et objekt har i sin livstid, og de stimuli som forårsager at objektet ændrer sin tilstand. </para>
<para>Tilstandsdiagrammer ser objekter som <emphasis>tilstandsmaskiner</emphasis> eller finite automates, som kan være i en af en mængde begrænsede tilstande og som kan ændre tilstand via et af et begrænset antal stimuli. Et objekt af typen <emphasis>Netserver</emphasis>, kan for eksempel være i en af følgende tilstande i sin livstid: </para>
<para>Tilstand er byggeblokken i tilstandsdiagrammer. En tilstand hører til nøjagtig en klasse, og repræsenterer en sammenfatning af de værdier klassens attributter kan intage. En &UML;-tilstand beskriver den interne tilstand for et objekt af en vis klasse. </para>
<para>Bemærk at ikke hver ændring af en af et objekts attributter skal repræsenteres som en tilstand, men kun de ændringer som væsentligt kan påvirke objektets arbejde.</para>
<para>Der er to specielle typer tilstand: start og slut. De er specielle på den måde at der ikke er nogen begivenhed som kan gøre at et objekt går tilbage til sin starttilstand, og på samme måde er der ingen begivenhed som gør det muligt for et objekt at forlade sin sluttilstand når den først er nået. </para>
<para>Aktivitetsdiagrammer beskriver en følge af begivenheder i et system, ved hjælp af aktiviteter. Aktivitetsdiagrammer er en speciel form af tilstandsdiagrammer, som kun (eller hovedsagelig) indeholder aktiviteter. </para>
<para>Aktivitetsdiagrammer ligner procedurelle flydediagrammer, med forskellen at alle aktiviteter er klart linkede til objekter.</para>
<para>Aktivitetsdiagrammer hører altid sammen med en <emphasis>klasse</emphasis>, en <emphasis>operation</emphasis> eller et <emphasis>brugstilfælde</emphasis>.</para>
<para>Aktivitetsdiagrammer understøtter sekventielle- og parallelle aktiviteter. Parallel kørsel repræsenteres med ikonen Del op/Vent, og det er ikke vigtigt for aktiviteter som kører parallelt i hvilken rækkefølge de udføres (de kan køres samtidigt eller en af gangen).</para>
<para>En aktivitet er et enkelt skridt i en process. En aktivitet er en tilstand i systemet med intern aktivitet og i det mindste en udgående overgang. Aktiviteter kan også have mere end en udgående overgang, hvis de har forskellige betingelser. </para>
<para>Aktiviteter kan opbygge hierarkier, hvilket betyder at en aktivitet kan bestå af flere <quote>detaljeaktiviteter</quote>, hvor indkommende og udgående overgange skal passe sammen med de indkommende og udgående overgange i detaljediagrammet. </para>
<para>Der er nogle få elementer i &UML; som ikke har noget virkelig semantisk værdi for modellen, men som hjælper til at klargøre dele af diagrammerne. Disse elementer er </para>
<para>Tekstlinjer er nyttige til at tilføje kort tekstinformation i et diagram. Det er fritstående tekst, og har ingen betydning i selve modellen. </para>
<para>Noter er nyttige til at tilføje mere detaljeret information om et objekt eller en særlig situation. De har den store fordel at noter kan ankres ved &UML;-elementer for at vise at noten <quote>hører til</quote> et særligt objekt eller en særlig situation. </para>
<para>Bokse er fritstående rektangler som kan bruges til at gruppere objekter sammen, for at gøre diagrammer mere læsbare. De har ingen logisk mening i modellen.</para>
<para>Komponentdiagrammer viser programkomponenter (enten komponentteknologier såsom Kparts, CORBA-komponenter eller Java Beans eller kun dele af systemet som er klart udskillelige) og artefakterne de består af, såsom kildekodefiler, programbiblioteker eller relationsdatabasetabeller.</para>
<para>Udplaceringsdiagrammer viser komponentinstanserne ved kørsel og deres associationer. De omfatter knuder, som er fysiske ressourcer, typisk en enkelt maskine. De viser også grænseflader og objekter (klasseinstanser).</para>
