Curs: construirea unui model de obiecte. Construirea unui model obiect al domeniului de subiect „organizarea proceselor cluburilor sportive” folosind limbajul de modelare UML

Modelul obiect al unei afaceri existente arată cum și datorită ce precedente sunt implementate. Acest model dezvăluie structura internă a unei afaceri, și anume: ce tipuri de resurse sunt folosite pentru implementarea precedentelor și cum interacționează acestea. Descrierea modelului obiect se bazează pe conceptul de „obiect”. Obiectele reprezintă participanți la proces și diverse tipuri de entități (produse finite, comandă etc.).

Obiecte de interfață ale procesului de afaceri studiat:

• 1. Manager serviciu clienți. Atribute: nume complet, funcție, salariu. Responsabilități: interacționează cu clienții, plasează comenzi, acceptă plăți de la clienți pentru comenzi.
• 2. Depozitar responsabil financiar. Atribute: nume complet, funcție, salariu. Responsabilitati: interactioneaza cu furnizorii, accepta materiale si semneaza facturi.
• 3. Sofer de livrare. Atribute: nume complet, funcție, salariu. Responsabilitati: Livrarea produsului finit catre client.

Obiecte de control ale procesului de afaceri studiat:

• 1. Designer. Atribute: nume complet, funcție, salariu. Responsabilitati: design produs, management de proiect, control.
• 2. Operator contabil automatizat. Atribute: nume complet, funcție, salariu. Responsabilitati: mentinerea inregistrarilor automate, lucrul cu o baza de date.
• 3. Maestru de mobilier (Asamblator). Atribute: nume complet, funcție, salariu. Responsabilitati: Fabricarea produsului in conformitate cu proiectul.

Obiecte entitate ale procesului de afaceri studiat:

• 1. Cec - un document emis la plata comenzii.
• 2. Catalog - un document care reflectă gama de produse.
• 3. Formular de comandă - un document care include numărul comenzii, data comenzii, informații despre client, tipul selectat, schița produsului, dorințele clientului.
• 4. Design produs - proiectare mobilier comandat.
• 5. Cerere pentru materiale - un document care caracterizează materialele necesare și volumele acestora.
• 6. Baza de date - un program care vă permite să păstrați înregistrări materiale într-o companie.
• 7. Materiale – necesare pentru realizarea unui produs la comandă.
• 8. Factură - un document semnat la expedierea materialelor.
• 9. Produsul finit este rezultatul producției, caracterizat prin apartenența la orice comandă.

Tabelul 5.1 oferă o descriere a relației obiectelor între ele.

Tabelul 5.1 Descrierea modului în care obiectele interacționează între ele

Notă: Dacă materialele necesare sunt în stoc, atunci se omite paragrafele 18, 19, 20, 21 din acest tabel.

Modelul dinamic de interacțiune între departamente și client în precedentul „Vânzarea unui produs personalizat” este prezentat în Figura 5.1 Modelul dinamic de interacțiune între departament, angajat și client în precedentul „Comandă” este prezentat în Figura 5.2 Modelul dinamic al interacțiunii dintre departament, angajați și client în precedentul „Design” este prezentat în Figura 5.3. Modelul dinamic al interacțiunii angajaților, în precedentul „Proiectare” este prezentat în Figura 5.4.

Figura 5.1 Diagrama de secvență a cazului de utilizare Vânzarea unui produs personalizat

Figura 5.2 Diagrama de secvență a cazului de utilizare „Plase an order”.

Figura 5.3 Diagrama secvenței de caz de utilizare a proiectării

Figura 5.4 Diagrama de secvență a cazului de utilizare în producție

Model obiect

Tehnologia orientată pe obiect se bazează pe așa-numita model de obiect. Principiile de bază ale construcției sale sunt: ​​abstractizarea, încapsularea, modularitatea, ierarhia, dactilografia, paralelismul și persistența. Fiecare dintre aceste principii în sine nu este nou, dar în modelul obiect sunt aplicate împreună pentru prima dată.

Analiza și proiectarea orientate pe obiecte sunt fundamental diferite de abordările tradiționale de proiectare structurată: necesită un mod diferit de a gândi procesul de descompunere, iar arhitectura produsului software rezultat depășește în mare măsură conceptele de programare structurată tradițională. Diferențele se datorează faptului că proiectarea structurată se bazează pe programare structurată, în timp ce proiectarea orientată pe obiecte se bazează pe metodologia de programare orientată pe obiecte.

