Architektūra, architektai ir architektūros kūrimo veikla programų sistemų inžinerijoje

1. Architektūra, architektai ir architektūros kūrimo veikla programų sistemų inžinerijoje Donatas Čiukšys Visorių informacinių technologijų parkas 2010-09-29

2. 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/

3. 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/PSArchitekturaProjektavimas/Teorija.html

4. Architektūros kaip tyrimų krypties raida (Pagal straipsnį: “The Golden Age of Software Architecture”)

5. Apžvalga

6. Architektai kuria architektūrą

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

8. 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 

9. 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

10. Architektas ir kiti projekto dalyviai

11. 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

12. 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) • ... • Karkasas (angl. framework) • ... • Posistemis, modulis • ... • Archetipai, architektūriniai stiliai • ... • Architektūra Projektuotojo atsakomybė Architekto atsakomybė

13. 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

14. 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.

15. Pvz.: duomenų architekto sritis • Data Management Body of Knowledge • http://www.dama.org/i4a/pages/index.cfm?pageid=3364

16. Sąvokų sistema Sinonimas: kokybinė charakteristika

17. Požiūriai: 4+1 vaizdo modelis (1995)

18. Dažniausiai naudojami požiūriai • Praėjus 10 metų po 4+1 vaizdo modelio sukūrimo (1995m.), Nick Rozanski ir EonWoods pasiūlė tokį požiūrių rinkinį:

19. 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

20. Architekto užimtumas projekte

21. 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

22. 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 suinteresuotusasmenis • 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

23. The role of a software architect • http://www.codingthearchitecture.com/pages/book/role.html

24. 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)

25. 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

26. “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)

27. Saugumo eksperto akiratis • Knyga, duodanti akiračio platumą: • Architecting secure software systems, Asoke K. Talukder, Manish Chaitanya, 2009 • Turinys • 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

28. 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 • PublicKeyInfrastructure • 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

29. Skaliuojamumo kokybinė charakteristika • Gera apžvalga „į plotį“ (pateikia „aisbergų viršūnėles“): • http://www.slideshare.net/jboner/scalability-availability-stability-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)

30. Skaliuojamumo kokybinė charakteristika: „aisbergų viršūnėlės“ • 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)

31. 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ą)

33. 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 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

34. 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: • “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..

35. Architektai ir judrūs (agile) procesai • 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

36. 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 

37. Java EE evoliucija

38. Java EE 6 apžvalga

39. Java EE technologijos daugelio lygmenų architektūroje

40. .Net technologijos daugelio lygmenų architektūroje

41. Kas įdomu architektui (nesvarbu kokia technologinė platforma, Java EE ar .Net)

42. Ačiū už dėmesį • Klausimai, pastabos, prieštaravimai , diskusija...