Bosch-malli. Kolme vaihetta. Termistöä. Ohjelm!toarkkitehtuu"n

Samankaltaiset tiedostot
Ohjelmistojen suunnittelu

TIE355 Ohjelmistoarkkitehtuurit, Bosch QASAR (Keskeneräinen)

Ohjelmistoarkkitehtuuri

Ohjelmistotekniikan menetelmät, luokkamallin laatiminen

Tietojärjestelmän osat

Sisällys. Ratkaisumallien historia. Ratkaisumalli. Ratkaisumalli [2] Esimerkki: Composite [2] Esimerkki: Composite. Jaakko Vuolasto 25.1.

Arkkitehtuurien tutkimus Outi Räihä. OHJ-3200 Ohjelmistoarkkitehtuurit. Darwin-projekti. Johdanto

Ohjelmistotuotanto vs. muut insinööritieteet. (Usein näennäinen) luotettavuus ja edullisuus

Ohjelmistoarkkitehtuurit. Kevät

Tenttikysymykset. + UML- kaavioiden mallintamistehtävät

Ohjelmistotekniikka - Luento 2

Suunnitteluvaihe prosessissa

1 Johdanto. TTY Ohjelmistotekniikka. Ohjelmistoarkkitehtuurit Syksy 2008

Tarjolla tänää: Ohjelmiston toteutuksesta. Kuinka tulla hyväksi ohjelmoijaksi? CRC-kortit. Testilähtöinen kehittäminen JOT2007. Uudelleenrakentaminen

Ohjelmistotekniikka - Luento 2 Jouni Lappalainen

Analyysi, dynaaminen mallintaminen, yhteistoimintakaavio ja sekvenssikaavio

Analyysi, dynaaminen mallintaminen, yhteistoimintakaavio ja sekvenssikaavio

Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1

Arkkitehtuurikuvaus. Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy. Ryhmä 14

Ohjelmiston toteutussuunnitelma

1.3 Katsaus ohjelmistotuotannon kehittymiseen

Concurrency - Rinnakkaisuus. Group: 9 Joni Laine Juho Vähätalo

Analyysi, staattinen mallintaminen, kohdealueen malli ja luokkakaavio

Testaaminen ohjelmiston kehitysprosessin aikana

1 Johdanto. TTY Ohjelmistotekniikka. Ohjelmistoarkkitehtuurit Syksy 2007

Ohjelmistoarkkitehtuurit. Syksy 2010

Test-Driven Development

Hieman lisää malleista ja niiden hyödyntämisestä

9. Muunneltavuuden hallinta

812347A Olio-ohjelmointi, 2015 syksy 2. vsk. IX Suunnittelumallit Proxy, Factory Method, Prototype ja Singleton

Uudelleenkäytön jako kahteen

Käyttöjärjestelmien historia. Joni Herttuainen Henri Jantunen Markus Maijanen Timo Saksholm Johanna Tjäder Eetu Turunen

Liite 1: KualiKSB skenaariot ja PoC tulokset. 1. Palvelun kehittäjän näkökulma. KualiKSB. Sivu 1. Tilanne Vaatimus Ongelma jos vaatimus ei toteudu

TOIMINNALLINEN MÄÄRITTELY MS

Ohjelmistoarkkitehtuurit Kevät käytäntöjä

Test-Driven Development

Käyttötapausanalyysi ja testaus tsoft

Ohjelmistojen mallintaminen, mallintaminen ja UML

Sytyke ry:n laivaseminaari Software Technology Transfer Pekka Forselius

Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1

Copyright by Haikala. Ohjelmistotuotannon osa-alueet

Agenda. Johdanto Ominaispiirteitä Kokonaisjärjestelmän määrittely Eri alojen edustajien roolit Sulautetut järjestelmät ja sulautettu ohjelmointi

19/20: Ikkuna olio-ohjelmoinnin maailmaan

Työn ositusmalleista. Luennon tavoitteista. Motivointia. Walker Royce, Software Project Management, A Unified Framework

6. Arkkitehtuurityylit

T Johdatus käyttäjäkeskeiseen tuotekehitykseen. suunnitteluprosessissa. Käyttäjän huomiointi. Iteroitu versio paljon kirjoitusvirheitä

Käyttäjäkeskeinen suunnittelu