Metodele de proiectare structurală ajută la simplificarea procesului de dezvoltare a sistemelor complexe prin utilizarea algoritmilor ca blocuri de construcție gata făcute. De asemenea, tehnicile de proiectare orientate pe obiecte sunt concepute pentru a ajuta dezvoltatorii să folosească caracteristicile expresive puternice ale programării bazate pe obiecte și orientate pe obiecte care folosesc clase și obiecte ca blocuri de construcție.

. (analiza orientată pe obiecte, OOA) are ca scop crearea de modele ale realității bazate pe o viziune asupra lumii orientată pe obiecte.

Analiza orientată pe obiecteeste o metodologie în care cerințele de sistem sunt percepute în termeni de clase și obiecte identificate în domeniul subiectului.

. ( design orientat pe obiecte, OOD )

Programarea presupune în primul rând utilizarea corectă și eficientă a mecanismelor limbajelor de programare specifice. Designul, pe de altă parte, se concentrează pe structurarea corectă și eficientă a sistemelor complexe. Să definim designul orientat pe obiecte după cum urmează:

Design orientat pe obiecteeste o metodologie de proiectare care combină procesul de descompunere a obiectelor și tehnici de prezentare a modelelor logice și fizice, precum și statice și dinamice ale sistemului proiectat.

Există două părți importante ale acestei definiții: proiectarea orientată pe obiecte

1) se bazează pe descompunerea orientată pe obiecte;

2) utilizează o varietate de tehnici de reprezentare a modelelor care reflectă structura logică (clase și obiecte) și fizică (module și procese) a sistemului, precum și aspectele sale statice și dinamice.

Este descompunerea orientată pe obiecte care distinge proiectarea orientată pe obiecte de proiectarea structurală; în primul caz, structura logică a sistemului este reflectată de abstracții sub formă de clase și obiecte, în al doilea - prin algoritmi.

. (programare orientată pe obiecte, POO)

Programare orientată pe obiecteeste o metodologie de programare bazată pe reprezentarea unui program ca o colecție de obiecte, fiecare dintre acestea fiind o instanță a unei clase specifice, iar clasele formează o ierarhie de moștenire.

Această definiție poate fi împărțită în trei părți:

1) OOP utilizează ca elemente de bază obiecte, nu algoritmi;

2) fiecare obiect este copie orice specific clasă;

3) se organizează cursuri ierarhic.

Un program va fi orientat pe obiecte numai dacă sunt îndeplinite toate cele trei cerințe specificate. În special, programarea care nu se bazează pe relații ierarhice nu aparține OOP, ci este numită programare bazată pe tipuri de date abstracte.

Există cinci tipuri principale de stiluri de programare, care sunt enumerate mai jos împreună cu tipurile de abstractizări inerente acestora:

Este imposibil să recunoaștem un stil de programare ca fiind cel mai bun în toate domeniile de aplicare practică. De exemplu, un stil orientat pe reguli este mai potrivit pentru proiectarea bazelor de cunoștințe, în timp ce un stil orientat către proceduri este mai potrivit pentru sarcinile de calcul. Pe baza experienței acumulate, stilul orientat pe obiecte este cel mai potrivit pentru cea mai largă gamă de aplicații; într-adevăr, această paradigmă servește adesea drept fundație arhitecturală pe care sunt construite alte paradigme.

Fiecare stil de programare are propria sa bază conceptuală. Fiecare stil necesită propria sa stare de spirit și un mod de a percepe problema care se rezolvă. Pentru stilul orientat pe obiecte, baza conceptuală este model de obiect. Are patru elemente principale:

• abstractizare;
• încapsulare;
• modularitatea;
• ierarhie.

Aceste elemente sunt principalîn sensul că fără niciuna dintre ele modelul nu va fi orientat pe obiecte. Pe lângă cele principale, există trei elemente suplimentare:

• tastare;
• paralelism;
• conservare.

Numind-le opționale, ne referim la faptul că sunt utile în modelul obiect, dar nu sunt obligatorii.

Abstracția identifică caracteristicile esențiale ale unui obiect care îl deosebesc de toate celelalte tipuri de obiecte și, astfel, își definește clar granițele conceptuale din punctul de vedere al observatorului.

Abstracția se bazează pe conceptele de client și server.

