Implementering af en UML virtual maskine Peter Fachman Brovang

Transkript

1 Implementering af en UML virtual maskine Peter Fachman Brovang DTU Kgs. Lyngby 2009 IMM-MASTER-XXXXXX

2

3 1 Abstrakt Abstrakt Implementering af en UML virtual maskine UML modeller er uuværdige instrument i visualiseringen af software systemers struktur og adfærd. Imidlertid i de fleste tilfælde den nuværende feedback fås ved, at man manuelt inspektion af modellernes konsistent, eller ved at transformerer dem om til eksekverbar programkode. For UML modellerne mangler der et programværktøj, som man direkte kan undersøge og umiddelbart feedback om UML modellers. Historisk har UML virtual maskiner blevet anvendt, der har fastslået UML som et abstrakt programmeringssprog for selve softwaresystemerne. Fremfor at transformerer UML modellerne til programkode, skal den virtual maskine direkte fortolke modellerne uden transformation. Dog er brugen af UML virtual maskiner til at belyse modellernes adfærd for at give softwareudvikleren feedback således han kan forbedre modeller, dette område er meget mindre udforsket. Målsætningen med specialet er, at designe og implementerer en UML virtual maskine der understøtter softwareudvikleren i hans modelleringsopgave ved at eksekverer UML modeller. For at opgaven håndterbar der det kun tiltænkt, at der skal udvikles en prototype, som kun dækker de mest gense UML diagrammer, og kun inddrager kernefunktionaliteten for hver enkelt type af disse diagrammer. UML virtual maskine skal gerne understøtte automatiseret test, der gives ved sekvensdiagrammer som repræsentere tilladte og fejlende eksekveringer og OCL betingelser. Burde Desuden bør specialet også undersøge hvilken funktionalitet en UVM skal understøtte for at supporterer softwareudvikleren i udviklingsprocessen. F.eks. at illustrerer et eksekveringstracé via sekvensdiagrammer.

4 Indholdsfortegnelse 2 Implementation of a UML virtual machine UML models are an invaluable means of visualizing the structure of software systems and their behaviour. However, in most of the cases feedback is obtained by manually inspecting the models or by transforming the model to executable programs. The UML modeller is missing a tool to directly investigate and animate UML models for improved feedback. In the past, UML virtual machines have been used to establish UML as an abstract programming language for software systems itself. Instead of transforming UML models to code, they are interpreted by the virtual machine directly. However, the use UML virtual machines to animate models to give the software developer feedback to improve his models are less well studied subject. The goal of the thesis is to design and implement a UML virtual machine that supports the software developer in his modelling task by executing UML models. To keep the task manageable, it is envisaged only to implement a prototype that covers most of the UML diagram types by implementing only the core features of each diagram type. The UML virtual machine should support the automatic execution of tests, given as sequence diagrams of allowed / non-allowed execution traces and OCL constraints. Furthermore, the thesis should investigate what features does the UMV has to provide to support the software developer, for example, execution traces could be shown as sequence diagrams. Side 2 af 54

5 3 Resumé Resumé Dette speciale omhandler implementeringen af UML virtual maskine, og er lavet i perioden fra juli 2008 til og med januar Specialet er opdelt i fem kapitler. I det første kapital, introducerer læseren til begrebsverden og forståelse, samt bevæggrunde for specialet. kapital to omhandler vinkelen af eksekverbare modeller i forhold til MDA, samt hvad der kernen i MDA er, og hvilket paralleller der er til en UML virtual maskine. 1 Introduktion 9 2 Model Dreven Arkitektur 11 3 Model eksekveringsmiljøer 4 UML virtual maskine 5 Konklusion **** Et resumé af mit speciale

6 Indholdsfortegnelse 4 Forord Dette kandidatspeciale er lavet ved DTU Informatik institut for Informatik og Matematisk Modellering, Danmarks Tekniske Universitet, som det afsluttende projekt til at opnå den afsluttende eksamen som Civilingeniør i informatik. Specialet omhandler implementeringen af UML virtual maskine og eksekvering af modeller UML. Specialet undersøges de forskellige problemstillinger og omstændigheder, for modelrepræsentation og hvorledes dette har indflydelse på konstruktionen af en UML virtual maskine. Specialet anvender eksekverbart UML fra UML s semantiske arkitektur, med fokus på den finkornede adfærdsdefinition. DTU Kgs. Lyngby, januar 2009 Peter Fachmann Brovang Side 4 af 54

7 5 Forord

8 Indholdsfortegnelse 6 Indholdsfortegnelse Abstrakt... 1 Resumé... 3 Forord Indledning... Error! Bookmark not defined. 2 Model Dreven Arkitektur Modeltransformation Eksekverbare modeller Model eksekveringsmiljøer Skyva Mentor Graphics (BridgePoint UML Suite) CASCON '08 konferencen UML virtual maskine Indledning UVM specifikationssnit *** mangler et bedre ord UVM arkitektur Analyse Overordnede use case analyse UVM analyse Design Design af objekttilstand Design for eksekveringstracé Design af UVM eksekvering Design af OCL betingelser Implementering Objekttilstand Eksekveringstracé og validering UVM Eksekvering Modelrepræsentation Test Teststrategi Test scenarioer Konklusion Litteraturliste Appendiks Side 6 af 54

9 7 Indholdsfortegnelse

10 8 1 Introduktion I implementeringen af en UVM applikation, dækker et bredt område af hvad sådan et værktøj skal kunne. Dette kan dækker den udviklerens interaktion med applikationens brugergrænseflade, som design og udformning af modellen, forskellige former visualiseringer af modellers eksekvering, samt test og fejlscenarioer. Derfor er dette speciale afgrænset til området som omhandler selve eksekveringskernen i UML virtual maskinen. Fokus på kernen af UML 2 standardens metamodel Omskriv formulering således det passer til den nuværende løsning/problem Side 8 af 54

11 9 Introduktion

