1 1
1 Indholdsfortegnelse 1 INDHOLDSFORTEGNELSE... 1 2 SAMMENFATNING OG BIDRAG... 3 3 INDLEDNING... 5 3.1 PROBLEMFORMULERING... 5 3.2 METODE... 6 3.2.1 Prototypeudvikling...7 4 BAGGRUND (DET EKSISTERENDE FRAMEWORK)... 7 4.1 JAMAICA OG DESIGNEREN... 7 4.1.1 Den domænespecifikke objekt model...8 4.1.1.1 Business Objects... 9 4.1.1.2 Elementer... 10 4.1.1.2.1 Registration og Family... 11 4.1.1.2.2 Containment og Relation... 12 4.1.1.3 Andre relevante abstraktioner... 12 4.1.1.3.1 View... 12 4.1.1.3.2 Task... 12 4.1.1.3.3 Activity Center og User Role... 12 4.1.1.3.4 Event... 13 4.1.1.3.5 Method... 13 4.1.1.3.6 Configuration... 13 4.1.2 Den nuværende konfigurationsmodel og dens problemstillinger...14 5 DESIGN OG IMPLEMENTATION AF FREEDESIGNER... 16 5.1 VISUAL STUDIO.NET DESIGN TIME MODELLERING VS. FREEDESIGNER... 17 5.2 OBJEKTAFHÆNGIG FUNKTIONALITET... 19 5.2.1 Canvas...19 5.2.2 Dokumentation...21 5.2.3 Halo metafor...22 5.3 BUSINESS OBJEKTER... 23 5.3.1 Generisk BO vs. typificeret...24 5.3.2 Flytning af BO er via drag-n-drop...24 5.3.3 Forskellige views på et Business Object...24 5.4 ELEMENTER... 25 5.4.1 Validering...27 5.4.1.1 Stoplys metafor... 27 5.5 RELATIONER... 29 5.5.1 Master/Detail...29 5.5.2 Relate to BO...29 5.5.3 Relate to exisisting...30 5.5.4 Navigation...31 5.6 CONTAINMENT... 33 5.6.1 Hvorfor speciel visualisering af Containment og Relation?...35 5.7 ALIASING... 36 5.8 OVERBLIK OG MODELNAVIGATION... 36 5.8.1 UML in Color...36 5.8.1.1 Teksturer... 38 5.8.2 Statusbar...38 1
Indholdsfortegnelse 5.8.3 MiniCanvas...39 5.8.4 Navigation via MenuItem...41 5.8.4.1 Subclassing MenuItem... 41 5.8.5 ToolTip information...43 5.8.6 Modellayout...43 6 TEKNISKE OG TEORETISKE OVERVEJELSER... 44 6.1 HVORFOR IKKE BARE TRADITIONEL UML?... 44 6.1.1 OMG s UML vs FreeDesigner UML profile...44 6.1.2 OCL...46 6.1.3 Domæne specifikke visuelle sprog (DSVL)...46 6.2 USERCONTROLS VS. SHAPES... 47 6.3 C# PROPERTIES SOM KONFIGURATIONSSKABELON... 48 6.3.1 Navnekonventioner vs. Custom attributes...49 6.3.1.1 Navnekonvention... 49 6.3.1.2 Custom Attributes... 50 6.3.1.3 Afkobling... 52 6.4 DEPACK, XML OG KODEGENERERING... 53 6.4.1 Database...56 6.5 DELEGATES OG EVENTS... 56 6.6 DESIGN PATTERNS... 58 6.6.1 Generelt...58 6.6.2 Singleton pattern...58 6.6.3 Command pattern...58 6.6.4 Decorator pattern...59 6.6.5 Model-View-Controller pattern...59 6.6.6 Observer pattern...60 6.6.7 Relevante patterns jeg ikke fik implementeret...60 6.6.7.1 Abstract Factory... 60 6.6.7.2 Composite... 60 6.6.8 Opsummering...61 7 EVALUERING AF FREEDESIGNER... 62 7.1 MANGLER OG FORBEDRINGER... 62 8 LIGNENDE LØSNINGER... 64 8.1 MJØLNER, AST OG IP... 64 8.2 NAKED OBJECTS... 64 9 KONKLUSION... 67 10 REFERENCER... 71 11 FIGUR OVERSIGT... 73 12 BILAG... 73-2 -
Sammenfatning og bidrag 2 Sammenfatning og bidrag Dette speciale samt et medfølgende prototypisk grafisk konfigurationsværktøj 1 bidrager med et UML inspireret grafisk konfigurationsinterface til Navisions Jamaica projekt. Selvom prototypen og specialet er blevet til med særligt henblik på Navisons ERP system, lader mange af ideerne sig umiddelbart overføre til UML modeller generelt samt andre ERP systemer og i det hele taget til domænespecifikke visuelle sprog og metamodeller. Et gennemgående tema i mine undersøgelser har været at finde frem til, hvorledes domænespecifikke metatyper (Business Objects) bedst muligt og mest intuitivt visualiseres og konfigureres. Min prototype FreeDesigner er et bud på dette. Modellen udvides udover den traditionelle UML opdeling i attributter og operationer til at håndtere elementer, som begrebet Containment, der dækker over en form for has-a aggregeringsrelationship, hvor min model grafisk afspejler dette domænespecifikke forhold mere direkte end den traditionelle UML diamant eller rombe. Modellen udvides endvidere grafisk i forhold til traditionelle relationer, hvor relationsattributter, i den udvidede model, grafisk/fysisk bryder ud af UML boksens grænser for derved at illustrere deres intentionalitet, involvering og rolle i relation til resten af modellen. UML stammer fra omkring 1996 2 og specialet og produktionen kan yderligere anskues som værende et mere moderne bud på hvorledes UML også kan repræsenteres. Specialet og produktionen fører en idé om at flytte al funktionalitet fra traditionelle toolbars, propertybox, input-felter/områder mm. til objekterne selv, til sit ekstrem: Der er ingen toolbars e.lign. i min løsning - alt er menuer bestemt ud fra konteksten. Der er lagt stor vægt på brugen af farver og farvemønstre i modelleringen med henblik på understøttelse af løsningens overskuelighed. Løsningens overskuelighed samt navigerbarhed er endvidere problemstillinger, der behandles i specialet. Specialet er således af særlig interesse for personer, der interesserer sig for domænespecifikke visuelle sprog, modellering af ERP systemer, UML samt 1 Vedlagt program på CD. 2 UML 0.9 1996 (http://pigseye.kennesaw.edu/~dbraun/csis4650/a&d/uml_tutorial/history_of_uml.htm#1). Det var i det år Grady Booch og Jim Rumbaugh fra Rational Software begyndte at forene Booch og OMT modellerings teknikkerne. UML s rødder går således længere tilbage i tiden. - 3 -
Sammenfatning og bidrag metamodeller generelt,.net/c# s grafiske udtryksmuligheder (GDI+) samt GUI design. - 4 -
INDLEDNING 3 INDLEDNING Enterprise Resource Planning (ERP) systemer udvikles typisk på baggrund af et stort framework. Dette framework tilpasses af partnere for at tilbyde skræddersyede løsninger til kunder. Det er ønskværdigt at gøre denne tilpasningsproces så nem og effektiv som muligt for disse partnere. En måde at gøre dette på er at give partnerne specialiserede modelleringsværktøjer. Nærværende speciale præsenterer mit forslag til et sådant domænespecifikt modellerings værktøj, hvor den grafiske notation er inspireret af UML, men indarbejder specifikke aspekter unikke for Navisions Jamaica-framework. Specialet centrerer sig således om Jamaica-designeren, domænespecifikke visuelle sprog (der sondres mellem to termer: domain specific visual languages [DSVL] og domain specific languages [DSL]), CASE-tools, programmeringsomgivelser, grafisk repræsentation og manipulation af data og søger at perspektivere disse op imod mit prototypiske konfigurationsværktøj og Navisions s ERP system Jamaica. 3.1 Problemformulering Navisions ERP løsning, som den fremstår implementeret som en integreret Visual Studio.NET løsning, konfigureres i dag ved hjælp af drag-n-drop mellem forskellige træstrukturer internt i Visual Studio.NET. Denne konfigurationsproces er besværlig og ikke specielt brugervenlig, og overblikket over konfigurationen er dårligt: I værste fald kan det praktisk taget være næsten umuligt at spore relationer mellem de forskellige deltagende (business) objekter i en konfiguration. Specialets problemfelt er i høj grad udsprunget af en generel fornemmelse af, at denne konfigurationsproces må kunne understøttes bedre. Jamaica består - forenklet set - af business objekter og elementer, der i Visual Studio.NET alle som en konfigureres via en og samme propertybox, hvilket bl.a. betyder, at fokus i konfigurationsprocessen konstant skifter frem og tilbage mellem objektet, der konfigureres og denne propertybox. Speciale samt produktion er mit bud på et mere intuitivt konfigurationsinterface/- værktøj, der fokuserer på overskuelighed og brugervenlighed, hvilket bl.a. er søgt opnået gennem implementation af en idé om at lægge al funktionalitet på de for brugeren tilgængelige objekter ingen propertybox, toolbars, knapper mm..net løsningen håndterer relationer på en måde, der gør det vanskeligt at finde frem til, hvilke objekter, der er forbundne. Mit mål har været at udvide den traditionelle UML model til at kunne håndtere og visualisere ovennævnte relationer som grafiske førsteklasses elementer, der entydigt og identificerbart fremviser deres relation til resten af modellen. - 5 -
INDLEDNING Et studiemæssigt delmål med specialet og navnlig produktionen af konfigurationsværktøjet FreeDesigner 3 har været at lære C# og.net frameworket at kende, hvorfor jeg også vil behandle specielle sprogkonstruktioner og designbeslutninger af særlig relevans for min løsning. På samme grundlag ønskede jeg i min løsning at inkorporere forskellige design patterns for at opnå større praktisk erfaring med dem. På den baggrund vil der i specialet være en diskussion af erfaringen med dette. 3.2 Metode 1.1.1 Litteratur studie før og efter prototype I et indledende 4-ugers projekt skaffede jeg mig overblik over bl.a. Navisions Jamaica framework, forskellige typer CASE-tools, programmeringsomgivelser, grafisk repræsentation og manipulering af data. Med udgangspunkt i det nordiske Mjølner projekt [5] undersøgte jeg forskellige typer programrepræsentationer, herunder grammatikker og særligt abstrakte syntakstræer (AST) ([10], s.12), og hvorledes disse med fordel kunne bruges i forskellige sammenhænge. I den forbindelse konkluderedes det, at AST ikke passede godt som programrepræsentation for mit værktøj, eftersom AST med størst fordel benyttes til repræsentation af tekstuel information, men er mindre velegnet til at repræsentere grafik og layout. I forbindelse med udarbejdelsen af artiklen UML in an ERP environment (bilag [1]) så jeg på programmeringsparadigmet Intentional Programming ([1], Kapitel 11). Dette var et relevant og nyttigt paradigme for mit værktøj, idet man i en implementation af paradigmet (der i udstrakt grad var baseret på AST) demonstrerede dets styrke, der bl.a. bestod i, at der kunne benyttes domænespecifikke grafiske notationer. Denne (eneste) implementation af Intentional Programming hørte under et Microsoft projekt, der på trods af, at Microsoft havde en fuldt fungerende version, af uvisse årsager stoppede projektet 4. I 4-ugers projektet undersøgte jeg endvidere XML standarden XMI med udgangspunkt i Knight projektet (et whiteboard UML diagrammeringsværktøj) [16] og konkluderede, at XMI ikke ville være velegnet til mit værktøj 5, da XMI retter sig mod UML modeller og ikke diagrammer og mere specifikt er rettet mod udvekslingen af modeller mellem programmer mere end egentlig programrepræsentation. 3 FreeDesigner er navnet på mit tool ( Free fordi det ikke er integreret i Visual Studio.Net designer, fordi dette er navnet på den nuværende løsning) og er den betegnelse, jeg fremover vil benytte. 4 Krzysztof Czarnecki, medforfatter til Generative Programming [1], hævdede på OOPSLA 2002 konferencen at vide, at Microsoft eller en partner var ved at være klar med en kommerciel implementation af Intentional Programming. 5 Klaus Marius Hansen (fra Knight projektet) frarådede mig på NWPER at benytte XMI i mit værktøj, da jeg fortalte ham om det. - 6 -
Baggrund (det eksisterende framework) Min tilgangsvinkel til dette speciale har således i første fase (i form af et 4- ugers projekt [10]) været litterær, hvor jeg har opnået et overblik over Navisions Jamaica framework, CASE tools generelt og andre lignende løsninger som f.eks. UML, XMI, AST. Undervejs og efter konstruktionen af prototypen FreeDesigner har jeg deltaget i konferencerne NWPER 6 og OOPSLA 2002 7, hvor artiklen UML in an ERP environment (bilag [1]) blev præsenteret på Workshop on Domain Specific Visual Languages. Herefter har jeg set på andre tools (f.eks. Naked Objets, Poseidon for UML) og læst yderligere litteratur, som jeg specialet igennem vil inkludere i diskussion. 3.2.1 Prototypeudvikling Da jeg har stået over for et helt nyt udviklings miljø (.NET) og et helt nyt sprog (C#) og fra bunden af har skullet udvikle et konfigurationsværktøj til et helt nyt framework (Jamaica), kan min metode bedst beskrives som eksplorativ. Ikke alle beslutninger i processen har været nøje velovervejet eller baseret på indgående viden, men netop været eksplorative og afprøvende i deres udgangspunkt. Visse (design-) beslutninger er blevet truffet udelukkende ud fra et ønske om at afprøve.net/c# s forskellige potentialer (f.eks. valgte jeg at implementere Custom Attributes til beskrivelse, af hvilke klasser, der skulle dekorere Elementer til trods for, at en løsning der benyttede navnekonventioner og reflection, allerede var implementeret og virkede primært for at stifte bekendtskab med Custom Attributes). Prototypen fungerer, og jeg har fået implementeret de idéer, jeg gerne ville. 4 Baggrund (det eksisterende framework) Mit speciale og mit modelleringsværktøj tager udgangspunkt i Navisions ERP framework og er et forslag til en forbedring af konfigurationsværktøjet til dette. En kort gennemgang af Navisions ERP system Jamaica er nødvendig, for at læseren kan forstå de dispositioner, designvalg mm., jeg har truffet. 4.1 Jamaica og Designeren I det følgende vil jeg kort søge at blotlægge den struktur, der ligger til grund for Jamaica-designeren. Overordnet set er Jamaica et framework, der sigter mod hurtigt og enkelt design af Enterprise-løsninger. Det sigter mod at understøtte modellering frem for kodning. Løsningen (som kunden/virksomheden ser den) er browser baseret og bygger på Microsofts.Net platform (C# og ASPX). Virksomhederne får en tilpasset udgave af systemet, som understøtter hverdagsrelaterede virksomhedsopgaver (lagerstyring, indkøb mm.). På abstrakt plan modelleres en løsning vha. domænespecifikke metatyper (se Figur 2) business objects som f.eks. Company, SalesOrder m.fl., der 6 http://www.it-c.dk/people/kasper/nwper2002/ 7 http://oopsla.acm.org/oopsla2002/ - 7 -
Baggrund (det eksisterende framework) konfigureres i Visual Studio.NET med Elementer 8, der f.eks. kan finde ud af at beregne moms, addere samt mange andre virksomhedsrelevante funktionaliteter. Denne konfigurationsmodel (som gemmes i en database og som XML) kan kompileres af en specialdesignet kompiler, der ud fra denne metamodel bestående af metatyper genererer C#, SQL og ASPX sider, som virksomheden konkret kan benytte til f.eks. at registrere salgsordrer, udskrive fakturaer mm. Figur 1. Model for arkitektur og hvad der sker ved kompilation [9] 4.1.1 Den domænespecifikke objekt model 9 I det følgende vil jeg kort og summarisk beskrive den domænespecifikke objektmodel. Behandlingen omhandler primært aspekter af modellen, som jeg 8 Termerne Element, Relation samt Containment har en speciel betydning inden for Jamaica frameworket og skrives alle med stort begyndelsesbogstav, så at de kan skelnes fra de mere generelle betydninger af ordene. Således alle Jamaica specifikke termer. 9 Denne gennemgang baserer sig i høj grad på [7] - 8 -
Baggrund (det eksisterende framework) har implementeret i prototypen FreeDesigner. Abstraktioner som Activity center, Task m.fl. har jeg udeladt 10. 4.1.1.1 Business Objects 11 Navisions ERP model tillader definition af business object (BO) klasser. Hver klasse konstrueres ved at beskrive et sæt af Elementer svarende til primitive konstruktioner i det underliggende framework. En måde at anskue dette på er at modellen tillader definition af vilkårlige klasser, men i stedet for at lade Integer og String udgøre primitiverne, som de f.eks. gør det i Javas model, udgøres de af primitive Elementer - Elementer som Address, Deadline, TotalInclVAT osv. Disse Elementer repræsenterer selve kernen i Navisions ERP viden som indkapsles i fundamentale byggeblokke kaldet Elementer. Elementerne har et antal foruddefinerede attributter, som skal konfigureres som en del af udviklingsprocessen [7]. Et BO er således en container for en samling data og funktionalitet og kan identificeres som et self-contained objekt (eller objekt med egen identitet i et modelleret domæne). Et BO kan være en kunde, en faktura el. lign [9]. BO er kan være hierarkiske i den forstand, at et BO kan være bygget op af andre BO er i ét niveau. Et BO findes på 3 forskellige abstraktionniveauer: Figur 2. Objektmodellen 1. BO Base: Det højeste abstraktionsniveau. Navision har identificeret/klassificeret 8-10 Baser, som rummer generel funktionalitet for de forskellige objekttyper, der tænkes specialiseret til specifikke BO Typer via nedarvning. Til en BO Base hører en konfigurationsskabelon, 10 For en grundigere analyse af objektmodellen og flere af dens facetter se [15] 11 Afsnittet er baseret på [8, s.12-17] og [9] - 9 -
Baggrund (det eksisterende framework) som definerer, hvilke Elementer, Tasks mm., en instans af et BO kan/må indeholde. Baser 12 : 1.1. Party kan repræsentere enkeltpersoner, kunder, organisationer mm. Ordet Party rummer sådan set sin egen definition. Et Party kan have forskellige roller (se 5.7 ) i forskellige situationer: I én situation kan et Party have rollen som køber og i en anden som sælger. Et Party kan eje Assets. 1.2. Asset indeholder de entiteter, der er relateret til et Party gennem en form for ejerskab. Assets kan indeholde andre Assets (f.eks. reservedele som dele af andet udstyr). 1.3. Contract handler om aftaler mellem Parties. F.eks. købs- og salgsordrer, som er opbygget af LineItems. 1.4. LineItem er f.eks. hver linje i en salgsordre. LineItem er ofte defineret som værende afhængig (Containment) af en BO Contract, hvor BO Contract ejer BO LineItem. 2. BO Type: Kan højst nedarve fra én BO Base, som altså er superklasse til BO Typen. Typens primære formål er at danne grundlag for, at to BO s af samme type i hvert sit modul kan udveksle information/synkroniseres, hvis der er Elementer af samme type tilstede. En BO Type har ikke et fast sæt af Element typer knyttet til sig og er således uafhængig af Elementer og Modul. Typiske eksempler på BO typer er Customer, PurchaseOrder og PurchaseOrderLine. 3. BO Instance er en instans af Bo Type. En instans tilhører altid et modul og instantiering er kun mulig i kontekst af et Modul. En BO instans er defineret ved dets Type og Modulet, det tilhører. Bemærk, at en instans ikke er et objekt, men svarer til en klasse i OO sammenhæng. 4.1.1.2 Elementer Elementer (nogle gange kaldet attributter ) udgør de primære byggeklodser og indeholder en samling funktionalitet, som er designet specifikt til det enkelte Elements brug. Elementer er det, der definerer et BO s indhold og kan samles i Families, så de forskellige Elementer kender til hinanden og dermed kan arbejde sammen uden yderligere eksplicit modellering (se 4.1.1.2.1). Eksempler på Elementer er DeliveryAddress og SalesOrderID, som er specialiseringer af de generiske og mere generelle Elementer (patterns) Address og Identification. Elementer eksisterer på tre abstraktionsniveauer analogt med BO: Base, Type og Instance. Alle disse størrelser kan sammensættes på en lang række forskellige måder, og denne aktivitet tjener til at skræddersy og konfigurere en løsning, der 12 De fire Baser, jeg har valgt at implementere. - 10 -
Baggrund (det eksisterende framework) svarer til den konkrete virksomheds behov og krav. Dette skridt kaldes konfiguration. 4.1.1.2.1 Registration og Family Registry 13 er et udmærket eksempel på, hvordan Elementer kan fungere og samarbejde. Registry er en samling af Elementer, hvis fælles formål er at registrere data om business events i et format, der passer til analyse og rapportering og en måde at vedligeholde historik, idet registreret data ikke længere kan ændres. Typisk bruges Registry Elementer i Contract BO er som f.eks. fakturaer (Invoice) og ordrer (Order). Disse BO er består typisk af en header og et antal lines en struktur, der afspejles af Registry Elementerne, som typisk udgøres af en total og en detail del (se Figur 3). Registry Elementer arbejder sammen om at registrere og udregne og er derfor tættere knyttet sammen end Elementer i al almindelighed. Dette opnås ved at lade disse Elementer tilhøre en Familie (Family), inden for hvilken Elementerne kender til hinanden. Et eksempel kunne være et moms og et sumtotal Element - begge fra Registration Familien - der som Familie placeres sammen på et SalesOrder BO. Fordi de tilhører samme Familie, kan et sumtotal Element finde ud af, at der også eksisterer et moms Element på samme BO og medtage dette i udregningen af summen. På konfigurationsniveau placeres Elementer fra samme Familie altså på et BO, som f.eks. SalesOrder, faktura e. lign. (Elementer fra en Familie kan placeres på mere end et BO, hvis disse er Contained LineItems ([14], s. 4)), og da Familie typen logisk set anskues som ét Element, forventes det, at alle Familiens (sub-)elementer ligeledes er til stede på det konfigurerede BO. Et Registration Element kan have tre forskellige roller: Total, Master og Detail. PriceTotal +PriceTotal 1 0..* PriceDetail +UnitPrice +Quantity Figur 3. Element base med Total og Detail repræsentation [14] Alle Detail Elementer har en modsvarende Total, der kan have Detail Elementer. Regler og semantik defineres i Element basen. Registration Master er en Registration Total med den yderligere status at fungere som Familiens overhoved (med ansvar for Familiens interne kommunikation mm.) af hvilket der kun eksisterer et pr. Familie[14]. 13 Registration er betegnelsen for problemet, der løses: Det at registrere data om business events - Registry betegner en konkret Familie af Elementer designet specielt med henblik på at varetage dette. - 11 -
Baggrund (det eksisterende framework) 4.1.1.2.2 Containment og Relation Modellen tillader relationer mellem klasser. For at holde definitionerne objektcentreret defineres relationer som Elementer. Elementer, der repræsenterer forskellige roller i et binært relationsforhold, kan forbindes, og en til mange samt mange til mange relationer kan defineres. Containment er en speciel form for relation og har givet navn til Containments to generiske roller Master og Detail. Hvis et Master objekt i en Containment Relation slettes, slettes alle de indeholdte (contained) Detail objekter også. Betegnelserne Master / Detail benyttes endvidere om almindelige relationer, hvor Master Elementet betegner objektet med singulær kardinalitet og Detail Elementet multipel kardinalitet. Master/Detail forholdet for almindelige relation har ikke samme slette semantik som i tilfældet med Containment. En af de mere indlysende fordele ved en UML inspireret repræsentation er, at man kan repræsentere Relationer grafisk som associationer (i Containments tilfælde som aggregering) i modsætning til Navisions model, hvor Relationer konfigureres som enhver anden Element type ved at udfylde værdier i en propertybox. 4.1.1.3 Andre relevante abstraktioner Ovenstående er de abstraktioner, der er absolut nødvendige for at forstå mit projekt. Der findes yderligere en del abstraktioner, som det ikke er strengt nødvendigt at kende til for at forstå mit projekt, men som jeg herunder kort vil beskrive for at give et mere fyldestgørende billede af frameworket og dets muligheder. 4.1.1.3.1 View Et View er en specifik repræsentation af et BO og bruges til at udvælge et sæt af data blandt Elementerne i et BO og give adgang til disse data. Views har med den visuelle konfiguration af de enkelte komponenter at gøre. Man kan knytte Views til på forskellige niveauer. Et View definerer, hvad der rent grafisk skal vises for brugeren, og hvad der skal være transparent. F.eks. kan man i en formular ønske, at navn og adresse, men ikke kunde-id vises. Dette defineres i et View. 4.1.1.3.2 Task En Task arbejder på et eller flere BO s og afspejler de opgaver (Tasks), som en bruger skal kunne arbejde med. En Task er logisk inddelt i et antal skridt (Steps), som er nødvendige for at gennemføre en Task. Hvert Step får tildelt et View. Tasks modellerer de opgaver, en bruger kan relatere sig til. Et eksempel er et Select og et Delete Step for en Delete Task. 4.1.1.3.3 Activity Center og User Role Et Activity Center består af en samling Tasks. Hver bruger har en rolle (såsom salgskonsulent eller indkøber). For hver af disse roller laves en konfiguration af et Activity Center, som bruges til at tilpasse brugerinterfacet - 12 -
Baggrund (det eksisterende framework) til den givne rolle. En bruger får således en portal med en samling Activity Centers, der svarer til brugerens rettigheder. 4.1.1.3.4 Event Eksempler på Events er OnDelete, OnCreate. Events har en speciel signatur og fyres, når et BO eller Element skifter tilstand og derved opfylder et foruddefineret krav. 4.1.1.3.5 Method En Metode (Method) manipulerer BO er og Elementer og er en procedure, der kan udføres på disse. Metoder kan fyre Events. 4.1.1.3.6 Configuration En BO Configuration består af et set Configuration Items, der definerer hvilke specifikke Element typer, Methods, Views og Events, en BO type har/kan have i kontekst af et specifikt Modul (Module) og skal stemme overens med en Configuration Template for Basen (hvis en sådan eksisterer). - 13 -
4.1.2 Den nuværende konfigurationsmodel og dens problemstillinger Den nuværende konfigurationsmodel er en intern Visual Studio.NET løsning, hvilket vil sige, at selve applikationen/konfigurationen er integreret og foregår i Visual Studio.NET (Se Figur 4 14 ). Visual Studio.NET har netop én instans af en property box (nederste højre hjørne), i hvilken alle objekter (hvis de benytter specielle Custom Attributes(se 6.3.1.2)) lader sig konfigurere det være sig på filniveau, objektinstansniveau mv. Figur 4. Navisions integrerede Visual Studio.NET løsning Den samlede løsning repræsenteres af en træstruktur (Første panel på Design explorer fanen i midten), hvor alle konfigurationens BO er er listede. Når disse vælges enkeltvis, opdateres det tilstødende panel (til højre) og viser en flad fremstilling af de indeholdte Elementer, Relationer mm. indeholdt i det valgte BO. 14 Stedlige (f.eks. til højre ) henvisninger referer i dette afsnit til Figur 4. 14
Baggrund (det eksisterende framework) Nederst i venstre hjørne ses en statisk Element træstruktur et opbevaringssted (repository), hvorfra Elementer kan trækkes ind på Design Exploreren. Alle Elementer kan trækkes når som helst, men det er først ved drop- og drag-over eventen, at brugeren opdager (enten ved et No symbol eller ved gennemførelse af drop), om handlingen er lovlig eller ej (almindelig drag-n-drop semantik). I Visual Studio.NET gives der ellers mulighed for at inaktivere elementer afhængigt af, hvad der er valgt, men dette er der tilsyneladende ikke gjort brug af (Hvis man f.eks. ønskede at trække et Element over på et BO, hvor det ikke måtte være, kunne Element træstrukturen have inaktiveret eller helt fjernet dette Element, efter at dette BO var blevet valgt (F.eks er et Customer BO valgt i Design Exploreren på Figur 4, hvilket kunne medføre, at alle de Elementer, der ikke måtte droppes på et Customer BO, automatisk blev inaktiveret)). Hovedproblematikken i denne fremstillingsform er, at det næsten bliver umuligt at danne sig et overblik over den fulde løsning, da træstrukturerne (særligt Design Exploreren) kun fortæller, hvilke BO er, der hører med i en løsning ikke, om deres interkonnektivitet. Denne kan man på besværlig vis browse sig frem til og etablere ved først at finde det Relation Element (der er et Element som alle andre Elementer), der har Base -værdien Master eller Detail (tekstuel property information i Design Exploren ved siden af Entity ). Når dette Element er valgt, kan man finde den modsatte deltager i Relationen repræsenteret ved tekstuel information i propertyboxen. Hurtig navigation mellem de deltagende BO er er ikke mulig. Forskelligheden i ikonerne og navnekonventioner (der automatisk understøttes f.eks. ved påhæftning af forklarende ord som type og view ) tjener som den eneste visualisering af komponenters betydning, rolle og placering i hierarkiet. Semantikken i disse Relationer er så central, at den (manglende) informationsmængde og dårlige overblik, man bibringes ved at browse træstrukturerne, ikke slår til. 6-8 forskellige paneler (toolbox, Element hieraki, Solution Explorer m.fl.) er i sig selv en stor mængde information at holde styr på, og den mentale model af, hvor objekter og deres properties lever, bliver ikke særligt godt understøttet med så mange forskellige views, opbevaringssteder og paneler. Fokus skifter i konfigurationsøjemed konstant mellem de forskellige paneler og altid frem og tilbage mellem disse og propertyboxen 15. Da der kun eksisterer én propertybox, vil et hvilket som helst valg af Element i en af træstrukturene fjerne muligheden for på samme tid at se konfiguration, properties mm. fra andre relevante objekter samtidigt. Inspektion af BO er er altså begrænset til et BO af gangen. 15 En observation, jeg bl.a. gjorde ved en demonstration af designeren ved Peter Borring Sørensen fra Navision - 15 -
Design og implementation af FreeDesigner Efter at jeg således har beskrevet det eksisterende framework, dets konfigurationsproces og problemer, vil jeg gå videre til at beskrive hensigten med mit prototypiske konfigurationsværktøj, løsningsmodeller for dette samt den konkrete implementation. 5 Design og implementation af FreeDesigner Den overordnede ambition har været at gøre konfigurationsprocessen mere intuitiv, overskuelig, brugervenlig og logisk end Navisions eksisterende løsning. I lyset af foregående kapitel kan problemstillingen nuanceres yderligere, og udfordringen og kravene til FreeDesigner er således at kunne: tilbyde mulighed for ren grafisk komposition og konfiguration af prædefinerede BO er og på den måde lette modelleringen af den endelige specialiserede ERP løsning, gøre konfigurationsprocessen så understøttende og intuitiv som muligt og på bedst mulig vis understøtte den konceptuelle model af domænet, visualisere Relation og Containment på en fornuftig og overskuelig måde og herunder understøtte hurtig navigation mellem forbundne Elemente, understøtte overblikket over den fulde løsning, undgå brugen af én central propertybox samt toolbars og opbevarinssteder generelt og derved muliggøre, at flere BO er kan undersøges og overskues på én gang, lægge al funktionalitet ud på objekterne selv i vidste muligt omfang. Overordnet set er ambitionen at demonstrere, at det er muligt at implementere idéen om at lægge al funktionalitet på objekterne selv, lader sig gøre. I forbindelse med dette skal det vurderes, om denne implementation er bedre understøttende end den eksisterende propertybox løsning. Ligeledes ønsker jeg at demonstrere, hvordan farver og øvrige idéer omkring visuelt udtryk positivt kan understøtte modelleringsprocessen og bibringe den brugervenlighed, overskuelighed samt øget semantisk fylde. Den fulde implementation af Jamaicas abstraktioner er ikke en ambition, da en sådan ville udgøre et alt for omfangsrigt projekt. Et testframework bestående af et hierarki af BO metattyper samt et hiearaki af Elementer mm. er implementeret som grundlag for konfigurationsmodellen. Primært har fokus ligget på konfigurationsdelen af frameworket (Designtime metatyper) og kun i begrænset omfang på runtime repræsentation (den resulterende løsning) af konfigurationen. Således er abstraktioner som View, Task, Activity Center, User Role ikke implementeret. Event og Method er kun i ringe omfang implementeret (såsom validering, sletning m.fl.). - 16 -
Design og implementation af FreeDesigner Succeskriteriet er en velfungerende prototype, der formår at implementere og anskueliggøre mine ideer omkring GUI og grafisk manipulation, og som demonstrerer, at de opgaver, der er mulige er løse i den nuværende løsning, også vil vise sig at (kunne) være mulige i min model. Som udgangspunkt eksisterede der to muligheder for hvorledes løsningen kunne implementeres: 1. som intern Visual Studio.NET implementation, 2. som selvstændig Visual Studio.NET uafhængig implementation. 5.1 Visual Studio.NET design time modellering vs. FreeDesigner Visual Studio.NET har fra begyndelsen været udviklingsmiljø for min løsning, og jeg må tilstå, at jeg aldrig har oplevet et miljø, der i så høj grad understøtter programmørens arbejdsgange og behov (eksempelvis kan man højreklikke på et metodekald, objekter mm. og vælge Go to definition, hvorefter Visual Studio.NET navigerer til definitionen på trods af, at denne f.eks. måtte befinde sig i en helt anden fil, namespace). Af denne grund var jeg helt fra begyndelsen meget åben over for muligheden af at lave en løsning, der var integrerbar i Visual Studio.NET og dermed også den eksisterende Jamaica løsning. Løsningen var endvidere attraktiv, fordi Visual Studio.Net tilbyder en lang række relevante features: 1. Designtime:.Net Frameworket er designet til at understøtte en hel del designtime features og sørger for, at designtime specifik kode bor i en separat assembly, så koden ikke påvirker størrelsen af runtime biblioteket (Den endelige løsnings størrelse ville dermed ikke blive påvirket af hvad der skulle til for at modellere den). 2. Design objects: Ethvert objekt, der implementerer System.ComponentModel.IComponent, kan få et designerobjekt knyttet til sig. Dette objekt kaldes en designer og indeholder den ekstra kode, som gør det muligt at manipulere med objektet design time. 3. Root designer: Der kan skabes mange designere for en visuel editor. En af disse skal være master, der tilvejebringer et interface, som brugeren kan interagere med. Denne designer kaldes en root designer, og komponenter, som den er bundet til, kaldes root components. 4. Host: Ud over disse designere er der også et objekt, der er ansvarligt for at håndtere instanserne af alle designerne og komponenterne og samtidig for at loade og save data. Dette objekt implementerer interfacet System.ComponentModel.Design.IDesignerHost og kaldes oftest blot host eller designer host. Visual Studio har en instans af dette objekt for hver Visual Studio editor instans. 5. Persistens: Kodegenerering er default måden, hvorpå designede komponenter gemmer deres data. I Figur 5 ses det, hvorledes figurene i Design view svarer til genereret kode i Code view. En model kan altså genskabes i en Designer på baggrund af en sådan kodefil. - 17 -
Design og implementation af FreeDesigner Figur 5 illustrerer mit første forsøg på en integreret Visual Studio.NET løsning, der ganske vist kun har defineret enkelte simple former (shapes) og ingen business logik fra ERP domænet. De definerede former, der kan instantieres fra toolboxen til venstre, kunne aktiveres og deaktiveres afhængigt af, hvad der i øvrigt var valgt (f.eks. ses tre elementer der ikke er shapes inaktiveret i toolboxen). Når formerne trækkes ind på kanvas, bliver den bagvedliggende kode opdateret. Denne kode kan kompileres, når det ønskes og derved vise sit kanvas med de modellerede former på en Windows Form (lig Java Frame) dette kunne i princippet også vises på en ASPX side (se punkt 5 ovenfor). Figur 5. Intern Visual Studio.NET løsning. Shapes på toolbaren tv. properties øverst th. Efter at have forsøgt mig med den interne løsningsmodel 16 fravalgte jeg den, omend den interne model ydede stor hjælp i henseende til persistens, undo/redo, patterns, kodegenerering mm. funktionaliteter, jeg i øvrigt i 16 Med udgangspunkt i et demo projekt, der findes på http://www.gotdotnet.com/team/windowsforms/shapedesigner.aspx - 18 -
Design og implementation af FreeDesigner studiemæssigt øjemed selv ønskede at implementere. Løsningsmodellen krævede for meget fokus på Visual Studio.NET, hvilket kun var et sekundært mål i bestræbelserne på at lære.net platformen og C# at kende. De overordnede CASE tool og GUI betragtninger, jeg havde gjort mig, harmonerede dårligt med Visual Studio.NET s forud- og veldefinerede GUI layout. Via denne model havde jeg ikke fuld kontrol over løsningen. Jeg var på én gang hjulpet og begrænset af Visual Studio.NET. Min eksterne løsning har jeg kaldt FreeDesigner slet og ret fordi den er fri af Visual Studio.NET og den eksisterende Jamaica løsning. 5.2 Objektafhængig funktionalitet Jeg har i FreeDesigner valgt ikke at benytte toolbars, propertybox mm. ud fra en betragtning om, at det centrale i et modelleringsværktøj netop er modelleringen, hvorfor jeg giver god plads til dette. Er der ingen toolbars, knapper mm., går opmærksomheden udelt til kanvasset 17, hvorpå det hele foregår. 5.2.1 Canvas Da der i FreeDesigner ikke er nogen central toolbar eller noget fast objekt opbevaringssted (repository), hvorfra man kan trække objekter ind på Canvas, og der heller ikke gives muligheder for at aktivering af instantieringsværktøjer (f.eks. dialoger), er den eneste mulighed, der resterer, at højreklikke 18 på Canvas for derigennem at få præsenteret de muligheder, der latent knytter sig til dette. Figur 6. Bart konfigurationskanvas med tilhørende kontekstmenuer Canvas opbyder muligheder for at instantiere BO er, konfiguration af farveprofiler, grid mm. Konceptuelt finder man - via dynamisk opdaterede 17 Canvas navnet reflekterer min engelske navngivning i FreeDesigner og denne engelske form benyttes når der refereres til den specifikke implementation. Når det ikke er den der refereres til benyttes den danske stavemåde med k. 18 Der eksisterer derudover en række shortcuts, som jeg eksperimentelt implementerede f.eks. Ctrl + b skaber et nyt BO. Ctrl + z: Undo m.fl. - 19 -
Design og implementation af FreeDesigner kontekstmenuer - hurtigt frem til, hvad der er muligt for de forskellige objekter. Kontekstmenuer er logiske træstrukturer, der er nemme at navigere rundt i. Intet er skjult i dialoger, paneler e. lign., og ingen muligheder lader sig realisere på mere end én måde (bortset fra nogle få genvejsfunktioner). Således har de fleste grafiske og logiske entiteter deres egen kontekstmenu, der tilbyder specifik kontekstuel manipulation af det relevante objekt. Den vigtigste konsekvens af at benytte kontekstmenuer er, at opmærksomheden forbliver på det relevante objekt, der skal konfigureres og ikke længere skifter mellem toolbars, propertybox og andre centrale menuer, som det er tilfældet if.eks. Visual Studio.NET løsningen. Hvis man leder efter noget, er der basalt set kun to steder, det kan befinde sig: på Canvas (der samtidig rummer de mere generelle muligheder, der overordnet har med konfigurationen at gøre), eller på det objekt, man ønsker at manipulere/konfigurere. Findes det ikke her, findes det slet ikke. Det er muligt at konfigurere Canvas s mønster (grid) til at have den farve og form, partneren måtte ønske (se Figur 7). Ændringer i dialogboxen reflekteres direkte på Canvas, idet parametrene ændres hvilket gør det nemt af finde et brugervenligt og pænt udseende. Det havde været ønskværdigt, at der var en Cancel knap, der undlod at skrive værdierne til Windows Registry (hvilket sker når, man trykker på Save/Close ) i tilfælde af, at man var tilfreds med den konfiguration, man havde fra starten af. Figur 7. Grid konfigurations dialogbox Endvidere er det på Canvas muligt at konfigurere farveprofiler (se Figur 24). - 20 -
5.2.2 Dokumentation Dokumentation og kommentarer ligger på det enkelte BO (se Figur 8). Knappen øverst th. synliggør/skjuler dokumentationen. Figur 8. Dokumentation på objektet selv Traditionelle UML værktøjer (se f.eks. Figur 9) benytter typisk et særligt lille notes objekt, der relateres til det objekt, der ønskes dokumenteret. Denne note muliggør som regel direkte indtastning af tekst/dokumentation. Det gør de, fordi de er en del af UML standarden (se [11], 3.11) og ikke nødvendigvis, fordi de synes at det er en god grafisk repræsentationsform for dokumentation. Noten adskiller sig typisk fra resten af modellen, som det ses i Figur 9, ved en anderledes farve, så den bliver nemmere at adskille fra klasse- og relationsentiteterne. Alligevel mener jeg, at det eren fordel at have dokumentation fast integreret på objektet da dette ikke kræver speciel instantiering og placering af et særskilt element, og fordi denne type dokumentation umuligt kan fejltages og forvirres med en klasse, relation eller et andet særskilt objekt. Dokumentation på objektet medvirker således ikke til en komplicering og forvirring af modellen, hvilket man kunne mene, at noterne gør i andre værktøj. Desuden ligger der en opfordring til programmører til at skrive dokumentation, idet dokumentation hører med som default og ikke som latent mulighed der først skal instantieres. 21
Design og implementation af FreeDesigner Figur 9. Dokumentation i Poseidon for UML 5.2.3 Halo metafor En af ideerne fra det forberedende 4-ugers projekt var at implementere en såkaldt halo omkring BO erne (se Figur 10). Idéen stammer direkte fra Visual Paradigm [4], der er et UML-java CASE tool. Figur 10. Halo element omkring et objekt (Visual Paradigm) 19 Klasserne eller de objekter, man måtte have med at gøre her, har på sig vedhæftet de latente muligheder, der knytter sig til det valgte element. Disse muligheder kan man trække i, som var de håndtag og derved aktualisere deres potentiale og f.eks. extende en klasse blot ved at hive i et extend- 19 Halo elementet findes også i java værktøjet Poseidon for UML( http://www.gentleware.com/ ) - dette samt Visual Paradigm er kommercialiserede produkter, der stammer fra open source projektet ArgoUML (http://sourceforge.net/projects/argouml/ ) - 22 -
Design og implementation af FreeDesigner håndtag. Ligeledes kan man fra en klasse hive i et notehåndtag og få en note ud, der automatisk linkes til klassen. I en tidligere version af FreeDesigner var en halo BO er i form af en en hånd implementeret (FreeDesigner.Shapes.GrabHandleDecorator). Hånden kunne trækkes over på et andet BO og dermed fange det ind i en Containment Relation. Efter denne implementation genovervejede jeg det praktiske i haloen og konkluderede at det faktisk var lettere og mere intuitivt blot at tage det ønskede objekt og trække det ind i Containment boksen. Endvidere indså jeg at flere af de Halo elementer der var brug for, havde med subelementer af et BO at gøre (på hvilke det ikke ville give mening at have halos) og kun sjældent angik hele BO et (hvilket afspejles af et BO kun har to kontekstmenupunkter i den nuværende version of FreeDesigner). Ideen om kontekstmenuer erstattede derfor haloen der ellers er et understøttende og intuitivt modelleringsværktøj men bedst understøtter funktioner der virker på topniveau. 5.3 Business Objekter Et BO er en abstraktion over en beholder, der kan indeholde et navn, Elementer, Relationer samt andre BO er, afhængigt af type. Den traditionelle UML fremstilling af denne beholder som en firkantet kasse er ganske velegnet, og den har jeg ikke fundet grund til at ændre på. I overensstemmelse med det domænespecifikke træk, at et specifikt BO skal arve fra én af Baserne (8-10 Baser er identificeret, men de fire Baser Party, Asset, Contract og LineItem er de Baser, der benyttes i overvejende grad 20 ), giver det god mening at benytte forskellige farvekoder for de forskellige Baser (se 5.8.1 for en diskussion af farverens rolle i min udgave af UML). Jeg har grafisk delt et BO op i fem hoveddele (se Figur 8): 1. Navn 2. Dokumentation (default skjult) 3. Elementer 4. Relationer 5. Containment Denne opdeling er meget lig traditionel UML, der benytter pkt. 1, 3 samt et område til metoder. Som beskrevet i afsnit 5.3.3 (Views) kan hvert enkelt af disse niveauer foldes ind og ud i overensstemmelse med det ønskede detaljeniveau. Når et BO vælges, benyttes simpel 2D tegning på Canvas til at tegne et afrundet rektangel omkring BO instansen. Denne fra sine firkantede omgivelser afvigende afrundede form gør identifikation af det valgte BO lettere. Afrundingen tager klassen Util.ShapeConverter sig af. Den indeholder 20 Farvekoder i relation til modeller med mere end fire stereotyper diskuteres i 5.8.1-23 -
Design og implementation af FreeDesigner to metoder, der begge returnerer et afrundet rektangel i form af et Region eller et GraphicsPath objekt fra en rektangel input parameter (BO ets Bounds Property). 5.3.1 Generisk BO vs. typificeret Min første løsningsmodel til, hvorledes BO er skulle instantieres, gik ud på, at brugeren først instantierede et generisk BO for derefter i BO ets kontekstmenu at typificere det. Jeg gik relativt hurtigt bort fra denne model, da der altid er et fast afgrænset antal BO er samme antal, der alligevel ville dukke op i typificeringskontekstmenuen. Der var altså tale om en omvej, et ekstra unødvendigt skridt, som nu kun står tilbage som en reminiscens, der kun eksisterer med det formål at kunne demonstrere typificeringsprocessen (således resterer også muligheden i kontekstmenuen til en Relation for at relatere til et (nyt) generisk BO). Et BO instantieres og typificeres nu direkte fra Canvas i én arbejdsgang. Bag scenen sker dog stadigvæk det samme: Først instantieres et generisk BO, hvorefter dets Type Property sættes og giver BO et dets specielle farvekode mm. Hvis man ser godt efter, kan denne typificeringsproces ses grafisk, idet et BO ændrer farveprofil fra en default (ikke konfigurerbar) profil til den typificere farveprofil samt ændrer default titel ( Business object ) til sin typificerede titel (f.eks. SalesOrder ). 5.3.2 Flytning af BO er via drag-n-drop På baggrund af muligheden for, at flytningen af et BO kan betyde, at brugeren ønsker at oprette en Containment Relation, er flytningen af BO er implementeret som drag-n-drop. Når den venstre museknap holdes nede på et BO s titelfelt, initialiseres en drag operation. Når musen flyttes (dragover), justeres BO ets koordinater i overensstemmelse med brugerens mus og flytter derved effektivt selve BO et i processen. I denne proces bliver der ikke foretaget noget drop. En fuldbyrdet drag-n-drop operation foretages kun, hvis dropeventen bliver registreret på Containment beholderen og det er kun i dette tilfælde at drag-n-drop implementationen er synlig. 5.3.3 Forskellige views på et Business Object Et BO består basalt set af tre beholdere: En til Elementer, en til Relationer og en til andre BO er (Containment). Denne inddeling gør det nemt og hurtigt at identificere de enkelte dele af et BO, således at f.eks. en Relation kan identificeres hurtigt. Det kunne indvendes mod min løsning, at de enkelte BO er bliver for store, når de indeholder dokumentation, andre BO er, Elementer mm. View funktionalitet sikrer derfor, at et BO kan foldes sammen og dermed få en acceptabel størrelse (se Figur 11). Denne funktionalitet ligger på top BO niveau, Element, Relation og Containment niveau, hvilket vil sige, at de enkelte dele eller et større samlet hele kan foldes ud og lukkes i og derved kommunikere større eller mindre detaljerigdom alt efter behov. - 24 -
Design og implementation af FreeDesigner Figur 11. View funktionalitet på alle niveauer Når beholderne er sammenklappede, kompenseres der for det lavere informationsniveau ved at vise, hvor mange Elementer, Relationer og Contained, der er på foldud/luki knapperne (f.eks. ses det på Figur 11, at der er et BO Contained i OurCompany på knappen th.). Ydermere vises der på øverste niveau (når musen holdes over navnet på BO et) et tooltip, der viser, hvad der er indeholdt i den lukkede beholder. Således også rekursivt ned på de lavere liggende niveauer, hvor tooltippene bliver mere detaljerige. Man behøver derfor ikke folde en beholder ud, hvis man f.eks. blot ønsker værdien, navnet e. lign. på et Element, der befinder sig i en sammenklappet beholder. 5.4 Elementer Et Element 21 kan indeholde mere end en property. F.eks. kan et Address Element bestå af tre properties: Gadenavn, gadenummer og postnummer. Et Element er en beholder, der kan indeholde properties og er altså ikke kun selv indholdt i et BO 22. De fleste modelleringsværktøjer undlader oftest at vise metodens/attributtens/relationens fulde sæt properties på selve modellen. Disse vises som regel i forkortet symbolform (Figur 12). Figur 12. Forkortet notation fra Together 21 I min kode er der navneforvirring mellem Element og Attribut, idet jeg ved starten på projektet pga. en patentansøgning ikke måtte benytte den egentlige betegnelse Element. Når jeg skriver Attribut, mener jeg det, der svarer til et Jamaica Element. 22 Dette er ikke tilfældet for min implementation af Relations Elementer: De indeholder ingen properties. - 25 -
Design og implementation af FreeDesigner someoperation formår via symbolik at kommunikere: public static Hashtable someoperation(person person){ } Den fulde signatur er: public static Hashtable Someoperation(Person person) throws IOException{ } Ønskes mere finkornet information og konfiguration kan man vælge den tekstuelle repræsentation på den givne entitet, hvorefter et udvidet sæt properties lader sig inspicere og konfigurere typisk i et nyt vindue eller i en propertybox 23. Den fulde mængde properties er traditionelt set ikke synlig på objektet selv. FreeDesigners grafiske repræsentation af Elementer blev til og kodet ud fra overvejelser om farve og forms rolle i henseende til overskuelighed (sammen med UML), UML s rolle i løsningen, objektafhængig funktionalitet for at undgå blokering og afskærmning af modelleringsfladen samt navigation og brugervenlighed. Disse overvejelser resulterede i en skitse for, hvorledes BO er og Relationer skulle fremstå (Se appendiks [1], s.5 Figur 3). Elementerne skulle ideelt set være afrundede, da en anderledes ikke-firkantet form fremhæver entiteten ud fra sine firkantede omgivelser. Da jeg benyttede.net UserControls og ikke simpel 2D tegning 24, var denne afrundede form lidt af en udfordring, idet UserControls i udgangspunktet er firkantede. Løsningen var at sætte UserControls Region Property, der kan have alle tænkelige komplekse former. Da jeg på daværende tidspunkt havde brug for yderligere en kompleks form til at lave en GrabControl (et Halo element, der kunne grabbe /indfange andre BO er til containment med form som en hånd (se appendiks [1], s.5 Figur 3) var det oplagt at have en metode, der som input tog et tofarvet bitmap med en vilkårlig kompleks form og returnerede et tilsvarende Region objekt svarende til den ene af farvernes form (i stedet for at hardcode et Region objekt via et komplekst GraphicsPath objekt). FreeDesigner.Util.BitmapToRegion håndterer transparens, således at et bitmap med den ønskede form udgør den ene inputparameter til metoden convert, der returnerer et Region objekt med bitmappens form, som herefter kan sættes som en UserControls (Se 6.2) Region Property. public unsafe static Region convert( Bitmap bitmap, Color transparencykey, TransparencyMode mode ) { TransparencyMode er en enum parameter til metoden, der kan angives, således at Color parameteren indikerer transparens eller modsat. Metoden benytter keywordet unsafe 25, fordi der benyttes pointere i scanningen af bitmappen. 23 Together såvel som JBuilder bruger begge samme type Propertybox som Visual Studio.NET. 24 Se afsnit 6.2 for en diskussion af fordele og ulemper ved brug af henholdsvis Shapes (2D tegning) og UserControls. 25 Denne fil skal derfor kompileres med kompiler switchen /unsafe - 26 -
Design og implementation af FreeDesigner Et Element kan åbnes og lukkes på samme måde som et BO og dets beholdere kan det. Størrelsen af Elementet i udfoldet tilstand afhænger af, hvor mange propertylines, der ligger på det (i Figur 13 ligger der f.eks. kun en propertyline på Discount Elementet). Når musen bevæger sig over et Element, skifter det farve for tydeligt at indikere, hvilket Element, der manipuleres. 5.4.1 Validering Nogle af Elementerne sammenblander runtime og designtime elementer ved f.eks. at befordre indtastning af firmanavn, pris o.lign. information der rigtigt først skal gives i den kompilerede ASPX løsning. Mest af alt er dette et udtryk for mit ønske om demonstrere konceptet: Propertyboxen er ikke nødvendig for at befordre indtastingsopgaver. Validering af input finder sted på og i objekterne selv. Elementer har en forudkonfigureret farve, der - hvis et Element har en ulovlig værdi eller kræver at blive konfigureret yderligere - får en rødlig farve (Discount Elementet i Figur 13 skal udfyldes, før det er gyldigt). Så snart dette er gjort, får Elementet sin normale farve tilbage (se Figur 14). Figur 13. Discount ikke valgt = invalid (rød farve) Figur 14. Discount type valgt = valid (normal farve) 5.4.1.1 Stoplys metafor Også på de enkelte propertylines bruges farvekoder til at kommunikere valideringsstatus. De Elementer, der kræver tekstuelt input, implementerer alle metoden validateattribute() 26, der returnerer en tilstand enumereret som NOTYETLEGAL (se Figur 15), ILLEGAL (se Figur 16) og LEGAL (se Figur 26 Interfacet FreeDesigner.AttributeDecorators.Idisplayable deklarerer denne metode. - 27 -
Design og implementation af FreeDesigner 17). Disse svarer farvemæssigt til stoplysets tre farver: Rød (ILLEGAL), Gul (NOTYETLEGAL) og Grøn (LEGAL). Figur 15. Validering af tinput: state = NOTYETLEGAL (gul farve) Figur 16. Validering af input: state = ILLEGAL (rød farve) Figur 17. Validering af input: state = LEGAL (grøn farve) Da funktionaliteten og konfigurationen ligger på objekterne selv, er fokus hermed lagt på de involverede objekter og løsningen, som det hele drejer sig om. Opmærksomheden skifter ikke længere frem og tilbage mellem objekter og propertybox. Et Address Element består som før nævnt af flere typer information (gadenavn, nummer osv.), men i stedet for at disse tastes ind i en propertybox, kan Elementet åbnes og konfigureres, hvor det befinder sig, og indtasting kan foregå direkte på de enkelte propertylines. Man kan med denne model se mange BO er og deres konfigurationer samtidig. De enkelte Elementer med tilhørende properties kan ses og sammenlignes og bruges referentielt i forhold til hinanden, selvom de bor i forskellige Elementer eller BO er, uden først at skulle vælge det enkelte Element og konferere med propertyboxens værdier. Elementerne kan ses åbne med alle deres propertylines eller lukket, hvor samme information vises som tooltip tekst, når musen befinder sig over Elementet. Al konfiguration foregår på Elementet selv. Valideringsstatus bliver kommunikeret ved brug af velkendte farvekoder, så det er let at se, om et Element befinder sig i en lovlig tilstand. - 28 -
Design og implementation af FreeDesigner 5.5 Relationer I den eksisterende Jamaica løsning er Relationer (fordi man har valgt konsekvent at være objekt centrisk) Elementer som alle de andre, blot med specielle attributter. Da en Relation er et specielt Element, inkluderer overvejelserne (særligt om grafisk repræsentation) fra ovenstående kapitel om Elementer også Relationer. En relation er kendetegnet ved at være involveret i en anden del af modellen. Dette karakteristika er det vigtigt at afspejle, således at en bruger hurtigt kan identificere de enkelte elementers samt den samlede løsnings involverethed i relation til hinanden. Denne involverethed har jeg valgt at illustrere ved at lade relationselementet stikke fysisk ud af BO containeren. Om det stikker ud til højre eller venstre er afhængigt af den modsatte deltagende Relations fysiske placering. Dette træk har jeg (forenklet set) opnået ved at sætte en Relations Parent Property til at være Canvas i stedet for BO ets container, som den hører hjemme i. Et BO sætter den ydre fysiske grænse for, hvilke Elementer, der kan ses på det, og med denne løsningsmodel slipper jeg for (som afprøvet i en alternativ version af FreeDesigner) at opdatere og justere BO ets Region Property med tilhørende komplicerede udregninger af denne. 5.5.1 Master/Detail FreeDesigner følger Master/Detail semantikken omkring Containment (se 4.1.1.2.2). En Master Relation ejer det BO, som den relaterer til, hvilket implicerer, at dette BO slettes, hvis Master Relations Elementet slettes. Denne semantik gælder kun for Master/Detail Relationer i Containment. Semantikken for normale Relationer er, at relationsforbindelserne slettes og efterlader BO erne intakte. Den semantiske information, der kan udledes fra en Relations fysiske fremtoning, styrkes ved, at det enkelte relationselement modtager den farvekode, som BO et på modsatte side af Relationen har. Dette bevirker, at en bruger kan vide sig sikker på, hvilken (Base) type BO, der er relateret til uden at skulle følge Relationen til modsatte ende. Endvidere bliver Relationens navn til det modsatte BO s navn efterfulgt af eller påhæftet (afhængigt af placering) et (M) eller et (D) afhængigt af, om det har rolle som Master eller Detail. Ændres der i BO ets navn, bliver Relationer, der relaterer til BO et, opdateret med det samme. Der er også givet mulighed for at ændre Master/Detail forholdet, således at de bytter roller via menupunktet Invert Master/Detail. Dette er en sen tilføjelse og virker kun på den Relation, der i udgangspunktet er Master (pga. ufuldstændigt design). 5.5.2 Relate to BO I Figur 18 ses et Relation Master Element med tilhørende kontekstmenu. Kontekstmenuen giver mulighed for at relatere til et nyt BO (der instantieres relateret til BO et, hvori Master Relationen ligger) eller til et allerede eksisterende BO. Det kan også slettes. Denne mulighed tilbydes, for at brugeren ikke først skal instantiere et BO for derefter at relatere til det. - 29 -
Design og implementation af FreeDesigner Figur 18. Relate to BO kontekst menu Det ville være en forbedring af kontekstmenuen til Relationer at lade de menupunkter, der har med instantiering af Relationer at gøre, optræde direkte på Relations beholderen i stedet for først at skulle instantiere en generisk Relation og først derefter relatere til et nyt eller eksisterende BO. Disse to sidstnævnte skridt kunne lige så vel foretages i første skridt, således at en Relation direkte blev relateret uden denne omvej. Af samme årsag burde menupunktet Relate to NEW (generic) UML (se Figur 18) også have været fjernet, da dette skridt ligeledes udgør en omvej, og fordi der aldrig er brug for generiske BO er (muligheden for at instantiere generiske BO er eksisterer for lettere at kunne illustrere typificeringsprocessen (se også 5.3.1)). 5.5.3 Relate to exisisting Det er muligt at relatere til allerede eksisterende BO er. Kontekstmenuen Relate to existing (se Figur 19) tager sig af dette. Denne kontekstmenu er udstyret med speciel funtionalitet, der bevirker at modellen/canvas automatisk scroller til og vælger det BO, som musen står på i kontekstmenuen. Menuen bliver stående statisk på samme sted, mens der scrolles rundt på Canvas. På denne måde kan man vide sig sikker på, hvilket BO man er ved at oprette en Relation til og slipper dermed for besværlig navigation rundt på Canvas med det formål at sikre sig, at det er det rigtige BO, der relateres til. Det er samme ide og funktionalitet, der ligeledes trækkes på og benyttes i MiniCanvas (se 5.8.3). - 30 -
Design og implementation af FreeDesigner Figur 19. Relate to existing kontekstmenu 5.5.4 Navigation At navigere fra en Relation til dens modsatte ende bør være let og effektivt. En Relation har i sin kontekstmenu et punkt, der hedder Go to peer (se Figur 20), der, hvis det vælges, scroller Relationens modsatte BO i fokus og vælger det. Da Relations Elementerne ikke indeholder nogen information i sig selv (der er ikke behov for at kunne åbne dem som normale Elementer, der indeholder propertylines) har jeg endvidere tilladt samme funktionalitet (at scrolle til modsatte ende og vælge BO et dér) blot ved klik på Relationen. På denne måde bliver det nemt at bevæge sig rundt i modellen og opdage, hvorledes Relationerne er sammensat. - 31 -
Design og implementation af FreeDesigner Figur 20. Hurtig navigation mellem relationer ( Go to peer ). Alt i alt mener jeg, at de i indledningen anførte problemstillinger i Jamaica Designeren omkring navigation og identificerbarhed af Relationer er løst i FreeDesigner. Dette er opnået ved at: 1. give Relationer en beholder for sig (der kan vise information om Relationerne, selvom den er lukket), 2. lade Relationerne stikke ud over BO ets naturlige grænser (indentificerer dem klart som Relationer og adskiller dem fra normale Elementer, der ikke stikker ud), 3. give Relationerne farvekoder i overensstemmelse med de BO er, de relaterer til, påtegnelse af (M) eller (D) (så det er klart, hvilken rolle Relationen spiller), 4. udstyre Relationer med en kontekst menu samt click-funktionalitet der tilbyder hurtig navigation mellem Relationer, 5. navigation til de mulige BO er, der skal relateres til, ved selve instantieringen af Relationer (via speciel type menupunkt). - 32 -
Design og implementation af FreeDesigner 5.6 Containment Containment bærer nærmest sin egen definition i sig selv. Et BO kan indeholde andre BO er. I Jamaica er dette muligt i ét niveau, men i FreeDesigner kan dette forhold gå til en vilkårlig dybde. Containment er implementeret via drag-n-drop, hvor Containmentcontaineren accepterer drops af andre BO er. Med fremstillingen af Containment metaforen, som den foreligger i FreeDesigner, mener jeg, at der, udover at Containmentmetaforen fremstiller et 1:1 forhold mellem semantik og visualisering, også rådes bod på den mere generelle UML problematik, der består i, at en relation visuelt kan signalere både at være aggregeret og associeret, hvilket man kun med sikkerhed kan bestemme ved at se begge ender af en relation og dermed konkludere, hvorvidt der befinder sig en diamant i en af dem eller ej. I FreeDesigner har Relationer forbindelsesstreger, mens aggregering (Containment) ikke behøver streger. Mjølners Beta UML editor [5] anvender en alternativ grafisk notation (Figur 21), der godt kunne anvendes på Containment. Figur 21. Mjølners priknotation for selektiv model information De tre prikker efter klasserne i Reservation-lib betyder, at der er udeladt information og signalerer, at man kan få denne information at se ved at dobbeltklikke på prikkerne. Prikkerne fungerer som links og fører til et mere udførligt diagram, som vises på samme kanvas: en form for viewports. Menuen view giver endvidere mulighed for mange forskellige views med forskellig detaljerigdom. Viewport metaforen kunne også have fundet anvendelse i forhold til Containment, hvor man kunne forestille sig, at et BO tiltænkt en Containment Relation, trækkes ind på BO et med Master rolle, hvorefter det fjernes fra Canvas og erstattes af et Mjølner link (priknotation) i det indeholdende BO. Dobbeltklik på linket ville bevirke, at BO et igen kom - 33 -
Design og implementation af FreeDesigner til syne på Canvas i nærheden af BO et med Master rollen evt. med en stiplet linje imellem de to for dermed at signalere at der er tale om Containment. Denne metafor er nyttig men jeg mener, at den af FreeDesigner benyttede metafor er mere brugbar, idet den straks tillader brugeren at konfigurere BO et i Containment såvel som udenfor. Farvekoderne hjælper til med at identificere Master Relationen i den enkelte Containment beholder (da farvekoden for det indeholdende BO findes på begge sider af BO et foroven og forneden)(se Figur 22) selv i større dybder (vilkårlig dybde er mulig i FreeDesigner). Hvis et BO f.eks. befinder sig fem lag nede i en Containment Relation, ville det i Mjølner modellen kræve fire dobbeltklik at nå frem til det, hvilket yderligere ville forårsage fremkomsten af fire ekstra BO er på Canvas. I FreeDesigner er man der med det samme og kan overskue såvel som konfigurere Relationerne om end de er mere komplekse i så stor en dybde. Figur 22. Containment i stor dybde - 34 -
5.6.1 Hvorfor speciel visualisering af Containment og Relation? UML 27 har i princippet udtrykskraft nok til at visualisere Containment og Relation (se Figur 23). Figur 23. Mulige relationestyper bestående af Master/Detail Element par Problemet ved denne visualisering er, at man nemt forvirrer aggregering og associering navnlig, hvis man befinder sig i den forkerte ende af relationen: At relationen ikke har en diamant/rombe kan betyde at: 1. objektet selv er aggregeret, 2. objektet er en del af en association For at bestemme dette skal man følge relationen til dens modsatte ende og der se efter diamanten/romben. Herefter skal man yderligere lokalisere Master/Detail Elementet for at forstå relationens nøjagtige semantik. På grund af denne forvirring finder jeg det logisk, at disse to typer relationer bliver, hvad de er : Containment er et objekt indeholdt i et andet, så hvorfor ikke også vise det således? En normal relation vises fint med den traditionelle streg i UML, men semantikken kan udfyldes bedre endnu (se Figur 20): Master/Detail elementerne får påtegnet et stort (M) eller (D), så man med det samme kan bestemme, hvilken rolle man har med at gøre. Endvidere antager den forbindende streg farven fra Master Elementet, således at man bibringes ekstra information blot ved stregens farve. Endvidere antager Master/Detail 27 I kapitel 6.1 diskuteres UML, og hvorfor jeg har valgt ikke at følge denne model stringent, mere indgående. 35
Design og implementation af FreeDesigner Elementerne farvekoden fra Relationernes modsatte BO farveprofil. Ved at lade Relationselementet stikke fysisk ud af boksen adskiller det sig fra normale Elementer og udviser deres involverethed og pegethed i forhold til et andet Element i modellen. Master/Detail Elementerne har deres egen beholder, hvilket gør dem nemme og hurtige at identificere. 5.7 Aliasing Bo er rummer i Jamaica frameworket mulighed for Aliasing ([15], kapitel 2.1.4.2): Et BO kan på én gang have rollen Indkøber og i en anden sammenhæng rollen Sælger. Dette forhold er ikke implementeret. 5.8 Overblik og modelnavigation Overblik og effektiv modelnavigation er to vigtige mål for min prototype der skulle råde bod på manglen af samme i Navisions designer. Farvekoders betydning for overskueligheden er beskrevet i kapitel 5.8.1. Formernes betydning for overblikket er beskrevet i 1.1.1, og OCL (modelnavigation) er beskrevet i 6.1.2. Navigation mellem relaterede BO er er beskrevet i 5.5.4. Nedenstående kapitler omhandler forskellige andre måder, hvorpå jeg har søgt denne problemstilling løst. 5.8.1 UML in Color Ideen om at benytte farvekoder i mine BO er var min egen. Senere har anskaffet mig bogen Java Modeling in Color with UML [13], hvori ideen udgør hovedtemaet. UML diagrammer vises som regel i sort/hvid. Ganske få tools har taget farve til sig som et nyttigt udtryksmiddel: Borlands JBuilder kan f.eks. producere et farvet UML diagram ud fra koden, men kan ikke bruges til at modellere kun til at visualisere. Poseidon for UML [4] muliggør vilkårlige farvedefinitioner for elementer. At der ikke bruges farve i større udstrækning er tankevækkende, da farve er et af de mest kraftfulde udtryksmidler til at hjælpe os i at skelne entiteter fra hinanden. Min originale idé gik på, at hver af de fire BO baser skulle have deres egen farvekode, der blev nedarvet til subklasser heraf. Faktisk er dette tal (4) præcis det antal, som bogen anbefaler ([13], kapitel 1.2.2), da det af farverne bibragte overblik bliver forvirret, hvis det er flere. Som nævnt i kapitel 4.1.1.1 har Navision faktisk identificeret 8-10 Baser. De fire Baser, jeg har implementeret og benytter, er dem, der primært benyttes i konfigurationerne, og det er mit forslag, at disse er de eneste, der skal benyttes farvekoder for. I en stor UML eksempel model, som Navision har lavet ([9], slide 37), fremgår det, at de fire Base typer, som jeg benytter i FreeDesigner er dem, der i overvejende grad benyttes. Mit forslag er derfor, at de resterende få Baser kunne være hvide eller alle dele den samme (mere anonyme) farveprofil. - 36 -
Design og implementation af FreeDesigner Figur 24. Konfiguration af farveprofiler De UML modeller, som eksperimentelt af Navision er konstrueret vha. Microsoft Visio, benytter UML stereotyper til at markere Base typerne (se Figur 23). Den føromtalte bog (se f.eks. [13], s. 126) knytter farveprofiler til stereotyper (eller arketyper, som bogen også kalder dem) og benytter samtidigt den traditionelle UML notation for stereotyper ( <<stereotypename>> ). At de enkelte BO ers farvekode i FreeDesigner ikke er enkeltfarvet skyldes kun ønsket om at få modellen til at se mere spændende og frisk ud. Et BO med kun én farve ser lidt forstenet og dødt ud gradienten bringer liv til BO et, synes jeg. Muligheden for at lade både Colour1 og Colour2 (se Figur 24) være ens eksisterer. Farvekoderne benyttes på BO er, hvor hver Base har sin egen profil. Elementer har ligeledes deres egen profil bortset fra Relations Elementer, hvor de to Relationer modtager farveprofilen fra det BO, de relaterer til. Ydermere får stregen mellem Relationerne farve af Master Relationen. FreeDesigner.UMLControls.UmlContainerKit tager sig af farvekoderne. Farvekoderne baserer sig på en enum, der kan antage værdier svarende til hver BO Base. - 37 -
Metoden applycolorprofile tager sig af tegningen i en switch på denne enum: switch(colorprofile){ case ColorProfiles.Asset: int[]color = FreeDesigner.Util.ColourProfileConfig.getAssetColors(); b = new LinearGradientBrush(drawingArea, Color.FromArgb((color[0])), Color.FromArgb((color[1])), LinearGradientMode.Vertical); Et problem ved at lade partnerne selv bestemme farvenuancerne er, at semantikken i de forskellige farver skifter for hver ny installation af FreeDesigner. Rød i en installation har ikke nødvendigvis den samme semantik i en anden, hvilket kunne være løst ved, at jeg blot havde lagt mig fast på nogle farver (der er givet en default konfiguration af disse, som man kan vælge at acceptere). Jeg mener i den forbindelse, at fordelen ved selv at få lov at afgøre, hvilke farver, man vil se på i sit værktøj, er større end ulempen ved ikke at have samme semantik på tværs af installationer, da det kun drejer sig om fem forskellige farveprofiler. 5.8.1.1 Teksturer En måde, hvorpå en skelnen mellem de forskellige (typer) elementer yderligere kunne styrkes, ville være brug af teksturer. Disse kunne benyttes på udvalgte dele af UML elementet - eksempelvis kun på øverste del (for ikke at forplumre i stedet for at forklare). Semantikken, der kunne lægges i brugen af teksturer, er mangfoldig og rig: Teksturer kunne angive, at stereotyper (f.eks. en BO Base af typen Party) implementerede et givent interface (i Java kunne klasser, der implementerede Serializable eller Remote, have tesksturerede navnefelter), teksturer kunne benyttes ved typer, der var nedarvede fra brugerdefinerede typer. Teksturen kunne angive, at klassen var en Exception klasse osv. Kun fantasien sætter grænser. I sidste instans er det netop spørgsmålene Forklarer det mere end det forplumrer?, giver det øget overblik?, der må fungere som rettesnor for det nyttige i at implementere en sådan feature. Semantisk overloading kan koste manglende enkelhed og overblik. 5.8.2 Statusbar På det elementære plan har FreeDesigner en statusbar, som udover at vise hjælpeinformation, fejlmeddelelser mm., yderligere er udstyret med 4 specielt dedikerede statusbarpaneler (se Figur 25): Det første viser hele tiden et koordinatsæt for, hvor på Canvas, musen befinder sig, hvilket er nyttigt i store løsninger. De sidste tre paneler viser information for, hvorledes løsningen numerisk fordeler sig i henseende til, hvor mange BO er, Contained BO er og Relationer, der indgår i løsningen. Dette bidrager til opnåelse af et hurtigt indtryk og overblik over løsningens kompleksitet og størrelse. Jeg vurderede, at en statusbars størrelse ikke skærmede væsentligt for modelleringsfladen og mener, at det er nødvendigt at have et fast interface, hvor programmet kan kommunikere beskeder, status mm. videre til 38
Design og implementation af FreeDesigner brugeren. Jeg har forsøgt at implementere en stoplysmetafor på et statusbarpanel, der i overensstemmelse med valideringen af partnerens handlinger viste status med samme stoplysmetafor, som benyttes i validering af Elementers værdier (Se kapitel 5.4.1). Dette projekt har jeg ikke færdiggjort. Figur 25. Statusbar med konfigurationsinformation 5.8.3 MiniCanvas Flere kendte løsninger 28 gør brug af en navigerbar minimodel af modelleringsfladen. Ideen er, at man nemt og overskueligt skal kunne navigere på den mindre model, og at fokus på den store model dermed automatisk følger med. Kontekstmenuen på Canvas rummer mulighed for at få vist en sådan minimodel (se Figur 25). Figur 26. MiniCanvas Oprindeligt var MiniCanvas implementeret således at det blev vist når man holdt mellemrumstasten nede og forsvandt igen når man slap den således at man havde nem og hurtig tilgang til det (det havde nok været bedre, hvis funktionen havde ligget på en af funktionstasterne (f.eks. F10), sådan at den virkede, selvom man stod i et tekstfelt). Dette medførte en del problemer i forhold, til hvilke komponenter, der havde fokus (havde et BO f.eks. fokus, 28 Se f.eks. Rational XDE, Poseidon for UML, Adobe Photoshop. - 39 -
Design og implementation af FreeDesigner kunne mellemrumstasten forårsage, at dokumentationsknappen blev udløst (problemstilling med taborder)). Problemerne løste jeg ved at lade visningen af MiniCanvas være bestemt af et kontekstmenupunkt på Canvas og lade det lukke igen ved klik på MiniCanvas. Det blålilla område, der følger musen, repræsenterer skærmområdet og hvor i dette, musen befinder sig (som det ses på Figur 26 er Canvas i FreeDesigner meget stort, og det rummer desværre ingen mulighed for konfiguraton). Føres sigtekornet (Cursor) ind over et BO, viser dette via tooltip tekst den relevante information for BO et (Navn, type, Relationer mm.), og det store Canvas scroller automatisk til BO et og vælger det, så det er klart, hvilket et, man har fat i. De í note 28 nævnte programmer, der benytter lignende minimodeller, har dem som regel fast integreret som et view/panel på designfladen. Min oplevelse af disse navigationspaneler har været, at det hørte til undtagelsen, at jeg benyttede dem 29, da arbejdet i reglen (hvad enten der er tale om et billede i Photoshop eller et UML diagram i Poseidon for UML) er fokuseret på mindre områder ad gangen. Navigation i større modeller foretages ved at zoome ind og ud. I sidste instans ville det være fornuftigt at foretage en brugerundersøgelse af, hvordan udviklere ønsker at (kunne) navigere og derefter vurdere, om pladsen til et sådant panel er godt givet ud. Da jeg ikke har givet mulighed for konfiguration af Canvas størrelse, men har valgt at gøre det meget stort, kommer størrelsesforholdet mellem Canvas og MiniCanvas minimodellen til at se en anelse mærkværdigt ud (meget små objekter på et relativt stort MiniCanvas). Dette ville kunne undgås, hvis blot man kunne afstemme Canvas størrelse efter modellen eller forstørre de enkelte BO er på MiniCanvas, så de relativt fyldte mere (dette kunne gøres automatisk). 29 Kan jo være, fordi mine løsninger ikke har været omfattende nok. - 40 -
5.8.4 Navigation via MenuItem Funktionalitet meget lig den, minicanvas tilbyder, forefindes også i Canvas kontekstmenu Navigate by name og Relationers kontekstmenu Relate to existing, hvor alle konfigurationens BO er listes med navn og id. Figur 27. Navigation via MenuItem Når musen bevæges over et menupunkt, navigerer modellen automatisk til det relevante BO og vælger det. Når et punkt vælges, scrolles der automatisk til det relevante BO, der samtidig vælges. Denne funktionalitet er også implementeret i kontekstmenupunktet for en Relation under menuen Relate to existing, der ligeledes scroller frem til det relevante BO, så man kan vide sig sikker på og checke, hvilket BO man er i færd med at relatere til. Det ville endvidere være en god idé at tegne de enkelte Menupunkter i samme farvekode som det BO, det peger på, for at opnå bedre overblik i store løsninger, men det har jeg ikke implementeret. Denne idé kunne udvides, således at menuen var sorterbar efter diverse kriterier. Mest oplagt ville det være at sortere efter BO Baserne i samme orden som den, man møder, når man skal instantiere BO er. 5.8.4.1 Subclassing MenuItem At al funktionalitet ligger på objekterne, og at funktionaliteten tilgås via kontekstmenuer betyder ikke, at kontekstmenuerne udelukkende skal fungere som genveje til programudførsel. De kan udstyres med større intelligens end som så, selv om det medfører, at de får en funktionalitet, der traditionelt ikke forbindes med menupunkter. 41
Design og implementation af FreeDesigner Menupunkter fra menuen Navigate by name 30 (se Figur 27) arver fra.net klassen MenuItem og er udstyret med en reference til et BO, der sættes i konstruktoren, hvilket gør det muligt at scrolle til BO et og vælge det, når MenuItem fyrer sine forskellige events (f.eks. click, popup, validate m.fl.). public class NavigateMenuItem:MenuItem{ private FreeDesigner.UMLControls.UMLMainControl _main; Ligeledes har jeg ved at arve fra MenuItem i FreeDesigner.UMLControls.Attribute. AttributeMenuItem (se Figur 28) givet Menupunkter et Type og et Element felt der kan benyttes ved instantiering, således at jeg ikke behøver at benytte ressourcekrævende refleksive metoder, hver gang et Element skal instantieres. Figur 28. Typificerede menuitems et item har en BO Type. En mulig udvidelse af denne implementation går på at implementere en usagelist, således at de mest brugte Elementer står først i kontekstmenuen og på at sørge for, at menuen åbner fra midten, således at de to næsthyppigst valgte Elementer begge kun står et klik væk 31, og det sidst benyttede står valgt i midten. Denne idé kunne også bruges på samme måde mht. instantiering af BO er fra Canvas. 30 Se namespace FreeDesigner.Canvas.CanvasForm.NavigateMenuItem 31 Smalltalk IDE en Visual Works åbner menupunkter fra midten med det punkt valgt, man sidst har benyttet. - 42 -
Design og implementation af FreeDesigner 5.8.5 ToolTip information Figur 29. Tooltip tekst, for BO (tv.) og Elements (th.) Med til at styrke overblikket er endvidere brugen af former, hvor BO er er firkantede, mens Elementer og Relationer er afrundede, hvilket gør dem nemmere at identificere, idet deres form og ikke blot farvekode afviger fra beholderens. 5.8.6 Modellayout Jeg har implementeret en ganske simpel algoritme, der tager sig af Modellayout (FreeDesigner.Util.LocationMaster). To klasser (UMLSorterX og UMLSorterY) implementerer begge Icomparer, der kræver metoden Compare(object obj1, object obj2) implementeret. Den har jeg implementeret, således at der sorteres efter henholdsvis mindste X og Y værdi. Den resulterende sorterede ArrayList kan herefter traveseres, og de enkelte BO er kan flyttes, hvis følgende test evaluerer til true: if(enlargebounds(umlb).intersectswith(enlargebounds(umla))){ Det er en simpel algoritme, og den tager ikke højde for f.eks. at arrangere BO er efter Relationer, men fungerer som eksempel på, at noget sådant kan implementeres (mere effektivt) givet mere tid. - 43 -
Tekniske og teoretiske overvejelser 6 Tekniske og teoretiske overvejelser Dette kapitel beskæftiger sig med emner, der falder lidt uden for det ellers gennemgående tema, der har med design og GUI at gøre. I kapitlet fokuseres der i højere grad på teknikker, der er anvendt i FreeDesigner samt de teoretiske overvejelser, der har ligget til grund for brugen af dem, herunder UML, OCL, domænespecifikke visuelle sprog, UserControls vs. Shapes, XML, kodegenerering, events og Delegates, database samt brugen af design patterns i FreeDesigner. 6.1 Hvorfor ikke bare traditionel UML? En af hovedmotivationerne for udviklerne af UML var at lave en semantik og notation, der adresserede alle størrelser af kompleks arkitektur på tværs af domæner [11](s.45). Man kunne på denne baggrund argumentere for, at traditionel UML alene kunne bruges som visualiseringsmedium for den grafiske konfiguration, en holdning, jeg har mødt fra forskelligt hold 32. Ren UML kan anskueliggøre Navisions konfigurationsmodel, hvilket faktisk praktiseres på eksperimentelt plan på Navision, via et Microsoft Visio plugin. 6.1.1 OMG s UML vs FreeDesigner UML profile Fire ting adskiller min model fra traditionel UML og bevirker, at den ikke er i overensstemmelse med OMG s UML specifikation (OMG UML 1.4[11]): 1. farvemønstrene, 2. containment metaforen anskueliggjort som rigtig visuel ontainment og ikke som en traditionel UML aggregerings relation, 3. elementer ud af boksen, 4. dokumentation for de enkelte objekter i objekterne selv. OMG s (Object Management Group) specifikation for UML og dettes extensbility er meget detaljerig og rigid, hvilket er hensigtsmæssigt, hvis man skal lave generelle modelleringsværktøjer for f.eks. programmeringssprog, således at semantikken bliver konform, og UML modeller nemt kan udveksles mellem forskellige tools. OMG har specificeret en Extension Mechanisms package ([11], s.130), der definerer, hvorledes specifikke UML modelelementer kan customizes og extendes med ny semantik ved hjælp af stereotypes, constraints mm. En sammenhængende mængde af sådanne extensions konstituerer en UML profile. Den primære OMG baserede mulighed for at extende UML ligger i brugen af Stereotypes, som giver mulighed for at definere virtuelle subklasser af UML metaklasser med nye metaattributter og udvidet semantik ([11], s.130). En af tankerne bag UML er endvidere portability af modeller bl.a. via XMI. Da portability ikke har været specificeret for Navisions konfigurationssystem (al 32 Således Juha-Pekka Tolvanen fra MetaCase (http://www.metacase.com/ ), der deltog i Workshop on Domain Specific Visual Languages på OOPSLA 2002-44 -
Tekniske og teoretiske overvejelser konfiguration foregår i ét tool), og da output formatet (kodegenereringen) retter sig mod XML formatet Depack (domænespecifikt for Navisions Business Objects) og ikke XMI (Domænespecifikt for UML og modeller), så jeg ingen grund til at fokusere på at lave en fuldkommen UML compliant model, men satte netop det domænespecifikke i højsædet. UML er primært et modelleringssprog for programmeringsdomænet og er som sådant et succesfuldt visualiseringsredskab for komplekse kodesammenhænge. Selve UML s metamodel er på et overordnet plan farbar, så længe det gælder om at visualisere relationer mellem entiteter, men så snart det bliver mere (domæne-)specifikt mener jeg, at der er mere vundet ved at udvide UML og lade det domænespecifikke få rang over UML s metamodel eller helt forlade UML til fordel for en anderledes visualiserings- /modelleringsmetafor. Idéen med UML er, at programmører m.fl. i UML har et universelt sprog, som de kan (gen-)bruge i de fleste (primært objektorienterede) kodesammenhænge og samtidigt et sprog, som er universelt og dermed kan forstås af andre programmører. Deraf følger dog ikke, at det er velegnet i alle modelleringssammenhænge. Af ovennævnte årsager og fordi systemet ikke er CORBA/IDL baseret, var MOF specifikationen 33 heller ikke relevant. På den baggrund har jeg valgt at kalde min model for UML inspireret og ikke en udvidelse af UML i stringent OMG forstand, der kunne kaldes for en UML profil. Jeg mener, at UML editorer generelt ville kunne drage nytte af flere af de idéer, jeg har implementeret i min model. Farvekoder er et eksempel herpå og vinder langsomt indpas flere forskellige steder 34. Dokumentation på objekterne selv mener jeg ligeledes er et plus sammen med øget mulighed for redigering på objekterne selv. Jeg mener endvidere, at UML editorer generelt kunne drage nytte af tydeligere markering af relationers rolle i begge ender af relationen, da man ofte er tvunget til at søge relationens modsatte ende for at få afklaret den præcise semantik. Brugen af kontekstmenuer til hurtig instantiering/manipulation synes jeg også er et ønskværdigt træk, som burde kunne customizes, således at de elementer, der oftest benyttes, kunne forefindes i en kontekstmenu. Containment metaforen er ikke så entydigt nyttig, da rombe/diamant semantikken formår at kommunikere separation of concerns, hvorimod Containment metaforen formår at kommunikere Containment. Hvad der er vigtigst at kommunikere, er domæne afhængigt, og jeg mener, at UML, der skal være et generelt sprog, er bedst tjent med at benytte rombe/diamant metaforen blot med en tydeligere angivelse af semantikken i den ende, der ikke har romben. 33 http://www.dstc.edu.au/research/projects/mof/rtf/mof-rtf.bk.final.pdf 34 Poseidon for UML[4] tillader definition af vilkårlige farver på elementerne, JBuilder benytter et veldefineret farvemønster til UML visualisering, og der gives sandsynligvis masser af eksempler. - 45 -
Tekniske og teoretiske overvejelser 6.1.2 OCL Under udviklingen af FreeDesigner har jeg undertiden savnet at have et sprog hvormed jeg meget præcist kunne udtrykke, hvilke BO er, hvilke Relationer mm., jeg ville have fat i. Havde min model været bygget på UML metamodellen, kunne jeg have benyttet OCL (Object Contstraint Language) [11] til validering, navigation, post-/preconditions mm. OCL er et formelt sprog beregnet til UML (OCL specifikationen er en del af UML specifikationen). OCL Udtryk ændrer ikke ved modellen eller nogen af objekternes værdier, men er primært konstrueret til at beskrive constraints, der typisk beskriver invariante betingelser for systemet eller metamodellen, der skal holde. OCL kan endvidere benyttes til modelnavigation og kan ved sproglige udtryk med udgangspunkt i ét specifikt objekt ( self ) via dotnotation ([11], kapitel 6.5.1) navigere til associerede objekter ([11], kapitel 6.5.6). OCL udtryk ville sandsynligvis kunne bruges til validering af FreeDesigners model (da denne ligger relativt tæt op ad UML s), men det er ikke forsøgt implementeret, og jeg er ikke sikker på, hvilke implikationer det har, at FreeDesigner ikke er 100% UML compliant. Validering håndteres i FreeDesigner på anden vis (se kapitel 5.4.1). 6.1.3 Domæne specifikke visuelle sprog (DSVL) Et ikke fuldstændig UML compliant visuelt sprog, der nærmer sig ERP domænet og mere specifikt Navisions idéer om samme, kaldes et Domæne specifikt visuelt sprog. DSVL er et voksende og selvstændigt område, og fænomenet har sine egne workshops, community sites mm. Jeg deltog i workshoppen[17] Domain Specific Visual Languages på OOPSLA 2002 i Seattle. Nuværende modelleringssprog er ofte baseret på koncepter taget fra programmeringssprog, hvilket fører til dårlig kortlægning af organisationer og virksomheders domæner og dobbeltarbejde i forhold til problemløsning, design og kodning. DSVL tilbyder hurtigere udvikling af applikationer baseret på modeller af produktet frem for modeller af koden, hvis det domænespecifikke visuelle sprog i øvrigt er godt designet. Et DSVL benytter regler og koncepter fra domænet selv. Sammen med generators og komponenter kan DSVL medvirke til at automatisere softwareproduktion. DSVL tilbyder på én gang at højne abstraktionsniveauet bort fra kode, der erstattes af grafisk manipulation af komponenter og forsøger samtidig at indkredse og definere det domæne, der skal modelleres. Elementerne i en DSVL model, deres abstraktioner og semantik tilhører altså det modellerede domæne og ikke kodedomænet, hvilket bl.a. muliggør at domænespecialister, der ikke er programmører, kan benytte DSVL. Modellerne kan på samme tid udgøre design, implementation samt dokumentation mm., og de kan nogle gange genereres direkte ud fra modellerne. - 46 -
Tekniske og teoretiske overvejelser Flere nuværende visuelle modelleringssprog tager udgangspunkt i kodeverdenen og benytter semantisk veldefinerede koncepter fra programmeringssprog (f.eks. UML). Med disse sprog skal udviklere gå direkte fra kravspecifikation til implementationskoncepter og skifte mellem koncepter og semantik fra domænet, UML og koden selv, hvilket ofte kan være en fejlbehæftet proces. I et DSVL bliver problemet løst én gang ved at benytte domænets koncepter i løsningen. De endelige produkter kan genereres automatisk fra disse highlevel specifikationer ved hjælp af domænespecifikke generators 35. Der er brug for tre ting for at opnå fuldautomatisk kodegenerering fra domænemodellering: 1. et modelleringsværktøj, der understøtter et domænespecifikt visuelt sprog (FreeDesigner), 2. en kodegenerator (FreeDesigner.XML.ASPX_codeGenerator), 3. domænespecifikt komponentbibliotek (namespace BO med tilhørende decorators). FreeDesigners modelleringssprog er således et domænespecifikt visuelt sprog inspireret af UML. 6.2 UserControls vs. Shapes I de første versioner af FreeDesigner benyttede jeg simpel 2D tegning til visualisering af de forskellige objekter. Den abstrakte klasse Shape (som stadig findes i modificeret form under namespace FreeDesigner.Shapes 36 ), fra hvilken alle øvrige Shapes arvede, kræver følgende metoder implementeret: object gethittest(point p); void Draw(Graphics g); Rectangle BoundingBox { get; set; } void DrawAdornments(Graphics g, bool primary); bool Selected{ get; set; } Denne model viste sig at være relativt kompliceret at implementere. Flere Shapes skulle indeholde andre Shapes, der rekursivt igen kunne indeholde andre Shapes i en relativt stor dybde. gethittest()metoderne blev meget indviklede, og alle events, som de forskellige Shapes kunne fyre, skulle hver især implementeres som Delegates med tilhørende EventArgs klasser mm. Denne problemstilling blev løst ved at arve fra.net klassen UserControl, som er en førsteklasses kontrol (der arver fra ContainerControl) og arver en masse egenskaber som f.eks. positionering, events, tegning. En UserControl kan indeholde UserControls (via sin Controls Property) og har sit eget Graphics 35 Ovenstående introduktion baserer sig i høj grad på [12,s.2]. 36 Shape er Modificeret, således at den nu arver fra UserControl og ikke længere er en normal arketypisk 2D shape. - 47 -
Tekniske og teoretiske overvejelser objekt, der bl.a. kan tilgås via kontrollens Paint event. Hver Kontrol har altså sit eget Graphics objekt, hvilket gør det nemt at bestemme, hvor der skal tegnes (i stedet for at skulle regne sig frem til et givent punkt på Canvas). Alle grafiske objekter arver nu fra UserControl. De fleste af de elementer, der arver fra UserControl, lever i namespace FreeDesigner.UMLControls (borset fra dem, der lever i FreeDesigner.Canvas). 6.3 C# Properties som konfigurationsskabelon Til en BO Base hører en konfigurationsskabelon, der definerer, hvilke Elementer, Tasks mm., en instans af et BO kan/må indeholde. Denne skabelon har jeg implementeret vha. C# s sprogkonstruktion Properties, som jeg har gjort flittig brug af i hele FreeDesigner. En anden problemstilling, der søgtes løst gennem brugen af Properties, var afkobling mellem BO og GUI logik. En Property er et metodepar (get og set), der i forhold til klientkode ser ud som og opfører sig som et felt (der kan sættes direkte). Properties er fast integreret i sproget og hviler ikke, som Java gør det, på navnekonventioner baseret på metodepar (getter og setter). En klasse har f.eks. følgende felt: private string _name; Til dette felt knyttes en Property: public string Name{ get{ return this._name; } set{ this._name = value; } } C# s sprogspecifikation foreslår, at Propertien hedder det samme som feltet, blot med stort forbogstav ([18], kapitel 8.7.4). Propertien giver nu mulighed for at tilskrive _name feltet direkte via Propertien Name: EnInstans.Name = Contract ; Endvidere kan man via reflection få fat i disse Properties: PropertyInfo[] all = atype.getproperties(); De enkelte BO Typer har en mængde Properties, der hver især svarer til et Element, der kan ligge på BO et. Skabelonen med Properties, som den foreligger i FreeDesigner, siger kun noget om, hvilke typer Elementer, der kan ligge på et givent BO ikke noget - 48 -
Tekniske og teoretiske overvejelser om, hvor mange. Den siger heller ikke noget om restriktioner eller om, i hvilken kontekst mm. de må forekomme. Den type restriktioner ville kunne håndhæves bedst, hvis hvert BO havde et centraliseret konfigurations factory objekt, der stod for instantiering, validering mm. 37 op imod f.eks. et Hashtable med Type antal indgange. Denne logik kan også til en vis grad inkorporeres i Propertymetoderne. 6.3.1 Navnekonventioner vs. Custom attributes Der er løs kobling mellem namespace BO (mit Business Object framework) og GUI logikken for dette. Namespace BO indkapsler BO viden og intet andet. Min første løsningsmodel på, hvordan jeg kunne opnå løs kobling og samtidig fremstille BO er grafisk, var at benytte navnekonventioner. Et BO har som ovenfor nævnt en mænge public Properties, der gør instansfelter af Element klasser tilgængelige. 6.3.1.1 Navnekonvention En BO klasse (uagtet at denne er abstrakt) har f.eks. et felt, som er et BOElement: public abstract class Party{ private BO.BOElement.Identification.Id m_partyid; Samme klasse har en Property, der ved navnekonvention understreger, at den er ment som et Element. Denne navnekonvention blev benyttet, fordi man kunne tænke sig interne Properties, der ikke skulle fungere som Elementer (det havde været tilstrækkeligt, hvis jeg blot havde set på signaturen og dér verificeret, at Propertiens returtype hørte hjemme under namespace BO.BOElement, hvorved der ikke havde været brug for navnekonventioner): public BO.BOElement.Identification.Id Element_Id{ get{ return this.m_partyid; } set{ this.m_partyid = value; } } De fleste sådanne Element Properties har tilsvarende Element decorator klasser 38 (namespace FreeDesigner.UMLControls.Attribute.AttributeElement), som via reflection (BO.BoInfo) og navnekonventioner benyttes til at visualisere og validere et givent BO. 37 Således har Jamaica frameworket som nævnt et særligt konfigurationsobjekt (se 4.1.1.3.6) 38 Se kapitel 6.6.5, hvor strukturen forklares som Model-view-controller, der er en udvidelse af decorator pattern. - 49 -
Tekniske og teoretiske overvejelser Nedenfor ses, hvorledes den ovenstående Property Element_Id modsvares af klassen Id_Element, der dekorerer et Id Element med GUI logik ved at arve fra Attribute. public class Id_Element : FreeDesigner.UMLControls.Attribute.Attribute, IDisplayable{ Runtime søges dér via reflection efter disse overensstemmelser mellem BO og decorators (Element_Id Id_Element). Findes en sådan decorator Element klasse ikke, instantieres en default Element decorator klasse med en konstruktor, der tager en string parameter (Propertiens navn). Propertiens navn bliver dermed til Elementets titel (minus _Element ) og Elementet får samtidigt en enkelt propertyline, der kan rumme tekst. Proceduren i navnekonventionsmodellen var altså kort resumeret: En BO Type har et Element felt, der tilgås via en Property med teksten Element_ + navnet (Element_Id). Via reflection ledes efter en decorator klasse, der hedder navnet + _Element (Id_Element). Denne decorator klasse instantieres med Elementet som parameter (Elementet aggregeres dermed af decorator klassen). Disse decorator klasser implemeterer alle Interfacet IDisplayable, der ud over at fungere som marker interface 39 (denne klasse tjener til visning!) også kræver metoden validateattribute() implementeret 40. Denne metode melder tilbage, om et givent Element har en legal tilstand ud fra følgende enum: public enum validationstate{ ILLEGAL, NOTYETLEGAL, LEGAL } Det er op til den enkelte klasse at definere, hvad der skal lægges i disse begreber. Således var den første tilgangsvinkel at afkoble namespace BO fra GUI logikken. 6.3.1.2 Custom Attributes En alternativ løsning er den nuværende, der benytter Custom Attributes, som langt mere eksplicit kommunikerer, hvad det er der foregår og kræves. Denne ændring fra navnekonventioner til Custom Attributes skal basalt set forstås på baggrund af en ambition om at afprøve forskellige C# koncepter. 39 Marker interface : F.eks. som Javas Serializable interface, der ikke kræver nogen metoder implementeret. 40 Se også kapitel 5.4.1, hvor validering af Elementer diskuteres. - 50 -
Tekniske og teoretiske overvejelser Således er der lavet en klasse DecoratorAttribute, der arver fra.net klassen Attribute. En Custom Attribute specificerer Custom Attribute klassens lovlige brug. For Elementers vedkommende må Attributten kun benyttes på Properties (andre anvendelser vil give compiletime fejl): [AttributeUsage(AttributeTargets.Property, AllowMultiple = false, Inherited = true)] public class DecoratorAttribute : Attribute{ Custom Attribute klassen har bl.a. et felt (og en Property) af typen Type: public Type DecoratorClass{ get{ return this._decoratorclass; Dette felt sættes i konstruktoren, og en DecoratorAttribute kan nu benyttes som følger: [DecoratorAttribute(typeof(FreeDesigner.AttributeDecorators.DiscountDecorator))] public BO.BOElement.Pricing.Discount Discount{ get{ [...] Endnu en konstruktor er (via overloading) tilgængelig for Elementer der ikke har fået (måske ikke behøver) en speciel decorator klasse tilknyttet. Denne konstruktor tager en Type og tekstbeskrivelse som argumenter og bruges således: [DecoratorAttribute(typeof(FreeDesigner.AttributeDecorators.DefaultDecorator),"Party 1")] Tekst argumentet bliver til Elementets navn. At DecoratorAttribute tager en Type som parameter betyder, at der compiletime kan checkes for, om der faktisk er produceret en decorator for den givne Property, og effektiviteten bliver forøget, da der ikke længere skal laves pattern matching på navnene. Via reflection kan man få fat i disse Custom Attributes (getcustomattributes() i BO.BOInfo): PropertyInfo[] prop = type.getproperties();//få fat I klassens Properties foreach(propertyinfo p in prop){ object [] ob = p.getcustomattributes(true);// få fat I Propertiens Custom Attribute foreach(attribute t in ob){ - 51 -
Tekniske og teoretiske overvejelser DecoratorAttribute myattrib=t as DecoratorAttribute//cast til DecoratorAttribute Med typeinformationen fra DecoratorAttribute kan et Element nu instantieres (her en default decorator): Type ty = myattrib.decoratorclass; object[]arg = {myattrib.description}; Attribute attribute = (Attribute)Activator.CreateInstance(ty,arg); 6.3.1.3 Afkobling Det, jeg har søgt at opnå, var, at nye Element klasser kunne defineres, uden at der nødvendigvis skulle skrives kode for GUI logik eller kode til at linke BO klasser med GUI logik. Dette har jeg opnået ved en afkobling i tre lag: 1. elementer defineres særskilt og benyttes som Properties på BO er, 2. custom Attributes på Element Properties dirigerer visningen, 3. GUI klasser aggregerer og viser Elementerne. En ny BO klasse vil automatisk blive medtaget i modelleringsframworket blot ved sin tilstedeværelse i namespace hierarkiet under namespace BO. Typificering og farvekoder af disse BO er hviler udelukkende på reflection og deres placering i namespace hierarkiet ikke på Custom Attributes eller navnekonventioner. For at få medtaget et nyt Element på et BO skal dette først defineres og leve under namespace BO.BOElement. Endvidere skal der indsættes Properties for Elementet i de BO klasser, hvor det ønskes benyttet. En default decorator på disse Properties er nok til visningen af Elementet. Ønskes særlig funktionalitet, visning eller validering, skal en decorator klasse defineres og valideringsmetoden implementeres. I sidste instans er brugen af Custom Attributes ikke det, man stringent forstår ved løs kobling (ingen GUI logik sammenblandet med business logik). Udgaven, hvor jeg benyttede navnekonventioner, kunne siges at være afkoblet: De forskellige Properties, der skulle mediere Elementer, havde navnet _Element påhæftet, hvilket siger mere om deres funktion end om deres visningslogik. Decorator klasserne hed det samme blot med Element_ foranstillet. Denne model rummede øget risiko for fejl og havde ikke samme sikkerhed som brugen af Custom Attributes: compiletime checking af sammenhængen mellem BO og GUI. På trods af den løsere kobling mener jeg, at Custom Attribute løsningen er mere elegant end navnekonventionsløsningen. Ønskes ingen GUI logik eller visning for en Property, kan man helt undlade at benytte Custom Attributes ved den. Selvom en Custom Attribute er tilknyttet en Property, betyder det ikke, at man skal bruge den: compileren checker blot om decoratorklassen eksisterer, og gør den det, er alt fint. - 52 -
Tekniske og teoretiske overvejelser Custom Attributes fungerer altså som et middle teer, der uddelegerer visningsopgaven og GUI logik til andre klasser. De konkrete GUI klasser tager hver en speciel type Element som argument og dekorerer det ved at tilføje GUI- og modelleringslogik til Elementet. Dette middle teer medfører, at man kan skrive nye BO og Element klasser og straks få dem integreret i modelleringsframeworket blot ved f.eks. at angive en default decorator eller arve fra FreeDesigner.Attribute for at lave en særskilt GUI repræsentation og validering. Reflection bruges til at kitte de enkelte dele sammen. 6.4 Depack, XML og kodegenerering Jamaica frameworket benytter et specialiseret XML format Depack til at repræsentere en konfiguration. Dette filformat fungerer som input til en specialiseret kompiler, der genererer ASPX sider, SQL databaser mm., som bliver den samlede løsning, virksomheden i sidste instans kommer til at se og benytte. Det havde været ønskværdigt, om min løsning ligeledes kunne skrive Depack og derefter kompileres, men DTD en til formatet stiller krav, som kun kan honoreres, hvis man benytter rigtige Jamaica objekter og har fokuseret på at navngive og bruge typer lig dem, Jamaica bruger. På den baggrund har jeg lavet en lidt alternativ løsning, der har til formål at demonstrere, at min løsning kan bruges til at opnå det samme. Tilgangen har været, at objekter på forskellige niveauer selv ved, hvordan de skal skrive og læse XML (se nedenstående kodeeksempler samt Figur 30). BO er og Elementer har en writexml(xmltextwriter writer)metode, der tager en XmlTextWriter som argument og skriver objekt data som XML. Modsvarende gives også en XML konstruktor, der tager en XmlTextReader som argument, og som derfra kan læse og konstruere objekter på baggrund af det læste XML. public void writexml(system.xml.xmltextwriter _writer){ try{ _writer.writestartelement("attribute",this.atrributename); _writer.writeelementstring("color1a",this.attributecolor.a.tostring(); [ ] public Attribute(XmlTextReader reader):this(){ //XML contstructor reader.readstartelement("attribute"); this.atrributename = reader.namespaceuri.tostring(); if(reader.nodetype == XmlNodeType.Element){ reader.readstartelement("color1a"); int a = Convert.ToInt16(reader.ReadString()); reader.readendelement(); [ ] - 53 -
<?xml version="1.0" encoding="us-ascii"?> - <BusinessObjects> - <BusinessObject> <Name>Company</Name> <Type>BO.BOBase.BOType.Party.Company</Type> <ID>T0BTIXMI1</ID> <LocationX>203</LocationX> <LocationY>489</LocationY> + <Element xmlns="contact Person"> + <Element xmlns="compagny name"> + <Element xmlns="address"> + <Element xmlns="phone"> - <Element xmlns="id"> <COLOR1A>255</COLOR1A> <COLOR1R>0</COLOR1R> <COLOR1G>128</COLOR1G> <COLOR1B>128</COLOR1B> <propertyline>f0b4p4x4g1j7l7c</propertyline> </Element> - <Relation xmlns="salesorder (M)"> <IsMaster>True</IsMaster> <RelationFrom>T0BTIXMI1</RelationFrom> <RelationTo>ZTVF3AP56</RelationTo> <LineStartX>454</LineStartX> <LineStartY>697</LineStartY> <LineEndX>680</LineEndX> <LineEndY>704</LineEndY> <COLOR1A>255</COLOR1A> <COLOR1R>0</COLOR1R> <COLOR1G>0</COLOR1G> <COLOR1B>128</COLOR1B> </Relation> + <Relation xmlns="invoice (M)"> </BusinessObject> + <BusinessObject> + <BusinessObject> + <BusinessObject> </BusinessObjects> Figur 30. Mit XML ( Depack ) format Mit XML format indeholder en mængde farveinformation, som egentlig ikke behøvede at blive medtaget, da farveprofiler er knyttet til Baserne og kunne genskabes ud fra disse uden at nedskrive farveinformation i XML dokumentet. XML dokumentet kan parses og gives som input til min kodegenerator (ASPX_codeGenerator.cs), der ganske vist ikke laver ASPX sider, men blot dynamisk genererer en MessageBox med lidt information om BO erne i 54
Tekniske og teoretiske overvejelser løsningen (se Figur 31). Princippet er det samme. Når en konfiguration gemmes (som Depack XML), genereres en fuld klasse definition webpage.cs dynamisk (med XML filen som input) (genereres i mappen hvor FreeDesigner.exe køres fra), som dynamisk, runtime kompileres og køres, hvilket resulterer i en MessageBox med konfigurationsinformation. Metoden ASPX_codeGenerator.compileAndRun() står for dette skridt. Skulle jeg have genereret ASPX sider, ville det kræve, at en Microsoft IIS server kørte på den pågældende maskine og dermed også, at jeg skulle oprette et virtuelt webdirectory på serveren mm. Det væsentlige var at få afprøvet og demonstreret dynamisk kodegenerering, hvilket er gjort med den simple MessageBox som eksempel. Figur 31. Resultatet af den genererede kode, når den køres Skulle designet omkring BO erne og Elementernes runtime repræsentation implementeres, ville jeg vælge at gøre det på samme måde, som jeg har implementeret decorators for Elementer. Et Element ville således have en decorator, der stod for designtime visning og en decorator, der stod for runtime visning. Dette ville jeg lave vha. Interfaces, således at decorator klasser implementerede metoder som decoratedesigntime() og decorateruntime(), således at visningslogikken for hvert Element/BO var samlet et sted. Metoden decorateruntime() ville bestå i kodegenerering og kun blive kaldt, når den endelige løsning skulle genereres. XML formatet muliggør, at en løsning kan gemmes og hentes igen. Gemme funktionaliteten på BO er, Elementer samt Contained BO er er implementeret, hvorimod rekonstruktionen af Relationerne kun delvis er færdiggjort. Det ville kræve en lidt anderledes implementation af XML formatet (skrivning af alle Relationerne for sig og ikke indlejrede i de enkelte BO er). - 55 -
Tekniske og teoretiske overvejelser 6.4.1 Database Jeg har ikke brugt databaseteknologi i mit projekt, hvilket jeg ville have gjort, hvis jeg havde haft mere tid: Der er gået megen tid med at skrive og parse xml, og gevinsten ved formatet er ikke stor nok til at retfærdiggøre brugen af XML, der ikke er så effektivt og sikkert at bruge som en database, hvor der ikke er så meget indirection, som tilfældet er det med XML formatet. Databasen ville have været rar at have i forbindelse med persistering og kodegenerering, hvor jeg havde foretrukket inkrementalt at have vedligeholdt en database med alle konfigurationens objekter frem for at benytte parsning og skrivning af XML. Det havde ligeledes været mere effektivt i forhold til at føre statistik med løsningen (hvor mange BO er er der i konfigurationen, hvilke relationer er der), hvor jeg som løsningen er nu designtime parser Canvas objektet rekursivt, eller compiletime (når koden dynamisk skal genereres) parser XML filen. 6.5 Delegates og Events Delegates er en.net feature der minder om C++ function pointers. En delegate definrer en reference type, der kan bruges til at indkapsle en metode. Events i.net baserer sig på delegate modellen (der i øvrigt er en implementation af observer design pattern). I event kommunikation er problemstillingen den, at den klasse, der fyrer events, ikke ved, hvilket objekt eller metode, der kommer til at modtage og håndtere den fyrede event. Det, der er brug for, er et mellemled mellem kilden og modtageren, hvilket er en delegates funktion. Da jeg valgte at benytte UserControls som baseklasse for grafiske objekter, fulgte der automatisk en masse medfødte events med. I studieøjemed valgte jeg til trods for dette alligevel at implementere min egen event for dermed at stifte bekendtskab med konstruktionen af delegatemodellen (der ikke kun benyttes ved events). Brug af medfødte events En Relation har f.eks. (fordi det er en UserControl) en medfødt Click event, som man abonnerer på således: myrelation.click += new EventHandler(this.OnRelation_Click); Metoden OnRelation_Click skal blot defineres og have følgende signatur: protected void OnRelation_Click(object sender, EventArgs e){ Således sættes en event op i.net via delegate modellen, hvilket må siges at være simpelt og intuitivt. Definition af egne events At definere egne events er en del mere kompliceret end blot konsumere prædefinerede events. - 56 -
Tekniske og teoretiske overvejelser I Attribute.cs erklæres en event med det formål at håndtere eventen, at Elementet åbnes eller lukkes og dermed ændrer størrelse. public event ResizeDelegate resize; ResizeDelegate er erklæret udenfor klassens scope: public delegate void ResizeDelegate(object sender, ResizeEventArgs e); Denne delegate tager en ResizeEventArgs, der arver fra EventArgs og indeholder relevant information for det at klappe i og åbne op: public class ResizeEventArgs:EventArgs{ public ResizeOptions resizetype; //COLLAPSE or EXPAND (enum) public int dy; //the amount to collapse or expand } } public ResizeEventArgs(ResizeOptions type, int dy){ this.resizetype = type; this.dy = dy; } En metode håndterer det at fyre eventen og uddelegerer arbejdet: public void fireresizeevent(resizeeventargs e){ if(resize!= null){ resize(this,e); } } Ovenstående metode kaldes, når eventen fyres. Her f.eks. når alle Elementer skal klappes sammen: private void OnMenuItemCollapse_Click(object sender, EventArgs e){ foreach(attribute at in this.m_attributecollection){ if(at.isexpanded){ at.fireresizeevent(new ResizeEventArgs(ResizeOptions.COLAPSE,at.getHeightOfAllPropertyLines())); } } } Nu kan Elementer abonnere på denne event: ResizeDelegate del = new ResizeDelegate(this.resizeColapser); attribute.resize += del; og i metoden resizecolapser kan man nu selv definere, hvad der skal ske, når eventen fyres: private void resizecolapser(object sender, ResizeEventArgs e){ switch(e.resizetype){ - 57 -
Tekniske og teoretiske overvejelser I FreeDesigner er der ud over ovenstående delegate og event kun gjort brug af prædefinerede events for de forskellige UserControls. Det er min oplevelse, at denne eventmodel, i hvert fald i sin anvendelse, er væsentlig mere intuitiv og effektiv end f.eks. Javas brug af indre anonyme klasser som standard (Swing) event implementation med ActionListeners mm. Dette på trods af at det er samme design pattern, der ligger til grund for implementationen (Observer). 6.6 Design Patterns 6.6.1 Generelt Studiemæssigt var det ambitionen at implementere en mængde design patterns i den løsning, der skulle laves, og på den måde få opøvet en vis rutine inden for dette område. Jeg har implementeret nogle patterns, men ikke så mange, som jeg havde håbet på. I dette kapitel gennemgås kort, hvordan forskellige patterns er implementeret, og der afsluttes med en konklusion på oplevelsen af dette. 6.6.2 Singleton pattern Entry.cs: Selve hovedapplikationen er implementeret som en Singleton, da jeg vurderede, at det ikke gav mening at køre flere konfigurationsapplikationer på én gang. På denne måde bliver det væsentligt nemmere at tilgå de rette instanser af statuspaneler, Canvas mm. CommandBroker.cs: CommandBroker er ligeledes implementeret som Singleton, og alle commands, undo/redo funktionalitet går igennem denne centrale instans. Implementationen af Singleton følger følgende mønster i C#: Klassen har en private konstruktor og et private readonly instansfelt. En static Property benyttes til at give public acces til instansen.: private static readonly CommandBroker instance = new CommandBroker(); private CommandBroker(){ this.undolist = new System.Collections.Stack(); this.redolist = new System.Collections.Stack(); } public static CommandBroker Instance { get { return instance; } } 6.6.3 Command pattern Alle commands implementer ICommand, der deklarerer to metoder: execute() og unexecute(). Alle commands kaldes gennem CommandBroker (en - 58 -
Tekniske og teoretiske overvejelser Singleton), der består af en undo og en redo Stack. Jeg ville gerne have lavet en visualisering af stakken for derved at muliggøre multipel undo/redo funtionalitet ved at arve fra MenuItem og lave en specialiseret løsning på dette, men en sådan løsning kunne ikke holdes inden for specialets tidsmæssige rammer. At integrere redo funktionalitet kunne være en ret tidskonsumerende opgave, og den er ikke implementeret 100% konsekvent, selvom det meste er omfattet. 6.6.4 Decorator pattern Canvas.cs: Canvas kan dekoreres med forskellige klasser, hvis formål er at optegne grid. Decorators implementer interfacet IGrid, hvor forskellig fælles Grid funktionalitet er deklareret (f.eks. Properties som GridColor, GridSpacing m.fl.). class Canvas har en reference til klassen GridConfigDecorator, der i sin Paint metode vælger den rette decorator ud fra værdien af en enum (public enum Grids {None=0,Lined=1,Dotted=2};) deklareret i Canvas. class Canvas har endvidere en reference til GridValues, der er en Struct, der benyttes til at opbevare brugerens valgte gridværdier. Klassen GridConfig tilbyder et bruger interface til at konfigurere disse værdier, der skrives til Windows Registry, hvis de ændres. Denne arkitektur kan også anskues ud fra paradigmet Model-View-Controller: Model udgøres af GridConfigDecorator, struct og enum, View udgøres af GridConfig, Control er lagt ud til CanvasForm. CanvasForm.cs: CanvasForm dekorerer Canvas med stort set enhver GUI funktionalitet, events mm., som ret beset ikke hører hjemme i Canvas. Retrospektivt mener jeg, at Model-View-Controller mønstret burde være implementeret over denne struktur, således at Controller laget var separeret ud i et særligt lag (nu er det kun separeret i Model og View). En stor del af kontrollogikken fra Canvas er uheldigvis spredt ud over et par klasser, hvilket ikke er særligt hensigtsmæssigt. En refactoring proces ville relativt simpelt kunne ordne dette, da event logikken er let genkendelig i event metoder (delegates), der følger standard C# navnekonvention om at sætte On (med stort O ) på metodenavnet, således at de alle hedder noget med OnCanvas... 6.6.5 Model-View-Controller pattern Model: Namespace BO er et godt eksempel på modellen, der indkapsler business logik. I dette namespace er der ingen GUI logik. View: Decorators benyttes til at visualisere BO typerne og de forskellige Elementer eksponeret via public Properties. Controller: Custom Attributes kontrollerer, hvordan et Element dekoreres. En del kontrol er lagt i BOInfo.cs, der via reflection holder styr på, hvilke objekter der instantieres. - 59 -
Tekniske og teoretiske overvejelser 6.6.6 Observer pattern Observer pattern blev i særlig grad benyttet, da jeg brugte toolbars mm. (GUI komponenterne er nu fjernet fra FreeDesigner). Jeg havde en toolbar, der afhængigt at brugerens valg på Canvas kunne opdatere sig og kun vise de for det valgte objekt relevante konfigurationsobjekter. Interfacet IToolbarObserver deklarerede eksempelvis metoden update(). Toolbar havde metoder til at attache og detache observers samt en metode notifyobservers(), der ved relevant tilstandsforandring (ved valg på Canvas) kaldte notify() på hver enkelt observer der kunne opdatere sig i overenstemmelse med tilstandsforandringen. Når et BO i FreeDesigner skifter navn og/eller type (typeskift er en mulighed, der hidrører fra en tidligere implementation af BO er, hvor man først skabte et generisk BO og derefter typificerede det (dette er af demonstrationsmæssige grunde stadig muligt, når man relaterer til et nyt genrisk BO ), abonnerer de BO er, der er relateret til dette BO, på den event, at BO et ændrer navn og/eller type, således at Relationselementets navn og af type afhængig farvekode kan opdateres til at afspejle det nye navn og/eller type. 6.6.7 Relevante patterns jeg ikke fik implementeret Der er flere relevante patterns, der med fordel kunne implementeres i FreeDesigner for at opnå et mere solidt design. I det følgende vil jeg kort beskrive de to mest relevante, som jeg ikke implementerede. 6.6.7.1 Abstract Factory Jeg kunne med fordel have implementeret dette pattern og ladet BO ernes Base type bestemme, hvorledes BO er og med hvilke parametre de skulle skabes. Arketype eksemplet fra GoF (se [19], s. 87) går jo på instantiering af forskellige GUI komponenter afhængigt af kontekst, og da FreeDesigner i høj grad udgøres af GUI komponenter, ville det have været oplagt at benytte dette pattern. 6.6.7.2 Composite Da et BO er komponeret af beholdere i beholdere, kunne Composite pattern gøre designet omkring dette forhold bedre. De enkelte dele af kompositionen kan i de fleste tilfælde behandles ens (funktionalitet som luk op og klap i, dekorer m.fl. kunne deklareres i Component interfacet ([19], s. 164). Metoden Operation i Composite, der itererer over alle children og kalder Operation på dem, er i FreeDesigner implementeret efter samme mønster, hvor et BO f.eks. refresher sig selv ved at kalde refresh på sig selv og alle children, der igen kalder refresh videre ned i hierarkiet. Interfacet IExpandable er der flere af GUI komponenterne i FreeDesigner, der implementerer, men der gøres aldrig brug af den funktionalitet, som dette pattern tilbyder. Dvs. foreach statements itererer over først den ene type, dernæst den næste type osv. i stedet for at itererere over typen IExpandable. - 60 -
Tekniske og teoretiske overvejelser XML persistering og objekt konstruktion fra XML kunne ligeledes med fordel drage nytte af dette pattern, og det er da også tæt på, at det er fuldt ud implementeret. Det, der mangler, er deklarationen af interfacet, der tillader alle implementerende typer at blive behandlet ens. Alle de enkelte komponenter implementerer de samme metoder: writexml(), readxml() (implementeret som konstruktorer) og foretager kald til samme metoder på sine children, så det ville kræve ganske lidt at implementere dette pattern fuldt ud i denne sammenhæng. 6.6.8 Opsummering Det kan være vanskeligt at implementere design patterns, når man følger en udviklingskurve som den, jeg har fulgt, idet denne kurve i høj grad har været af eksploration og eksperimenteren. F.eks. lå fokus for Elementernes vedkommende på at lave transparens, således at deres form kunne blive afrundet og på at bryde objekternes naturlige grænser (i henseende til Relationer, der stikker ud) Efterhånden som disse ambitioner indfries, bliver koden til, kode, der ikke har haft mønstre for øje. Først herefter og for sent tænkte jeg på patterns og integration med eksisterende kode, hvilket burde have fundet sted forinden. Design patterns kræver grundig analyse (use cases, class mining osv.) af hele domænet samt den overordnede løsning. Nu, hvor alle klasser er defineret, og jeg har en funktionel prototype, burde hele systemet og designet refaktoreres. I denne proces burde design patterns inkorporeres mere effektivt, så designet blev så optimalt som muligt. Design patterns kræver, at der foreligger materiale i form af klasser, use cases e. lign. Uden dette vil implementationen af patterns være inkonsekvent og tilfældig. Givet en længere specialeskrivningsperiode, og var der ikke kun tale om en prototype, ville jeg med fordel have kunnet refaktorere det hele på et mere solidt grundlag, nu hvor jeg ved, hvad der skal til for at få maskineriet til at køre. - 61 -
7 Evaluering af FreeDesigner FreeDesigner er en fungerende prototype, der i sin enkelhed demonstrerer de ideer jeg havde omkring grafisk repræsentation og manipulation. Al manipulation foregår i FreeDesigner via kontekstmenuer uden nogen som helst brug af propertybox e.lign. Farvekoder er implementeret, således at der opnås større overblik over en konfiguration, Containment er visualiseret osv. Basalt set demonstrerer FreeDesigner, at mine ideer er holdbare og kan føres ud i livet. På dette grundlag er jeg tilfreds med FreeDesigner. 7.1 Mangler og forbedringer Som tidligere nævnt har jeg ikke implementeret alle aspekter af Navisions Jamaica system, da dette er en alt for omfangsrig opgave for en person at give sig i lag med, og ikke alle aspekter af frameworket har lige stor relevans for min problemstilling. I det efterfølgende vil jeg kort gøre opmærksom på nogle relevante mangler ved FreeDesigner samt visse features, som det ville have været godt at få implementeret. Grunden til, at disse mangler ikke allerede er blevet udbedret eller implementeret, er simpelthen for kort en specialetidsramme og opprioritering af andre problemstilinger. Flytning af BO er: Det ville det have været fint at have implementeret cut-n-paste funktionalitet. Cut-n-paste ville kunne implementeres meget nemt, da det i virkeligheden er baseret på samme teknologi som drag-n-drop. Ikoner: Ikoner på Elementer og BO er i henholdsvis kontekstmenuerne og på selve objekterne ville have understøttet konfigurationsprocessen positivt, idet de enkelte forskellige metatyper og Elementer blev lettere at lokalisere. F.eks. ville metatypen LineItem BO vise en streg, metatypen Company BO en fabrik osv. Zoom: En faktor zoom burde have været medtaget i alle grafiske klasser og på alle grafiske elementer, således at man kunne zoome ind og ud overalt og dermed i størrere udstrækning end det nu er muligt demonstrere løsningens overskuelighed. Runtime environment: Min fokus har primært været rettet mod design og konfiguration af designtime elementer. Kodegenerering og de tiltag, der skal til for at få en runtimeversion (ASPX) til at hænge sammen (Views, Task, Activity center m.fl. 41 ), har jeg ikke implementeret, hvilket selvfølgelig havde været ønskværdigt. 41 Det ikke implementerede er: View, Task, Activity Center, User Role, Action, Field, Event, Method, Key, Dependency og Event wire 62
Evaluering af FreeDesigner Tråde: Jeg har ved små eksperimenter forsøgt at implementere tråde de steder, hvor der laves layout, og hvor grafisk tunge objekter skabes, hvilket sætter farten væsentligt op. Til gengæld fremkommer der adskillige nye problemstillinger for hver enkelt optimering. Trådmodellen er relativt kompliceret (f.eks. kan en Control skabt af én tråd ikke få en Control skabt af en anden tråd som Parent) og ville kræve et mindre studie af trådprogrammering og en god portion refaktorering af min kode, hvilket jeg har nedprioriteret, fordi tråde i virkeligheden burde være medtænkt fra begyndelsen, og fordi FreeDesigner demonstrerer sine styrker og svagheder uden. Graphdrawing: Relationerne i FreeDesigner bliver forbundet med en linje direkte fra en Relation til en anden. Der findes forskellige løsninger til at gøre dette pænere (f.eks. med vertex punkter) således at modellens overskuelighed bliver bedre. Jeg har i den forbindelse kigget på Graphdrawing og de forskellige muligheder for at implementere forskellige path algoritmer i FreeDesigner, men har i sidste ende nedprioriteret implementationen af dette til fordel for løsningen af andre problemstillinger. Containment: Containment metaforen benyttes oftest i forbindelse med LineItems, der f.eks. er indeholdt i et Contract BO. Det ville være rart at have en genvej til instantiering af denne type Containment. En knap ( Make contained ) og en dropdown menu med de mulige emner, der kunne indeholdes i Containment, kunne fungere som genvej til instantiering af Contained BO er inde i Containment beholderen, således at man ikke først behøver at instantiere BO et uden for beholderen og derefter trække det ind i den (således var det også oprindeligt tænkt (bilag [1]), s. 5, figur 3). - 63 -
8 Lignende løsninger 8.1 Mjølner, AST og IP I mit forberedende 4-ugers projekt så jeg på det Nordiske Mjølner projekt [5]. Mjølner projektet har været nytænkende inden for mange områder, herunder grafisk repræsentation (se Figur 21). Særligt beskæftigede jeg mig i den forbindelse med grammatikker ([10], s.11) og abstrakte syntakstræer (AST), som i Mjølner benyttes som fælles programrepræsentation, således at et Beta program f.eks. internt er repræsenteret af et AST og ud af til f.eks. et UML diagram, der er et prettyprint af dette AST. Ligeledes har jeg efterfølgende læst om Intentional Programming (IP) og en implementation af dette paradigme ([1], kapitel 11), der i høj grad baserer sig på AST. AST er velegnet til tekstuel repræsentation, men mindre velegnet i forbindelse med grafisk repræsentation. Både Mjølner og Microsoft har tilsyneladende haft succes med implementationen af AST i forbindelse med grafisk repræsentation (prettyprints og intentions (se bilag [1], kapitel 4)). Havde AST været benyttet som grundlaget for FreeDesigner, havde jeg i hermed fået både validering af modellen (grammatikbaseret) og et persistens format (som i Mjølner). Visning ville være et spørgsmål om at parse dette AST og ellers vise det på samme måde, som det gøres i FreeDesigner som et prettyprint af træstrukturen. Da den bagvedliggende programrepræsentation ikke er dette speciales primære problemområde, og et andet Next-projekt samtidig beskæftigede sig med en sprogliggørelse af Jamaica frameworket 42, der måske ville benytte AST, ønskede jeg ikke bruge for meget tid på dette felt, idet repræsentationen i sidste instans ville afhænge af dette projekts resultater. 8.2 Naked objects Naked Objects er et open source Java-baseret framework 43, som tilbyder et 100% autogenereret grafisk bruger interface, hvor udvikleren kun behøver at fokusere på de centrale business objekter og metoderne, der skal kunne operere på disse. Jeg har i sammenlignings øjemed lavet en test applikation med et par BO er og har i den forbindelse fundet en mængde lighedspunkter mellem FreeDesigner og Naked Objects: Begge undlader at benytte centraliserede menuer eller dialog bokse Begge udstiller BO er som førsteklasses grafiske entiteter. I Naked Objects som JFrames, i FreeDesigner som UserControls Begge lader al konfiguration foregå på BO erne selv og ikke i propertyboxe Begge benytter kontekstmenuer i konfigurationsøjemed (I Naked Objects tilfælde for f.eks. at kunne kalde metoder på BO erne) 42 Dette projekt er siden hen gået i opløsning, og dets fokus er ændret. 43 http://www.nakedobjects.org 64
Lignende løsninger Begge benytter Drag-n-drop af BO er i relationsøjemed (Naked Objects f.eks. for at forme associationer, FreeDesigner i Containment øjemed). Naked Objects handler ikke som FreeDesigner om grafisk konfiguration af foruddefinerede metatyper, der efter konfiguration kommer til at udgøre en domænespecifik løsning. Naked Objects tillader brugeren at koncentrere sig om business logikken. GUI en får man forærende blot ved at arve fra AbstractNakedObject, der runtime udgør selve løsningen. Denne GUI og de træk, der er karakteristiske for GUI logikken er, hvad Naked Objects primært har til fælles med FreeDesigner. En Naked Object applikation har en centraliseret toolbar indeholdende alle løsningens mulige BO er, der vises med forskellige ikoner, som via navnekonvention er knyttet til et BO (Der produceres to ikoner med størrelserne 16*16 og 32*32 pixels til repræsentation af BO et på henholdsvis toolbaren og det instantierede BO. Ikonerne skal ligge i en mappe images og skal hedde det samme som BO et med strengen 16 og 32 påhæftet. Frameworket finder derefter selv ud af at linke BO og icon sammen og kaster en Exception, hvis man ikke har defineret begge ikoner). Når en Løsning er lavet, består brugerens handlinger i at kalde metoder på BO erne, der er tilgængelige i kontekstmenuer og udføre drag-n-drop f.eks. for at lave associationer. Figur 32. Naked Objects test implementation - 65 -
Lignende løsninger Ønsker man i Naked Objects, at et BO skal kunne indeholde andre BO er (Containment), kan dette gøres ved at udstyre BO klassen med en specialiseret InternalCollection, der er specialiseret til at indeholde objekter af typen BO (se nedenstående klasse fragment). Yderligere skal der defineres en metode med en speciel signatur: public <Type> actionadd<name> public class BO extends AbstractNakedObject { private final InternalCollection _containedlist = new InternalCollection(BO.class, this); public BO actionaddcontained() { BO con = (BO)createInstance(BO.class); this._containedlist.add(con); con.getcontained().add(this); return con; } Jeg fandt det relativt nemt at lave ovenstående lille applikation. Frameworket var veldokumenteret, og mulighederne så ud til at være rige. Idéen om at lægge konfigurationen af BO er på objektet selv,synes jeg selvsagt er god. Et negativ forhold er, at Naked Objects har valgt, at alle BO er skal fremstilles som JFrames, der instantieres direkte på brugerens skrivebord, hvilket efter min mening kommer til at virke uoverskueligt, hvis man har ikoner på sit skrivebord eller andre applikationer åbne. Hvert nyt BO får sin egen tab på applikationsbaren (dér hvor minimerede applikationer ligger). Det havde efter min mening været en bedre løsning at implementere en applikation med et JDesktopPane og lade BO erne være JInternalFrames på dette. Endvidere finder jeg, at JFrames ikke er velegnet i forhold til illustration af relationer. Relationer indlejrede i BO erne kan dog ved dobbeltklik åbne det objekt, der er relateret til i en ny JFrame, men jeg synes ikke, det understøtter relationsmetaforen særlig godt. - 66 -
9 Konklusion Hovedformålet med produktionen af prototypen FreeDesigner var overordnet set at give mit bud på, hvordan man kunne modellere Navisions ERP løsninger grafisk med udgangspunkt i Jamaica Frameworket. Dette er gjort vha. en UML inspireret tilgangsvinkel til grafisk fremstilling, der som udgangspunkt benytter UML s velkendte grafiske metaforer med kasser og relationer. Modellen er blevet udvidet, således at f.eks. dokumentation ligger på objekterne selv, og Containment kan visualiseres som de facto Contained. De efterfølgende konklusioner hviler på de i kapitel 5 omtalte problemstillinger omkring Jamaica frameworkets konfigurationsmodel og kan læses i sammenhæng med og som svar på disse. Overblik over løsningen var en central problemstilling, der skulle håndteres. Dette er søgt opnået på forskellige fronter: 1. Modelleringsfladen er fuldstændig fri for forstyrrende elementer såsom propertybox, paneler, toolbars m.fl., således at modellen altid er i fokus og har god plads. 2. Farvekoder svarende til baser (eller UML stereotyper) bevirker, at de enkelte dele i modellen er hurtige at identificere og lettere at skelne fra hinanden. 3. En mininavigationsmodel giver overblik over løsningen samt rig information om de enkelte BO er (når musen hænger over et mini BO), uden at de først behøver at vælges e. lign. Denne minimodel benyttes endvidere i navigationsøjemed. 4. Menupunkter har fået funktionalitet, der tillader hurtig navigation til et specifikt BO og i forbindelse med Relationer viser og vælger det BO, man måtte være i færd med at relatere til. 5. Et BO består af beholdere til henholdsvis Elementer, Relationer og Containment, hvilket letter identifikationen af de enkelte dele og typer i BO et. 6. Et BO rummer mulighed for på forskellige niveauer at få et mere eller mindre finkornet view på BO et, hvis bestanddele kan åbnes og lukkes på en sådan måde, at skjult information stadig er tilgængelig via tooltips, uden at man behøver at åbne BO et). 7. Dokumentation på BO et selv styrker overblikket, idet den ikke står i notesform som særskilt element (dikteret af UML standarden) og dermed forstyrrer overblikket over de egentlige elementer i løsningen. Det var centralt, at FreeDesigner blev en løsning hvor det var nemt at navigere mellem de forskellige elementer, der måtte indgå i en konfiguration. Navigation er befordret via ovennævnte mininavigationsmodel samt kontekstmenuer på Relationer, der giver mulighed for hurtigt at navigere til Relationens modpart (kontekstmenupunkt Go to peer ). Denne funktionalitet 67
Konklusion opnås dog lettere ved blot at klikke på Relationen, hvorefter der straks navigeres til dennes modpart. Kontekstmenuer på Canvas tilbyder ligeledes at navigere til et eksisterende BO via dets navn og/eller id. Særligt vigtigt var det at fremstille Relationer og Containment på en identificerbar og overskuelig måde, så det var nemt at se, hvad der var hvad. Implementationen af Containment i FreeDesigner giver et 1:1 forhold mellem semantik og fremstilling. Et BO er de facto indeholdt i et andet, og sådan fremstilles det. Muligheden for at folde ting sammen på forskellige niveauer bevirker, at de indeholdte BO er ikke behøver at fylde meget og dermed gøre det indeholdende BO for stort: Hvis Containment beholderen lukkes, fylder de intet udover, hvad BO et med Master rolle fylder. Den (af mig) anbefalede måde at modellere på er først at modellere BO et tiltænkt Containment og derefter trække det færdigkonfigurerede BO ind i Containment boksen, hvor man bør minimere det eller lukke beholderen af pladshensyn (konfiguration kan ligeledes foregå i Containment). Relationer har som Containment og Elementer sin egen beholder, hvilket gør det let og hurtigt at se, hvilke Relationer et BO har. Når Relations beholderen er åben, stikker Relationerne ud over BO ets kant, hvilket understreger deres intentionalitet i forhold til andre dele af modellen og endvidere bevirker, at en Relation er meget nem at identificere. Påtegnede symboler vidner om Relationens rolle (som Master eller Detail), og Relationens farvekode giver endvidere et hint, om hvilken Base type BO, der er relateret til. Implementationen af en model, hvor al funktionalitet ligger på objekterne demonstrerer, at en propertybox ikke er nødvendig, og at objekter og deres properties lader sig konfigurere uden en sådan box. Jeg har ikke postuleret, at dette gør sig gældende for alle modeller, men at det i Navisions domænespecifikke system lader sig gøre og ligefrem er ønskværdigt for at holde fokus på det centrale i modelleringsprocessen: Modellen. Min studiemæssige ambition om at lære.net platformen og C# at kende er til fulde opfyldt, og i det hele taget har jeg i FreeDesigner skrevet flere linjer kode end nogen sinde før, hvilket for mig er en værdifuld sidegevinst (ca. 18.000 linjer [se Figur 33] (flere end nedenstående figur vidner om, da GUI bibliotek (Toolbars o.lign.), den integrerede løsning samt Naked Object modellen mm. ikke er medregnet). - 68 -
Konklusion Figur 33. Antal linjer kodet i FreeDesigner Ligeledes var det en studiemæssig ambition at implementere design patterns, hvilket ikke blev gjort i den udstrækning, jeg havde håbet på. Da min kodning indledningsvist var eksplorativ i henseende til konkrete løsningsmodeller på forskellige kodemæssige problemstillinger, faldt design patterns ofte i baggrunden, og koden burde afslutningsvis refaktoreres, hvilket jeg gerne ville have haft tid til at gøre. Abstract factory ville være det første og mest oplagte pattern, jeg ville implementere. Det grafiske udtryk, som FreeDesigner udviser, er på én gang et forslag til, hvordan UML kan gøres mere tidsvarrende og smart og demonstrerer samtidig, at farver kombineret med UML i væsentlig grad kan være med til at forbedre overblikket over (navnlig større) løsninger. Jeg mener, at UML editorer generelt ville kunne drage nytte af flere af de idéer, der er implementeret i FreeDesigner, herunder dokumentation på objekterne selv, øget mulighed for redigering på objekterne selv, tydeligere markering af relationers rolle i begge ender, brugen af kontekstmenuer til hurtig instantiering/manipulation, hvorimod Containment metaforen - som anskueliggjort af FreeDesigner - ikke så entydigt ville være gavnlig for UML editorer. idet disse i højere grad har brug for at signalere separation of concerns. Overordnet set mener jeg, at FreeDesigner er et godt bud på, hvordan man kan lave visuel konfiguration af ERP systemer. Jeg mener, at FreeDesigner løser de i indledningen identificerede problemstillinger omkring overskuelighed, identifikation af konfigurationens enkelte elementer og - 69 -
Konklusion manglende overensstemmelse mellem semantik og repræsentation. Min overordnede fornemmelse af, at konfigurationen kunne foretages smartere end den er blevet det, i Jamaica designeren, er bekræftet, selvom FreeDesigner blot er en prototype og et konceptuelt bevis på visuel konfiguration. - 70 -
10Referencer [1] Krzysztof Czarnecki, Ulrich W. Eisenecker, Generative Programming: Methods,Tools, and Applications, 2000 [2] John Brockman, "Intentional Programming" A Talk With Charles Simonyi. Interview available at http://www.edge.org/digerati/simonyi/simonyi_p1.html [3] Oege de Moor. Intentional Programming. Talk given at British Computer Society, Advanced Programming Specialist Group. Available as http://wwwinst.eecs.berkeley.edu/~maratb/slides/bcs.pdf [4] Visual Paradigm: (java CASE tool) Downloades fra http://www.visualparadigm.com/ Halo elementet findes også i Poseidon for UML og kan downloades fra http://www.gentleware.com/ - begge er kommercialiserede produkter der stammer fra open source projektet ArgoUML (http://sourceforge.net/projects/argouml/ ) [5] J. Lindskov Knudsen, M. Lofgren, O. Lehrmann Madsen. B. Magnusson (Eds.), Object-Oriented Environments - The Mjølner Approach, Prentice Hall, 1993, Yderligere information: http://www.mjolner.com/index_en.php - TheMjolner System kan downloades fra http://www.mjolner.com/mjolnersystem/download_en.php [6] Damm, C.H., Hansen, K.M., Thomsen, M., Tyrsted, M. Tool Integration: Experiences and Issues in Using XMI and Component Technology. Proceedings of TOOLS Europe 2000. Mont St Michel & St Malo, France, June 5-8, 2000. [7] Jesper Linvald and Kasper Østerbye, UML in an ERP environment, presented at OOPSLA 2002 Workshop on Domain specific visual languages in the proceedings of the second Domain-specific modelling languages workshop at OOPSLA 2002 (Seattle), p. 95-104 (Vedlagt som bilag [1]). [8] Tiina Siltamies og Helle Sørensen, 4 ugersraport, IT-Højskolen, 2001 [9] Powerpoint præsentation fra Navision (ikke udgivet) [10] Jesper Linvald, 4-ugers rapport, IT-Højskolen, 2002 [11] OMG UML 1.4, OMG Unified Modeling Language Specification, http://cgi.omg.org/docs/formal/01-09-67.pdf - (OCL specification i kapitel 6) [12] Preface til Workshop om Domain Specific Visual Languages, http://www.cis.uab.edu/info/oopsla-dsvl2/papers/preface.pdf [13] Java Modeling in Color with UML: Enterprise Components and process, Coad P., Lefebvre E., De Luca J., Yourdon Press, Prentice Hall, 1999 71
Referencer [14] Navision, Technical Information, Registration and OLAP - Version 1.0 [15] Navision, Jamaica Framework Design Version 0.9, Juni 2001 [16] Christian Heide Damm, Klaus Marius Hansen, Michael Thomsen, Michael Tyrsted, COT/2-49-V1.0 (Center for Object Technology), Tool Integration: Experiences and Issues in Using XMI and Component Technology, 25/4-2000, kan ses på http://www.cit.dk/cot/reports/reports/case2/49/cot-2-49.pdf [17] Workshop on Domain Specific Visual Languages, http://www.cis.uab.edu/info/oopsla-dsvl2/, OOPSLA 2002 [18] C# Language specification, final draft October 2002, Produced by ECMA TC39/TG2 [19] E. Gamma, R. Helm, R. Johnson, J. Vlissedes, Design Patterns - Elements of Reusable Object Oriented Software, Addison Wesley, 1995. - 72 -
Figur oversigt 11Figur oversigt Figur 1. Model for arkitektur og hvad der sker ved kompilation [9]...8 Figur 2. Objektmodellen...9 Figur 3. Element base med Total og Detail repræsentation [14]...11 Figur 4. Navisions integrerede Visual Studio.NET løsning...14 Figur 5. Intern Visual Studio.NET løsning....18 Figur 6. Bart konfigurationskanvas med tilhørende kontekstmenuer...19 Figur 7. Grid konfigurations dialogbox...20 Figur 8. Dokumentation på objektet selv...21 Figur 9. Dokumentation i Poseidon for UML...22 Figur 10. Halo element omkring et objekt (Visual Paradigm)...22 Figur 11. View funktionalitet på alle niveauer...25 Figur 12. Forkortet notation fra Together...25 Figur 13. Discount ikke valgt = invalid (rød farve)...27 Figur 14. Discount type valgt = valid (normal farve)...27 Figur 15. Validering af tinput: state = NOTYETLEGAL (gul farve)...28 Figur 16. Validering af input: state = ILLEGAL (rød farve)...28 Figur 17. Validering af input: state = LEGAL (grøn farve)...28 Figur 18. Relate to BO kontekst menu...30 Figur 19. Relate to existing kontekstmenu...31 Figur 20. Hurtig navigation mellem relationer ( Go to peer )....32 Figur 21. Mjølners priknotation for selektiv model information...33 Figur 22. Containment i stor dybde...34 Figur 23. Mulige relationestyper bestående af Master/Detail Element par35 Figur 24. Konfiguration af farveprofiler...37 Figur 25. Statusbar med konfigurationsinformation...39 Figur 26. MiniCanvas...39 Figur 27. Navigation via MenuItem...41 Figur 28. Typificerede menuitems et item har en BO Type....42 Figur 29. Tooltip tekst, for BO (tv.) og Elements (th.)...43 Figur 30. Mit XML ( Depack ) format...54 Figur 31. Resultatet af den genererede kode, når den køres...55 Figur 32. Naked Objects test implementation...65 Figur 33. Antal linjer kodet i FreeDesigner...69 12 Bilag [1] Jesper Linvald and Kasper Østerbye, UML in an ERP environment, presented at OOPSLA 2002 Workshop on Domain specific visual languages in the proceedings of the second Domain-specific modelling languages workshop at OOPSLA 2002 (Seattle), p. 95-1 - 73 -
74