Analiza este un proces de cercetare și în speță de decompoziție aunei probleme în probleme mai mici.

Rezolvăm acele probleme mici și facem sinteza pentru a identifica soluția .

Proiectarea este un proces de stabilire a structurii unui proiect software. Programarea este scrierea codului compilat sau interpretat și obținerea unei aplicații î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 entități care au comportament, metode , conțin informație ( atribute ) și care pot interacționa între ele. Dependență, asocieri.Obiectele pot fi lucruri tangibileRoluri – Sitem de operare – 2 roluri( admin si user) Unități organizaționale - Departament , secțiune , lucru în grupDispozitive - sensor , timer , printerEvenimente – Logoff, contract,paymentLocații – desktop, școală

Paradigmă- un set de presupuneri, concepte, valori și practici care constituie un mod de a privi realitatea pentru o comunitate care le îmărtășește .

Principiul de delegare, presupune că un obiect poate pune responsabilitatea implementării 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 înlocuiește parinte - trebuie-), Interface segregation principle, Dependency inversion principle. Mesaje și responsabilități. Mebrii comunică prin transmiterea de cereri între ei. Acțiunea este inițiată într-un obiect prin transmiterea unui mesaj către un agent ( un obiect) responsabil pentru acțiune. Mesajul codifică cererea de acțiune și este acompaniat de informația adăugătoare ( argumenți paramentri) necesară pentru a realiza sau îndeplini cererea. Receptorul este obiectul care primește mesajul. Dacă receporul acceptă mesajul, atunci el acceptă responsabilitatea de a realiza acțiunea indicată. Ca și răspuns la mesaj receptorul va îndeplini o metodă care va satisface cererea.

Șablon de proiectare – Lanț de responsabilități

ABSTRACȚII

Principiile fundamentale ale abordarii OO, Allen Key (1993)

-Totul este obiect

-Obiectele interacționază prin transmiterea și primirea mesajelor

-Fiecare obiect își are memoria proprie

-Fiecare obiect aparține unui grup de obiecte –clasă

-Clasa definește compornamentul comun tuturor obiectelor exemplarelor sale

-Clasele se organizează într-o structură arborescentă cu o rădăcină comună, asigurînd transferal de comportament de la clasele superioare claselor inferrioare din ierarhia de moștire.

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 număr de subunități 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ă legături

Principii (low capling și high coheasion) . Între module trebuie să aflăm interfețe cît mai puține.

Dezavantajele programării OO

Documentarea este un process mai dificil, decît în cazul programării procedurale.

În structure cu multe nivele de ierarhizare, uneori este foarte greu de urmărit de la care clasă vine o proprietate.

Avantaje programării OO

Mijloc de tartare a complextății atinsă prin abstractizare

Scalabilitate

Procesarea structurilor eterogene

Schimbarea comportamenului în momentul execuției

Reutilizare

Polimorfism structuri care se comportă diferit fără schimbarea unor elem.

Abstracție- 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 soluție la conflictele de nume și reprezintă colecții de clase, care sunt interdependente. Modulul oferă 2 spații de nume- spațiul public, care e accesibil în afara modului numit și interfață. Spațiul 2 spațiul privatdisponibil 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 clienților acestui tip de date . E foarte important ca acești clienți să aibă informația despre responsabilitățile, operațiile oferite, dar nu și modul de implementare a lor.Orientarea pe serviciiOrientarea pe obiecte ne permite definirea serviicilor tipurilor abstracte de date și oferă clienților clasei, servicii și nu date. Mesaje, moștenire și polimorfism- pe lîngă abordarea orientării pe sericii orientarea pe obiecte adaugă încă cîteva idei noi la tipul de date abstract în speța transmiterii de mesaje și polimorfism . E foarte important de a găsi nivelul drept de abstractizare la etapa inițială 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 informația necesară pentru utilizarea eficientă a ei.

-Metodele trebuie să aibă acces doar la informația necesară pentru îndeplinirea responsabilității lor.