12 Model Dreven Arkitektur 10 2 Model Dreven Arkitektur Begrebet Model-dreven arkitektur (MDA) blev introduceret af OMG [5] i år 2001 til at definere strukturerede retningslinjer for domæneudvikling. MDA dækker en række områder som modeltransformation, UML, CWN (Common Warehouse Meta-model) og MOF (Meta-Object Facility). Indenfor området MDA er Stephen Mellor en af drivkræfterne, bl.a. som medforfatter til bøgerne [3,6]og er nu formand for UML Action Semantics Consortium. Derfor er hovedtrækkene i dette kapital baseret på Stephen Mellor publikationer. De væsentlige områder i MDA for dette speciale er områderne Eksekverbar UML og modeltransformation. Her vil vi se på kernen af områder og perspektiver i forhold til specialet. Stephen Mellor fortæller bl.a. i Agila MDA [4], at der er flere paralleller med metodiker som XP, hvor ordet code blot kan udskiftes med executable model. Stephen Mellor ligger vægt på, at den eksekverbar UML er konceptuelle og derfor ikke repræsenterer en direkte implementering for en given model. Det væsentlige er, at en transformation til en model kompiler skal præserverer abstraktionen i modellen. Svagheden i MDA terminologien er på hvilken måde modelverifikation skal finde sted. Fokus er primært på well-formedness transformationen til PSM. Der refereres løst til, at man kan anvende aktioner eller scripts til at verificerer modellens adfærd via de ændringer i objekttilstanden, som modellen gennemgået via eksekveringerne. 2.1 Modeltransformation Transformationen af uafhængige modeller til en platform specifik model er et af kerneområderne i MDA, dette kaldes for PIM/PSM transformation (se Figur 2.1-1). Begrebet PIM betyder, at vi f.eks. har en model, vis design er beskrevet i UML sproget. Når modellens design er komplet, kan vi tage vores model og transformerer modellen til XMI (XML Metadata Interchange), som så er platform specifik model (PSM). XML udgaven af modellen skal så igen blive brugt til at lave en automatiseret transformerer modellen til fysisk kode, f.eks. CORBA, Java eller dot-net. Figur 2.1-1: Transformation fra PIM til PSM (til kode) Side 10 af 54

13 11 Model Dreven Arkitektur Disse transformationer kan finde sted, da en UML model defineret i sit UML metamodellens sprog (captuered), og UML metamodellen er beskrevet (decribed) MOF (Meta-Object Facility), som f.eks. kan transformeres til XMI. Relationerne i PIM/PSM transformationen er illustreret på Figur nedenfor. Figur 2.1-2: Model-, Metamodel- & Platform relationer 3 Til at præcisere den semantiske forståelse af modellerne indeholder UML metamodellen allerede profiler (profile) til at udvide en eksisterende metamodel med nye modelelementer og stereotyper. Således at man kan introducere nye begreber eller konceptuelle forståelser af en model. Den interessante vinkel mellem MDA og en UVM er, at vi kan have forskellige semantiske forståelser af konkrete elementer i UML metamodellen, som kan afhænge hvilken kontekst for den aktuelle model er placeret i. UML metamodellens abstraktionsniveau tillader faktisk forskellige fortolkninger alt efter, i hvilken kontekst modellen er placeret i. Modeltransformationen i MDA tillader markeringer (marks), som kan anvendes på specifikke elementer i modellen, disse har betydning for hvorledes den aktuelle model bliver mappet til en konkret platform uden at kontaminere modellen. Dette er interessant i forhold til fortolkningen af modellen i en UVM, at vi kan sætte en bestemt semantisk forståelse af, hvorledes et eller flere modelelementer skal fortolkes under eksekveringen Eksekverbare modeller I MDA terminologien skal eksekveringen af en model, være verificering af modellens korrekthed, via UML metamodellen eksekverbar profil Action. Fundamentet for eksekveringen, som beskrevet i [5,6] er UML klasser, objekter, og tilstandsmaskiner med aktioner således at vi har en struktur for objekttilstanden og adfærd for tilstandsændringer. Modeller skal oversættes til en VM (model kompiler) og herefter eksekveres på VM. Her skal kernen, som beskrevet i 3 modellen, holdes på PIM niveau, således at transformationer til konkret kode af modellen ikke vil skjule eller sløre problemstillinger ved modellen. UML metamodellen tilbyder eksekverbart element via Action som abstraktsyntaks, men ikke som en del af notationsformen. Her definerer Stephen Mellor, at den konkrete syntaks kan være hvilket som helst sprog, enten dedikeret Action-Languages eller programmeringssprog som Java, som kan defineres i en OpaqueAction OpaqueAction (from BasicActions), side 264

14 Model eksekveringsmiljøer 12 3 Model eksekveringsmiljøer Dette kapital omhandler andres tilgang til model eksekveringsmiljøer (MRE) og sammenligner deres arbejde med MRE er i perspektiv med dette speciales arbejde med implementeringen af en UVM. 3.1 Skyva Skyva 2 er en amerikansk virksomhed, som allerede i 2001 havde implementeret den første succesfulde UML virtual maskine og præsenteret en UVM arkitektur ved OOPSLA'01 [7]. I 2002 sælges virksomheden til nye ejer, der omstrukturerer virksomheden og afskediger 80 procent af den samlede stab. Dette resulterer i, at videreudviklingen af denne UML virtual maskine stopper. Det, som gør Skyva s så interessant, er, at næsten alle mere eller mindre tager udgangspunkt i materialet, som blev præsenteret ved OOPSLA'01, af Dirk Riehle, Steven Fraleigh, Dirk Bucka-Lassen, and Nosa Omorogbe fra Skyva. Deres UVM arkitektur [7], er en 4-lags arkitektur, som illustreret i Figur Denne arkitektur er faktisk helt i tråd med, hvorledes dette speciale har forestillet sig den indre arkitektur af en UVM. I forhold til aktuel implementering af UVM en er kun laget M3 i arkitekturen undladt, som omhandler MOF/XMI, hvilket er inputtet fra et UML designer værktøj. Resten af lagene i arkitekturen er repræsentative for specialets UVM med UML definerede klasser (M2), hvor en konkret model har instanser af disse klasser (M1) og til sidst med konkrete objekter (M0), som er instanser af klasserne fra laget M1. Figur 3.1-1: Skyva UVM arkitektur [7] 2 Kilde: Side 12 af 54

15 13 Model eksekveringsmiljøer I [7] laves der et snit af arkitektur lagene, i henholdsvis en logisk og en fysisk arkitektur, som er vist nedenfor på Figur Hvor den fysiske arkitektur er den struktur, som en UVM skal have for at kunne repræsentere en model. Dette gøres, for at den logiske arkitektur kan afspejle modeller, skrevet i et UML sprog og herved repræsentere modellen i en UVM. Figur 3.1-2: Skyva s, logiske og fysiske instance-of relation mellem lagene [7] Materialet fra OOPSLA'01 har primært til målsætningen at definere en arkitektur for en UVM, derfor er vag omkring, hvorledes UVM skal understøtte eksekveringen af en model, men de beskriver, at de anvender tilstandsmaskiner for klasserne med aktioner på transitionerne mellem tilstandene. Specialet har ikke taget udgangspunkt i Skyva s arkitektur [7], men alligevel er specialet nået frem til en arkitektur, som på i overordnede træk er identisk med, hvad der blev præsenteret ved OOPSLA'01. Dette vidner om holdbarheden i deres betragtninger om, hvad det arkitektoniske fundament skal være for en UVM.

