Sisteme de Administrare Conturi de Servicii Cloud

Cloud – Servicii folosite de windows azure

Microsoft azure( formal Windows azure înainte de 25 martie 2014) este o "cloud computing" platformă și infrastructură creată de Microsoft, pentru construirea, implementarea și gestionarea aplicațiilor și serviciilor printr-o rețea globală Microsoft.

Acesta oferă servicii atât PaaS și IaaS, suportă multe limbaje de programare diferite, instrumente și cadre, Incluzând ambele specificații Microsoft și a treia parte a sistemului software. Windows Azure a fost lansat pe 1 februarie 2010

Densitatea mare de găzduire de site-uri web, permite dezvoltătorilor de a construi site-uri folosind ASP.NET, PHP, Node.js său Python și pot fi implementate folosind FTP, Git, Mercurial său Team Foundation Server. Această caracteristică a fost anunțat în formă de previzualizare în iunie 2012 la evenimentul Microsoft Azure. Clienții pot crea site-uri web în PHP, ASP.NET, Node.js, ,Python sau selecta din mai multe aplicații open source la o galerie pentru a implementa.

Mașină Virtuală

Dezvoltatorii migrează aplicații și infrastructuri fără modificarea codului existent și pot rula atât pe Windows Server cât și pe Linux . Au anunțat în formă de previzualizare la evenimentul creat de Windows Azure în iunie 2012. Windows Azure Virtual Machines cuorinde infrastructură că un serviciu (IaaS), oferind de la Microsoft pentru cloud-urile lor publice. Clienții pot crea mașini virtuale, la care au de control complet, pentru a rula în Microsoft Dată Centers. În previzualizare mașinile virtuale acceptă Windows Server 2008 și sisteme de operare 2012 și câteva distribuții de Linux. Versiunea General Availability de mașină virtuală a fost lansat în mai 2013.

Cloud Services

Platformă Microsoft este că un mediu de serviciu (PaaS)ce poate fi folosit pentru a crea aplicații scalabile și servicii. Suportă mai multe nivele de arhitecturi și implementări automate. Anterior numit "Hosted Services", servicii de cloud pentru Windows Azure cuprând un aspect al PaaS oferite de platformă Windows Azure. Servicile de cloud sunt containere de aplicații găzduite. Aceste aplicații pot fi publice (cum ar fi site-uri web și soluții e-commerce), său pot fi private specializate pe anumite domenii, cum ar fi prelucrarea comenzilor său analizarea datelor. Dezvoltătorii pot scrie cod pentru servicii de cloud într-o varietate de limbaje de programare. Există kituri de dezvoltare specific software (SDK) furnizat de Microsoft pentru Python, Java, Node.js și .NET. alte limbaje pot avea suport prin proiecte Open Source. Microsoft a publicat codul sursă pentru bibliotecile clientului lor pe GitHub.

Design

Microsoft Azure utilizează un sistem de operare specializat, numit Microsoft Azure, pentru a rula "cloud layer " de: un cluster găzduit la centre de date Microsoft, care gestionează modul stocare a resurselor. Microsoft Azure a fost descris că un "cloud layer" partea de sus a unui număr de sisteme de servere Windows, care folosesc Windows Server 2008 și o versiune personalizată a Hyper-V, cunoscut sub numele de Microsoft Azure Hypervisor pentru a oferi virtualizare de servicii.

Scalarea și fiabilitatea sunt controlate de Microsoft Azure Fabric Controller astfel de servicii și mediul nu avariază, dacă la unul dintre servere apar defecțiuni în cadrul centrului de date Microsoft și oferă gestionarea de aplicații web utilizatorului că resursele de memorie și echilibrare a sarcinilor.

Azure oferă un API construit pe REST, HTTP, XML și care permite dezvoltarea pentru a interacționa cu serviciile oferite de Microsoft Azure. Microsoft oferă, de asemenea, o bibliotecă client-side reușit clasă care încapsulează funcțiile de interacționare cu serviciile. De asemenea, se integrează cu Microsoft Visual Studio, Git, Eclipse.

Tehnologii:

.Net

Programare orientată pe obiect

Introducere .NET

.NET este un cadru (Framework) software de dezvoltare unitară care permite realizarea, distribuirea și rularea aplicațiilor desktop Windows și a aplicațiilor de WEB.

