Design de sus în jos și de jos în sus

De la Wikipedia, enciclopedia liberă.
Salt la navigare Salt la căutare

Sus în jos și de jos în sus modelele sunt informații strategii de procesare și de gestionare a cunoștințelor, în special în ceea ce privește software - ul și, prin extensie, alte teorii umaniste și sisteme de teorii. În general, acestea sunt metodologii utilizate pentru a analiza situațiile problematice și a construi ipoteze adecvate pentru soluționarea lor: conceptul de situație problematică poate fi urmărit în cele mai variate domenii, cum ar fi dezvoltarea unui program de calculator, rezolvarea unei probleme geometrice sau matematic , elaborarea unui text, rezolvarea unei probleme practice / operaționale.

În modelul de sus în jos , este inițial formulată o vedere generală a sistemului sau scopul principal al acestuia este descris fără a intra în detaliile părților sale. Fiecare parte a sistemului este ulterior rafinată ( descompunere , specializare și specificație sau identificare ) [1] adăugând mai multe detalii despre proiectare. Fiecare parte nouă astfel obținută poate fi apoi refinită, specificând detalii suplimentare, până când specificația completă este suficient de detaliată pentru a valida modelul. Modelul de sus în jos este deseori conceput cu ajutorul cutiilor negre care simplifică umplerea, dar nu permit înțelegerea mecanismului elementar.

Spre deosebire de modelul de sus în jos este designul de jos în sus , în care părți individuale ale sistemului sunt specificate în detaliu și apoi conectate împreună pentru a forma componente mai mari, care la rândul lor sunt interconectate pentru a forma un sistem. Strategiile bazate pe fluxul de informații ascendent par potențial necesare și suficiente, deoarece se bazează pe cunoașterea tuturor variabilelor capabile să condiționeze elementele sistemului.

De sus în jos

Programarea de sus în jos este un stil de programare în care proiectarea începe prin specificarea părților complexe și ulterior descompunerea lor în părți mai mici ( împărțiți și cuceriți ). În cele din urmă, componentele sunt specificate suficient pentru codificare și programul este, de asemenea, scris. Acesta este exact opusul programării de jos în sus.

Numele de sus în jos înseamnă „de sus în jos”: problema se pune la „sus” și subproblemele care o compun la „jos”. Numele amintește și de o reprezentare piramidală: scopul final este vârful piramidei, iar subproblemele care o compun formează baza.

De sus în jos începe de la obiectiv și de la acesta dă naștere strategiei direct potrivite pentru determinarea obiectivului însuși, apoi apreciază de ce și face cum depinde de acesta; ca parte a strategiei care vizează determinarea directă a obiectivului, identifică resursele necesare, le specifică pe cele disponibile și le identifică pe cele lipsă, propune ulterior fiecare resursă lipsă ca sub-obiectiv sau ca sub-problemă în care fiecare sub-obiectiv necesită o substrategie legată de aceasta.

De jos în sus

De jos în sus amintește în schimb o imagine care prezintă o săgeată în care coada este partea de jos (partea inferioară), în timp ce sus este vârful: din punct de vedere dinamic, începem de jos și continuăm în sus .

De jos în sus se formează din punctul de plecare ( jos ) sau din situația inițială; consideră scopul final, conduce la construirea unei căi secvențiale organizate în etape succesive în care ancorarea dintre obiectivele intermediare și obiectivul final este în general căutată într-un mod intuitiv ( euristic ).

Informatică

În procesul de dezvoltare software , abordările de sus în jos și de jos în sus joacă un rol fundamental. Abordarea de sus în jos pune accentul pe planificare și pe o înțelegere completă a sistemului. Este evident că nicio codare nu poate începe până când nu se atinge cel puțin un nivel suficient de detaliu în proiectarea unei părți semnificative a sistemului. Totuși, aceasta întârzie faza de testare a ultimelor unități funcționale ale unui sistem până când o parte semnificativă a proiectării a fost finalizată. Abordarea de jos în sus pune accentul pe codificare și pe faza de testare timpurie, care poate începe de îndată ce primul modul a fost specificat. Cu toate acestea, această abordare prezintă riscul ca modulele să poată fi codificate fără a avea o idee clară despre cum ar trebui să fie conectate la alte părți ale sistemului, iar acest tip de legătură ar putea să nu fie ușor. Reutilizarea codului este unul dintre principalele beneficii ale abordării de jos în sus.

