Arhitektuuriline kavandamine
Arhitektuuriline kavandamine
Arhitektuuriline kavandamine
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
Arhitektuurne<br />
<strong>kavandamine</strong><br />
Tarkvaratehnika<br />
Raino Kolk
Kes mina olen?<br />
raino.kolk@ttu.ee<br />
@rainokolk
Milleks ma siin olen?
Tarkvara arhitektuur?<br />
• Tarkvara arhitektuuri kontseptsioon on pärit Edsger Dijkstra 1968 ja David<br />
Parnas 1970 aastate uurimistöödest<br />
• Süsteemi illustratsioon, mis aitab arusaada süsteemi käitumisest.<br />
(Software Engineering Institute http://www.sei.cmu.edu/)<br />
• Süsteemi arhitektuur on struktuuride kogum, mis aitavad mõista süsteemi,<br />
hõlmates tarkvara elemente, seoseid nende vahel ja elementide ning<br />
seoste omadusi.(wikipedia)<br />
• Arhitektuur on vundament millele, tarkvara ehitatakse. Arhitektuuri mudel<br />
defineerib vundamendi visiooni (agilemodeling)
Erinevused funktsionaalsest<br />
disainist<br />
• IEEE 1990 sõnastik:<br />
o Arhitektuurne disain - protsess, mille käigus<br />
defineeritakse riistvara ja tarkvara komponendid ja<br />
nende liidesed, kujundamaks välja raamistikku tarkvara<br />
arendamiseks<br />
o Eeldisain - protsess, mille käigus analüüsitakse<br />
arhitektuuri alternatiive ja defineeritakse arhitektuur,<br />
komponendid, liidesed igale tarkvara komponendile.<br />
o Detaildisain - eeldisaini tulemi<br />
laiendamine/täpsustamine saavutamaks vajalikku<br />
täpsust arendamise alustamiseks<br />
o Funktsionaaldisain - protsess, mille käigus defineeritakse<br />
seosed süsteemi komponentide vahel.
Erinevused funktsionaalsest<br />
disainist<br />
• Arhitektuur on disain aga mitte kõik disainid ei ole<br />
arhitektuur<br />
• Arhitektuuri juhivad mittefunktsionaalsed nõuded,<br />
funktsionaaldisaini juhivad funktsionaalsed nõuded<br />
• Pseudo kood kuulub detaildisaini<br />
dokumentatsiooni<br />
• UML komponendi-, paigaldus- ja<br />
paketidiagrammid on enamasti arhitektuuri<br />
dokumentatsioonis<br />
• UML klassi-, objekti-, käitumisdiagrammid<br />
funktsionaaldisaini dokumentatsiooni
Erosioon
Arhitektuuri erosioon<br />
Kontroller<br />
Äri<br />
Teenus
Mustrid
Klient- Server
Klient- Server<br />
• Client-Queue-Client süsteem<br />
• P2P<br />
• Aplikatsioonide server
Klient- Server<br />
Kasu<br />
• Kõrgem turvalisu<br />
• Andmed on tsentraliseeritud<br />
• Kerge hallata
Komponentidel põhinev
Komponentidel põhinev<br />
• taaskasutatav<br />
• asendatav<br />
• laiendatav<br />
• kapseldatud<br />
• sõltumatus
Komponentidel põhinev<br />
Kasu:<br />
• kerge paigalda<br />
• kerge ehitada<br />
• odav hind<br />
• taaskasutatav<br />
• lahendab tehnilist keerukust
Kihiline arhitektuur
Kihiline arhitektuur<br />
• abstraktne<br />
• kapseldatud<br />
• selgelt defineeritud kihid<br />
• kõrge koherentsus<br />
• taaskasutatav<br />
• nõrgalt seotud
Kihiline arhitektuur<br />
Kasud:<br />
• abstraktne<br />
• manageeritav<br />
• isoleeritud<br />
• jõudlus<br />
• taaskasutatav<br />
• testitav
Message bus
Message bus<br />
Kasud:<br />
• laiendatavus<br />
• nõrgalt seotud<br />
• skaleeritavus<br />
• aplikatsioonide lihtsus
N-tier
N-tier<br />
Kasud:<br />
• hallatavus<br />
• skaleeritavus<br />
• paindlikus<br />
• kättesaadavus
Objekt orienteeritud<br />
arhitektuur
Objekt orienteeritud<br />
arhitektuur<br />
• abstraktsioon<br />
• kompositsioon<br />
• pärilus<br />
• kapseldamine<br />
• polümorfism<br />
• eraldatus
Objekt orienteeritud<br />
arhitektuur<br />
Kasu:<br />
• arusaadavus<br />
• taaskasutatavus<br />
• testitavus<br />
• laiendatavus<br />
• kõrge kohesiivsus
DDD<br />
Kasu:<br />
• suhtlus<br />
• laiendatavus<br />
• testitavus
Teenus orienteeritud<br />
arhitektuur
Teenus orienteeritud<br />
arhitektuur<br />
• autonoomne<br />
• jagatav<br />
• nõrgalt seotud<br />
• jagatakse lepingut ja skeemi, mitte sisemisi<br />
klasse
Teenus orienteeritud<br />
arhitektuur<br />
Kasu:<br />
• abstraktsus<br />
• leitavus<br />
• erinevad platvormid<br />
• ratsionaalsus
Monoliitne arhitektuur
Mõtle....<br />
• Kuidas kasutajad kasutavad loodavat süsteemi<br />
• Kuidas süsteemi paigaldada<br />
• Millised on mittefunktsionaalsed nõuded:<br />
turvalisus, jõudlus, paralleelsus, multikeelsus,<br />
konfiguratsioon<br />
• Kuidas saavutada paidlikus ja hallatavus läbi aja<br />
• Millised on arhitektuursed trendid, mis võivad<br />
mõjutada süsteemi praegu või tulevikus
Võtme jõud...<br />
...mis mõjutavad arhitektuuri<br />
• Kasutaja volitused - kasutaja kogemus: ära<br />
dikteeri.<br />
• Turu küpsus - kasuta valmis komponente,<br />
ära leiuta jalgratast<br />
• Paidlik disain - taaskasutatavus, hallatavus<br />
• Tuleviku trendid
Arhitektuuri disain<br />
Ära üle inseneeri. Ära tee eeldusi, mida ei saa<br />
kontrollida.<br />
• Mis on fundamentaalsed osad arhitektuurist, mille<br />
valesti tegemine on väga suure riskiga süsteemile<br />
• Milline osa süsteemist on suurima muutumise<br />
tõenäosusega.<br />
• Milliste osade disainimist võib edasi lükata ilma<br />
märkimisväärsete mõjudeta<br />
• Millised on võtme eeldused ja kuidas neid kontrollida<br />
• Mis võib põhjustada süsteemi ümber disainimise
Arhitektuuri disainimise<br />
protsess<br />
Tarkvaraarhitektuuri disainimeks ei ole<br />
universaalset, aksepteeritud protsessi
ADD(Attribute Driven<br />
Design)<br />
• ADD töötati välja Carnegie Mellon Ülikooli<br />
pool<br />
• Väljakutsed<br />
o<br />
o<br />
o<br />
o<br />
Milline arhitektuur kataks kõige paremini kasutajate<br />
vajadusi<br />
Kuidas täita kujuteldava süsteemi nõudeid<br />
Kuidas otsustada, milline arhitektuuri strateegia on<br />
sobilik<br />
Kuidas hinnata nõuete täitmisel tehtavate<br />
kompromisside mõjusid
ADD<br />
ADD on rekursiivne<br />
• 1. osa taktika<br />
o Kontrolli, et nõuded oleks piisavad.<br />
o<br />
o<br />
Vali süsteemi osa, mida komponentideks lahutada<br />
Identifitseeri arhitektuuri juhtivad nõuded<br />
o Vali kontseptsioon, mis täidab juhtivad nõuded<br />
• 2. osa dokumenteerimine<br />
o Algväärtusta arhitektuuri elemendid ja jaota vastutused<br />
o<br />
Defineeri elementide liidesed<br />
o Verifitseeri ja viimistle nõudeid ning määra nende pealt<br />
piirangud elementidele.<br />
• Korda samme kõikide süsteemi osade kohta
ADD kasu<br />
• Nõuete vahelised kompromissid tulevad<br />
varajases staadiumis välja, mis aitab luua<br />
luua parima arhitektuuri nõuete katmiseks.
Won Kim pakutud protsess<br />
Won Kim is Senior Advisor at Samsung Electronics and Distinguished<br />
Professor at SungKyunKwan University<br />
1. Koosta esialgne paigaldusplaan(deployment plan). See annab ülevaate<br />
kasutatavast keskkonnast.<br />
2. Mängi esialgsed kasutuslood läbi paigaldusplaani peal. See peaks<br />
sisaldama andmevooge läbi keskkonna, andmete sisenemisi, väljastamist<br />
ja talletamist põhi andmetüüpidega.<br />
3. Grupeeri ja prioretiseeri nõuded.<br />
4. Vali üks kuni mitu mustrit moodulite vaatele ja defineeri kaetud nõuded<br />
5. Vali üks kuni mitu mustrit komponentide vaatele ja defineeri kaetud<br />
nõuded<br />
6. Vali üks kuni mitu mustrit paigutusvaatele ja defineeri kaetud nõuded<br />
7. Teosta järelkontroll arhitektuurile<br />
8. itereeri punkte 1-7
Agiilne arhitektuur<br />
• Arhitektuur ei ole mitte midagi erilist<br />
• Karda kivisse raiutud arhitektuuri<br />
• Igal süsteemil on arhitektuur<br />
• Arhitektuur skaleerub
Agiilne arhitektuur<br />
Kes vastutab arhitektuuri eest?<br />
Kõik on vastutavad.<br />
Probleem:<br />
• vahel inimesed ei ole üksteisega nõus<br />
• suurtes tiimides skaleeruvus
Agiilne arhitektuur
Arhitektuur suures<br />
meeskonnas
Arhitektuur suures<br />
meeskonnas<br />
• Arhitektuuri juhitud lähenemine<br />
• Featuuri juhitud lähenemine<br />
• Avatud lähtekoodi lähenemine<br />
• Kombinatsioon eelnevatest
Arhitektuur suurtes tiimides
Arhitektuuri testimine<br />
• Küsi endalt:<br />
o<br />
o<br />
o<br />
o<br />
o<br />
Millistele eeldustele tugineb arhitektuur<br />
Milliseid nõudeid arhitektuur katab<br />
Mis on selle arhitektuuri võtme riskid<br />
Milliste meetmetega leevendada riske<br />
Mil moel on see arhitektuur edasiminek viimase<br />
kandidaadi/baas arhitektuuri suhtes.
Agiilne tarkvara arhitektuur
Agiilne arhitektuur
Agiilne arhitektuur
Agiilne arhitektuur
Agiilne arhitektuur<br />
Lenda valguskiirusel<br />
• Ole nii väle kui võimalik<br />
• Ära kirjuta 50 lehekülge kui 5 kõlbab<br />
• Ära kirjuta 5 lehekülge, kui pilt kõlbab<br />
• Ära joonista pilti, kui metafor kõlbab<br />
• TAGRI
Agiilne arhitektuur<br />
Tõesta oma arhitektuur
Agiilne arhitektuur
Agiilne arhitektuur
Agiilne arhitektuur<br />
Tavaline praktika<br />
• Arhitektid tõstetakse või veel hullem tõstavad end ise<br />
kõrgemale pedestaali astmele<br />
• Arhitektid on liiga hõivatud, et "määrida" oma käsi<br />
koodi kirjutamisega<br />
• Arhitektuuri mudelid on piisavalt robustsed, et<br />
lahendada ka tulevikus tekkivaid probleeme<br />
• Eesmärk on luua lõplik arhitektuur võimalikult vara<br />
• Hästi dokumenteeritud mudelid<br />
• Arhitektuuri mudeleid presenteeritakse vaid "sobilikele<br />
kuulajatele"<br />
• Arhitektuurile tehakse enne järelkontroll ja seejärel
Agiilne arhitektuur<br />
Agiilne praktika<br />
• Arhitektidel on alandlikkust tunnistada et nad ei oska vee<br />
peal käia<br />
• Arhitektid osalevad aktiivselt arendustegevuses. Nad on<br />
meeskonna konsultandid<br />
• Arhitektidel on alandlikkust tunnistada, et nad ei oska<br />
tulevikku ennustada. Küll aga on nad enesekindlad selles, et<br />
homseid probleeme saab lahendada homme<br />
• Arhitektuur tekib iteratiivselt koos arendusega<br />
• Valguskiirus. Dokumenteeri nii palju kui on vaja<br />
kommunikatsiooniks.<br />
• Mudeleid kommunikeeritakse avalikult kõigile osapooltele,<br />
ka poolikuid, et saada tagasisidet<br />
• Arhitektuuri kontrollitakse eksperimentidega
Raamat mida soovitan
Lugemist<br />
• http://www.sei.cmu.edu/architecture/<br />
• http://msdn.microsoft.com/en-us/library/ee658117.aspx<br />
• http://msdn.microsoft.com/en-us/library/ee658098.aspx<br />
• http://www.jot.fm/issues/issue_2006_09/column3/<br />
• http://www.agilemodeling.com/essays/agileArchitecture.htm
Change language