Modelarea sistemelor informatice

Curs 1
Partea I. Introducere
 Sisteme
 Sistem = colectie de componente ce interactioneaza intre ele intr-
un mod unitar
 Sisteme:
◦ Naturale: univers, atom, galaxie, ecosistem, sistemul anatomic, etc
◦ Artificiale: masini, avioane, sisteme de control al zbourilor, sisteme
bancare, calculatoare, etc
 Resurse: materiale, energetice si informationale
 Orice sistem are o stare si un comportament
 Dpdv al comportamentului, sistemele se impart in:
◦ Simple: biciclete, etc
◦ Complexe si organizate: masini, vapoare, avioane, sisteme hardware, etc
◦ Complexe si neorganizate: economia unei tari,
bursa marfurilor, etc MEDIU
RESURSE DE RESURSE DE IESIRE
INTRARE

SISTEM
 Sistem informatic si sistem software
 Sistem informatic = sistem complex si organizat format din:
◦ Sistem software
◦ Sistem hardware
◦ Oameni
◦ Baze date si/sau de cunostinte
◦ Documentatie

 Sistem software = sistem complex si organizat format din:

◦ Programe
◦ Structuri de date
◦ Documentatie
 Caracteristicile sistemelor software:
◦ Nu sunt fabricate in sens clasic, ci dezvoltate sau inginerizate
◦ Nu se demodeaza, dar se pot deteriora
◦ Majoritatea sunt create de la zero, nu din compunerea componentelor
existente
 Calitatea sistemelor software
Criteriu Definitie

Timp de raspuns Cat de repede stie sistemul de cererea utilizatorului dupa ce aceasta a fost
transmisa?
Iesirea Cat de multe task-uri realizeaza sistemul intr-o perioada de timp?
Memoria De cata memorie are nevoie sistemul pentru a rula?
Robustete Abilitatea de a trata o intrare invalida de la utilizator
Siguranta Diferenta dintre comportamentul specificat si cel observat
Valabilitate Procentul din timpul sistemului folosit pentru realizarea sarcinilor normale
Toleranta implicita Abilitatea de a opera in conditii eronate
Securitate Abilitatea de a raspunde la fortari a sistemului
Protectie Abilitatea de a nu pune in pericol vieti omenesti, chiar in prezenta erorilor si
esecurilor
Costul de dezvoltare Costul dezvoltarii sistemului

Costul de repartitie Costul instalarii sistemului si pregatirea utilizatorilor

Costul upgrad-arii Costul translatarii datelor de la sistemul anterior, in cazul

reengineering. Acest criteriu rezulta din cerintele de compatibilitate cu
sistemul initial.
Costul de intretinere Costul necesar rezolvarii bug-urilor si imbunatatirii sistemului

Costul de administrare Banii necesari administrarii sistemului

 Calitatea sistemelor software (cont.)
Extensibilitate Cat de usor este sa adaugam noi functionalitati sau noi clase la sistem?
Modificabilitate Cat de usor modificam functionalitatea sistemului?
Adaptabilitate Cat de usor portam sistemul la un nou domeniu al problemei?
Portabilitate Cat de usor portam sistemul la o platforma diferita?
Lizibilitate Cat de usor se intelege sistemul citind codul acestuia?
Urmarirea cerintelor Cat de usor mapam codul la cerintele sistemului?
Utilitate Cat de bine suporta sistemul munca utilizatorului?
Utilizare Cat ii este de usor utilizatorului sa foloseasca sistemul?
COMPROMIS Motivatia
Spatiu vs viteza Daca software-ul nu indeplineste timpul de raspuns impus sau cerintele de
iesire, poate fi expandata mai multa memorie pentru a mari viteza software-
ului.
Termenul de Daca dezvoltarea a depasit orarul, manager-ul proiectului poate livra la timp
livrare vs produsul dar cu mai putina functionalitate de cat era planificata initial, sau sa
functionalitate furnizeze cu toata functionalitatea specificata dar depasind termenul
Termen de livrare Daca testarea a depasit orarul, managerul proiectului poate livra sw-ul la
vs calitate timp, dar cu bug-uri stiute (si apoi sa le rezolve) sau sa livreze mai tarziu,
dar cu cat mai multe bug-uri rezolvate
Termen de livrare Daca dezvoltarea a depasit orarul, managerul proiectului poate adauga
vs staff resurse pentru a creste productivitatea, dar care determina cresterea
costului de dezvoltare. Pentru majoritatea proiectelor, aceasta optiune este
valabila la inceputul proiectului.
Partea a II-a. Specificatii
 Introducere
