Suunnitteluratkaisut ja niiden arviointi sulautetuissa järjestelmissä

Transkriptio

1 1 Suunnitteluratkaisut ja niiden arviointi sulautetuissa järjestelmissä Kai Koskimies Tampereen teknillinen yliopisto

2 Taustaa: Sulake projekti Osallistujat Areva T&D John Deere Kone Sandvik TTY Tavoitteet Ohjelmistoarkkitehtuurin arviointimenetelmien soveltaminen koneenrakennusteollisuudessa (ATAM) Hyvien suunnitteluratkaisujen kerääminen ja dokumentointi koneenohjausjärjestelmistä

3 3 Ohjelmistojen laatuominaisuudet Ajoaikaiset laatuominaisuudet Suorituskyky Tilankäyttö Luotettavuus Saatavuus Tietoturvallisuus Opittavuus Käytettävyys Kehitys- ja evoluutioaikaiset laatuominaisuudet: Muunneltavuus Siirrettävyys Ylläpidettävyys Uudelleenkäytettävyys Laatustandardit: esim. ISO 9126

4 4 Ohjelmistoarkkitehtuuri ja laatuvaatimukset Ohjelmistoarkkitehtuuri on tapa toteuttaa ohjelmiston laatuvaatimukset Ohjelmistoarkkitehtuuri määrää miten hyvin (useimmat) laatuvaatimukset toteutuvat Ohjelmistoarkkitehtuuri arvioidaan (yleensä) vasten laatuvaatimuksia

5 5 Mitä on ohjelmistoarkkitehtuurien arviointi?? Vaatimusten tarkennus Skenaariot Analyysi Laatuvaatimukset Ohjelmistoarkkitehtuuri Arkkitehtuuriratkaisut Ratkaisujen identifiointi

6 6 Skenaariot Arkkitehtuurin testitapaus : konkreettinen tilanne ohjelmiston käytön tai evoluution aikana, jossa ohjelmiston tietty laatuvaatimus tulee esiin. Esimerkki:

7 Sulake prosessin tietovuo 7 Koodin laaturaportti 4 Suunnittelumallien dokumentointi 50 Suunnittelumallit Kohdejärjestelmä Koodianalyysi Suunnittelumallikieli Teollisuus Vaatimusdokumentit Piilotieto vaatimuksista Kyselyt Laatuvaatimusten tarkennus Skenaariot Priorisointi Valitut skenaariot Arkkitehtuurianalyysi Tutkimusteemat Arviointi raportit 10 Tutkimusyhteisö Laatustandardit Arkkitehtuuridokumentointi Piilotieto arkkitehtuurista Yritys

8 Perusongelma skenaariopohjaisessa arkkitehtuurin arvioinnissa 8 Miten löydetään kattavat skenaariot mahdollisimman tehokkaasti? Vaatimusten tarkennus Skenaariot Analyysi Laatuvaatimukset Ohjelmistoarkkitehtuuri Arkkitehtuuriratkaisut Ratkaisujen identifiointi Analogia: testitapausten löytäminen Skenaariot edellyttävät luovuutta ja tietoa Skenaarioille ei ole ilmeisiä kattavuusmääritelmiä Skenaarioiden ajaminen on kallista

9 Idea: johdetaan yleisiä skenaarioita koneenohjaukseen domain-mallin avulla 9 Node Yleinen skenaario Control functionality Intelligent sensor Log feed Boom movement Harvesteri skenaario Cabin door sensor Pressure sensor Porauskone skenaario

10 Arviointiraportti: skenaariokohtaiset analyysit 10 Tyypillisesti priorisoitua skenaariota Skenaarioon liittyvät arkkitehtuuriratkaisut luokitellaan riskittömiksi tai riskeiksi Arkkitehdin selvitys skenaarion hoitumisesta kirjataan

11 11 Esimerkki koneenohjauksen suunnittelumallista VARIABLE MANAGER Context A distributed embedded control system with several autonomous units. The units must share common state information about the system as a whole. ISOLATE FUNCTIONALITIES has been applied. The architect needs to abstract source and location of the information. There is a need to access all the data providers independently. Problem How can you efficiently share system state in the distributed machine control system? Forces Accuracy: Data is volatile. Efficiency: Message traffic should be minimized. Scalability: System must be scalable in terms of its units. Extendability: It should be easy to add new units accessing the state. Adaptability: It should be easy to change the way state is implemented. Adaptability: It should be easy to change the location of origin of the state information. Usability: It should be easy to find the desired state value.

12 12 Esimerkki jatkuu Solution The architect adds a common variable manager module to every node that contains the shared state variables needed by the node. The local value of the remote variable can be updated when a changed value is noticed on the bus. The values of the variables are sent and updated using different strategies: by-request, periodically, as a side-effect for example when another variable is updated. A value can have an associated status or age. If SANDBOX pattern is applied to the system, variable manager can be implemented on the sandbox node. Then it can contain the shared state of the whole system. Node notifychange register LocalVarTable Bus VarManager getvalue setvalue valuechange Component

13 Suunnittelumallikieli (Pattern language) 13 Suunnittelumalleilla pyritään kattamaan tärkeimmät yleiset koneenohjausjärjestelmien suunnitteluratkaisut Useita ennestään dokumentoimattomia malleja, monet löytyvät myös muista lähteistä Suunnittelumallien kuvauksia on työstetty kansainvälisissä workshopeissa (PLoP)

14 14 Koodin laaturaportit Tutkimusalihankintana Szegedin yliopistosta (Unkari) Raportissa yhteenveto erilaisista metriikoista (riippuvuudet, kompleksisuus, koodin kopiointi) Pahat hajut ja yleiset koodausvirheet Analyysissä käytetään Columbus-työkalua

15 Haasteet arkkitehtuurien arvioinnissa 15 Hyödyllisten skenaarioiden tehokas löytäminen Skenaarioiden kattavuusongelma Arkkitehtuuriarvioinnin integroiminen osaksi ohjelmistokehitysprosessia Kevyt, lean, inkrementaalinen arkkitehtuurin suunnittelu, dokumentointi ja arviointi Arkkitehtuuriarvioinnin tulosten arviointi

16 Yhteenvetoa 16 Ohjelmistoarkkitehtuurien arvioinnilla saavutetaan etuja: Suunnittelun testaus : vahvistaa hyvät ratkaisut, kiinnittää huomion kyseenalaisiin ratkaisuihin Tarjoaa luontevan kommunikointitilaisuuden eri osapuolten välille Tarjoaa tilaisuuden kerätä yrityksen ohjelmistoihin kätkeytyvää tietotaitoa Kerätty suunnittelumallien kokoelma tiivistää olennaisen osan koneenohjausjärjestelmien suunnittelutietoudesta Ohjelmistoarkkitehtuurien arviointimenetelmiä tulisi kehittää kattavammiksi, luotettavammiksi, ja kevyemmiksi

17 Linkkejä 17 R.S. Hanmer: Patterns for Fault Tolerant Software. Wiley Clements P., Kazman R., Klein M.: Evaluating Software Architectures. Addison- Wesley Eloranta V-P., Hartikainen V-M., Leppänen M., Reijonen V., Haikala I., Koskimies K. and Mikkonen T.: Patterns for Distributed Embedded Control System Software Architecture, Tampere University of Technology, Department of Software Systems, Report 2,

18 Kiitos! 18