Generering av Universella Editorer Peter Ljungqvist Department of Computer Science Åbo Akademi University, FIN-20520, Åbo, Finland email:pljungqv@abo. Klassicering enligt ACM: D.2.2 Design Tools and Techniques Klassicering enligt ACM-SIG: SIGSOFT 1
Sammanfattning Editorer för visuella språk, bör vara så enkla som möjligt att använda. Dessutom bör det vara möjligt för användaren att generera en editor som är specik för det visuella språk han använder. I denna artikel diskuteras vilka fördelarna kan vara av att använda sig av denna editorgenerering. För alla praktiska exempel kommer språket UML [UML03] att användas, eftersom det är det kändaste och mest använda visuella språket idag. I denna artikel kommer verktyget SMW [SMW03] att användas, för att beskriva hur ett modelleringsverktyg för diagram kan se ut. 1 Inledning För att eektivt kunna arbeta med visuella språk behövs speciella verktyg, speciellt editorer, som är specika för det språk man använder sig av. Man kan förstås använda sig av ett vanligt ritprogram för att rita diagram och symboler, men det är inte ett speciellt eektivt sätt. Det är då svårt att jobba med språket och att modiera diagramen. För att rita diagram behövs alltså en editor, som är anpassad för detta ändamål. SMW är ett program, som använder sig av editorer för att för att tillverka och manipulera såväl diagram, som deras bakomliggande modell. För tillfället har SMW inget sätt att generera nya språkspecika editorer, utan dessa måste tills vidare programmeras för hand. För att beskriva ett visuellt språk behövs en metamodell av språket. En metamodell är en specikation över språket och en beskrivning av språkets grammatik. Olika sätt att representera denna metamodell, t.ex. XMI [OMG03], tas upp i denna rapport. 2 Representation av modeller Detta kapitel kommer att förklara vad modeller och metamodeller är och hur de kan representeras. En metamodell är en modell som berättar hur språket för den modell man kommer att konstruera bör se ut. Metamodellen beskriver vilka element modellen kan innehålla, deras attribut och eventuellt hur dessa element kan kopplas till varandra. Modellen i sin tur är vad användaren gör med hjälp av editorn. Den innehåller information om de konkreta elementen, deras attribut och hur de är kopplade till varandra. 2.1 Metamodeller För att kunna berätta åt editorn vilken data som behövs för att beskriva ett språk, behövs en metamodell. Metamodellen innehåller en specikation över språket och en beskrivning
av språkets grammatik. Med hjälp av denna metamodell kan man därefter generera en editor för att skapa och manipulera modeller, som använder sig av det i metamodellen beskrivna språket. OMG standarden följer en fyra nivås standard för att deniera UML. Ett exempel på vad som nns i vilken nivå kan ses i tabell 2.1. Nivå Beskrivning Exempel meta-metamodell Beskriver metamodellen. MetaClass, MetaAttribute metamodell En instans av en metametamodell. Class, Attribute Beskriver språket för en modell. modell En instans av en metamodell. Aktie, pris Denierar ett språk för att beskriva ett system. användarobjekt En instans av en modell. Beskriver ett specikt system. Nokia_Aktie, 200 Tabell 1: Metamodellarkitektur i fyra nivåer Det nns ett antal olika sätt att beskriva metamodellen. Den kan antingen beskrivas med hjälp av ett diagram eller av en l som innehåller data in något speciellt format. Figur 1 visar ett utdrag ur metamodellen för klassdiagram i UML. Ur guren kan man bland annat se att alla element i UML är subklasser av klassen ModelElement och att alla element har ett namn. En närmare granskning av guren ger informationen att alla klasser kan ha ett obegränsat antal attribut. I det här fallet beskrivs metamodellen för UML klassdiagram i form av ett UML klassdiagram, vilket är intressant. Man kan alltså beskriva ett språk med hjälp av språket självt. Det nns dock många andra format för att beskriva metamodellen för ett språk. Ett format som har visat sig vara användbart för lagring av metamodeller är XML [W3C00] och speciellt dess subformat XMI. XMI(XML Metadata Interchange) är precis som namnet antyder speciellt utvecklat för utbyte av metadata. XMI består av ett antal grundläggande regler för hur dokumenten skall skapas, deras innehåll beskrivs med hjälp av taggar. Ett XMI dokument ser med andra ord ut som ett html dokument, vars utseende är bekant för de esta. Figur 2 visar ett exempel på ett utrdrag ur ett XMI dokument. Som man kan se ur exemplet innehåller dokumentet alltså ett antal taggar med
Figur 1: Ett utdrag ur metamodellen för UML olika namn och attribut. Alla element i modellen har ett speciellt id(xmi.id), för att de skall gå att skilja åt. Inom en snar framtid kommer de esta verktyg för modellering av diagram att använda sig av detta format för lagring av information. XMI är perfekt för att användas för språk som beskriver objektorienterade språk eftersom det byggs upp av element och attribut, precis som objektorienterade språk byggs upp av klasser och attribut. 2.2 Utvidgning av XMI Efter att man har skapat ett dokument i XMI, kan man utvidga den graska informationen i dokumentet. Detta görs för att skapa olika representationer av modellen. En möjlighet är att skapa en representation i SVG. SVG(Scalable Vector Graphics) är en teknologi för att beskriva vektorgrak i ett textbaserat format och producera en visualisering utgående från denna. Det textbaserade formatet är ett XML format. SVG är rekommenderat av W3C [?]. Användningen av vektorgrak ger upphov till ett ertal möjligheter, som inte nns om man skulle använda sig av ren grak, t.ex. bitmaps. Några av möjligheterna är att man kan skala och rotera även enskilda element då man använder sig av vektorgrak. I bitmaps kan man bara utföra dessa operationer på hela bilder. XSLT (extensible Stylesheet Language) [W3C] är en annan teknik som denierar
<?xml version="1.0"encoding="utf-8"?> <XMI xmi.version='1.1' xmlns:model='omg.org/mof.model/1.3'> <XMI.header> <XMI.model xmi.name='uml' xmi.version='1.4'/> <XMI.metamodel xmi.name='model' xmi.version='1.3'/> </XMI.header> <XMI.content> <Model:Package xmi.id='a0' name='uml' isroot='false' isleaf='false'> <Model:Namespace.contents> <Model:Tag xmi.id='a1'... Figur 2: Exempel på ett XMI dokument tillverkningen av stylesheets för utvidgning av XML. Även XSLT är rekommenderat av W3C och använder sig också av XML. I det här fallet transformeras XMI dokumentet till ett SVG XML dokument som innehåller grakinformation som kan läsas av en webbläsare med stöd för SVG. 2.3 UML-modeller och diagramdata XMI anpassas för lagring av UML-modeller med hjälp av en speciell DTD. Denna speciella anpassning av XMI för just UML brukar beskrivas XMI[UML]. En DTD(Document Type Declaration) är en deniton på hur själva XML-len och dess element och attribut bör tolkas. I detta fall beskriver denna DTD alltså vilka element som nns i UML och hur de kan kopplas till varandra. Enbart en beskrivning av själva modellen räcker dock inte för att man skall kunna lagra all information som behövs för att beskriva ett diagram i UML. Man måste också kunna lagra information över hur det diagrammet ser ut rent graskt. För detta ändamål har en speciell DTD för diagram information skapats. Den kallas UML Diagram Interchange och den förkortas XMI[DI] [GD03]. Den innehåller bland annat information om hur de olika elementen är placerade, deras storlek, färg... Med hjälp av dessa två XMI-ler kan man nu lagra all information om ett diagram, som behövs för att man skall kunna återskapa diagrammet. Med hjälp av denna information kan man också förytta diagrammet mellan olika modelleringsverktyg. Diagramdatan behöver inte som i detta exempel vara just en l av typen UML[DI].
Det kan vara en hurudan beskrivnig som helst. Det viktiga är att den innehåller all information, som behövs för att man skall kunna återskapa den graska delen av modellen. Mera om detta i kapitlet om editorer. 3 Generering av editorer Detta kapitel behandlar editorer och vad de behövs till. Först kommer en kort beskrivning av vad en editor är och därefter berättas det om funktioner specika för en diagrameditor. 3.1 Vad är en editor? En editor är ett verktyg för att rita och manipulera diagram. Förutom modellen, som beskrivits tidigare, behöver vi även ett sätt att visualisera den. Det som behövs är en grask visualisering av modellen. Genom att manipulera denna graska beskrivning kan man ändra på själva modellen, eller enbart på utseendet av den. En editor består åtminstone av en meny och ett verktygsfält, där man ser en bild av modellen. Från menyn kan man välja att t.ex spara modellen, lägga till element eller kopiera och klistra in element. I verktygsfältet kan man med hjälp av enkla musrörelser ytta och ändra på elementen för att den visuella delen skall se ut, som man vill ha den att se ut. Om användaren väljer att radera ett element från verktygsfältet, bör det även raderas från den bakomliggande modellen. Man kan alltså säga att en editor är ett verktyg för att underlätta manipulerandet av modeller för användaren. En editor har vissa funktioner som är oberoende av vilken sorts diagram man vill editera. Exempel på sådana är funktioner för att spara modeller, kopiera, klippa och klistra. Till dessa allmänna funktioner hör även allt som har med modelleringsverktygets utseende och funktion att göra, t.ex. hur olika fönster sköts om och hur man skriver ut sitt diagram på en skrivare. Man kan alltså säga att en editor består av två olika huvuddelar, dvs. funktioner som är specika för det visuella språk man editerar och funktioner som gäller oberoende av språk. I vissa publikationer kan man se uttrycket editor användas enbart för de funktioner som är språkspecika och ordet modelleringsverktyg för hela programmet. I denna uppsats behandlas genereringen av editorer, dvs. enbart generering av funktioner som är specika för ett visst visuelt språk. De funktioner i ett modelleringsverktyg som är allmänna för alla språk behöver inte genereras, eftersom dessa funktioner endast behöver implementeras en gång.
3.2 En metamodell för enkla graska objekt För att generering av editorer skall kunna göras automatisk, måste det nnas ett sätt att beskriva hur de olika elementen i ett diagram skall se ut. Det som behövs är en metamodell för graska primitiver. Domokos och Varro [DOM02] beskriver hur en dylik metamodell kan se ut. Element i olika diagram har många saker gemensamt. Alla består av noder och bågar. Noderna beskrivs ofta som ellipser eller rektanglar, bågarna beskrivs som linjer eller pilar. Detta kan man dra bytta av då man försöker skapa en metamodell för generella diagram. Noderna har dessutom en position och en färg. Bågarna å sin sida har en startpunkt och en slutpunkt. I vissa typer av diagram kan bågarna ha ere start- och slutpunkter. När man försöker skapa en metamodell för generella diagram måste man vara försiktig med sådana faktum. Om man i metamodellen inte tillåter bågar att ha ere start eller slutpunkter kommer man förr eller senare att få problem och vara tvungen att ändra om sin metamodell. Figur 3 visar hur en metamodell för de graska objekten kan se ut. Alla graska element är subklasser till klassen GraphPrimitives. Från guren kan man också se hur noder och bågar är kopplade till varandra. De olika elementen har attribut som är specika för dem. Figur 3: Ett exempel på en metamodell för enkla graska objekt Det är dock mycket praktiskt att ta vara på likheter mellan olika diagram då man skapar metamodellen. I detta fall är det i själva verket en meta-metamodell vi beskriver eftersom den inte är specik för något visst visuellt språk. Efter att man har en meta-
metamodell, som beskriver t.ex. hur bågar och noder kan se ut, måste man skapa en metamodell för det språk man vill använda säg av. Det är här som vi för UML t.ex. kan använda oss av UML[DI]. Denna metamodell är en specialisering av den graska meta-metamodellen. Metamodellen kan i detalj beskriva vilken typ av noder och bågar diagrammet kan innehålla, eftersom denna metamodell är specik för ett visst språk. Om du vill ha en grask metamodell för ett UML-klassdiagram kan du t.ex. säga att en typ av noder är klasser som beskrivs som rektanglar. För varje element som ingår i språket måste man göra denna detaljbeskrivning. När man har denna detaljerade beskrivning klar för varje element är metamodellen för det ifrågavarande språket klart. Nästa fråga, som man behöver ställa sig själv är hur man vill representera denna metamodell. Eftersom även denna graska metamodell har liknande egenskaper som metamodellen för att beskriva modellelementens beteende kan man med fördel använda sig av XMI för att beskriva den graska representationen. 3.3 Vad bör genereras? Det nns vissa funktioner som är specika för editeringen av ett visst språk. Det första man kommer att tänka på är att språken har olika element. Man måste alltså kunna generera ett sätt att lägga till en viss typ av element. Alla editorer behöver funktioner för att lägga till element till modellen och diagrammet, men endast en editor för UML-klassdiagram behöver funktioner för att lägga till klasser, paket, associations... Som tidigare nämnts innehåller metamodellen för språket en beskrivning över alla element, som kan läggas till i modellen. Denna information bör i själva verket nnas i två metamodeller, både den som beskriver språket och den som beskriver det graska gränssnittet. Den graska metamodellen bör dessutom innehålla information, för att berätta hur elementet skall se ut. För att återgå till vårt exempel om UML-klassdiagram kan man alltså säga att denna metamodell bör innehålla information om t.ex. hur en klass ser ut och hur den kan placeras. När man genererar en editor för denna metamodell måste man alltså skapa en funktion för att lägga till element av metamodellens alla typer. Funktioner för att lägga till element sätts därefter till som meny-alternativ i modelleringsverktyget. Även funktioner för att radera element bör läggas till i editorn. Detta är inte alltid så enkelt som det låter. Det nns förstås funktioner för att plocka bort graska element ur diagrammet, som är oberoende av språket. Att radera elementet ur modellen kan dock kräva svårare funktioner. Detta beror på att element kan vara beroende av varandra i modellen. T.ex. kan du inte plocka bort ett paket ur ett UML-klassdiagram utan att
även radera alla klasser och övriga element som nns inne i paketet. Att generera dessa raderingsfunktioner vållar dock inga större problem eftersom kopplingen mellan de olika elementen nns beskrivet i metamodellen. 4 SMW - Ett modelleringsverktyg SMW(System modelling workbench) är ett program utvecklat vid Åbo Akademi, som används för att hantera modeller och diagram. SMW är baserat på metamodeller och innehåller framförallt editorer för UML. Figur 4 är en skärmdump från SMW, som visar ett utdrag ur metamodellen för UML 1.4. Till vänster på bilden ses en trädrepresentation av den användarmodell, som just nu håller på att editeras. Funktioner för att lägga till editorspecika element nns tillgängliga för de olika UML diagrammen nns tillgängliga. De nns i verktygsfälten, som kan ses i gurens övre del. Om man vill lägga till t.ex. en klass, klickar man på ikonen för klasser i verktygsfältet och därefter klickar man på representationen av diagrammet. Då läggs klassen till såväl i diagrammet, som i den bakomliggande modellen. 5 Sammandrag Att basera editorer på metamodeller är mycket praktiskt. Om varje språk har en metamodell för grammatiken och en för graken, kan man generera en editor för språket. I vilket format man beskriver metamodellerna är inte avgörande för huruvida man kan generera editorer eller ej, men det har visat sig att XMI formatet passar utmärkt för den här typen av information. Om man använder sig av ett gemensamt format för metamodellerna resulterar det i att modeller enkelt kan yttas från ett modelleringsverktyg till ett annat. Att generera editorer är alltså inte omöjligt, men det krävs att man har välgenomtänkta metamodeller. Trots alla likheter som olika visuella språk har, så är det inte trivialt att skapa en gemensam meta-metamodell för dem.
Figur 4: Ett utdrag ur metamodellen för UML Referenser [UML03] Object Management Group. Unied Modelling Language Specication http://www.omg.org/uml/. [SMW03] I. Porres, et al: System Modeling Workbench http://www.abo./ iporres/html/smw.html. [OMG03] Object Management Group. XML Metatdata Interchange http://www.omg.org/technology/documents/formal/xmi.htm. [W3C00] W3C:Extensible Markup Language (XML) 1.0 (Second Edition) http://www.w3.org/tr/rec-xml.
[GD03] Gentleware AG, DaimlerChrysler AG, et.al: UML 2.0 Diagram Interchange. http://www.gentleware.com/projects/diagraminterchange/. [DOM02] Domokos,Varro: An OPen Visualization Framework for Metamodel-Based Modeling Languages, 2002 [XS99] W3C: XSL Transformations (XSLT) v1.0, http://www.w3c.org/tr/xslt, November 1999 [W3C] World Wide Web Consortium http://www.w3c.org/