UML-diagram

Indhold

 [skjul] 

• 1 Historie
• 1.1 Før UML 1.x
• 1.2 UML 1.x
• 1.3 UML 2.x
• 2 Design
• 2.1 Softwareudviklingsmetoder
• 2.2 Modellering
• 3 diagrammer
• 3.1 Strukturdiagrammer
• 3.2 Adfærdsdiagrammer
• 3.2.1 Interaktionsdiagrammer
• 4 Metamodellering
• 5 Vedtagelse
• 6 kritikpunkter
• 6.1 Kritik af UML 1.x

Historie[redigere kilde | redigere]

Historien om objektorienterede metoder og notation

UML har været under udvikling siden anden halvdel af 1990'erne og har sine rødder i de objektorienterede metoder, der blev udviklet i slutningen af 1980'erne og begyndelsen af 1990'erne. Tidslinjen (se billede) viser højdepunkterne i historien om objektorienterede modelleringsmetoder og notation.

Det er oprindeligt baseret på Booch-metodens notationer, objektmodelleringsteknikken (OMT) og objektorienteret softwareudvikling (OOSE), som er integreret i et enkelt sprog. ^[5]

Før UML 1.x[redigere kilde | redigere]

Rational Software Corporation ansatte James Rumbaugh fra General Electric i 1994, og derefter blev virksomheden kilden til to af de mest populære objektorienterede modelleringsmetoder i dag:^[6] Rumbaughs objektmodelleringsteknik (OMT) og Grady Boochs metode. De fik snart hjælp i deres bestræbelser af Ivar Jacobson, skaberen af den objektorienterede software engineering-metode (OOSE), som sluttede sig til dem hos Rational i 1995. ^[1]

Under teknisk ledelse af disse tre (Rumbaugh, Jacobson og Booch) blev der i 1996 dannet et konsortium kaldet UML Partners med det formål at færdiggøre specifikationen af Unified Modeling Language (UML) og foreslå den til standardisering i Object Management Group (OMG). Partnerskabet omfattede også andre interesserede parter (f.eks. HP, DEC, IBM og Microsoft). UML-partnernes UML 1.0-udkast blev foreslået OMG i januar 1997 af konsortiet. I samme måned dannede UML Partners en gruppe, der skulle definere den nøjagtige betydning af sprogkonstruktioner, og som havde Cris Kobryn som formand og Ed Eykholt som administrator, med henblik på at færdiggøre specifikationen og integrere den med andre standardiseringsbestræbelser. Resultatet af dette arbejde, UML 1.1, blev forelagt for OMG i august 1997 og vedtaget af OMG i november 1997. ^[1][7]

UML 1.x[redigere kilde | redigere]

Efter den første udgave blev der nedsat en arbejdsgruppe, der ^[1]skulle forbedre sproget, og som udgav flere mindre revisioner, 1.3, 1.4 og 1.5. ^[8]

De standarder, der blev udarbejdet (såvel som den oprindelige standard), er blevet bemærket som tvetydige og inkonsekvente. ^[9][10]

UML 2.x[redigere kilde | redigere]

Den store revision af UML 2.0 erstattede version 1.5 i 2005, som blev udviklet af et udvidet konsortium med henblik på at forbedre sproget yderligere for at afspejle nye erfaringer med brugen af dets funktioner. ^[11]

Selv om UML 2.1 aldrig blev frigivet som en formel specifikation, udkom versionerne 2.1.1.1 og 2.1.2 i 2007, efterfulgt af UML 2.2 i februar 2009. UML 2.3 blev formelt udgivet i maj 2010.^[12] UML 2.4.1 blev formelt udgivet i august 2011.^[12] UML 2.5 blev udgivet i oktober 2012 som en "In process"-version og blev officielt udgivet i juni 2015. ^[12]

UML 2.x-specifikationen består af fire dele:

1. Overbygningen, der definerer notation og semantik for diagrammer og deres modelelementer
2. Den infrastruktur, der definerer den centrale metamodel, som overbygningen er baseret på
3. Object Constraint Language (OCL) til at definere regler for modelelementer
4. UML Diagram Interchange, der definerer, hvordan UML 2-diagramlayouts udveksles

