- mittaamisesta - toimintopistemetriikka - oliosunnittelun metriikat (QMOOD)

Transkriptio

1 Ohjelmistotekniikka - Luento 11 Jouni Lappalainen Luku 22: Ohjelmistotuotteen hallinta (SCM) - alkio, komponentti, versio, vaihetaso ja kuvauskanta - SCM prosessi - muutosten valvonta - julkistusten hallinta Luku 23: Tuotemetriikat - mittaamisesta - toimintopistemetriikka - oliosunnittelun metriikat (QMOOD)

2 Soveltuvat lait ja pohdiskelun aiheita Mutkikkuusmetriikat ennustavat hyvin julkaisun jälkeistä luotettavuutta ja ylläpidettävyyttä / hyp_15, McCabe 1976

3 Soveltuvat lait ja pohdiskelun aiheita Miksi vaihetasoja tarvitaan? Kerro omin sanoin. Tarkastele QMOOD mallin laatutekijöitä uudelleenkäytettävyys (reusability) ja ymmärrettävyys (understandability). Mistä suunnitteluominaisuuksista (design properties) niiden arvo lasketaan? Mitkä metriikat (niillä mitatut arvot) vaikuttivat eniten uudelleenkäytettävyyteen esim. MFC (Microsoft Foundation Classes) kehityksessä? Bansiya J., Davis C.G., A Hierarchical Model for Object-Oriented Design Quality Assessment, IEEE Transactions on Software Engineering, vol 28, no 1, 2002, pp. 4-17

4 22: Ohjelmistotuotteen hallinta Muutosten hallinta (change management) ja ohjelmistotuotteen hallinta (software configuration management) ovat sateenvarjoaktiviteetteja, joita tarvitaan koko ohjelmistokehitysprosessin ajan.

5 Muutokset ovat väistämättömiä muuttuneet vaatimukset aiheutuvat - muutoksista liiketoiminnassa - muutoksista käyttäjän tarpeissa - uudelleenorganisoinnista tai liiketoiminnan kasvusta/vähenemisestä - muutoksista budjetissa tai aikataulussa aiheuttavat muutoksia suunnittelutason kuvauksiin dataan testitapauksiin Projektisuunnitelmaan koodiin 5

6 Tuotekehitys- /asiakasnäkökulma Tuotekehitysprosessin kannalta keskeisin tavoite on antaa tuotekehitystiimille stabiili ja kontrolloitavissa oleva ympäristö => versionhallinta, pelisäännöt, työskentely-ympäristö, testiversioiden rakentaminen. Asiakasprosessin (toimitusten) kannalta keskeisin tavoite on asiakastoimitusten konfiguraatioiden hallinta: mitä tarkkaanottaen asiakkaalle toimitetaan / on toimitettu miten toimitettava kokonaisuus kootaan ja paketoidaan Haikala (luentomateriaali) 2005

7 Tuotteenhallinnan ongelmia Ongelma asiakkaalla X, tuote Y, versio a.b.c On pystyttävä rakentamaan versio a.b.c (konfiguraation versio, komponenttien versiot). Kun korjaus on suunniteltu ja tehty, syntyy muutettujen komponenttiversioiden uudet versiot ja tuotteen uusi versio. On vielä aikamoinen urakka selvittää Missä muissa korjattujen komponenttien versioissa esiintyy sama virhe. Johtaako virheen korjaus muutoksiin virheellistä komponenttia hyödyntäneissä komponenteissa. Haikala (luentomateriaali) 2005

8 Hallinta-alkio 0..* 0..* Komponentti Konfiguraatio 1 1 on versio Versio 0..* on versio 0..* Komponentin versio 0..* 0..* Konfiguraation versio Komponentti voi olla myös johdettu, esim. käännetty toisesta komponentista -> myös kääntäjä tuotteenhallinnan piiriin Versio on jäädytetty hallinta-alkio Haikala (luentomateriaali) 2005

9 Vaihetasot (baselines) IEEE Std. No määrittelee vaihetason: A specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures. Määrittely tai tuote, joka on katselmoitu ja hyväksytty ja siten toimii tulevan kehityksen perustana ja johon voidaan tehdä muutoksia ainoastaan formaalin muutostenhallintaprosessin kautta.