Proiectarea de sus în jos a fost susținută în anii 1970 de cercetătorii IBM Harlan Mills și Niklaus Wirth . Mills a dezvoltat conceptele de programare structurată pentru utilizare practică și le-a testat într-un proiect din 1969 pentru automatizarea arhivei New York Times . Succesul ingineresc și de management al acestui proiect a dus la creșterea abordării de sus în jos prin IBM și restul industriei de calculatoare. Niklaus Wirth, care, printre alte companii, a dezvoltat limbajul de programare Pascal , a scris lucrarea de autor Dezvoltare software pentru îmbunătățiri ulterioare . Metodele de sus în jos erau preferate în ingineria software în anii 1980.

Abordările moderne ale proiectării software combină de obicei atât tehnici de sus în jos, cât și de jos în sus. Deși o înțelegere a sistemului complet este de obicei considerată necesară pentru un design bun, ceea ce duce teoretic la o abordare de sus în jos, majoritatea proiectelor software încearcă să utilizeze codul existent la un anumit nivel. Modulele preexistente oferă designului o tendință de jos în sus. Unele abordări de proiectare funcționează prin proiectarea unui sistem parțial funcțional, care este complet codificat, apoi acest sistem este apoi extins pentru a îndeplini toate cerințele de proiectare.

Programare

Tehnica pentru scrierea unui program folosind metode de sus în jos este de a scrie o procedură principală care indică nume pentru funcțiile principale de care va avea nevoie. Ulterior, echipa de programare va revizui cerințele pentru fiecare dintre aceste funcții și procesul va fi repetat. Aceste sub-proceduri compartimentate vor efectua în cele din urmă acțiuni atât de simple încât vor duce la o codificare simplă și concisă. Când toate diversele subproceduri au fost codificate, programul este terminat.

Beneficii

  • Echipa de programare rămâne concentrată asupra obiectivului.
  • Toată lumea își cunoaște sarcina.
  • Când începe programarea, nu mai există întrebări.
  • Codul este simplu de urmat, deoarece este scris metodic și cu un scop specific.

Dezavantaje

  • Programarea de sus în jos poate complica faza de testare, deoarece nu va exista un executabil până când nu veți ajunge aproape de sfârșitul proiectului.
  • Programarea de jos în sus facilitează testarea unitară, dar până când sistemul nu se unește, nu poate fi testat în întregime, ceea ce cauzează adesea complicații spre sfârșitul „Suntem individual, împreună eșuăm”.
  • Toate deciziile depind de începutul proiectului și unele decizii nu pot fi luate pe baza specificațiilor detaliate.

Neuroștiințe și psihologie

Acest lexicon este folosit și în neuroștiințe și psihologie . Studiul atenției vizuale este un exemplu. Dacă atenția dvs. este asupra unei flori dintr-un câmp, poate fi pur și simplu că floarea este mai relevantă din punct de vedere vizual decât restul câmpului. Informațiile care v-au determinat să observați floarea v-au venit de jos în sus. Atenția dvs. nu a fost condiționată de cunoașterea florii; stimulii externi erau deja suficient de adecvați. Comparați această situație cu una în care căutați o floare. Aveți o reprezentare a ceea ce căutați. Când vedeți obiectul pe care îl căutați, acest lucru este important. Acesta este un exemplu de utilizare a informațiilor într-un mod de sus în jos.

Notă

Bibliografie

  • Perl Design Patterns Book

Alte proiecte

linkuri externe

Controlul autorității GND ( DE ) 4243685-0