Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 1

Arhitecturi pentru sisteme software
Curs 1
Site curs:
https://sites.google.com/site/arhswcm
id9208661 pdfMachine by Broadgun Software - a great PDF writer! - a great PDF creator! - http://www.pdfmachine.com http://www.broadgun.com
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 2
Arhitecturi software - exemple
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 3
Arhitecturi software - exemple
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 4
Arhitecturi software - exemple
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 5
Arhitecturi software - exemple
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 6
Arhitecturi software - exemple
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 7
Arhitecturi software - exemple
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 8
Arhitecturi software - exemple
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 9
Concluzie
Probleme ale descrierilor naive ale arhitecturii software
• Text informal ºi diagrame de tip box-and-lines.
• Intuitive
• Precizie slabã
• Rareori formalizatã
O soluþie : Dezvoltarea ARHITECTURALÃ a sistemelor software ºi
descrierea formalã a structurii acestora.
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 10
Dezvoltarea arhitecturalã a sistemelor software
• Compunerea sistemelor din pãrþi componente.
• Asigurarea conformitãþii sistemului cu arhitectura ºi cu
proprietãþile dorite.
• Utilizare arhitecturi standard pentru integrare.
• Reutilizare.
• Reducere costuri utilizând linii de produse.
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 11
Dezvoltarea arhitecturalã a sistemelor software
• Compunerea sistemelor din pãrþi componente.
• Asigurarea conformitãþii sistemului cu arhitectura ºi cu
proprietãþile dorite.
• Utilizare arhitecturi standard pentru integrare.
• Reutilizare.
• Reducere costuri utilizând linii de produse.
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 12
PLAN CURS
 Obiectivele cursului
 Definiþia ºi rolul arhitecturii software
 Evoluþia domeniului
 Arhitectura software în context
 Impactul arhitecturii software
 Relaþiile de influenþã ale arhitecturii software
 Rolul ºi calitãþile arhitectului software
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 13
Obiectivele cursului - 1
 Rolul arhitecturii software în procesul de dezvoltare a software-lui.
 Recunoaºterea principalelor stiluri ºi ºabloane arhitecturale.
 Descrierea cerinþelor astfel încât arhitectura sã poatã fi evaluatã.
 Înþelegerea principiilor unei bune documentaþii arhitecturale.
 Înþelegerea modului de incorporare a COTS ºi middleware în
proiectele arhitecturale.
 Generarea de alternative arhitecturale pentru o problemã ºi
alegerea uneia dintre ele.
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 14
Obiectivele cursului - 2
 Proiectarea ºi construirea unui sistem de dimensiuni medii care
satisface o specificaþie arhitecturalã
 Înþelegerea modului în care notaþiile formale pot fi utilizate
pentru a specifica arhitecturi.
 Evaluarea adecvãrii unei arhitecturi date în îndeplinirea unui
set de cerinþe sistem ºi echilibrarea compromisurilor asupra
calitãþii.
 Cunoaºterea tendinþelor de viitor în domeniul arhitecturilor
software.
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 15
PLAN CURS
 Obiectivele cursului
 Definiþia ºi rolul arhitecturii software
 Evoluþia domeniului
 Arhitectura software în context
 Impactul arhitecturii software
 Relaþiile de influenþã ale arhitecturii software
 Rolul ºi calitãþile arhitectului software
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 16
Arhitecturã software - Definiþie
Definiþii la:
http://www.sei.cmu.edu/architecture/start/definitions.cfm
Definiþia adoptatã la acest curs:
“Arhitectura software a unui sistem de calcul este setul structurilor
unui sistem necesare pentru a realiza raþionamente referitoare la
acesta, structuri conþinând elementele software, relaþiile dintre
acestea ºi proprietãþile vizibile din exterior ale ambelor”.
Clements, Bachmann, Bass, Garlan, Ivers, Little, Nord, Stafford, Documenting Software
Architectures: Views and Beyond, Addison Wesley Longman, 2010
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 17
Proiectare arhitecturalã
Informaþii despre domeniul aplicaþiei
PROIECTARE ARHITECTURALÃ
Arhitectura aplicaþiei
= Perspectivã generalã asupra software-lui.
Elemente ale modelului analizã
ªabloane ºi stiluri arhitecturale existente
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 18
Locul ºi rolul arhitecturii software
Proiect de nivel superior al sistemului
Abstractizãri la nivel de sistem
Modele reutilizabile la nivel de sistem
Rãspunde cerinþelor de comportament ºi de calitate
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 19
Importanþa arhitecturii software
Reducerea costurilor de dezvoltare ºi de mentenanþã
 clarificarea structurii sistemului pe diferite nivele
 reutilizare
