1. Paradigma POO.

Mesaje i responsabiliti

Paradigme de programare este un set de concepte, modele si practici care descriu esenta programarii
Programare structurata (functionala) = un program este conceput pe baza unei secvente de
functii, fara a avea o stare
Programare orientata obiect = programele sunt vazute ca fiind niste colectii de obiecte care
interactioneaza unele cu altele
Mesaje si responsabilitati
Membrii unei comuniti orientat-obiect comunica intre ei .
Urmtorul principiu important explic utilizarea de mesaje pentru a iniia o aciune:
Aciune este iniiat n programarea orientat pe obiecte prin transmiterea unui mesaj de la un agent
(un obiect), responsabil pentru aciunile. Mesajul codific cererea de aciune i este nsoit de orice
informaii suplimentare (argumente / parametri) necesare pentru ndeplinirea cererii.
Receptorul este obiectul la care este trimis mesajul. Dac receptorul accept mesajul, accept
responsabilitatea de a efectua aciunea indicat. Ca rspuns la un mesaj, receptorul va efectua o
metod pentru a satisface cererea
Exist unele probleme important de subliniat aici:
Clientul trimite cererea nu trebuie s cunoasc mijloacele prin care cererea este efectuat. n acest
vom vedea principiul de informare ascunde.
Un alt principiu implicit n mesajul de trecere este ideea de a gsi pe altcineva pentru a face munca
de exemplu reutilizarea componentelor care ar fi putut fi scrise de altcineva.
interpretarea mesajului este determinat de ctre receptor i poate varia n funcie de diferite
receptoare. De exemplu, dac te-a trimis mesajul "flori livrare" la un prieten, ea, probabil, va fi
neles ceea ce a fost necesar i flori s-ar mai fi fost livrate, dar metoda a folosit ar fi fost foarte
diferit de cea utilizat de florar
n programarea orientat pe obiecte, comportamentul este descris n termeni de responsabiliti.
cererile Clientului indic doar rezultatul dorit. Receptoarele sunt liberi s urmreasc orice tehnica
care atinge rezultatele dorite
gndire n acest fel permite o mai mare independen ntre obiecte.
Astfel, obiectele au responsabiliti pe care sunt dispui s-i ndeplineasc, la cerere. Colectarea de
responsabiliti asociate cu un obiect este adesea numit protocol

2. Paradigma POO. Abstracii

Paradigma POO
Concepte:
1.Clasa - implementare a unui TAD
2.Obiect = instanta a unei clase
3.Metoda = implementarea unei operatii din interfata TAD (mesaj = apel al metodei > interactiune intre
obiecte)
Caracteristici:
1.Incapsulare (date + operatii) ascunderea informatiei protectia informatiei consistenta datelor
2.Mostenire reutilizarea codului
3.Polimorfism = capacitatea unei entitati de a reactiona diferit in functie de starea sa.
Programarea orientata pe obiecte este o metoda de implementare in care programele sunt organizate ca
ansamble de obiecte ce coopereaza intre ele, fiecare obiect reprezentand instanta unei clase; fiecare clasa
apartine unei ierarhii de clase in cadrul careia clasele sunt legate prin relatii de mostenire.
Aceasta definitie cuprinde trei parti importante, si anume:
obiectele si nu algoritmii sunt blocurile logice fundamentale;
fiecare obiect este o instanta a unei clase. Clasa este o descriere a unei multimi de obiecte
caracterizate prin structura si comportament similare.
clasele sunt legate intre ele prin relatii de mostenire.
Un limbaj de programare care ofera suport pentru utilizarea claselor si a obiectelor, dar care nu are
implementat mecanismul relatiilor de mostenire intre clase este un limbaj de programare bazat pe obiecte.
1

Programarea bazata pe clase si pe obiecte, care nu face uz de relatia de mostenire se mai

