4+1 arkkitehtuurin tiivistelmä (alkuperäisestä julkasusta)
==============================================================

- Hyvä huomata, että UML on julkaistu vasta 4+1:n julkaisun jälkeen


Logical View
-------------

- object model of the design

- tarkoituksena tukea lähinnä järjestelmän funktionaalisia vaatimuksia eli sitä
  mitä järjestelmän on tarkoitus tarjota sitä käyttäville
- decomposition ei ole ainoastaan toimintojen analysoimiseksi, vaan myäös
  yleisten osien tunnistamiseen
- luokkakaavioita: luokat, suhteet, perintä, kompositio
	- Huom! alkuperäisen dokumentin julkaisuhetkellä ei ole ollut UML:ää! 
	  Luokkakaavio ei välttämättä tarkoita tarkalleen UML:n luokkakaaviota
- luokkakategorioilla voidaan kuvata joukkoa yhteenkuuluvia luokkia
	- jos on tarvetta kuvata tarkemmin jonkun objektin tilaa, voidaan käyttää tilakaavioita
	- järkevintä kuvata isoa kokonaisuutta aluksi luokkakategorioiden avulla ja vasta sitten tarkemmin luokkakaavioilla, jos tarpeen

- Jos data on sovelluksen toiminnan kannalta erityisasemassa, voidaan käyttää muita loogisia kuvia, kuten
  Entity Relationship -diagrammeja


Development View
-----------------
- subsystem decomposition

- softa pakataan pieniin osiin, kirjastoihin tai alijärjestelmiin, jotka voidaan 
  kehittää erikseen yhden tai useamman devaajan (alihankkijan) toimesta
- alijärjestelmät voidaan (ehkä) jakaa kerroshierarkiaan, jossa yksi kerros tarjoaa
  hyvin määritellyn rajapinnan sitä ylempänä oleville kerroksille

- kuvauksessa käytetään moduuli- ja subsystem kaavioita
	- kaavioissa näkyy export/import suhteet eli se mitä rajapintoja tarjotaan ja
	  mitä käytetään
	- voidaan jakaa toteutus kerroksiin ja kuvata sitä kautta
	-> UML:n komponenttikaavio ehkä paras tähän?
	
- voidaan listata sääntäöjä, miten ositusta tulee tehdä

- näkymä ottaa siis lähinnä kantaa järjestelmän sisäiseen rakenteeseen
	- samat toiminnot tarjoava järjestelmä voidaan rakentaa usealla eri tavalla
	- sisäinen rakenne vaikuttaa ennen kaikkea ylläpidon helppouteen ja kehittämisen
	  nopeuteen (palikoiden yleiskäyttäöisyys jne.)

- toimii pohjana vaatimusten allokoinnissa, tyäön allokoinnissa tiimeille, 
  tyäömäärien arvioinnissa ja suunnittelussa, projektin etenemisen valvonnassa ja 
  uudelleenkäytettävien komponenttien miettimisessä ja tietoturvassa
  
- describes the static organization of the software in its development environment

- logial ja development lähellä toisiaan
	- mitä suurempi projekti sitä kauempana
	
	
Process View
--------------

- huomioi joitakin non functional vaatimuksia, kuten suorituskykyä ja saatavuutta
- kuvaa järjestelmän rinnakkaisuutta (säikeiden & prosessien käyttöä)
- kuvaa lisäksi distribution?, system's integrity, fault-tolerance
- kuvaa lisäksi miten loogisessa näkymässä kuvatut abstraktiot istuvat prosessiarkkitehtuuriin
	- missä säikeessä operaatiota suoritetaan 
	
- voidaan kuvata useammalla eri abstraktiotasolla, joista jokainen taso tuo esiin
  eri huolia
	- korkeimmalla tasolla prosessiarkkitehtuuri voidaan nähdä joukkona 
	  ohjelmista (prosesseista) koostuvia loogisia verkkoja, jotka jakautuvat
	  eri laitteistoille, jotka on kytketty toisiinsa tietoverkoilla (LAN, WAN, WLAN,..)
	- voi olla useita erilaisia loogisia verkkoja samanaikaisesti

- prosessi = executable unit
	- voidaan käynnistää, sammuttaa, ..
	- voidaan monistaa, jos halutaan jakaa processing loadia
- task = separate thread of control
	- 
	
- webbiserverin kanssa simppeli, yleensä oma säie requestien kuunteluun ja
  suoritus jakautuu omiin säikeisiin

Physical View
---------------

- mapping from software onto the hardware
- reflects distributed aspects


	
Scenarios 
-----------
- putting it all together
	- 
- kuvataan tiettyjä tärkeiksi valittuja skenaarioita
	- esim. käytetään loogisessa näkymässä esitettyjä komponentteja 
			ja kuvataan tietty skenaario niiden kautta muodostetuilla sekvensseillä
			
- helpoin alottaa loogisesta