UML-diagram

Innehåll

 [dölja] 

• 1 Historia
• 1.1 Före UML 1.x
• 1.2 UML 1.x
• 1.3 UML 2.x
• 2 Design
• 2.1 Metoder för utveckling av programvara
• 2.2 Modellering
• 3 diagram
• 3.1 Strukturdiagram
• 3.2 Beteendediagram
• 3.2.1 Interaktionsdiagram
• 4 Metamodellering
• 5 Antagande
• 6 Kritiska synpunkter
• 6.1 Kritik av UML 1.x

Historia[redigera källa | redigera]

Historien om objektorienterade metoder och notation

UML har utvecklats sedan andra hälften av 1990-talet och har sina rötter i de objektorienterade metoder som utvecklades i slutet av 1980-talet och början av 1990-talet. Tidslinjen (se bild) visar höjdpunkterna i de objektorienterade modelleringsmetodernas och notationernas historia.

Det bygger ursprungligen på Booch-metoden, Object-modeling technique (OMT) och Object-oriented software engineering (OOSE), vilka har integrerats i ett enda språk. ^[5]

Före UML 1.x[redigera källa | redigera]

Rational Software Corporation anställde James Rumbaugh från General Electric 1994 och efter det blev företaget källan till två av de mest populära objektorienterade modelleringsmetoderna för dagen:^[6] Rumbaughs Object-modeling technique (OMT) och Grady Boochs metod. De fick snart hjälp i sina ansträngningar av Ivar Jacobson, skaparen av metoden för objektorienterad programvaruteknik (OOSE), som anslöt sig till dem på Rational 1995. ^[1]

Under dessa tre personers (Rumbaugh, Jacobson och Booch) tekniska ledning organiserades 1996 ett konsortium kallat UML Partners för att färdigställa specifikationen för Unified Modeling Language (UML) och föreslå den till Object Management Group (OMG) för standardisering. I partnerskapet ingick även andra intresserade parter (t.ex. HP, DEC, IBM och Microsoft). UML Partners UML 1.0-utkast föreslogs av konsortiet till OMG i januari 1997. Under samma månad bildade UML Partners en grupp som skulle definiera den exakta innebörden av språkkonstruktioner, med Cris Kobryn som ordförande och Ed Eykholt som administratör, för att färdigställa specifikationen och integrera den med andra standardiseringsinsatser. Resultatet av detta arbete, UML 1.1, lades fram för OMG i augusti 1997 och antogs av OMG i november 1997. ^[1][7]

UML 1.x[redigera källa | redigera]

Efter den första versionen bildades^[1] en arbetsgrupp för att förbättra språket, som gav ut flera mindre revideringar, 1.3, 1.4 och 1.5. ^[8]

De standarder som tagits fram (liksom den ursprungliga standarden) har konstaterats vara tvetydiga och inkonsekventa. ^[9][10]

UML 2.x[redigera källa | redigera]

UML 2.0 ersatte version 1.5 2005, som utvecklades av ett utökat konsortium för att förbättra språket ytterligare och återspegla nya erfarenheter av användningen av dess funktioner. ^[11]

UML 2.1 släpptes aldrig som en formell specifikation, men versionerna 2.1.1 och 2.1.2 publicerades 2007, följt av UML 2.2 i februari 2009. UML 2.3 släpptes formellt i maj 2010.^[12] UML 2.4.1 släpptes formellt i augusti 2011.^[12] UML 2.5 släpptes i oktober 2012 som en "In process"-version och släpptes officiellt i juni 2015. ^[12]

UML 2.x-specifikationen består av fyra delar:

1. Överstrukturen som definierar notation och semantik för diagram och deras modellelement.
2. Infrastruktur som definierar den centrala metamodell som överbyggnaden bygger på.
3. Object Constraint Language (OCL) för att definiera regler för modellelement.
4. UML Diagram Interchange som definierar hur UML 2-diagramlayouter utbyts.