10 Komponentti A Komponentti B Komponentti C Komponentti D Vaihetasoja syntyy jokaisesta hallintaalkiosta (konfiguraatiosta ja komponentista) Vaihetasot (baseline) release = julkistus, julkaisu (asiakkaalle toimitettava) build = mikä tahansa suoritettava vaihetaso merkkaus (tagging) = julkaisuun liittyvien versioiden merkkaus versionhallintatyökalussa Haikala (luentomateriaali) 2005

11 Vaihetasot (baselines) /Pressman 2005 modified SCIs Project database Software engineering tasks SCIs Formal technical reviews approved SCIs stored SCIs SCM controls extracted SCIs BASELINES: System Specification Software Requirements Design Specification Source Code Test Plans/Procedures/Data Operational System 11

12 Mistä ohjelmistotuote/konfiguraatio koostuu? Data model Design specification data design architectural design module design interface design Component N Test specification interface description algorithm description PDL test plan test procedure test cases Source code Pressman

13 SCM kuvauskanta (tietovarasto) SCM kuvauskanta sisältää hallinta-alkioiden lisäksi tiedot komponenttien käyttäjistä, järjestelmän asiakkaista, käytettävistä alustoista (platform), esitetyistä muutoksista Sen avulla tulisi mahdollistaa kyselyt Mille asiakkaille tiettyä versiota on toimitettu? Mikä laitteisto ja käyttöjärjestelmä vaaditaan tietyn version suorittamisessa? Kuinka monta versiota tietystä järjestelmästä on olemassa ja milloin ne on luotu? Mihin versioihin tietyn komponentin muutos vaikuttaa? Kuinka monta muutospyyntöä on tehty tiettyyn versioon? Kuinka paljon vikoja on raportoitu tietystä versiosta?

14 Versiointi. Kuvauskannan ominaisuudet saves all of these versions to enable effective management of product releases and to permit developers to go back to previous versions Riippuvuuksien jäljitys ja muutosten hallinta. The repository manages a wide variety of relationships among the data elements stored in it. Jäljitys vaatimuksiin. Provides the ability to track all the design and construction components and deliverables that result from a specific requirement specification Konfiguraation hallinta. Keeps track of a series of configurations representing specific project milestones or production releases. Version management provides the needed versions, and link management keeps track of interdependencies. Jäljitysketju (audit trails). establishes additional information about when, why, and by whom changes are made. Pressman

15 Miten muutosten hallinta hoidetaan? Ohjelmistotuotteen hallinta (SCM, Software Configuration Management) aktiviteetit ovat Tunnista muutos Ohjaa muutoksen suoritusta Varmista, että muutos on toteutettu oikein Ilmoita muutoksesta muille siitä kiinnostuneille raportointi tuotteenhallinta muutoksenhallinta versionhallinta tunnistus Ohjelmisto V m.n hallintaalkiot (SCIs) Pressman

16 Perinteisesti (keskitetyssä) versionhallinnassa talletus tapahtuu muutoksen (delta) tallentamisella delta = muutos kahden hallinta-alkion version välillä forward delta periaate = talletetaan ensimmäinen versio kokonaan ja jatkossa vain tehdyt muutokset reverse delta periaate = talletetaan viimeisin versio ja peruutuksen tarvitsemat muutokset variaatio revisio Monihaarainen versiopuu - voi vaikeuttaa komponentin ylläpitoa Versionumerointi vaihtelee, mutta voi olla esim. 1-4 numeroinen ( ), jossa 1 taso on jos on tehty uudelleen suurimmalta osalta 2 taso kertoo jos on tehty toiminnallisia muutoksia 3 taso kertoo virheiden korjaamisesta (4 taso on tuotekehityksen välitallennuksia varten)

17 Versiot ja haaroittuminen Haara Runko Erikoistumishaarautuminen - tietyn asiakkaan tarpeisiin - ei yhdistetä runkoon Haara Liitos Haara Runko Kehityksen haarautuminen - kehittäjä(t) kehittävät jonkin aikaa osaa järjestelmästä - oma hiekkalaatikko - muiden tekemät muutokset ei näy - liitetään myöhemmin runkoon V 1 V 2 Runko Monia versioita: Erikoistumishaarautuminen - ongelmana esim. virheiden korjaus - voidaan joutua etsimään ja korjaamaan virhe useista versioista V 3 V 3a Shalloway et al. 2011

