Ohjelmistotekniikka: Luento 5

Ohjelmistotekniikka: Luento 5 Luku 6: Vaatimusten mallintaminen: skenaariot, analyysiluokat UML kertausta Luku 7: Vaatimusten mallintaminen: vuo, käyttäytyminen ja mallit (patterns) Vuopohjainen mallintaminen (DFD malli) Vaatimusten keräys Web-sovelluksessa 1

Soveltuvat lait ja pohdiskelun aiheita Käytetyn mallin arvo riippuu valitusta näkökulmasta, mikään ei ole paras kaikkiin tarkoituksiin / no 4, Davis 1990 Oliomalli vähentää kommunikoinnin ongelmia analysoijien ja käyttäjien välillä / hyp_no 1, Booch 1991 2

Vaatimusmallin (analyysimallin) tarkoitus kuvata asiakkaan vaatimukset luoda pohja ohjelmistosuunnittelulle määritellä joukko vaatimuksia, joita tullaan käyttämään rakennetun ohjelmiston validoinnissa Peukalosääntöjä (Arlow & Neustadt 2002) pysy riittävän abstraktilla tasolla jokaisen mallin elementin tulee lisätä ymmärrystä jätä infrastruktuurista huolehtiminen suunnitteluvaiheeseen minimoi kytkennät järjestelmän osien välillä sidosryhmillä on useita käyttötarkoituksia mallille pidä malli niin yksinkertaisena kuin mahdollista 3

Sovellusalueanalyysi tai toimiala-analyysi (domain analysis) Mitä yhteistä sovellusalueella on? Sovellusaluetietämyksen lähteet Tekninen kirjallisuus Olemassaolevat sovellukset Asiakastutkimukset Asiantuntijoiden neuvot Nykyiset/tulevat vaatimukset Sovellusalueanalyysi Luokkataksonomiat Uudelleenkäytön standardit Toiminnalliset mallit Sov. alueen kielet Sovellusalueanalyysimalli Kuinka löydetään uudelleenkäyttöä varten mahdollisimman laajasti sovellettavat analyysiluokat ja/tai yhteiset funktiot ja ominaispiirteet? 4

Suunnittelumenetelmien kehittyminen Suunnittelumenetelmät ovat aikansa lapsia (kaikissa eri abstraktiotason kuvauksia) 1980 luvulla JSD (Jackson System Development), Jackson 1983 MSA (Modern Structured Analysis), Yourdon 1989 1990 luvulla oliomenetelmät ja kuvaustavat, kuten OOA & OOD, Coad & Yourdon 1991 OMT, Rumbaugh et al. 1991 UML kuvaustavan määrittely, Rumbaugh et al. 1999 UML & RUP prosessi, Jacobson et al. 1998 OMT++, Jaaksi et al. 1999 2000 luvulla UML & RUP valtakausi jatkuu (UML 2.0 2005, UML 2.3 2010) 5

Analyysimallin osat Käyttäjät Prosessi Skenaariopohjaiset mallit Vuomallit Käyttötapaukset Käyttötapauskaaviot Aktiviteettikaaviot Uimaratakaaviot Tietovuokaaviot Ohjausvuokaaviot Käsittelykertomukset Ohjelmisto- vaatimukset Luokkamallit Käyttäytymismallit Rakenne Luokkakaaviot Analyysipakkaukset CRC mallit Yhteistyökaaviot Tilakaaviot Sekvenssikaaviot Oliojoukon vuorovaikutus 6

Kaavio Rakennekaavio Käyttäytymiskaavio Luokkakaavio Pakkauskaavio Tilakaavio Aktiviteettikaavio Oliokaavio Sijoittelukaavio Käyttötapauskaavio Komponenttikaavio Koostekaavio Ajoituskaavio Vuorovaikutuskaavio Kokoava vuorovaikutuskaavio Sekvenssikaavio Kommunikaatiokaavio (yhteistyökaavio) 7

UML kertausta Käydään läpi UML kaaviot Millerin tutoriaalin pohjalta Practical UML: A Hands-On Introduction for Developers http://edn.embarcadero.com/article/31863 Ei ihan ajan tasalla, joten http://www.omg.org/spec/uml/ UML:stä on paljon hyviä kirjoja, joita löytyy myös kirjastosta 8

