Arkkitehdin arkipäivää Sandvikilla Janne Viitala Sandvik

Transkriptio

1 Arkkitehdin arkipäivää Sandvikilla Janne Viitala Sandvik

2 Motivaatio Arkkitehtuureilla on väliä Aamulehti, pääkirjoitus: Avoin väylämalli myös Suomeen Viron potilastietojärjestelmä pohjautuu Enterprise Service Bus arkkitehtuurimalliin. Viro: 10M Suomi: 1800M Service Bus 2

3 Agenda Arkkitehdin arkipäivä Mikä ihmeen Sandvik? Käytönnön kokemuksia ja havaintoja arkkitehdin työstä teollisuudessa Suunnittelu Dokumentointi Kommunikointi Muutama nyrkkisääntö 3

4 Disclaimer T.s. Vastuu on kuulijalla Esitetyt mielipiteet ja näkemykset ovat esittäjän omia eivätkä vastaa Sandvikin, TTY:n, tai minkään muunkaan instanssin virallisia tai epävirallisia mielipiteitä. Tuskin tulee tentiin. 4

5 5 Mikä Sandvik? Lyhyt intro

6 Heritage Founded 1862 in Sandviken, Sweden Göran Fredrik Göransson redesigned the Bessemer furnace to mass-produce steel A breakthrough and an innovation started the company 150 years ago

7 Sandvik/Tamrock Historia Tampella 1856 Tamperelaista konepajaperinnettä Paineilmaporakoneita 50-luvulta Tampellan Porakoneyksikkö ==> Tamrock (1969) Myllypuroon -70 luvun alussa Tamrock ==> Sandvik (1997) Sandvik Mining ja Sandvik Construction 7

8 8 Tuotteita Sandvik Mining

9 Ohjelmistot Sandvikin laitteissa Esimerkkejä Porauksen ohjaus (painemittauksia ja -ohjauksia, pumppujen ohjausta, jne) Puomin ohjaus (asemamittaus, paikoitus erilaisissa koordinaatistossa, taipuma yms. kompensoinnint) GPS-pohjainen porakruunun paikannus ja paikoitus Graafiset käyttöliitymät operaattorille ja huollolle (mittarit/indikaattorit, porakaaviot, diagnostiikka,...) Tiedonkeruu ja raportointi SICA-platform! Lisäksi erilaisia off-board sovelluksia (etäoperointi, valvonta, porakaavioiden luonti/käsittely, kivianalyysi,...) 9

10 10 SW-arkkitehdin työstä Case Sandvik

11 Arkkitehti? Määritelmä Suunnittelee suurehkon ohjelmiston rakenteen komponenttitasolla Dokumentoi suunnitelman riittävällä tarkkuudella Toivottavasti osallistuu hommaan tämän jälkeenkin jollakin tavalla (koodaus, katselmoinnit, testaussuunnittelu, ) Eli mitä tässä esityksessä ei tarkoiteta arkkitehdistä puhuttaessa: Arkkitehtuurin dokumentoijaa Koodaria joka vastaa osaltaan toteuttamansa komponentin arkkitehtuurista 11

12 Arkkitehdin työ Yleiskatsaus 1)Suunnittelee ohjelmiston rakenteen tietyllä tasolla 2)Dokumentoi suunnitelman riittävällä tarkkuudella 1) 3) 3)Kommunikoi arkkitehtuurin sidosryhmille (kehittäjät, testaus, projektin vetäjät, johto,...) 2) Ja toivottavasti osallistuu hommaan tämän jälkeenkin jollakin tavalla (koodaus, katselmoinnit, testaussuunnittelu, ) 12

13 Järjestelmän suunnittelu Mitä se edellyttää? Yleinen sw-osaaminen Kyky hahmottaa ja hallita monimutkaisia kokonaisuuksia Järjestelmän arkkitehtuurin yhtenäisyys, unifying vision Sovellusalue-osaaminen! 13

14 SW osaaminen Mitä se on Vahva koodaustaito & -kokemus käytetyillä kielillä Arkkitehdin tulee osata koodata! Tärkeää koska: devil is in the details Oliomenetelmät, UML, yleiset patternit (GoF),... Arkkitehdin tulisi nähdä ja pystyä esittämään miten periaatteessa mikä tahansa toiminto järjestelmässä toteutetaan. 14

