OOAD - Object Oriented Design - Tutorialspoint

Systemdesign

Objekt-orienterad systemdesign innebär att man definierar sammanhanget för ett system följt av utformning av systemets arkitektur.

Kontext – Kontexten för ett system har en statisk och en dynamisk del. Systemets statiska kontext utformas med hjälp av ett enkelt blockdiagram av hela systemet som utvidgas till en hierarki av delsystem. Delsystemmodellen representeras av UML-paket. Det dynamiska sammanhanget beskriver hur systemet interagerar med sin omgivning. Den modelleras med hjälp av användningsfallsdiagram.
Systemarkitektur – Systemarkitekturen utformas på grundval av systemets kontext i enlighet med principerna för arkitekturdesign samt domänkunskap. Typiskt sett delas ett system in i lager och varje lager dekomponeras för att bilda delsystemen.

Objektsorienterad dekomponering

Dekomponering innebär att man delar upp ett stort komplext system i en hierarki av mindre komponenter med mindre komplexitet, enligt principerna om divide-and-conquer. Varje större komponent i systemet kallas ett delsystem. Objektorienterad dekomposition identifierar enskilda autonoma objekt i ett system och kommunikationen mellan dessa objekt.

Fördelarna med dekomposition är –

De enskilda komponenterna är mindre komplexa och därmed mer begripliga och hanterbara.
Det möjliggör uppdelning av arbetskraft som har specialiserad kompetens.
Det gör det möjligt att byta ut eller ändra delsystem utan att påverka andra delsystem.

Identifiera Concurrency

Concurrency gör det möjligt för fler än ett objekt att ta emot händelser samtidigt och för fler än en aktivitet att utföras samtidigt. Samtidighet identifieras och representeras i den dynamiska modellen.

För att möjliggöra samtidighet tilldelas varje samtida element en separat kontrolltråd. Om samtidigheten är på objektsnivå tilldelas två samtidiga objekt två olika kontrolltrådar. Om två operationer av ett enda objekt är samtidiga till sin natur delas det objektet upp på olika trådar.

Concurrency är förknippat med problem som dataintegritet, dödläge och svält. Därför måste en tydlig strategi utarbetas när samtidighet krävs. Dessutom måste samtidighet identifieras i själva konstruktionsstadiet och kan inte lämnas till implementeringsstadiet.

Identifiera mönster

När man konstruerar tillämpningar antas vissa allmänt accepterade lösningar för vissa kategorier av problem. Dessa är designmönstren. Ett mönster kan definieras som en dokumenterad uppsättning byggstenar som kan användas i vissa typer av problem med applikationsutveckling.

Vissa vanligt förekommande designmönster är –

Façademönster
Mönster för separation av modell och vy
Observermönster

Mönster för modellvyns controller
Publish subscribe pattern
Proxy pattern

Controlling Events

Under systemdesign, måste de händelser som kan inträffa i systemets objekt identifieras och hanteras på lämpligt sätt.

En händelse är en specifikation av en betydande händelse som har en plats i tid och rum.

Det finns fyra typer av händelser som kan modelleras, nämligen –

Signalhändelse – Ett namngivet objekt som kastas av ett objekt och fångas upp av ett annat objekt.
Kallhändelse – En synkron händelse som representerar avsändandet av en operation.
Time Event – En händelse som representerar tidens gång.
Change Event – En händelse som representerar en förändring av tillståndet.

Hantering av randvillkor

Systemkonstruktionsfasen måste ta upp initialisering och avslutande av systemet som helhet samt av varje delsystem. De olika aspekter som dokumenteras är följande –

Systemets uppstart, dvs. systemets övergång från icke-initialiserat tillstånd till stabilt tillstånd.

Systemets avslutande, dvs, stängning av alla löpande trådar, rensning av resurser och de meddelanden som ska skickas.

Systemets inledande konfiguration och omkonfigurering av systemet vid behov.

Förutseende av fel eller oönskad avslutande av systemet.

Gränsvillkor modelleras med hjälp av gränsanvändningsfall.

Objektsdesign

När hierarkin av delsystem har utvecklats identifieras objekten i systemet och deras detaljer designas. Här beskriver konstruktören i detalj den strategi som valts under systemkonstruktionen. Tonvikten flyttas från tillämpningsdomänens begrepp till datorbegrepp. De objekt som identifieras under analysen etsas ut för implementering med målet att minimera exekveringstid, minnesförbrukning och totalkostnad.

Objektsdesign omfattar följande faser –

Objektidentifiering
Objektrepresentation, dvs, konstruktion av designmodeller
Klassificering av operationer
Algoritmdesign
Design av relationer
Implementering av kontroll för externa interaktioner
Package av klasser och associationer till moduler

Objektidentifiering