Creºterea calitãþii produsului software
 clarificarea cerinþelor
 explicitarea deciziilor, realizate pe bazã de principii, ºi a
implicaþiilor lor
 analize la nivel de sistem
 analiza precoce a problemelor de proiectare
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 20
Importanþa arhitecturii software – reducerea costurilor
de mentenanþã
Aproape 50% din efortul de mentenenþã este
investit în analiza ºi înþelegerea codului ºi
documentaþiei existente.
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 21
Arhitecturã software vs. programare
PROGRAMAREA
 Implementarea părþilor
componente
 Proprietãþile computaþionale
 Operaþionalã
 În mare parte dinamicã
 Performanþã la nivel de
algoritm
 “vedere” interioarã a
modulelor
ARHITECTURA SOFTWARE
 Interacþiunile dintre pãrþile
componente
 Proprietãþile structurale
 Declarativã
 În mare parte staticã
 Performanþã la nivel de
sistem
 “vedere” exterioară a
modulelor
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 22
PLAN CURS
 Obiectivele cursului
 Definiþia ºi rolul arhitecturii software
 Evoluþia domeniului
 Arhitectura software în context
 Impactul arhitecturii software
 Relaþiile de influenþã ale arhitecturii software
 Rolul ºi calitãþile arhitectului software
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 23
Evoluþia domeniului - anii 1980
 Utilizare informalã de diagrame de tip box-and-lines
 Aplicare ad-hoc a expertizei arhitecturale
 Utilizarea neorganizatã, necodificatã, a ºabloanelor ºi stilurilor
 Majoritatea proiectelor nu au “arhitect”
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 24
Evoluþia domeniului - anii 1990
 Recunoaºterea importanþei arhitecþilor în companiile de
dezvoltare de software
 Procese software ce includ revizuiri ale arhitecturii ºi
documentaþie arhitecturalã explicitã
 Utilizare de linii de produse, de standarde arhitecturale, de
cadre pentru integrare de componente
 Codificarea vocabularului, notaþii ºi instrumente pentru proiectare
arhitecturalã
 Cãrþi ºi cursuri de arhitecturi software
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 25
Evoluþia domeniului - anii 2000
 Încorporarea notaþiilor arhitecturale în principalele limbaje de
proiectare (ex. UML 2.0) ºi instrumente (ex. Software Architect
de la IBM)
 Metode bazate pe proiectare arhitecturală ºi rafinarea acesteia
(ex. MDA – Model Driven Architecture)
 Unele instrumente pentru analizã arhitecturală
 Standarde arhitecturale pentru sisteme enterprise (ex. RM-ODP,
TOGAF)
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 26
PLAN CURS
 Obiectivele cursului
 Definiþia ºi rolul arhitecturii software
 Evoluþia domeniului
 Arhitectura software în context
 Impactul arhitecturii software
 Relaþiile de influenþã ale arhitecturii software
 Rolul ºi calitãþile arhitectului software
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 27
Ingineria sistemelor
Ingineria sistemelor – disciplină de proiectare ºi management
pentru proiectarea ºi construirea de sisteme mari, complexe,
interdisciplinare.
Arhitectura sistemului – element critic al ingineriei sistemelor:
• Descrie elementele ºi interacþiunile unui sistem complet precum
ºi contribuþia acestora la scopul sistemului
• Include identificarea ºi caracterizarea elementelor sistemului,
fãrã a descrie substructurile acestor elemente.
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 28
Interese în proiectãri arhitecturale
 Caracteristicile limbajului
 Eficienþa algoritmilor
 Proiectarea structurilor de date
 Testarea aplicaþiei software
 Implementarea funcþionalitãþii
