OOAD - Objektorienteret design - Tutorialspoint

Systemdesign

Objekt-orienteret systemdesign omfatter definition af et systems kontekst efterfulgt af design af systemets arkitektur.

Kontekst – Konteksten for et system har en statisk og en dynamisk del. Systemets statiske kontekst designes ved hjælp af et simpelt blokdiagram af hele systemet, som udvides til et hierarki af delsystemer. Undersystemmodellen er repræsenteret ved UML-pakker. Den dynamiske kontekst beskriver, hvordan systemet interagerer med sit miljø. Den modelleres ved hjælp af use case-diagrammer.
Systemarkitektur – Systemarkitekturen udformes på grundlag af systemets kontekst i overensstemmelse med principperne for arkitektonisk design samt domæneviden. Typisk opdeles et system i lag, og hvert lag dekomponeres for at danne delsystemerne.

Objektorienteret dekomponering

Dekomponering betyder opdeling af et stort komplekst system i et hierarki af mindre komplekse komponenter med mindre kompleksitet efter principperne om divide-and-conquer. Hver større komponent i systemet kaldes et delsystem. Objektorienteret dekomposition identificerer de enkelte autonome objekter i et system og kommunikationen mellem disse objekter.

Fordelene ved dekomposition er –

De enkelte komponenter er af mindre kompleksitet og dermed mere forståelige og håndterbare.
Det muliggør opdeling af arbejdsstyrken med specialiserede færdigheder.
Det gør det muligt at udskifte eller ændre delsystemer uden at påvirke andre delsystemer.

Identificering af Concurrency

Concurrency gør det muligt for flere objekter at modtage begivenheder på samme tid og for flere aktiviteter at blive udført samtidigt. Concurrency identificeres og repræsenteres i den dynamiske model.

For at muliggøre concurrency tildeles hvert concurrent element en separat kontroltråd. Hvis samtidigheden er på objektniveau, tildeles to samtidige objekter to forskellige kontroltråde. Hvis to operationer af et enkelt objekt er samtidige af natur, opdeles dette objekt på forskellige tråde.

Concurrency er forbundet med problemerne dataintegritet, deadlock og sultedannelse. Der skal derfor udarbejdes en klar strategi, når der er behov for samtidighed. Desuden skal samtidighed identificeres i selve designfasen og kan ikke overlades til implementeringsfasen.

Identificering af mønstre

Ved design af applikationer vedtages nogle almindeligt accepterede løsninger for visse kategorier af problemer. Disse er designmønstre. Et mønster kan defineres som et dokumenteret sæt af byggeklodser, der kan anvendes i visse typer af problemer i forbindelse med applikationsudvikling.

Nogle almindeligt anvendte designmønstre er –

Façade-mønster
Model view separation pattern
Observer pattern
Model view controller-mønster
Publish subscribe-mønster
Proxy-mønster

Controlling af hændelser

Under systemdesign, de hændelser, der kan forekomme i systemets objekter, skal identificeres og håndteres på passende vis.

En hændelse er en specifikation af en væsentlig hændelse, der har en placering i tid og rum.

Der er fire typer af hændelser, der kan modelleres, nemlig –

Signalhændelse – Et navngivet objekt, der kastes af et objekt og opfanges af et andet objekt.
Kaldshændelse – En synkron hændelse, der repræsenterer afsendelse af en operation.
Time Event – En hændelse, der repræsenterer tidsforløb.
Change Event – En hændelse, der repræsenterer ændring af tilstand.

Håndtering af randbetingelser

Systemdesignfasen skal omhandle initialisering og afslutning af systemet som helhed samt af hvert enkelt delsystem. De forskellige aspekter, der dokumenteres, er som følger –

Systemets opstart, dvs. systemets overgang fra ikke-initialiseret tilstand til stabil tilstand.

Systemets afslutning, dvs, lukning af alle kørende tråde, oprydning af ressourcer og de meddelelser, der skal sendes.

Den indledende konfiguration af systemet og omkonfigurering af systemet, når det er nødvendigt.

Forudseende af fejl eller uønsket afslutning af systemet.

Grænsebetingelser modelleres ved hjælp af grænsebrugstilfælde.

Objektdesign

Når hierarkiet af delsystemer er blevet udviklet, identificeres objekterne i systemet, og deres detaljer designes. Her uddyber designeren den strategi, der er valgt under systemdesignet. Vægten skifter fra anvendelsesdomænekoncepter til computerkoncepter. De objekter, der identificeres under analysen, ætses ud til implementering med henblik på at minimere udførelsestiden, hukommelsesforbruget og de samlede omkostninger.

Objektdesign omfatter følgende faser –

Objektidentifikation
Objektrepræsentation, dvs, konstruktion af designmodeller
Klassifikation af operationer
Algoritmedesign
Design af relationer
Implementering af kontrol for eksterne interaktioner
Pakning af klasser og associationer i moduler

Objektidentifikation