numeste programare cu tipuri de date abstracte.
Important: Trebuie sa intelegem ca prin simpla invatare a unui limbaj care suporta programarea orientata pe
obiecte NU invatam automat sa programam corect conform modelului obiectual! Pentru a invata acest lucru
trebuie sa intelegem si sa aplicam conceptele si mecanismele care stau la baza acestui model. Si tocmai acest
lucru ni-l propunem.
Concluzii
Ideea POO (Programare Orientat Obiectual) este de a crea programele ca o colecie de obiecte, uniti
individuale de cod care interacioneaz unele cu altele, n loc de simple liste de instruciuni sau de apeluri de
proceduri .
Obiectele POO sunt de obicei reprezentri ale obiectelor din viaa real (domeniul problemei), astfel nct
programele realizate prin tehnica POO sunt mai uor de neles, de depanat i de extins dect programele
procedurale. Aceasta este adevrat mai ales n cazul proiectelor software complexe i de dimensiuni mari,
care se gestioneaz fcnd apel la ingineria programrii.
Abstractizarea este una din caile fundamentale prin care noi, oamenii, ajungem sa intelegem si sa
cuprindem complexitatea.
O abstractiune buna este cea care scoate in evidenta toate detaliile semnificative pentru perspectiva din care
este analizat un obiect, suprimand sau estompand toate celelalte caracteristici ale obiectului.
In contextul programarii orientate pe obiecte, Booch ne ofera urmatoarea definitie a abstractiunii [Boo94]:
O abstractiune exprima toate caracteristicile esentiale ale unui obiect, care fac ca acesta sa se distinga de alte
obiecte; abstractiunea ofera o definire precisa a granitelor conceptuale ale obiectului, din perspectiva unui
privitor extern.
In procesul de abstractizare atentia este deci indreptata exclusiv spre aspectul exterior al obiectului, adica
spre comportarea lui, ignorand implementarea acestei comportari. Cu alte cuvinte abstractizarea ne ajuta sa
delimitam ferm "CE face obiectul" de "CUM face obiectul ceea ce face".
Comportarea unui obiect se caracterizeaza printr-o suma de servicii sau resurse pe care el le pune la
dispozitia altor obiecte. Un asemenea comportament, in care un obiect, numit server, ofera servicii altor
obiecte, numite clienti, este descris de asa-numitul model client-server.
Totalitatea serviciilor oferite de un obiect server constituie un contract sau o responsabilitate a
obiectului fata de alte obiecte.
Responsabilitatile sunt indeplinite prin intermediul unor operatii (alte denumiri folosite: metode,
functii membru).
Fiecare operatie a unui obiect se caracterizeaza printr-o semnatura unica, formata din: nume, o lista
de parametri formali si un tip returnat.
Multimea operatiilor unui obiect, impreuna cu regulile lor de apelare constituie protocolul obiectului.
3. Clase i obiecte. Principiile lui Parnas. ncapsularea. Ierarhizarea. Membri statici.
Clase i obiecte
Definitia 1
Clasa, intr-un anumit limbaj de programare, reprezinta definirea unui tip de obiecte abstracte sau
concrete, adica descrierea proprietatilor, a datelor si a metodelor, a prelucrarilor, posibile asupra datelor.
Clasa este, de fapt, o notiune abstracta, care defineste un anumit tip de obiecte, sau, altfel spus, o clasa
reprezinta multimea posibila a mai multor obiecte de acelasi tip.
Definitia 2
In primul rind un obiect reprezinta o entitate ( fizica, conceptuala sau soft).
Definitie formala : Obiect este o instanta a unei clase, care utilizeaza atributele si implimenteaza
metodele acesteia.
Crearea unui obiect presupune specificarea clasei din care face parte, astfel identificandu-se
proprietatile obiectului si modul in care acestea pot fi folosite si prelucrate.
2

Principiile lui Parnas.

