Naked Objects -kirja on taas toiminut lähteenä, ja on hyvä pitää auki kohdasta "A development process". Allaoleva on pääosin lyhennelmää tuosta kappaleesta ja kappaleesta "Writing tests".
Naked Objects ei ole pelkästään hauska kirjasto java-ohjelmien tekemiseen, vaan sen kehittäjät ovat myös muotoilleet ohjelmiston kehittämiselle oman mallinsa. Tämä malli sisältää kolme vaihetta, jotka ovat:
Tämän vaiheen tarkoituksena on tutustua sovellusalueeseen, ja kokeilla erilaisia oliomalleja ohjelmalle. Tarkoituksena on todella kokeilla useampia kuin yhtä mallia, ja niiden tekemisessä Naked Objects auttaa.
Vaihe toistaa kolmea alivaihetta: olioiden ja niiden vastuiden määrittely, prototyypin toteuttaminen, ja (liike-)toimintaskenaarioiden kokeilu protolla. Aikatauluksi kirja suosittelee 4-5 iteraatiota parissa viikossa täydellä sitoutumisella, mutta pitää realistisena neljää viikkoa hyvällä sitoutumisella (asiakasta kaivataan mukaan myös).
Olioita ja niiden vastuualueita määritellessä tulee muistaa pitää ajatukset erossa käyttötapauksista. Kuten edellisistä demoista muistetaan, Naked Objectsin tekijät sanovat käyttötapauksista olioiden johtamisen olevan huono tapa; ensin oliot, sitten mahdollisesti käyttötapaukset. Olioiden löytämiseen kirja antaa monia hyviä neuvoja, kehoitan varsinkin lukemaan kohdan "Dealing with the concept of process".
Prototyypin olioiden toteuttamiseen annetaan kirjassa seuraava resepti:
title-metodi (identifioi olion käyttäjälle).Tämän jälkeen ohjelmaa voi jo kokeilla, ja katsoa miten se näyttäisi toimivan. Kokeilun jälkeen jatketaan seuraavasti:
about-metodit.Tämän jälkeen alkaa taas demoilu ja skenaarioiden testaus protolla.
Lopulta tuloksena pitäisi olla proto, joka miellyttää sekä asiakasta että kehittäjiä. Proto toimii jo tavallaan dokumentaationa kertoen mitä ohjelmalla tulisi tehdä, sekä millainen oliomallinnus ongelmaan olisi mahdollinen. Protosta kannatta muistaa, että se on vain proto. Protoa ei kehitetä sovellukseksi, vaan se heitetään aina menemään. Tämä on tärkeää muistaa! Protosta ei kehity ohjelmaa, vain ongelmia.
Tässä vaiheessa määritellään (liike-)toiminnalliset vaatimukset ja priorisoidaan ne. Julkaisuille arvioidaan ajat. Myös resurssit tulee arvioida, ainakin jollain tarkkuudella. Tulee myös suunnitella ohjelmiston integrointi käytössä olevaan infrastruktuuriin, eli katsoa miten ohjelmisto sopii alustaansa ja tarvitaanko alustaa mahdollisesti muuttaa. Tässä vaiheessa tulisi kirjoittaa, asiakkaan kanssa, myös XP:stä tuttuja käyttäjäkertomuksia, joiden avulla suunnittelu helpottuu. Niistä on myös apua seuraavan vaiheen hyväksyntätestien kirjoittamisessa.
Tässä vaiheessa ohjelmisto kehitetään, integroidaan, testataan ja julkaistaan edellä tehdyistä tutkimus- ja määrittelyvaiheista saatujen tietojen ja kokemusten avulla. Ensiksi kuitenkin tulee muistaa, että tutkimusvaiheessa tehtyjä kokeiluja ei kehitetä eteenpäin, vaan luodaan aivan uusi ohjelma. Tutkimusvaiheen koodi on kirjoitettu hätäisesti ja vailla tarkempaa virhetilanteita varten varautumista. Se on tarkoitettu vain ideoiden testaamiseen. Jos tuota tutkimusprototyyppiä kehitetään edelleen, johtaa se virheisiin tuotantokoodissa. Tutkimusprotosta otetetaan talteen oliomalli ja korkean tason vastuukuvaukset, joskus myös metodien esittelyt, muttei koskaan metodien runkoja. Metodien esittelytkin voisi jättää pois, mutta jos se rauhoittaa kehittäjiä, niin mikäpäs siinä.
Varsinainen koodaus aloitetaan kirjoittamalla ohjelmoijatestejä (JUnit!). Naked Objects -luokkakirjasto auttaa tässä. Naked Objects kehitysmalli kehoittaa myös kirjoittamaan hyväksymistestit ohjelmina, XP-hengessä. Tätä pidetään yleensä vaikeana, onhan kyseessä ohjelmisto, jolla on graafinen käyttöliittymä. Naked Objects -luokkakirjasto kuitenkin auttaa jälleen. Hyväksymistestit olisi hyvä kirjoittaa asiakkaan ohjelmoijan avustamana.
Kun testit on kirjoitettu, alkaa varsinainen koodaus. Naked Objects -kirja on tässä kohdassa hieman hämärä, tai luen sitä väärin, sillä siitä saa kuvan, että ohjelmoijatestit kirjoitettaisiin vasta tässä vaiheessa, hyväksyntätestien jälkeen. Noh, sopii meille.
Hyväksyntätestit ovat muutenkin suuressa suosiossa Naked Objects -ajattelussa. Naked Objectsin kehittäjät näet väittävät, että hyväksyntätesteistä voitaisiin jopa automaattisesti generoida käyttäjälle dokumentaatio ohjelman käytöstä. Tämä väite perustuu siihen ajatukseen, että hyväksyntätestit kuvaavat yhden tavan käyttää ohjelmaa tietyn toiminnon tekemiseen. Kannattaa huomata, ettei tuossa sanota ainoan tavan, vaan yhden tavan. Jälleen yksi kokeilemisen arvoinen juttu, tuo automaattinen dokumentointi.
Pelittää kuten JUnit, mutta Naked Objects lisää joitakin testausta helpottavia luokkia. Kuten Bill Gates parempina päivinään sanoi roskiksista ohjelmalistauksia (käyttöjärjestelmien!) kalastaessaan: "...study great programs that other people have written...".
public void testBookingForCustomer() {
Booking booking = new Booking();
Customer customer = new Customer();
booking.associateCustomer(customer);
assertEquals(customer, booking.getCustomer());
assertTrue(customer.getBookings().contains(booking));
assertTrue(booking.aboutActionCheckAvailability().canUse().isAllowed());
booking.actionCheckAvailability();
assertEquals("Available", booking.getStatus().title().toString());
}
Tai paremmin vastaten sitä, mitä kuvaruudulla tapahtuu:
public void testBookingForCustomer() {
View booking = getClassView("Bookings").newInstance();
View customer = getClassView("Customers").newInstance();
booking.drop("Customer", customer.drag());
booking.assertFieldContains("Customer", customer);
customer.assertFieldContains("Bookings", booking);
booking.rightClick("Check Availability");
booking.assertFieldContains("Status", "Available");
}
(Bill Gatesin lausahduksen sanotaan löytyvän kirjasta "OS/2 Notebook", vaan en ole voinut asiaa tarkistaa vielä.)