Objektorienterad analys och design

Objektorienterad analys och design ( OOAD ) är ett tekniskt tillvägagångssätt för att analysera och designa en applikation, ett system eller en verksamhet genom att tillämpa objektorienterad programmering, samt använda visuell modellering genom hela mjukvaruutvecklingsprocessen för att vägleda intressentkommunikation och produktkvalitet.

OOAD i modern mjukvaruteknik utförs vanligtvis på ett iterativt och inkrementellt sätt. Resultaten av OOAD-aktiviteter är analysmodeller (för OOA) respektive designmodeller (för OOD). Avsikten är att dessa kontinuerligt ska förädlas och utvecklas, drivna av nyckelfaktorer som risker och affärsvärde.

Historia

I början av objektorienterad teknologi före mitten av 1990-talet fanns det många olika konkurrerande metoder för mjukvaruutveckling och objektorienterad modellering, ofta knutna till specifika CASE-verktygsleverantörer ( Computer Aided Software Engineering) . Inga standardnotationer, konsekventa termer och processguider var de största problemen vid den tiden, vilket försämrade kommunikationseffektiviteten och förlängde inlärningskurvorna.

Några av de välkända tidiga objektorienterade metoderna var från och inspirerade av gurus som Grady Booch , James Rumbaugh , Ivar Jacobson (de tre Amigos ), Robert Martin , Peter Coad , Sally Shlaer , Stephen Mellor och Rebecca Wirfs-Brock .

1994 började Three Amigos of Rational Software arbeta tillsammans för att utveckla Unified Modeling Language ( UML). Senare, tillsammans med Philippe Kruchten och Walker Royce (äldste son till Winston Royce ), har de lett ett framgångsrikt uppdrag att slå samman sina egna metoder, OMT , OOSE och Booch-metoden , med olika insikter och erfarenheter från andra branschledare i Rational Unified Process (RUP), en omfattande iterativ och inkrementell processguide och ramverk för att lära sig branschens bästa praxis för mjukvaruutveckling och projektledning. Sedan dess Unified Process- familjen blivit förmodligen den mest populära metodiken och referensmodellen för objektorienterad analys och design.

Översikt

Programvarans livscykel är vanligtvis uppdelad i stadier som går från abstrakta beskrivningar av problemet till design, sedan till kod och testning och slutligen till implementering. De tidigaste stadierna i denna process är analys och design. Analysfasen kallas också ofta för "kravinhämtning".

Vattenfallsmodellen . _

OOAD genomförs på ett iterativt och inkrementellt sätt, som formulerats av Unified Process .

I vissa tillvägagångssätt för mjukvaruutveckling - gemensamt kända som vattenfallsmodeller - är gränserna mellan varje steg menade att vara ganska stela och sekventiella. Termen "vattenfall" myntades för sådana metoder för att betyda att framstegen gick sekventiellt i endast en riktning, dvs när analysen var klar då och först då påbörjades designen och det var sällsynt (och ansågs vara en felkälla) när ett designproblem krävde en ändring av analysmodellen eller när en kodningsfråga krävde en ändring i design.

Alternativet till vattenfallsmodeller är iterativa modeller. Denna distinktion populariserades av Barry Boehm i en mycket inflytelserik artikel om hans spiralmodell för iterativ mjukvaruutveckling. Med iterativa modeller är det möjligt att utföra arbete i olika stadier av modellen parallellt. Så det är till exempel möjligt – och ses inte som en felkälla – att arbeta med analys, design och till och med kod på samma dag och att ha problem från ett skede påverkan från ett annat. Tonvikten på iterativa modeller är att mjukvaruutveckling är en kunskapsintensiv process och att saker som analys inte riktigt kan förstås helt utan att förstå designproblem, att kodningsproblem kan påverka design, att testning kan ge information om hur koden eller t.o.m. designen bör modifieras osv.