Principiile lui Parnas sunt:
1. Declararea (interfata) clasei trebuie sa asigure clientul doar cu informatia necesara pentru utilizarea
eficienta a ei, dar nici o alta informatie in plus.
2. Metodele trebuie sa aiba acces doar la informatia necesara pentru indeplinirea responsabilitatilior lor.
ncapsularea numit i ascunderea de informaii: Asigur faptul c obiectele nu pot schimba starea
intern a altor obiecte n mod direct (ci doar prin metode puse la dispoziie de obiectul respectiv); doar
metodele proprii ale obiectului pot accesa starea acestuia. Fiecare tip de obiect expune o interfa pentru
celelalte obiecte care specific modul cum acele obiecte pot interaciona cu el. Incapsularea serveste la
separarea interfetei de implementarea acesteia.
Avantaje:
Ofera independenta implimentarii de interfata.
Previne coruperea datelor interne.
Permite mai multor echipe un lucru independent asupra modulelor.
Documentarea buna permite o buna mentenata, dar si o depanare buna.
Ierarhizarea
Adesea un grup de abstractiuni formeaza o ierarhie, iar prin identificarea acestor ierarhii, putem simplifica
substantial intelegerea problemei.
Ierarhizarea reprezinta o ordonare a abstractiunilor.
Cele mai importante ierarhii in paradigma obiectuala sunt:
Ierarhia de clase (relatie de tip "is a")
Ierarhia de obiecte (relatie de tip "part of")
Mostenirea (ierarhia de clase)
Mostenirea defineste o relatie intre clase in care o clasa impartaseste structura si comportarea
definita in una sau mai multe clase (dupa caz vorbim de mostenire simpla sau multipla). Asa
cum aminteam mai sus, relatia de mostenire este cea care face diferenta intre programarea
orientata pe obiecte si cea bazata pe obiecte.
Semantic, mostenirea indica o relatie de tip "is a" ("este un/o"). De exemplu un urs "este un"
mamifer si deci intre clasa ursilor si cea a mamiferelor exista o relatie de mostenire. Si in
cazul programarii acesta este cel mai bun test pentru a detecta o relatie de mostenire intre
doua clase A si B: A mosteneste pe B daca si numai daca putem spune ca "A este un fel de
B". Daca A "nu este un" B atunci A nu ar trebui sa mosteneasca pe B.
Prin urmare, mostenirea implica o ierarhie de tip generalizare/specializare, in care clasa
derivata specializeaza structura si comportamentul mai general al clasei din care a fost
derivata.

Agregarea (ierarhia de obiecte)

Agregarea este relatia intre doua obiecte in care unul dintre obiecte apartine celuilalt obiect. Agregarea reda
apartenta unui obiect la un alt obiect. Semantic, agregarea indica o relatie de tip "part of" ("parte din"). De exemplu
intre o roata si un automobil exista o astfel de relatie, intrucat putem spune ca "o roata este o parte din automobil".
Membri statici.
Membrii statici exista in exemplare unice pentru fiecare clasa, find accesati in comun de toate instantele clasei
repective.

Se recomanda ca referire unui membru static sa se faca prin intermediul numelui clasei si nu prin
intermediul numelui obiect.
Declararea unui membru static presupune precedarea acestuia de cuvantul cheie static:
static tip_membru nume_membru_static;
iar referirea unui membru static se face astfel:
nume_clasa::nume_membru_static;
unde, nume_membru_static poate fi o data sau o functie membru static.
Membri static pot fii referiti fara a instantia clasa, ei nedepinzind de obiecte.
3

4. Ierarhii de clase i de obiecte. Modele de relaii. Accesibilitatea membrilor in C++ i Java.

Ierarhizarea:
ierarhii de clase(mostenirea) mostenirea implica o ierarhie de tip generalizare sau specializare.
ierarhii de obiecte(agregare) relatie dintre doua obiecte in care unul dintre obiecte apartine celuilalt
obiect.
Modele de relatii:
clasa are un caracter dual:
ierarhie conceptuala
ieragie de implementare
obiectul corespunde unui tip:

is-a
has-a
uses-a

Exemplu de relatii de obiecte:

Accesibilitatea membrilor in C++.
Specificatorii de acces definete drepturile de acces pentru atribute sau metode pe care-l urmeaz pn la
definirea unui alt specificator de acces sau pn la sfritul unei clase. Cele trei tipuri de specificatori de
acces sunt "private", "public", "protected".
private:
Membrii declarati ca "private", pot fi accesate numai n cadrul aceleiai clase, i nu din afara clasei.
publica:
Membrii declarat ca "public" sunt accesibile n cadrul clasei, ct i din afara ei.
protected:
Membrii declarat ca "protected" nu pot fi accesate din afara clasei, dar pot fi accesate de la o clasa
mostenita. Aceasta este utilizat atunci cnd este aplicat mostenirea membrilor unei clase.

Accesibilitatea membrilor in java.

In java sunt utilizate aceeasi specificatori ca si in C++ insa apare inca un specificator - package-private(no
modifier).
package-private(no modifier) daca un atribut utilizeaza acest specificator atunci el este public pentru tot
pachetul insa private pentru accesarea innafara pachetului.
5. Ierarhii de clase i de obiecte. Funcii virtuale. Motenire multipl. Blocarea motenirii.
4

Ierarhii de clase si obiecte

Despre aceasta intreabare a vorbit si Max Gribincea mai sus, eu vreau sa adaug doar doua propozitii
despre care el probabil a vorbit, sau poate nu, insa acestea clarifica totul. (c stati, sper c in timpul
examenului propozitia asta sa no copietz :D).
Ierarhiile de clase reprezinta o multime de clase legate prin mostenire unde o clasa se caracterizeaza prin
este o. Adica clasa B este un fel de Clasa A (B mostenind de la A).
Ierarhiile de obiecte reprezinta o multime de obiecte legate prin compozitie si agregare, la nivel de clase
caracterizate prin contine un. Adica clasa B contine un obiect de clasa A.
Functii virtuale
n programarea orientat pe obiecte (POO), o funcie virtual sau metod virtual este o funcie al crei
comportament, n virtutea declarrii acesteia ca fiind "virtual", este determinat de ctre definiia unei funcii
cu aceeai semntur cea mai ndeprtat pe linia succesoral a obiectului n care este apelat. Acest concept
este o foarte important parte din poriunea de polimorfism a paradigmei de programare pe obiecte (POO).
Exemplu functii virtuale C++:
class Animal
{
public:
virtual void eat() { cout << "Eu mnnc aa cum o poate face orice Animal.\n"; }
};
class Wolf : public Animal
{
public:
void eat() { cout << "Eu nfulec ca un lup!\n"; }
};
class Fish : public Animal
{
public:
void eat() { cout << "Eu m hrnesc ca un pete!\n"; }
};
class OtherAnimal : public Animal
{
};
int main()
{
Animal *anAnimal[4];
anAnimal[0] = new Animal();
anAnimal[1] = new Wolf();
anAnimal[2] = new Fish();
anAnimal[3] = new OtherAnimal();
for(int i = 0; i < 4; i++)
anAnimal[i]->eat(); }
Rezultatul C++:
Eu mnnc aa cum o poate face orice Animal.
Eu nfulec ca un lup!
Eu m hrnesc ca un pete!
Eu mnnc aa cum o poate face orice Animal.
Exemplu functii viruale C#:
5

