ACADEMIA DE STUDII ECONOMICE BUCUREŞTI

FACULTATEA DE CIBERNETICĂ, STATISTICĂ ŞI INFORMATICĂ ECONOMICĂ

P RO I E C TA R E A S I S T E M E LO R
I N F O R M AT I C E

-CURS 9-

BUCUREȘTI
Etapa de
proiectare a – partea I -
sistemelor
informatice
ETAPA DE PROIECTARE
Ordine
• Este a treia etapă din ciclul de dezvoltare.
• Este precedată de etapa de analiză.

Obiective
• Să creeze o arhitectură generală care satisface cerințele
sistemului.
• Să transpună designul logic din analiză într-o structură fizică.
• Arhitectura sistemului include: hardware, software, suport pentru
rețea, metode de procesare și securitate.

Produs final
• Rezultatul etapei constă în specificația de proiectare a sistemului.
• Ne concentrăm pe: arhitectura sistemului, interfața cu utilizatorul,
procedurile de intrare/ieșire și proiectarea datelor persistente.

Dependențe
• Modul cum proiectăm sistemul va depinde de decizia de a alege o
strategie de dezvoltare bazată pe achiziție sau pe construcție.
• Interdependența componentelor sistemului face ca proiectarea să
nu poată fi descrisă printr-o serie de pași clar definiți.
SCOPUL PROIECTĂRII

SISTEM EFICIENT
- Acceptă cerințele organizației pentru care este construit.
- Satisface nevoile utilizatorilor.

SISTEM FIABIL
- Tratează erorile de intrare, de procesare, defecțiunile
hardware sau greșelile umane.
- Un design bun anticipează erorile și ușurează corectarea lor.
- Sistemul este disponibil aproape tot timpul și menține copii
de rezervă adecvate.

SISTEM CARE POATE FI ÎNTREȚINUT

- Sistemul poate fi întreținut dacă este flexibil, scalabil și ușor
de modificat.
- Deseori sunt necesare schimbări pentru: a corecta probleme,
a se adapta la noi cerințe sau a folosi noile tehnologii.
FACTORI CARE INFLUENȚEAZĂ ALEGEREA
ARHITECTURII

Organizarea și cultura corporativă

Planificarea resurselor

Costul inițial și total al proprietății (TCO)

Scalabilitate

Integrare web

Cerințe de integrare cu sistemele moștenite

Probleme de securitate

Opțiuni de procesare
FACTORI DE INFLUENȚĂ-1

Organizarea și cultura corporativă

• Sistemul trebuie să funcționeze bine în cadrul unei organizații.
• Automatizarea a permis descentralizarea, colaborarea și
distribuirea geografică a activităților.
• Există variate modele de descentralizare și control.
• Filialele pot fi nevoite să implementeze soluții și tehnologii
informatice care să permită integrarea și monitorizarea.

Planificarea resurselor
• Sunt frecvent folosite soluțiile software de tip ERP.
• Se dorește o strategie unitară privind utilizarea TIC.
• ERP permite conectivitatea și integrarea facilă a sistemelor viitoare.
• ERP pot fi extinse către clienți și furnizori, prin integrarea cu
software de tip SCM (Supply Chain Management).
• Exemple de furnizori de soluții ERP: Oracle, SAP, Microsoft
FACTORI DE INFLUENȚĂ-2

Costul inițial și costul total al proprietății

• Dezvoltarea sistemului ia în calcul fezabilitatea economică și costul total al
proprietății (TCO-Total Cost of Ownership).
• TCO include achiziții tangibile, taxe, contracte, precum și costuri de mentenanță,
training, suport sau datorate nefuncționării sistemului.
• O analiză a costurilor ar trebui să răspundă la întrebări precum:
➢ Dacă dezvoltarea prin construcție a fost selectată inițial ca cea mai bună
alternativă, este încă cea mai buna alegere? Este estimarea costului inițial
realistă?
➢ Dacă inițial a fost aleasă o anumită soluție pentru achiziție, este totuși
aceasta cea mai bună alegere? Există versiuni mai noi sau produse
competitive disponibile? Au apărut modificări ale prețurilor?
➢ Au avut loc evenimente economice, guvernamentale sau de reglementare
care ar putea afecta proiectul propus?
➢ Au apărut probleme legate de fuziune sau achiziție care ar putea necesita
compatibilitatea cu un anumit mediu?
➢ Sunt produse sau tehnologii apărute recent pe care le putem lua în
considerare?
FACTORI DE INFLUENȚĂ-3

