Sunteți pe pagina 1din 15

6.

MODELAREA ÎN ANALIZĂ

Iss_c6

6.1. Definiţii, metode, elemente, etape


Modelarea în analiză
• foloseşte descrieri textuale şi diagrame pentru structurarea cerinţelor privitoare la
datele, funcţiile şi comportamentul sistemului, într-o manieră uşor de înţeles şi care să
permită revizuirea dpdv al corectitudinii, completitudinii şi consistenţei
• este efectuată de analist care construieşte modelele pe baza cerinţelor specificate în
etapa de colectare, analiză şi specificare a cerinţelor
• are următoarele obiective
– să descrie ce doreşte clientul
– să constituie o bază (un punct de plecare) pentru proiectare
– să definească un set de cerinţe pentru validarea sistemului construit

Modelarea în analiză: cerinţe pentru modele


(Arlow J., I. Neustadt, UML and the Unified Process, Addison-Wesley, 2002)
 abstractizare ridicată: modelul trebuie să acorde atenţie cerinţelor vizibile în
domeniul problemei sau ariei de activitate, având un nivel de abstractizare relativ
ridicat
 utilizabilitate: fiecare element al modelului de analiză trebuie să contribuie cu ceva
specific la înţelegerea cerinţelor; el trebuie să acopere domeniul informaţiei sau
funcţionalitatea sau comportamentul
 fără detalii tehnice: referirile la infrastructură sau la alte detalii de ordin fizic aparţin
modelelor de proiectare
 cuplare minimă între elemente (clase şi funcţii)
 util pentru toţi stakeholderii:
 managerii îl folosesc pentru validarea cerinţelor,
 proiectanţii pentru modelele de proiectare,
 testerii pentru planificarea testelor de acceptanţă
• cât de simplu se poate: trebuie să fie uşor de înţeles de toţi stakeholderii.

6.1.1. Domeniul problemei


 Domeniu (domain): domeniul problemei, arie specifică problemei sau organizaţiei în
care se va folosi sistemul soft ţintă
 Domeniu organizaţional (business domain): subdiviziune funcţională a organizaţiei:
contabilitate, producţie, marketing etc
 Problem domain (specific application domain): domeniu generic de aplicaţie în care se
încadrează sistemul soft: gestiunea datelor, controlul proceselor în timp real, jocuri
multimedia, imagerie medicală, calcule statistice etc.
 Analiza domeniului (domain analysis):
 Firesmith (1993) identificarea, analiza şi specificarea cerinţelor comune dintr-
un domeniu (de organizaţie sau de problemă)
 Lethbridge (2003) modelarea domeniului cu scopul unei mai bune înţelegeri a
lui de către analişti şi stakeholderi
 OO domain analysis: identificarea, analiza şi specificarea elementelor comune,
refolosibile dintr-un domeniu de problemă, sub formă de obiecte, clase, asamblări
(assemblies), cadre de aplicaţie (frameworks).
6.1.2. Metode de analiză
• analiza structurată: tratează separat datele şi prelucrările efectuate asupra acestora
1
– obiecte (purtătoare) de date (data objects) (E-R)
• atribute
• relaţii
• depozite de date (tabele)
– fluxuri de date
– procese care manipulează date (DFD)
• fluxuri de intrare
• fluxuri de ieşire
• analiza orientată pe obiecte: tratează împreună datele şi prelucrările efectuate asupra
acestora
– clase
• date
• operaţii
– colaborări (relaţii) între clase
• generalizare
• asociere
• realizare
• dependenţă

6.1.3. Elementele modelului de analiză


• bazate pe scenarii
– descrieri de cazuri de utilizare
– diagrame de cazuri de utilizare
– diagrame de activităţi
• structurale (bazate pe clase)
– diagrame de clase
– diagrame de pachete
– modele CRC
– diagrame de colaborări (comunicare)
• comportamentale
– diagrame de stări
– diagrame de secvenţe
• bazate pe fluxuri
– diagrame de flux de date
– diagrame de flux de control
– descrieri textuale de prelucrări

6.1.4. Etapele modelării (pentru fiecare increment)

1. Selectarea cazurilor de utilizare aferente incrementului curent


