TEKNILLINEN KORKEAKOULU Tietotekniikan osasto
Teknillisen fysiikan koulutusohjelma
Erkki Ruohtula
SDL-kuvauskielen käyttö ohjelmoinnissa
Diplomityö tehty tietokonetekniikan syventymiskohteessa
Työn valvoja Professori Olli Simula Työn ohjaaja TkT Markus Lindqvist
Helsinki 31.10.1991
TEKNILLINEN KORKEAKOULU DIPLOMITYÖN TIIVISTELMÄ Tekijä: Erkki Ruohtula
Työn nimi: SDL-kuvauskielen käyttö ohjelmoinnissa Title in English: Using the SDL Specification Language
for Programming
Päivämäärä: 31.10.1991 Sivumäärä: 91 s
Osasto: Tietotekniikan osasto Professuuri: Tik-61
Laitos: Teknillisen fysiikan laitos tietokonetekniikka Työn valvoja: Professori Olli Simula
Työn ohjaaja: TkT Markus Lindqvist, Telenokia
Diplomityö alkaa yleisesityksellä CCITT SDL-kuvauskielestä. Tämän jälkeen tarkas
tellaan ongelmia, joita kohdataan käytettäessä SDL-kuvauskieltä ohjelmointikielenä, ja näiden ongelmien erilaisia käytännön ratkaisuja. Erityisesti käsitellään Telenokia Oy:ssä toteutettua TNSDL-järjestelmää, jonka suunnitteluun ja toteutukseen tekijä on osallistunut. Tämä järjestelmä toteuttaa erään muunnelman SDL-suosituksen kie
lestä, ja työ esittää TNSDL-järjestelmässä tehtyjen ratkaisujen perusteet Telenokian käyttämän metodologian ja ohjelmointikäytön vaatimuksista lähtien. Järjestelmän to
teutustavasta annetaan yleiskuvaus. Lopuksi esitetään käyttökokemuksia, jotka tuke
vat oletusta, että SDL-kielen ohjelmointikäyttö lisää työn tuottavuutta. Menestyksel
linen ohjelmointikäyttö edellyttää kielestä toteutusta, joka pystyy ottamaan huomioon kohdeympäristön ominaisuudet ja yleensäkin toteutusläheiset yksityiskohdat, sekä so
peutumaan käytettyyn kehitysympäristöön.
Avainsanat: SDL-kuvauskieli ohjelmointi
Alkusanat
Tämä työ on tehty Telenokialta, yleisten televerkkojen menetelmäkehitysosastolta. Tek
nillisen korkeakoulun puolesta valvojana on toiminut professori Olli Simula, jota kiitän työtäni kohtaaan osoittamastaan mielenkiinnosta. Työn ohjaajana toimi menetelmäke
hitysosaston päällikkö, TkT Markus Lindqvist. Häntä tahdon kiittää mahdollisuudesta tehdä tämä työ sekä häneltä työn kestäessä saamastani kannustuksesta, kritiikistä ja hy
vistä neuvoista.
Haluan kiittää kaikkia työtovereitani menetelmäkehitysosastolta reilusta työilmapiiristä ja avusta erinäisissä asioissa. Erityisesti on mainittava TNSDL:n kehittämiseen eri tavoin osallistuneet Peter Hjort, Esa Kettunen, Kari Latva-Hoppala, Jørgen Nørgaar d-Peder- sen ja Heikki Tuominen. Kiitän myös niitä lukuisia TNSDL-kielen käyttäjiä, joilta olen saanut palautetta.
Vanhempiani kiitän jatkuvasta opintojeni tukemisesta ja rohkaisemisesta. Heillä on ollut niihin toisinaan enemmän uskoa kuin minulta. Kiitos!
Helsingissä 27.10.1991
Erkki Ruohtula
Sisältö
1 Johdanto 1
2 Kuvauskieli SDL 2
2.1 Yleistä... 2
2.2 Perusajatus... 3
2.3 Kielen esitystavat... 4
2.4 SDL-88 ... 7
2.4.1 Yleisistä säännöistä... 7
2.4.2 Lohkojako... 7
2.4.3 Kanavat ja sanomareitit... 10
2.4.4 Prosessi... 11
2.4.5 Toimintalauseet... 14
2.4.6 Proseduurit... 18
2.4.7 Palveluhajotelma... 20
2.4.8 Sanomien määrittely... 21
2.4.9 Muuttujien määrittely... 22
2.4.10 Vaihtoehtoiset kommunikointitavat... 22
2.4.11 Tietotyyppien määrittely... 23
2.4.12 Ennaltamääritellyt tyypit ja lausekkeet... 25
2.4.13 Makrot ja valintamäärittelyt... 27
3 Ongelmat ohjelmointikäytön kannalta 29 3.1 Syistä... 29
3.2 Kääntäminen kohdekoneelle... 29
3.3 Nimet ja näkyvyys... 30
3.4 Rinnakkaisprosessointi... 30
3.5 Prosessien välinen kommunikointi... 32
3.6 Automaatit... 33
3.7 Optimointi... 35
3.8 Epämuodolliset osat ... 36
3.9 Tietotyypit ... 37
3.10 Tiedon esitystapa sanomissa... 37
3.11 Graafisen ja tekstuaalisen esityksen suhde ... 38
3.12 Sekalaiset järjestelmäriippuvuudet... 39
3.12.1 Viittaukset SDL:n ulkopuolelle ... 39
3.12.2 Datan osoitus... 39
3.12.3 Vikasietoisuus... 39
4 Eräitä toteutuksia 40 4.1 TNCODE... 40
4.2 OKI •... 41
4.3 PKI SDL ja ISDL... 41
4.4 VERILOG GEODE... 42
4.5 Telesoft SDT ... 43
5 TNSDL 45 5.1 TNSDL-kielen ja CCITT-suosituksen erojen syistä... 45
5.2 DX 200-järjestelmän käsitemalli... 46
5.3 Käsitemalli ja TNSDL-kieli... 48
5.3.1 Lohkorakenne... 48
5.3.2 Palveluesittelyt... 52
5.4 Toteutettavuus: tyyppijärjestelmä... 53
5.4.1 Alkeistyypit... 53
5.4.2 Uusien tyyppien määrittely ... 55
5.4.3 Operaattorit... 59
5.4.4 Operaattorit encode ja decode... 59
5.4.5 Ennaltamääriteltyjä ei-alkeistyyppejä...60
5.4.6 Tyyppien yhteensopivuus ... 61
5.5 Toteutettavuus: Sanomat ... 62
5.6 Ajoympäristön vaikutus kieleen... 62
5.6.1 Muistin osoitus... 63
5.6.2 Lämmitysmääreet... 63
5.6.3 Transitioiden paikalliset muuttujat... 64
5.6.4 Lisätyt ennaltamääritellyt muuttujat... 65
5.6.5 Lähetysattribuutit ... 65
5.7 Käyttäjien toiveet ja ohjelmointikäyttö... 65
5.7.1 Toistolause ... 65
5.7.2 Jatkolähetys... 66
5.7.3 Proseduurin semantiikka... 66
5.7.4 Tiedoston sisällytys... 67
5.7.5 Leksikaaliset säännöt... 67
5.8 Toteutus... 68
5.8.1 Valinnoista ... 68
5.8.2 Translaattorin rakenne... 69
5.8.3 Tuotettujen prosessien rakenne ... 71
5.8.4 Sanomien käsittely... 72
5.8.5 Tyyppien kääntäminen... 73
5.8.6 Translaattorin muut toiminnot ... 74
5.9 Käyttökokemuksia ... 74
5.9.1 Käytön laajuus... 74
5.9.2 Eduista ... 75
5.9.3 Ongelmista... 76
6 Eri toteutusten vertailua 78
7 Yhteenveto 79
Viitteet 80
Liitteet 85
A Lyhenteet 85
В Näyte koodintuotosta OKI:n SDL—toteutuksessa 86
C Näyte koodintuotosta TNSDL-translaattorissa 88
1 Johdanto
SDL (Spesification and Description Language) on kansainvälisen tietoliikennealan elimen CCITT:n (Comité Consultatif International Télégraphique et Téléphonique) standardoi
ma ja suosittelema määrittely- ja suunnittelukieli.
Tämä työ lähti tarpeesta koota yhteen tietoa SDL-kielen ohjelmointikäytössä esiintyvistä ongelmista ja niiden ratkaisuista. SDL ei ole varsinaisesti ohjelmointikieli, mutta sen poh
jana käytetty ajatusmalli sopii hyvin simuloitavissa olevien kuvausten tekoon, ja tästä on lyhyt matka sen suoraan käyttöön todellisen toteutuksen teossa. Useita toteutuskäytössä avustavia järjestelmiä onkin kehitetty, yleensä laajemman SDL-tukiympäristön osana.
SDL-kieltä on käytetty Telenokia Oy.ssä suunnittelun apuvälineenä 1970-luvun lopulta lähtien. Tätä on avustettu ohjelmilla, jotka muuntavat SDL-kieltä tekstiesityksestä graa
fiseen muotoon [54]. Itse tehty graafinen editorikin on ollut käytössä. SDL-kuvauksia on on myös melko pitkään käytetty suoraan ohjelmien tekoon. SDL-kuvauksista on tuotettu PL/M-kielisiä ohjelmarunkoja yhtiössä kehitetyllä työkalulla [43]. Näitä on sitten käsin täydennetty kokonaisiksi ohjelmiksi. Kyseiset työkalut perustuvat vanhaan, vuoden 1980 suosituksen [8] mukaiseen kieleen, eivätkä ne tue datan käsittelyä.
Vuonna 1988 ryhdyttiin Telenokiassa selvittämään kehittyneemmän SDL-88 -suosituksen [10] mukaisen kielen käyttöä. Lopputuloksena määriteltiin siitä muunnelma, TNSDL, jossa CCITT:n kieltä on muokattu tukemaan suoraan Telenokia ohjelmistokehityksessä käytettävää käsitemallia ja muokkamalla tyyppijärjestelmää helpommin automaattisesti toteutettavaksi.
Tämän määrittelyn pohjalta lähdettiin keväällä 1989 toteuttamaan translaattoria, joka tuottaa TNSDL-määrittelyistä vastaavia C-kielisiä ohjelmia, sekä muita kieltä tukevia työkaluja. Eräs tämän esityksen tarkoituksista on koota TNSDL-projektissa saatuja ko
kemuksia ja verrata TNSDL-translaattorissa tehtyjä ratkaisuja muihin alan tuotteisiin.
Aihetta sivuavia diplomitöitä ovat [54], joka kuvaa SDL-kieltä tekstiesityksestä graafiseen muotoon kääntävää ohjelmaa, [34], joka vertailee aikanaan saatavilla olleita SDL-tuki- järjestelmiä graafisen editoinnin toimivuuden ja resurssien käytön kannalta, [50], joka selvittää SDL-88:n soveltuvuutta Telenokian tarpeisiin, ja [25], joka kuvaa TNSDL-kie- len tyyppijärjestelmää.
Tämä työ jakautuu seuraaviin osiin: aluksi luvussa 2 esitetään SDL-kuvauskielen pe
rusteet. Luvussa 3 tarkastellaan kieltä ohjelmointikäyttöön sovellettaessa kohdattavia ongelmia ja niiden ratkaisuja. Luvussa 4 esitellään lähemmin eräitä toteutuksia ja luku 5 selostaa yksityiskohtaisesti TNSDL:ssä tehtyjä ratkaisuja. Myös käytännön kokemuk
sia sen käytöstä esitetään. Luku 6 vertaa toteutuksia yleisemmällä tasolla ja yhteenveto on luvussa 7. Liitteissä on esitetty kaksi esimerkkiä eri SDL-toteutusten tuottamasta koodista.
2 Kuvauskieli SDL
2.1 Yleistä
SDL-kielen suunnittelussa tavoitteena oli kieli, joka on
• helppokäyttöinen, helppolukuinen ja helposti opittavissa,
• mahdollistaa yksikäsitteisten määrittelyjen teon tarjouspyynnöissä ja tilauksissa,
• on laajennettavissa,
• sallii erilaisten määrittely- ja suunnittelumenetelmien käytön olettamatta jotain tiettyä metodologiaa.
CCITT suosittelee kielen käyttöä vaatimusmäärittelyyn, järjestelmien määrittelyyn ja suunnitteluun eri yksityiskohtaisuuden tasoilla, testaukseen, ja (luonnollisesti) CCITTrn omien suositusten tekoon [10].
Huomataan, että ohjelmointia ei mainita. Ohjelmointitarkoituksiin CCITT suosittelee CHILL-nimistä kieltä, joka myös on sen piirissä suunniteltu. Sekä SDL että CHILL sai
vat alkunsa, kun ohjelmisto-ongelmia pohtimaan asetettu CCITTrn työryhmä v. 1972 suositteli suunnittelu- ja määrittelykielen, ohjelmointikielen sekä käyttöliittymässä käy
tettävän kielen etsimistä tietoliikennealan tarpeisiin. Näitä kolmea kieltä varten asetettiin työryhmät.
Suunnittelu- ja määrittelykieltä tutkinut ryhmä päätyi suunnittelemaan oman kielen, jo
ka kuitenkin pohjautuu alalla pitkään käytettyihin, äärellisiin automaattehin perustuviin malleihin. Vuonna 1976 julkaistiin suositus, joka määritteli laajennettuihin äärellisiin automaatteihin perustuvan graafisen kuvausmenetelmän, nimeltään SDL. Kuvausten se
mantiikka oli tuossa vaiheessa hyvin epämuodollinen. Kieltä täsmennettiin edelleen vuo
den 1980 suosituksessa, ja pian tämän jälkeen sille määriteltiin myös puhtaasti teksti
muotoinen vaihtoehtoinen esitystapa. Vuoden 1984 suosituksessa kieleen lisättiin mm.
dynaaminen prosessien luonti ja prosessityypin käsite, datan käsittely abstraktien tie
totyyppien avulla ja tarkasti määritelty semantiikka. Vuoden 1988 suosituksessa [10]
SDL-kieleen tuli edelleen joitakin täsmennyksiä ja muutoksia, ja semantiikka määritel
tiin muodollisesti Meta—IV —kielellä [11, 6]. Kielen historiaa ja tehtyjen ratkaisujen syitä käsitellään teoksen [51] alussa.
Muut työryhmät päätyivät myös uusien kielten suunnitteluun. Ohjelmointikieliryhmä te
ki kielen nimeltä CHILL, josta CCITT julkaisi ensimmäisen suosituksen 1980. Tämä on paljolti Modula-2:n kaltainen kieli, jossa on mukana sanomilla tapahtuva prosessien vä
linen kommunikointi. K äy 11 ölii t ty mäkielen MML ensimmäinen suositus julkaistiin 1976.
Tämän kielen tarkoituksena on vakioida keskuslaitteiden operoinnissa käytetty komento
kieli.
Saapuvien sanomien jono u
Prosessi
Kuva 1: SDL-prosessin sanomajono.
2.2 Perusajatus
SÜL perusiuu rinnakkaisesti toimiviin prosesseihin, jotka kommunikoivat keskenään ja ympäristön kanssa sanomilla. Sanomat jaetaan eri tyyppeihin, ja sanomatyyppi voidaan määritellä siten, että se kuljettaa mukanaan dataa. Jokaiseen prosessiin liittyy saapu
vien sanomien jono, joka on kooltaan periaatteessa ääretön. Tästä jonosta prosessi lukee sanomia samassa järjestyksessä kuin missä ne ovat jonoon saapuneet, eli se toimii FIFO- periaatteella (ks kuva 1). Tämän jonon ansiosta kommunikointi on asynkronista; sanoman lähettänyt prosessi voi tarvittaessa jatkaa toimintaansa vastaanottajasta riippumatta.
Prosessin runko on laajennettu tilakone, jossa syötemerkistön muodostavat eri sanomatyy- pit: odottaessaan sanomaa kone on jossain tilassa, joka voi sanoman seurauksena vaihtua.
Tilasiirtymän aikana prosessi voi lähettää sanomia.
Toisin kuin puhtaassa tilakoneessa [2, s 114], se, mihin tilaan tilasiirtymä päättyy, voi tilan ja saapuneen sanoman tyypin lisäksi riippua sanoman mukana tulleesta datasta ja prosessin sisäisistä muuttujista. Lisäksi, mikäli jossain tilassa saapuu sanoma, jolle ei ole tilassa määritelty tilasiirtymää, sanoma yksinkertaisesti poistetaan saapuvien sanomien jonosta tekemättä mitään. Tätä sanotaan implisiittiseksi kulutukseksi. Puhdas tilakone joutuisi vastaaavassa tilanteessa määrittelemättömään tilaan, ”jumiutuisi”.
Puhtaaksi tilakoneeksi SDL-prosessin voisi periaatteessa muuttaa jakamalla tilat muuttu
jien mahdollisten arvojen perusteella osiin, jakamalla dataa kuljettavat sanomatyypit yhtä moneksi dataa sisältämättömäksi sanomaksi kuin erilaisten arvojen yhdistelmiä sanomas
sa voi olla, ja lisäämällä joka tilaan tilasiirtymän implisiittisesti kulutettaville sanomille.
Lopputulos olisi kuitenkin hyvin paljon SDL-prosessia monimutkaisempi ja vaikeampi
Kuva 2: Puhelinteknisiä SDL-symboleja. [8, s 10]
ymmärtää. Helppo ymmärrettävyys on aina ollut tärkeä tavoite SDL-kielessä.
SDL tekee eron prosessityypin ja sen ilmentymän välillä. Samasta prosessityypistä voi olla yhtä aikaa toiminnassa useita ilmentymiä, jotka erotetaan niiden prosessitunnisteen (PId) perusteella. Tämä tilanne vastaa usean saman ohjelman kopion yhtäaikaista ajoa moniajokäyttöjärjestelmissä. Sanomat osoitetaan aina jollekin prosessin ilmentymälle, jota edustaa PId-tyyppinen muuttuja tai sellainen kanava tai sanomareitti, joka johtaa
määrättyyn prosessiin (ks kohta 2.4.3).
2.3 Kielen esitystavat
SDL:n alkuperäinen käyttötapa on melko epämuodollisten kuvausten tekeminen graafises
ti, samaan tapaan kuin ohjelmien suunnittelu vuokaavioiden avulla. Itseasiassa SDL:n graafisen esitystavan ja vuokaavioiden suurin ero on erityiset symbolit tiloille, sanomien vastaanotolle ja lähetykselle. Vanhemmat SDL-suositukset itseasiassa vakioivat myös pienet kuvasymbolit tiloissa esiintyville puhelinteknisille käsitteille. Esimerkki tällaisesta SDL-esityksestä on kuvassa 2. Tekstimuotoinen SDL-esitys kehitettiin lähinnä tietokone- käsittelyn tarpeisiin, mutta siinäkin sallitaan eräissä tilanteissa vapaamuotoinen teksti formaalin sijasta (ei siis vain kommenteissa).
SDL-kuvauksien kahden esitystavan, graafisen ja tekstimuotoisen, takana on yhteinen abstrakti syntaksi. Abstrakti syntaksi kuvaa vain mitä eri rakenteita kielessä on ja miten ne koostuvat alirakenteista. Se ei ota kantaa esitystapakysymyksiin kuten operaattoreiden presedenssiin tai välimerkkeihin [23, s 24]. SDL-suosituksessa [10] abstrakti syntaksi esi
tetään Meta-IV-kielen osajoukon avulla (Meta-IV on osa VDM-määrittelymenetelmää
[б]).
Abstraktia syntaksia vastaava tekstimuotoinen syntaksi (SDL/PR) esitetään suosituk
sessa Backus-Naur-formalismilla (BNF) sekä syntaksidiagrammina (”raidekaaviona”).
SDL/PR muistuttaa ulkoasultaan tavanomaisia ohjelmointikieliä.
Graafinen syntaksi (SDL/GR) esitetään BNF:n muunnelmalla, jossa voi esiintyä kuvan osia ja osakuvien keskinäisiä suhteita määrääviä varattuja sanoja. Normaalien vuokaa- viosymbolien lisäksi graafisessa esityksessä on erikoismerkinnät mm. tiloille ja sanomien vaihdolle. Jotkut asiat, kuten sanomien ja muuttujien esittelyt, esitetään tekstimuodossa myös graafisessa syntaksissa. Kuvassa 3 on graafisessa muodossa esitetty yksinkertainen prosessi, jolla on kaksi tilaa, ja joka vastaanottaa kahdentyyppisiä sanomia. Sanoman digit voi ajatella edustavan näppäimistöltä tulevia merkkejä, joista prosessi kokoaa syö
tettyä numeroa muuttujaan sum. Sanoman give saapuminen saa prosessin lähettämään tuloksen emoprosessilleen ja aloittamaan numeron kokoamisen alusta (prosessissa esiinty
vät rakenteet selviävät tarkemmin jäljempänä).
Kuvan 3 prosessin tekstimuotoinen vastine näyttää tältä:
PROCESS convert ; DCL sum, t Integer;
START;
NEXTSTATE wait;
STATE wait;
INPUT digit(sum);
NEXTSTATE collect;
ENDSTATE wait;
STATE collect;
INPUT digit(t);
TASK sum := 10*sum + t;
NEXTSTATE -;
INPUT give;
OUTPUT result(sum) TO PARENT;
NEXTSTATE wait;
ENDSTATE collect;
ENDPROCESS convert ;
Jatkossa käytän tässä esityksessä enimmäkseen tekstisyntaksia, koska se paremmin sopii SDL:n tarkasteluun ohjelmointinäkökulmasta.
PROCESS convert;
result(sum) TO PARENT collect
sum := 10 * sum +1 DCL sum, t Integer;
Kuva 3: Esimerkki graafisesta esityksestä.
2.4 SDL-88
Seuraa vissa kappaleissa esittelen SDL-kielen viimeisimmän suosituksen piirteitä edellistä yksityiskohtaisemmin.
2.4.1 Yleisistä säännöistä
Kielen tunnuksissa ei kirjaimen koolla ole merkitystä, ja niissä voi olla kirjainten lisäksi numeroita ja useita erikoismerkkejä. Merkkijonovakiot alkavat heittomerkillä ’ ja loppuvat heittomerkkiin. Heittomerkin voi sisällyttää merkkijonoon kahdentamalla se. Komment
tien kirjoittamiseksi on kaksi merkintätapaa. Missä tahansa voi esiintyä kommentteja, jotka alkavat merkkiparilla /* ja loppuvat pariin */. Toinen kommentointitapa on kir
joittaa ennen puolipistettä varattu sana COMMENT ja merkkijonovakio. Tällä on se etu, että sen mahdolliset sijaintipaikat on kiinnitetty kieliopissa, joten kieltä muodosta toiseen muuttavissa ohjelmissa se on tarvittaessa helpompi säilyttää.
2.4.2 Lohkojako
SDL sisältää työkalut myös prosessia laajempien kokonaisuuksien hallintaan.
Ylimmällä tasollaan SDL-kuvaus koostuu järjestelmän määrittelystä. Järjestelmän ul
kopuolella on ympäristö, sisäpuolella joukko lohkoja ja näissä voimassa olevia kanavien (2.4.3), sanomien ja niihin liittyvien sanomalistojen (2.4.8), tietotyyppien (2.4.11), ja makrojen (2.4.13) esittelyjä. Kuvassa 4 on graafisessa muodossa esitetty kaksi lohkoa sisältävän järjestelmän ylin taso.
Lohkoilla on samankaltainen merkitys kuin eräiden ohjelmointikielten moduleilla, eli ne ryhmittelevät esitystä ja rajoittavat esittelyjen näkyvyysaluetta. Lisäksi niillä on merkitys sanomien reitityksen hallinnassa. Tekstuaalisesti lohkon kuuluminen jonkin järjestelmän sisään ilmaistaan viittauksella lohkoon sen nimen perusteella tai kirjoittamalla lohkon määritelmä järjestelmän määritelmän sisään (sama menettely toimii muissakin sisäkkäis
ten rakenteiden tapauksissa).
Myös lohkojen tasolla voi esitellä kanavia, sanomia, sanomalistoja, tietotyyppejä ja mak
roja. Lohkoissa voi lisäksi esitellä prosesseja, sanomareittejä (2.4.3) ja lohkon alirakenteen.
Alirakennetta käyttämällä voi määritellä sisäkkäisten lohkojen hierarkian ja sillä voi olla paikallisia määrittelyjä.
Alla on tekstimuodossa tarkempi esitys edellä olleen kuvan 4 järjestelmästä exchange, joka sisältää kaksi lohkoa, incoming ja outgoing. Näistä incoming on esitelty muualla, outgoing itse lohkon sisällä. Jälkimmäinen sisältää muualla esitellyn prosessin handler ja alirakenteen details. Sanalla SIGNAL esitellään sanomia, esimerkiksi incoming_call esitellään yhden kokonaisluvun välittäväksi sanomaksi. Sanoilla CHANNEL, SIGNAL-
SYSTEM exchange
SIGNAL incoming_caII(Integer), incoming_ackj\
outgoing_call(Integer), attach(Integer, Integer);
tí LUCK incoming
X
tiLUCK outgoing between[attach]
to_incoming
\ / [incoming_ack]
\z
to.environ [outgoing_call]
Kuva 4: Lohkoja ja kanavia graafisesti esitettynä.
ROUTE ja CONNECT alkavat esittelyt liittyvät kappaleessa 2.4.3 käsiteltyyn sanomien reititykseen.
SYSTEM exchange;
/* Sanomia */
SIGNAL incoming_call(Integer), incoming.ack,
outgoing.call(Integer), attach(Integer, Integer);
/* Kanavia */
CHANNEL to.incoming
FROM ENV TO incoming WITH incoming.call;
FROM incoming TO ENV WITH incoming.ack;
ENDCHANNEL to.incoming;
CHANNEL between
FROM incoming TO outgoing WITH attach;
ENDCHANNEL between;
CHANNEL to.environ
FROM outgoing TO ENV WITH outgoing.call;
ENDCHANNEL to.environ;
/* Lohkoja */
BLOCK incoming REFERENCED; /* Lohko, esitelty muualla */
BLOCK outgoing; /* Lohko, esittely tassa */
SIGNALROUTE to_handler FROM ENV TO handler /* sanomareitteja */
WITH attach;
SIGNALROUTE to.env FROM handler TO ENV WITH outgoing.call;
CONNECT between AND to.handler;
CONNECT to_environ AND to.env;
PROCESS handler REFERENCED;
SUBSTRUCTURE details; /* alirakenne */
SIGNAL'charge ;
CHANNEL to.worker FROM ENV TO worker WITH attach;
ENDCHANNEL to.worker;
CHANNEL to.env FROM worker TO ENV WITH outgoing.call;
ENDCHANNEL to.env;
CONNECT between AND to.worker;
CONNECT to.environ AND to.env;
CHANNEL charges FROM worker TO manager WITH charge ; ENDCHANNEL charges ;
BLOCK worker REFERENCED; /* alirakenteen lohkoja */
BLOCK manager REFERENCED ; ENDSUBSTRUCTURE details;
ENDBLOCK outgoing;
ENDSYSTEM exchange;
Alirakenteen tulkinta on mielenkiintoinen: se on lohkossa mahdollisesti esiteltyihin proses
seihin nähden rinnakkainen kuvaus lohkon toiminnasta, eikä, kuten ensinäkemältä luulisi, osa samaa kuvausta. Ajatus on, että lohko voidaan kuvata ylimalkaisesti joillain proses
seilla, sekä yksityiskohtaisemmin aliraketeiksi hajotettuna. Kuvausta tulkittaessa (”ajet
taessa”) tulkitaan vain alimman tason prosessit, eli prosessit sellaisissa lohkoissa, joissa ei ole alirakennetta. On täysin kuvauksen kirjoittajan vastuulla, että nämä kaksi näkemys
tä ovat merkitykseltään sopusoinnussa. Esimerkiksi edellä esitetyssä SDL-kuvauksessa lohkon outgoing sama toiminta kuvataan sekä prosessilla handler että alirakenteella details.
2.4.3 Kanavat ja sanomareitit
Lohkojen välillä sanomien ajatellaan kulkevat kanavia pitkin, joilla hallitaan sanomien reititystä. Järjestelmässä voi olla ympäristöön johtavia kanavia. Näitä myöten kulkevat sanomat edustavat ympäristöstä tulevia herätteitä ja sinne meneviä vasteita.
Kanavien määrittelyssä annetaan sen päätepisteet (joista toinen voi olla ympäristö) ja luetellaan sen välittämä sanomien joukko. Kanava voi olla yksi- tai kaksisuuntainen ja sen välittämien sanomien joukko voi olla eri suuntiin erilainen. Edellisessä esimerkissä between on yksisuuntainen kanava lohkosta incoming lohkoon outgoing, ja to_incoming on kaksisuuntainen kanava ympäristön ja lohkon incoming välillä.
Kanavan semantiikkaan kuuluu, että se saattaa viivästyttää sanomaa satunnaisen ajan.
Kanava ei kuitenkaan muuta sen kautta kulkevien sanomien järjestystä. Kahden pisteen välillä voi olla useita samoja sanomia välittäviä kanavia. Mikäli sanomia lähetetään eri kanavia myöten samalla välillä, niiden saapumisjärjestys voi muuttua.
Kanavalla voi myös olla alirakenne, jossa sen toiminta esitellään lohkojen ja näiden sisäl
tämien prosessien avulla. Toisin sanoen, kanava korvataan sen päätepisteisiin liittyvillä lohkoilla. Näin voidaan mallittaa kanavaan liittyviä protokollia. Esimerkiksi kanavalle to_environ voisi antaa alirakenteen seuraavasti:
CHANNEL to.environ
FROM outgoing TO ENV WITH outgoing.call;
SUBSTRUCTURE to_environ;
BLOCK packet_handler; REFERENCED;
CHANNEL a
FROM ENV TO packet.handler WITH outgoing.call;
ENDCHANNEL a;
CHANNEL b
FROM packet.handler TO ENV WITH outgoing.call;
ENDCHANNEL b;
CONNECT outgoing AND a;
CONNECT b AND ENV;
ENDSUBSTRUCTURE;
ENDCHANNEL to.environ;
Esittely määrää, että kanavan to_environ sanomat kulkevat lohkon packet_handler kautta. Alirakenteessa voisi olla myös useita paikallisten kanavien yhdistämiä lohkoja.
Kanavan alirakenne ei ole samalla tavalla ongelmallinen kuin lohkon alirakenne, koska kanavaesittely ilman alirakennetta ei yritäkään kertoa kanavasta mitään yksityiskohtia.
Sanomareitti on samantapainen kuin kanava, mutta se voi yhdistää vain kaksi prosessia tai prosessin ja sen ympäristön, eli prosessia ympäröivän lohkon ulkopuolen. Sanomareittiin ei myöskään liity mitään viivettä.
Ympäristöön johtavat sanomareitit liitetään johonkin lohkon ulkopuoliseen kanavaan eri
tyisellä kanava-reitti-liittymällä (channel to route connection). Näistä on esimerkkejä edellä lohkon outgoing alussa.
2.4.4 Prosessi
SDL-prosessin esittely määrittelee prosessityypin, josta voi olla useita yhtäaikaisia ilmen
tymiä. Prosessin otsakkeessa kerrotaan, montako prosessia järjestelmän käynnistyessä luodaan implisiittisesti, ja montako niitä voi enintään olla suorituksessa. Prosessin il
mentymät voivat luoda uusia ilmentymiä. Luonnin yhteydessä lapsi-ilmentymille voi välittää parametreja, jos niitä on esitelty prosessin otsakkeessa. Ilmentymän toimiessa näihin voidaan viitata kuten muuttujiin. Jäljempänä käytetään sanaa ”prosessi” sekä prosessityypeistä että niiden ilmentymistä, mikäli sekaannuksen vaaraa ei ole.
Prosessin otsakkeessa voi esitellä prosessin vastaanottamien sanomien joukon. Tämä esit
tely on pakollinen, mikäli ympäröivässä lohkossa ei ole prosessiin viittaavia sanomareit- tejä. Sanomareittejä käytettäessä sanomien joukko on johdettavissa niistä.
Prosessissa voi esitellä paikallisia tyyppejä, sanomia (joilla on merkitystä palveluhajo- telman tapauksessa, kappale 2.4.7) ja makroja. Lisäksi prosessi voi esitellä muuttujia, ajastimia ja proseduureja (lähemmin kappaleissa 2.4.9, 2.4.5 ja 2.4.6). Alla olevassa kat
kelmassa on prosessin otsake ja joitain esittelyjä. Prosessista accounting ei järjestelmän käynnistyessä luoda yhtään ilmentymää, ja dynaamisesti niitä voi luoda enintään viisi.
Prosessilla on parametrit customer ja good_servi.ce, ja se käsittelee sanomat add ja sub.
Lisäksi esitellään kaksi kokonaislukumuuttujaa, x ja y.
PROCESS accounting (0, 5);
FPAR customer PId,
good_servi.ce Boolean;
SIGNALSET add, sub;
DCL x, у Integer;
ENDPROCESS accounting;
Jokaisella prosessin ilmentymällä on oma vastaanottojono, johon saapuvat sanomat ke
rääntyvät ennen niiden käsittelyä, sekä omat kopiot prosessityypissä esitellyistä muuttu
jista. Prosessi ei voi muuttaa toisen prosessin muuttujia (mutta tietyillä määrittelyillä se voi tutkia niiden arvoja). Muuttujille voi antaa alkuarvon. Prosessin parametrit ovat muuttujia, joiden alkuarvon antaa luova prosessi. Jokaisella prosessilla on joukko en- naltamääriteltyjä PId-tyyppisiä muuttujia (tai funktioita), jotka ovat tarpeen prosessien välisen kommunikoinnin alkuunsaamiseksi. Nämä on lueteltu seuraavassa taulukossa:
Nimi Merkitys
SELF Prosessin oma tunniste.
PARENT
Prosessin luonut prosessi, lämän arvo on NULL, jos prosessi syntyi jär
jestelmän käynnistyksen yhteydessä. NULL on prosessitunnustyypin ainoa vakio, ]a sen merkitys on ”ei mikään prosessi”.
OFFSPRING Viimeksi luotu prosessi. Arvo on NULL, ellei prosessi ole elinaikanaan luo
nut prosesseja.
SENDER Viimeksi vastaanotetun sanoman lähettäjä. Arvo on NULL, ellei prosessi - ole elinaikanaan vastaanottanut sanomia.
Prosessin varsinaisen toiminnan määrittelevä osa koostuu ■prosessi-rungosta.Se alkaa aina aloituspisteen esittelyllä, joka sisältää prosessin suorituksen alkaessa tehtävän tilasiirty- män (eli transition), joka koostuu joukosta suoritettavia lauseita. Tämän tilasiirtymän lopussa yleensä valitaan ensimmäinen tila käyttäen kohdassa 2.4.5 kuvattua seuraajatila- lausetta. Aloituspisteen jälkeen tulee joukko tilojen esittelyjä.
Kustakin tilasta kerrotaan tilassa vastaanotettavat sanomat ja vastaanottoa seuraava ti- lasiirtymä. Voidaan myös määritellä, että jotkut sanomat talletetaan käsiteltäväksi myö
hemmin jossain toisessa tilassa. Kuten kappaleessa 2.2 mainittiin, prosessin ollessa jossain tilassa kaikki ne sanomat tuhotaan, joille ei ole määritelty vastaanottoa. Talletus voidaan tulkita erikoistapaukseksi vastaanotosta ja sitä seuraavasi a tilasiirtymästä.
Vastaanotossa annetaan sanomien nimet. Mikäli sanoma kuljettaa tietoa, annetaan lista muuttujannimiä (tai viittauksia rakenteellisien muuttujan osiin)1 joihin tieto vastaanoton yhteydessä talletetaan. Tilasiirtymissä voi mm. suorittaa laskentaa ja lähettää sanomia.
Näitä käsitellään yksityskohtaisemmin jäljempänä. Tilasiirtymä päättyy seuraajathan määräämiseen, hyppyyn toisaalle kuvauksessa tai prosessin suorituksen lopetukseen.
Seuraavassa esimerkissä prosessin tilamäärittelystä on kaksi tilaa, add ja sub, ja tilasta riippuen muuttujaan x lisätään tai siitä vähennetään sanomassa vai tullut arvo (laskenta tehdään kohdassa 2.4.5 selostetulla tehtävälauseella). Sanoma toggle vaihtaa aina tilasta toiseen. Aloitustilasiirtymässä nollataan x ja valitaan ensimmäiseksi tilaksi add.
START;
TASK x := 0;
NEXTSTATE add;
STATE add;
INPUT val(y);
TASK x := x + y;
NEXTSTATE add;
INPUT toggle;
NEXTSTATE sub;
1 Rakenteellisten muuttujien osien salliminen tässä on SDL-88 -suosituksen julkaisemisen jälkeen CCITT:n kieltä ylläpitävän työryhmän hyväksymä laajennos, [21, s 14]
ENDSTATE;
STATE sub;
INPUT val(y);
TASK x := x - y;
NEXTSTATE sub;
INPUT toggle;
NEXTSTATE add;
ENDSTATE;
On mahdollista kätevästi kuvata sekä tilanne, jossa toiminta useassa eri tilassa on sa
manlainen jonkin sanoman saapuessa, että tilanne, jossa jossain tilassa usean eri sano
man saapuminen aiheuttaa saman toiminnan. Lisäksi kielessä on lyhennysmerkintöjä, joilla voi viitata kaikkiin prosessin tiloihin (tähtitila) tai kaikkiin niihin vastaanotettavan sanomajoukon sanomiin, joita ei erikseen nimeltä mainita missään tilan vastaanotto- tai talletuslauseista (tähtivastaanotto).
STATE waiting, ready;
INPUT go, run;
NEXTSTATE running;
INPUT *;
OUTPUT refusal TO SENDER;
NEXTSTATE -;
ENDSTATE;
STATE *;
INPUT are_you_alive;
OUTPUT yes TO SENDER;
NEXTSTATE -;
ENDSTATE;
Katkelma määrää, että tiloissa waiting ja ready sanomat go ja run aiheuttavat tilan vaihdon tilaan running, kaikki muut tuottavat vastauksen refusal. Kaikissa tiloissa vastataan sanomaan are_you_alive sanomalla yes. Esimerkissä esiintynyt ”NEXTSTA
TE on merkintä, joka tarkoittaa, että tilaa ei muuteta. Se on erityisen hyödyllinen tähtitilan tapauksessa.
Alkuperäisen tila-herätemallin laajennuksina nykyisessä SDL:ssä on mahdollista määri
tellä tiloihin viritty mis ehto sanoman vastaanotolle. Tämä on vastaanottolauseeseen lii
tetty totuusarvolauseke, joka ilmaisee, että vastaanotto voi aiheuttaa tilasiirtymän vain lausekkeen ollessa tosi. Muussa tapauksessa sanoma talletetaan.
Toinen laajennus on jatkuva sanoma. Se on tilaan liitetty totuusarvolauseke, joka ai
heuttaa sitä seuraavan tilasiirtymän ilman sanoman saapumista, mikäli lauseke on tosi.
Mikäli tilassa on useita jatkuvia sanomia, voidaan niihin liittää prioritetteja, jotka määrä- vät usean samanaikaisesti toden lausekkeen tapauksessa suoritettavan tilasiirtymän. Jos tilassa vastaanotetaan todellinen sanoma, tämä on käsiteltävä ennen jatkuvia sanomia.
Esimerkki:
STATE a;
PROVIDED ioport != 0;
OUTPUT yes TO PARENT;
NEXTSTATE
INPUT s; PROVIDED allowed;
TASK ioport := 0;
NEXTSTATE b;
ENDSTATE;
Tilassa a, niinkauan kuin ioport poikkeaa nollasta, lähetetään sanomia yes emoproses- sille. Jos sanoma s saapuu ja allowed on tosi, nollataan ioport ja siirrytään tilaan
b.
2.4.5 Toimintalauseet
Toimintalauseet vastaavat pitkälti ohjelmointikielten lauseita. SDL-suosituksessa ne on jaoteltu varsinaisiin toiminta)auseisiin action ja lopettimiin terminator, joista jälkim
mäiset voivat esiintyä vain toimintalauseketjun lopussa ja kuvaavat jotain suorituksen kulun muutosta. Useimmat toimintalauseet voivat esiintyä prosessin lisäksi myös muissa prosessirungon sisältävissä lohkoissa (proseduureissa ja palveluissa), eräät vain joissain näistä.
Varsinaiset toimintalauseet
Tehtävä (TASK): Tehtävä voi sisältää yhden tai useampia sijoituslauseita, tai vaih
toehtoisesti epäformaalin kuvauksen tehtävästä merkkijonovakiona. Esimerkkejä:
TASK x :» a * y + 1, a := 0;
TASK ’ Avaa kuumavesihana’;
Sijoituslauseet ovat kuten ohjelmointikielissä: sijoitusoperaattorin ”:=” vasemmalla on muuttujaviittaus, oikealla siihen sijoitettava lauseke. Jos sijoituslauseita on useampia, ne suoritetaan annetussa järjestyksessä. Muuttujia ja lausekkeita käsitellään jäljempänä kohdassa 2.4.12.
Prosessin luomispyyntö (CREATE): Luomispyyntö tuottaa uuden prosessi-ilmen
tymän. Pyynnössä annetaan halutun prosessityypin nimi sekä sille mahdollisesti annetta
vat parametrit, suluissa olevana pilkuin eroteltuna lausekejonona. Yksittäisen parametrin voi jättää pois. Esimerkki:
CREATE waiter;
CREATE server(filesystem, , port);
Järjestelmä luo annetuntyyppisen prosessin muuttujineen samaan lohkoon kuin missä luonnin pyytäjä on, antaa sille tyhjän vastaanottojonon, kopioi sille mahdollisesti annetut parametrit prosessin omiin parametrien ilmentymiin ja alustaa ne prosessin muuttujat, joille on määritelty alustuslauseke (kappale 2.4.9). Jos parametrilistasta puuttuu alkio, saa vastaava prosessin parametri arvon ”määrittelemätön”. Luonnin jälkeen prosessin suoritus alkaa sen aloituspisteestä. Uusi prosessi toimii rinnakkaisesti kaikkien muiden prosessien kanssa.
Luonti voi epäonnistua, jos yritetään luoda enemmän prosesseja kuin mitä prosessityypin määrittelyssä sallitaan. Tällöin luovan prosessin OFFSPRING saa arvon NULL ja suoritus jatkuu.
Proseduurin kutsu (CALL): Kutsu käynnistää jonkin samassa prosessissa määri
tellyn proseduurin ja mahdollisesti välittää sille parametrejä. Parametrit annetaan sa
moin kuin luontipyynnössä. Mikäli vastaava proseduurin muodollinen parametri on lajia IN/OUT, on lausekkeen oltava muuttujan nimi. Proseduurin sisältöä suoritetaan, kun
nes päädytään paluulauseeseen (ks 2.4.5), minkä jälkeen jatketaan kutsua seuraavasta lauseesta. Proseduuria käsitellään tarkemmin kohdassa 2.4.6.
Sanoman lähetys (OUTPUT): Lähetys luo uuden annetun sanomatyypin ilmenty
män ja lähettää sen kohteeksi määrätylle prosessi-ilmentymälle. Lähetyksessä ilmoitetaan sanoman mahdollisesti kuljettama tieto parametrilistana, jonka on sovittava yhteen sano
man esittelyn kanssa.
Kohde voidaan ilmaista jollain seuraavista tavoista:
Osoitustapa Merkitys TO PId-lauseke
Sanoma lähetetään annetulle iimentymälle, jonka on oltava saavutettavissa prosessin näkemien sanomareittien ja kanavien
kautta. ,,—,—
VIA polku,...
Sanoma lähetetään annetun polun (joka voi olla sanomareitti tai kanava) kautta. Tämä osoitustapa toimii ainoastaan, jos polun päässä on vain yksi prosessi-ilmentymä. Jos annetaan usean polun luettelo, valitaan joku niistä. Tällöin kaikkien polkujen on oltava samaa lajia
TO PId VIA polku,... Sanoma lähetetään prosessitunnisteelle, jonka on oltava saavu
tettavissa annettua polkua tai polkuja myöten.
(tyhjä)
Jos prosessista ulos johtaa vain yksi polku, joka voi kuljettaa annetun sanoman, ja se johtaa yksikäsitteiseen prosessi-ilmen
tymään, voi osoituksen jättää pois.
Esimerkkejä:
OUTPUT foo(s) TO instance;
OUTPUT bar(l, s+2, d) VIA short, long;
Päätös ja valinnainen tilasiirtymä (DECISION ja ALTERNATIVE): Päätös vastaa ohjelmointikielten CASE-lausetta. Siitä on tehtävälauseen tapaan olemassa for
maali ja epäformaali muoto. Formaalissa tapauksessa sen alussa on kysymyslauseke, jota verrataan listaan vastauksia. Jos vertailu osuu kohdalle, suoritetaan vastausta seuraava alitilasiirtymä.
Vastausten on oltava joko vakioita, alialueita, tai (ja tässä SDL on hieman ohjelmointi
kieliä joustavampi) vakion vertailuja, kuten ”> 3” tai näiden pilkuilla eroteltuja listoja (jolloin pilkku tulkitaan TAI-operaatioksi). Yksi vastauksista voi olla ELSE:, joka on muiden komplementti. Vastausten ja kysymyksen on oltava samaa tyyppiä, ja vastausten on oltava toinen toisensa poissulkevia. Ajon aikana on jonkin annetusta vaihtoehdoista oltava voimassa, muuten syntyy virhetilanne.
Epäformaalissa tapauksessa sekä kysymykset että vastaukset ovat merkkijonovakioina an
nettua tekstiä. Esimerkki molemmista tapauksista:
DECISION x*y;
(0): CALL a;
(2:8): CREATE b(x, y);
(< 0, 1): CALL c; /* negat. tai = 1 */
ELSE: TASK x := x + 1;
ENDDECISION;
DECISION 'Sateen laji’;
('Vesisade'): TASK ’Avaa sateenvarjo’;
('Lumisade'): TASK 'Laita sukset jalkaan’;
ENDDECISION;
Valinnainen tilasiirtymä muistuttaa päätöstä, mutta siinä kysymyslauseen tulee olla vakio ja rakennetta raj aavat sanat ALTERNATIVE ja END ALTERNATIVE. Mekanismia voi käyttää valintamäärittelyn (ks 2.4.13) ohella erilaisten järjestelmien esittämiseen sa
massa kuvauksessa.
Vienti (EXPORT): Vienti asettaa lauseessa annetun muuttujan hetkellisen arvon nä
kyville, siten, että sen saa jossain toisessa prosessissa selville tuontilauseella (IMPORT).
Tästä lisää vaihtoehtoisten kommunikointitapojen kuvauksessa kappaleessa 2.4.10.
Ajastimen asetus ja purku (SET ja RESET): Ajastin on mekanismi, jolla prosessi voi lähettää itselleen sanoman määrätyllä ajanhetkellä. Tätä voidaan käyttää esimerkiksi erilaisten aikavalvontojen esittämiseen. Ajastimet esitellään niitä käyttävissä prosesseissa.
Niillä voi olla parametreja, joita käytetään saman ajastimen eri ilmentymien erottamiseen toisistaan. Ajastimen laukeamisen synnyttämän sanoman nimi on sama kuin ajastimella.
Lähettäjäksi tälle sanomalle ilmoitetaan prosessi itse.
Asetuslauseessa määrätään, millä ajanhetkellä sanoma lähetetään sekä sanoman paramet
rit. Purkulauseessa poistetaan vielä laukeamaton ajastin, joka aiemmin on asetettu samaa tyyppiä ja parametreja käyttäen. Jos asetuksessa parametrit ovat samat kuin aiemmin asetetulla, mutta ei vielä lauennella ajastimella, aiempi asetus korvautuu uudella. Al
la on tyypillinen käyttötapa: lähetetään sanoma, johon odotetaan vastausta tietyn ajan kuluessa. Ajastimella varmistetaan, ettei odoteta loputtomasti.
TIMER time.out; /* Ajastimen esittely */
OUTPUT are_you_alive TO friend;
SET (N0W+10, time_out);
NEXTSTATE wait;
STATE wait ;
INPUT i_am_alive;
RESET (time.out); /* vastasi ajoissa, poista ajastin */
INPUT time_out;
/* kaiketi kuollut */
ENDSTATE;
Lopettimet Tilasiirtymän päättävät lopettimet kuvaavat aina jotain suorituksen kulun muutosta. Lopetin voi puuttua tilasiirtymästä, jos se päättyy päätöslauseeseen tai kysees
sä on päätöslauseen alitilasiirtymä. Kaikkien aloituspisteestä tai sanoman vastaanotosta alkavien tilasiirtymän vaihtoehtoisten suoritustapojen on kuitenkin lopulta päädyttävä lopettimeen.
Seuraajatila (NEXTSTATE): Seuraajatila-lauseella lopetetaan meneillään oleva ti- lasiirtymä ja siirrytään odottamaan sanomaa jossain toisessa samassa prosessirungossa olevassa tilassa. Tila merkitsee samaa tilaa, josta tilasiirtymä alkoi. Esimerkkejä tästä käskystä on prosessin esittelyssä (2.4.4).
Liitin (JOIN): Liitin vastaa ohjelmointikielten ehdotonta hyppyä. Kohteena on jokin samassa prosessirungossa oleva toimintalause. Lauseeseen viitataan nimiöllä (muodoltaan kaksoispisteeseen loppuva nimi), jollaisen voi panna jokaisen toimintalauseen tai lopetti- men eteen.
TASK i := 0;
loop: TASK a(i) := 0;
DECISION i;
(< a_size): JOIN loop;
ELSE: /* skip */
ENDDECISION;
Yllättävää kyllä, JOIN on standardi-SDLrssä ainoa tapa rakentaa tilasiirtymän sisään silmukka. JOIN on oikeastaan graafisen SDL:n vuoviivan tekstivastine.
Loppu (STOP): Loppu tuhoaa sen suorittaneen prosessin. Kaikki sen prosessin muut
tujat, ajastimet ja vastaanottojonossa olleet sanomat katoavat. Loppu ei voi esiintyä proseduurissa.
Paluu (RETURN): Paluu siirtää prosessin suorituksen proseduurista sen kutsujaan.
Proseduurin paikalliset muuttujat katoavat. Paluulausetta voi luonnollisesti käyttää vain proseduurin sisällä.
2.4.6 Proseduurit
Proseduuri vastaa ohjelmointikielten aliohjelmaa. Sen voi esitellä vain prosessin tai toisen proseduurin esittelyosassa. Proseduuri muistuttaa rakenteeltaan prosessia. Toisin kuin tällä, proseduurilla ei ole omaa sanomajonoa, vaan se käyttää kutsuvan prosessi-ilmen
tymän jonoa. Vastaanotettavien sanomien joukko ja ennalt am ääri telly t muuttujat ovat
myös samat kuin tällä prosessilla. Proseduuri ei toimi rinnakkain toisten saman prosessi- ilmentymän proseduurien tai varsinaisen prosessin rungon kanssa, vaan kutsulause siirtää ilmentymän suorituksen proseduurin sisään ja paluulause palauttaa sen kutsujaan.
Proseduurilla voi olla parametreja, joiden avulla kutsuja voi välittää sille lähtötietoja ja vastaanottaa tuloksia. Parametrin voi otsakkeessa esitellä joko syöteparametriksi, joka välittää tietoa vain proseduuriin päin, tai viiteparametriksi, jonka kautta arvoja voi pa
lauttaa. Syöteparametri toimii proseduurin kannalta kuin alustettu paikallinen muuttuja, ja kutsussa sitä vastaava arvo voi olla sopivan tyyppinen lauseke. Viiteparametri toimii proseduurin suorituksen ajan synonyyminä kutsussa annetulle todelliselle parametrille, jonka on oltava muuttujan nimi. Kaikki viiteparametrin kautta tehdyt muutokset välit
tyvät heti todelliseen parametriin.
Proseduurilla voi olla paikallisia muuttujia, jotka luodaan suorituksen alkaessa ja tuhotaan paluun yhteydessä. Proseduuri voi myös suoraan viitata ympäröivien lohkojen muuttu
jiin.2 Proseduurin tilat ovat itsenäisiä, ympäröivän lohkon tiloista riippumattomia. On mahdollista (ja tavallista) määritellä myös proseduureja, joilla on vain paluukäskyyn päät
tyvä aloitustilasiirtymä eikä tiloja laisinkaan.
Alla olevassa esimerkissä proseduuri remote_read saa syöteparametrina number_wanted halutun merkkien määrän, vaihtaa sanomia prosessi-ilmentymän kanssa, jota oletetaan edustavan globaali PId-muuttuja server, ja palauttaa tulokset viiteparametrien charac
ters ja number-received kautta. Oletetaan, että char act er_ar r ay on sopiva ympäröi
vässä lohkossa määritelty taulukkotyyppi (ks kappale 2.4.12).
PROCEDURE remote.read;
FPAR IN number.wanted Integer,
IN/OUT characters character.array, IN/OUT number.received Integer;
START;
OUTPUT char_request(number.wanted) TO server;
NEXTSTATE wait;
STATE wait;
INPUT char_data(character_array, number.received);
RETURN;
ENDSTATE wait ;
ENDPROCEDURE remote.read;
2Suositus näyttää tämän kieltävän [10, s 41, 50], mutta SDL-työryhmä täsmensi myöhemmin, että tämän oli tarkoitus olla sallittua [21, s 13].
2.4.7 Palveluhajotelma
Palveluhajotelma on mekanismi, jolla prosessin runko voidaan esittää joukkona vuoroit- tain toimivia aliautomaatteja, joita kutsutaan palveluiksi. Kukin palvelu muistuttaa muo
doltaan prosessia, siinä on tiloja ja se voi vastaanottaa ja lähettää sanomia. Se käyt
tää kuitenkin prosessin sanomajonoa ja muuttujia, eikä sillä ole parametreja. Toisin kuin proseduuri, palvelua ei käynnistetä kutsulla prosessin rungosta, vaan jokainen pal
velu aloittaa toimintansa prosessin syntyessä. Sitä paitsi palveluhajotelman tapauksessa prosessilla ei ole omaa runkoa. Kaikki tilat ovat palveluiden sisässä.
Samassa prosessissa ei saa olla kahta tai useampaa palvelua, jotka käsittelevät saman sanoman. Tämä johtuu palveluhajotelman toimintatavasta. Sanoman saapuessa suori
tettava tilasiirtymä voidaan ajatella valittavaksi tutkimalla ensin, minkä palvelun käsitel
täväksi sanoma kuuluu, ja tämän jälkeen valitsemalla tilasiirtymä kyseisen palvelun tilan perusteella. Yhdellä kertaa voi samassa prosessi—ilmentymässä olla käynnissä vain yksi ti
lasiirtymä. Oikeastaan palveluhajotelma on SDL—suosituksen mukaan lyhennysmerkintä, joka tulkitaan muodostamalla uusi automaatti, jonka tiloina ovat kaikki palvelujen tilojen yhdistelmät. Edellä annettu toiminnan kuvaus vastaa tätä ja on ymmärrettävämpi.
Palvelujen väliseen tiedonvaihtoon voi käyttää etuoikeutettuja sanomia, jotka käsitellään aina ennen prosessin muita sanomia. Näitä käsitellään lähetys- ja vastaanottolauseilla, jotka prefiksoidaan sanalla PRIORITY. Prosessissa voidaan ajatella tällöin olevan eril
linen etuoikeutettujen sanomien jono, johon PRIORITY OUTPUT:illa asetetaan sano
mia* Ja josta PRIORITY INPUT niitä ottaa. Prosessin ollessa valmis vastaanottamaan sanomaa se etsii sitä ensin etuoikeutetusta jonosta, ja käyttää normaalia jonoa vain jos etuoikeutettu jono oli tyhjä. Etuoikeutettua sanomaa ei voi tallettaa.
Sanomien reititystä palvelusta toiseen hallitaan prosessin sisällä määritellyillä sanomarei- teillä, jotka ovat samanlaisia kuin lohkon tasolla olevat prosessien väliset sanomareitit.
Prosessissa, jossa on palveluhajotelma, ei saa määritellä tilallisia proseduureja. Rajoituk
sen tarkoitus on auttaa varmistamaan, ettei kaksi eri palvelua vastaanota samaa sanomaa, mutta rajoitus on tarpeettoman jyrkkä. Riittävä rajoitus olisi, että yhtä tilallista prose
duuria saa kutsua vain yhdestä palvelusta käsin, kuten [51, s 148] esittää.
Allaolevassa esimerkissä prosessin p palvelu a vastaanottaa sanoman outside, lähettää etuoikeutetun sanoman palvelulle b, joka puolestaan lähettää sanoman answer prosessille
whoever, jonka prosessi on saanut parametrinään.
PROCESS p; FPAR whoever PId;
SIGNAL express ;
SIGNALROUTE x FROM ENV TO a WITH outside;
SIGNALROUTE y FROM a TO b WITH express ; SIGNALROUTE z FROM b TO ENV WITH answer;
CONNECT ol AND x; /* oi ja o2 oletetaan uiko- */
CONNECT o2 AND z; /* puolisiksi sanomareiteiksi */
SERVICE a;
START;
NEXTSTATE w;
STATE и;
INPUT outside ;
PRIORITY OUTPUT express;
NEXTSTATE -;
ENDSTATE w;
ENDSERVICE a;
SERVICE b;
START;
NEXTSTATE w;
STATE w;
PRIORITY INPUT express;
OUTPUT answer TO whoever;
NEXTSTATE -;
ENDSTATE w;
ENDSERVICE b;
ENDPROCESS p;
2.4.8 Sanomien määrittely
Sanoma koostuu nimestäjä sanoman mahdollisesti kuljettaman tiedon määrittelystä. Tie
to kuvataan luettelemalla tietotyyppien nimiä. Sanoman esittely kuvaa oikeastaan tyypin, jonka ilmentymiä luodaan lähetyslauseilla. Esimerkkejä sanomanmäärittelyistä on kap
paleessa 2.4.2 olevassa järjestelmän esittelyssä.
Sanoma voidaan hajottaa joukoksi alemman tason sanomia (signal refinement). Näitä alisanomia käytetään hyväksi kanavien alirakenteen yhteydessä. Osa sanomista voidaan hajotelmassa määrätä vastakkaissuuntaisiksi muihin nähden. Hajotelmalla voidaan esit
tää esimerkiksi kerrostetun protokollan tason N sanoma, joka tasolla N — 1 koostuu joukosta datas anomia ja kättelysanomia.
Sanomia voi ryhmitellä nimetyiksi sanomalistoiksi, joilla voi lyhentää sanomia luettelevia esittelyjä.
2.4.9 Muuttujien määrittely
Muuttujia voi esitellä prosesseissa, proseduureissa ja palveluissa. Niiden merkitys ei pal
joa poikkea ohjelmointikielten muuttujista. Muuttujien esittelyssä annetaan niiden tyypit (aina tietotyypin nimellä) sekä mahdolliset alkuarvot. Lisäksi voi määritellä, että muut
tujaa voi tutkia toisesta saman lohkon prosessista (tästä lisää kohdassa 2.4.10). Seuraava esittely määrää, että amount ja limit ovat kokonaislukuja, alkuarvoltaan 1, ja length on alkuarvoltaan määrittelemätön reaaliluku:
DCL amount, limit Integer := 1, length Real ;
2.4.10 Vaihtoehtoiset kommunikointitavat
Sanomilla kommunikoinnin lisäksi SDL tarjoaa mahdollisuuden käyttää prosessista toi
seen näkyviä muuttujia (jaettua muuttujaa) ja muuttujan arvon vientiä (joka oikeastaan on eräänlaista sanoman välitystä). Näiden suurin ero on siinä, että näkyvän muuttu
jan arvon muutokset heijastuvat muihin prosesseihin jatkuvasti, viedyn muuttujan vain silloin, kun prosessi suorittaa erityisen vientilauseen.
Näkyvä muuttuja Muuttuja voidaan tehdä näkyväksi toisille saman lohkon prosesseil
le paljastamalla se muuttujaesittelyssä määrettä REVEALED käyttäen. Muuttujaa kat
selevan prosessin on tehtävä samalle muuttujalle näkyvyysmäärittely sanalla VIEWED muuttujien esittelyosassaan. Tämän jälkeen katseleva prosessi saa muuttujan hetkellisen arvon selville katselulausekkeella, jossa annetaan muuttujan nimi ja paljastavan prosessin tunniste. Esim.
PROCESS a;
DCL REVEALED i Integer;
CREATE b;
PROCESS b;
VIEWED i Integer;
TASK n := VIEW(i, PARENT);
Katkelmassa i on a:n paljastama muuttuja, jolle b tekee näkyvyysmäärittelyn. Esimer
kissä oletetaan, että prosessi a on prosessin b emoprosessi.
Muuttujan vienti Viennissä prosessi voi vientilauseella tehdä jonkin muuttujan het
kellisen arvon tunnetuksi sille tuontimääreen tehneille prosesseille. Näiden ei tarvitse olla samassa lohkossa. Se voidaan tulkita lyhennysmerkinnäksi sanoman vaihdolle, jossa vien- tilause välittää arvon sanoman avulla kaikille siitä kiinnostuneille prosesseille. Edellinen esimerkki vientiin sovellettuna:
PROCESS a;
DCL EXPORTED i Integer;
TASK i := 0;
CREATE b;
EXPORT (i); /* vienti : i = 0 */
TASK i := l+l;
PROCESS b;
IMPORTED i Integer;
TASK n := IMP0RT(i, PARENT);
Jos a ei sisällä muita EXPORT—lauseita, tuottaa muuttujan i tuonti aina arvon 0. Pal
jastettuja ja vietäviä muuttujia ei saa määritellä proseduureissa, koska proseduurin muut
tujat ovat olemassa vain proseduurin ollessa aktiivinen. Niihin viittaavat toiset prosessit eivät voisi tietää, onko niitä todellisuudessa viittaushetkellä olemassa.
2.4.11 Tietotyyppien määrittely
Kaikki SDL-kielen tietotyypit määritellään abstrakteina tyyppeinä käyttäen initiaalial
gebrallista mallia[l8]. Menetelmässä tyypin ominaisuudet kuvataan antamalla tyypin literaalit, operaattorit, siihen liittyvät lajit (eli arvojoukot) ja aksioomat. Kaikki tyypin arvot voidaan kuvata literaaleista ja operaattoreista koostuvina lausekkeina, joita voidaan käsitellä aksioomien avulla. Näin muodostetut määritelmät kuvaavat täsmällisesti tyypin ominaisuudet joten niitä voi käyttää S DL—kuvausten formaalissa todentamisessa, ja ne ovat täysin riippumattomia toteutustekniikoista.
Initiaali algebrallisesta mallista ja S DL—kielen tietotyypeistä on diplomityössä [25] yksi
tyiskohtainen kuvaus. Tässä esityksessä pyritään vain antamaan SDL-kielen tyypeistä yleiskuva.
Seuraava esimerkki3 esittelee kokonaislukujen joukkoa kuvaavan tyypin. Tyypillä on ope
raattorit Incl alkion lisäämiseksi, Del alkion poistamiseksi ja IN jäsenyyden tutkimisek-
3 Esimerkki perustuu suosituksen [10] joukkogeneraattoriin, mutta operaattoreita on karsittuja kor
jaukset [21, s 20] on huomioitu.
si. Lisäksi SDL-kielessä on käytäntö, että kaikilla tyypeillä on valmiiksi yhtäsuuruus- ja erisuuruusoperaattorit ”=” ja
NEWTYPE Intset LITERALS Empty;
OPERATORS
Incl: Integer, Intset -> Intset;
Del : Integer, Intset -> Intset;
"IN": Integer, Intset -> Boolean;
AXIOMS
FOR ALL i, j IN Integer ( FOR ALL s IN Intset ( i IN Empty == False;
i IN InclCi, s) == True;
i /= j == True ==>
i IN Incl(j, s) == i IN s;
Del(i, Empty) == Empty;
NOT i IN s == DelCi, s) = s;
Del(i, Incl(i, s)) == DelCi, s);
InclCi, InclCj, s))== InclCj, InclCi, s));
InclCi, InclCi, s))== InclCi, s);
Empty = InclCi, s) == False;
))
ENDNEWTYPE Intset;
Määrittelyn voi parametrisoida tekemällä siitä generaattorin, jolla on muodollisena pa
rametrina tyyppejä, literaaleja tai operaattoreita. Edellä olevan joukkotyypin voi tällä menettelyllä helposti yleistää mille tahansa alkiot y ypille. Lisäksi uusia tyyppejä voi johtaa olemassa olevista käyttämällä perintää tai SYNTYPE-mekanismia, joka antaa tyypille uuden nimen, mutta voi tässä yhteydessä lisätä sille ehtoja (esimerkkinä kappaleen 2.4.12 tyyppi Natural).
Algebrallisen mallin käytön helpottamiseksi (tai jotta käyttö yleensä olisi mahdollista ilman suunnatonta työmäärää) sisältää SDL joukon valmiiksi määriteltyjä tyyppejä ja tyyppigeneraattoreita. Näiden formaalit määritelmät löytyvät SDL-suosituksesta [10, s 188-199]. Lisäksi on joukko lyhennysmerkintöjä, kuten se, että literaalit voi esitellä antamalla niiden ulkoasun kuvaavan säännöllisen lausekkeen[2, s 94], jolloin vältytään suurten (mahdollisesti äärettömien) luetteloiden kirjoittamiselta. Operaattorit voi esitel
lä infix-lajisiksi käyttämällä tiettyjä symboleja tai varattuja sanoja (kuten IN edellisessä esimerkissä), joten esimerkiksi normaalien aritmeettisten operaattoreiden kuvaus onnis
tuu.
Ohjelmointikielistä tuttujen taulukoiden ja tietueiden käsittelyyn on olemassa ennalta- määritelty generaattori sekä ”syntaktista sokeria” sekä määrittelyssä että niitä käyttä
vissä lausekkeissa. Näistä lisää seuraa vassa kappaleessa.
2.4.12 Ennaltamääritellyt tyypit ja lausekkeet
Seuraavassa luettelossa ovat ennaltamääritellyt tietotyypit ja generaattorit. Luettelos
sa ei tyyppien yhtäsuuruus- ja erisuuruusoperaattoreita kerrota erikseen, koska ne ovat, kuten aiemmin mainittiin, aina voimassa kaikille tyypeille.
Boolean: Totuusarvo, literaalit ovat True (tosi) ja False (epätosi). Operaattorit ovat
NOT (ei), AND (ja), OR (tai), XOR (poissulkeva tai) ja => (implikaatio).
Character: Yksittäinen merkkivalikoiman merkki. Useimmat merkit kirjoitetaan kuten yhden merkin merkkijonovakiot (ks 2.4.1), ohjausmerkeille on nimetyt vakiot. Operaat
torit ovat vertailut <,<=,> ja >».
String. Generaattori, jolla voidaan muodostaa jonotyyppi. Jonon alkioiden tyyppi an
netaan generaattorin parametrina. Operaattorit ovat MkString (yhden alkion jonon muo
dostus), Length (jonon pituus), First (jonon ensimmäinen alkio), Last (jonon viimeinen alkio), // (kahden jonon yhdistäminen) ja Substring (alijonon muodostaminen).
Charstring: Merkkijono, eli generaattorin String soveltaminen tyyppiin Character täydennettynä literaalien ulkoasun säännöillä.
Integer. Kokonaisluku. Operaattorit ovat vertailut <, <=, > ja >=, peruslaskutoimituk- set +, -» * ja /, sekä muunnokset reaalilukujen ja kokonaislukujen välillä (Float ja Fix).
Jakolasku tuottaa vain kokonaisosan.
Natural: Positiivinen kokonaisluku. Tämän esittely suosituksessa [10, s 194] on hyvä esimerkki SYNTYPE-mekanismista:
SYNTYPE Natural = Integer CONSTANTS >- О
ENDSYNTYPE Natural;
Real. Reaaliluku. Operaattorit ovat samat kuin tyypillä Integer (mutta jakolasku on tarkka).
Array: Taulukko. Tämä on ennaltamääritelty generaattori, joka ottaa parametreinään taulukon indeksityypin ja alkioiden tyypin. Array-generaattoriin liittyy lyhennysmerkitä, joka sallii alkioihin viittauksen sulkulausekkeilla indeksoimalla, ohjelmointikielten tapaan.
Esimerkki ([10, s 197]):
NEWTYPE indexbychar Array(Character, Integer) ENDNEWTYPE indexbychar;
DCL charvalue indexbychar;
TASK charvalue(’A’) := charvalue(’B’)-1 ;
Powerset: Joukko. Tämä on ennaltamääritelty generaattori, jolle annetaan paramet
rina joukon kantatyyppi. Generoiduilla tyypeillä on samat operaattorit IN, Incl ja Del kuin kappaleen 2.4.11 esimerkissä. Lisäksi on osajoukkovertailut <, <=, > ja >=, sekä AND leikkauksen ja OR unionin laskemiseksi.
PId: Prosessitunnus. Tällä on literaali NULL ja operaattori unique !, jota järjestelmä käyttää piilevästi prosessin luonnin yhteydessä.
Duration: Aikaväli. Tämä on johdettu tyypistä Real, mutta sallittuja operaatioita on rajoitettu: kerto- ja jakolasku on mahdollista vain, jos toinen operandi on tyyppiä Real.
Time: Absoluuttinen aika. Tämäkin on johdettu tyypistä Real. Aritmetiikka on ra
joitettu Durât ion-tyyppisten arvojen lisäämiseen ja vähentämiseen, sekä kahden ajan erotuksen laskemiseen. Ajastimen asetuksessa (ks 2.4.5) laukeamisajan on oltava tätä tyyppiä.
Tietue: Tietuetyyppiä varten ei ole olemassa varsinaista ennaltamääriteltyä generaat
toria. Sensijaan on lyhennysmerkintä, jonka ajatellaan laajennettavaksi algebralliseksi määrittelyksi, joka esittelee operaattorit kunkin kentän arvon asettamiselle ja tutkimisel
le, sekä tarpeelliset aksioomat. Kenttiin viittaamiseksi lausekkeissa on olemassa merkintä
tapa muuttuja ¡kenttä, joka tilanteesta riippuen laajennetaan kenttään liittyvän asetus
ta! tutkimisoperaattorin kutsuksi. Myös tietuearvon muodostaminen sen komponenteista on mahdollista. Esimerkki:
NEWTYPE s_t STRUCT b Booleani;
i Integer;
ENDNEWTYPE s_t;
DCL x, y s_t;
TASK x!b := y ! i = 0;
TASK y := TYPE s.t (. False, 2 .);
On huomattava, että ennaltämääritellyillä SDL-tyypeillä ei ole tavanomaisten ohjelmoin
tikielten tietotyyppien rajoituksia. Esimerkiksi reaalilukujen tarkkuudet ja arvoalueet ovat rajattomia. Rajallisia ohjelmoinnissa käytettäviä tyyppejä mallitettaessa voidaan käyttää rajoitusmääreitä, kuten seuraavassa 16-bittisen etumerkillisen kokonaislukutyy- pin esittelyssä:
SYNTYPE intl6 = Integer CONSTANTS -32768 : 32767;
ENDSYNTYPE int 16;
2.4.13 Makrot ja valintamäärittelyt
SDL sisältää mekanismit suurissa kuvauksissa esiintyvien toistuvien osien ja vaihtoeh
toisten tulkintojen hallintaan. Tässä esiteltävillä menetelmillä voi kuvausta tiivistää ja esittää samassa dokumentissa eri muunnelmia samasta järjestelmästä.
Makro: Makro on nimetty ja mahdollisesti parametrisoitu lyhennysmerkintä. Toisin kuin proseduurit, jotka aina sisältävät ehjän, prosessitason rakenteista muodostuvan ko
konaisuuden, makron m ääntelyssä voi olla mielivaltaisia SDL-katkelmia, lukuunottamat
ta makromääritelmiä ja määriteltävään makroon itseensä kohdistuvia laajennuslauseita.
Makro tulkitaan yksinkertaisesti korvaamalla siihen viittaava laajennuslause makron sisäl
löllä, jossa ensin on kaikki viittaukset makron muodollisiin parametreihin korvattu laa- jennuslauseessa annetuilla todellisilla parametreillä. Piirre vastaa toiminnaltaan C-kielen ja useiden symbolisten konekielten makroja.
Laajennuslause voi esiintyä missä tahansa. Makrojen näkyvyyssäännöt poikkeavat yleisis
tä säännöistä: makron nimi on näkyvissä koko järjestelmässä, riippumatta makron esit
telyn sijainnista lohkojen suhteen. Esimerkki: Makro reflect laajentuu koodiksi, joka palauttaa parametrinään saamansa sanoman lähettäjälle.
MACRODEFINITION reflect FPAR s;
INPUT s;
OUTPUT s TO SENDER;
NEXTSTATE -;
ENDMACRO reflect;
STATE working;
MACRO reflect(ping);
MACRO reflect(zap);
Makrolaajennuksia sisältävän kuvauksen laillisuus voidaan tutkia vasta kaikkien makro- jen laajentamisen jälkeen. Esimerkin makroa voidaan käyttää vain tilan tai tilasiirtymän perässä sijaitsevissa laajennuslauseissa, ja makron argumentin on oltava parametriton sanoma.
Valintamäärittely: Valintamäärittelyllä ilmaistaan, että jokin osa kuvausta otetaan mukaan vain, jos annettu totuusarvolausekkeella ilmaistu ehto täyttyy. Se on läheistä su
kua valinnaiselle tilasiirtymälle (sivu 17), mutta voi sisältää mitä tahansa SDL-esittelyjä ja sijaita missä tahansa. Esimerkki:
SYSTEM car;
SYNONYM price Natural * EXTERNAL; /* ulkoinen synonyymi */
BLOCK motor REFERENCED;
SELECT IF price > 10000;
BLOCK automatic.transmission REFERENCED;
ENDSELECT;
Eli jos price on yli 10000, autoon sisältyy automaattivaihteisto.
Ulkoinen synonyymi Sekä valintalauseessa että valinnaisessa tilasiirtymässä voi olla hyödyllistä ilmaista, että valittu versio riippuu jostain kuvauksen ulkopuolisesta päätök
sestä. Tämä saadaan aikaan käyttämällä ulkoista synonyymiä. Se on vakio, jolle annetaan ennen kuvauksen tulkitsemista valittu arvo, jonka kuitenkin on oltava ulkoisen synonyy
min esittelyssä määrättyä tyyppiä. Edellisen esimerkin price on tyyppiä Natural oleva ulkoinen synonyymi.
3 Ongelmat ohjelmointikäytön kannalta
3.1 Syistä
Kuvauskielten suunnittelussa ei yleensä ole otettu huomioon niillä tehtyjen kuvausten käyttöä lopullisena toteutuksena. Tarkoitus on ollut, että toteutus tehdään jollain tavano- maisella ohjelmointikielellä kuvauskielisen esityksen pohjalta. On kuitenkin hyviä syitä yrittää suoraa ohjelmointikäyttöä muuttamalla kuvaus automaattisesti toteutukseksi tai sen osaksi. Työmäärä on luonnollisesti vähäisempi, käsinkoodaus on virhealtista, ja mitä vähemmän on erillisiä, mutta toisistaan riippuvaisia dokumentteja, sitä helpompaa on järjestelmän ylläpito.
Kuvauskielissä pääpaino on sen kuvaamisessa, mitä tehdään, sen sijaan, että tarkkaan ku
vattaisiin, miten se tehdään, kuten useimmissa ohjelmointikielissä on asian laita. Tästä painotuserosta johtuu, että haluttaessa käyttää kuvauskieltä suoraan ohjelmointiin jou
dutaan ratkaisemaan joukko ongelmia, jotka voidaan jakaa seuraaviin kahteen luokkaan:
• Korkean tason käsitteiden ja määritelmien automaattinen kuvaaminen koneellisesti toteutettavissa oleviksi algoritmeiksi ja tietorakenteiksi.
• Kuvauskielisestä esityksestä puuttuvan toteutusläheisen tiedon lisääminen.
Esimerkki ensimmäisestä ongelmasta on S DL—kielen automaattien kuvauksen muutta
minen tietokoneen ymmärtämiksi vertailu- ja haarautumiskäskyiksi, jälkimäisestä taas prosessien jakaminen eri keskusyksiköille, mikäli niitä on käytettävissä useita.
SDL on perusajatukseltaan varsin konkreettinen kuvauskieli. Sillä laaditut kuvaukset ovat luonteeltaan malleja kuvattavasta järjestelmästä. Useimmat sen käsitteet löytyvät myös varsinaisten ohjelmointikielten joukosta ja niiden automaattinen toteuttaminen on tun
nettua tekniikkaa. Näistä syistä sen käyttäminen ohjelmointiin näyttää helpolta, eräisiin muihin kuvauskielin verrattuna. Edellä mainitut ongelmat kuitenkin tulevat SDL-kieles- säkin vastaan eri muodoissaan, ja niitä eritellään tässä luvussa.
3.2 Kääntäminen kohdekoneelle
Jotta mitä tahansa korkeantason ohjelmointikieltä voisi ajaa tietokoneessa, se on muu
tettava konekieliseen muotoon tai tulkattava ajon aikana. Tulkkitoteutus on käytännössä liian hidas useimpiin sovelluksiin, joiden suunnittelussa SDL-kieltä käytetään. Hyvän konekielen tasolle menevän kääntäjän teko taas on vaikeaa.
Melkein kaikissa kirjallisuudessa mainituissa SDL—toteutuksissa tämä ongelma on rat
kaistu tuottamalla SDL-kuvauksesta jotain tavanomaista ohjelmointikieltä, joka sitten