15 SW osaaminen UML, oliomenetelmät, jne UML on de-facto mallinnus-/kuvausmenetelmä UML käytännön tasolla ( 20% UML:stä riittää 80% tarpeisiin - Ivar Jacobson) Kannattaa huomioida että käytännössä UML-osaamisen taso vaihtelee! Management, wanhat parrat,... Sovellusspesialistit ja järjestelmäsuunnittelijat SysML vielä tuntematon Perus-design patternit (GoF) Vesi KahvinPorot Hyvä työkalupakki suunnitteluun. Myös tehokkaita kommunikaatiovälineenä! ( käyttöliittymätoiminnot toteutetaan Commandpatternia käyttäen ).

16 Sovellusalue (=Domain) osaaminen Mitä se on? Käytännön kokemusta kyseiseltä sovellusalueelta Tyypillisiä ongelmia Tyypillisiä ratkaisuita Tärkeää koska Vaatimukset eivät koskaan kerro kaikkea! Etenkään ei-toiminnalliset. Siksi ne tarvii haistaa. Muutoksiin varautuminen Vaikka vaatimukset kertoisivatkin kaiken, tulee tietää mikä toimii ja mikä ei (ja miksi). 16

17 Sovellusalue osaaminen Miten kartuttaa? Tekemällä oppii! Alakohtaisia pattern-kataloogeja, esim. TTY:n koneenohjauspatternit 17

18 Sovellusalueosaaminen Esimerkki Suunnittele yleiskäyttöinen työkoneen hälytysjärjestelmä Mistä asioista tehdään hälytyksiä? Miten ne esitetään käyttäjälle? API sovellusohjelmoijille? Vasteaikavaatimuksia? Pysyvä talletus? Siirto koneen ulkopuolelle? Miten konfiguroidaan eri kone-, väylä- ja ohjaintyypeille? Tulevaisuuden näkymiä? Mihin varautua? Yleisesti käytetyt/tunnetut ratkaisut? Miten petrata? ==>ja sitten suunnittelu 18

19 Sovellusalueosaaminen Esimerkki Työkoneiden elinkaarihalinta Sarjatuonannon vaatimukset? Huolto? Varaosat? Elektroniikan elinkaari < koneen elinkaari Elektroniikka tyypillisesti paranee ja halpenee koko ajan Vanhentuva elektroniikka puolestaan kallistuu Kuitenkin tarve kustannustehokkuuteen Tällaiset vaatimukset toisinaan nousevat esiin vasta kun laite on saatu valmiiksi 19

20 Järjestelmän suunnittelu Tyypillisiä ongelmia Pieleen mennyt arkkitehtuuri keskeisimpiä syitä projektin epäonnistumiseen. Tyypillisiä ongelmia: Norsunluutorni-arkkitehtuuri Ylisuunnittelu Väärät abstraktiot [N]IH ==> Antipatternit

21 Antipatternit Lyhyt intro viisas oppii toisten virheistä omiensa sijaan Huonoja toteutus- tai toimintamalleja Voivat liittyä sw-rakenteeseen, organisaatioon, projektinhallintaan yms. toimintatapoihin Vrt. Design patternit jotka liittyvät sw-rakenteeseen Vrt. Prosessi joka liittyy toimintatapoihin Antiprosessi? Idea: sovellusaluekohtaisia antipatterneja? Vrt. Sovellusaluekohtaiset design patternit

22 Norsunluutorni-arkkitehtuuri Arkkitehtuurisuunnittelu tehdään huomioimatta detaljeita joita käytännön työssä kuitenkin kohdataan. laatikkokuva == järjestelmä virhe? Tyypillisiä syitä: Liikaa työtä arkkitehdille devil is in the details Domain-osaamisen puutteet Kompetenssin puute 22

23 Overengineering Tarpeettoman monimutkainen rakenne, "excessive future-proofing" Spagettikoodin vastakohta (liikaa rakennetta vs. toiminnallisuus) Esimerkki; speksi sanooo 'tee C++ ohjelma joka tulostaa terve maailma '. Triviaali toteutus: #include <iostream> void main () { std::cout << terve maailma << end; } Vaihtoehto b: Celestial Object Greeter Framework (TM)

