Fundamentele programrii

curs 7
Principii de proiectare
Diagrame UML
Arhitectura stratificat
abloane Grasp

Diagrame UML
Unified Modeling Language (UML) - este un limbaj standardizat de
modelare destinat vizualizrii, specificrii, modelrii i documentrii

aplicaiilor.
UML include un set de notaii grafice pentru a crea modele vizuale ce

descriu sistemul.

Diagrame UML
Diagrame de clase
n UML clasele sunt reprezentate sub form de dreptunghiuri cu trei compartimente
pentru:
numele clasei,
compartimentul din mijloc afieaz atributele clasei,
compartimentul inferior conine operaiile clasei

Vizibilitatea membrilor:
- privat (inaccesibil pentru toate celelalte clasele)
# protejat (accesibil pentru subclase)
+ vizibil pentru toate celelelate clase
~ vizibil pentru clasele din acelai pachet

Diagrame UML
Diagrame de clase - Exemplu

from Rational import Rational

class Calculator(object):
'''
defineste un calculator de nr rationale
'''
def __init__(self):
self.total=Rational(0,1)
self.undoStack=[]

def get_total(self):
return self.total
def add(self,a):
'''adauga la total numarul a
parametrii: a
prec: a-nr rational
post: total =tolal+a
'''
copie=Rational(self.total.get_nominator(),self.total.get_denominator())
self.undoStack.append(copie)
self.total.addToSelf(a) #total=total+a

def undo(self):
'''anuleaza ultima operatie'''
if len(self.undoStack)>0:
self.total=self.undoStack.pop()

Diagrame UML
Relaii ntre clase
Descriu modul n care obiectele unei clase sunt conectate/interacioneaza cu obiectele altei clase

Tipuri de relaii:
Relaia de asociere
Agregare
Compunere
Dependenta
Generalizare

Diagrame UML - Relaii ntre clase

Relaia de asociere
Descrie modul n care obiectele unei clase sunt conectate cu obiectele altei clase
O asociere poate avea nume, capetele asocieri pot fi adnotate cu nume de roluri, multiplicitate, vizibilitate
i alte proprieti. Asocierea poate fi unidirecional sau bi-direcional
Rol

Multiplicitate

Diagrame UML - Relaii ntre clase

Relaia de agregare (compunere)
modeleaz o relaie de tip 'parte/ntreg'
arata cum obiectele mai mari sunt compuse din obiecte mai mici
poate fi privita si ca o relatie speciala de asociere
exista doua tipuri de agregare

agregare slaba (romb neumplut), cand o componenta poate apartine la mai multe agregate
(obiecte compuse)
agregare tare (romb umplut cu negru), cand o componenta poate apartine la cel mult un
agregat (obiect compus)

Diagrame UML - Relaii ntre clase

Relaia de agregare tare

un contact apartine
la o singura agenda;
stergere agenda =>
stergere contact

o agenda poate avea

zero sau mai multe
contacte

Diagrame UML - Relaii ntre clase

Relaia de agregare slaba
un contact apartine la
una sau mai multe
agende; un contact poate
exista si dupa stergere
agendei

o agenda poate
avea zero sau mai
multe contacte

Diagrame UML - Relaii ntre clase

Generalizare Motenire

Diagrame UML - Relaii ntre clase

Relaia de Dependen- element depinde sau foloseste un alt element

Exemple de dependene:
creaz instane
are un parametru
foloseste un obiect n interiorul unei metode

Arhitectura stratificat
Arhitectura stratificat ablon arhitectural care permite dezvoltarea

de sisteme flexibile n care componentele au un grad ridicat de

independen
Fiecare strat comunic doar cu startul imediat urmtor (depinde doar de
stratul imediat urmtor)

Fiecare strat are o interfa bine definit (se ascun detaliile), interfa folosit
de stratul imediat superior

Arhitectura stratificat cont