2. Modelarea cazurilor de utilizare
2.1. Detalierea cazurilor de utilizare
2.2. Trasarea diagramelor de activităţi
3. Modelarea statică
3.1. Identificarea conceptelor
3.2. Adăugarea de relaţii între concepte
3.3. Adăugarea de atribute
4. Modelarea dinamică
4.1. Desenarea diagramelor de secvenţe sistem
4.2. Specificarea operaţiilor sistem
5. Modelarea fluxurilor de date şi control
5.1. Modelarea fluxurilor de date
2
5.2. Modelarea fluxurilor de control
5.3. Modelarea proceselor

Etapele modelării (pentru fiecare increment)


Rezultate (artefacte) ale analizei (OOA)

Artefact de analiză Răspunde la întrebarea


Cazuri de utilizare Care sunt procesele specifice
domeniului (aplicaţiei)?
Model conceptual Care sunt conceptele, relaţiile şi
atributele?
Diagrame de Care sunt evenimentele de
secvenţe sistem intrare în sistem şi operaţiile
sistem?
Contracte Care este menirea operaţiilor
sistem?

6.2. Modelarea cazurilor de utilizare

6.2.1. Detalierea cazurilor de utilizare


Cazurile de utilizare sistem
– identificate la analiza cerinţelor
– descrise sumar
Detalierea cazurilor de utilizare înseamnă
– (a) descrierea detaliată a celor aferente incrementului curent
– (b) identificarea altor cazuri de utilizare (incluse, extindere) în timpul detalierii
celor de la (a) şi descrierea lor
Modalităţi de descriere
Detalierea cazurilor de utilizare
întrebări (Jacobson, I., Object-Oriented Software Engineering, Addison-Wesley, 1992)
 cine sunt actorii (primar, secundar)?
 care sunt obiectivele actorilor?
 care sunt precondiţiile?
 care sunt principalele sarcini şi funcţii executate de actor?
 ce alte situaţii – de excepţie - trebuie luate în considerare la descrierea
poveştii?
 ce alternative pentru interacţiunea actorului sunt posibile?
 ce fel de informaţie din sistem achiziţionează, produce sau modifică actorul?
 trebuie ca actorul să informeze sistemul asupra modificărilor din mediul
extern?
 de ce informaţie are nevoie actorul de la sistem?
 actorul trebuie informat asupra schimbărilor neaşteptate?

3
6.2.1. Detalierea cazurilor de utilizare: Şablon de descriere Alistair Cockburn
[alistair.cockburn.us]
Numele cazului de utilizare numele cazului de utilizare
Actorul principal şi obiectivul lui actorul primar şi intenţia
acestuia
Stakeholderi (actori secundari) şi diverşi stakeholderi (actori
interesele lor secundari) şi interesele pe care
le reprezintă
Pre-condiţii în ce condiţii se poate iniţia
cazul de utilizare
Post-condiţii condiţii se se obţin prin execuţia
cazului respectiv
Scenariul principal (pe o coloană sau pe două)
Scenarii alternative (pe o coloană sau pe două)

Cerinţe speciale cerinţe nefuncţionale, de calitate


Listă de tehnologii şi date necesare tehnologii şi date implicate în
interacţiune sau prelucrare
Frecvenţa de apariţie minimă, maximă, medie
Probleme deschise probleme de rezolvat

6.2.2. Trasarea diagramelor de activităţi


Fiecărui caz de utilizare i se asociază o diagramă de activităţi
Scop: oferă o reprezentare grafică a fluxului de interacţiuni dintr-un scenariu.
Modalităţi de reprezentare
• obişnuită
• cu culoare (swimlane)

6.3. Modelarea statică


3.1. Identificarea conceptelor
3.2. Adăugarea de relaţii între concepte
3.3. Adăugarea de atribute
Definiţii
• Concept: idee, lucru, obiect; poate fi discutat în termeni
– simbolici (concept=nume) cuvinte sau imagini reprezentând conceptul
– intensivi: există o definiţie a conceptului
– extensivi: există o mulţime de exemple sau instanţe la care se aplică conceptul
• Modelul domeniului ilustrează concepte abstracte şi semnificative din domeniul
problemei
Scopul modelării domeniului:
– descompunerea problemei în concepte (obiecte) individuale, relaţii între
acestea şi detalii ale lor
Modalităţi de identificare a conceptelor din descrierea textuală a domeniului problemei
– folosirea unei liste de categorii de concepte
– identificarea substantivelor şi expresiilor substantivale din descriere

