Modelul compozit oferă o reprezentare a ierarhiilor parțiale întregi, combinând obiecte în structuri de copaci.
Problema. Foarte adesea este nevoie să se creeze componente mici (primitive), să fie combinate în componente mai mari (containere), componente mai mari pentru conectarea la componente mari, componente mari la componente uriașe etc. În același timp, clienții trebuie să facă distincția între componentele primitive și componentele - containere, lucrați cu ei în moduri diferite. Acest lucru complică aplicația. Modelul Compozitor vă permite să eliminați această diferență, poate fi utilizat în următoarele cazuri:
q este necesar să se construiască o ierarhie a obiectelor formularului întreg-număr;
q este necesară unificarea utilizării obiectelor compozite și individuale.
Soluția. Elementul cheie al soluției este componenta clasei abstracte, care este atât primitivă cât și container. În el sunt declarate:
q Operarea abstractă a lucrării primitive ();
q operațiile abstracte ale containerului - gestionarea primitivelor descendente Add (Component) și Delete (Component), precum și accesul la descendentul Receive Child ().
Componenta structurală a modelului Structura este prezentată în Fig. 12.51.
Fig. 12.51. Componenta structurală a modelului Linker
Se poate observa din figură că o compoziție recursivă este organizată folosind modelul.
Clasă Componenta este un element simplu de copac, clasa Composer este un element recursiv, iar clasa List este elementul final al arborelui. Clasa Component servește ca părinte a clasei Sheet și Composer. Rețineți că clasa Composer este un ansamblu de părți componente - exemple ale clasei Componentă (astfel se specifică recursiunea).
Clienții utilizează interfața Componentă pentru a interacționa cu obiectele de copac. Dacă cererea clientului este un obiect de listă, atunci acesta procesează cererea. Dacă destinatarul este un obiect compus linker, acesta redirecționează cererea către copiii săi, efectuând eventual acțiuni suplimentare înainte sau după redirecționare.
Modelul modelului este prezentat în Fig. 12.52, unde se arată că are trei setări - component, linker și foaie.
Modelul aplicației grafice este ilustrat în Fig. 12.53.
Fig. 12.52. Desemnarea modelului Compozitor
Fig. 12.53. Personalizarea modelului compozitorului
În acest caz, operația principală a aplicației este operația Draw (). Se înțelege că o astfel de operație este inclusă în fiecare dintre clasele plug-in, adică clasele de elemente de desen, dreptunghi și grafic. Operațiile Draw () trebuie să înlocuiască operațiile Work () din clasele de model.
Modelul de comandă efectuează conversia solicitării către un obiect, furnizând:
q parametrizarea clienților cu cereri diferite;
q plasarea interogărilor în coada de așteptare și înregistrarea acestora;
q operațiuni de anulare a asistenței.
Problema. Destul de des este necesar să se trimită o cerere fără a se cunoaște care operațiune a fost solicitată și cine este destinatarul cererii. În aceste cazuri, trebuie să separați obiectul care a inițiat solicitarea de la un obiect care poate executa interogarea. Ca rezultat, interfața cu utilizatorul este foarte flexibilă - puteți asocia diverse elemente de meniu cu o funcție specifică, înlocuiți dinamic comenzile etc. Modelul Comanda este folosită în următoarele cazuri:
q obiectele sunt parametrizate de acțiune. În limbile de procedură, parametrizarea este efectuată utilizând funcția de apel invers, care este înregistrată pentru apelurile ulterioare. Pattern Comanda oferă o înlocuire orientată pe obiecte a funcțiilor de apel invers;
q este necesar să se asigure anularea operațiunilor. Acest lucru este posibil datorită stocării istoricului operațiunilor;
q este necesar să se înregistreze modificările de stare pentru a restabili sistemul în cazul unei defecțiuni de urgență;
q necesită crearea unor operații complexe care sunt construite pe baza operațiilor primitive.
Soluția. Elementul principal al soluției este o clasă abstractă. O comandă care oferă o operație abstractă, Perform (). Subclasele specifice din această clasă implementează operația Execute (). Acestea specifică perechea destinatar-acțiune. Destinatarul este stocat în variabila instanței din subclasă. O solicitare adresată destinatarului este trimisă în timpul executării unei operații specifice Efectuați ().
Componenta structurală a modelului Comanda este prezentată în Fig. 12.54. Clasele acestei structuri au următoarele atribuții:
q Comanda declară o interfață pentru operație;
q ConcrCommand definește relația dintre instanța clasei Recipient și acțiunea, implementează Execute (), invocând operația dorită a destinatarului;
q Clientul creează un obiect al clasei ConcrKommand și își stabilește destinatarul;
q inițiatorul cere comanda să îndeplinească cererea;
q Destinatarul poate efectua operațiile solicitate.
Fig. 12.54. Componenta structurală a echipei modelului
Ca comandă specifică, puteți utiliza comanda Deschidere, comanda Paste. Initiatorul poate fi elementul de meniu, iar destinatarul poate fi Document.
Obiectele din acest model realizează următoarele interacțiuni:
q clientul creează un obiect al clasei Conccrcommand și își stabilește destinatarul;
q Obiect al clasei Initiatorul salveaza obiectul clasei Conccrcommand;
q inițiatorul apelează operația Execute () pe obiectul de comandă Conccrcomm;
q Un obiect al clasei ConccrKommand solicită operarea destinatarului să execute interogarea.
Rezultate. Aplicarea unui model Comanda are următoarele rezultate:
q obiectul care solicită operația este separat de obiectul care poate executa cererea;
q obiectele de comandă sunt obiecte pline. Acestea pot fi utilizate și extinse în mod obișnuit;
q Comenzile compuse sunt ușor asamblate din comenzi simple;
q sunt adăugate cu ușurință comenzi noi (nu este nevoie să modificați clasele existente).
Desemnarea modelului Comanda este prezentată în Fig. 12.55, unde se arată că are patru setări - client, comandă, inițiator și receptor.
Fig. 12.55. Desemnarea modelului
Modelul aplicației cu un meniu grafic este ilustrat în Fig. 12,56.
Fig. 12,56. Setarea comenzii modelului
Destul de des, înainte de a decide să comande software, organizația desfășoară modelarea afacerilor. Obiectivele modelării afacerilor:
q să afișeze structura și procesele organizației;
q asigurați o înțelegere clară, integrată și, cel mai important, aceeași înțelegere a nevoilor organizației de către angajați și dezvoltatori viitori de software;
q formularea cerințelor reale pentru software-ul activităților organizației.
Pentru a atinge aceste obiective, se dezvoltă două modele: Q Model de caz; ci un model de obiect de afaceri.
Modelul de afaceri definește o reprezentare externă a proceselor de afaceri ale organizației (în ceea ce privește mediul extern - clienți și parteneri).
După cum se arată în Fig. 12.57, Modelul de utilizare a Casei de Utilizare este construit folosind elemente Business Business Case și Elemente de Afaceri - o extensie simplă a instrumentelor utilizate în diagramele de Utilizare obișnuită.
Fig. 12.57. Fragmentul modelului de business Utilizarea cazului pentru aeroport
Actorii de afaceri definesc entități externe și persoane cu care afacerea interacționează. Un actor de afaceri este o persoană, dar un sistem informatic care interacționează cu afacerile poate juca, de asemenea, rolul unui astfel de actor.
Elementele de afaceri ale cazului de utilizare descriu diferite fluxuri de afaceri. Fluxurile de lucru din elementele de afaceri ale Casei de Utilizare sunt descrise de obicei prin diagrame de activitate.
Modelul obiect de activitate reflectă reprezentarea internă a proceselor de afaceri ale organizației (în ceea ce privește angajații acesteia).
După cum se arată în Fig. 12.58, modelul de obiect de afaceri este construit cu ajutorul oamenilor de afaceri și al entităților de afaceri - cursuri cu stereotipuri speciale. Aceste clase au desemnări grafice speciale.
Fig. 12,58. Fragmentul obiectului modelului de afaceri al aeroportului
Un lucrător de afaceri este o abstractizare a unei persoane care acționează în afaceri. Entitățile de afaceri sunt "obiecte" care sunt prelucrate sau utilizate de angajații afacerii, așa cum execută elementul de utilizare a Casei de Utilizare. De exemplu, o entitate comercială este un document sau o parte esențială a unui produs. De fapt, modelul de obiect de afaceri este afișat utilizând diagrame de clasă.
1. Explicați două abordări pentru modelarea comportamentului sistemului. Explicați meritele și dezavantajele fiecăreia dintre aceste abordări.
2. Descrieți nodurile și arcele diagramei de diagramă de stare. Care este scopul acestei diagrame?
3. Cum se afișează acțiunile în starea diagramei de stare?
4. Cum sunt prezentate tranzițiile condiționale între stări?
5. Cum sunt definite stările imbricate în diagramele diagramelor de stare?
6. Explicați conceptul de substituire istorică.
7. Descrieți mijloacele și capabilitățile diagramei de activitate.
8. Când nu ar trebui să se utilizeze o diagramă de activitate?
9. Ce instrumente de diagramă de activități vă permit să afișați acțiuni paralele?
10. De ce este inclus piscina în diagrama de activități?
11. Care este numele obiectului din diagrama de cooperare?
12. Explicați sintaxa reprezentării proprietății în diagrama de colaborare.
13. Ce stereotipuri de vizibilitate sunt folosite în diagrama de cooperare? Explicați semnificația lor.
14. În ce formă sunt mesajele scrise în UML? Explicați semnificația mesajului.
15. În ce sens sunt mesajele și acțiunile? Specificați tipurile de acțiuni.
16. Cum diferă fluxul procedural de un flux de mesaje asincron?
17. Cum se indică repetarea mesajelor?
18. Cum se arată ramificația mesajelor?
19. Ce este comun în diagrama de secvențe și diagrama de cooperare? Cum diferă unele de altele?
20. Cum se afișează ordinea de transfer a mesajului în diagrama succesivă?
21. Când este mai convenabil să folosiți diagrame de secvențe?
22. Ce elemente comportă schema de utilizare a casetei?
23. Ce relații sunt permise între elementele diagramei Casei de utilizare?
24. Pentru ce sunt folosite diagramele Casei de Utilizare?
25. Care este diferența dintre includerea și extinderea în ceea ce privește managementul?
26. Care este scopul specificației elementului Use Case și modul în care este formalizată?
27. Ce este scriptul de utilizare a Casei?
28. Cum este documentat raportul de incluziune?
29. Cum este documentat raportul de expansiune?
30. Care este ordinea construirii modelului de cerințe?
31. Care este scopul cooperării? Care sunt elementele constitutive ale acesteia?
32. Pot cooperative diferite să folosească aceleași clase? Justificați răspunsul.
33. Ce este un model?
34. Cum este modelul diferit de cooperare? Deci sunt similare?
35. Cum este descris modelul?
36. Ce trebuie să fac pentru a aplica modelul?
37. Care sunt obiectivele modelarea afacerilor?
38. Care sunt componentele modelului de afaceri? Cum arată aceste părți? Care este originalitatea lor?
Articole similare
Trimiteți-le prietenilor: