Transcript PPTX - Matematikos ir Informatikos fakultetas

Donatas Čiukšys
Visorių informacinių technologijų parkas
2010-09-29
Apie pranešėją
 Nuo 1996 m.:
 programuotojas, projektuotojas, architektas UAB
„MitSoft“
 Nuo 2000 m.:
 lektorius Vilniaus universitete, Matematikos ir
informatikos fakultete, Programų sistemų katedroje

http://www.mif.vu.lt
 nuo 2004 m. magistrantams skaitau kursą „Programų
sistemų architektūra ir projektavimas“

http://www.mif.vu.lt/~donatas/
2
Mano supratimą apie architektūrą
formavo:
 Knygos:
 Software Systems Architecture. Working
with Stakeholders Using Viewpoints and
Perspectives, Nick Rozanski, Eoin Woods.
Addison-Wesley, 2005
 Software Architecture in Practice, Second Edition,
Len Bass, Paul Clements, Rick Kazman, 2003
 Software Engineering Institute (SEI) Carnegie
Mellon University (CMU) darbuotojų
straipsniai
 Len Bass, Paul Clements, Rick Kazman
 Daugiau šaltinių:
http://www.mif.vu.lt/~donatas/PSArchitektura
Projektavimas/Teorija.html
3
Architektūros kaip tyrimų krypties
raida
(Pagal straipsnį: “The Golden Age of Software Architecture”)
4
Apžvalga
Teorija
Procesas
Archetipai, architektūros stiliai
Modeliai, struktūros ir vaizdai
Požiūriai (viewpoints)
Kokybinės charakteristikos
Taikomoji architektūra (application architecture),
Dalykinė architektūra (domain-specific architecture)
...
Krioklio/iteratyvus
RUP, UP, Iconix, XP, Scrum, ...
Dalykinės srities modelis (domain model),
scenarijai, reikalavimų specifikacija,
architektūros dokumentacija,
projektinė dokumentacija, testavimo scenarijai,
išeities tekstai, ...
Socialiniai aspektai
Programų sistemų
architektūra
Diplomatija
Konfliktų sprendimas
Lyderio vaidmuo (team leader)
...
Technologijos (software)
Technologijos (hardware)
UI kūrimo platformos: NetBeans platform, Eclipse RCP
(rich client platform)
Karkasai: Web karkasai, programų sistemų kūrimo
karkasai, ...
Java EE: (JSF, EJB, JPA, JMS, Web Services, ...)
.NET: (ASP.NET MVC, WCF, EntityFramework, Messaging,
Web Services, ...)
DBVS: reliacinės, objektinės, objektinės-reliacinės, XML, …
...
Tinklo įranga: ugniasienės, maršrutizatoriai,
load-balancers, ...
Serverinė įranga: serveriai, Network
attached storage (NAS), Storage area
network (SAN), ...
Virtualizacija (VMWare, Xen, VirtualPC, ...)
...
5
Architektai kuria architektūrą
Socialiniai
aspektai
architects
(žmonės)
Programų sistemų
kūrimo proceso
aspektai
architect
(procesas)
UML, našumas, saugumas,
pasiekiamumas,
technologijos, ...
architectures
(architektūra)
6
Specialybė - architektas
 Karjera IT kompanijoje:
 Tinklų prižiūrėtojas , programuotojas, ...,
projektuotojas, ..., architektas, ..., projekto vadovas, ...
 Architekto atsakomybė (supaprastintai): žinant
reikalavimus sistemai, nuspręsti:
 kaip ir į kokias dalis sistemą skaidyti,
 kokias technologijas/įrankius parinkti dalių realizacijai
 kaip dalys bus jungiamos tarpusavyje

išskirstyta sistema ar ne, kokie komunikavimo protokolai
7
Specialybė - architektas
 Kas įtakoja šiuos sprendimus?
 Funkciniai reikalavimai (akivaizdu)
 Nefunkciniai (kokybiniai) reikalavimai

Našumas, saugumas, pasiekiamumas, modifikuojamumas, ...
 Integracijos su egzistuojančiomis sistemomis poreikis
 IT kompanijos vidaus standartai
 Dirbant su kokiomis technologijomis/įrankiais yra sukaupta
daugiausia patirties?
 Biudžetas ir sistemos sukūrimo terminai
 Dažnai prieštarauja užsakovų išsakytiems reikalavimams
