Moniulotteisten ohjelmistojen hallinta

Transkriptio

1 Moniulotteisten ohjelmistojen hallinta Kai Koskimies Tampereen teknillinen yliopisto 1

2 Ohjelmistokehityksen kehitys Vaatimukset Ohjelmointikieli Programming-in-the-small Ongelma: ohjelmointikielen hallinta Sovellus 2

3 Ohjelmistokehityksen kehitys Vaatimukset Ohjelmointikieli Programming-in-the-large Ongelma: komponenttien riippuvuuksien hallinta Komponentti Komponentti Komponentti 3

4 Ohjelmistokehityksen kehitys Vaatimukset Ohjelmointikieli Programming-in-the-many Ongelma: ihmisten hallinta Komponentti Komponentti Komponentti 4

5 Ohjelmistokehityksen kehitys Vaatimukset Ohjelmointikieli malli malli Model-driven development Ongelma: monimutkaisuuden hallinta malli Komponentti Komponentti Komponentti 5

6 Ohjelmistokehityksen kehitys Vaatimukset Ohjelmointikieli Ohjelmistoalusta malli malli Tuoterungot Ongelma: muunneltavuuden hallinta malli Komponentti Komponentti Komponentti 6

7 Miksi ohjelmistojen hallinta on vaikeaa? Paljon erilaisia artifakteja Paljon erilaisia ihmisiä Paljon erilaisia teknologioita Paljon erilaisia riippuvuuksia 7

8 Järjestelmä koostuu erilaisista artifakteista Dokumentit Mallit Komponentit Skriptit Erilaiset resurssi- ym. tiedostot Tavoite: artifaktien ulkoiset riippuvuudet heikkoja, sisäiset vahvoja 8

9 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

10 Ongelma Miten liittää toisiinsa loogisesti yhteenkuuluvat osat eri artifakteissa? 10

11 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

12 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

13 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

14 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

15 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

16 Esimerkki (2) Tool Root setup instantiate RectangleTool RectangleTool Concept Client Instantiation Code ConcreteImpl instantiate 16

17 Esimerkki (2) Tool Root setup Concept Client Instantiation Code ConcreteImpl instantiate 17

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 FileStorage store Strategia-suunnittelumallin ilmentymä 18

19 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

20 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

21 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

22 Viipalemallin sovelluksia Sovelluskehyksen erikoistamistuki Ylläpidon tuki Järjestelmän ymmärtämisen tuki Muunneltavuuden hallinnan tuki Mallitransformaatioiden tuki (MDA) 22

23 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

24 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

25 Kirjallisuus Tool: I. Hammouda, J. Koskinen, M. Pussinen, M. Katara, T. Mikkonen: Adaptable concern-based framework specialization in UML. ASE 2004, Linz, Austria (2004) Framework specialization: Hakala M., Hautamäki J., Koskimies K., Paakki J., Viljamaa A., and Viljamaa J.: Generating application development environments for Java frameworks. GCSE Springer LNCS 2186, 2001, Maintenance: I. Hammouda, M. Harsu: Documenting maintenance tasks using maintenance patterns. International Conference on Software Maintenance & Reengineering 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 MDA model transformation: M. Siikarla, K. Koskimies and T. Systä: Open MDA using transformational patterns. MDAFA 2004, Linköping, Sweden, June 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

26 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