1 Johdanto 1.1 Mikä on ohjelmistoarkkitehtuuri? 1.2 Ohjelmistoarkkitehtuuri ja laatuvaatimukset 1.3 Katsaus ohjelmistotuotannon kehittymiseen 1.4 Miksi ohjelmistoarkkitehtuuri on tärkeä 1.5 Ohjelmistoarkkitehtuuri ja ohjelmistokehitysprosessi 1.6 Ohjelmistoarkkitehtuuri ja organisaatio 1.7 Ohjelmiston osittaminen 1.8 Toteutusalustan arkkitehtuuri 1.9 Yhteenvetoa 1 Pieni motivointikalvo 2 1.1 Mikä on ohjelmistoarkkitehtuuri? Mitä asioita ohjelmistoarkkitehtuuri sisältää? - Miten toiminnallisuus on jaettu alijärjestelmien kesken? - Miten alijärjestelmät kommunikoivat keskenään? 3 1
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, järjestelmälle määritelty, spesifikaatio Olemassa olevan järjestelmän arkkitehtuuri Järjestelmän ominaisuus, järjestelmän määrittelemä Ongelmia: Vain ideaalisessa maailmassa nämä ovat sama asia Yleensä ei tarkenneta kummasta puhutaan Suunniteltua arkkitehtuuria ei ole välttämättä dokumentoitu Toteutuksen arkkitehtuuri vaikeasti nähtävissä/määriteltävissä 4 Arkkitehtuurifilosofiat arkkitehtuuri järjestelmä järjestelmä esitys kuvaa ratkaisut arkkitehtuuri arkkitehtuurin kuvaus Idealistinen arkkitehtuurin kuvaus Pragmaattinen 5 Standardien määritelmät 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) Software architecture: The fundamental conception of a system in its environment embodied in elements, their relationships to each other and to the environment, and the principles guiding its design and evolution. (ISO/IEC 42010) 6 2
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) - tietyt kiinnitetyt perusratkaisut - tietyn teknologian käyttö(tapa) - tiettyjen tietorakenteiden käyttö(tapa) - tiettyjen suunnitteluen käyttö(tapa) - käyttösuhteiden säännöt - poikkeusten käsittelysäännöt Arkkitehtuuri = järjestelmän laki 7 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 8 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. 9 3
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. 10 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, laki Arkkitehtuuri on olemassa ennen järjestelmän rakentamista, se ei ole vain olemassa olevan järjestelmän kuvaus 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) Jos oletetaan, että arkkitehtuurikuvaukset ovat todenmukaisia, tietyn järjestelmän arkkitehtuuri on aina hyvin määritelty Arkkitehtuuri voi olla hyvä tai huono monessa mielessä (vrt. laki) 11 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. Oikeastaan tarvittaisiin kaksi eri arkkitehtuurikäsitettä 12 4
1.2 Ohjelmistoarkkitehtuuri ja laatuvaatimukset 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 13 1.3 Katsaus ohjelmistotuotannon kehittymiseen 14 Ohjelmointi Vaatimusten toteutus ohjelmointikielellä Ohjelma Programming-in-the-small Ongelma: Ohjelmointikielen hallinta Ratkaisu: Ohjelmointiympäristöt 15 5
Järjestelmäkehitys Programming-in-the-large Ongelma: Riippuvuuksien hallinta Ratkaisu: Arkkitehtuuri 16 Ohjelmistotuotanto Prosessi Programming-in-the-many Ongelma: Ihmisten hallinta Ratkaisu: Prosessi 17 Hajautetut järjestelmät Prosessi Ongelma: Järjestelmän hajauttaminen, rinnakkaisuus Ratkaisu: Arkkitehtuuri Rinnakkaiset laitealustat 18 6
Mallipohjainen ohjelmistotuotanto Model-driven development Ongelma: Monimutkaisuuden hallinta Ratkaisu: Abstraktio, ntaminen, arkkitehtuuri 19 Model-Driven Development (MDD) Bran Selic 20 Tuoteperheet Ohjelmointialusta Ongelma: Varioitavuuden hallinta Ratkaisu: Arkkitehtuuri + prosessi 21 7
Globaali ohjelmistokehitys Ohjelmointialusta Ongelma: Työn hajauttaminen Ratkaisu: Arkkitehtuuri + prosessi 22 Palvelut Ongelma: Integrointi liiketoimintaan Ratkaisu: Arkkitehtuuri (SOA) 23 Ohjelmistotuotanto tänään Ohjelmointialusta Liiketoimintapalvelut Ohjelmointialusta Liiketoimintapalvelut Ohjelmistoarkkitehtuuri on avain - komponentien välisten suhteiden hallintaan - järjestelmien monimutkaisuuden hallintaan - ohjelmistojen muunneltavuuden hallintaan - ohjelmistokehityksen ja laskennan hajauttamiseen - liiketoimintaintegrointiin 24 8
Taloussanomat 2.9.2005 25 1.4 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 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 27 9
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? 28 1.5 Ohjelmistoarkkitehtuuri ja ohjelmistokehitysprosessi 29 Arkkitehtuurin kehittäminen Laatuvaatimukset Arkkitehtuurin kannalta merkittävät vaatimukset Vaatimusanalyysi Inkrementaalisuus, agile: pienin toteutettavissa oleva arkkitehtuuri -> toteutus Keskeiset toiminnalliset vaatimukset Arkkitehtuurimuunnos Ympäristövaatimukset Rajoitteet Toissijaiset toiminnalliset vaatimukset Yksityiskohtainen suunnittelu Alustava arkkitehtuuri Yleisten ratkaisuen soveltaminen Arkkitehtuurin arviointi Alustava arkkitehtuurisuunnittelu Laatuvaatimuksen huomiointi ei OK Kaikki käsitelty Arkkitehtuuri OK 30 10
Arkkitehtuurin kehittäminen 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ö Rajoitteet - Esim. tietyn teknologian sanelemat Ympäristövaatimukset 32 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 muuttuvat järjestelmän elinkaaren aikana - Walking on water and developing software from specifications are easy tasks when both are frozen (E. Bevard) 33 11
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 34 Arkkitehtuurin arviointi Monet ohjelmiston laatuominaisuudet olisivat pääteltävissä jo arkkitehtuurikuvauksesta (esim. tiukka kerrosarkkitehtuuri -> suorituskykyongelmat) Arkkitehtuurin arviointi = laatuvaatimusten tarkennus + arkkitehtuurin arviointi tarkennettuja laatuvaatimuksia vasten (esim. ATAM) Arkkitehtuurin arviointi on ohjelmiston testaamista sen ensimmäisen täsmällisen kuvauksen perusteella 35 1.6 Ohjelmistoarkkitehtuuri ja organisaatio alijärjestelmä liiketoimintayksikkö järjestelmä ryhmä henkilö henkilö komponentti komponentti Conwayn laki: arkkitehtuurin rakenne = organisaation rakenne 36 12
1.7 Ohjelmiston osittaminen Perusteena voi olla: toiminnallisuus yleisyys hajautus muutosherkkyys intressi, huolenaihe (concern)... huolenaihe 37 Aspektien käyttö läpikulkevan toiminnan toteutukseen around advice Esim. lokitietojen kerääminen, käyttöoikeuksien tarkistus Marko Lahma 38 1.8 Toteutusalustan arkkitehtuuri 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 J2EE-alustalla? Miten vaatimukset toteutetaan Symbian-alustalla? Miten vaatimukset toteutetaan Qt-alustalla? 39 13
Kehitys kulkee kohti arkkitehtuuritason toteutusvälineitä Toteutusvälineet: Muuttujat Aliohjelmat ohjelmointikieli Luokat ohjelmistoarkkitehtuuri Komponentit Alustat 40 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 41 1.9 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 tukemista Ohjelmistokehityksestä on tullut arkkitehtuurikeskeistä: monet lähestymistavat ja teknologiat perustuvat tai liittyvät läheisesti arkkitehtuuriin 42 14