Visorių informacinių technologijų parkas
2010-09-29

 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




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

(Pagal straipsnį: “The Golden Age of Software Architecture”)
4

Teorija
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 )
...
Procesas
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, ...
Programų sistemų architektūra
Technologijos (software)
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, …
...
Socialiniai aspektai
Diplomatija
Konfliktų sprendimas
Lyderio vaidmuo (team leader)
...
Technologijos (hardware)
Tinklo įranga : ugniasienės, maršrutizatoriai, load-balancers, ...
Serverinė įranga : serveriai, Network attached storage (NAS), Storage area network (SAN), ...
Virtualizacija (VMWare, Xen, VirtualPC, ...)
...
5

Socialiniai aspektai architects
(žmonės)
Programų sistemų kūrimo proceso aspektai architect
(procesas)
UML, našumas, saugumas, pasiekiamumas, technologijos, ...
architectures
(architektūra)
6

 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

 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



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

Užsakovas
Projekto vadovas
Sisteminis analitikas
Architektas
Projektuotojai/ programuotojai
Dalykiniai/techniniai ekspertai/architektai
10




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



Kaip aprėpti visą sistemą – taikyti “skaldyk ir valdyk” principą
Kaip smulkiai skaldyti?











Klasė (OOP prasme), komponentas
...
Tipinis projektavimo sprendimas
(angl. design pattern)
...
Karkasas (angl. framework)
...
Posistemis, modulis
...
Archetipai, architektūriniai stiliai
...
Architektūra
Projektuotojo atsakomybė
Architekto atsakomybė
12

 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 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



Data
Management
Body of
Knowledge http://www.dama.or
g/i4a/pages/index.cf
m?pageid=3364
15

Architektūrinis elem entas
1..* susideda
2..*
Architektūros kūrimo procesas pasako, kaip projektuoti vykdo
Architektas projektuoja sukuria
Architektūra
1 gali būti dokumentuota
0..*
Architektūrinis aprašas
1 išsiaiškina interesus susideda
1..*
Vaizdas
0..* atitinka
Sinonimas: kokybinė charakteristika yra įtakojamas
0..*
0..*
Perspektyva
1..*
1 riša susideda turi
1..*
1..*
Tarpelem entis ryšys
Programų sistem a dokumentuoja architektūrą
Požiūris tenkina poreikius
1..*
1..*
1..*
Suinteresuotas asm uo
1..* turi
1..* atsižvelgia
Interesas
1..* 1..*
1..* atsižvelgia
16

17

 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 Konstravimo požiūris
Informacinis požiūris
Lygiagrečių procesų požiūris
Dislokavimo požiūris
Operacinis požiūris
18

 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

Laikas
20

 Ž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









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

 http://www.codingthearchitecture.com/pages/book/role.html
23



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

 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


 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



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






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

 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

 State/data perspective:






Caching and Distributed caching
Data grids
Service of Record

NoSQL
 RDBMS
CAP theorem
Partitioning
Replication
 Behaviour perspective:



Parallel Computing
Load-balancing
Event-Driven Architecture

Messaging





Enterprise Service Bus
Domain Events
Event Stream Processing
Event Sourcing
Command & Query
Responsibility Segregation
(CQRS)
30

 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

 Tom Hollander patirtis, dirbant architektu judriame procese
 http://www.infoq.com/news/2010/09/Tips-Architect-Agile-Team
 a Solutions Architect at Microsoft Australia
UX
Release
Test
PjM
Team
Dev
PdM
Arch

:





PjM – Project Manager, similar to a Scrum
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


1.
2.
3.
4.
Hollander has come up with a top 10 list of things for a solution architect to be successful in an agile team :
“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

5.
6.
7.
8.
9.
10.
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.
Write docs … but only if someone needs to read them
35

 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

37

38

Vartotojo interfeiso paruošimo lygmuo
Dalykinio funkcionalumo lygmuo
(verslo logika)
Esyb ių lygmuo
( duomenų pavaizdavimas objektais)
DBVS lygmuo
( duomenų saugojimas)
Naršyklė
Servlets,
JSP, JSF
EJB JPA
CDI (Contexts and dependency injection)
RDBVS
39

Klientas
Naršyklė
Serveris
Vartotojo interfeiso paruošimo lygmuo
Dalykinio funkcionalumo lygmuo
(verslo logika)
Esyb ių lygmuo
( duomenų pavaizdavimas objektais)
DBVS lygmuo
( duomenų saugojimas)
ASP.NET
MVC
WCF
Transactions,
...
ADO.NET
Entity
Framework
RDBVS
40

(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

 Klausimai, pastabos, prieštaravimai  , diskusija...
42