Ingineria sistemelor soft 2013-2014
Curs 6
Proiectarea de sistem (I)
Curs bazat pe B. Bruegge and A.H. Dutoit
"Object-Oriented Software Engineering using UML, Patterns, and Java"
Proiectarea de sistem
Proiectarea de sistem (cont.)
• Procesul de transformare a modelului rezultat din ingineria cerin¸telor într-un model arhitectural al sistemului
• Produse ale proiect ˘arii de sistem
◦ Obiectivele de proiectare (eng. design goals)
• Calit ˘a¸ti ale sistemului pe care dezvoltatorii trebuie s ˘a le optimizeze
• Derivate din cerin¸tele nefunc¸tionale
◦ Arhitectura sistemului
• Subsistemele componente (de dimensiuni mai mici, asignabile unei subechipe de dezvoltare)
• Responsabilit ˘a¸tile subsistemelor ¸si dependen¸tele între ele
• Maparea subsistemelor la hardware
• Strategii de dezvoltare: fluxul global de control, strategia de gesionare a datelor cu caracter persistent, politica de control a accesului
Proiectarea de sistem (cont.)
• Activit ˘a¸ti ale proiect ˘arii de sistem
◦ Identificarea obiectivelor de proiectare
• Identificarea ¸si stabilirea priorit ˘a¸tilor acelor calit ˘a¸ti ale sistemului pe care dezvoltatorii trebuie s ˘a le optimizeze
◦ Descompunerea ini¸tial ˘a a sistemului
• Pe baza modelului func¸tional ¸si a modelelor de analiz ˘a
• Bazat ˘a pe utilizarea unor stiluri arhitecturale standard
◦ Rafinarea descompunerii ini¸tiale pentru a r ˘aspunde obiectivelor de proiectare
• Rafinarea arhitecturii de la pasul anterior, pân ˘a la îndeplinirea tutror obiectivelor de proiectare
• Analogie cu proiectarea arhitectural ˘a a unei cl ˘adiri
◦ Componente: camere vs. subsisteme
◦ Interfe¸te: pere¸ti/u¸si vs. servicii
◦ Reproiectare: mutarea pere¸tilor vs. schimbarea subsistemelor/interfe¸telor
Concepte ˆın proiectarea de sistem
• Subsisteme ¸si clase
• Servicii, interfe¸te ¸si API-uri
• Coeziune ¸si cuplare
• Stratificare ¸si parti¸tionare
• Stiluri arhiecturale ¸si arhitecturi software
Subsisteme s¸i clase
• Subsistem = parte înlocuibil ˘a a unui sistem (constând într-un
num ˘ar de clase din domeniul solu¸tiei), caracterizat ˘a prin interfe¸te bine definite, care încapsuleaz ˘a starea ¸si comportamentul
claselor componente
◦ Descompunerea în subsisteme permite gestionarea complexit ˘a¸tii ("divide et impera")
◦ Un subsistem se dezvolt ˘a, de regul ˘a, de c ˘atre un programator sau o echip ˘a de dezvoltare
◦ Prin descompunerea sistemului în sisteme (relativ) independente, se permite dezvoltarea (relativ) concurent ˘a a acestora
◦ Sistemelor complexe le corespund mai multe nivele de descompunere (Composite pattern)
Subsisteme s¸i clase (cont.)
• Ex.: descompunere în subsisteme a sistemului SGA (diagram ˘a UML de componente)
◦ Subsistemele sunt reprezentate ca ¸si componente UML, cu rela¸tii de dependen¸t˘a între ele
◦ O component ˘a UML poate reprezenta
• O componenta logic ˘a = un subsistem ce nu are un echivalent runtime
• O componenta fizic ˘a = un subsistem ce are un echivalent runtime
Servicii, interfet¸e s¸i API-uri
• Serviciu = mul¸time de opera¸tii înrudite (definite cu acela¸si scop)
◦ Subsistemele sunt caracterizate de serviciile oferite altor subsisteme
◦ Ex.: un subsistem care ofer ˘a un serviciu de notificare va defini opera¸tii de tipul LookupChanel(), SubscribeToChanel(), UnsubscribeFromChanel(), SendNotification()
◦ Serviciile se identific ˘a în timpul proiect ˘arii de sistem
• Interfa¸t˘a (a unui subsistem) = mul¸time de opera¸tii UML înrudite, complet tipizate (numele, parametrii + tipurile lor, tipul returnat)
◦ Rafinare a unui serviciu, specific ˘a interac¸tiunile ¸si fluxul de informa¸tii dinspre
¸si înspre frontiera subsistemului (nu ¸si în interiorul acestuia)
◦ Interfe¸tele se definesc în timpul proiect ˘arii obiectuale
• API (Application Programming Interface) = specificare a unei interfe¸te subsistem într-un limbaj de programare
◦ API-urile se definesc în etapa de implementare
Servicii, interfet¸e s¸i API-uri (cont.)
• Ex.: Interfe¸te/servicii oferite (eng. provided ) ¸si solicitate/utilizate (eng. required )
◦ Nota¸tia UML: conectori ball-and-socket
• Ball (lollipop) = interfa¸t˘a oferit ˘a, socket = interfa¸t˘a solicitat ˘a
• Dependen¸tele dintre subsisteme se reprezint ˘a prin cuplarea conectorilor ball cu cei socket
• Reprezentare utilizat ˘a în momentul în care descompunerea în subsisteme e relativ stabil ˘a ¸si focusul se schimb ˘a de pe identificarea subsistemelor pe identificarea serviciilor (anterior se folosesc rela¸tii UML de dependen¸t˘a)
Coeziune s¸i cuplare
• Cuplare (eng. coupling) = num ˘arul de dependen¸te dintre dou ˘a subsisteme
◦ Cuplare slab ˘a (eng. low coupling) - num ˘ar mic de dependen¸te (subsisteme relativ independente)
◦ Cuplare strâns ˘a (eng. strong coupling) - num ˘ar mare de dependen¸te (schimb ˘arile efectuate într-un sistem îl vor afecta ¸si pe cel ˘alalt)
◦ Dezirabil ˘a într-o descompunere: cuplarea slab ˘a
◦ Reducerea cupl ˘arii conduce, în general, la cre¸sterea complexit ˘a¸tii prin introducerea de subsisteme suplimentare
• Coeziune (eng. coesion) = num ˘arul de dependen¸te din interiorul unui subsistem
◦ Coeziune înalt ˘a (eng. high coesion) - subsistemul con¸tine un num ˘ar mare de clase puternic rela¸tionate ¸si care efectueaz ˘a sarcini similare
◦ Coeziune slab ˘a (eng. low coesion) - subsistemul con¸tine un num ˘ar de clase nerela¸tionate
◦ Dezirabil ˘a într-o descompunere: coeziunea înalt ˘a
◦ Cre¸sterea coeziunii (prin descompunere în subsisteme cu coeziune înalt ˘a) conduce ¸si la cre¸sterea cupl ˘arii, prin dependen¸tele nou introduse
Cuplare
• Ex.: Subsisteme stâns cuplate
◦ Subsistemele de gestiune trimit SGBD-ului comenzi SQL
◦ Trecerea la un alt SGBD sau schimbarea strategiei de persisten¸t˘a (fi¸siere text) determin ˘a modific ˘ari la nivelul tuturor celor trei subsisteme de gestiune
Cuplare (cont.)
• Ex.: Reducerea cupl ˘arii prin inserarea unui subsistem suplimentar
◦ Noul subsistem izoleaz ˘a subsistemele de gestiune de SGBD
◦ Subsistemele de gestiune utilizeaz ˘a doar serviciile oferite de noul subsistem, care va fi responsabil cu trimiterea de comenzi SQL spre SGBD
◦ Trecerea la un alt SGBD sau schimbarea strategiei de persisten¸t˘a va determina doar modific ˘ari la nivelul subsistemului introdus
Coeziune
• Subsistem cu coeziune slab ˘a
◦ Clasele componente pot fi parti¸tionate în dou ˘a submul¸timi slab cuplate
Coeziune (cont.)
• Cre¸sterea coeziunii prin descompunerea subsistemului ini¸tial
Stratificare s¸i partit¸ionare
• Descompunere ierarhic ˘a a unui sistem (stratificare)
◦ Genereaz ˘a o mul¸time ordonat ˘a de straturi (eng. layers)
◦ Un strat reprezint ˘a un grup de subsisteme ce ofer ˘a servicii înrudite, eventual utilizând servicii dintr-un alt strat
◦ Straturile sunt ordonate: un strat poate accesa doar servicii ale straturilor inferioare
• Arhitectur ˘a închis ˘a - fiecare strat poate accesa doar servicii din stratul imediat inferior (scop = modificabilitate/flexibilitate)
• Arhitectur ˘a deschis ˘a - un strat poate accesa servicii din oricare dintre straturile inferioare (scop = eficien¸t˘a )
• Parti¸tionare
◦ Genereaz ˘a un grup de subsisteme la acela¸si nivel (eng. peers), fiecare dintre ele fiind responsabil de o categorie diferit ˘a de servicii
• În general, o descompunere a unui sistem complex este rezultatul
atât al stratific ˘arii, cât ¸si al parti¸tion ˘arii
Stiluri arhitecturale s¸i arhitecturi software
• Descompunerea sistemului (eng. system decomposition) =
identificarea subsistemelor, a serviciilor ¸si a rela¸tiilor între acestea
• Stil arhitectural (eng. architectural style) = ¸sablon de descompunere a sistemelor
• Arhitectur ˘a software (eng. software architecture) = instan¸t˘a a unui stil arhitectural
• Exemple de stiluri arhitecturale
◦ Repository
◦ Model-View-Controller
◦ Client-Server
◦ Peer-to-Peer
◦ Three-tier architecture
◦ Four-tier arhitecture
◦ Pipes and filters
Repository
• Subsistemele acceseaz ˘a ¸si modific ˘a o singur ˘a structur ˘a de date centralizat ˘a, denumit ˘a repository
◦ Subsistemele sunt relativ independente ¸si interac¸tioneaz ˘a doar prin intermediul repository-ului (cuplare slab ˘a)
◦ Fluxul de control poate fi dictat de repository (prin triggere) sau de c ˘atre subsisteme (prin blocaje ¸si sincroniz ˘ari)
Repository (cont.)
• Avantaje
◦ Arhitectur ˘a util ˘a în cazul sistemelor cu necesit ˘a¸ti de procesare complexe, în continu ˘a schimbare
◦ Odat ˘a definit repository-ul, pot fi oferite servicii noi prin definirea de subsisteme adi¸tionale
• Dezavantaje
◦ Subsistemele ¸si repository-ul sunt strâns cuplate, fac ˘and dificil ˘a modificarea repository-ului f ˘ar ˘a a afecta subsistemele
◦ Probleme de performan¸t˘a
• Utilitate
◦ Sisteme de gestiune a bazelor de date
◦ Compilatoare ¸si medii integrate de dezvoltare (eng. Integrated Development Environments, IDEs)
Exemplu de arhitectur ˘a Repository pentru un IDE
Model-View-Controller (MVC)
• Subsistemele sunt încadrate în una din trei categorii
◦ Model - reprezint ˘a informa¸tii/cuno¸stin¸te din domeniul problemei
◦ View - afiseaz ˘a aceste informa¸tii utilizatorului
◦ Controller - translateaz ˘a interac¸tiunile cu view -ul în ac¸tiuni asupra modelului
• Subsistemele model nu depind de nici un subsistem view sau controller
◦ Modific ˘arile produse la nivelul acestora sunt propagate în subsistemele view prin intermediul unui protocol de înscriere/ notificare
◦ Func¸tionalitatea de înscriere/notificare este realizat ˘a, de obicei, cu ajutorul
¸sablonului de proiectare Observer
Model-View-Controller (cont.)
• Justificare
◦ Interfa¸ta utilizator (view-urile ¸si controller-ele) sunt mult mai predispuse spre schimbare decât informa¸tiile din model
◦ Pot fi ad ˘augate vederi noi, f ˘ar ˘a a modifica în alt fel sistemul
• Utilitate
◦ Sisteme interactive, mai ales cele care necesit ˘a diferite vederi ale aceluia¸si model
• MVC este un tip particular de Repository, în care modelul
corespunde structurii repository, iar fluxul de control este dictat de
c ˘atre obiectele controller
Exemplu de arhitectur ˘a MVC
•
Modelul este reprezentat de fi¸sierul 9DesignPatterns.ppt2
•
Una dintre vederi este fereastra CBSE, care listeaza con¸tinutul
directorului cu acela¸si nume, cealalta este fereastra Info, care afi¸seaz ˘a informa¸tii relativ la fi¸sierul 9DesignPatterns.ppt2
•
Schimbarea numelului fi¸sierului determin ˘a actualizarea ambelor vederi
Exemplu de arhitectur ˘a MVC (cont.)
•
Secven¸ta de interac¸tiuni aferent ˘a schimb ˘arii numelui fi¸sierului
9DesignPatterns.ppt2
Client-Server
• Un subsistem, numit server, ofer ˘a servicii instan¸telor unor alte subsisteme, numite clien¸ti, care sunt responsabile de
interac¸tiunea cu utilizatorii
◦ Solicitarea unui serviciu se face, de obicei, printr-un mecanism de apel la distan¸t˘a (Java RMI, CORBA, HTTP)
◦ Fluxurile de control din server ¸si clien¸ti sunt independente, cu excep¸tia sincroniz ˘arilor pentru gestionarea cererilor ¸si primirea r ˘aspunsurilor
• Utilitate
◦ Sisteme distribuite complexe, care gestioneaz ˘a un volum mare de date
Exemple de arhitecturi client-server
• Un sistem informa¸tional cu o baz ˘a de date centralizat ˘a
◦ Clien¸tii sunt responsabili de colectarea inputurilor utilizator, validarea acestora
¸si ini¸tierea tranzac¸tiilor cu baza de date
◦ Serverul este responsabil de executarea tranzac¸tiilor ¸si garantarea integrit ˘a¸tii datelor
◦ Îm acest caz, stilul client/server este o particularizare a stilului repository, în care structura de date centralizat ˘a este gestionat ˘a de un proces
• WWW - un client acceseaz ˘a date oferite de diverse servere
Peer-to-peer
• Generalizare a stilului arhitectural client-server: un subsistem poate juca atât rol de client, cât ¸si de server (fiecare subsistem poate solicita ¸si oferi servicii)
◦ Fluxurile de control sunt independente, cu excep¸tia sincroniz ˘arilor pe cereri
• Exemple
◦ O baz ˘a de date care accept ˘a cereri de la o aplica¸tie, dar o ¸si notific ˘a atunci când se produc schimb ˘ari asupra datelor
Three-tier architecture
• Subsistemele sunt organizate pe trei straturi/nivele
◦ interfa¸t˘a utilizator - include toate obiectele boundary care mediaz ˘a interac¸tiunea cu utilizatorii (ferestre, forme, pagini Web, etc.)
◦ logica aplica¸tiei - include toate obiectele entity ¸si control care realizeaz ˘a verific ˘arile, proces ˘arile ¸si notific ˘arile cerute de aplica¸tie
◦ accesul la date - gestioneaz ˘a ¸si ofer ˘a acces la datele cu caracter persistent
• Avantaje
◦ Nivelul de acces la date joac ˘a rolul repository-ului din stilul arhitectural omonim ¸si poate fi partajat de c ˘atre aplica¸tiile care opereaz ˘a asupra respectivelor date
◦ Separarea dintre logica aplica¸tiei ¸si interfa¸t˘a permite modific ˘ari ale interfe¸tei f ˘ar ˘a a afecta logica aplica¸tiei
MVC vs. Three-tier architecture
• Stilul arhitectural MVC este nonierarhic (triangular)
◦ Subsistemul view trimite cereri c ˘atre subsistemul controller
◦ Subsistemul controller actualizeaz ˘a subsistemul model
◦ Subsistemul view este notificat de c ˘atre subsistemul model
• Stilul arhitectural 3-tier este ierarhic (liniar)
◦ Nivelul de prezentare nu comunic ˘a niciodat ˘a direct cu cel de date (arhitectur ˘a închis ˘a)
• MVC nu acoper ˘a problema persisten¸tei datelor
Four-tier architecture
• O varia¸tie a stilului arhitectural three-tier, în care nivelul interfa¸t˘a se descompune în
◦ prezentare client - localizat pe ma¸sinile client
◦ prezentare server - localizat pe unul sau mai multe servere
• Avantaje
◦ Pe nivelul prezentare client pot exista diferi¸ti clien¸ti, o parte a obiectelor boundary fiind reutilizate
◦ Ex.: un sistem bancar include pe nivelul de prezentare client o interfa¸t˘a Web pentru utilizatori, un ATM ¸si o interfa¸t˘a desktop pentru angaja¸tii b ˘ancii.
Formele partajate de to¸ti clien¸tii sunt definite ¸si procesate la nivelul prezentare
Pipes and filters
• Pipeline - lan¸t de unit ˘a¸ti de procesare (procese, thread-uri, ...)
aranjate astfel încât output-ul uneia reprezint ˘a input-ul urm ˘atoarei
• Pipes and filters - stil arhitectural constând din dou ˘a tipuri de subsisteme, denumite pipes (canale) ¸si filters (filtre)
◦ Filter - subsistem care efectueaz ˘a un pas de procesare
◦ Pipe - conexiune dintre doi pa¸si de procesare
• Fiecare subsistem filtru are un canal de intrare ¸si unul de ie¸sire
◦ Datele preluate din canalul de intrare sunt procesare de c ˘atre filtru ¸si trimise canalului de ie¸sire