Kuolevuusseminaari

EcoProP Potilashuoneen toiminnalliset vaatimukset

Osittavat arkkitehtuurityylit. Palveluihin perustuvat arkkitehtuurityylit. Erikoisarkkitehtuurityylit

9. Ohjelmistoarkkitehtuurien arviointi

Ohjelmistoarkkitehtuurit, syksy

2 Ohjelmistoarkkitehtuurien kuvaus

Ohjelmistojen mallintaminen, kurssikoe esimerkkivastauksia

Ohjelmistoarkkitehtuurit. Syksy 2008

Ohjelmistotekniikan menetelmät, kevät 2008

Integrointi. Ohjelmistotekniikka kevät 2003

Ohjelmistokehykset ohjelmistorunkoja uudelleenkäyttö olioperustaisista ohjelmistorunko

Yksikkötestaus. import org.junit.test; public class LaskinTest public void testlaskimenluonti() { Laskin laskin = new Laskin(); } }

12. Kehysarkkitehtuurit

UML- mallinnus: Tilakaavio

ITK130 Ohjelmistojen luonne

CQRS, -ES, PACS, DICOM, WTF?

Sisäänrakennettu tietosuoja ja ohjelmistokehitys

T Projektikatselmus

T Projektikatselmus

TIEP114 Tietokoneen rakenne ja arkkitehtuuri, 3 op. FT Ari Viinikainen

Ohjelmistoarkkitehtuurit Kevät käytäntöjä

Ohjelmistojen mallintaminen Ohjelmiston suunnittelu Model driven development Harri Laine 1

Ohjelmistoarkkitehtuurit, syksy

Suorituskyky ja ohjelmistokehitys Suorituskykymallit

1 Johdanto. Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 1

Ohjelmoinnin peruskurssien laaja oppimäärä, kevät

Miten 333 organisaatiota voi kehittää yhtä yhteistä digitaalista palvelua ja vielä kuunnella kaikkien asiakkaita?

T Testiraportti - järjestelmätestaus

TeliaSonera Identity and Access Management

2.2 Muunnosten käyttöön tutustumista

VAATIMUSMÄÄRITTELY

Ohjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit

Työkalujen merkitys mittaamisessa

Opetusneuvos Anu Räisänen Erikoistutkija Jari Metsämuuronen

Sisäänrakennettu tietosuoja ja ohjelmistokehitys

Ohjelmistotekniikan menetelmät, kesä 2008

1510 Ihminen ja tietoliikennetekniikka

Käytettävyys verkko-opetuksessa Jussi Mantere

Metallien 3D-tulostus uudet liiketoimintamahdollisuudet

Testilähtöinen ohjelmistokehitys. Testilähtöinen ohjelmistokehitys. TDD Testilähtöinen ohjelmistokehitys. Testi! Testi

Testaussuunnitelma Labra

2.2 Muunnosten käyttöön tutustumista

10. Tuoterunkoarkkitehtuurit

Pikaohje QPR-käyttöön

Testaus käsite. Sekalaista testausasiaa. Testauksen käsitteestä. Kattavuusmitat. Jos ajatellaan, että testaus = V&V, voidaan erottaa:

Perusarkkitehtuurin ja vuorovaikutuksen mallintamisen perusteita.

Yleisiä asioita. Harkat alkavat ensi viikolla Vierailuluentoa. Slackin #luennot-kanava taas käytössä. Ensi viikon perjantaina, Janne Viitala, Sandvik

4. Luennon sisältö. Lineaarisen optimointitehtävän ratkaiseminen Simplex-menetelmä

Yhteistoimintakaavio (Esimerkki)

KYSYMYKSET TEKSTIVIESTINÄ Aloita viesti lyhenteellä SD ja kirjoita kysymyksesi tai palaute

MediaMark- ja NextMediahankkeiden

Johdanto. Agenda. Tuotantoprosessi. Historiallinen kehitys. Konsepti. Tuotantoprosessin vaiheet

TIEA241 Automaatit ja kieliopit, kesä Antti-Juhani Kaijanaho. 29. toukokuuta 2013

Transkriptio:

Bosch-malli Ohjelm!toarkkitehtuu"n suunni#elu 2$6 Quality Attribute-oriented Software Architecture Design method Toiminnallisista vaatimuksista laadittu arkkitehtuurimalli kehitetään arvioimalla sitä laadullisten vaatimusten täyttymisten mahdollisuuksien suhteen Kolme vaihetta Termistöä Toiminnalliset vaatimukset Toiminnallisuuden perusteella suunnittelu Arkkitehtuurin arviointi Arkkitehtuurin muokkaus Laatuvaatimukset Kehitys Operatiiviset Profiilit Käyttöprofiili, käyttöskenaariot

Metodin yleiskuva Toiminnasta arkkitehtuuriin Laadun varmistus yleensä projektin lopussa, eli liian myöhään Attribuutteja ei voida mitata kuin valmiista järjestelmästä Valmiin järjestelmän muuttaminen kallista Tosin: Alansa spesialistit, tacit knowledge Yksittäiseen laatuatribuuttiin erikoistuminen Toiminnallisista vaatimuksista luodaan ensimmäinen arkkitehtuurimalli Mallin elementit eivät ole sovellusalueen käsitteitä! Top-down, eikä bottom-up, kuten olioilla Arviointi Muokkaus Arvioidaan, voidaanko laatuatribuutit saavuttaa Mallit: Skenaarioperustainen Simulaatio Matemaattinen mallinnus Kokemus Pyritään mahdollistamaan laatuatribuutin täyttyminen Vaihtoehdot: Sovitetaan arkkitehtuurityyli Sovitetaan arkkitehtuurimalli (ortog, aspek.) Sovitetaan suunnittelumalli Muunnetaan vaatimukset toiminnallisuudeksi Hajautetaan vaatimukset

Asiakkaat Markkinointi Dilbertit Vaatimusmäärittely QASAR (iteratiivinen) Quality Attribute-Oriented Software Architecture Iteratiivinen tuotteen kehitys Yksityiskohtainen suunnittelu Toteutus Testaus (Puolivalmis) tuote Tuotteen käyttö Tuote Tuote valmis? Tuoteversio Iteratiivinen tuotteen kehitys Jakelu Vaatimuksen valinta Toiminnallisuuteen perustuva arkkitehtuuriratkaisu FR (Osittainen) vaatimusmäärittely Toiminnallisuuteen perustuva arkkitehtuuriratkaisu FR Vaatimusmäärittely Sovellusarkkitehtuuri QR Sovellusarkkitehtuuri Arkkitehtuurin muunnos Ei OK Arvioi laatuatribuuti OK Arkkitehtuurin muunnos Ei OK Arvioi laatuatribuuti QR QA-optimointi ratkaisut Lisää vaatimuksia? Kyllä QA-optimointi ratkaisut OK QASAR (iteratiivinen)

Arkkitehtuurin suunnittelu Esimalli toiminnallisin perustein Bosch: Valitaan käsiteltävät vaatimukset Luodaan toiminnallisten vaatimusten perusteella esimalli arkkitehtuurille Arvioidaan laatuatribuuttien täyttyminen Muokataan arkkitehtuuria Jatketaan, kunnes kaikki vaatimukset täyttyvät Määrittele järjestelmän konteksti Määrittele rajapinnat ja yhdistä nämä vaatimuksiin (toim. ja ei toim.) Tunnista arkkityypit, järjestelmän ydinabstraktiot Tunnista ehdokkaat ja valitse ehdokkaista pieni ja kestävä joukko; poista ehdokkaita jos tarpeen, mieluummin yhdistä Tunnista ja valitse suhteet arkkityyppien välillä Esimalli toiminnallisin perustein Arkkitehtuurin varmennus Jaa arkkitehtuuri komponentteihin Tunnista komponentit Komponentti muodostuu yhdestä tai useammasta arkkityypistä Tunnista komponenttien väliset suhteet Komponenttien väliset suhteet määräytyvät ja löytyvät myös arkkityyppien välisistä suhteista Luo pari esimerkkiä instantioiduista arkkitehtuureista Täyttyvätkö laadulliset vaatimukset? Profiilit Suorituskyky, ylläpidettävyys, luotettavuus, turvallisuus, varmuus Varmennus Skenaariot, simulaatio ja prototyyppi, matemaattinen mallinnus, kokemus