Specificatie = Descriere abstracta a unui sistem software si a proprietatilor
acestuia.
Tipurile de proprietati ale sistemului includ comportamentul functional, structura
interna, comportamentul temporal, caracteristicile de performanta, constrangerile
de timp real sau de securitate

Abstractizarea implica ignorarea detaliilor care nu sunt relevante dintr-un anumit

punct de vedere, pentru un anumit scop si intr-o anumita faza din procesul de
dezvoltare a produsului software.
Mecanismul de abstractizare permite specificarea unui sistem independent de
orice detaliu de implementare.
De aceea, specificatiile sunt in mod necesar mai simple, facilitand verificarea
acestora. Pentru aceasta analistul foloseste tipuri de date si structuri de date din
domeniul problemei si nu din domeniul solutiei, descrie comportamentul
sistemului in termeni de operatii, si nu cum este obtinut acest comportament, si
defineste nivelul de detaliu necesar. Nivelele de detaliu ale abstractizarii permit
captarea in faza de proiectare a detaliilor de implementare.
 Introducere (cont)
Procesul specificarii se incadreaza in metoda aplicata in dezvoltarea sistemului.
In general, o metoda este un proces disciplinat, format dintr-o multime de reguli
ce trebuie respectate de cel care aplica metoda, numit agent si care vizeaza un
obiectiv, pentru obtinerea caruia este folosita metoda.
O metoda de dezvoltare a unui produs software este definita ca o agregare a patru
componente:
 un proces software
 un model de proces software
 un limbaj de specificare
 euristici
 Proces software
 Proces care conduce la realizarea unui produs software
 O multime de activitati realizate de oameni si/sau masini cu scopul
de a produce si intretine un sistem software si produse auxiliare:
planul proiectului, documente de proiectare, cod, cazuri de testare,
manual de utilizare, etc)
 Proces software (cont.)
 Cadru de referinta in care se desfasoara toate activitatile necesare
obtinerii unui sistem software de calitate
 Defineste strategia adoptata pentru producerea software-ului, nu si
tehnologiile utilizate

Produse intermediare

Puncte de control

Puncte de garantie a calitatii

Colectie de task-uri

Activitati de baza

Activitati auxiliare
Proces software
 Metodologii de dezvoltare a software
 Metodologie = colectie de metode folosite pentru rezolvarea
unei clase de probleme, aplicabile in timpul dezvoltarii unui sistem
si grupate intr-o anumita abordare generala, filozofica.
 O metodologie de dezvoltare sw consta din doua componente
complementare:
◦ Un proces software = secventa de activitati si decizii care muta
sistemul de la concepere pana la terminare;
◦ O notatie standard = forma de comunicare folosita pentru a
documenta cunostintele si deciziile luate pe parcursul procesului de
dezvoltare a sistemului.
 Metodologia structurata (1970-1989) se bazeaza pe principiile:
abstractizare, ierarhizare, separarea datelor (entitatilor) de functii
(procese).
 Metodologii de dezvoltare a software
(cont.)
 Metodologia orientata spre date (1970-1980) se bazeaza pe
principiile:
◦ datele intreprinderii furnizeaza o baza mult mai stabila pentru o
proiectare de sistem decat procedurile intreprinderii, si
◦ datele ar trebui vazute ca o resursa a intreprinderii independenta de
sistemele care le proceseaza.
 Baza acestei metodologii a fost pusa in 1970 odata cu inventarea
