Arhitecturi PT Sisteme Sofware

Cristina Mndru 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
Arhitecturi software - exemple
Concluzie
Probleme ale descrierilor naive ale arhitecturii software
Text informal i diagrame de tip box-and-lines.
Intuitive
Precizie slab
Rareori formalizat
O soluie : Dezvoltarea ARHITECTURAL a sistemelor software i
descrierea formal a structurii acestora.
Dezvoltarea arhitectural a sistemelor software
Compunerea sistemelor din pri componente.
Asigurarea conformitii sistemului cu arhitectura i cu
proprietile dorite.
Utilizare arhitecturi standard pentru integrare.
Reutilizare.
Reducere costuri utiliznd linii de produse.
Dezvoltarea arhitectural a sistemelor software
Compunerea sistemelor din pri componente.
Asigurarea conformitii sistemului cu arhitectura i cu
proprietile dorite.
Utilizare arhitecturi standard pentru integrare.
Reutilizare.
Reducere costuri utiliznd linii de produse.
PLAN CURS
Obiectivele cursului
Definiia i rolul arhitecturii software
Evoluia domeniului
Arhitectura software n context
Impactul arhitecturii software
Relaiile de influen ale arhitecturii software
Rolul i calitile arhitectului software
Obiectivele cursului - 1
Rolul arhitecturii software n procesul de dezvoltare a software-lui.
Recunoaterea principalelor stiluri i abloane arhitecturale.
Descrierea cerinelor astfel nct arhitectura s poat fi evaluat.
nelegerea principiilor unei bune documentaii arhitecturale.
nelegerea modului de incorporare a COTS i middleware n
proiectele arhitecturale.
Generarea de alternative arhitecturale pentru o problem i
alegerea uneia dintre ele.
Obiectivele cursului - 2
Proiectarea i construirea unui sistem de dimensiuni medii care
satisface o specificaie arhitectural
nelegerea modului n care notaiile formale pot fi utilizate
pentru a specifica arhitecturi.
Evaluarea adecvrii unei arhitecturi date n ndeplinirea unui
set de cerine sistem i echilibrarea compromisurilor asupra
calitii.
Cunoaterea tendinelor de viitor n domeniul arhitecturilor
software.
PLAN CURS
Evoluia domeniului
Arhitectur software - Definiie
Definiii la:
http://www.sei.cmu.edu/architecture/start/definitions.cfm
Definiia adoptat la acest curs:
Arhitectura software a unui sistem de calcul este setul structurilor
unui sistem necesare pentru a realiza raionamente referitoare la
acesta, structuri coninnd elementele software, relaiile dintre
acestea i proprietile vizibile din exterior ale ambelor.
Clements, Bachmann, Bass, Garlan, Ivers, Little, Nord, Stafford, Documenting Software
Architectures: Views and Beyond, Addison Wesley Longman, 2010
Proiectare arhitectural
Informaii despre domeniul aplicaiei
PROIECTARE ARHITECTURAL
Arhitectura aplicaiei
= Perspectiv general asupra software-lui.
Elemente ale modelului analiz
abloane i stiluri arhitecturale existente
Locul i rolul arhitecturii software
Proiect de nivel superior al sistemului
Abstractizri la nivel de sistem
Modele reutilizabile la nivel de sistem
Rspunde cerinelor de comportament i de calitate
Importana arhitecturii software
Reducerea costurilor de dezvoltare i de mentenan
clarificarea structurii sistemului pe diferite nivele
reutilizare
Creterea calitii produsului software
clarificarea cerinelor
explicitarea deciziilor, realizate pe baz de principii, i a
implicaiilor lor
analize la nivel de sistem
analiza precoce a problemelor de proiectare
Importana arhitecturii software reducerea costurilor
de mentenan
Aproape 50% din efortul de mentenen este
investit n analiza i nelegerea codului i
documentaiei existente.
Arhitectur software vs. programare
PROGRAMAREA
Implementarea prilor
componente
Proprietile computaionale
Operaional
n mare parte dinamic
Performan la nivel de
algoritm
vedere interioar a
modulelor
ARHITECTURA SOFTWARE
Interaciunile dintre prile
componente
Proprietile structurale
Declarativ
n mare parte static
Performan la nivel de
sistem
vedere exterioar a
modulelor
PLAN CURS
Evoluia domeniului
Evoluia 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
Recunoaterea importanei arhitecilor n companiile de
dezvoltare de software
Procese software ce includ revizuiri ale arhitecturii i
documentaie arhitectural explicit
Utilizare de linii de produse, de standarde arhitecturale, de
cadre pentru integrare de componente
Codificarea vocabularului, notaii i instrumente pentru proiectare
arhitectural
Cri i cursuri de arhitecturi software
ncorporarea notaiilor 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)
PLAN CURS
Evoluia domeniului
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 interaciunile unui sistem complet precum
i contribuia acestora la scopul sistemului
Include identificarea i caracterizarea elementelor sistemului,
fr a descrie substructurile acestor elemente.
Interese n proiectri arhitecturale
Caracteristicile limbajului
Eficiena algoritmilor
Proiectarea structurilor de date
Testarea aplicaiei software
Implementarea funcionalitii
Proiect software non-
arhitectural
Identificarea atributelor de calitate
Cerinele funcionale pentru software
Partiionarea aplicaiilor software
Integrare i testare la nivel de software i de sistem
Arhitectur software
Identificarea contextului sistemului
Partiionare (centrat pe Hw i infrastructur)
Identificarea cerinelor software
Cerinele funcionale generale ale sistemului
Integrare i testare la nivel de sistem
Arhitectur sistem
Procese business i modele operaionale
Date business
Structur i relaii organizaionale
Prile interesate n afacere (stakeholders)
Infrastructura IT
Arhitectur enterprise
Interese cheie n proiectare Nivel de abstractizare
Ierarhia proiectrii arhitecturale
Principii:
Interese diferite pe nivele diferite
Deciziile de pe nivelele superioare impun constrngeri nivelelor
inferioare
Nivelul superior transfer responsabilitatea detalierii ctre
nivelul inferior
Ierarhia proiectrii arhitecturale
ENTERPRISE: procesul
business mapat pe o
infrastructur cu
granularitate mare.
SISTEM: Concentrare pe
cerinele funcionale
alocate elementelor fizice.
(sisteme de sisteme)
SOFTWARE: multidemnsional; satisfcnd
cerine funcionale i de calitate.
Deseori ortogonal n raport cu structurile
sistemului.
Critic n satisfacerea obiectivelor business.
PLAN CURS
Evoluia domeniului
Atributele de calitate (modificabilitate, disponibilitate,
performan, etc.) sunt dependente de design.
Gndirea arhitectural este gndire strategic.
O arhitectur software proiectat deliberat i bine documentat
ofer valoare proiectului i firmei ce dezvolt software-ul.
Proiectul arhitectural i documentaia asociat:
servesc ca vehicol de comunicare
ghideaz deciziile iniiale de proiectare
reduc riscul
ajut la managementul proiectului/produsului
faciliteaz reutilizarea
Documentaia arhitecturii ofer un cadru de referin n care pot fi
expuse i negociate interese concurente.
Permite:
Negocierea cerinelor tuturor prilor interesate
Realizarea de informri asupra progresului
Alocare de resurse i ghidarea construirii produsului software
Documentaia trebuie s fie:
DESCRIPTIV - pentru comunicare
PRESCRIPTIV - pentru proiectani i pentru
implementatori.
Servesc ca vehicol de comunicare
Ghideaz deciziile iniiale de proiectare
Reduc riscul
Ajut la managementul proiectului/produsului
Faciliteaz reutilizarea
Arhitectura face trecerea de la specificarea cerinelor (ce?) la
ndeplinirea acestora (cum?).
Arhitectul poate prezice calitile sistemului prin studierea
abstractizrilor arhitecturale ale acestuia.
Deciziile arhitecturale influeneaz proprietile sistemului n
moduri cunoscute
Proiectul arhitectural poate fi analizat i utilizat pentru a prezice
n ce msur vor fi obinute proprietile ateptate de la sistem.
Reduc riscul
PERFORMAN evitare gtuiri, cuplare strns a
elementelor, limitarea cantitii i frecvenei comunicrilor
distribuite i ntre elemente
MODIFICABILITATE centrare pe responsabilitile
elementelor, decuplarea elementelor, localizarea
responsabilitilor, minimizarea i simplificarea
dependenelor ntre elementele sistemului.
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
servete ca echipament de testare suport pentru
prototipare, integrare, testare precoce.
Reduc riscul
Permite realizarea de estimri mai precise ale costurilor i planului de timp.
Estimrile se bazeaz pe elementele arhitecturii
Echipa responsabil pentru un anume element ofer estimrile pentru acesta
Managerii de proiect integreaz estimrile i rezolv dependenele i
conflictele
Util n managementul modificrilor.
Permite prilor interesate s judece i s gestioneze modificrile la sistem
pe toat durata de via a acestuia (aprox. 80% din efort are loc dup dezvoltarea i
punerea iniial n funciune a sistemului).
Arhitectura mparte modificrile n trei clase:
Locale un singur element
Non-locale mai multe elemente
Arhitecturale modificri la topologia sistemului sau la mecanismele de comunicare
i coordonare.
Ofer nelegere i cunoatere ptrunztoare de-a lungul ntregului ciclu de
via al sistemului. Proiectul arhitectural i documentaia asociat:
Reduc riscul
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 urmtoarele dezavantaje:
Este costisitor i dificil de gsit funciile, metodele sau procedurile cele mai
potrivite
Este dificil de determinat proprietile motenite n aceste module.
Reduc riscul
PLAN CURS
Evoluia domeniului
Ciclul business al arhitecturii (ABC)
Relaiile dintre obiectivele afacerii, cerinele produsului,
experiena arhitectului, arhitecturi i sisteme formeaz un
ciclu.
Arhitectura software este influenat de o serie de factori.
Arhitectura software i sistemul dezvoltat pe baza ei influeneaz, la
rndul ei, aceti factori.
n centrul acestui ciclu st arhitectul software.
nelegerea i analiza acestui ciclu poate ajuta compania s-i
gestioneze afacerea, organizarea i arhitectura.
ABC - Factorii ce influeneaz arhitectura software
Prile interesate n sistem
Firma ce dezvolt sistemul
Contextul tehnologic
Cunotinele i experiena arhitectului
Stakeholder-i (clieni, utilizatori, dezvoltatori, manageri, personal de
ntreinere, 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 organizaionale i proprietile la nivelul business ale sistemului
sunt rareori nelese i cu att mai puin bine exprimate arhitectul
trebuie s joace un rol activ n identificarea i angajarea precoce a
stakeholder-ilor n ciclul de dezvoltare.
Clase de influene organizaionale:
Afacerea imediat
Firma poate avea o investiie n anumite bunuri, cum ar fi arhitecturi existente i
produsele bazate pe acestea.
Afacerea pe termen lung
Arhitectura poate fi nucleul unei investiii pe termen lung n infrastructur, pentru
ndeplinirea obiectivelor strategice ale firmei.
Structura organizaional
Structura organizaional poate modela arhitectura a.. diviziunile de funcionalitate
se aliniaz la unitile de expertiz existente.
Contextul tehnologic existent n momentul elaborrii arhitecturii.
Include:
Limbaje
Instrumente
Sisteme de operare
Platforme de calcul
Cadre de implementare
Practici industriale standard i tehnici de inginerie software
Arhitecii iau decizii de proiectare pe baza experienei lor.
Experienele reuite conduc la replicarea proiectelor care au mers bine
Experienele nereuite vor fi evitate n noile proiecte, chiar dac
metodele, tehnicile i/sau tehnologiile ce au codus la acestea ar putea
funciona bine n alte proiecte
Alegerile pe care le face un arhitect sunt influenate de experiena, de
instruirea (training) i de educaia sa formal (n acest ordine!).
ABC - Factorii influenai de arhitectura software
Arhitectura i sistemul dezvoltat
pe baza acesteia vor
influena:
Structura i obiectivele
firmei dezvoltatoare
Cerinele beneficiarilor
Experiena arhitectului
Tehnologia
Arhitectul divizeaz sistemul n componente majore i uniti de
lucru.
modeleaz firma prin partiionarea forei de munc

ajut la stabilirea unui vocabular de comunicare
baz pentru WBS, utilizat n planificare, urmrire i bugetare
organizare n scopul gestionrii configuraiilor
organizare n scopul elaborrii documentaiei
baz pentru integrare i testare
Arhitectul definete elementele software ce trebuie implementate i
integrate. Acestea devin baz pentru:
alocare talente, recrutare, formare echip
activiti de dezvoltare, testare i integrare
estimare i alocare resurse
planuri de timp, bugete, urmrire proiect i supraveghere
Structura i obiectivele firmei dezvoltatoare
Tehnologia
Arhitecturile pot influena obiectivele unei firme
deoarece:
Un sistem de succes construit pe baza unei anumite arhitecturi
poate permite unei companii s pun stpnire pe o anumit
zon de pia
Arhitectura poate oferi oportuniti pentru producere eficient i
punere n funciune de sisteme similare.
Tehnologia
Pe baza cunotinelor despre sisteme similare clienii 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.
Clienii vor cere arhitecturi de calitate n sistemele viitoare
Pe baza cunotinelor despre sistemul dezvoltat clienii i vor modifica
cerinele sistem n raport cu disponibilitii sistemelor
i elementelor existente.
Tehnologia
Dezvoltarea unei arhitecturi mbogete experiena arhitectului.
Tehnologii, instrumente, metode ce au fost utilizate n
dezvoltarea de sisteme reuite conduc la crearea de sisteme
viitoare n aceeai manier.
Arhitectura unui sistem euat este evitat n proiecte viitoare.
Tehnologia
Ocazional, un sistem sau o arhitectur vor modifica stadiul actual
al tehologiei.
Exemple:
generatoare de compilatoare
baze de date relaionale
foi de calcul
sisteme de operare cu interfee grafice
WWW
Java
Tehnologia
PLAN CURS
Evoluia domeniului
Competenele, rolul i calitile arhitectului software
Tehnologie
Creativ
Capabil de investigaie
Practic/pragmatic
Patrunztor
Tolerant fa de ambiguiti,
dispus la reluri, n cutare
de soluii multiple
Capacitate de a lucra pe
nivel abstract
Modelare
Analiza compromisurilor
Prototipare/experimentare/
simulare
Pregtirea documentelor i
prezentrilor arhitecturii
software
Analiza tendinelor
tehnologice
Un punct de vedere asupra
sistemului
nelegerea profund a
domeniului i tehnologiilor
pertinente
Posibilitatea de a decela
elementele tehologice care
reprezint cheia succesului
Metode de dezvoltare i
tehnici de modelare
caliti rol competene
Consultan
Angajat n succesul altora
Empatic, abordabil
Practic/pragmatic
Agent de schimb eficient
Bun mentor
Crearea unei relaii de
ncredere n consultant
nelegerea a ceea ce
doresc i au nevoie
dezvoltatorii de la
arhitectur
Ajut dezvoltatorii s vad
valoarea arhitecturii i s
neleag cum o pot utiliza
cu succes
Mentor pentru arhitecii
juniori
Tehnici de a obine i
provoca informaii
Metode cadru de
consultare
Cunosctor al proceselor
(business, software,
management)
Strategie
Vizionar
Antreprenorial
Influenarea strategiei
afacerii
Traducerea strategiei
afacerii n viziune i
strategie tehnic
nelegerea clientului i a
tendinelor din pia
Capturarea n arhitectur a
cerinelor clientului, a celor
organizaionale i a
cerinelor business
Strategia i raiunile
fundamentale ale companiei
Competitorii (produse,
strategii, procese)
Practica business a
companiei
Politici oganizaionale
Abilitatea de a vedea din
puncte de vedere multiple i
de a exprima n puncte de
vedere multiple
ncreztor i clar/logic n
exprimare
Ambiios i hotart
Rbdtor (cu msur)
Rezistent i flexibil
Sensibil la localizarea i
fluxul puterii n cadrul
companiei
Comunicare
Ascultare, nod esenial n
reeaua de comunicare
interuman, exercitare de
influen.
Vnzarea unei viziuni.
Pstrarea acesteia n via.
Luarea periodic a pulsului
tuturor factorilor critici de
influen asupra proiectului
arhitectural.
Care sunt juctorii cheie
n companie
Ce doresc acetia pe
planul afacerii i pe plan
personal
Conducere
Vzut ca lider de ceilali dar
i de el nsui.
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, att al
afacerii ct i personal.
Stabilirea contextului echipei
(viziunea)
Luare de decizii i asumarea lor
Construire echipe
Motivare
Autocunoatere
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

Arhitecturi PT Sisteme Sofware

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Arhitecturi PT Sisteme Sofware

Încărcat de

Drepturi de autor:

Formate disponibile

Cristina Mndru Arhitecturi pentru sisteme software Slide 1

Arhitecturi pentru sisteme software

modeleaz firma prin partiionarea forei de munc

S-ar putea să vă placă și