Client Orice obiect care folosește resursele altui obiect (numit Server).

Vom caracteriza comportamentul unui obiect prin serviciile pe care le oferă altor obiecte și operațiunile pe care le efectuează asupra altor obiecte. Această abordare concentrează atenția asupra manifestărilor externe ale obiectului și conduce la idee model de contract programare, atunci când manifestarea exterioară a unui obiect este considerată din punctul de vedere al contractului său cu alte obiecte, structura sa internă trebuie realizată în conformitate cu aceasta (adesea în interacțiune cu alte obiecte). Contractul înregistrează toate obligațiile pe care obiectul server le are față de obiectul client. Cu alte cuvinte, acest contract definește responsabilitate obiect, adică comportamentul pentru care este responsabil.

Fiecare operațiune acoperită de acest contract este definită în mod unic de parametrii ei formali și de tipul de returnare. Setul complet de operațiuni pe care un client le poate efectua asupra unui alt obiect, împreună cu ordinea corectă în care sunt apelate acele operațiuni, se numește protocol. Un protocol reflectă toate modurile posibile în care un obiect poate acționa sau poate fi afectat. Ea determină astfel complet comportamentul extern al abstracției din punct de vedere static și dinamic.

Încapsulare este procesul de separare unul de altul a elementelor unui obiect care determină structura și comportamentul acestuia. Încapsularea servește la izolarea obligațiilor contractuale ale unei abstracții de implementarea lor.

Abstracția și încapsularea sunt complementare: abstracția se concentrează pe comportamentul observabil al unui obiect, în timp ce încapsularea se ocupă de structura internă. Cel mai adesea, încapsularea se realizează prin ascunderea informațiilor, adică mascarea tuturor detaliilor interne care nu afectează comportamentul extern. De obicei, atât structura internă a unui obiect, cât și implementarea metodelor sale sunt ascunse. În termeni practici, aceasta înseamnă că există două părți într-o clasă: o interfață și o implementare. Interfață reflectă comportamentul extern al unui obiect, descriind abstractizarea comportamentului tuturor obiectelor unei clase date. Intern implementare descrie reprezentarea acestei abstractii si mecanismele de realizare a comportamentului dorit al obiectului. Principiul separării interfeței și implementării corespunde esenței lucrurilor: partea interfață conține tot ceea ce privește interacțiunea unui anumit obiect cu orice alte obiecte; implementarea ascunde de la alte obiecte toate detaliile care nu au legătură cu procesul de interacțiune dintre obiecte.

Modularitate - aceasta este o proprietate a unui sistem care a fost descompus în module coerente intern, dar slab interconectate.

În procesul de împărțire a unui sistem în module, două reguli pot fi utile. În primul rând, deoarece modulele servesc ca blocuri de program elementare și indivizibile care pot fi reutilizate în întregul sistem, distribuția claselor și a obiectelor între module trebuie să țină cont de acest lucru. În al doilea rând, mulți compilatori creează un segment de cod separat pentru fiecare modul. Prin urmare, pot exista restricții privind dimensiunea modulului. Dinamica apelurilor subrutinelor și aspectul declarațiilor în cadrul modulelor pot afecta foarte mult localitatea de referință și gestionarea paginilor de memorie virtuală. Când procedurile sunt slab modularizate, apelurile reciproce între segmente devin mai frecvente, ceea ce duce la pierderea eficienței cache-ului și la schimbări frecvente ale paginii.

Este destul de dificil să reuniți astfel de cerințe contradictorii, dar principalul lucru este să înțelegeți că separarea claselor și obiectelor într-un proiect și organizarea unei structuri modulare este independent actiuni. Procesul de izolare a claselor și a obiectelor face parte din procesul de proiectare logică a unui sistem, iar împărțirea în module este o etapă a proiectării fizice. Desigur, uneori este imposibil să finalizați proiectarea logică a unui sistem fără a finaliza proiectarea fizică și invers. Aceste două procese sunt efectuate iterativ.

Ierarhie - aceasta este ordonarea abstracțiilor, aranjarea lor pe nivele.

Principalele tipuri de structuri ierarhice în relație cu sistemele complexe sunt structura de clasă (ierarhia „este-a”) și structura obiectului ( „partea” ierarhiei).

