Analiza este un proces de cercetare i n spe de decompoziie

probleme n probleme mai mici.

aunei

Rezolvm acele probleme mici i facem sinteza pentru a identifica soluia .

Proiectarea este un proces de stabilire a structurii unui proiect software.
Programarea este scrierea codului compilat sau interpretat i obinerea unei
aplicaii n urma acestui proces.
Site-uri: www.coursera.org uml-diagrams.org objectmentor.com
Booch, 1994 . Programarea orientate pe obiecte este o metoda de implementare in
care programele sunt organizate ca un ansamblu de obiecte ce coopereaza intre
ele.
La baza programarii orientate pe obiecte, avem obiecte i nu proceduri sau
sarcini. Obiectele sunt entiti care au comportament, metode , conin informaie
( atribute ) i care pot interaciona ntre ele. Dependen, asocieri.
Obiectele pot fi lucruri tangibile
Roluri Sitem de operare 2 roluri( admin si user)
Uniti organizaionale - Departament , seciune , lucru n grup
Dispozitive - sensor , timer , printer
Evenimente Logoff, contract,payment
Locaii desktop, coal
Paradigm- un set de presupuneri, concepte, valori i practici care constituie un
mod de a privi realitatea pentru o comunitate care le mrtete .
Principiul de delegare, presupune c un obiect poate pune responsabilitatea
implementrii unei sarcini pe un alt obiect.
Un set de principii: S O L I D Single responsability principle , Open close
principle ( la modificari) , Liskov substitution(orice clasa fiu nlocuiete parinte trebuie-), Interface segregation principle, Dependency inversion principle.
Mesaje i responsabiliti. Mebrii comunic prin transmiterea de cereri ntre ei.
Aciunea este iniiat ntr-un obiect prin transmiterea unui mesaj ctre un agent
( un obiect) responsabil pentru aciune. Mesajul codific cererea de aciune i este
acompaniat de informaia adugtoare ( argumeni paramentri) necesar pentru a
realiza sau ndeplini cererea. Receptorul este obiectul care primete mesajul. Dac
receporul accept mesajul, atunci el accept responsabilitatea de a realiza
aciunea indicat. Ca i rspuns la mesaj receptorul va ndeplini o metod care va
satisface cererea.
ablon de proiectare Lan de responsabiliti
ABSTRACII
Principiile fundamentale ale abordarii OO, Allen Key (1993)

-Totul este obiect

-Obiectele interacionaz prin transmiterea i primirea mesajelor
-Fiecare obiect i are memoria proprie
-Fiecare obiect aparine unui grup de obiecte clas
-Clasa definete compornamentul comun tuturor obiectelor exemplarelor sale
-Clasele se organizeaz ntr-o structur arborescent cu o rdcin comun,
asigurnd transferal de comportament de la clasele superioare claselor inferrioare
din ierarhia de motire.
MODULARIZAREA
-Scopul descompunerii n module este reducerea costurilor prin posibilitatea de a
proiecta i revizui modulele n mod independent
-Modularizarea const n divizarea programului ntr-un numr de subuniti care pot
fi compilate separate, dar care sunt cuplate ntre ele
-gradul de cuplaj ntre module trebuie s fie mic
-clasele care compun un modul trebuie s aib legturi

Principii (low capling i high coheasion) . ntre module trebuie s aflm interfee ct
mai puine.

Dezavantajele programrii OO
Documentarea este un process mai dificil, dect n cazul programrii procedurale.
n structure cu multe nivele de ierarhizare, uneori este foarte greu de urmrit de la
care clas vine o proprietate.
Avantaje programrii OO
Mijloc de tartare a complextii atins prin abstractizare
Scalabilitate
Procesarea structurilor eterogene
Schimbarea comportamenului n momentul execuiei
Reutilizare
Polimorfism structuri care se comport diferit fr schimbarea unor elem.
Abstracie- abstractizarea este procesul de suprimare voluntar a anumitor detalii a
unui proces sau artefact pentru a aduce n eviden aspectele, detaliile sau structuri
accentuate.