modelului relational de baze de date si a modelarii entitate-relatie.
 Metodologia orientata spre obiecte (1990-prezent): sistemul
este modelat numai in termeni de obiecte. Aceste obiecte ofera
servicii (comportament) lumii inconjuratoare si contin informatie.
Obiectele comunica intre ele prin mesaje.
Principiile metodologiei orientata spre
obiecte
 Abstractizare: capacitatea de a capta proprietatile esentiale ale
unei entitati, in cazul nostru, ale unui obiect.
 Incapsulare: datele (starea) si comportamentul (operatii) sunt
incapsulate in obiect. Accesul la un obiect se face numai prin
intermediul interfetei acestuia.
 Mostenire: mecanism folosit pentru partajarea datelor si a
comportamentului comun unei colectii de clase. Aceasta
factorizeaza proprietatile comune ale claselor in supraclase si le
reutilizeaza in definirea subclaselor.
 Polimorfism:
◦ de incluziune: subclasificare
◦ parametrizat: clase template
 Modularitate: Descompunerea unui sistem într-un ansamblu de
module cu o mare coeziune interna si cu legaturi slabe intre ele.
Partea a III-a. Metode semi-formale
de specificare a sistemelor software
 Metode semi-formale ale metodologiei
structurate
 Proiectarea structurata Yourdon-Constantine (1972-1973) a furnizat o metoda
pentru dezvoltarea unui arhitecturi de sistem care sa fie conforma cu principiile
ingineriei software: modularitate, module slab cuplate si coeziunea modulelor. Asadar
accentul a fost pus pe proiectarea de sistem.
 DeMarco (1978) a imbunatatit abordarea structurata, prin descrierea unor pasi ce
conduc analiza structurata, trecand de la modelarea sistemelor existente (introducand
diagrame de fluxuri de date), la modelarea sistemului in curs de dezvoltare (folosind
DFD-uri, mini-specificatii si un dictionar de date). Desi nu a mai fost ignorata
modelarea datelor, accentul era pus in continuare pe modelarea proceselor.
 Continuand traditia structurata, Ward si Mellor (1985) au introdus extensii
importante analizei structurate pentru a suporta mai bine modelarea sistemelor in timp
real.
 Yourdon (1989) a revolutionat versiunea de analiza structurata a lui DeMarco
astfel: adauga o faza preliminara pentru dezvoltarea unui model esential al
sistemului in dezvoltare; inlocuieste tehnica de “partitionare dupa eveniment” cu
descompunerea top-down pentru construirea diagramelor de fluxuri de date;
accentueaza mai mult modelarea informatiilor, prin intermediul diagramelor
entitate-relatie; accentueaza modelarea comportamentala cu ajutorul diagramelor
tranzitie de stari; si incurajeaza prototipizarea.
 Metode semi-formale ale metodologiei
orientate spre obiecte
 Bailin (1988) dezvolta o metoda de specificare orientata spre obiecte a cerintelor,
bazandu-se pe tehnicile folosite in metodologia structurata. Astfel, foloseste diagrame
flux de date ierarhice pentru a descrie fluxul de date intre entitatile active sau intre
functii (operatiile fiecarei entitati) si diagrame entitate-relatie pentru a arata entitatile
si relatiile dintre ele.
 Shlaer si Mellor (1988, 1992) definesc o varianta orientata spre obiecte a modelarii
informatiei, dupa care, in 1992 o extind introducand tehnici pentru specificarea si
comportamentul obiectelor si adaugand concepte ale domeniului si subsistemului.
Metoda Shlaer-Mellor furnizeaza suport implicit pentru principiile OO, mai putin
polimorfism. Obiectele si relatiile din diagrama de structura a informatiei nu sunt
identice cu conceptele OO de clasificare si mostenire, dar pot fi mapate usor la aceste
concepte in timpul proiectarii. Cerinta ca fiecare proces de actiuni (si DFD-ul asociat)
sa fie asociat cu exact un obiect, pastreaza incapsularea acelor operatii.
 Coad si Yourdon (1991) considera ca metoda lor este construita pe “cele mai bune