16 Model eksekveringsmiljøer Mentor Graphics (BridgePoint UML Suite) Mentors produkt BridgePoint UML Suite må betragtes som den ledende producent og leverandør af MDA værktøjer. Her har Stephen Mellor været chefforsker for Embedded Systems Division frem til 2006 og herefter formand for UML Action Semantics Consortium under OMG, samt medforfatter til bøgerne [6,3], som danner et grundlæggende fundament for dette speciale. Derfor kan det siges, at Stephen Mellor er en af de afgørende faktorer for Mentors nuværende position. BridgePoint UML Suite, er MDA værktøjet for indlejresystemer, som Mentor har udviklet. Deres designer (BridgePoint Builder) anvender UML 2.0 notation. Årsagen til deres fokus på indlejresystemer, er at verifikationsgabet mellem design og implementering i indlejresystemer er væsentligt større end ved en traditionel software applikationen. Hvorledes, de forskellige dele BridgePoint UML Suite er forbundet med hinanden, er vist på Figur nedenfor. Figur 3.2-1: BridgePoint UML Suite 3 BridgePoint er et proprietært produkt, derfor er der ikke de store afsløringer med hensyn til, hvorledes de løser forskellige problemstillinger i produktet. Men til BridgePoint har man udviklet en konkretsyntaks for den abstrakte syntaks af Action i UML, sproget der kaldes for Object-Action-Languages [8]. Forkortet OAL. Her anvender specialet netop OAL konkretsyntaks for at beskrive i UML notationsformen. Det som Stephen Mellor har publiceret om eksekverbar UML, som er [6,9], kan muligvis give et indblik i, hvorledes BridgePoint konceptuelt fungerer. Hvis det forholder sig således, er fundamentet i strukturen klasser med operationer og attributter, og tilstandsmaskiner. Her vil klasseoperationerne mappe til specifikke hændelser via tilstandsmaskinens transitioner. Her kan tilstandsmaskinens tilstande indeholde aktioner (Action) som en defineret adfærd. Dette er snittet for tilstandsmaskiner i UML s semantiskarkitektur 4. 3 Kilde: The Semantics Architecture, side 11 Side 14 af 54

17 15 Model eksekveringsmiljøer 3.3 CASCON '08 konferencen På CASCON konferencen i oktober 2008 [10] blev præsenteret et indlæg om en UVM fortolker, der tager udgangspunkt i UML 2 aktioner og aktiviteter, som fra en eksekveringsmæssig vinkel har nøjagtig samme snit af UML s semantiskarkitektur, som dette speciale. Deres tilgang er ligeledes tokens til evaluering af aktiviteten. Ydermere har de fået traversering af data via ObjectNode [1] henover kanterne (edge), og hermed kan transportere data mellem noderne. Deres fortolker kaldes for ACTi. Deres vinkel er mere programanalytisk 5. Ved at analysere mulige stier igennem aktiviteten. ACTi, gives brugeren flere muligheder for at vælge det udgangspunkt til eksekveringen, der skal anvendes i analysen. udgangspunkt er enten tilfældigt (random) eller et brugerdefineret input. ACTi kan analysere ønskede/uønskede noder, noder som bliver gensidigt udelukket, om præcedens for brugerdefineret orden overholdes, antallet af gange en sti (ActivityEdge) udføres, samt om aktiviteten overholder de semantiske regler for tokens, dvs. når en token når til en ActivityFinalNode, forefindes der ikke flere tokens i aktiviteten. Dette betyder, at ACTi fortolkeren har potentialer til at mindske verificeringsgabet ved at verificere konsistensen af modeladfærd som aktivitetsdiagrammer. 5 UK: Program Analysis

18 UML virtual maskine 16 4 UML virtual maskine Dette kapital omhandler udviklingen af UVM applikationen. Kapitlet er inddelt i en analyse, design, implementering, og test afsnit. 4.1 Indledning I begyndelsen af specialet blev flere forskellige muligheder undersøgt, med hensyn til hvorledes en implementering af en UVM kunne gennemføres. En af mulighederne, som blev undersøgt, var at benytte eksisterende platforme til implementeringen af en UVM. Her så vi muligheden i at anvende Eclipse EMF (Eclipse Modeling Framework), da den allerede indeholder en udgave af en Emof (Essential Meta-Object Facility), der er kaldes for Ecore. Fordelen ved, at bruge et framework som EMF, er at vi får forærende størstedelen af repræsentationen af UML elementerne, XMI parser, UML editor, og meget mere, dog inkluderer EMF ikke interaktionsdiagrammet fra UML standarden. Denne indfaldsvinkel giver en næsten færdig modelrepræsentation, men EMF er også et meget komplekst framework, som ville havde været ressourcekrævende for en UVM applikation, og specialet vil hermed være konceptuelt låst til den aktuelle fysiske implementering for EMF. For at vi bedre kan nå til essensen af en UVM s nødvendige behov for at eksekvere og validere modeller, blev det besluttet ikke at anvende eksisterende frameworks. Derfor blev det nødvendigt at identificere konkrete relationer mellem udvikler, hans model og interaktionen med UVM en. Disse beskrivelser er vedlagt i appendiks A er brugerhistorier for eksekvering og appendiks B omhandler brugergrænsefladen. I appendiks A, findes bl.a. brugerhistorier for UML tilstandsmaskiner, da tilstandsmaskiner allerede er et gennemarbejdet område. Derfor har vi valgt at undlade at udforske emnet yderligere. En anden gren af brugerhistorierne fra appendiks A, som også er blevet væsentlig reduceret, er hvorledes man kan anvende OCL betingelser til at udlede en given adfærd. Udledningen skulle have været sket ud fra OCL body- og postkonditioner, ved at analysere konditioner for den ønskede posttilstand. Dette er blevet reduceret til kun at blive gjort for forespørgselsoperationer, dvs. bodykonditionen. Årsagen er, at udledte OCL for eksekverbar adfærd ikke med i specialet, og at ikke alle OCL udtryk kan give en udledt adfærd, og det er problematisk at præcisere, hvornår et OCL udtryk skal anvendes til at udlede en given adfærd eller ej. Side 16 af 54

