Documente online.
Zona de administrare documente. Fisierele tale
Am uitat parola x Creaza cont nou
 HomeExploreaza
upload
Upload




Informatica de gestiune (PSI) 2

economie


MFC_3_PSI_2_Nou

Informatica de gestiune (PSI) 2


TRUE/FALSE




Potrivit teoriei sistemelor, un organism economic nu este sistem. F




Modelul unui domeniu de activitate specializat din realitatea înconjurãtoare se obtine prin descrierea elementelor si fenomenelor din domeniul respectiv, reduse la caracteristicile lor esentiale.  A



Modelul unui produs software este o amplificare a realitãtii de informatizat la elementele si caracteristicile sale detaliate pentru domeniul de activitate cãruia îi este destinat produsul software care se proiecteazã.                      F



Proprietãtile si componentele elementelor reprezentate într-un  model software corespund realitãtii la modul general, fiind selectate numai aspectele necesare realizãrii obiectivului propus pentru produsul software care se proiecteaza.       A



Proprietãtile si componentele elementelor reprezentate într-un model software corespund realitãþii la nivel de detaliu, fiind selectate toate aspectele acestora, nu numai cele necesare realizãrii obiectivului propus pentru produsul software respectiv.                     F



Intr-un model, in locul elementelor reale se folosesc simboluri.    A



Modelul poate cuprinde numai planuri generale, care oferã o vedere de ansamblu asupra realitãtii de informatizat.       F


Modelul poate cuprinde numai planuri detaliate, care oferã o vedere de completa asupra realitãþii de informatizat        F


Modelul poate cuprinde atât planuri detaliate, cât si planuri generale, care oferã o vedere de ansamblu asupra realitãaii de informatizat.              A




Un model bun include toate elementele cu efecte largi asupra domeniului de activitate de informatizat si omite toate acele elemente care nu sunt relevante în plan abstract.                     A




Un model bun include toate elementele domeniului de activitate de informatizat,  inclusiv toate acele elemente care nu sunt relevante în plan abstract.                F



Un model bun omite toate acele elemente din domeniul de informatizat care nu sunt relevante în plan abstract.             A



Un model bun include toate elementele cu efecte largi asupra domeniului de activitate de informatizat.       A



Modelul este o abstractizare care exprimã esentialul sau structura unei probleme complexe, eliminând detaliile neesentiale, lucru care face problema mai usor de înteles.                        A


Modelul nu este o abstractizare a realitatii de informatizat, nu exprimã esentialul sau structura acesteia.      F



Modelul este o abstractizare care exprimã esentialul sau structura unei probleme complexe.  A



Modelul este o abstractizare care elimina detaliile neesentiale, lucru care face problema de rezolvat mai usor de înteles.                       A



Pentru a dezvolta produse software complexe, informaticienii trebuie sã abstractizeze diferitele aspecte sau vizualizãri ale domeniului de activitate de informatizat.                  A



Pentru a dezvolta produse software complexe, informaticienii trebuie sã construiascã modele folosind notatii precise.              A



Pentru a dezvolta produse software complexe, informaticienii trebuie sã verifice cã modelele satisfac cerintele impuse produsului software de utilizatorii sãi .                  A



Pentru a dezvolta produse software complexe, informaticienii trebuie sã adauge detalii pentru transformarea modelelor în programe executabile.                     A



Pentru a dezvolta produse software complexe, informaticienii trebuie sã abstractizeze diferitele aspecte sau vizualizãri ale domeniului de activitate de informatizat, sã construiascã modele folosind notatii precise, sã verifice cã modelele satisfac cerintele impuse produsului software de utilizatorii sãi si, treptat, sã adauge detalii pentru transformarea modelelor în programe executabile. A



Pentru a dezvolta produse software complexe, informaticienii nu trebuie sã abstractizeze diferitele aspecte sau vizualizãri ale domeniului de activitate de informatizat, trebuie in schimb sã construiascã modele folosind notatii precise,  sã verifice cã modelele satisfac cerintele impuse produsului software de utilizatorii sãi si, treptat,  sã adauge detalii pentru transformarea modelelor în programe executabile.               F


Pentru a dezvolta produse software complexe, informaticienii nu trebuie sã abstractizeze diferitele aspecte sau vizualizãri ale domeniului de activitate de informatizat, sã construiascã modele folosind notaþii precise, trebuie in schimb sã verifice cã modelele satisfac cerintele impuse produsului software de utilizatorii sãi si, treptat, sã adauge detalii pentru transformarea modelelor în programe executabile.               F



Programarea este procesul de reprezentare a realitãtii înconjurãtoare în calculator, sub formã de programe.              A



Programarea este procesul de reprezentare a realitãtii înconjurãtoare în calculator, sub formã hexazecimala.              F



In procesul de abstractiyare, elementele care sunt nerelevante pentru realitatea de reprezentat sunt eliminate.              A


Orice domeniu de activitate poate fi descris din diferite puncte de vedere, folosind diferite modele.           A



Orice domeniu de activitate poate fi descris dintr-un singur punct de vedere, folosind un singur model.      F


Pentru fiecare aspect din realitate, semnificativ pentru dezvoltarea de software, se construieste un model care reprezintã practic o abstractizare semanticã a domeniului respectiv.                      A



Pentru fiecare aspect din realitate, semnificativ pentru dezvoltarea de software, se construiesc mai multe modele care reprezintã practic mai multe abstractizari semantice ale domeniului respectiv.                        F


Pentru toate aspectele din realitate, semnificative sau nu pentru dezvoltarea de software, se construieste un model care reprezintã practic o abstractizare semanticã a domeniului respectiv.

F


Toate modele care descriu fiecare un aspect din realitatea de infornatizat semnificativ pentru dezvoltarea de software, formeazã împreunã modelul semantic al domeniului de activitate pe baza cãruia se implementeazã produsul software.                        A



Fiecare model care descrie un aspect din realitatea de informatizat semnificativ pentru dezvoltarea de software,  formeazã  modelul semantic al domeniului de activitate pe baza cãruia se implementeazã produsul software.              F



Modelul este schema unui sistem care ajutã la proiectarea sistemului respectiv, înainte de a-l construi.       A


Modelul este schema unui sistem pe baza caruia se face abstractizarea si mmodelarea sistemului respectiv.              F



Modelul este schema unui sistem, realizatã dupa construirea sa, care se foloseste pentru proiectarea documentatiei sistemunui respectiv.                     F



În procesul de dezvoltare software, modelul este folosit pentru a stabili, înainte de realizare, dacã proiectul este bun, dacã cerintele impuse produsului software de utilizatorii sãi sunt îndeplinite si dacã produsul software respectiv este suficient de stabil si de flexibil, în conditiile în care aceste cerinte se modificã continuu.        A


În procesul de dezvoltare software, modelul este folosit pentru a stabili, dupã realizare, dacã proiectul este bun, dacã cerintele impuse produsului software de utilizatorii sãi sunt îndeplinite si dacã produsul software respectiv este suficient de stabil si de flexibil, în conditiile în care aceste cerinte se modificã continuu.                       F


În procesul de dezvoltare software, modelul este folosit pentru a stabili, înainte de realizare, dacã proiectul este bun.                        A


