Mer om klassdiagram
UML (Unified Modeling Language) är ett visuellt modelleringsspråk för att beskriva, visualisera, specificera och dokumentera olika delar av system och programvara. Syftet med UML är underlätta kommunikation, förståelse och design av komplexa system och programvara mellan utvecklare, kunder och andra intressenter.
Nu ska vi fortsätta med klassdiagram och se hur vi kan göra för att även visa relationer mellan klasserna.
Förutsättning
Section titled “Förutsättning”Du kan grunderna i objektorienterad programmering.
Terminologi
Section titled “Terminologi”-
UML: Unified Modeling Language.
-
Strukturdiagram: (Structure diagram) Statisk representation av strukturen i ett system.
-
Beteendediagram: (Behavior diagram) Dynamisk bild av systemet som visar vad som händer i systemet.
-
Element: Representerar olika delar i UML.
-
Kardinalitet : Antalet objekt som är involverade i en relation.
Strukturdiagram
Section titled “Strukturdiagram”Det vanligaste strukturdiagrammet är klassdiagram vilket vi redan har tittat på. Klassdiagram visar systemets klasser och dess relationer. Ett annat strukturdiagram är komponentdiagram som visar systemets fysiska komponenter inklusive bibliotek, paket och andra moduler samt dess beteende. Sedan finns det även ett paketeringsdiagram (package diagram) som används vid leverans av systemet och visar hur systemet är organiserat i paket och namespaces.
Beteendediagram
Section titled “Beteendediagram”Det beteendediagram som vi ska fokusera på är use case diagram (användningsfallsdiagram) och beskriver funktionaliteten ur användarens perspektiv. Ett annat vanligt beteendediagram är sekvensdiagram som visar hur systemets objekt samverkar i en specifik sekvens över tid. Ett annat vanligt beteendediagram är tillståndsdiagram (state diagram) som visar systemet olika objekts tillstånd och övergångarna mellan dessa tillstånd.
Element i UML
Section titled “Element i UML”Elementen representerar olika delar som till exempel aktörer, klasser, use cases (användningsfall), aktiviteter, tillstånd och komponenter.
- aktör; någon som använder programmet, till exempel en kund till banken.
- klass; en klass med egenskaper och metoder som används för att representera och skapa objekt, till exempel klassen BankAccount.
- relation; relationen mellan element, till exempel att klassen Bank innehåller ett antal objekt av klassen BankAccount.
- use case eller användningsfall; en händelse med en aktör som använder programmet, till exempel kunden vill skapa ett bankkonto.
- aktiviteter; en händelse eller ett steg, till exempel att en kund ber banken skapa ett konto.
- livlina; så länge något element deltar, till exempel börjar ett objekts livlina när objektet skapas.
- tillstånd; beskriver programmets tillstånd, till exempel att ett nytt konto skapats i banken vilket innebär att tillståndet för banken ändrats (antalet konton har ökats med 1).
- komponent; är en del av programmet.
Relationer
Section titled “Relationer”Det finns flera typer av relationer som används i UML för att beskriva beroenden mellan elementen. Här pratar vi om komposition, aggregation och kort om association.
Komposition
Section titled “Komposition”Komposition innebär att objekt av klassen A, innehåller objekt av klassen B. När objekt av ägandeklassen A upphör så upphör också objekten som den innehåller. Komposition visar en “del-av” relation eller en stark “har-en” relation.
Om vi utgår från bankexemplet så innehåller banken ett antal bankkonton. Klassen Bank innehåller objekt av klassen BankAccount. Vi tar med kardinalitet genom att beskriva att en bank (en 1:a vid diamanten på linjen mot Bank) kan ha noll eller flera bankkonton (0..n vid linjen mot BankAccount). När objektet av klassen Bank tas bort så tas även alla objekt av klassen BankAccount bort.
Komposition symboliseras av en ifylld diamant/romb som pekar på det ägande objektet, gärna med kardinalitet.
Aggregation
Section titled “Aggregation”Aggregation är en svagare typ av “har-en” relation än komposition. Aggregation innebär att ett objekt klassen A använder objekt av klassen B. Även om objektet av klassen A upphör att existera så fortsätter objekten av klassen B att existera.
Vi fortsätter med bankexemplet så har banken anställda. Vi har en klass Employee. Klassen Bank har anställda och därmed objekt av klassen Employee. Vi tar med kardinalitet genom att beskriva att en bank (en 1:a vid diamanten på linjen mot Bank) kan ha en eller flera anställda (1..n vid linjen mot Employee). Objekten av klassen Employee fortsätter att existera när Bank upphör.
Aggregation symboliseras av en diamant/romb som inte är ifylld som pekar på det objektet som använder det, gärna med kardinalitet.
Association
Section titled “Association”Association är en generell relation som visar att en eller flera klasser har relationer (som inte är komposition eller aggregation) till varandra. Association kan ha en riktning eller rikta åt båda hållen och ha kardinalitet.
Association visar att ett objekt kan ha en relation till ett annat objekt och samarbeta när det behövs men inte nödvändigtvis hela tiden. Vi fortsätter med bankexemplet så har banken kunder men de kommer och går. Objekt av klassen Customer utnyttjar tjänster i banken och då har Customer en association med Bank. Vi tar med kardinalitet genom att beskriva att en bank (en 1:a vid linjen mot Bank) kan ha noll eller flera kunder (0..n vid pilen mot Customer).
Association symboliseras av en enkel pil som visar riktningen eller en enkel pil som pekar åt båda hållen om riktningarna på associationen går åt båda hållen. Om det är en enkel pil så pekar den på objektet som används, gärna med kardinalitet.
Sammanställning av symboler
Section titled “Sammanställning av symboler”
Bankexemplet
Section titled “Bankexemplet”Koden för bankexemplet är uppdaterad för att bättre passa till denna artikeln. Om du vill titta på koden i sin helhet och ladda ner den så kör du task download-code -- kmom03/MyBank.
Klassöversikt
Section titled “Klassöversikt”- Bank – huvudklassen som har relationer till de andra tre.
- BankAccount – används via komposition. Banken skapar bankkonton som är en del av banken.
- Employee – används via aggregation. Banken har anställda.
- Customer – används via association. Banken betjänar kunder.
Relationer - banken
Section titled “Relationer - banken”- Komposition: Bank skapar BankAccount som är en del av banken och slutar att existera när banken slutar att existera. Bank äger BankAccount.
- Aggregation: Bank har Employee som tillförs utifrån och kan existera utan banken.
- Association: Customer använder Bank men ingen äger den andra och de existerar oberoende av varandra.
Klassdiagram med kardinalitet
Section titled “Klassdiagram med kardinalitet”Här har vi bankexemplet med riktiga symboler och kardinalitet.
- Bank har noll eller flera BankAccount
- Bank har en eller flera Employees
- Bank har noll eller flera Customer
Avslutningsvis
Section titled “Avslutningsvis”PlantUML har använts för Klassdiagram. Det finns andra bra verktyg online för att rita uml diagram, till exempel draw.io och WebSequenceDiagrams.
Om du vill läsa mer om UML.