SafeHome valvontafunktio Käyttötapaus (sanallinen kuvaus): Valitse kamera ja näytä kuvaa Jos olen poissa kotoa, voin katsoa PC:n ja selaimen avulla SafeHome järjestelmän kameroiden kuvia. Aluksi täytyy kirjautua SafeHome palvelimelle. Sen jälkeen kaikki SafeHome järjestelmän palvelut ovat käytettävissä. Tietyn kameran kuvan saa valitsemalla ensin valvonta toiminnon ohjauspaneelin näppäimistä, sitten edelleen valitse kamera toiminto. Näytöllä esitetyn pohjapiirroksen avulla voin valita nähtäväksi joko pieniä (thumbnail) otoksia kaikista kameroista tai valitun kameran kuvaa. Jos haluan vaihtaa kameraa, saan valitse kamera toiminnolla pohjapiirroksen näkyville ja sen avulla voin vaihtaa kameraa. 9

SafeHome valvontafunktio Käyttötapaus (skenaario): Valitse kamera ja näytä kuvaa 1. Talon omistaja ottaa yhteyden SafeHome kotisivulle 2. Talon omistaja antaa käyttäjätunnuksen 3. Talon omistaja antaa salasanan 4. Järjestelmä näyttää kaikki toimintonäppäimet 5. Talon omistaja valitsee valvonnan toiminnon 6. Talon omistaja valitsee valitse kamera toiminnon 7. Järjestelmä näyttää pohjapiirroksen ja kameroiden paikat 8. Talon omistaja valitsee kameran pohjapiirroksesta 9. Talon omistaja valitsee näytä toiminnon 10. Järjestelmä näyttää ikkunan, jossa on valitun kameran numero 11. Järjestelmä näyttää ikkunassa kuvaa valitusta kamerasta 10

Käyttötapaus (laaja esitys): Valitse kamera ja näytä kuvaa Ensisijainen toimija: Talon omistaja Tavoite: Saada halutun kameran kuva näkyville Internetin kautta Esiehdot: SafeHome kotisivut on toiminnassa ja käyttäjä on aiemmin rekisteröitynyt Herätin/liipasin: Talon omistaja haluaa katsoa kameran kuvaa Skenaario:11 askelta esitelty edellisellä sivulla Poikkeukset: Käyttäjätunnus tai salasana on väärä - katso käyttötapaus: Varmista käyttäjätunnus ja salasana Valvontatoimintoa ei ole räätälöity talon omistajan talolle - katso käyttötapaus: Konfiguroi valvontatoiminto Talon omistaja valitsee Näytä pikkukuvaa (thumbnail) kuvaa kaikista kameroista katso käyttötapaus: Näytä pikkukuvaa kuvaa kaikista kameroista Prioriteetti: kohtuullisen tärkeä, toteutetaan perustoimintojen jälkeen Milloin valmis: kolmannessa vaiheessa Käyttötiheys: kohtuullisen usein Avoimet kysymykset: Onko järjestelmän turvallisuus riittävä? Onko verkon nopeus riittävä kuvan välittämiseen? 11

Flow-of-events esitystapa http://agile.csc.ncsu.edu/sematerials/ UseCaseRequirements.pdf UC4 Opiskelijatietojen ylläpito 4.1 Esiehdot: Opintosihteerillä on pääsy järjestelmään 4.2 Päälinja: Opintosihteeri valitsee opiskelijan järjestelmästä joko opiskelijanumeron tai nimen avulla [E1]. Opintosihteeri päivittää kurssin suoritustiedot [UC5]. 4.3 Tarkennetut kulut: ei ole 4.4 Vaihtoehtoiset kulut [E1] Opiskelijaa ei löydy, ilmoitetaan opintosihteerille. 12

