Suurempien ohjelmien ja API:en rakenteesta

Yksinkertainen pieni ohjelma saattaa koostua muutamasta luokasta, jotka käyttävät toistensa palveluja. Kun luokkia tulee enemmän, ohjelman monimutkaisuus kasvaa ja on vaikeampaa pitää kirjaa siitä kuinka ohjelma kokonaisuutena toimii. Kun luokat vielä riippuvat toisistaan, muutokset yhdessä paikassa saattavat vaikuttaa toiseen. Jotta vähänkin suurempia ohjelmia on mahdollista toteuttaa, täytyy kerrallaan käsiteltävän olevan tiedon määrää jollain tavoin hallita.

Termi abstraktio on tullut vastaan jo monesti aiemmin kurssimateriaalissa. Abstraktiolla tarkoitetaan yleisesti ottaen sitä, että jotakin ongelman tai ratkaisun osaa voidaan tarkastella sekä käyttää keskittyen vain sen olennaisiin piirteisiin ja jättäen sen tarkka sisäinen toteutus tietoisesti huomiotta. Abstraktioiden muodostamisesta käytetään termiä abstrahointi. Läheinen termi tälle on tiedon kätkeminen, jossa tarkoituksellisesti piilotamme näkyvistä yksityiskohtia.

Termi, modularisointi tarkoittaa prosessia, jossa jokin kokonaisuus (ohjelma, ohjelman osa, algoritmi, tms.) jaetaan selkeisiin osakokonaisuuksiin jotka voidaan toteuttaa itsenäisesti toisistaan. Näistä osakokonaisuuksista käytetään nimeä moduli. Kullakin modulilla on lisäksi jokin selkeä rajapinta, jonka kautta sen kanssa voi toimia, ja jonka kautta se toimii muiden modulien kanssa. Modulilla on myös yksityiskohtainen ohjelmakoodista koostuva toteutus.

Termillä kapselointi tarkoitetaan datan ja sen käsittelyyn tarkoitettujen funktioiden tai metodien kokoamista yhtenäiseksi kokonaisuudeksi.

Vaikka yllä olevat termit muistuttavat toisiaan, eivät ne tarkkaan ottaen tarkoita samaa. Esimerkiksi tiedon kätkeminen ja kapselointi vaikuttavat samankaltaisilta, mutta tiedon kätkeminen nähdään suunnitteluun liittyvänä periaatteena, kun taas kapselointi on ohjelmointikielen mekanismi.

Ohjelmointikielet tukevat abstraktioiden rakentamista, kapselointia ja modularisointia eri tavoin. Mm. Python tarjoaa useita työkaluja tiedon ryhmittelyyn, modularisointiin:

• Modulit: Pythonin keskeinen tapa organisoida ohjelmakoodia. Moduli on tiedosto, joka sisältää joukon funktio- ym. määrittelyjä. Python-modulien rajapinnan voi ajatella koostuvan näistä määrittelyistä.
• Import-lause: Etsii nimen perusteella modulin ja ottaa sen sisältämiä määrittelyjä käyttöön.
• Pakkaukset: Pythonissa moduleja voi organisoida hierarkisesti nimettyihin pakkauksiin. Pakkaukset ovat myös moduleita.
• Myös luokat ja metodit voivat kaikki sisältää luokkamäärittelyjä. Myös tätä rakennetta voidaan haluttaessa käyttää samalla tavoin luokkien ryhmittelyyn.

Suunnitelmasta toteutukseen

Mutta mistä tällaisen suuren ohjelman toteutus pitäisi aloittaa? Yksi suurimmista ongelmista ohjelmaa suunnitellessa ja toteuttaessa on, että ohjelmassa on suuri määrä toiminnallisuutta hajautettuna luokkiin, joiden välillä on joukko riippuvuuksia. Vähänkään isompaa ohjelmaa ei kuitenkaan voi toteuttaa kehittämällä sitä yhtenä kokonaisuutena, luottaen että kaikki osaset lopulta loksahtavat yhteen.

Katsotaan siis kahta keskenään vastakkaista suunnittelumenetelmää, Top-down ja Bottom-up lähestymistapoja ja kuinka tuotetuista suunnitelmista siirrytään toteutukseen.

Top-down suunnittelu