19 17 UML virtual maskine 4.2 UVM specifikationssnit Her vil vi se på, hvilke behov softwareudvikleren/-arkitekten har til en UVM. Disse behov skal definere minimumkravene til hvorledes en UVM skal formuleres. Derfor er tilgangen til UML metamodellen et minimalistiskudsnit, som kun inddrager den absolutte nødvendige funktionalitet fra metamodellen. Dette betyder, at parallelt med udviklingen af en UVM skal der laves repræsentative MOF (Meta-Object Facility) ud fra det perspektiv, at repræsentationen er nødvendig for UVM en til eksekvering. Fokus for den eksekverbare adfærd er en finkornet adfærd via aktivitetsdiagrammer og aktioner, som kan modificere objekttilstanden i UVM en. Derfor vil vi ligeledes som i [6] binde klasseoperationer til adfærd defineret i aktiviteter. Valideringen af modellens udførte adfærd skal ske igennem tests, som validerer at et eksekveringstracé stemmer overens med det forventede tracé defineret i et interaktions-diagram UVM arkitektur Vi kan opdele UVM ens modelrepræsentationen i en 4-lags arkitektur svarende til OMG s arkitektur (se Figur 4.2-1). Specialet har defineret et udsnit af elementerne fra UML metamodellen og ligeledes for OCL udtryk. Dette snit har vi så defineret en tilhørende MOF klasser for, således vi kan instantiere brugerdefinerede modeller og tilhørende objekttilstande for modellen. Figur 4.2-1: UVM arkitektur lag for model repræsentation (tilsvars OMG s) Ud fra dette kan vi sige at UVM en skal kunne indeholde en model, en objekttilstand for modellen, og at UVM en via eksekveringen producerer et tracé, som skal kunne valideres i en test case.

20 UML virtual maskine Analyse Denne sektion beskæftiger sig med hvorledes udvikleren (developer) skal interagerer med hans model og interaktionen med UVM en Overordnede use case analyse Førend udvikleren kan eksperiment med en model skal den først modelleres. Modellen har struktur, adfærd og betingelser for objekttilstanden, og for at validerer modellens adfærd skal udvikleren oprette test case. Herefter skabes en objekttilstand af modellen som udgangspunkt for model eksekveringen. Dette er illustreret med use case diagrammet på Figur Figur 4.3-1: Use case diagram udviklerens modellering Side 18 af 54

21 19 UML virtual maskine Modellen genereret fra Figur transformeres til XMI 6, således at modellen kan fortolkes af UVM en. Her skal udvikleren kunne eksekvere adfærd i modellen, som han efterfølgende kan validere med en test case. Da verificeringen af et eksekveringstracé ikke altid er validt, skal udvikleren også kunne observerer både objekttilstanden og selve eksekveringen i UVM en. Figur 4.3-2: Use case diagram for udvikler interaktion med UVM 6 XMI: XML Metadata Interchange

22 UML virtual maskine Use cases Use Case 1 Målsætning: Aktør: Beskrivelse: Prækondition: Postkondition: Trigger: Primært scenario: Opret model (create model) At lave en model, som kan eksekveres på en UVM Udvikler (developer) Udvikleren opretter struktur (klasser) og adfærd for modellen Der er allerede oprettet en model, som objekttilstanden kan reflektere Modellen er oprettet Ny model skal udarbejdes 1. Opretter statiskstruktur for modellen 2. Tilføjer klasser til modellen 3. Tilføjer attributter og operationer til klasserne 4. Indsætter associationen mellem klasserne 5. Udfør use case: Opret adfærd 6. Udfør use case: Opret betingelser Problemstillinger: - Use Case 2 Målsætning: Aktør: Beskrivelse: Prækondition: Postkondition: Trigger: - Primært scenario: Opret objekttilstand (create state) Definer en objekttilstand for modellen Udvikler (developer) Opretter objekter af modellens statiske struktur Der er allerede oprette en model, som objekttilstanden kan reflekterer Modellen er klar til eksekvering på UVM en 1. Opretter objekter og tilskriver attributter med konstantværdier 2. Linker relevante objekter sammen i objekttilstanden Problemstillinger: - Side 20 af 54

23 21 UML virtual maskine Use Case 3 Målsætning: Aktør: Beskrivelse: Prækondition: Postkondition: - Trigger: - Primært scenario: Opret adfærd (create behaviour) Der skal defineres en eksekverbar adfærd for modellen Udvikler (developer) Udvikleren kan definere adfærd via et aktivitetsdiagram med UML actions Modellens struktur for adfærden er allerede defineret 1. Udvikleren modellerer en aktivitet med tilhørende actions Alternativt scenario: 1a. Operationen har en simpel adfærd, som ikke er tilstandsændrende. Opretter en OCL bodykondition, som kan give en udledt adfærd Problemstillinger: Begrænsning af anvendelse for OCL udtryk Use Case 5 Målsætning: Aktør: Beskrivelse: Prækondition: Postkondition: - Trigger: Primært scenario: Opret test case (create test case) Laver test case for eksekveringen Udvikler (developer) Udvikleren laver et sekvensdiagram, som repræsenterer et aktuelt eksekveringstracé, og angiver eventuelle objekttilstande på de ønskede steder i tracés Struktur, adfærd, og evt. objekttilstand, som test casen gør brug af findes allerede Udvikleren skal verificere en angivet del af modellen. 1. Udvikleren placerer de nødvendige meddelelser (message) mellem aktuelle lifelines for objektinstanserne 2 Udvikleren angiver de påkrævede assertions i test casen Problemstillinger: Det er uafklaret, hvornår egenskaber for lifelines skal mappes til instanser af eksekveringstracé, eller hvornår disse referer til objekttilstanden