18 Versiot ja haaroittuminen Liitos 1 Liitos 3 A 1 A 2 B 1 B 2 Liitos 2 Liitos 4 Runko Työskentely eristyksissä: Kehityksen haarautuminen - haarautumisella kapseloidaan oma työ - ongelmana liitosten (yhdistämisien) kustannukset Liitoskustannus Kompleksisuus Liitoskustannus Liitosten kompleksisuus Liitosten välinen aika Liitosten välinen aika Shalloway et al. 2011

19 Versiot ja haaroittuminen Liitos 1 Runko uusi Jos toisen tiimin tekemiä muutoksia ei heti liitetä uuteen haaraan, joudutaan yhdistäminen tekemään myöhemmin. A 1 B1 Runko vanha Liitos 2 Liitos 1 Runko A 1 B1 Liitos uudestaan Liitos 2 Liitos uudestaan (merge-back) - liitetään runkoon tehdyt muutokset välittömästi myös uuteen haaraan Shalloway et al. 2011

20 Versiot ja haaroittuminen A B Liitos Verifioi liitos Liitos uudestaan Verifioi liitosuudestaan Kustannuksiin vaikuttavat tekijät Shalloway et al. 2011

21 kokonaiskustannukset Versiot ja haaroittuminen verifiointi Kustannukset liitos Liitosten välinen aika Kun käytetään perinteistä testausta kokonaiskustannukset Kustannukset verifiointi liitos Liitosten välinen aika Kun käytetään TDD (test-driven development) menetelmää Shalloway et al. 2011

22 Keskitetty versionhallinta Perinteiset versionhallintajärjestelmät ovat lähes yksinomaan keskitettyjä. ainoa kopio versiotietokannasta sijaitsee palvelimella kaikki kehittäjien tekemät muutokset versionhallintaan tehdään verkkoyhteyden yli yhteiseen jaettuun versiotietokantaan. Yleisimpiä käytössä olevia keskitettyjä versionhallintajärjestelmiä ovat Subversion, CVS ja ClearCase 22

23 Hajautettu versionhallinta Hajautetut versionhallintajärjestelmät eivät edellytä keskitettyä tietokantaa. Jokaisella kehittäjällä on oma, täydellinen kopio versiotietokannasta -> nopeuttaa kehitystä. Vaikka kopiotietokannat ovat teknisesti tasaarvoisia, käytännössä usein tiettyä, palvelimella ylläpidettävää kopiota kohdellaan "virallisena kaikki kehittäjät lopulta integroivat muutoksensa siihen projektin julkaisut tehdään siitä Yleisimmät hajautetut versionhallintajärjestelmät ovat Git ja Mercurial. 23

24 Git hajautettu versionhallinta Git tukee haaroittumista, oma hiekkalaatikko jokaiselle kehittäjälle. kehittäjä voi käyttää lyhytaikaisia haaroja kokeiluun Git ylläpitää muutoskokonaisuuksien sisällöstä ja "sukupuusta" kirjaa kahden kehittäjän erikseen tekemät samanlaiset muutokset pystytään todentamaan identtisiksi säästytään monilta konflikteilta siinä vaiheessa kun kehittäjät synkronoivat omaa versiohistoriaansa projektin keskitettyyn versiotietokantaan. 24

25 Esimerkki haarautumisesta Hyväksytty virheen korjaus Julkaisu QA:lle Julkaisu tuotantoon Julkaisu 1.1 Kehitys Laadunvarmistus Tuotanto Korjauksen tekeminen myös julkaisuun 1.2 Julkaisu QA:lle Julkaisu tuotantoon Julkaisu 1.2 Kehitys Laadunvarmistus Tuotanto Korjauksen tekeminen myös julkaisuun 1.3 Julkaisu QA:lle Julkaisu tuotantoon Julkaisu 1.3 Kehitys Laadunvarmistus Tuotanto Julkaisu QA:lle Julkaisu tuotantoon Julkaisu 1.4 Kehitys Laadunvarmistus Tuotanto Julkaisun mukainen haarautuminen (branch-by-release) Walrad & Strom, 2002