De nuværende versioner af disse standarder følger: UML Superstruktur version 2.4.1, UML Infrastruktur version 2.4.1, OCL version 2.3.1 og UML Diagram Interchange version 1.0.^[13] Det bliver fortsat opdateret og forbedret af revisionsarbejdsgruppen, som løser eventuelle problemer med sproget. ^[14]

Design[redigere kilde | redigere]

UML (Unified Modeling Language) er en måde at visualisere et systems arkitektoniske planer i et diagram (se billede), herunder elementer som f.eks: ^[5]

• Eventuelle aktiviteter (job)
• Systemets enkelte komponenter
• Og hvordan de kan interagere med andre softwarekomponenter.
• Hvordan systemet skal køre
• Hvordan enheder interagerer med andre (komponenter og grænseflader)
• Ekstern brugergrænseflade

Selv om det oprindeligt kun var beregnet til objektorienteret designdokumentation, er UML (Unified Modeling Language) blevet udvidet til at dække et større sæt af designdokumentation (som anført ovenfor) ^[15]og har vist sig nyttigt i mange sammenhænge. ^[16]

Softwareudviklingsmetoder[redigere kilde | redigere]

UML er ikke en udviklingsmetode i sig selv; den blev ^[17]imidlertid designet til at være kompatibel med de førende objektorienterede softwareudviklingsmetoder på daværende tidspunkt (f.eks.OMT, Booch-metoden, Objectory) og især med RUP, som det oprindeligt var meningen, at den skulle bruges, da arbejdet begyndte hos Rational Software Inc.

Modellering[redigere kilde | redigere]

Det er vigtigt at skelne mellem UML-modellen og et sæt af diagrammer for et system. Et diagram er en delvis grafisk repræsentation af et systems model. Sættet af diagrammer behøver ikke at dække modellen fuldstændigt, og det ændrer ikke modellen, hvis man sletter et diagram. Modellen kan også indeholde dokumentation, der styrer modelelementerne og diagrammerne (f.eks. skriftlige use cases).

UML-diagrammer repræsenterer to forskellige synspunkter af en systemmodel: ^[18]

• Statisk (eller strukturel) synsvinkel: lægger vægt på systemets statiske struktur ved hjælp af objekter, attributter, operationer og relationer. Den strukturelle synsvinkel omfatter klassediagrammer og sammensatte strukturdiagrammer.
• Dynamisk (eller adfærdsmæssig) visning: fremhæver systemets dynamiske adfærd ved at vise samarbejder mellem objekter og ændringer i objekters interne tilstande. Denne visning omfatter sekvensdiagrammer, aktivitetsdiagrammer og tilstandsmaskindiagrammer.

UML-modeller kan udveksles mellem UML-værktøjer ved hjælp af XML Metadata Interchange (XMI)-udvekslingsformatet (XML Metadata Interchange).

Diagrammer[redigere kilde | redigere]

UML 2 har mange typer af diagrammer, som er opdelt i to kategorier.^[5] Nogle typer repræsenterer strukturelle oplysninger, og resten repræsenterer generelle typer af adfærd, herunder nogle få, der repræsenterer forskellige aspekter af interaktioner. Disse diagrammer kan kategoriseres hierarkisk som vist i det følgende klassediagram: ^[5]

Disse diagrammer kan alle indeholde kommentarer eller noter, der forklarer brugen, begrænsningerne eller hensigten.

Strukturdiagrammer[redigere kilde | redigere]

Strukturdiagrammer fremhæver de ting, der skal være til stede i det system, der modelleres. Da strukturdiagrammer repræsenterer strukturen, anvendes de i vid udstrækning til at dokumentere softwaresystemers softwarearkitektur. For eksempel komponentdiagrammet, som beskriver, hvordan et softwaresystem er opdelt i komponenter, og viser afhængighederne mellem disse komponenter.

• Komponentdiagram
• Klassediagram

Adfærdsdiagrammer[redigere kilde | redigere]

Adfærdsdiagrammer understreger, hvad der skal ske i det system, der modelleres. Da adfærdsdiagrammer illustrerer et systems adfærd, anvendes de i vid udstrækning til at beskrive softwaresystemers funktionalitet. Aktivitetsdiagrammet beskriver f.eks. de forretningsmæssige og operationelle trinvise aktiviteter for komponenterne i et system.

• Aktivitetsdiagram
• Diagram over brugssager

Interaktionsdiagrammer[redigere kilde | redigere]