class A
{
public void F() { Console.WriteLine("A.F"); }
public virtual void G() { Console.WriteLine("A.G"); }
}
class B: A
{
new public void F() { Console.WriteLine("B.F"); }
public override void G() { Console.WriteLine("B.G"); }
}
class Test
{
static void Main() {
B b = new B();
A a = b;
a.F();
b.F();
a.G();
b.G();
}
}
Rezultate C#:
A.F
B.F
B.G
B.G
Java functii virtuale:
In Java toate metodele non-statice sunt implicit virtuale. Doar cele cu cuvintul cheie final, si cele private nu
sunt virtuale.
Exemplu functii virt Java: (acesta merge si la polimorfism ca si cele C++ si C# de mai sus)
class Vehicle{
public void move(){
System.out.println(Vehicles can move!!);
}
}
class MotorBike extends Vehicle{
public void move(){
System.out.println(MotorBike can move and accelerate too!!);
}
}
class Test{
public static void main(String[] args){
Vehicle vh=new MotorBike();
vh.move(); // prints MotorBike can move and accelerate too!!
vh=new Vehicle();
vh.move(); // prints Vehicles can move!!
}
}
Mostenirea multipla
6

Mostenirea multipla este mecanismul prin care o clas preia structura (datele membru) i comportamentul
(metodele) a doua sau mai multe clase la care adaug elemente specifice.
Motenire multipl - clasa derivat preia caracteristicile i metodele de la mai multe clase de baz.
Mostenirea multipla este prezenta in limbajul C++ si nu este implementata in C# sau Java (cu toate ca
exista metode de utilizare a interfetelor pentru a realiza ceva de genul mostenirii multiple).
Exemplu mostenire multipla C++:
class Imprimanta{
protected:
int rezolutie;
public:
Imprimanta(int rezolutie=600){ this->rezolutie = rezolutie; cout<<"Apel Constr.
Imprimanta\n";
}
~Imprimanta(){
cout<<"Apel Destr.
Imprimanta\n";
}
void print(char *text){
cout<<"Print "<<text<<"\n";
}
};
class Scaner{
protected:
int rezolutie;
public:
Scaner(int rezolutie=1200){
this->rezolutie = rezolutie; cout<<"Apel Constr. Scaner\n";
}
~Scaner(){
cout<<"Apel Destr. Scaner\n";
}
void scan(){
cout<<"Scanez\n";
} };
class MultiFunctionala: public Imprimanta, public Scaner{
public:
MultiFunctionala(int rezI, int rezS): Imprimanta(rezI), Scaner(rezS)
cout<<"Apel Constr. MultiFunctionala\n";
}
~MultiFunctionala(){
cout<<"Apel Destr. MultiFunctionala\n";
} };
void main(){
MultiFunctionala m(300,600);
m.print("hello");
m.scan();
}

Rezultatul programului de mai sus:

Apel Constr. Imprimanta
Apel Constr. Scaner
Apel Constr. MultiFunctionala
Print hello
Scanez
Apel Destr. MultiFunctionala Apel
Destr. Scaner
Apel Destr. Imprimanta
Blocarea mostenirii
7

Exista posibilitatea de a bloca extinderea unei clase, sa nu mai transfere proprietatile si metodele ei vreunei
sub-clase legata de ea. Pentru aceasta se adauga termenul final inaintea cuvantului class
Exemplu blocarea mostenirii C++:
class MakeFinal
{
private:
~MakeFinal() { };
friend class FinalClass;
};
class FinalClass : virtual public MakeFinal // <-- virtual is the key
{
public:
FinalClass() { cout << "FinalClass::ctor" << endl;}
~FinalClass() { cout << "FinalClass::dtor" << endl;}
};
class NotPossible : public FinalClass
{
public:
NotPossible() { cout << "NotPossible::ctor" << endl;}
~NotPossible() { cout << "NotPossible::~ctor" << endl;}
};
Exemplu blocarea mostenirii C#:
sealed class SealedClass
{
public int x;
public int y;
}
//class MyDerivedC: SealedClass {} // Error
class SealedTest2
{
static void Main()
{
SealedClass sc = new SealedClass();
sc.x = 110;
sc.y = 150;
Console.WriteLine("x = {0}, y = {1}",
sc.x, sc.y);
}
}
// Output: x = 110, y = 150