Det første trin i objektdesign er objektidentifikation. De objekter, der er identificeret i de objektorienterede analysefaser, grupperes i klasser og forfines, så de er egnede til den faktiske implementering.

Funktionerne på dette trin er –

Identificering og forfining af klasserne i hvert delsystem eller pakke
Definering af forbindelserne og associationerne mellem klasserne
Design af de hierarkiske associationer mellem klasserne, dvs, generalisering/specialisering og arv
Design af aggregeringer

Objektrepræsentation

Når klasserne er identificeret, skal de repræsenteres ved hjælp af objektmodelleringsteknikker. Denne fase omfatter hovedsagelig konstruktion af UML-diagrammer.

Der er to typer designmodeller, der skal produceres –

Statiske modeller – For at beskrive den statiske struktur af et system ved hjælp af klassediagrammer og objektdiagrammer.
Dynamiske modeller – For at beskrive den dynamiske struktur af et system og vise interaktionen mellem klasser ved hjælp af interaktionsdiagrammer og tilstandsdiagrammer.

Klassifikation af operationer

I dette trin defineres den operation, der skal udføres på objekter, ved at kombinere de tre modeller, der er udviklet i OOA-fasen, nemlig objektmodellen, den dynamiske model og den funktionelle model. En operation specificerer, hvad der skal gøres, og ikke hvordan det skal gøres.

Der udføres følgende opgaver vedrørende operationer –

Der udvikles et tilstandsovergangsdiagram for hvert objekt i systemet.
Der defineres operationer for de hændelser, som objekterne modtager.
Fælde, hvor en hændelse udløser andre hændelser i samme eller forskellige objekter, identificeres.
Underoperationerne inden for handlingerne identificeres.
De vigtigste handlinger udvides til dataflowdiagrammer.

Algoritme design

Operationerne i objekterne defineres ved hjælp af algoritmer. En algoritme er en trinvis procedure, der løser det problem, der er fastlagt i en operation. Algoritmer fokuserer på, hvordan det skal gøres.

Der kan være mere end én algoritme, der svarer til en given operation. Når de alternative algoritmer er identificeret, vælges den optimale algoritme for det givne problemområde. Målepunkterne for valg af den optimale algoritme er –

Computational Complexity – Kompleksiteten bestemmer effektiviteten af en algoritme med hensyn til beregningstid og hukommelsesbehov.

Fleksibilitet – Fleksibiliteten bestemmer, om den valgte algoritme kan implementeres på passende vis uden tab af hensigtsmæssighed i forskellige miljøer.

Uforståelighed – Dette afgør, om den valgte algoritme er let at forstå og implementere.

Design af relationer

Strategien for implementering af relationerne skal udarbejdes i løbet af objektdesignfasen. De vigtigste relationer, der behandles, omfatter associationer, aggregeringer og arv.

Designeren bør gøre følgende med hensyn til associationer –

Identificer, om en association er ensrettet eller tovejsrettet.
Analysér stien for associationerne og opdater dem om nødvendigt.
Implementer associationerne som et særskilt objekt, hvis der er tale om mange-til-mange-relationer; eller som et link til et andet objekt, hvis der er tale om en-til-en- eller en-til-mange-relationer.

Med hensyn til arvelighed bør designeren gøre følgende –

Justér klasserne og deres associationer.
Identificer abstrakte klasser.
Skab bestemmelser, så adfærd deles, når der er behov for det.

Implementering af kontrol

Objektdesigneren kan indarbejde forfininger i strategien for tilstandsdiagrammodellen. I systemdesignet laves en grundlæggende strategi for realisering af den dynamiske model. Under objektdesignet forskønnes denne strategi med henblik på en passende implementering.

Ansætningerne til implementering af den dynamiske model er –

Repræsentere tilstand som en placering i et program – Dette er den traditionelle procedure-drevne tilgang, hvor placeringen af kontrollen definerer programtilstanden. En finite state machine kan implementeres som et program. En overgang udgør en indgangsangivelse, hovedkontrolvejen udgør sekvensen af instruktioner, grenene udgør betingelserne, og de bagudrettede veje udgør løkker eller iterationer.
State Machine Engine – Denne fremgangsmåde repræsenterer en tilstandsmaskine direkte gennem en tilstandsmaskineklasse. Denne klasse udfører tilstandsmaskinen gennem et sæt overgange og handlinger, der leveres af applikationen.
Kontrol som samtidige opgaver – I denne tilgang implementeres et objekt som en opgave i programmeringssproget eller operativsystemet. Her implementeres en hændelse som et opkald mellem opgaverne. Det bevarer den iboende samtidighed for virkelige objekter.

Pakning af klasser

I ethvert stort projekt er det vigtigt at foretage en omhyggelig opdeling af en implementering i moduler eller pakker. Under objektdesign grupperes klasser og objekter i pakker for at gøre det muligt for flere grupper at samarbejde om et projekt.

De forskellige aspekter af pakning er –