24 UML virtual maskine 22 Use Case 6 Målsætning: Aktør: Beskrivelse: Prækondition: Postkondition: Trigger: Primært scenario: Eksekver adfærd (execute behaviour) Eksekver en adfærd i modellen Udvikler (developer) Udvikleren sender en meddelelse til UVM en, som aktiverer en tilstandsændring Modellen er indlæst i UVM en Modellen objekttilstand har ændret sig Udvikleren skal bruge et eksekveringstracé til sin test case 1. Finder objektinstansen, som skal modtage en meddelelse 2. Udvælger den aktuelle meddelelse 3. Angiver eventuelle argumenter til meddelelsen 4. Mapper returargument til en variabel 5. Udvikleren eksekver udtryk 6. UVM en udskriver resultatet af variablen 7. Udvikleren gemmer eksekveringstracé således det kan anvendes af en test case Alternativt scenario: 4a. Der er intet returargument til meddelelsen Use Case 4 Målsætning: Aktør: Beskrivelse: Prækondition: Postkondition: - Trigger: Primært scenario: Opret betingelse (create constraint) Opretter en OCL kondition Udvikler (developer) En OCL kondition kan verificere konditioner objekttilstanden, før, efter og under eksekvering Struktur som konditionen anvender findes allerede i modellen Specifikationen for modellen indeholder OCL betingelser 1. Opretter betingelsen for det angivne element i modellen, konditionen skrives i den konkrete syntaks for OCL Problemstillinger: - Side 22 af 54

25 23 UML virtual maskine Use Case 7 Målsætning: Aktør: Beskrivelse: - Prækondition: Postkondition: - Trigger: - Primært scenario: Tracé validering (tracé validation) Validering af modellens eksekveringstracé Udvikler (developer) Det aktuelle tracé forefindes allerede 1. Finder den første meddelelse i sekvensdiagrammet 2. Evaluerer meddelelsen argumenter 3. Følger meddelelse til modtager instansen (receiver) 4. Verificer operation imod meddelelsen i sekvensen 5. Fra modtager instansen lifeline findes retursvar (reply) meddelelsen. 6. Pågældende tracé element er valideret. Proceduren gentages for den næste tracé element, indtil valideringen er afsluttet Alternativt scenario: 4a. Hvis pågældende lifeline har tilhørende objektinstans, kontrolleres objektet imod det objekt som er sammen tracés

26 UML virtual maskine 24 Use Case 8 Målsætning: Aktør: Beskrivelse: Prækondition: Postkondition: - Trigger: Primært scenario: Observer eksekvering (observe execution) Observer eksekvering i real time Udvikler (developer) Udvikleren observer UVM ens eksekveringen som ved debugging Udvikleren har indsat et break-point i modellen og startet eksekveringen En test case har fejlet udvikleren skal identificerer fejlen 1 Gentages: 1.1 UVM stopper ved break-point 1.2 Udvikleren kan observere objekttilstanden og konkrete element i adfærden 1.3 Udvikleren singlestep til næste element i adfærden Udvikleren afslutter observationen af eksekveringen Alternativt scenario: 1.3a Udvikleren kører frem til næste break-point Side 24 af 54

27 25 UML virtual maskine Use Case 9 Målsætning: Aktør: Beskrivelse: Prækondition: Postkondition: - Trigger: Primært scenario: Observer objekttilstand (observe state) Udvikleren skal kunne se den aktuelle objekttilstand Udvikler (developer) Udvikleren observerer den globale objekttilstand til modellen, herunder objekters egenskaber (properties) som de er i den aktuelle tilstand Det findes en objekttilstand for Udvikleren skal se objekttilstanden under eksekvering 1. Vælger et objekt i den globale objekttilstand 2 Vælger en egenskab for objektet 2.1 Egenskaben er et objekt, som igen slev har egenskaber 3 Brugeren afslutter, da han har fået informationerne fra objekttilstanden Alternativt scenario: 1a. Objektet er primitiv datatype kan dataene ses med det samme 2a Egenskaben er primitiv datatype kan dataene ses med det samme

28 UML virtual maskine UVM analyse Dette underafsnit vil vi gå i en dybere analyse af; hvad en objekttilstand (state) er, hvordan eksekveringen kan forekomme i UVM en, og hvorledes tracé valideringen skal forstås. For at gøre betragtninger mere forståelig vil være tilfælde hvor forskellige typer af UML modeller vil blive inddraget Analyse af objekttilstand På klassediagrammet har henholdsvis attributter på klassen og associationer mellem klasserne. Når vi skal oprette en objekttilstand af en model gøres via et objektdiagram, her repræsenteres klasserne via objektinstanser, attributter angives med deres initialiseret værdi og objekter bliver forbundet med links (instans af association). Når vi modellerer struktur eller tilstand for UML modeller kan vi skifte mellem enten at have en repræsentation relationer/egenskaber, som henholdsvis attributter eller associationer alt efter hvorledes det passer bedst ind i den kontekst, som modellen skal præsenteres i. I objektdiagrammet har vi de objekter, som er angivet med et variabelnavn i det globale miljø for hele modellen og disse objekter kan så igen være linket til anonyme objekter der kun kendes ved den reference. Side 26 af 54

29 27 UML virtual maskine Analyse for eksekveringstracé Intensionen er, at vi skal kunne tage et konkret eksekveringstracé og teste op imod et tracé defineret ved et sekvensdiagram. Herved skal den udførte adfærd af UVM en valideres imod det forventede tracé som et sekvensdiagram kan definere. Normalt betragter vi et eksekveringstracé. som en sekvens af meddelelser, der tvinger objekttilstanden fra en tilstand til den næste. Men strukturen i sekvensdiagrammet tillader, at vi kan have indlejret meddelelser i en kompositstruktur, som vist i eksempel 2 og 3 på Figur Figur 4.3-3: Eksempler på eksekveringstracé repræsenteret i sekvensdiagrammer

30 UML virtual maskine 28 På nedenstående Figur vises et udsnit af definitioner, som forefindes i UML standarden 7. Meddelelserne (message) getvalue i sekvensdiagrammet til objektet c repræsenterer ikke operationen, men input/output parametrene for kaldet. Operationen er derimod repræsenteret gennem Behaviour-Execution-Specification blokken, som holder operation igennem det Event for Execution-Specification. I det konkrete tilfælde er et Receive-Operation-Event. Figur 4.3-4: Definitionen for et sekvensdiagram 7 1 Kapital 14 Interactions Side 28 af 54

