Moniulotteisten ohjelmistojen hallinta Kai Koskimies Tampereen teknillinen yliopisto http://www.cs.tut.fi/~kk http://practise.cs.tut.fi 1
Ohjelmistokehityksen kehitys Vaatimukset Ohjelmointikieli Programming-in-the-small Ongelma: ohjelmointikielen hallinta Sovellus 2
Ohjelmistokehityksen kehitys Vaatimukset Ohjelmointikieli Programming-in-the-large Ongelma: komponenttien riippuvuuksien hallinta Komponentti Komponentti Komponentti 3
Ohjelmistokehityksen kehitys Vaatimukset Ohjelmointikieli Programming-in-the-many Ongelma: ihmisten hallinta Komponentti Komponentti Komponentti 4
Ohjelmistokehityksen kehitys Vaatimukset Ohjelmointikieli malli malli Model-driven development Ongelma: monimutkaisuuden hallinta malli Komponentti Komponentti Komponentti 5
Ohjelmistokehityksen kehitys Vaatimukset Ohjelmointikieli Ohjelmistoalusta malli malli Tuoterungot Ongelma: muunneltavuuden hallinta malli Komponentti Komponentti Komponentti 6
Miksi ohjelmistojen hallinta on vaikeaa? Paljon erilaisia artifakteja Paljon erilaisia ihmisiä Paljon erilaisia teknologioita Paljon erilaisia riippuvuuksia 7
Järjestelmä koostuu erilaisista artifakteista Dokumentit Mallit Komponentit Skriptit Erilaiset resurssi- ym. tiedostot Tavoite: artifaktien ulkoiset riippuvuudet heikkoja, sisäiset vahvoja 8
Mutta mikään tapa jakaa ohjelmistojärjestelmä osiin ei voi koskaan olla riittävä eristämään huolenaiheet omiin artifakteihinsa Tyypillisiä artifaktien poikki kulkevia huolenaiheita: - tuoterunkojen variaation hallinta - ylläpitotehtävään liittyvät kohdat järjestelmässä - käyttötapaukset - järjestelmän ulospäin näkyvät piirteet - yleiset globaalit huolenaiheet (esim. turvallisuus) - suunnittelumallit -jne 9
Ongelma Miten liittää toisiinsa loogisesti yhteenkuuluvat osat eri artifakteissa? 10
Miten poikki kulkevia huolenaiheita "hallitaan" teollisuudessa? - dokumentoinnilla - kommentoinnilla - ohjelmointikonventioilla (esim. nimeämisellä) - jäljitystä tukevilla työkaluilla - henkilökohtaisella kommunikoinnilla - palavereilla - mutta useimmiten ei oikein mitenkään 11
Erilaiset artifaktityypit Arkkitehtuurimalli Requirement 4.34: Requirement 4.35: Requirement 4.36: public class Person extends Customer { public Person(String name) { super(name); dosomething(); } void store() {.., } } Lähdekoodi <persistence> <transaction> </transaction> </persistence> Vaatimusspeksi Yksityiskohtainen malli XML-kuvaustiedosto 12
Viipalemallit Artifaktien ulkopuolinen tapa määritellä järjestelmän alkioiden muodostama konfiguraatio alkioiden välisine suhteineen ja riippuvuuksineen Viipalemalli koostuu rooleista, joihin voidaan sitoa järjestelmän alkioita eri artifakteista, kunhan ne täyttävät mallin antamat rajoitteet Viipalemalli - voi esittää minkä hyvänsä poikkikulkevan huolenaiheen - ei riipu tietystä artifaktityypistä tai notaatiosta 13
Työkalun avulla - kuvataan viipalemallit - sidotaan järjestelmän elementtejä mallin rooleihin - tarkistetaan, että mallin rajoitteet pätevät sidotuille elementeille - voidaan generoida ehdot täyttävät elementit (malli määrittelee oletuselem.) - säilytetään tieto viipaleesta eri tarkoituksia varten (esim. visual.) Työkalutuki viipalemalleille Olemassa oleva työkalu Req Req tool UML Java XML Rose Eclipse XML editori Viipaletyökalu (MADE) Eclipse Viipalemallin ilmentymä Rooleja 14
rajoite Esimerkki (1) sidonnat Customer id getid is-contained-by Class(*) is-contained-by rooli Field(*) returns Getter(1) { elementname = get + Field.elementName} kuinka monta sidontaa rajoite 15
Esimerkki (2) Tool Root setup instantiate RectangleTool RectangleTool Concept Client Instantiation Code ConcreteImpl instantiate 16
Esimerkki (2) Tool Root setup Concept Client Instantiation Code ConcreteImpl instantiate 17
Esimerkki (3) Requirements: Person serialize storemethod <<interface>> Storage store Req 3.45: It should be possible to easily change the storage media for business entities FileStorage store Strategia-suunnittelumallin ilmentymä 18
Esimerkki (3) Requirements: Person serialize storemethod <<interface>> Storage store Req 3.45: It should be possible to easily change the storage media for business entities Strategia-suunnittelumallin ilmentymä 19
Viipalemallien hyödyntäminen A B A B p Tarkistus: Päteekö p(a,b)? p Generointi: Generoi B niin että p(a,b) pätee x y x y A B A B Visualisointi: Näytä osat, jotka kuuluvat viipaleeseen x y Jäljitys: Olettaen B, mikä on A tässä viipaleessa? 20
Viipalemallin etuja Itse järjestelmään ei tarvitse koskea, ja sen artifakteja voidaan luoda ja ylläpitää tavanomaisin menetelmin Viipaleet voivat olla päällekkäisiä: sama elementti voi olla useissa rooleissa eri viipalemalleissa Työkalu voi muuntaa sitomattoman tai osittain sidotun viipalemallin ohjeistetuksi tehtävälistaksi Tehtävälistan avulla sitominen (viipaleen muodostus) tapahtuu askeleittain, ja suunnittelija pysyy kärryillä siitä mitä tapahtuu, ei magiikkaa Samaa mekanismia voi käyttää moniin tarkoituksiin Perusmekanismi ei ota kantaa artifaktityyppiin tai -notaatioon 21
Viipalemallin sovelluksia Sovelluskehyksen erikoistamistuki Ylläpidon tuki Järjestelmän ymmärtämisen tuki Muunneltavuuden hallinnan tuki Mallitransformaatioiden tuki (MDA) 22
Viipalemallin käyttö piirrepohjaiseen variaationhallintaan Käyttötapoja: - generointi - visualisointi Piirremalli - jäljitys A F B C Design malli X Y MyB XB oper instantiate XB MyB Toteutus class MyB extends X { } class Y { void oper() { b = new MyB(): } 23
Yhteenvetoa Viipalemalli on kevyt ratkaisu aspektien esittämiseen: järjestelmä voidaan kehittää perinteisin menetelmin Viipalemalli on suhteellisen yksinkertainen mekanismi, joka on osoittautunut yllättävän monikäyttöiseksi Toisaalta: jos sinulla on vasara, kaikki näyttää naulalta Onko tämä lähestymistapa kannattava käytännössä? Pieniä kokeiluja todellisilla ohjelmistoilla on tehty kohtalaisen positiivisin tuloksin, mutta käytännöllisen hyödyn arviointi edelleen työn alla Rajoituksia: olettaa hyvät API:t ohjelmistokehitysympäristön työkaluilta 24
Kirjallisuus Tool: I. Hammouda, J. Koskinen, M. Pussinen, M. Katara, T. Mikkonen: Adaptable concern-based framework specialization in UML. ASE 2004, Linz, Austria (2004) 78 87. Framework specialization: Hakala M., Hautamäki J., Koskimies K., Paakki J., Viljamaa A., and Viljamaa J.: Generating application development environments for Java frameworks. GCSE 2001. Springer LNCS 2186, 2001, 163-176. Maintenance: I. Hammouda, M. Harsu: Documenting maintenance tasks using maintenance patterns. International Conference on Software Maintenance & Reengineering 2004. System comprehension: I. Hammouda, O. Guldogan, K. Koskimies, and T. Systä: Tool-supported customization of UML class diagrams for learning complex system models. International Workshop on Program Comprehension 2004. MDA model transformation: M. Siikarla, K. Koskimies and T. Systä: Open MDA using transformational patterns. MDAFA 2004, Linköping, Sweden, June 2004. Feature-driven variability management: I. Hammouda, J. Hautamäki, M. Pussinen and K. Koskimies: Managing variability using heterogeneous feature variation patterns. To appear in FASE 2005, Edinbourgh. 25
User interface Rose A UML model being constructed according to a pattern The used pattern library A view to an instance of a pattern (roles) A task list to carry out the bindings at this point Instructions for doing a binding task Eclipse based GUI 26