introducere În procesul de proiectare al …vega.unitbv.ro/~romanca/psci/2-psci-proiectare.pdf ·...

1

INTRODUCERE ÎN PROCESUL DE

PROIECTARE AL SISTEMELOR EMBEDDED

2

PRINCIPALE OBIECTIVEALE METODOLOGIEI DE PROIECTARE

oferă posibilitatea păstrării unei istorii / înregistrări a rezultatelor etapelor proiectării (utilă pentru documentare, testare funcţională, depanare)permite dezvoltarea sau folosirea unor unelte de proiectare asistată de calculator, şi desfăşurarea în paralel a proiectării pentru diferite componente.simplifică comunicarea dintre membrii unei echipe de proiectare.

3

ELEMENTE SPECIFICE PROIECTĂRII EmS

• Deciziile luate la proiectare se bazează pe re-utilizarea unor componente ale proiectelor deja existente

• Strânsa interacţiune dintre hardware şi software. Programatorii trebuie să înţeleagă partea hardware iar proiectanţii de hardware trebuie să înţeleagă partea software

• Utilizarea de blocuri funcţionale → fiecare proiectant este responsabil atât de hardware cât şi de software pentru o funcţiune, sau pentru un set de funcţiuni

4

ETAPE PROIECTARE

• Deciziile luate la un anumit pas al proiectării sunt bazate pe estimarea a ce se va întâmpla mai târziu

• Dacă estimările sunt inadecvate, trebuie să ne întoarcem şi să îndreptăm deciziile noastre iniţiale, ţinând cont de noile evenimente

• La fiecare etapă a proiectării se adaugă detalii:√ analiza proiectului la fiecare pas pentru a determina cum se

îndeplinesc specificaţiile√ rafinarea proiectului pentru a adăuga elemente de detaliu√ verificarea proiectul pentru a fi siguri că îndeplineşte toate

obiectivele sistemului

PRINCIPALELE ETAPE ÎN PROCESUL DE PROIECTARE AL EmS

•Definirea cerinţelor produsului•Elaborare specificaţii funcţionale•Crearea proiectului arhitectural•Furnizare versiune arhitecturalăfinalã

Etapa 1: Crearea arhitecturii

Etapa 2: Implementarea arhitecturii

Etapa 3: Testarea sistemului

•Implementare module•Verificare şi punere la punct•Implementarea şi integrarea sistemului

•Verificare şi testare sistem în diferite faze de implementare

Etapa 4: Furnizarea prototipului

5

6

Et.1: Creareaarhitecturii

Definirea cerinţelorprodusului

Analiza preliminarã a cerinţelor

Creareaproiectuluiarhitectural

Furnizare versiunearhitecturalã

Incorporarefeedback

Dezvoltareaversiune

arhitecturalã

Verificare şi feedback

Furnizareversiune arh.

finalã

Elaborare specificaţii funcţionale

Et. 2: Implementareaarhitecturii

Imple-mentareasistemului

Incorporarefeedback

Et. 3: Testareasistemului

Verificareşi testaresistem

Etapa 4: Furnizareaprototipului

Furnizare prototipsistem

7


DEFINIREA PROBLEMEI ŞI A CERINŢELOR PRODUSULUI

• Definirea produsului descrie ce va fi şi ce va face acesta• Definirea cerinţelor este primul pas al procesului, fiind cheia succesului în

proiectarea sistemelor electronice: documentaţia• Documentaţia descrie ce veţi construi

– Spune oamenilor de marketing ce produs vor avea de vândut, iar grupului de ingineri cum să implementeze produsul.

• Rezultatul acestei faze va fi o definire simplă a problemei, din punctul de vedere al utilizatorului (beneficiarul)– Se va descrie problema, dar nu se vor sugera soluţii

• DA: Mişcarea vorbitorului nu va fi stânjenită de cablul microfonului• NU: Se va folosi un microfon wireless

8


CINE DEFINEŞTE CERINŢELE ?

• Într-o companie foarte mare, definirea cerinţelor va fi făcută de către departamentul de marketing, sau un client important

• Într-o companie mică schiţa de definire a cerinţelor se poate face de către inginerii software şi hardware

• Pentru un proiecte mici, proiectantul defineşte cerinţele

9


CE TREBUIE DEFINIT CA CERINŢE ?