26 Hyväksytty virheen korjaus Julkaisu QA:lle Julkaisu tuotantoon Julkaisu 1.1 Kehitys Laadunvarmistus Tuotanto Muutos täytyy liittää (check-in) siihen julkaisuun, josta koodi on otettu (check-out) korjattavaksi Julkaisu 1.2 Kehitys Build-by-bug-number ongelma Walrad & Strom, 2002

27 Silta Hyväksytty virheen korjaus Lopullinen julkaisu QA:lle (koodin jäädytys) Liitä hyväksytyt ja testatut korjaukset kehityslinjaan Ominaisuuden jäädytys Hyväksytty virheen korjaus Kehityslinja Normaali kehitys Koodin jäähdytys: vain testaus ja hyväksytyt muutokset Normaali kehitys Hyväksytty lopullinen virheen korjaus Hyväksytty hätätilanteen virheen korjaus Hyväksytty julkaisu tuotantoon Julkaisuehdokas Alfa 1 testaus Alfa n testaus Beta 1 testaus Beta n testaus Testaus Testaus Tuotantoehdokas 1.0 Tuotantojulkaisu Tuotanto 1.0 Tuotanto 1.1 Tarkoituksen mukainen haarautuminen (branch-by-purpose) Walrad & Strom, 2002

28 Lopullinen julkaisu QA:lle (koodin jäädytys) Ominaisuuden jäädytys Kehityslinja Koodin jäähdytys: vain testaus ja hyväksytyt muutokset QA Alfa 1 testaus Beta n testaus Tuotantoehdokas 1.1 Testaus Tuotanto Tuotanto 1.1 Kun käytetään yhtä kehityslinjaa, vältetään build-by-bug-number ongelma Walrad & Strom, 2002

29 Versionhallinta jatkuvan integroinnin (continuous integration) tukena Kaikki kehittäjät suorittavat itsenäisesti integroinnin omilla työasemillaan ennen ohjelmakoodimuutosten siirtämistä versionhallintaan, jotta he varmistuvat siitä etteivät heidän tekemänsä muutokset riko integrointia. Kehittäjät siirtävät muutoksensa versionhallintaan vähintään kerran päivässä. Integrointi tapahtuu erillisellä palvelimella useita kertoja päivässä. Kaikkien automaattisten testien on mentävä läpi jokaisessa onnistuneessa integroinnissa. Integroinnin tuloksena syntyy tuote, jonka toiminnallisuutta voidaan testata manuaalisesti. Epäonnistuneen integroinnin korjaaminen (fixing broken build) on aina korkeimman prioriteetin tehtävä. Jotkut kehittäjät seuraavat jatkuvan integroinnin generoimia raportteja etsiäkseen parantamisen kohteita. Tällaisia seurattavia asioita ovat esimerkiksi ohjelmointistandardit ja riippuvuusanalyysit.

30 1. Kehittäjä siirtää muutoksensa versionhallintaan. Integrointipalvelin (CI Server) monitoroi muutoksia versionhallinnassa esimerkiksi muutaman minuutin välein 2. Integrointipalvelin generoi palautteen integroinnista (esim. sähköposti) 3. Integrointipalvelin havaitsee muutokset, noutaa viimeisimmän lähdekoodin versionhallinnasta, ja suorittaa integrointiskriptin (Build Script) joka integroi ohjelmiston 4. Integrointipalvelin jatkaa versionhallinnassa tapahtuvien muutosten monitorointia Duvall et al. Continuous integration, 2007

