Citation for published version (APA): Saaman, E. H. (2000). Another formal specification language Groningen: s.n.

Transcriptie

1 University of Groningen Another formal specification language Saaman, Erik Harald IMPORTANT NOTE: You are advised to consult the publisher's version (publisher's PDF) if you wish to cite from it. Please check the document version below. Document Version Publisher's PDF, also known as Version of record Publication date: 2000 Link to publication in University of Groningen/UMCG research database Citation for published version (APA): Saaman, E. H. (2000). Another formal specification language Groningen: s.n. Copyright Other than for strictly personal use, it is not permitted to download or to forward/distribute the text or part of it without the consent of the author(s) and/or copyright holder(s), unless the work is under an open content license (like Creative Commons). Take-down policy If you believe that this document breaches copyright please contact us providing details, and we will remove access to the work immediately and investigate your claim. Downloaded from the University of Groningen/UMCG research database (Pure): For technical reasons the number of authors shown on this cover page is limited to 10 maximum. Download date:

2 SAMENVATTING Dit proefschrift is het verslag van de ontwikkeling van de nieuwe formele specificatietaal AFSL die speciaal bedoeld is voor de beschrijving van software. Behandeld worden de rol van formele specificatie in software-ontwikkeling, de algemene principes van formele specificatietalen, de ontstaansgeschiedenis van AFSL, de redenen om een nieuwe taal te maken, de definitie van de taal, ontwerpoverwegingen, voorbeelden van het gebruik en ideeën voor mogelijke verbeteringen aan de taal. De afkorting AFSL staat voor Almost Formal Specification Language waarbij Almost refereert naar de mogelijkheid om (niet formele) natuurlijke taal te gebruiken binnen het verder formele AFSL. In de titel Another Formal Specification Language refereert Another naar het feit dat er al veel formele specificatietalen bestaan (misschien al genoeg), maar het geeft ook aan dat AFSL anders is. Een specificatie is een beschrijving van de eigenschappen van een ding. Een specificatie is formeel als hij aan bepaalde vormafspraken voldoet zodat de doelgroep de beschrijving begrijpt. Voorbeelden van specificaties zijn de partituur van een muziekstuk, een patroon van een bruidsjurk en het elektronisch schema van een radio. Het is vaak van belang om een specificatie te hebben voordat het ding gemaakt wordt omdat het proces anders in chaos ontaardt. Je kunt een groep bouwvakkers immers geen huis laten bouwen door ze alleen te vertellen wat het gewenste vloeroppervlak en aantal kamers zijn. De hierboven gegeven voorbeelden hebben allemaal een verschillende mate van formaliteit. De noten in de partituur geven bijvoorbeeld toonhoogte aan maar bepalen niet de klankkleur van de noten. Dat is de reden waarom dirigent en musici zo n belangrijke rol spelen bij de interpretatie van van een muziekstuk. Het patroon maakt gebruik van speciale symbolen die een geschoolde kleermaker voldoende aanwijzingen geeft om de jurk precies op maat te maken, ook al zegt het nog niks over de kleur stof. Het elektronisch schema tenslotte maakt gebruik van zulke gestandaardiseerde symbolen dat elke elektronicus er een radio mee kan maken. De notatie die gebruikt wordt voor een specificatie noemen we een specificatietaal. Notenschrift is een specificatietaal, maar ook de symbolen die gebruikt worden in een patroon. Een specificatietaal is formeel als deze zodanig is gestandaardiseerd dat er geen ruimte is voor interpretatieverschillen. Notenschrift is dus niet echt een formele specificatietaal maar de notatie voor elektronische schema s wel. Hebben we specificaties nodig voor het maken van software? Er bestaat veel ergenis over de kwaliteit van software en de slechte beheersbaarheid van het bijbehorende ontwikkelproces. Er is een aantal redenen waarom het moeilijk is software te maken. Software is meestal te omvangrijk om door één persoon begrepen te worden. Het is moeilijk om vast te stellen aan welke eisen precies voldaan moet voldoen. De onderlinge samenhang tussen verschillende onderdelen maakt het moeilijk om veranderingen aan te brengen. Het maken van software is een denkproces waarbij de redenen om een bepaalde beslissing te nemen niet altijd ex-