(Flow of Events esitystapa): UC 1: Valitse kamera ja näytä kuvaa 1.1 Esiehdot: SafeHome kotisivut on toiminnassa ja käyttäjä on aiemmin rekisteröitynyt 1.2 Päälinja (main flow): Talon omistaja ottaa yhteyden SafeHome kotisivulle. Talon omistaja antaa käyttäjätunnuksen ja salasanan [E1]. Järjestelmä (ohjauspaneeli) näyttää kaikki toimintonäppäimet ja talon omistaja valitsee valvonta toiminnon [E2]. Tämän jälkeen talon omistaja valitsee valitse kamera toiminnon ja järjestelmä näyttää pohjapiirroksen ja kameroiden paikat. Talon omistaja valitsee kameran pohjapiirroksesta [E3]. Talon omistaja valitsee näytä toiminnon. Järjestelmä näyttää ikkunan, jossa on valitun kameran numero [E3]. Järjestelmä näyttää ikkunassa kuvaa valitusta kamerasta [E3]. 1.3 Tarkennetut kulut (subflows): ei ole 1.4 Vaihtoehtoiset kulut (alternative flows): [E1] Jos käyttäjätunnus tai salasana on väärä, siirry käyttötapaukseen [UC x] (Varmista käyttäjätunnus ja salasana) [E2] Jos valvontatoimintoa ei ole räätälöity talon omistajan talolle, siirry käyttötapaukseen [UC x] (Konfiguroi valvontatoiminto) [E3] Jos talon omistaja valitsee Näytä pikkukuvaa (thumbnail) kuvaa kaikista kameroista, siirry käyttötapaukseen [UC x] (Näytä pikkukuvaa kuvaa kaikista kameroista) 13

Analyysiluokkien tunnistaminen Voidaan aloittaa käyttöskenaarioita tutkimalla alleviivataan substantiivit tai substantiivilausekkeet kerätään ne tauluun tunnistetaan synonymit Tunnistetaan myös toiminnot (operaatiot) merkitään verbit kursiivilla 14

Tunnistetaan esim. Ulkoiset entiteetit muut järjestelmät, laitteet, ihmiset Asiat raportit, näytöt, kirjeet Tapahtumat transaktiot, hälytykset Roolit johtaja, suunnittelija, myyjä Organisaatioyksiköt osasto, ryhmä, tiimi Paikat valmistuspaikka, tapahtumapaikka Rakenteet tunnistimet, ajoneuvot, tietokoneet 15

SafeHome kuvaus SafeHome turvajärjestelmä mahdollistaa talon omistajan konfiguroida turvajärjestelmä sen jälkeen kun se on asennettu, valvoa kaikkia tunnistimia, jotka on liitetty turvajärjestelmään, ja olla yhteydessä talon omistajaan rajapinnan (Internetin, PC:n tai ohjauspaneelin) välityksellä. PC:tä käytetään asennuksen aikana järjestelmän konfigurointiin. Jokaiselle tunnistimelle määritellään numero ja tyyppi, salasana määritellään järjestelmän aktivointia ja toiminnan keskeyttämistä varten. Määritellään myös puhelinnumero, johon ilmoitetaan havaituista tunnistintapahtumista. Kun tunnistintapahtuma havaitaan, ohjelmisto laukaisee äänihälytyksen. Talon omistajan määrittelemän viiveen jälkeen järjestelmä ilmoittaa hälytyksestä, tapahtumapaikasta ja hälytyksen tyypistä valvontapalvelun puhelinnumeroon. Puhelinnumeroon soitetaan 20 sek. välein, kunnes yhteys saadaan. Talon omistaja saa tietoa hälytyksestä rajapinnan kautta ja talon omistaja käyttää järjestelmää seuraavasti 16

Mahdollinen luokka Järjestelmä (turvaj.) Talon omistaja Tunnistin Rajapinta (ohj.pan., PC ) Asennus Numero, tyyppi Salasana Puhelinnumero Tunnistintapahtuma Äänihälytys, hälytys Viive Tapahtumapaikka Valvontapalvelu Luokittelu rakenne rooli tai ulkoinen entiteetti ulkoinen entiteetti ulkoinen entiteetti tapahtuma tunnistimen attribuutteja asia asia tapahtuma ulkoinen entiteetti järjestelmän attributti paikka ulkoinen entiteetti 17

Analyysiluokan tunnistaminen 1. Onko luokassa säilytettävää tietoa? tarvitaan järjestelmän toimintaan 2. Onko luokassa tarvittuja palveluja? muutetaanko niiden avulla luokan attribuutteja 3. Onko luokassa monia attribuutteja? suunnittelun aikana yksikin attribuutti kertoo paljon, mutta toteutuksessa luokassa pitää olla useampia attribuutteja 4. Onko luokalle tavanmukaisia attribuutteja? sopivatko nämä attribuutit kaikkiin luokan esiintymisiin 5. Onko luokassa tavanmukaisia toimintoja? sopivatko nämä toiminnot kaikkiin luokan esiintymisiin 6. Kuvaako luokat olennaisia vaatimuksia? ulkoiset entiteetit tulevat esille jo vaatimusmallissa (Ehdokasluokan tulisi täyttää (lähes) kaikki näistä 6 ominaisuudesta) 18

