Kuten esimerkki 8 osoittaa, kehittäjien on käsiteltävä riippuvuussuhteita, jotka syntyvät ongelman ja sen ratkaisun hajottamisesta useisiin moduuleihin. Sanomme, että järjestelmän moduuli on riippuvainen toisesta moduulista, jos on mahdollista, että yhden moduulin muutos vaatii muutoksen toiseen moduuliin. Jos esimerkiksi yritys muuttaa tuotantomenetelmiään, tämä voi aiheuttaa sen seurauksena muutoksen tapaan, jolla se laskee tuottamistaan tavaroista vaadittavat maksut.
Kehittäjän on huolehdittava kunkin riippuvuuden luonteen lisäksi myös riippuvuuksien määrästä. Ohjelmistotekniikassa ”kytkennällä” viitataan järjestelmän eri osien keskinäisen riippuvuuden asteeseen. On helppo havaita, että tietyissä järjestelmissä voi olla toisistaan riippuvaisten moduulien ketjuja, joissa esimerkiksi moduuli A riippuu moduulista B, joka taas riippuu moduulista C ja niin edelleen. Joissain tapauksissa nämä ketjut voivat liittyä yhteen ja luoda kehämäisen riippuvuuden, joka on vahvan (tai korkean) kytkennän erityinen muoto.
Kehittäjät pyrkivät rakentamaan löyhästi kytkettyjä järjestelmiä, koska ne ovat helpommin ymmärrettävissä ja ylläpidettävissä. Hyvässä ohjelmistojärjestelmässä on siis matala kytkentä, mikä tarkoittaa, että yhteen osaan tehtävät muutokset leviävät harvemmin koko muuhun järjestelmään. Vähäisen kytkennän etuna on myös se, että komponentit on helppo korvata ja mahdollisesti käyttää uudelleen.
Mitä tahansa kytkennän tasoa ohjelmistojärjestelmässä onkin, on tärkeää tietää, mitkä moduulit ovat kytkettyjä. Jos moduulien välisestä kytkennästä ei olisi tietoja, kehittäjän täytyisi käyttää aikaa moduulien läpikäymiseen selvittääkseen, vaikuttaako muutos kuhunkin moduuliin vai ei. Tuloksena olisi paljon tarkistamiseen käytettyä vaivaa, vaikka muutoksia ei tarvittaisikaan. Esimerkki 9 havainnollistaa vaaraa, joka aiheutuu siitä, että useampi kuin yksi moduuli käyttää yhteistä tai jaettua dataa.
Esimerkki 9
Datan käsittely on aina ollut ohjelmistokehittäjien ongelma. Tietyn ikäisissä sovelluksissa soveltuvin tallennusmuoto vuosiluvun esittämiseen oli luku väliltä 0-99. Se oli järkevää, koska vuosi 1966 tallennettiin numerona 66, vuosi 1989 numerona 89 ja niin edelleen, joten vain kahden numeron tallentamiseen tarvittiin vähemmän tilaa. Lisäksi jos päivämäärät tallennettiin numeroina, tehtävät, joihin liittyi lajittelu päivämäärän järjestyksen mukaan, olivat yksinkertaisia – 22. tammikuuta 1989 tallennettiin 890122:ksi, ja 22. joulukuuta 1966 jälkeinen päivä tallennettiin 661222:ksi.
Valitettavasti monet näistä sovelluksista olivat edelleen käytössä vuoden 2000 lähestyessä, joten jokaisen sovelluksen jokainen moduuli, joka käytti vuosiluvun lyhyttä muotoa, oli tutkittava.
Esimerkin 9 ongelmaan liittyi ennen kaikkea se, että eri kehittäjillä oli erilaiset tavat lukea ja käsitellä arvoja, jotka oli tallennettu muuttujiin, jotka käyttivät kuusinumeroista päivämäärämuotoa. Tämä lisäsi niin sanotun vuosituhannen vaihteen bugin ratkaisemiseen vaadittavaa vaivaa. Jos kehittäjillä olisi ollut johdonmukainen tapa manipuloida päivämääriä, joka ei olisi ollut riippuvainen tallennusmuodosta, vuosituhannen vaihteen vika ei olisi ollut huolenaihe.
Koheesio on tapa kuvata, kuinka tiiviisti yhden moduulin sisällä olevat toiminnot liittyvät toisiinsa. Koheesio on yleinen käsite – esimerkiksi organisaation osastolla voi olla yhtenäinen joukko vastuualueita (esimerkiksi kirjanpito) tai sitten ei (sekalaiset palvelut). Ohjelmistojärjestelmissä erittäin yhtenäinen moduuli suorittaa yhden tehtävän tai saavuttaa yhden tavoitteen – ”tee yksi asia ja tee se hyvin” on hyödyllinen motto. Moduulin tulisi toteuttaa yksi looginen tehtävä tai yksi looginen kokonaisuus.
Heikko kytkentä ja korkea koheesio ovat kilpailevia tavoitteita. Jos jokainen moduuli tekee vain yhden asian matalalla abstraktiotasolla, saatamme tarvita monimutkaisen rakennelman hyvin kytkettyjä moduuleja suorittamaan toimintaa korkeammilla abstraktiotasoilla. Kehittäjän olisi pyrittävä saavuttamaan paras mahdollinen tasapaino kytkentä- ja koheesiotasojen välillä ohjelmistojärjestelmässä. Esimerkiksi hotellit saavat tuloja vuokraamalla huoneitaan vieraille. Huoneen käsite on todennäköisesti edustettuna jossakin hotellivarauksia koskevassa ohjelmistojärjestelmässä. Voi olla kätevää käyttää huoneen käsitettä edustavaa moduulia tai luokkaa keräämään ja tallentamaan tietoa huoneiden vuokraamisesta saatavista tuloista. Parempi ratkaisu on kuitenkin erillinen lasku- tai maksumoduuli, koska se on yhtenäisempi, varsinkin kun hotelli tuottaa tuloja muilla tavoin, esimerkiksi tarjoilemalla aterioita henkilöille, jotka eivät ole hotellivieraita.
Tehtävä 5 Jaa ja hallitse
- a.Miksi kannattaa harkita suuren projektin jakamista pienempiin osiin?
- b.Miten ohjelmistojärjestelmän monimutkaisuus vaikuttaa ylläpitotehtävään?
- c.Mikä on moduuli?
- d.Miksi on hyödyllistä, että ohjelmistojärjestelmässä on vähäinen kytkentä?
- e.Anna esimerkkejä siitä, minkälainen tieto olisi arvokasta, kun harkitaan muutosta tiettyyn moduuliin.
- f.Mitä ovat moduulin kontekstiriippuvuudet? Miten ne liittyvät moduulin rajapintaan?
- g.Mitä etuja on siitä, että käytetään moduuleja, joilla on määritellyt rajapinnat?
- h.Miksi on hyödyllistä, että ohjelmistojärjestelmän moduuleissa on suuri yhteenkuuluvuus?
- i. Miksi moduulien yhteenkuuluvuus on tärkeää?Mitä ominaisuuksia moduulilla pitäisi olla, jotta sen kehittäminen ja ylläpito olisi helppoa ja halpaa ja jotta virheet jäisivät mahdollisimman vähäisiksi?
- j.Miksi on tärkeää saavuttaa tasapaino kytkennän ja yhteenkuuluvuuden välillä?
Vastaus
- a.On olemassa rajoitus sille, kuinka paljon yksi ihminen pystyy ymmärtämään kerrallaan. Niinpä on olemassa raja sille, kuinka suurta ohjelmistojärjestelmää yksi henkilö voi käsitellä. Jakamalla suuri projekti pienempiin osiin on mahdollista tunnistaa joukko helpommin hallittavissa olevia tehtäviä asianosaisille.
- b.On olennaista pystyä tekemään muutos ohjelmistojärjestelmään ilman, että tarvitsee tuntea kaikki kyseisestä järjestelmästä. Jokaisesta muutoksesta tulee vaikea, kun ohjelmien sisäinen ohjausvirta ja riippuvuudet ovat monimutkaisia. Mitä suurempi on riippuvuuksien määrä ja luonne, sitä vaikeampaa on ylläpitää ohjelmistojärjestelmää.
- c.Moduuli on mikä tahansa tunnistettava ohjelmistojärjestelmän osa, jota tarkastellaan erikseen. Moduulit voivat olla esimerkiksi aliohjelmia (proseduraalisessa kielessä vastaavat metodeja), luokkia (oliokeskeisessä kielessä), kirjastofunktioita tai muita itsenäisesti käsiteltäviä rakenteita.
- d.Kun kytkentä on vähäistä, moduulien välillä on vain vähän riippuvuuksia. Siksi ohjelmistojärjestelmän yhteen osaan (yhteen tai useampaan moduuliin) tehdyt muutokset leviävät harvemmin koko järjestelmään. (Moduulien välisten riippuvuuksien selkeä kirjaaminen auttaa ennakoimaan ohjelmistojärjestelmään ehdotetun muutoksen vaikutuksia.)
- e.On olemassa kahdenlaisia tietoja, jotka edistävät ehdotetun muutoksen analysointia:
- Mitkä moduulit ovat kyseisen moduulin asiakkaita? Tämä tieto osoittaa, kuinka laajalle muutos voi levitä ohjelmistojärjestelmässä.
- Mitä oletuksia kyseisen moduulin asiakasmoduuleissa on tehty? Ymmärrys moduulin oletetuista palveluista auttaa arvioimaan tiettyyn muutokseen liittyviä riskejä.
- f.Moduulin kontekstiriippuvuudet ovat muiden moduulien palveluita, joita moduuli tarvitsee toimiakseen oikein. Moduulin kontekstiriippuvuudet voidaan ilmaista muiden rajapintojen avulla. Voit siis ilmaista moduulin vastuualueet sen rajapinnan ja kontekstiriippuvuuksien avulla. Jos konteksti tarjoaa moduulin tarvitsemat palvelut ja asiakkaat täyttävät kaikki rajapinnassa määritellyt ehdot, moduuli voi taata rajapinnassaan kuvattujen palvelujen tarjoamisen.
- g.Hyödyt ovat seuraavat:
- Kehittäjien tarvitsee tietää vain moduulin rajapinnasta (sen syntaksista ja siitä, mitä se vaatii ja saavuttaa – sen semantiikasta), ei siitä, miten moduuli tarjoaa kyseiset palvelut. Näin ollen kehittäjät voivat olla tuottavampia.
- Kehittäjät voivat ymmärtää ohjelmistojärjestelmän osa-alueita perusteellisemmin, joten virheitä tulee vähemmän.
- Virheiden löytämisen pitäisi olla helpompaa, koska epäolennaisia moduuleja vältetään.
- Mahdollisuus moduulien uudelleenkäyttöön lisääntyy, kun tiedetään, mitä kyseinen moduuli tarjoaa ja vaatii.
- h. Kun koheesio on korkea, moduuli suorittaa järkevän joukon operaatioita tai aktiviteetteja. Ihannetapauksessa korkea koheesio merkitsee vain yhtä suurta abstraktiota moduulia kohti. Rajapinta abstrahoi pois sen, mitä kehittäjän on tiedettävä moduulin käyttämiseksi. Näin kehittäjien on helpompi ymmärtää moduulin tarkoitus ja sen käyttö. Lisäksi korkea koheesio tekee moduulista yleensä uudelleenkäytettävämmän muissa sovelluksissa, koska se tarjoaa joukon operaatioita, jotka sopivat luontevasti yhteen.
- i. Moduulin kytkeytymisen pitäisi olla vähäistä ja koheesion suurta, sen pitäisi edustaa hyvää abstraktiota ja sillä pitäisi olla hyvin määritelty rajapinta, joka on kapseloitu abstraktio hyvin ymmärretystä käsitteestä.
- j.Kun rakennat järjestelmää, voit valita joko pienemmän joukon löyhästi kytkettyjä, vähemmän yhtenäisiä moduuleja tai suuremman joukon tiukasti kytkettyjä, enemmän yhtenäisiä moduuleja. Edellisessä tapauksessa kutakin moduulia voi olla vaikea ymmärtää, kun taas jälkimmäisessä tapauksessa niiden väliset suhteet voivat olla liian monimutkaisia. On löydettävä sopiva tasapaino.