Transcript Arhitecturi pentru sisteme software
Slide 1
Arhitecturi pentru sisteme software
Curs 1
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
Slide 2
Arhitecturi software - exemple
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Slide 3
Arhitecturi software - exemple
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Slide 4
Arhitecturi software - exemple
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Slide 5
Arhitecturi software - exemple
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Slide 6
Arhitecturi software - exemple
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Slide 7
Arhitecturi software - exemple
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Slide 8
Arhitecturi software - exemple
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
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.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
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 producţie.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
Slide 11
PLAN CURS
Obiectivele cursului
Definiţia şi rolul arhitecturii software
Evoluţia domeniului
Arhitectura software în context
Analiza definiţiei arhitecturii software
Impactul arhitecturii software
Relaţiile de influenţă ale arhitecturii software
Rolul şi calităţile arhitectului software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Slide 12
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 12
Slide 13
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 (potrivire) 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 13
Slide 14
PLAN CURS
Obiectivele cursului
Definiţia şi rolul arhitecturii software
Evoluţia domeniului
Arhitectura software în context
Analiza definiţiei arhitecturii software
Impactul arhitecturii software
Relaţiile de influenţă ale arhitecturii software
Rolul şi calităţile arhitectului software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Slide 15
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 constă din structura sau structurile
sistemului şi conţine elementele software, proprietăţile vizibile din
exterior ale acestora şi relaţiile dintre ele”.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Slide 16
Proiectare arhitecturală
Elemente ale modelului analitic
Informaţii despre domeniul aplicaţiei
Şabloane şi stiluri arhitecturale existente
PROIECTARE ARHITECTURALĂ
Arhitectura aplicaţiei
= Perspectivă de generală asupra software-lui.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
Slide 17
Locul şi rolul arhitecturii software
Proiect de nivel superior al sistemului
Abstractizări la nivel de sistem
Modele reutilizabile la nivel de sistem
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Slide 18
Contextul activităţilor de dezvoltare a arhitecturii
software
http://bredemeyer.com/where.htm
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
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 timpurie a problemelor de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
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 20
Slide 21
Arhitectură software vs. programare
ARHITECTURA SOFTWARE
Interacţiunile dintre părţile
componente
PROGRAMAREA
Implementarea părţilor
componente
Proprietăţile structurale
Proprietăţile computaţionale
Declarativă
Operaţională
În mare parte statică
În mare parte dinamică
Performanţă la nivel de
sistem
“vedere” exterioară a
modulelor
Cristina Mîndruţă
Performanţă la nivel de
algoritm
“vedere” interioară a
modulelor
Arhitecturi pentru sisteme software
Slide 21
Slide 22
PLAN CURS
Obiectivele cursului
Definiţia şi rolul arhitecturii software
Evoluţia domeniului
Arhitectura software în context
Analiza definiţiei arhitecturii software
Impactul arhitecturii software
Relaţiile de influenţă ale arhitecturii software
Rolul şi calităţile arhitectului software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
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 23
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 producţie, 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 24
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 25
Slide 26
PLAN CURS
Obiectivele cursului
Definiţia şi rolul arhitecturii software
Evoluţia domeniului
Arhitectura software în context
Analiza definiţiei arhitecturii software
Impactul arhitecturii software
Relaţiile de influenţă ale arhitecturii software
Rolul şi calităţile arhitectului software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
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 27
Slide 28
Ingineria sistemelor
Principiu: integrarea sistemului (de jos în sus) este posibilă doar pe baza
proiectării (de sus în jos), care începe cu o arhitectură robustă a sistemului.
Modelul SE “Vee” de
proiectare şi
dezvoltare în
ingineria
sistemelor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Slide 29
Ingineria sistemelor
Există cadre standard (ex. TOGAF) care adresază
în general
entităţile,
procesul de inginerie a sistemului,
infrastructura.
Critică:
Nivelul de abstractizare este prea înalt.
NU adresează problemele tehnice de dezvoltare a soluţiei
arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Slide 30
Arhitectură “enterprise”
Arhitectura “enterprise” descrie structurile business şi
procesele care conectează aceste structuri.
Descrierea conţine:
Logica de organizare a procesului business – fluxul informaţiilor şi
activităţile dintre entităţile firmei
Dacă e cazul:
Infrastructura IT ce reflectă cerinţele de integrare şi standardizare
ale modelului de operare al firmei.
În general – cadru ce se referă la documentaţiile implicate în procese.
Există multiple cadre pentru arhitecturi “enterprise” (EAF).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Slide 31
Arhitecturi “enterprise” - exemplu
Enterprise Architecture Framework – John Zachman (IBM).
Orientare business
Orientare tehnică
Implementare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Slide 32
Interese în proiectări arhitecturale
Nivel de abstractizare
Interese cheie în proiectare
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”
Arhitectură sistem
Arhitectură software
Identificarea contextului sistemului
Partiţionare (centrată pe Hw şi infrastrucură)
Identificarea cerinţelor software
Cerinţele funcţionale generale ale sistemului
Integrare şi testare la nivel de sistem
Proiect software de detaliu
Cristina Mîndruţă
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
Caracteristicile limbajului
Eficienţa algoritmilor
Proiectarea structurilor de date
Testarea aplicaţiei software
Implementarea funcţionalităţii
Arhitecturi pentru sisteme software
Slide 32
Slide 33
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 33
Slide 34
Ierarhia proiectării arhitecturale
ENTERPRISE: procesul
business mapat pe o
infrastructură cu
granularitate mare.
SYSTEM: Concentrare pe
cerinţele funcţionale
alocate elementelor fizice.
(sisteme de sisteme)
SOFTWARE: multidemnsională; satisfăcând cerinţe
funcţionale şi non-funcţionale.
Deseori ortogonală în raport cu structurile
sistemului.
Critică în satisfacerea obiectivelor business.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 34
Slide 35
PLAN CURS
Obiectivele cursului
Definiţia şi rolul arhitecturii software
Evoluţia domeniului
Arhitectura software în context
Analiza definiţiei arhitecturii software
Impactul arhitecturii software
Relaţiile de influenţă ale arhitecturii software
Rolul şi calităţile arhitectului software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Slide 36
Arhitectura software - definiţie
“Arhitectura software a unui program sau a unui sistem de calcul
constă din structura sau structurile sistemului şi conţine
elementele software, proprietăţile vizibile din exterior ale
acestor elemente şi relaţiile dintre elemente.”
Proiectarea şi documentarea arhitecturii software sunt
esenţiale în dezvoltarea şi evaluarea produsului software.
Dacă nu se realizează proiectarea arhitecturală, în paralel cu
dezvoltarea produsului software se va dezvolta implicit o
arhitectură. Care ar putea să nu vă placă!!!
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
Slide 37
Arhitectura software - definiţie
Caracteristici ale arhitecturii software:
Abstractizare a sistemului.
Partiţionare declarativă şi asignare de responsabilităţi.
Defineşte elementele şi modul în care sunt acestea relaţionate.
Suprimă detaliile despre comportamentul intern şi informaţiile
locale ale elementelor.
Orice sistem are o arhitectură software (chiar dacă aceasta nu a fost proiectată în
mod deliberat).
Cel mai simplu sistem este compus dintr-un singur element aflat în relaţie cu el
însuşi.
Arhitectura îndeplineşte cerinţele funcţionale şi în acelaşi timp promovează o serie
de calităţi ale sistemului (ex. performană, flexibilitate, etc.).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
Slide 38
Arhitectura software - definiţie
“Arhitectura software a unui program sau a unui sistem de calcul
constă din structura sau structurile sistemului şi conţine
elementele software, proprietăţile vizibile din exterior ale
acestor elemente şi relaţiile dintre acestea.”
Abstractizare a structurilor reale ce compun sistemul software.
Structurile sunt reale
Reprezentările lor sunt abstracte
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
Slide 39
Arhitectura software - definiţie
“Arhitectura software a unui program sau a unui sistem de calcul
constă din structura sau structurile sistemului şi conţine
elementele software, proprietăţile vizibile din exterior ale
acestor elemente şi relaţiile dintre acestea.”
Tipuri de structuri software:
Structură statică - cod, apel metodă/funcţie,…
Structură dinamică - proces/fire de execuţi, flux de date,…
Structură fizică - alocarea sistemului de fişiere, procesor, reţea,
….
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 39
Slide 40
Structură, perspectivă, vedere
Un edificiu trebuie să aibă trei calităţi:
durabilitate (firmitas), utilitate (utilitas),
estetică (venustas).
Marcus Vitruvius Pollio, De architectura
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
Slide 41
Structură, perspectivă, vedere
O vedere din perspectivă
dinamică
O vedere din perspectivă
statică
Vedere (view) – o reprezentare a unei structuri,
văzută dintr-o anumită perspectivă.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
Slide 42
Structură, perspectivă, vedere
Perspectiva FIZICĂ
Vederi ale alocărilor:
•calculatoare
•dispozitive
•reţele
Perspectiva STATICĂ
Vederi ale modulelor:
•clase
•funcţii
•interfeţe
Perspectiva DINAMICĂ
Vederi ale componentelor şi
conectorilor:
•procese
•diagrame de secvenţe
•flux de date
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
Slide 43
Arhitectura software - definiţie
“Arhitectura software a unui program sau a unui sistem de calcul
constă din structura sau structurile sistemului şi conţine
elementele software, proprietăţile vizibile din exterior ale
acestor elemente şi relaţiile dintre acestea.”
Element – “parte” a unui sistem.
Perspectiva
STATICĂ
DINAMICĂ
FIZICĂ
Cristina Mîndruţă
Tipuri de elemente
clase, fişiere, ...
fire de execuţie, flux de date, control, ...
calculatoare, dispozitive, reţele, ...
Arhitecturi pentru sisteme software
Slide 43
Slide 44
Arhitectura software - definiţie
“Arhitectura software a unui program sau a unui sistem de calcul
constă din structura sau structurile sistemului şi conţine
elementele software, proprietăţile vizibile din exterior ale
acestor elemente şi relaţiile dintre acestea.”
Proprietăţi funcţionale : asignarea de responsabilităţi elementelor este o
parte esenţială a proiectării arhitecturale.
Proprietăţi non-funcţionale : cerinţele de calitate pentru sistem şi
componentele sale.
Tipurile de proprietăţi vizibile depinde de perspectiva asupra sistemului.
Exemplu:
•Perspectivă statică – modificabilitatea
•Perspectivă dinamică - performanţa
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
Slide 45
Arhitectura software - definiţie
“Arhitectura software a unui program sau a unui sistem de calcul
constă din structura sau structurile sistemului şi conţine
elementele software, proprietăţile vizibile din exterior ale
acestor elemente şi relaţiile dintre acestea.”
•Elementele interacţionează prin interfeţe care împart detaliile în părţi
publice şi părţi private.
•Aceste interacţiuni formează relaţiile dintre elementele arhitecturale.
•Arhitectura se ocupă doar cu partea publică a acestei partiţionări.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
Slide 46
Arhitectura software - definiţie
“Arhitectura software a unui program sau a unui sistem de calcul
constă din structura sau structurile sistemului şi conţine
elementele software, proprietăţile vizibile din exterior ale
acestor elemente şi relaţiile dintre acestea.”
Tipurile de relaţii depind de tipurile de elemente, care depind la rândul lor
de perspectivă.
Exemple:
uses
uses
Modul B
Proces X
date
Proces Y
Modul C
Vedere din perspectivă STATICĂ
Elemente: module
Relaţii: uses
Cristina Mîndruţă
date
date
Modul A
Vedere din perspectivă DINAMICĂ
Elemente: procese
Relaţii: flux de date
Arhitecturi pentru sisteme software
Slide 46
Slide 47
PLAN CURS
Obiectivele cursului
Definiţia şi rolul arhitecturii software
Evoluţia domeniului
Arhitectura software în context
Analiza definiţiei arhitecturii software
Impactul arhitecturii software
Relaţiile de influenţă ale arhitecturii software
Rolul şi calităţile arhitectului software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
Slide 48
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 48
Slide 49
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 49
Slide 50
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ă:
• Serveşte ca vehicol de comunicare
• Ghidează deciziile iniţiale de proiectare
• Reduce riscul
• Ajută la managementul proiectului/produsului
• Facilitează reutilizarea
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Slide 51
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.
PERFORMANŢĂ – evitare gâtuiri, cuplare strânsă a
elementelor, limitare 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.
SCALABILITATE – consolidarea, localizarea şi
centralizarea resurselor de câte ori e posibil.
Cristina Mîndruţă
Proiectul arhitectural şi documentaţia asociată:
• Serveşte ca vehicol de comunicare
• Ghidează deciziile iniţiale de proiectare
• Reduce riscul
• Ajută la managementul proiectului/produsului
• Facilitează reutilizarea
Arhitecturi pentru sisteme software
Slide 51
Slide 52
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 timpurie.
Proiectul arhitectural şi documentaţia asociată:
• Serveşte ca vehicol de comunicare
• Ghidează deciziile iniţiale de proiectare
• Reduce riscul
• Ajută la managementul proiectului/produsului
• Facilitează reutilizarea
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
Slide 53
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ă:
•
•
•
•
•
Cristina Mîndruţă
Serveşte ca vehicol de comunicare
Ghidează deciziile iniţiale de proiectare
Reduce riscul
Ajută la managementul proiectului/produsului
Facilitează reutilizarea
Arhitecturi pentru sisteme software
Slide 53
Slide 54
Impactul arhitecturii software
Facilitează reutilizarea de elemente cu granularitate mare.
Exemple:
•
Componente (ex. baze de date, COTS)
•
Cadre de dezvoltare (ex. J2EE)
•
Linii de producţie (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ă:
• Serveşte ca vehicol de comunicare
• Ghidează deciziile iniţiale de proiectare
• Reduce riscul
• Ajută la managementul proiectului/produsului
• Facilitează reutilizarea
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 54
Slide 55
PLAN CURS
Obiectivele cursului
Definiţia şi rolul arhitecturii software
Evoluţia domeniului
Arhitectura software în context
Analiza definiţiei arhitecturii software
Impactul arhitecturii software
Relaţiile de influenţă ale arhitecturii software
Rolul şi calităţile arhitectului software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 55
Slide 56
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 ciclul poate ajuta compania săşi gestioneze afacerea, organizarea şi arhitectura.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 56
Slide 57
ABC - Factorii ce influenţează arhitectura software
Cristina Mîndruţă
Părţile interesate în sistem
Firma ce dezvoltă sistemul
Contextul tehnologic
Cunoştinţele şi experienţa arhitectului
Arhitecturi pentru sisteme software
Slide 57
Slide 58
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 timpurie 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 58
Slide 59
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 59
Slide 60
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 60
Slide 61
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 61
Slide 62
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 62
Slide 63
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 63
Slide 64
ABC - Factorii influenţaţi de arhitectura software
Arhitectul divizează sistemul în componente majore şi unităţi de
lucru.
•Structura şi obiectivele firmei dezvoltatoare
•Cerinţele beneficiarilor
•Experienţa arhitectului
modelează firma prin partiţionarea forţei de muncă
•Tehnologia
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
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 64
Slide 65
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 65
Slide 66
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 66
Slide 67
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 67
Slide 68
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 68
Slide 69
ABC - exemplu
Vezi lab1: TheLutherArchitecture.pdf
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 69
Slide 70
PLAN CURS
Obiectivele cursului
Definiţia şi rolul arhitecturii software
Evoluţia domeniului
Arhitectura software în context
Analiza definiţiei arhitecturii software
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 70
Slide 71
Competenţele, rolul şi calităţile arhitectului software
Tehnologie
competenţe
Î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
Modelare
Analiza compromisurilor
Prototipare/experimentare/
simulare
Creativ
Capabil de investigaţie
Practic/pragmatic
Patrunzător
Pregătirea documentelor şi
prezentărilor arhitecturii
software
Analiza tendinţelor
tehnologice
Tolerant faţă de ambiguităţi,
dispus la reluări, în căutare
de soluţii multiple
Capacitate de a lucra pe
nivel abstract
Un punct de vedere asupra
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 71
Slide 72
Competenţele, rolul şi calităţile arhitectului software
Consultanţă
competenţe
Tehnici de a obţine şi
provoca informaţii
calităţi
rol
Crearea unei relaţii de
încredere în consultant
Angajat în succesul altora
Empatic, abordabil
Metode cadru de
consultare
Cunoscător al proceselor
(business, software,
management)
Î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
Practic/pragmatic
Agent de schimb eficient
Bun mentor
Mentor pentru arhitecţii
juniori
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 72
Slide 73
Competenţele, rolul şi calităţile arhitectului software
Strategie
competenţe
calităţi
rol
Strategia şi raţiunile
Influenţatea strategiei
fundamentale ale companiei afacerii
Vizionar
Antreprenorial
Competitorii (produse,
strategii, procese)
Traducerea strategiei
afacerii în viziune şi
strategie tehnică
Practica business a
companiei
Î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
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 73
Slide 74
Competenţele, rolul şi calităţile arhitectului software
Politici oganizaţionale
competenţe
Care sunt jucătorii cheie
în companie
Comunicare
Ce doresc aceştia pe
planul afacerii şi pe plan
personal
Abilitatea de a vedea din
puncte de vedere multiple şi
de a exprima în puncte de
vedere multiple
Ascultare, nod esenţial în
reţeaua de comunicare
interumană, exercitare de
influenţă
calităţi
rol
“Vânzarea” unei viziuni.
Păstrarea acesteia “în viaţă”
Încrezător şi clar/logic în
exprimare
Luarea periodică a pulsului
tuturor factorilor critici de
ainfluenţă asupra proiectului
arhitectural
Cristina Mîndruţă
Ambiţios şi hotarât
Răbdător (cu măsură)
Rezistent şi flexibil
Sensibil la localizarea şi
fluxul puterii în cadrul
companiei
Arhitecturi pentru sisteme software
Slide 74
Slide 75
Competenţele, rolul şi calităţile arhitectului software
Conducere
competenţe
Autocunoaştere
calităţi
rol
Stabilirea contextului echipei
(viziunea)
Văzut ca lider de ceilalţi dar
şi de el însuşi
Luare de decizii şi asumarea lor
Construire echipe
Motivare
Carismatic şi credibil
Încredere că se poate face
şi că poate conduce efortul
respectiv
Angajat, dedicat, pasionat
Plasarea întregului efort întrun context mai larg atât al
afacerii cât şi personal
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 75
Slide 76
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, 2003
Clements, Kazman, Klein, Evaluating Software Architectures: Methods and
Case Studies, Adison Wesley Longman, 2001
Buschmann F., Menuier R., Rohnert H., Sommerlad P., Stal M., PatternOriented Software Architecture. A System of Patterns, John Wiley & Sons, 1996
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 76
Arhitecturi pentru sisteme software
Curs 1
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
Slide 2
Arhitecturi software - exemple
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Slide 3
Arhitecturi software - exemple
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Slide 4
Arhitecturi software - exemple
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Slide 5
Arhitecturi software - exemple
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Slide 6
Arhitecturi software - exemple
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Slide 7
Arhitecturi software - exemple
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Slide 8
Arhitecturi software - exemple
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
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.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
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 producţie.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
Slide 11
PLAN CURS
Obiectivele cursului
Definiţia şi rolul arhitecturii software
Evoluţia domeniului
Arhitectura software în context
Analiza definiţiei arhitecturii software
Impactul arhitecturii software
Relaţiile de influenţă ale arhitecturii software
Rolul şi calităţile arhitectului software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Slide 12
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 12
Slide 13
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 (potrivire) 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 13
Slide 14
PLAN CURS
Obiectivele cursului
Definiţia şi rolul arhitecturii software
Evoluţia domeniului
Arhitectura software în context
Analiza definiţiei arhitecturii software
Impactul arhitecturii software
Relaţiile de influenţă ale arhitecturii software
Rolul şi calităţile arhitectului software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Slide 15
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 constă din structura sau structurile
sistemului şi conţine elementele software, proprietăţile vizibile din
exterior ale acestora şi relaţiile dintre ele”.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Slide 16
Proiectare arhitecturală
Elemente ale modelului analitic
Informaţii despre domeniul aplicaţiei
Şabloane şi stiluri arhitecturale existente
PROIECTARE ARHITECTURALĂ
Arhitectura aplicaţiei
= Perspectivă de generală asupra software-lui.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
Slide 17
Locul şi rolul arhitecturii software
Proiect de nivel superior al sistemului
Abstractizări la nivel de sistem
Modele reutilizabile la nivel de sistem
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Slide 18
Contextul activităţilor de dezvoltare a arhitecturii
software
http://bredemeyer.com/where.htm
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
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 timpurie a problemelor de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
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 20
Slide 21
Arhitectură software vs. programare
ARHITECTURA SOFTWARE
Interacţiunile dintre părţile
componente
PROGRAMAREA
Implementarea părţilor
componente
Proprietăţile structurale
Proprietăţile computaţionale
Declarativă
Operaţională
În mare parte statică
În mare parte dinamică
Performanţă la nivel de
sistem
“vedere” exterioară a
modulelor
Cristina Mîndruţă
Performanţă la nivel de
algoritm
“vedere” interioară a
modulelor
Arhitecturi pentru sisteme software
Slide 21
Slide 22
PLAN CURS
Obiectivele cursului
Definiţia şi rolul arhitecturii software
Evoluţia domeniului
Arhitectura software în context
Analiza definiţiei arhitecturii software
Impactul arhitecturii software
Relaţiile de influenţă ale arhitecturii software
Rolul şi calităţile arhitectului software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
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 23
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 producţie, 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 24
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 25
Slide 26
PLAN CURS
Obiectivele cursului
Definiţia şi rolul arhitecturii software
Evoluţia domeniului
Arhitectura software în context
Analiza definiţiei arhitecturii software
Impactul arhitecturii software
Relaţiile de influenţă ale arhitecturii software
Rolul şi calităţile arhitectului software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
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 27
Slide 28
Ingineria sistemelor
Principiu: integrarea sistemului (de jos în sus) este posibilă doar pe baza
proiectării (de sus în jos), care începe cu o arhitectură robustă a sistemului.
Modelul SE “Vee” de
proiectare şi
dezvoltare în
ingineria
sistemelor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Slide 29
Ingineria sistemelor
Există cadre standard (ex. TOGAF) care adresază
în general
entităţile,
procesul de inginerie a sistemului,
infrastructura.
Critică:
Nivelul de abstractizare este prea înalt.
NU adresează problemele tehnice de dezvoltare a soluţiei
arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Slide 30
Arhitectură “enterprise”
Arhitectura “enterprise” descrie structurile business şi
procesele care conectează aceste structuri.
Descrierea conţine:
Logica de organizare a procesului business – fluxul informaţiilor şi
activităţile dintre entităţile firmei
Dacă e cazul:
Infrastructura IT ce reflectă cerinţele de integrare şi standardizare
ale modelului de operare al firmei.
În general – cadru ce se referă la documentaţiile implicate în procese.
Există multiple cadre pentru arhitecturi “enterprise” (EAF).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Slide 31
Arhitecturi “enterprise” - exemplu
Enterprise Architecture Framework – John Zachman (IBM).
Orientare business
Orientare tehnică
Implementare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Slide 32
Interese în proiectări arhitecturale
Nivel de abstractizare
Interese cheie în proiectare
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”
Arhitectură sistem
Arhitectură software
Identificarea contextului sistemului
Partiţionare (centrată pe Hw şi infrastrucură)
Identificarea cerinţelor software
Cerinţele funcţionale generale ale sistemului
Integrare şi testare la nivel de sistem
Proiect software de detaliu
Cristina Mîndruţă
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
Caracteristicile limbajului
Eficienţa algoritmilor
Proiectarea structurilor de date
Testarea aplicaţiei software
Implementarea funcţionalităţii
Arhitecturi pentru sisteme software
Slide 32
Slide 33
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 33
Slide 34
Ierarhia proiectării arhitecturale
ENTERPRISE: procesul
business mapat pe o
infrastructură cu
granularitate mare.
SYSTEM: Concentrare pe
cerinţele funcţionale
alocate elementelor fizice.
(sisteme de sisteme)
SOFTWARE: multidemnsională; satisfăcând cerinţe
funcţionale şi non-funcţionale.
Deseori ortogonală în raport cu structurile
sistemului.
Critică în satisfacerea obiectivelor business.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 34
Slide 35
PLAN CURS
Obiectivele cursului
Definiţia şi rolul arhitecturii software
Evoluţia domeniului
Arhitectura software în context
Analiza definiţiei arhitecturii software
Impactul arhitecturii software
Relaţiile de influenţă ale arhitecturii software
Rolul şi calităţile arhitectului software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Slide 36
Arhitectura software - definiţie
“Arhitectura software a unui program sau a unui sistem de calcul
constă din structura sau structurile sistemului şi conţine
elementele software, proprietăţile vizibile din exterior ale
acestor elemente şi relaţiile dintre elemente.”
Proiectarea şi documentarea arhitecturii software sunt
esenţiale în dezvoltarea şi evaluarea produsului software.
Dacă nu se realizează proiectarea arhitecturală, în paralel cu
dezvoltarea produsului software se va dezvolta implicit o
arhitectură. Care ar putea să nu vă placă!!!
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
Slide 37
Arhitectura software - definiţie
Caracteristici ale arhitecturii software:
Abstractizare a sistemului.
Partiţionare declarativă şi asignare de responsabilităţi.
Defineşte elementele şi modul în care sunt acestea relaţionate.
Suprimă detaliile despre comportamentul intern şi informaţiile
locale ale elementelor.
Orice sistem are o arhitectură software (chiar dacă aceasta nu a fost proiectată în
mod deliberat).
Cel mai simplu sistem este compus dintr-un singur element aflat în relaţie cu el
însuşi.
Arhitectura îndeplineşte cerinţele funcţionale şi în acelaşi timp promovează o serie
de calităţi ale sistemului (ex. performană, flexibilitate, etc.).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
Slide 38
Arhitectura software - definiţie
“Arhitectura software a unui program sau a unui sistem de calcul
constă din structura sau structurile sistemului şi conţine
elementele software, proprietăţile vizibile din exterior ale
acestor elemente şi relaţiile dintre acestea.”
Abstractizare a structurilor reale ce compun sistemul software.
Structurile sunt reale
Reprezentările lor sunt abstracte
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
Slide 39
Arhitectura software - definiţie
“Arhitectura software a unui program sau a unui sistem de calcul
constă din structura sau structurile sistemului şi conţine
elementele software, proprietăţile vizibile din exterior ale
acestor elemente şi relaţiile dintre acestea.”
Tipuri de structuri software:
Structură statică - cod, apel metodă/funcţie,…
Structură dinamică - proces/fire de execuţi, flux de date,…
Structură fizică - alocarea sistemului de fişiere, procesor, reţea,
….
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 39
Slide 40
Structură, perspectivă, vedere
Un edificiu trebuie să aibă trei calităţi:
durabilitate (firmitas), utilitate (utilitas),
estetică (venustas).
Marcus Vitruvius Pollio, De architectura
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
Slide 41
Structură, perspectivă, vedere
O vedere din perspectivă
dinamică
O vedere din perspectivă
statică
Vedere (view) – o reprezentare a unei structuri,
văzută dintr-o anumită perspectivă.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
Slide 42
Structură, perspectivă, vedere
Perspectiva FIZICĂ
Vederi ale alocărilor:
•calculatoare
•dispozitive
•reţele
Perspectiva STATICĂ
Vederi ale modulelor:
•clase
•funcţii
•interfeţe
Perspectiva DINAMICĂ
Vederi ale componentelor şi
conectorilor:
•procese
•diagrame de secvenţe
•flux de date
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
Slide 43
Arhitectura software - definiţie
“Arhitectura software a unui program sau a unui sistem de calcul
constă din structura sau structurile sistemului şi conţine
elementele software, proprietăţile vizibile din exterior ale
acestor elemente şi relaţiile dintre acestea.”
Element – “parte” a unui sistem.
Perspectiva
STATICĂ
DINAMICĂ
FIZICĂ
Cristina Mîndruţă
Tipuri de elemente
clase, fişiere, ...
fire de execuţie, flux de date, control, ...
calculatoare, dispozitive, reţele, ...
Arhitecturi pentru sisteme software
Slide 43
Slide 44
Arhitectura software - definiţie
“Arhitectura software a unui program sau a unui sistem de calcul
constă din structura sau structurile sistemului şi conţine
elementele software, proprietăţile vizibile din exterior ale
acestor elemente şi relaţiile dintre acestea.”
Proprietăţi funcţionale : asignarea de responsabilităţi elementelor este o
parte esenţială a proiectării arhitecturale.
Proprietăţi non-funcţionale : cerinţele de calitate pentru sistem şi
componentele sale.
Tipurile de proprietăţi vizibile depinde de perspectiva asupra sistemului.
Exemplu:
•Perspectivă statică – modificabilitatea
•Perspectivă dinamică - performanţa
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
Slide 45
Arhitectura software - definiţie
“Arhitectura software a unui program sau a unui sistem de calcul
constă din structura sau structurile sistemului şi conţine
elementele software, proprietăţile vizibile din exterior ale
acestor elemente şi relaţiile dintre acestea.”
•Elementele interacţionează prin interfeţe care împart detaliile în părţi
publice şi părţi private.
•Aceste interacţiuni formează relaţiile dintre elementele arhitecturale.
•Arhitectura se ocupă doar cu partea publică a acestei partiţionări.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
Slide 46
Arhitectura software - definiţie
“Arhitectura software a unui program sau a unui sistem de calcul
constă din structura sau structurile sistemului şi conţine
elementele software, proprietăţile vizibile din exterior ale
acestor elemente şi relaţiile dintre acestea.”
Tipurile de relaţii depind de tipurile de elemente, care depind la rândul lor
de perspectivă.
Exemple:
uses
uses
Modul B
Proces X
date
Proces Y
Modul C
Vedere din perspectivă STATICĂ
Elemente: module
Relaţii: uses
Cristina Mîndruţă
date
date
Modul A
Vedere din perspectivă DINAMICĂ
Elemente: procese
Relaţii: flux de date
Arhitecturi pentru sisteme software
Slide 46
Slide 47
PLAN CURS
Obiectivele cursului
Definiţia şi rolul arhitecturii software
Evoluţia domeniului
Arhitectura software în context
Analiza definiţiei arhitecturii software
Impactul arhitecturii software
Relaţiile de influenţă ale arhitecturii software
Rolul şi calităţile arhitectului software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
Slide 48
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 48
Slide 49
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 49
Slide 50
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ă:
• Serveşte ca vehicol de comunicare
• Ghidează deciziile iniţiale de proiectare
• Reduce riscul
• Ajută la managementul proiectului/produsului
• Facilitează reutilizarea
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Slide 51
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.
PERFORMANŢĂ – evitare gâtuiri, cuplare strânsă a
elementelor, limitare 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.
SCALABILITATE – consolidarea, localizarea şi
centralizarea resurselor de câte ori e posibil.
Cristina Mîndruţă
Proiectul arhitectural şi documentaţia asociată:
• Serveşte ca vehicol de comunicare
• Ghidează deciziile iniţiale de proiectare
• Reduce riscul
• Ajută la managementul proiectului/produsului
• Facilitează reutilizarea
Arhitecturi pentru sisteme software
Slide 51
Slide 52
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 timpurie.
Proiectul arhitectural şi documentaţia asociată:
• Serveşte ca vehicol de comunicare
• Ghidează deciziile iniţiale de proiectare
• Reduce riscul
• Ajută la managementul proiectului/produsului
• Facilitează reutilizarea
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
Slide 53
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ă:
•
•
•
•
•
Cristina Mîndruţă
Serveşte ca vehicol de comunicare
Ghidează deciziile iniţiale de proiectare
Reduce riscul
Ajută la managementul proiectului/produsului
Facilitează reutilizarea
Arhitecturi pentru sisteme software
Slide 53
Slide 54
Impactul arhitecturii software
Facilitează reutilizarea de elemente cu granularitate mare.
Exemple:
•
Componente (ex. baze de date, COTS)
•
Cadre de dezvoltare (ex. J2EE)
•
Linii de producţie (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ă:
• Serveşte ca vehicol de comunicare
• Ghidează deciziile iniţiale de proiectare
• Reduce riscul
• Ajută la managementul proiectului/produsului
• Facilitează reutilizarea
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 54
Slide 55
PLAN CURS
Obiectivele cursului
Definiţia şi rolul arhitecturii software
Evoluţia domeniului
Arhitectura software în context
Analiza definiţiei arhitecturii software
Impactul arhitecturii software
Relaţiile de influenţă ale arhitecturii software
Rolul şi calităţile arhitectului software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 55
Slide 56
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 ciclul poate ajuta compania săşi gestioneze afacerea, organizarea şi arhitectura.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 56
Slide 57
ABC - Factorii ce influenţează arhitectura software
Cristina Mîndruţă
Părţile interesate în sistem
Firma ce dezvoltă sistemul
Contextul tehnologic
Cunoştinţele şi experienţa arhitectului
Arhitecturi pentru sisteme software
Slide 57
Slide 58
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 timpurie 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 58
Slide 59
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 59
Slide 60
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 60
Slide 61
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 61
Slide 62
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 62
Slide 63
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 63
Slide 64
ABC - Factorii influenţaţi de arhitectura software
Arhitectul divizează sistemul în componente majore şi unităţi de
lucru.
•Structura şi obiectivele firmei dezvoltatoare
•Cerinţele beneficiarilor
•Experienţa arhitectului
modelează firma prin partiţionarea forţei de muncă
•Tehnologia
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
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 64
Slide 65
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 65
Slide 66
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 66
Slide 67
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 67
Slide 68
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 68
Slide 69
ABC - exemplu
Vezi lab1: TheLutherArchitecture.pdf
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 69
Slide 70
PLAN CURS
Obiectivele cursului
Definiţia şi rolul arhitecturii software
Evoluţia domeniului
Arhitectura software în context
Analiza definiţiei arhitecturii software
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 70
Slide 71
Competenţele, rolul şi calităţile arhitectului software
Tehnologie
competenţe
Î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
Modelare
Analiza compromisurilor
Prototipare/experimentare/
simulare
Creativ
Capabil de investigaţie
Practic/pragmatic
Patrunzător
Pregătirea documentelor şi
prezentărilor arhitecturii
software
Analiza tendinţelor
tehnologice
Tolerant faţă de ambiguităţi,
dispus la reluări, în căutare
de soluţii multiple
Capacitate de a lucra pe
nivel abstract
Un punct de vedere asupra
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 71
Slide 72
Competenţele, rolul şi calităţile arhitectului software
Consultanţă
competenţe
Tehnici de a obţine şi
provoca informaţii
calităţi
rol
Crearea unei relaţii de
încredere în consultant
Angajat în succesul altora
Empatic, abordabil
Metode cadru de
consultare
Cunoscător al proceselor
(business, software,
management)
Î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
Practic/pragmatic
Agent de schimb eficient
Bun mentor
Mentor pentru arhitecţii
juniori
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 72
Slide 73
Competenţele, rolul şi calităţile arhitectului software
Strategie
competenţe
calităţi
rol
Strategia şi raţiunile
Influenţatea strategiei
fundamentale ale companiei afacerii
Vizionar
Antreprenorial
Competitorii (produse,
strategii, procese)
Traducerea strategiei
afacerii în viziune şi
strategie tehnică
Practica business a
companiei
Î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
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 73
Slide 74
Competenţele, rolul şi calităţile arhitectului software
Politici oganizaţionale
competenţe
Care sunt jucătorii cheie
în companie
Comunicare
Ce doresc aceştia pe
planul afacerii şi pe plan
personal
Abilitatea de a vedea din
puncte de vedere multiple şi
de a exprima în puncte de
vedere multiple
Ascultare, nod esenţial în
reţeaua de comunicare
interumană, exercitare de
influenţă
calităţi
rol
“Vânzarea” unei viziuni.
Păstrarea acesteia “în viaţă”
Încrezător şi clar/logic în
exprimare
Luarea periodică a pulsului
tuturor factorilor critici de
ainfluenţă asupra proiectului
arhitectural
Cristina Mîndruţă
Ambiţios şi hotarât
Răbdător (cu măsură)
Rezistent şi flexibil
Sensibil la localizarea şi
fluxul puterii în cadrul
companiei
Arhitecturi pentru sisteme software
Slide 74
Slide 75
Competenţele, rolul şi calităţile arhitectului software
Conducere
competenţe
Autocunoaştere
calităţi
rol
Stabilirea contextului echipei
(viziunea)
Văzut ca lider de ceilalţi dar
şi de el însuşi
Luare de decizii şi asumarea lor
Construire echipe
Motivare
Carismatic şi credibil
Încredere că se poate face
şi că poate conduce efortul
respectiv
Angajat, dedicat, pasionat
Plasarea întregului efort întrun context mai larg atât al
afacerii cât şi personal
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 75
Slide 76
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, 2003
Clements, Kazman, Klein, Evaluating Software Architectures: Methods and
Case Studies, Adison Wesley Longman, 2001
Buschmann F., Menuier R., Rohnert H., Sommerlad P., Stal M., PatternOriented Software Architecture. A System of Patterns, John Wiley & Sons, 1996
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 76