Det första steget i objektsdesign är objektidentifiering. De objekt som identifierats i de objektorienterade analysfaserna grupperas i klasser och förfinas så att de lämpar sig för det faktiska genomförandet.

Funktionerna i detta skede är –

Identifiera och förfina klasserna i varje delsystem eller paket
Definiera länkarna och associationerna mellan klasserna
Utforma de hierarkiska associationerna mellan klasserna, dvs, generalisering/specialisering och arv
Utformning av aggregeringar

Objektrepresentation

När klasserna väl är identifierade måste de representeras med hjälp av tekniker för objektmodellering. I detta skede handlar det i huvudsak om att konstruera UML-diagram.

Det finns två typer av designmodeller som måste produceras –

Statiska modeller – För att beskriva den statiska strukturen hos ett system med hjälp av klassdiagram och objektdiagram.
Dynamiska modeller – För att beskriva den dynamiska strukturen i ett system och visa interaktionen mellan klasser med hjälp av interaktionsdiagram och tillståndsdiagram.

Klassificering av operationer

I det här steget definieras de operationer som ska utföras på objekten genom att kombinera de tre modellerna som tagits fram i OOA-fasen, nämligen objektmodellen, den dynamiska modellen och funktionsmodellen. En operation specificerar vad som ska göras och inte hur det ska göras.

Följande uppgifter utförs när det gäller operationer –

Det utvecklas ett tillståndsövergångsdiagram för varje objekt i systemet.
Operationer definieras för de händelser som tas emot av objekten.
Fall där en händelse utlöser andra händelser i samma eller olika objekt identifieras.
Underoperationerna inom handlingarna identifieras.
Huvudaktionerna utökas till dataflödesdiagram.

Algoritmdesign

Operationerna i objekten definieras med hjälp av algoritmer. En algoritm är ett stegvis förfarande som löser det problem som fastställts i en operation. Algoritmer fokuserar på hur det ska göras.

Det kan finnas mer än en algoritm som motsvarar en viss operation. När de alternativa algoritmerna har identifierats väljs den optimala algoritmen för det givna problemområdet. Mätvärdena för att välja den optimala algoritmen är –

Räkningskomplexitet – Komplexiteten avgör hur effektiv en algoritm är i termer av beräkningstid och minneskrav.

Flexibilitet – Flexibiliteten avgör om den valda algoritmen kan implementeras på ett lämpligt sätt, utan att förlora sin lämplighet i olika miljöer.

Förståelse – Detta avgör om den valda algoritmen är lätt att förstå och implementera.

Design av relationer

Strategin för att implementera relationerna måste utarbetas under objektdesignfasen. De viktigaste relationerna som behandlas är associationer, aggregationer och arv.

Designern bör göra följande när det gäller associationer –

Identifiera om en association är enkelriktad eller dubbelriktad.
Analysera associationernas väg och uppdatera dem vid behov.
Införliva associationerna som ett distinkt objekt om det rör sig om många-till-många-relationer eller som en länk till ett annat objekt om det rör sig om en-till-en- eller en-till-många-relationer.

Med avseende på arv bör konstruktören göra följande –

Justera klasserna och deras associationer.
Identifiera abstrakta klasser.
Förberedelser så att beteenden delas vid behov.

Implementering av kontroll

Objektsdesignern kan införliva förfiningar i strategin för tillståndsdiagrammodellen. Vid systemkonstruktion görs en grundläggande strategi för att förverkliga den dynamiska modellen. Under objektsdesignen förskönas denna strategi för lämplig implementering.

Ansatserna för implementering av den dynamiska modellen är –

Representera tillståndet som en plats i ett program – Detta är den traditionella procedurstyrda strategin där platsen för kontroll definierar programtillståndet. En finit tillståndsmaskin kan implementeras som ett program. En övergång bildar ett inmatningsmeddelande, huvudkontrollvägen bildar sekvensen av instruktioner, grenarna bildar villkoren och de bakåtriktade vägarna bildar slingor eller iterationer.
State Machine Engine – Detta tillvägagångssätt representerar direkt en tillståndsmaskin genom en klass för en tillståndsmaskin. Denna klass utför tillståndsmaskinen genom en uppsättning övergångar och åtgärder som tillhandahålls av programmet.
Kontroll som samtidiga uppgifter – I detta tillvägagångssätt implementeras ett objekt som en uppgift i programmeringsspråket eller operativsystemet. Här implementeras en händelse som ett anrop mellan uppgifter. Det bevarar verklig objekts inneboende samtidighet.

Packning av klasser

I alla stora projekt är det viktigt med noggrann uppdelning av ett genomförande i moduler eller paket. Under objektdesignen grupperas klasser och objekt i paket för att göra det möjligt för flera grupper att samarbeta i ett projekt.

De olika aspekterna av paketering är –

