OMT Design System design –design technical environment Object design –design class diagram

OMT System design (Pressman sivut ) Partitioning the analysis model Concurrency and Subsystem allocation Task Management Data Management Resource Management Human-Computer Interface Intersubsystem Communication

Oliopohjainen käyttöliittymän suunnittelu Sisältää sekä ulkoasun että toteutustavan suunnittelun Käyttöliittymän toteutustavan keskeisten ratkaisujen tulisi olla riippumattomia sen ulkoasusta Käyttöliittymän ja sovelluksen välinen kommunikointi tulisi olla käyttöliittymän toteutustavasta riippumaton

Käyttöliittymän suunnittelu Ulkoasun ja toteutustavan suunnittelu Ulkoasun suunnittelu erittäin tärkeä vaihe Toteutustavan tulisi olla riippumaton ulkoasusta

Käyttöliittymän ja sovelluksen välinen kommunikointi MVC -malli (Model-View-Controller) Tarkkailija (Observer) suunnittelumalli –Maailma koostuu subjekteista ja tarkkailijoista. Kullakin subjektilla voi olla mielivaltaisen monta tarkkailijaa, joiden laatua ei subjekti tunne.Aina kun subjekti haluaa muuttaa tilaansa, se ilmoittaa siitä kaikille tarkkailijoilleen, jotka noteeraavat muutoksen kukin tavallaan. Kun tarkkailija haluaa ryhtyä tarkkailemaan jotakin subjekti, se ilmoittautuu tälle. –Subjekti on sovellus, tarkkailija tämän kuva näytöllä. Kun sovelluksen tila muuttuu, kaikille siitä riippuville käyttöliittymäelementeille ilmoitetaan muutoksesta

Käyttöliittymän suunnittelu- Tarkkailija suunnittelumalli Maailmaa koostuu subjekteista ja tarkkailijoista. Kullakin subjektilla voi olla mielivaltaisen monta tarkkailijaa, joiden laatua subjekti ei tunne Aina kun subjekti muuttaa tilansa, se ilmoittaa siitä kaikille tarkkailijoilleen, jotka noteeraavat muutoksen kukin tavallaan Kun tarkkailija haluaa ryhtyä tarkkailemaan jotakin subjektia, se ilmoittautuu tälle

Oliosuunnittelu Tavoitteena täsmentää analyysimallia ottamalla huomioon toteutustekniset näkökohdat, mutta sitoutumatta kuitenkaan vielä tiettyyn toteutusvälineeseen (esim. kieleen) OMT:ssä lisäksi systeemisuunnitteluvaihe (= teknisen toteutusympäristön kiinnittäminen)

Oliosuunnittelun tehtävät Staattinen malli –olioiden esitysmuodon suunnittelu –tehokkuusnäkökohtien huomioon ottaminen –assosiaatioiden suunnittelu –muunneltavuuden lisääminen Dynaaminen malli –käyttöliittymän suunnittelu –operaatioiden suunnittelu –tilakaavioiden suunnittelu

Olioiden esitysmuoto Kaikkia analyysivaiheen luokkakaaviossa olevia luokkia ei välttämättä kannata toteuttaa omina luokkinaan –luokka voidaan esittää käyttäen perustietotyyppejä, esim. Kokonaislukuja –esitetäänkö jokin käsite omana luokkanaan vaiko vain joukkona jonkin toisen luokan attribuutteja

Tehokkuusnäkökohdat Assosiaatioiden vaikutus operaatioiden ja olioihin viittaamisen tehokkuutteen –viittauspolkuja lyhentävät assosiaatiot Johdetut attribuutit tehostavat usein suoritusta, koska niillä vältetään tietyn muista attribuuteista riippuvan tiedon uudelleenlaskenta

Assosiaatioiden suunnittelu Assosiaatiot puretaan toteutuksessa –1:1 suhteet viiteattribuuteiksi –2 tai 3, vastaava määrä viiteattribuutteja –n assosiaatio säiliöolion avulla (hajautettu hakemisto tai indeksoitu rakennne) –m:n erityisen assosiaatioluokan avulla

Muunneltavuuden ja ylläpidettävyyden lisääminen Abstraktit luokat ja virtuaalioperaatiot –voidaanko operaation määrittely antaa siinä luokassa, jossa operaatio esiintyy mallissa, tai onko operaatio tarkoitettu uudelleenmääriteltäväksi aliluokissa –uusia abstrakteja yliluokkia Abstraktit rajapintaluokat ylläpidettävyyden lisäämiseksi

Suunnittelumallit (desing patterns) Tapa suunnitella olio-ohjelmiston osa tietyn usein esiintyvän ongelman ratkaisemiseksi Suunniteluprosessin abstraktiotasoa voidaan nostaa ja kokeneiden ohjelmoijien osaamista siirtää muille –mallit ovat mestarikokin reseptejä :-) Koskee usein muutamia luokkia ja niiden välisiä suhteita; tyypillisesti 3-4 luokkaa Gamma et. al.: Design Patterns Erilaisia malleja: –luontimallit (creational patterns) –rakennemallit (structural patterns) –käyttäytymismallit (behavioral patterns)

Käyttöliittymän suunnittelu Ulkoasun ja toteutustavan suunnittelu Ulkoasun suunnittelu erittäin tärkeä vaihe Toteutustavan tulisi olla riippumaton ulkoasusta

Käyttöliittymän ja sovelluksen välinen kommunikointi MVC -malli (Model-View-Controller) Tarkkailija (Observer) suunnittelumalli –Maailma koostuu subjekteista ja tarkkailijoista. Kullakin subjektilla voi olla mielivaltaisen monta tarkkailijaa, joiden laatua ei subjekti tunne.Aina kun subjekti haluaa muuttaa tilaansa, se ilmoittaa siitä kaikille tarkkailijoilleen, jotka noteeraavat muutoksen kukin tavallaan. Kun tarkkailija haluaa ryhtyä tarkkailemaan jotakin subjekti, se ilmoittautuu tälle. –Subjekti on sovellus, tarkkailija tämän kuva näytöllä. Kun sovelluksen tila muuttuu, kaikille siitä riippuville käyttöliittymäelementeille ilmoitetaan muutoksesta

Operaatioiden suunnittelu Analyysivaiheessa kuvaus muutamalla lauseella Suunnitteluvaiheessa kuvaus täsmennetään niin, että näistä kuvauksista voi suoraviivaisesti tuottaa koodia Operaatiokaavake

Tilakaavioiden suunnittelu Ongelma: tilakaaviolla ei suoraa vastinetta ohjelmointikielissä Operaatiopohjainen toteutus: tilakaavion omaava olio vastaanottaa sanomat synkronisten operaatiokutsujen muodossa Simuloitu tila-automaatti: ohjausolio lukee sanomaa jostakin lähteestä Strukturoitu toteutus: ei erillistä tila-attribuuttia, tilaa vastaa tietty ohjelmakohta

Uudelleenkäytön oliomekanismit Periytyminen (inheritance) –muuntava uudelleenkäyttö (white-box reuse) –ongelmat: staattisuus: perittyjä ominaisuuksia ei voi muuttaa ajonaikana avoimuus: aliluokka näkee yliluokan yksityiskohdatkin

Uudelleenkäytön oliomekanismit Kompositio (Composition) –kokoaa uudelleenkäyttö (black-box reuse) –perustuu olioiden rajapintoihin: niin kauan kuin olioiden rajapinnat säilyy, ne voidaan vaihtaa toisiksi –Hyödyt: modulaarinen tapa helpompaa, tunnetaan vain rajapinnat –Haitat: toteutus vaikeammin ymmärrettävä vähemmän joustava –Komponenttipohjaiset ohjelmistot: Bean, EJB, Corba

Uudelleenkäytön oliomekanismit Delegointi (delegation) –periytymisen toteuttaminen komposition avulla –olio siirtää suorituspyynnön jollekin toiselle oliolle (yliluokkaolio, parent object), jos se ei itse pysty sitä toteuttamaan –etuna tavanomaiseen periytymiseen: olioiden käyttäytymistä voidaan dynaamisesti muuttaa –useissa suunnittelumalleissa sovelletaan delegointia

Sovelluskehykset (application frameworks) Kiinteästi toisiinsä liittyvien luokkien kokoelma, josta sopivasti täydentämällä ja kokoamalla saadaan valmis sovellus tai sen merkittävä osa Ohjelmisto, joka sisältää tietyn tyyppisten sovellusten peruratkaisut Esimerkki: graafisten käyttöliittymien toteutusta tukevat luokkakirjastot (Borland OWL, Java AWT)

Sovelluskehyksen suunnittelu Sovelluskehyksen suunnittelu iteratiivisesti: suunnitellaan yksittäisiä sovelluksia sovellusalueella, irroitetaan näiden yhteiset osat sovelluskehyksen ensimmäiseksi versioksi Sovelluskehyksen suunnittelussa olennaista löytää ne seikat, jotka voivat vaihdella (kuumat kohdat, hot spot)

Perinteinen ohjelmakirjasto ja sovelluskehys Hollywood-periaate: don’t call us, we’ll call you Sovellus Sovelluskehys Moduuleita Sovelluskohtainen koodi Uudelleenkäytettävä koodi Aliluokkia