Oliomalli
Oliomalli on kohdealueen (problem domain) olio-ohjelmoinnin paradigmaan pohjautuva abstraktio, joka on olioanalyysin lopputulos (OOA Object-Oriented Analysis) Oliomallinnus syntyi olio-ohjelmoinnin pohjalta 1980- ja 1990-luvun vaihteessa (kts kirjallisuusluettelo). Olio-ohjelmoinnin yhteydessä olio on teknisesti määritelty kielen ominaisuus.
Olio on tässä merkityksessä alun perin syntynyt olio-ohjelmoinnin yhteyteen. Mallinnuksen yhteydessä tätä määritelmää voidaan pelkistää (abstrahoida). Voimmekin sanoa että mallin olio on mikä tahansa todellisuuden osa, joka on itsenäinen kokonaisuus ja jolla on näin ollen "identiteetti". Tästä seuraa, että oliot ovat ainutkertaisia ja niillä kaikilla on elinkaari. Oliolla on siis kunkin elämänsä hetkenä "sisäinen tila". Tämä tila ilmenee olion ominaisuuksien arvoina. Ottakaamme esimerkiksi olion Kalle Kehveli. Tämän sisäistä tilaa kuvaavat monet ominaisuudet kuten esimerkiksi: pituus, paino, tukan väri, käden pituus, mielentila, verenpaine ja insuliinin määrä veressä. Tällaisia ominaisuuksia eivät kuitenkaan ole suhteet muihin olioihin, kuten koiraan, autoon, vaimoon, lapsiin työhön jne. Nämä ovat olioiden välisiä suhteita (eng. association). Tämä määrää olion pysyvän rakenteen.
Konkreettiset asiat kuten: henkilö, kauppakirja, auto, koira tai lentokone, ovat helppoja mieltää olioiksi. Olioanalyysin kannalta erityisen tärkeitä olioita ovat myös tapahtumat kuten: kokous, työmatka, lento tai häätilaisuus.
Tämän rakenteen rinnalla yhtä tärkeässä asemassa ovat "olion palvelut". Nämä ovat asioita joita "olio osaa" tehdä. Ensimmäinen ja tavallaan alkeellisin palvelu, jonka olio osaa, on kertoa ja asettaa oman sisäisen tilansa. Tämä on muuten aina tapa, jolla olion ulkoinen todellisuus saa tästä tilasta tietää. Näiden lisäksi kaikki oliot osaavat niille luonteenomaisia asioita. Esimerkiksi Kalle Kehveli osaa puhua ja lukea suomen kielellä, syödä, soittaa puhelimella, pelata golfia, katsoa elokuvaa. Todellinen kirjaolio kuten kädessäni oleva Sinuhe Egyptiläinen ( Mika Waltarin romaani) ei itse asiassa osaa mitään. Vastaavasti tekemäni työmatka olio ei myöskään todellisuudessa osaa mitään.
Oliomalli koostuu luokista. Luokka on mallintajan mekanismi ryhmitellä todellisuuden tarkastelukulman mukaan riittävän samankaltaisia olioita ryhmiksi. Tämä ryhmittely on läheistä sukua uusien sanojen muodostumiselle kieleen. Tämä on mallinnuksen ratkaiseva vaihe. Tässä vaiheessa päätetään miten paljon malli pelkistää todellisuuden monimutkaisuutta. Luokkaa määritettäessä tunnistetaan myös luokan palvelut. 
Tässä vaiheessa siis luokalle nimetään ne ominaisuustyypit, joita olioilta edellytetään, jotta ne kuuluvat luokaan. Menetelmällä ei voi sulkea pois ominaisuuksia. Vastaavasti nimetään palvelut, joita luokan oliot osaavat. Tämä on vaihe, jossa mallintaja synnyttää todellisuutta kuvaavan abstraktion. Tämän abstraktion tulee olla pelkistys, joka helpottaa ymmärtämään ja kuvaamaan kohdetodellisuutta. Tehtävä maailman pysyvien rakenteiden osalta on jokseenkin helppo ja suoraviivainen, mutta palvelujen kohdalla tilanne on huomattavasti mutkikkaampi. On nimittäin kiistatta todettu, että malli yksinkertaistuu ja selkeytyy, kun toiminnot sijoitetaan todellisuuden vastaisesti mahdollisimman lähelle niitä rakenteita, joita ne käsittelevät. Tärkeää on kuitenkin löytää mallin tulevan käyttötarkoituksen kannalta oleelliset luokat ominaisuuksineen ja palveluineen.
Näin mallin kirjaoliolla on palvelu kerroSivumäärä tai vaikkapa lueKappale! Jos taas tarkastelukulma on kokoonpano –esim. kännykän, niin kännykkä ja sen komponentit osaavat koota itsensä. Ehkä kaikkein yllättävimmät abstraktit osaamiset liittyvät kuitenkin tapahtumaolioihin. Näiden kohdalla voidaan tavallaan puhua ”yliolioista” , sillä nämä abstraktit oliot osaavat enemmän kuin niiden todellisuusvastineet! Kun siis toiminta sijoitetaan tällaisessa mallissa jollekin luokalle, puhutaan myös vastuun jaosta. Tyypillisesti tapahtumaluokalla –ja sitä myötä siis tapahtumaolioille – määritellään palveluita. Ottakaamme muutama esimerkki. Tapahtumaolioilla on aina alku- ja loppuaika jotka joissain tapauksissa ovat degeneroituneet ajankohdaksi. Tähän aikaan liittyvät osaamiset ovat tietenkin luonnollisesti tapahtumaolio palveluja. Tällaisia ovat esimerkiksi tapahtuman kesto. Tapahtumaan liittyviin ominaisuuksiin liittyy palveluita. Esimerkiksi lento-oliolla tai autoon liittyvällä matkaoliolla tyypillisesti on seuraavia palveluita: polttoainekulutus; keskikulutus. Vastaavasti näihin tapahtumiin voi liittyä osallistujiin liittyviä palveluita kuten esimerkiksi: kerroMatkustajamäärä tai kerroMatkustajat
Mallin abstraktiotaso määräytyy valittujen luokkien abstraktiotasoista. Luokan abstraktiotaso määräytyy sen mukaan kuinka paljon toisistaan eroavia todellisia olioita luokkaan kuuluu. Mitä suurempia ovat olioiden mahdolliset erot, sitä korkeampi on abstraktiotaso. Mallissa tämä näkyy olion ominaisuuksien lukumääränä. Korkealla abstraktiotasolla ominaisuuksia on vähän ja vastaavasti matalalla paljon. 
Jos luokat määritellään kovin alhaiselle abstraktiotasolle, malli vastaa erityisen hyvin maailmaa ja sen käsitteellistä monimuotoisuutta, mutta mallin luokkien määrä kasvaa liian suureksi ja koko mallin yksinkertaistava ja selkeyttävä tavoite vaarantuu. Jos taas luokat määritellään liian yleisiksi, niiden semanttinen sisältö kutistuu. Näin saadaan hyvin laaja yleinen ja ymmärrettävä malli, joka vaan ei kerro juuri mitään kohdealueesta. Aloittavat mallintajat sortuvat helposti jälkimmäiseen. Luokkien huolellinen nimeäminen on äärimmäisen tärkeätä. Kun kielen sanat muodostavat todellisten olioiden sumeita joukkoja, luokkaa määriteltäessä tämän mallintaja eliminoin sumeuden poimimalla mukaan vain näkökulman välttämättömät piirteet ja jättämällä kaiken muun monimuotoisuuden luokan ulkopuolelle.
Ohjelmoinnin olio ja analyysin mallin olio ovat periaatteessa sama asia, mutta kun tarkastellaan analyysin oliota Kalle Kehveli, on tämä kokonainen henkilö kaikkine ominaisuuksineen ja piirteineen, mutta häntä tarkastellaan olioviitekehyksessä. Olio-ohjelmointikielen (kuten Javan) vastaava Kalle Kehveli olio on sen sijaan tuotettu Henkilö luokasta ja tämä todellisen henkilön vastinpari ohjelmassa on siis läpikäynyt mallintajan pelkistyksen ja on näin ollen abstrahoitu Kalle Kehveli.
Luokista muodostetaan sitten kaavio nykyään useimmiten UML- (Unified Modeling Language) standardin mukaan. Luokkakaavio (class diagarm) kostuu luokista ja näiden välisistä yhteyksistä. yhteyksiä on kolmenlaisia:
1. olioiden välinen yhteys
2. kokoomarakenne
3. yleistys/erikoistus rakenne (periytyvyys)
Näistä ylivoimaisesti tärkein on olioiden välinen yhteys. Nämä olioiden väliset yhteydet antavat maailmalle sen muodon ja rakenteen. Nämä yhteydet piirretään kuitenkin luokkakaavioon – tämä on muodollisesti epäjohdonmukaista. Luokkakaaviossa siis piirtämällä yhteyksiä näytetään olioiden pysyväisluonteisia siteitä muihin olioihin. Jotkut teoreetikot (Lähde kiitos!) ehdottavat, että kaikkien niiden luokkien välille merkitään yhteys, joiden välillä kulkee viesti. Mielestäni (Kenen mielestä?) tämä on tarpeetonta ja ainoastaan haittaa mallin lukemista. Tällaiselle yhteydelle voidaan antaa myös nimi, joka kertoo minkä on tämän yhteyden luonne.
Tässä yhteys on piirretty luokkakaavioon, mutta tällainen yhteys toteutuu ainoastaan luokista poimittujen olioiden välillä. Näin tarvitsemme henkilöolion Kalle Kehveli ja koiraolion Musti. Ja nyt voimme todeta, että Kallen ja Mustin välillä on olemassa omistaa yhteys.
Seuraava oliomallin yhteystyyppi on kokoomarakenne. Tämä yhteystyyppi on edellisen erikoinen tapaus. Tällä tyypillä voidaan osoittaa olion olevan toisen osa. Kaaviossa yhteysviivan kokonaisuutta edustavan luokan päässä on vinoneliö. Tämä voi olla joko täytetty kuten kuvan Henkilö esimerkissä. (eng. composition)
tai se voi olla tyhjä (eng. aggregation). Täysi neliö merkitsee voimakkaampaa sidontaa kuin tyhjä.
Viimeisenä ja analyysin kannalta vähäisimpänä on yleistys/erikoistus (periytyvyys). 
Tällä rakenteella voidaan kuvata käsitteiden hierarkioita. Tällä rakenteella voidaan luokkakaavioon tuoda useita tarkkenevia abstraktiotasoja samaan kaavioon.
Esimerkin kaaviossa on hyvin yleistä ajoneuvo käsitettä tarkennettu aliluokilla kuten auto ja polkupyörä. Tätä erikoistamista voidaan syventää niin syvälle kuin se on tarpeellista aina lisäämällä uusia aliluokkia. Tässä esimerkiksi polkupyörä on tarkennettu kilpa- ja retkipyöräksi.
Liiketoiminnan abstrakteissa malleissa koko rakenteella on hyvin vähän oikeaa käytännöllistä käyttöä.
Tässä siis kaikki luokat luokitellaan neljään kategoriaan:
Tämän luokan oliot ovat tarkastelunäkökulmassa ja aikaikkunassa pysyviä – siis olemassa ennen tarkastelun alkua ja jäävät olemaan sen loputtua. Tyypillisiä esimerkkejä kaikki todellisuuden konkreettisia asioita edustavat luokat kuten: Auto, Henkilö, Tuoli, Yritys jne.
Tämän luokan oliot antavat tyypillisesti jollekin pysyvän luokan oliolle roolin jossain tapahtumassa. Esimerkkejä: oikeudenkäynnissä on läsnä, joukko henkilöluokan oliota, joilla kuitenkin on eri roolit: syytetty, tuomari, asianajaja, syyttäjä, kantaja, todistaja jne.
Tämän luokan oliot ovat kuvauksia jostain muusta. Keittokirjan resepti on kuvaus ruokalajista, näytelmän käsikirjoitus on kuvaus näytelmätapahtumasta, nuotit on kuvaus musiikkiesityksestä.
Tämän luokan oliot ovat olioiksi muutettuja tapahtumia – siis ajanjaksoja joilla on alku tai loppu. Esimerkkejä: kokous, liikenneonnettomuus, reittilento, häät, juhla, verovuosi, mansikka-aika. Kaikilla tapahtumaluokan olioilla on siis aina kaksi attribuuttia: alkuaika ja loppuaika. (sovittaessa nämä voidaan jättää kirjaamatta, jolloin pelkän värin perusteella tämä tiedetään).
Pulmana näissä –kuten kaikessa abstraktioissa – on joidenkin tapausten kohdalla vaikeus päättää mihin kategoriaan se kuuluu. Silloin tulee vaan valita ”paras” kompromissi.
Kirja: Java Modeling In Color With UML: Enterprise Components and Process
Yhteistoimintakaaviot vastaavat pitkälti oliomaailmassa käyttötilanteen esimerkkiä (skenaariota). Yhteistoimintakaavio (collaboration diagram) koostuu siis oliota kuvaavista suorakaiteista. Kustakin kaavion oliosta ilmoitetaan se identiteetin lisäksi se luokka, johon olio kuuluu. Yhteistoimintakaavion tarkoituksena on kuvata olioiden viestinvaihtoon perustuva yhteistoiminta. Tässä UML2:ssa asia on ymmärretty väärin ja siellä puhutaan pelkästään vuorovaikutuksesta (communucation)! Kyseessä on kuitenkin siis aito yhteistyö, jonka avulla kaavion oliot yhdessä saavat aikaan halutun lopputuloksen. Kaaviossa esitetään olioiden toisilleen lähettämät viestit. Viestit numeroidaan, jotta niiden ajallinen lähettämisjärjestys (siis ajan kulku) näkyy kaaviossa. Kaavion tehtävä ei siis ole kuvata viestejä vaan epäsuorasti viestin avulla olioyhteisön toiminta –yhteistyö.
Teknisesti tällainen malli koostuu joukosta kaaviota. Yhdestä luokkamallista (joka pyritään piirtämään yhteen luokkakaavioon) ja 1 – 15 yhteistoimintakaaviosta, joissa esimerkein esitetään liiketoiminnan keskeisimmän ydintoiminnon abstraktisti.
Mallin keskeisin tavoite on antaa liiketoiminnan varsin abstrakti simulaatiomalli, joka selittää kohdealueen rakenteen ja toiminnan valitulla yksityiskohtaisuuden tasolla. Näin varmistutaan siitä, että mallin koko ja sen seurauksena kompleksisuus eivät kasva käyttökelvottomiksi vaan tätä kompleksisuutta hallitaan. "( kts. Stuart Kauffman:.”At home in the universe” ja NK-kompleksisuus)"
Luokkamalli antaa kohdetodellisuuden rakenteellisen kuvan, joissa kuitenkin tulee näkyä luokan keskeiset liiketoimintapalvelut. Nämä yhdistyvät yhteistoimintakaavioiden viesteihin. Näin oliomalli on aina kokonainen maailman simulaatiomalli ja kuvaa abstraktisti mutta täydellisesti koko kohdetodellisuuden (sekä rakenteen että toiminnan). Toisaalta olioparadigma on uloin ja kokonaisvaltainen lähestymistapa. Kun toiminta kuvataan olioiden välisenä yhteistoimintana, sitä oikeastaan voi (ainakaan tarvitse) kuvat enää millään muulla tavoin. Näin funktionaalinen dekompositio ja olioiden yhteistoiminta ovat toisensa poissulkevia esitystapoja. 
Liiketoimintamallien keskeisenä voimavarana on olioitetut tapahtumat (kts. ed. värikoodaus).Liiketoiminnan abstraktissa mallissa periytyvyydelle on harvoin oikeata käyttöä ja usein miten liiketoimintamallissa on tyypillisesti 0 – 3 käyttökelpoista periytyvyysrakennetta.