Scalabilitate
• Constă în capacitatea unui sistem de fi extins, modificat sau
redus ca dimensiuni.
• Este importantă în sistemele care depind de volumul datelor.
• Este necesară pentru a susține afaceri dinamice, în creștere.
• Beneficiarii sunt atenți la problemele de scalabilitate care ar
putea influența speranța de viață a sistemului.

Integrare Web
• Trebuie să integrăm o aplicație nouă cu altele bazate pe web?
• Arhitecturile bazate pe web au standarde de proiectare foarte
cunoscute și utilizate pe scară largă.
• Se evită problemele de conectivitate și compatibilitate datorate
folosirii unor dispozitive hardware variate.
• Partenerii externi pot folosi browsere web pentru a importa și
exporta date.
FACTORI DE INFLUENȚĂ-4

Cerințe de integrare cu sistemele moștenite

• Un sistem nou poate interacționa cu unul sau mai multe sisteme
vechi, moștenite.
• Convertirea fișierelor vechi de date este un proces costisitor și
consumator de timp.
• Soluțiile de tip middleware pot facilita transferul de date între
sisteme.
• Noul sistem va înlocui sistemul moștenit sau vor coexista?

Probleme de securitate
• Securitatea este o preocupare majoră în dezvoltarea unui sistem.
• Este deosebit de importantă când prelucrările datelor sunt
efectuate în locații distribuite geografic.
• În sistemele critice, problemele de securitate influențează
semnificativ arhitectura sistemului.
• În sistemele bazate pe web datele critice și datele clienților trebuie
protejate în Internet.
FACTORI DE INFLUENȚĂ-5

Opțiuni de procesare
• Alegerea arhitecturii trebuie să ia în considerare și modul în care
sistemul va procesa datele.
• Există două modalități de procesare importante:
➢ online
➢ în loturi
• Primele sisteme informatice au fost concepute pentru a gestiona datele
sub formă de loturi.
• Astăzi procesarea în loturi este mai puțin folosită.
• Un sistem pentru procesarea comenzilor trebuie să proceseze datele
online și necesită mai multe resurse de rețea și posibilități de
recuperare a datelor.
• Un sistem pentru prelucrarea lunară a facturilor ar putea funcționa și în
loturi.
SISTEM CU PROCESARE ONLINE

Gestionează complet tranzacțiile când și unde au loc.

Utilizatorii interacționează direct cu datele din sistem.
Evită întârzierile și facilitează un dialog constant între utilizator și sistem.

Sistemul informatic trebuie să fie

disponibil ori de câte ori este
necesar pentru a sprijini funcțiile
afacerii.
Utilizatorii pot accesa datele
aleatoriu.
Exemple: sisteme pentru rezervări
aeriene, sistemele pentru ATM.
SISTEM CU PROCESARE ÎN LOTURI
• Este o variantă de procesare în care datele sunt gestionate în grupuri sau loturi.
• În anii 1960 reprezenta o alegerea acceptabilă, astăzi este o opțiune de dorit
doar în anumite situații particulare.
• Poate fi folosită pentru volume mari de date care trebuie prelucrate într-un
program de rutină, în domenii ca salarizarea, tranzacții bancare sau bursiere.
• Avantaje: 1) planificarea sarcinilor repetitive și rularea fără intervenția
utilizatorului; 2) prelucrărilor pot rula în intervale orare convenabile ca timp și
costuri; 3) rulează într-un mediu relativ controlat, propice pentru prelucrări
legate de securitate, audit sau confidențialitate.
MODELE DE
ARHITECTURI
SOFTWARE
ARHITECTURA CLIENT/SERVER

• Lumea interconectată necesită o arhitectură informatică care să cuprindă

întreaga companie.
• Majoritatea sistemelor adoptă modele de proiectare specifice sistemelor
distribuite și bazate pe Internet.
• Generic, termenul client/server se referă la sisteme care împart procesarea
între unul sau mai mulți clienți în rețea și un server central.
• Datele nu sunt transferate de la server la client – doar cererea și rezultatul sunt
transmise prin rețea.
COMPONENTE ALE UNEI APLICAȚII
Interfața utilizator
• Stratul de prezentare este locul unde utilizatorul final
interacționează cu sistemul.
• Are rolul de a afișa informații și de a colecta date de la utilizator.
• Poate lua diferite forme, în funcție de tipul de aplicație (web,
desktop, mobilă etc.)

