OOAD - Proiectare orientată pe obiecte - Tutorialspoint

Anunțuri

După faza de analiză, modelul conceptual este dezvoltat în continuare într-un model orientat pe obiecte, folosind proiectarea orientată pe obiecte (OOD). În OOD, conceptele independente de tehnologie din modelul de analiză sunt mapate pe clase de implementare, se identifică constrângerile și se proiectează interfețe, rezultând un model pentru domeniul de soluționare. Pe scurt, se construiește o descriere detaliată în care se specifică modul în care sistemul urmează să fie construit pe tehnologii concrete

Etapele pentru proiectarea orientată pe obiecte pot fi identificate astfel: –

Definirea contextului de sistemului
Proiectarea arhitecturii sistemului
Identificarea obiectelor din sistem
Construcția modelelor de proiectare
Specificarea interfețelor obiectelor

Proiectarea sistemului

Proiectare orientată pe obiecteorientată pe obiecte presupune definirea contextului unui sistem, urmată de proiectarea arhitecturii sistemului.

Context – Contextul unui sistem are o parte statică și una dinamică. Contextul static al sistemului este proiectat folosind o diagramă bloc simplă a întregului sistem, care este extinsă într-o ierarhie de subsisteme. Modelul subsistemului este reprezentat prin pachete UML. Contextul dinamic descrie modul în care sistemul interacționează cu mediul său. Acesta este modelat folosind diagrame de cazuri de utilizare.
Arhitectura sistemului – Arhitectura sistemului este proiectată pe baza contextului sistemului în conformitate cu principiile de proiectare arhitecturală, precum și cu cunoștințele din domeniu. De obicei, un sistem este compartimentat în straturi și fiecare strat este descompus pentru a forma subsistemele.

Decompoziția orientată pe obiecte

Decompoziția înseamnă împărțirea unui sistem complex mare într-o ierarhie de componente mai mici, cu complexitate mai mică, pe principiile „divide et impera”. Fiecare componentă majoră a sistemului se numește subsistem. Descompunerea orientată pe obiecte identifică obiectele autonome individuale dintr-un sistem și comunicarea dintre aceste obiecte.

Avantajele descompunerii sunt –

Componentele individuale sunt de o complexitate mai mică, deci mai ușor de înțeles și de gestionat.
Permite divizarea forței de muncă care are competențe specializate.
Permite ca subsistemele să fie înlocuite sau modificate fără a afecta alte subsisteme.

Identificarea concurenței

Concurența permite ca mai multe obiecte să primească evenimente în același timp și ca mai multe activități să fie executate simultan. Concurența este identificată și reprezentată în modelul dinamic.

Pentru a permite concurența, fiecărui element concurent i se atribuie un fir de control separat. În cazul în care concurența este la nivel de obiect, atunci două obiecte concurente primesc două fire de control diferite. Dacă două operații ale unui singur obiect sunt de natură concurentă, atunci acel obiect este împărțit între diferite fire de execuție.

Concurența este asociată cu probleme de integritate a datelor, blocaj și înfometare. Prin urmare, trebuie elaborată o strategie clară ori de câte ori este necesară concurența. În plus, concurența necesită să fie identificată chiar în etapa de proiectare și nu poate fi lăsată pentru etapa de implementare.

Identificarea modelelor

În timpul proiectării aplicațiilor, pentru anumite categorii de probleme se adoptă unele soluții general acceptate. Acestea sunt modelele de proiectare. Un model poate fi definit ca un set documentat de blocuri de construcție care pot fi utilizate în anumite tipuri de probleme de dezvoltare a aplicațiilor.

Câteva tipare de proiectare utilizate în mod obișnuit sunt: –

Tipare de fațadă
Tipare de separare model-vedere
Tipare de observator

Model view controller pattern
Model view controller pattern
Publish subscribe pattern
Proxy pattern

Controlul evenimentelor

În timpul proiectării sistemului, evenimentele care pot apărea în obiectele sistemului trebuie să fie identificate și tratate în mod corespunzător.

Un eveniment este o specificație a unui eveniment semnificativ care are o locație în timp și spațiu.

Există patru tipuri de evenimente care pot fi modelate, și anume –