De aktuella versionerna av dessa standarder följer nedan: UML Superstructure version 2.4.1, UML Infrastructure version 2.4.1, OCL version 2.3.1 och UML Diagram Interchange version 1.0.^[13] Språket fortsätter att uppdateras och förbättras av arbetsgruppen för revidering, som löser eventuella problem med språket. ^[14]

Design[redigera källa | redigera]

UML (Unified Modeling Language) erbjuder ett sätt att visualisera ett systems arkitektoniska ritningar i ett diagram (se bild), inklusive element som: ^[5]

• All verksamhet (arbetstillfällen)
• Systemets enskilda komponenter
• Och hur de kan interagera med andra programvarukomponenter.
• Hur systemet kommer att fungera
• Hur enheter interagerar med andra (komponenter och gränssnitt).
• Externt användargränssnitt

Även om UML (Unified Modeling Language) ursprungligen endast var avsett för objektorienterad konstruktionsdokumentation, har det utvidgats till att omfatta en större uppsättning konstruktionsdokumentation (enligt listan ovan) ^[15]och har visat sig vara användbart i många sammanhang. ^[16]

Metoder för mjukvaruutveckling[redigera källa | redigera]

UML är inte en utvecklingsmetod i sig själv, ^[17]men den utformades för att vara kompatibel med de ledande objektorienterade metoderna för programvaruutveckling som fanns på sin tid (t.ex.OMT, Booch-metoden, Objectory) och särskilt med RUP, som det ursprungligen var tänkt att den skulle användas när arbetet inleddes på Rational Software Inc.

Modellering[redigera källa | redigera]

Det är viktigt att skilja mellan UML-modellen och en uppsättning diagram för ett system. Ett diagram är en partiell grafisk representation av en systemmodell. Mängden diagram behöver inte helt täcka modellen och om ett diagram tas bort ändras inte modellen. Modellen kan också innehålla dokumentation som styr modellelementen och diagrammen (t.ex. skriftliga användningsfall).

UML-diagram representerar två olika vyer av en systemmodell: ^[18]

• Statisk (eller strukturell) syn: betonar systemets statiska struktur med hjälp av objekt, attribut, operationer och relationer. Den strukturella vyn omfattar klassdiagram och sammansatta strukturdiagram.
• Dynamisk vy (eller beteendevy): betonar systemets dynamiska beteende genom att visa samarbeten mellan objekt och förändringar i objektens interna tillstånd. Denna vy omfattar sekvensdiagram, aktivitetsdiagram och tillståndsdiagram.

UML-modeller kan utbytas mellan UML-verktyg med hjälp av utbytesformatet XML Metadata Interchange (XMI).

Diagram[redigera källa | redigera]

UML 2 har många typer av diagram som delas in i två kategorier.^[5] Vissa typer representerar strukturell information och resten representerar allmänna typer av beteende, inklusive några som representerar olika aspekter av interaktioner. Dessa diagram kan kategoriseras hierarkiskt enligt följande klassdiagram: ^[5]

Alla dessa diagram kan innehålla kommentarer eller anteckningar som förklarar användning, begränsning eller avsikt.

Strukturdiagram[redigera källa | redigera]

Strukturdiagrammen betonar de saker som måste finnas i det system som modelleras. Eftersom strukturdiagrammen representerar strukturen används de i stor utsträckning för att dokumentera programvarusystemens mjukvaruarkitektur. Exempelvis komponentdiagrammet som beskriver hur ett mjukvarusystem delas upp i komponenter och visar beroendena mellan dessa komponenter.

• Komponentdiagram
• Klassdiagram

Beteendediagram[redigera källa | redigera]

Beteendediagram betonar vad som måste hända i det system som modelleras. Eftersom beteendediagram illustrerar ett systems beteende används de ofta för att beskriva funktionaliteten hos programvarusystem. Aktivitetsdiagrammet beskriver till exempel de stegvisa affärs- och driftsaktiviteterna för komponenterna i ett system.

• Aktivitetsdiagram
• Diagram över användningsfall

Interaktionsdiagram[redigera källa | redigera]