Exemplu blocarea mostenirii Java:

class Point
{
int x, y;
}
class ColoredPoint extends Point
{
int color;
}
// Colored3dPoint class cannot be extended
further
// clasa Colored3dpoint nu poate fi mostenita
final class Colored3dPoint extends ColoredPoint
{
int z;
}

6. Polimorfism
8

Polimorfismul este exemplul cel mai practic al reutilizrii, el fiind prin definiie capacitatea unei
entiti de a lua mai multe forme.
Funciile se difereniaz prin:

numele funciei;

lista de parametri;

valoarea returnat,
aceste forme de difereniere putnd exista fie simultan, fie separat.
Polimorfismul este universal sau ad-hoc.
Polimorfismul universal la rndul su se mparte n polimorfism parametric i polimorfism incluziune.
Polimorfismul parametric presupune c diferena ntre funcii se realizeaz prin lista de parametri
i/sau valoarea returnat, funciile avnd acelai nume. El se refer la posibilitatea utilizrii unei singure
funcii (cod, nume, funcionalitate) asupra unui set de tipuri, dac un argument al semnturii sale determin
tipul corespunztor fiecrui apel al funciei.
Polimorfismul incluziune presupune manipularea obiectelor de un anumit tip n situaii n care se cer
tipuri diferite de tipul obiectelor. Astfel obiectele de tip ClasaDerivata pot fi utilizate n orice situaie care
necesit prezena unor obiecte de tipul ClasaDeBaza, unde ClasaDeBaza este o superclas a
clasei ClasaDerivata. Polimorfismul incluziune permite unei funcii s opereze asupra unui set de tipuri
determinate de relaii de subtip (ierarhii de clase). Implementarea unei asemenea forme de polimorfism
permite folosirea unor tehnici care s trateze un obiect ca instan a mai multor clase n acelai timp (ntre
care exist relaii de superclasa-subclas). n acest fel organizarea i prelucrarea coleciilor de obiecte
eterogene se face ntr-o manier flexibil i elegant.
Polimorfismul ad-hoc la rndul su se mparte n polimorfism coerciziune i polimorfism
suprancrcare.
Polimorfismul coerciziune este caracteristic limbajelor de programare care dispun de faciliti de
conversie intern ntre tipuri.
Polimorfismul suprancrcare se obine prin suprancrcarea funciilor i mascarea lor n cadrul unei
ierarhii de clase. Atfel, operaiile polimorfice sunt operaii cu acelai nume dar cu implementri diferite. De
exemplu, de-a lungul unei ierarhii de clase, o operaie definit ntr-o superclas poate fi redefinit ntr-o
subclas. Astfel ea este polimorfic, decizia de selecie a funciei active lundu-se n funcie de parametri de
apel.
Specifice limbajului C++ sunt polimorfismul ad-hoc i polimorfismul de incluziune, acesta din urm
realizndu-se prin intermediul funciilor virtuale i a legrii dinamice.
Avantajele sistemelor polimorfice sunt partajabilitatea comportrii, posibilitatea de definire a
operaiilor abstracte asociate tipurilor, flexibilitate.

