1

Cap. 5
Proiectarea Sistemelor Software.
Fundamente de Inginerie Software
2009
Conf.Dr.Ing. Dan Pescaru
Textbooks: Sommerville Software Engineering 7, 2004, Cap. 11
Maciaszek Practical Software Engineering, 2005, Cap. 9
Surs: http://www.comp.lancs.ac.uk/computing/resources/IanS/SE7/
http://www.comp.mq.edu.au/books/pse/
2
FIS conf.dr.ing. Dan Pescaru
Arhitectura unui Sistem Software
Arhitectura unui Sistem Software este
organizarea tuturor elementelor software innd cont
de:
Suportabilitate (claritate + mentenabilitate +scalabilitate)
Managementul interdependenelor
Organizarea n module specifice (clase, pachete,
componente)
Comportamentul modulelor
Tipare i principii arhitecturale
Proiectarea arhitectural este setul de decizii
menite s asigure o arhitectur eficient i logica din
spatele acestor decizii
3
FIS conf.dr.ing. Dan Pescaru
Dimensiune i Complexitate
Sisteme motenite (Legacy Systems):
Monolitice, procesare secvenial i predictibil
Complexitate = Dimensiune
Sisteme obiectuale:
Distribuite, procesare aleatoare i nepredictibil
Complexitatea = Legturi, dependene
Tipar Facade
4
FIS conf.dr.ing. Dan Pescaru
Obiectivele Proiectrii Arhitecturale
Identificarea componentelor majore ale sistemului
i a comunicaiilor dintre acestea
Proiectarea unor module software organizate pe
nivele pentru a reduce complexitatea i a mari gradul
de nelegere a dependenelor dintre module
Se interzic intercomunicaiile directe ntre obiectele de pe
nivele vecine
5
FIS conf.dr.ing. Dan Pescaru
Caracteristicile unui Sistem
Performana
Localizarea operaiilor critice i minimizarea comunicaiilor. Se
recomand utilizarea componentelor cu granularitate mare
Securitatea
Utilizarea unui arhitecturi stratificate cu plasarea secvenelor critice
pe nivelele interne
Sigurana
Localizarea detaliilor critice din punct de vedere al siguranei ntr-
un numr mic de sub-sisteme
Disponibilitatea
Include componente redundante i mecanisme tolerante la erori
Mentenabilitatea (Uurina la ntreinere)
Utilizarea unor componente fine, uor de nlocuit
6
FIS conf.dr.ing. Dan Pescaru
Conflicte Arhitecturale
Utilizarea unor componente de granularitate mare
mbuntete performana dar reduce
mentenabilitatea
Introducerea unor date redundante crete
disponibilitatea dar face mult mai dificil asigurarea
securitii
Localizarea detaliilor critice din punct de vedere al
siguranei de obicei duce la creterea comunicaiilor
i deci scderea performanei
7
FIS conf.dr.ing. Dan Pescaru
Structurarea Sistemului
Prin structurare se urmrete descompunerea
sistemului n subsisteme care interacioneaz ntre
ele
n mod normal proiectarea arhitectural este
exprimat ca o diagram bloc
Diagramele care descriu arhitectura ofer o privire de
ansamblu asupra sistemului
8
FIS conf.dr.ing. Dan Pescaru
Exemplu
Sistem de control pentru un robot de mpachetat (Sommervile`04):
Sistem
vizualizare
Sistem de
identificare
obiecte
Controler
bra
Control
strngere
Sistem
selecie
mpachetare
Sistem
mpachetare
Controler
transport
9
FIS conf.dr.ing. Dan Pescaru
Decizii la Proiectarea Arhitectural
Proiectarea este un proces creativ. Totui este bine de
considerat urmtoarele ntrebri la luarea deciziilor:
Exist o arhitectur generic ce poate fi utilizat?
Cum va fi distribuit sistemul?
Ce stil arhitectural se potrivete?
Ce concept poate fi aplicat pentru structurarea sistemului?
Cum va fi sistemul descompus pe module?
Ca strategie de control se poate utiliza?
Cum va fi evaluat proiectarea arhitectural?
Cum va fi documentat arhitectura propus?
10
FIS conf.dr.ing. Dan Pescaru
Reutilizarea Arhitecturii
Sistemele dintr-un anumit domeniu au foarte des
arhitecturi similare. Aceste arhitecturi reflect
conceptele din respectivele domenii.
Liniile de produs aplicaii sunt create n jurul unei
arhitecturi centrale cu variante care s satisfac
cerine particulare a diverilor clieni
11
FIS conf.dr.ing. Dan Pescaru
Stiluri Arhitecturale
Stilul arhitecturii unui sistem se subscrie de regul
unui stil arhitectural generic
Considerarea unui stil general poate simplifica
definirea arhitecturii sistemului
Totui, cele mai multe sisteme mari sunt eterogene i
nu se conformeaz unui singur stil
12
FIS conf.dr.ing. Dan Pescaru
Modele de Arhitecturi
Modele structurale (statice) scot n eviden componentele
majore ale sistemului
Modele de proces (dinamice) arat structura proceselor
sistemului
Modele de interfee definesc interfeele diverselor sub-sisteme
Modele de relaii (ex. modele de fluxuri de date) indic
relaiile ntre sub-sisteme
Modelul de distribuie arat cum sunt distribuite sub-sistemele
pe diversele sisteme de calcul
13
FIS conf.dr.ing. Dan Pescaru
Organizarea unui Sistem
Reflect strategia de baz care este utilizat pentru
structurarea unui sistem
Cele mai rspndite trei stiluri de organizare sunt:
Cu zon de date partajat
Stil server cu servicii partajate
Model organizat pe nivele (main abstract)
14
FIS conf.dr.ing. Dan Pescaru
Modelul cu zon de date partajat
Sub-sistemele schimb date n dou moduri posibile:
Datele partajate sunt reinute ntr-o baz de date central i
pot fi accesate de toate sub-sistemele
Fiecare sub-sistem menine propria baz de date i transfer
datele explicit la celelalte sub-sisteme
Modelul cu zon partajat de date se adreseaz n
principal sistemelor care partajeaz cantiti mari de
date
15
FIS conf.dr.ing. Dan Pescaru
Caracteristici
Avantaje
Mod eficient de partajare a unor cantiti mari de date
Gestionare centralizat: securitate, backup etc. Sub-sistemele nu
sunt influenate de maniera de producere a datelor
Modelul partajat este prezentat printr-o schem de depozitare
Dezavantaje
Sub-sistemele trebuie s adere la acelai model de stocare a
datelor. Ca atare se vor impune compromisuri
Evoluia datelor este dificil i costisitoare
Nu permite politici de gestiune specifice
Dificil de distribuit n mod eficient
16
FIS conf.dr.ing. Dan Pescaru
Arhitectur CASE tool pentru model
Project
repository
Design
translator
Program
editor
Design
editor
Code
generator
Design
analyser
Report
generator
17
FIS conf.dr.ing. Dan Pescaru
Modelul Client-Server
Un model de sistem distribuit axat pe modul n care
datele i procesele sunt distribuite pe mai multe
sisteme de calcul
Componente:
Un set de servere care asigur servicii specifice precum:
tiprire, gestionarea datelor etc.
Un set de clieni care apeleaz aceste servicii
O reea care asigur accesul clienilor la servere
18
FIS conf.dr.ing. Dan Pescaru
Caracteristici
Avantaje
Distribuia datelor este direct;
Utilizeaz eficient sistemele de reea. Costuri mici cu
hardware-ul
Uor de adugat noi servere sau de mbuntit cele
existente
Dezavantaje
Sub-sistemele pot organiza datele n mod diferit, ceea ce
poate duce la un schimb de date ineficient
Gestiune redundant la nivelul fiecrui server
Nu exist gestiune centralizat pentru nume i servicii. Poate
devenii dificil de gsit ce servere i servicii sunt disponibile
19
FIS conf.dr.ing. Dan Pescaru
Exemplu de arhitectur n domeniul media
Catalogue
server
Library
catalogue
Video
server
Film clip
files
Picture
server
Digitised
photographs
Web server
Film and
photo info.
Client 1 Client 2 Client 3 Client 4
Internet
20
FIS conf.dr.ing. Dan Pescaru
Model pe Nivele (main abstract)
Utilizat pentru modelarea interfeelor ntre sub-
sisteme
Organizeaz sistemul ntr-un set de nivele (sau
maini abstracte), fiecare asigurnd un set de servicii
Setul de servicii definete un limbaj main pentru
nivelul respectiv
Ex: modelul de reea OSI
21
FIS conf.dr.ing. Dan Pescaru
Model pe Nivele (main abstract)
Sprijin dezvoltarea incremental a sub-sistemelor pe
diferite nivele. Schimbarea interfeei unui nivel
afecteaz doar nivelele adiacente acestuia
Este portabil (necesit doar schimbarea nivelelor de
baz)
De multe ori ns este artificial de structurat un
sistem n acest mod
Nivelele superioare pot depinde direct de servicii
oferite de nivelele cele mai de jos. Trimiterea
cererilor din aproape n aproape pot degrada
performana
22
FIS conf.dr.ing. Dan Pescaru
Model pentru gestionarea versiunilor obiectelor
(Buxton 80 Ada Programming Support Environment APSE)
23
FIS conf.dr.ing. Dan Pescaru
Descompunerea Sub-sistemelor n Module
Nu se face o distincie rigid ntre descompunerea n
module i organizarea general a sistemului
n general granularitatea modulele este mai fin
dect cea a sub-sistemelor
Sub-sistemele sunt la rndul lor sisteme compuse din
module
Modulele nu sunt sisteme independente
24
FIS conf.dr.ing. Dan Pescaru
Descompunerea n Module
Dou modele principale de descompunere:
Un model obiectual un sistem este descompus n obiecte
care interacioneaz ntre ele
Un model pipeline (sau flux de date) un sistem este
descompus n module funcionale care transform intrrile n
ieiri
Dac este posibil, deciziile care se refer la accesul
concurent se vor lua abia la implementarea
modulelor, programele secveniale fiind mai uor de
proiectat i implementat
25
FIS conf.dr.ing. Dan Pescaru
Modelul Obiectual
Structureaz sistemul ntr-un set de obiecte slab
cuplate dar cu interfee bine definite
Paii principali constau n identificarea claselor
obiectelor a atributelor i a operaiilor lor
Obiectele menin o stare proprie (privat) i definesc
operaiile prin care aceasta poate fi modificat
26
FIS conf.dr.ing. Dan Pescaru
Model obiectual pentru procesat facturi
emite()
trimiteAtenionare()
acceptaPlat()
trimiteConfirmare()
numrFactur
data
suma
client
numrFactur
data
suma
clientID
numrFactur
data
suma
clientID
clientID
nume
adres
perioad de creditare
Client
Plat
Factura
Confirmare
27
FIS conf.dr.ing. Dan Pescaru
Avantajele Modelul Obiectual
Cuplarea ntre obiecte este slab ca atare
implementarea unuia poate fi modificat fr a afecta
celelalte obiecte
Obiectele pot reflecta n mod natural entitile din
lumea real
Limbajele orientate pe obiecte sunt larg utilizate
Dezavantaje:
o schimbare n interfeele obiectelor poate crea probleme
entitile complexe pot fi greu de reprezentat ca obiecte
28
FIS conf.dr.ing. Dan Pescaru
Modelul Funcional Pipeline
Proceseaz intrrile n ieiri conform unor
transformri funcionale
Asemntor cu modelul pipe din shell-ul UNIX
Variante ale acestui concept sunt des ntlnite. Cnd
transformrile sunt secveniale, acesta este un model
de prelucrare a loturilor de date foarte comun n
sistemele de procesare a datelor
Nu este recomandabil n cazul sistemelor interactive
cu intrri complex (tastatur, GUI, mouse etc.)
29
FIS conf.dr.ing. Dan Pescaru
Model Pipeline pentru procesare facturi
Citete facturile
emise
Identific
plile
Elibereaz
chitane
Gsete
plile
scadente
Chitane
Emite
somaii
de plat
Somaii de plat
Facturi Pli
30
FIS conf.dr.ing. Dan Pescaru
Avantajele Modelului Pipeline
Sprijin reutilizarea transformrilor
Organizare intuitiv
Uor de adugat noi transformri
Relativ uor de implementat att concurent ct i
secvenial
Dezavantaje:
necesit un format comun pentru transferul datelor de-a
lungul pipeline-ului
interaciunea bazat pe evenimente este dificil de
implementat
31
FIS conf.dr.ing. Dan Pescaru
Stiluri de Control
Stabilete controlul fluxului ntre sub-sisteme (distinct
fa de modelul de decompoziie
Control centralizat
Un sub-sistem are rspunderea global de a controla, porni
i opri alte sub-sisteme
Control bazat pe evenimente
Fiecare sub-sistem poate rspunde la evenimente venite din
exterior de la alte sub-sisteme sau de la mediul n care
sistemul funcioneaz
32
FIS conf.dr.ing. Dan Pescaru
Control Centralizat
Un sub-sistem de control are responsabilitatea
gestionrii execuiei altor sub-sisteme (decizii luate
pe baza valorilor unor variabile de stare)
Modelul apel-rspuns
Model top-down la care controlul pornete de la subrutinele
cele mai de sus din ierarhie i migrez n jos. Este aplicabil
sistemelor secveniale
Modelul gestionar
Aplicabil n cazul sistemelor concurente. O component de
sistem controleaz oprirea, pornirea i coordonarea altor
procese din sistem. Poate fi implementat n sisteme
secveniale ca i o secven condiional cu valori multiple
33
FIS conf.dr.ing. Dan Pescaru
Modelul Apel-Rspuns
34
FIS conf.dr.ing. Dan Pescaru
Controlul unui sistem de timp-real
System
controller
User
interface
Fault
handler
Computation
processes
Actuator
processes
Sensor
processes
35
FIS conf.dr.ing. Dan Pescaru
Control Bazat pe Evenimente
Condus de evenimente generate extern,
independente de controlul sub-sistemelor care
proceseaz evenimentele
Dou modele principale:
Modelul broadcast. Un eveniment este trimis tuturor sub-
sistemelor. Orice sub-sistem poate procesa evenimentul
Modelul bazat pe ntreruperi. Utilizat n sistemele de timp
real unde ntreruperile sunt detectate de un handler de
ntrerupere i trimise altor componente pentru procesare
36
FIS conf.dr.ing. Dan Pescaru
Modelul Broadcast
Eficient la integrarea sub-sistemelor de pe diverse
calculatoare ntr-o reea
Sub-sistemele se nregistreaz pentru evenimentele
de interes. Cnd un astfel de eveniment apare,
controlul este transferat sub-sistemului care poate
trata acel eveniment
Politica de control nu este inclus n eveniment sau n
gestionarul de mesaje. Sub-sistemele decid ce
evenimente le intereseaz
Totui, sub-sistemele nu tiu dac sau cnd un
eveniment va fi tratat de alte sub-sisteme
37
FIS conf.dr.ing. Dan Pescaru
Broadcast Selectiv
Sub-system
1
Event and message handler
Sub-system
2
Sub-system
3
Sub-system
4
38
FIS conf.dr.ing. Dan Pescaru
Modelul Bazat pe ntreruperi
Utilizat n sistemele de timp-real unde rspunsul rapid
la evenimente este esenial
Se bazeaz pe un set de tipuri cunoscute de
ntreruperi fiecare avnd definit cte un handler
(rutin de tratare)
Fiecare tip are asociat o locaie de memorie. Un
comutator hardware va face transferul ctre
handlerul corespunztor
Permite un rspuns rapid dar este complex de
programat i dificil de validat
39
FIS conf.dr.ing. Dan Pescaru
Control Bazat pe ntreruperi
40
FIS conf.dr.ing. Dan Pescaru
Arhitecturi specifice
Modelele arhitecturale pot fi specifice unui anumit
domeniu
Exist dou tipuri de modele specifice unui domeniu
Modele generice abstracii ale unui numr mare de sisteme
reale i care ncapsuleaz caracteristicile principale ale
acestora
Modele de referin mai abstracte (modele ideale). Asigur
o privire larg asupra clasei respective de sisteme i ajut la
compararea diverselor arhitecturi
Modelele generice sunt n general de tip bottom-up
pe cnd cele de referin sunt de tip top-down
41
FIS conf.dr.ing. Dan Pescaru
Modele de referin
Modelele de referin sunt derivate din studierea
domeniului aplicaiei mai degrab dect din studierea
sistemelor existente
Pot fi utilizate ca o baz pentru implementare sau
pentru compararea sistemelor
Pot juca rolul unui standard fa de care sistemele
pot fi evaluate
Ex: Modelul OSI un model pe nivele pentru
sistemele de comunicaii
42
FIS conf.dr.ing. Dan Pescaru
Modelul de referin OSI
Presentation
Session
Transport
Network
Datalink
Physical
7
6
5
4
3
2
1
Communications medium
Network
Datalink
Physical
Application
Presentation
Session
Transport
Network
Datalink
Physical
Application
43
FIS conf.dr.ing. Dan Pescaru
Modelul de referin pentru CASE
Modelul asigur urmtoarele servicii pentru un mediu CASE:
Data repository services
Stocarea i gestionarea datelor
Data integration services
Gestionarea grupurilor de entiti
Task management services
Definirea modelelor de proces. Sprijin pentru integrarea proceselor
Messaging services
Comunicaii ntre uneltele CASE i ntre unelte i mediu
User interface services
Dezvoltarea interfeelor utilizator
44
FIS conf.dr.ing. Dan Pescaru
Modelul ECMA (1991)
Tool
slots
Message
services
Task management services
User interface services
Data repository services
Data integration services
45
FIS conf.dr.ing. Dan Pescaru
Concluzii
Arhitectura software este cadrul fundamental pentru
structurarea unui sistem
Proiectarea arhitectural include deciziile referitoare la
arhitectura aplicaiei, la distributivitate i la stilul arhitectural
care va fi utilizat
Pot fi dezvoltate diferite modele arhitecturale precum modele
structurale, modele de control i modele de decompoziie
Modelele de organizare a sistemelor includ modele de stocare,
modele client-server i modele pe nivele (maini abstracte)
46
FIS conf.dr.ing. Dan Pescaru
Concluzii
Modelele de decompoziie a modulelor includ modele obiectuale
respectiv pipeline
Modelele de control includ controlul centralizat i modelele
bazate pe evenimente
Arhitecturile de referin pot fi utilizate pentru explicitarea
arhitecturilor specifice unor domenii. De asemenea ele pot fi
utilizate pentru evaluarea i compararea proiectelor
arhitecturale
47
FIS conf.dr.ing. Dan Pescaru
Atribute ale Arhitecturii
Performana
Localizarea operaiilor pentru minimizarea comunicaiilor la nivelul
sub-sistemelor
Securitatea
Utilizarea unui arhitecturi pe nivele care s pstreze aspectele
sensibile pe nivelele interioare
Sigurana
Izolarea componentelor critice
Disponibilitatea
Includerea unor componente redundante n arhitectur
Mentenabilitatea
Utilizarea unor componente de granularitate fin