2 1 2 2 Kertaus on opintojen äiti: OSI malli Oliokeskeiset välikerrokset Application Presentation Session Transport Network Data link Physical 2 3 2 4 Kuljetus eli transport kerros Kerros 4 OSI-mallissa. Tiedon siirto verkossa. Internetissä kaksi yleistä protokollaa, TCP ja UDP. Tarkalleen ottaen TCP/IPpino ei noudata OSImallia, mutta kuljetuskerroksen tehtävien osalta melko hyvin. Application Presentation Session Transport Network Data link Physical Transmission Control Protocol (TCP) Kaksisuuntainen tavuvirta hajautettujen komponenttien välillä. Esim. UNIXin rsh, rcp ja rlogin toimivat TCP:n päällä. Luotettava mutta hieman hidas. Puskurointi molemmissa päissä -> laskentanopeudet voivat olla erilaiset.
2 5 2 6 Pyynnöt ja vastaukset TCP:llä User Datagram Protocol (UDP) Asiakas Application Palvelin Application Tavuista koostuvien datagrammien välittäminen komponentilta toiselle. Datagrammissa on vastaanottajan osoite. Epäluotettava mutta hyvin nopea protokolla. Presentation Presentation Viestin pituus rajoitettu. Vastaanottajan pää puskuroitu. Session Pyynnöt Session Esim. UNIXin rwho-komento on UDP-pohjainen. Transport Syötevirta Tulosvirta Transport Vastaukset 2 7 2 8 Pyynnöt ja vastaukset UDP:llä Sovellus suoraan kuljetuskerroksen päälle Asiakas Application Presentation Session Transport Palvelin Application Presentation Pyyntödatagrammit Session Transport Vastausdatagrammit Pyyntöjen parametrit muunnettava manuaalisesti tavujonoiksi. Tiedon heterogeenisyys ratkaistava manuaalisesti. Komponentit tunnistettava manuaalisesti. Komponentit aktivoitava manuaalisesti. Ei takeita tyyppiturvallisuudesta. Hajautettujen komponenttien interaktiot synkronoitava manuaalisesti. Ei Quality of Service-takeita (QoS).
Välikerroksen rooli 2 9 Sovelluksen ja kuljetuskerroksen välissä, toteuttaa istunto- (session) ja esitystapakerrokset (presentation). Tekee hajautuksen tuntumattomaksi. Ratkaisee heterogeenisyyden laitteistotasolla, käyttöjärjestelmätasolla, verkkojen välillä ja ohjelmointikielten välillä. Kehitys- ja ajoympäristö hajautetuille komponenteille. Metodikutsu vs. etämetodikutsu Caller Kutsuja Kutsuttava Kutsuja Tynkä Kutsuttava Tynkä Kuljetuskerros (esim. TCP tai UDP) 2 10 tynkä on englanniksi stub Tynkä (engl. stub) Tyngän koodi generoidaan automaattisesti rajapintamäärittelystä. Asiakastynkä edustaa palvelinta asiakkaalle, palvelintynkä edustaa asiakasta palvelimelle. Tynkä toteuttaa proxy-patternin Palvelintynkää kutsutaan joskus rangaksi (engl. skeleton). Tyyppiturvallisuus. Tyngät myös huolehtivat synkronoitumisesta kutsussa. 2 11 Synkronoituminen Tavoitteena samanlainen synkronoituminen kuin paikallisessa metodikutsussa (kutsuja odottaa vastausta). Tyngät toteuttavat: Asiakastynkä lähettää pyynnön ja odottaa vastausta palvelimelta. Palvelintynkä odottaa pyyntöjä ja kutsuu varsinaista palvelinoliota pyynnön saadessaan. 2 12
2 13 Yksinkertainen tynkä ranka toteutus Tehdään yksinkertaisen etäolion tynkä ja ranka itse Javalla. Etäoliolle määritellään seuraavanlainen rajapinta: public interface Person { public int getage() throws Throwable; public String getname() throws Throwable; Palvelinolion toteutus public class PersonServer implements Person { int age; String name; public PersonServer(String name, int age) { this.age = age; this.name = name; public int getage() { return age; public String getname() { return name; 2 14 Asiakkaan tynkä import java.io.objectoutputstream; import java.io.objectinputstream; import java.net.socket; public class Person_Stub implements Person { Socket socket; public Person_Stub() throws Throwable { socket = new Socket("130.230.3.2", 9000); public int getage() throws Throwable { ObjectOutputStream outstream = new ObjectOutputStream(socket.getOutputStream()); outstream.writeobject("age"); outstream.flush(); ObjectInputStream instream = new ObjectInputStream(socket.getInputStream()); return instream.readint(); public String getname() throws Throwable { ObjectOutputStream outstream = new ObjectOutputStream(socket.getOutputStream()); outstream.writeobject("name"); outstream.flush(); ObjectInputStream instream = new ObjectInputStream(socket.getInputStream()); return (String)inStream.readObject(); 2 15 Palvelimen ranka import java.io.objectoutputstream; import java.io.objectinputstream; import java.net.socket; import java.net.serversocket; public class Person_Skeleton extends Thread { PersonServer myserver; public Person_Skeleton(PersonServer server) { this.myserver = server; ; 2 16 public void run() { try { ServerSocket serversock = new ServerSocket(9000); Socket sock = serversock.accept(); while (soc!= null) { ObjectInputStream istream = new ObjectInputStream(soc.getInputStream()); String method = (String)iStream.readObject(); if (method.equals("age")) { int age = myserver.getage(); ObjectOutputStream ostream = new ObjectOutputStream(sock.getOutputStream()); ostream.writeint(age); ostream.flush();
Palvelimen ranka (jatkoa) else if (method.equals("name")) { String name = myserver.getname(); ObjectOutputStream ostream = new ObjectOutputStream( sock.getoutputstream()); ostream.writeobject(name); ostream.flush(); catch (Throwable t) { t.printstacktrace(); System.exit(0); public static void main(string args[]) { PersonServer person = new PersonServer("Eufrosyne", 57); Person_Skeleton skel = new Person_Skeleton(person); skel.start(); 2 17 Asiakasohjelma public class PersonClient { public static void main(string [] args) { try { Person person = new Person_Stub(); int age = person.getage(); String name = person.getname(); System.out.println(name + " on " + age + "-vuotias"); catch (Throwable t) { t.printstacktrace(); 2 18 Yksinkertaisen tynkä ranka toteutuksen ongelmia Käsityötä Palvelimen osoite on langoitettu asiakastyngän koodiin Vain yksi henkilöpalvelin Jos palvelimia voisikin olla useita: Mitä jos haluttaisiin lisätä henkilölle vanhemmat: miten henkilö voi viitata toisiin henkilöihin? Miten erotettaisiin samalla koneella oleville eri henkilöpalvelimille tulevat kutsut? Entäpä jos asiakas ja palvelin olisivat erilaisissa laitteistoympäristöissä? Entä jos asiakas ja palvelin pitäisi tehdä eri ohjelmointikielillä? 2 19 Kutsumeklari (Object Request Broker, ORB) Kutsumeklari (lyhyesti ORB) on oliokeskeisen hajautetun järjestelmän ydin Mahdollistaa edellisen kalvon ongelmien ratkaisemisen ORBin avulla hajautetut oliot voivat viitata toisiinsa ja kutsua toistensa palveluita ORB mahdollistaa myös monet muut välikerroksen toiminnot Kaikissa kehittyneissä oliokeskeisissä välikerroksissa on ORB, kutsuttiin sitä sillä nimellä tai jollain muulla 2 20
Olioihin viittaaminen Edellä olevassa yksinkertaisessa toteutuksessa olio oli tietyssä portissa tietyllä koneella RPC:ssä käytetään portmap-demonia, joka kuvaa palveluiden nimet portteihin Jos sitä käytettäisiin oliojärjestelmässä, joka oliolla pitäisi olla yksikäsitteinen nimi Oliokeskeisissä välikerroksissa käytetään olioviitteitä ORB huolehtii olioviitteistä Asiakkaat ja palvelimet eivät ymmärrä olioviitteiden toteutuksesta mitään 2 21 Olioihin viittaaminen (jatkoa) Asiakas identifioi kutsuttavan olion olioviitteellä Asiakkaan ORB tietää viitteen perusteella, mille koneelle kutsu on matkalla Asiakkaan ORB välittää viitteen (tai osan siitä) kutsun mukana palvelimen ORBille Palvelimen ORB osaa viitteen perusteella ohjata kutsun oikealle oliolle Välissä voi olla vielä olioadapteri Tarvittaessa olio voidaan aktivoida 2 22 Rajapintamäärittelykieli (Interface Definition Language, IDL) 2 23 IDL esimerkki 2 24 Kaikissa oliokeskeisissä välikerroksissa on rajapintamäärittelykieli (IDL). (Java/RMI:ssä tämä kieli on Java.) Perus-RPC:n ominaisuuksien lisäksi parametreina voidaan välittää oliotyyppejä, voidaan nostaa poikkeuksia ja perinnän käsite on tuettu. IDL-kääntäjä tuottaa rajapintakuvauksesta tyngät ja rangat, jotka toteuttavat istunto- ja esitystapakerrokset. interface Document : Object { typedef struct _Date { short day; short month; short year; Date; attribute string name; attribute string content; ; interface DocumentStore : Object { exception NameNotFound{; short save (in Document d); Document load(in string name) raises(namenotfound); ;
Yksinkertaistettu kehitysprosessi Suunnittelu Rajapintojen määrittely 2 25 Pääsytuntumattomuus Asiakastyngällä on samat operaatiot kuin palvelinoliolla. Näinollen asiakas voi kutsua paikallisesti asiastynkää tai 2 26 Palvelintynkien generointi Palvelimen toteutus Palvelimen rekisteröinti Asiakastynkien generointi Asiakkaan toteutus kutsua paikallisesti suoraan palvelinoliota kutsua muuttamatta. Välikerros voi optimoida kommunikointia olemalla käyttämättä tynkää, jos asiakas ja palvelin ovat samalla koneella. 2 27 2 28 Paikkatuntumattomuus Palvelimen rekisteröinti Olion identiteetti Olioviitteet Asiakkaat tekevät pyyntöjä palvelinolioille, jotka tunnistetaan olioviitteillä. Palvelimen fyysistä sijaintia ei tarvitse tietää. Miten olioviite saadaan? Olioadapterin pitää pystyä paikallistamaan ja käynnistämään palvelinoliot. Palvelinoliot rekisteröidään jonkinlaiseen talletuspaikkaan. Rekisteröinti on välikerros- ja tuotekohtaista. Olioadapteri etsii oliota talletuspaikasta ennen aktivointia.
2 29 Sisältö 2 30 CORBA: yleisesittely CORBA CORBAn oliomalli CORBA IDL CORBA-arkkitehtuuri 2 31 2 32 Object Management Group (OMG) Yleishyödyllinen yhteisö, jonka päämaja on Yhdysvalloissa. Perustettu 1989. Yli 800 jäsentä (v. 2000). Tehtävänä kehittää ja tehdä tunnetuiksi oliokeskeisiä teollisuusstandardeja sovellusten yhteensovittamiseksi, esim. CORBA ODMG-93 UML CORBAn tavoitteet Hajautetut ja heterogeeniset etäkutsut käyttäjille ja ohjelmoijille tuntumattomasti. Uusien ja legacy-komponenttien integrointi. Avoin, ilmainen standardi. Laaja teollisuuden konsensus.
2 33 2 34 CORBA arkkitehtuuri Oliomalli ja rajapintamäärittely Application Objects Domain Interfaces Object Request Broker CORBAservices CORBA facilities Oliot Tyypit Moduulit Attribuutit Operaatiot Pyynnöt Poikkeukset Alityypit 2 35 2 36 OMG IDL Kieli, jolla voi ilmaista CORBAn oliomallin kaikki käsitteet. OMG/IDL on ohjelmointikieliriippumaton. perustuu paljolti C++:aan. ei ole ohjelmointikieli, vaan puhtaasti deklaratiivinen. Sidonnat moniin eri ohjelmointikieliin. CORBAn oliomalli: oliot Oliolla on tunniste, joka on yksikäsitteinen samassa ORBissa. Olioon voi olla monia viitteitä. Viitteet tukevat paikkatuntumattomuutta. Viitteet ovat säilyviä (persistent).
2 37 2 38 CORBAn oliomalli: tyypit CORBA: moduulit Rakennettuja tyyppejä Oliotyyppi typedef struct Osoite { string katuosoite; string postinumero; string postitoimipaikka; ; typedef sequence<osoite> Osoitelista; interface Postitoimisto {... ; Atomisia tyyppejä module People { typedef struct Address { string flat_number; string street; string postcode; string city; ;... ; People::Address 2 39 2 40 CORBA: attribuutit ja operaatiot CORBA: poikkeukset interface Tyontekija; typedef sequence<tyontekija> Tyontekijalista; interface Ryhma { readonly attribute string nimi; attribute Tyontekija paallikko; attribute Tyontekijalista jasenet; void maksapalkat(in Paivays p);... ; Yleiset poikkeukset (esim. verkko rikki, epäkelpo olioviite, muisti loppunut) Käyttäjän määrittelemät poikkeukset exception KassaTyhja { double vaje; ; interface Ryhma {... void maksapalkat(in Paivays p) raises(kassatyhja); ;
2 41 2 42 CORBA: perintä ja alityypit CORBA: arkkitehtuuri interface Yhteiso { readonly attribute string nimi; ; Asiakas Palvelinolion toteutus interface Yritys : Yhteiso { readonly attribute string lytunnus;... ; Dyn. kutsurajap. Asiakas tynkä ORB rajapinta ORBin ydin Toteutusranka Olio adapteri Yksi standardoitu rajapinta Yksi rajapinta / oliotyyppi Yksi rajapinta / olioadapteri ORB kohtainen rajapinta 2 43 2 44 Yksinkertainen CORBA esimerkki Syntyvät tiedostot Tehdään yksinkertainen kertoman laskeva palvelin CORBAlla ja C++:lla Kirjoitetaan tiedostoon kertoma.idl seuraava rajapinta: interface kertoma { long laske(in long n); ; Orbixin idl-kääntäjää käytetään seuraavasti: idl -base -poa kertoma.idl kertoma.hh: asiakastyngän otsikkotiedosto, tarvitaan myös palvelimessa kertomac.cxx: asiakastyngän toteutus kertomas.hh: palvelinrangan otsikkotiedosto kertomas.cxx: palvelinrangan toteutustiedosto
2 45 2 46 kertoma_impl.hh kertoma_impl.cxx #ifndef KERTOMA_IMPL_HH #define KERTOMA_IMPL_HH #include "kertomas.hh" using CORBA::Long; class kertoma_impl : public virtual POA_kertoma { public: virtual Long laske(long n) throw (CORBA::SystemException); ; #endif #include "kertoma_impl.hh" #include <iostream> using CORBA::Long; Long kertoma_impl::laske(long n) throw (CORBA::SystemException) { Long tulos = 1; for (Long i = 1; i <= n; ++i) { tulos *= i; return tulos; kertoma_server.cxx #include "kertoma_impl.hh" 2 47 kertoma_server.cxx (jatkoa) 2 48 #include <iostream> using std::cout; int main(int argc, char* argv[]) { try { // alustetaan ORB ja v litet n sille // mahdollisesti komentorivilt annetut // parametrit CORBA::ORB_var orb = CORBA::ORB_init(argc, argv); // Haetaan viite juuri-poa:aan CORBA::Object_var obj = orb->resolve_initial_references("rootpoa"); PortableServer::POA_var poa = PortableServer::POA::_narrow(obj); cerr << "Juuri-POA haettu" << endl; // Aktivoidaan POA:n hallinnoija PortableServer::POAManager_var mgr = poa->the_poamanager(); mgr->activate(); // Luodaan kertomaolio kertoma_impl kertoma_servant; // Kirjoitetaan merkkijonoksi muutettu // viite olioon stdoutiin. kertoma_var k = kertoma_servant._this(); CORBA::String_var str = orb->object_to_string(k); cout << str << endl; // Ruvetaan kuuntelemaan pyynt j orb->run(); catch (const CORBA::Exception&) { cerr << "K sittelem t n poikkeus" << endl; return 1; return 0;
kertoma_client.cxx #include <iostream> #include <strstream> #include "kertoma.hh" 2 49 kertoma_client.cxx (jatkoa) 2 50 using std::cout; using std::cerr; using CORBA::Long; int main(int argc, char* argv[]) { try { // Alustetaan ORB CORBA::ORB_var orb = CORBA::ORB_init(argc, argv); // Tarkistetaan komentoriviparametrit if (argc!= 3) { cerr << "K ytt : kertoma_client" << " IOR_merkkijonomuodossa luku" << endl; throw 0; // Muunnetaan parametrina saatu merkkijono // olioviitteeksi CORBA::Object_var obj = orb->string_to_object(argv[1]); if (CORBA::is_nil(obj)) { cerr << "Annettu olioviite on nil tai rikki" << endl; throw 0; // Muunnetaan viite oikean tyyppiseksi kertoma_var k = kertoma::_narrow(obj); if (CORBA::is_nil(k)) { cerr << "Parametri ei ole viite kertoma-olioon" << endl; throw 0; 2 51 2 52 kertoma_client.cxx (jatkoa) istrstream n_str(argv[2]); Long n; n_str >> n; cout << n << ":n kertoma on " << k->laske(n) << endl; catch (const CORBA::Exception&) { cerr << "K sittelem t n CORBA-poikkeus" << endl; return 1; catch (...) { return 1; return 0; Hajautetuista metaoliomalleista
2 53 2 54 Motivointia Hajautetut järjestelmät koostuvat useista komponenteista. Komponentit ovat heterogeenisia. Niiden täytyy kuitenkin toimia yhdessä. Komponenteille täytyy määritellä yhteinen malli, johon sisältyvät komponenttien tilat, komponenttien palvelut ja komponenttien väliset interaktiot. Oliokeskeinen lähestymistapa Komponentti = olio. Komponentin näkyvä tila = olion attribuutit. Komponentin palvelu = olion metodi. Komponenttien interaktio = metodikutsu. Komponentin palvelun epäonnistuminen = poikkeus. 2 55 2 56 Metaoliomalli Tasot ja metatasot Oliokeskeisiä ohjelmointikieliä on useita, ja niiden kaikkien metaoliomallit ovat hieman erilaiset. Hajautusvälikerroksen pitää määritellä metaoliomalli, joka yhdistää heterogeenisten komponenttien mallit. Seuraavassa määritellään lyhyesti metaoliomalli, jota tällä kurssilla käytetetään. Metaoliomalli Olioiden tyypit (luokat) Taso 2 Taso 1 Oliot Taso 0
Olio Oliolla on yksilöllinen tunniste. Samaan olioon voi olla useita (erilaisiakin) viitteitä. Oliolla on joukko attribuutteja, joiden nimet viittaavat arvoihin. Kaksi viitettä voi viitata esim. samaan olioon tai kahteen identtiseen olioon. Oliolla on joukko operaatioita, jotka määräävät yhdessä attribuuttien kanssa sen rajapinnan. Operaatiot voivat nostaa poikkeuksia. 2 57 Luokka Luokka on olion tyyppi. Attribuutit, operaatiot ja poikkeukset määritellään luokassa. 2 58 Attribuutit Attribuutilla on nimi ja tyyppi. Tyyppi voi olla oliotyyppi (luokka) tai muu tyyppi. Toiset oliot voivat lukea attribuutin arvon. 2 59 Attribuutti saattaa olla myös toisten olioiden muokattavissa. Attribuuttia vastaa yksi tai kaksi operaatiota (set/get). Attribuuttia ei välttämättä toteuteta suoraan jäsenmuuttujan avulla, mutta se on hyvin yleistä. Poikkeukset 2 60 Hajautetun järjestelmän palvelupyynnöt saattavat syystä tai toisesta epäonnistua. Poikkeusta käytetään välittämään tieto epäonnistumisesta ja sen syystä palvelupyynnön lähettäjälle. Operaation suorituksen epäonnistuminen voi johtua yleisestä (esim. verkko nurin) tai oliolle spesifisestä syystä (esim. virheellinen parametri).
2 61 2 62 Operaatiot Operaation signatuuri koostuu nimestä, luettelosta in-, out-, ja inout-parametreja, paluuarvon tyypistä, ja luettelosta poikkeuksia, jotka operaatio voi nostaa. Operaatiokutsut Asiakasolio voi pyytää operaation suorittamista palvelinoliolta. Operaatiokutsu ilmaistaan lähettämällä viesti palvelinoliolle. Palvelinolio nimetään olioviitteellä. Asiakkaan pitää käsitellä palvelimen mahdollisesti nostamat poikkeukset. 2 63 2 64 Perintä ja alityypitys Metaoliomalliin sisältyy perinnän käsite, joka muodostaa alityyppisuhteen. Alityyppi perii attribuutit, operaatiot ja poikkeukset isätyypiltään. Alityypit voivat määritellä uusia ominaisuuksia. Alityypit voivat uudelleenmääritellä vanhoja ominaisuuksia. Hajautettujen oliomallien suunnittelu
Hajautettujen ja paikallisten olioiden erot Viitteet Aktivointi/deaktivointi Siirtäminen Säilyvyys Kutsuviive Rinnakkaisuus Kommunikointi Tietoturva Jos ei ole tarkkana, menee helposti vipuun. 2 65 Olion elinkaari Tavallisen olio-ohjelmointikielen oliot ovat samassa (virtuaali)koneessa, samassa muistiavaruudessa. Hajautetut oliot saatetaan luoda eri koneilla. Hajautettu olio saatetaan kopioida tai siirtää toiselle koneelle. Automaattinen roskienkeruu hankalaa. Elinkaari tarvitsee siis erityishuomiota hajautettuja olioita suunniteltaessa. 2 66 Viitteet olioihin Tavallisessa olio-ohjelmointikielessä viitteet toteutetaan yleensä yksinkertaisesti osoittimilla muistipaikkoihin. Joissakin kielissä osoittimet näkyvät suoraan ohjelmoijalle (C++), toisissa eivät (Smalltalk, Java). Viitteet hajautettuihin olioihin ovat ongelmallisempia Sijaintitieto Tietoturva Viitteet olioiden tyyppeihin (eli luokkiin) Viitteet hajautettuihin olioihin vievät paikallisia viitteitä enemmän tilaa (Orbixissa 40 tavua, tyypillinen tavallinen osoitin 4 tai 8 tavua). 2 67 Kutsuviive Paikallisen metodikutsun viive on sadan nanosekunnin luokkaa (1 * 10-7 s) Etämetodikutsun viive on olosuhteista riippuen yleensä välillä 0,1...10 ms (0,1... 10 * 10-3 s). Ero on siis 1.000...100.000-kertainen! Hajautetun oliojärjestelmän partitiointi ja rajapinnat on suunniteltava siten, että olioiden palvelut suorittavat melko isoja kokonaisuuksia, eikä palveluita tarvitse pyytää kovin usein. 2 68
2 69 2 70 Esimerkki: peräkkäissäiliön läpikäynti Javassa Hajautetuissa olioissa Hajautetun oliomallin suunnittelu Kolme voimaa: Vector +size():int +elementat(i:int):object... List +long list (in how_many:long, out l:sequence<object>, out bi:iterator i) Iterator binding iterator +next_one(out o:object): boolean +next_n(in how_many:long, out l:sequence<object>):boolean Partitiointi Rajapintasuunnittelu Rakeisuus Partitiointi 2 71 Partitiointi koostuu niistä päätöksistä, jotka tehdään jaettaessa järjestelmän toiminnallisuutta alijärjestelmiin ja edelleen sijoiteltaessa syntyneitä alijärjestelmiä fyysisiin paikkoihinsa (tässä tapauksessa hajautettuja olioita eri koneille). Osa päätöksistä on pakotettuja toiminnallisten vaatimusten vuoksi. Toiset päätökset tehdään luovemmin eitoiminnallisten vaatimusten ja yleisten tavoiteltavina pidettävien seikkojen ohjaamina. Suorituskyky, laajennettavuus, kustannukset... Rajapintasuunnittelu Tavoitteena koheesion maksimointi Rajapinnan tulisi edustaa hyvin määriteltyä abstraktiota, ja sen kaikkien elementtien tulisi liittyä tuohon abstraktioon. Metodin tulisi tehdä yksi, koherentti tehtävä. Alijärjestelmä on kohesiivinen, jos sen rajapinnat ovat kohesiivisia ja tukevat alijärjestelmän edustamaa oliokeskeistä abstraktiota. 2 72
Rajapintasuunnittelu (jatkoa) Kytkentöjen (coupling) minimointi 2 73 Implisiittinen kytkentä 2 74 Kytkentä on mitta alijärjestelmien välisten riippuvuuksien vahvuudelle. Kytkennät pitäisi minimoida. Ei kytkentää (nil coupling) interface SomeObject { any do_it(in string method, in string arguments); ; Julkinen kytkentä (export coupling) Luokka riippuu vain toisen julkisesta rajapinnasta. Avoin kytkentä (overt coupling) Luokka riippuu luvallisesti toisen toteutusyksityiskohdista. Salakytkentä (covert coupling) Luokka riippuu ilman lupaa toisen toteutuksesta. Rakeisuus (granularity) 2 75 Dokumenttien noutaminen Document 2 76 Rakeisuus kuinka hienojakoinen tai karkea oliomalli on. Hienojakoisessa mallissa on paljon pieniä olioita ja pieniä tehtäviä tekeviä metodeja. Karkeassa mallissa on olioita, jotka edustavat suuria käsitteitä tai kokonaisuuksia. Hienojakoisessa mallissa enemmän kytkentöjä. Hajautetuissa järjestelmissä kovin hienojakoinen malli laskee todennäköisesti suorituskykyä. Karkeassa mallissa usein huono koheesio. Löydettävä sopiva kompromissi. -nbrchapters: long +addchapter(in posn: long, in Chapter chap) +getchapter(in long posn) : return Chapter Chapter -nbrparagraphs : long +addparagraph(in posn: long, in Paragraph para) +getparagraph(in long posn) : return Paragraph Paragraph -nbrsentences : long +addsentence(in posn: long, in Sentence sent) +getsentence(in long posn) : return Sentence <<seq>> Sentence String
2 77 2 78 Viestisekvenssikaavio edellisestä Parempi oliomalli :Client :Document :Chapter :Paragraph nbrchapters getchapter() nbrparagraphs() getparagraph() nbrsentences() getsentence() getsentence() getsentence() getparagraph()... Koko dokumentin läpikäyminen vaatii tolkuttoman määrän etämetodikutsuja Huono malli! ContentProvider +getcontent() : return Content Document -issection : boolean +getsubdocuments() : return Documents +getsecnames() : return SectionNames +getsec(in name : String) : return Document <<struct>> Content format: String data: <<any>> <<seq>> SectionNames String <<seq>> Documents Document