În procesul de dezvoltare software, modelul este folosit pentru a stabili, înainte de realizare,  dacã cerintele impuse produsului software de utilizatorii sãi sunt îndeplinite.                    A


În procesul de dezvoltare software, modelul este folosit pentru a stabili, înainte de realizare,  dacã produsul software respectiv este suficient de stabil si de flexibil, în condiþiile în care cerinte utilizatorului se modificã continuu.              A


Modelul unui sistem economic nu se foloseste in procesul de dezvoltare software, ci numai in procesul de abstractizare.                  F


În procesul de dezvoltare software, abstractizarea modelului semantic este esentiala pentru a stabili, înainte de realizare, dacã proiectul este bun, dacã cerintele impuse produsului software de utilizatorii sãi sunt îndeplinite si dacã produsul software respectiv este suficient de stabil si de flexibil, în conditiile în care aceste cerinte se modificã continuu.                        F


           45.         Abstractizarea este procesul de modelare al unui sistem informatic.                      F



Schema unui sistem informatic defineste structura acestuia.                     F



Abstractizarea este capacitatea fundamentalã a omului  care-i permite sã simplifice complexitatea lumii reale pentru a o întelege.                     A



Abstractizarea este capacitatea fundamentalã a omului care-i permite sã reprezinte complexitatea lumii reale, cu cele mai mici detalii, pentru a o explica tuturor.                       F



Specialistii din orice domeniu de activitate (ingineri, artisti, designeri, informaticieni) construiesc modele ale sistemelor, înainte de a le executa.                       A



Specialistii din orice domeniu de activitate (ingineri, artisti, designeri, informaticieni) construiesc modele ale sistemelor, înainte de a le executa, numai dacã doresc, acestea neavand nici o semnificatie in executia sistemelor respective.                     F


Potrivit conceptului de orientat -obiect, toate elementele lumii reale, înconjurãtoare, sunt obiecte, mai mult sau mai putin complexe care, în plan abstract, sunt reduse la caracteristicile lor reprezentative pentru domeniul de studiat.               A



Pentru vizualizarea sistemului în întreaga sa complexitate, se realizeazã un set de modele practic independente care, împreunã, formeazã modelul sistemului software, fiecare model din set reprentand vizualizarea sistemului respectiv dintr-un anumit punct de vedere.                      A



Modelul vizual al produsului software care trebuie proiectat, realizat folosind UML, constã atât dintr-o semanticã, cât si din vizualizãrile acestei semantici de cãtre utilizator.                    A



UML oferã notatii si semantici standard pentru descrierea structurii si comportãrii unui obiect, dar nu s-a dovedit a fi  un mediu de proiectare potrivit pentru dezvoltarea aplicatiilor obiect distribuite de dimensiuni mari si foarte mari.                                F



Modelarea urmãreste întelegerea sistemului si un model este suficient de bun, motiv pentru care, nu este nevoie de mai multe modele conectate între ele pentru pentru realizarea unui sistem.                         F




Lucrurile care se exprimã cel mai bine în mod grafic sunt reprezentate în mod grafic în UML, în timp ce lucrurile care se exprimã cel mai bine în modul text sunt reprezentate direct în limbajul de programare. Aceastã mapare permite specialistilor sã genereze cod de program din modelul UML folosind un limbaj de programare si invers. Se poate reconstrui un model UML dintr-o implementare fãcutã cu ajutorul unui limbaj de programare, folosind instrumente de programare suport care necesitã interventia umanã. Dar informatia care nu a fost codificatã la implementare se pierde la reconstrucþia modelului UML. Combinarea celor douã cãi de trecere de la modelele UML la codul de program generat folosind un limbaj de programare si invers, conduce la abilitatea de a lucra atât cu vizualizãri grafice, cât si cu reprezentãri textuale, utilizând instrumentele software create în acest scop.                       A



UML nu se limiteazã numai la modelarea software. Este suficient de expresiv pentru modelarea sistemelor nonsoftware, ca de exemplu  fluxul de lucru într-un sistem legislativ, structura si comportarea unui sistem medical sii proiectarea de sisteme hardware.                        A



           58.         Prin folosirea culorilor, un model poate oferi o vedere de ansamblu, nu si una de detaliu în acelasi timp, fãrã a fi nevoie de alte reprezentãri, deoarece culoarea dã fiecãrui model senzaþia de spaþiu, dar nui îi sporeste continutul.      F



MULTIPLE CHOICE


Modelarea informala se foloseste pentru:

a.

sistemele informatice simple;

b.

sistemele informatice complexe;

c.

toate tipurile de sisteme informatice.




Modelele informale se caracterizeaza prin accea ca:

a. se construiesc ad-hoc, de fiecare programator în parte;

b. nu oferã un limbaj comun care sã poatã fi folosit si de altii ;

c. nu transmit mai departe experienta acumulatã în domeniu;

d. folosesc un limbaj comun de modelare, accesibil tuturor informaticienilor.

a.

a

b.

a+b+c

c.

d

d.

a+d




Modelele formale se caracterizeaza prin accea ca:

a. se construiesc ad-hoc, de fiecare programator în parte;

b. nu oferã un limbaj comun care sã poatã fi folosit si de altii ;

c. nu transmit mai departe experienta acumulatã în domeniu;

d. folosesc un limbaj comun de modelare, accesibil tuturor informaticienilor.

a.

a+d

b.

d

c.

b+c




Modelele formale pot fi:

a.

structurale

b.

comportamentale

c.

structurale si comportamentale




Un model bine realizat ajutã la:

a. întelegerea domeniului de activitate pentru care se proiecteazã produsul software;

b. proiectarea, vizualizarea, crearea si implementarea unor produse software flexibile si    usor de întretinut, în conditii de eficientã economicã maximã si timp de lucru minim;

c. îmbunãtãtirea comunicatiei între toti cei implicati în proiect: clienti, experti în domeniu, analisti, proiectanti, utilizatori, auditori, etc.


a.

c

b.

a

c.

b

d.

a+b+c




Modelarea proceselor de dezvoltare software a diferitelor domenii de activitate din realitatea înconjurãtoare are ca rezultat crearea unor modele care:

a. reprezintã, în plan abstract, structura sau comportamentul unor domenii de activitate cu grad mare de complexitate;

b. documenteazã toate deciziile luate cu privire la dezvoltarea unui produs software;

c. oferã tuturor celor interesati exemple de dezvoltare produse software complexe.

a.

a+b+c

b.

c

c.

b

d.

a




Principiile care stau la baza procesului de modelare a produselor software sunt:

a. crearea unui model care influenteazã modul de rezolvare al problemei date si forma în care poate fi prezentatã solutia acesteia;

b. exprimarea fiecãrui model pe diferite nivele de detaliu;

c. crearea unor modele conectate la realitate;

d. modelul oricaui sistem trebuie conceput dintr-un set de modele independente;

e. este suficient un singur model.

a.

d

c.

a+b+c+d

b.

e

d.

a+b+c+e




Stiind ca tehnicile de modelare folosite în dezvoltarea de software afecteazã viziunea proiectantului asupra realitãtii de informatizat, precizati care dintre afirmatiile urmatoare este adevarata:

a. pentru construirea unui sistem informatic, un proiectant de baze de date utilizeazã modele entitate- asociere (Merise) /eveniment rezultat;