24 COGFrameWork +setcelestialobjectfactory (ICOFactory) +setgreetingfactory (ICOFactory) +greetcelestialobject () Common Framework CelestialObject +name (): string -printname (); Greeter +greet (): string -printgreeting (); IGreeterFactory +createcelestialobject (): CelestialObject ICelectialObjectFactory +createcelestialobject (): CelestialObject World HelloSayer MyGreeterFactory MyCelectialObjectFactory Greeter specific <<create>> <<create>> Application

25 #include <iostream> class ICelectialObjectFactory; class IGreeterFactory; class CelestialObject { friend class COGFrameWork; public: virtual const char *name () = 0; private: void printname () { std::cout << name (); } }; class Greeter { friend class COGFrameWork; public: virtual const char *greet () = 0; private: void printgreeting () { std::cout << greet (); } }; class ICelectialObjectFactory { public: virtual CelestialObject *createcelestialobject () = 0; }; class IGreeterFactory { public: virtual Greeter *creategreeter () = 0; }; class COGFrameWork { public: void setcelestialobjectfactory (ICelectialObjectFactory* f) { m_celestielobjectfactory = f; } void setgreeterfactory (IGreeterFactory* f) { m_greeterfactory = f; } void greetcelestialobject () { CelestialObject *o = m_celestielobjectfactory- >createcelestialobject (); Greeter *g = m_greeterfactory->creategreeter (); } g->printgreeting (); std::cout << " "; o->printname (); std::cout << std::endl; private : ICelectialObjectFactory *m_celestielobjectfactory; IGreeterFactory *m_greeterfactory; }; class World : public CelestialObject { public: const char *name () { return "maailma"; } }; class HelloSayer : public Greeter { public: const char *greet () { return "terve"; } }; class MyCelectialObjectFactory : public ICelectialObjectFactory { public: CelestialObject *createcelestialobject () { return new World; } }; class MyGreeterFactory : public IGreeterFactory { public: Greeter *creategreeter () { return new HelloSayer; } }; Lähdekoodi ~150LoC int main () { COGFrameWork *fw = new COGFrameWork; MyCelectialObjectFactory *cof = new MyCelectialObjectFactory; MyGreeterFactory *gf = new MyGreeterFactory; fw->setcelestialobjectfactory (cof); fw->setgreeterfactory (gf); fw->greetcelestialobject (); }

26 Overengineering Seurauksia Monimutkaisuus kasvattaa monimutkaisuutta, esim COGW: Puuttuu virhetarkistuksia ja pitää suunnitella miten virhetilanteet hallitaan Muistinhallinnassa bugeja Koodimäärä == Konfigurointimäärä > kovakoodauksen määrä jonka se korvaa (esim. 'muuta ohjelma tulostamaan lisäksi terve Mars ') 26

27 Virheelliset abstraktiot Suunnitteluongelmana Muutospyyntö: 'muuta ohjelma tulostamaan terve Belgia ' ==> taivaankappale nimeltä Belgia! T.s. Valittu väärä abstraktio, mikä haittaa uudelleenkäyttöä ja ylläpitoa. Tyyppillinen seuraus puutteellisesta domain-osaamisesta. 27

28 [Not] Invented Here Suunnitteluongelmana IH: Käytetään ratkaisua johon on tykästytty tyyppillisesti itse kehitettyä. Käyttö riippumatta siitä soveltuuko se tehtävään ensinkään NIH: Ei käytetä toimivaa valmista ratkaisua vaikka se teknis-taloudellisesti olisi perusteltua, koska oma toteutus on jotenkin maagisesti parempi. Korjataan toimiva valmis ratkaisu rikkinäiseksi

29 Muita yleisiä antipatterneita Organisaatioon/toimintaan liittyviä: Analysis Paralyzis (ei domain osaamista) Design by Committee ( unifying vision...) GodClass SW-suunnitteluun liittyviä: God class Fat interface Kirjallisuutta on, kannattaa tutustua.

30 Arkkitehtuurin dokumennista

31 Arkkitehtuurin dokumentointi Tarpeita ja haasteita Tarvittava taso riippuu täysin sidosryhmistä! Esim: Pieni kokenut teami samassa projektihuoneessa ==> kevyt Offshoring ==> raskas ja yksityiskohtainen dokumentaatio, tarkka seuranta! Pitkä elinkaari edellyttää parempaa dokumentaatiota. 31