31 29 UML virtual maskine Analyse af eksekveringsadfærden Objekttilstanden som fås fra objektmodellen, her vil vi ændre tilstanden ved at sende meddelelser til et objekt i tilstanden, se Figur Her vil objektet kalde UVM en (UvmExecutor), der så udfører den konkrete adfærd, som meddelelsen definerer. Figur 4.3-5: Eksekvering i UVM'en Sådan en adfærd kan bl.a. defineres via et aktivitetsdiagram, som vist i Figur Her traverserer adfærden til den indlejrede Action, som udføres, hvorefter aktiviteten afsluttes. Den konkrete aktion semantik som Action indeholder, er ikke defineret af UML standarden. Standarden definerer kun en abstraktsyntaks for aktioner [1] for UML eksekverbar profil. Hvorledes den abstraktsyntaks omsættes til en konkretsyntaks individuelt producenterne, den konkrete syntaks anvendt i Figur er OAL [8] (Object-Action-Languages). Figur 4.3-6:Aktivitetsdiagram for increment metode på Counter klasse Da en adfærd i sig selv ikke behøver at have en tilstandsændrende effekt, kan også definerer forespørgselsfunktioner i OCL, som vist i nedenstående eksempel Figur context Counter::getValue(): int body: self.value Figur 4.3-7: OCL betingelse, hvorfra en simpel adfærd kan udledes [2]

32 UML virtual maskine Design Dette afsnit omhandler designet af UVM ens tre grundpiler objekttilstanden, tracé og eksekvering. For at præsentere designet af UVM eksekvering i en kontekst tages der udgang i Counter klasse eksemplet, som ses nedenfor i Figur Eksemplet inddrager alle de grundliggende elementer både for modeldefinition, objekttilstand, eksekvering og test Design af objekttilstand Figur 4.4-1: Counter klasse- og objektdiagram For at vi repræsenter Counter klassen og dennes objekttilstand, har vi klassen UvmState, som vist på nedenstående Figur I tilstanden mappes UmlObject dennes objekttilstand og miljø (PropertyEnv). Attributten value defineres via klassen PropertyEnv, som mapper en UmlProperty til en UvmInstance, som afgrænser domænet af objekter man kan mappe til, i eksemplet en integer. Figur 4.4-2: UvmState klassediagram, med tilhørende snit af UML metamodellen Den globale objekttilstand defineres ligeledes med en ProperEnv klassen, til UvmState klassen, via den stærke aggregering med property-name, som er global. Dvs. at UmlProperty mapper objekter i den globale tilstand. Et hvert UmlObject tilhørende en UmlClass. Klassen UmlClass definerer både egenskaber i objekttilstanden og hvilket operation (UmlOperation) som kan anvendes på et objekt. Klassen UmlOperation er igen repræsentant for en adfærd, der kan ændre objekttilstanden for et objekt. Side 30 af 54

33 31 UML virtual maskine Objekttilstand links UVM ens objekttilstand skal nu holde links. Dette gøres med klassen Link, som vist på Figur 4.4-3, klassen holder de objektinstanser scr og dest, som repræsenterer de egenskaber for association (UmlAssociation) via specialiseringsklassen Reference, som udvider med egenskaberne for multiplicitet. Figur 4.4-3: Datastruktur for association og links objekttilstand I UML metamodellen er definitionen lidt anderledes for Property 8 end vist på Figur Her kan (multiplicitet [0..1]) en Property have tilkoblet en association til sig, og definerer selv multipliciteten. Men for at vi kan undersøgelse af den potentielle forskel mellem attributter og links (associationer), differentieres der mellem de to betragtninger Property (from Kernel, AssociationClasses), side 123

34 UML virtual maskine Design for eksekveringstracé I analysen for eksekveringstracés, nåede vi frem til træstruktur for meddelelser sendt til UVM en. Hvor et Trace er en sekvens af meddelelser og hvis en adfærd for en meddelelse som resulterer i nye meddelelser til UVM en skal disse være sub elementer (TraceElement) til meddelelsen som aktiveret dem. Dette er illustreret med objektdiagrammet (se Figur 4.4-4) nedenfor, hvor Trace har en ordnet sekvens af, hvor hvert TraceElement igen kan indeholde en sub sekvens af TraceElement objekter. Figur 4.4-4: Objektdiagram for komposit datastruktur Træstrukturen kan omsætte til en den datastruktur, som klassediagrammet på Figur viser. Her har vi den abstrakte klasse AbstractTrace som definerer et ordnet set elements af type TraceElement, da begge klasser Trace og TraceElement nedarver funktionaliteten fra AbstractTrace har vi en datastruktur for træstrukturen. For at sikre associationen mellem AbstractTrace og TraceElement er korrekt, for klassen AbstractTrace ansvaret for at oprette objekterne, som er sub elementer til de to specialiseringsklasser Trace og TraceElement. Figur 4.4-5: Datastruktur for eksekveringstracé træstruktur Klassen TraceElement skal bære informationerne om hvilken eksekveringen UVM en har foretaget (se Figur 4.4-6). Derfor skal klassen vide hvilken meddelelse (UvmMessage), som er sendt til UVM en, hvilken operation (UmlOperation) meddelelsen matches med, og en hvilken objekttilstand (UvmState) som ved starten af eksekvering. Figur 4.4-6: Klassediagram for TraceElement Side 32 af 54

35 33 UML virtual maskine Design af UVM eksekvering UVM en har til opgave at udfører en adfærd defineret af en UmlOperation, som f.eks. kan være en aktivitet [1]. På nedenstående Figur vises interaktionen mellem UvmExecutor klassen og adfærden UvmBehaviour interfacet. Først identificeres den aktuelle operation ud fra meddelelsen sendt til UVM en, herefter hentes den aktuelle adfærd (behaviour) som så eksekveres. Figur 4.4-7: UVM udførelse af UvmBehaviour Datastrukturen for klassen UvmExecutor er ganske simpel, se Figur Klassen mapper operationer til en konkret adfærd, via interfacet UvmBehaviour kan vi anvende eksekverbar adfærd, som er defineret med et aktivitetsdiagram (klassen Activity). Figur 4.4-8: Klassediagram for UvmExecutor Til at kommunikerer inputdata og returargument (klassen UvmInstance), identifikation for adfærd og snittet af objekttilstanden, har vi klassen UvmMessage. Modtager objektet receiver er det objekt som definerer scope et for miljøet (self). Meddelelsen egenskab name bruges til at identificerer den konkrete operation. Figur 4.4-9: Datastruktur for UvmMessage

36 UML virtual maskine 34 Tidligere i analysen er det nævnt at i scenarioet hvor vi har simple forespørgselsfunktioner skal alternativt kunne udlede en adfærd fra en operationens OCL bodykondition, se Figur Dette gøres at tage outputværdien og sætte den som returargumentet i stedet for at sammenligne returværdien fra adfærden. Figur : Alternativ valg af adfærd for eksekvering Side 34 af 54