31 Mitä keinoja jatkuva integrointi tarjoaa? Ei ole jaettavaa koodia! - ongelmia testikonfiguraatioissa! - ongelmia tiimien yhteistyössä! - ongelmia integrointibuildeissa! Virheet paljastuvat liian myöhään! - riittämätön regressiotestaus! - alhainen testikattavuus! Projektin tilan näkyvyys heikko! - tilainformaatiota ei jaeta reaaliajassa! - puuttuvat kuvaukset! Huonolaatuinen ohjelmisto! - ei noudateta koodausstandardeja! - käytetään huonoa arkkitehtuuria! - liikaa duplikoitua koodia! Jatkuva tietokantaintegraatio! - materiaali versionhallintajärjestelmässä! - kehittäjillä oma kopio! - kehittäjillä riittävät tietokantaoikeudet! Jatkuva testaus! - lisää automatisoituja testejä! - testiympäristö tuotantoympäristön kaltainen! Jatkuva tarkastus! - vähennetään koodin kompleksisuutta ja duplikointia! - noudatetaan standardeja! - arvoidaan kattavuutta! Jatkuva jakelu! - julkistuksia jatkuvasti! - buildien tehokas käyttö! erittäin tärkeä! tärkeä! tärkeä! tärkeä! tärkeä! tärkeä! erittäin tärkeä! Jatkuva palaute! - oikeaa tietoa oikeille ihmisille oikeaan aikaan oikealla tavalla! tärkeä! Mitä riskejä ohjelmistokehityksessä? Duvall et al. Continuous integration, 2007

32 22 (loppuosa). Muutosten valvonta STOP 32

33 Muutosten valvontaprosessi Pyydetään muutosta täyttämällä Muutospyyntölomake Analysoidaan pyyntö Jos pyyntö on aiheellinen, niin muuten arvioidaan, miten muutos toteutetaan arvioidaan muutoskustannukset tallennetaan pyyntö tietokantaan toimitetaan pyyntö muutosten hallintaryhmälle jos muutos on hyväksytty, niin toistetaan tee muutokset ohjelmistoon tallenna muutokset ja linkitä muutospyyntöön toimita muutettu ohjelmisto laadunvalvontaan kunnes ohjelmiston laatu on hyväksytyllä tasolla luo uusi versio järjestelmästä muuten peru muutospyyntö peru muutospyyntö Lomake määritellään versionhallinnan suunnittelussa Massatuotteiden tapauksessa muutospyynnöt perustuvat asiakkailta tulleisiin virheraportteihin Arvioidaan, mihin muihin moduuleihin muutos vaikuttaa CCB (Change control board) kokoonpano vaihtelee projektin koon mukaan Sommerville 2004

34 Muutospyyntölomake Projekti: Proteus/PCL-tools Numero: 23/02 Muutoksen pyytäjä: I. Sommerville Päivä: 1/12/02 Pyydetty muutos: Kun komponentti on valittu rakenteesta, näytetään tiedoston nimi, mihin se on talletettu Muutoksen analysoija: G. Dean Analyysi tehty: 10/12/02 Tarkasteltavat komponentit: Display-Icon.Select, Display-Icon.Display Liittyvät komponenetit: FileTable Muutoksen arviointi: Toteutus on kohtuullisen helppo, kun tiedoston nimitaulu on saatavilla. Vaatii näyttökentän suunnittelun ja toteutuksen. Liittyviin komponentteihin ei tule muutoksia. Muutoksen prioriteetti: alhainen Muutoksen toteutus: Arvioitu työpanos: 0.5 päivää Toimitettu hallintaryhmälle: 15/12/02 Hallintaryhmän päätös tehty: 1/2/03 Hallintaryhmän päätös: Hyväksy muutos. Muutos voidaan toteuttaa julkaisussa 2.1 Toimitettu laaturyhmälle: Laaturyhmän päätös: Toimitettu versionhallintaan: Sommerville 2004

35 Julkistusten hallinta Järjestelmän julkistus on asiakkaalle toimitettu versio. Julkistus on muutakin kuin koodia, esim. konfigurointitiedostot miten julkistus kootaan tiettyyn toimitukseen datatiedostot tarvitaan järjestelmän onnistuneeseen toimintaan asentamisohjelma ohjeet ja skriptit, kuinka järjestelmä asennetaan tietylle laitteistolle järjestelmän dokumentaatio Sommerville 2004

36 Julkistusten hallinta... Järjestelmän julkistuksen ajankohta on tärkeä liian tiheästi tehdyt julkistukset nähdään painolastina ei riittävästi uusia piirteitä ei haluta päivitystä, varsinkin jos se maksaa liian harvoin tehdyt julkistukset voi aiheuttaa asiakkaan menetyksen kilpailijan tuote uusine piirteineen tuntuu paremmalta Sommerville 2004

