Keskustelu: Yleinen keskustelu: UML/luokkakaavio ja luokkien "rajaaminen"

Moi

Jos pitäisi mallintaa vaikka ajokortti, niin miten sitä kannattaisi lähteä mallintamaan?
Tai vaikkapa sopimusehdot, jotka ovat pääasiassa kaikille samanlaiset, mutta jotka kostuvat yhdestä tai useammasta lausekkeesta, joita voi räätälöidä ennalta annettujen arvojen avulla(viittauksia toisten luokkien instansseihin).

Ja jos nämä kaksi esimerkkiä yhdistää teoreettisesti yhteen eli ajokortti perustuisikin noihin sopimusehtoihin.
Loppukäyttäjä voi valita sopimusehtoihin esim. ajoneuvoluokkia ja näille vaihtelevat voimassaoloajat.

Äkkiseltä kuulostaa melko yksinkertaiselta, mutta kun aloin tuota piirteleen, niin boom.
Luvanhaltija, ajoneuvotyypit, ajoneuvoluokat, ajokortti, sopimusehdot, sopimuslausekkeet jne.
Soppaan voisi vielä lisätä luvanmyöntäjän, toimihenkilöt, roolit, roolioikeudet.

Jonkin verran ehdin googlettamaan ja melko monenlaisia lähestymistapoja löytyy. Hukkasin vain sen saitin, jossa näitä oli lueteltu.
Erilaisten periaatteiden ja erityisesti SRP tuottaa ongelmia eli miten pieniin osiin tuo tosiaan kannattaa pilkkoa.

Ja joo, on varmasti epäspesifi määrittely ja avaus, mutta koitetaan nyt jotain rakentaa tästä.

Tärkeintä suunnitelmassa on miettiä, mitä on tarkoitus tehdä. Edellä kuvaamallasi tehtävänannolla ei kannata mallintaa yhtäkään luokkaa, koska niille ei ole mitään käyttöä. Ongelmia pitää osata rajata, koska muutenhan voit mallintaa ajokortista alkaen koko maailman aina jokaisen auton rengaspainesuosituksiin ja tehdastyöntekijöiden sukuluetteloihin asti.

Yleisiä suuntaviivoja:

Erillinen luokka kannattaa tehdä tiedosta, johon pitää viitata monesta lähteestä. Esimerkiksi henkilön kuva voi olla sama passissa ja ajokortissa, joten siitä voi tehdä oman luokan. (Toisaalta ehkä painolaatu on näissä olennaisesti erilainen, ja sen esittämiseksi pitääkin tehdä kuvasta erilaiset kappaleet molempiin?)

Kiinteästi yhteen kuuluvaa tietoa ei kannata erottaa useaksi eri luokaksi. Esimerkiksi ajokorttiin on fyysisesti painettu henkilön nimi, joka ei automaattisesti muutu nimenmuutoksen yhteydessä, joten se pitää myös tietokannassa tallentaa ajokortin yhteyteen. Painettu nimi voi toki olla sama monessakin asiakirjassa, joten teoriassa siitä voi tehdä erillisen luokan, mutta näin lyhyen tiedon kohdalla se olisi mielestäni yliampuvaa enkä näe siitä olennaista hyötyä.

Melko iso ja epäolennainen tieto kannattaa joskus erottaa suorituskyvyn vuoksi. On tehokkaampaa käsitellä vaikka listaa kirjoista, kun mukana ei liiku jokaisen kirjan kaikki teksti.

Ajokorttiin liittyviä ajatuksia:

Ajokortti on fyysinen esine, joten sen kohdalla on olennaista, että tekstit (mm. luvanhaltijan nimi) liityvät suoraan ajokorttiin. Tämä johtuu siitä, että ajokortti ei automaattisesti uudistu, vaikka esimerkiksi henkilön nimi vaihtuisi tai poliisilaitosten organisaatio muuttuisi.

Luvanhaltija yksilöidään ajokortissa olevalla henkilötunnuksella. Jos ei ole tarvetta käsitellä luvanhaltijoita järjestelmässä sen enempää, ei tarvitse tehdä erillistä luokkaa.

Ajokortissa on kuva ja nimikirjoitus. Nämä voivat olla samat kuin muissa asiakirjoissa, joten nämä varmastikin ovat erillisinä luokkina, joihin on suorat viittaukset ajokortista. (Viittaus ei voi mennä luvanhaltijan kautta, koska ajokortti ei muutu, vaikka luvanhaltija lähettäisi poliisille uuden kuvan.)

Ajoneuvoluokkia on rajallisesti ja ne eivät saman ajokortin aikana voi muuttua, joten ne voisi laittaa ajokorttiin suoraan. Toisaalta ne voi tallentaa myös yksitellen.

Ainakaan omasta ajokortistani ei löydy suoraa linkkiä mihinkään sopimusehtoihin tai toimihenkilöön tms., joten sellaisten mallintaminen ei kuulu ajokortin yhteyteen. Jos halutaan mallintaa koko prosessia, varmaankin tulisi luokka ajokorttitilaukselle, josta olisi sitten viittaus tilauksen tuloksena tuotettuun ajokorttiin.