37 35 UML virtual maskine Design af OCL betingelser I nedenstående Figur ses OCL betingelserne for hver af de tre definerede operationer for Counter klassen. Hermed er designet afgrænset fra problemstillingen for objektinvarianter, og hvorledes disse skal valideres. context Counter::increment() post: self.value = self.value@pre + 1 context Counter::decrement() pre: self.value > 0 post: self.value = self.value@pre - 1 context Counter::getValue():int body: self.value Figur : Ocl betingelser for Counter klasse metoder [2] Som det fremgår af Figur skal operationen have tre typer af konditioner, henholdsvis pre, body og post. Da de tre typer af OCL betingelser skal evalueres under forskellige konditioner er der defineret tre specialiseringsklasser i datastrukturen for hver type af betingelse. Den fælles funktionalitet defineres i den abstrakte superklasse OclConstraint, klassen holder udtrykket (OclExpression), som skal evalueres. Figur : Ocl betingelser for klassen UmlOperation

38 UML virtual maskine Implementering Objekttilstand Snapshot af objekttilstanden Læs attributter Læs links Link validering create/destroy Eksekveringstracé og validering UVM Eksekvering Side 36 af 54

39 37 UML virtual maskine Modelrepræsentation For at repræsentere udsnittet af modelelementer, som er omtalt i tidligere afsnit. Inddelingen af underafsnit er en tilnærmelse af den kronologiske orden, hvorved de forskellige modelrepræsentationer udvidede UVM ens funktionalitet, som vist i nedenstående punktopstilling: Modelstruktur - Klassediagram Objekttilstand - Objektdiagram Eksekvering - Aktivitetsdiagram Test - Sekvensdiagram Tilstandsverifikation - OCL betingelser OCL udtryk Datastrukturen som er vist på Figur er de implementeret klasse for repræsentation af OCL udtryk [2]. Årsagen til den abstrakte klasse OclExpression implementerer interfaces ValueSpecification er vi anvender OCL udtryk til at evaluere konditionen i en DecisionNode, se afsnit

40 UML virtual maskine 38 Aktivitetsdiagram. For den konkrete syntaks self og result, findes der ikke tilsvarende en abstraktsyntaks og OCL standarden refererer sprogligt også til self, som en variabel der repræsenter konteksten af et objekt. Figur 4.5-1: Datastruktur for OCL Da vi i starten af udviklingsfasen for UVM en havde en vision om, at kunne verificerer klasse invarianter for bl.a. associationer, indeholde datastrukturen klassen IteratorExp, som implementerer collection operation udtrykkene forall og collect. Den fysiske implementering af klassen OperationCallExp på Figur og dens repræsentation af OCL standard [2] reference til UML s operation [1], kaldt for referredoperation. Har sin årsag en længere implementeringsteknisk diskussion om hvordan vi kunne reducerer kompleksiteten af den aktuelle implementering UVM en. En af mulighederne som blev undersøgt var hvordan vi kunne bruge Reflection og refleksive objekter. For at vi kan evaluerer OCL udtrykkene i er der defineres et fælles for de forskellige miljøer (environments). Her der en primære klasse er OclContextEnv, her defineres en kontekst med UmlObject kaldes self som i den konkrete syntaks. Det er også to associationer til objekttilstanden henholdsvis state og prestate, her oprettes prætilstanden med konstruktionen af klassen (se Figur 4.5-3). For håndtering er lokale variabler, som input/output parameter for en UML operation er implementeret et lokalt miljø kaldt for env. Her er defineret samme scoping for variabler mv., som i Java. Side 38 af 54

41 39 UML virtual maskine Figur 4.5-2: Kontekst for evalueringer af OCL udtryk public OclContextEnv(UmlObject object, UvmState state){ this.env = new Hashtable<Identifier, UvmInstance>(); this.put(self, object); this.self = object; this.state = state; this.prestate = state.snapshot(); } Figur 4.5-3: initialisering af OclContextEnv

42 UML virtual maskine 40 De to klasser OclEnvScope og OclObjectEnv er hjælpeklasser, der definerer til evalueringen af LoopExp s i datastrukturen. Ligeledes bruges klassen OclProxyEnv, som stedfortræder miljøet ContextEnv for implementeringen af interfaces ValueSpecification. For bedre at give en forståelse af konstruktionen af et OCL datastrukturen vises den objektdiagrammet (se Figur 4.5-5) for OCL udtrykket på Figur post: self.value = self.value@pre +1 Figur 4.5-4: OCL udtryk i konkretsyntaks Figur 4.5-5: Objektdiagram af OCL udtryk Side 40 af 54

43 41 UML virtual maskine Klassediagram og Objektdiagram Da vi allerede tidligere i designet af UVM en i afsnit Design af objekttilstand allerede har med datastrukturen af objekter og klasser. Fra OCL datastrukturen på har det været nødvendig er at inkludere klassen Variable, hvor den fælles funktionalitet udnyttes af specialiseringsklasserne UmlProperty og UmlParameter. Figur 4.5-6: Repræsentation of UML klasser og objekter Som det ses af Figur har vi to næsten ens associationer fra klassen UmlClass til klasserne UmlProperty og UmlOperation, der er lavet en generisk hjælpeklasse Container, som mapper klasserne UmlProperty og UmlOperation og håndter via deres fælles interface Identifier, som vist på Figur Interfaces Identifier bruges i flere sammenhænge bl.a. også til mappe værdi variabler, objekter og egenskaber i kontekstmiljøer (environment). Figur 4.5-7: Hjælpeklassen Container og interfaces Identifier

44 UML virtual maskine 42 Implementeringen af UML association og property forholdet er blevet lavet via en specialiseringsklasse Reference (se Figur 4.5-8), for at adskille funktionaliteten mellem egenskaber, som attribut og som referencer via links. Figur 4.5-8:Repræsentation af UML associationer Multipliciteten bliver efter modificering valideret med metodekaldet validate, hvis valideringen ikke overholder multipliciteten kastes en fejl. Når der skal forespørges på en associations link samling via et af dens property-name, dvs. vi referer til associationen som vi gør med attributter (se Figur 4.5-9). Så definerer multipliciteten om det er selve objektet som der er linket eller det er en samling af objekter, hvis multipliciteten har default værdien 1..1, så er det selve objektet, ellers returneres et UvmSet som indeholder objekterne, der er linket til. context Order::getPrice():int body: self.products.price->sum() Figur 4.5-9: Eksempel på kald til association via property-name Side 42 af 54