37 Julkistusstrategia - mikä aiheuttaa uuden julkistuksen? Tekninen laatu Alustan muutokset Lehmanin viides laki Kilpailu Markkinat Asiakkaan vaatima muutos Jos on raportoitu vakavista vioista (monilta asiakkailta), tarvitaan korjausjulkistus. Esim. käyttöjärjestelmän päivitys Uusien ominaisuuksien määrä uudessa julkistuksessa on keskimäärin vakio. Kilpailijan tulo markkinoille vaatii uuden julkistuksen. Markinointiosasto on luvannut uuden julkistuksen tiettyyn aikaan. Räätälöidyissä järjestelmissä asiakkaat ovat halunneet ja maksaneet muutoksista.

38 Miten ohjelmistot kehittyvät? Bash is the popular Unix shell. BIND is the leading DNS server on the Internet. Bison is the GNU parser generator. OpenSSH is the standard open-source suite of the widely used secure shell protocols. Quagga is a tool suite for building software routers that support the RIP, OSPF, and BGP protocols on top of IPv4. Samba is a tool suite that facilitates Windows-UNIX interoperability. Sendmail is the leading transfer agent today. SQLite is a popular library implementation of a self-contained SQL database engine. Vsftpd stands for Very Secure FTP Daemon and is the FTP server in major Linux distributions. Neamtiu I., Xie G., Chen J., Journal on Software Maintenance and Evolution,

39 Muutosten tilan seuranta Software Configuration Item voi olla dokumentti, testitapausten kooste tai yksittäinen ohjelmakomponentti SCIs! Change Requests Change Request Form Change Reports ECOs Engineering Change Order Muutos on hyväksytty, odottaa toimenpiteitä Status Accounting Reporting 39

40 Mittaamisen tavoitteena on saada Oikea tieto Oikeassa muodossa Oikeaan aikaan Oikeille ihmisille 23. Tuotemetriikat Mittaaminen (measurement) pyritään saamaan aikaan matemaattinen malli, joka kuvaisi johdonmukaisella asteikolla mitattavien kohteiden mitattavan ominaisuuden suuruuden Metriikka (metric, joskus myös measure) measurement function a software quality metric a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which software possesses a given attribute that affects its quality run bb wb insp faults/hr

41 Miksi mitataan? Lisätään ymmärrystä mitattavasta kohteesta tuotteen valmiudesta, kompleksisuudesta, laadusta, virheettömyydestä mittaustulosten avulla tuotteita pystytään analysoimaan paremmin, ja niistä saadaan vertailukelpoista tietoa Päätöksenteon työkalu Motivoinnin työkalu

42 Toimintopohjaiset metriikat Toimintopistemetriikkaa (function point metric, FP), voidaan käyttää toimitettavan järjestelmän toiminnallisuuden, mutkikkuuden ja koon mittaamiseen. Albrecht 1979 Toimintopisteet saadaan järjestelmän ja ympäröivän maailman kommunikointia kuvaavista tiedoista. Toimintopisteiden laskentaan käytettävät tiedot ovat: ulkoisten syötteiden määrä (number of external inputs (EIs)) ulkoisten tulosteiden määrä (number of external outputs (EOs)) ulkoisten kyselyjen määrä (number of external inquiries (EQs)) sisäisten tietovastojen määrä (number of internal logical files (ILFs)) ulkoisten rajapintojen määrä (number of external interface files (EIFs))»

43 Toimintopisteet Information Weighting factor Domain Value Count simple average complex External Inputs (EIs) External Outputs (EOs) External Inquiries (EQs) Internal Logical Files (ILFs) External Interface Files (EIFs) x3 x3 3x 3x 3x = = = = = Count total 43

44 Test sensor" Sensors! User! Password" Zone inquiry" Sensor inquiry" Panic button" Activate/deactivate" SafeHome! User! Interaction! Function! Password, sensors " Alarm alert" Zone setting" Messages " Sensor status" User! Activate/deactivate" Monitoring! & response! subsystem! EIs = password, panic button, " activate/deactivate " EOs= messages, sensor status" EQs = zone inquiry, sensor inquiry" ILFs = SCD" EIFs = test sensor, zone setting, " activate/deactivate, alarm alert" System configuration data! FP = count total * [ * sum (F i )]!! FP = 50 * [ (0.01 * 46)] = 56!! 1 FP e.g. 60 LOC,! 1 person month effort e.g. 12 FP! Information Weighting factor Domain Value Count simple average complex External Inputs (EIs) External Outputs (EOs) External Inquiries (EQs) Internal Logical Files (ILFs) External Interface Files (EIFs) Count total 3! 2! 2! 1! 4! X 3 X 3 3X 3X 3X = = = = = 9! 8! 6! 7! 20! 50!

