Faza a II-a a procesului de dezvoltare a sistemelor Definirea cerintelor (specificatiilor) software

1. Faza definirii cerintelor software

1.1 Introducere

Standardele SE definesc faza II ca fiind faza definirii cerintelor software sau a analizei, din ciclul de viata al produsului: cerintele utilizatorului sunt analizate, rezultând specificatiile software.

In contiunare, se va prezenta foarte sumar un ghid pentru producerea cerintelor software, bazat pe recomandarile standardelor SE.

În aceasta faza se produce setul cerintelor soft pe baza documentului DCU si pe baza modelului logic al sistemului.

Modelul logic e o descriere abstracta a ceea ce ar trebui sa execute sistemul si nu trebuie sa contina detalii de implementare.

Cerintele software si modelul logic al sistemului sunt vor fi documentate în Documentul Cerintelor Software (DCS), documentul obligatoriu al acestei faze.

DCS reprezinta punctul de vedere al echipei de dezvoltare si nu al utilizatorului.

Corespondenta cerintelor din DCU si a celor din DCS 959j97j nu este în mod necesar de la 1 la 1.

Definirea cerintelor software reprezinta raspunderea echipei de dezvoltare. La aceasta faza participa si utilizatori, ingineri de sistem software sau hardware, personal de operare.

Activitatea de management va trebui sa asigure ca acest document va fi revizuit de catre toti participantii la aceasta faza.

1.2 Construirea modelului logic al sistemului

Un model logic al sistemului este:

o descriere simplificata a sistemului

ierarhic, conform unor criterii consistente de descompunere

compus din simboli alesi conform unor conventii

construit pe baza unor anumite metode si utilitare

folosit în analiza sistemelor

Modelul logic al sistemului determina o mai buna întelegere a cerintelor software, considerate ca întreg. El trebuie construit iterativ: revizuiri ale fiecarui nivel al sitemului trebuie realizateînainte de a trece la urmatorul nivel de detaliu. Utilitarele CASE se recomanda pentru obtinerea unor modele clare si consistente, usor de construit si de modificat.

Tipul modelului logic depinde de metoda fofosita. Sectiunea 3 rezuma metodele potrivite pentru construirea unui model logic.

În cele ce urmeaza, prezentam conceptele si terminologia descompunerii functionale, pentru a arata cum se construieste un model logic. Aceasta nu înseamna neaparat aceasta metoda trebuie folosita, ci doar ca ea ar putea fi potrivita.

1.2.1 Descompunerea functionala

Pentru a construi un model logic, sistemul este descompus într-un set de functiuni de baza, cu doar câteva simple intrari si iesiri.

Descompunerea functionala este numita si metoda "top-down" pentru ca începe descompunerea sistemului de la o singura functie, rezultând apoi functii la nivele de mai mare detaliu. Fiecare nivel modeleaza sistemul la diferite trepte de abstractizare.

Standardele SE definesc urmatoarele recomandari privind construirea unui model logic:

functiile trebuie sa aiba un singur obiectiv, bine definit.