concepte din modelarea informatiei, a limbajelor de programare OO si din sistemul
bazat de cunostinte”. Metoda Coad-Yourdon suporta explicit toate principiile
metodologiei orientate spre obiecte. Diagrama de clase si obiecte furnizeaza o
clasificare a obiectelor si identifica relatiile potentiale de mostenire. In plus,
incapsularea obiectelor este modelata prin intermediul conceptului de serviciu.
 Metode semi-formale ale metodologiei
orientate spre obiecte
 Booch (1991, 1994) reprezinta structura unui sistem prin diagrame de clase si
comportamentul obiectelor prin diagrame de stari. Comunicarea obiectelor este
reprezentata de Booch prin diagrame de timp, respectiv diagrame de secvente.
 Rumbaugh et al. (1991, 1995) au continuat tehnica de modelare a obiectelor (OMT)
introdusa de Loomis et al. (1987) si au publicat doua versiuni: in 1991 (OMT91) si in
1995 (OMT95). OMT91 pastreaza din metodologia structurata diagramele de fluxuri
de date, pentru a arata cum sunt efectuate calculele de catre sistem in timpul executarii
unei functii ale sistemului. In rest, foloseste diagramele de clase si obiecte pentru a
arata structura sistemului si statechart-urile pentru a arata variatiile de stare din sistem.
In varianta OMT95, Rumbaugh et al. propun o combinatie intre analiza de domeniu a
sistemului si abordarea condusa de cazurile de utilizare introdusa de Jacobson. Acest
lucru inseamna ca pentru identificarea obiectelor se folosesc cazurile de utilizare si
framework-ul MVC (Model-View-Controller). OMT95 poate fi vazut ca o varianta
intermediara intre OMT91 si UML.
 Jacobson et al. (1992, 1995) elaboreaza metoda OO numita OOSE (Object
Oriented Software Engineering), cu varianta comerciala Objectory, care introduce
diagrama de cazuri de utilizare pentru a descrie functionalitatea sistemului, cum am
amintit putin mai sus. In analiza structurii sistemului, Jacobson et al. diferentiaza trei
tipuri de obiecte: obiectele entitate, obiectele de interfata si obiectele de control.
 Metode semi-formale ale metodologiei
orientate spre obiecte
 In 1996, OMG-ul (Object Management Group) lanseaza pe piata cererea de a primi
propuneri pentru a gasi o metoda standard pentru metodologia de modelare orientata
spre obiecte, ca raspuns la nevoia industriei de software de a alege o metoda din
multitudinea metodelor OO ce existau in acel moment.
 Solutia a fost data de Booch, Rumbaugh si Jacobson (1997), care realizeaza
unificarea metodelor lor: Booch, OMT si OOSE. Termenul de unificare este folosit cu
semnificatia ca noua metoda combina conceptele si notatiile folosite in cele trei
metode.
 Incercari de unificare a metodelor existente au existat si inainte de 1997. Un
exemplu important este metoda Fusion (1994) care contine concepte din OMT, Booch
si CRC (Wirfs-Brock, 1990). Tot in 1994, Rumbaugh s-a alaturat lui Booch la Rational
Software Corporation si au reusit sa combine conceptele din metodele OMT si Booch
in 1995, ca o prima incercare de unificare a doua metode. In acelasi an firma Rational
coopteaza si pe Jacobson si astfel toti trei au continuat aceasta munca. Rezultatul a fost
UML (Unified Modeling Language).
 In ianuarie 1997 OMG-ul admite versiunea 1.0 a UML-ului, pe langa alte cateva
propuneri. Cei admisi au negociat o varianta comuna care a dus la versiunea UML 1.1.
Aceasta a fost acceptata ca standard de OMG in noiembrie 1997.