Monday, May 17, 2010

Malleja; mitä miten miksi ja milloiin

Oliomalli on tehokkain ja tuottavin tunnetuista sovelluskehitykseen käytetyistä malleista nyt ja näköpiirissä olevassa tulevaisuudessa. kts:http://fi.wikipedia.org/wiki/Oliomalli


Käsitteet malli ja mallinnus.

Malli on ihmistä (siis meidän rajoittunutta tietokapasiteettia varten) tehty pelkistys valitusta osasta todellisuutta. Tässä on siis kaksi avainsanaa 1) pelkisty (hienommin abstraktio) ja todellisuus.

Ensimmäinen ”mallinnuksen” sekaannus yleisessä kielenkäytössä näyttää liittyvän heti tähän käsitteeseen ”malli”. Aloittakaamme siitä mitä malli ei ole. Matemaattinen yhtälö tai yhtälöryhmä olipa siinä mitä tahansa matemaattisia elementtejä ei sellaisenaan koskaan voi olla malli. Yhtä vähän kielen kielioppi voi olla malli. Malli siis on joillakin sovituilla säännöillä tehty pelkisty –siis yksinkertaistus todellisuuden osasta.

Nämä pelkistyksen säännöt ovat siis mallin rakennuselementtejä eivätkä ne ole malli. Tällainen sääntö saattaa sisältää esim. matemaattisen yhtälön, mutta tulkita on yhtä kuin malli. Seuraava on yhtälö: v*t=s.

Tämä yhtälö voi toimia keskinopeuden mallina. Tästä tekee mallin seuraava toteamus: Yhtälössä s edustaa matkaa, t edustaa aikaa ja v keskinopeutta. Näin meillä on keskinopeuden pelkistyksen malli.

Liikkuvan kappaleen keskinopeus annettuna aikana on hyvin korkean tason abstraktio. Se siis selittää koko todellisuuden tapahtumasta erinomaisen vähän.

Koko tämä tematiikka on käsitelty laajasti ja ehkä parhaana yhteenvetona tästä aiheesta kehottaisin itse kutakin kääntymään Ludwig Wittgensteinin puoleen ja lukemaan: Tractatus logico-philosophicus

http://fi.wikipedia.org/wiki/Tractatus_logico-philosophicus

(Logisch-philosophische Abhandlung, 1921).

Hän käyttää esimerkkinä mittanauhaa ja toteaa, että mittanauhalla ei ole semanttista sisältöä. Se on sopimus tai sääntö – siis eräänlainen ymmärtämisen rakenne. Malliksi se muuttuu kun mittanauhan reuna koskettaa todellisuutta ja kertoo kappaleen pelkistyksen –siis sen mitan annettuun suuntaan.

Sovelluskehityksen mallit

Puhun operatiivisista ohjausjärjestelmistä. Tähän tarvitaan malleja, joiden avulla ohjaus onnistuu. Tällaisia malleja voisi kutsua simulaatiomalleiksi. Siis malli on laadittu niin, että se matkii todellisuutta mahdollisimman tarkasti. Kun todellisuudessa sattuu ilmiö, joka muuttaa kohdetodellisuutta, niin tätä vastaava muutos toteutuu mallissa kyseisen käynnistysilmiön vastineella.

Huonoja ja hyviä malleja

Yleistäen voi sanoa, että mitä yksinkertaisempi mallin laatimisen säännöstö on sitä pelkistetymmän (abstraktimman) osan todellisuudesta saa.

Yksinkertaiset aikamallit

Nämä mallit esiintyvät monilla nimillä: prosessimalli, aktiviteettikaavio, vuokavio käyttötapaus vain muutaman mainitakseni. Mallinnuksen ainoa rakennesääntö on määritä tapahtumia ja osoita tapahtumien välinen aikajärjestys. Sääntö on niin yksinkertainen että sitä on lähes mahdoton rikkoa! Niinpä mallien sisällöt voivat olla melkeinpä mitä tahansa! Näin malli siis selittään tapahtumien jonkinlaisen ajallisen peräkkäisyyden ja kaikki muu onkin sitten sattumaa.