32 Arkkitehtuurin dokumentointi Mitä dokumentoidaan? Pelkät UML-kaavit kertovat miten, tarviiko dokumentoida myös miksi? Jos tätä ei dokumentoida, kasvaa riski siihen että jatkossa tehdään tavoitteiden kanssa ristiriitaisia ratkaisuita. ==> unifying vision menetätään Yksi lähestymistapa on dokumentoida nimenomaan arkkitehtuuripäätökset ja niiden perustelut. 32

33 Arkkitehtuurin dokumentointi Mallipohjaisuus vai ei? Mallipohjainen: Luodaan UML-malli järjestelmästä vaatii CASE työkalun Myös suunnittelutyökalu, ei pelkkä dokumentaatio Tyypillisesti koodin generointi, round-trip engineering Nojaa vahvasti työkaluihin hyvässä ja pahassa (millaista koodia työkalu generoi, toimiiko round-trip, jne) Havainnollistaminen: Pelkkä kuva mikä tahansa piirto-ohjema UML-symboleilla toimii Joustava Ongelma: kuvan ja todellisuuden vastaavuus; ristiriitaisuudet 33

34 Arkkitehtuurin dokumentointi Design Patternit Tehokkaita ovat tehokkaita kommunikaatiovälineitä, kannattaa hyödyntää. Välittävät rakenteen lisäksi tietoa myös arkkitehtuurin tavoitteista, koska patternit (toivottavasti) valitaan niiden perusteella: käyttöliittymätoiminnot toteutetaan Command-patternia käyttäen ==> undo/redo, hajautus kenties mielessä Mona Lisa Ajoalustan GUI-toiminnot piilotetaan Bridge:n taakse ==> portattavuus vissiin tärkeää 34

35 Arkkitehtuurin dokumentointi Sandvik malli Ei mallinnusta, ei API dokumentaatiota arkkitehtuuridokumentaatiossa Kuvataan konsepteja - t.s. järjestelmän osatoimintoja. Rakenne komponenttien tasolla (komponentit, riippuvuudet, interaktiot) Selitetään miten ja miksi järjestelmä toimii tältä osin Toiminta käyttäjän näkökulmasta (sis. Kuvaruutumalleja, toimintakuvauksia) Komponettien tehtävät ja vastuut (vrt. API) Myös hylättyjä ratkaisuita ja perusteluita Tavoite luoda komponenti tekijälle ymmärrys siitä mitä pitää tehdä, sekä komponentin käyttäjille ymmärrys miten, miksi ja milloin sitä käytetään. Kuvaus läpi järjestelmän (koneenohjaimet, väylät, service-taso, GUI, liitynnät ulkomaailmaan), vrt. viipaleet (aspects). Esim. hälytykset, parametrit, varaosien asennus, lukitukset,... 35

36 36 Arkkitehtuurin kommunikointi

37 Arkkitehtuurin kommunikointi Mitä ja miten? Kuten dokumentaatiossa, taso riippuu täysin ihmisistä ja organisaatiosta Kokenut teami projektihuoneessa, tai yhden hengen projekti vs Offshore alihankkija projekti Keinoja: Dokumenttien läpikäynti, koulutus, osallistuminen tekemiseen, katselmoinnit, Jälleen: Design Patternit 37

38 Kommunikaatio-ongelmat Sidosryhmille ei välity käsitystä siitä mitä ollaan tekemässä. Tyypillisiä syitä: Kehno dokumentaatio/koulutus/esitystapa Ei seurantaa (esim. katselmointeja tai arkkitehdin osallistumista toteutukseen) Sidosryhmien fyysinen välimatka (off-site, off-shore) Kompetenssi (esim. maallikot) Aiempi kokemus (=oletukset) Asenne, kulttuurierot Usein vaikea arvioida miten onnistuttu kommunikoimaan.?? 38

39 39 Nyrkkisääntöjä

40 Nyrkkisääntöjä Käytännön tilanteisiin Uudelleenkäytettävän koodin tekeminen on 3 kertaa kalliimpaa kuin kertakäyttöisen Jos koodista tarvii uudelleenkäytössä muuttaa >20%, niin on halvempi kirjoittaa se tyhjästä uudelleen SW-teamien tuottavuudessa voi olla 26x eroja Tuntihinnassa voi olla 3x eroja (offshoring) Homma on 80% valmis 80% ajasta HUOM: nyrkkisääntö on vain nyrkkisääntö 40

41 41

42 Heading Subtitle text 42