functiile trebuie sa fie potrivite nivelului la care apar (exemplu: "Calculeaza ." sa nu apara cu "Verifica .."

interfetele trebuie minimizate

orice functie se descompune în cel mult 7 sub-functii.

nu se foloseste terminologia specifica implementarii (fisier, înregistrare, modul, statie de lucru, etc.)

atributele de performanta ale oricarei functii (capacitate, viteza, acuratete) ar trebui specificate, daca e posibil

trebuie identificate functiile critice.

numele functiilor trebuie sa reflecte scopul lor.

numele functiilor trebuie sa aiba o structura declarativa ("Calculeaza suma", "Cauta identificator ", etc.

Se considera ca descompunerea functionala a atins un nivel suficient de detalii daca:

modelul furnizeaza toate capabilitatile cerute

respecta cele noua recomandari

1.2.2. Analiza performantei

Cerintele utilizatorului pot contine atribute de performanta (capacitate, viteza, acuratete). Acestea definesc performantele pentru o functie sau un grup de functii.

Modelul logic trebuie verificat d.p.d.v. al conflictelor performantelor prin studierea tutuor cailor de-a lungul fluxurilor de date.

1.2.3 Analiza functiilor critice

Uneori, cerintele de capabilitate sunt definite în termeni privind categoria severitatii consecintelor hazardului (CSCH). Aceste categorii pot varia de la catastrofic" la "critic" si de la "marginal" la "neglijabil".

Daca asemenea termeni sunt specificati, modelul logic trebuie analizat pentru a propaga CSCH catre toate cerintele corelate cu cerinta initiala, având atasata aceasta categorie (iar pentru aceasta exista tehnici speciale).

1.2.4. Prototipul

Uneori, este util de a verifica anumite parti ale modelului. Tehnica executarii unui prototip, ar putea clarifica cerintele.

Echipa de dezvoltare poate identifica cerinte cu un grad oarecare de risc (adica nu e sigur ca aceste cerinte ar putea fi satisfacute). Prototipul poate decide daca asemena cerinte trebuie sau nu incluse în DCS.

1.3 Specificarea cerintelor software

Standardele SE definesc urmatoarele tipuri de cerinte software:

cerintele functionale (provenite din cerintele de capabilitate)

cerintele nefunctionale sau   de performanta (provenite din constrângerile asupra cerintelor de capabilitate)

1.3.1. Cerintele functionale

Acestea specifica functiile pe care sistemul trebuie sa le execute.

Exista o corespondenta de la 1 la 1 între cerintele functionale si nodurile sistemului logic.

Cerintele functionale trebuie organizate în aceeasi maniera top-down, funtie de structura modelului logic.

O cerinta functionala:

defineste ce executa sistemul

defineste transformarea ce trebuie executata pe intrprile specificate pentru a genera iesirile

are atasate cerinte de performanta (capacitate, viteza, acuratete)

trebuie exprimate prin fraze concise, simple (de exemplu, utilizând engleza structurata)

1.3.2 Cerintele nefunctionale (de performanta)

Acestea provin din cerintele restrictive. Ele ar trebui atasate cerintelor functionale, putând aparea deci pe orice nivel, aplicându-se tuturor cerintelor functionale de pe nivelul urmator.

De obicei, sunt exprimate în limbaj natural, deoarece notatiile formale nu sunt destul de expresive.

2. Metode pentru definirea cerintelor software

Introducere

Faza definirii cerintelor software poate fi numita si faza analizei, conform standardelor SE.

Analiza se realizeaza folosind o metoda sau o combinatie de metode pentru:

construirea modelului logic

specificarea cerintelor software

Se rezuma în continuare câteva bine-cunoscute metode, far a recomanda o metoda standard si fara a defini un set complet de metode.

Functie de fiecare proiect, se alege metoda cea mai potrivita. E recomandabil a se studia sisteme concrete, care au fost dezvoltate cu diverse metode, pentru a alege metoda cea mai potrivita.

Metode posibile sunt:

descompunerea functionala

analiza structurata

analiza orientata-obiect

metode formale

dezvoltarea sistemelor Jackson

prototipul

2.1 Descompunerea functionala

Aceasta este metoda traditionala de analiza si a fost prezentata pe scurt într-o sectiune anterioara.

Aceasta metoda a fost încorporata în metoda analizei structurate.

2.2 Analiza structurata

Este numele unei clase de metode de analiza a sistemelor prin construirea unor modele ale fluxurilor de date.

Fac parte din aceasta clasa urmatoarele metode:

metodele Yourdon (DeMarco si Ward-Mellor)

SSADM (Structured System Analysis and Design Methodology)

SADT (Structured Analysis and design Techniques)

Analiya structurata include toate conceptele descompunerii functionale dar produce specificatii functionale de o mai mare calitate, prin definireariguroasa a interfetelor între procese si anume, fluxurile de date si control.

Diagramele fluxurilor de date (DFD) sunt caracteristice metodelor de analiza structurata.

Conform definitiei propusa de DeMarco, analiza structurata înseamna folosirea urmatoarelor tehnici pentru a produce specificatiile sistemului:

DFD

Dictionarul de Date

engleza structurata

tabele de decizie

arbori de decizie

Ultimele 3 sunt utilizate pentru a specifica detalii de procesare algoritmica.

Dezvoltarea analizei struturate pentru sistemele de timp real, a suplimentat aceasta lista cu:

Schema Transformarilor

Lista evenimentelor

Diagrame stare-tranzitie

Schema de Date

Specificatii pre- si post- conditie

SSADM, care pune accent pe modelarea datelor, mai include:

Diagramele Entitate-Relatie (E-R entity-relationship ) sau Modelele Entitatii

Istoriile vietii entitatii (Entity Life Histories)

Analiza structurata produce specificatii structurate, continând o descriere sistematica si riguroasa a sistemului. Analiza si proiectarea sistemului reprezinta procesul realizarii unui model al sistemului.

2.2.1 Analiza structurata ("Structured Analysis - versiunea DeMarco (78)

SA este o metoda generala de analiza a sistemelor.

Exista 2 versiuni similare:

-Gane, Sarson (79)

-DeMarco (78)

Ne vom referi în continuare la versiunea DeMarco.

SA DeMarco utilizeaza Diagramele Fluxurilor de Date (DFD).

DFD evidentiaza transformarea datelor de intrare în date de iesire printr-o secventa de transfromari functionale. Ele reprezinta un mod intuitiv de descriere a sistemelor si pot fi întelese fara o antrenare speciala.

În mod normal, aceste diagrame nu trebuie sa includa informatii de control, dar trebuie sa documenteze transformarile datelor.

DFD sunt grafice adnotate de text, folosind urmatoarele simboluri:

flux de date

proces

fisier

surse sau destinatii

and, or 

Primul simbol reprezinta fluxul de date, unic etichetate textual.

Simbolul 2 reprezinta procesul care transforma datele de intrare în date de iesire.

Simbolul 3 reprezinta sursa sau destinatia datelor. Ele sunt exterioare sistemului care trebuie analizat.

Simbolul 4, o linie dreapta, reprezinta un fisier sau o baza de date.

Ultimele simboluri au întelesul cunoscut al operatorilor expresiilor booleene. Sunt folosite când mai multe fluxuri de date intra sau ies dintr-un proces.

Toate aceste simboluri pot fi combinate pentru a forma o DFD.

Exemplul 1:

B

S1  S2

A P1 C P2 D P3 E

DB

Figura 1: Diagrama a fluxurilor de date

Sursa S1 creeaza data A care urmeaza sa fie transformata de procesul P1 în doua pachete de date B si C. Procesul P2, folosind informatii din baza de date DB , transforma datele B si C în D, procesul P3 transforma data D în data E, care ajunge la destinatia S2.

Fiecare proces poate fi expandat într-o maniera ierarhica, pentru a prezenta un nivel de detaliu mai mare. Un proces poate reprezenta un numar de alte procese si fluxuri de date, deci o DFD, ca în figura 2. Acest lucru e numit organizare pe nivele (leveling), un proces fiind considerat parintele altor procese descendente.

Conceptul de echilibrare (balancing) se refera la faptul ca intrarile si iesirile procesului parinte sunt, de asemenea, reprezentate în diagrama descendenta. si acest lucru este pus în evidenta în figura 2.

C P3 D

A B

P1 P2

E P4 F

B C

P21 P22 P25

E

P23 P24

Figura 2: Organizarea pe nivele. Echilibrarea intrarilor si iesirilor

Toate datele care apar în DFD sunt documentate într-un dictionar de date.

Celelalte elemente ale analizei structurate: Engleza structurata, Tabele de decizie si Arborii de decizie sunt utilizate pentru a specifica detalii ale procesarii.

DFD reprezinta o parte integrala a unui numar de metode iar mediile (utilitarele) CASE, de obicei, suporta crearea DFD.

Notatiile folosite în diverse metode sunt asemanatoare.

Folosind DFD, se prezinta în continuare, modelul unui sistem de generare a rapoartelor, folosit în conjunctie cu un editor de diagrame.

Figura 3: Generator de rapoarte al editorului

Generatorul de rapoarte preia o diagrama si produce un raport despre entitatile diagramei. Utilizatorul introduce un nume de diagrama si generatorul de rapoarte extrage toate numele entitatilor din baza de date a diagramei. Acestea sunt sortate si apoi dictionarul de date este consultat pentru informatii despre entitati.

Descriptorii de entitate obtinuti, sunt sortati functie de tipul entitatilor (nod sau arc) iar raportul este generat tinând cont de aceste categorii.

2.2.2 Metoda E-R

Cele mai multe sisteme software complexe folosesc mari baze de date. O parte din activitatea de modelare a sistemelor este dedicata definirii logice a datelor manipulate de sistem.

Metode obisnuite pentru modelarea logica a datelor sunt:

n      modelul entitate-relatie ("entity-relationship ) sau E-R , Chen-1976

n      SDM (Hammer, McLeod-81)

n      modelul relational ("Relational Model")

În principiu, modelul E-R stabileste entitati de date (care în termenii limbajelor de programare ar corespunde tipurilor de structuri de date) si relatii între aceste entitati (corespunzatoare operatiilor asupra tipurilor de entitati).

Entitatile pot avea atribute (analog câmpurilor din structuri), la fel si relatiile ("private data values n general, atributele sunt atomice (nu se descompun mai departe).

Tipurile pot avea subtipuri astfel încât un tip special de relatii numit relatie de mostenire (inheritance relation) a fost introdus pentru extinderea modelului E-R. Subtipurile mostenesc atributele supertipurilor. Atribute aditionale proprii pot fi adaugate entitatii subtip.

În general, modelul E-R este suportat de mediile CASE.

Modelul utilizat aici reprezinta extensia modelului E-R, a lui Chen.

Notatiile grafice utilizate sunt prezentate în figura 4.

<nume> entitate

<nume> atribut pentru entitate sau relatii

<cardinalitate de intrare>

relatie relatie de mostenire

<cardinalitate de iesire>

Figura 4: Notatiile folosite în modelul E-R extins

Exista variante pentru aceste notatii.

Cardinalitatea de intrare reprezinta numarul entitatilor de intrare.

Cardinalitatea de iesire reprezinta numarul entitatilor de iesire.

O relatie de mostenire arata ca o entitate mosteneste atributele entitatii parinte. Subtipul este indicat printr-o sageata.

Relatiile între entitati pot fi:

ceea ce înseamna ca o instanta a unei entitati participa în relatie cu o instanta a altei entitati.

1:M - o instanta a unei entitati participa în relatie cu mai multe instante ale altei entitati.

M:N - mai multe instante ale unei entitati participa în relatie cu mai multe instante ale altei entitati.

În acest model, relatia M:1 nu este suportata.

Exemplul 1:

Ca o simpla ilustrare a modelului E-R, consideram un simbol utilizat de sistemele de editare a diagramelor:

Simbolii reprezentând tipuri particulare sunt compusi din simboli primitivi ca: linii, elipse, dreptunghi.

Modelul datelor pentru simbolul compus din figura anterioara, este prezentat în figura 5.

Simbol compus tip dimensiune

are

primitive  culoare

dreptunghi linie elipsa

lungime latime lungime unghi diam_x diam_y

Figura 5: Modelul simbolului compus

Acest model arata ca simbolul compus considerat are un atribut care indica daca simbolul are dimensiuni variabile sau fixe si este realizat dintr-un numar de primitive, toate având atributul de "culoare Primitivele pot fi dreptunghiuri, linii sau elipse, fiecare din aceste subtipuri având propriile lor atribute.

Exemplul 2:

Editorul de diagrame se bazeaza pe reprezentarea sub forma de graf a diagramei. Diagrama consta deci dintr-un set de noduri de tipuri diferite conectate prin arce, reprezentând relatiile dintre noduri. Exista 2 tipuri de reprezentari pentru diagrama:

reprezentarea pe ecran a acestui graf

reprezetarea din baza de date, distincta de prima

Sistemul de editare a diagramelor realizeaza o mapare a reprezentarii bazei de date catre reprezentarea ecran, ori de câte ori diagrama trebuie afisata.

Informatia produsa de editor pentru alte utilitare trebuie sa includa o reprezentare logica a grafului. Utilitarele ce vor folosi aceste diagrame sunt interesate în tipurile entitatilor existente , atributele lor logice (ca numele lor) si conexiunile dintre ele, si nu de forma sau de coordonatele de pe ecran ale entitatilor. Organizarea logica a grafului este prezentata în figura urmatoare:

Figura 6: Modelul logic al datelor privind un sistem de editare a diagramelor

O diagrama e compusa din noduri si conexiuni. Nodurile si conexiunile au asociate nume, atribute de tip si un set de etichete. Fiecare eticheta are un nume si un tip si poate fi ori un icon, ori o eticheta-text. O eticheta-text are un atribut text. Un icon are un atribut bitmap.

În stânga desenului, se prezinta o relatie explozie" evidentiind faptul ca un nod poate reprezenta, la rândul sau, o diagrama (prin repetarea entitatii de diagrama din radacina diagramei initiale).

Un nod poate avea mai multe conexiuni, iar conecteaza (este în relatie cu) doua noduri.

Modelele E-R au fost utilizate foarte mult în proiectarea bazelor de date. Datorita existentei tipurilor, subtipurilor si a supertipurilor, este usor de a mapa aceste modele în baze de date orientate obiect. Desi bazele de date orientate obiect nu au atins un stadiu matur, se pare ca vor fi folosite pe scara larga în viitor, în aplicatii ca medii CASE.

2.2.3 Dictionarul de date

Pe masura ce un model al sistemului este dezvoltat, apar foarte multe entitati a caror identificare prin nume trebuie sa fie unica. Mentinerea unicitatii este dificila mai ales daca mai multe persoane sunt implicate în procesul de dezvoltare . Este absolut necesara o metoda automatizata si, în acest scop, se foloseste un utilitar pentru coordonarea numelor: dictionarul de date.

Dictionarul de date (DD) documenteaza riguros diagramele sistemelor. Practic, dictionarul de date este o lista de nume ale entitatilor, însotite de descrieri ale acestora.

DD sunt utile în toate fazele proceului de dezvoltare, începând de la modelarea initiala si pâna la întretinerea sistemului.

Toate numele entitatilor, tipurilor, relatiilor, atributelor, etc., trebuie introduse în DD. Exista posibilitatea, prin suportul software existent, de a crea , a mentine si a interoga DD.

Exemplul 1:

Un model logic posibil al datelor pentru un DD este aratat în figura 7.

DD nume

1

defineste

def N nume

intrare

desc tip

data

folosita de foloseste include

intrare intrare intrare

Figura 7: Model al dictionarului de date

Acesta arata ca DD este compus dintr-un numar de intrari, fiecare intrare având ca atribute: nume, reprezentare, descriere, data crearii si o stare (care permite unei intrari sa devina inactiva).

Fiecare intrare participa în 3 relatii cu alte intrari. Acestea arata:

ce entitati vor folosi aceasta entitate

ce entitati sunt folosite de aceasta entitate

ce entitati sunt incluse în aceasta entitate (de exemplu, entitatile operatii sunt incluse în entitatile tipurilor de date abstracte)

Exemple de intrari în DD pentru diagrama din fig. 3, sunt prezentate în figura 8. Informatiile privind relatiile dintre entitati nu au fost cuprinse aici. Într-un DD automat, aceste informatii sunt accesibile dintr-un meniu asociat fiecarei intrari.

Figura 8: O parte a înregistrarilor din DD pentru generatorul de rapoarte a diagramelor

2.2.4 Modelul Ward-Mellor

Acesta descrie un proces iterativ de modelare a sistemului care defineste întâi primele nivele ale modelului esential, care este un model logic al sistemului. În loc de a construi imediat nivelele urmatoare ale modelului, Ward si Mellor recomanda construirea primelor nivele ale modelului de implementare. Ciclul continua cu definirea urmatorului nivel al modelului esential. Acest mod evita îndepartarea prea mare a modelului de realitate si previne o implementare lipsita de coerenta si structura. Totusi, nu se intentioneaza în acest fel construirea modelului definitiv de implementare. Acesta ar trebui sa aiba loc în faza proiectarii sistemului.

Aceasta metoda este considerata în faza definirii specificatiilor software a sistemelor de timp real.

2.2.5. Modelul SADT (D.Ross-1977)

Acest model considera doua etape în faza definirii cerintelor software:

-analiza contextului sistemului, a interactiunii sale cu exteriorul

-specificarea functionala care presupune construirea unei arhitecturi functionale, exprimata prin diagrame SADT.

Arhitectura functionala reprezinta un model logic al sistemului, derivat dintr-o descompunere functionala, top-down, a sistemului, începând cu diagrama de context, care prezinta toate interfetele sistemului, dupa acelasi principiu ca si SA.

Ca si în SA, fluxurile de date ale sistemului sunt transformate de o functe sau de o activitate. Diagramele obtinute în acest fel se numesc diagrame de activitati.

Diagramele de acitivitati SADT sunt formate din dreptunghiuri, sageti si diagrame, ca în figura 9:

Date de control

Date de intrare  Functie sau activitate Date de iesire

Mecanism

Figura 9: Diagrama SADT

Un dreptunghi e o functie sau activitate care transforma datele. Datele de intrare patrund prin partea stânga si ies, transformate, prin partea dreapta.

Pe latura superioara a dreptunghiului sunt evidentiate constrângerile sau datele de control pentru activitatea respectiva. Acestea constrâng modul de transformare a intrarii în iesire sau controleaza modul în care o activitate poate fi folosita pentru a produce o iesire.

În partea inferioara a dreptunghiului, se prezinta mecanismul folosit de functia sau activitatea respectiva, dar mecanismele nu sunt esentiale modelului SADT.

Dreptunghiul este etichetat cu un verb sau o expresie declarativa care sa exprime clar o actiune de transformare a datelor.

Fiecare sageata este etichetata cu un substantiv.

O diagrama consta dintr-un set de astfel de simboluri din figura anterioara si fiecare element al diagramei poate fi descompus mai departe, prin acelasi tip de relatie parinte-descendent, întâlnit la diagramele SA. Pentru a mentine consistenta si completitudinea nivelelor, intrarile, iesirile si datele de control ale unei diagrame parinte trebuie sa apara si în diagrama descendent. Fiecare descompunere trece astfel prin nivele din ce în ce mai detaliate. Exemplul urmator ilustreaza aceastap descompunere:

Figura 10: Descompunere SADT