• CERINŢE FUNCŢIONALE– Intrări şi ieşiri (interfaţa cu utilizatorul şi mediul)– Funcţii şi constrângeri de timp

• CERINŢE NE-FUNCŢIONALE– Performanţă.– Costuri. – Consumul de putere.– Dimensiune fizică şi greutatea.– Fiabilitate, siguranţă în funcţionare, mentenabilitate

EXEMPLU DE FORMULAR DECERINŢE TIPICE


• Nume• Scop• Intrări / Ieşiri către lumea externă

– Tipul datelor– Caracteristicile generale ale datelor– Tipuri de dispozitive de interfaţă cu utilizatorul

• Funcţii. Intrări → FUNCŢII → Ieşiri• Performanţă• Costuri de fabricaţie. Apreciere grosieră, sau limită maximă.• Putere. Apreciere grosieră, sau limită maximă (baterii / reţea ?)• Dimensiune / greutate fizică

10

11


REZUMAT CERINŢE

Fază Rezultate Definirea problemei de proiectare şi elaborare cerinţe • Cercetare, analiză piaţă • Consultare utilizator. Culegere de informaţii

generale de la clienţi (utilizatori sau beneficiari)

• Cerinţe funcţionale şi nefuncţionale • Cercetare

⇒ Definirea corectă a problemei ⇒ Propunere cerinţe ⇒ Document (formular) de cerinţe ⇒ Crearea unui plan de testare

12

EXEMPLU: Hartă GPS

lat: 40 13 lon: 32 19

I-78

Scot

ch R

oad

Poziţia utilizatorului în latitudine / l i di

Poziţia curentă a utilizatorului

Prelucrat după Wayne Wolf, Computers as Components, Academic Press, London 2001

13

EXEMPLU: Hartă GPS

• Este un dispozitiv portabil care afişează pentru utilizator o hartă a terenului din jurul poziţiei curente a utilizatorului.

• Harta afişează modificările corespunzătoare schimbării poziţiei utilizatorului, sau ale dispozitivului de afişare a hărţii.

• Harta mobilă obţine poziţia sa de la GPS

14

Hartă GPS: Cerinţe iniţialeFuncţionalitate: proiectat pentru utilizare în trafic auto şi scopuri similare; nu

pentru utilizare nautică, sau aviaţie, care necesită funcţiuni şi baze de date mai specializate. Sistemul va afişa / indica principalele drumuri şi alte puncte de reper disponibile în bazele de date topografice standard.

Interfaţa cu utilizatorul: Ecranul va avea cel puţin rezoluţia de 400 x 600 pixeli. Dispozitivul va fi controlat prin maximum trei butoane. La apăsarea butoanelor pe ecran se deschide un meniu pentru a permite utilizatorului să selecteze funcţiile de control ale sistemului.

Performanţă: Harta se va rula lent pe ecran. După alimentare, afişarea cadrului iniţial pe ecran se va face în cel mult o secundă, iar sistemul va fi capabil să verifice şi să afişeze poziţia sa în cel mult 15 secunde.

Cost: Costul de vânzare maxim 500$. (aproximativ de 5 ori costul componentelor).

Dimensiune / greutate: Dispozitivul se va potrivi confortabil în palma mâinii.Consum de putere: Funcţionare pentru cel puţin 8 ore cu 4 baterii AA.

15

Formular de cerinţeName

GPS moving map

Purpose

Consumer-grade moving map for driving

Inputs

Power button, two control buttons

Outputs

Back-lit LCD display 400 X 600

Functions

Uses 5-receiver GPS system; three user-selectable resolutions; displays current latitude and longitude

Performance

Updates screen within 0.25 seconds upon movement

Manufacturing cost

$100 cost-of-goods- sold

Power

100 mW

Physical size/weight

no more than 2” X 6” (5cm x 15 cm), 12 ounces (340 g)

16


ELABORAREA SPECIFICAŢIILOR

• Specificaţiile reprezintă o descriere funcţională detaliată ce respectă cerinţele. Nu indică modul de implementare.

• Uşurează înţelegerea cerinţelor şi urmăresc îndeplinirea cerinţelor în timpul activităţilor de proiectare.

• Uşurează munca de proiectare şi înlătură eventualele greşeli, repetări sau omisiuni ale unor funcţii ⇒ reluări ale proiectării

• Specificaţiile sunt deosebit de importante pentru proiecte complexe, ce implică un colectiv de cercetare ⇒ sarcinile de proiectare pentru fiecare persoană din grup.