Kaksi mallia

Tätä mallinnusta on terästetty tekemällä toinen tästä mallista riippumaton rakennemalli, kuten ER-malli. Kahden mallin lähestymisessä on seuraava pulma: malli selittää toiminnan ja rakenteen, mutta näiden mallien vuorovaikutus –siis yhtyeenliittäminen - käy mallien kasvaessa hyvin nopeasti mahdottomaksi.

Oliomalli

Oliomalli on edellisen mallityypin jalostunut muoto (ja muuten kehitettiin juuri eo. ongelman ratkaisemiseksi). Tässä mallissa lähdetään hyvin todellisuusvetoisesti ja todetaan, että todellisuus koostuu hyvin itsenäisistä agenteista (mallissa olioista) näiden keskinäisistä riippuvuuksista ja vuorovaikutuksista. Näin tässä yhdistetään orgaanisesti edellisen kahden mallin tapaukseen verrattuna sekä rakenne että toiminta nyt yhteen malliin. Kun sovelluksen toteutukseen käytetään loogista 3-kerrosjakoa ja toteutus tapahtuu oliokielellä, ollaan tämän hetken tietämyksen kompleksisuusminimissä. Tällä hetkellä voin osoittaa väitteen todeksi Stuart Kauffmania mukaillen.

Tämä on juuri mallilähtöistä sovelluskehitystä. Tähän liittyy ketterä inkrementaalisuus ja generointi luontevina jatkeina.

XLM ei todellakaan riitä simulaationmallien säännöksi, ellei sitten simuloida pelkästään hierarkiarakenteita. Mallit ovat silloin kaikki organisaatiokaavioita ja toiminnallisuutta mallilla ei ole ollenkaan!
En myöskään ymmärrä mitenkään mitä tarkoitetaan ”semanttisilla” malleilla. Kuten olen kuvannut muunlaisia todellisuuden malleja EI VOI olla olemassa. Ainoastaan jotain todellista voi yksinkertaistaa!

Tästä syystä aikoikaan perustin OlioOSY:n. Jäin ajatuksineni vähemmistöön ja sitten ehdotin ”nimenmuutosta” MallinnusOSYyn. Minulle koko ajan nämä kaksi ovat käytännössä sama asia.


ja blogini: http://jukkatamminen.wordpress.com/

Oliomalli on ominaisuuksiensa takia kompleksisuusminimissä.

Tuesday, August 08, 2006

SOA: Two steps backwards in history

Still I am really sad because the object oriented knowledge so vital and flourishing during 1990’s have almost totally disappeared. I used to think that abstract domain modelling is pretty simple thing to do, but gradually I have been forced be concrete experience change my mind. Perhaps abstraction as a whole is very hard for majority of people.

As Grady Booch write in his book Object Oriented Design ( from page 15) about the limitations of human capacity to understand complex system, he describes the difference of functional decomposition and object oriented analysis and comes to the only obvious conclusion: the outcome of OO-analysis is at least one magnitude more simple that the corresponding functional decomposition, when we model behaviour. The reason is our general way of understanding reality. We comprehend our environment as collections of collaborative agents. That is our most natural way of understanding world. Our concepts (the whole natural language) i.e. words are merely abstraction of those agents. When we still deliberately add the level of abstraction and distribute the needed pieces of behaviour very evenly indeed for all the entities like events or otherwise static object we will end up creating a model with absolute minimum complexity from our perception perspective. The nature of each agent (here each domain class) will naturally limit the set of all possible action to very small number.

Functional decomposition is not supported with any structural elements at all and thus will eventually end up with completely arbitrary break down. When the steps in the total behaviour is increased the complexity of the arbitrary break down will explode!

In SOA the whole idea on simulation model has been abandoned. These people have returned 15 years back in history to times of structured programming! We (read ole dinosaurs) struggled in that swamp tens of year and at least I feel no need to return there any more !