MECANISM Abstractizare:
Modulul, e o soluie la conflictele de nume i reprezint colecii de clase, care
sunt interdependente. Modulul ofer 2 spaii de nume- spaiul public, care e
accesibil n afara modului numit i interfa. Spaiul 2 spaiul privat
disponibil doar n interiorul modulului.
TIPURI DE DATE ABSTRACTE
Programatorii trebuie s aib posibilitatea de a definini noi tipuri de date. Aceasta
include i posibilitate de a oferi clienilor acestui tip de date . E foarte important ca
aceti clieni s aib informaia despre responsabilitile, operaiile oferite, dar nu i
modul de implementare a lor.
Orientarea pe servicii
Orientarea pe obiecte ne permite definirea serviicilor tipurilor abstracte de date i
ofer clienilor clasei, servicii i nu date.
Mesaje, motenire i polimorfism- pe lng abordarea orientrii pe sericii
orientarea pe obiecte adaug nc cteva idei noi la tipul de date abstract n spea
transmiterii de mesaje i polimorfism . E foarte important de a gsi nivelul drept de
abstractizare la etapa iniial a proiectului.

Clase i obiecte
Method
Class example2{
Public:
Int I;
Int addi(int j ){
I=i+j;
Return I;
}
}

Parafrazarea principiile lui Parnas

-Declararea clasei trebuie s asigure clientul doar cu informaia necesar pentru
utilizarea eficient a ei.
-Metodele trebuie s aib acces doar la informaia necesar pentru ndeplinirea
responsabilitii lor.
Daniel Keller

-S aleg nume ce pot fi pronunate n voce

-Cuvintele se ncep cu masuscule n nume complexe
-Atenie la utilizarea prescturtrilor
-Atenie la nume multisemantice
-Nu se recomanda utilizarea numerelor

ncapsularea
Ofer independen implementrii de interfa
Previne coruperea datelor interne
Permite mai multor echipe un lucru independent asupra modulelor
Documentarea bun permite obun mentenan, dar i depanare dificil.

Ierarhizarea
Ordonarea/gruparea abstraciilor obinute...
Ierarhii de clas, motenirea
-motenirea implic o ierarhie de tip generalizare sau specializare ( este o )
Ierarhia de obiecte, agergare
Relaia ntre dou obiecte n care unul dintre obiecte aparine celuilalt obiect
Agreagarea partoff
( un obiect conine prin referin sau valoare
(compozi) obine alte obiecte )

Piciorul este scaun?NU- compoziie

Masa este mobil?Da- motenire

Intefaa unei clase e un set de metode publice a unei clase . Atributele

trebuie s fie private pentru securitate. Metodele care nu trebuie s fie
accesibile din afar trebuie s fie private sau protected. Toate atributele
private.

Convenii de nume n JAVA

-Prima liter cu majuscul pentru denumiri de clase

Public class MyClass{}

-Prima liter cu minscul
myField, myVar, myMethod
-Denumirile nu sunt separate prin simblul _
-Cuvintele intermediare se ncep cu majusc.
drawLine ()
-Nume de constant toate cu masjucula, iar cuvintele se separa prin _
NUME_Constanta

Referina unui obiect initial este null. Null e o valoare special i nu

trebuie echivalat cu zero sau nimic.
Pentru a crea un obiect, trebuie s folosim operatorul NEW
MyClass myObject //un obiect cu val null// = new Class()
Dac nu exist constructor atunci compil singur creeaz implicit unul fr valori.
Dac ai scris un constructor cu macar 1 par. Atunci trebuie s avem grij s i se
atribuie toate valorile.
Cnd trebuie s ntoarcem un obiect

this.value

Trebuie s artm care e atrbut i care parametru!!!

Dac dorim apela o metod la fel ca i sus.

Cnd se folosete simbolul this????

1.Cnd ar putea exista conflicte de nume cu datele membru ale unui obiect
(attribute)
2.Cnd o metod trebuie s returneze ca rezultat o referin la obiectul ei receptor.
3.Referina la obiectul receptor trebuie transmis ca argument la apelul altei metoe

Membri statici a claselor

Membri statici exist n exemeplare unice pentru fiecare clas , fiind accesate n
comun de toate instanele clasei respective. Se recomand ca referirea unui
membru statis s se fac ptrin intermediul numelui obiectului! Membrii statici pot fi
referii fr a instania clasa, ei nu depind de obiecte.