• Presupun o analiză (internă) a concepţiilor de proiectare enunţate, pentru a verifica dacă specificaţiile cerute sunt posibil de implementat– re-utilizarea unor părţi din alte proiecte anterioare permite asigurarea

succesului noului proiect (funcţional şi ca timp de terminare)

17


ELABORAREA SPECIFICAŢIILOR

• Specificaţiile pot fi privite ca un contract între beneficiar şi proiectant

• Documentele cu cerinţe şi specificaţii pot fi folosite pentru crearea unui plan de testare. Documentul de cerinţe defineşte ce este nevoie a fi testat.

• Pentru proiecte mari testarea poate fi făcută de un inginer de testare independent de colectivul de proiectare, care elaborează un plan de testare pe baza cerinţelor.

• Separarea analizei cerinţelor şi specificaţiilor este necesară adesea– diferenţe mari între modul cum beneficiarii pot descrie sistemul şi ceea

ce au nevoie arhitecţii pentru a proiecta sistemul.– beneficiarii pot avea aşteptări nerealiste cu privire la ceea ce se poate

face cu bugetul alocat de ei.

18


ELABORAREA SPECIFICAŢIILOR• Complexitatea şi formalismul specificaţiilor depind de tipul companiei

proiectante şi de dimensiunea produsului final.• Se poate realizeaza o modelare (de obicei de tip O.O:) a specificaţiilor în

scopul proiectării arhitecturii şi ulterior a proiectării componentelor.– Modelele sunt reprezentări conceptuale ale funcţionalităţii sistemului.

Modelul este constituit din obiecte funcţionale şi reguli pentru compunerea acestor obiecte.

• Descrierea grafică a specificaţiilor OO– fie într-un limbaj de modelare (de ex. UML),– sau prin definirea şi desenarea unor diagrame de analiză conceptuală a

sistemului care cuprind:• componentele cheie ale sistemului,• funcţiile de bază ale fiecărei componente,• interacţiunea – căile de comunicare între aceste componente şi• lista serviciilor oferite utilizatorului sistemului.

19

Exemplu diagramă conceptuală pentru servicii bancare simple (Alistair Cockburn)

Servicii mica bancă:Verificare contPăstrare bani în contVerificare stocuriÎmprumuturi

20

Exemplu diagramă conceptuală

Casier

Depozit (Seif)

Calculator

Masă

Realizează tranzacţia

Păstrează banii

Furnizează o suprafaţă plată pentru completat cereri

tranzacţii

Păstrează înregistrările şi balanţele

$

Interogare balanţă Detalii tranzacţie

Client

21

REZUMAT SPECIFICAŢII

Fază Rezultate Elaborare Specificaţii Descriere de detaliu a comportării sistemului.

O descriere detaliată, precisă, clară şi fără ambiguităţi a cerinţelor Descriere funcţii şi interacţiune componente

sistem Modelarea funcţionalităţii sistemului Analiza concepţiilor de proiectare - revizie

Document specificaţii Finalizarea descrierii modelul

funcţional Crearea unui plan de testare

22

EXEMPLU: Hartă GPS

• Lista de specificaţii pentru harta de navigare GPS va includecâteva componente:– ce date se recepţionează de la constelaţia de sateliţi GPS;– datele hărţii afişate;– interfaţa cu utilizatorul;– operaţii ce trebuie realizate pentru a satisface cerinţele

utilizatorului;– operaţii în fundal (ne-evidente) cerute pentru a păstra

sistemul în funcţiune, cum ar fi de exemplu funcţionarea receptorului GPS.

23

EXEMPLU: Hartă GPS

Wolf realizează descrierea funcţională prin modelare înUML (Unified Modeling Language)

UML:- este un limbaj vizual care poate capta în mod sugestiv

specificaţiile- umbreşte distincţiile dintre hw şi sw- modelează comportarea sistemului- este un generator automat de cod, putând genera codHDL sau C++ pentru implementarea proiectului.

24

Un obiect “Display” în notaţia UML

d1: Display

pixels: array[] of pixels elements menu_items

pixels is a 2-D array

comment

object name class name

attributes

Un obiect include un set de atribute care definesc starea sa internă. Atunci când se implementează într-un limbaj de programare, aceste atribute devin de obicei variabile, sau constante păstrate într-o structură de date.

25