Skjuler intern information for udefrakommende – Det gør det muligt at betragte en klasse som en “sort boks” og tillader, at klassens implementering kan ændres uden at kræve, at nogen af klassens klienter ændrer kode.
Sammenhæng mellem elementer – Et element, f.eks. en klasse, en operation eller et modul, er sammenhængende, hvis det er organiseret efter en konsistent plan, og alle dets dele er iboende relateret til hinanden, så de tjener et fælles mål.
Konstruktion af fysiske moduler – Følgende retningslinjer hjælper under konstruktionen af fysiske moduler –
- Klasserne i et modul bør repræsentere lignende ting eller komponenter i det samme sammensatte objekt.
- Tæt forbundne klasser bør være i samme modul.
- Uforbundne eller svagt forbundne klasser bør placeres i separate moduler.
- Moduler bør have en god sammenhængskraft, dvs, højt samarbejde mellem dets komponenter.
- Et modul bør have lav kobling med andre moduler, dvs. interaktion eller indbyrdes afhængighed mellem modulerne bør være minimal.

Designoptimering

Analysemodellen indfanger de logiske oplysninger om systemet, mens designmodellen tilføjer detaljer for at understøtte effektiv informationsadgang. Før et design implementeres, bør det optimeres for at gøre implementeringen mere effektiv. Formålet med optimering er at minimere omkostningerne i form af tid, plads og andre målinger.

Designoptimering bør imidlertid ikke være overdreven, da let implementering, vedligeholdbarhed og udvidelighed også er vigtige hensyn. Det ses ofte, at et perfekt optimeret design er mere effektivt, men mindre læsbart og genanvendeligt. Så designeren skal finde en balance mellem de to ting.

De forskellige ting, der kan gøres med henblik på designoptimering, er –

Tilføje redundante associationer
Undgå ikke-anvendelige associationer
Optimering af algoritmer
Save afledte attributter for at undgå genberegning af komplekse udtryk

Tilføjelse af redundante associationer

Ved designoptimering, kontrolleres det, om afledning af nye associationer kan reducere adgangsomkostningerne. Selv om disse redundante associationer måske ikke tilføjer nogen information, kan de øge effektiviteten af den samlede model.

Optagelse af ikke-anvendelige associationer

Fordelingen af for mange associationer kan gøre et system uoverskueligt og dermed reducere systemets samlede effektivitet. Under optimeringen fjernes derfor alle ikke-anvendelige associationer undervejs.

Optimering af algoritmer

I objektorienterede systemer foregår optimering af datastruktur og algoritmer i et samarbejde. Når klassedesignet er på plads, skal operationerne og algoritmerne optimeres.

Optimering af algoritmer opnås ved –

Optimering af rækkefølgen af beregningsopgaver
Optimering af løkkenes udførelsesrækkefølge i forhold til den, der er fastlagt i den funktionelle model
Fjernelse af døde stier i algoritmen

Save and Storing of Derived Attributes

Derived attributes er de attributter, hvis værdier beregnes som en funktion af andre attributter (basisattributter). Det er en tidskrævende procedure at genberegne værdierne for afledte attributter, hver gang der er brug for dem. For at undgå dette kan værdierne beregnes og gemmes i deres beregnede form.

Dette kan imidlertid give anledning til opdateringsanomalier, dvs. en ændring i værdierne for basisattributter uden tilsvarende ændring i værdierne for de afledte attributter. For at undgå dette tages følgende skridt –

Med hver opdatering af basisattributværdien genberegnes den afledte attribut også på ny.
Alle afledte attributter genberegnes og opdateres periodisk i en gruppe i stedet for efter hver opdatering.

Designdokumentation

Dokumentation er en væsentlig del af enhver softwareudviklingsproces, der registrerer proceduren for fremstilling af softwaren. Det er nødvendigt at dokumentere designbeslutningerne for ethvert ikke-trivielt softwaresystem for at overføre designet til andre.

Anvendelsesområder

Og selv om det er et sekundært produkt, er en god dokumentation uundværlig, især på følgende områder –

I forbindelse med design af software, der udvikles af flere udviklere
I forbindelse med iterative softwareudviklingsstrategier
I forbindelse med udvikling af efterfølgende versioner af et softwareprojekt
I forbindelse med evaluering af et software
I forbindelse med at finde betingelser og områder for afprøvning
I forbindelse med vedligeholdelse af softwaren.

Indhold

En gavnlig dokumentation bør i det væsentlige omfatte følgende indhold –

Systemarkitektur på højt niveau – Procesdiagrammer og moduldiagrammer
Nøgleabstraktioner og mekanismer – Klassediagrammer og objektdiagrammer.
Scenarier, der illustrerer de vigtigste aspekters adfærd – Adfærdsdiagrammer

Kendetegn

Kendetegnene ved en god dokumentation er –

Koncis og samtidig utvetydig, konsistent og komplet
Sporbar til systemets kravspecifikationer
Velstruktureret
Diagrammatisk i stedet for beskrivende

Rådgivninger

OOAD – Object Oriented Design