230 likes | 379 Views
Modelarea regulilor : Tabel de Decizie. Constantinoaia Veronica 341 C5 veronica.constantinoaia@gmail.com. Cuprins. Introducere Table Driven Programming Tabel de Decizie Studiu de caz Bibliografie. Introducere. Proiectele software == schimbare perpetuua
E N D
Modelarearegulilor:Tabel de Decizie Constantinoaia Veronica 341 C5 veronica.constantinoaia@gmail.com
Cuprins • Introducere • Table Driven Programming • Tabel de Decizie • Studiu de caz • Bibliografie
Introducere • Proiectele software == schimbareperpetuua • Aplicatiiledezvoltatetrebuiesaevoluezepemasurace se modificacerintele. • Programarea Agile estecreatapentruschimbari, farareplanuirisireconstruiri. • Programareabazatapetabele (Table-driven programming) descrienumeroasetehniciprin care se pot integraschimbarile.
Table-driven programming • Metodadezvoltata la inceputulanilor ‘70 de catreprogramatoriivremii. • Este o tehnicafoarteeficienta de implementare a sistemelorbazatepepoliticisireguli. • Se foloseste de sabloane de stari, workflow-uri, tabele de deciziesiconstrangeri.
Tabel De Decizie(1) • Reprezintauna din celemai simple sifoarteeficientemetode de a rezolvaproblemecomplexe. • Unicitatea: un astfel de tabelpoatefispecificatsiintretinut de un utilizator.
Tabel de decizie(2) • Definitie: Un tabel de decizieesteformulareacazurilor de test bazatapedeciziileluate; rezultaastfel un proces de lucru cu un grad ridicat de acuratetesicompletitudine. • Scop: Imbunatatireamodului de lucrusi a rezultatului final.
Tabel de decizie(3) • Principiu: Functionalitateasistemuluiesteverificata de cazurile de test bazatepelogica de decizie din cadrulsistemului. Numarulcazurilor de test depinde de cerinte. • Utilizare: Unit testing, Integration testing, System testing, Functional acceptance testing
Tabel de decizie (4) • Pasul 1: Determinareaconditiilor. Acestea se trec in subtabelul A a tabelului. • Pasul 2: Definireaactiunilor. Acestea se trec in subtabelul B. • Pasul 3: Completareasubtabelului C – fiecareconditiedevineadevarat o data sifalsa o data. • Pasul 4: Completareasubtabelului D – Determinareadeciziilor care suntimposibilesicombinareacazurilor de test duble. • Pasul 5: Dacaestenecesar, descrierea in limbaj natural a cazurilor de test.
Tabel de decizie (7) • Forma simpla a acestortabeleeliminaconditiilecomplexe de tipulif then else. • In cazulproiectelormaicomplexe, pot fi create maimulteastfel de tabele legate intreele, modularizandastfellogicaaplicatiei.
Studiu de caz • Situatia : Reduceri la un magazin de imbracaminte. In magazinexistadoartreitipuri de articolevestimentare:pantaloni,bluzesifuste. • Premisa: Vorfipuse la reduceredoararticolele care sunt de maimult de 3 luni in magazin. Pantaloniivorbeneficia de o reducere de 20%, bluzele de 30% sifustele de 50%.
Pasul 1: Determinareaconditiilor. Acestea se trec in subtabelul A atabelului.
Pasul 2: Definireaactiunilor. Acestea se trec in subtabelul B.
Pasul 3: Completareasubtabelului C – fiecareconditiedevineadevarat o data sifalsa o data.
Pasul 4: Completareasubtabelului D – Determinareadeciziilor care suntimposibilesicombinareacazurilor de test duble. • Cazul de test 1 nu esteposibildatoritanerespectariiintegritatiidatelor. (un item nu poatefisi “pantaloni” si “bluza” in acelasitimp) • Cazurile de test 6,7,8 suntidentice cu cazul 5 pentru ca nu mai are nici o relevantatipulitemuluidaca nu a fost in magazinmaimult de 3 luni
Pasul 5: Dacaestenecesar, descrierea in limbaj natural a cazurilor de test.
Bibliografie • http://martinfowler.com/ieeeSoftware/accChange.pdf • http://www.ordina.nl/nl/downloadcentrum/~/media/Files/Markten/ICT/20101110%20QuickReferenceCards_English_v1%200.ashx?forcedownload=1 • Jerome Boyer & HafedhMili: Agile Business Rule Development: Process, Arhitecture, and Jrules Example