Även om det är möjligt att göra objektorienterad utveckling med hjälp av en vattenfallsmodell, utvecklas i praktiken de flesta objektorienterade system med ett iterativt tillvägagångssätt. Som ett resultat av detta övervägs ofta "analys och design" i objektorienterade processer samtidigt.

Det objektorienterade paradigmet betonar modularitet och återanvändbarhet. Målet med ett objektorienterat tillvägagångssätt är att uppfylla "öppet-stängt-principen" . En modul är öppen om den stöder förlängning, eller om modulen tillhandahåller standardiserade sätt att lägga till nya beteenden eller beskriva nya tillstånd. I det objektorienterade paradigmet uppnås detta ofta genom att skapa en ny underklass till en befintlig klass. En modul stängs om den har ett väldefinierat stabilt gränssnitt som alla andra moduler måste använda och som begränsar interaktionen och potentiella fel som kan introduceras i en modul genom ändringar i en annan. I det objektorienterade paradigmet uppnås detta genom att definiera metoder som anropar tjänster på objekt. Metoder kan vara antingen offentliga eller privata, dvs vissa beteenden som är unika för objektet exponeras inte för andra objekt. Detta minskar en källa till många vanliga fel i datorprogrammering.

Programvarans livscykel är vanligtvis uppdelad i stadier som går från abstrakta beskrivningar av problemet till design, sedan till kod och testning och slutligen till implementering. De tidigaste stadierna i denna process är analys och design. Skillnaden mellan analys och design beskrivs ofta som "vad vs hur". I analys arbetar utvecklare med användare och domänexperter för att definiera vad systemet ska göra. Implementeringsdetaljer ska ignoreras till största delen eller helt (beroende på den specifika metoden) i denna fas. Målet med analysfasen är att skapa en funktionell modell av systemet oberoende av begränsningar såsom lämplig teknik. I objektorienterad analys görs detta vanligtvis via användningsfall och abstrakta definitioner av de viktigaste objekten. Den efterföljande designfasen förfinar analysmodellen och gör nödvändig teknik och andra implementeringsval. I objektorienterad design ligger tonvikten på att beskriva de olika objekten, deras data, beteende och interaktioner. Designmodellen bör ha alla detaljer som krävs så att programmerare kan implementera designen i kod.

Objektorienterad analys

Syftet med varje analysaktivitet i mjukvarans livscykel är att skapa en modell av systemets funktionskrav som är oberoende av implementeringsbegränsningar.

Den största skillnaden mellan objektorienterad analys och andra former av analys är att vi genom det objektorienterade tillvägagångssättet organiserar krav kring objekt, som integrerar både beteenden (processer) och tillstånd (data) modellerade efter verkliga objekt som systemet interagerar med. I andra eller traditionella analysmetoder betraktas de två aspekterna: processer och data separat. Till exempel kan data modelleras av ER-diagram och beteenden av flödesscheman eller strukturdiagram .

Vanliga modeller som används i OOA är användningsfall och objektmodeller . Användningsfall beskriver scenarier för standarddomänfunktioner som systemet måste utföra. Objektmodeller beskriver namn, klassrelationer (t.ex. Circle är en underklass till Shape), operationer och egenskaper för huvudobjekten. Mockups eller prototyper för användargränssnitt kan också skapas för att underlätta förståelsen.

Objektorienterad design

Under objektorienterad design (OOD) tillämpar en utvecklare implementeringsbegränsningar på den konceptuella modellen som produceras i objektorienterad analys. Sådana begränsningar kan inkludera hårdvaru- och mjukvaruplattformar , prestandakrav, ihållande lagring och transaktioner, systemets användbarhet och begränsningar av budgetar och tid. Begrepp i analysmodellen som är teknikoberoende, kartläggs på implementerande klasser och gränssnitt vilket resulterar i en modell av lösningsdomänen, dvs en detaljerad beskrivning av hur systemet ska byggas på konkreta teknologier.

Viktiga ämnen under OOD inkluderar även design av mjukvaruarkitekturer genom att tillämpa arkitektoniska mönster och designmönster med de objektorienterade designprinciperna.

