Ohjelmistoarkkitehtuurit, TTY

Vierailuluento

Mika Siikarla, 31.1.2012

Jotain IHAN muuta...

Tamperelainen ohjelmistotalo

Bitwise pähkinänkuoressa

• Sopivan kokoinen (43 henkeä)

• Kannattavan kasvava, AAA

• Koko tuplaantui laman aikana

• Vuonna 2012 palkattu 12 henkeä

• Hyvässä paikassa (Viinikan ympyrässä)

Bitwise valittiin Suomen parhaaksi työpaikaksi 2012

Bitwiserit hoitavat projektit, joihin kukaan muu pysty

• haasteita• mielenkiintoisia pulmia• vaihtelevia tehtäviä• jatkuvaa uuden oppimista• yhdessä tekemistä

onnistumisia sankaritarinoita tyytyväiset asiakkaat

• Kaikki on helppoa (=lean)

• Ketterät menetelmät

• Markkinoiden parhaat välineet ja työkalut

• Jokaisella mahdollisuus vaikuttaa

• Kaikki mukana asiakasrajapinnassa

• Projektikierto

• Mukana koko elinkaaressa

• Tiimi istuu samassa huoneessa

• Mentori valmentaa

• Illaksi kotiin

» .NET, C#, C++

» JavaEE, Spring 3, EJB3, GWT, JSF2, PrimeFaces, JPA2, JTA, JCA, JMS, OSGi, Play 2.0...

» sulautetut järjestelmät, C

» Python, Django

» JavaScript, node.js, CoffeeScript

» HTML5, CSS3, LESS, Jquery

» PHP, Perl, TCL

» Web Services, REST, SOAP, CORBA, Remoting, RMI

» SOA, ESB

» PostgreSQL, Oracle, SQLServer, MySQL, MongoDB, CouchDB, light-tietokannat, ORM-kehykset

» WPF, Qt, Java FX2, Swing, AWT, Windows Forms...

» Linux, Windows, Unix, Solaris, reaaliaikaytimet

» Scrum, Kanban, CI, TDD, BDD

» Git, SVN, Jenkins, Bamboo, JIRA, Trac

Mm. näillä teknologioilla

Bitwise etsii ihmisiä,

joilla on

• Halu oppia

• Kyky oppia

• Rohkeutta hypätä uuteen

• Maalaisjärkeä

• Ammattiylpeyttä

• Input ja output

• Tiimipelitaitoja

• Pohojalaanen tekemisen meininki

• Rohkeutta olla oma itsensä

Bitwise houkuttelee opiskelijaa

Kukaan ei ole guru syntyessään

– meillä voit kasvaa sellaiseksi

Tarjolla

• Osa-aikaisia töitä

• Kesätöitä

• Lopputyöaiheita

Bonuksena palkallinen päivä viikossa kirjoittamiseen

Hyvät kaverit vakinaistetaan, poikkeuksetta

Ryhdy bitwiseriksi!

Lue lisää www.bitwise.fi

Lähetä hakemus rekry@bitwise.fi

Vastuuvapauslauseke

MIELIPIDE

Omia henkilökohtaisia mielipiteitäni.

Tietysti ovat ainoita oikeita!

Ehkä joku muukin on joskus ollut samaa mieltä joistakin kohdista.

”These are my principles. If you don’t like them I have others.”

- Groucho Marx (ilmeisesti ei)

Aivot päälle.

RIIPPUU VASTAAJASTA JA KYSYJÄSTÄ(ja ehkä aiheestakin)

Arkkitehtuuri

ARKKITEHTUURI

Suunnittelijan näkökulmasta joukko suunnittelua rajoittavia sääntöjä.

Se mitä suunnittelija mielestään saa tehdä.

Se mitä arkkitehdin mielestä suunnittelija saa tehdä.

Subjektiivisia! Ei ole olemassa ”todellista” arkkitehtuuria.

Ei RTFC, ei takaisinmallinnettavissa.

ON (ja vaatii) KOMMUNIKOINTIA(dokumentointi, keskustelu, … ?)

ARKKITEHTUURI

Teknisessä mielessä koodista voidaan löytää komponentteja ja niiden välisiä suhteita, mutta mitkä ovat säännöt?

Vrt. pelinappulat ja lauta ilman pelin sääntöjä.

Tai pelinappulalta vaikuttavia osia...

ON (ja vaatii) KOMMUNIKOINTIA

Arkkitehti

ARKKITEHTI

En ole ammatiltani arkkitehti. Minun ammattini on ohjelmistosuunnittelija.

Bitwisellä ei ole töissä ketään, jonka ammatti on arkkitehti.

EI ASU TÄÄLLÄ

ARKKITEHTI

Hän, joka tekee arkkitehtuurin (osan)...

sillä hetkellä, kun hän tekee {}...