b. pentru construirea unui sistem informatic, un analist programator utilizeaza modele concentrate pe algoritmi, în care datele trec de la un proces la altul;

c. pentru construirea unui sistem informatic, un proiectant de sisteme orientate -obiect utilizeaza obiecte si clase de obiecte care interactioneazã între ele;

d. pentru construirea unui sistem informatic toti proiectantii utilizeaza obiecte si clase de obiecte care interactioneazã între ele.

a.

d

d.

b

b.

a+b+c

e.

c

c.

a

 




Metoda de proiectare orientatã -obiect se bazeaza pe cunoasterea conceptelor software fundamentale care o definesc, dintre care cele mai importante sunt: 

a.

obiect, clasã, încapsulare, mostenire, polimorfism;

c.

clasã;

b.

obiect;

d.

obiect, clasã.


Obiectul este o constructie software:

a. în care operatiile (functii sau proceduri) sunt organizate în jurul unui set de variabile (date) care de fineste generic un element din domeniul de activitate pentru care se realizeazã produsul software;

b. care are identitate proprie (are un nume propriu si caracteristici prin care se deosebeste de alte obiecte);

c. care are stare proprie (definitã de setul de date asociate lui);

d. care are comportare (definitã de actiunea sa asupra altor obiecte si de actiunea altor obiecte asupra sa).

a.

a



b.

a+b

c.

a+b+c+d

d.

c+d




Clasa descrie:

a.  structura unui set de obiecte similare- asemãnãtoare;

b. comportarea unui set de obiecte similare- asemãnãtoare.

a.

a

b.

b

c.

a+b




Folosind notatiile UML, clasele si obiectele se reprezintã grafic prin

a.

calsele prin patrate si obiectele prin dreptunghiuri

c.

clasele se reprezinta grafic prin dreptunghiuri, obiectele nu au reprezentare grafica

b.

dreptunghiuri

d.

nici una nu se reprezinta grafic.




           13.         Obiectele unei clase au proprietati semnificative pentru exprimarea carora se folosesc:

a. atribute: exprima structura obiectelor;

b. operatii: esprima comportarea obiectelor;

c. constrangeri: exprima conditiile, cerintele si regulile pe care trebuie sã le respecte obiectele.

a.

c

b.

a

c.

a+b+c

d.

b




Modelarea vizualã constã în procesul de a afisa informaþia dintr-un model:

 într-o formã graficã, folosind un set standard de elemente grafice.

a.

într-o formã graficã, folosind un set specific de elemente grafice;

b.

într-o formã graficã, folosind un set standard de elemente grafice;

c.

într-o formã graficã, folosind elemente rafice arbitrar alese.




Comunicarea între utilizatori, proiectanti, analisti si oricine altcineva care este implicat în dezvoltarea unui sistem informatic este mai eficientã dacã informaþia de modelat: se reprezintã :

a.

 în format text-  nonvizual

b.

 într-un format grafic- vizual

c.

 în format textsi grafic.




Un modelul vizual constãdin:

a.

vizualizãrile semanticilor de cãtre utilizator

b.

semantici si din vizualizãrile acestor semantici de cãtre utilizator.

c.

semantici




Semanticile produsului software în curs de dezvoltare exprimã urmatoarele aspecte primare ale unui produs software:

a. structural: identificã elementele care formeazã produsul software;

b. comportamental: defineste modul în care elementele structurale lucreazã si interactioneazã în executia unui produs software;

c. functional: exprimã comportarea cerutã de utilizator.

a.

a

b.

a+b+c

c.

b

d.

b+c




Pentru a întelege arhitectura unui sistem software orientat pe obiect trebuie realizate câteva modele, cãrora le corespund urmatoarele vizualizãri complementare, care se interconecteazã intre ele:

a. o vizualizare a cazurilor de utilizare, care prezintã cerintele pe care trebuie sã le ofere sistemul utilizatorilor sãi;

b. o vizualizare a proiectului software,  care prezintã problematica domeniului de informatizat împreunã cu solutia sa;

c. o vizualizare a procesului , care prezintã distributia proceselor sistemului si succesiunea timp a acestora;

d. o vizualizare a implementãrii sistemului, care prezintã realizarea fizicã a sistemului;

e. o vizualizare a exploatãrii sistemului, care prezintã iesirile sistemului din punct de vedere tehnic.


a.

a+c+e

b.

b+d

c.

nu trebuie

d.

a+b+c+d+e




Succesul unui proiect software este dat de utilizarea urmatoarele elemente:

a. un instrument de dezvoltare software (pachet de programe utilitare folosite pentru realizarea proiectului software);

b. o notatie (sistem de notatie);

c. un proces de dezvoltare software (proces de realizare a unui proiect software).

a.

a

b.

a+b+c

c.

b




           20.         Notatia are urmatoarele roluri:

a. serveste ca limbaj de comunicare a deciziilor care nu sunt evidente sau nu pot fi deduse din programul sursã (codul de program);

b. furnizeazã semantici suficient de bogate pentru a exprima deciziile tactice si strategice cele mai importante cu privire la realizarea unui proiect software;

c. oferã o formã concretã a proiectului software suficient de sugestivã pentru a stimula gândirea umanã si pentru a fi manipulatã de instrumentele de dezvoltare software.

a.

a

b.

c

c.

a+b+c

d.

b




Procesul de dezvoltare software trebuie:

a. sã satisfacã asteptãrile clientului, poate chiar sã le depãseascã;

b. sã se desfãsoare pe perioada de timp planificatã;

c. sã conducã cea mai economicã formã de proiect;

d. sã fie flexibil, usor adaptabil la schimbãrile ce apar pe perioada sa de desfãsurare;

e. sã aibã un ciclu de viaþã care stimuleazã creativitatea si inovatia specialistilor în domeniu, bine gestionat pentru a asigura controlul necesar fãrã a afecta creativitatea;

f. sã poatã fi controlat si mãsurat pentru siguranta cã este complet.

a.

b+c+d

b.

b

c.

c+d

d.

a+b+c+d+e+f



Modelele vizuale pot arãta cum lucreazã sistemul pe câteva nivele. Se poate (pot) modela: 

a.

interactiunea dintre sistem si utilizatori;

b.

interactiunea obiectelor în interiorul sistemului;

c.

interactiunile dintre sisteme;

d.

interactunile dintre sistem si utilizatori, dintre obiecte în interiorul sistemului si chiar dintre sisteme.



Pentru a asigura succesul unui proiect software (proiect de sistem informatic) este necesarã utilizarea urmatoarelor elemente:

a.

o notatie (sistem de notatie);

b.

un proces de dezvoltare software (proces de realizare a unui proiect software);

c.

un instrument de dezvoltare software (pachet de programe utilitare folosite pentru realizarea proiectului software);

d.

o notatie, un proces de dezvoltare software si un instrument de dezvoltare software;

e.

o notatie si un proces de dezvoltare software.




Notatia are urmatoarele roluri:

a. serveste ca limbaj de comunicare a deciziilor care nu sunt evidente sau nu pot fi deduse din programul sursã (codul de program);

b. furnizeazã semantici suficient de bogate pentru a exprima deciziile tactice si strategice cele mai importante cu privire la realizarea unui proiect software;

