1 Johdanto 1.1 Mikä on ohjelmistoarkkitehtuuri? 1.2 Katsaus ohjelmistotuotannon kehittymiseen 1.3 Ohjelmistoarkkitehtuuri ja ohjelmistokehitysprosessi 1.4 Toteutusalustan arkkitehtuurin rooli 1.5 Yhteenvetoa Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1
1.1 Mikä on ohjelmistoarkkitehtuuri? Mitä asioita ohjelmistoarkkitehtuuri sisältää? - suunnittelumallit - rajapinnat - komponentit - ohjelmiston tietosisältö ja tietovirrat Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 2
Ohjelmistoarkkitehtuurin määritelmä Jokseenkin kaikilla on tästä hieman erilainen käsitys, Ks. http://www.sei.cmu.edu/architecture/definitions.html Kaksi eri arkkitehtuurikäsitystä: Suunniteltu arkkitehtuuri Suunnittelijan tahdonilmaus Olemassa olevan järjestelmän arkkitehtuuri Järjestelmän ominaisuus Ongelmia: Vain ideaalisessa maailmassa nämä ovat sama asia Yleensä ei tarkenneta kummasta puhutaan Toteutuksen arkkitehtuuri vaikeasti nähtävissä/määriteltävissä (milloin arkkitehtuurikuvaus on täydellinen?) Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 3
Arkkitehtuurifilosofiat Idealistinen: Pragmaattinen: järjestelmä järjestelmä kuvaa ratkaisut esitys arkkitehtuuri arkkitehtuuri arkkitehtuurin kuvaus arkkitehtuurin kuvaus Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 4
IEEE:n määritelmä Software architecture: The fundamental organization of a system embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution. (IEEE Standard 1471-2000) Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 5
Arkkitehtuuri järjestelmän kehitysperiaatteena "Architecture is the set of design decisions about any system that keeps its implementors and maintainers from exercising needless creativity." (D'Souza & Wills) - tietyn teknologian käyttö(tapa) - tiettyjen tietorakenteiden käyttö(tapa) - tiettyjen suunnittelumallien käyttö(tapa) - alustan käyttöön liittyvät säännöt - käyttösuhteiden säännöt - poikkeusten käsittelysäännöt Arkkitehtuuri = järjestelmän perustuslaki Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 6
Boehmin määritelmä: yhteys vaatimuksiin A software system architecture comprises A collection of software and system components, connections, and constraints A collection of system requirements A rationale which demonstrates that the components, connections, and constraints define a system that, if implemented, would satisfy the collection of system requirements Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 7
Bass & Clements in rajatumpi määritelmä The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 8
Pragmaattinen määritelmä: Kuvausperustainen arkkitehtuurikäsite Järjestelmän arkkitehtuuri on niiden (olemassaolevien) kuvausten joukko, jotka antavat järjestelmän keskeisistä suunnitteluratkaisuista ja niiden perusteista todenmukaista tietoa. Jos arkkitehtuuri on riittävä informaatio järjestelmän suunnitteluratkaisuista sen toteuttajille ja ylläpitäjille koko sen elinkaaren ajan, sanomme että arkkitehtuuri on riittävä. Jos arkkitehtuurin mukainen järjestelmä on mahdollista rakentaa, sanomme että arkkitehtuuri on kelvollinen. Kelvollinen arkkitehtuuri ei esimerkiksi sisällä keskenään ristiriitaisia kuvauksia. Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 9
Kuvausperustainen arkkitehtuurikäsite Seurauksia: Arkkitehtuuri ei ole järjestelmän sisäinen ominaisuus, vaan ulkopuolista tietoa järjestelmästä: arkkitehtuuri on suunnittelijan tahdonilmaus, järjestelmää koskeva sopimus Järjestelmästä voi päätellä joitakin arkkitehtuurikuvauksia, mutta ei yleensä riittävää arkkitehtuuria Järjestelmä ja sen arkkitehtuuri ovat erillisiä, informaatioltaan osittain päällekkäisiä artifakteja Kaikilla on yhtenevä käsitys arkkitehtuurista ( = olemassa olevien arkkitehtuurikuvausten joukko) Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 10
Kuvausperustainen arkkitehtuurikäsite Kaikki eivät ole samaa mieltä: Esim. Bass&Clements: Even though every system has an architecture, it does not necessarily follow that the architecture is known to any one.. This reveals the difference between the architecture and the representation of that architecture. Unfortunately, an architecture can exist independently of its description or specification, which raises the importance of architecture documentation and architecture reconstruction. Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 11
Synteesi: tämän kurssin määritelmä IEEE:n määritelmää mukaillen: The description of the fundamental organization of a system embodied in its components, the rationale behind this organization, and the principles guiding its design and evolution. Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 12
Arkkitehtuuri ja laatu Ohjelmiston arkkitehtuuri määräytyy pääasiassa sen laatuvaatimusten, ei toiminnallisten vaatimusten perusteella Arkkitehtuuri on tapa ottaa huomioon järjestelmän laatuvaatimukset ohjelmistokehitysprosessissa Mikä tahansa järjestelmä voidaan toiminnallisuuden puolesta toteuttaa millä tahansa arkkitehtuurilla, joka koostuu toisiinsa liittyvistä komponenteista (ts., toiminnallisuus voidaan sijoitella miten hyvänsä järjestelmän osiin, jos mikään osa ei ole irrallinen muusta järjestelmästä). Pelkän loogisen toiminnallisuuden kannalta arkkitehtuuri ei ole kovin merkittävä. Toiminta A Toiminta B A tarvitsee B:tä? Kuinka usein? Millainen yhteys? => Suorituskyky Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 13
1.2 Katsaus ohjelmistotuotannon kehittymiseen Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 14
Ohjelmointi Vaatimukset Ohjelmointikieli Vaatimusten toteutus ohjelmointikielellä Ohjelma Programming-in-the-small Ongelma: Ohjelmointikielen hallinta Ratkaisu: Ohjelmointiympäristöt Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 15
Järjestelmäkehitys Vaatimukset Ohjelmointikieli Programming-in-the-large Ongelma: Riippuvuuksien hallinta Ratkaisu: Arkkitehtuuri Komponent Komponent Komponent Komponentti Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 16
Ohjelmistotuotanto Vaatimukset Ohjelmointikieli Prosessi Programming-in-the-many Ongelma: Ihmisten hallinta Ratkaisu: Prosessi Komponent Komponent Komponent Komponentti Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 17
Hajautetut järjestelmät Vaatimukset Ohjelmointikieli Prosessi Ongelma: Järjestelmän hajauttaminen, rinnakkaisuus Ratkaisu: Arkkitehtuuri Komponent Komponent Komponent Komponentti Rinnakkaiset laitealustat Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 18
Mallipohjainen ohjelmistotuotanto Vaatimukset Ohjelmointikieli malli malli malli Model-driven development Ongelma: Monimutkaisuuden hallinta Ratkaisu: Abstraktio, mallintaminen, arkkitehtuuri Komponent Komponent Komponent Komponentti Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 19
Model-Driven Development (MDD) Bran Selic Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 20
Tuoteperheet Vaatimukset malli Ohjelmointikieli Ohjelmointialusta malli Ongelma: Varioitavuuden hallinta Ratkaisu: Arkkitehtuuri + prosessi malli Komponent Komponent Komponent Komponentti Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 21
Globaali ohjelmistokehitys Vaatimukset malli Ohjelmointikieli Ohjelmointialusta malli Ongelma: Työn hajauttaminen Ratkaisu: Arkkitehtuuri + prosessi malli Komponent Komponent Komponent Komponentti Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka22
Liiketoimintapalvelut Palvelut Vaatimukset malli Ohjelmointikieli Ohjelmointialusta malli malli Ongelma: Integrointi liiketoimintaan Ratkaisu: Arkkitehtuuri (SOA) Komponent Komponent Komponent Komponentti Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 23
Ohjelmointialusta Liiketoimintapalvelut Ohjelmistotuotanto tänään Vaatimukset malli Ohjelmointikieli malli malli Komponent Komponent Komponent Komponentti Ohjelmistoarkkitehtuuri on avain - komponentien välisten suhteiden hallintaan - järjestelmien monimutkaisuuden hallintaan - ohjelmistojen varioitavuuden hallintaan - ohjelmistokehityksen ja laskennan hajauttamiseen - liiketoimintaintegrointiin Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 24
Taloussanomat 2.9.2005 Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 25
Miksi ohjelmistoarkkitehtuuri on tärkeä? Tarjoaa abstraktiotason, jolla monet keskeiset järjestelmän kehittämiseen liittyvät ongelmat ratkaistaan Keskeinen kommunikoinnin väline ohjelmiston elinkaaren aikana: määrittelee ja nimeää järjestelmän keskeiset osat, ratkaisut, käsitteet Järjestelmän perustuslaki, kartta, ja opas: antaa rajat ja helpottaa (tai tekee mahdolliseksi) järjestelmän rakentamista, testausta, ylläpitoa ja uudelleenkäyttöä Ensimmäinen analysoitavissa oleva järjestelmän esitysmuoto: järjestelmää voidaan testata ennen toteutusta Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 26
Epäonnistuneen ohjelmistoarkkitehtuurin seurauksia järjestelmää ei pystytä toteuttamaan järjestelmä ei valmistu suunnitellussa ajassa järjestelmä ei skaalaudu järjestelmä on tehoton järjestelmää on vaikea testata järjestelmää on vaikea ylläpitää järjestelmää ei pystytä uudelleenkäyttämään järjestelmää ei pystytä siirtämään toiseen ympäristöön Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 27
Syitä epäonnistuneeseen arkkitehtuuriin: - huono kommunikaatio - arkkitehtuurin kannalta olennaisia vaatimuksia ei ole otettu huomioon - arkkitehti on kokematon tai heikkotahtoinen - johdolta tuleva painostus - kehitysprosessi ei tue arkkitehtuuria - muita? Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 28
1.3 Ohjelmistoarkkitehtuuri ja ohjelmistokehitysprosessi Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 29
Arkkitehtuurin kehittäminen Laatuvaatimukset Arkkitehtuurin kannalta merkittävät vaatimukset Vaatimusanalyysi Keskeiset toiminnalliset vaatimukset Ympäristövaatimukset Alustava arkkitehtuuri Alustava arkkitehtuurisuunnittelu Laatuvaatimuksen huomiointi Rajoitteet Yleisten ratkaisumallien soveltaminen Arkkitehtuurimuunnos ei OK OK Toissijaiset toiminnalliset vaatimukset Kaikki käsitelty Inkrementaalisuus, agile: pienin toteutettavissa oleva arkkitehtuuri -> toteutus Yksityiskohtainen suunnittelu Arkkitehtuurin arviointi Arkkitehtuuri Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 30
Ohjelmiston jako komponentteihin Perusteena voi olla: toiminnallisuus yleisyys hajautus muutosherkkyys intressi, huolenaihe (concern)... huolenaihe Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 31
Arkkitehtuurin kannalta merkittävät vaatimukset Keskeiset toiminnalliset vaatimukset (mitä järjestelmä tekee) - Usein lähtökohta arkkitehtuurin suunnittelulle Laatuvaatimukset (miten tehdään) vaikuttavat tyypillisesti olennaisesti arkkitehtuuriin ( ei-toiminnalliset vaatimukset ) - Esim. suorituskyky, muunneltavuus, skaalautuvuus, hinta, ylläpidettävyys, siirrettävyys, uudelleenkäytettävyys jne. Kehitysympäristövaatimukset - Järjestelmä on pystyttävä järkevästi kehittämään tietyssä organisaatiossa (esim. hajautettu kehitys) Suoritusympäristövaatimukset - Esim. Sulautetun järjestelmän laiteympäristö Ympäristövaatimukset Rajoitteet - Esim. tietyn teknologian sanelemat Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 32
Vaatimukset Arkkitehtuurin kannalta merkittävät vaatimukset on yleensä priorisoitu - Tyypillisesti yksi tai kaksi laatuvaatimusta dominoi arkkitehtuuria, vähemmän tärkeiden täytyy mukautua Vaatimusten ja arkkitehtuuriratkaisujen yhteyden säilyttäminen olennaista - Kuinka järjestelmä täyttää arkkitehtuurin kannalta merkittävät vaatimukset, erityisesti laatuvaatimukset Vaatimukset muuttuvat järjestelmän elinkaaren aikana - Walking on water and developing software from specifications are easy tasks when both are frozen (E. Bevard) Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 33
Laatuvaatimusten yhteentörmäys Piirrerunsaus, nopeasti saatavilla, yhteensopivuus Suorituskyky, luotettavuus, käytettävyys Muunneltavuus, testattavuus Kustannus, resurssitarve Markkinointi Loppukäyttäjä Ylläpitäjä Hinta, stabiilisuus, toimitusvarmuus, Johto Arkkitehti Asiakas Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 34
Arkkitehtuuriratkaisujen valinta Ratkaisu 2 Ratkaisu 1 Ratkaisu 3 Jo tehdyt ratkaisut rajoittavat Mahdollisten uusien ratkaisujen joukkoa Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 35
Ohjelmistoarkkitehtuuri ja organisaatio alijärjestelmä liiketoimintayksikkö järjestelmä ryhmä henkilö henkilö komponentti komponentti komponentti henkilö => Conway n laki arkkitehtuurin rakenne = organisaation rakenne Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 36
Arkkitehtuurin arviointi Monet ohjelmiston laatuominaisuudet olisivat pääteltävissä jo arkkitehtuurikuvauksesta (esim. tiukka kerrosarkkitehtuuri -> suorituskykyongelmat) Arkkitehtuurin arviointi = laatuvaatimusten tarkennus + arkkitehtuurin arviointi laatuvaatimuksia vasten (esim. ATAM) Arkkitehtuurin arviointi on ohjelmiston testaamista sen ensimmäisen täsmällisen kuvauksen perusteella Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 37
1.4 Toteutusalustan arkkitehtuurin rooli Ohjelmistoalusta pakottaa sovellukselle usein tietyn arkkitehtuurin Sovellus rakennetaan tämän arkkitehtuurin ehdoilla Sovelluskehityksen keskeinen kysymys on miten vaatimukset saadaan toteutettua alustan tarjoamilla välineillä Esimerkiksi: Miten vaatimukset toteutetaan JavaBeans-arkkitehtuurissa? Miten vaatimukset toteutetaan Symbian OS -arkkitehtuurissa? Miten vaatimukset toteutetaan tietyssä GUI-arkkitehtuurissa? Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 38
Kehitys kulkee kohti arkkitehtuuritason toteutusvälineitä Toteutusvälineet: ohjelmointikieli ohjelmistoarkkitehtuuri Muuttujat Aliohjelmat Luokat Komponentit Alustat Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 39
Mitä vaatimuksia tämä asettaa ohjelmistoarkkitehtuurille? Kun ohjelmistoarkkitehtuuri on osa toteutusvälineistön kuvausta, sen tulee olla: geneerinen: sopiva monille sovelluksille tavallisen ohjelmoijan ymmärrettävissä kuvattu täsmällisesti ja kattavasti kuvattu käyttäjän (so. sovellusohjemoijan) kannalta Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 40
1.5 Yhteenvetoa Ohjelmistoarkkitehtuuri on järjestelmän keskeisiä ratkaisuja koskeva kuvaus, joka mahdollistaa järjestelmän hallinnan sen elinkaaren aikana Ohjelmistoarkkitehtuurilla ja ohjelmiston laadulla on kiinteä yhteys: arkkitehtuuri on suuressa määrin laatuominaisuuksien varmistamista Ohjelmistokehityksestä on tullut arkkitehtuurikeskeistä: monet lähestymistavat ja teknologiat perustuvat tai liittyvät läheisesti arkkitehtuuriin Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 41