Eveniment semnal – Un obiect cu nume aruncat de un obiect și prins de un alt obiect.
Eveniment apel – Un eveniment sincron care reprezintă expedierea unei operații.
Eveniment de timp – Un eveniment care reprezintă trecerea timpului.
Eveniment de schimbare – Un eveniment care reprezintă schimbarea stării.

Manipularea condițiilor limită

Faza de proiectare a sistemului trebuie să abordeze inițializarea și terminarea sistemului ca întreg, precum și a fiecărui subsistem. Diferitele aspecte care sunt documentate sunt următoarele –

Începutul sistemului, adică trecerea sistemului de la starea neinițializată la starea de echilibru.
Terminarea sistemului, adică, închiderea tuturor firelor de execuție, curățarea resurselor și a mesajelor care urmează să fie trimise.
Configurarea inițială a sistemului și reconfigurarea sistemului atunci când este necesar.
Prevederea eșecurilor sau a terminării nedorite a sistemului.

Condițiile limită sunt modelate folosind cazuri de utilizare a limitelor.

Proiectarea obiectelor

După ce a fost dezvoltată ierarhia subsistemelor, sunt identificate obiectele din sistem și sunt proiectate detaliile acestora. Aici, proiectantul detaliază strategia aleasă în timpul proiectării sistemului. Accentul se deplasează de la conceptele din domeniul aplicației către conceptele informatice. Obiectele identificate în timpul analizei sunt gravate pentru implementare cu scopul de a minimiza timpul de execuție, consumul de memorie și costul total.

Proiectarea obiectelor include următoarele faze –

Identificarea obiectelor
Reprezentarea obiectelor, adică, construirea modelelor de proiectare
Clasificarea operațiilor
Proiectarea algoritmilor
Proiectarea relațiilor
Implementarea controlului pentru interacțiunile externe
Pachetarea claselor și asociațiilor în module

Identificarea obiectelor

Prima etapă a proiectării obiectelor este identificarea obiectelor. Obiectele identificate în fazele de analiză orientată pe obiecte sunt grupate în clase și rafinate astfel încât să fie potrivite pentru implementarea efectivă.

Funcțiile acestei etape sunt –

Identificarea și rafinarea claselor din fiecare subsistem sau pachet
Definirea legăturilor și asociațiilor dintre clase
Proiectarea asociațiilor ierarhice dintre clase, adică, generalizarea/specializarea și moștenirile
Desenarea agregărilor

Reprezentarea obiectelor

După ce clasele sunt identificate, acestea trebuie să fie reprezentate folosind tehnici de modelare a obiectelor. Această etapă implică, în esență, construirea de diagrame UML.

Există două tipuri de modele de proiectare care trebuie produse –

Modele statice – Pentru a descrie structura statică a unui sistem folosind diagrame de clase și diagrame de obiecte.
Modele dinamice – Pentru a descrie structura dinamică a unui sistem și pentru a arăta interacțiunea dintre clase folosind diagrame de interacțiune și diagrame state-chart.

Clasificarea operațiilor

În această etapă, operațiile care urmează să fie efectuate asupra obiectelor sunt definite prin combinarea celor trei modele dezvoltate în faza OOA, și anume, modelul obiect, modelul dinamic și modelul funcțional. O operație specifică ce trebuie făcut și nu cum trebuie făcut.

Se realizează următoarele sarcini privind operațiile –

Se elaborează diagrama de tranziție de stări a fiecărui obiect din sistem.
Se definesc operațiile pentru evenimentele primite de obiecte.
Se identifică cazurile în care un eveniment declanșează alte evenimente în aceleași obiecte sau în obiecte diferite.
Se identifică suboperațiile din cadrul acțiunilor.
Acțiunile principale sunt extinse în diagrame de flux de date.

Proiectarea algoritmilor

Operațiile din obiecte sunt definite cu ajutorul algoritmilor. Un algoritm este o procedură etapizată care rezolvă problema stabilită într-o operație. Algoritmii se concentrează pe modul în care trebuie să se facă.

Pot exista mai mult de un algoritm corespunzător unei anumite operații. Odată ce sunt identificați algoritmii alternativi, se selectează algoritmul optim pentru domeniul problemei date. Parametrii de măsurare pentru alegerea algoritmului optim sunt –