Pentru a defini un membru static se utilizeaz cuvntul cheie static, plasat dup
modificatorul de acces:
modificatorAcces static tipMembru numeMembru;
Intr-o metod static NU este permisa referira simpl a unui membru non-static.
n orientarea pe obiecte nu exist var globale. Avem nevoie de mecanins care ar
emula acest concept.
ntr-o metoda static Nu este permisa referirea simpl a unui membru non-static.
Apelnd o anumit metod cu valorile acestui obiect o s fie ok. Dac apeleaz
metoda static tot e ok, deoarece atrbiutele statice se partajeaz. Dac apelm
metoda static this nestatice. n metod static nu poi apela nonstatic.
~X =100 va fi de 2 ori
La apelarea constructorilor, se apeleaz n primul rnd constructorii
atributelor, iar apoi construct. Clasei. La distrugerea obiectului se apelaz
la nceput destructorul clasei iar apoi obiectelor atrbut.
De 8 ori x y x y ~x ~y ~x ~y
Organizarea claselor.
1.Gruparea claselor dup funcionalitate
-uurina n cutare
-evitarea conflictelor de nume (adugarea claselor nu doar n modul )
-controlul accesului ( Grupuri accesibile private sau publice n dependen)
2.Java
-package
3.C++ C#
-Namespace

Ierarhii de clase i obiecte

Modele de relaii . Clasa are un caractel dual.
-Ierarhie conceptual
-Ierarhie de implementare
Obiectul corespunde unui tip.
-IS-a

Motenire

-Has-a

Agregare( cnd avem pointeri adresa la obiectul cela)

-Uses-a (dependen n uml) Clasa a folosete o list

Compoziia- lomonosov n Chiinu .

Motenirea n C++ . Accesibilitatea membrilor!!!

MOtenirea n JAVA!!!
//vezi mob
Super(4) constructor baza
Ordinea exec. Constructor destructor la motenire
Derived*dref = new Derived();
delete dref;
//vezi mob
La c++ rezultat base.foo

Java Derived.foo va fi

Exista 2 tipuri obiecte : declarate si instantiate.

Funcii virtuale, dac era n C++ virtual mergea cum trebuie, dar dac nu e virtual
atunci nu se ia de la tipul instaniat (new Derived) dar de la tipul de baz declarant
(base*b).

Funcia virtual e funcia care implic : 1. Redefinirea comportamentului n calsa

derivat de o funcie cu aceeai signature. 2. Funcia implic rezoluia dinamic a
comportamentului n dependen de obiect i nu de tipul referinei spre acest
obiect. Tipul referinei corespunde obiectului.

3.Implic generarea unui table al funciilor v-table , care pstreaz pointeri spre
funciile fiecrui oibect derivat:
Acest lucru nu-l vedem. Ele fac LEGAREA trzie . Implic costuri performan .
//vezi mob
Base*ref = new Derived();
Cu vritual nu trebuie sa scriu de dou ori acelai cod.
Obj.add 4 de ex. Daca e un tip f bucata asta else f altceva . Compilatorul la
obj.add nu va ti care metod va li apelat.

Daca e virtuala va prelua de la clasa instantiata!!!!!!!!

Daca nu e virtuala e de la cea parinte!!!!!!!!!!!!!!!!!!!!!!!
Functia virtuala foloseste rezolutia obiectului. Cind avem creat dinamic
putem schimba comportamentu. Va afisa 2 si se va apela dinamic.
ablonul strategy se folosete pentru a schimba comportamentul unui
obiect n mod dinamic ( de regul pentru specificare algoritmilor n timp
real )
O clas abstract e clasa care are mcar 1 funcie pur virtual . Funcia
pur virtual nu are implementare i nu are corp (){} Iar din ele nu poti
instantia obiecte . Se folosesc pentru a define un set de functii .
Implements in java toate metodele sunt implementate . Motenirea
multipl nu e n java.

Aceeasi clasa in 2 interfeti diferite in c++ mostenire multipla!!!

n java e un pic altfel cu ajutorul implements!!! 1 clas implementeaza 2
interfee!!!

Func Virtuale dinamic obiectul carei clase folosim pentru utilizare .

MOTENIREA MULTIPL N C++
n Java sunt folosite interfeele pentru a defini :
-Contracte ( API-uri)
-Tipuri ( ca alternativa pentru mostenirea multipl )
Spre deosibire de clasa abstract, interfaa nu poate conine corp pentru metodele
declarate. Interfaa se ncepe cu I mare , dup care merge cuvntul entitii sau
logice celei ce trebuie s o implementm . Pentru motenire n Java folosim
extends!!!!! Relaia de implementare realise .