Layer (strat) grupare logic a elementelor ce compun un sistem
software
n arhitectura multi-stratificat, straturile sunt folosite pentru a aloca
responsabilitile n aplicaie.
Stratul este un grup de clase (sau module) care au acelai set de
responsabiliti i aceleai dependene cu alte module

Arhitectura stratificat
User Interface Layer (View Layer, UI layer sau Presentation layer)

Application Layer (Service Layer sau GRASP Controller Layer)

Domain layer (Business Layer, Business logic Layer sau Model Layer)
Infrastructure Layer (acces la date modaliti de persisten,
logging, network I/O ex. Trimitere de email sau alte servicii technice)

Enunt problema Gestiune studenti

Scrieti o aplicatie care sa gestioneze studentii unei facultati. Intr-o
iteratie initiala, aplicatia va oferi urmatoarele functionalitati:
Adauga student
Modifica student

Sterge un student
Filtreaza:
Dupa nume
Dupa matricol

Principii de proiectare
O bun proiectare este aceea care conduce la obtinerea unui
system soft:
Uor de neles, testat, ntreinut, modificat

O bun proiectare necesit aplicarea unor euristici, reguli,

principii de proiectare, abloane de proiectare.

Principii de proiectare
abloane Grasp- General Responsibility Assignment Software
Patterns (or Principles)
conin recomandri pentru alocarea responsabilitilor ntr-o aplicaie orientat obiect.
High Cohesion
Low Coupling
Information Expert
Controller
Protected Variations
Creator
Pure Fabrication

abloane Grasp
Low Coupling
Aloc responsabiliti astfel nct cuplarea rmne slab (redus)

ntr-o proiectare orientat pe obiecte, cuplajul reprezint gradul de interconectare dintre

entittile sale.

Cuplajul este un criteriu important de evaluare a proiectarii deoarece el caracterizeaza dou

proprieti mult dorite:
o modicare ntr-o parte a sistemului trebuie sa aiba un impact minim asupra celorlalte parti
ntelegerea unui modul trebuie sa necesite ntelegerea unui numar ct mai mic de alte module.

abloane Grasp
Low Coupling

Un cuplaj excesiv afecteaza n mod negativ diverse atribute externe ale calitii precum:
Reutilizabilitatea un cuplaj puternic al unei entiti scade reutilizabilitatea acesteia datorit dependenei de
context
Modularitatea un cuplaj puternic indic faptul c nu sunt clar specificate responsabilitile fiecrui modul
ntelegerea si testabilitatea logica entitii puternic cuplate este greu de neles, deoarece necesit
nelegerea entitilor de care aceasta depinde
Forme de cuplare:
Clasa A are un atribut care este de tipul B.
Clasa A are o medod care refer o instan de tipul B n orice form (parameterii, variabile locale, valoare
returnat, apel la
metode)
Clasa A ete derivat direct sau indirect din clasa B.

abloane Grasp
High Cohesion
Aloc responsabilitile astfel nct coeziunea n sistem rmne ridicat
Coeziunea este un aspect complementar cuplajului. Ea descrie gradul cu care entitatile unei portiuni de
proiectare contribuie la ndeplinirea unui singur si bine denit scop.
Coeziunea ridicat la nivel de clas indica o strnsa legatur ntre toate elementele respectivei clase.

abloane Grasp
High Cohesion
O proiectare obiectuala buna trebuie sa balanseze echitabil constrangerile de coeziune ridicat si
cele de cuplaj redus.
O coeziune sczut afecteaza n mod negativ diverse proprietati ale sistemului proiectat:
ntelegerea. Clasele mari si complexe sunt greu de nteles n special daca ele sunt si necoezive.
ntreinerea. Datorita greutatilor ntmpinate n ntelegerea codului unei clase aceasta este greu de ntretinut.
Orice modicare adusa unei clase impune ntelegerea ei n totalitate.
Siguranta si testabilitatea. O clasa prea complexa nu numai ca nu este usor de ntretinut si nteles dar este si
greu de testat. Este deci mult mai probabila aparitia unor erori logice ceea ce are drept consecinta o scadere a
sigurantei (reliability) n functionare.

