Objektorienteret analyse

Der er ingen kildehenvisninger i denne artikel, hvilket er et problem. Du kan hjælpe ved at angive kilder til de påstande, der fremføres. Hvis ikke der tilføjes kilder, vil artiklen muligvis blive slettet.

Objektorienteret analyse er i systemudvikling fællesbetegnelsen for en række delmetoder til gennemførelse af analysedelen af et udviklingsforløb.

I analyse beskriver man de begreber fra genstandsområdet og sammenhængene mellem dem, som systemudviklerne har behov for at forstå for at kunne designe og programmere det kommende system. Med andre ord beskriver man, hvad systemet skal kunne. I den objektorienterede tankegang lægger man vægt på at beskrive begreberne (i såvel analyse som design og program) med objekter og deres indbyrdes kommunikation. En af fordelene ved den objektorienterede analyse er, at de modeller, man får beskrevet i denne del af udviklingen, umiddelbart kan videreføres i design og programmering.

Statisk modellering

Reelt er det en tilsnigelse at kalde det "objektorienteret", da man først og fremmest fokuserer på klasse-begrebet. En klasse er beskrivelsen af en række objekter med samme adfærdsmønster, attributter og struktur — man kan sige, at en klasse definerer en række objekter. Et eksempel fra en salgsvirksomhed kan illustrere sammenhængen: Antag at virksomheden har kunder som "Jens Hansen", "Inger Melgaard" og "Andersen og co.". Disse tre kan betragtes som objekter fra klassen "Kunde".

I objektorienteret analyse finder man de relevante klasser og beskriver sammenhængene mellem dem i et klassediagram. Der er flere måder at finde klasser på, f.eks.

• interview af personer fra genstandsområdet
• tekstanalyse
• gennemgang af checklister

hvor man i de to først tilfælde fokuserer på at finde navneord og derudfra udsøger sig relevante begreber, som kan indgå i beskrivelsen af systemet. De relevante begreber kan suppleres med check af lister med forslag til klasser, især hvis der ikke er så store muligheder i de to første tilgangsmåder.

I analyseklassediagrammet fokuserer man på begreber, der er anvendes i genstandsområdet. Man går ikke alt for detaljeret til værks i beskrivelsen, og især søger man at undgå at træffe designmæssige beslutninger for tidligt. Ofte vil man f.eks. have brug for "adresse" som attribut i en klasse, bl.a. i ovennævnte "Kunde"-klasse, men selv om man sandsynligvis i designet vil opdele "adresse"-attributten i flere attributter: "vej", "postnummer" etc., så vil der oftest være tale om et valg af, hvordan attributterne konkret skal repræsenteres, og dette valg udskydes til design.

Dynamisk modellering

Arbejdet med at finde klasser og konstruere et klassediagram har sigte på at beskrive de statiske sammenhænge i systemet. De dynamiske sammenhænge kan beskrives på forskellige måder og give anledning til forskellige supplerende diagrammer. Med interaktionsdiagrammer kan man beskrive, hvordan objekter samarbejder om at løse en opgave i genstandsområdet. Det er dog blevet almindeligt, at man forinden ser nærmere på use cases for genstandsområdet. Use casene er ikke bundet til objektorienteret analyse, men en af de indflydelsesrige bagmænd bag de objektorienterede metoder, svenskeren Ivar Jacobson fik indført use casene i beskrivelsessproget UML og metoden Unified Process, og derfra har de fleste andre metoder taget teknikken ind.

Med use cases fokuserer man på, hvordan de kommende brugere vil bruge det kommende system med ord og begreber fra genstandsområdet. En use case beskriver en række ensartede, afgrænsede og afsluttede anvendelser af systemet, og man vil ofte indlede analysearbejdet med at finde frem til mængden af use cases i systemet. Use cases beskrives med use case diagram samt use case specifikationer. I specifikationerne søger man i detalje at beskrive interaktionen mellem bruger og system, men samtidig bør man undgå at lægge sig fast på tekniske løsninger, lige som man ikke beskriver, hvordan systemet arbejder "bag overfladen". Dette sker til gengælde med interaktionsdiagrammerne, der på den måde kommer til at bygge bro mellem use case perspektivet og objektperspektivet. Et interaktionsdiagram vil normalt være en uddybning af én use case, hvor man beskriver, hvordan objekterne, der er defineret i klassediagrammet, samarbejder om at gennemføre opgaven.

Endelig kan man udarbejde tilstandsdiagrammer for klasser, hvis objekter kan have ikke-trivielle livsforløb. Disse krydscheckes med use cases og interaktionsdiagrammer, så det sikres, at alle tilstande for et objekt kan nås med use cases.

Yderligere aktiviteter

Undertiden vælger man at arbejde med brugergrænsefladen i analysen, selv om der her reelt er tale om design. Design af brugergrænsefladen ligger imidlertid i direkte forlængelse af udarbejdelsen af use casene, og samtidig er det et arbejde, som de kommende brugere kan involveres aktivt i.

Opsamling

En god analysebeskrivelse indeholder dermed:

• klassediagram med evt. supplerende beskrivelse af de enkelte klasser
• use case-diagram og specifikationer (i hvert fald for de ikke-trivielle use cases)
• interaktionsdiagrammer for de centrale og/eller komplicerede use cases
• eventuelt tilstandsdiagrammer for udvalgte klasser
• eventuelt prototyper eller andre beskrivelser af den kommende brugergrænseflade.