Interfata Ioperation

<| - - - - -

Clasa Operation

Blocarea motenirei
Exist cazuri cnd o clas nu dorim s fie motenit . Pentru java e definit final .
Dac punem acest lucru, clasa nu mai poate fi extins . Dac punem la metode nu
poate fi suprascrise iar la atrbiute nu mai pot fi suprascrise

DETERMINAREA I ANALIZA CERINELOR

..

Definiii.
Cerine funcionale i nefuncionale .
Cerine non-funcionale performan , culori , mrimi.

Abordri sunt cteva: avem trei tipuri pentru care scrim cerine
-As-IS sisteme existente aa cum sun la moment. Pentru ele se creeaz cerine
pentru sistemul care trebuie s fie computerizat.
-To-be sisteme sunt sisteme de perspective care sunt bazate pe cerinele de
updatare sau cele create
-System Proposal propunerea de sistem care trebuie s fie rezultatul livrat la faza
de analiz.

Crein :
-o caracterisitc a sistemului
-un statement care trebuie s fie realizat
-cerinele se pot modifica

Funcional requirement
-

Se includ funcionalitile pentru user sau procese pe care sistemul trebuie s

realizeze

Nonfunctional requirement
-

Prorprietile pe care sistemul trebuie s le aib

Operaionale
Performane
Securiti
Social and political

Surse de cerine Sources of Requirements

-

Clieni
Parteneri
Adminsistratori
Analiti industriali
Domain experts

Informatia competitor

Tehnici de colectare a cerinelor

Caracteristici pentru coletare:
Impertinen
Imparialitate
Relaxarea constrngerilor
Atenie la detalii
Reframing(noi posibiliti ) repoziionarea problemei
Tehnici
-

Interviul: -ntrebri cu sfrit nchis i deschis ( s spui ceva 1 2 3 poze galarii)