45 43 UML virtual maskine Aktioner (Actions) Aktioner er ikke en del af notationsformen i UML, men er en abstraktsyntaks der skal understøtte et sprogs konkrete syntaks for eksekverbart UML. Aktioner hører under basic behaviour UML semantiske arkitektur. Pga. at datastrukturen for aktioner er ganske omfattende er datastrukturen blevet opdelt i flere udsnit. Til at transportere data mellem forskellige aktioner bruges Pins (se Figur ). Anvendelsen af Pins tilsvar ikke hvorledes de er tiltænkt for aktivitetsdiagrammet. For at undgå traversering af data henover kanterne for aktioner skal man bruge klasserne ActionInputPin og ValuePin som input, derfor en Action kunne evaluerer sine InputPin s og heraf eval metoden på InputPin klassen. Figur : Datastruktur for Pins For at kunne evaluere udtrykkene, som hver aktion repræsenterer, implementerer klassen Action en metode eval der tager argumentet af ContextEnv (se Figur ), som indeholder de forskellige miljøvariabler. Klassen WriteVariableAction er simplificeret således den inkluderer den nødvendige funktionalitet af dens to specialiseringsklasser, dvs. indsætter variablen hvis den ikke findes i miljøet og overskriver hvis den allerede er defineret. Den abstrakte klasse StructuralFeatureAction, der referencen til en UML property, klassen WriteStructuralFeatureAction repræsenterer en simplificering af de to specialiseringsklasser. Figur : Datastruktur for læsning og skrivning af variable, egenskaber og læsning af scope

46 UML virtual maskine 44 For at kalde en anden adfærd eller rekursive aktivere adfærden. Her er ligeledes to specialiseringsklasser for CallOperationAction, hvor klassen InteranlOperationAction klassen repræsenterer binær- og monadisk udtryk, imens operationer fra modellen repræsenteres i klassen ObjectOperationAction (se Figur ). Figur : Datastruktur for InvocationAction For håndtering af objekter og links har vi aktionerne vist i Figur , her kan vi oprette objekter og oprette/nedlægge links mellem objekter baseret på objekter og deres property-name for associationen. Figur : Datastruktur for Link og Objekt aktioner Side 44 af 54

47 45 UML virtual maskine Aktivitetsdiagram Den eksekverbare adfærd, som et aktivitetsdiagram repræsenter implementerer ikke på nuværende tidspunkt parallelisme og traversering af data mellem noderne. Oprindelig var det målsætningen denne funktionalitet skulle være inkluderet i adfærden for aktivitetsdiagrammer. Derfor eksekveringen kun simulerer en tilsvarende adfærd af en tilstandsmaskine. Datastrukturen er som vist på Figur Figur : Datastruktur for Aktivitetsdiagrammet Implementeringen af klassen Activity på Figur inkluderer dog en work-list og håndtering af tokens for parallel eksekvering af noderne i aktiviteten. Princippet i work-list en FIFO herved er der ikke gjort en indsats for skabe en tilfældig orden af eksekveringen af noderne. Adfærden kan håndtere multiple node for eksekvering og eksekveringen af work-list en tilendebringes, når den aktuelle node i listen er et objekt af klassen ActivityFinalNode.

48 UML virtual maskine Interaktionsdiagram Det er datastruktur for repræsentationen af interaktionsdiagrammet/sekvensdiagram, for validering af klassen Interaction evaluerer et eksekveringstraces via instans af TraceContext, som skal gives til metoden eval. Figur : Datastruktur for interaktionsdiagrammet En UML operation er bundet til interaktionens via klasse Event (se Figur og Figur ) via klassen BehaviorExecutionSpecification og specialiseringen af klassen MessageEvent. Figur : Datastruktur for Events Side 46 af 54

49 47 UML virtual maskine 4.6 Test Teststrategi Beskrivelse af min teststrategi Eksempler på hvordan jeg har anvendt teststrategien Test scenarioer Interessante eksempler på test scenarioer

50 UML virtual maskine 48 Side 48 af 54

51 49 Konklusion 5 Konklusion Den interne repræsentation af attributværdier og link i UVM en bur være den samme (næsten skal stadigvæk identificerer forskellen), imens det er præsentationen af en konkret objekttilstand som gør forskellen. Modeller er mere en struktur, modeller er struktur og adfærd. Høj kompleksitet selv om meget begrænset udsnit

52 Konklusion Fremtidigarbejde Side 50 af 54

53 51 Litteraturliste 6 Litteraturliste [1] OMG, Unified Modeling Language: Superstructure, version 2.1.1, formal [2] OMG, Object Constraint Language: Available Specification Version 2.0, formal [3] Stephen J. Mellor; Kendall Scott; Axel Uhl; Dirk Weise, MDA Distilled: Principles of Model-Driven Architecture, Addison-Wesley Professional, 2004 [4] Stephen J. Mellor, Agile MDA - A White Paper, OMG [5] OMG, Model Driven Architecture [6] Stephen J. Mellor & Marc J. Balcer, Executable UML: A Foundation for Model-Driven Architecture, Addison Wesley Professional, 2002 [7] Dirk Riehle, Steven Fraleigh, Dirk Bucka-Lassen, Nosa Omorogbe, The Architecture of a UML Virtual Machine, OOPSLA '01, ACM Press, Page pdf [8] Mentor Graphics (Projekt Technology), Object Action Language Manual, Version 1.4, UML modeller BridgePoint [9] Stepehn J. Mellor, OMG, Embeded System in UML, in_uml_by_s_mellor.pdf [10] Michelle L. Crane & Juergen Dingel Towards a UML virtual machine: implementing an interpreter for UML 2 actions and activities. In Proceedings of the 2008 Conference of the Center For Advanced Studies on Collaborative Research: Meeting of Minds (Ontario, Canada, October 27-30, 2008).. CASCON '08. ACM, [OCL-MDA] Object Constraint Language, Getting Your Models Ready for MDA by Jos Warmer; Anneke Kleppe

54 Litteraturliste 52 Publisher: Addison Wesley Professional Pub Date: August 27, 2003 Print ISBN-10: [Automata] [Guide] AutomataTheory, Languages and Computation by John E. Hopcroft, Rajeev Motwani & Jeffrey D. Ullman Publisher: Pearson, Addison Wesley ISBN: Unified Modeling Language User Guide, The, Second Edition by Grady Booch; James Rumbaugh; Ivar Jacobson Publisher: Addison Wesley Professional Pub Date: May 19, 2005 Print ISBN-10: Side 52 af 54