Toimihenkilöt, roolit ja oikeudet ovatkin sitten monimutkainen kokonaisuus. Kannattaa muistaa sielläkin, että tiedoilla pitää olla aikaleima. Jokin käyttöoikeus voi jollain hetkellä olla voimassa ja toisella hetkellä ei. Jos tätä halutaan tarkasti seurata tietokannassa, täytyy tallentaa oikeuksien voimassaoloajat ja toimenpiteiden tapahtuma-ajat, jotta voidaan tarkastaa tietyn toimenpiteen luvallisuus kyseisellä hetkellä myös jälkikäteen.

Ajokortti oli hieman huono eli se 1. ajatus, joka tuli mieleen.
Parempi voisi olla vaikka oma paikallisliikenteen matkustajakortti tai muu vastaava, jonka tiedot elävät huomattavasti useammin kuin ajokortin.
Tai jokin kulkukortti, johon asetetaan voimassaoloaika kohteittain. Lisäksi voidaan asettaa esim. yleiskulkulupa, johon sisällytetty jotain kohteita ja voimassaoloaikoja.

Metabolix kirjoitti:

Erillinen luokka kannattaa tehdä tiedosta, johon pitää viitata monesta lähteestä.

Tuo oli kuitenkin hyvä pointti, että mikäli tietoihin viitataan useasta eri paikasta, niin silloin kannattaa tehdä luokka.

Metabolix kirjoitti:

Kiinteästi yhteen kuuluvaa tietoa ei kannata erottaa useaksi eri luokaksi.

mutta tämän kohdalla jäin hieman miettimään kompositiota ja aggregaatiota?

Sain toisaalta vinkin, ettei kannata tehdä kovin yksityiskohtaisia luokkia.
Jäin kuitenkin ilman perusteluita eli en tullut juurikaan viisaammaksi.

Kuten huomaat, muutamalla säännöllä ei saa täysin yksiselitteistä ja kattavaa ohjeistusta.

Multibyte kirjoitti:

Metabolix kirjoitti:

Kiinteästi yhteen kuuluvaa tietoa ei kannata erottaa useaksi eri luokaksi.

mutta tämän kohdalla jäin hieman miettimään kompositiota ja aggregaatiota?

Kompositio (eli yhden luokan käyttäminen osana toista luokkaa) tarkoittaa yleensä sitä, että luokat eivät liity kiinteästi yhteen vaan ainakin jotkin luokat ovat käyttökelpoisia myös muissa yhteyksissä. Jos luokka on ylipäänsä kohtuullisen kokoinen, ei ole hyödyllistä jakaa sitä osiin (ja tuottaa toivottua tulosta yhdistelemällä osia) vain jakamisen takia, jos pienemmille luokille ei ole mitään itsenäistä käyttöä.

Esimerkiksi henkilön koko nimi on yleensä järkevää sijoittaa samaan luokkaan, koska se on selvästi yhtenäinen asia ja etunimen ja sukunimen erottamisesta omiin luokkiinsa ei ole hyötyä. Ajokortissa oleva valokuva taas voi olla oma luokkansa, koska sille on muitakin käyttökohteita (kuten passi tai henkilökortti), ja ajokorttiin sitten sisältyy muiden tietojen ohella yksi kuva, koska kuva on kuitenkin välttämätön osa ajokorttia. Tässä on kyse kompositiosta.

Aggregaatiossa (erään määritelmän mukaan) osat eivät ole pakollisia tai niitä voi olla vaihteleva määrä. Esimerkiksi autossa voi olla kuljettaja (0–1 kpl yleensä) ja matkustajia (0–N kpl), mutta auto voi olla myös tyhjä. Mielestäni tämä on varsin selvä tilanne luokkasuunnittelun kannalta, koska auto ja kuljettaja ovat kaiken järjen mukaan erilliset.

Multibyte kirjoitti:

Sain toisaalta vinkin, ettei kannata tehdä kovin yksityiskohtaisia luokkia.

Vaikea sanoa, mihin vinkki on viitannut. Ehkä siihen, että yleensä ei kannata tehdä erillisiä luokkia mopokortille ja kuorma-autokortille (eikä periyttää näitä yleisestä ajokortista), jos ne ovat lähes samanlaiset ja melko helposti voi tehdä yhden yhteisen luokan, joka kattaa kaikki tilanteet.

Mites sitten sovelluksen ja sen osien kuvaus palveluina?
Googlesta oli varsin vaikea löytää mitään tästä aiheesta.
En kyllä tiedä varmaksi, että mitä nimea se tottelee.

Multibyte kirjoitti:

Mites sitten sovelluksen ja sen osien kuvaus palveluina?

Niin mitä siitä?

Ole kiltti ja kirjoita yhtenäiset tekstikappaleet yhteen ilman ylimääräisiä rivinvaihtoja. Virkkeet erottuvat jo alkukirjainten ja välimerkkien perusteella, joten ei tarvitse käyttää rivinvaihtoa jokaisen virkkeen jälkeen. Tarpeettomasti monelle riville katkottu teksti näyttää aivan pöljältä.