DIPLOMITYÖ
Teknillinen korkeakoulu Tietotekniikan osasto Ohjelmistotekniikka
Markku Hinkka
Modulaarinen sovelluskehitys oliopohjaisessa kehitysympäristössä
Valvoja: Professori Eljas Soisalon-Soininen, Informaatiotekniikan laboratorio, Teknillinen korkeakoulu
Ohjaaja: Diplomi-insinööri Teemu Lehto, QPR Software Oyj
Teknillinen korkeakoulu Diplomityön tiivistelmä Tekijä: Markku Hinkka
Työn nimi: Modulaarinen sovelluskehitys oliopohjaisessa kehitysympäristössä Päivämäärä: 16.8.2000 Sivumäärä: 99
Osasto:
Professuuri:
Tietotekniikan osasto
Tik-106, Tietojenkäsittelytekniikka (ohjelmistotekniikka) Valvoja:
Ohjaaja:
Professori Eljas Soisalon-Soininen Diplomi-insinööri Teemu Lehto
Tässä työssä suuni te Itiin ja kehitettiin oliopohjaiseen mallinnukseen perustuvan Must- sovelluskehittimen tukea monen kehittäjän rinnakkaiseen sovellusten kehittämiseen, sovellusmoduulien käyttöön, tekstimuotoiseen oliotietokannan käsittelyyn sekä versionhallintaan integrointiin. Työ pyrittiin tekemään siten, että esitetyt ratkaisuvaihtoehdot ja ratkaisut pidettiin mahdollisimman riippumattomana lopullisesta ratkaisun toteutusympäristöstä.
Työn alkuosa keskittyy aihepiiriin liittyvän teorian esittämiseen. Teoriaosassa käydään läpi olioteknologian perusteita, oliotietokantoja sekä määritellään työssä käytetyn oliotietokannan rakenne siten, että rakenteesta löytyy vastaavuudet mahdollisimman helposti mistä tahansa ODMG:n oliomallin mukaisesti toteutetusta oliotietokannasta, kuitenkaan jättämättä mitään Mustiin oliotietokannan työn kannalta oleellisia rakenteita huomiotta. Olioteknologian lisäksi teoriaosuudessa käsitellään tuotteenhallintaa etenkin versionhallinnan näkökulmasta, sekä rakenteellisen tiedoston analysointiin liittyvää teoriaa yhteysvapaista kieliopeista semantiikan analysointiin.
Teoriaosien lopuksi käsitellään työn kohdetta, eli Must-ohjelmistoa, sen historiaa, ominaisuuksia, käyttäjiä, kehitys- ja käyttöympäristöjä sekä vertaillaan sitä muihin vastaavankaltaisiin tuotteisiin.
Ongelmien ratkaisua lähdetään etsimään kiteyttämällä varsinainen ongelma neljään ratkaistavaan osaan: oliomallin moduuliin kuuluvan osan määrittely, moduulista luotavan siirtotiedoston rakenne, abstrakti syntaksi sekä moduulin lukeminen oikeaan paikkaan oliomallissa. Mahdollisina siirtotiedostoon kuvattujen moduulien kuvauskielinä tarkastellaan tarkemmin muunmuassa itse määriteltyä kuvauskieltä, Microsoft Visual Basic-ohjelmointikieltä sekä XML:a.
Must-ympäristöön parhaiksi ratkaisuiksi todetaan lopulta entiteetti-tasolla tapahtuva moduuliin kuuluvien rakenteiden määrittely, joka mahdollistaa muunmuassa helpon integroinnin Mustiin laskentasääntökieleen, nykyiseen Must Modeller- käyttöliittymään ja COM-rajapintaan. Toteutettavaksi kuvauskieleksi valitaan lopulta XML helpon laajennettavuuden, selkeän syntaksin, laajan ohjelmistotuen ja hyvän oliopohjaiseen kuvaukseen soveltuvuuden johdosta. Moduulien tietokantaan lataukselle päätettiin toteuttaa kaksi eri latausmenetelmää; korvaus ja lisäys, joista korvaus korvaa mallissa ennestään olevia rakenteita siirtotiedostoon kuvatun moduulin rakenteilla kun taas lisäys lisää uutta informaatiota oliomalliin poistamatta tai muuttamatta siellä jo ennestään olevaa informaatiota.
Avainsanat: oliopohjainen, oliomallinnus, oliotietokanta, modulaarisuus, moduuli, komponentti, C++, XML, versionhallinta, jäsennys, abstrakti syntaksi, tekstimuotoinen kuvauskieli____________
Helsinki University of Technology Abstract of the Master’s Thesis
Author: Markku Rinkka
Name of the thesis: Modular application development in an object-oriented development environment.
Date: 16.8.2000 Pages: 99
Department:
Professorship:
Department of Computer Science and Engineering Tik-106, Information Processing Science
(software engineering) Supervisor:
Instructor:
Professor Eljas Soisalon-Soininen M.Sc. Teemu Lehto
This thesis concentrates on developing better multi-user support, modular model design support, text based object database manipulation and version control system integration for Must-application development tool which is based on object-oriented modelling. The aim was to keep the alternative solutions as independent of the final implementation environment as possible.
The thesis begins with description of the overall theory of the subject area. In the theory section the description of the basics of the object technology and object databases is followed by the description of the simple object model used in the rest of the thesis. The described object model was designed to allow easy mappings from any object model based on the OMT to the described object model. Special care was taken not to leave any critical aspects of the Must’s object model out of the described object model. In addition to the object technology, the theory section covers product management with main focus on version control and the theory related to the analyzation of a structured information beginning from context-free grammars and ending with semantic analyzation. The final chapter of the theory section covers Must-application development tool, its history, features, users, development and working environments and comparisons with other similar products.
The search for the solutions for the presented problems begins with dividing problem into four smaller problems: Determining which part of the database belongs to the determined module, format of the export file generated from the module, abstract syntax used as an intermediate representation of the module and importing the module into the right location in the database. The examined potential export file formats include completely new file format, Microsoft Visual Basic and XML.
As the best solution to be implemented in the Must environment the module’s contents should be determined at the maximum of entity-level granularity, which enables easy integration with Must’s calculation engine, Must Modeller’s user interface and COM-interface. XML was selected as the format for export files because it is highly scalable, it has syntax that is simple and easy to leam, it is widely supported in other products and it is highly suitable for describing objects. Two distinctive methods were selected for importing modules from export file into Must’s object database: replace and add. Replacing replaces old version of the module being imported in the database whereas adding adds new module without modifying any old information stored into the database before the import operation.
Keywords: object-oriented, object-oriented modelling, object database, modularity, module, component, C++, XML, version control, parsing, abstract syntax, textual description language_______
Esipuhe
Tämä työ on tehty QPR Software Oyj:n Must Modeller-tuotekehitysprojektin sekä siihen osittain perustuvan SynerPlan-tuotekehitysprojektin puitteissa. Työn tavoitteena on kehittää Must Modeller-sovelluskehittimeen uusia ominaisuuksia, joiden pääasiallisena tavoitteena on helpottaa sovelluksen kehittämiseen liittyvän työn jakamista usean kehittäjän kesken sekä sovellusten ajoaikaista päivitettävyyttä.
Haluan kiittää QPR Software Oyj:tä opiskelija-ystävällisestä ilmapiiristä, diplomityö- aiheen tarjoamisesta sekä sen tekemisen rahoittamisesta. Teemu Lehtoa kiitän työn ohjaamisen lisäksi lukuisista diplomityöhön liittyvistä valaisevista keskusteluista ja kommenteista. Eljas Soisalon-Soinista haluan kiittää diplomityö-aiheen hyväksy
misestä, sekä opastuksesta diplomityön teossa.
Edellisten lisäksi haluan kiittää ystäviäni ja läheisiäni, erityisesti isääni ja äitiäni, joiden diplomityölle ja opiskelulleni antama tuki ja kärsivällisyys ovat olleet mittaamattoman arvokkaita.
Espoossa, 16. elokuuta 2000
Markku Rinkka
Sisällysluettelo
Sisällysluettelo
Kuvaluettelo...4
Taulukkoluettelo...4
1 Lyhenneluettelo...5
2 Johdanto...8
2.1 Diplomityön tavoite...8
2.2 Diplomityön rajaus...9
3 Olioteknologia...10
3.1 Olio-ajattelu... 10
3.2 Oliotietokannat... 11
3.2.1 Diplomityössä käytettävä oliomalli... 12
3.2.2 Mallinnusesimerkki... 14
3.3 Ohjelmamoduulit... 16
3.4 Moduulien uudelleenkäyttö... 18
4 Tuotteenhallinta...22
4.1 Käsitteet...22
4.2 Versionhallinta...23
4.3 Microsoft Visual SourceSafe...23
5 Rakenteellisen tiedoston analysointi...25
5.1 Yhteysvapaat kieliopit...25
5.2 BNF notaatio...25
5.3 Äärelliset automaatit...26
5.4 Säännölliset lausekkeet...26
5.5 Leksikaalinen analysointi...27
5.6 Syntaksin analysointi...28
5.7 Semantiikan analysointi...29
6 Must... 30
6.1 Historiaa... 30
6.2 Ohjelmointiympäristö... 31
6.3 Must Modeller... 31
6.4 Käyttöliittymä... 32
Sisällysluettelo
6.5 Tietokanta...32
6.6 Oliomalli...33
6.7 Laskentasääntökieli... 34
6.8 Laskentamoottori... 35
6.9 Käyttöympäristö... 36
6.10 Käyttäjät...37
6.11 Sovellusalueet...39
7 Tavoitteet...41
7.1 Oliomallin modulaarisuus...42
7.2 Oliomallin tekstimuotoinen käsittely... 43
7.3 Toteutusperiaatteet... 43
8 Ratkaisuvaihtoehdot...45
8.1 Oliomallin moduuliin kuuluvan osan selvittäminen... 46
8.1.1 Manuaalinen moduulin rakenteiden selvittäminen... 46
8.1.2 Täysautomaattinen moduulin rakenteiden selvittäminen... 47
8.1.3 Edellisten hybridi...47
8.1.4 Oliomalliin tallennettu moduulikuvaus... 50
8.2 Siirtotiedoston formaatti... 52
8.2.1 XML siirtotiedoston formaattina... 53
8.2.2 Visual Basic siirtotiedoston formaattina... 57
8.2.3 Itse määritelty siirtotiedoston formaatti... 58
8.3 Abstrakti syntaksi... 60
8.4 Moduulin lukeminen oliomalliin... 62
8.4.1 Yleistä...63
8.4.2 Moduulin korvaus... 63
8.4.3 Moduulin lisäys... 64
8.4.4 Moduulin sisäänlukujärjestys... 65
8.4.5 Käyttöliittymä moduulien sisäänlukuun... 66
9 Valitut ratkaisut...67
9.1 Moduulin lukeminen ja kirjoittaminen...67
9.2 Siirtotiedoston formaatti... 67
10 Ratkaisuiden toteutus Must ohjelmistoon... 68
10.1 Modulaarisuus...68
10.2 Siirtotiedoston luonti... 69
10.3 Jäsennys...70
10.4 Jatkokehityskohteita...71
10.4.1 Attribuuttien näkyvyys...71
10.4.2 Laskentasäännön sisäiset muuttujat... 71
10.4.3 Parametrien antaminen funktio-attribuuteille... 72
Sisällysluettelo
11 Yhteenveto...73
11.1 Teoria... 73
11.2 Ongelmat...74
11.3 Ratkaisuvaihtoehdot... 74
11.4 Ratkaisut...75
12 Lähdeluettelo...76
13 Tuoteinformaatio... 80
Kuvaluettelo
Kuvaluettelo
Kuva 1: Työssä käytetyn oliotietokannan rakenne UML-muodossa... 14
Kuva 2: Mallinnusesimerkin tietorakenne UML-notaatiolla esitettynä... 16
Kuva 3: Julkisivu-suunnittelurakenteen vaikutus luokkien välisiin viittauksiin... 18
Kuva 4: Uudelleenkäyttö tuotantoprosessissa... 19
Kuva 5: Esimerkki äärellisestä automaatista...26
Kuva 6: Must Modellerin arkkitehtuuri...32
Kuva 7: Kurssitietokannan UML-oliodiagrammi...45
Kuva 8: Esimerkki abstraktin syntaksipuun luokkahierarkiasta...61
Kuva 9: Esimerkki abstraktista syntaksipuusta...62
Kuva 10: XML-tiedoston luonnin välivaiheet...69
Kuva 11: XML-tiedoston sisäänluvun välivaiheet...70
Kuva A.l : Esimerkki UML-luokkadiagrammista... 83
Kuva A.2: Esimerkki UML-oliodiagrammista... 84
Kuva B.l: Pääikkuna, jossa on avattuna selain-näkymä oliomalliin... 86
Kuva B.2: Yksinkertainen taulukkonäkymä... 87
Taulukkoluettelo
Taulukko 1: Esimerkki leksikaalisesta analysoinnista...28Taulukko 2: Must:in oliotietokantatyyppien vertailu...33
Taulukko 3: Must:in ominaisuuksien saatavuus muissa ohjelmistoissa...40
Taulukko 4: Moduuliin automaattisesti kuuluvat rakenteet...47
Taulukko 5: Rakenteiden moduuliin siirtämisen lisäparametrit...48
Taulukko 6: Kuvauskielivaihtoehtojen vertailua... 53
Taulukko 7: Moduulin sisältämien rakenteiden siirtojärjestys oliotietokantaan...65
Taulukko A.l : UML-notaatiossa käytettävät kardinaliteetti-merkinnät...82
Taulukko B.l : Must Modellerin näkymiä oliomalliin...85
1. Lyhenneluettelo
1 Lyhenneluettelo
ANTLR
ANother Tool for Language Recognition [jGuru 2000]. Jäsenningeneraattori, joka tuottaa EBNF-tyyppisestä määrittelystä C++-luokkia, jotka toteuttavat EBNF-määrittelyssä määritellyn kieliopin mukaisen selaimen ja jäsentimen.
API
Application Programming Interface. Ohjelmointirajapinta.
ASP
Microsoft Active Server Pages. Microsoftiin Internet Information Server WWW-palvelimessa toimiva dynaamiseten ja interaktiivisten sovellusten kehitystekniikka.
C++
C-ohjelmointikielestä kehitetty olio-ohjelmointikieli.
COM
Component Object Model. Microsoftin kehittämä ohjelmointikieliriippumaton oliokomponenttimalli.
DBMS
DataBase Management System. Järjestelmä jonka välityksellä käytetään tietokantaa.
DDE
Dynamic Data Exchange. Microsoftin prosessien väliseen kommunikointiin kehitettämä protokolla.
DLL
Dynamic Load Library. Windows-ympäristössä käytetty dynaamisesti ohjelmaan linkitettävä funktiokirjasto.
DOM
Document Object Model. W3C:n määrittelemä ympäristö- ja laitteistoriippumaton rajapinta mm. XML dokumenttien käsittelyyn.
DTD
Document Type Declaration. Määrittelee XML-dokumentissa käytetyn kieliopin.
EBNF
Extended Backus-Naur Form. Kielioppien määrittelyssä yleisesti käytetty kieli.
HTTP
HyperText Transfer Protocol. Internetissä yleisesti käytetty tietoliikenneprotokolla.
1. Lyhenneluettelo
[DL
Interface Definition Language. Määrittelee hajautetun palvelun ominaisuudet yleisesti tunnettuja tietotyyppejä käyttäen.
LISP
LISt Processor. Lista-tietorakenteeseen perustuva ohjelmointikieli.
MFC
Microsoft Foundation Classes. Microsoftin Windows-käyttöjärjestelmän ohjelmointiin kehittämä C++-luokkakirjasto.
MOS
Must Object System. Must oliomallinnusytimen toteuttavan C++-kirjaston nimi.
MUST
MUlti-purpose System modelling Tool. Olioihin perustuva sovelluskehitysohjelmisto, jota diplomityössä pyritään kehittämään. Käytetään myös kirjoitusasua Must.
ODBC
Object DataBase Connectivity. Microsoftin käyttöjärjestelmissä toimiva C- kielinen liittymä relaatiotietokantoihin.
ODL
ODMG Object Definition Language. Laajennettu IDL. Tarkoitettu oliotietokantojen skeeman, eli olioiden rajapintojen määrittelyyn.
ODMG
Object DataBase Management Group. Oliotietokantatoimittajista muodostuva standardointielin.
OMG
Object Management Group. Useiden suurien tietotekniikkayritysten yhdessä perustama olioihin perustuvien ohjelmistotekniikoiden standardointielin.
OML
Object Manipulation Language. Kieli, jota käytetään oliotietokantoihin talletetun tiedon hakemiseen ja muuttamiseen.
OMT
Object Modeling Technique. Oliopohjainen suunnittelumetodologia, joka esitellään kirjassa [Rumbaugh et ai. 1991].
OQL
Object Query Language. SQL:n kaltainen OML:n osa joka tukee assosiatiivisia tietokantahakuja.
1. Lyhenneluettelo SAX
Simple API for XML. Yksinkertainen, tapahtumiin perustuva rajapinta XML- dokumenttien käsittelyyn.
SGML
Standard Generalized Markup Language (ISO 8879). Maailmanlaajuinen standardi erilaisten elektronisten dokumenttien rakenteiden ja sisällön kuvausten tekemiseen.
SDK
Software Development Kit. Kokoelma työkaluja joiden avulla ohjelmoidaan tiettyä järjestelmää. Esimerkiksi Win32 SDK.
SQL
Structured Query Language. Standardoitu relaatiotietokantojen kyselykieli.
TFC
Table Format Codes. Mustiin taulukkonäkymien [Lehto 1995] määrittelykieli.
UML
Unified Modeling Language. Oliopohjainen analysonti- ja suunnittelukieli.
Winl6
Yleisnimitys 16 bittisille windows-arkkitehtuureille. Esimerkiksi Windows 3.1.
Win32
Yleisnimitys 32 bittisille windows-arkkitehtuureille. Esimerkiksi Windows 95, ja Windows NT.
WWW
World Wide Web. Maailmanlaajuinen tietoverkko. Tällä yleensä tarkoittetaan internetistä löytyvien hypermediadokumenttien luomaa verkostoa.
XML
Extensible Markup Language. Metakieli, jolla voi kuvata toisia kieliä ja joka mahdollistaa SGML:n käytön WWW:ssä.
2. Johdanto
2 Johdanto
Useimmissa nykyaikaisissa sovelluskehittimissä on jonkinlainen tuki monen samaa projektia tekevän sovelluskehittäjän samanaikaiselle työskentelylle; Microsoft Excel ja Access ohjelmistoissa monta käyttäjää voi tehdä muutoksia, vaikka samanaikaisestikin, käyttäjien välillä jaettuun tietokantaan; C++-ohjelmia voi kehittää rinnakkain erilaisia versionhallintaohjelmistoja käyttäen; useita olio- tai relaatiotietokantoihin perustuvia järjestelmiä voi monta käyttäjää selata ja muutella samanaikaisesti, jne. Monen samanaikaisen kehittäjän tuesta on suunnattomasti hyötyä etenkin suurempien, useampien sovelluskehittäjien työpanosta vaativien projektien läpiviemisessä.
Yhtenä merkittävimmistä tämän hetken menetelmistä ohjelmien laadun ja tuottavuuden parantamiseen pidetään ohjelmakomponenttien uudelleenkäyttöä [Frakes&Terry 1996].
Ohjelmakomponenttien uudelleenkäyttö vaatii käytettävältä sovelluskehittimeltä menetelmää komponenttien sovelluksesta irroittamiseen ja toiseen sovellukseen liittämiseen.
2.1 Diplomityön tavoite
Tämän diplomityön perimmäisenä tavoitteena on selvittää miten erityisesti Must- sovelluskehittimeen [Lehto 1995] saataisiin tehokkaimmin toteutettua edellisessä kappaleessa mainittu tuki monelle käyttäjälle ja ohjelmakomponenttien uudelleenkäytölle. Lisäksi tavoitteena on kehittää erityisesti sovelluskehittimen
”tehokäyttäjiä” varten ihmisen luettavissa ja muunneltavissa oleva Must-oliotietokannan kuvauskieli.
Diplomityöhön liitetään lisäksi suunnitelma ominaisuuksien toteuttamisesta Must- sovelluskehitinohjelmistoon.
Vaikka työn tarkoituksena onkin kehittää Must-sovelluskehitintä, pyritään se tekemään niin yleisluontoisesti, että aivan viimeisimpiä toteutusvaiheita lukuunottamatta samat ominaisuudet voidaan toteuttaa johonkin toiseen oliopohjaiseen sovelluskehittimeen samoja menetelmiä käyttäen.
Kiteytettäen voidaan sanoa, että etsitään vastauksia seuraaviin Must- sovelluskehitykseen nykyisin liittyviin ongelmiin:
Kuinka saadaan päivitettyä palvelimella olevaan sovellukseen muualla kehitettyjä parannuksia, ilman että palvelua tarvitsee välillä sulkea?
Kuinka yhdistetään usean sovelluskehittäjän samaan aikaan malliin tekemät muutokset?
Kuinka saadaan minimoitua samankaltaisten mallien tekemisen vaatima työmäärä?
Kuinka saadaan suunniteltua Must-oliomalleja ilman Must Modeller- sovelluskehitintä?
Diplomityö pyritään tekemään mahdollisimman helposti ymmärrettäväksi myös sellaisille henkilöille, joilla ei ennestään ole kunnollista kuvaa diplomityön
2. Johdanto käsittelemästä aihealueesta. Työn alkuosassa selvitetään aihealueeseen liittyvää teoriaa, loppuosan keskittyessä ongelmien ratkaisuiden kuvaamiseen alkuosassa esiteltyä teoriaa hyödyntämällä. Esiteltävien asioiden ymmärtämistä ja hahmottamista pyritään helpottamaan tarpeen mukaan yksinkertaisia esimerkkejä ja kuvia apuna käyttäen.
2.2 Diplomityön rajaus
Tämän diplomityön tuloksena saadaan eräänlainen suunnitelma edellisessä kappaleessa lueteltujen tavoitteiden saavuttamisesta Must-ohjelmistossa.
Tämän diplomityön puitteissa ei ole tarkoitus toteuttaa minkäänlaista versionhallintajärjestelmää, vaan versionhallintajärjestelmänä tullaan käyttämään kolmannen osapuolen tuotetta, joka esitellään kappaleessa 4.3.
Tavoitteena ei myöskään ole suunnitella monen käyttäjän samanaikaisesti fyysisesti saman oliomallin käsittelyä, vaan periaatteena on, että jokaisella käyttäjällä on oma oliomalli, johon tämä tekee muutoksia. Kun muutokset halutaan yhdistää toisen käyttäjän tekemien muutosten kanssa, luo tämä toinen käyttäjä tekemistään muutoksista siirtotiedoston, joka voidaan lukea sisään omaan oliomalliin.
Koska Mustiin teknistä toteutusta on käsitelty jo Teemu Lehdon [Lehto 1995] sekä Sami Rosendahlin [Rosendahl 1997] diplomitöissä, ei sitä tulla käsittelemään tässä diplomityössä pintaa syvemmältä.
3. Olioteknologia
3 Olioteknologia
Olioteknologia on viimeisen vuosikymmenen aikana mullistanut ohjelmistomaailman.
Lähes kaikki nykyisin vakavammassa käytössä olevat ohjelmointikielet tukevat olioteknologiaan perustuvia ajatusmalleja ja rakenteita.
Tässä kappaleessa käsitellään tämän diplomityön ymmärtämisen kannalta oleellisimpia olioteknologiaan liittyviä asioita. Kappale aloitetaan olioteknologian pohjana olevan ajatusmallin esittelyllä kappaleessa 3.1. Tämän jälkeen siirrytään Mustiinkin tietokantana käytettyjen oliotietokantojen esittelyyn kappaleessa 3.2. Oliotietokantojen jälkeen esitellään ohjelmamoduuli-käsite kappaleessa 3.3, sekä selvitetään ohjelmamoduulien uudelleenkäytön tuomia hyötyjä ja haittoja kappaleessa 3.4.
3.1 Olio-ajattelu
Olioihin perustuvan ajattelutavan perusajatuksena on jakaa ongelma-alue selkeisiin itsenäisiin osa-kokonaisuuksiin (luokkiin), joita käsitellään tarkkaan määritellyn rajapinnan välityksellä. Rajapinta pyritään tekemään sellaiseksi, että se rajoittaa luokan toteutuspuolta mahdollisimman vähän. Ongelmaa ratkaistaessa luodaan luokista instansseja eli luokan “ilmentymiä”. Luokkaa voidaan usein pitää abstraktina oliomäärittelynä, kun taas instanssi on luokan määrittelyn mukainen konkreettinen olio.
Rajapinta on usein toteutettu metodeilla, joiden välityksellä tarkastellaan ja manipuloidaan luokasta luodun instanssin tilaa. Joissain tapauksissa rajapinta sisältää myös luokan attribuutteja, joiden käyttö paljastaa rajapinnan takana piilevän toteutuksen olion ulkopuolelle. Tämä ei useimmissa tapauksissa ole hyvä idea, sillä se rajoittaa luokasta perittyjen olioiden toteutusta. Vaihtoehto attribuuttien suoralle rajapintaan siirtämiselle on nk. get- ja set-metodien käyttö, jossa attribuutille luodaan metodit (esim. get_attribute ja set_attribute), joiden välityksellä attribuuttia käsitellään.
Tällöin tästä luokasta peritty luokka voi toteuttaa kyseiset metodit tarvittaessa täysin eri menetelmällä, kuin yläluokan toteutuksessa on tehty. Tätä instanssin tyypistä riippuvaa metodin nimen ja toteutuksen välistä ohjelman ajon aikaista sidontaa kutsutaan polymorfismiksi.
Jos kahdella luokalla on yhteisiä ominaisuuksia (esim. rajapinta samankaltainen), voidaan tätä mallintaa perinnän avulla. Tällöin voidaan esimerkiksi luoda oma abstraktiksi yläluokaksi kutsuttu luokka, johon asetetaan kahden luokan yhteiset ominaisuudet. Tämän jälkeen nämä kaksi luokkaa voidaan periä tästä abstraktista yläluokasta, jolloin yhteisiä ominaisuuksia ei enää tarvitse toteuttaa molempiin luokkin, vaan riittää että ne toteuttaa abstraktiin yläluokkaan.
Monimutkaisia järjestelmiä suunniteltaessa on usein hyödyllistä miettiä ongelmaa suunnittelurakenteiden (design patterns [Gamma et ai. 1995]) avulla.
S uunni ttel urakenteet ovat eräänlaisia uudelleenkäytettäviä olioiden välisten interaktioiden ja niiden rajapintojen kuvauksia, joiden avulla suunnittelijat voivat kuvata toisilleen monimutkaisiakin rakenteita yhtä sanaa, suunnittelurakenteen nimeä, käyttämällä [Holland&Lieberherr 1996]. Gamma et ai. [1995] ovat kirjassaan kuvanneet
3. Olioteknologia 23 tällaista suunnittelurakennetta, antamalla jokaiselle suunnittelurakenteelle nimen ja selkeän kuvauksen käyttötarkoituksineen.
3.2 Oliotietokannat
Tietokannat ovat yksinkertaisien datatiedostojen tapaan tiedon säilytykseen tarkoitettuja paikkoja. Datatiedoston tapaan tietokantaa ei ole tarkoitettu tiedon esittämiseen, vaan ainoastaan sen säilyttämiseen. Tietokannassa tieto on usein järjestetty siten, että tiedon haku kannasta on mahdollisimman nopeaa. Tämä tarkoittaa muunmuassa sitä, että toisiinsa läheisesti liittyvä tieto löytyy myös tietokannasta läheltä toisiaan. Tietokanta koostuu useimmiten kahdesta osasta: tiedostot, joihin tieto fyysisesti talletetaan, sekä tietokannan hallintajärjestelmä (DBMS), joka kontrolloi tietokannan käsittelyä [Microsoft 1999a].
Oliotietokannat ovat olioihin perustuvaan ajattelutapaan perustuvia tietokantoja.
Oliotietokantojen kanssa kilpailevina vaihtoehtoina ovat tiedostojärjestelmät, relaatiotietokannat sekä olio-ominaisuuksilla laajennetut relaatiotietokannat.
Tiedostojärjestelmät ovat oliotietokantoihin verrattuna huonosti skaalautuvia ja jaettavia, eivätkä ne täytä hajautettujen monen käyttäjän sovelluksien tarpeita kovinkaan hyvin. Lisäksi tiedostojärjestelmään perustuvia tietokantoja käytettäessä jää ohjelmointikielen tietorakenteiden siirtäminen tietokantaan ja sieltä takaisin sovellukseen sovellusohjelman harteille.
Relaatiotietokannat tukevat objektien jakamista, mutta niiden integrointi olio- ohjelmointikieliin on hankalaa. Olio-ohjelmointikieltä käyttävän ohjelmoijan harteille jää relaatiotietokantaa käytettäessä objektien muuttaminen relaatiotietokantaan sopivaan muotoon ja em. muodosta takaisin sovelluksen ymmärtämään muotoon. Olio- ominaisuuksilla laajennetut relaatiotietokannat eivät myöskään integroidu kovinkaan hyvin oliopohjaiseen ohjelmointi-ympäristöön.
Oliotietietokantojen suurin anti tietokannoille on mahdollisuus mallintaa olioilla.
Olioiden käyttö helpottaa tietokannan suunnittelua ja niiden integrointi olio- ohjelmointikieliin on helppoa [Loomis 1995],
Oliotietokannat soveltuvat erityisesti tilanteisiin, joissa käsitellään monimutkaista tietoa.
Francois Bancilhon artikkelin [Bancilhon 1996] mukaan monimutkaista tietoa käsiteltäessä oliotietokantojen tehokkaampi toiminta voidaan selittää niiden asiakaskeskeisillä suunnittelulähtökohdilla sekä relaatiotietokannoille tyypillisten raskaiden join-operaatioiden puuttumisella.
Sekä relaatio- että oliotietokantojen hallintajärjestelmiä löytyy markkinoilta useita.
Tunnettuja relaatiotietokantojen hallintajärjestelmiä ovat mm. Oracle Corporationin Oracle [Oracle 2000], Sybase Inc.:n Adaptive Server [Sybase 2000], sekä Microsoftin SQL server [Microsoft 2000f], Vastaavasti oliotietokantojen hallintajärjestelmiä ovat mm. Mustin hyödyntämä eXcelon Corporationin ObjectStore [eXcelon 1997], Objectivity Inc:n Objectivity/DB [Objectivity 2000], sekä POET Softwares POET Object Server Suite [POET 1999].
3. Olioteknologia
3.2.1 Diplomityössä käytettävä oliomalli
Diplomityössä käsiteltävä oliomalli on pyritty tekemään mahdollisimman yksinkertaiseksi, kuitenkin siten, ettei mitään työn kannalta oleellisia Must- mallinnusohjelmiston tietokannan ominaisuuksia jää huomioimatta. Käytetyn oliomallin kuvaus muissa oliotietokannoissa on varsin suoraviivaista, mikäli tietokanta on toteutettu OMT:n mukaisesti [Loomis 1995].
Työssä käytettävä oliomalli on dynaaminen, eli oliotietokannan metaolioille voidaan tehdä oliomallin semantiikan mukaisia muutoksia oliotietokannan hallintajärjestelmän käynnissäolon aikana.
Seuraavassa esitellään lyhyesti työssä käytetyn oliomallin meta-oliot.
Primitiivinen tietorakenne
Primitiivisiä tietorakenteita ovat numerot, merkkijonot ja viittaukset tietokannan entiteetteihin, sekä näistä muodostetut listat ja taulukot.
Oliomalli
Tätä kappaletta lukuunottamatta oliomalli-termiä käytetään kuvaamaan kaikkia yksittäiseen oliotietokantaan talletettuja rakenteita. Oliomallin sisältämiä rakenteita voi käsitellä oliomallin sisältämän juuriluokka-listan kautta (juuriluokat ovat luokkia, joilla ei ole yläluokkaa).
Mary E. S. Loomis käyttää kirjassaan [Loomis 1995], ja minä tässä kappaleessa, oliomalli (object model)-termiä kuvaamaan oliotietokantaan talletettavia tietotyyppejä ja tietokannan hallintajärjestelmän ymmärtämää ja pakottamaa tietotyyppien semantiikkaa.
Ei-primitiivinen tietorakenne
Ei-primitiivisillä tietorakenteilla on merkkijono-tyyppinen tunniste (nimi). Ei primitiivisä tietorakenteita ovat attribuutit ja entiteetit.
Entiteetti
Entiteetti on yleisnimitys oliomallin niille ei-primitiivisille tietorakenteille, jotka voivat sisältää attribuutteja. Entiteeteillä on nolla tai useampia attribuutteja, joilla on part-of tyyppinen suhde entiteettiinsä. Kahdella samaan oliomalliin kuuluvalla saman tyyppisellä entiteetillä ei voi olla samaa nimeä.
Luokat ja instanssit ovat entiteettejä.
Luokka
Luokka sisältää tiedon kaikista luokan instansseille yhteisistä ominaisuuksista, kuten luokalla olevista attribuuteista. Luokat toimivat eräänlaisina tietokannan olioiden
3. Olioteknologia tyyppimäärittelyinä [Silberschatz et ai. 1996], missä luokan attribuutit toimivat eräänlaisina prototyyppeinä [Gamma et ai. 1995] instanssien attribuuteille.
Luokalla on nolla tai useampia instansseja, nolla tai useampia alaluokkia sekä nolla tai useampia yläluokkia.
Instanssi
Instanssi on luokan “ilmentymä”, eli sen rajapinta vastaa luokan rajapintaa. Instanssilla on attribuuttien arvoja lukuunottamatta samanlaiset attribuutit kuin instanssin luokan prototyyppi-attribuuteilla. OMT:ssä instanssia nimitetään joskus myös olioksi [Rosendahl 1997]. Instanssi kuuluu aina täsmälleen yhteen luokkaan.
Koska Instanssi on entiteetti, on sillä myös oma tunniste, jonka täytyy olla uniikki oliotietokannan muiden instanssien tunnisteiden joukossa.
Attribuutti
Attribuutit ovat ei-primitiivisiä tietorakenteita joilla on arvo, joka on primitiivinen tietorakenne. Attribuutin tyyppi voi olla relaatio tai jokin primitiivinen tietorakenne.
Attribuutit ovat aina osana entiteettiä. Attribuutin luokka on entiteetti jonka osana se on, tai mikäli entiteetti on instanssi, on attribuutin luokka tämän instanssin luokka. Mikäli attribuutti on määritelty attribuutin luokan yläluokassa, on sen tyyppi sama kuin yläluokan attribuutilla. Kahdella samaan entiteettiin kuuluvalla attribuutilla ei voi olla samaa nimeä.
Attribuutilla voi lisäksi olla laskentasääntö, joka saattaa aiheuttaa riippuvuuksia attribuutin arvon ja muiden oliomallissa olevien olioiden välillä. Mikäli attribuutilla ei ole laskentasääntöä, on sen arvo vapaasti määriteltävissä (eli on nk. syöttöarvo).
Attribuutin arvo säilötään sen tyypin mukaisesti, eli numero-tyyppiseen attribuuttiin ei voi tallettaa esimerkiksi merkkijonoa “Moi!”.
Tietoalkiot ja relaatiot ovat attribuutteja.
Laskentasääntö
Laskentasääntö määrittää attribuutille yksikäsitteisen arvon, joka voi riippua muista oliomallin olioista. OMT:ssä laskentasääntöä nimitetään operaatioksi tai metodiksi.
Olion laskentasäännön kutsumista sanotaan myös viestin lähettämiseksi (message passing).
Laskentasääntö on sama kaikilla saman luokan instanssien samannimisillä attribuuteilla.
Laskentasäännön voi periä alaluokkien attribuuteille.
Tietoalkio
Tietoalkio on attribuutti, jonka arvo ei ole viittaus-tyyppinen. OMT:ssä tietoalkiota vastaa attribuutti. Tietoalkion arvo voi olla numero, numerolista tai merkkijono.
3. Olioteknologia Relaatio
Relaatiot kuvaavat oliomallin instanssien välisiä suhteita (viittauksia oliomallin instansseihin). OMT:ssä relaatiota vastaa assosiaatio.
Relaatioilla on seuraavat erityispiirteet:
Relaatiolla on arvo, joka sisältää nolla tai useampia viittauksia kohdeluokkansa (tai tämän alaluokkien) instansseihin. Instanssiviittausten lista on järjestetty, eli siinä olevien instanssien järjestys säilyy samana kuin missä järjestyksessä instanssit relaatioon asetettiin.
- Luokan relaatioiden arvo on aina tyhjä.
- Relaatiolla on kohdeluokka.
Relaatiolla on kardinaliteetti, joka määrää arvona olevien instanssien maksimimäärän. Kardinaliteetin arvo on joko yksi tai monta.
Relaatio voi olla kaksisuuntainen, jolloin relaatiolla tulee olla vastinrelaatio kohdeluokassa. Tällöin relaation arvona olevien instanssien vastinrelaation arvona on sen relaation instanssi josta lähdettiin.
Jos relaatio on määritelty jo yläluokassa, on relaation kohdeluokka sama kuin yläluokan relaation kohdeluokka, tai kohdeluokka on yläluokan kohdeluokan alaluokka.
juuriluokat
viitatut instanssit yläluokka
alaluokka
Instanssi Luokka
Oliomalli
Entity {abstract)
arvo Tietoalkio kardinaliteetti
Relaatio nimi : Merkkijono
Objekti {abstract}
laskentasääntö : Merkkijono Attribuutti
{abstract}
Kuva 1: Työssä käytetyn oliotietokannan rakenne UML-muodossa
3.2.2 Mallinnusesimerkki
Tehtävänä on mallintaa yksinkertainen kurssitietokanta kappaleessa 3.2.1 esitettyjä rakenteita käyttäen. Tietokantaan kuuluu seuraavat kuvauksen mukaiset oliot:
Kurssi
Kurssilla on koodi, opintoviikkojen lukumäärä, luennoija sekä tiedot osallistujista.
3. Olioteknologia Luennoija
Luennoijalla on nimi ja tiedot kursseista joita hän luennoi.
Opiskelija
Opiskelijalla on nimi ja tiedot suoritetuista kursseista arvosanoineen.
Mallinnus on hyvä aloittaa luokkahierarkian selvittämisellä. Tässä tapauksessa kaikista em. olioista on hyvä tehdä oma luokkansa. Näin saadaan luokat kurssi, luennoija ja opiskelija.
Tämän jälkeen tutkitaan luokille asetettuja vaatimuksia, jolloin huomataan että sekä luennoijalla että opiskelijalla on nimi, joten nimi voidaan siirtää yhteiseen abstraktiin yläluokkaan (tietoalkion tyyppinä merkkijono), jonka nimeksi sopii hyvin esim.
ihminen.
Seuraavaksi käydään luokat läpi yksitellen, ja selvitetään luokkien lopullinen rajapinta.
Kurssi-luokan opintoviikkojen lukumäärä voidaan kuvata numero-tyyppisellä tietoalkiolla opintoviikot.
Kurssi-luokalla on tieto kurssin luennoijasta ja vastaavasti luennoijalla on tieto kursseista joita luennoi. Tämä voidaan mallintaa siten, että asetetaan Kurssi-luokkaan yksi-kardinaliteettinen relaatio luennoija jonka kohdeluokkana on Luennoija.
Vastaavasti tälle asetetaan vastinrelaatioksi luokkaan luennoija moni-kardinaliteettinen relaatio kurssit.
Vastaavasti Kurssi-luokan Opiskelija-lista voidaan toteuttaa moni-kardinaliteettisella relaatiolla osanottajat, jolle luodaan moni-kardinaliteettinen vastinrelaatio kurssit luokkaan Opiskelija.
Kurssi-luokan opiskelija-lista on hieman vaikeampi tapaus, sillä Opiskelija-luokassa halutaan liittää suoritettu kurssi siitä saatuun arvosanaan. ODMG oliomallin mukaisessa mallinnuksessa [Loomis 1995, Barry 1998] tämä kävisi määrittämällä Opiskelija- luokkaan rakenteellinen attribuutti opintosuoritus, mutta koska työssä käytettävä oliotietokanta ei tunne rakenteellisia attribuutteja, täytyy tämä mallintaa relaatiota ja uutta Opintosuoritus-luokkaa käyttäen.
Opintosuoritus-luokkaan lisätään yksi-kardinaliteettinen relaatio kurssi, jonka kohdeluokaksi asetetaan Kurssi. Lisäksi em. relaatiolle luodaan luokkaan Kurssi moni- kardinaliteettinen vastinrelaatio opintosuoritukset. Vastaavasti Opintosuoritus-luokkaan lisätään yksi-kardinaliteettinen relaatio opiskelija, jonka kohdeluokaksi asetetaan Opiskelija ja vastinrelaatioksi moni-kardinaliteettinen opintosuoritukset.
Lopuksi Opintosuoritus-luokkaan lisätään vielä arvosana-tietoalkio, joka on numerotyyppinen.
Näin olemme saaneet mallinnettua kuvan 2 mukaisen kurssitietokannan, jota käytetään seuraavasti:
3. Olioteknologia Uuden oppilaan lisääminen:
Luodaan uusi instanssi luokkaan oppilas, minkä jälkeen asetetaan oppilaan tiedot instanssin attribuutteihin.
Uuden luennoijan lisääminen:
Luodaan uusi instanssi luokkaan Luennoija, minkä jälkeen asetetaan luennoijan tiedot instanssin attribuutteihin.
Uuden kurssin opintosuoritusten merkitseminen:
Varmistetaan, että luennoijalla ja kurssille osallistuneilla oppilailla on omat instanssit. Luodaan uusi instanssi luokkaan Kurssi. Lisätään luennoija-relaation arvoksi luennoijan instanssi. Luodaan jokaista kurssille osallistunutta oppilasta kohden oma instanssi Opintosuoritus-luokkaan. Asetetaan jokaisen uuden Opintosuoritus-instanssin kurssi ja opiskelija-relaatiot osoittamaan opintosuoritusta vastaaviin instansseihin. Täytetään Opintosuoritus-luokan arvosana-tietoalkiot sekä Kurssi-instanssin koodi ja opintoviikot tietoalkiot oikeilla arvoillaan.
opiskelija luennoija
opintosuoritukset kurssit
kurssi opiskelijat
Opiskelija Luennoija
arvosana : numero Opintosuoritus nimi: Merkkijono
Ihminen {abstract}
opintoviikot: numero koodi: merkkijono
Kurssi
Kuva 2: Mallinnusesimerkin tietorakenne UML-notaatiolla esitettynä
3.3 Ohjelmamoduulit
Ohjelmistosovellusten kompleksisuus kasvaa jatkuvasti niihin integroitavien uusien ominaisuuksien myötä. Ohjelmistovalmistajat pyrkivät sisällyttämään tuotteisiinsa kaikki mahdolliset ominaisuudet, jotta kaikkien käyttäjien tarpeet saadaan tyydytettyä.
Suurin osa käyttäjistä hyödyntää kuitenkin vähemmän kuin 10 prosenttia tavallisen sovelluksen ominaisuuksista [Orfali et ai. 1996]. Tällaiset monoliittiset sovellukset ovat painajainen ohjelmiston ylläpitäjälle. Uusien piirteiden, virheiden korjausten ja
3. Olioteknologia testauksen vaatima aika on pitkä, sillä jokaisessa uudessa ohjelmistoversiossa on satoja uusia ominaisuuksia [Viitala 1997].
Monimutkaiset monoliittiset järjestelmä voidaan jakaa yksinkertaisempiin osiin, joita kutsutaan moduuleiksi. Useasta moduulista koottua järjestelmää kutsutaan modulaariseksi.
Mikäli monimutkainen järjestelmä on toteutettu modulaarisesti, on siihen huomattavasti helpompi tehdä muutoksia kuin ei-modulaariseen järjestelmään. Tämä johtuu siitä, että tällöin muutoksen tekeminen ei vaadi koko järjestelmän ymmärtämistä, vaan useimmiten riittää ymmärtää muutokseen liittyvien moduulien toiminta ja niiden vastuualueet.
Oleellisena osana modulaaristen järjestelmien suunnittelussa on moduulien välisten kytkentöjen minimointi, sekä moduulien kiinteyden maksimointi. Moduulien välisillä kytkennöillä tarkoitetaan kaikkia niitä riippuvuuksia, joita moduulista on ympäristöönsä. Moduulien kiinteydellä puolestaan viitataan siihen, että moduuliin kuuluvat elementit (esimerkiksi proseduurit, oliot, informaatio jne.) kuuluvat loogisesti yhteen, eli toimivat yhdessä tuoden järjestelmään jonkin uuden ominaisuuden.
Kun modulaarisuutta sovelletaan oliopohjaisiin ohjelmistoihin, tarkoitetaan modulaarisuudella sitä, että olioita tai niistä muodostettuja ryhmiä voidaan korvata toisilla saman rajapinnan tarjoamilla olioilla tai eliöryhmillä, ilman oliomallin muuhun rakenteeseen koskemista. Moduulilla tarkoitetaan yhden tai useamman olion muodostamaa, useimmiten jonkin tietyn tarkoituksen täyttävää, ohjelmakokonaisuutta.
Moduulista käytetään usein komponentti-nimitystä, jonka merkitys eroaa moduulista lähinnä sillä, että komponentit voivat sisältää myös parametroitavia, varsinaisesta ohjelmakoodista riippumattomia, tietoja, joita kutsutaan resursseiksi [Szyperski 1998].
Yhtenä suurimmista oliotekniikoideti tuomista eduista pidetään sitä, että oliot kätkevät olion käyttäjältä sen varsinaisen sisäisen toteutuksen määrittelemänsä rajapinnan taakse.
Yksinkertaisimmassa tapauksessa tämä tarkoittaa muunmuassa sitä, että olio voidaan korvata toisella oliolla, mikäli tämä korvaava olio tarjoaa vähintään yhtä monipuolisen rajapinnan kuin mitä korvattava olio tarjosi. Korvattava olio ei aseta rajapintansa ja vastuualueidensa lisäksi mitään muita rajoituksia korvaavan olion rakenteelle ja toteutukselle. Myös olioryhmä voidaan kuvata oliona, jonka rajapinta koostuu jokaisen olioryhmän olion omasta rajapinnasta siten, että siitä on poistettu eliöryhmän olioiden ainoastaan olioryhmän sisällä tapahtuvaan kommunikointiin käytetyt rajapinnat. Tämä menetelmä vastaa julkisivu (facade)- suunnittelurakennetta [Gamma et ai. 1999], missä julkisivu-olion rajapinta toimii rajapintana muun systeemin ja julkisivu-olion hallinnoiman olioryhmän välillä [Kuva 3], Julkisivu-olion rajapinnan täytyy siis sisältää vähintään kaikki ulkopuolisen järjestelmän julkisivu-olion hallinnoimalta eliöryhmältä vaatimat ominaisuudet.
3. Olioteknologia
Luokka 2
Luokka 3
Luokka 4
Luokka 3 Luokka 4
Luokka 1 Luokka 1
Luokka 2
Julkisivuluokka Käyttäjäluokka 1
Käyttäjäluokka 3 Käyttäjäluokka 2
Käyttäjäluokka 3
Käyttäjäluokka 1
Käyttäjäluokka 2
Kuva 3: Julkisivu-suunnittelurakenteen vaikutus luokkien välisiin viittauksiin Kun oliomallissa korvataan jokin moduuli uudella moduulilla, täytyy oliotietokantaan tuoda tämän uuden moduulin rakenteiden (useimmiten luokkien) määrittelyt, minkä jälkeen oliotietokannan täytyy tarkistaa, että uusi moduulin rajapinta vastaa rajapintaa joka siltä vaaditaan siinä oliomallin paikassa johon se asetetaan. Perinteisissä olio- ohjelmointikielissä kuten C++, tämä tarkistus tapahtuu ohjelman kääntämisen aikana.
Oliotietokannoissa, jotka mahdollistavat luokkahierarkian ajonaikaisen muuttamisen (esimerkiksi Must), tämä tarkistus täytyy tehdä ennen vanhan moduulin poistamista, jotta oliomalli ei joudu epäkonsistenttiin tilaan sen takia, että korvaava moduuli ei
kelpaa muulle oliomallille.
3.4 Moduulien uudelleenkäyttö
Uudelleenkäyttöä pidetään, ainakin periaatteessa, yhtenä parhaimmista menetelmistä nostaa ohjelmistotyön tuottavuutta. Uudelleenkäyttöä voikin hyödyntää lähes kaikkien ohjelmistoprojektin varrella tehtävien dokumenttien, komponenttien ja muiden tuotteiden tekemisessä. Esimerkiksi tehtäessä ohjelmistolle käyttöliittymää, voidaan käyttää jotain aiempaa projektia varten tehtyä käyttöliittymäkomponenttia hieman muunneltuna, sen sijaan että luotaisiin samankaltainen komponentti kokonaan uudestaan.
Useissa yrityksissä on käytettävissä omat komponenttikirjastot, joissa säilytetään tulevaisuuden varalle aiemmissa projekteissa tehtyjä uudelleenkäytettäviä komponentteja. Tätä komponenttikirjastoa käytetään projektin suunnitteluvaiheessa mahdollisten käytettävien komponenttien etsimiseen. Toteutusvaiheessa sopivat komponentit haetaan kirjastosta ja muokataan projektin tarpeisiin sopivaan muotoon.
Lopuksi, kun projekti on saatu loppuun, dokumentoidaan projektissa mahdollisesti syntyneet uudet uudelleenkäytettävät komponentit ja siirretään ne komponenttikirjastoon. Tämä prosessi on esitetty myös kuvassa 4.
3. Olioteknologia
Tuote Arkkitehtuuri-
suunnittelu
Moduuli- suunnittelu
toteutus
Kirjastointi Määrittely
Komponenttien muokkaaminen
Komponentti- kirjastot
Kuva 4: Uudelleenkäyttö tuotantoprosessissa
Uudelleenkäytettävyydestä saavutettavissa olevia hyötyjä ovat tuottavuuden ja laadun paraneminen. Jotta komponenttia voidaan sanoa uudelleenkäytettäväksi, täytyy sitä olla käytetty jo vähintään kerran johonkin aiempaan projektiin [Stroustrup 1997].
Aiemmasta käytöstä johtuen, on komponenttia myös testattu aiemmin, joten siinä ei todennäköisesti ole virheitä. Näin ollen saadaan lyhennettyä testaukseen ja virheiden korjaamiseen tarvittavaa aikaa [Haikala&Märijärvi 1998].
Koska tämän diplomityön tarkoituksena on kehittää oliotietokantaan perustuvan sovelluskehittimen moduulien uudelleenkäyttöä, keskitytään seuraavassa ainoastaan ohjelma-moduulien uudelleenkäyttöön.
Oliopohjaisissa sovelluskehittimissä kaksi yleisimmin käytettyä toiminnallisuuden uudelleenkäyttötekniikkaa ovat perintä ja olioiden kokoaminen (object composition).
Perintää hyödynnettäessä periytetään luokka siitä uudelleenkäytettävästä luokasta, jonka ominaisuudet halutaan uudelle luokalle. Tämä uudelleenkäyttötekniikka tunnetaan myös nimellä white-box reuse, missä termi ”white-box” viittaa näkyvyyteen, eli uudelleenkäytettävän luokan sisäinen toteutus on usein nähtävissä myös siitä perityissä luokissa [Gamma et ai. 1995].
Olioiden kokoamisella tarkoitetaan sitä, että esimerkiksi uusi luokka sisältää viittauksen uudelleenkäytettävän luokan instanssiin. Uusi luokka kommunikoi muiden luokkien tapaan uudelleenkäytettävän luokan instanssin kanssa tämän julkisen rajapinnan
3. Olioteknologia välityksellä, jolloin uudelleenkäytettävän luokan sisäinen toteutus ei paljastu uudelle luokalle. Olioiden kokoamiseen perustuvaa uudelleenkäyttötekniikkaa kutsutaankin tästä syystä black-box reuse:ksi [Gamma et ai. 1995],
Tutkimuksissa on havaittu että white-box-uudelleenkäytöllä ei juurikaan saada lyhennettyä luokan kehittämiseen kuluvaa aikaa eikä luotettavuutta, verrattuna luokkien kokonaan uudelleenkirjoittamiseen. Black-box-uudelleenkäytön on sensijaan havaittu vähentävän luokkien kehittämiseen kuluvaa aikaa sekä luotettavuutta [Griss et ai.
1995],
Uudelleenkäytettäviä moduuleita suunniteltaessa kannattaa selvittää, onko olemassa jotain yleisesti tunnettua suunnittelurakennetta (design pattern), jota voisi hyödyntää moduulin tekemisessä. Suunnittelurakenteet ovat useissa erilaisissa ongelmissa hyödynnettävissä olevia hyviksi havaittuja kuvauksia olioista, luokista, näiden vastuista ja niiden välisestä interaktiosta tietyn yleisen suunnitteluongelman ratkaisemiseksi.
Tunnetut suunnittelurakenteet on usein suunniteltu juuri uudelleenkäytettävyyttä, helppoa muuteltavuutta ja laajennettavuutta silmällä pitäen [Cochran&Weisz 1997].
Jotta ohjelmamoduulia voidaan käyttää uudelleen, täytyy niiden täyttää seuraavat kriteerit:
- Moduulin tulee olla sisäisesti kiinteä (high cohesion)[Ghezzi et ai. 1991]. Ts.
moduuli sisältää vain loogisesti yhteenkuuluvien komponentteja.
Moduulien välisten kytkentöjen minimointi (low coupling) [Ghezzi et al. 1991]. Ts.
moduulin rajapinta on mahdollisimman yksinkertainen.
Hyvä rajapinnan dokumentaatio. Ts. moduulin rajapinta ulkomaailmaan on dokumentoitu mahdollisimman täydellisesti, eikä moduuli tee moduulin ulkopuolelta havaittavasti sen enempää tai vähempää kuin mitä sen dokumenteissa sanotaan.
- Moduulin tulee olla löydettävissä. Ts. uudelleenkäytettäville moduuleille täytyy järjestää jokin yhteinen säilytyspaikka (komponenttikirjasto), jossa moduuleita voi
säilyttää, päivittää sekä mistä tarvittavat moduulit on helppo löytää ja hakea.
Toistaiseksi uudelleenkäytön hyödyt ovat jääneet pieniksi suhteessa aiheesta kirjoitettujen julkaisujen määrään. Syynä tähän ovat useat uudelleenkäyttöön liittyvät ongelmat. Seuraavassa Douglas C. Schmidtin artikkelissaan [Schmidt 1999] luettelemat yleisimmät uudelleenkäyttöä hankaloittavat esteet.
Organisaation aiheuttamat esteet
Uudelleenkäytettävien komponenttien kehittäminen ja hyödyntäminen vaatii organisaatiolta hyvää sovelluskehittäjien ymmärtämistä ja liiketoiminnan vaatimusten ymmärtämistä.
Talouden esteet
Uudelleenkäytön tukeminen vaatii taloudellista panostamista. Monille organisaatioille uudelleenkäyttöä kehittävien ryhmien työn laskuttaminen ja rahoittaminen aiheuttaa ongelmia.
Ylläpidolliset esteet
Uudelleenkäytettävien komponenttien luettelointi, säilyttäminen ja hakeminen monesta yksiköstä koostuvissa organisaatioissa on vaikeaa. Potentiaalisten
3. Olioteknologia uudelleenkäyttötilanteiden havaitseminen, sekä uudelleenkäytettävien komponenttien löytäminen oman työryhmän ulkopuolelta, on vaikeaa.
Poliittiset esteet
Uudelleenkäytettäviä koponentteja kehittäviä työryhmiä vieroksutaan ja pidetään eräänlaisina kilpailijoina.
Psykologiset esteet
Sovelluskehittäjät saattavat katsoa "Top-down"-uudelleenkäyttöponnistuksia hallinnon epäluottamuksena sovelluskehittäjien kykyihin. Lisäksi etenkin kehittyneempien sovelluskehittäjien joukossa on yleistä, että ei edes haluta käyttää mitään sellaista, joka ei ole itse tehtyä.
Tekniset esteet
Sovelluskehittäjien puuttellinen osaaminen tai organisaation systemaattiseen uudelleenkäyttöön riittämätön pätevyys.
4. Tuotteenhallinta
4 Tuotteenhallinta
Ohjelmistotuotteet koostuvat usein useista komponenteista: ohjelmatiedostot, dokumentit jne. Komponenteista kootaan suurempia kokonaisuuksia, konfiguraatioita.
Komponentit ja konfiguraatiot kehittyvät jatkuvasti virheiden korjaamisen ja uusien ominaisuuksien toteutuksen seurauksena, komponenteista voidaan koostaa erilaisia konfiguraatioita eri tarkoituksiin ja toisinaan saattaa tulla tarvetta jatkokehittää jotain vanhaa konfiguraatio- tai komponenttiversiota. Muunmuassa näistä tarpeista huolehtii tuotteenhallinta (configuration management), joka voidaan jakaa kolmeen osakokonai suuteen:
1. Menetelmät, joilla saman komponentin eri versiot hallitaan 2. Menetelmät, joilla konfiguraatioita ja niiden versioita hallitaan
3. Versioita ja konfiguraatioita luotaessa ja muutettaessa noudatettavat toimintatavat [Haikaia&Märijärvi 1998].
Ghezzi et ai. määrittelevät tuotteenhallinan teoksessaan Fundamentals of Software Engineering [Ghezzi et ai. 1991] seuraavasti:
Coordinating software development and controlling the change and evolution of software products and components.
4.1 Käsitteet
Ohjelmistotuote koostuu komponenteista, joita ovat esimerkiksi ohjelmatiedostot ja dokumentaatio. Komponentit voivat olla johdettuja (derived), jolloin ne luodaan joko automaattisesti toisista komponenteista (esimerkiksi lähdekooditiedostosta johdettu objektitiedosto), tai ihmisen interaktion välityksellä (esimerkiksi teknisestä määrittelydokumentista johdettu lähdekoodi tiedosto). Komponenteista muodostetaan konfiguraatioita, jotka voivat komponenttien lisäksi sisältää myös muita konfiguraatioita. Hallinta-alkio (configuration item) on yhteinen nimitys komponenteille ja konfiguraatioille. Hallinta-alkiosta muodostetaan versio, kun halutaan jäädyttää se siten, ettei kyseiseen versioon tehdä enää koskaan muutoksia, vaan kaikki muutokset tehdään vielä jäädyttämättömiin hallinta-alkion versioihin.
Kehitysprojektin aikana hallinta-alkion viimeisintä jäädytettyä versiota kutsutaan vaihetasoksi (baseline). Vaihetasoa pidetään eräänlaisena keskustietokantana, josta kehitysprojektiin osallistuvat henkilöt hakevat hallinta-alkioiden viimeisimmät versiot omassa yksityisessä työ-ympäristössä muuteltavaksi. Muutosten jälkeen hallinta-alkiot, joihin muutoksia tehtiin, liitetään takaisin vaihetasoon.
Hallinta-alkioiden versio tunnistetaan hallinta-alkioon liittyvän versionumeron avulla.
Versionumeroita luodaan sovitun järjestelmän mukaisesti (esimerkiksi 1.0, 1.1 jne).
Tuotteenhallintaan liittyy myös jäljitettävyys (traceability). Jäljitettävyydellä tarkoitetaan ohjelman komponenttien versioiden tunnistamista ohjelmaversion perusteella ja toisaalta tietoa siitä, missä kaikissa ohjelmakonfiguraatioissa komponentti on mukana [Haikala&Märijärvi 1998],
4. Tuotteenhallinta
4.2 Versionhallinta
Versionhallinnan päätavoitteena on helpottaa tuotekehitystä monen tuotekehittäjän ympäristössä. Versionhallintaa käyttämällä helpotetaan muunmuassa monen kehittäjän samanaikaiset samaan komponenttiin liittyvien muutoksien tekemistä, ylläpidetään versiohistoriaa ja synkronoidaan versionhallintaan liitetyt komponentit tuotekehittäjien kehitysympäristöihin.
Versionhallinta voi olla tiedostopohjaista, ohjelmointikielipohjaista tai tietokantapohjaista [Conradi&Westfechtel 1998]. Tiedostopohjaisessa versionhallinnassa versionhallinnan alle liitetään ohjelmakomponentteja aina ohjelmakooditiedosto kerrallaan. Ohjelmointikielipohjaisessa versionhallinnassa versionhallintaan liitetään ohjelmamoduuleita ja niiden välisien riippuvuuksien kuvauksia. Tietokantapohjaisessa versionhallinnassa versioidaan tietokannan olioita ja niiden välisiä suhteita.
Versionhallinta ylläpitää hallinta-alkioiden versiopuita. Versiopuut koostuvat kaikista hallinta-alkion versioista siten, että puun juurena on kyseisen hallinta-alkion ensimmäinen versio, mistä versiopuu kasvaa useimmiten lineaarisesti peräkkäisiä versioita pitkin (joita kutsutaan myös revisioiksi). Joskus versiopuuhun joudutaan tekemään sivuhaaroja (branch), eli variaatioita. Variaatioita joudutaan tekemään kun esimerkiksi asiakas haluaa jostain vanhasta versiosta sellaisen version, joka on muutoin täsmälleen sama kuin jokin vanha versio, paitsi että siinä on korjattu jokin ohjelmointivirhe tai lisätty jokin ominaisuus. Variaatioita on syytä välttää kaikin keinoin, sillä virheen korjaaminen versiopuun mihin tahansa jäädyttämättömään versioon saattaa vaatia kyseisen virheen korjaamista myös kaikkiin muihin jäädyttämättömiin versioihin (myös variaatioista luotaviin uusiin versioihin).
Versionhallinnan avuksi on kehitetty useita ohjelmistoja. Näitä ovat mm. SCCS (Source Code Control System), RCS (Revision Control System) sekä Microsoft Visual SourceSafe, joista viimeisintä käytetään tämän diplomityön esimerkkiversionhallintaohjelmistona.
4.3 Microsoft Visual SourceSafe
Microsoft Visual SourceSafe (jatkossa SourceSafe) [Microsoft 2000] valittiin diplomityön esimerkkiversionhallintaohjelmistoksi, koska sitä on jo käytetty menestyksekkäästi Must Modeller-ohjelmiston tuotekehityksessä. Seuraavassa lyhyt esittely SourceSafem käytöstä erilaisissa versionhallinnan tilanteissa.
SourceSafe:n käyttö aloitetaan luomalla uusi projekti, jolloin SourceSafe luo projektille tyhjän tietokannan. Tämän jälkeen tietokantaan voidaan lisätä uusia tiedostoja. Kun tiedosto lisätään SourceSafem projektiin, merkitään se automaattisesti read-only tilaan, jolloin käyttäjä ei voi tehdä siihen muutoksia. Kun tiedostoon halutaan tehdä muutoksia, tehdään sille SourceSafem projektissa check out-operaatio, jonka seurauksena käyttäjän levyllä aiemmin ollut read-only tiedosto muuttuu muuteltavaan muotoon, tai mikäli tiedostoa ei aiemmin ollut käyttäjän levyllä kopioidaan se SourceSafem tietokannasta käyttäjän levylle. Jos joku muu käyttäjä oli jo tehnyt check out-operaation tiedostolle (multiple check out-tilanne), ilmoittaa SourceSafe tästä käyttäjälle, ja lisäksi, riippuen
4. Tuotteenhallinta projektin asetuksista, estää kokonaan uuden check out-operaation, tai antaa käyttäjälle mahdollisuuden perua check out, tai jatkaa check out-operaatiota muiden tekemistä check out-operaatioista huolimatta.
Kun tiedostoon ei enää tehdä muutoksia, siirretään tiedosto takaisin SourceSafem tietokantaan check /«-operaatiolla, jolloin käyttäjälle annetaan mahdollisuus liittää check in-operaatioon jokin kommentti (jossa voidaan esimerkiksi kertoa lyhyesti mitä muutoksia tehtiin). Kommentin antamisen jälkeen SourceSafe tarkistaa, että oliko SourceSafem vastaavaan tiedostoon tehty muutoksia jonkun toisen käyttäjän toimesta sen jälkeen kun käyttäjä oli tehnyt check out-operaation. Jos muutoksia löytyi, suoritetaan znerge-operaatio, jolloin SourceSafe yrittää automaattisesti päätellä kuinka tehdyt muutokset yhdistetään toisiinsa uudeksi tiedostoksi. Jos automaattinen muutosten yhdistäminen ei onnistu (näin käy usein esimerkiksi silloin, jos muutoksia oli kummassakin yhdistettävässä tiedostossa tehty samalle riville), tai käyttäjä niin haluaa, annetaan käyttäjälle mahdollisuus suorittaa muutosten yhdistäminen käsin, joko erillistä SourceSafem mukana tulevaa Visual Merge-apuohjelmaa tai käyttäjän itse valitsemaa ohjelmaa käyttäen. Jos käyttäjä haluaa perua tekemänsä tiedostoon tekemänsä muutokset ennen check in-operaatiota, voi hän perua muutokset undo (check out)- operaatiolla.
Käyttäjän levyllä olevat tiedostot synkronoidaan SourceSafe-tietokannan tiedostojen kanssa get (latest version)-operaatiolla.
SourceSafem projektiin kuuluvia tiedostoja voidaan jakaa useiden SourceSafem projektien kanssa share-operaatiota käyttäen, jolloin SourceSafe:ssa on jokaista usean projektin kesken jaettua tiedostoa kohden aina yksi ainoa tiedosto. Kun tähän yhteen tiedostoon tehdään muutoksia, näkyvät muutokset välittömästi kaikissa projekteissa, joihin tiedosto on jaettu. Kun halutaan luoda mistä tahansa tiedostosta uusi variaatio, täytyy projektin tiedostot ensiksi jakaa uuden projektin kanssa, jonka jälkeen suoritetaan branch-operaatio tiedostolle josta uusi variaatio halutaan luoda.
SourceSafe perustuu reverse delta-teknologiaan, missä versionhallintaan liitetystä tiedostosta säilytetään aina viimeisin versio, sekä siihen tehdyt muutokset aikaisempiin versioihin nähden [Microsoft 1998a]. Tämä mahdollistaa minkä tahansa hallinta-alkion vanhan version hakemisen, tiedoston versiohistorian selaamisen, muutosten tarkastelun jne.
5. Rakenteellisen tiedoston analysointi
5 Rakenteellisen tiedoston analysointi
Rakenteellista tiedostoa, esimerkiksi C++-lähdekooditiedostoa, analysoidessaan, tulkki (interpreter) muuttaa tiedoston merkkijonovirran tokenivirraksi leksikaalisessa analyysissä. Leksikaalisen analyysin jälkeen tulkki muodostaa tokeni virran mukaisen, usein puumuotoisen, abstraktin syntaksin (abstract syntax [Appel 1998]) syntaksi- analyysissä. Syntaksin analysoinnin jälkeen tulkki tarkistaa, että kaikki muuttujaviittaukset ovat laillisia ja tekee tyyppi-ja muita semanttisia tarkistuksia.
Tämän jälkeen tulkilla on käsitys tiedoston sisällöstä, joten se voi esimerkiksi kääntää sisäisen kuvauksen jollekkin toiselle kielelle (esimerkiksi assembleriksi monissa C++- kääntäjissä), tai alkaa suorittamaan tiedostossa kuvattua ohjelmaa (erilaiset tulkittavat ohjelmointikielet, esimerkiksi Must:in laskentasääntökieli).
5.1 Yhteysvapaat kieliopit
Yhteysvapaat kieliopit (context-free grammar) koostuu vat neljästä osasta:
1. Kielen atomisia symboleja kuvaavat terminaalisymbolit.
2. Nonterminaalit jotka kuvaavat kielen rakenteita.
3. Säännöt (produktiot) kuvaamaan rakenteiden komponentteja. Kaikissa säännöissä on nonterminaali vasemmalla puolella, symboli ::=, ja lista terminaaleja ja nonterminaaleja oikealla puolella.
4. Aloitusnonterminaali, joka kuvaa kielen rakenteen [Sethi 1997].
5.2 BNF notaatio
Backus-Naur-Form (BNF) on yhteysvapaiden kielien kuvauskieli, jota käytetään ohjelmointikielten syntaksin määrittelyyn. BNF kehitettiin alun perin Algol-60 ohjelmointikielen kuvaamiseen.
BNF:n säännöt ovat muotoa:
nonterminal ::= option\ \ optioni |...
Kukin vaihtoehto option„ määrittelee välisymbolille nonterminal yhden säännön.
BNF:sta on tehty monia erilaisia laajennoksia, joita kutsutaan myös nimellä EBNF tai Extended BNF. Esimerkiksi seuraavia laajennoksia on käytetty:
- Aaltosulut, ‘{‘ ja ‘}’, edustavat nollaa tai useampaa toistoa.
Hakasulut, ‘[‘ ja *]’, edustavat vaihtoehtoista rakennetta.
Sulkuja, ‘(‘ ja ‘)\ käytetään ryhmittelyyn [Sethi 1997].
5. Rakenteellisen tiedoston analysointi
5.3 Äärelliset automaatit
Äärelliset automaatit ovat eräänlaisia merkkijonon tunnistuslaitteita, joiden ainoa tehtävä on joko hyväksyä tai hylätä niille syötetty merkkijono. Äärellinen automaatti lukee merkki kerrallaan “syöttönauhaa”, joka sisältää syöttömerkkijonon merkit. Aina merkin luettuaan, äärellinen automaatti vaihtaa sisäistä tilaansa sen mukaan mikä luettu merkki oli. Kun koko nauha on luettu loppuun, merkkijono joko hyväksytään tai hylätään sen mukaan, onko äärellisen automaatin tila yksi lopputiloista.
Deterministisellä äärellisellä automaatilla (Deterministic Finite Automata) tarkoitetaan edellämainitun kaltaista automaattia, jolla on aina luettuaan yhden merkin nauhalta, ainoastaan yksi mahdollinen seuraava tila. Epädeterministisellä äärellisellä automaatilla (Nondeterministic Finite Automata) tarkoitetaan automaattia, jolla voi olla useita seuraavia tiloja [Lewis&Papadimitriou 1981].
Deterministinen äärellinen automaatti koostuu viidestä osasta:
1. Automaatin tilat.
2. Automaatin hyväksymä merkistö.
3. Alkutila.
4. Lopputilat.
5. Siirtymäfunktio, eli merkin, tilan ja tilan johon siirrytään, yhdistelmä.
Epädeterministinen äärellinen automaatti koostuu muutoin samoista osista kuin deterministinenkin, paitsi että siirtymäfunktion tilalla on siirtymärelaatio, johon kuuluu tila, merkistöstä muodostettu merkkijono sekä tila johon siirrytään.
Esimerkki
Kuvassa 5 esitetty äärellinen automaatti tunnistaa kaikki merkkijonot jotka alkavat a:lla, ja jonka jälkeen tulee merkkijonoja b, cd, cdb, cdbcd jne.
mielivaltainen määrä mielivaltaisessa järjestyksessä. Esim. a, abcd, abbcdcdb.
d
Kuva 5: Esimerkki äärellisestä automaatista
5.4 Säännölliset lausekkeet
Säännölliset lausekkeet ovat erilaisten merkkijonojen tunnistamiseen käytettäviä merkkijonojen hahmoja (pattern). Säännölliset lausekkeet ovat yksinkertaisimmillaan seuraavan BNF-kuvauksen mukaisia:
5. Rakenteellisen tiedoston analysointi
regexp ::= regexp “|” regexp ; vaihtoehtoisuus 1 regexp regexp ; peräkkäisyys
regexp* ; toisto
“(“ regexp “)”
a
; ryhmittely
missä a on mikä tahansa syöteaakkoston merkki. Operaattorit on annettu niiden kasvavan presedenssin järjestyksessä [Aho et ai. 1986], Mikä hyvänsä säännöllinen lauseke voidaan esittää myös äärellisenä automaattina, ja mikä hyvänsä äärellinen automaatti vastaavasti säännöllisenä lausekkeena [Lewis&Papadimitriou 1981].
Esimerkki
Kappaleessa 5.3 esitettyä äärellistä automaattia vastaava säännöllinen lauseke on a(b\cd)*.
5.5 Leksikaalinen analysointi
Rakenteellisen tiedoston analysoinnissa ensimmäinen vaihe on usein leksikaalinen analyysi. Leksikaalisessa analyysissä selaaja (lexer) tunnistaa merkkejä sisältävästä syötetietovirrasta yhteenkuuluvien merkkien jonot (lekseemit) ja muodostetaan niitä vastaavat tokenit uloslähtevään tokenivirtaan. Selaaja ohittaa tarvittaessa merkityksettömät merkit (white space) sekä syötetietovirran sisältämät kommentit ja antaa tunnistamattomista merkeistä virheilmoituksen.
Joissakin tapauksissa syötetietovirran selaus voidaan jakaa kahteen vaiheeseen:
“skannaukseen” ja leksikaaliseen analysointiin. Skannausvaiheessa syötetietovirralle tehdään yksinkertaisia muunnoksia, kuten merkityksettömien merkkien poistaminen, leksikaalisen analyysin vastatessa varsinaisesta lekseemien tunnistamisesta, ja tokenien luomisesta.
Selaaja tunnistaa tokenin tyypin lekseemeistä vertaamalla niitä tokenien hahmoihin, jotka ovat useimmiten säännöllisiä lausekkeita, jotka tunnistavat tokenin tyyppiset merkkijonot muista merkkijonoista.
Esimerkki
Olkoon c-kielinen syötemerkkijono:
if (c > 0) return “Jep!”;
C-kääntäjän selaaja voisi tuottaa tästä merkkijonosta esimerkiksi taulukossa 1 esitetyn tokenijonon.
5. Rakenteellisen tiedoston analysointi Tokenin tunniste Tokenin arvo Lekseemi Hahmo
if if if
lparen ( (
id c c [a-z][a-z0-9]*
relop GT > <>>=<= == !=
integer 0 0 [0-9]*
rparen ) )
return return return
string Jep! “Jep!”
semicolon ; ;
Taulukko 1: Esimerkki leksikaalisesta analysoinnista
Selaajan koodaaminen käsin on työlästä, ja käsin koodattuna sen muutteleminen myöhemmin on hankalaa. Selaimen tekemiseen onkin olemassa useita apuohjelmia, jotka generoivat selaimen lähdekielisen koodin äärellisestä automaatista. Generoitu äärellinen automaatti tunnistaa erillisessä kuvaustiedostossa määritellyt hahmot ja suorittaa niille määritellyt toiminnot (jotka useimmiten määrittelevä sidonnan lekseemin ja tokenin välille).
5.6 Syntaksin analysointi
Syntaksin analysoinnin tavoitteena on muuntaa leksikaalisen analysoinnin tuloksena saatu tokeni virta sellaiseen muotoon, että sitä on helppo käsitellä analysoinnin myöhemmissä vaiheissa, samalla tarkastaen annetun tokeni virran kieliopin sääntöjen mukaisuus. Käytännössä tämä tarkoittaa jonkinlaisen abstraktin syntaksin (esimerkiksi abstraktin syntaksipuun) muodostamista.
Syntaksin analysoinnista vastaa jäsentäjä (parser). Jäsentäjä pyrkii selvittämään annetun tokenivirran rakenteen, eli sen kuinka kieliopista voidaan johtaa (derive) annettu syöte.
Käytännössä tämä tapahtuu jäsennyspuun avulla. Jäsennyspuu muodostetaan siten, että jokaista tokenivirrasta luettua tokenia kohden luodaan jäsennyspuuhun oma solmunsa.
Solmun paikka lopullisessa puussa riippuu jäsentäjän kieliopista. Jäsennyspuu kuvaa annetun syötevirran konkreettista syntaksia [Appel 1998].
Koska syötevirta sisältää useita tokeneita, joita tarvitaan ainoastaan syötevirran jäsentämiseen, voidaan konkreettisesta syntaksista poistaa nämä analysoinnin myöhemmissä vaiheissa turhat rakenteet kokonaan. Tällaisia rakenteita ovat mm. monet erilaiset välimerkit ja kieliopista riippuvat jäsennyksen avuksi luodut rakenteet. Kun nämä myöhemmissä vaiheissa turhat rakenteet poistetaan, jää jäljelle abstrakti syntaksi, joka sisältää jäsennetyn syötetiedoston lauserakenteen, jonka semanttista oikeellisuutta
ei ole vielä tarkastettu.
Kuten selaajissakin, vähänkään monimutkaisempien jäsentäjien koodaaminen käsin ei ole järkevää. Syynä tähän ovat työläys ja myöhemmin tehtävien muutosten tekemisen vaikeus. Jäsentäjien automaattiseen muodostamiseen on tehty useita erilaisia apuohjelmia, niinkutsuttuja jäsenningeneraattoreita. Muodostettavan jäsentäjän kielioppi annetaan näille ohjelmille usein EBNF:n kaltaisella kuvauskielellä.
5. Rakenteellisen tiedoston analysointi
5.7 Semantiikan analysointi
Viimeisenä vaiheena rakenteellisen tiedoston analysoinnissa on usein semantiikan analysointi. Semantiikan analysointivaiheessa syntaksin analysointivaiheesta saadulle abstraktille syntaksille tehtävät asiat riippuvat läheisesti siitä, mihin käyttötarkoitukseen tiedostoa ollaan analysoimassa. Yleisiä, useisiin eri loppukäyttötarkoituksiin soveltuvia tehtäviä ovat erilaiset tyyppitarkastukset, nimitarkastukset ja optimoinnit. Jos analysointia tehdään esimerkiksi ohjelmointikielen kääntäjää varten, tässä vaiheessa tehdään myös mm. erilaisia kontrollivuotarkastuksia ja muuttujanimien sidontoja niiden määrittelyihin.
Tyyppitarkastuksissa voidaan tarkastaa esimerkiksi, että funktioiden parametreksi ja attribuuttien arvoiksi annetaan oikean tyyppisiä arvoja, eikä esimerkiksi henkilön nimi- attribuuttiin yritetä laittaa numeroa, tai henkilön ikä-attribuuttiin merkkijonoa.
Nimitarkastuksilla varmistetaan funktioiden ja muuttujien nimien virheettömyys.
Optimoinneissa pyritään poistamaan abstraktista syntaksista turhia rakenteita ja muuttamaan tehottomia rakenteita tehokkaampiin.
6. Must
6 Must
Tässä kappaleessa esitellään lyhyesti Must ohjelmiston historiaa, sen ominaisuuksia, toimintaympäristöä sekä käyttäjiä. Kappaleen tarkoituksena on antaa lukijalle selkeä käsitys taustoista ja syistä, joiden johdosta diplomityötä on lähdetty tekemään, sekä esitellä ohjelmisto, johon diplomityön tuloksia lopulta tullaan soveltamaan.
6.1 Historiaa
Must perustuu Nokian Tutkimuskeskuksessa 1986 aloitettuun oliopohjaiseen Stratex tuotteseen, joka valmistui päätöksenteon tukijärjestelmien rakentamiseen tähtäävän projektin tuloksena. Stratex on Unix-pohjaisessa käyttöympäristössä toimiva CommonLisp-ohjelmointikielellä toteutettu oliopohjainen mallinnusohjelmisto, joka on erityisesti suunnattu strategisen suunnittelun tarpeisiin. Stratex ei kuitenkaan soveltunut riittävän hyvin sovelluskehittäjien tarpeisiin, joten päätettiin kehittää kokonaan uusi ohjelmisto uudessa ympäristössä, uudella ohjelmointikielellä. Tämän uuden ohjelmiston nimeksi valittiin Must, joka tulee sanoista MUlti-purpose System Modelling Tool.
Tämän työn ohjaaja, Teemu Lehto, on esitellyt Mustin kehitystyötä diplomityössään [Lehto 1995],
Vuodesta 1992 lähtien Mustin kehitystyötä tehtiin vuonna 1992 perustetussa ViSolutions Oy:ssä. Joulukuussa 1996 ICL Data Oy osti ViSolutions Oy:n osakepääoman, ja 1.9.1997 ViSolutions Oy fuusioitiin ICL Data Oy:öön. 1.9.1999 seitsemän Mustiin parissa ICL Data Oyissä työskennellyttä henkilöä perustivat Planway Oy:n ja ostivat Must-tuotteen ICL Data Oyiltä. 1.1.2000 Planway Oy yhdistettiin European Business Institute (EBI):een ja EBI yhdistettiin 14.2.2000 edelleen QPR Softwareen.
Mustiilla on tehty ViSolutions Oyin, ICL Data Oyin, Planway Oyin ja EBIin asiakkaille mm. raportointi-, budjetointi-, laatu-, logistiikka-, ympäristö- ja yrityspelisovelluksia.
Must toimii 32 bittisillä Microsoft Windows-käyttöjärjestelmällä varustetuissa PC- mikrotietokoneissa. Must on ohjelmoitu C++-kielellä käyttäen Borlandin ja Microsoftiin C++-kehitysympäristöjä sekä Intersolvin C++/Views- ja Microsoftiin MFC- luokkakirjastoja.
Vuonna 1997 Sami Rosendahl suunnitteli ja toteutti diplomityönä Mustiissa nykyisin käytössä olevan oliotietokannan [Rosendahl 1997],
Edellämainittujen lisäksi Martti Paajanen on tehnyt lisensiaattityön hajautetusta ongelmanratkaisusta Must-ympäristössä [Paajanen 1996], sekä Magnus Olander väitöskirjan Mustilla toteutetusta Mefstrat-projektista [Olander 1998].
Allekirjoittanut on ollut Mustiin tuotekehityksessä mukana 1.6.1996 lähtien.