Mahdollinen luokka Järjestelmä (turvaj.) Talon omistaja Tunnistin Rajapinta (ohj.pan., PC ) Asennus Numero, tyyppi Salasana Puhelinnumero Tunnistintapahtuma Äänihälytys, hälytys Viive Tapahtumapaikka Valvontapalvelu Perustelut 6 kohdan mukaan hyv: kaikki toteutuvat ei hyv/hyv: 1, 2 ei, 6 kyllä hyv: kaikki toteutuvat hyv: kaikki toteutuvat ei hyv: ei hyv: 3 ei, tunnistimen attrib. ei hyv: 3 ei, järjestelmän attrib. ei hyv: 3 ei, järjestelmän attrib. hyv: kaikki toteutuvat hyv: 2,3,4,5,6 toteutuvat ei hyv: 3 ei, järjestelmän attrib. ei hyv/hyv: 1, 2 ei, 6 kyllä ei hyv/hyv: 1, 2 ei, 6 kyllä 19

ilmoittaa on yhteydessä Valvontapalvelu 1 1 Järjestelmä 1 1 1 1 valvoo saa ilmoituksen * Tapahtumapaikka 1 1 sijaitsee Tunnistin 1 havaitsee Rajapinta * laukaisee * 1 * Tunnistintapahtuma Äänihälytys Alustava luokkakaavio 20

CRC -kuvauksen kortteja Class: Tarjoilija Responsibility: Tarjoilee ruoan ja juoman asiakkaalle Ottaa vastaan tilauksen asiakkaalta Pyytää kokkia valmistamaan ruokaannoksen Collaborator Asiakas Kokki Class: Kokki Responsibility: Valmistaa ruoka-annoksen Collaborator Tarjoilija Class: Asiakas Responsibility: Valitsee ruoan ja juoman Collaborator Tarjoilija 21

Luku 7: Vaatimusten mallintaminen vuo, käyttäytyminen ja mallit (patterns) Käsitellään vain SA (Structured Analysis) menetelmän komponentit Vaatimusten keräys Web-sovelluksessa Esimerkki: Taidevälittäjän tuki 22

Liittymäkaavio (terminaattorit/transformaatiot) Tapahtumalista 1. Tapahtuma 1 2. Tapahtuma 2 Tietohakemisto tieto_a = tieto_b + tieto_c tieto_x =... Hierarkkiset tietovuokaaviot ER-kaaviot Tilakaaviot SA (Structured Analysis) menetelmän komponentit Minispesifikaatiot if a < b then... 23

Ohjauspaneeli käyttäjän komennot ja data näytön informaatio Ohjauspaneelin näyttö Safe Home ohjelmisto hälytyksen tyyppi Hälytys Tunnistimet tunnistimien tila numeron valinta Puhelinyhteys Liittymäkaavio (context diagram) SafeHome kodin turvajärjestelmälle 24

Ohjauspaneeli käyttäjän komennot ja data Vuorovaikutus käyttäjän kanssa salasana konfigurointipyyntö käynnistä/ lopeta Aktivoi/ passivoi järjestelmä Konfiguroi järjestelmä A/P viesti konfigurointitiedot Järjestelmän konfigurointitiedot konfigurointitiedot Tunnista salasana käypä salasana konfigurointitiedot Näytä viestit ja tila näytön informaatio numeron valinta Ohjauspaneelin näyttö Tunnistimet tunnistimien tila Valvo tunnistimia hälytyksen tyyppi numeron valinta Hälytys Puhelinyhteys Ensimmäisen tason DFD kaavio SafeHome kodin turvajärjestelmälle

Vaatimusten keräys (Web-)sovelluksessa 1. Määrittele käyttäjäkategoriat sidosryhmien haastattelun perusteella 2. Määrittele sovellukselta odotettavat piirteet sidosryhmien haastattelun perusteella 3. Analysoi kerättyä tietoa 4. Määrittele käyttötapauksien avulla vuorovaikutusskenaariot kaikille käyttäjäluokille 26