O clasă în notaţia UML Display

pixels elements menu_items

mouse_click() draw_box

operations

class name

atributes

Operaţiile (metode în C++) determină modul cum obiectul interacţionează cu restul lumii

26

O specificaţie de maşină de stare UML (pentru o operaţie a display-ului)

region found

got menu item

called menu item

found object

object highlighted

start state

stop state

mouse_click(x,y,button)/find_region(region)

region = menu/ which_menu(i)

call_menu(I)

region = drawing/ find_object(objid)

highlight(objid)

27

Secvenţa operaţiilor în timp descrisă prin diagrama secvenţială

m: Mouse d1: Display u: Menu

mouse_click(x,y,button) which_menu(x,y,i)

call_menu(i)

time

lifeline

28


PROIECTARE ARHITECTURALĂ

• Arhitectura este o reprezentare abstractă a implementării sistemului şi indică structura sistemului în termenii componentelor mari şi interconexiunile dintre acestea.

• La nivel arhitectural, componentele hardware şi software sunt reprezentate ca o compoziţie de elemente ce interacţionează.

• Detalii de implementare (HW & SW) sunt abstractizate, conţinând doar informaţia de comportament şi de inter-relaţie între componente.

• O arhitectură embedded include elemente interne ale sistemului, elemente externe ce interacţionează cu sistemul, proprietăţile fiecărui element individual şi relaţiile de interacţiune între elemente

• În această etapă se face partiţionarea implementării funcţiilor între hardware şi software.

29


IMPORTANŢA ARHITECTURII

• Indică cum se vor implementa funcţiile sistemului, descrise în specificaţii.

• Arhitectura este un mijloc eficient pentru înţelegerea proiectului EmS, constituind documentul ce defineşte infrastructura proiectului, diferitele opţiuni de proiectare, constrângerile de proiectare. Planul arhitectural are capacitatea de a comunica rapid şi corect modul de proiectare către alte persoane cu sau fără pregătire tehnică, constituind totodată baza (fundaţia) activităţii de planificare a proiectării unui dispozitiv.

• Permite analiza şi testarea calităţii unui dispozitiv• Permite definirea unor modalităţi de reducere a costurilor de

proiectare-construcţie şi estimarea corectă a riscurilor implicate de implementarea diverselor elemente

• Permite reutilizarea cunoaşterii → scăderea în viitor a costurilor

30


PROIECTARE ARHITECTURALĂ

Proiectarea arhitecturală include:Definirea componentelor sistemului. Este o estimare ce ţine de

experienţă şi de cunoaşterea caracteristicilor componentelor hardware şi software propuse.

Specificaţii hardware / software (există opţiunea între a cumpăra şi a construi prin forţe proprii). În cazul UML: modelare grafică a obiectelor componente. Obiectele corespund pieselor reale HW şi SW ale proiectului.

Alegerea procesoruluiAlegerea limbajului de programareEvaluarea sistemuluiProiectare hardwareProiectare firmwareIntegrare

31


DE ŢINUT CONT• Este important de ţinut minte că hardware reprezintă un cost recurent

(repetat), ce se repetă pentru fiecare sistem vândut.• Software reprezintă un cost ne-recurent. Trebuie dezvoltat o singură dată, dar

nu apare ca şi cost pe unitatea de produs, decât dacă este o taxă de licenţă de plătit.

• Alegerea variantei de implementare hardware:– Cu microprocesoare, microcontrollere discrete şi cablaj imprimat – în

aceeaşi carcasă, System in Package– Sistem distribuit.– Un-sistem-pe-un-chip (System-on-chip = SOC). Proiecte SOC pe bază

de nuclee IP– ASIC, bazat tot pe nuclee IP dar pentru aplicaţii specifice şi în număr

extrem de mare. Sunt tot SoC, full custom design.

32

ALEGEREA PROCESORULUIEtapa 1: Crearea arhitecturii

• Numărul de pini de IO necesari - Pini grupaţi în porturi de IO, restricţii, capabilităţicurenţi mari

• Interfeţe necesare• Cerinţe memorie RAM

– numărul de variabile plus suma tuturor bufferelor interne, structuri FIFO, şidimensiunea stivei

– intern / extern, restricţii de utilizare, SFR, moduri de adresare– eficienţă compiler.

• Cerinţe memorie ROM– suma codului de program plus toate tabelele necesare a fi incluse într-o memorie