Polimorfismul suprancrcare
void display() const{
cout<<"no arguments";
}
void display(int a) const{
cout<<"display("<<a<<")";
}
int main()
{ display();
display(10);
return 0; }
Polimorfismul coerciziune
void display( int a) const{
cout<<"display("<<a<<")";
}
int main()
{ display(10);
display(12,6);
display('\n');
return 0;
}
Polimorfismul incluziune
using namespace std;
class A
{
public:
virtual void say()
{
cout<<"silence...";
}
virtual ~A();
};
class B:public A
{
public:
virtual ~B();
virtual void say()
{
cout<<"B say....";
}
};
class C:public A
{
public:
virtual ~C();
virtual void say()
{
cout<<"C say ....";
}
};
void main()
{

A*arrayofas[2];
arrayofas[0]=new B();
arrayofas[1]= new C();
for( int i=0;i<1;++i)
{
arrayofas[i]->say();
}
}
Polimorfismul parametric C++
template<class T,int lenght>
class typeblock
{
public:
typeblock()
{
p=new T[lenght];
}
~typeblock()
{
delete[] p;
}
operator T*()
{
return p;
}
protected:
T*p;
};
main
{
typeblock <char ,256> char block;
typeblock<int ,1024> int block;
}
Java
public class entry<K,V>
{
private final K key;
private final V value;
public entry (K k,V v)
{
key=k;
value=v;
}
public k getkey()
{
return key;
}
public v getvalue()
{
return value;}
public stringtostring()
{
return "("+ key+...")";
10

Determinarea i Analiza Cerinelor.

nainte de a proiecta arhitectura unui sistem software este important s se obin o imagine clar asupra
cerinelor care influeneaz arhitectura. De obicei aceste cerine sunt cerine non-funcionale care se refer la
calitatea sistemului software.
Procesul de identificare a cerinelor care afecteaz arhitectura are dou tipuri de intrri: pe de o parte
arhitectul trebuie s analizeze cerinele funcionale, iar pe de alt parte el trebuie s in cont i de cerinele
venite din partea celor care vor interaciona cu aplicaia. n urma analizei efectuate asupra celor dou tipuri
de cerine rezult cerinele care influeneaz arhitectura sistemului software. Procesul de analiz a cerinelor
n vederea izolrii cerinelor care influeneaz arhitectura este ilustrat in Fig. 11.2.

Unele cerine vor aciona ca i constrngeri ele limitnd opiunile arhitectului. n Tabela 11.1 sunt prezentate
exemple de cerine care influeneaz arhitectura, iar n Tabela 11.2 sunt prezentate exemple de cerine care
impun constrngeri.

Un alt aspect care trebuie avut n vedere vis-a-vis de cerinele care influeneaz arhitectura unui sistem
software, este faptul c aceste cerine nu sunt egale, unele fiind mai importante dect altele. De aceea este
necesar o prioritizare a acestor cerine. De obicei se folosesc trei niveluri de prioritizare:
- Ridicat sistemul software trebuie s implementeze cerinele cu aceast prioritate. Aceste cerine au un
cuvnt greu de spus n ceea ce privete arhitectura.
- Medie cerinele cu aceast prioritate vor trebuii implementate la un moment dat, dar nu sunt absolut
necesare pentru prima versiune.
- Sczut funcionaliti dorite, dar care se pot implementa n msura posibilitilor.
Prioritizarea cerinelor se complic atunci cnd apar conflicte ntre cerine, de ex.: timp scurt pn la
scoaterea pe pia a produsului vs. dezvoltarea de componente generice i reutilizabile. De cele mai multe
ori rezolvarea acestor conflicte nu este uoar, dar este sarcina arhitectului s le rezolve.
11

Etapa de Proiectare. Arhitecturi.

Reprezint cea mai important aciune ntreprins de ctre arhitect. Un document de cerine foarte bine
structurate, respectiv o comunicare bun cu restul echipelor implicate n proiect nu nsemn nimic dac se
proiecteaz o arhitectur slab. Etapa de proiectare a arhitecturii are ca i intrri cerinele obinute n etapa
anterioar iar ca rezultat se obine un document care descrie arhitectura sistemului software. Proiectarea
arhitecturii se realizeaz n doi pai: primul pas se refer la alegerea unei strategii globale, iar al doilea
const din specificarea componentelor individuale i a rolului pe care fiecare component l joac n
arhitectura global.
Validarea Arhitecturii
Scopul etapei de validare este acela de a verifica faptul c arhitectura proiectat este potrivit pentru
sistemul software care urmeaz s fie dezvoltat. Principala dificultate n ceea ce privete validarea unei
arhitecturi const n faptul c n acest moment nu exist un produs software fizic care s poat fi executat
i testat. Exist dou metode prin care se poate valida arhitectura unui sistem software: testarea manual
utiliznd scenarii, respectiv validare prin construirea unui prototip.
Utilizarea Scenariilor
Utilizarea scenariilor pentru validarea arhitecturii unui sistem software presupune definirea unor stimuli care
s aib efect asupra arhitecturii. Dup care se face o analiz pentru a se determina care va fi rspunsul
arhitecturii la un astfel de scenariu. Dac rspunsul este cel dorit atunci se consider c scenariul este
satisfcut de arhitectur. Dac rspunsul nu este cel dorit sau este greu de calificat atunci s-a descoperit o
zon de risc n arhitectur. Se pot imagina scenarii care s evalueze oricare din cerinele sistemului.
Crearea Unui Prototip
Dei scenariile sunt tehnici foarte utile n vederea testrii unei arhitecturi, nu ntotdeauna verificarea unui
scenariu se poate face doar prin analiza arhitecturii, de aceea n anumite situaii se recurge la construirea
unui prototip care s permit verificarea anumitor scenarii. Un prototip se poate construi din dou motive:
- Proof-of-concept: verific dac se poate implementa arhitectura proiectat astfel nct s satisfac
cerinele.
- Proof-of-technology: verific faptul c tehnologia middleware selectat se comport aa cum se ateapt.
Odat ce prototipul a fost implementat i testat rspunsul arhitecturii la stimulii prevzui n scenarii se poate
obine cu un nalt grad de certitudine.
Dei un prototip poate fi foarte util n ceea ce privete validarea unei arhitecturi, trebuie avut grij ca
dezvoltarea unui astfel de prototip s nu dureze prea mult. De obicei un prototip este abandonat dup ce
arhitectura a fost validat, de aceea dezvoltarea unui prototip nu trebuie s dureze mai mult de cteva zile,
cel mult 1-2 sptmni.

12

1
2
3
4
5
1
2
3
4
5
6
7
1
2
3
4
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

public class Main {

private EventsHandler evHandler;
private Monitor monitor;
private CommandsHandler cmdHandler;
}
public class CommandsHandler {
private Monitor mon;
public void configureParameter () {
}
public short[] getParams (byte[] types) {
return null;
}
}
public class EventsHandler {
public void send (Report r) {
}
}
public class Monitor {
private byte[] monitoredTypes;
private short measuringPeriod;
private Timer timers;
private Parameter params;
private MeasuringTool tool;
private MeasuringAPI api;
private boolean toolOrAPI;
public Monitor () {
}
public void run () {
}
public void addParam () {
}
public short getValue (byte type) {
return 0;
13

17
}
18 }
1 public class Parameter {
private short value;
2
private short aboveThr;
3
private short belowThr;
4
private byte type;
5
private Report rep;
6
private EventsHandler reportHandler;
7
public Parameter () { }
8
public void setAboveThr (short val) { }
9
public void setBelowThr (short val) {
}
10
public
void
setValue
(short
val)
{
}
11
public void periodicReport () {
}
12
public void checkThresholds () {
}
13
public
byte
getType
()
{
14
return 0;
}
15
public
short
getValue
() {
16
return 0;
17
}
}
18
1
2
3
4
5
1
2
3
4
5
1
2
3
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
1
2
3
4

public class MeasuringAPI extends Measuring {

public short[] measure (byte[] types) {
return null;
}
}
public class MeasuringTool extends Measuring {
public short[] measure (byte[] types) {
return null;
}
}
public class Measuring {
public Measuring () {
} }
public class Report {
private byte type;
private byte reason;
private short value;
public Report () {
}
public byte getReason () {
return 0;
}
public byte getType () {
return 0;
}
public short getValue () {
return 0;
}
}
public class Timer {
private short interval;
private Parameter param;
public Timer () {
}
14

5
6 }

public void run () {

15