Daniel Keller

-Să aleg nume ce pot fi pronunțate în voce

-Cuvintele se încep cu masuscule în nume complexe

-Atenție la utilizarea prescturtărilor

-Atenție la nume multisemantice

-Nu se recomanda utilizarea numerelor

Încapsularea

Oferă independență implementării 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 abstracțiilor obținute...

Ierarhii de clasă, moștenirea

-moștenirea implică o ierarhie de tip generalizare sau specializare ( este o )

Ierarhia de obiecte, agergare

Relația între două obiecte în care unul dintre obiecte aparține celuilalt obiect

Agreagarea – partoff ( un obiect conține prin referință sau valoare (compoziț) obține alte obiecte )

Piciorul este scaun?NU- compoziție

Masa este mobilă?Da- moștenire

Intefața 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.

Convenții 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

Referința 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 fără valori.

Dacă ați scris un constructor cu macar 1 par. Atunci trebuie să avem grijă să i se atribuie toate valorile.

Cînd trebuie să întoarcem un obiect this.value

Trebuie să arătăm care e atrbut și care parametru!!!

Dacă dorim apela o metodă la fel ca și sus.

CÎnd se folosește simbolul this????

1.Cînd ar putea exista conflicte de nume cu datele membru ale unui obiect (attribute)

2.Cînd o metodă trebuie să returneze ca rezultat o referință la obiectul ei receptor.

3.Referința 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 instanțele clasei respective. Se recomandă ca referirea unui membru statis să se facă ptrin intermediul numelui obiectului! Membrii statici pot fi referiți fără a instanția clasa, ei nu depind de obiecte.

Pentru a defini un membru static se utilizează cuvîntul 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. Apelînd o anumită metodă cu valorile acestui obiect o să fie ok. Dacă apelează metoda statică tot e ok, deoarece atrbiutele statice se partajează. Dacă apelăm metoda statică this nestatice. În metod statică nu poți apela nonstatic.

~X =100 va fi de 2 ori

La apelarea constructorilor, se apelează în primul rînd 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ă funcționalitate

-ușurința în căutare