Top-down suunnittelussa työ aloitetaan koko järjestelmän tasolta ja pohditaan, mitä järjestelmä korkeimmalla abstraktiotasolla tekee. Tästä pyritään löytämään ja nimeämään seuraavan tason alijärjestelmät ilman, että päätetään mitään niiden toteuttamisesta. Alijärjestelmä on tässä vaiheessa jonkinlainen “musta laatikko”, joka tarjoaa kaikki tarvittavat palvelut, mutta sen toteutus on meille tuntematon.

Esimerkiksi Timelinerin toiminnallisuus voitaisiin jakaa kolmeen alijärjestelmään: käyttöliittymään, toimintalogiikkaan sekä ilmoitusjärjestelmään. Käyttöliittymän erottaminen toimintalogiikasta on aina hyvä idea.

Yllämainittu menetelmä toistetaan kunkin alijärjestelmän, mustan laatikon, tasolla. Alijärjestelmä kuvataan käyttäen apuna pienempiä osasia. Nämä voivat olla taas joitakin alijärjestelmiä, useamman vielä tuntemattoman luokan kokoelmia, mutta niiden vastuut ja riippuvuudet muista luokan osasista voidaan jälleen kerran asettaa vaikka näitäkään osia ei vielä ole. Vastaavasti kukin näin löydetty järjestelmä voidaan osittaa samalla tavalla jne.

Esimerkiksi Timelinerin toimintalogiikan voimme jakaa ihmisiin liittyvään toiminnallisuuteen, kalentereihin liittyvään toiminnalisuuteen ja töihin (tentit, projektit jne.) liittyvään toiminnallisuuteen.

Herää kysymys, missä vaiheessa tämä osittaminen loppuu? Voisimme ajatella etenevämme yksittäisen koodirivin tasolle, mutta tämä ei yleensä ole mielekästä. Yleensä jossain vaiheessa havaitsemme, että tarvittavaa alijärjestelmää varten on olemassa valmis toteutus joko käyttämällä jotain valmista kirjastoa tai uudelleenkäyttämällä itse tekemäämme koodia tai sitten törmätään luokkiin ja metodeihin, jotka meidän on toteutettava itse.

Suunnitellessa käytännössä määritellään järjestelmien ulkoiset rajapinnat ennen niiden toteutusta. Alijärjestelmän rajapintoja määritettäessä mietitään, miten samalla abstraktiotasolla olevat alijärjestelmät voivat käyttää toisiaan. Kun rajapinnat on määritetty kunnolla, voimme toteuttaa ja testata eri alijärjestelmiä/luokkia toisistaan riippumatta. Alijärjestelmän A ei tarvitse tietää alijärjestelmän B toteutusta; riittää että se tuntee B:n rajapinnan.

Top-down toteutus

Myös toteutusta voidaan tehdä Top-Down järjestyksessä. Mutta kuinka kirjoitetaan luokka joka käyttää mustia laatikoita, luokkia, joiden toteutusta ei vielä ole?

Top-down suunnittelun tuloksena meillä on luokkien rajapinnat ja käsitys mihin paketteihin ne kuuluvat, mutta ei juurikaan toteutuksia luokille (poislukien uudelleenkäyttämämme koodi, esim. kirjastoluokat). Jotta yksittäisen luokan toteutusta voidaan alkaa kirjoittaa, korvataan kaikki sen tarvitsemat muut luokat luokilla, joilla on haluttu rajapinta, mutta ei toiminnallisuutta.

Tyhjiä luokkia ja muitakin korvikkeita

Oikean toteutuksen tilalla käytetään eri syistä eri tyyppisiä “sijaisolioita”. Sijaisolion tehtävä voi olla koodin kääntämisen mahdollistaminen, mutta jo varsin aikaisessa vaiheessa on tärkeää, että koodin toiminnallisuutta pääsee testaamaan. Sijaisolion toteuttavaa luokka kutsutaan “sijaisluokaksi”. Testaukseen ja sen apuvälineisiin tutustutaan tarkemmin luvuissa 2.2 ja 2.3.

class Dummy:
     pass

dummy = Dummy()
d.x = 10
d.y = 20

class Dummy(object):
     def __init__(self, **kwds): self.__dict__ = kwds

x = Dummy2(pituus=10, leveys=20)

#
# Dummy-luokka, jonka kaikki metodit on määritelty ilman toteutusta.
# Metodeja voi kutsua ja kenttiä voi asetella ilman virheitä
#

class Dummy:

    def method1(self):
        pass

    def method2(self, n):
        pass

print("Create dummy")
d = Dummy()
print(d)
d.method1()
d.method2(20)
print("Bye")