Objektorienterad modellering

Objektorienterad modellering (OOM) är ett vanligt tillvägagångssätt för att modellera applikationer, system och affärsdomäner genom att använda det objektorienterade paradigmet under hela utvecklingens livscykler . OOM är en huvudteknik som ofta används av både OOD- och OOA-aktiviteter inom modern mjukvaruteknik.

Objektorienterad modellering delas vanligtvis in i två aspekter av arbetet: modellering av dynamiska beteenden som affärsprocesser och användningsfall , och modellering av statiska strukturer som klasser och komponenter. OOA och OOD är de två distinkta abstrakta nivåerna (dvs analysnivån och designnivån) under OOM. Unified Modeling Language (UML) och SysML är de två populära internationella standardspråken som används för objektorienterad modellering.

Fördelarna med OOM är:

Effektiv och effektiv kommunikation

Användare har vanligtvis svårt att förstå heltäckande dokument och programmeringsspråkskoder väl. Visuella modelldiagram kan vara mer begripliga och kan tillåta användare och intressenter att ge utvecklare feedback om lämpliga krav och struktur i systemet. Ett centralt mål med det objektorienterade tillvägagångssättet är att minska det "semantiska gapet" mellan systemet och den verkliga världen, och att få systemet att konstrueras med terminologi som är nästan densamma som intressenterna använder i vardagen. Objektorienterad modellering är ett viktigt verktyg för att underlätta detta.

Användbar och stabil abstraktion

Modellering hjälper kodning. Ett mål med de flesta moderna mjukvarumetoder är att först ta itu med "vad"-frågor och sedan ta upp "hur"-frågor, dvs. först bestämma den funktionalitet som systemet ska tillhandahålla utan hänsyn till implementeringsbegränsningar, och sedan överväga hur man gör specifika lösningar på dessa abstrakta krav, och förfina dem till detaljerade konstruktioner och koder genom begränsningar som teknik och budget. Objektorienterad modellering möjliggör detta genom att producera abstrakta och tillgängliga beskrivningar av både systemkrav och design, dvs modeller som definierar deras väsentliga strukturer och beteenden som processer och objekt, som är viktiga och värdefulla utvecklingstillgångar med högre abstraktionsnivåer över konkret och komplex källkod .

Se även

Vidare läsning

Grady Booch . "Objektorienterad analys och design med applikationer, 3:e upplagan": http://www.informit.com/store/product.aspx?isbn=020189551X Addison-Wesley 2007.
Rebecca Wirfs-Brock , Brian Wilkerson, Lauren Wiener. Designa objektorienterad programvara . Prentice Hall, 1990. [ En jordnära introduktion till objektorienterad programmering och design. ]
A Theory of Object-Oriented Design : Byggstenarna i OOD och beteckningar för att representera dem (med fokus på designmönster.)
Martin Fowler . Analysmönster: Återanvändbara objektmodeller . Addison-Wesley, 1997. [ En introduktion till objektorienterad analys med konceptuella modeller ]
Bertrand Meyer . Objektorienterad mjukvarukonstruktion . Prentice Hall, 1997
Craig Larman . Tillämpa UML och mönster – Introduktion till OOA/D & Iterativ utveckling . Prentice Hall PTR, 3:e uppl. 2005.,mnnm,n,nnn
Setrag Khoshafian. Objektorientering .
Ulrich Norbisrath, Albert Zündorf, Ruben Jubeh. Berättelsedriven modellering . Amazon Createspace. sid. 333., 2013. ISBN 9781483949253 .

externa länkar

Artikel Objektorienterad analys och design med UML och RUP en översikt (även om CRC-kort).
Tillämpa UML – Handledning för objektorienterad analys och design
OOAD & UML-resurswebbplats och forum – Objektorienterad analys och design med UML .
Programvarubehovsanalys med UML- artikel av Dhiraj Shetty.
Artikel Objektorienterad analys i den verkliga världen