4
6.3.1. Identificarea conceptelor: Lista de categorii de concepte
Categoria conceptului Exemple
obiecte sau lucruri fizice, tangibile POST, Casă, Maşină, Cal, Vapor, Scaun
locaţii Magazin, Birou, Autogară, Şcoală, Primărie
documente, specificaţii, proiecte sau DescriereMarfă, DescriereModul, DescriereTraseu,
descrieri ale unor lucruri ProiectInstalaţii, PlanParter
tranzacţii Vînzare, Plată, Rezervare, Înmatriculare, ÎmprumutCarte
roluri (funcţii) ale oamenilor Casier, Student, Doctor, Pilot, Client, Bibliotecar
containere de alte lucruri Magazin, Bibliotecă, Autobus, Maşină
lucruri în container Marfă, Carte, Pasager, Scaun, Roată
alte sisteme soft sau electro-mecanice SistemDeAutorizareCreditCard, SistemDeControlTraficl,
externe sistemului studiat SistemDeAutorizareCec, SistemDeSalarii
concepte substantive abstracte Foame, Furie, Cleptomanie
organizaţii sau compartimente ServiciuSalarizare, Facultate, DepartamentVânzări
evenimente istorice, incidente Vânzare, Intâlnire, Înmatriculare, Exmatriculare,
RecepţieMarfă
procese (de obicei nu se reprezintă ÎmprumutCarte, RezervareZbor, VânzareMarfă
conceptual, dar pot fi)
reguli şi politici PoliticăDeAmortizare, PoliticăDeSalarizare,
RegulăDePromovare
cataloage (nomenclatoare) NomenclatorMărfuri, CatalogNote, CatalogPiese
contracte, documente fiscale, de Chitanţă, Factură, ContractDeMuncă, NotăDeRecepţie,
muncă, legale RegistruDeÎntreţinere
instrumente şi servicii financiare LinieDeCredit, Stoc
manuale, cărţi ManualDeOperare, Tutorial,

6.3.1. Identificarea conceptelor


Modalităţi de identificare
• folosirea listei de categorii de concepte
• identificarea substantivelor/expresiilor substantivale
– studiul cazurilor de utilizare şi al descrierilor detaliate ale acestora
– se identifică expresiile substantivale - fiecare identifică potenţial un concept
(sau atribut) din domeniul problemei
– se examinează interviurile, chestionarele etc...
– se obţine o listă de substantive
• conţine atât concepte, cât şi atribute: atenţie la deosebiri
Numele conceptelor
• substantive din domeniul problemei la singular
• se elimină caracteristici nerelevante

6.3.2. Adăugarea de relaţii între concepte


5
Relaţie: legătură între concepte
• indică o corespondenţă semnificativă între concepte
• oferă informaţie despre unde este nevoie de cunoaştere
• UML:
– relaţii de asociere: relaţii structurale între concepte (obiecte, instanţe ale
claselor)
• format nume: concept - verb - concept
– se creează o propoziţie care este corectă gramatical şi are
înţeles în contextul modelului domeniului
• direcţie (opţional)
• capete
– rol
– multiplicitate
– relaţii de generalizare (ISA): relaţii între clase
• identificarea relaţiilor: lista de relaţii uzuale

Adăugarea de relaţii între concepte: lista de relaţii uzuale

6.3.3. Adăugarea de atribute la clase


Atribut: identifică o proprietate a conceptului
• instanţa unui concept are valori pentru fiecare dintre atributele conceptului

• sfaturi
– atribute simple (tipuri de date simple)
– asociază tipuri de date la atribute
6
– pentru fiecare concept
• se identifică proprietăţile (atributele) esenţiale pentru modelarea lui
• se adaugă acele proprietăţu (atribute) necesare pentru satisfacerea
cerinţelor funcţionale
– când nu eşti sigur dacă ceva e concept sau atribut, consideră-l concept