1. Määrittele käyttäjäkategoriat Mikä on käyttäjän tavoite, miksi hän käyttää sovellusta? esim. SafeHomeAssured.com sivun käyttäjä etsii tietoja turvajärjestelmistä tekee hintavertailua haluaa hankkia järjestelmän hakee teknistä tukea Kuinka hyvin käyttäjä tuntee sovelluksen hyvin perehtynyt <-> aloittelija Mitä kautta käyttäjä tulee sovelluksen käyttäjäksi Mistä ominaisuuksista käyttäjä pitää/ei pidä Näiden kysymysten avulla pitää määritellä riittävä määrä käyttäjäluokkia 27

2. Kommunikointi sidosryhmän (sisältää loppukäyttäjät) kanssa Pyritään keräämään tietoa mahdollisimman monilta käyttäjiltä, voidaan käyttää perinteistä keskustelua tyypillisten käyttäjien kanssa, tavoitteena parempi ymmärrys vaatimuksista sähköisesti toteutettua keskustelua, voidaan helposti tallettaa, koska kommunikointi tekstimuodossa haastatteluja, kysytään käyttäjän mielipidettä sovelluksesta web sivua tai sähköpostia käyttäen skenaarioita, käyttötapausten avulla kuvataan sovelluksen käyttöä 28

3. Analysoidaan kerättyä tietoa Kerätty tieto luokitellaan käyttäjäluokkien ja transaktiotyyppien mukaan Tavoitteena on saada lista sisältöolioista operaatioista, jotka liittyvät olioihin tietyssä transaktiossa toiminnoista, joita sovellus tarjoaa käyttäjälle ei-toiminnallisista vaatimuksista 29

4. Käyttötapausten kehittäminen Käyttötapauksia tarvitaan tehokkaan analyysimallin rakentamiseen Käyttötapaukset auttavat suunnittelijaa ymmärtämään, millaisia käyttötarpeita loppukäyttäjällä on Käyttötapaukset auttavat kehitystyön jakamisessa osiin Käyttötapaukset toimivat testitapausten kehittämisen perustana 30

Esimerkki: Taidevälittäjän tuki (käyttötapaus, luokkakaavio, yhteistyökaavio ja sekvenssikaavio) Taidevälittäjän tukiohjelmiston tulisi laskea korkein hinta, jonka välittäjän kannattaa maksaa maalauksesta. Ohjelmiston tulisi tuottaa myös raportteja hankinnoista ja myynneistä. Välittäjällä on siten kolme liiketoimintaaktivitettia: hän ostaa maalauksia, myy maalauksia ja tuottaa raportteja. Taidevälittäjä kerää tarkkaa tietoa omista, gallerian omistamista maalauksia ja hyödyntää hinta-arvioissaan huutokaupattujen töiden hintatietoja. Maalaus voi olla mestarityö tai muu maalaus. 31

Mestarityön tekijä on tunnettu maalari ja sen arvo saadaan huutokauppatiedoista. Huutokauppahintaa korotetaan vuosittain 8%:lla siitä vuodesta lähtien, kun kauppa on tehty. Mestarityön arvon arvioimiseksi etsitään mahdollisimman samankaltainen myyty työ, jonka hintaa käytetään hinnoittelun perustana. Samankaltaisuuskerroin saadaan tekniikan, aiheen ja koon perusteella. Tällöin arvioidaan onko tekniikka samanlainen (1 tai 0) onko aihe samanlainen (1 tai 0) Lasketaan nämä luvut yhteen ja kerrotaan pienemmän maalauksen koolla ja jaetaan suuremman maalauksen koolla. Jos kerroin on 0, välittäjä ei luokittele työtä mestarityöksi. Muun maalauksen hinta saadaan tekijän muotikertoimen ja kankaan koon perusteella (niiden tulona). Jos muotikerrointa ei tiedetä, välittäjä ei osta työtä. 32

Taidevälittäjän tuki Osta maalaus Myy maalaus Myyjä Välittäjä Tuota raportti Ostaja Päivitä muotikerroin 33

Maalaus GallerianTyö HuutokTyö Mestarityö MuuMaalaus MuotiKerroin käyttää 34

