IP 1-30
Engage in Software Engineering Mastery
Test your knowledge and skills in software engineering with our comprehensive quiz featuring 55 thought-provoking questions. Challenge yourself and see how you compare with others in the field!
This quiz covers essential concepts including:
- Modularity and design principles
- Real-time systems
- Software testing and prototyping
Modularitatea inseamna:
Stabilirea unor ierarhii de program
Delimitarea unor secvente de program, cu intrari si iesiri bine precizate, intre care se stabilesc relatii ierarhice sau de colaborare
Delimitarea unor secvente de program
Stabilirea riguroasa a intrarilor si iesirilor
Notiunea de timp real implica:
Proprietatea de a reactiona in conditii reale a sistemului
Proprietatea sistemului de a reactiona la schimbari in proces, intr-un timp mai mic decat o limita prestabilita
Timp minim de reactie
Reactia sistemului in conditii precizate
Metoda MASCOT presupune, printre altele, elaborarea unei diagrame (numite ACR) care reflecta:
Structurile de date si de apel folosite in program
Relatiile dintre structurile de date si structurile de program
Tranzactiile de sistem
fluxurile de date din program, care isi au obarsiile in dispozitivele de intrare si se termina intotdeauna cu dipozitivele de iesire
Obiectivele ingineriei programarii stabilesc:
Modelele de proiectare
Principiile care trebuie urmate la proiectare
Modelele si principiile de proiectare
Dezideratele activitatii de proiectare sw
Intr-un sistem de conducere de proces interactioneaza urmatoarele componente:
Software, hardware
Programe, calculatoare, interfete de proces, manuale de utilizare
Echipamente, software, proceduri de operare, operator uman
Interfete, sisteme de reglare, sisteme de calcul, software
Modelul de dezvoltare in spirala presupune:
O abordare iterativa in cadrul careia la fiecare iteratie,analiza riscurilor cantareste diferitele alternative din punct de vedere al validarii prin testare, ceea ce permite analiza fezabilitatii inainte ca o anumita alternativa sa fie aleasa
O abordare iterativa in cadrul careia, la fiecare iteratie, prin analiza riscurilor se compara diferitele alternative din punct de vedere al cerintelor si constrangerilor, iar prototipizarea verifica fezabilitatea inainte ca o anumita alternativa sa fie aleasa
O abordare euristica in cadrul careia la fiecare etapa de dezvoltare , conceptul de dezvoltare abordat este validat prin metode euristice si solutia aleasa este in continuare dezvoltata in spirala.
Ingineria programarii se ocupa cu:
Aplicarea unor principii de programare structurata, astfel incat sa creasca fiabilitatea produselor-program
Utilizarea intr-o maniera disciplinata, sistematica si cu pricepere a unor metode si instrumente asociate, adecvate, avand in vedere anumite obiective si principii de baza
Folosirea unor instrumente software adecvate, astfel incat sa creasca productivitatea activitatii de programare
Organizarea corecta a activitatii de programarea intr-o firma de software
Adaptabilitatea(flexibilitatea) se refera la:
Obiectivul de realizare a unor programe care sa poata fi usor adaptate pentru conditii diferite de functionare
Obiectivul de realizare a unor programe adaptate unor situatii concrete de funtionare
Principiul de programare prin care programul trebuie sa fie usor de modificat
Principiul de proiectare prin care se cere proiectantului sa se adapteze usor la noi cerinte
Prototipizarea este o paradigma a ingineriei programarii care se refera la:
Construirea aplicatiilor prin metoda top-down
Construirea unui prototip al programului si modificarea acestuia
Proiectarea folosind descrieri-tip ale modulelor de program disponibile
Dezvoltarea rapida a unui model simplificat al programului, interactiunea cu clientul si adaugarea ulterioara a functiilor omise
Cate module de program pot fi subordonate unui modul, conform regulilor euristice de proiectare
De obicei intre 3 - 4 si 7, iar daca fan-out este mai mare de 9 sau mai mic de 3 - 4, este necesara reproiectarea
Maxim 5 si minim 2
Intre 3 si 6
Mai mult de 4
De ce sunt necesare taskurile de "luare la cunostinta" intr-un sistem de telemecanica?
Deoarece operatorul trebuie sa confirme ca a luat la cunostinta de evenimentele din proces si sunt necesare alte taskuri decat cele de tratare a evenimentelor, din pricina asincronismului reactiilor operatorului cu evenimentele din proces
Deoarece evenimentele din proces trebuie aduse la cunostiinta sistemului
Deoarece telecomenzile trebuie confirmate de catre operator
Deoarece sistemul trebuie sa reactioneze suficient de rapid la evenimentele din proces
Proiectarea structurata se realizeaza prin:
Folosirea proiectarii top-down si a unor structuri standard de control al programului: procesare secventiala, decizie, reunire
Proiectarea ingrijita a programelor, astfel incat acestea sa aiba o structura clara
Folosirea unor structuri standard de control al programului: procesare secventiala, decizie, reunire
Proiectarea top-down si modularizare structurala
Ce sunt regulile euristice de proiectare?
Reguli rezultate din aplicarea teoriilor euristice
Metodologii de proiectare ale organizatiilor software
reguli rezultate din experienta practica
Metode sistematice de proiectare
Principiile ingineriei programarii se refera la:
Modele folosite in procesul de proiectare
Modalitatile de atingere a obiectivelor ingineriei programarii
Scopurile programarii
Destinatia activitatii de programare
Redundanta dinamica se realizeaza prin:
Efectuarea unor teste de acceptanta si eventuala rulare a unei versiuni alternative
Dublarea unei functii
Efectuarea unor teste de acceptanta si rularea unei versiuni alternative
testarea starii taskurilor
Documentatia software de proiectare este necesara pentru:
Elaborarea unui prototip
Activitatea de asistenta tehnica si refolosire software
Prezentarea produsului
Prezentarea produsului si relatiile cu clientii
"Ascunderea" este utila pentru:
Mai buna structurare a programului
Definirea unor restrictii de acces si "ascunderea" detaliilor nesemnificative ale unui modul de program
Definirea unor interfete complexe prin ascunderea temporara a detaliilor
"ascunderea" detaliilor referitoare la tratarea erorilor
Cand o clasa trebuie sa gestioneze un numar de obiecte de aceeasi clasa, o abordare potrivita in proiectare ar fi sa se adauge:
Un model (pattern) de proiectare
O clasa container intre clasa primara si setul de obiecte
O clasa observator intre clasa primara si setul de obiecte
Nivelurile cerintelor software sunt urmatoarele:
De business, de proiectare, de testare
De business, utilizator, functionale
De sistem,de program,de modul
Activitatile de proiectare software cuprind urmatoarele:
Proiectarea cu Diagrama de flux de data (data flow),proiectarea Entitate-relatie, proiectarea cu Diagrame de structura
Proiectarea arhitecturii, specificarea abstracta, proiectarea componentelor si a interfetelor, proiectarea structurilor de date, proiectarea algoritmilor
Proiectarea structurata , proiectarea orientata pe obiecte , proiectarea orientata pe calendar, proiectare orientata pe cerinte
Sistemele de operare dedicate folosesc pentru comunicare:
Mesaje
Mesaje si variabile comune
Cutii postale si semafoare
Zone tampon si conducte
Intr-un sistem de telemecanica, efectuarea unei telecomenzi parcurge urmatoarele etape:
Selectie, executie, confirmare din proces
Selectie,executie
Selectie,confirmare
Trimiterea telecomenzii,raspunsul procesului
Obiectivele ingineriei programarii sunt:
Modularitatea,confirmabilitatea,adaptabilitatea,eficienta
Adaptabilitatea, eficienta, fiabilitatea, perceptibilitatea
Adaptabilitatea,eficienta,modularitatea,confirmabilitatea,eficienta
Modularitatea,abstractizarea,ascunderea,eficienta,fiabilitatea ,perceptabilitatea,confirmabilitatea
Un sistem Delta de stocare de versiuni:
Reprezinta toate versiunile prin utilizarea unei singure copii a codului sursa si diferentele dintre versiuni sunt marcate prin compilare conditionata:codul sursa relevant pentru anumite versiuni este generat de macrocomenzi astfel incat compilatorul poate reconstitui diversele versiuni
Memoreaza o singura versiune completa si le reprezinta pe celelalte prin retinerea diferentelor de la una la alta
Cuprinde conventiile d enume care sunt folosite pentru a discerne intre situatiile in care fisiere diferite reprezinta versiuni diferite ale aceluiasi modul
Ce este o revizie?
O noua versiune care realizeaza aceleasi functionalitati pentru situatii usor diferite si care este destinata a fi o alternativa interschhimbabila cu alta similara
o noua versiune destinata a inlocui versiunea veche si care reflecta evolutia in depanarea si imbunatatirea modulului ca functionalitate si performate
Un mecanism functional care arata organizarea unui set de variatii si relatiile dintre acestea
Un mesaj (UML) este:
Un apel de functie care se realizaza la aparitia unui eveniment
O abstractie a unei unitati de comunicare intre un obiect sursa si un obiect destinatie
O realizare a unei comunicari intre un obiect sursa si un obiect destinatie
Dezvoltarea iterativa furnizeaza clientului o versiune de program care:
Contine de la inceput toate functiile si cu fiecare versiune noua acestea sunt perfectionate si performantele imbunatatite
Contine de la inceput un set restrans de functionalitati si cu fiecare versiune noua se adauga altele noi
Permite instruirea clientului si adaugarea de functii noi
Strategia de identificare a obiectelor numita "sublinierea substantivelor" permite depistarea
Unor clase de interes,a unor subsisteme,clase neiteresante sau atribute de clase
Unor asociatii, unor obiecte, clase, atribute, metode si generalizari
Unor obiecte de interes,a unor actori,obiecte clase,atribute,metode si generalizari
Problema dublei intretineri rezulta daca:
Mai multi proiectanti au drepturi pentru acces is modificare simultana a acelorasi date(eventual cod sursa))
Se mentin copii multiple ale aceluiasi cod sursa
Doi proiectanti actualizeaza simultan acelasi cod sursa si astfel este posibil sa se suprascrie unele modificari in copia distribuita
Când, în cadrul şablonului Observer, serverul primeşte un apel subscribe
Crează un obiect de tip ConcreteObserver care adaugă stocarea locală în atributele dorite.
Crează un obiect de tip NotificationHandle care include adresa obiectului
Apeleaza periodic o metoda Gimme() de interogare direct a valorii urmarite
În UML conectarea modelului de obiecte cu modelul cazurilor de utilizare se realizează prin aceea că
Fiecare caz de utilizare va fi realizat de un set de obiecte care lucrează împreună.
Fiecare model de obiecte este realizat de un set de cazuri de utilizare care trimit secvențe de mesaje.
Fiecare caz de utilizare corespunde câte unui obiect.
În UML, o operaţie este:
Specificarea unui mesaj.
Descrierea unei secvenţe de apeluri de metode.
Specificarea unui comportament
Sistemele de conducere de proces prezintă anumite particularităţi, printre acestea numărându-se:
Prezența interfeţelor cu utilizatorul, puterea foarte mare de procesare, utilizarea memoriilor statice, includerea unui mecanism de watch-dog, toleranța la defectare,fiabilitatea foarte bună, sisteme de operare speciale (OSEK sau AUTOSAR) şi funcţionarea în condiţii grele de lucru.
Proiectarea folosind redundanţa statică sau dinamică, utilizarea unor microcontrollere speciale, prezenţe interfețelor de procesși a interteţelor de vizualizare de semnal, funcţionarea în condiţii grele de lucru
Prezenţa interfeţelor de proces, utilizarea memoriilor statice, includerea unui mecanism de watch- dog, eventual existenţa mai multor procesoare, modularitatea, toleranța la defectare, fiabilitatea foarte bună, sisteme de operare în timp real, câteodată lipsesc interfețele standard de vizualizare şi funcţionarea în condiţii grele de lucru.
Comunicare daisy-chain, stea sau multipunct, existenţa unor interfețe speciale cu operatorul, sisteme de operare UNIX, Linux sau ONX.toleranțala detectare, fiabilitatea foarte bună, funcţionarea în condiţii grele de lucru
Tipurile de informaţii furnizate de clienţi (în cadrul activităţii de analiză software) sunt:
Cerinţe de business, scenarii de business, restricţii asupra echipamentelor disponibile, cerințe funcţionale, structuri de date
Specificaţii, sugestii de arhitectură software, structuri de date, funcţii ale sistemului, interfaţa cu utilzatorul
Cerinţe de business, scenarii de business, reguli da business, cerințe funcţionale, atribute de calitate, constrângeri externe, structuri ce date, sugestii pentru posibile soluții
Pentru identificarea cazurilor de utilizare analistul stă de vorbă cu clientul şi îi adresează întrebări cheie precum:
Care sunt actorii ? Care sunt mesajelor pe care le trimit şi recepționează ? Care sunt grupele care alcătuiesc cazuri de utilizare ?
Care esle rolul actorilor şi al sistemului în fiecare scenariu ? Care sunt interacţiunile (fluxurile) ? Care sunt secvențele de evenimente şi date ? şi posibilele variaţiuni.
Care sunt funcţiile primare ale sistemului ? Care sunt funcţiile secundare ale sistemului ? De ce a fost construit sistemul ? Ca în'ocuieşte şi de ce?
O stare este:
O descriere complet constructivă de descompunere a comportamentului complex în bucăţi npai mici, fiecare fiind valabilă în anumite condiţii specifice.
O condiţie de existenţă a unui clasificator (clasă sau caz de utilizare) care persistă o perioadă semnificativă de timp şi poate fi cumva distinsă faţă de alte condiţii similare de existenţă.
O descriere e comportamentului unui obiectul în timpul intrării, ieşirii sau persistenţei.
Pentru dezvoltarea produsului conform celordescrise în problemă, se va folosi dezvoltarea agilă “uzuală”. Conducătorul diviziei responsabile va stabili cu membrii echipei, ca şi principii călăuzitoare, următoarele:
Software-ul se livrează frecvent (săptămânal), chiar şi schimbări târzii sunt acceptate, cooperarea cu clientul este apropiată (dacă se poate, zilnică), forma de comunicare dorită este conversaţia faţă în faţă, achipa se auto-organizează.
Software-ul este livrat o dată la două luni, schimbări după două săptămâni nu se acceptă, cooperarea cu clientul se face prin întâlniri săptămânale, forma de comunicare predilecta este e-mailul, echipa este structurată după metada echipei programatorului-şef
Software-ul se livrează frecvent (săptâmânal), se defineşte, pentru fiecare increment, o descriere a cerinţelorla nivelul clientului, se descriu apoi specificaţiile funcţionale, se face proiectarea formală, verificarea corectitudinii, testarea statistică şi certificarea, se lucrează cu echipe organizate riguros şi ierarhic.
Agregarea este:
Un tip special de asociere care implică proprietatea logică sau fizică
O'relaţie de tip clasă părinte/clasă descendent
O formă tare de compozitie în care părţile sunt în întregime în responsabilitatea clasei compozite
Un şablon (pattern)
Abstractizează şi identifică aspectele cheie ale unei structuri comune de proiectare în care o singură sursă ce informaţie acţionează ca un server pentru mai mulţi clienţi.
Abstractizează şi identifică aspectele cheie ale unsi structuri comune de proiectare prin utilizarea claselor abstracteşi a moştenirii şi funcţiilorvirtuale
Abstractizează şi identifică aspectele cheie ale unei structuri comune de proiectare pe care o face utilă pentru crearea unui design OO, reutilizabil.
Actorii în sistemul din problemă, în accepţiunea UMI, sunt:
Antena, utilizatorul, calculatorul PC
Senzorii, sistemul de acţionare, traductoarele de măsură, utilizatorul, unitatea serială
Sistemul de acţionareal antenei, sistemul de măsură de poziţie, interfaţa cu utilizatorul, unitateaserială de comunicare cu calculatorul PC, utilizatorul.
Şablonul Container este o bună soluţie pentru cazul
Când un obiect are asociere 1-la-mai mulţi şi dorim să îmbunătăţim reuzabilitatea şi atunci acea clasă de la capătul “1” va gestiona un set de obiecte stocate într-un container
Când devine mai uşoară adăugarea unui nou container - un vector extensibil — prin crearea uneiinterfeţe care asigură clienţilor serviciile cerute de aceştia dar folosesc operaţiile promitive ale containerelor existente.
Când un obiect are nevoie de o implementare comună potrivită pentru o varietate de utilizări.
Documentul de proiectare arhitecturală trebuie să
Specifice rolul fiecarei componente, cerinţele care i-au fost alocate,interfata de comunicare cu celelalte componente ale sistemului
Descrie rolul fiecărei componente, cerintele de memorie și timp de calcul alocate, interfata de comunicare cu celelalte componente ale sistemului
Descrie rolul fiecărui programator şi al fiecărei componente, respecliv inler fala de comunicare cu celelalte componenle ale sistemului
Specifice rolul fiecărei funcţii, cerințele care i-au fost alocate, interfata de comunicare cu utilizatorul, descrierea componentelor sistemului
Asocierile sunt:
Codificate prin existenţa unei clase asociative
Relaţii de colaborare definite prin existenţa unui server şi respectiv a unui pachet de metode
Relaţii care se manifestă la rulare pentru a permite schimb de mesaje între obiecte
Şablonul Observer rezolvă problema
în care o singură sursă de informaţie acţionează ca un server pentru mai mulţi clienţi care trebuie să îşi actualizeze autonom datele când acestea se schimbă.
în care un obiect trebuie să afişeze periodic (observe) schimbările survenite în valorile citite de le un senzor.
în care un server trebuie să furnizeze la cerere datecitite din proces.
Cerintele functionale in UML:
Sunt codificate prin note text.
Sunt reprezentate prin diagrame de secventa si prin diagrame de stare
Sunt reprezente direct de cazurile de utilizare
Sistemul UNIX nu este foarte raspandit in conducerea de proces deoarece prezinta:
Pret ridicat
Lipsa de unitate, sintaxa criptica, lipsa de interfete grafice, si de software
Nepotrivire cu necesitatile de timp real
Imposibilitatea implementarii multitaskingului
Familiile mai reprezentative de sisteme de operare dedicate sunt:
OS-2, WARP, QNX, OS-9
OS-9, QNX, Windows 95 CE
OS-9, QNX, VxWorks/Microworks
OS-900, QTRM, RTS
Sistemele de operare dedicate folosesc pentru alocarea unitatii centrale:
Prioritati fixe
256 prioritati
Mesaje si variabile
Planificarea circulara(round-robin)
In modelul (pattern) Rendezvous participa urmatoarele obiecte:
Rendezvous, Lock, Thread
Rendezvous, Lock, Client, Context, Thread,
Rendezvous, Wait, Semaphore, Client, Context, Thread
Un fir de executie in Windows NT 4 este:
Un process
Un task
Un modul de program care realizeaza apeluri DLL
O cale de executie in interiorul unui proces
Categoriile de prestatori(server) in arhitectura client-server la Windows NT 4 sunt:
Monitorul, WIN32, DLL
Windows NT Executive, WIN32
I/O Manager, Win NT Executive, WIN32
NTFS, HPFS, FAT
Configuratia larg distribuita utilizeaza:
Legatura multipunct
Field-bus
Retele WAN si protocoale de comunicatii potrivite
Protocoale de comunicatie Nowell si retele LAN
Intr-o diagrama in care apar reprezentate urmatoarele entitati
Taskuri si dispozitive
Taskuri, conducte, cutii postale, dispozitive, semafoare, blocuri eveniment
Module de program, functii, canale, rezervoare
Taskuri(activitati), dispozitive, canale, rezervoare
Etapele de aplicare a metodologiei MASCOT sunt:
Proiectare generala, proiectare in detaliu, asistenta tehnica
Proiectare preliminara de ansamblu, proiectare detaliata, implementare si testare
Specificatii, programare, implementare
Analiza de sistem, analiza de process, proiectare de detaliu
La Windows NT 4 concurenta era implementata prin:
Preemptiune, cu ordonarea dupa 31 prioritati pe cate 4 paliere (IDLE, NORMAL, REALTIME)
Preemptiune, cu ordonarea dupa 31 prioritati, ordonate pe 2 paliere: 4 clase de prioritate si 5 niveluri pe fiecare clasa
Multithreading
Intreruperi event-driven cu planificare circulara(round-robin)
{"name":"IP 1-30", "url":"https://www.quiz-maker.com/QPREVIEW","txt":"Test your knowledge and skills in software engineering with our comprehensive quiz featuring 55 thought-provoking questions. Challenge yourself and see how you compare with others in the field!This quiz covers essential concepts including:Modularity and design principlesReal-time systemsSoftware testing and prototyping","img":"https:/images/course4.png"}