c. oferã o formã concretã a proiectului software suficient de sugestivã pentru a stimula gândirea umanã si pentru a fi manipulatã de instrumentele de dezvoltare software.


a.

a+c

c.

b+c

b.

a+b+c

d.

a




Cele mai populare notatii sunt:

1.Universal Modeling Language- UML;

2.Booch

3.Object Modeling Technology- OMT


a.


b.


c.


d.


e.





Procesul de dezvoltare software trebuie:

1. sã satisfacã asteptãrile clientului, poate chiar sã le depãseascã;

2. sã se desfãsoare pe perioada de timp planificatã;

3. sã conducã cea mai economicã formã de proiect;

4. sã fie flexibil, usor adaptabil la schimbãrile ce apar pe perioada sa de desfãsurare;

5. sã aibã un ciclu de viatã care stimuleazã creativitatea si inovatia specialistilor în domeniu, bine gestionat pentru a asigura controlul necesar fãrã a afecta creativitatea;

6. sã poatã fi controlat si mãsurat pentru siguranta cã este complet.


a.


c.


b.


d.





Procesul de dezvoltare software se poate desfãsura în mai multe feluri. Existã mai multe tipuri de procese de realizare a unui proiect software, fiecare cu avantajele si dezavantajele sale, cele mai populare fiind:


a.

modelul cascadã;

b.

modelul cascadã, modelul iterativ si incremental;

c.

modelul iterativ;

d.

modelul iterativ si incremental.

e.

modelul incremental.




Cea mai mare limitare a modelului cascada este datã de faptul cã nu se poate reveni la pasii parcursi, în conditiile în care, la sfârsitul procesului respectiv, se constatã deseorii cã:

o parte din cerintele stabilite în faza de analizã s-au modificat;

arhitectura stabilitã în etapa de proiectare s-a schimbat (software- ul nu se mai instaleazã în aceleasi locatii, iar hardware- ul nu corespunde performantelor software-ului proiectat);

în programul sursã nu se pot implementa anumite decizii luate în faza de proiectare;

anumite cerinte nu au fost suficient detaliate pentru a putea fi testate în etapa de testare;

pe perioada dezvoltãrii software-ului, domeniul de activitate pentru care s-a proiectat acesta s-a modificat si, ca rezultat, proiectul nu mai corespunde nevoilor clientului.


a.


c.


b.


d.





principalele caracteristicile ale modelului iterativ si incrementalconstau în:

1. împãrþirea tuturor activitãþilor în unitãti mai mici, cu diverse nivele de detaliu;

2. împãrtirea  proiectului în module care se interconecteazã cu alte module ale ansamblului, la diverse nivele de detaliu;

3. posibilitatea de proiectare, de la nivel general la detaliu, a modulelor produsului software în functie de prioritãtile si cerintele domeniului de activitate cãruia îi este destinat;

4. posibilitatea de revenire la pasii parcursi din etapele ciclului de viatã al produsului software care se proiecteazã, analizã cerinte- proiectare- dezvoltare- testare si exploatare software, pentru efectuarea de modificãri.


a.


c.


b.


d.





Sistemele informatice complexe pot fi dezvoltate usor folosind urmãtoarele trei tipuri de diagrame UML, celelalte tipuri de diagrame putând fi folosite pentru a modela aspecte suplimentare ale sistemului:

a.

diagrame de clase, diagrame de activitãti, diagramede desfãsurare;

b.

diagramele de clase, diagrame de stãri, diagramele de secvente;

c.

diagrame de utilizari (usecase), diagramele de secvente, diagrame de desfãsurare.




Modelul produsului software care se proiecteazã cu ajutorul UML trebuie sã fie:

a.

complet;

c.

complet si consistent;

b.

complet, consistent si precis;

d.

consistent.




Generarea automatã a programelor sursã oferã urmãtoarele avantaje majore proiectantilor de produse software:

1. reducerea efortului de generare programe sursã;

2. asigurarea consistentei între modelul UML si programul sursã care conduce la obtinerea produsului software final;

3. posibilitatea de revenire de la programul sursã la modelul UML în vederea integrãrii modificãrilor determinate de schimbãrile produse la nivelul domeniului de activitate pentru care s-a dezvoltat produsul software respectiv.

a.


b.


c.





           33.         Arhetipul se defineste ca fiind forma sau modelul unei categorii de clase de obiecte care, pentru calsele din categoria respectiva, specifica:

a.

atributele, legãturile (link-urile), metodele si punctele de plug-in tipice;

b.

punctele de plug-in tipice;

c.

metodele si punctele de plug-in tipice;



d.

atributele si punctele de plug-in tipice;




           34.         In procesul de modelare se poate folosi culoarea pentru:

1. etichete adãugate nivelelor informatiei; exemplu: nivele ale claselor cu caracteristici similare;

2. indicarea progresului în timp; exemplu: folosirea de luminozitãti diferite ale pentru a sugera evoluþia în timp;

3. reprezentarea categoriilor de informatie într-un model;

4. adãugarea impactului vizual al modelului, foarte important pentru cã modelarea este prin natura sa o activitate vizualã.


a.


b.


c.


d.





           35.         Caracteristicile unui arhetip includ:

1. atribute si legãturile dintre atribute;

2. metode;

3. legãturi (link-uri) cu alte arhetipuri;

4. puncte de plug- in, pentru conectarea la interfete.


a.


b.


c.


d.


e.





YES/NO


Pentru sistemele informatice simple se face, de regulã, o modelare formalã. Modelele formale sunt construite ad-hoc, de fiecare programator în parte si nu oferã un limbaj comun care sã transmitã mai departe experienta acumulatã în domeniu?                NU


Pentru sistemele informatice complexe se construiesc modele formale, care folosesc un limbaj comun de modelare, accesibil tuturor informaticienilor?                   DA



Pentru a fi eficient si util, modelul unui sistem informatic trebuie sã fie format din mai multe modele construite, fiecare, pentru reprezentarea unui singur aspect semnificativ al domeniului de informatizat?                        DA



S-a demonstrat cã cele mai bune modele sunt acelea care permit selectarea nivelului de detaliu în functie de cine face vizualizarea si de ce trebuie sã vadã. Pe analistul de sistem îl intereseazã iesirile produsului software pentru a stabili cerintele pe care trebuie sã le respecte produsul respectiv, în prima parte a procesului de dezvoltare software, iar pe utilizatorul final îl intereseazã iesirile produsului software pentru utilizarea eficientã a acestuia, în ultima parte a procesului de dezvoltare software?                     DA



Secretul construirii unui model eficient si util constã  în simplificarea realitãtii fãrã a ascunde (masca) detalii importante pentru procesul modelat?                   DA



Tehnicile de analizã a sistemelor orientate pe obiect fac posibilã conectarea tuturor vederilor independente ale sistemului într-un singur întreg semantic?              DA



Tehnicile de analizã structurate separa modelul de analizã si modelul de proiectare al unui sistem, modele care se creeazã independent unul de altul. Conectarea gresitã a celor douã, la sfârstul procesului de modelare, face ca sistemul astfel conceput  sã fie instabil în timp?     DA