Un element important al sistemelor orientate pe obiecte și principalul tip de ierarhie „is-a” este conceptul de moștenire menționat mai sus. Moștenirea înseamnă o relație între clase (relația părinte/copil) în care o clasă împrumută o parte structurală sau funcțională a uneia sau a mai multor clase (respectiv, singurȘi moștenire multiplă). Cu alte cuvinte, moștenirea creează o ierarhie de abstracțiuni în care subclasele moștenesc structura uneia sau mai multor superclase. Adesea, o subclasă se bazează pe sau rescrie componente ale unei clase superioare.

În timp ce ierarhia „este a” definește relația de generalizare/specializare, relația „parte din” introduce ierarhia de agregare. În „partea” ierarhiei, o clasă se află la un nivel de abstractizare mai înalt decât oricare folosit pentru a o implementa.

Tastare este o modalitate de a proteja împotriva utilizării obiectelor unei clase în locul alteia, sau cel puțin de a controla o astfel de utilizare.

Paralelism - aceasta este o proprietate care distinge obiectele active de cele pasive.

Depozitare - capacitatea unui obiect de a exista în timp, supraviețuind procesului care l-a dat naștere și (sau) în spațiu, deplasându-se din spațiul său de adrese inițial.

Cu o abordare orientată pe obiecte, analiza cerințelor sistemului se reduce la dezvoltarea modelelor acestui sistem. Un model al unui sistem (sau orice alt obiect sau fenomen) este o descriere formală a unui sistem care identifică principalele obiecte care alcătuiesc sistemul și relațiile dintre aceste obiecte. Construirea modelelor este o modalitate larg răspândită de a studia obiecte și fenomene complexe. Modelul omite numeroase detalii care fac dificil de inteles. Modelarea este larg răspândită atât în ​​știință, cât și în tehnologie.

Modelele ajută:

Verificați performanța sistemului în curs de dezvoltare în fazele incipiente ale dezvoltării acestuia;

Comunicați cu clientul sistemului, clarificând cerințele acestuia pentru sistem;

Faceți (dacă este necesar) modificări în proiectarea sistemului (atât la începutul proiectării sale, cât și în alte faze ale ciclului său de viață).

În prezent, există mai multe tehnologii pentru dezvoltarea orientată pe obiect a sistemelor software de aplicație, care se bazează pe construcția și interpretarea modelelor acestor sisteme pe un computer. Acest proiect folosește una dintre ele - OMT (Object Modeling Techniques). În plus, a fost construită o diagramă de model de obiect în UML.

Modelul obiect descrie structura obiectelor care alcătuiesc sistemul, atributele acestora, operațiile și relațiile cu alte obiecte. Modelul obiect ar trebui să reflecte acele concepte și obiecte din lumea reală care sunt importante pentru sistemul în curs de dezvoltare. Modelul obiect reflectă, în primul rând, pragmatica sistemului în curs de dezvoltare, care se exprimă în utilizarea terminologiei domeniului de aplicație asociată cu utilizarea sistemului în curs de dezvoltare.

Definirea claselor de model de obiecte

Analiza cerințelor externe pentru sistemul proiectat face posibilă determinarea obiectelor și claselor de obiecte asociate cu problema aplicată pe care acest sistem trebuie să o rezolve. Toate clasele trebuie să aibă sens în domeniul aplicației în cauză; clase asociate cu implementarea computerului, cum ar fi lista, stiva etc. nu trebuie administrat în această etapă.

Să începem prin a identifica clasele posibile dintr-o declarație scrisă a unei probleme aplicate. Când identificați clase posibile, ar trebui să încercați să identificați cât mai multe clase posibil, notând numele fiecărei clase care vă vine în minte. În special, fiecare substantiv care apare în enunțul preliminar al problemei poate avea o clasă corespunzătoare. Prin urmare, atunci când se identifică clase posibile, fiecare astfel de substantiv este de obicei asociat cu o clasă posibilă.

Ca rezultat, obținem următoarea listă de nume posibile de clase:

Un alt proxy;

Document;

Server Web la distanță;

Configurare;

Informații despre document;

Informații despre serverul Web la distanță;

Antetul cererii;

Antet de răspuns.

