Clasa de proiectare reprezintă abstractizarea uneia sau mai multor clase în implementarea sistemului; Obiectul exact la care corespunde depinde de limba de implementare. De exemplu, într-un limbaj orientat pe obiecte, cum ar fi C ++, clasa de proiectare poate corespunde unei clase simple. În limba Ada, o clasă poate corespunde unui tip special definit în partea vizibilă a pachetului.
Clasele definesc obiecte. care, la rândul lor, pun în aplicare cazurile de utilizare. Clasa se bazează pe cerințele impuse de implementarea cazurilor de utilizare pentru obiectele de sistem, precum și pe toate modelele obiect dezvoltate anterior.
Succesul clasei depinde în mare măsură de mediul de implementare. De exemplu, dimensiunea corectă a unei clase și a obiectelor depinde de limba de programare. Ceea ce pare potrivit în limba Iadului ar putea să nu aibă succes în Smalltalk. Clasele ar trebui să fie cartografiate la un anumit fenomen în limba de implementare, iar structura clasei trebuie să fie astfel încât rezultatul să fie un cod bun.
Deși caracteristicile limbii de implementare afectează modelul de proiectare, trebuie să vă asigurați că structura clasei este ușor de înțeles și de modificat. Clasa ar trebui dezvoltată ca și cum ați avea cursuri și încapsulare, deși nu sunt acceptate în limba de implementare.
Singurul mod în care obiectele pot accesa sau afecta atributele sau relațiile unui obiect dat este de a profita de operațiile sale. Operațiile unui obiect sunt determinate de clasa sa. Operațiile vă permit să efectuați un comportament specific care poate afecta atributele și relațiile obiectului și poate cauza executarea altor operații. Operația corespunde unei funcții a membrilor în C ++ și unei funcții sau proceduri în limba Ada. Comportamentul pe care îl atribuie unui obiect depinde de rolul său în implementările implementării cazului de utilizare.
În specificația de funcționare, parametrii sunt parametri formali. Fiecare parametru are un nume și un tip. Pentru a specifica operațiile și parametrii acestora, puteți utiliza sintaxa și semantica limbii de implementare, astfel încât aceste operații și parametri vor fi deja specificate în limba de implementare până la începerea codificării.
În sistemul unei mașini de reciclare, obiectele din clasa Prime Receipt monitorizează câte elemente dintr-un anumit tip pe care le-a pus clientul. Comportamentul obiectului Receipt Basis include creșterea numărului de obiecte returnate. Această acțiune este efectuată de operația insertItem. care primește o referință la obiectul pus.
Când specificați operațiile, folosiți sintaxa și semantica limbii de implementare.
Operația aproape întotdeauna specifică comportamentul obiectului. O operație poate specifica și comportamentul unei clase - în acest caz se numește o operație de clasă. Acest lucru poate fi modelat în UML prin specificarea domeniului corespunzător al operației.
Operațiunea poate avea următoarele scopuri:
- Public disponibil. Operația este văzută de toate elementele modelului, cu excepția clasei în sine.
- Secure. operația este văzută doar de clasa însăși, de subclasele sale și de prietenii săi (în diferite limbi pot exista nume diferite)
- Privat. Operațiunea este văzută doar de clasa însăși și de prietenii săi
- Nerealizare. Operația este vizibilă numai în cadrul clasei.
Un domeniu de aplicare public ar trebui utilizat în cazuri excepționale. Numai atunci când operația este necesară pentru o altă clasă.
Domeniul protejat ar trebui utilizat în mod implicit; protejează operațiunea de a fi folosită de clasele externe, ceea ce facilitează legarea slabă și încapsularea comportamentului.
Un domeniu de aplicare privat ar trebui să fie utilizat atunci când doriți să împiedicați moștenirea unei operații de clase derivate. Acest lucru vă permite să separați clasele derivate de clasele de bază și să petreceți mai puțin efort pentru a elimina sau a elimina operațiile moștenite neutilizate.
Domeniul de aplicare este cel mai restrictiv; Se folosește în cazurile în care operația însăși poate fi utilizată numai de clasa însăși. Acesta este un fel de domeniu privat. care este destul de suficient în majoritatea cazurilor.
Un obiect poate răspunde la un mesaj în moduri diferite, în funcție de starea în care se află; Comportamentul obiectului ca funcție a stării este determinat pe diagrama de stare asociată. Pentru fiecare stare posibilă a obiectului, diagrama de stare descrie ce mesaje poate primi obiectul, ce operații vor fi efectuate și în ce stare se va muta obiectul. Pentru mai multe informații, consultați Tehnologie: diagrama de stare.
Cooperarea este un set dinamic al interacțiunilor obiect în care obiectele schimbă informații prin trimiterea de mesaje unul la celălalt. Mesajul este trimis direct către Smalltalk și sunând la subrutina din Ada. Mesajul este trimis către obiectul care primește operația internă. Mesajul indică numele operației care trebuie efectuată și parametrii necesari. La trimiterea mesajelor pentru toți parametrii, sunt furnizați parametrii actuali (valorile parametrilor formali).
Redirecționarea mesajelor între obiecte în implementarea cazului de utilizare Comutarea comenzii între obiecte ca operații de pornire este descrisă în diagramele de interacțiune. Pentru informații despre aceste diagrame, consultați Tehnologia: Diagrama secvențelor și tehnologia: Diagrama de comunicare.
Un atribut este o proprietate numită a unui obiect. Un nume de atribut este un substantiv care descrie rolul unui atribut față de un obiect. Un atribut poate avea o valoare inițială atunci când creează un obiect.
Simulați atributele numai dacă simplifică înțelegerea obiectului. Pentru a modela o proprietate obiect ca atribut urmează doar dacă această proprietate este numai pentru acest obiect. În caz contrar, trebuie să modelați proprietatea cu o relație de asociere sau de agregare cu clasa ale cărei obiecte reprezintă această proprietate.
Nu este întotdeauna ușor să se decidă imediat dacă conceptul trebuie modelat ca un obiect separat sau ca atribut al unui alt obiect. Adăugarea de obiecte inutile la model supraîncărcă documentația și crește cantitatea de lucru. Din acest motiv, trebuie să stabiliți criterii pentru a determina importanța conceptului pentru sistem.
- Readiness. Alegerea dintre un obiect și un atribut nu este determinată de importanța conceptului în viața reală, ci de necesitatea accesării acestuia în timpul implementării cazului de utilizare. Dacă apare frecvent accesul la element, modelați-l ca obiect.
- Izolarea la timpul de execuție. Atunci când cazurile de utilizare sunt efectuate ca obiecte, conceptele de model sunt tratate separat.
- Conexiuni cu alte concepte. Conceptele modelului sunt strâns legate de alte concepte și nu sunt folosite separat, dar întotdeauna indirect prin obiect, ca atribut al obiectului.
- Cerințe din relație. Dacă, din anumite motive, trebuie să stabiliți relații cu un element din două direcții, verificați-l din nou pentru a afla dacă ar trebui să fie un obiect separat. Două obiecte nu pot asocia aceeași instanță a tipului de atribut.
- Frecvența apariției. Dacă elementul există numai în timpul execuției, nu îl modelați ca obiect. Modelați-l ca un atribut al obiectului care efectuează comportamentul dorit sau pur și simplu specificați-l în descrierea obiectului corespunzător.
- Complexitatea. În cazul în care obiectul este prea dificil din cauza atributele sale, atribute o parte a muta la alte obiecte. Uită-te, totuși, că nu sunt prea multe astfel de obiecte. Pe de altă parte, elementele pot fi foarte simple. De exemplu, atributele de categorie includ 1) elemente sunt destul de simple pentru a fi sprijinite direct mai simple tipuri în limbajul de implementare, cum ar fi numere întregi în C ++, și 2), elemente care sunt suficient de simplu pentru a fi puse în aplicare cu independent de componente aplicație mediu de implementare, de ex , String în C ++ și Smalltalk-80.
În diferite sisteme, conceptul poate fi modelat diferit. Într-un sistem, conceptul poate fi atât de important încât este mai bine modelat ca obiect. În cealaltă, poate juca un rol secundar și este mai bine să îl modelăm ca atribut al obiectului.
De exemplu, un sistem conceput pentru o companie aeriană trebuie să sprijine plecările.
Un sistem care să sprijine zborurile de plecare. Permiteți personalului din aeroport să solicite un sistem care să permită zboruri de plecare Pentru fiecare plecare este necesar să se determine timpul de plecare, zborul și destinația. Acest lucru poate fi modelat ca obiect al clasei Plecarea cu atributele timpului de plecare. zbor și destinație.
Dacă sistemul este conceput pentru o agenție de turism, situația poate fi oarecum diferită.
Destinațiile zborurilor formează un obiect propriu - Destinație.
Ora de plecare, zbor și destinație, desigur, va fi totuși necesară. Cu toate acestea, cerințele vor fi diferite, deoarece agenția de turism este interesată de un zbor către destinația specificată. Prin urmare, trebuie să creați un obiect separat pentru destinație. Obiecte Plecare și Destinație. bineînțeles, ar trebui să fie conștienți unul de altul, pentru care este creată o asociație între clasele lor.
Atunci când alegeți atributele care ar trebui definite în clasă, trebuie să luați în considerare importanța anumitor concepte. Atribute ale clasei Mașină. fără îndoială, vor fi diferite, în funcție de faptul dacă obiectele sale fac parte din sistemul de înregistrare a vehiculelor sau din sistemul de mașini.
În cele din urmă, regulile care definesc ce trebuie reprezentate ca obiecte și care - ca atribute, nu sunt absolute. Teoretic, totul poate fi modelat ca obiecte, dar acest lucru este prea împovărătoare. O regulă simplă este aceea de a trata un obiect ca ceva care la un anumit moment este folosit fără referire la alte obiecte. În plus, nu este necesar să modelați fiecare proprietate a unui obiect cu atributul - este suficient să simulați numai acele proprietăți care sunt necesare pentru înțelegerea obiectului. Nu este necesar să modelați detaliile care sunt prea strâns legate de implementare: acestea ar trebui lăsate de dezvoltator.
Atributele de clasă
Atributul aproape întotdeauna specifică proprietățile obiectului. Un atribut poate specifica și proprietățile unei clase - în acest caz se numește atribut de clasă. Acest lucru poate fi modelat în UML prin specificarea domeniului corespunzător al atributului.
Un obiect poate încapsula un element a cărui valoare se poate schimba independent de comportamentul obiectului. Poate fi ceva care este de fapt un element extern, dar nu este modelat ca subiect. De exemplu, lăsați limitele sistemului să fie alese astfel încât echipamentul senzorilor să se încadreze în limitele lor. Senzorul poate fi apoi încapsulat într-un obiect, astfel încât valoarea măsurată de acesta să genereze un atribut. După aceasta, această valoare se poate schimba continuu sau periodic, indiferent dacă acest obiect afectează orice alt obiect din sistem.
Termometrul poate fi modelat ca obiect; obiectul va avea un atribut corespunzător temperaturii și valoarea sa se va schimba ca răspuns la o modificare a temperaturii ambiante. Alte obiecte pot interoga temperatura curentă prin efectuarea unei operații pe obiectul termometrului.
Valoarea temperaturii atributului variază spontan în obiectul Termometru.
Încă puteți simula o valoare încapsulată care se schimbă în acest fel ca atribut normal, dar trebuie să specificați în clasa obiect că se schimbă în mod spontan.
Atributul poate avea următoarele domenii:
- Public disponibil. un atribut este văzut atât din interiorul cât și din exteriorul pachetului care conține clasa.
- Secure. atributul este văzut doar de clasa însăși, subclasele și prietenii săi (în diferite limbi pot exista nume diferite)
- Privat. atribui numai clasei în sine și prietenilor ei
- Nerealizare. numai clasa în sine vede atributul.
Domeniul de protecție ar trebui utilizat în mod implicit; protejează atributul de utilizarea de către clasele externe, ceea ce facilitează comportamentul slab legat și încapsulat.
domeniu de aplicare privat ar trebui să fie utilizat atunci când doriți să împiedicați moștenirea atributelor claselor derivate. Acest lucru permite clase să se separe de bază și să petreacă mai puțin efort pentru a elimina sau de a exclude atributele moștenite neutilizate derivate.
Domeniul de aplicare este cel mai restrictiv; Se folosește în cazul în care atributul poate fi utilizat numai de clasa însăși. Acesta este un fel de domeniu privat. care este destul de suficient în majoritatea cazurilor.
Unele clase pot reprezenta abstracții complexe și au o structură complexă. În timpul modelării clasei, designerul poate prezenta elementele sale participante interne și interrelațiile lor pentru a se asigura că implementatorul implementează corect cooperațiile din această clasă.
În UML 2.0, clasele sunt definite ca clase structurate. care poate avea o structură internă și porturi. Clasele pot fi extinse într-o serie de piese conectate, permițând, de asemenea, descompunerea. O clasă poate fi încapsulată prin transmiterea comunicărilor din surse externe la porturile de o conexiune la distanță, supunându interfața declarată.
Astfel, pe lângă utilizarea diagramelor de clasă pentru a reprezenta relațiile de clasă (de exemplu, asocieri, compoziții și agregări) și atribute, proiectantul poate folosi o diagramă structurală compusă. Această diagramă permite dezvoltatorului să demonstreze modul în care instanțele părților interne își joacă rolurile într-o instanță a unei clase date.
Pentru mai multe informații despre acest subiect și exemple de diagrame ale structurilor compozite, consultați Concept: Structured Class.
Articole similare
Trimiteți-le prietenilor: