Ohjelmiston suunnitteluperiaatteita Kevät 2002 Päivi Ovaska LTKK/Tite.

Esitys aiheesta: "Ohjelmiston suunnitteluperiaatteita Kevät 2002 Päivi Ovaska LTKK/Tite."— Esityksen transkriptio:

1 Ohjelmiston suunnitteluperiaatteita Kevät 2002 Päivi Ovaska LTKK/Tite.

2 Sisältö Ohjelmiston laatiminen Ohjelmistoparadigmat Suunnittelun tavoitteet Suunnittelun yleisiä periaatteita Modulien toteuttaminen Suunnittelun eteneminen Esimerkki Työkalut ja teknologiat

3 Ohjelmiston laatiminen

4 Erilaisia ohjelmistorakenteita Spagetti strukturointu

5 Moduli

6 Periaatteista ja toteutusvälineistä laatuun

7 Suunnittelun yleisiä periaatteita Yksinkertaisuus ja suoraviivaisuus osittaminen ja lokaalisuus abstraktioiden hyödyntäminen yhdenmukainen toteutusfilosofia eli arkkitehtuurityyli

8 Yksinkertaisuus ja suoraviivaisuus KISS: On kaksi tapaa rakentaa ohjelmistoja (Hoare). 1: Suunnitteluratkaisut ovat niin suoraviivaisia ja ymmärrettäviä, että virheettömyys on ilmeistä. 2: Suunnitteluratkaisut ovat niin mutkikkaita, että virheet eivät ole ilmeisiä. Kolme hyvää periaatetta: - KISS: Keep It Simple, Stupid - Design for errors. - Design for change. Ja erityisesti reaaliaikajärjestelmissä: - Design for testing. Ja ehkä se kaikista tärkein periaate: - SAY IT ONCE AND ONLY ONCE.

9 Esimerkki hierarkkisesta osittamisesta

10 Lokaalisuus Osittamisen suunnittelua siten, että suunnittelupäätökset kapseloidaan mahdollisimman hyvin osien sisään Edut: – muutosten tekeminen helpottuu – ohjelmiston yksittäisten osien toteutus ja testaus erikseen – mahdollistaa osan irrottamisen kokonaisuudesta ja uudelleenkäytön toisessa yhteydessä Modulin sisäisen toteutuksen lokalisointi

11 Abstraktioiden hyödyntäminen Abstraktio – malli, joka kuvaa esittämästään asiasta oleellisen Epäoleellinen voidaan jättää pois ja tarpeettomat yksityiskohdat koteloidaan (encapsulate) abstraktion sisälle Informaatin kätkeminen (information hiding) Abstraktiosta näkyy käyttäjälle rajapinta (interface), sen sisään koteloitu toteutus on abstraktion käyttäjälle tuntematon Käyttötarkoituksina korkeamman tason abstraktion luominen alemman tason abstraktiosta, erilaisuuden kätkeminen, suunnitteluratkaisun piilottaminen

12 Esimerkki työasemasovelluksen abstrahoinnista

13 Yhdenmukainen toteutusfilosofia = arkkitehtuurityyli Yhdenmukaiset toteutusperiaatteet, joilla järjestelmän piirteet toteutetaan Toteutusfilosofia kiteyttää periaatteet ja rakenteet, joiden ajatellaan pysyvän muuttumattomana Antaa kehittäjälle mallin siitä, miten uusi ominaisuus toteutetaan järjestelmään Antaa ylläpitäjälle tietoa, minkä tapaista ratkaisua on etsittävä ja mihin muutokset on kohdistettava Antaa yleisen mallin, jonka mukaan järjestelmän avainabstraktioita yhdistellään

14 Esimerkki käyttöjärjestelmän toteutusfilosofioista

15 Modulien toteuttaminen Yksi moduli kuvaa yhden abstraktion tai koostuu joukosta yhteenkuuluvia aliohjelmia useimiten modulijako vastaa ohjelman jakoa tiedostoiksi Modulien kuvauksessa rajapinnan kuvaus erotettava sisäisestä toteutuksesta (esim. C, rajapintafuntiot otsikkotiedostoon, modulin tietorakenteet ja funktiot toteutustiedostoihin)

16 Esimerkki moduulin määrittelystä /* This module implements a simple integer stack. The maximum depth of the stack is defined by "stackSize" below. Items can be pushed and popped to/from the stack, and the number of items in the stack can be queried with function "sizeOfStack". In the cases of stack overflow and stack underflow, the module prints an error message to stderr, and exits to operating system with exit status 1. */ #define stackSize 10 void push(int n); int pop(void); int sizeOfStack(void); Käyttö: #include "stack.h" : if (sizeOfStack()>0) {item = pop();}

17 Moduulin toteutus /* Version 1.0 14.9.1996 ijh */ #include #include "stack.h" static int stack[stackSize]; static int stackTop = 1; /* stack pointer */ void push(int n) { if (stackTop < stackSize 1) { stack[++stackTop] = n; } else { fprintf(stderr,"stack overflow\n"); exit(1); } int pop(void) { if (stackTop >= 0) { return stack[stackTop]; } else { fprintf(stderr,"stack underflow"); exit(1); } return 0; /* never executed, just remove compiler warning*/ } int sizeOfStack(void){ return stackTop+1; }

18 Abstrakti tietotyyppi Luokkarajapinnan määrittely (stack.h) const int stackSize=10; class Stack { int theStack[stackSize]; int stackTop; public: Stack(); // konstruktori eli rakentaja ~Stack(); // destruktori eli tuhoaja void push(int n); int pop(); inline int sizeOfStack() const; }; Käyttö: Stack s1,s2; // määritellään kaksi pinoa s1.push(3); s2.push(4); Termejä - luokka - metodi - jäsenfunktio - jäsenmuuttuja - ilmentymä - olio - konstruktori - destruktori - kuormitus? - yleisrasite - inline

19 Toteutus #include Stack::Stack(): stackTop(-1) // stackTop alustetaan arvoon -1 {} Stack::~Stack() {} // destruktori ei tee mitään void Stack::push(int n) { if (stackTop < stackSize - 1) { theStack[++stackTop] = n; } else { fprintf(stderr, "stack overflow\n"); exit(1); } int Stack::pop(){ if (stackTop >= 0) { return(theStack[stackTop--]); }else { fprintf(stderr, "stack underflow\n"); exit(1); } inline int Stack::sizeOfStack() { return(stackTop + 1); }

20 Rajapintojen suunnittelu ja toteutus Modulin rajapinta on sopimus modulin käyttäjän ja sen toteuttajan välillä Sopimuksessa modulin tarjoamat palvelut, modulin ympäristöstään ja käyttäjän toiminnasta tekemät oletukset, modulin toteutuksen asettamat rajoitukset, modulin toiminta poikkeustilanteissa Huomioitavia asioita: – modulien sisäinen kiinteys (cohesion) – modulien väliset kytkennät (coupling)

21 Rajapintojen dokumentointi Minne? – Tekninen määrittely. – Moduulin määrittelytiedosto. – Moduulin toteutustiedosto. – CASE-väline. Miten – Riittävän tarkasti". – Yksi nyrkkisääntö: toinen henkilö (eri kuin tekijä) pystyy moduulitestaamaan moduulin spesifikaation perusteella tutustumatta toteutukseen. Ylläpito? – Muokattava ylläpitoa tukevaan muotoon.

22 Modulien väliset kytkennät Rajapinnat mahdollisimman kapeita ja löyhiä: välitetään vain ne tiedot, joita se tarvitsee operaation suorittamiseen – arvonvälitys osoittimien sijaan – vältä erityisesti tilannetta, jossa parametrien välityksen seurauksen jokin moduli säilyttää itsellään osoittimen toisen modulin sisäisiin tietorakenteisiin

23 Suunnittelun eteneminen Mietitään ratkaisun yleiset periaatteet (toteutusfilosofia, arkkitehtuurityyli) Suunnitellaan modulirakenne Määritellään, mitä tietoa modulit sisältävät Suunnitellaan modulien rajapinnat Määritellään modulien näkyvyys: mitä muita moduleja moduli tarvitsee toiminnassaan Testataan ratkaisua tutkimalla millaisia kutsusekvenssejä ohjelmat toiminnot aiheuttavat modulien sisällä (esim. SA menetelmän tapahtumalistana, UML käyttötapauksina) Suunnitellaan modulien sisäinen toteutus Varmistetaan kriittisimpien toteutusratkaisujen toimivuus esimerkiksi prototyypillä Suunnittelun dokumentointi Iteroiden ja rinnakkain

24 Esimerkki Ohjelmisto muodostaa tekstitiedostosta hakusanaston Hakusanasto sisältää dokumentissa esiintyneet sanat aakkosjärjestyksessä Jokaisesta sanasta tulostetaan sen esiintymisrivit tiedostossa Hakusanasto on muotoa: akku 4 akussa5,10 alku1,7...

25 Tapahtuma- sekvenssikaavio sanaston muodostamisesta

26 Esimerkkiohjelman luokkakaavio

27 Esimerkkiohjelman rajapintamäärittelyt

28 Esimerkkiohjelman modulien näkyvyyys

29 Työkalut ja teknologiat Olioteknologia ei poista perinteisten välineiden tarvetta (tuotteenhallinta, testaus, dokumentointi...). Ohjelmointikielet (ja ympäristöt) Komponenttiteknologiat – CORBA, COM+ (DCOM, ActiveX),.NET, Java Beans, Enterprise Java Beans (EJB) – hajautettujen oliokeskeisten järjestelmien toteuttaminen. Määrittelyn ja suunnittelun apuvälineet (CASE) – Rational Rose, Prosa, Metacase… tietohakemisto, kaaviot, koodin generointi, reverse-engineering – Kaavionpiirtelyvälineet (Visio, ABCFlowcharter). Olioiden pysyvyyden toteuttaminen (persistence) – talletus tiedostoihin – talletus relaatiotietokantaan – oliotietokanta.

30 Oliokielet

31 Uudelleenkäytettävät ohjelmistokomponentit 60 – 80% kaikesta tehtävästä ohjelmistosta on tehty jo aikaisemmin, osa siitä jopa samassa organisaatiossa Yleiskäyttöiset komponentit – käyttöliittymäkirjastot, matematiikkakirjastot, tietorakennekirjastot sovellusaluekohtaiset komponentit – esim. televerkon hallintaan liittyvät sovelluskohtaiset komponenti – sovelluksen oma käyttöliittymäkirjasto sovelluskehykset (frameworks) – joukko toisiinsa liittyviä komponentteja

32 Uudelleenkäyttö tuotantoprosessissa

33 Uudelleenkäytön ongelmia Komponenttikirjaston luomisen ja ylläpitämisen vaatima työmäärä Komponenttien etsiminen Dokumentoinnin puutteellisuus Haluttomuus käyttää muiden tekemiä komponentteja Uudelleenkäytettävät komponentit eivät synnyt projektityön sivutuotteina, vaan ne vaativat erityispanostusta ja myös erityisosaamista