Interaktionsdiagram, som är en delmängd av beteendediagram, betonar flödet av kontroll och data mellan sakerna i det system som modelleras. Till exempel sekvensdiagrammet som visar hur objekt kommunicerar med varandra i form av en sekvens av meddelanden.

• Sekvensdiagram
• Kommunikationsdiagram

Metamodellering[redigera källa | redigera]

Huvudartikel: Metaobjektfacilitet

Illustration av metaobjektet

Object Management Group (OMG) har utvecklat en arkitektur för metamodellering för att definiera Unified Modeling Language (UML), kallad Meta-Object Facility (MOF).^[19] Meta-Object Facility är utformad som en arkitektur i fyra lager, enligt bilden till höger. Den tillhandahåller en meta-metamodell i det översta lagret, som kallas M3-lagret. Denna M3-modell är det språk som används av Meta-Object Facility för att bygga metamodeller, så kallade M2-modeller.

Det mest framträdande exemplet på en Meta-Object Facility-modell i nivå 2 är UML-metamodellen, den modell som beskriver själva UML. Dessa M2-modeller beskriver delar av M1-lagret och därmed M1-modeller. Dessa skulle till exempel vara modeller som är skrivna i UML. Det sista lagret är M0-lagret eller datalaget. Det används för att beskriva systemets instanser vid körning. ^[20]

Metamodellen kan utökas med hjälp av en mekanism som kallas stereotypning. Detta har kritiserats för att vara otillräckligt/ ohållbart av Brian Henderson-Sellers och Cesar Gonzalez-Perez i "Uses and Abuses of the Stereotype Mechanism in UML 1.x and 2.0". ^[21]

Adoption[redigera källa | redigera]

UML har visat sig vara användbart i många designsammanhang, ^[16]så till den grad att det har blivit nästan allestädes närvarande inom IT-samhället. ^[22]

Den har ibland behandlats som en designmässig silverkula, vilket har lett till problem i användningen. Missbruk av den omfattar överdriven användning av den (utformning av varje liten del av systemets kod med den, vilket är onödigt) och antagandet att vem som helst kan utforma vad som helst med den (även de som inte har programmerat). ^[23]

Det anses vara ett stort språk med många konstruktioner. Vissa (däribland Jacobson) anser att det finns för många och att detta hindrar inlärningen (och därmed användningen) av det. ^[24]

Kritik[redigera källa | redigera]

Vanlig kritik av UML från industrin är bland annat: ^[4]

• inte användbar: "[ger] dem inga fördelar jämfört med deras nuvarande, utvecklade metoder och representationer".
• för komplicerat, särskilt när det gäller kommunikation med kunder: "onödigt komplicerat" och "Det bästa skälet till att inte använda UML är att det inte är "läsbart" för alla intressenter. Hur mycket är UML värt om en affärsanvändare (kunden) inte kan förstå resultatet av din modellering?".
• Behovet av att hålla UML och koden i synk, precis som med dokumentation i allmänhet.

Kritik av UML 1.x[redigera källa | redigera]

Notering av kardinalitet

Precis som i databaserna Chen, Bachman och ISO ER-diagrammen anges att klassmodeller ska använda "look-across"-kardinalenheter, även om flera författare (bl.a^[27]. Merise, ^[25]Elmasri och Navathe^[26]) föredrar samma sida eller "look-here" för roller och både minimi- och maximikardinalenheter. Nya forskare (Feinerer, ^[28]Dullea m.fl.^[29]) har visat att den "look-across"-teknik som används i UML- och ER-diagram är mindre effektiv och mindre sammanhängande när den tillämpas på n-ary-relationer av ordning >2.

Feinerer säger: "Problem uppstår om vi använder oss av den semantik som används för UML-associationer. Hartmann ^[30]undersöker denna situation och visar hur och varför olika omvandlingar misslyckas." (Även om den "reduktion" som nämns är falsk eftersom de två diagrammen 3.4 och 3.5 i själva verket är desamma) och även "Som vi kommer att se på de kommande sidorna introducerar look-across-tolkningen flera svårigheter som förhindrar en utvidgning av enkla mekanismer från binära till n-ary associationer".