3 pliciet worden gemaakt. Ten slotte is de omgeving waarbinnen de software moet opereren is vaak moeilijk te doorgronden. Bij al deze aspecten is communicatie een belangrijke element, specificaties kunnen daarbij een belangrijke rol spelen. Bijvoorbeeld bij het vastleggen van afspraken, documenteren van ontwerpbeslissingen, beschrijven van de verschillende onderdelen van de software, beschrijven van de omgeving, beschrijving van standaarden, etc. Een bijkomend voordeel van het maken van specificaties is dat het de betrokken partijen dwingt goed na te denken over het op te lossen probleem. Er zijn verschillende soorten specificatietalen. Het meest voorkomend zijn symbolische talen (waarbij met letters en woorden gewerkt wordt) en grafische talen (waarbij met plaatjes gewerkt wordt). Over het algemeen vatten grafische beschrijvingen slechts deelaspecten van een compleet systeem, zoals bijvoorbeeld de relaties tussen gegevens die verwerkt worden. Als een grafische taal gebruikt wordt voor een volledige specificatie worden de plaatje al gauw te ingewikkeld. Een uitgangpunt van dit proefschrift is het kunnen maken van volledige specificaties, daarom is gekozen voor een symbolische taal. Veel symbolische specificaties van software worden geschreven in natuurlijke taal (Nederlands, Engels, etc.). Het nadeel van natuurlijke taal is dat hij vaak niet goed gebruikt wordt, op verschillende manieren begrepen kan worden en moeilijk automatisch te verwerken is. Een andere symbolische taal die in kleine kring gebruikt wordt, vooral in de wetenschap, is die van de wiskunde. Deze taal is minder dubbelzinnig dan natuurlijke taal en leent zich bovendien bij uitstek voor systematische analyse van software, zoals het correct bewijzen van programma s. Toch is ook de taal van de wiskunde niet gestandaardiseerd en leent zich ook slecht voor automatische verwerking. Daar komt nog eens bij dat hij moeilijk in het gebruik is. Kortom, voor de specificatie van software is een echte formele taal het meest gewenst. Er bestaat een veelheid aan formele talen. De bekendste van deze talen is de eerste-orde predikatenlogica en gerelateerd daaraan de logische programmeertaal Prolog. In principe kunnen de meeste formele talen gebruikt worden voor de specificatie van software. In de praktijk leidt dat echter tot omslachtige en daardoor onbegrijpelijke specificaties. Bovendien sluiten deze algemene talen slecht aan bij de rest van het software-ontwikkelproces. Daarom bestaan er talen die speciaal gemaakt zijn voor de specificatie van software. Veel van deze talen zijn ontwikkeld om gebruikt te kunnen worden voor het correct bewijzen van programma s, maar daar is AFSL niet voor bedoeld. Als gevolg daarvan ontbreken bijvoorbeeld bewijsregels. Nu we weten dat specificeren zinvol kan zijn en dat daar bij voorkeur een formele taal voor gebruikt moet worden kunnen we dus aan de slag. Helaas ligt dat niet zo simpel. De huidige formele specificatietalen zijn zo ingewikkeld dat ze een opleiding vergen die een stuk verder gaat dan een programmeeropleiding. Los daarvan is het boven tafel krijgen van specificaties geen eenvoudige taak, daarvoor is veel inzicht en ervaring nodig. Het zou daarom helpen als er een methode was voor het maken van formele specificaties. Deze methode zou moeten bestaan uit een specificatietaal plus aanwijzingen en hulpmiddelen voor het gebruik van deze taal. Zo n methode bestaat niet, met name ontbreekt het aan concrete aanwijzingen voor het opstellen van specificaties. Dit is de aanleiding geweest voor het starten van een onderzoek met als doel het ontwikkelen van een specificatiemethode. Uitgangspunt vormde daarbij de ideeën uit objectgeorienteerde methoden, aangezien die zich nadrukkelijk richten op het beschrijven van systemen. Onderdeel van het onderzoek was een tweetal praktijkstudies. Gebaseerd op de wensen voor de specificatiemethode is een aantal eisen opgesteld waar-