Potrivit conceptului de structural, toate elementele lumii reale, înconjurãtoare, sunt obiecte, mai mult sau mai putin complexe care, în plan abstract, sunt reduse la caracteristicile lor reprezentative pentru domeniul de studiat?   NU



Dezvoltarea produselor software cu baze de date nu reprezinta, în contextul actual, un proces social complex, deoarece analiza de sistem presupune cunoasterea fara detalii a domeniului de activitate pentru care se dezvoltã produsul respectiv, care trebuie translatat într-un mediu abstract, la acest proces nefiind necesara decat participarea informaticienilor, nu si a specialistilor în domeniu si utilizatorilor?                    NU



Dezvoltarea produselor software cu baze de date este, în contextul actual, un proces social complex deoarece analiza de sistem presupune cunoasterea profundã a domeniului de activitate pentru care se dezvoltã produsul respectiv, care trebuie translatat într-un mediu foarte abstract, la acest proces participând împreunã informaticieni, specialisti în domeniu si utilizatori?             DA



Astãzi, dezvoltarea de software se face numai pe baza conceptului de orientat -obiect, caz în care blocul cel mai important al întregului software este obiectul?                        DA



Un produs software orientat- obiect sau obiectural consta dintr-o multime de obiecte software, împreunã cu clasele cãrora le apartin, cu relatiile dintre acestea si cu elementele software auxiliare de tip entitati si evenimente?   NU



Un produs software orientat- obiect sau obiectural constã într-o multime de obiecte software, împreunã cu clasele cãrora le apartin si relatiile dintre acestea?                        DA



În dezvoltarea produselor software orientate -obiect se lucreazã cu elemente (obiecte sau seturi de obiecte) care pot fi utilizate si reutilizate într-o multime de aplicatii, proiectantii concentrându-se numai asupra a ceea ce este unic în fiecare aplicatie?  DA


Conceptul de orientare pe obiect exprimã un nou mod de vizualizare si reprezentare a produselor software potrivit cãruia orice produs software este format din mai multe elemente (obiecte sau seturi de obiecte), practic independente, prin combinarea si interconectarea cãrora se poate construi orice alt produs software?                   DA



Posibilitatea de a construi odatã componentele si de a le reutiliza ori de câte ori este necesar, reprezintã un avantaj major care a impus utilizarea conceptului de proiectare orientatã -obiect în dezvoltarea de produse software?              DA



           17.         In model, obiectele nu sunt considerate ca entitãti individuale. Pentru obiectele similare se creeazã un grup, care în terminologie orientata obiect e numit Clasã?                       DA



           18.         Clasele si obiectele se reprezintã grafic folosind notatiile UML, adicã dreptunghiuri. Pentru a se deosebi clasele de obiecte, numele obiectelor sunt subliniate?                    DA




           19.         Obiectul este instanta care este prezentã la momentul executiei si care se comportã conform protocolului specific clasei sale?                     DA


Incapsularea reprezinta actiunea prin care se impacheteaza intr-un obiect datele impreuna cu comportarea lor specifica?                  DA



Incapsularea reprezinta actiunea prin care se impacheteaza intr-un obiect datele impreuna cu structura, comportarea si starea lor specifica?                    NU



           22.         Mostenirea este mecanismul care permite crearea de obiecte noi, bazate pe un obiect deja creat, astfel încât obiectele copil mostenesc caracteristicile obiectului pãrinte?                    DA



           23.         Principalul dezavantaj oferit de mostenire este întretinerea sistemului care foloseste acest mecanism


NU


Pentru vizualizarea sistemului în întreaga sa complexitate, se realizeazã un set de modele practic independente dar care, împreunã, formeazã modelul sau schema sistemului software respectiv. Fiecare model reprezintã vizualizarea sistemului dintr-un anumit punct de vedere, sub un anumit aspect, si fiecare dintre aceste vizualizãri are o structurã si o comportare proprie?                              DA


Se poate învãta notatia dar, dacã nu se cunoaste procesul de dezvoltare software, e posibil ca proiectul software sã fie gresit?                 DA



Dacã se foloseste un proces de dezvoltare software foarte bun, dar nu se poate comunica pentru cã lipseste notatia, e posibil ca proiectul software sã fie gresit?         DA


Dacã nu se pot documenta metodologiile de lucru  (instrumentele de dezvoltare software folosite),  e posibil ca proiectul software sã fie gresit?           DA



Notatia graficã joacã un rol important în modelarea vizualã fiind folositã pentru reprezentarea graficã a diferitelor aspecte ale software- ului (sistemului informatic) pentru dezvoltarea cãruia se realizeazã proiectul software?  DA     



Procesul de dezvoltare software reprezintã procesul de realizare a unui proiect software, prin proiect software întelegând proiectul de realizare a unui sistem informatic?                       DA



Potrivit Visual modeling with Relational Rose 2000 and UML, triunghiul succesului. unui produs software este format dintr-o notatie (sistem de notatie), un proces de dezvoltare software (proces de realizare a unui proiect software) si un instrument de dezvoltare software (pachet de programe utilitare folosite pentru realizarea proiectului software)?     DA


Procesul de dezvoltare software stabileste ce modele trebuie create si când trebuie create?  DA



Modelul cascada poate fi folosit în dezvoltarea de software pentru domenii de activitate complexe, aflate în continuã schimbare?  NU



Procesul Unificat Relational constã într-un set foarte cuprinzãtor de indicatii cu privire la aspectele tehnice si organizatorice ale dezvoltãrii de sisteme software, focalizat pe analiza cerintelor sistemului si pe proiectarea acestuia?  DA     



Fiecare metodã de dezvoltare software este suportatã de un instrument de dezvoltare?   DA



Relational Rose suportã numai unul din cele trei sisteme de notare: Booch, Object Modeling Technology- OMT si Universal Modeling Language- UML?               NU



Desi nu este un limbaj de modelare particular si nu are un singur furnizor, UML este un standard de modelare a produselor software?  DA


Modelul unui produs software constã atât din semanticã cât si din toate vizualizãrile acestei semantici de cãtre utilizator. O vizualizare exprimã partea semanticii care corespunde unui anumit nivel de abstractizare a domeniului de informatizat?         DA



Limbajul furnizeazã un vocabular si regulile de combinare a cuvintelor din acest vocabular cu scopul comunicãrii. Un limbaj de modelare este un limbaj cu vocabular si reguli focalizate pe reprezentarea conceptualã si fizicã a unui produs software?                       DA



Utilizarea UML conduce la realizarea model explicit care usureazã comunicarea?                       DA



UML este un limbaj de modelare insuficient de expresiv si precis pentru a permite executia directã a modelelor,  simularea sistemelor si instrumentarea sistemelor functionale?       NU



UML contine si un cadru organizaþional de aranjare a modelelor în pachete, care permit echipelor software sã partitioneze sisteme mari în subsisteme, sã înteleagã si sã controleze dependenþele între pachete si sã gestioneze versiunile unitãtilor model într-un mediu de dezvoltare complex?              DA



UML nu este un limbaj de programare?             NU



UML este un limbaj formal care urmãreste furnizarea de teoreme?                     NU