Proiect software non-
arhitectural
 Identificarea atributelor de calitate
 Cerinþele funcþionale pentru software
 Partiþionarea aplicaþiilor software
 Integrare ºi testare la nivel de software ºi de sistem
Arhitecturã software
 Identificarea contextului sistemului
 Partiþionare (centratã pe Hw ºi infrastructurã)
 Identificarea cerinþelor software
 Cerinþele funcþionale generale ale sistemului
 Integrare ºi testare la nivel de sistem
Arhitecturã sistem
 Procese business ºi modele operaþionale
 Date business
 Structură ºi relaþii organizaþionale
 Părþile interesate în afacere (stakeholders)
 Infrastructura IT
Arhitecturã “enterprise”
Interese cheie în proiectare Nivel de abstractizare
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 29
Ierarhia proiectãrii arhitecturale
Principii:
 Interese diferite pe nivele diferite
 Deciziile de pe nivelele superioare impun constrângeri nivelelor
inferioare
 Nivelul superior transferã responsabilitatea detalierii către
nivelul inferior
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 30
Ierarhia proiectãrii arhitecturale
ENTERPRISE: procesul
business mapat pe o
infrastructurã cu
granularitate mare.
SISTEM: Concentrare pe
cerinþele funcþionale
alocate elementelor fizice.
(sisteme de sisteme)
SOFTWARE: multidemnsionalã; satisfãcând
cerinþe funcþionale ºi de calitate.
Deseori ortogonalã în raport cu structurile
sistemului.
Criticã în satisfacerea obiectivelor business.
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 31
PLAN CURS
 Obiectivele cursului
 Definiþia ºi rolul arhitecturii software
 Evoluþia domeniului
 Arhitectura software în context
 Impactul arhitecturii software
 Relaþiile de influenþã ale arhitecturii software
 Rolul ºi calitãþile arhitectului software
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 32
Impactul arhitecturii software
 Atributele de calitate (modificabilitate, disponibilitate,
performanþã, etc.) sunt dependente de design.
 Gândirea arhitecturalã este gândire strategicã.
 O arhitecturã software proiectatã deliberat ºi bine documentatã