Arkkitehtuurin muokkaus Arkkitehtuurin muokkaus Vaiheet Tunnista ongelmalliset atribuutit Tunnista ongelmalliset kohteet Valitse muokkaustapa Muokkaa arkkitehtuuria Muokkaustavat Sovita arkkitehtuurityyli (Shaw & Garlan, Buschmann) Sovita arkkitehtuurimalli (aspektuaalinen) Samanaikaisuus, pysyväisyys, hajautus, graafinen käyttöliittymä Sovita suunnittelumalli Muunna laadullinen vaatimus toiminnallisuudeksi Itsemonitorointi, joustavuus Arkkitehtuurin muuntaminen Laatuatribuuttien arviointi Kun mikään muu ei onnistu Hajota ja hallitse! Susi on tapettava pentuna! Mittaaminen mahdotonta, joten arvioimme potentiaalia kvalitatiivinen vertaileva boolean tulos kvantitatiivinen 'absoluuttinen numeerinen tulos ei raja-arvoja, optimia

Laatuattribuuttien arviointi Profiilit teoreettisen maksimin arviointi optimi? teollisuus erotus opt-x auttaa arvioimaan laatua kvant. mahdollista, mutta usein kallista kvalit. usein riittävää Nykykäytännöt laatuattribuutit heikosti tai ylimalkaisesti spesifioitu "Ylläpidettävyyden oltava mahdollisimman hyvä." "Suorituskyvyn oltava riittävä keskivertokäyttäjälle." Profiilit Profiilit tutkijat keskittyneet omaan alaan teknologiat raskaita, kalliita, hankalia tarvitaan tietoa, jota ei ole arkk. suunnittelun aikana olemassa teollisuus ei ole ottanut menetelmiä käyttöön Määritelmä joukko skenaarioita näiden välinen tärkeys arvioituna

Skenaariot profiileihin Skenaariot profiileihin Kaikki skenaariot mukaan, tai valitaan osa skenaarioista: Hätäiseen tehtynä ajautuu vain GUIliitännäisiin skenaarioihin. Menetelmä hieman kattavampaan valintaan: Määrittele kategoriat Valitaan skenaariot per kategoria Skenaariot profiileihin Arviointitavat Lasketaan painot, suhteeliset tai absoluuttiset, skenaarioille Toimintatavat Yksin, ryhmässä, ensin yksin valmistellen, sitten ryhmässä tuotokset yhdistäen (Boschin suositus) Skenaarioperustainen Simulaatioperustainen Matemaattinen mallintaminen Kokemusperustainen

Skenaarioperustainen arviointi Simulaatioperustainen arviointi Kuten olioille mutta laatuatribuuteille muitakin skenaarioita kuin käyttöskenaario käyttötapaukset ovat optiomoiduille arkkitehtuureille, eivät sovi tähän touhuun Vaiheet vaikutusanalyysi laatuatrib. ennustaminen Hyvä vertailuun Vaiheet Määrittele ja toteuta konteksti Toteuta arkkitehtuurikomponentit Toteuta profiili Simuloi järjestelmää ja käynnistä profiili(t) Analysoi kerätty data ja ennusta laatuatribuutit Toimii myös toiminnallisille vaatimuksille Prototyypitys Matemaattinen mallintaminen Toteuta prototyyppi Älä näytä sitä asiakkaalle...... tai tee siitä ainakin ruma :) Aja sitä oikeassa ympäristössä Analysoi, ennusta Vaiheet Valitse ja sovita yleinen malli Esitä arkkitehtuuri mallin käsitteillä (sov. arkkit. malliin) Arvioi syöttö Ennusta laatuatribuutit tuloksista Metriikat, ajoitukset, resurssit Malleja ei olemassa kaikille laatuatribuuteille Simulaation kanssa vaihtoehtoinen

Kokemusperustainen arviointi Arvioinnin vaiheet Hyvä vs. huono suunnitelma...feel in my guts... Kerran Valitse tarvitut laatuatribuutit ja niiden tarvittu taso. Määrittele profiili jokaiselle atribuutille. Valitse arviointitapa jokaiselle laatuatribuutille. Arvioinnin vaiheet jatkuu Arkkitehtuurin muuntaminen Toistuvasti Tee arviointi sen hetkiselle arkkitehtuurille. Kerää tulokset ja tee päätökset: Jatketaan Uudelleenneuvottelu Lopetetaan Yleistä muuntamisesta Muuntamisen vaiheet Muuntamisen vaihtoehdot

