Arkkitehdin arkipäivää Sandvikillaohar/luennot/luennot2012/Vierailuluento_1.pdf · Sandvik...
Transcript of Arkkitehdin arkipäivää Sandvikillaohar/luennot/luennot2012/Vierailuluento_1.pdf · Sandvik...
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