class DataContainerStub:

    def store(self, key, value):
        assert key == "Antti"
        assert value == 10

    def retrieve(self, key):
        assert key == "Antti"
        return 10

class FakeDB:

    def __init__(self):
        self.contents = {}

    def store(self, key, value):
        self.contents[key] = value

    def retrieve(self, key):
        return self.contents[key]

Bottom-up suunnittelu

Bottom-up suunnittelustrategia etenee päinvastaiseen suuntaan kuin Top-Down, lähtien liikkeelle yksittäisistä osasista ja yhdistämällä niitä kerros kerrallaan suuremmiksi kokonaisuuksiksi. Yksittäisten luokkien ohjelmointi ja testaus voitaisiin periaattessa aloittaa heti. Osasten yhdistely myöhemmin voi kuitenkin hyvin hankalaa koska ne on suunniteltu itsenäisesti. Lisäksi lopputulos voi olla rakenteeltaan sekava, hankala muokata ja ylläpitää.

Bottom-up suunnittelu tukee koodin uudelleenkäyttöä, sillä vanhat osat otetaan sellaisinaan suunnittelun lähtökohdiksi ja saadaan mahdollisesti pienillä muokkauksilla tai sellaisenaan käyttöön. Tässä Bottom-up suunnittelu eroaa Top-down suunnittelusta, jossa syntyvät rajapinnat ja yksittäiselle komponentille tulevat vaatimukset eivät välttämättä sovi sellaisenaan vanhalle koodille.

Todellisuus

Todellisuudessa eri lähestymistapoja kannattaa yhdistellä parhaan lopputuloksen saavuttamiseksi.

Käytännössä toimiva ratkaisu suunnitteluun on yhdistää ja vuorotella Top-Down- ja Bottom-up -suunnittelua siten, että ohjelmistolle syntyy selkeä ja ylläpidettävä rakenne, mutta samalla myös alimman tason komponentteja voidaan käyttää uudelleen ja niiden rajapinnat ovat selkeitä ja käyttökelpoisia. Käytännössä suunnittelua täytyy iteroida joidenkin modulien kohdalla useitakin kertoja kunnes hyvä ratkaisu löytyy. Tätä voisi kutsua vaikkapa Meet-in-the- middle suunnitteluksi.

“When to use iterative development? You should use iterative development only on projects that you want to succeed.” –Martin Fowler, in “UML Distilled

Top-down suunnittelulla vältetään moduulien yhteensopivuusongelmia sekä turhia tai monimutkaisia riippuvuuksia ja saadaan kokonaiskuva projektista, ja Bottom-up lähestymistapa mahdollistaa mm. koodin uudelleenkäytön ja mahdollistaa yksittäisten luokkien suunnittelun ilman ylhäältä saneltua rakennetta.

Suunnitellun rakenteen laadusta

Syntyneen paketti- ja luokkarakenteen laatuun liittyvät keskeisesti termit koheesio (cohesion) ja kytkentä (coupling).

Yhteenvetoa

• Suunnittelussa ohjelma kannattaa jakaa jonkinlaisiin alijärjestelmiin ja tarpeettomia riippuvuuksia näiden välillä on mahdollisuuksien mukaan vältettävä
• Top-down suunnittelu toimii jakamalla ohjelman vastuita moduleille, jatkaen alaspäin kunnes päästään yksittäisiin luokkiin.
• Bottom-up menetelmä taas suunnittelee aihealueeseen sopivia luokkia ja lähtee yhdistelemään niistä alijärjestelmiä.
• Molemmilla lähestymistavoilla on heikkoutensa. Ei ole yhtä menetelmää, jolla päästään varmasti hyvään suunnittelutulokseen, käytännössä menetelmiä yhdistellään ja jonkin toisen järjestelmän tuottaman osasen voi vaikkapa uudelleensuunnitella toisella menetelmällä. Suunnittelun toistaminen on hyvä idea - ongelma-alueesta tulee usein opittua uutta.
• Ei ole yleispätevää tapaa selvittää, onko jokin ratkaisu ”hyvä” tai ”huono”. Samaan ongelmaan on erilaisia ratkaisuja ja vaikkapa kaksi kurssilaista tuskin tuottaisi samanlaisen ratkaisun vähänkään isompaan ongelmaan.
• Toteuttaessa ja testatessa ohjelmaa, luokkia korvataan sijaisluokilla. Eri tyyppiset sijaisluokat vastaavat eri tarpeisiin.

Palaute

Vastaa palautekyselyyn A+:ssa.