Când creați orice proiect software, prima (și cea mai importantă) etapă este întotdeauna proiectarea. În orice disciplină de inginerie, designul se referă de obicei la un fel de abordare unificată prin care căutăm modalități de a rezolva o problemă specifică, asigurându-ne că sarcina este îndeplinită. În spatele presupunerii lui Stroustrup: „Scopul designului este de a identifica o structură internă clară și relativ simplă, care se numește uneori arhitectură... Designul este produsul final al procesului de proiectare”. Produsele de design sunt modele care ne permit să înțelegem structura viitorului sistem, să echilibrăm cerințele și să conturăm o schemă de implementare.

Modelarea este larg răspândită în toate disciplinele ingineriei, în mare parte pentru că implementează principiile de descompunere, abstractizare și ierarhie. Fiecare model descrie o anumită parte a sistemului luat în considerare, iar noi, la rândul nostru, construim noi modele pe baza celor vechi, în care suntem mai mult sau mai puțin încrezători. Modelele ne permit să ne controlăm eșecurile. Evaluăm comportamentul fiecărui model în situații normale și neobișnuite și apoi facem ajustările corespunzătoare dacă nu suntem mulțumiți de ceva.

Tehnologia orientată pe obiect se bazează pe așa-numitul model obiect. Principiile sale principale sunt: ​​abstractizarea, încapsularea, modularitatea, ierarhia, dactilografia, paralelismul și persistența. Fiecare dintre aceste principii nu este de fapt nou, dar în modelul obiect sunt aplicate împreună pentru prima dată. Primele patru concepte sunt obligatorii în sensul că fără fiecare dintre ele modelul nu va fi orientat pe obiecte. Altele sunt opționale, ceea ce înseamnă că sunt utile în modelul obiect, dar nu sunt obligatorii.

Beneficiile modelului obiect

Modelul obiect este fundamental diferit de modelele asociate cu metode mai tradiționale de analiză structurală, proiectare și programare. Acest lucru nu înseamnă că modelul obiect necesită abandonarea tuturor metodelor și tehnicilor găsite anterior și testate în timp. Mai degrabă, introduce câteva elemente noi care se adaugă experienței anterioare. Abordarea obiect oferă o serie de facilități semnificative care nu au fost furnizate de alte modele. Cel mai important, abordarea bazată pe obiecte vă permite să creați sisteme care satisfac caracteristicile sistemelor complexe bine structurate. Există alte cinci beneficii pe care modelul obiect le oferă.

1. Modelul obiect vă permite să utilizați pe deplin capacitățile expresive ale programării orientate pe obiecte și pe obiecte. Stroustrup notează: „Nu este întotdeauna evident cum să profitați pe deplin de un limbaj precum C++. Îmbunătățiri semnificative ale eficienței și calității codului pot fi obținute pur și simplu prin utilizarea C++ ca „C îmbunătățit” cu elemente de abstractizare a datelor. Cu toate acestea, mult mai mult.” Un progres semnificativ este introducerea ierarhiei de clasă în procesul de proiectare. Acesta este ceea ce se numește proiectare orientată pe obiecte și este locul în care beneficiile C++ sunt cel mai bine demonstrate." Experiența a arătat că atunci când limbaje precum Smalltalk, Object Pascal, C++, CLOS și Ada sunt folosite în afara modelului obiect, caracteristicile lor cele mai puternice sunt fie ignorate, fie aplicate greșit.
2. Utilizarea abordării bazate pe obiect crește semnificativ nivelul de unificare a dezvoltării și reutilizarea nu numai a programelor, ci și a proiectelor, ceea ce duce în cele din urmă la crearea unui mediu de dezvoltare. Sistemele orientate pe obiecte sunt adesea mai compacte decât echivalentele lor neorientate pe obiecte. Și asta înseamnă nu doar o reducere a volumului de cod al programului, ci și o reducere a costului proiectului, datorită utilizării dezvoltărilor anterioare, ceea ce oferă un câștig în cost și timp.
3. Utilizarea unui model de obiect duce la construirea de sisteme bazate pe descrieri intermediare stabile, ceea ce simplifică procesul de efectuare a modificărilor. Acest lucru oferă sistemului posibilitatea de a se dezvolta treptat și nu duce la reelaborarea completă a acestuia chiar și în cazul unor modificări semnificative ale cerințelor inițiale.
4. Modelul obiect reduce riscul dezvoltării sistemelor complexe, în primul rând pentru că procesul de integrare se întinde pe întreaga perioadă de dezvoltare, mai degrabă decât să devină un eveniment unic.Abordarea obiectului constă într-o serie de etape de proiectare bine gândite, care reduce de asemenea gradul de risc si creste increderea in corectitudinea deciziilor luate.
5. Modelul obiect este orientat spre percepția umană asupra lumii sau, în cuvintele lui Robson, „Mulți oameni care nu au idee cum funcționează un computer găsesc abordarea orientată pe obiect a sistemelor complet naturală”.