nevolatilă– regulă bazată pe experienţă: ocupare în proporţie de maxim 80%– Testare compilator ales → porţiuni de cod pentru a determina dimensiunea

acestuia după compilare / asamblare– dimensiunea codului depinde limbajul de programare ales pentru dezvoltare– dacă se folosesc operaţii în virgulă mobilă, iar procesorul nu are inclus un co-

procesor matematic ⇒ cod mare.

33


ALEGEREA PROCESORULUI• Număr de întreruperi cerut• Consideraţii real-time• Mediul de dezvoltare. Funcţiuni principale ale unui mediu integrat de

dezvoltare (IDE - Integrated Development Environment), ce rulează pe un calculator desktop (de exemplu un PC).:– dezvoltarea programelor utilizator (de obicei în limbaj C şi / sau

asamblare) într-o fereastră de editare.– compilator şi editor de legături– depanarea şi punerea la punct a programelor prin debugger– asamblor pentru rutinele scrise în asamblare– simulator pentru rularea programelor (inclusiv pas cu pas prin

debugger) şi urmărirea conţinutului registrelor interne, a memoriei, a porturilor de IO, a circuitelor timer / counter, etc.

– transferul codului (program executabil) către memoria locală (flash, EEPROM) a microcontrollerului

34


ALEGEREA PROCESORULUI

– Investiţii anterioare ale companiei (IDE), principii economice.

• Necesităţi de viteză de prelucrare. – În cazul cel mai dezavantajos al mai multor întreruperi aflate în curs

de servire procesorul trebuie să funcţioneze respectând specificaţiile de proiectare.

– Lungimea buclelor de interogare suficient de scurtă ca să nu se piardă niciodată un octet de la o intrare de date serială, sau de la oricare altă interfaţă.

– Frecvenţa de ceas a procesorului nu trebuie confundată cu frecvenţa oscilatorului de ceas.

– Setul de instrucţiuni este de asemenea foarte important. În unele aplicaţii arhitectura RISC poate fi o capcană.

35


ALEGEREA PROCESORULUI• ROM-ability

– Flash– EPROM– OTP– ROM.

• Costuri• In Circuit programming• Arhitectura memoriei• Cerinţe de putere• Cerinţe de mediu

– Unele aplicaţii impun ca MP să lucreze la game extreme de temperatură şi radiaţie.

36


DEZVOLTAREA VERSIUNII ARHITECTURALE

• Proiectarea componentelor hardware şi software• Integrarea sistemului prin conectarea componentelor

proiectate.• Verificare şi obţinere de informaţii de feedback• Inspecţia unui proiect se face de către o altă persoană

decât proiectantul (detectarea omisiunilor, erorilor). Inspecţia se face pe baza unor prezentări scrise sau orale din partea proiectantului.

37


DEZVOLTAREA VERSIUNII ARHITECTURALE

• Documentarea:– detectarea uşoară a componentelor care conduc la

neconformităţi cu cerinţele– comunicarea dintre membrii unei echipe– elaborarea rapoartelor cu privire la proiect– elaborarea documentaţiei finale a proiectului, – reutilizarea componentelor proiectului pentru alte

proiecte, modificare, upgrade.• Elaborarea unui plan pentru integrarea şi testarea

componentelor

38


REZUMAT:ARHITECTURA ŞI INTEGRARE

Proiecte la nivel de sistem. Structura sistemului în termenii componentelor mari şi interconexiunile dintre acestea. Modul de implementare a funcţiilor şi modul de implementare a componentelor

• Alegerea procesorului• Alegerea limbajului• Definirea blocurilor majore

hardware şi software• Opţiune între cumpărare sau

construire prin forţe proprii.• Partiţionare: Blocuri

funcţionale, Hw / SW

REZULTATE

• Specificaţii pt. blocuri funcţionale

• Alegere MCU/CPU• Alegere limbaj• Revizie de proiectare a

sistemului

39

EXEMPLU: Hartă GPSDiagrama bloc ce defineşte arhitectura pentru harta mobilă

Receptor

GPS Maşină de

căutare Dispozitivde redare

Interfaţă utilizator Database

Display

40

HARDWARE

Receptor GPS

CPU

Panou I/O

Display

Frame Buffer

Memorie

Magistrală

41

SOFTWARE

Poziţie Căutare în bază date

Redare

Timer

Interfaţă utilizator