abloane Grasp
Information Expert
Aloc responsabilitatea clasei care are toate informaiile necesare pentru a

ndeplini o anumit sarcin

Information Expert este un principiu care ajut s determinm care

este clasa potrivit care ar trebui s primeasc responsabilitatea (o
metod noua, un cmp, un calcul).

abloane Grasp
Creator
Crearea de obiecte este o activitate important ntr-un sistem orientat obiect. Care este clasa responsabil

cu crearea de obiecte este o proprietate fundamental care definete relaia ntre obiecte de
diferite tipuri.
ablonul Creator descrie modul n care alocm responsabilitatea de a crea obiecte n sistem
n general o clasa B ar trebui s aib responsibilitatea de a crea obiecte de tip A dac una sau mai
multe (de preferat) dintre urmtoarele condiii sunt adevrate:
Instana de tip B conine sau agreg instane de tip A
Instana de tip B gestioneaz instane de tip A
Instana de tip B folosete extensiv instane de tip A
Instana de tip B are informaiile necesare pentru a iniializa instana A.

abloane Grasp
Protected Variations

class ValidatorProdus:

Cum alocm responsabilitatea astfel nct variaiile

curente i viitoare nu vor afecta sistemul (nu va fi
necesar o revizuire a sistemului, nu trebuie sa facem
schimbri majore n sistem)?

Crem o nou clas care ncapsuleaz

aceste variaii.

ablonul

Protected

Variations

protejeaz

elementele sistemului de variaiile/modificrile altor

elemente din sistem (clase, obiecte, subsisteme)

def valideaza(self, produs):

"""
arunca ExceptieValidare
daca atributele produsului nu sunt valide
"""
errMessage = ""
if (produs.code==""):
errMessage+=" "+"Code can not be empty!"
if (produs.nume==""):
errMessage+=" "+ "Name can not be empty!"
if (produs.pret<0):
errMessage+=" "+"Price can not be negative!"
if (produs.cant<0):
errMessage+=" "+"Quantity can not be negative!"
if errMessage!="":
raise ExceptieValidareProdus(errMessage)

Clas ValidatorProdus: aplic Principiu

ncapsulnd partea instabil ntr-o clas separat Protect Variation!!!!!
(cu o interfa public bine delimitat, care ulterior,
folosind polimorfism, poate introduce variaii prin noi
implementri).

abloane Grasp
Pure Fabrication Repository

Operaii CRUD (create,read, update, delete) pentru o entitate

Reducem cuplarea
Coeziunea ridicat
Partea de bussiness logic poate fi testat independent de sursa de date

abloane Grasp
GRASP Controller
Scop: decuplarea sursei de evenimente de obiectul care gestioneaz
evenimentul. Decuplarea startului de prezentare de restul aplicaiei.

Controller este definit ca primul obiect dup stratul de interfa

utilizator. Interfaa utilizator folosete un obiect controller, acest
obiect este responsabil de efectuarea operaiilor cerute de utilizator.
Controller coordoneaz (controleaz) operaiile necesare pentru a
realiza aciunea declanat de utilizator.
Controlerul n general folosete alte obiecte pentru a realiza operaia,
el doar coordoneaz activitatea.

Referine
http://en.wikipedia.org/wiki/Class_diagram#Association
http://en.wikipedia.org/wiki/GRASP_(object-oriented_design)
Craig Larman. Applying UML and Patterns. An Introduction to Object Oriented Analysis and Design
Limbajul Python

http://docs.python.org/3/reference/index.html

Biblioteca standard Python

http://docs.python.org/3/library/index.html

Tutorial Python

http://docs.python.org/3/tutorial/index.html

Kent Beck. Test Driven Development: By Example. Addison-Wesley Longman, 2002

http://en.wikipedia.org/wiki/Test-driven_development

Martin Fowler. Refactoring. Improving the Design of Existing Code. Addison-Wesley, 1999

http://refactoring.com/catalog/index.html