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

Esitys aiheesta: "OMT Design System design –design technical environment Object design –design class diagram."— Esityksen transkriptio:

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

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

3 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

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

5 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

6 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

7

8 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)

9 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

10 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

11 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

12 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

13 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

14 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)

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

16 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

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

18 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

19 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

20 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

21 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

22 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)

23 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)

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