UML este un limbaj de modelare general valabil?                      DA




           45.         Arhetipul se defineste ca fiind forma sau modelul unei categorii de clase de obiecte?         DA



           46.         Utilizarea culorilor sporeste nivelele continutului care se exprimã, face ca aceste nivele sã fie vizibile de la distanþã si observabile înainte de citirea detaliilor?             DA



           47.         Folosirea culorilor creeazã senzatia de spatiu, numai în constructia modelelor , nu si  în citirea (întelegerea) lor?              NU



           48.         Se foloseste culoarea alb, in mod ocazional, pentru reprezentarea în model a notelor, punctelor de plug- in si a interactiunilor apropiate ale sistemului?                 DA



NUMERIC RESPONSE


           1.           Cate tipuri de arhetipuri pe baza cãrora se creeazã o componentã independentã de domeniu s-au identificat?


ANS: 



COMPLETION


Modelele formale pot fi:

-           .....................: bazate pe modul de organizare al sistemelor care se modeleazã;

-           .....................: bazate pe dinamica sistemelor care se modeleazã.


ANS: 

structurale

comportamentale


este o constructie software în care operatiile (functii sau proceduri) sunt organizate în jurul unui set de variabile (date) care defineste generic un element din domeniul de activitate pentru care se realizeazã produsul software.


ANS:  Obiectul


Fiecare ______________are identitate proprie (are un nume propriu si caracteristici prin care se deosebeste de alte obiecte), stare (definitã de setul de date asociate lui) si comportare (definitã de actiunea sa asupra altor obiecte si de actiunea altor obiecte asupra sa).


ANS:  obiect


_________________descrie structura si comportarea unui set de obiecte similare- asemãnãtoare, in model, obiectele nefiind reprezentate ca entitãti individuale, obiectele similare fiind grupate împreunã.


ANS:  Clasa


Modelarea _______________ constã în procesul de a afisa informatia dintr-un model într-o formã graficã, folosind un set standard de elemente grafice.


ANS:  vizuala


Comunicarea între utilizatori, proiectanti, analisti si oricine altcineva care este implicat în dezvoltarea unui sistem informatic este mai eficientã dacã informatia de modelat se reprezintã într-un format __________ deoarece omul este capabil sã înteleagã mai bine complexitatea când este afisatã vizual.


ANS:  grafic


Pentru vizualizarea sistemului în întreaga sa complexitate, se realizeazã un set de _____________ practic independente dar care, împreunã, formeazã modelul sau schema sistemului software respectiv.


ANS:  modele


Notatia ______________ joacã un rol important în modelarea vizualã fiind folositã pentru reprezentarea graficã a diferitelor aspecte ale software- ului (sistemului informatic) pentru dezvoltarea cãruia se realizeazã proiectul software.


ANS:  grafica


Procesul de dezvoltare software reprezintã procesul de realizare a unui ____________software, prin proiect software întelegând proiectul de realizare a unui sistem informatic.


ANS:  proiect


În modelul ________________, care a reprezentat metodologia de documentare pentru foarte multe proiecte software realizate prin metode traditionale, se parcurg succesiv etapele de analizã cerinte, proiectare, dezvoltare, testare si exploatare software, întelegând prin software sistemul informatic care se proiecteazã.


ANS:  cascada


Modelul iterativ si incremental, care reprezintã metodologia de documentare pentru proiecte software realizate prin metoda orientatã pe obiect, constã într-o serie de _____________ incrementale, evoluând cãtre produsul software finit.


ANS:  iteratii


Modelul iterativ si incremental descrie ciclul de viatã al unui proiect software iterativ care  se dezvoltã progresiv (în pasi, incremental),  pe mãsurã ce se desfãsoarã procesul de dezvoltare software cu arhitecturã _______________ pe obiect (obiecturalã).


ANS:  orientata


Procesul Relational Unificat -  Relational Unified Process (RUF) este modelul de proces, _____ _______ ______ _________ cu arhitecturã orientatã pe obiect, cel mai utilizat pentru realizarea de proiecte software dedicate unor domenii de activitate complexe, aflate într-o continuã schimbare si dezvoltare.


ANS:  iterativ- incremental


Existã multe instrumente de dezvoltare _______________ pe piatã, de la simple instrumente de desenare, pânã la instrumente de modelare obiect sofisticate.


ANS:  software


Familia de produse Relational Rose oferã un ___________________ de dezvoltare software, cu un set complet de instrumente de modelare vizuale, pentru generarea unor solutii eficiente si robuste necesare mediului real de afaceri de tip client- server, organizatie distribuitã în spatiu si sisteme în timp real.


ANS:  instrument


Diagramele UML sunt modele ______________ care, fiecare reprezintã grafic un aspect al domeniului de activitate si care, împreunã, formeazã modelul vizual al acelui domeniu, respectiv imaginea sa graficã de ansamblu (întreaga sa complexitate).


ANS:  vizuale


Diagramele UML folosesc pentru reprezentarea graficã a domeniului de activitate  notatia ___________________ Universal Modeling Language- UML, devenitã standard industrial în lumea produselor software.


ANS:  grafica


________________ de realizare a proiectului software Relational Rose este folosit în toate fazele procesului relational unificat (Relational Unified Process), procesul de dezvoltare software desfãsurat pentru dezvoltarea produsului software aferent domeniului de activitate.


ANS:  Instrumentul


UML e un limbaj de ________________care urmeazã a fi translatat într-un limbaj de programare pentru generarea de cod (de program).


ANS:  modelare


UML a devenit un _________________ pentru modelarea produselor software deoarece:

1. are un model semantic bine definit, cunoscut sub denumirea de metamodelcare estee atât larg (acoperã majoritatea aspectelor necesare pentru determinarea cerintelor si proiectarea unui produs software) cât si adânc (însemnând cã este posibil sã creezi un model executabil care poate fi executat sau care poate fi utilizat la generarea programului sursã pentru compilare);

2. foloseste o notatie usor de învãtat si simplu de retinut;

3. nu este un limbaj de modelare particular si nu are o singurã sursã, un singur furnizor.

4. este aplicabil; fiind a treia generatie de limbaj de modelare orientat pe obiect.


ANS:  standard


UML este un limbaj de modelare ______________ folosit la realizarea unui model vizual al produsului software care trebuie proiectat.


ANS:  vizual


Cu ajutorul UML utilizatorul creeazã __________ produsului software care se proiecteazã.


ANS:  modelul


______________ unui produs software nu este exprimatã într-o singurã vizualizare, ci  de suma tuturor semanticilor corespunzãtoare vizualizãrilor diferitelor nivele de abstractizare ale domeniului de informatizat.


ANS:  Semantica


Existã o corespondentã între setul de ________________ UML care se realizeazã si modelul semantic construit pentru un produs software,  elementele semantice ale modelului fiind reprezentate în diagramele UML.


ANS:  diagrame


Conceptele structurale elementare folosite de UML în realizarea _____________ UML sunt:  obiectul, clasa, tipul de date si interfata. Aceste elemente structurale formeazã  bazele proiectului structural ale modelului utilizatorului.


ANS:  diagramelor




este o structurã de date împreunã cu toate operatiile care actioneazã asupra acestor date.


ANS:  Obiectul


_______________ este o colectie de operatii, separã în exteriorul clasei un set de servicii care pot fi chemate clasã pentru implementare, lucru posibil pentru cã o clasã contine metode care includ linii de cod care implementeazã servicii.