(ypač nefunkciniams) – nori gerai, greitai ir pigiai 
8
Specialybė - architektas
 Projektuotojai paprastai atsakingi už projektinius
sprendimus, kurie įtakoja vieną ar kelis sistemos
modulius/posistemius
 Architektas atsakingas už projektinius sprendimus, kurie
įtakoja visą sistemą
 Būtinos žinios iš praktiškai visų informatikos sričių – tiek apie
vartotojo interfeiso kūrimą, tiek apie DBVS (ir ne tik
reliacines), tiek apie OOAP (objektiškai orientuotą analizę ir
projektavimą),

galima tęsti toliau: karkasai, portalai, duomenų saugyklos
(warehouse), verslo procesai ir jų automatizavimas, klasteriai, diskų
masyvai, ...
 Būtina nuolat sekti technologines naujienas ir gebėti jas
palyginti su jau egzistuojančiomis
9
Architektas ir kiti projekto dalyviai
Užsakovas
Sisteminis
analitikas
Projekto
vadovas
Architektas
Projektuotojai/
programuotojai
Dalykiniai/techniniai
ekspertai/architektai
10
Užsakovas, sisteminis analitikas ir
architektas
 Nors yra svarbu suprasti santykinę reikalavimų vertę įmonės
verslui (tą išmano sisteminis analitikas), tačiau ne mažiau
svarbu atsižvelgti ir į reikalavimų įgyvendinimo kaštus ir
rizikas
 Ypač nefunkcinių reikalavimų
 Nefunkcinių reikalavimų įgyvendinimo kaštus ir rizikas gali
būti sunku įvertinti dėl sisteminio analitiko žemo ar
neadekvataus technologinių žinių lygio
 Aišku, yra sisteminių analitikų, kurie ir profesionaliai atlieka
(nefunkcinių) reikalavimų analizę, ir puikiai išmano
technologijas, tačiau tai dažniau išimtis, nei taisyklė
 Architektas ir yra tas technologijas išmanantis specialistas,
kuris gali įvertinti nefunkcinių reikalavimų įgyvendinimo
parinktomis technologijomis kaštus bei laiko sąnaudas
11
Architektas ir projektuotojas
 Kaip aprėpti visą sistemą – taikyti “skaldyk ir valdyk” principą
 Kaip smulkiai skaldyti?
 Klasė (OOP prasme), komponentas
 ...
 Tipinis projektavimo sprendimas
(angl. design pattern)
Projektuotojo
 ...
atsakomybė
 Karkasas (angl. framework)
 ...
 Posistemis, modulis
Architekto
 ...
atsakomybė
 Archetipai, architektūriniai stiliai
 ...
 Architektūra
12
Architektas ir projekto vadovas
 Architektas projekto vadovui teikia nefunkcinių
reikalavimų įgyvendinimo kaštų ir rizikų įverčius
 Jei kliento pageidaujamas sistemos pakeitimas (change
request) įtakoja didelę sistemos dalį, architektas
gali/turi įvertinti pasekmes/kaštus/rizikas
13
Architektas ir ekspertai
 Architektas turi turėti akiračio platumą, bet nebūtinai
gilumą
 Turi apimti visą sistemą
 Jei specifinėse srityse architektui trūksta
kompetencijos, jis konsultuojasi su tos srities
ekspertais/architektais, pvz.:
 saugumo ekspertai,
 duomenų architektai (darbo su dideliais duomenų
kiekiais organizavimas/optimizavimas),
 ir pan.
14
Pvz.: duomenų
architekto sritis
 Data
Management
Body of
Knowledge
 http://www.dama.or
g/i4a/pages/index.cf
m?pageid=3364
15
Sąvokų sistema
Architektūrinis
elem entas
2..*
riša
1..*
Tarpelem entis
ryšys
1..*
1..*
susideda
susideda
Architektūros
kūrim o
procesas
pasako,
kaip projektuoti
Architektūra
Program ų
sistem a
turi
1
1
vykdo
projektuoja
tenkina poreikius
gali būti dokumentuota
0..*
Architektas
sukuria
1..*
dokumentuoja
architektūrą
Architektūrinis
aprašas
1..*
išsiaiškina interesus
Suinteresuotas
asm uo
1..*
1..*
turi
susideda
1..*
1..*
Požiūris
atitinka
Vaizdas
0..*
1
atsižvelgia
1..*
0..*
Interesas
1..*
1..*
yra įtakojamas
Sinonimas:
kokybinė
charakteristika
0..*
atsižvelgia
Perspektyva
1..*
16
Požiūriai: 4+1 vaizdo modelis (1995)
17
Dažniausiai naudojami požiūriai
 Praėjus 10 metų po 4+1 vaizdo modelio sukūrimo (1995m.),