siltä osin kuin hänen tekemisensä liittyy {}.

Rooli, tietyssä suhteessa ja tietyssä kontekstissa.

Kuten kuuntelija, puhuja, veli, opettaja, oppilas, ajaja, ...

ON ARKKITEHTI TOIMIESSAAN ARKKITEHTINA(da Vinci)

ARKKITEHTI

ArchitectAlsoImplementshttp://orgpatterns.wikispaces.com/ArchitectAlsoImplements

”The Architect [...] should himself or herself write code.”

”[...] it is crucial that the architect have a strong feel for the application needs. It is by understanding recurring application needs that the architect can build long-term robust frameworks. If architects work only on infrastructure […] there will be a disconnect between the infrastructure (framework, middleware) and the application.”

OSS: Eat your own dog food.

TOIMII MYÖS TOTEUTTAJANA

Vaatimukset → Arkkitehtuuri

VAATIMUKSET

PERUSTELEVAT ARKKITEHTUURIN

(Erityisesti ei-toiminnalliset) vaatimukset rajoittavat arkkitehtuuria.

Arkkitehtuuripäätösten perustelut vaatimuksista.

Vaatimukset

Arkkitehtuuri

toteuttaa

VAATIMUKSET

ELÄVÄT(elääkö arkkitehtuuri?)

Vaatimusten muutosten pitäisi näkyä arkkitehtuurin muutoksina.

Ehkä otettu huomioon?

Ehkä vanha kelpaa?

Ehkä kohta palataan takaisin?

Massa: uutta vai parempaa?

Vaatimukset

Arkkitehtuuri

toteuttaa

Vaatimukset

Arkkitehtuuri

toteuttaa

Vaatimukset

Arkkitehtuuri

toteuttaa

VAATIMUKSET

EIVÄT AINA TIEDOSSA

Jos Kun vaatimuksia ei tunneta kokonaisuudessaan, onko arkkitehtuurille kokonaisuudessaan perusteita?

Esim. suorituskyky, suoritustapa.

Lukitaanko vastaus?

?a??im?k?e?

Ar??it?h??uri

toteuttaa??

Kurkistus oikeaan maailmaan

OHJELMISTO

TYHJIÖSSÄ

J

Asiakas

OHJELMISTO

YMPÄRISTÖSSÄÄN(muiden ohjelmistojen kanssa)

J +

Toimittaja Operaattori

OHJELMISTO

YMPÄRISTÖSSÄÄN(laitteiden ja muiden ohjelmistojen kanssa)

J +

Toimittaja Operaattori

OHJELMISTO

YMPÄRISTÖSSÄÄN(prosessien, laitteiden ja muiden ohjelmistojen kanssa)

J +

Toimittaja Operaattori

OHJELMISTO

YMPÄRISTÖSSÄÄN(integrointien, prosessien, laitteiden ja muiden ohjelmistojen kanssa)

J +

Toimittaja Operaattori

Ekskursio ympäristöön

TOIMINTAYMPÄRISTÖ

Ohjelmistoja: ohjaus, turvallisuus, tarkkailu

Koneita: autom., ajettuja, etäohjattuja, autom.+etä

Tilaa: 3D, jaettua, neuvoteltua

Esineitä: siirrettäviä

Esteitä: pysyviä, tilapäisiä

Rajoitteita: kulku, käyttö; loogisia, osittaisia

Infraa: antureita, kytkimiä, verkkoja

Ihmisiä

Suurin osa operaattorin hallinnassa, pieni osa ei...

ON MONIMUOTOINEN

MITÄ EI VAADITA

Ei (suoranaista) (yksin)vastuuta ihmisten hengestä tai terveydestä.

Ei kovia reaaliaikavaatimuksia.

Suurin osa toiminnallisuudesta ei vaadi resursseihin nähden intensiivistä laskentaa, muistia tai tallennusta.

ON OSA VAATIMUKSIA(ja siksi vaikuttaa arkkitehtuurin prioriteetteihin)

Backtrack palluroihin

OperaattoriOperaattoriOperaattoriOperaattori

OHJELMISTO

MONESSA YMPÄRISTÖSSÄ

Toimittaja

OHJELMISTO

YHDESSÄ YMPÄRISTÖSSÄ(integrointien, prosessien, laitteiden ja muiden ohjelmistojen kanssa)

J +

Toimittaja Operaattori

OHJELMISTO

TOISESSA YMPÄRISTÖSSÄ(integrointien, prosessien, laitteiden ja muiden ohjelmistojen kanssa)

J +

Toimittaja Operaattori

? ? ? ?

? ? ? ? ?? ? ?

?

OHJELMISTO

TULEVASSA YMPÄRISTÖSSÄ(integrointien, prosessien, laitteiden ja muiden ohjelmistojen kanssa)

J +

Toimittaja Operaattori

TOIMINTAYMPÄRISTÖ