Ymmärrys sovellusalueesta Ominaisuudet ja laatuattribuutit Tarve ymmärtää sovellusalue sovellusaluemallinnus arkkitehtuuri yhteiset käsitteet, määritelmät, yhteinen kuva järjestelmästä helpottavat keskustelua muutokset tekijäryhmässä vaikuttavat vähemmän Mikä estää arkkitehtuurin vaaditun ominaisuuden täyttymisen? laatuattribuutin arviointi laatuattribuutin konteksti, alijärjestelmä Laatuattribuutin parannus muokkaamalla kontekstia muokkaamalla arkkitehtuuria Muuntamisen vaikutukset Hyviä ja huonoja vaikutuksia, usein yhtäaikaisesti. Laajoja vaikutuksia läpi arkkitehtuurin, tai lokaaleja vaikutuksia. Muunnokset voivat viedä arkkitehtuurin kauemmas sovellusalueen käsitteistä, ja lisätä elementtien määrää huomattavasti. Muistettava pitää asiat selkeinä ja yksinkertaisina.

Muunnosvaihtoehdot Muuntamisen vaiheet 1 2 / 4 Arkkitehtuurityylin sovitus Arkkitehtuurimallin sovitus Suunnittelumallin sovitus Laatuvaatimusten muuntaminen toiminnallisiksi 1. Tunnista täyttymättömät laatuattribuutit nykyiset ja toivotut tasot enintään viisi käsittelyyn kerrallaan 2. Selvitetään mihin elementtiin kukin laatuattribuutti vaikuttaa Muuntamisen vaiheet 3 4 / 4 Arkkitehtuurin muuntaminen 3. Valitaan kullekin soveliain muunnos Valitaan muunnostapa vaihtoehdoista tai hajautetaan useaksi eri vaatimukseksi Varmistetaan attribuutin tason täyttyminen taso saa laskea, kunhan se pysyy hyväksyttynä 4. Muunnetaan arkkitehtuuri ja päivitetään kuvaukset Arkkitehtuurityylin sovitus Arkkitehtuurimallin sovitus Suunnittelumallin sovitus Laatuvaatimusten muuntaminen toiminnallisiksi Laatuvaatimusten hajauttaminen

Arkkitehtuurityylin sovitus Arkkitehtuurimallin sovitus Kuvastot: Shaw & Garlan Buschmann et al. Siemens-kirja Heidän mallit ovat muiden tyylejä. Vaikutusalue koko arkkitehtuuri. Ei monia yht'aikaisia tyylejä. Vaikuttaa koko arkkitehtuuriin, voi olla useita yht'aikaisia Voi laajentaa tai muuttaa komponenttien (elementtien) toimintaa Voi lisätä muutaman elementin Vaikutus tietotekniikka-alueessa, ei sovellusalueessa Arkkitehtuurimalleja Rinnakkaisuus Rinnakkaisuus Pysyväisyys Hajautus GUI Käyttöjärjestelmän prosessit Käyttöjärjestelmän säikeet Yhteistyömoniajo (non-preemptive threads) Sovellustasoinen moniajo

Pysyväisyys Hajautus Tietokantahallintajärjestelmät Sovellustasoinen pysyväisyys ja transaktiot Välittäjät (brokers) Etämetodikutsu Suunnittelumallin sovitus Ensin yksinkertaisesti monimutkaisuuteen tulee kasvaa.??? Kartoitettuja malleja suunnittelun ongelmiin. Kuvastoja: GoF; Siemens; Anti-mallit; Martin: Agile Software Development; PLOP-sarja; http://www.c2.com/ Vaikuttavat pieneen osaan arkkitehtuuria. Useita kerrallaan, muttei kaikkia.

Laatuvaatimukset toiminnallisiksi Laatuvaatimusten hajauttaminen Poikkeukset Itsemonitorointi Moninkertaiset järjestelmät Hajautetaan vaatimus usean elementin vastuulle Vikasietoisuuden jako: vikasietoisuuden laskenta vikasietoisuuden kommunikointi