ANS:  Interfata


           28.         În procesul de modelare a oricãrui domeniu de afaceri se folosesc modele mici, obtinute prin interconectarea mai multor arhetipuri, cunoscute în literatura de specialitate sub denumirea de componente independente de _____________, pe baza cãrora se realizeazã modelul abstract al acestuia.


ANS:  domeniu


           29.         ___________________ se defineste ca fiind forma prin care se reprezintã, prin caracteristicile lor esentiale, toate elementele de acelasi fel.


ANS:  Arhetipul


           30.         În procesul de modelare a oricãrui domeniu de activitate se folosesc modele mici, obtinute prin interconectarea mai multor arhetipuri, cunoscute în literatura de specialitate sub denumirea de componente ________________ de domeniu, prin combinarea cãrora se construieste modelul abstract al domeniului respectiv.


ANS:  independente


           31.         Pentru sporirea claritãtii si expresivitãtii modelelor se folosesc ____________, câte una pentru fiecare arhetip.


ANS:  culorile


           32.         ______________ se foloseste în compunerea modelelor pentru cã ea oferã cea mai sugestivã cale de codificare a aspectelor suplimentare ale informatiilor reprezentate într-un model.


ANS:  Culoarea


           33.         Pentru cã exprimã în modelul abstract al realitãtii de informatizat, o categorie de clase cu caracteristicile lor comune si esentiale, arhetipul se reprezintã grafic printr-un __________.


ANS:  dreptunghi


           34.         Puncte de plug-in se folosesc pentru adaptarea unui ___________ la comportamentul altuia.


ANS:  arhetip


           35.         Arhetipurile în culori sunt foarte utile în construirea de module, pentru cã se ____________ (branseazã) între ele într-un mod repetabil si foarte previzibil.


ANS:  conecteaza


MATCHING


Un model vizual constã atât din semantici cât si din vizualizãrile acestor semantici de cãtre utilizator. O parte importantã a modelului este definitia semanticilor produsului software în curs de dezvoltare. Aceste semantici exprimã trei aspecte primare ale unui produs software:

a. structural

b. comportamental

c. functional


exprimã comportarea cerutã de utilizator;


identificã entitãtile, elementele care formeazã produsul software;


defineste modul în care elementele structurale lucreazã si interactioneazã în executia unui produs software; comportamentul poate fi modelat si vizualizat atât pentru elemente structurale individuale cât si pentru un ansamblu de elemente structurale care lucreazã împreunã pentru a crea o comportare mai largã;


1.        ANS:              C


2.        ANS:              A


3.        ANS:              B




Pentru a înnelege arhitectura unui sistem software orientat pe obiect trebuie realizate câteva modele, cãrora le corespund vizualizãri complementare, dar care se interconecteazã:

a. o vizualizare a cazurilor de utilizare (a use case view);

b. o vizualizare a proiectãrii (design view);

c. o vizualizare a procesului;

d. o vizualizare a implementãrii sistemului;

e. o vizualizare a exploatãrii sistemului (deployment view).


prezintã distributia proceselor sistemului si succesiunea in timp a acestora, desfãsurarea cronologicã a lor;


prezintã cerintele pe care trebuie sã le ofere sistemul utilizatorilor sãi;


prezintã problematica domeniului de informatizat împreunã cu solutia sa;


prezintã iesirile sistemului din punct de vedere tehnic;


prezintã realizarea fizicã a sistemului.


4.        ANS:              C


5.        ANS:              A


6.        ANS:              B


7.        ANS:              E


8.        ANS:              D



Procesul Unificat Relational este structurat pe doua dimensiuni:

a. timp;

b. componente ale procesului.



producerea unui set specific de metodologii cu activitãti bine definite pentru fiecare componentã;


împãrtirea ciclului de viatã în faze si iteratii.



  9.      ANS:              B


10.      ANS:              A



Structurarea proiectului de-a lungul dimensiunii timp implicã adoptarea urmãtoarelor faze bazate pe timp:

a. Initierea (inception):

b. Elaborarea;

c. Constructia;

d. Transferul.


planificarea activitãtilor si resurselor necesare realizãrii proiectului; urmãrind planul iteratiei, elaborarea se face pentru fiecare use case din iteratia curentã; se focalizeazã pe stabilirea arhitecturii proiectului; sarcina majorã a acestei faze este detalierea use case;


formarea viziunii de ansamblu asupra proiectului; analizarea domeniului de activitate pentru stabilirea obiectivelor si determinarea cerintelor produsului software care se proiecteazã; în aceastã fazã se creeazã  diagramele business use cas, diagramele activity si diagramele use case; se face un plan al iteratiei care descrie care dintre use cases se implementeazã pe durata cãrei iteratii; (se creazã modelul bussiness si modelul use case folosind Relational Rose);


se transferã produsul software final cãtre utilizatorii sãi; sarcinile desfãsurate în aceastã fazã includ completarea produsului software final, a procedeelor de testare, a documentaþiei de utilizare si instruirea utilizatorilor; Relational Rose e folosit pe durata acestei faze pentru actualizarea modelelor;


realizarea a ceea ce a mai rãmas din proiect si testarea acestuia; pentru generarea automatã de cod folosind Relational Rose, unele limbaje necesitã construirea diagramelor component în prima parte a fazei de constructie; pe durata acestei faze, Relational Rose este folosit pentru realizarea diagramelor sequence, collaboration, class, statecharte, component si deployment; pe baza proiectului, se genereazã programul sursã (cod de program).


11.      ANS:             B


12.      ANS:             A


13.      ANS:             D


14.      ANS:             C



Structurarea proiectului de-a lungul dimensiunii componentã a procesului de realizare a unui proiect software implicã parcurgerea urmãtoarelor faze, corespunzãtoare activitãþilor desfãºurate:

a. Modelarea domeniului de activitate (bussiness modeling);

b. Analiza domeniului de activitate (bussiness analysis);

c. Proiectarea (design);

d. Implementarea (implementation);

e. Testarea (test);

f. Exploatarea (deployment).


descrierea a cum va fi realizat produsul software, în faze de implementare;


generarea programului sursã (cod program), direct executabil;


determinarea cerintelor, respectiv stabilirea setului de cerinte, functionale si nefunctionale, care trebuie îndeplinite de produsul software de proiectat pentru domeniul de activitate dat;


livrarea produsului software proiectat la beneficiar ºi instruirea utilizatorilor sãi;


verificarea produsului software, în ansamblul sãu; se verificã îndeplinirea cerintelor stabilite pentru domeniul de activitate respectiv;


prezentarea domeniului de activitate cu structura sa, cu caracteristicile sale, cu fluxul de lucru din interiorul sãu, prezentarea interactiunilor sale cu exteriorul si a celor din interiorul sãu; se încearcã întelegerea a ceea ce este în interiorul si exteriorul sãu; nu orice proiect necesitã modelarea domeniului de activitate.


15.      ANS:              C


16.      ANS:              D


17.      ANS:              B


18.      ANS:              F


19.      ANS:              E


20.      ANS:              A



Modelul semantic UML, cunoscut sub denumirea de metamodel, este:

a. larg;

b. adânc.


face posibila crearea unui model executabil care poate fi utilizat la generarea programului sursã pentru compilare;