Dölja intern information från utomstående – Det gör det möjligt att betrakta en klass som en ”svart låda” och tillåter att klassens implementering ändras utan att kräva att någon klient av klassen ändrar koden.
Sammanhängande element – Ett element, t.ex. en klass, en operation eller en modul, är sammanhängande om det är organiserat enligt en konsekvent plan och alla dess delar har ett naturligt samband så att de tjänar ett gemensamt mål.
Konstruktion av fysiska moduler – Följande riktlinjer är till hjälp när man konstruerar fysiska moduler –
- Klasser i en modul bör representera liknande saker eller komponenter i samma sammansatta objekt.
- Tätt sammankopplade klasser bör finnas i samma modul.
- Oförbundna eller svagt sammankopplade klasser bör placeras i separata moduler.
- Moduler bör ha god sammanhållning, dvs, hög grad av samarbete mellan dess komponenter.
- En modul bör ha låg koppling till andra moduler, dvs. interaktionen eller det ömsesidiga beroendet mellan modulerna bör vara minimalt.

Optimering av utformningen

Analysmodellen fångar den logiska informationen om systemet, medan utformningsmodellen lägger till detaljer för att stödja en effektiv informationsåtkomst. Innan en design implementeras bör den optimeras för att göra implementeringen mer effektiv. Syftet med optimering är att minimera kostnaden i form av tid, utrymme och andra mått.

Designoptimering bör dock inte vara överflödig, eftersom enkel implementering, underhållbarhet och utvidgbarhet också är viktiga frågor. Man ser ofta att en perfekt optimerad design är effektivare men mindre läsbar och återanvändbar. Konstruktören måste alltså hitta en balans mellan dessa två.

De olika saker som kan göras för designoptimering är –

Lägg till redundanta associationer
Släpp bort icke användbara associationer
Optimering av algoritmer
Spara härledda attribut för att undvika att komplexa uttryck beräknas på nytt

Lägg till redundanta associationer

Under designoptimering, kontrolleras det om nya associationer kan minska åtkomstkostnaderna. Även om dessa överflödiga associationer kanske inte tillför någon information kan de öka effektiviteten i den övergripande modellen.

Förlust av icke användbara associationer

Förekomsten av för många associationer kan göra ett system obegripligt och därmed minska systemets övergripande effektivitet. Under optimeringen tas därför alla icke användbara associationer bort.

Optimering av algoritmer

I objektorienterade system sker optimering av datastruktur och algoritmer i samarbete. När klassdesignen väl är på plats måste operationerna och algoritmerna optimeras.

Optimering av algoritmer erhålls genom –

Omläggning av ordningsföljden för beräkningsuppgifter
Omläggning av looparnas exekveringsföljd från den som fastställts i den funktionella modellen

Borttagning av döda vägar inom algoritmen

Sparande och lagring av avledda attribut

Avledda attribut är de attribut vars värden beräknas som en funktion av andra attribut (basattribut). Det är ett tidskrävande förfarande att räkna om värdena för härledda attribut varje gång de behövs. För att undvika detta kan värdena beräknas och lagras i sin beräknade form.

Detta kan dock ge upphov till uppdateringsanomalier, dvs. en förändring av värdena för basattributen utan motsvarande förändring av värdena för de härledda attributen. För att undvika detta vidtas följande åtgärder –

Vid varje uppdatering av basattributets värde beräknas även det härledda attributet på nytt.
Alla härledda attribut beräknas på nytt och uppdateras periodiskt i en grupp i stället för efter varje uppdatering.

Designdokumentation

Dokumentation är en viktig del av varje programvaruutvecklingsprocess som registrerar förfarandet för att göra programvaran. Konstruktionsbesluten måste dokumenteras för alla icke-triviala programvarusystem för att överföra konstruktionen till andra.

Användningsområden

En bra dokumentation är oumbärlig även om den är en sekundär produkt, särskilt inom följande områden –

För att utforma programvara som utvecklas av ett antal utvecklare
För iterativa strategier för programvaruutveckling
För att utveckla efterföljande versioner av ett programvaruprojekt
För att utvärdera en programvara
För att hitta villkor och områden för testning
För underhåll av programvaran.

Innehåll

En fördelaktig dokumentation bör i huvudsak innehålla följande innehåll –

Systemarkitektur på hög nivå – Processdiagram och moduldiagram
Nyckelabstraktioner och -mekanismer – Klassdiagram och objektdiagram.
Scenarier som illustrerar de viktigaste aspekternas beteende – Beteendediagram

Kännetecken

Kännetecknen för en bra dokumentation är –

Sammanfattad och samtidigt entydig, konsekvent och fullständig
Spårbar till systemets kravspecifikationer
Välstrukturerad
Diagrammatisk i stället för beskrivande

OOAD – Object Oriented Design