Interaktionsdiagrammer, som er en delmængde af adfærdsdiagrammer, fremhæver strømmen af kontrol og data mellem tingene i det system, der modelleres. For eksempel sekvensdiagrammet, som viser, hvordan objekter kommunikerer med hinanden i form af en sekvens af meddelelser.

• Sekvensdiagram
• Kommunikationsdiagram

Metamodellering[redigere kilde | redigere]

Hovedartikel: Meta-objekt-facilitet

Illustration af metaobjektfaciliteten

Object Management Group (OMG) har udviklet en metamodelleringsarkitektur til at definere Unified Modeling Language (UML), kaldet Meta-Object Facility (MOF).^[19] Meta-Object Facility er udformet som en arkitektur i fire lag, som vist på billedet til højre. Den indeholder en meta-meta-model i det øverste lag, kaldet M3-laget. Denne M3-model er det sprog, som Meta-Object Facility bruger til at opbygge metamodeller, kaldet M2-modeller.

Det mest fremtrædende eksempel på en lag 2 Meta-Object Facility-model er UML-metamodellen, som er den model, der beskriver selve UML. Disse M2-modeller beskriver elementer af M1-laget og dermed M1-modeller. Det vil f.eks. være modeller, der er skrevet i UML. Det sidste lag er M0-laget eller datalaget. Det bruges til at beskrive systemets runtime-instanser. ^[20]

Metamodellen kan udvides ved hjælp af en mekanisme, der kaldes stereotyping. Denne er blevet kritiseret for at være utilstrækkelig/uholdbar af Brian Henderson-Sellers og Cesar Gonzalez-Perez i "Uses and Abuses of the Stereotype Mechanism in UML 1.x and 2.0". ^[21]

Adoption[redigere kilde | redigere]

UML har vist sig at være nyttig i mange designkontekster, ^[16]så meget at den er blevet næsten allestedsnærværende inden for it-verdenen. ^[22]

Det er til tider blevet behandlet som en designmæssig mirakelkur, hvilket har ført til problemer i forbindelse med dets anvendelse. Misbrug af det omfatter overdreven brug af det (design hver eneste lille del af systemets kode med det, hvilket er unødvendigt) og antagelse af, at alle kan designe alt med det (selv dem, der ikke har programmeret). ^[23]

Det ses som et stort sprog med mange konstruktioner. Nogle (bl.a. Jacobson) mener, at der er for mange, og at dette hæmmer indlæringen (og dermed brugen) af det. ^[24]

Kritik[redigere kilde | redigere]

Almindelig kritik af UML fra industrien omfatter: ^[4]

• ikke er nyttige: "[giver] dem ikke fordele i forhold til deres nuværende, udviklede praksis og repræsentationer"
• for kompliceret, især i forbindelse med kommunikation med kunderne: "unødvendigt kompleks" og "Den bedste grund til ikke at bruge UML er, at den ikke er "læsbar" for alle interessenter. Hvor meget er UML værd, hvis en forretningsbruger (kunden) ikke kan forstå resultatet af din modelleringsindsats?"
• behov for at holde UML og kode i synkronisering, ligesom med dokumentation generelt

Kritik af UML 1.x[redigér kilde | redigér]

Kardinalitetsbetegnelse

Som i database Chen, Bachman og ISO ER-diagrammer er klassemodeller specificeret til at bruge "look-across"-kortinaliteter, selv om flere forfattere (bl.a^[27]. Merise, ^[25]Elmasri & Navathe^[26]) foretrækker same-side eller "look-here" for roller og både minimale og maksimale kortinaliteter. Nyere forskere (Feinerer, ^[28]Dullea m.fl.^[29]) har vist, at den "look-across"-teknik, der anvendes i UML- og ER-diagrammer, er mindre effektiv og mindre sammenhængende, når den anvendes på n-ary relationer af orden >2.

Feinerer siger: "Der opstår problemer, hvis vi opererer med den look-across-semantik, som anvendes til UML-associationer. Hartmann ^[30]undersøger denne situation og viser, hvordan og hvorfor forskellige transformationer mislykkes." (Selv om den nævnte "reduktion" er falsk, da de to diagrammer 3.4 og 3.5 faktisk er de samme) og også "Som vi vil se på de næste par sider, introducerer look-across-fortolkningen flere vanskeligheder, som forhindrer udvidelsen af simple mekanismer fra binære til n-ary associationer."