UML ( Engelska Unified Modeling Language - ett unified modeling language) är ett grafiskt beskrivningsspråk för objektmodellering inom området mjukvaruutveckling , för modellering av affärsprocesser , systemdesign och visning av organisationsstrukturer .
UML är ett allmänt språk, det är en öppen standard som använder grafisk notation för att skapa en abstrakt modell av ett system som kallas en UML-modell . UML skapades för att definiera, visualisera, designa och dokumentera, i princip, mjukvarusystem . UML är inte ett programmeringsspråk , men kodgenerering är möjlig baserat på UML-modeller .
UML tillåter också mjukvaruutvecklare att komma överens om grafisk notation för att representera vanliga begrepp (som klass , komponent , generalisering , aggregering och beteende ) och att fokusera mer på design och arkitektur .
Förutsättningarna för framväxten av UML- modelleringsspråket identifierades i samband med den snabba utvecklingen under andra hälften av 1900-talet av objektorienterade programmeringsspråk ( Simula 67 , Smalltalk , Objective C , C ++ , etc.) . På grund av den pågående komplikationen av de skapade mjukvaruprodukterna finns det ett behov av att ta hänsyn till fler och fler nya funktioner i språk och utvecklingsverktyg i analysen, formuleringen av krav och i processen att designa mjukvaruapplikationer. Till exempel, under en kort tidsperiod från 1989 till 1994 växte antalet objektorienterade verktyg från ett dussin till mer än femtio. Många utvecklare tyckte dock att det var svårt att välja ett modellspråk som fullt ut skulle möta alla deras behov. Som ett resultat har en ny generation utvecklingsmetoder uppstått, bland vilka Booch-metoden , skapad av Jacobson Object-Oriented Software Engineering ( OOSE ) och utvecklad av Rambaud Object Modeling Technique ( OMT ), har vunnit särskild popularitet. Utöver dem fanns det andra färdiga teknologier, såsom Fusion , Shlaer-Mellor och Coad-Yourdon , men alla hade inte bara fördelar utan också betydande nackdelar [1] .
1994 gick Grady Booch och James Rumbaugh , som arbetade för Rational Software , samman för att skapa ett nytt objektorienterat modelleringsspråk. De tog modelleringsmetoderna Objektmodelleringsteknik och Booch som grund för språket . OMT var fokuserat på analys, medan Booch var fokuserat på att designa mjukvarusystem. I oktober 1995 släpptes en preliminär version 0.8 av Unified Method . Hösten 1995 började Ivar Jakobson , författaren till Object-Oriented Software Engineering - OOSE, till Rational . OOSE tillhandahöll utmärkta möjligheter för att specificera affärsprocesser och analysera krav genom användningsfall . OOSE har också integrerats i den enhetliga metoden.
I detta skede övergick huvudrollen i att organisera UML-utvecklingsprocessen till OMG- konsortiet (Object Management Group) . Designteamet på OMG, som även inkluderade Butch, Rambeau och Jacobson ("de tre amigos"), släppte UML version 0.9 och 0.91 specifikationer i juni och oktober 1996 .
| Version | Acceptansdatum |
|---|---|
| 1.1 | november 1997 [2] |
| 1.3 | Mars 2000 [3] |
| 1.4 | september 2001 [4] |
| 1.4.2 | Juli 2004 [3] |
| 1.5 | Mars 2003 [5] |
| 2.0 | juli 2005 [6] |
| 2.1 | formellt inte accepterat [3] |
| 2.1.1 | augusti 2007 [7] |
| 2.1.2 | november 2007 [8] |
| 2.2 | februari 2009 [9] |
| 2.3 | maj 2010 [10] |
| 2.4 beta 2 | Mars 2011 [11] |
| 2.5 | juni 2015 [12] |
| 2.5.1 | December 2017 [13] |
I spåren av det växande intresset för UML har företag som Digital Equipment Corporation , Hewlett-Packard , i-Logix, IntelliCorp, IBM , ICON Computing, MCI Systemhouse, Microsoft , Oracle Corporation , Rational Software anslutit sig till utvecklingen av nya versioner av språk inom UML Partners- konsortiet , Texas Instruments och Unisys . Samarbetet resulterade i UML 1.0-specifikationen, som släpptes i januari 1997 . Den följdes i november samma år av version 1.1, som innehöll notationsförbättringar samt några semantiska tillägg.
Efterföljande utgåvor av UML har inkluderat versionerna 1.3, 1.4 och 1.5, publicerade i juni 1999 , september 2001 respektive mars 2003 .
UML 1.4.2 har antagits som den internationella standarden ISO / IEC 19501:2005 [12] .
Den formella specifikationen för UML 2.0 publicerades i augusti 2005. Språkets semantik har förfinats och utökats avsevärt för att stödja modelldriven utveckling - MDD-metoden . Den senaste versionen av UML 2.5 publicerades i juni 2015.
UML 2.4.1 har antagits som den internationella standarden ISO / IEC 19505-1, 19505-2 [12] .
Följande typer av diagram används i UML (för att eliminera tvetydighet ges även notationen på engelska):
|
Strukturdiagram:
Beteendediagram:
|
Strukturdiagram:
Beteendediagram:
|
Strukturen för UML 2.3-diagram kan representeras i ett UML-klassdiagram:
Klassdiagram (Klassdiagram) - ett statiskt strukturdiagram som beskriver systemets struktur, som visar systemets klasser, deras attribut, metoder och beroenden mellan klasser.
Det finns olika synpunkter på konstruktionen av klassdiagram, beroende på syftet med deras tillämpning:
Komponentdiagram (Component diagram ) - ett statiskt strukturdiagram, visar uppdelningen av ett mjukvarusystem i strukturella komponenter och relationer (beroenden) mellan komponenter. Fysiska komponenter kan vara filer, bibliotek, moduler, körbara filer, paket etc.
Sammansatt strukturdiagram ( Composite structure diagram) - ett statiskt strukturdiagram som visar klassernas interna struktur och, om möjligt, interaktionen mellan element (delar) av klassens interna struktur.
En underart av sammansatta strukturdiagram är samarbetsdiagram (Collaboration diagram, introducerat i UML 2.0), som visar klassernas roller och interaktioner inom ett samarbete. Samarbeten är praktiskt när man modellerar designmönster .
Sammansatta strukturdiagram kan användas tillsammans med klassdiagram.
Distributionsdiagram ( deployment diagram) - används för att modellera arbetsnoder (hårdvara, engelsk nod ) och artefakter som distribueras på dem. UML 2 distribuerade artefakter på noder , medan UML 1 distribuerade komponenter på noder. Ett manifestationsberoende etableras mellan en artefakt och det logiska elementet (komponenten) som den implementerar.
Objektdiagram - visar en hel eller partiell ögonblicksbild av det simulerade systemet vid en given tidpunkt. Objektdiagrammet visar klassinstanser (objekt) av systemet med de aktuella värdena för deras attribut och länkar mellan objekt.
Paketdiagram (paketdiagram) - ett strukturdiagram, vars huvudinnehåll är paket och relationerna mellan dem. Det finns ingen strikt åtskillnad mellan olika strukturdiagram, så detta namn erbjuds endast för bekvämlighet och har ingen semantisk betydelse (paket och paketdiagram kan förekomma på andra strukturdiagram). Paketdiagram tjänar först och främst till att organisera element i grupper enligt något attribut för att förenkla strukturen och organisationen av arbetet med systemmodellen.
Aktivitetsdiagram - ett diagram som visar nedbrytningen av en viss aktivitet i dess beståndsdelar. En aktivitet är en specifikation av exekverbart beteende i form av en koordinerad sekventiell och parallell exekvering av underordnade element — kapslade aktiviteter och separata åtgärder ( engelska action ), sammankopplade av flöden som går från utgångarna från en nod till ingångarna från en annan.
Aktivitetsdiagram används vid modellering av affärsprocesser, tekniska processer, seriell och parallell beräkning.
En analog av aktivitetsdiagram är algoritmscheman enligt GOST 19.701-90 och drakescheman .
Automatdiagram (State machine diagram, finite state machine diagram , state diagram ) - ett diagram som visar en finita tillståndsmaskin med enkla tillstånd , övergångar och sammansatta tillstånd.
En tillståndsmaskin är en specifikation av sekvensen av tillstånd genom vilka ett objekt eller interaktion passerar som svar på händelserna i dess liv, såväl som objektets svar på dessa händelser. En tillståndsmaskin är kopplad till ett källelement ( klass , samarbete eller metod) och tjänar till att definiera beteendet hos dess instanser.
En analog till automatdiagram (tillståndsdiagram) är drakdiagram .
Ett use case-diagram eller ett use case-diagram (Use case diagram) är ett diagram som visar de relationer som finns mellan aktörer och use case .
Huvudsyftet är att tillhandahålla ett enda verktyg som låter kunden, slutanvändaren och utvecklaren diskutera systemets funktionalitet och beteende tillsammans.
Kommunikations- och sekvensdiagram är transitiva , de uttrycker interaktion, men de visar det på olika sätt och kan med tillräcklig grad av noggrannhet omvandlas från en till en annan.
Kommunikationsdiagram (Kommunikationsdiagram, i UML 1.x - samarbetsdiagram , samverkansdiagram ) - ett diagram som skildrar interaktioner mellan delar av en sammansatt struktur eller samarbetsroller. Till skillnad från sekvensdiagrammet indikerar kommunikationsdiagrammet uttryckligen förhållandet mellan element (objekt), och använder inte tid som en separat dimension (anropande sekvensnummer används).
Sekvensdiagram - ett diagram som visar interaktioner mellan objekt, ordnade efter tidpunkten för deras manifestation. I synnerhet skildrar den objekten som deltar i interaktionen och sekvensen av meddelanden som de utbyter.
Samarbetsdiagram - Den här typen av diagram låter dig beskriva interaktionen mellan objekt, abstrahera från sekvensen av meddelanden som skickas. Denna typ av diagram återspeglar i en kompakt form alla mottagna och sända meddelanden för ett visst objekt och typerna av dessa meddelanden.
Eftersom sekvens- och samarbetsdiagram är olika vyer av samma processer, låter Rational Rose dig skapa samarbetsdiagram från sekvensdiagram och vice versa, och synkroniserar även dessa diagram automatiskt.
Ett interaktionsöversiktsdiagram är en typ av aktivitetsdiagram som inkluderar sekvensdiagramfragment och kontrollflödeskonstruktioner.
Denna typ av diagram inkluderar Sekvensdiagram (diagram över sekvenser av åtgärder) och Samarbetsdiagram (samarbetsdiagram). Dessa diagram låter dig överväga interaktionen mellan objekt i systemet som skapas från olika synvinklar.
Tidsdiagram - en alternativ representation av sekvensdiagrammet, som explicit visar tillståndsförändringarna på livlinan med en given tidsskala. Kan vara användbart i realtidsapplikationer.
Trots att UML är en ganska utbredd och använd standard, kritiseras den ofta på grund av följande brister:
| Unified Modeling Language | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||
| |||||||||||
| |||||||||||
| Mjukvaruutveckling | |
|---|---|
| Bearbeta | |
Koncept på hög nivå | |
| Vägbeskrivning |
|
| Utvecklingsmetoder _ | |
| Modeller |
|
| Anmärkningsvärda siffror |
|
| ISO- standarder | |
|---|---|
| |
| 1 till 9999 |
|
| 10 000 till 19999 |
|
| 20 000+ | |
| Se även: Lista över artiklar vars titlar börjar med "ISO" | |