Complexitatea computațională – Complexitatea determină eficiența unui algoritm în ceea ce privește timpul de calcul și necesarul de memorie.
Flexibilitatea – Flexibilitatea determină dacă algoritmul ales poate fi implementat în mod corespunzător, fără pierderea adecvării în diverse medii.
Înțelegere – Aceasta determină dacă algoritmul ales este ușor de înțeles și de implementat.

Proiectarea relațiilor

Strategia de implementare a relațiilor trebuie să fie creionată în timpul fazei de proiectare a obiectului. Principalele relații care sunt abordate cuprind asocierile, agregările și moștenirile.

Proiectantul trebuie să facă următoarele cu privire la asocieri –

Identificați dacă o asociere este unidirecțională sau bidirecțională.
Analizați traseul asociațiilor și actualizați-le dacă este necesar.
Implementați asociațiile ca un obiect distinct, în cazul relațiilor de tip mulți-la-mulți; sau ca o legătură cu un alt obiect în cazul relațiilor unu-la-unu sau unu-la-mulți.

În ceea ce privește moștenirile, proiectantul ar trebui să facă următoarele –

Ajustați clasele și asociațiile lor.
Identificați clasele abstracte.
Faceți prevederi astfel încât comportamentele să fie partajate atunci când este necesar.

Implementarea controlului

Proiectantul de obiecte poate încorpora rafinamente în strategia modelului diagramei de stare. În proiectarea sistemului, se realizează o strategie de bază pentru realizarea modelului dinamic. În timpul proiectării obiectului, această strategie este înfrumusețată corespunzător pentru o implementare adecvată.

Abordările pentru implementarea modelului dinamic sunt –

Reprezentarea stării ca o locație în cadrul unui program – Aceasta este abordarea tradițională bazată pe proceduri, prin care locația controlului definește starea programului. O mașină cu stări finite poate fi implementată ca un program. O tranziție formează o instrucțiune de intrare, calea principală de control formează secvența de instrucțiuni, ramurile formează condițiile, iar căile de întoarcere formează buclele sau iterațiile.
Motor de mașini cu stări – Această abordare reprezintă direct o mașină cu stări prin intermediul unei clase de motoare de mașini cu stări. Această clasă execută mașina de stări printr-un set de tranziții și acțiuni furnizate de aplicație.
Control ca sarcini concurente – În această abordare, un obiect este implementat ca o sarcină în limbajul de programare sau în sistemul de operare. Aici, un eveniment este implementat ca un apel intertasking. Aceasta păstrează concurența inerentă a obiectelor reale.

Pachetarea claselor

În orice proiect mare, este importantă compartimentarea meticuloasă a unei implementări în module sau pachete. În timpul proiectării obiectelor, clasele și obiectele sunt grupate în pachete pentru a permite mai multor grupuri să lucreze în cooperare la un proiect.

Diferitele aspecte ale împachetării sunt: –

Ascunderea informațiilor interne de ochii din exterior – Permite ca o clasă să fie privită ca o „cutie neagră” și permite ca implementarea clasei să fie schimbată fără a fi nevoie ca vreun client al clasei să modifice codul.
Coerența elementelor – Un element, cum ar fi o clasă, o operație sau un modul, este coerent dacă este organizat pe un plan consecvent și dacă toate părțile sale sunt legate în mod intrinsec astfel încât să servească un scop comun.
Construcția modulelor fizice – Următoarele linii directoare ajută la construirea modulelor fizice –
- Classele dintr-un modul trebuie să reprezinte lucruri sau componente similare în același obiect compozit.
- Classele strâns conectate ar trebui să se afle în același modul.
- Classele neconectate sau slab conectate ar trebui să fie plasate în module separate.
- Modulele ar trebui să aibă o bună coeziune, și anume, o cooperare ridicată între componentele sale.
- Un modul ar trebui să aibă o cuplare redusă cu alte module, adică interacțiunea sau interdependența dintre module ar trebui să fie minimă.

Optimizarea proiectării