Maalaus etunimi sukunimi työnnimi valmisvuosi korkeus leveys tekniikka aihe GallerianTyö luokittelu hankintapäivä myyjännimi maxhankintahinta todhankintahinta tavoitemyyntihinta myyntipäivä ostajannimi ostajanosoite todmyyntihinta HuutokTyö huutopäivä huutohinta Mestarityö MuuMaalaus MuotiKerroin käyttää tekijänetunimi tekijänsukunimi kerroin 35

Luokkien stereotyyppiesitystapa Malliluokka (entity) - Model mallintaa pitkäaikaista informaatiota, esim. Maalaus Käyttöliittymäluokka (boundary) View mallintaa vuorovaikutusta tuotteen ja aktoreiden välillä, esim. Hankintaraportti Kontrolliluokka (control) Controller mallintaa monimutkaista laskentaa, esim. LaskeMestarityönHinta 36

Kurssi Harjoitusryhmä <<read>> <<read>> Ilmoittautuminen <<maintain>> Osallistuminen <<read>> Opiskelija (Luukkainen & Laine, 2010) 37

Skenaario mestarityön ostolle Välittäjä antaa kuvauksen maalauksesta Ohjelmisto selaa huutokauppatietoja löytääkseen mahdollisimman samanlaisen työn samalta tekijältä Ohjelmisto laskee hankintahinnan ylärajan lisäämällä huutokauppahintaan vuosittaisen 8%:n korotuksen. Välittäjä tekee tarjouksen, joka alittaa lasketun ylärajan myyjä hyväksyy tarjouksen Välittäjä päivittää myyntitiedot (myyjän nimi ja osoite, hankintahinta) 38

Myyjä antaa välittäjän pyytämän tiedon Myyjä Mestarityö Välittäjä UI Hinnoittelija HuutokTyö Kommunikaatiokaavio: Osta mestarityö 39

Myyjä Myyjän tieto välittäjälle 1: Anna mestarityön tiedot 3: Luo uusi olio :Mestarityö 9: Anna myyjän tiedot 2: Siirrä mestarityön tiedot 10: Siirrä myyjän tiedot 11: Pyydä päivitys 4: Palauta uusi olio 12: Ilmoita päivityksen onnistumisesta 5: Selaa huutokauppatietoja Välittäjä 8: Näytä hinta 14: Näytä ilmoitus päivityksen onnistumisesta :UI 7: Tuota hinta 13: Ilmoita päivityksen onnistumisesta :Hinnoittelija 6: Palauta huutokaupatun työn hinta :HuutokTyö Kommunikaatiokaavio: Osta mestarityö 40

Myyjä Välittäjä :UI :Hinnoittelija :HuutokTyö 1: Anna mestarityön tiedot 2: Siirrä mestarityön tiedot 3: Luo uusi olio :Mestarityö Myyjän tieto välittäjälle 8: Näytä hinta 9: Anna myyjän tiedot 7: Tuota hinta 10: Siirrä myyjän tiedot 4: Palauta uusi olio 5: Selaa huutokauppatietoja 11: Pyydä päivitys 6: Palauta huutokaupatun työn hinta 14: Näytä ilmoitus päivityksen onnistumisesta 13: Ilmoita päivityksen onnistumisesta 12: Ilmoita päivityksen onnistumisesta Sekvenssikaavio: Osta mestarityö 41

Soveltuvat lait 1. Käytetyn mallin arvo riippuu valitusta näkökulmasta, mikään ei ole paras kaikkiin tarkoituksiin / no 4, Davis 1990 Davisin laadullisessa tutkimuksessa nähtiin, että eri kuvaustavoilla päästiin hyödyllisiin, vaikkakin erilaisiin tuloksiin. Kuvausmenetelmät ovat hyödyllisempiä ratkaisun kuvaamisessa kuin ongelman määrittelyssä (ongelman määrittelyssä toimialan tietämys on tärkeää) Ohjelmistosuunnittelijan tulisi käyttää useita sopivia työkaluja ja tekniikoita, kuten puuseppä huonekalujen valmistamisessa. 2. Oliomalli vähentää kommunikoinnin ongelmia analysoijien ja käyttäjien välillä / hyp_no 1, Booch 1991 perustellaan sillä, että (1) voidaan helpommin mallintaa ihmisen tietämystä, (2) siirto vaatimusmäärittelyistä suunnitteluun ja toteutukseen on saumaton, (3) käsitellään dataa ja prosesseja samanaikaisesti ja (4) noudattaa hyviä ohjelmistotekniikan periaatteita. 42