Dankwoord - martes

Recommendations

Info

8 HOOFDSTUK 2. STATE-OF-THE-ART 2.1.2 Pre- en Postcondities Indien men een meer complete specicatie van een systeem wenst is belangrijk om gebruik te maken van preen postcondities. Pre- en postcondities zijn beperkingen die de eecten en toepasbaarheid van operaties speciceren. In subsectie 3.1.2 zullen we dieper ingaan op preen postcondities. Sommige tools [13] beperken zich alleen maar tot precondities. De argumenten achter deze beslissing zijn dat de gebruiker de regels van een contract moet volgen. Indien dat niet zo is, is er geen garantie dat het resultaat van het uitvoeren van een stuk code correct zal verlopen. Verder wordt ook verondersteld dat het uitvoeren van een stuk code altijd correct beëindigt indien de precondities niet geschonden zijn. In deze thesis vertegenwoordigen we het gebruik van preen postcondities. De vereisten zijn dat een tool beide soorten van constraints ondersteunt. We hebben al twee soorten van constraints gezien: klasse-invarianten, preen postcondities. Bij elk van deze soorten van constraints zijn er verschillende modelelementen betrokken, namelijk attributen, associatie, operaties, enz. 2.1.3 Attributen en Associaties Indien de visibiliteit van attributen en associaties als private gemodelleerd is dan zijn deze beperkt tot de klasse waarin ze gedenieerde zijn. Om naar deze modelelementen te kunnen refereren is het essentieel om inspectoren voor deze modelelementen te denieren. Indien een tool ondersteuning biedt voor invarianten en preen postcondities moet het tool minimaal een vertaling van eenvoudige constraints ondersteunen. Met eenvoudige constraints bedoelen we constraints die bijvoorbeeld alleen maar attributen en operaties op deze attributen bevatten. Ook vallen enkelvoudige associaties in deze categorie. Indien de associaties een collectie voorstellen is dat niet meer het geval. Dit wordt uitgelegd in de volgende paragraaf. 2.1.4 Operaties op collecties Er bestaan twee soorten van operaties op collecties: zij die over de collecties itereren en zij die dat niet doen. Hier focussen we op de eerste soort, namelijk collectieiteratoren. In JAVA hebben OCL collectieiteratoren geen tegenhangers. Bijgevolg verkrijgen we meestal complexe constructies na de vertaling van deze collectieiteratoren naar een doeltaal. Wat we hier willen onderzoeken is in welke mate de complexiteit van deze constructies kan worden gereduceerd. 2.1.5 @pre en result In OCL zijn er ook meer geavanceerde constructies voor postcondities. Hier bedoelen we constructies die naar waarden van modelelementen op twee verschillende tijdstippen refereren, bijvoorbeeld de OCL constructie @pre. Een andere constructie is een constructie die het result sleutelwoord bevat. Dit sleutelwoord duidt de terugwaarde van een operatie aan. Het type van result hangt af van het terugtype van de operatie. Beide sleutelwoorden kunnen de specicatie van een model verbeteren en hun vertaling naar een doeltaal is hier gewaardeerd
2.1. EVALUATIECRITERIA 9 2.1.6 Assertion Hoewel deze criteria cruciaal zijn ontbreekt nog een deel van de puzzel. Is de transformatie uiteindelijk betrouwbaar? Wat gebeurt als een constraint geschonden is? Is er een exceptie gegooid? Dat zijn allemaal vragen die men kan stellen. Hiervoor gebruiken we de techniek van assertion [14]. In sommige programmeertalen is dat volledig ondersteunt of helemaal niet. Try-catch blokken zijn geen slechte manier van werken. Maar bij het uitvoeren van een systeem zal elke constraint nagegaan worden. Bij het installeren (deployment) leidt dat tot een vertraagd systeem. Daarom verkiezen we voor de assertion techniek die ons toelaat om de beslissing te nemen over het aan- en uitschakelen van de constraints op run-time. Een code die geen van deze twee technieken gebruikt beschouwen we als slechte code. 2.1.7 Slimme controle van klasse-invarianten De criteria die we hanteren wat betreft de technieken voor het nagaan van voldoening van constraints hebben we hierboven beschreven. Eveneens van belang is de vraag of we telkens alle klasse-invarianten moeten nagaan na het uitvoeren van een publieke methode. Misschien is het wel beter om enkel de relevante klasse-invariaten te inspecteren. In hoofdstuk 3 gaan we een mogelijke intelligente methode voorstellen om na het uitvoeren van een publieke methode alleen maar relevante klasse-invarianten na te gaan. Alles wat we tot nu toe besproken hebben is samengevat in tabel 2.1. Deze tabel somt een aantal criteria op en geeft voor elke vereiste een beschrijving. Id Criteria Beschrijving 1 invarianten Garanderen een geldige toestand van objecten 2 pre-, postcondities Vervolledigen de specicatie door constraints op operaties toe te voegen 3 attributen, Basismodelelementen in een OCL associaties expressie 4 collectieiteratoren OCL collectieiteratoren hebben geen substituten in JAVA - hoe worden hulp operaties gegenereerd 5 @pre Verbeteren de specicatie van postcondities door naar waarden op verschillende tijdstippen te refereren 6 result Verbeteren de specicatie van postcondities(geeft de terugwaarde van operaties terug) 7 assertion De manier van controle: zijn de constraints al dan niet geschonden 8 Slimme controle van Zijn alle constraints nagegaan of maar deze klasse-invarianten die relevant zijn Tabel 2.1: Evaluatiecriteria voor transformatie van OCL expressies door een tool
Page 1 and 2: Dankwoord Ik wil alle mensen bedank
Page 3 and 4: INHOUDSOPGAVE iii 3 Methodologie 17
Page 5 and 6: L¼st van guren 1.1 Relatie tussen
Page 7 and 8: Hoofdstuk 1 Inleiding 1.1 Situering
Page 9 and 10: 1.2. PROBLEEM BESCHRIJVING 3 1.2 Pr
Page 11 and 12: 1.4. DOELSTELLINGEN 5 • Ten vierd
Page 13: Hoofdstuk 2 State-of-the-art De Obj
Page 17 and 18: 2.2. TOOLS 11 alleen maar invariant
Page 19 and 20: 2.2. TOOLS 13 compleet systeem als
Page 21 and 22: 2.2. TOOLS 15 Indien het sleutelwoo
Page 23 and 24: Hoofdstuk 3 Methodologie In dit hoo
Page 25 and 26: 3.1. DESIGN BY CONTRACT 19 Het prin
Page 27 and 28: 3.2. BESCHRIJVING VAN DE METHODOLOG
Page 43 and 44: 3.3. NAÏEVE AANPAK 37 Listing 26 S
Page 45 and 46: 3.3. NAÏEVE AANPAK 39 Listing 30 v
Page 47 and 48: 3.4. INTELLIGENTE AANPAK 41 Figuur
Page 49 and 50: 3.5. EVALUATIE 43 3.4.4.1 Inkapseli
Page 51 and 52: 3.5. EVALUATIE 45 Figuur 3.2: Klass
Page 53 and 54: 4.1. HAT 47 Figuur 4.1: Architectuu
Page 55 and 56: 4.2. RUN-TIME OCL NAAR JAVA 49 Figu
Page 57 and 58: 4.3. NAÏEVE AANPAK IN HAT 51 van d
Page 59 and 60: 4.5. EVALUATIE 53 Id Criteria Opmer
Page 61 and 62: 5.2. VERTALING MET BEHULP VAN HAT 5
Page 63 and 64: 5.2. VERTALING MET BEHULP VAN HAT 5
Page 65 and 66:
Hoofdstuk 6 Besluit MDD zou moeten
Page 67 and 68:
6.4. TOEKOMSTIG WERK: UITBREIDINGEN
Page 69 and 70:
Bibliograe [1] A.Kleppe, J.Warmer,
show all

Dankwoord - martes

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?