Logica aplicației
• Stratul de nivel mediu procesează informațiile primite de la interfețe
și de la datele persistente ale sistemului.
• Folosește logica de afaceri a domeniului și reguli de afaceri specifice.
• Scrisă în limbaje ca Java, Python, JavaScript sau PHP.
• Comunică cu datele folosind API-uri.

Datele
• Stratul de bază de date sau de acces la date este locul în care sunt
stocate și gestionate datele procesate de aplicație.
• Frecvent este un SGBD relațional (MySQL, Oracle, DB2) sau un
server de de baze de date NoSQL (Cassandra , MongoDB).
ARHITECTURA CLIENT/SERVER - NIVELURI

• Variantele timpurii de arhitecturi client/server erau organizate pe două niveluri.

• Ulterior, a devenit mai populară arhitectura client/server pe trei niveluri.
• Un design cu trei niveluri poate îmbunătăți performanța generală la nivel de
server, dar și de client.
• Nivelul de mijloc este mai eficient și rentabil în sistemele de dimensiuni mari.
 C O M P O N E N T E L E A P L I C AȚ I E I Î N
DIFERITE MODELE DE ARHITECTURI
 Separarea logică și fizică a funcționalității

Fiecare nivel rulează pe cel puțin un server hardware

dedicat sau pe un server virtual

Dezvoltare mai rapidă - fiecare nivel poate fi

ARHITECTURA dezvoltat simultan de echipe diferite

CLIENT/SERVER Scalabilitate îmbunătățită - orice nivel poate fi

CU TREI NIVELURI scalat independent de celelalte

- AVANTAJE Fiabilitatea îmbunătățită - o întrerupere a unui

nivel produce efecte reduse

Securitate îmbunătățită - un nivel de aplicație bine

conceput poate funcționa ca un fel de firewall intern

Tendință spre modernizare - trendul general îl

reprezintă migrarea către cloud.
ARHITECTURA ORIENTATĂ PE SERVICII-
SOA (SERVICE ORIENTED ARCHITECTURE)

Consumatorul poate să fie Organizațiile pot

Procesele de afaceri sunt
împărțite în componente reacționa mai rapid la
o aplicație, un alt
sau servicii individuale. nevoile de afaceri aflate în
serviciu sau o persoană. continuă schimbare.

SOA folosește și Sistemele pot fi construite

Mai multe servicii pot fi
orchestrate pentru a reutilizează serviciile și reconfigurate cu
individuale sub formă de
gestiona sarcinile. ușurință.
„blocuri de bază”.

Reutilizabilitate Interoperabilitate Modularizare

Un serviciu ar trebui să fie Un serviciu ar trebui să Un serviciu ar trebui să fie
utilizabil în multiple aplicații funcționeze cu orice alt simplu și modular.
diferite. serviciu.
SOA – INVOCAREA SERVICIILOR

➢ Mai multe aplicații pot invoca aceleași servicii.

➢ Găzduirea și implementarea unor astfel de servicii se face în cloud.
➢ Se elimină nevoia de a scrie mult cod.
➢ SOA necesită un efort și o expertiză semnificativă.
➢ SOA ajută la creșterea flexibilității, dar integrarea diferitelor servicii poate fi
extrem de complexă.
COMPONENTELE SOA
Serviciul
• Este fundamentul SOA și poate fi privat sau public.
• Conține trei elemente: implementarea, contractul și interfața.

Furnizorul de servicii
• Pune la dispoziție și întreține unul sau mai multe servicii.
• Publică serviciile într-un registru împreună cu detalii specifice.
•
Consumatorul de servicii
• Este o persoană, un sistem, o aplicație sau alt serviciu care solicită
un serviciu de la furnizorul de servicii.
• Localizează metadatele serviciului în registru.
• Poate dezvolta componente client pentru a utiliza serviciul.

Registrul de servicii
• Este un director de servicii disponibile.
• Stochează descrierile serviciilor și alte informații relevante despre
modul de utilizare a serviciilor.
SOA – INTERACȚIUNEA
COMPONENTELOR
ARHITECTURA ORIENTATĂ PE SERVICII-SOA

Beneficii
• Interoperabilitate între diferite sisteme și platforme
• Flexibilitate și agilitate în a răspunde nevoilor afacerii
• Scalabilitate prin extinderea instanțelor serviciilor
• Întreținere îmbunătățită și actualizări independente

Limite
• Complexitate ce crește odată cu numărul de servicii și
cu interacțiunile lor
• Costul inițial mare datorat investiției inițiale
• Preocupări privind securitatea care sunt generate de
punctele suplimentare de acces și comunicare între servicii