UML
Det er utroligt vigtigt at analysere et kompleks softwaresystem, før man begynder at konstruere eller renovere det. Der findes over 50 teknikker til objekt-orienteret analyse og design, som alle bruger forskellige modeller til at visualisere og beskrive et kompleks objekt-orienteret softwaresystem. Modellerne bruges blandt andet til at kommunikere ud fra samt til at sikre en god arkitektur. Det er her UML kommer ind i billedet.
UML (Unified Modeling Language) bygger på tre af de mest brugte teknikker til objekt-orienteret analyse og design, nemlig Booch's teknik, OOSE (Object-Oriented Software Engineering) og OMT (Object Modeling Technique). UML er blevet udviklet af Rational Software i samarbejde med andre firmaer. UML blev senere til en standard, og den er åben for alle. Mange firmaer bruger UML i forbindelse med store softwareprojekter.
UML er et sprog, notation eller syntaks, der bruges til at beskrive en visuel og logisk model af et system. Systemet kan være et hvilket som helst system, der kan indeholde både information og funktioner, men UML bruges normalt til at beskrive designet af et objekt-orienteret softwaresystem.
Ved brug af UML kan man beskrive et system i mange detaljer på flere abstraktionsniveauer. I sig selv beskriver UML ikke processen for, hvordan modellen skabes, eller hvilken arkitektur der skal bruges til implementering. Ved brug af UML får man notationen til at definere et system med en specifik arkitektur, og dette bliver gjort på en objektorienteret måde.
UML kan altså både bruges til at specificere, visualisere, konstruere og dokumentere et softwaresystem, men UML er ikke et programmeringssprog, ikke en model og ikke et værktøj.
Til at visualisere de mange detaljer og abstraktionsnivauer, der findes i et softwaresystem, benyttes der diagrammer til præsentation eller modellering af både analyse og design. Til alle diagrammer er der tilknyttet en specifik notation, modelelementer og retningslinier. Notation er de vigtigste koncepter og semantik, modelelementer er en visuel gengivelse af elementerne i modellen og retningslinier er kort sagt regler for brug af notation og modelelementer.
Eksempel på et use case diagram, som beskrives nærmere i næste afsnit.
Hvis vi for eksempel kigger på begrebet use case, som er en handling eller en bestemt opførsel en bruger gør i forbindelse med brug af softwaresystemet, så repræsenteres en sådan use case af en oval cirkel, hvortil der er knyttet en beskrivelse for eksempel "Tegne en forsikring". En bruger repræsenteres som en tændstikmand med en beskrivelse, eksempelvis "Forsikringsagent". En use case kan relateres til andre use cases, og dette repræsenteres af en pil.
Analyse
En objekt-orienteret analyse består af tre trin:
1. Use Case modellering.
2. Klassemodellering (Class Modeling).
3. Dynamisk modellering (Dynamic Modeling).
Disse tre trin kan normalt ikke udføres i den ovenstående rækkefølge, da ændringer i en model eller diagram vil medføre ændringer i de to andre diagrammer. Derfor bliver trinene udført parallelt.
1. Use Case Modeling
Bestem hvordan de forskellige resultater beregnes af systemet, dog uden at tænke på, hvilken rækkefølge dette gøres. Præsenter denne information i et use case diagram og tilhørende scenarier (en instans af en use case). Et use case diagram visualiserer brugernes forhold til hinanden, hvordan brugerne vil benytte systemet. Et use case diagram er altså en definition af kravene for et system, som både kan forstås af brugere og udviklere.
2. Klasse modellering
Bestem klasserne og deres attributter, og bestem herefter de indbyrdes forhold imellem klasserne. Præsenter dette i et klassediagram (class diagram). Klassediagrammet beskriver typer af objekter og deres indbyrdes forhold.
I samme gruppe (Static Structure) som klassediagrammer findes også objektdiagrammer, der illustrerer aktuelle objekter og deres indbyrdes forhold. Men at beskrive alle objekter i et system kan være omfattende, især da mange objekter ligner hinanden. Derfor bruges klassediagrammer mere end objekt diagrammer. Objekter er først rigtig vigtige, når de har forbindelse til et andet objekt, og til at beskrive dette bruges vekselvirkningsdiagrammer, som beskrives i næste afsnit.
3. Dynamisk modellering
Bestem hvilke handlinger der udføres på eller af hver klasse eller subklasse. Præsenter denne information i statusdiagram (state diagram). Et state diagram viser, hvilke operationer som afhænger af hvilke klasser, og hvordan et objekt fungerer i forskellige stadier. Alle de mulige scenarier reflekteres af diagrammet.
Design
Objekt-orienteret design består af fire trin:
1. Konstruer vekselvirkningsdiagrammer (interaction diagram) for hvert scenarie.
2. Konstruer detaljerede klassediagrammer.
3. Design systemet med vægt på forholdet mellem objekter og klienter.
4. Gå videre med det detaljerede design.
1. Vekselvirkningsdiagrammer
UML understøtter to vekselvirkningsdiagrammer, sekvens (sequence) og samarbejdsdiagrammer (collaboration). Begge diagrammer viser de samme ting - objekter og de meddelelser som sendes imellem objekterne. Men de to diagrammer lægger, som navnene antyder, vægt på noget forskelligt. Sekvensdiagrammer lægger vægt på den kronologiske rækkefølge af meddelelser, og disse diagrammer bruges derfor, hvor rækkefølgen af handlinger er vigtig. Samarbejdsdiagrammer lægger vægt på forholdet mellem objekter, og de er derfor gode til at illustrere strukturen af et softwaresystem.
2. Detaljerede klassediagrammer
Klassediagrammet, som blev fremstillet i analysefasen, viser klasser og deres attributter, men ikke deres funktioner og metoder. Metoder og funktioner indsættes nu i et mere detaljeret klassediagram.
3. Forholdet mellem objekter og klienter
Et objekts klient defineres som en programdel, der sender en meddelelse til det pågældende objekt. For eksempel hvis objektet C sender en meddelelse til objektet O, så er C en klient af O. Der skal derfor fremstilles et diagram, som illustrerer forholdene mellem objekter og klienter.
4. Detaljeret design
Det detaljerede design kan vises ved hjælp af forskellige metoder, deriblandt pseudokode eller ved brug af tabeller, der beskriver hver komponent.
Udover de beskrevne diagrammer findes der et aktivitetsdiagram (activity diagram), som kan bruges alle steder i en model til at vise et flow af aktiviteter. Aktivitetsdiagrammet kan bruges som et supplement til vekselvirkningsdiagrammer, da disse kun illustrerer de objekter, som afleverer meddelelser, mens et aktivitetsdiagram illustrerer de operationer som sendes imellem objekterne. Men de fleste bruger aktivitetsdiagrammet til at definere et flow af handlinger på forretningsniveau.