6.4. Modelarea dinamică

Scop: construirea unui model comportamental al sistemului, care explică cum reacţionează
sistemul la evenimente externe
– interacţiunea utilizatorului
– mesaje (fluxuri de date sau de control) de la alte sisteme
Paşi:
1. Desenarea diagramelor de secvenţe sistem
Câte una (cel puţin) pentru fiecare caz de utilizare
Identifică evenimentele de intrare în sistem şi operaţiile sistem
2. Specificarea contractelor operaţiilor sistem
Câte un contract pentru fiecare operaţie sistem
Pre-condiţii, post-condiţii
Ce face operaţia

6.4.1. Desenarea diagramelor de secvenţe sistem


Fapte
• În decursul interacţiunii lor cu sistemul, actorii generează evenimente, cerând
sistemului să efectueze (ca răspuns la acestea) o anumită operaţie
• Operaţiile pe care sistemul poate să le execute sunt foarte strâns legate de
evenimentele generate de actori
• Operaţiile sistemului se identifică plecând de la identificarea evenimentelor generate
de actori
Terminologie
• eveniment de intrare în sistem: intrare externă generată de un actor şi direcţionată spre
sistem
– iniţiază o operaţie sistem ca răspuns la eveniment
• operaţie sistem: operaţie executată de sistem ca răspuns la un eveniment de intrare în
sistem
– unele operaţii sistem pot genera evenimente de ieşire din sistem spre actori
(actori, alt sistem) pentru a-l anunţa că poate genera următorul eveniment de
intrare în sistem
• eveniment sistem: eveniment de intrare în sistem sau eveniment de ieşire din sistem
• scenariul unui caz de utilizare: o secvenţă de evenimente sistem care apar pe durata
realizării unui caz de utilizare

Paşi: pentru un caz de utilizare


1. Desenează o linie de viaţă pentru sistem (reprezentat ca obiect)
2. Identifică actorii care interacţionează direct cu sistemul
3. Desenează o linie de viaţă pentru fiecare actor identificat la pasul 2
4. Din scenariul principal al cazului de utilizare identifică evenimentele de intrare în sistem
generate de fiecare actor
5. Pentru fiecare eveniment de intrare în sistem (care identifică o operaţie sistem)
– stabileşte numele şi argumentele (parametrii)
– se trasează pe diagramă un mesaj de la actorul care l-a generat la sistem,
respectând ordinea de apariţie a evenimentelor
7
6. (opţional) Ataşează scenariul cazului de utilizare pentru adnotări
Sfaturi pentru nume şi parametri
• numele evenimentului trebuie să indice intenţia actorului care l-a generat
– nu se specifică modul sau suportul fizic de transmitere
– intenţia se specifică la modul cel mai abstract
– regulă: verb, indică acţiune
– argumente cu nume sugestive

Înregistrarea operaţiilor sistem


• fiecare eveniment de intrare în sistem Event(x1, x2, ..., xn) provoacă execuţia
operaţiei sistem Event(x1, x2, ..., xn).
– numele evenimentului de intrare şi numele operaţiei sistem sunt identice
– deosebire: evenimentul de intrare este stimul, iar operaţia este răspunsul
sistemului la stimul
• atâtea operaţii sistem câte evenimente de intrare sistem
Înregistrarea operaţiilor în diagrama de clase
• în partea de operaţii a clasei
– tipurile parametrilor
nu se detaliază

6.4.2. Specificarea operaţiilor sistem