oferã valoare proiectului ºi firmei ce dezvoltã software-ul.
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 33
Impactul arhitecturii software
Proiectul arhitectural ºi documentaþia asociatã:
• servesc ca vehicol de comunicare
• ghideazã deciziile iniþiale de proiectare
• reduc riscul
• ajutã la managementul proiectului/produsului
• faciliteazã reutilizarea
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 34
Impactul arhitecturii software
Documentaþia arhitecturii oferă un cadru de referinþã în care pot fi
expuse ºi negociate interese concurente.
Permite:
• Negocierea cerinþelor tuturor pãrþilor interesate
• Realizarea de informãri asupra progresului
• Alocare de resurse ºi ghidarea construirii produsului software
Documentaþia trebuie sã fie:
• DESCRIPTIVÃ - pentru comunicare
• PRESCRIPTIVÃ - pentru proiectanþi ºi pentru
implementatori.
Proiectul arhitectural ºi documentaþia asociatã:
• Servesc ca vehicol de comunicare
• Ghidează deciziile iniþiale de proiectare
• Reduc riscul
• Ajută la managementul proiectului/produsului
• Facilitează reutilizarea
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 35
Impactul arhitecturii software
Arhitectura face trecerea de la specificarea cerinþelor (ce?) la
îndeplinirea acestora (cum?).
Arhitectul poate prezice calitãþile sistemului prin studierea
abstractizãrilor arhitecturale ale acestuia.
• Deciziile arhitecturale influenþeazã proprietãþile sistemului în
moduri cunoscute
• Proiectul arhitectural poate fi analizat ºi utilizat pentru a prezice
în ce mãsurã vor fi obþinute proprietãþile aºteptate de la sistem.
Proiectul arhitectural ºi documentaþia asociatã:
• Servesc ca vehicol de comunicare
• Ghidează deciziile iniþiale de proiectare
• Reduc riscul
• Ajută la managementul proiectului/produsului
• Facilitează reutilizarea
PERFORMANÞÃ – evitare gâtuiri, cuplare strânsã a
elementelor, limitarea cantităþii ºi frecvenþei comunicãrilor
distribuite ºi între elemente
MODIFICABILITATE – centrare pe responsabilităþile
elementelor, decuplarea elementelor, localizarea
responsabilitãþilor, minimizarea ºi simplificarea
dependenþelor între elementele sistemului.
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 36
Impactul arhitecturii software
O arhitecturã ce a fost proiectatã poate fi evaluatã pot fi
identificate ºi diminuate elementele riscante ale sistemului.
Infrastructura arhitecturalã proiectatã poate fi implementatã ºi
serveºte ca “echipament” de testare suport pentru
prototipare, integrare, testare precoce.
Proiectul arhitectural ºi documentaþia asociatã:
• Servesc ca vehicol de comunicare
• Ghidează deciziile iniþiale de proiectare
• Reduc riscul
• Ajută la managementul proiectului/produsului
• Facilitează reutilizarea
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 37
Impactul arhitecturii software
Permite realizarea de estimări mai precise ale costurilor ºi planului de timp.
• Estimãrile se bazeazã pe elementele arhitecturii
• Echipa responsabilã pentru un anume element oferã estimãrile pentru acesta
• Managerii de proiect integreazã estimãrile ºi rezolvã dependenþele ºi
conflictele
Utilã în managementul modificãrilor.
• Permite pãrþilor interesate sã judece ºi sã gestioneze modificãrile la sistem
pe toatã durata de viaþã a acestuia (aprox. 80% din efort are loc după dezvoltarea ºi
punerea iniþialã în funcþiune a sistemului).
• Arhitectura împarte modificãrile în trei clase:
• Locale – un singur element
• Non-locale – mai multe elemente
• Arhitecturale – modificări la topologia sistemului sau la mecanismele de comunicare
ºi coordonare.
Oferã înþelegere ºi cunoaºtere pătrunzătoare de-a lungul întregului ciclu de
viaþã al sistemului. Proiectul arhitectural ºi documentaþia asociatã:
• Servesc ca vehicol de comunicare
• Ghidează deciziile iniþiale de proiectare
• Reduc riscul
• Ajută la managementul proiectului/produsului
• Facilitează reutilizarea
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 38
Impactul arhitecturii software
Faciliteazã reutilizarea de elemente cu granularitate mare.
Exemple:
• Componente (ex. baze de date, COTS)
• Cadre de dezvoltare (ex. Java EE)
• Linii de produse (reutilizare strategicã)
Obs. Reutilizarea de module de granularitate mică are următoarele dezavantaje:
• Este costisitor ºi dificil de gãsit funcþiile, metodele sau procedurile cele mai
potrivite
• Este dificil de determinat proprietãþile moºtenite în aceste module.
Proiectul arhitectural ºi documentaþia asociatã:
• Servesc ca vehicol de comunicare
• Ghidează deciziile iniþiale de proiectare
• Reduc riscul
• Ajută la managementul proiectului/produsului
• Facilitează reutilizarea
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 39
PLAN CURS
 Obiectivele cursului
 Definiþia ºi rolul arhitecturii software
 Evoluþia domeniului
 Arhitectura software în context
 Impactul arhitecturii software
 Relaþiile de influenþã ale arhitecturii software
 Rolul ºi calitãþile arhitectului software
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 40
Ciclul business al arhitecturii (ABC)
Relaþiile dintre obiectivele afacerii, cerinþele produsului,
experienþa arhitectului, arhitecturi ºi sisteme formeazã un
ciclu.
 Arhitectura software este influenþatã de o serie de factori.
 Arhitectura software ºi sistemul dezvoltat pe baza ei influenþeazã, la
rândul ei, aceºti factori.
 În centrul acestui ciclu stã arhitectul software.