-evitarea conflictelor de nume (aduăgarea 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 relații . Clasa are un caractel dual.

-Ierarhie conceptuală

-Ierarhie de implementare

Obiectul corespunde unui tip.

-IS-a Moștenire

-Has-a Agregare( cînd avem pointeri –adresa la obiectul cela)

-Uses-a (dependență în uml) Clasa a folosește o listă

Compoziția- lomonosov în Chișinău .

Moștenirea în C++ . Accesibilitatea membrilor!!!

MOȘtenirea în JAVA!!!

//vezi mob

Super(4) constructor baza

Ordinea exec. Constructor destructor la moștenire

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.

Funcții virtuale, dacă era în C++ virtual mergea cum trebuie, dar dacă nu e virtual atunci nu se ia de la tipul instanțiat (new Derived) dar de la tipul de bază declarant (base*b).

Funcția virtuală e funcția care implică : 1. Redefinirea comportamentului în calsa derivată de o funcție cu aceeași signature. 2. Funcția implică rezoluția dinamică a comportamentului în dependență de obiect și nu de tipul referinței spre acest obiect. – Tipul referinței corespunde obiectului.

3.Implică generarea unui table al funcțiilor v-table , care păstrează pointeri spre funcțiile fiecărui oibect derivat:

Acest lucru nu-l vedem. Ele fac LEGAREA tîrzie . Implică costuri performanță .

//vezi mob

Base*ref = new Derived();

Cu vritual nu trebuie sa scriu de două ori același 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 folosește pentru a schimba comportamentul unui obiect în mod dinamic ( de regulă pentru specificare algoritmilor în timp real )

O clasă abstractă e clasa care are măcar 1 funcție pur virtuală . Funcția 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 . Moștenirea 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 interfețe!!!

Func Virtuale – dinamic obiectul carei clase folosim pentru utilizare .

MOȘTENIREA MULTIPLĂ ÎN C++

În Java sunt folosite interfețele pentru a defini :

-Contracte ( API-uri)

-Tipuri ( ca alternativa pentru mostenirea multiplă )

Spre deosibire de clasa abstractă, interfața nu poate conține corp pentru metodele declarate. Interfața se începe cu I mare , după care merge cuvîntul entității sau logice celei ce trebuie să o implementăm . Pentru moștenire în Java folosim extends!!!!! Relația de implementare –realise .

Interfata Ioperation <| - - - - - Clasa Operation

Blocarea moștenirei

Există cazuri cînd o clasă nu dorim să fie moștenită . 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 CERINȚELOR ………………………………………………………………………………………………………..

Definiții.

Cerințe funcționale și nefuncționale .

Cerințe non-funcționale – performanță , culori , mărimi….

Abordări sunt cîteva: avem trei tipuri pentru care scrim cerințe

-As-IS sisteme existente așa cum sun la moment. Pentru ele se creează cerințe pentru sistemul care trebuie să fie computerizat.

-To-be sisteme – sunt sisteme de perspective care sunt bazate pe cerințele 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

-cerințele se pot modifica

Funcional requirement

- Se includ funcționalitățile pentru user sau procese pe care sistemul trebuie să realizeze

Nonfunctional requirement

- Prorprietățile pe care sistemul trebuie să le aibă- Operaționale- Performanțe- Securități- Social and political

Surse de cerințe Sources of Requirements

- Clienți- Parteneri- Adminsistratori- Analiști industriali- Domain experts- Informatia competitor

Tehnici de colectare a cerințelor

Caracteristici pentru coletare:

Impertinență

Imparțialitate

Relaxarea constrîngerilor

Atenție la detalii

Reframing(noi posibilități ) repoziționarea problemei

Tehnici

- Interviul: -întrebări cu sfîrșit închis și deschis ( să spui ceva 1 2 3 poze galarii)- Chestionare: -atenție la desin și pot conține close-end și open-end întrebări- Alte metode de colectare a cerințelor ( observarea lucrătorilor - Analiza documentelor business

Joint application design

Prototipizarea

Interviuri

- Opinii și date concrete – fapte. Seculații- Observă limbajul corpului și emoțiile - (Trebuie să aveți un check-list)- Să fii neutru și partial . Să poți asculta- Mai multe puncta de vedere

Cum sunt selectații cei care intervievează – intervievatori

Tipuri de utilizatori , managerii, participanți proiect.

Ține în minte politica organizațională

Designing interview questions

Tipuri de întrebări

- Closed-Ended questionsHow do customers place orders?

- Open-Ended questionsWhat are some problems you face on daily basis

- Probing QuestionsWhy?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

Înregistrați toată informația

Fii sigur că înțelegi toate problemele și termenii

Separați părerile de facts

Acordă timp pentru întrebări

Fă un rezumat

Chestionare- un se de întrebări

Analiza documentelor ( tot felul de sisteme informații descrise)

Cel fel de informație poate fi obținută prin analiza documentelor:

-problemecu sistemu existent

-oportunitatea de a face cunoștințe cu noi necesități

-organizarea direcției

-nume presoanelor cheie

-valorile organizației

-informație special în circmstanțe

-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 pînă la 50%.

Participanții

o Coordonator (antrenat în tehnici JAD și setează agenda și conduce procesele de grup)

o Colegi ( participă la discuțiile sesiunilor )o Secretar ( care înregistrează informația )

Sesiune JAD

o Timp organizat ½ din zi pe parcursul cîtorva săptămîni ( după ore de lucru faci pauză )

o Susținere a managementului de a elibera participanții de la task-urile lor zi de zi o Planificarea corectă (în caz contrar timpul e pierdut)

PROTOTIPIZAREA (collect requirments)

o E o tehnică relativ modernă de colectare a cerințelor. În această abordare,se colectează un set de cerințe preliminare pentru a crea versiunea inițială a soluției(prototyp-ul). Clientul vede această soluție și oferă cerințe adiționale.

o În următorul ciclu de dezvoltare, prototyp-ul e modificat și prezentat clientului din nou .Procesul continuă atît timp cît nu este colectată masa critică de cerințe( anumită cantitate pentru dezv sis. real )

PrototypingRepetitiv processRezultatul e o versiune rudimentară sau simplificată a sistemului.Are ca scop de a dezvolta specificații concrete pentru sistemul final .Această abordare ne permite să transformăm cerințele într-un sistem informațional.Cerințele apar cînd utilizatorul vede prototipul.

CÎnd e utilă prototipizareao Este folosit cînd cerințele clientului nu sunt clare.o Să fie implicați puțini oameni.o Cînd interfețele sunt complexe și necesită o formă concretăo Este utilă cînd există o istorie de comunicare complicată între analiști și utilizatori

Cînd nu e bună prototipizarea sau apare o problematică

o La prototipizare se evită descrierele formale ( evitată )o Dificultatea adaptării design-ului pentru audiențe mari.o Un System Development Life Cycle (SDLC)- Ciclul de viață e lungit.( E util să începem

dezvoltarea un pic mai devreme)o Parajarea cu alte sisteme foarte des nu e luată în considerație.

URMătoarea etapă se începe mai înainte ca etapa 2-a să se finalizeze pentru a nu rămîne fără taskuri...

Alte tehnici

Interviuiri- unu la unu

Brainstorming

Interviuri în grup

Analiza interfețelor

Studierea sistemeleor analogice

Reverse Engineering

One-to-one interviews (iterviuri)

Sa dea cît mai multe întrebări deschise, pentru a afla cît mai multe de la client.

Group interviews ( de la 2 la 4 pers)

Brainstorming

În unele cazuri este important cacerințele să fie create. E bun cînd dorești a face ceva inovativ complet. Cel care coordonează brainstormingul să nu dea voie pers închise în sine care nu trebuie să tacă.

Analiza interfeții

Un process în care analizăm punctele de interacțiune cu sisteme externe, dispozitive sau oameni. Orice punct care o ieșire la un sistem extern, la un dispozitiv, om e considerat interfața. Ne permite să creem cerințe 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 soluții pentru rezolvarea problemelor sistemului nostru. Să vedem ce există și să îmbunătățim.

Reverse engineering

În baza acestui cod de creat cerințele sau documentația. Avînd la dispoziție codul sursă.

Requirements Analysis

Analiza cerințelor este un proces, care reduce diferența dintre cerințele de sistem și design-ul de proiect

Ne oferă design ca :

-sisteme infromatice

-funcționare

-comportamente

Obiectivele analizei

Identificare necesității clientului.

Evaluarea fezabilității( de a aduce beneficii)

Analiza economică și tehnică

Alocarea funcțiilor elementare de sistem

Stabilirea unui plac și a constrîngerilor

Crearea termenilorcare îi vom utiliza

Fazele analizii cerințelor

Determinarea problemei

Evaluarea și sintetizarea ( focusarea ce și cum)

Modelarea

Specificarea

Review

Domeniul informațional

Conține toate obiectele de date, numere ,text,imagini,video

Modelul de date și content informațional, care ne arată relația dintre data și control cre ne face systemul

Information flow- reprezintă maniera în care data și obiectele se shimbă prin sistem

Structura informației –reprezentări ale organizăriiinterne în itemuri de control.

Modelare

Model de date(dintre obiecte)

Model functional( descrierea funcției care pornește transformărișle) (interiorul clickului)

Model comportament( ce se întîmplă cînd dăm click)

Partiționarea

Procesează rezultateleîn elaborarea datelor, funcțiunilor și comportamentului

Orizotală pariționare (

Verticală partiționare(ne adîncim și schimbăm nivelul de abstracție) cu cît mai sus e nalt

Cerințe visuale

Viziunea esențială

De implementare

Specificare principiilor

Separarea funcționalităților de implementare

Limbaj orientat pe proces

Specificațiile să aibă componentele software

Specificarea sistemului= modelul cognitiv

Trebuie ca specificarea să aibă mediu ei.

Specificarea trebuie să fie operațională.

Toleranată la incopletități și ușor de adăugat ( să permită ca informația să fie incompletă)

Conceptul de adaptor. Șablon de adaptor

Specifcațiile trebuie revăzute

Sunt greu detestat

Trebuie revizuite de client și dezvoltator

Estimarea impactului este greu de facut(daca modific speif)

Evaluarea specificațiior tehnice

Sunt înțelese ușor

Design și testare

Test case-uri generate de cerine

Aproape de aplicații

Prototipizari si specificatii

Prototipizare cu pierderi ( prototipul e aruncat)

Prototipul evolutionar ( este redefinit si ultilizat pentru finalizarea sistemului )

Erori tipice în analiza cerințelor

- Clienții nu înțeleg ce vor.

- Cerințele se schimbă pe parcursul proiectului.

- Clienții pun termeni nerezonabili

-Probleme de comunicare, client și manageri de proiect.

- Echipa de dezvoltare nu înțelege politica de dezvoltare.

Clienții nu știu ce vor

- Să-l asigurați că petreceți mult timp la începutul proiectului pentru a înțelege cerințele, scopul și livrabilitatea proiectului.

- Subliniați presupunerile cu care lucrează clientul. (asumcții și fapte)- Încercați să scrieți o viziune clară a proiectului care conține funcțiile specifice și beneficiile

oferite de sistem.

Schimbarea cerințelor pe durata proiectului

- Stabiliți un proces foarte clar pentru cererile de schimbare.- Setați puncte de control (milestone) pentru fiecare bază de setare în urma cărora nu mai pot fi

cerințe de setare.- Asigură-te că cererile de schimbări sunt clar comunicate și planul proiectului este updatat în

concordanță.

Stakeholder ( persoană interesată )

Clienții au termeni nerezonabili

- Convertiți cerințele într-un plan de proiect:Cazul cel mai bunCazul tipic ( Ionel se îmbolnăvește)Cazul cel mai rău ( Toți se îmbol.)

- Asigurați-vă că planul proiectului ia resurse disponibile și ia suficient timp pentru respectarea calității

- Discutați termenii limită utilizînd datele din planul inițial sau draft.

Exită probleme de comunicare între clienți, manageri

- Faceți notițe- Fiți consistenți în utilizarea cuvintelor (numiți un concept cu același cuvînt)

Echipa de dezvoltare nu înțelege politica de oranizare.

- Identificare persoanei care este capabilă să răspundă la întrebări și identificarea persoanei default

- Identificați și cultivați alianții- Convingeți oponenții din organizarea clientului prin plasarea problemelor într-un mod relevant

pentru experiența lor.- Utilizați punctele de intrare pentru a mișca agenda înainte

ETAPA DE PROIECTARE. Arhitecturi

Arhitectura software conține setul sau mulțimea de decizii importante ce țin de organizarea unui sistem software, incluzînd selectarea elementelor structurale și a interfețelor acestora. Tot aici specificăm colaborarea dintre aceste elemente și organizarea în subsisteme mai mari.

Aceasta, la fel implică funcționalitate, performanță, reutilizare, constrîngeri economice și tehnlogice și compromisuri estetice.

Practici de implementare

Primul concept spune să preferăm compoziția moștenirii, mai bine compoziția folosim decît moștenire. Atunci cînd aveți posibilitatea utilizării compoziției în locul moștenirii, dați prioritate compoziției pentru că moștenirea mărește nivelul de dependență dintre clasele părinte și fiu. Deci, limitează reutilizarea claselor fiu. Aceasta de asemenea reduce complexitatea ierarhiilor, care pot fi greu de administrat.

Dacă folosim moștenirea , putem spune că a este b și b e a, dar dacă nu, trebuie să folosim agregarea sau cimpoziția. Cînd facem moștenire, atunci accesăm toate metodele ei, dacă mai facem încă o dată moștenire, nivelul trei nu va avea nevoie de acele metode și mărim dependența între clase și nu le vom putea utiliza, deoarece clasa noastră child nu are nevoie. De asta e mai bine să folosim compoziția, pentru a adăuga în clasa B și să le apelăm. Noi vom scrie mai mult cod, dar peste un timp va fi mai bine.

Stabiliți un stil de cod și convenții pentru dezvoltare și nume. Scopul acestei reguli e de a colabora în echipe . Cînd coderii au alte stiluri se pierde conductivitate. Unul pune abrevieiri, altul cuvinte întregi.

Verificați stilurile de codare stabilit în organizație, 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 experiențelor.

Mențineți calitatea sistemului utilizînd tehnici de QA automat în timpul dezvoltării. Dacă 2*2 e patru, nu poate avea altă valoare, la fel duplicatele de cod.

Utilizați unit testing și alte tehnici automatizate, cum ar fi analiza dependențelor și analiza statică a codului în timpul dezvoltării. Definiții metrici clare de performanță și comportament pentru componente și subsisteme și folosiți acele sisteme automatizate pentru a le verifica.

Principii de implementare a nivelelor

Primul este des întîlnit și e numit separarea ariilor de funcționalități . Aplicația ar trebuie să fie împărțită în func. distincte, care au o intersecție cît mai mic posibilă. Cel mai mare avantaj a acestui principiu constă în faptul că funcționalitatea poate fi optimizată independent de alte funcționaltăți.

Stabiliți 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 cît mai multe depndențe sunt între nivele cu atît soluția va fi mai greu de înțeles și adminsitrat. Deci concluzia e de a stabili cît mai explicit tehnologiile.

Utilizați abstracții pentru a implementa cuplarea slabă între nivele. Acesta poate fi atins prin definirea interfețelor componentelor ca fațada de exemplu, ce va conține date de intrare ieșire. Stabilirea pe o perioadă de timp.

Nu utilizați diferite tipuri de componente în același nivel logic.

Păstrați 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 aplicație va rezulta într-o dificultate sporită de implementare, extindere și mentenanță. De fiecare dată cînd e necesară convertirea dintr-un format în altul va trebui să implementăm cod pentru conversie și operația va duce la un timp inutil de procesare sau adăugător.

Idei cheie

- Determinați tipul aplicațieiCe fel de aplicație trebuie să fie (dispozitive mobile, aplicații rich-clinet PC (sunt aplicații care au logică pe client independent de server), Rich Internet Applications, Aplicații de tip serviciu.

- Determinați strategia de instalare (deployment)- Determinați tehnologiile potrivite- Determinați atributele de calitate- Determinați aspectele comune( ceea ce am discutat în diagrama cu security și factori comuni

în sistemul nostru). Se stabilesc mecanismele de securitate, comunicare și mangementul operațional. De asemenea, e recomandabil să fie luați în considerație următorii factori. Instrumentariul și logurile. Atunci cînd facem aplicații (în faza de lansare primară, să avem loguri care le putem extrage și vedea cele întîmplate). 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 necesități am drepturi de a accesa ceva.

Gîndiți-vă la tabele ca la niște obiecte (tuplurile lor). Din aplicație nu poți face create sau drop la table. Teoretic nu trebuie să poți face.

Determine the Crosscutting Concerns

Excepții de management. Arătăm mesaje de erorare, excepții.

Comunicarea. Alegerea protocoalelor, protejarea datelor senzitive pe network.

Caching. Atunci cînd de ex. toți caută în google un singur lucru și el menține în cash pentru a afișa direct, dar nu din baze de date.