Tehnologia .NET pune impreună mai multe tehnologii (XML, ASP, OOP, WDSL ,SOAP, UDDI) și limbaje de programare (VB, C++, C#, J#) asigurând, totodată, atât portabilitatea codului compilat între diferite calculatoare cu sistem Windows, cât și reutilizarea codului în programe, indiferent de ce limbaj de programare e folosit.

.NET Framework este o parte ce este livrată împreună cu sistemul de operare Windows. De fapt, .NET 2.0 vine cu sistemul de operare Windows Server 2003, se poate instala și pe versiunile anterioare, până la Windows 98 inclusiv; .NET 3.0 este instalat pe Windows Vista și poate fi instalat si pe versiunile Windows XP cu SP2 și Windows Server 2003 cu minimum SP1.

Pentru a desfășura aplicații pe platforma .NET este bine să avem 3 componente esențiale:

 un set de limbaje (C#, Visual Basic .NET, J#, Perl, Fortran, Cobol, Managed C++, Smalltalk, Lisp, Pascal etc),

 un set de medii de desfășurare (Visual Studio .NET, Visio),

 o librărie de clase pentru crearea serviciilor Web, aplicațiilor desktop

Windows și aplicațiilor Web.

Când dezvoltăm aplicații .NET, putem utiliza:

 Servere specializate – câteva servere Enterprise .NET (din familia SQL Server 2000, Exchange 2000 etc), care pun la dispoziție funcții de păstrare a bazelor de date, email, aplicații B2B (Bussiness to Bussiness – comerț electronic între partenerii unei afaceri).

 Servicii Web (în special comerciale), utile în aplicații care necesită identificarea celor ce folosesc acest serviciu (de exemplu, .NET Passport – un mod de autentificare folosind un singur nume și o parolă pentru toate site-urile vizitate)

 Servicii ce cuprind dispozitive non-PC (XBox, Pocket PC Phone Edition, Smartphone, set-top boxes, Tablet,PC, Smart Display, etc.)

.NET Framework

Partea de .NET Framework stă la baza tehnologiei .NET, este ultima interfață între aplicațiile .NET și sistemul de operare și actualmente conține:

 Limbajele C#, VB.NET, C++ și J#. Pentru a fi integrate în platforma .NET, toate aceste limbaje respectă niște specificații OOP numite Common Type System (CTS). Ele au ca elemente de bază: clase, interfețe, delegări, tipuri valoare și referință, iar ca mecanisme: moștenire, polimorfism și tratarea excepțiilor.

 Platforma de executare comună a programelor ce este numită Common Language Runtime

(CLR), utilizată de toate aceste 4 limbaje. CTS este o parte din CLR.

 Ansamblul de librării necesare în realizarea aplicațiilor desktop sau Web,ce este numit

Framework Class Library (FCL).

Arhitectura .NET Framework

Servicii WEB Formulare

Data and XML classes

(ADO.NET, SQL, XML etc.)

Framework Base Classes

(IO, securitate, fire de execuție, colecții etc.)

Common Language Runtime

(execepții, validări de tipuri,compilatoare JIT)

CLR

Despre compilarea programelor

Un program scris într-unul dintre aceste limbajele .NET conform Common Language Specification (CLS) este compilat în Microsoft Intermediate Language (MSIL sau IL). Codul astfel obținut având extensia "exe", dar nu este executabil direct, ci folosește formatul unic MSIL.

CLR include o mașină virtuală asemănătoare cu o mașină Java, ce execută instrucțiunile IL rezultate în urma compilării. Mașina folosește un compilator mai special numit JIT (Just In Time). Compilatorul JIT examinează codul IL corespunzător apelului unei anumite metode și produce codul mașină adecvat și eficient. El recunoaște secvențele de cod pentru care s-a obținut deja codul mașină adecvat, permițând reutilizarea acestuia fără reexaminare, ce face ca, pe parcursul rulării,aceste aplicații .NET să fie din ce în ce mai rapide.

Faptul că programul IL produs de diferitele limbaje este foarte asemănător are ca rezultat interoperabilitatea între aceste limbaje. Astfel, clasele și obiectele create într-un anumit limbaj

.NET pot fi folosite cu succes în altul.

În plus, CLR se ocupă de gestionarea automată a memoriei (un mecanism folosit în platforma .NET ce ajuta de eliberare automată a zonelor de memorie asociate unor date ce au devenit nefolositoare – Garbage Collection).

De ce am alege .NET?

În primul rând pentru că ne oferă instrumente pe care putem să le folosim și în alte programe, oferă acces ușor la baze de date, permite realizarea imaginilor sau a altor elemente de grafica. Spațiul de nume System.Windows.Forms conține instrumente (controale) ce permit implementarea elementelor interfeței grafice cu utilizatorul. Folosind aceste controale, puteți proiecta și dezvolta rapid și interactiv, elementele interfeței grafice. Tot .NET oferă clase ce efectuează majoritatea sarcinilor uzuale pe care le intâlnesc programele și ce plictisesc și fură timpul programatorilor, reducând astfel timpul necesar dezvoltării aplicațiilor.

C#

C# este un limbaj de programare orientat-obiect conceput de Microsoft pe la sfârșitul anului 90. A fost conceput că un concurent pentru limbajul Java. Că și acesta, C# este un derivat al limbajului de programare C++.

C# și programarea Windows

C# simplifică mult scrierea de programe pentru sistemul de operare Windows.

Vedere generală asupra limbajului C#. Tipuri predefinite. Tablouri. Șiruri de caractere

2.1 Vedere generală asupra limbajului C#

C# este un limbaj de programare imperativ, obiect–orientat. Este foarte asemănător cu Java și C++, motiv pentru care curbă de îınvățare este foarte lină.

Un prim exemplu de program, care conține o serie de elemente ce se vor întâlni în continuare, este: using System;

class HelloWorld

{

public static void Main()

{

Console.WriteLine(‘‘Hello world!’’);

}

}

În exemplul precedent metoda principală preia o listă de parametri transmiși din linia de comandă (un șir de obiecte de tip String) și va afișa pentru fiecare nume “Hello” urmat de numele de indice i (numerotarea parametrilor începe de la 0). Construcția “{0}” va fi înlocuită cu primul argument care urmează după “Hello {0}”. La executarea programului de mai sus în forma: HelloWorld Ana Dan, se va afișa pe ecran:

Hello Ana

Hello Dan

Metoda Main poate să returneze o valoare întreagă, care să fie folosită de către sistemul de operare pentru a semnala dacă procesul s–a încheiat cu succes sau nu . Menționăm faptul că limbajul este case–sensitive .

Ca metode de notare Microsoft recomandă folosirea următoarelor două convenții:

• conventie Pascal, în care prima literă a fiecărui cuvânt se scrie ca literă mare; exemplu: LoadData, SaveLogFile

• convenția tip "cămilă" este la fel ca precedenta, dar primul caracter al primului cuvânt nu este scris ca literă mare; exemplu: userIdentifier, firstName. În general, convenția tip Pascal este folosită pentru tot ce este vizibil (public), precum nume de clase, metode, proprietăți, etc. Parametrii metodelor ¸si numele câmpurilor se scriu cu convenția cămilă. Se recomandă evitarea folosirii notației ungare (numele unei entități trebuie să se refere la semantica ei, nu la tipul de reprezentare).

2.2 Tipuri de date

C# prezintă două grupuri de tipuri de date: tipuri valoare și tipuri referință. Tipurile valoare includ tipurile simple (ex. char, int, float), tipurile enumerare și structură și au ca principale caracteristici faptul că ele conțin direct datele referite și sunt alocate pe stivă sau inline într–o structură. Tipurile referință includ tipurile clasă, interfață, delegat și tablou, toate având proprietatea că variabilele de acest tip stochează referințe către obiectele conținute. Demn de remarcat este că toate tipurile de date sunt derivate (direct sau nu) din tipul System.Object, punând astfel la dispoziție un mod unitar de tratare a lor.

2.2.1 Tipuri predefinite

C# conține un set de tipuri predefinite, pentru care nu este necesară referirea vreunui spațiu de nume via directiva using sau calificare completă: string, object, tipurile întregi cu semn și fără semn, tipuri numerice în virgulă mobilă, tipurile bool și decimal.

Tipul string este folosit pentru manipularea șirurilor de caractere codificate Unicode; conținutul obiectelor de tip string nu se poate modifica . Clasa object este rădăcina ierarhiei de clase din .NET, la care orice tip (inclusiv un tip valoare) poate fi convertit.

Tipul bool este folosit pentru a reprezenta valorile logice true și false. Tipul char este folosit pentru a reprezenta caractere Unicode, reprezentate pe 16 biți. Tipul decimal este folosit pentru calcule în care erorile determinate de reprezentarea în virgulă mobilă sunt inacceptabile, el punînd la dispoziție 28 de cifre zecimale semnificative.

ASP

Active Server Pages (ASP), cunoscut și sub denumirile de Classic ASP sau ASP Classic, a fost primul limbaj de programare server-side al lui Microsoft pentru generarea de pagini web dinamice. Inițial a fost lansat ca un add-on pentru IIS prin Windows NT 4.0 Option Pack, după care a fost inclus ca o componentă gratuită în Windows Server, începând cu versiunea Windows 2000 Server). În prezent a fost depășit de versiunea sa ASP.NET.

ASP 2.0 oferit șase obiecte încorporate: cerere, ASPError, cerere, răspuns, Server și sesiune. Sesiune, de exemplu, reprezintă o sesiune care menține starea de variabile la o pagină. [1 engine\ Active Scripting (Scriptare) pe suport de componenta Object Model (COM) permite ASP site-uri de acces funcționalitate în biblioteci compilat ca DLL-uri. ASP 3.0 nu difera foarte mult de ASP 2.0, dar oferă unele îmbunătățiri suplimentare cum ar fi: metoda Server.Transfer, metoda de Server.Execute și un obiect de ASPError îmbunătățită.

ASP 3.0, de asemenea, activat de tamponare implicit și optimizat motorul pentru o performanță mai bună. Utilizarea de pagini ASP cu Internet Information Services (IIS) este susținută în prezent pe toate versiunile suportate de IIS. Utilizarea de pagini ASP vor fi sprijinite pe Windows 8 pentru un minim de 10 de ani de la data de lansare Windows 8.

Summary

Paginile web cu fișiere ASP utilizare prelungire ASP, deși unele site-uri web deghiza alegerea lor de limbaj de scripting din motive de securitate (de exemplu, utilizați în continuare mai frecvente .htm sau .html extensia). Pagini cu utilizarea de prelungire .aspx compilat ASP.NET (bazate pe .NET Framework Microsoft), ceea ce le face mai rapid și mai robust decât scripting server-side în ASP, care este interpretat în run-time; Cu toate acestea, paginile ASP.NET poate include încă unele scripting ASP.Introducerea ASP.NET condus la utilizarea termenului clasic ASP pentru tehnologii originale.

Programatorii scriu majoritatea paginilor ASP utilizând VBScript, dar orice alt motor Active Scripting pot fi selectate în locul directivei Language sau <limba script = "manu" runat = "server"> sintaxa. JScript (implementarea Microsoft a ECMAScript) este altă limbă, care este, de obicei, nu este valabil. PerlScript (un derivat de Perl), iar altele sunt disponibile ca instalabile motoare Active Scripting terți.

ASP on non-Microsoft Operatin Systems

Tehnologia Microsoft ASP rulează doar pe platformele Windows. Un număr de produse emula o parte din funcționalitatea Classic ASP pe serverele web non-Microsoft. Apache :: ASP de exemplu porturile Classic ASP a Web Server Apache, dar nu interpreteaza Visual Basic limbi sau alte scripting susținute de ASP.

Sun Java System ASP (fosta ChiliSoft ASP) a fost un emulator de popular și relatărilor complete, [6], dar a fost întreruptă.

MVC/Patern MVC

Introducere

Probleme

Una dintre cele mai intâlnite probleme în proiectele de anvergură este organizarea pe grupuri pentru a putea lucra cu una sau mai multe echipe de programatori. De asemenea, cu toții ne dăm seama la un moment dat că scriem cod eronat. Eu definesc codul eronat că fiind neadecvat pentru reutilizare acestuia în alte aplicații. Nu de foarte multe ori suntem obligați să facem sisteme de autentificare, de înregistrare, avem nevoie de multe modalități de a utiliza bazele de date etc. Dar, aceste probleme care sunt scrise o data și folosite ulterior au în comun ceva : o dată facute modificările ce trebuie aduse pentru ca acestea să fie refolosite sunt minime. Însă ce facem dacă suntem nevoiți să încercăm să edităm acel cod sursă după un an?

Soluția

Evident, soluția stă în propriile noastre mâini. Trebuie să gândim o altă modalitate de lucru ce se poate potrivi perfect pentru orice model de proiect, trebuie să stabilim o arhitectură ce pot să o aibă în comun toate proiectele. Practic, un punct de reper ce poate fi descoperit un programator bun, indiferent de limbajele de programare în care lucrează, abilitatea programatorului este de a aplică tehnici cunoscute în această industrie pentru a arhitecturiza un model de proiecte într-un mod eficient. Design Patterns sunt un set de procedee ce pot fi aplicate în diverse probleme ce se găsesc frecvent în cadrul programării orientate pe obiect (POO). Unele din cele mai cunoscute design patternuri utiliyate la scară largă sunt Factory, Registry, Singleton,și MVC.

Primele trei modauri de lucru sunt usoare, în vreme ce MVC reprezintă o structură foarte eficientă și complexă , ce se adapteayă cu aproape orice model de proiect.

Întroducere MVC

Ce este un MVC?

MVC, sau Model-View-Controller este un tipar arhitectural folosit în industria de development software (inclusiv web development). Această modalitate de utilizare reușește cu succes izolarea părții logice de interfață a proiectului, rezultând aplicații foarte de ușor de modificat. În structură MVC, modelul reprezintă datele de care are nevoie aplicația, viewerul concordă cu elementele de interfață și controller-ul reprezintă sistemul de comunicații și decizional care prelucrează datele informaționale, făcând relație între model și view.

Despre Model,Controller sView

Modelul reprezintă o partea de hard-programming, partea logică a unei aplicații. Are în responsabilitate toate acțiunile și operațiile asupra autentificării utilizatorilor, datelor și integrarea diverselor clase care permit procesarea informațiilor pentru diverse baze de date.

View-ul se ocupă de actiunea de a afișa date, practic această parte a programului are grijă de cum vede utiliyatorul final informația procesată de către controller. O dată ce aceste funcțiile sunt executate de către model, viewului îi sunt arătate rezultatele, iar acesta le va transmite către browser. În general viewul reprezintă o mini-aplicatie care ajută la randarea unor anumite informații, ce are la bază diverse template-uri.

Controller-ul reprezintă inteligența aplicației. Aceasta crează legătură dintre model și view, între acțiunile utilizatorului și partea decizională ce tine de aplicației În funcție de ce are nevoie utilizatorul, controllerul apelează anumite funcții hotărâte special pentru secțiunea de site în care se găsește userul. Funcția este folosită de model pentru a prelucra aceste date, după care informațiile ce sunt noi vor fi trimise de către view, ce le va arăta apoi prin template-uri.

WCF(windows services)

Windows Communication Foundation (sau WCF) este un API din cadrul .NET Framework folosit pentru construcția aplicațiilor bazate pe servicii connected (SOA).

Arhitectura

WCF a fost proiectat în acord cu principiile SOA pentru implementarea programării distribuite, unde serviciile sunt consumate de către consumatori. Clienții pot consuma mai multe servicii, și serviciile pot fi, la rândul lor, consumate de mai mulți clienți. Serviciile sunt slab conectate între ele. De-obicei, serviciile oferă o interfață WSDL, pe care orice client WCF o poate folosi, pentru a consuma serviciul, indiferent de platforma pe care este găzduit sericiul. WCF implementează mai multe standarde avansate pentru servicii web, cum ar fi WS-Addressing, WS-ReliableMessaging și WS-Security. Odată cu lansarea .NET Framework versiunea 4.0, WCF oferă și servicii pentru utilizarea familiei de formate RSS (Really Simple Syndication).

Servicii

Un serviciu WCF este compus din 3 părți — o clasă Serviciu care implementează serviciul care va fi oferit, un mediu gazdă, pentru a găzdui seriviciul, și unul sau mai multeendpoints la care clienții se vor conecta. Toată comunicația cu serviciul WCF se derulează prin intermediul endpoint-urilor. Endpoint-urile specifică un Contract care definește care metode din clasa Serviciu vor fi accesibile prin intermediul endpoint-ului; fiecare endpoint poate expune un set diferit de metode. În concluzie, endpoint-urile definesc olegătură care specifică cum va comunica un client cu serviciul și adresa unde este găzduit endpoint-ul.

În Windows Vista, Windows Server 2008 și Windows 7 (sisteme de operare care încorporează IIS 7), Windows Activation Services poate fi folosit pentru a găzdui serviciul WCF. Alte posibilități pentru găzduirea serviciului WCF pot fi fie IIS, sau se poate autogăzdui în orice proces, folosind clasa ServiceHost, care este furnizată de către WCF. Un serviciu WCF auto-găzduit poate fi pus la dispoziție de către o aplicație-consolă, o aplicație Windows Forms, sau un serviciu Windows.

Endpoint-uri

Un client WCF se conectează la un serviciu WCF folosind un endpoint. Fiecare serviciu își expune contractele prin intermediul unuia sau mai multor endpoint-uri. Un endpoint are o adresă, care este un URL specificând unde poate fi accesat endpoint-ul, și parametrii de conexiune, care specifică transferul de date.

Prescurtarea "ABC" poate fi folosită pentru memorarea noțiunilor Address / Binding / Contract (Adresa / Conexiune / Contract). Conexiunea specifică ce protocoale de comunicare sunt folosite pentru accesarea serviciului, dacă anumite mecanisme de securitate sunt necesare, și alte informații similare. WCF include conexiuni predefinite pentru cele mai comune protocoale de comunicare, cum ar fi SOAP peste HTTP, SOAP peste TCP, și SOAP peste Message Queues, etc. Interacțiunea dintre endpoint-ul WCF și client este realizată folosind formatul SOAP.

Când un client dorește să acceseze serviciul prin intermediul unui endpoint, nu îi este suficientă doar cunoașterea contractului, ci mai este necesară și acceptarea tipului de legătură, specificată de endpoint. Deci atât clientul, cât și serverul trebuie să aibă endpoint-uri compatibile.

Odată cu lansarea .NET Framework versiunea 3.5 din noiembrie 2007, Microsoft a lansat un encoder, ce îi oferă platformei WCF suportul necesar pentru formatul de serializareJSON [1]. Acest lucru le permite serviciilor dezvoltate utilizând WCF să răspundă și cererilor trimise de paginile web prin intermediul metodelor AJAX.

WPF

Windows Presentation Foundation (WPF) este compus din o mulțime de assembly pentru a crea aplicații GUI. Un principal avantaj al acestui model este separarea completă dintre designeri și dezvoltatori.

WPF – Fundamente Ierarhia de clase (cea mai des folosită)

Object – clasă de bază pentru toate clasele din .NET.

DispatcherObject – clasa de bază folosită de orice obiect ce dorește să fie accesat numai din firul care l-a creat.

DependencyObject – clasa de bază pentru orice obiect ce suportă proprietăți dependențe, una din caracteristicile principale ale WPF.

Freezable – clasa de bază pentru obiecte ce pot fi « înghețate » într-o stare read-only din motive de performanță. Poate fi accesată de fire multiple. Nu-și poate schimba starea dar poate fi clonată. Exemple : primitive grafice – pensoane, penițe, clase pentru geometrii și animații.

Visual – clasa de bază pentru obiecte ce au reprezentare vizuală 2D.

UIElement – clasa de bază pentru toate obiectele vizuale 2D ce suportă evenimente rutate, asociere de comenzi, layout și focus.

Visual3D – clasa de bază pentru toate obiectele ce au reprezentare vizuală 3D.

UIElement3D – clasa de bază pentru toate obiectele vizuale 3D ce suportă evenimente rutate, asociere de comenzi, focus.

ContentElement – O clasa de bază similară cu UIElement dar pentru părți de document ale conținutului ce nu au o redare proprie. ContentElement este găzduit într-o clasă derivată din Visual pentru a fi redată pe ecran.

FrameworkElement – clasa de bază ce adăugă suport pentru stiluri, dată binding, resurse și un mecanism pentru controalele windows cum ar fi tooltips și meniul contextual. FrameworkContentElement – analog cu FrameworkElement pentru conținut.

Control – clasa de bază pentru controalele obișnuite Button, ListBox și StatusBar. Adăugă proprietăți precum Foreground, Background și FontSize precum și abilitatea de a fi restilizate.

Descriere functionala a sistemului

PANA AICI

Use case diagram

O diagramă caz de utilizare în mai simplă este o reprezentare de interacțiune a utilizatorului cu sistemul care arată relația dintre utilizator și diferitele cazuri de utilizare în care utilizatorul este implicat. O diagrama cazurilor de utilizare pot identifica diferitele tipuri de utilizatori ai unui sistem, precum și diferite cazuri de utilizare și va fi adesea însoțite de alte tipuri de diagrame, de asemenea.

Structura DB

Diagrama de clase

Diagrama de clase prezintă din punct de vedere organizatoric al sistemului arătând clasele acestuia, metodele, atributele și relațiile dintre clase.

Cele mai importante elemente ale diagramei de clase sunt:

Clasa – este redată sub forma unui dreptunghi în interiorul căruia este scris numele clasei. Uneori în interiorul unei clase sunt reprezentate atributele și metodele folosite de către aceasta (doar semnătura).

Interfața – este redată sub forma unui dreptunghi în interiorul căruia este scris numele interfeței. Ca și alternativă o interfață poate fi reprezentată și în mod simplificat sub forma de cerc în dreptul căruia este scris numele interfeței. Interfața poate fi considerată un caz special de clasă.

Relația – este redată sub forma unei drepte orientate ce leagă cele două clase. O legătură de asociere dintre dintre două clase semnifică o relație de cooperare sau de asemănare între clasele conectate. Tipurile de conexiuni posibile între două clase sunt: agregare, compoziție, asociere, implementare și moștenire.

Diagramele de clase pot să fie folosite în mai multe stadii ale procesului de evoluție a aplicației pentru: definirea modelului abstract și prezentarea entităților importante ale sistemului, definirea proiectării arhitecturii sistemului la nivel detaliat.

Atributele sunt redate în interiorul claselor din care acestea fac parte și sunt scrise sub forma:specificator_de_acces nume: tip_returnat. Numele acestor atribute încep prin convenție cu literă mică.

Metodele pot fi redate de asemenea în interiorul claselor din care acestea fac parte și sunt scrise sub forma:specificator_de_acces nume_metoda (tip1:parametru1, tip2:parametru2, …, tipn parametrun): tip returnat. Numele acestor metode încep prin convenție cu literă mică.

Tipurile posibile de indicatori de acces sunt:

Public – și este redat în cadrul diagramelor prin caracterul „+”.

Private – și este redat în cadrul diagramelor prin caracterul „-”.

Protected – și este redat prin caracterul „#”.

Acces de pachet – și este redat în cadrul diagramelor prin caracterul „~”.

O diagramă de clase poate fi desenată pe mai multe nivele de granularitate a anumitor detalii, mergând de la o variantă mai schematică în care sunt redate doar numele claselor (fără detalii ce se referă la conținutul acestora) până la o variantă mai detaliată în care sunt redate toate atributele și metodele folosite indiferent de nivelul de acces al acestora. Una dintre cele mai folosite variante este acea în care sunt aratate doar metodele și \ sau atributele publice ale unei clase.

Relatia de asociere

Asocierea este cel mai slab model de interconectare între două clase. Între două clase se definește o astfel de legătură atunci când între acestea este un flux de mesaje sau de date.

O asociere se poate propaga în două direcții (caz în care asocierea este redată cu o dreaptă simplă) sau unidirecțională (caz în care asocierea este redată printr-o dreaptă orientată. O alăturare bidirecțională are un nume,la fiecare capăt al unei drepte ce o reprezintă având atașate următoarele elemente:

Un indicator pentru multiplicitate 

Un rol 

Pentru a defini indicatorului de multiplicitate UML sunt puse la dispoziție următoarele notații standard:

* – oricate obiecte

1…* – cel putin un obiect sau mai multe

1 – un obiect

n – exact n obiecte

a…b – cel putin a obiecte si maxim b obiecte

Diagrama de mai sus poate fi analizată astfel: Clasa Phone are cunoștință de starea clasei Button și obiectele de tipul Button vor juca funcția de phoneButtons în cadrul clasei Phone. Când clasa Phone va fi implementată aceasta va putea folosii un număr nedefinit de butoane (zero sau oricâte). Clasa Button are cunoștință de starea clasei Phone și aceasta va juca functia phone în cadrul clasei Button. Când un obiect asemanator tipului Button va fi implementat acesta va avea acces la fix un obiect de tipul Phone.

Observatie: O greșeală banală este aceea de adăugare a operatorului de multiplicitate la capătul greșit al acestei legăturii de asociere. Operatorul de multiplicitate trebuie adăugat în dreptul clasei al cărui entitate de obiecte sunt constrânse.

În cazul asocierii intr+o singură direcție doar una dintre clase are la cunoștință de starea celeilalte clase. Acest model de asociere este redat printr-o dreaptă orientată ce are capătul săgeții orientat către clasa cunoscută. În imaginea de mai jos este demonstrată o asociere unidirecțională.

Dacă starea unei asociații între două clase are nevoie de construirea unui alt obiect care să memoreze aceste informații suplimentare legate de acea asocierea, atunci aceasta se poate reda printr-o clasă asociată conform imaginii de mai sus.

Diagrama de mai sus poate fi ințelege astfel: atunci când sunt create obiectele Controler șiTrafficLight și va exista o legătură între ele, va fi creat și un obiect de tipul ControlAlgorithm.

Relatia de agregare simplă

Un alt caz de alăturare între clase este cel care definește legatura dintre întreg și parte componentă. Acest tip de legătură definește o relație mai strânsă între părțile implicate. Pentru a modela faptul că un întreg este compus din una sau mai multe componente limbajul UML pune le dispoziție asocierile de tip agregare simplă și asocierile de tip agregare de compoziție.

Diagrama de mai sus poate fi interpretată astfel: Obiectele de tip Whell și Engine sunt părți componentă a obiectului de tip Car. Ciclul de viață al obiectelor de tip parte nu este în mod obligatoriu același cu ciclul de viață al obiectului de tip Car (un obiect de tip Engine poate fi creat înaintea obiectului de tip Car și poate fi atașat ulterior la acesta, mai mult decât atât, distrugerea obiectului de tip Car nu înseamnă în mod implicit ca va determina și distrugerea obiectului de tip Engine ).

Relatia de compozitie

Agregarea de compoziție denotă tot o relație de tip întreg-parte dar care este mult mai strânsă. Ciclul de viață al părților este strâns legat de ciclul de viață al întregului, mai mult de cât atât, întregul este responsabil pentru crearea obiectelor de tip parte. Distrugerea întregului determină și distrugerea părților. În figura de mai jos este exemplificată o diagramă de compoziție.

Relatia de extindere

Relația de moștenire este reprezentată în cadrul UML printr-o săgeată orientată către clasa de bază (clasa moștenită).

Relatia de implementare a unei interfete

Pentru a reprezenta relația de implementare a unei interfețe de către o clasă limbajul UML pune la dispoziție două notații ce sunt prezentate în figura de mai jos.

Atat in diagrama din stanga cat si in diagrama din dreapta este exemplificata relatia de implementare a unei interfete.

In diagrama din stanga interfata este reprezentata schematic (doar numele clasei).

In diagrama din dreapta interfata este reprezentata in mod similar cu o clasa obisnuita avand incluse metodele declarate de interfata.

Recomandari privind construirea diagramelor de clase

Înainte de a începe construirea efectivă a diagramelor trebuiesc identificate principalele clase ale sistemului, responsabilitățile acestora precum și colaboratorii.

Numele claselor trebuie să fie cât mai explicite și să reflecte cât mai aproape rolul clasei în cadrul sistemului.

Construirea diagramelor de clase pentru un sistem este un proces iterativ și acestea pot fi modificate pe măsură ce sistemul este construit.

Trebuie folosite convențiile de nume pentru clase, atribute și metode corespunzătoare limbajului în care sistemul va fi implementat.

MVC cum folosesc

Structura unei aplicatii folosind arhitectura MVC

Acest tutorial va prezenta structura ce o folosesc personal pentru a organiza in format MVC un nou framework. Aceasta serie de articole se va invarti in jurul acestei structuri.

• application->aplicatie1->controller->model->view->aplicatie2->aplicatie3
• config
• db
• librari-> cache->controller->model->dbs->view->templates
• public->aplicatie1->css->img-> js->swf->aplicatie2->aplicatie3
• tmp->cache->logs->sessions

Definirea unui singur punct accesibil din partea clientului

Prima problema ce o intalnim este stabilirea unui singur punct de intrare, un index.php care va avea grija de tot si toate. Pentru a usura acest proces ne vom folosi de URL redirecting si permalinks, care sunt evident configurate din .htaccess.

Mai intai adaugam un fisier .htaccess in root-ul arhitecturii cu urmatorul cod. Acesta va redirecta totul catre folderul /public al aceleiasi arhitecturi.

?

;
Urmeaza sa cream un nou fisier .htaccess in directorul /public.

?

Fisierul public/index.php

Aceasta pagina va avea declarate cateva constante si va incarca bootstrap-ul.

?

Fisierul library/basics.php

Acest fisier contine, dupa cum spune si numele, cateva functii de baza, de care ne vom izbi pe tot parcursul procesului de dezvoltare al arhitecturii. Functia setReporting() stabileste daca suntem in timpul dezvoltarii si trateaza variabile pe ecran, in vreme ce in afara starii de developer, erorile vor fi stocate pe disc. Functia killMagicQuotes() va cauta magic quotes si le va elimina, unregisterGlobals() va elimina variabilele globale, __autoload() este una din functiile magice ce se bazeaza pe overloading ce va face putina magie : va incarca toate fisierele necesare pentru clase. Functia clear este functia care se va apela recursiv curatand un vector de orice dimensiune/adancime prin htmlentities.

?

Fisierul library/bootstrap.php

In acest fisier vom incarca cateva din cele mai importante fisiere. Vom apela functiile din basics.php prezentate anterior pentru a curata variabilele si a filtra putin informatiile. Acest fisier va incarca una din clasele cele mai importante : dispatcherul, sau cel care spune cine sa faca ce. Dispatcherul functioneaza in urmatorul mod : www.worldit.info/controller/actiune/query. Pentru a intelege mai exact cum functioneaza dispatcherul ne vom imagina ca avem urmatorul link :
• www.worldit.info/news/show/id/1

Controllerul e news
Modelul este new
Viewul este este show
Actiunea este show
Query-ul este un array (id,1)

?

Fisierul library/paths.php

Acest fisier contine cateva constante ce ne vor ajuta pe parcurs la utilizarea eficienta a cailor relative si absolute ale fisierelor framework-ului.

?

Clasa Object – baza controalelor (library/controller/object.php)

Aceasta clasa este putin mai dezvoltata decat o clasa abstracta, prezentand cateva din functiile de baza necesare in toate clasele noastre ulterioare. Prezinta functiile __construct(), __destruct(), __toString() si log(), create special doar pentru overloading ulterior in clasele copii. Functia _set() este utila pentru a seta variabile dinamic iar dispatchMethod() apeleaza o functie din interiorul obiectului, fiind o optimizare smechera pentru imbunatatirea performantelor.

?

Clasa Dispatcher – managerul MVC (library/dispatcher.php)

Aceasta clasa, dupa cum spuneam si mai sus, reprezinta unul din creierii principali, o parte foarte importanta ce dirijeaza toate creierasele mai mici (controllerele). Functia dispatch() proceseaza prin intermediul unor functii auxiliare (_extractParams(),_parseUrl(),_restructureParams(),_getController()) parametri oferiti de utilizator prin intermediul URI si incarca controllerul de care avem nevoie, la actiunea ceruta cu parametrii (query) oferiti. De aceasta parte a procesului se ocupa functia _invoke().

?

Cam atat pentru prima parte care deja s-a intins foarte mult. Pana in acest moment am reusit sa introducem o parte din partile componente principale ale unui framework ce foloseste o structura de lucru MVC. In cea de-a doua parte a articolului voi introduce partile componente principale : Model View Controller. Daca ati digerat acest articol si nu aveti rabdare pana voi termina urmatoarea parte, puteti arunca o privire pe intregul framework, care poate fi inteles daca urmariti documentatia scrisa de mine pentru aproape toate functiile. Framework-ul din aceasta arhiva prezinta toate caracteristicile de baza de care are nevoie unul cu exceptia debuggerului.

Detalii de implementare

Sabloane de proiectare

Șabloane pentru proiectare (Design Patterns)

1. Introducere

Proiectarea orientată pe obiecte a software-ului presupune identificarea de obiecte, abstractizarea lor în clase de granularitate potrivită, definirea interfețelor și ierarhiilor de moștenire, stabilirea relațiilor între aceste clase.

Soluția trebuie să rezolve problema și să fie în același timp suficient de flexibilă pentru a rezista la noi cerințe și probleme ce pot apare în timp.

Proiectanții cu experiență refolosesc soluțiile bune de câte ori au ocazia. Există grupări de clase sau obiecte care se repetă în cele mai diferite sisteme. Acestea rezolvă probleme specifice, folosirea lor fac proiectele mai flexibile, mai elegante, reutilizabile. Un proiectant care stăpânește un set de asemenea șabloane le poate aplica imediat la noile proiecte fără a mai fi nevoit să le redescopere.

Șabloanele ce se pot refolosi pot fi general valabile sau specifice unui domeniu, de exemplu pentru probleme de concurență, sisteme distribuite, programare în timp real, etc.

2. Clasificare

Șabloanele utilizate în sistemele OO pot fi clasificate într-o ierarhie după cum urmează:

Idiomuri

Mecanisme

Cadre (frameworks).

Un idiom este legat de un anumit limbaj de programare și reprezintă o convenție general acceptată de utilizare a limbajului respectiv.
Exemple tipice de idiomuri pot fi găsite în cadrul limbajelor C/C++. Returnarea unei valori întregi care să semnifice succesul sau eșecul unei funcții este un idiom din C (adoptat și de C++, pe langă generarea excepțiilor). Importanța acestui idiom constă în faptul că el reprezintă un anumit stil acceptat de comunitatea utilizatorilor de C și orice programator care citește o secvență C recunoaște imediat această convenție. Încălcarea acestui idiom are drept consecință producerea de cod greu de înțeles, chiar dacă este corect. Practic fiecare limbaj de programare își are propriile sale idiomuri. La fel și o echipă de programatori își poate stabili un set de obiceiuri, în funcție de experiența și cultura pe care le posedă.

Se poate spune că un idiom este o formă de reutilizare pe scară mică.

Un mecanism este o structură în cadrul căruia obiectele colaborează în vederea obținerii unui anumit comportament ce satisface o anumită cerință a problemei. Mecanismele reprezintă decizii de proiectare privind modul în care cooperează colecțiile de obiecte. Ele se mai numesc și sabloane de proiectare (design patterns).
Majoritatea sistemelor OO includ mecanisme referitoare la:

persistența obiectelor

controlul stocării

controlul proceselor

transmisia/recepția mesajelor

distribuirea și migrarea obiectelor

conectarea în rețele (networking)

tranzacții

evenimente

modul de prezentare ("look & feel") al aplicației.

Un cadru reprezintă o colecție de clase care oferă un set de servicii pentru un domeniu particular. Cadrul exportă un număr de clase și mecanisme pe care utilizatorii le pot adapta.

Cadrele sunt forme de reutilizare pe scară largă.

Cele mai răspândite tipuri de cadre sunt cele destinate creării de interfețe grafice.
 

3. Definiție

Un sablon reprezintă o soluție comună a unei probleme într-un anumit context.

Importanța șabloanelor (standardelor) în construirea sistemelor complexe a fost de mult recunoscută în alte discipline. În cadrul comunității proiectanților de software OO (orientate pe obiecte) ideea de a aplica șabloane se pare că a fost inspirată de propunerea unui arhitect, Christopher Alexander, care a lansat inițiativa folosirii unui limbaj bazat pe sabloane pentru proiectarea clădirilor și a oraselor. Acesta afirma că: "Fiecare șablon descrie o problemă care apare mereu în domeniul nostru de activitate și indică esența soluției acelei probleme într-un mod care permite utilizarea soluției de nenumărate ori în contexte diferite".
Deși în domeniul sistemelor OO soluțiile sunt exprimate în termeni de obiecte și interfețe (în loc de ziduri, uși, grinzi etc), esența noțiunii de sablon este aceeași, adică de soluție a unei probleme într-un context dat.

Șabloanele de proiectare sunt o memorare pentru posteritate a experienței în domeniul proiectării sistemelor OO.

Un șablon este descris de patru elemente:

Nume: folosește pentru identificare; descrie sintetic problema rezolvată de șablon și soluția.

Problema: descrie când se aplică șablonul; se descrie problema și contextul.

Solutia: descrie elementele care intră în rezolvare, relațiile între ele, responsabilitățile lor și colaborările între ele.

Consecințe si compromisuri: implicațiile folosirii șablonului, costuri și beneficii. Acestea pot privi impactul asupra flexibilității, extensibilității sau portabilității sistemului, după cum pot să se refere la aspecte ale implementării sau limbajului de programare utilizat. Compromisurile sunt de cele mai multe ori legate de spațiu și timp.

4. Organizarea unui catalog de șabloane

Șabloanele sunt la diferite niveluri de abstractizare, au granularități diferite.

Deoarece există multe șabloane de proiectare este necesară o anumită clasificare a lor în vederea alcătuirii unui catalog.

Criterii de clasificare:

Scop – șabloanele pot fi creaționale, structurale sau comportamentale.

Șabloanele creaționale (creational patterns) privesc modul de creare al obiectelor.

Șabloanele structurale (structural patterns) se referă la compoziția claselor sau al obiectelor.

Șabloanele comportamentale (behavioral patterns) caracterizează modul în care obiectele și clasele interacționează și își distribuie responsabilitățile.

Domeniu de aplicare – șabloanele se pot aplica obiectelor sau claselor.

Șabloanele claselor se referă la relații dintre clase, relații stabilite prin moștenire și care sunt statice (fixate la compilare).

Șabloanele creaționale ale claselor acoperă situațiile în care o parte din procesul creării unui obiect cade în sarcina subclaselor.

Șabloanele structurale ale claselor descriu modul de utilizare a moștenirii în scopul compunerii claselor.

Șabloanele comportamentale ale claselor utilizează moștenirea pentru descrierea unor algoritmi și fluxuri de control.

Șabloanele obiectelor se referă la relațiile dintre obiecte, relații care au un caracter dinamic.

Șabloanele creaționale ale obiectelor acoperă situațiile în care o parte din procesul creării unui obiect cade în sarcina unui alt obiect.

Șabloanele structurale ale obiectelor descriu căile prin care se asamblează obiecte.

Șabloanele comportamentale ale obiectelor descriu modul în care un grup de obiecte cooperează pentru a îndeplini o sarcină ce nu ar putea fi efectuată de un singur obiect.

În tabelul de mai jos sunt incluse cele mai importante șabloane, clasificate după criteriile enumerate anterior:
 

5. Rolul șabloanele de proiectare în rezolvarea problemele de proiectare

Șabloanele de proiectare rezolvă multe din problemele cu care se confruntă proiectanții. Câteva din aceste probleme sunt urmatoarele:

5.1 Găsirea obiectelor adecvate

Un obiect, care intră în alcătuirea programelor OO, împachetează atât date, cât și metode (operații) ce operează asupra datelor. Obiectul execută o operație când primește o cerere (mesaj) de la un client.

Mesajele reprezintă singura cale prin care un obiect este determinat să execute o operație, în timp ce operațiile sunt singurul mod de a modifica datele interne ale obiectului. Din cauza acestor restricții starea internă a obiectului se spune că este încapsulată: ea nu poate fi accesată direct, iar reprezentarea ei este invizibilă dinspre exteriorul obiectului.

Partea dificilă în proiectarea unui sistem OO este descompunerea sistemului în obiecte. Aceasta deoarece procesul este influențat de mai mulți factori care acționează adesea în mod contradictoriu: încapsularea, granularitatea, dependențele, flexibilitatea, performanțele, evoluția, gradul de reutilizare etc.

Există mai multe metodologii OO: unele se concentrează pe substantivele și verbele extrase din enunțul problemei, altele se concentrează pe colaborările și responsabilitățile din sistem sau se modelează lumea reală și obiectele găsite la analiză se translatează și în proiectare.

Multe din obiectele care apar la proiectare provin din modelul creat în faza de analiză. La proiect se vor adauga însă și clase care nu au corespondență în lumea reală. Unele din aceste clase sunt de nivel primar (de exemplu tablourile), altele au un nivel de abstractizare mai ridicat. De exemplu sablonul Composition introduce o abstracție menită să asigure tratarea uniformă a obiectelor care nu au un corespondent fizic. Modelarea strictă a lumii reale va duce la un sistem ce reflectă realitatea curentă, dar nu neapărat și pe cea viitoare. Abstracțiunile identificate în timpul proiectării sunt esențiale în obținerea unui sistem flexibil.

Șabloanele ne pot ajuta în identificarea unor abstracțiuni mai puțin evidente și a obiectelor care le pot reprezenta. De exemplu obiectele care reprezintă procese sau algoritmi nu apar în natură, dar ele nu pot lipsi dintr-un proiect. Șablonul Strategy descrie modul de implementare a unor familii interschimbabile de algoritmi. Șablonul State reprezintă fiecare stare a unei entități sub forma unui obiect. Asemenea obiecte sunt rareori descoperite în timpul analizei sau chiar a stadiului incipient al proiectării.

5.2 Determinarea granularității obiectelor

Obiectele ce compun un sistem pot varia enorm ca mărime și ca număr. Ele pot reprezenta practic orice începând de la componente hardware până la aplicații întregi. Cum decidem ce ar trebui sa fie un obiect?

Există șabloane care acoperă și acest aspect. Astfel, șablonul Facade descrie modul în care subsisteme complete pot fi reprezentate ca obiecte, șablonul Flyweight arată cum se poate gestiona un număr uriaș de obiecte la nivelurile cele mai fine de granularitate. Alte șabloane descriu căile prin care un obiect poate fi descompus în obiecte mai mici. Abstract Factory și Builder reprezintă obiecte a căror unică responsabilitate este crearea de alte obiecte. Visitor și Command reprezintă obiecte a căror unică responsabilitate este implementarea unui mesaj către alt obiect sau grup de obiecte.

5.3 Specificarea interfețelor obiectelor

Pentru fiecare operație declarată într-un obiect se precizează numele, obiectele pe care le ia ca parametrii și valoarea returnată; aceste elemente formează semnătura operației. Mulțimea tuturor semnăturilor corespunzătoare operațiilor dintr-un obiect reprezintă interfața obiectului. Interfața unui obiect descrie complet setul mesajelor care pot fi trimise spre obiectul respectiv.

Un tip este un nume utilizat pentru a referi o anumită interfață. Astfel, vom spune despre un obiect că este de tipul Window dacă el acceptă toate mesajele corespunzătoare operațiilor definite în interfața numită Window. Ca urmare, un obiect poate avea mai multe tipuri, adică o parte a interfeței sale poate fi de un tip, iar altă parte de alt tip. De asemenea, mai multe obiecte pot partaja un anumit tip comun, daca interfețele lor includ tipul respectiv. Interfețele pot să conțină, la rândul lor, alte interfețe ca submulțimi. Având două tipuri, T1 și T2, vom spune că T1 este subtip al lui T2 dacă interfața T1 include interfața T2. În acest caz T2 este supertip al lui T1. Mai spunem ca T1 moștenește interfața T2.

Interfețele sunt lucruri fundamentale în sistemele OO. Obiectele sunt cunoscute doar prin intermediul interfetelor lor. O interfață nu dă nici un detaliu relativ la implementarea unui obiect, iar obiecte distincte pot implementa în mod diferit o aceeasi cerere. Altfel spus, două obiecte având implementări complet diferite pot avea interfețe identice.

Când o cerere este trimisă unui obiect, operația care se va executa depinde de:

cerere

obiectul care receptionează cererea.

Obiecte diferite care pot recepționa cereri identice pot avea implementări diferite ale operațiilor ce vor satisface cererile respective. Asocierea unei cereri cu un obiect și cu o operație a obiectului la momentul execuției se numește asociere (legare) dinamică (dynamic binding). Asocierea dinamică permite scrierea de programe în care:

la emiterea unei cereri să nu ne preocupe ce obiect o va recepționa, știindu-se că orice obiect a cărui interfață include o semnătura potrivită va fi bun;

obiecte având interfețe identice pot fi substituite unul altuia la executie; această posibilitate de substituire se mai numește polimorfism.

Polimorfismul este un concept esențial în cadrul tehnologiei orientate pe obiecte. El permite:

ca un obiect client să nu aibă nevoie să cunoască altceva despre alte obiecte decât că posedă o anumită interfață;

simplificarea definiției clienților;

decuplarea obiectelor unele de altele;

ca la execuție obiectele să-și modifice relațiile dintre ele.

În acest context, șabloanele de proiectare ne ajută la:

definirea interfețelor;

identificarea elementelor care NU trebuie să apară într-o interfață.

Astfel, șablonul Memento descrie modul de încapsulare și salvare a stării interne a unui obiect pentru ca starea respectivă să poată fi restaurată ulterior. Șabloanele specifică de asemenea și relații între interfețe.

5.4 Specificarea implementării obiectelor

Implementarea unui obiect este definită prin intermediul clasei obiectului. Clasa unui obiect specifică datele interne ale obiectului și definițiile operațiilor pe care acesta le poate executa.
Obiectele sunt create prin instanțierea unei clase; se mai spune că un obiect este o instanță a unei clase. Procesul de instanțiere a unei clase presupune alocarea de memorie pentru datele interne ale obiectului respectiv și asocierea operațiilor cu aceste date. O clasă poate fi instanțiată de mai multe ori, în felul acesta rezultând mai multe exemplare similare de obiecte.

Pe baza unor clase existente se pot defini noi clase, folosind moștenirea claselor. O subclasă moștenește de la una sau mai multe clase părinte (superclase) toate datele și operațiile definite în acestea din urmă. Obiectele instanțe ale subclasei vor

conține toate datele definite în subclasa și în clasele părinte

putea executa toate operațiile definite în subclasa și în clasele părinte.

O clasă abstractă are drept scop principal definirea unei interfețe comune pentru subclasele sale. Implementarea operațiilor unei clase abstracte este pasată parțial sau în întregime subclaselor sale. De aceea, o clasă abstractă nu poate fi instanțiată. Operațiile declarate într-o clasă abstractă, dar neimplementate se numesc operații abstracte. Clasele care nu sunt abstracte se numesc clase concrete.

O subclasă poate detalia sau redefini comportamentul claselor părinte. Mai precis, subclasa poate redefini (override) o operație care apare și într-o clasă părinte, ceea ce permite subclasei să poată prelua cereri în locul superclasei.

O clasa mixin este o clasă care are drept scop oferirea unei interfețe sau a unei funcționalități opționale altor clase. Ea este similară unei clase abstracte, în sensul că nu poate fi instanțiată, dar nu poate figura singură ca părinte al unor subclase, ci doar într-o schemă de moștenire multiplă.

5.4.1 Moștenirea claselor și moștenirea interfețelor

Este important să ințelegem diferența între clasa unui obiect și tipul obiectului.
Clasa definește starea internă a obiectului și implementarea operațiilor lui. Tipul obiectului se referă doar la interfața obiectului – setul cererilor la care obiectul poate răspunde. Un obiect poate avea mai multe tipuri, iar obiecte de clase diferite pot avea același tip.

Desigur că între clasă și tip există o strânsă legătura: prin faptul că o clasă definește operațiile pe care un obiect le poate executa, automat ea definește și tipul obiectului. Când spunem că un obiect este instanță a unei clase, aceasta înseamnă că obiectul posedă interfața definită de clasa respectivă.

Un limbaj ca C++ folosește clasele pentru a specifica tipul obiectului și implementarea.

Este de asemenea important să ințelegem diferența dintre moștenirea de clasă și moștenirea de interfață (subtipizare). Moștenirea de clasă presupune că implementarea unui obiect este definită în termenii implementării altui obiect. Cu alte cuvinte, ea reprezintă un mecanism de reutilizare (partajare) a reprezentării și a codului. Moștenirea de interfață (subtyping) este un mecanism prin care un obiect poate fi utilizat în locul altuia.

Este destul de ușor de confundat aceste concepte între ele deoarece majoritatea limbajelor de programare OO nu le disting în mod explicit. De exemplu în C++ moștenire înseamnă atât moștenire de clasă, cât și de interfață. O diferențiere între cele două s-ar putea face astfel:

moștenirea de interfață poate fi redată ca o derivare publică a unei clase abstracte (o clasă care conține funcții-membru pur virtuale);

moștenirea de clasă poate fi modelată prin derivarea privată a unei clase.

Multe dintre șabloanele de proiectare se bazează pe această distincție. De exemplu obiectele dintr-un Chain of Responsibility trebuie să aibă un tip comun, fără însă a avea și implementarea comună. În cadrul șablonului Composite, Component definește o interfață comună, în timp ce Composite definește o implementare comună. Șabloanele Command, Observer, State și Strategy sunt adesea implementate cu ajutorul claselor abstracte.
 

5.4.2 Programarea prin interfețe și nu prin implementări

Moștenirea de clasă este în esență un mecanism care permite:

extinderea funcționalității unei aplicații prin reutilizarea funcționalității din clasele părinte;

definirea rapidă a unui nou fel de obiect, în termenii unuia deja existent;

obținerea unor noi implementări aproape fără efort, prin preluarea unei mari părți din ceea ce avem nevoie de la clase existente.

Reutilizarea implementării reprezintă doar o fațetă a conceptului de moștenire. Posibilitatea de a defini familii de obiecte cu interfețe identice (de obicei prin moștenirea de la o clasă abstractă) este un alt aspect important, deoarece polimorfismul depinde de el.

Clasele derivate dintr-o clasă abstractă vor partaja interfața acelei clase. Subclasele vor adăuga sau vor redefini operații, dar nu vor ascunde operații ale clasei părinte. În felul acesta toate subclasele vor putea răspunde la cererile corespunzătoare interfeței clasei abstracte părinte.
Există doua avantaje ale manipulării obiectelor prin intermediul interfețelor definite în clasele abstracte:

clienții nu trebuie să știe tipurile particulare ale obiectelor utilizate, atâta timp cât obiectele respective sunt compatibile cu interfața pe care clienții o așteaptă;

clienții nu trebuie să știe care sunt clasele care implementează obiectele respective, știu doar despre clasele abstracte care definesc interfața.

Toate acestea reduc substanțial dependențele dintre subsisteme, permitând formularea următorului principiu al proiectării OO:
 

Nu declara variabile ca fiind instanțe ale unor clase concrete, mai degrabă angajează-te să folosești o interfață definită printr-o clasă abstractă. Când este necesară instanțierea unor clase concrete, se recomandă aplicarea șabloanelor creaționale (Abstract Factory, Builder, Factory Method, Prototype, Singleton) care permit abstractizarea procesului de creare a obiectelor. În felul acesta se realizează o asociere a unei interfețe cu implementările ei transparent la momentul instanțierii.

5.5 Mecanisme ale reutilizării

Problema este cum obținem un software flexibil și reutilizabil folosind concepte ca obiect, clasă, interfață, moștenire. Șabloanele constituie un răspuns.

Moștenirea și compunerea obiectelor

Cele mai cunoscute tehnici de reutilizare a funcționalității în cadrul sistemelor OO sunt moștenirea de clasă și asamblarea sau compunerea obiectelor (object composition).

Moștenirea de clasă este cunoscută și sub numele de reutilizare tip cutie albă (white-box reuse) deoarece în majoritatea cazurilor o parte din starea internă a claselor părinte este vizibilă în subclase.

Asamblarea obiectelor reprezintă o tehnică de obținere a unei funcționalități noi prin asamblarea sau compunerea unor obiecte având interfețe bine definite. Tehnica este cunoscută sub numele de reutilizare tip cutie neagră (black-box reuse) deoarece obiectele care se asamblează nu își cunosc unul altuia starea internă, ele apar unul față de altul ca niște cutii negre.

Ambele tehnici au avantaje și dezavantaje. Moștenirea de clasă se caracterizează prin următoarele (avantaje):

este definită static la compilare și poate fi specificată direct, fiind suportată explicit de limbajele de programare;

permite modificarea ușoară a implementării operațiilor reutilizate, și anume într-o subclasă ce redefinește o parte din operațiile clasei părinte pot fi afectate și operații moștenite dacă acestea apelează operații redefinite. În secvența C++ de mai jos este ilustrată sintetic această situație:

Dezavantaje:

implementarea moștenită de la clasele părinte nu poate fi modificată în momentul execuției;

cel mai adesea clasele părinte definesc cel puțin parțial reprezentarea fizică a subclaselor lor, deci subclasele au acces la detalii ale implementării superclaselor. De aceea se mai spune că moștenirea de clasă încalcă principiile încapsulării;

modificările aduse implementării unei superclase vor forța subclasele să se modifice și ele. Dependențele de implementare pot cauza probleme atunci când se încearcă reutilizarea subclaselor: dacă anumite aspecte ale implementării moștenite nu corespund necesităților aplicației clasa părinte trebuie rescrisă sau înlocuită. Această dependență limitează flexibilitatea și, în ultimă instanță reutilizarea. O soluție în acest caz ar fi aplicarea moștenirii de la clase abstracte, deoarece ele includ implementare în mică măsură.

Compunerea obiectelor se caracterizează prin:

se defineste în mod dinamic, la execuție, prin faptul că anumite obiecte primesc referințe ale altor obiecte;

necesită ca obiectele să-și respecte unul altuia interfața, ceea ce presupune că interfețele să fie proiectate astfel încât să nu împiedice utilizarea unui obiect în combinație cu mai multe tipuri de obiecte. Deoarece obiectele sunt accesate doar prin intermediul interfețelor nu este încălcat principiul încapsulării. În decursul execuției orice obiect poate fi înlocuit cu altul, atâta timp cât obiectele respective au același tip. În plus, datorită faptului că și implementarea unui obiect este scrisă tot în termenii interfețelor altor obiecte, dependențele de implementare vor fi substanțial reduse;

prin compunerea obiectelor se obține urmatorul efect asupra unui proiect: clasele sunt încapsulate și focalizate asupra câte unui singur obiectiv, ceea ce face ca ele, ca și ierarhiile lor, să aibă dimensiuni mici și să fie mai ușor de gestionat. Un proiect bazat pe compunerea obiectelor se caracterizează printr-un număr mai mare de obiecte și un număr mai mic de clase, iar comportarea sistemului va depinde de relațiile dintre obiecte, în loc să fie definită într-o clasă.

Toate aceste aspecte conduc spre formularea celui de-al doilea principiu al proiectării OO:
 

În mod ideal nu ar trebui create noi componente pentru a realiza reutilizarea. Pentru obținerea funcționalității dorite trebuie doar asamblate componentele prin intermediul compoziției obiectelor existente. În practică însă aceasta nu se poate realiza în totalitate deoarece setul de componente disponibile nu este niciodată destul de bogat. Reutilizarea prin moștenire este mai ușor de folosit pentru a face componente noi în comparație cu compunerea componentelor deja existente. De aceea moștenirea și compunerea obiectelor sunt folosite împreună.

Experiența arată că adesea proiectanții folosesc moștenirea în mod abuziv. De aceea se recomandă studiul și aplicarea șabloanelor de proiectare, acestea bazându-se foarte mult pe compunerea obiectelor.

 

Delegarea

Reprezintă o cale de aplicare a principiului compunerii obiectelor. Într-o relație de delegare două obiecte sunt implicate în rezolvarea unei cereri, și anume: obiectul care receptează mesajul – delegatorul – deleagă execuția operației corespunzătoare unui alt obiect – delegat. Acest lucru este oarecum similar cu situația în care subclasele pasează sarcina execuției unor operații claselor părinte (este vorba despre operațiile moștenite și neredefinite). Dar, în timp ce clasa părinte a unei subclase rămâne aceeași pe toată durata execuției, în cazul delegării obiectele delegat pot fi schimbate, cu condiția să aibă aceeași interfață.

Delegarea este considerată ca un șablon de proiectare fundamental, pe ea bazându-se foarte multe din celelalte șabloane (de exemplu State, Visitor, Strategy, Mediator, Chain of Responsibility, Bridge).

Principalul avantaj al delegării este că face posibil foarte ușor să se compună comportari în timpul execuției, inclusiv să se schimbe dinamic această compunere.

Dezavantajul, pe care îl au și alte tehnici ce fac software-ul flexibil, este că software-ul dinamic, parametrizat, este mai greu de înțeles decât software-ul static. În plus există și penalități în timpul execuției.

Moștenirea și tipurile parametrizate

Tipurile parametrizate reprezintă o altă tehnică de reutilizare a funcționalității care nu este strict legată de modelul orientat pe obiecte. Ele permit definirea de către utilizatori a unui tip nou fără a specifica tipurile pe care acesta le folosește. Aceste tipuri se vor furniza ca și parametrii unde se folosește acest tip parametrizat. De exemplu un tip Lista poate fi parametrizat prin tipul elementelor conținute. Acesta poate fi întreg, șir de caractere, etc.

Printre limbajele care suportă această tehnică se numără Ada, Eiffel (prin tipurile generice) și C++ (prin template-uri).

Tipurile parametrizate ne oferă a treia cale pentru a compune comportarea în sistemele OO. Există diferențe importante între aceste trei tehnici:

compunerea obiectelor permite modificarea în timpul execuției a comportamentului, dar presupune indirectare și, ca urmare, poate fi mai puțin eficientă;

moștenirea oferă posibilitatea de a utiliza implementări deja existente ale unor operații, dar și de a redefini în subclase operațiile respective;

tipurile parametrizate permit modificarea tipurilor pe care o clasă le utilizează, dar, la fel ca și moștenirea, sunt precizate la compilare și nu mai pot fi modificate la execuție.

5.6 Structuri stabilite la compilare și structuri create la execuție

Structura unui program OO aflat în execuție amintește foarte puțin cu structura codului. Acesta din urmă este înghețat în momentul compilării și constă dintr-un ansamblu de clase aflate în relații fixe de moștenire. Structura la execuție constă dintr-o rețea de obiecte aflate în continuă schimbare și comunicare. De fapt cele două tipuri de structuri sunt aproape independente intre ele.

Exemplificăm pe deosebirea dintre relațiile de agregare și asociere (sau cunoaștere – acquaintance) și cum se manifestă acestea în timpul compilării și execuției. Agregarea presupune ca un anumit obiect posedă sau este responsabil față de un alt obiect. În general spunem despre un obiect că are sau este parte dintr-un alt obiect. Agregarea implică faptul că un obiect agregat și proprietarul lui au durata de viață comună.

Asocierea, numită și relație de utilizare (de tip "using"), presupune că un obiect pur și simplu știe de existența altui obiect. Cele două obiecte asociate pot cere operații unul altuia dar nu sunt responsabili unul față de altul. Asocierea este o relație mai slabă decât agregarea și sugerează o cuplare mai slabă între obiecte.

Cele două tipuri de relații pot fi ușor confundate din cauză că pot fi implementate în mod asemănător. În C++ agregarea se poate implementa prin definirea de membrii variabilă ce sunt instanțe adevărate dar este mai folosită practica să o definim prin pointeri sau referințe la instanțe. Asocierea este implementată și ea prin pointeri și referințe.

De fapt agregarea și asocierea sunt determinate mai mult de intenția proiectantului decât de mecanismele din limbaj. Distincția între ele este dificil de observat în codul sursă. Agregările apar în număr mai mic, dar au un caracter mai stabil în timp. Asocierile se fac și se refac mai frecvent, uneori stabilindu-se doar pe durata unei operații. Asocierile au un caracter mai dinamic, ceea ce le face greu de depistat în codul sursă.

Multe dintre șabloanele de proiectare, mai ales cele care au domeniul de aplicare la nivel de obiect, captează distincția dintre structurile stabilite la compilare și cele de la execuție, în sensul că un specialist care cunoaște șabloanele de proiectare poate detecta mai ușor în codul sursă structurile ce se vor crea la execuție.

Interconectarea/ Comunicarea dintre technologii

https://www.google.ro/?gws_rd=cr,ssl&ei=9QB-VdLED6v8ygPqmKfQCw#q=wiki+windows+azure

https://en.wikipedia.org/wiki/Microsoft_Azure

https://en.wikipedia.org/wiki/Microsoft_Azure#SQL_Database

https://en.wikipedia.org/wiki/Active_Server_Pages

http://www.cs.ubbcluj.ro/~vcioban/Bistrita/Manuale/CursDotNetSassu.pdf am modificat la C#

https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

https://ro.wikipedia.org/wiki/Windows_Communication_Foundation

http://thor.info.uaic.ro/~iasimin/Special/WPF_C1_2012.pdf

https://en.wikipedia.org/wiki/Use_Case_Diagram

https://en.wikipedia.org/wiki/Class_diagram

http://www.microsoft.com/romania/educatie/curs_dot_net/profesori/default.aspx .Net