Nick Rozanski ir Eon Woods pasiūlė tokį požiūrių rinkinį:
Funkcinis požiūris
Informacinis požiūris
Lygiagrečių procesų požiūris
Konstravimo požiūris
Dislokavimo požiūris
Operacinis požiūris
18
Dažniausiai reikalaujamos kokybinės
charakteristikos (perspektyvos)
 Saugumas – užtikrina priėjimo prie sistemos resursų
kontrolę,
 Našumas ir skaliuojamumas – padeda pasiekti
reikiamą sistemos našumą ir užtikrina, kad sistema
tinkamai reaguos į didėjantį apkrovimą,
 Pasiekiamumas ir patikimumas/stabilumas – užtikrina
sistemos pasiekiamumą reikiamu laiku reikiamam
naudotojų skaičiui bei apibrėžia, kaip sistema tvarkysis
su gedimais,
 Evoliucija (=modifikuojamumas) – užtikrina, kad
sistemoje bus galima nesunkiai padaryti pakeitimus
19
Priėmimas
Integracija
Kodavimas/
testavimas
Projektavimas
Reikalavimų analizė
Architekto įtraukimo
į projektą laipsnis
Architekto užimtumas projekte
Laikas
20
Architektui reikalingi įgūdžiai
 Žemiau išvardinti pagrindiniai įgūdžiai, kuriais turi
pasižymėti žmogus, ketinantis tapti architektu:
 Bent paviršutinis visų šiuolaikinių technologijų
išmanymas
 Patirtis projektuojant ir kuriant programų sistemas
 Gebėjimas greitai perprasti naujas žinias, susijusias su
nepažįstamomis dalykinėmis sritimis
 Komunikabilumas, gebėjimas susišnekėti su įvairų
techninį išsilavinimą turinčiais žmonėmis, gebėjimas
išreikšti mintis jų sąvokų sistema, o ne savo
21
Architekto atsakomybės
 Užtikrinti, kad programų sistemos apimtis (angl. scope) ir







ribojimai yra dokumentuoti ir pripažinti suinteresuotų asmenų
Identifikuoti ir įtraukti į projektą svarbius suinteresuotus
asmenis
Padėti priimti sistemos lygio projektinius sprendimus,
užtikrinant, kad jų priėmimui yra turima visa reikalinga
informacija ir kad šie sprendimai atitinka suinteresuotų asmenų
poreikius
Apibrėžti ir dokumentuoti programų sistemos architektūrą
Prižiūrėti architektūros aprašą, bei būti už jį atsakingu
Užtikrinti, kad programų sistemos architektūra atitinka sistemai
keliamas kokybines charakteristikas
Padėti užtikrinti, kad sutarti architektūriniai principai ir
standartai iš tiesų įgyvendinti sukurtoje programų sistemoje
Užimti techninio lyderio vaidmenį komandoje
22
The role of a software architect
 http://www.codingthearchitecture.com/pages/book/role.html
23
Apibendrinimas
 Klasikinis/dažnas architekto pareigybės įsivaizdavimas:
 Išmanyti technologijas, projektavimą, gebėti sistemą skaidyti
į dalis ir joms parinkti technologijas
 Visus reikalavimus išsiaiškina sisteminis analitikas
 Architektas projekto pradžioje sukuria architektūrą ir
projektą palieka
 Realybė:
 Reikia viso projekto eigoje susitikinėti su suinteresuotais
asmenimis ir derinti prieštaringus (nefunkcinius)
reikalavimus
 Reikia išmanyti kokybinių charakteristikų realizavimo
technikas/taktikas, gebėti įvertinti nefunkcinių reikalavimų
poveikį sistemos struktūrai
 Dirbti reikia viso projekto metu, darbas įtraukia ir
programavimo veiklas (integracija; nefunkcinių reikalavimų
įgyvendinimas)
24
Apibendrinimas
 Tam, kad sukurti architektūrą, reikės projektuoti:
 Funkcinius reikalavimus; tam mes turime požiūrius:



Funkcinis, informacinis, lygiagrečių procesų, konstravimo,
dislokavimo, operacinis
Dažniausiai pasitelkiama UML notacija
Šito studentai mokinami klasikiniuose programų sistemų
inžinerijos kursuose
 Nefunkcinius reikalavimus; tam mes turime kokybines
charakteristikas:



Saugumas, našumas, pasiekiamumas, modifikuojamumas, ...
Šito studentai mokinti buvo pradėti visai neseniai!
UML čia nepadeda; kiekviena kokybinė charakteristika įtakoja
daugumą UML diagramų, sukurtų projektuojant funkcinius
reikalavimus
25
“Smoke break” 
 Aptarėme teorinius architektūros kūrimo aspektus
 Toliau žvilgsnis į kai kuriuos praktinius aspektus:
 Saugumo kokybinė charakteristika
 Skaliuojamumo kokybinė charakteristika
 Technologinės platformos (Java EE ir .Net)
26
Saugumo eksperto akiratis
 Knyga, duodanti akiračio platumą:
 Architecting secure software systems, Asoke K. Talukder, Manish
Chaitanya, 2009
 Turinys
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Security in Software Systems
Architecting Secure Software Systems
Constructing Secured and Safe C/UNIX Programs
Constructing Secured Systems in .NET
Networking and SOA-Based Security
Java Client-Side Security
Security in Mobile Applications
Security in Web-Facing Applications
Server-Side Java Security
Constructing Secured Web Services
27
Saugumo eksperto akiratis: vienas iš „aisbergų“:
8. Security in Web-Facing Applications
 Vulnerabilities in Web
 Threat Modeling for Web
Applications
 Security Development
Lifecycle for Web
Applications
 Identity Management




Single Sign-On
Identity Federation
Identity Security
Directory Services
 Public Key Infrastructure
 Identity-Based







Cryptosystem
Forward Secure Signature
Code Injection
Parameter Tampering
Cross-Site Scripting
File Disclosure
Next Generation Web
Security
Security Review and Testing
of Web Applications
28
Skaliuojamumo kokybinė
charakteristika
 Gera apžvalga „į plotį“ (pateikia „aisbergų viršūnėles“):
 http://www.slideshare.net/jboner/scalability-availabilitystability-patterns
 Našumo problemą turime, jei sistema lėtai veikia su mažu
naudotojų skaičiumi
 Skaliuojamumo problemą turime, jei su mažu naudotojų
skaičiumi sistema veikia greitai, bet su dideliu – lėtai
 Sistema skaliuojasi 100% (is scalable), jei du kartus
padidinus naudotojų skaičių, atsako laiką galima išlaikyti
tą patį, jei sistemoje du kartus padidiname resursų kiekį
(CPU/RAM)
29
Skaliuojamumo kokybinė
charakteristika: „aisbergų viršūnėlės“
 State/data perspective:
 Caching and Distributed
caching
 Data grids
 Service of Record
 Behaviour perspective:
 Parallel Computing
 Load-balancing
 Event-Driven Architecture

NoSQL
RDBMS

 CAP theorem

 Partitioning

 Replication




Messaging
Enterprise Service Bus
Domain Events
Event Stream Processing
Event Sourcing
Command & Query
Responsibility Segregation
(CQRS)
30
CAP teorema
 CAP teorema (Brewer‘io teorema) teigia, kad
programų sistemai neįmanoma vienu metu teikti visų
šių garantijų:
 Consistency (visi klientai visada mato vienodus
duomenis)
 Availability (dalies mazgų gedimas nesutrikdo likusių
mazgų darbo – klientai naudojasi pilnu funkcionalumu)
 Partition Tolerance (sistemos išskirstymo galimybė;
kiekviena išskirstyta dalis turi tuos pačius
duomenis/funkcionalumą)
31
32
Architektai ir judrūs (agile) procesai
 Tom Hollander patirtis, dirbant architektu judriame procese
 http://www.infoq.com/news/2010/09/Tips-Architect-Agile-Team
 a Solutions Architect at Microsoft Australia
 Projekto struktūra:
 PjM – Project Manager, similar to a Scrum
PjM
Release
PdM
Team
UX
Arch
Test
Dev