Înþelegerea ºi analiza acestui ciclu poate ajuta compania sã-ºi
gestioneze afacerea, organizarea ºi arhitectura.
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 41
ABC - Factorii ce influenþeazã arhitectura software
 Pãrþile interesate în sistem
 Firma ce dezvoltã sistemul
 Contextul tehnologic
 Cunoºtinþele ºi experienþa arhitectului
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 42
ABC - Factorii ce influenþeazã arhitectura software
Stakeholder-i (clienþi, utilizatori, dezvoltatori, manageri, personal de
întreþinere, etc) – au interese diferite pe care le vor garantate
sau optimizate.
Exemple
 Dezvoltatori – limbaje, tehnologii
 Administratori – reglare, configurare, repartizare sistem
 Marketing – caracteristici ºi preþ competitive pe piaþã
Obiectivele organizaþionale ºi proprietãþile la nivelul business ale sistemului
sunt rareori înþelese ºi cu atât mai puþin bine exprimate – arhitectul
trebuie sã joace un rol activ în identificarea ºi angajarea precoce a
stakeholder-ilor în ciclul de dezvoltare.
•Pãrþile interesate în sistem
•Firma ce dezvoltã sistemul
•Contextul tehnologic
•Cunoºtinþele ºi experienþa arhitectului
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 43
ABC - Factorii ce influenþeazã arhitectura software
•Pãrþile interesate în sistem
•Firma ce dezvoltã sistemul
•Contextul tehnologic
•Cunoºtinþele ºi experienþa arhitectului
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 44
ABC - Factorii ce influenþeazã arhitectura software
Clase de influenþe organizaþionale:
 Afacerea imediatã
Firma poate avea o investiþie în anumite bunuri, cum ar fi arhitecturi existente ºi
produsele bazate pe acestea.
 Afacerea pe termen lung
Arhitectura poate fi nucleul unei investiþii pe termen lung în infrastructurã, pentru
îndeplinirea obiectivelor strategice ale firmei.
 Structura organizaþionalã
Structura organizaþionalã poate modela arhitectura a.î. diviziunile de funcþionalitate
se aliniazã la unitãþile de expertizã existente.
•Pãrþile interesate în sistem
•Firma ce dezvoltã sistemul
•Contextul tehnologic
•Cunoºtinþele ºi experienþa arhitectului
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 45
ABC - Factorii ce influenþeazã arhitectura software
Contextul tehnologic existent în momentul elaborãrii arhitecturii.
Include:
• Limbaje
• Instrumente
• Sisteme de operare
• Platforme de calcul
• Cadre de implementare
• Practici industriale standard ºi tehnici de inginerie software
•Pãrþile interesate în sistem
•Firma ce dezvoltã sistemul
•Contextul tehnologic
•Cunoºtinþele ºi experienþa arhitectului
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 46
ABC - Factorii ce influenþeazã arhitectura software
Arhitecþii iau decizii de proiectare pe baza experienþei lor.
• Experienþele reuºite conduc la replicarea proiectelor care au mers bine
• Experienþele nereuºite vor fi evitate în noile proiecte, chiar dacă
metodele, tehnicile ºi/sau tehnologiile ce au codus la acestea ar putea
funcþiona bine în alte proiecte
• Alegerile pe care le face un arhitect sunt influenþate de experienþa, de
instruirea (training) ºi de educaþia sa formalã (în acestã ordine!).
•Pãrþile interesate în sistem
•Firma ce dezvoltã sistemul
•Contextul tehnologic
•Cunoºtinþele ºi experienþa arhitectului
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 47
ABC - Factorii influenþaþi de arhitectura software
Arhitectura ºi sistemul dezvoltat
pe baza acesteia vor
influenþa:
 Structura ºi obiectivele