4 aan de te gebruiken specificatietaal moest voldoen. De taal moet eenvoudig zijn zodat hij gemakkelijk te leren en automatisch te verwerken is. Natuurlijke taal moet toegestaan zijn zodat een informele specificatie stapsgewijs omgezet kan worden naar een formele. De taal moet bruikbaar zijn in alle fasen van software-ontwikkeling om vertaalproblemen tussen opeenvolgende fasen te voorkomen. De taal moet algemeen toepasbaar voor willekeurige probleemgebieden zodat methode en deelspecificaties hergebruikt kunnen worden. Objectgeorienteerde concepten zoals klassificatie, inheritance, encapsulation en polymorfisme moeten ondersteund worden. Een modulemechanisme met parameters moet hergebruik ondersteunen. Er bleek geen taal beschikbaar te zijn die in voldoende mate voldeed aan al deze eisen. Daarom is besloten een nieuwe taal te maken, dat is AFSL geworden. AFSL is gebaseerd op de eerste-orde predikatenlogica, daarnaast hebben de specificatietalen COLD, EHDM en LSL grote invloed gehad. Belangrijke eigenschappen van AFSL zijn: eenvoudige basistaal waarbij alle geavanceerde mogelijkheden terugvertaald kunnen worden naar deze basis; natuurlijke taal is toegestaan in informele definities; functies kunnen impliciet gebruikt worden voor het converteren van functie-argumenten naar de benodigde vorm, dit maakt een vorm van inheritance mogelijk; modulen zijn sjablonen, bij import worden moduleparameters tekstueel vervangen door de opgegeven argumenten; polymorfie is gebaseerd op overloading. De belangrijkste innovatie van AFSL is echter de manier waarop zogenaamde nietfunctionele eigenschappen worden behandeld. De niet-functionele eigenschappen van een operatie zijn verborgen aspecten die vallen buiten het pure functionele input/output-gedrag. Voorbeelden hiervan zijn: afhandeling van foutmeldingen, lezen en schrijven van variabelen en communicatie met andere processen. Niet-functionele eigenschappen worden in AFSL op een vergelijkbare manier behandeld als bij de programmeertaal Haskell (het zogenaamde monads-mechanisme). Uitgangspunt hierbij is dat niet-functionele informatie wordt verpakt in het resultaat van de operatie. Speciale uitpakoperaties zijn nodig om de niet-functionele informatie verder te verwerken. Het nadeel hiervan is dat de verwerking van niet-functionele eigenschappen zichtbaar is binnen de specificatie, waardoor deze soms moeilijk te begrijpen is. AFSL heeft daarom de unieke mogelijkheid om via zogenaamde application redirection de uitpakoperaties impliciet toe te passen, waardoor ze niet meer zichtbaar zijn. Alhoewel de huidige versie van AFSL heel dicht in de buurt komt van de originele eisen, zijn er toch een aantal verbeteringen mogelijk: type-polymorfisme zal specificaties eenvoudiger maken, met name door de beperking van het aantal module-imports; flexibelere syntax voor functie-applicaties zal formuleringen toestaan die dichter staan bij wat gebruikelijk is binnen een bepaald domein; hogere-orde functies zullen een eenvoudiger behandeling van niet-functionele eigenschappen mogelijk maken; operationele semantiek maakt validatie en implementaie van specificaties eenvoudiger. Al deze verbeteringen vergen echter fundamentele aanpassingen aan AFSL, daarom zijn ze in de huidige versie niet opgenomen. Het is uiteindelijk niet gelukt om een methode van specificeren te ontwikkelen. Hiervoor zijn twee oorzaken aan te wijzen. Ten eerste kostte het ontwerpen en bestuderen van AFSL veel meer werk dan verwacht. De verschillende aspecten van een taal hebben vaak invloed op elkaar. Zo staan syntax, overloading, impliciete functies en application redirection in verband met elkaar omdat ze allemaal tot ambiguiteiten kunnen leiden. Verandering aan één aspect heeft daardoor vaak gevolgen voor de rest. Daarnaast zijn er weinig richtlijnen en hulpmiddelen voor het ontwikkelen van formele talen. Met name het ontbreken van een algemeen geaccepteerd mechanisme voor het definiëren van de semantiek was een grote handicap. De

5 tweede moeilijkheid bij het ontwikkelen van de methode was het ontbreken van bruikbare kennis waar op voortgebouwd kon worden. Bestaande objectgeorienteerde methoden bleken weinig concrete aanwijzingen te bevatten voor het het maken van modellen, meestal beperken ze zich tot de uitleg van de gebruikte notatie en voorbeelden van het gebruik. Achteraf is het de vraag of het wel mogelijk is richtlijnen te formuleren voor het maken van specificaties. Daarvoor is het proces nog te onbegrepen, bovendien is het heel moeilijk richtlijnen eenduidig te formuleren. In eerste instantie zullen we ons daarom moeten richten op het ontwikkelen van goede talen en automatische hulpmiddelen. Ondanks het niet vinden van de heilige graal is het onwikkelen van AFSL geen zinloze onderneming geweest. Een aantal belangrijke aspecten zijn aan de orde gekomen die van belang zijn voor de brede toepasbaarheid van formele specificatie. Als zodanig vormt dit proefschrift een proeftuin voor taalontwerp. De combinatie van taaleigenschappen is hierbij van groot belang, te vaak worden deze in isolatie bestudeerd zonder daarbij aandacht te besteden aan de practische toepasbaarheid binnen een groter geheel.