Master, making sure the team is following the
process.
PdM – is the Product Manager, also known as
the Customer or the Product Owner,
determining what the product is supposed to
be
Architect – a solution/application architect
Dev – the development team
Test – the test team
UX – the User Experience team
Release – the Build and Release role taking
care of the building process
33
Architektai ir judrūs (agile) procesai
 Hollander has come up with a top 10 list of things for a
solution architect to be successful in an agile team:
1.
2.
3.
4.
“Just enough” upfront design – a certain amount of upfront design – 1-
2 weeks - is absolutely needed based on what type of application it is
Start with a vertical slice – means starting with a small piece of
functionality which cuts as many vertical layers as possible in order to tie
together all the technology pieces decided during the previous phase.
Just-in-time design each iteration – At the middle of a 4-week
iteration, the project manager, the product manager and the architect should
meet to discuss the requirements to be addressed during the following
iteration, to make sure they all agree on them, what is more important is put
up in front, and everything is understood.
Trust your team… but be there for them – this has to do with the
relationship architect-developer. The architect needs to make sure he does
not overstep his role, making the developer’s job boring by taking all the fun
of decision making. In the same time, the architect needs to be a mentor for
the team, solving difficult problems that might bog down the developers..
34
Architektai ir judrūs (agile) procesai
5.
6.
7.
8.
9.
Write code! – The architect should know what’s in the code in order to have a
better idea on the impact of his decisions. He can also figure out when a refactoring is
needed. A code writing architect has better credibility with the development team.
Be involved in everything – It is good for the architect to be involved in all
meetings related to his project: design, development, code reviews, requirements
planning, etc., because he can have a larger and more clear perspective on what is
going on, and he can help the product manager to avoid making wrong decisions in an
early stage by informing him/her on their possible outcome.
Drive a culture of quality
Know when changes are required – The architect should be very flexible
and ready to make design changes when they are required. It may be that an early
solution is no longer appropriate, or new requirements demand a different approach.
Shield the team from external randomization – While this is usually
the job of a project manager/Scrum master, the architect can get involved in
protecting the team from external requests that tend to divert the team’s focus and
take time from actual work.
10. Write docs … but only if someone needs to read them
35
Trumpai apie technologijas
 Java EE
 Dirbu nuo 1998 m., dėstau studentams kaip kurso
„Programų sistemų architektūra“ technologinę dalį
 http://www.mif.vu.lt/~donatas
 .Net
 Stebiu viena akimi 
36
Java EE evoliucija
37
Java EE 6 apžvalga
38
Java EE technologijos daugelio
lygmenų architektūroje
Serveris
Klientas
Naršyklė
Vartotojo
interfeiso
paruošimo
lygmuo
Dalykinio
funkcionalumo
lygmuo
Servlets,
JSP, JSF
Esybių
lygmuo
DBVS
lygmuo
(verslo logika)
(duomenų
pavaizdavimas
objektais)
(duomenų
saugojimas)
EJB
JPA
RDBVS
CDI (Contexts and dependency injection)
39
.Net technologijos daugelio
lygmenų architektūroje
Serveris
Klientas
Vartotojo
interfeiso
paruošimo
lygmuo
Naršyklė
ASP.NET
MVC
Dalykinio
funkcionalumo
lygmuo
(verslo logika)
WCF
Transactions,
...
Esybių
lygmuo
(duomenų
pavaizdavimas
objektais)
ADO.NET
Entity
Framework
DBVS
lygmuo
(duomenų
saugojimas)
RDBVS
40
Kas įdomu architektui
(nesvarbu kokia technologinė platforma, Java EE ar .Net)
Presentation Tier
View
Template language
Expression language
Drag-and-drop
Preview in browser
Controller
Declarative page flow
Declarative form validation
Page composition
Form resubmition prevention
Inversion of Control (IoC)
Dependency Injection
Action-based controller
Component-oriented
controller
Request, session contexts
Conversation context
Business Logic Tier
Stateful components
Stateless components
Memory management
(pooling)
Distribution transparency
Declarative transactions
Declarative security
Declarative persistency
Dependency injection
Declarative scope/context
management
Data Tier
Object/Relational Mapping (ORM)
CRUD SQL generation
Many-to-many relationships
Primary key generation
Lazy resolution of queries
n+1 select problem
Inheritance/polymorphic queries
Query caching
Disconnected operation mode
...
RDBMS vendor independence
41
Ačiū už dėmesį
 Klausimai, pastabos, prieštaravimai , diskusija...
42