Pixeli

42

2. Implementarea arhitecturii

IMPLEMENTAREA SISTEMULUI

• Implementarea hardware şi software• Proiectare de detaliu componente şi construcţie

– Pentru software asta înseamnă proiectarea de detaliu, scriere şi depanare a codului

– Pentru hardware înseamnă proiectarea de detaliu, realizarea proiectului prototipului şi testarea circuitelor.

• Implementare nucleu MCU• Construcţie şi testare alte blocuri funcţionale ale arhitecturii. Dacă la

proiect lucrează o singură persoană, atunci blocurile funcţionale sunt completate secvenţial. Dacă există mai mulţi proiectanţi acestea se pot rezolva în paralel.

43

2. Implementarea arhitecturii

IMPLEMENTAREA SISTEMULUI

• Sarcinile presupuse pentru fiecare bloc funcţional includ proiectare hardware de detaliu şi construcţie, proiectare software de detaliu şi construcţie şi apoi integrarea hardware-software şi testarea

• Pot exista interdependenţe între proiectarea hardware şi software. Partea hardware nu poate fi testată până când o parte din software nu este gata, iar software nu poate fi testat până când partea din proiectul hardware nu este gata

• În mod tipic se construieşte hardware şi se testează minimal mai întâi. Apoi majoritatea efortului se concentrează pe scrierea de software şi testarea software pe hardware.

• Documentarea sistemului

44

3. Testarea sistemului

VERIFICARE ŞI TESTARE• Scop: verificare, testare, încorporare de informaţii de feedback pentru

corectarea neconformităţilor• Revizii:

– Reviziile sunt demonstraţii, inspecţii ale schemelor şi inspecţii ale codului

– Revizia trebuie făcută de specialişti independenţi, familiari cu proiectul (CERINŢE) şi tehnologiile, care să ajute la detectarea erorilor

– Se pot detecta omisiuni, erori• Testarea produsului final este o continuare a activităţilor de testare din

timpul proiectării, acestea put-nd fi urmărite conform documentaţiei elaborate la proiectare arhitecturală

• Testare publică - un proiect preliminar este distribuit unor beneficiar de la care se aşteaptă feedback (“beta testing”). Reacţia de la clienţi poate duce nu numai la detectarea unor erori, schimbarea codului, dar şi la schimbarea unor specificaţii. Nu e recomandată întotdeauna în domeniul EmS.

45

4. Furnizare prototip

FURNIZARE PRODUS FINAL ŞI MENTENANŢĂ

• Prototipul final şi integrarea constituie ultima fază a proiectării.• Este faza în care toate blocurile funcţionale sunt înglobate şi se

construieşte prototipul hardware final. De asemenea modulele software sunt combinate, iar codul este revizuit pentru a rula ca o aplicaţie de sine stătătoare pe prototip. Unele din componentele hardware şi software au fost deja construite şi testate pe un sistem de dezvoltare, înainte de această fază

• În funcţie de complexitatea sistemului de dezvoltare utilizat această ultimă fază poate fi un pas uşor de realizat, sau poate fi o operaţie complexă.

• În mediul competitiv actual multe din deciziile luate la proiectare se bazează pe re-utilizarea unor componente ale proiectelor deja existente. Astfel că ciclul de viaţă al unui proiect continuă şi după producţie şi el poate include mentenanţa produsului, raportarea bug-urilor şi arhivarea.

46

4. Furnizare prototip

FURNIZARE PRODUS FINAL ŞI MENTENANŢĂ

• Documentare:– Importantă atât pentru componentele hardware, dar şi mai

importantă pentru cele software. Permite detectarea uşoară a componentelor care conduc la neconformităţi cu cerinţele, permite comunicarea dintre membrii unei echipe, elaborarea rapoartelor cu privire la proiect, elaborarea documentaţiei finale a proiectului, permite reutilizarea componentelor proiectului pentru alte proiecte.

– Pentru software toate informaţiile referitoare la etapele anterioare, de la punerea problemei, elaborarea algoritmului şi a schemei logice (eventual diversele versiuni succesive indicând evoluţia programului)

– Sursa programului (cu comentarii suficiente pentru a se corela cu schema logică), eventuale eşantioane de date de intrare / ieşire, dacă este cazul

introducere În procesul de proiectare al …vega.unitbv.ro/~romanca/psci/2-psci-proiectare.pdf ·...

Documents