Fapte
• diagrama de secvenţe sistem nu descrie efectul execuţiei operaţiei apelate
– lipsesc detaliile necesare pentru a înţelege cum se comportă sistemul ca
răspuns la un eveniment de intrare
• pentru a înţelege comportamentul sistemului, trebuie să se evidenţieze schimbările
(tranziţiile) de stare realizate de fiecare operaţie sistem
– exemplu: cum se modifică valorile atributelor sistemului în timpul (şi după)
execuţia operaţiei sistem
– execuţia unei operaţii sistem produce o tranziţie de starea curentă a sistemului
(înainte de operaţie) la o altă stare (după operaţie)
Terminologie
• comportamentul sistemului: descrierea a ceea ce face sistemul, fără a explica concret
cum face
– sistemul este considerat cutie neagră
• contract: document care descrie
– condiţiile în care operaţia se poate executa
– rezultatele obţinute (ce se obţine) după executarea operaţiei
• model de comportament: diagrame de secvenţe sistem + contracte de operaţii
• stare a sistemului: clişeu al sistemului corespunzător unui moment precis care descrie
– obiectele ce există în sistem în momentul respectiv
– valorile curente ale atributelor obiectelor respective
– legăturile curente între obiectele respective
• o tranziţie de stare înseamnă
– ştergerea obiectelor vechi şi a legăturilor acestora cu obiectele rămase
– adăugarea de obiecte noi şi a legăturilor acestora (între ele şi cu obiectele
existente)
– modificarea valorilor atributelor obiectelor existente
• contractul unei operaţii:
8
– signatura operaţiei Nume(args): rezultat
– pre-condiţii: condiţii pe care starea sistemului trebuie să le îndeplinească
înainte de începerea execuţiei operaţiei
– post-condiţii: condiţii pe care le îndeplineşte starea sistemului după terminarea
execuţiei operaţiei
– tripletul Hoare: {pre-condiţii} Nume(args) {post-condiţii}
• contractul unei operaţii sistem
– descrie ce trebuie să se obţină prin execuţia operaţiei sistem
– modificările în starea sistemului după execuţia operaţiei

6.4.2. Specificarea operaţiilor sistem


Paşi
1. Construcţia diagramelor de secvenţe sistem (câte una pentru fiecare caz de utilizare)
– pun accentul pe secvenţa de evenimente din scenariul cazului de utililzare (şi
ordinea în care acestea apar)
– identifică evenimentele sistem
• nume
• argumente
– fiecărui eveniment de intrare în sistem îi corespunde o operaţie sistem (cu
acelaşi nume)
2. Specificarea contractului pentru fiecare operaţie
– care sunt condiţiile normale în care operaţia se poate executa (apela)
• pre-condiţii (predicate ce referă starea sistemului dinainte de execuţie)
– ce se obţine prin execuţia operaţiei
• post-condiţii (predicate ce referă starea sistemului după execuţie)
• cum se modifică starea sistemului pe măsură ce operaţia se execută

Specificarea operaţiilor sistem


Şablon de contract

9
6.4.2. Specificarea operaţiilor sistem
Sfaturi generale
• se foloseşte un stil declarativ, cu accentul pus pe ceea ce trebuie să se producă
• formularea pre- şi post-condiţiilor
– pre-condiţii: exprimate la prezent
• exemplu: codul mărfii există în tabela Nomenclator
– post-condiţii: la timpul trecut
• exemple:
corect: a fost creată o înregistrare de MarfăVândută
incorect: creează o înregistrare de MarfăVândută
• sfat: se accentuează că post-condiţiile sunt declaraţii despre o tranziţie
de stare efectuată în trecut, şi nu acţiuni (care se execută în prezent)
Pre-condiţiile
• definesc ipoteze privitoare la starea sistemului dinaintea începerii execuţiei operaţiei
• conţin
– condiţii (precizate explicit sau implicite) care nu se testează în corpul operaţiei
– condiţii esenţiale pentru execuţia operaţiei în bune condiţii
• comunicarea rezultatelor analizei la alţii (proiectanţi, implementatori,
testeri)

Post-condiţiile
• pentru descrierea declarativă a tranziţiilor de stare pentru lucrurile (obiectele) din
modelul domeniului (modelul conceptual) se foloseşte metafora scenei şi a cortinei
• paşi
– înainte de execuţia operaţiei:
• se ridică cortina,
• se ia un clişeu al scenei ce conţine toate lucrurile din modelul
domeniului (pre-stare)
– începe execuţia operaţiei
• se lasă cortina
• porneşte execuţia operaţiei
– se termină execuţia operaţiei
• se ridică cortina din nou
• se ia un clişeu al scenei ce conţine toate lucrurile din modelul
domeniului (post-stare)
• se compară stările pre-stare şi post-stare şi se notează modificările
observate
– se pune accentul pe următoarele tipuri de modificări
» crearea şi ştergerea de instanţe (apar obiecte noi în
scenă, dispar obiecte din scenă)
» modificarea valorilor atributelor obiectelor
» legături (asociaţii) formate sau distruse (legături noi
între obiecte, vechi legături distruse)
• toate modificările observate se scriu în post-condiţii
• grad de detaliere şi de completitudine
– OOA:
• nu este necesară scrierea unui set complet de post-condiţii
• post-condiţiile într-un contract din OOA reprezintă cea mai bună
evaluare făcută la momentul respectiv
– OOD:
• post-condiţii detaliate, precise, complete

