Uudelleenkäyttö

Yleistä On pyritty pääsemään vakiokomponenttien käyttöön Kuitenkin vakiokomponentit yleistyneet vain rajallisilla osa-alueilla (esim. windows-käyttöliittymä) On arvioitu, että 60-80% ohjelmistosta on tehty aiemmin, tästä merkittävä osa samassa organisaatiossa Onnistunut uudelleenkäyttö on yksi tehokkaimmista tavoista parantaa tuottavuutta.

Uudelleenkäytön jako kahteen Kehitinpohjainen uudelleenkäyttö –Sovelluskehittimet –Vain harvoille sovellusalueille Komponenttien uudelleenkäyttö –Koko sovellus (Uudet versiot) –Osajärjestelmä –Sovelluskehykset –Moduuli tai olio –Funktio –Suunnitelmat –Testidata

Komponenttien luokittelu Yleiskäyttöiset komponentit –Tietorakenteet, käyttöliittymäkomponentit Sovellualuekohtaiset –Esim. Televerkon hallinta Sovelluskohtaiset komponentit –Käytetään samassa sovelluksessa useaan kertaan. –Yleiset luokat

Edellytykset uudelleenkäytölle Sopivia komponentteja täytyy voida löytää järkevässä ajassa Komponenteista täytyy olla riittävästi informaatiota –Tarkoitus, toiminnan kuvaus yms. dokumentaatio –Havaitut ongelmat Täytyy pystyä omaksumaan edellisestä riittävä informaatio kohtuullisessa ajassa Täytyy pystyä luottamaan dokumentaation oikeellisuuteen

Uudelleenkäytön ongelmat 1/2 Uudelleenkäytettävien komponenttien tuottaminen vaatii lisäresursseja –Täytyy yleistää, luetteloida, testata ja dokumentoida Tarvittavaa komponenttia on usein vaikea löytää kohtuullisessa ajassa Dokumentoinnin puutteellisuus Asenneongelmat –Haluttomuus käyttää toiseten tekemiä komponentteja –Haluttomuus luottaa toisten työhön Komponentit liian yleiskäyttöisiä (tehokkuus, asenne)

Uudelleenkäytön ongelmat 2/2 Komponentit liian monimutkaisia –Käytettävyys, ymmärrettävyys –Opittavuus Tuotteenhallinnan ongelmat –Komponentti ei usein kelpaa sellaisenaan Merkittävän hyödyn saamiseksi uudelleenkäyttö pitäisi toteuttaa prosessin alkuvaiheessa

Uudelleenkäytön tukemisen keinot Uudelleenkäyttösuunnitelman laatiminen organisaatiossa Edellisen yhdistäminen henkilöstökoulutukseen Uudelleenkäyttöä tukevien välineiden hankkiminen Uudelleenkäyttöä tukevien menetelmien ja työkalujen tukeminen organisaatiossa Mittaustieto, metriikat – vaikutuksen mittaaminen Johdon sitoutuminen

Uudelleen käytettävän komponentin kehittäminen Suunnittelu usein hankalaa ja työlästä tehdä komponentista riittävän yleiskäyttöinen Olio-ohjelmointi (perintä) parantanut mahdollisuuksia uudelleenkäyttöön –Vähentää myös versio-ongelmia. Peritään luokka kokonaan, eikä muuteta alkuperäistä. Tyypillisesti luodaan yleiskäyttöinen ylemmän tason luokka ja peritään siitä oikeasti käytettävä luokka. –> Ylemmän tason luokka helposti uudelleenkäytettävissä –Esim. Windows-komponentit

Uudelleenkäytön etuja Suunnittelu- ja tuotantokustannusten vähentyminen (huom! ei mikään automaatio) Luotettavuuden parantuminen. Komponentit ovat jo ”oikeassakin käytössä” testattuja. Kokonaisriskin pienentyminen. Ei epävarmuutta aiheutuvista kustannuksista. Erikoistietämystä koteloidaan komponentteihin (esim. matemaattiset kirjastot) Sisäisiä standardeja voidaan toteuttaa komponentteina Kehitysaikaa voidaan lyhentää (vrt. kustannukset)

Tavallinen etenemistapa 1.Määritellään vaatimukset 2.Suunnitellaan järjestelmän arkkitehtuuri 3.Määritellään tarvittavat komponentit 4.Etsitään komponentteja omista kirjastoista ja markkinoilta 5.Mahdollisesti sovitetaan vaatimukset mahdollisuuksiin käyttää tietyn tyyppisiä komponentteja (Kuinka onnistuu?) 6.Muokataan komponentit ja liitetään ne ohjelmaan

Komponenttien siirrettävyys Lähdekoodin siirrettävyys –Mahdollisuus siirtyä käyttöjärjestelmästä toiseen rajallinen –Kuitenkin mahdollista Java,.NET, Delphi/Kylix Suoritettavan ohjelman siirrettävyys –Onnistuu käyttöjärjestelmästä toiseen välikieltä käyttämällä –Ei saa käyttää käyttöjärjestelmäriippuvaisia toimintoja

Kaksi lähestymistapaa komponenttien uudelleenkäyttöön 1.Muuntava uudelleenkäyttö –Peritään komponentti –Perittyä käyttäytymistä voidaan haluttaessa muuttaa 2.Kokoava uudelleenkäyttö –Valmiin komponentin käyttö sellaisenaan –Yhteyksien rakentaminen

Suunnittelumallit Suunnittelumalli on dokumentoitu tapa suunnitella ohjelmiston osa usein esiintyvän ongelman ratkaisemiseksi. Dokumentaatiossa seuraavat asiat: –Mallin tarkoitus –Mahdolliset sovelluskohteet –Rakenne (esim. luokkakaavio) –Edut ja haitat (miksi ratkaisu on jotain toista parempi) –Toteutukseen liittyviä seikkoja –Toteutusesimerkkejä

Sovelluskehykset Kiinteästi toisiinsa liittyviä luokkia, joista sopivasti täydentämällä ja kokoamalla saadaan valmis sovellus. Rakennetaan tietylle sovellusalueelle Voidaan kehittää sovelluskehitin toteutusta varten Esim. –Integraattori –Toiminnanohjausjärjestelmä –WWW-kauppa –Windows-sovelluskehittimet