firmei dezvoltatoare
 Cerinþele beneficiarilor
 Experienþa arhitectului
 Tehnologia
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 48
ABC - Factorii influenþaþi de arhitectura software
Arhitectul divizeazã sistemul în componente majore ºi unitãþi de
lucru.

 modeleazã firma prin partiþionarea forþei de muncã
 ajutã la stabilirea unui vocabular de comunicare
 bazã pentru WBS, utilizatã în planificare, urmărire ºi bugetare
 organizare în scopul gestionãrii configuraþiilor
 organizare în scopul elaborãrii documentaþiei
 bazã pentru integrare ºi testare
Arhitectul defineºte elementele software ce trebuie implementate ºi
integrate. Acestea devin bazã pentru:
• alocare talente, recrutare, formare echipã
• activitãþi de dezvoltare, testare ºi integrare
• estimare ºi alocare resurse
• planuri de timp, bugete, urmãrire proiect ºi supraveghere
•Structura ºi obiectivele firmei dezvoltatoare
•Cerinþele beneficiarilor
•Experienþa arhitectului
•Tehnologia
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 49
ABC - Factorii influenþaþi de arhitectura software
Arhitecturile pot influenþa obiectivele unei firme
deoarece:
 Un sistem de succes construit pe baza unei anumite arhitecturi
poate permite unei companii sã punã stãpânire pe o anumitã
zonã de piaþã
 Arhitectura poate oferi oportunitãþi pentru producere eficientã ºi
punere în funcþiune de sisteme similare.
•Structura ºi obiectivele firmei dezvoltatoare
•Cerinþele beneficiarilor
•Experienþa arhitectului
•Tehnologia
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 50
ABC - Factorii influenþaþi de arhitectura software
Pe baza cunoºtinþelor despre sisteme similare clienþii cer anumite tipuri
de caracteristici.
Exemple:
• Beneficiarii învaþã limbajul arhitectural, percep beneficiile, ºi vor tipuri
similare de arhitecturi cum ar fi client-server, EJB, CORBA, .NET, etc.
• Clienþii vor cere arhitecturi de calitate în sistemele viitoare
Pe baza cunoºtinþelor despre sistemul dezvoltat clienþii îºi vor modifica
cerinþele sistem în raport cu disponibilitãþii sistemelor
ºi elementelor existente.
•Structura ºi obiectivele firmei dezvoltatoare
•Cerinþele beneficiarilor
•Experienþa arhitectului
•Tehnologia
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 51
ABC - Factorii influenþaþi de arhitectura software
Dezvoltarea unei arhitecturi îmbogãþeºte experienþa arhitectului.
 Tehnologii, instrumente, metode ce au fost utilizate în
dezvoltarea de sisteme reuºite conduc la crearea de sisteme
viitoare în aceeaºi manierã.
 Arhitectura unui sistem eºuat este evitatã în proiecte viitoare.
•Structura ºi obiectivele firmei dezvoltatoare
•Cerinþele beneficiarilor
•Experienþa arhitectului
•Tehnologia
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 52
ABC - Factorii influenþaþi de arhitectura software
Ocazional, un sistem sau o arhitecturã vor modifica stadiul actual
al tehologiei.
Exemple:
 generatoare de compilatoare
 baze de date relaþionale
 foi de calcul
 sisteme de operare cu interfeþe grafice
 WWW
 Java