45 Metrics for Object-oriented design Chidamber and Kemerer 1994:" Weighted methods per class, WMC Number of methods and their complexity; WMC should be kept as low as is reasonable Depth of the inheritance tree, DIT The maximum length from the node to the root of the tree. As DIT grows, it leads to potential difficulties to predict the behavior of the class. Number of children, NOC When NOC increases, the abstraction presented by the parent class can be diluted (some of the children are not appropriate members of the parent class.) Coupling between object classes, CBO As CDO increases, reusability of the class may decrease. Response for a class, RFC A set of methods that can potentially be executed in response to a message received by an object of that class. As RFC increases, the effort required for testing also increases. Lack of cohesion in methods, LCOM Is the number of methods that access one or more of the same attributes. If no methods access the same attributes, then LCOM is 0.

46 QMOOD quality metrics and attributes QMOOD = Quality Model for Object Oriented Design Bansiya & Davis: A Hierarchical Model for Object-Oriented Design Quality Assessment, IEEE TSE, January, 2002 developed for C++ programs First Level Second Level Third Level Fourth Level Design Quality Attributes Object- Oriented Design Properties Object- Oriented Design Metrics Object- Oriented Design Components Reusability Flexibility Understandability Coupling Cohesion Composition Encapsulation Design size Direct class coupling Cohesion among methods in class Measure of aggregation Data access metric Design size in classes

47 Bansiya & Davis 2002

48 Bansiya & Davis 2002

49 Bansiya & Davis 2002

50 Metrics are mainly based on metric suite of Chidamber & Kemerer (1994). Some metrics are new, because C&K metrics require a nearly complete implementation of classes. The new metrics are DAM DCC CAM MOA MFA Bansiya & Davis 2002

51 MFC = Microsoft Foundation Classes OWL = Object Windows Library Bansiya & Davis 2002

52 MFC = Microsoft Foundation Classes OWL = Object Windows Library Bansiya & Davis 2002

53 Bansiya & Davis 2002

54 Luokkien väliset riippuvuussuhteet Code Element Ca Ce Epävakaus = Instability Alkion x epävakaus voidaan laskea kahden tekijän avulla Efferent Couplings (Ce) niiden alkioiden lukumäärä, joita x käyttää Afferent Couplings (Ca) niiden alkioiden lukumäärä, jotka käyttävät x:ää Instability (x) = Ce / (Ce + Ca)» NDepend työkalulla voidaan tutkia koodin riippuvuuksia» SELECT TOP 10 METHODS ORDER BY MethodCa DESC» mitä ohjelman metodeja käytetään eniten» jos Ca = 0, voi olla merkki kuolleesta koodista, jonka voi poistaa»

55 Soveltuvat lait ja pohdiskelun aiheita Mutkikkuusmetriikat ennustavat hyvin julkaisun jälkeistä luotettavuutta ja ylläpidettävyyttä / hyp_15, McCabe 1976 syklomaattinen kompleksisuus, Halsteadin mittari ja LOC korreloivat löydettyjen virheiden määrään ei voida todista, että ennen julkistusta löydetyt virheet ennustaisivat julkistuksen jälkeisten virheiden määrää

56 Soveltuvat lait ja pohdiskelun aiheita Miksi vaihetasoja tarvitaan? Kerro omin sanoin. Tarkastele QMOOD mallin laatutekijöitä uudelleenkäytettävyys (reusability) ja ymmärrettävyys (understandability). Mistä suunnitteluominaisuuksista (design properties) niiden arvo lasketaan? Mitkä metriikat (niillä mitatut arvot) vaikuttivat eniten uudelleenkäytettävyyteen esim. MFC (Microsoft Foundation Classes) kehityksessä? Bansiya J., Davis C.G., A Hierarchical Model for Object-Oriented Design Quality Assessment, IEEE Transactions on Software Engineering, vol 28, no 1, 2002, pp. 4-17