Dankwoord - martes

Recommendations

Info

56 HOOFDSTUK 5. CASE STUDY - ROYAL AND LOYAL Figuur 5.2: Het model van Royal and Loyal We hebben alle constraints op het model gegenereerd met behulp van het HAT tool met paar uitzonderingen. Met sommige constraints hadden we moeilijkheden om deze te kunnen valideren in het tool zelf. Indien een beperking niet gevalideerd is dan kan deze niet gegenereerd worden. Bijgevolg moesten we de constraints licht aanpassen om deze te kunnen genereren. We gaan nu de punten bespreken waarop we aanpassingen moesten uitvoeren of gewoon niets konden doen. • Indien we in een OCL expressie een associatie hebben die een collectie van objecten voorstelt (dus multipliciteit is groter dan een) en indien deze associatie op zijn beurt een tweede associatie oproept dan worden zulke OCL expressie in HAT niet gevalideerd.
5.2. VERTALING MET BEHULP VAN HAT 57 In zulke gevallen zijn er geen mogelijkheden om aanpassingen uit te voeren. Bijgevolg hebben we OCL expressies van deze soort genegeerd. We geven een voorbeeld van zo'n OCL expressie in de context LoayaltyProgram zie figuur 5.1 context LoayaltyProgram inv: partners.deliveredServices -> forall(x|x.condition = true) • Indien we twee klassen hebben die met elkaar verbonden worden met een associatieklasse, dan kunnen we niet navigeren via deze associatieklasse. In OCL navigeert men in dergelijke situaties door de naam van de associatieklasse te concateneren aan de naam van het gewenste associatieeinde en deze met een punt uit elkaar te scheiden. De naam van de associatieklasse moet met een hoofdletter beginnen. In HAT worden deze OCL expressies niet gevalideerd. Dat was ook een van de redenen waarom we onze associatieklasse Membership naar een gewone klasse getransformeerd hebben. Voorbeeld van zulke expressies is de volgende OCL expressie (zie figuur 5.1) context Customer inv: Membership.account -> select(x|x.points>0)->isEmpty() • Indien we constraints in de context van een associatieklasse willen denieren dan moeten we deze in HAT denieren bij een van de betrokkene klassen bij deze associatieklasse. Met andere woorden wordt de context van deze constraint niet de associatieklasse maar een van de betrokken klassen. Daarvoor hebben we uit de associatieklasse een gewone klasse gemaakt. • Veel van de postcondities bevatten sleutelwoorden zoals @pre en result. Voor OCL expressies die het sleutelwoord result bevatten kunnen we niets doen. Deze expressies zijn niet gevalideerd. De sleutelwoorden @pre hebben we gewoon niet toegevoegd. Bijgevolg is ook de betekenis van een OCL expressie veranderd maar deze expressies zijn wel gevalideerd in HAT en gegenereerd. Indien we zulke OCL expressie negeren dan kunnen we onze intelligente aanpak niet testen. Daarom hebben we zulke expressies behouden maar we hebben deze licht aangepast aangepast . Bijvoorbeeld de volgende OCL expressie: context LoayaltyProgram::enroll(c:Customer) post: wordt participants = participants@pre->including(c) context LoayaltyProgram::enroll(c:Customer) post: participants = participants->including(c) De aanpakken die we in hoofdstuk 3 ontwikkeld hebben werkten zoals ze beschreven waren. We konden een groot deel van de code direct van ons model genereren. Indien we nu onze gegenereerde code met de handgeschreven code gaan vergelijken dan zou er toch een groot verschil zijn. Een groot deel was hierboven beschreven. We hebben een inspanning gedaan om het tool te laten evalueren op een gevalstudie. Indien we sommige aanpassingen niet gedaan hebben op ons model zouden de resultaten niet bevredigend worden. Maar de tekorten wat betreft associatieklassen kunnen altijd opgelost worden.
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 and 14: Hoofdstuk 2 State-of-the-art De Obj
Page 15 and 16: 2.1. EVALUATIECRITERIA 9 2.1.6 Asse
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: 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?