Modelul de analiză captează informațiile logice despre sistem, în timp ce modelul de proiectare adaugă detalii pentru a sprijini accesul eficient la informații. Înainte ca un proiect să fie implementat, acesta ar trebui să fie optimizat astfel încât să facă implementarea mai eficientă. Scopul optimizării este de a minimiza costul în termeni de timp, spațiu și alți parametri.

Cu toate acestea, optimizarea proiectării nu ar trebui să fie excesivă, deoarece ușurința implementării, mentenabilitatea și extensibilitatea sunt, de asemenea, preocupări importante. Se observă adesea că o proiectare perfect optimizată este mai eficientă, dar mai puțin lizibilă și reutilizabilă. Așadar, proiectantul trebuie să găsească un echilibru între cele două.

Diversele lucruri care pot fi făcute pentru optimizarea proiectării sunt –

Adaugarea de asociații redundante
Omiterea de asociații neutilizabile
Optimizarea algoritmilor
Salvarea atributelor derivate pentru a evita recalcularea expresiilor complexe

Agregarea de asociații redundante

În timpul optimizării proiectării, se verifică dacă derivarea de noi asociații poate reduce costurile de acces. Deși este posibil ca aceste asociații redundante să nu adauge nicio informație, ele pot crește eficiența modelului general.

Admiterea de asociații neutilizabile

Prezența unui număr prea mare de asociații poate face ca un sistem să devină indescifrabil și, prin urmare, să reducă eficiența generală a sistemului. Astfel, în timpul optimizării, toate asociațiile neutilizabile sunt eliminate.

Optimizarea algoritmilor

În sistemele orientate pe obiecte, optimizarea structurii de date și a algoritmilor se face într-o manieră colaborativă. Odată ce designul clasei este stabilit, operațiile și algoritmii trebuie să fie optimizați.

Optimizarea algoritmilor se obține prin –

Rezolvarea ordinii sarcinilor de calcul
Întoarcerea ordinii de execuție a buclelor față de cea prevăzută în modelul funcțional

Înlăturarea căilor moarte în cadrul algoritmului

Salvarea și stocarea atributelor derivate

Atributele derivate sunt acele atribute ale căror valori sunt calculate în funcție de alte atribute (atribute de bază). Recalcularea valorilor atributelor derivate de fiecare dată când acestea sunt necesare este o procedură care necesită mult timp. Pentru a evita acest lucru, valorile pot fi calculate și stocate în formele lor calculate.

Dar, acest lucru poate crea anomalii de actualizare, adică o modificare a valorilor atributelor de bază fără o modificare corespunzătoare a valorilor atributelor derivate. Pentru a evita acest lucru, se iau următoarele măsuri –

Cu fiecare actualizare a valorii atributului de bază, atributul derivat este, de asemenea, recalculat.
Toate atributele derivate sunt recalculate și actualizate periodic într-un grup, mai degrabă decât după fiecare actualizare.

Documentația de proiectare

Documentația este o parte esențială a oricărui proces de dezvoltare de software care înregistrează procedura de realizare a software-ului. Deciziile de proiectare trebuie să fie documentate pentru orice sistem software non-trivial pentru a transmite proiectarea altora.

Domenii de utilizare

Deși este un produs secundar, o bună documentație este indispensabilă, în special în următoarele domenii –

În proiectarea unui software care este dezvoltat de mai mulți dezvoltatori
În strategiile iterative de dezvoltare software
În dezvoltarea versiunilor ulterioare ale unui proiect software
Pentru evaluarea unui software
Pentru găsirea condițiilor și zonelor de testare
Pentru întreținerea software-ului.

Contenit

O documentație benefică ar trebui să includă, în esență, următorul conținut –

Arhitectura sistemului la nivel înalt – Diagrame de proces și diagrame de module
Abstracțiuni și mecanisme cheie – Diagrame de clase și diagrame de obiecte.
Scenarii care ilustrează comportamentul principalelor aspecte – Diagrame comportamentale

Caracteristici

Caracteristicile unei bune documentații sunt –

Concise și, în același timp, lipsite de ambiguitate, coerentă și completă
Tracesibilă la specificațiile cerințelor sistemului
Bine structurată
Diagramatică în loc de descriptivă