PPTX - Matematikos ir Informatikos fakultetas

advertisement

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

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

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

Projekto vadovas

Sisteminis analitikas

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)

...

Karkasas (angl. framework)

...

Posistemis, modulis

...

Archetipai, architektūriniai stiliai

...

Architektūra

Projektuotojo atsakomybė

Architekto atsakomybė

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

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

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 Konstravimo požiūris

Informacinis požiūris

Lygiagrečių procesų 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

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

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

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

UX

Release

Test

PjM

Team

Dev

PdM

Arch

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

33

Architektai ir judrūs (agile) procesai

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

Architektai ir judrūs (agile) procesai

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

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

Klientas

Serveris

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

.Net technologijos daugelio lygmenų architektūroje

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

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

Download