Arkkitehdin arkipäivää SandvikillaJanne ViitalaSandvik

Arkkitehtuureilla on väliäMotivaatio

2

• Aamulehti, pääkirjoitus: “Avoin väylämalli myös Suomeen”

• Viron potilastietojärjestelmä pohjautuu Enterprise Service Bus arkkitehtuurimalliin.

• Viro: 10M€

• Suomi: 1800M€

Service Bus

33

• Mikä ihmeen Sandvik?

• Käytönnön kokemuksia ja havaintoja arkkitehdin työstä teollisuudessa

• Suunnittelu

• Dokumentointi

• Kommunikointi

• Muutama nyrkkisääntö

Arkkitehdin arkipäiväAgenda

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.

T.s. Vastuu on kuulijallaDisclaimer

4

Lyhyt introMikä Sandvik?

5

Founded 1862 in Sandviken, SwedenGöran Fredrik Göransson redesigned the Bessemer furnace to mass-produce steelA breakthrough and an innovation started the company 150 years ago

Heritage

• Tampella 1856 – Tamperelaista konepajaperinnettä

• Paineilmaporakoneita 50-luvulta

• Tampellan Porakoneyksikkö ==> Tamrock (1969)

• Myllypuroon -70 luvun alussa

• Tamrock ==> Sandvik (1997)

• Sandvik Mining ja Sandvik Construction

HistoriaSandvik/Tamrock

7

SandvikMining

Tuotteita

8

• 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, ...)

EsimerkkejäOhjelmistot Sandvikin laitteissa

9

Case SandvikSW-arkkitehdin työstä

10

• 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

MääritelmäArkkitehti?

11

YleiskatsausArkkitehdin työ

12

1)Suunnittelee ohjelmiston rakenteen tietyllä tasolla

2)Dokumentoi suunnitelman riittävällä tarkkuudella

3)Kommunikoi arkkitehtuurin sidosryhmille (kehittäjät, testaus, projektin vetäjät, johto, ...)

Ja toivottavasti osallistuu hommaan tämän jälkeenkin jollakin tavalla (koodaus, katselmoinnit, testaussuunnittelu, …)

1)

2)

3)

• Yleinen sw-osaaminen

• Kyky hahmottaa ja hallita monimutkaisia kokonaisuuksia

• Järjestelmän arkkitehtuurin yhtenäisyys, “unifying vision”

• Sovellusalue-osaaminen!

Mitä se edellyttää?Järjestelmän suunnittelu

13

• 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.

Mitä se onSW osaaminen

14

SW osaaminenUML, 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)

• Hyvä “työkalupakki” suunnitteluun.

• Myös tehokkaita kommunikaatiovälineenä! (“käyttöliittymätoiminnot toteutetaan Command-patternia käyttäen”).

KahvinPorot

Vesi

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).

Mitä se on?Sovellusalue (=Domain) osaaminen

16

• Tekemällä oppii!

• Alakohtaisia pattern-kataloogeja, esim. TTY:n koneenohjauspatternit

Miten kartuttaa?Sovellusalue osaaminen

17

“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

EsimerkkiSovellusalueosaaminen

18

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”

EsimerkkiSovellusalueosaaminen

19

Järjestelmän suunnitteluTyypillisiä ongelmia

Pieleen mennyt arkkitehtuuri keskeisimpiä syitä projektin epäonnistumiseen.

Tyypillisiä ongelmia:

• Norsunluutorni-arkkitehtuuri

• Ylisuunnittelu

• Väärät abstraktiot

• [N]IH

==> Antipatternit

AntipatternitLyhyt 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

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

Norsunluutorni-arkkitehtuuri

22

?

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)

CelestialObject

World HelloSayer

Greeter

+greet (): string-printGreeting ();

+name (): string-printName ();

COGFrameWork

+setCelestialObjectFactory (ICOFactory)+setGreetingFactory (ICOFactory)+greetCelestialObject ()

ICelectialObjectFactory

+createCelestialObject (): CelestialObject

IGreeterFactory

+createCelestialObject (): CelestialObject

MyCelectialObjectFactory

<<create>>

<<create>>

MyGreeterFactory

CommonFramework

Greeter specific

Application

#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; }};

int main (){ COGFrameWork *fw = new COGFrameWork; MyCelectialObjectFactory *cof = new MyCelectialObjectFactory; MyGreeterFactory *gf = new MyGreeterFactory; fw->setCelestialObjectFactory (cof); fw->setGreeterFactory (gf); fw->greetCelestialObject ();}

Lähdekoodi~150LoC

• 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”')

SeurauksiaOverengineering

26

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.

SuunnitteluongelmanaVirheelliset abstraktiot

27

[Not] Invented HereSuunnitteluongelmana

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

Muita yleisiä antipatterneita

Organisaatioon/toimintaan liittyviä:

• Analysis Paralyzis (ei domain osaamista)

• Design by Committee (“unifying vision”...)

SW-suunnitteluun liittyviä:

• God class

• Fat interface

Kirjallisuutta on, kannattaa tutustua.

GodClass

Arkkitehtuurin dokumennista

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.

Tarpeita ja haasteitaArkkitehtuurin dokumentointi

31

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.

Mitä dokumentoidaan?Arkkitehtuurin dokumentointi

32

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

Mallipohjaisuus vai ei?Arkkitehtuurin dokumentointi

33

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ä

• “Ajoalustan GUI-toiminnot piilotetaan Bridge:n taakse” ==> portattavuus vissiin tärkeää

Design PatternitArkkitehtuurin dokumentointi

34

“MonaLisa”

• 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”, ...

Sandvik malliArkkitehtuurin dokumentointi

35

Arkkitehtuurin kommunikointi

36

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

Mitä ja miten?Arkkitehtuurin kommunikointi

37

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.

Kommunikaatio-ongelmat

38

?

?

Nyrkkisääntöjä

39

• 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ö

Nyrkkisääntöjä

40

Käytännön tilanteisiin

41

www.sandvik.com

• text

SubtitleHeading

42