Chestionare: -atenie la desin i pot conine close-end i open-end ntrebri
Alte metode de colectare a cerinelor ( observarea lucrtorilor
Analiza documentelor business

Joint application design

Prototipizarea

Interviuri
-

Opinii i date concrete fapte. Seculaii

Observ limbajul corpului i emoiile
(Trebuie s avei un check-list)
S fii neutru i partial . S poi asculta
Mai multe puncta de vedere

Cum sunt selectaii cei care intervieveaz intervievatori

Tipuri de utilizatori , managerii, participani proiect.
ine n minte politica organizaional

Designing interview questions

Tipuri de ntrebri
-

Closed-Ended questions
How do customers place orders?
Open-Ended questions
What are some problems you face on daily basis
Probing Questions
Why?

Can you give me an example?

Can you explain in more details

Interviews steps
Organizing Interview Questions
-Unstructured interview useful early in information gathering
-Structured interview useful later in process

Pas cu pas interviu

nregistrai toat informaia
Fii sigur c nelegi toate problemele i termenii
Separai prerile de facts
Acord timp pentru ntrebri
F un rezumat

Chestionare- un se de ntrebri
Analiza documentelor ( tot felul de sisteme informaii descrise)

Cel fel de informaie poate fi obinut prin analiza documentelor:

-problemecu sistemu existent
-oportunitatea de a face cunotine cu noi necesiti
-organizarea direciei
-nume presoanelor cheie
-valorile organizaiei
-informaie special n circmstane
-reguli de procesare

Sesiunule JAD (Joint Application Design)

Sunt grupuri structurate, focusate pe procesul determinarii mecanismului si
implica o echipa de proiect, manageri si utilizatori care lucreaza mpreun. Pot
reduce timpul de analiz cu pn la 50%.
Participanii
o
o
o

Coordonator (antrenat n tehnici JAD i seteaz agenda i

conduce procesele de grup)
Colegi (
particip la discuiile sesiunilor )
Secretar ( care nregistreaz informaia )

Sesiune JAD
o
o
o

Timp organizat din zi pe parcursul ctorva sptmni ( dup

ore de lucru faci pauz )
Susinere a managementului de a elibera participanii de la taskurile lor zi de zi
Planificarea corect (n caz contrar timpul e pierdut)

PROTOTIPIZAREA (collect requirments)

o

E o tehnic relativ modern de colectare a cerinelor. n aceast

abordare,se colecteaz un set de cerine preliminare pentru a crea
versiunea iniial a soluiei(prototyp-ul). Clientul vede aceast soluie i
ofer cerine adiionale.
n urmtorul ciclu de dezvoltare, prototyp-ul e modificat i prezentat
clientului din nou .Procesul continu att timp ct nu este colectat
masa critic de cerine( anumit cantitate pentru dezv sis. real )

Prototyping
Repetitiv process
Rezultatul e o versiune rudimentar sau simplificat a sistemului.
Are ca scop de a dezvolta specificaii concrete pentru sistemul final .
Aceast abordare ne permite s transformm cerinele ntr-un sistem
informaional.
Cerinele apar cnd utilizatorul vede prototipul.
Cnd e util prototipizarea
o Este folosit cnd cerinele clientului nu sunt clare.
o S fie implicai puini oameni.
o Cnd interfeele sunt complexe i necesit o form concret

Este util cnd exist o istorie de comunicare complicat ntre analiti i

utilizatori

Cnd nu e bun prototipizarea sau apare o problematic

o
o
o
o

La prototipizare se evit descrierele formale ( evitat )

Dificultatea adaptrii design-ului pentru audiene mari.
Un System Development Life Cycle (SDLC)- Ciclul de via e lungit.( E
util s ncepem dezvoltarea un pic mai devreme)
Parajarea cu alte sisteme foarte des nu e luat n consideraie.

URMtoarea etap se ncepe mai nainte ca etapa 2-a s se finalizeze pentru

a nu rmne fr taskuri...
Alte tehnici
Interviuiri- unu la unu
Brainstorming
Interviuri n grup
Analiza interfeelor
Studierea sistemeleor analogice
Reverse Engineering

One-to-one interviews (iterviuri)

Sa dea ct mai multe ntrebri deschise, pentru a afla ct mai multe de
la client.
Group interviews ( de la 2 la 4 pers)
Brainstorming
n unele cazuri este important cacerinele s fie create. E bun cnd
doreti a face ceva inovativ complet. Cel care coordoneaz brainstormingul s nu
dea voie pers nchise n sine care nu trebuie s tac.
Analiza interfeii
Un process n care analizm punctele de interaciune cu sisteme
externe, dispozitive sau oameni. Orice punct care o ieire la un sistem extern, la un
dispozitiv, om e considerat interfaa. Ne permite s creem cerine pentru
integrare( sau de integrare).
Studierea sistemelor analoage

Punctele de start sunt foarte des sisteme existente sau similare. Uneori
sisteme i produse comparabile pot s ne dea soluii pentru rezolvarea problemelor
sistemului nostru. S vedem ce exist i s mbuntim.
Reverse engineering
n baza acestui cod de creat cerinele sau documentaia. Avnd la
dispoziie codul surs.
Requirements Analysis
Analiza cerinelor este un proces, care reduce diferena dintre cerinele de
sistem i design-ul de proiect
Ne ofer design ca :
-sisteme infromatice
-funcionare
-comportamente

Obiectivele analizei
Identificare necesitii clientului.
Evaluarea fezabilitii( de a aduce beneficii)
Analiza economic i tehnic
Alocarea funciilor elementare de sistem
Stabilirea unui plac i a constrngerilor
Crearea termenilorcare i vom utiliza

Fazele analizii cerinelor

Determinarea problemei
Evaluarea i sintetizarea ( focusarea ce i cum)
Modelarea
Specificarea
Review

Domeniul informaional

Conine toate obiectele de date, numere ,text,imagini,video

Modelul de date i content informaional, care ne arat relaia dintre data i control
cre ne face systemul
Information flow- reprezint maniera n care data i obiectele se shimb prin sistem
Structura informaiei reprezentri ale organizriiinterne n itemuri de control.
Modelare
Model de date(dintre obiecte)
Model functional( descrierea funciei care pornete transformrile) (interiorul
clickului)
Model comportament( ce se ntmpl cnd dm click)

Partiionarea
Proceseaz rezultatelen elaborarea datelor, funciunilor i comportamentului
Orizotal pariionare (
Vertical partiionare(ne adncim i schimbm nivelul de abstracie) cu ct mai sus e
nalt

Cerine visuale
Viziunea esenial
De implementare

Specificare principiilor
Separarea funcionalitilor de implementare
Limbaj orientat pe proces
Specificaiile s aib componentele software
Specificarea sistemului= modelul cognitiv
Trebuie ca specificarea s aib mediu ei.
Specificarea trebuie s fie operaional.

Toleranat la incopletiti i uor de adugat ( s permit ca informaia s fie

incomplet)
Conceptul de adaptor. ablon de adaptor

Specifcaiile trebuie revzute

Sunt greu detestat
Trebuie revizuite de client i dezvoltator
Estimarea impactului este greu de facut(daca modific speif)

Evaluarea specificaiior tehnice

Sunt nelese uor
Design i testare
Test case-uri generate de cerine
Aproape de aplicaii

Prototipizari si specificatii
Prototipizare cu pierderi ( prototipul e aruncat)
Prototipul evolutionar ( este redefinit si ultilizat pentru finalizarea sistemului )
Erori tipice n analiza cerinelor
- Clienii nu neleg ce vor.
- Cerinele se schimb pe parcursul proiectului.
- Clienii pun termeni nerezonabili
-Probleme de comunicare, client i manageri de proiect.
- Echipa de dezvoltare nu nelege politica de dezvoltare.

Clienii nu tiu ce vor

-

S-l asigurai c petrecei mult timp la nceputul proiectului pentru a nelege

cerinele, scopul i livrabilitatea proiectului.
Subliniai presupunerile cu care lucreaz clientul. (asumcii i fapte)
ncercai s scriei o viziune clar a proiectului care conine funciile specifice
i beneficiile oferite de sistem.
Schimbarea cerinelor pe durata proiectului

Stabilii un proces foarte clar pentru cererile de schimbare.

Setai puncte de control (milestone) pentru fiecare baz de setare n urma
crora nu mai pot fi cerine de setare.
Asigur-te c cererile de schimbri sunt clar comunicate i planul proiectului
este updatat n concordan.

Stakeholder ( persoan interesat )

Clienii au termeni nerezonabili
-

Convertii cerinele ntr-un plan de proiect:

Cazul cel mai bun
Cazul tipic ( Ionel se mbolnvete)
Cazul cel mai ru ( Toi se mbol.)
Asigurai-v c planul proiectului ia resurse disponibile i ia suficient timp
pentru respectarea calitii
Discutai termenii limit utiliznd datele din planul iniial sau draft.
Exit probleme de comunicare ntre clieni,

manageri
-

Facei notie
Fii consisteni n utilizarea cuvintelor (numii un concept cu acelai cuvnt)
Echipa de dezvoltare nu nelege politica de oranizare.

Identificare persoanei care este capabil s rspund la ntrebri i

identificarea persoanei default
Identificai i cultivai alianii
Convingei oponenii din organizarea clientului prin plasarea problemelor ntrun mod relevant pentru experiena lor.
Utilizai punctele de intrare pentru a mica agenda nainte
ETAPA DE PROIECTARE. Arhitecturi

Arhitectura software conine setul sau mulimea de decizii importante ce in de

organizarea unui sistem software, incluznd selectarea elementelor structurale i a
interfeelor acestora. Tot aici specificm colaborarea dintre aceste elemente i
organizarea n subsisteme mai mari.
Aceasta, la fel implic funcionalitate, performan, reutilizare, constrngeri
economice i tehnlogice i compromisuri estetice.
Practici de implementare
Primul concept spune s preferm compoziia motenirii, mai bine compoziia
folosim dect motenire. Atunci cnd avei posibilitatea utilizrii compoziiei n locul
motenirii, dai prioritate compoziiei pentru c motenirea mrete nivelul de
dependen dintre clasele printe i fiu. Deci, limiteaz reutilizarea claselor fiu.
Aceasta de asemenea reduce complexitatea ierarhiilor, care pot fi greu de
administrat.

Dac folosim motenirea , putem spune c a este b i b e a, dar dac nu,

trebuie s folosim agregarea sau cimpoziia. Cnd facem motenire, atunci accesm
toate metodele ei, dac mai facem nc o dat motenire, nivelul trei nu va avea
nevoie de acele metode i mrim dependena ntre clase i nu le vom putea utiliza,
deoarece clasa noastr child nu are nevoie. De asta e mai bine s folosim
compoziia, pentru a aduga n clasa B i s le apelm. Noi vom scrie mai mult cod,
dar peste un timp va fi mai bine.
Stabilii un stil de cod i convenii pentru dezvoltare i nume. Scopul
acestei reguli e de a colabora n echipe . Cnd coderii au alte stiluri se pierde
conductivitate. Unul pune abrevieiri, altul cuvinte ntregi.
Verificai stilurile de codare stabilit n organizaie, dac nu exist atunci
mai bine e s-l introduci, utilizarea acestuia permite membrilor echipei s simplifice
revizuirea codului (code review), aceasta se face pentru ridicarea experienelor.
Meninei calitatea sistemului utiliznd tehnici de QA automat n timpul
dezvoltrii. Dac 2*2 e patru, nu poate avea alt valoare, la fel duplicatele de cod.
Utilizai unit testing i alte tehnici automatizate, cum ar fi analiza
dependenelor i analiza static a codului n timpul dezvoltrii. Definiii metrici clare
de performan i comportament pentru componente i subsisteme i folosii acele
sisteme automatizate pentru a le verifica.
Principii de implementare a nivelelor
Primul este des ntlnit i e numit separarea ariilor de funcionaliti .
Aplicaia ar trebuie s fie mprit n func. distincte, care au o intersecie ct mai
mic posibil. Cel mai mare avantaj a acestui principiu const n faptul c
funcionalitatea poate fi optimizat independent de alte funcionalti.
Stabilii explicit modul de comunicare ntre nivele, pentru a nu fi dificil
de repartizat. Este important s fie stabilite protocoalele
de comunicare i
formatele de date transmis ntre nivele totodat cu ct mai multe depndene sunt
ntre nivele cu att soluia va fi mai greu de neles i adminsitrat. Deci concluzia e
de a stabili ct mai explicit tehnologiile.
Utilizai abstracii pentru a implementa cuplarea slab ntre nivele.
Acesta poate fi atins prin definirea interfeelor componentelor ca faada de
exemplu, ce va conine date de intrare ieire. Stabilirea pe o perioad de timp.
Nu utilizai diferite tipuri de componente n acelai nivel logic.
Pstrai formatul de date consistent
n interiorul unui nivel sa
componente. Uneori trebuie s-l transforme dintr-un nivel n altul. Utilizarea mai
multor formate ntr-o aplicaie va rezulta ntr-o dificultate sporit de implementare,
extindere i mentenan. De fiecare dat cnd e necesar convertirea dintr-un
format n altul va trebui s implementm cod pentru conversie i operaia va duce
la un timp inutil de procesare sau adugtor.
Idei cheie

Determinai tipul aplicaiei

Ce fel de aplicaie trebuie s fie (dispozitive mobile, aplicaii rich-clinet
PC (sunt aplicaii care au logic pe client independent de server), Rich
Internet Applications, Aplicaii de tip serviciu.
Determinai strategia de instalare (deployment)
Determinai tehnologiile potrivite
Determinai atributele de calitate
Determinai aspectele comune( ceea ce am discutat n diagrama cu
security i factori comuni n sistemul nostru). Se stabilesc
mecanismele de securitate, comunicare i mangementul operaional.
De asemenea, e recomandabil s fie luai n consideraie urmtorii
factori. Instrumentariul i logurile. Atunci cnd facem aplicaii (n faza de
lansare primar, s avem loguri care le putem extrage i vedea cele
ntmplate). Autentificare persoana reala corespunde celei virtuale, noi
vedem dac persoana are permisiuni sau nu de a face ceva. Autorizare ne
permite s oferim acces la diferite servicii n dependen de necesiti am
drepturi de a accesa ceva.
Gndii-v la tabele ca la nite obiecte (tuplurile lor). Din aplicaie nu
poi face create sau drop la table. Teoretic nu trebuie s poi face.
Determine the Crosscutting Concerns
Excepii de management. Artm mesaje de erorare, excepii.

Comunicarea.
network.

Alegerea

protocoalelor,

protejarea

datelor

senzitive

pe

Caching. Atunci cnd de ex. toi caut n google un singur lucru i el menine
n cash pentru a afia direct, dar nu din baze de date.