10
• se descoperă mai multe detalii legate de operaţie, tranziţiile de stare
şamd.

6.5. Modelarea fluxurilor

6.5.1. Modelarea fluxurilor de date


Oferă o vedere IPO a sistemului (Input-Process-Output)
Modele: DFD + diagramă de descompunere a proceselor (DD)
• mai multe nivele de detaliere pentru DFD, explicate de DD
• nivelul 0: diagrama de context
– un singur proces: sistemul (rădăcina DD)
– entităţi externe
– fluxuri de intrare şi de ieşire în sistem
– modelul de date inclus în sistem
• nivelul 1: DFD cu procesele esenţiale (primul nivel din DD)
– descompunerea sistemului
– toate entităţile din diagrama de context
– toate fluxurile din diagrama de context (eventual mai detaliate)
– modelul de date al sistemului
– fluxuri între procesele esenţiale (interne sistemului)
• nivelele următoare: DFD conţine procesele de pe nivelele ³ 2 din DD
– reprezintă descompunerea unui proces P de pe nivelul anterior
– toate fluxurile de intrare şi ieşire din P de pe nivelul anterior (eventual
detaliate)
– depozite de date concrete
– fluxuri între procese (interne procesului P)

6.5.2. Modelarea fluxurilor de control


Necesară pentru aplicaţiile reactive (bazate pe evenimente)
– modelarea interfeţei cu utilizatorul
– sisteme de control în timp real (lift, instalaţii cu senzori, procese chimice etc)
Paşi
– identificarea evenimentelor externe
– specificarea reacţiei sistemului la evenimente
• se apelează procese
• se produc modificări de stare
Specificarea fluxurilor de control se poate face prin
– diagrama de stări
– tabela de activare a programului
Particularităţi OOA
– diagrama preliminară de stări (nivel 0)
– grad scăzut de detaliere
• sistemul - cutie neagră

6.5.3. Modelarea proceselor


Specificarea proceselor: descrie procesele primitive ce apar în modelele de flux de date şi de
control
Modalităţi de specificare
• text nestructurat
• pseudocod (Process/Program Design Language, PDL)
• diagrame
– scheme logice
11
– Nassi-Shneiderman
• tabele de decizie
OOA: text nestructurat

6.6. Studiu de caz: POST

POST: exemplu de concept


• Numele conceptului (simbol): Vânzare
• Definiţie (intensiv): evenimentul ce corespunde unei tranzacţii de cumpărare de
mărfuri
• Exemplu (extensiv): este caracterizată de: coordonatele spaţiale (magazinul) şi
temporale (data şi ora), suma plătită, mărfurile cumpărate (denumire, cantitate, preţ),
metoda de plată etc

POST: modelul conceptual (numai concepte)

12
POST: modelul conceptual (clase şi relaţii)

POST: modelul conceptual (clase, relaţii şi atribute)

13
POST: caz de utilizare şi
diagrama de secvenţe sistem

POST: specificarea post-condiţiilor pentru operaţia sistem


introducereMarfă(cod, cant)

• Signatură: introducereMarfă(cod, cant)


• Creare şi distrugere de instanţe
– a fost creată o nouă MarfăVândută
– a fost creată o nouă Vânzare (la primul apel)
• Modificare de atribute
– MarfăVândută.cantitate a fost setată la cant.
– Vânzare.nrMărfuri a fost actualizat.
• Asocieri formate şi/sau distruse
– nou-creata MarfăVândută a fost inclusă în Vânzarea curentă.

14
POST: specificarea contractului pentru introducereMarfă(cod, cant)

15