Baza conceptuală a abordării orientate pe obiecte este modelul obiect. Principiile de bază ale construcției sale sunt:

· abstractizare;

· încapsulare;

· modularitate;

· ierarhie.

Abstracția este selecția celor mai importante, esențiale caracteristici ale unui obiect, care îl deosebesc de toate celelalte tipuri de obiecte și, astfel, îi definesc clar limitele conceptuale din punctul de vedere al analizei și analizei ulterioare și ignorând cele mai puțin importante sau nesemnificative. Detalii.

Abstracția vă permite să gestionați complexitatea sistemului concentrându-vă pe proprietățile esențiale ale obiectului. Abstracția concentrează atenția asupra caracteristicilor externe ale unui obiect și vă permite să separați cele mai semnificative caracteristici ale comportamentului său de detaliile implementării lor. Selectarea setului potrivit de abstracții pentru un domeniu de problemă dat este principala provocare a proiectării orientate pe obiecte. Abstracția depinde de domeniu și de punct de vedere - ceea ce este important într-un context poate să nu fie important în altul. Obiectele și clasele sunt abstracțiile de bază ale unui domeniu.

Încapsularea este localizarea fizică a proprietăților și comportamentului într-o singură abstracție (considerată o „cutie neagră”), ascunzându-le implementarea în spatele unei interfețe publice.

Încapsularea este procesul de separare unul de altul a elementelor individuale ale unui obiect care determină structura și comportamentul acestuia. Încapsularea servește la izolarea interfeței unui obiect, care reflectă comportamentul său extern, de implementarea internă a obiectului. Abordarea obiect presupune că resursele proprii, care pot fi manipulate doar de operațiunile obiectului însuși, sunt ascunse de mediul extern. Abstracția și încapsularea sunt complementare: abstracția concentrează atenția asupra trăsăturilor externe ale unui obiect, în timp ce încapsularea (sau restricționarea accesului în alt mod) împiedică obiectele utilizatorului să discerne structura internă a obiectului.

Încapsularea este similară cu conceptul de ascundere a informațiilor. Aceasta este capacitatea de a ascunde numeroase detalii ale unui obiect din lumea exterioară. Lumea exterioară a unui obiect este totul în afara acestuia, inclusiv restul sistemului. Ascunderea informațiilor oferă același beneficiu ca și încapsularea: flexibilitate.

Modularitatea este o proprietate a unui sistem asociată cu posibilitatea descompunerii acestuia într-un număr de subsisteme (module) puternic cuplate, dar slab interconectate.

Modularitatea reduce complexitatea sistemului, permițând dezvoltarea independentă a modulelor individuale. Încapsularea și modularitatea creează bariere între abstracții.

Ierarhia este un sistem ordonat sau ordonat de abstracții, aranjarea lor pe niveluri.

Principalele tipuri de structuri ierarhice în raport cu sistemele complexe sunt structura de clasă (ierarhie după nomenclatură) și structura obiectelor (ierarhie după compoziție). Exemple de ierarhii de clase sunt moștenirea simplă și multiplă (o clasă folosește o parte structurală sau funcțională, respectiv, a uneia sau mai multor alte clase), iar ierarhiile obiectelor sunt agregare.

Clasele pot fi organizate într-o structură ierarhică, care în aparență seamănă cu o schemă de clasificare în logica conceptuală. Ierarhia conceptelor este construită după cum urmează. Conceptul sau categoria cea mai generală este considerată conceptul care are cel mai mare volum și, în consecință, cel mai mic conținut. Acesta este cel mai înalt nivel de abstractizare pentru o anumită ierarhie. Apoi se precizează acest concept general, adică volumul său scade și conținutul său crește. Apare un concept mai puțin general, care în diagrama ierarhică va fi situat la un nivel sub cel inițial. Acest proces de concretizare a conceptelor poate fi continuat până când, la nivelul cel mai de jos, se obține un concept, a cărui concretizare ulterioară într-un context dat este fie imposibilă, fie impracticabilă.