acoperã majoritatea aspectelor necesare pentru determinarea cerintelor si proiectarea unui produs software.


21.      ANS:              B


22.      ANS:              A



Semantica unui produs software în curs de dezvoltare are trei aspecte primare:

a. structural;

b. comportamental;

c.  functional.


defineste modul în care elementele structurale lucreazã si interactioneazã în executia produsului software care se proiecteazã;


se referã la comportarea cerutã, fãrã a tine seama de modul de implementare a comportãrii respective;


identificã elementele care formeazã produsul software: obiecte, clase, use cases, componente, subsisteme, etc.


23.      ANS:              B


24.      ANS:              C


25.      ANS:              A



Programul sursã poate fi generat:

a. automat

b. manual.


           26.         de care un programator;


cu ajutorul unui instrument de dezvoltare produse software.


26.      ANS:              B


27.      ANS:              A


UML este un limbaj de modelare folosit pentru:

a.  vizualizare (vizual);

b.  specificatii;

c.  constructie;

d. documentarea mecanismelor de proiectare a unui sistem software.



furnizeazã documentatia arhitecturii sistemului, cu toate detaliile necesare, inclusiv un limbaj de exprimare a cerintelor, de test si pentru modelarea activitãtilor proiectului, pentru planificarea si managementul versiunilor;


permite construirea de modele precise, neambigue si complete, pe baza specificatiilor primite de la toti analistii si proiectantii, implementând deciziile care trebuie luate în unui sistem software intensiv;


           30.         este un limbaj grafic care reprezinta mai mult decat un set de simboluri grafice deoarece în spatele fiecãrui simbol folosit în UML se ascunde o semanticã bine definitã care permite oricarui programator sa realizeze un model în UML pe care un alt programator sau chiar un alt instrument (tools) de programare, îl poate interpreta corect, fãrã ambiguitãti;


modelele construite cu UML pot fi conectate direct la o varietate de limbaje de programare, ceea ce înseamnã cã se poate mapa un model în UML la un limbaj de programare, ca de exemplu Java, C++ sau VisualBasic, la o BD relationalã sau la depozitele unei BD orientate pe obiect.


28.      ANS:              D


29.      ANS:              B


30.      ANS:              A


31.      ANS:              C



Pentru a întelege UML, trebuie format un model conceptual al acestui limbaj, ceea ce implicã învãþarea a trei concepte majore:

a. constructia blocurilor UML de bazã (fundamentale);

b. regulile;

c. mecanisme comune.


indicã cum se pot asambla blocurile UML;sunt reguli semantice pentru nume, scop, vizibilitate, integritate, executie;


se aplicã la nivelul întregului UML si pot fi de tip specificatii, ornamente, marcaje, mecanisme de extensie;


           34.         vocabularul UML permite constructia a trei categorii de blocuri UML: lucruri, relatii si diagrame.


32.      ANS:              B


33.      ANS:              C


34.      ANS:              A



Vocabularul UML cuprinde 3 categorii de blocuri UML:

a. lucruri;

b. relatii;

c. diagrame.


grupeazã lucrurile în colectii cu un anumit scop; pot fi clas diagram, object diagram, use case diagram, sequence diagram, collaboration diagram, statechart diagram, activity diagram, component diagram, deployment diagram;


abstractizãri care formeazã prima clasã dintr-un model; pot fi structurale, comportamentale;


leagã  lucrurile împreunã; pot fi de tip dependentã, asociere, generalizare, realizare.


35.      ANS:              C


36.      ANS:              A


37.      ANS:              B



Modelele si conceptele UML pot fi grupate în urmãtoarele 5 zone conceptuale:

a. structura staticã;

b. comportarea dinamicã;

c. scheme (cadre) de implementare;

d. organizarea modelului;

e. mecanisme de extensi.


capacitãti de extensie în interiorul UML care nu necesita schimbãri în limbajul de bazã; 


modelarea informatiei  împarte în pãrri coerente asa fel încât echipa sã lucreze simultan la mai multe pãrti, stiut fiind ca sistemele de calcul (calculatoarele) pot lucra cu multe modele, dar omul nu poate;


           40.         modele UML pentru componente ale sistemului (parti fizice) inlocuibile usor cu alte componente cu aceeasi specificatiecare, se conformeazã relalitatii si conduc la realizarea a unui set de interfete;


vederea staticã  care reprezinta schema modelului ce defineste universul pe care îl acoperã, conceptele cheie din aplicatie, cu  proprietãtile interne ale acestora si relatiile dintre ele; conceptele aplicatiei sunt modelate sub formã de clase, fiecare clasã descriind un set de obiecte discrete care memoreazã informatia si comunicã între ele pentru realizarea unui anumit comportament.


se modeleaza fie în ciclul de viatã al unui obiect care interactioneazã cu restul lumii, fie în modele de comunicare a unui set de obiecte conectate care intractioneazã pentru implementarea unei comportãri.


38.      ANS:              E


39.      ANS:              D


40.      ANS:              C


41.      ANS:              A


42.      ANS:              B




S-au identificat patru arhetipuri (descrise  de Peter Coad) pe baza cãrora se creeazã o componentã independentã de domeniu:

a. arhetipul interval- moment;

b. arhetipul rol (role);

c. arhetipul  descriere de tip catalog de intrare;

d. arhetipul  parte/loc/lucru.



           43.         catalog de descrieri, altfel spus  o colectie de valori reutilizabile ce exprimã comportarea tuturor elementelor a cãror descriere este cuprinsã în catalogul  respectiv;


           44.         calea de participare la actiune a unei pãrti (persoanã sau organizatie), a unui loc sau a unei componente;


           45.         o parte (persoanã sau organizatie), un loc sau un element care joacã roluri diferite în domeniul de activitate studiat;


           46.         reprezintã ceea ce se produce (are loc, se întâmplã) la un moment de timp sau într-un interval de timp.


43.      ANS:              C


44.      ANS:              B


45.      ANS:              D


46.      ANS:              A



Pentru a spori impactul acestor arhetipuri asupra celor care construiesc sau care citesc modelul, i se asociazã fiecãruia câte o culoare:

a. roz;

b. galben;

c. verde;

d. albastru.



           47.         se asociaza arhetipului descriere care, în mod uzual, are cele mai simple responsabilitãti;


           48.         se asociaza arhetipului parte- loc- lucru;


           49.         se asociaza arhetipului moment- interval, cel mai important în procesul de modelare, pentru ca atrage cea mai multã atentie;


           50.         se asociaza arhetipului rol, urmatorul ca importanta în procesul de modelare, pentru ca atrage cea mai multã atentie, dupã culoarea roz.


47.      ANS:              D


48.      ANS:              C


49.      ANS:              A


50.      ANS:              B




Document Info


Accesari: 2383
Apreciat: hand-up

Comenteaza documentul:

Nu esti inregistrat
Trebuie sa fii utilizator inregistrat pentru a putea comenta


Creaza cont nou

A fost util?

Daca documentul a fost util si crezi ca merita
sa adaugi un link catre el la tine in site


in pagina web a site-ului tau.




eCoduri.com - coduri postale, contabile, CAEN sau bancare

Politica de confidentialitate | Termenii si conditii de utilizare




Copyright © Contact (SCRIGROUP Int. 2025 )