•Structura ºi obiectivele firmei dezvoltatoare
•Cerinþele beneficiarilor
•Experienþa arhitectului
•Tehnologia
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 53
PLAN CURS
 Obiectivele cursului
 Definiþia ºi rolul arhitecturii software
 Evoluþia domeniului
 Arhitectura software în context
 Impactul arhitecturii software
 Relaþiile de influenþã ale arhitecturii software
 Competenþele, rolul ºi calitãþile arhitectului software
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 54
Competenþele, rolul ºi calitãþile arhitectului software
Tehnologie
Creativ
Capabil de investigaþie
Practic/pragmatic
Patrunzãtor
Tolerant faþã de ambiguitãþi,
dispus la reluãri, în cãutare
de soluþii multiple
Capacitate de a lucra pe
nivel abstract
Modelare
Analiza compromisurilor
Prototipare/experimentare/
simulare
Pregãtirea documentelor ºi
prezentãrilor arhitecturii
software
Analiza tendinþelor
tehnologice
Un punct de vedere asupra
sistemului
Înþelegerea profundã a
domeniului ºi tehnologiilor
pertinente
Posibilitatea de a decela
elementele tehologice care
reprezintã cheia succesului
Metode de dezvoltare ºi
tehnici de modelare
calitãþi rol competenþe
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 55
Competenþele, rolul ºi calitãþile arhitectului software
Consultanþã
Angajat în succesul altora
Empatic, abordabil
Practic/pragmatic
Agent de schimb eficient
Bun mentor
Crearea unei relaþii de
încredere în consultant
Înþelegerea a ceea ce
doresc ºi au nevoie
dezvoltatorii de la
arhitecturã
Ajutã dezvoltatorii sã vadã
valoarea arhitecturii ºi sã
înþeleagã cum o pot utiliza
cu succes
Mentor pentru arhitecþii
juniori
Tehnici de a obþine ºi
provoca informaþii
Metode cadru de
consultare
Cunoscãtor al proceselor
(business, software,
management)
calitãþi rol competenþe
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 56
Competenþele, rolul ºi calitãþile arhitectului software
Strategie
Vizionar
Antreprenorial
Influenþarea strategiei
afacerii
Traducerea strategiei
afacerii în viziune ºi
strategie tehnicã
Înþelegerea clientului ºi a
tendinþelor din piaþã
Capturarea în arhitecturã a
cerinþelor clientului, a celor
organizaþionale ºi a
cerinþelor business
Strategia ºi raþiunile
fundamentale ale companiei
Competitorii (produse,
strategii, procese)
Practica business a
companiei
calitãþi rol competenþe
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 57
Competenþele, rolul ºi calitãþile arhitectului software
Politici oganizaþionale
Abilitatea de a vedea din
puncte de vedere multiple ºi
de a exprima în puncte de
vedere multiple
Încrezãtor ºi clar/logic în
exprimare
Ambiþios ºi hotarât
Rãbdãtor (cu mãsurã)
Rezistent ºi flexibil
Sensibil la localizarea ºi
fluxul puterii în cadrul
companiei
Comunicare
Ascultare, nod esenþial în
reþeaua de comunicare
interumanã, exercitare de
influenþã.
“Vânzarea” unei viziuni.
Pãstrarea acesteia “în viaþã”.
Luarea periodicã a pulsului
tuturor factorilor critici de
influenþã asupra proiectului
arhitectural.
Care sunt jucãtorii cheie
în companie
Ce doresc aceºtia pe
planul afacerii ºi pe plan
personal
calitãþi rol competenþe
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 58
Competenþele, rolul ºi calitãþile arhitectului software
Conducere
Vãzut ca lider de ceilalþi dar
ºi de el însuºi.
Carismatic ºi credibil.
Încredere cã se poate face
ºi cã poate conduce efortul
respectiv .
Angajat, dedicat, pasionat.
Plasarea întregului efort într-
un context mai larg, atât al
afacerii cât ºi personal.
Stabilirea contextului echipei
(viziunea)
Luare de decizii ºi asumarea lor
Construire echipe
Motivare
Autocunoaºtere
calitãþi rol competenþe
Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 59
BIBLIOGRAFIE
Bass, L; Clements, P & Kazman, R. Software Architecture in Practice, Second
Edition, Addison-Wesley Professional, 2003
Albin, Stephen T. The Art of Software Architecture:Design Methods and
Techniques, John Wiley & Sons, 2003
Lattanze, Anthony J. Architecting Software Intensive Systems: A Practitioners
Guide, Auerbach, 2008
Clements, Bachmann, Bass, Garlan, Ivers, Little, Nord, Stafford, Documenting
Software Architectures: Views and Beyond, Addison Wesley Longman, 2010
Clements, Kazman, Klein, Evaluating Software Architectures: Methods and
Case Studies, Adison Wesley Longman, 2001
Buschmann F., Menuier R., Rohnert H., Sommerlad P., Stal M., Pattern-
Oriented Software Architecture. A System of Patterns, John Wiley & Sons, 1996