Toimitukset eri laajuisia: toimittajan ja operaattorin järjestelmien osuus vaihtelee

Toimitukset eri vaiheissa: määrittely, osatoimitus, lopputoimitus, ylläpito.

Tuotteet eri vaiheissa.

Opitaan ympäristöstä lisää; vaatimukset muuttuvat.

Simulaatio kokeilu aito ympäristö↔ ↔

VAIHTELEE

MONTA TUOTETTA

Prototyyppi

Kypsä tuote ==> arkkitehtuuri??

Tuoterunko

Suuri kannuste yhtenäistää.

MONTAKO ARKKITEHTUURIA?

Tekninen ympäristö

KOMPONENTTIEN UUDELLEENKÄYTTÖ

Ympäristö

J+K

J

J'

Bitwise

~200 kloc C#

VAATIMUSTEN KYPSYYS

Prototyyppi: vaatimukset ovat arvauksia, arkkitehtuuri on arvaus

Kypsä tuote: vaatimukset (melko hyvin) tiedossa, arkkitehtuuri (melko) vakaa

Tuoterunko: vaatimukset olemassaolevista ja ennakoiduista tuotteista

RAJOITTAA ARKKITEHTUURIN KYPSYYTTÄ

VAATIMUSTEN KYPSYYS

Prototyyppi:

arvaus (kehitys kokeilu oppiminen)+ OK→ → → →

Syklin nopeus tärkein ei-toiminnallinen vaatimus!

Ymmärrettävyys ja muunneltavuus erittäin tärkeitä.

Muilta osin arkkitehtuuriin panostaminen menee hukkaan.

Kypsä tuote:

Uudelleenkäytön mahdollistamiseksi olisi kiva olla lähellä muiden tuotteiden arkkitehtuuria.

MÄÄRÄÄ ARKKITEHTUURIN KYPSYYTTÄ

HYVIN TEHTY ARKKITEHTUURI

Ensin ominaisuuden kehityssykli. Kun OK ja ETV tiedossa, tehdään arkkitehtuuri kunnolla, kun päätökset perusteltavissa. Ei hätäillä arkkitehtuurin kanssa.

Arkkitehtuuri laahaa perässä, ei täysin yhtenäinen.

Ryhdin parantaminen perustellusti: roi, hidastavuus, yhtenäistys (J, J*, J+K, ...)...

Kevyet analyysit: takaraivossa todo-list, wtf/min, pelkokerroin, jne.

ON TEHTY HYVIEN TIETOJEN PERUSTEELLA(garbage in, garbage out)

HYVIN TEHTY ARKKITEHTUURI

Poikkeuksia: muutokset ytimeen, liikaa hidasteita

Viivästetään? Häkätään silti?

Ei lupa luopua arkkitehtuurisuunnittelusta.

Ei vähennetä arkkitehtuurin tärkeyttä – kasvatetaan sitä!

ON TEHTY HYVIEN TIETOJEN PERUSTEELLA(garbage in, garbage out)

ARKKITEHTUURI

Ei lupa luopua arkkitehtuurisuunnittelusta.

Ei vähennetä arkkitehtuurin tärkeyttä – kasvatetaan sitä!

Poikkeuksia: muutokset ytimeen, liikaa hidasteita

Viivästetään? Häkätään silti?

Poikkeuksia: keskeiset, esim. käynnistys, failover, toipuminen, tiedon pysyvyys, ...

HALLITUSSA KAAOKSESSA(how and why to fake it)

PELASTA YDIN

Tuoterunko ja yhtenäistys vs. (?) muokattavuus.

Suojele ydintä! Keskeinen sovellusalalogiikka.

Suojele pikkuytimiä!

”Kypsyyskerrokset”: muutoksille alttiit ulompana. Aika kypsyttää.

Abstrahointi, ryhmittely, sovittimet, sillat, samaistus, rajapinnat,

PELASTAT ARKKITEHTUURIN

Oikeahko esimerkki

J

J ja M neuvottelevat suoraan resurssin R käytöstä

M L

Olipa kerran väylä

HÄK HÄK HÄK

MJ

L

BUS

M-kanava

”Joku muukin voisi käyttää väylää”

Erotetaan väylän ja M:n käsittely

MJ

Lkanava

protokolla

M-proxy

BUS

Uudelleenkäytettävä

J, M ja N neuvottelevat...

HÄK HÄK HÄK

MJ

Lkanava

protokolla

M-proxy

BUS N

Uudelleenkäytettävä

”Voisi varmaan olla muitakin kuin J, M, N...”

Välittäjä hoitaa skeduloinnin.(mikä tahansa määrä neuvottelijoita; mille tahansa resurssille)

MJ

Lkanava

protokolla

M-proxy

BUS

välittäjä

N

Uudelleenkäytettävä

Loppuisipa jo!

Kysymyksiä?