1 INDHOLDSFORTEGNELSE SAMMENFATNING OG BIDRAG INDLEDNING PROBLEMFORMULERING METODE Prototypeudvikling...

Transkript

1 1 1

2 1 Indholdsfortegnelse 1 INDHOLDSFORTEGNELSE SAMMENFATNING OG BIDRAG INDLEDNING PROBLEMFORMULERING METODE Prototypeudvikling BAGGRUND (DET EKSISTERENDE FRAMEWORK) JAMAICA OG DESIGNEREN Den domænespecifikke objekt model Business Objects Elementer Registration og Family Containment og Relation Andre relevante abstraktioner View Task Activity Center og User Role Event Method Configuration Den nuværende konfigurationsmodel og dens problemstillinger DESIGN OG IMPLEMENTATION AF FREEDESIGNER VISUAL STUDIO.NET DESIGN TIME MODELLERING VS. FREEDESIGNER OBJEKTAFHÆNGIG FUNKTIONALITET Canvas Dokumentation Halo metafor BUSINESS OBJEKTER Generisk BO vs. typificeret Flytning af BO er via drag-n-drop Forskellige views på et Business Object ELEMENTER Validering Stoplys metafor RELATIONER Master/Detail Relate to BO Relate to exisisting Navigation CONTAINMENT Hvorfor speciel visualisering af Containment og Relation? ALIASING OVERBLIK OG MODELNAVIGATION UML in Color Teksturer Statusbar

3 Indholdsfortegnelse MiniCanvas Navigation via MenuItem Subclassing MenuItem ToolTip information Modellayout TEKNISKE OG TEORETISKE OVERVEJELSER HVORFOR IKKE BARE TRADITIONEL UML? OMG s UML vs FreeDesigner UML profile OCL Domæne specifikke visuelle sprog (DSVL) USERCONTROLS VS. SHAPES C# PROPERTIES SOM KONFIGURATIONSSKABELON Navnekonventioner vs. Custom attributes Navnekonvention Custom Attributes Afkobling DEPACK, XML OG KODEGENERERING Database DELEGATES OG EVENTS DESIGN PATTERNS Generelt Singleton pattern Command pattern Decorator pattern Model-View-Controller pattern Observer pattern Relevante patterns jeg ikke fik implementeret Abstract Factory Composite Opsummering EVALUERING AF FREEDESIGNER MANGLER OG FORBEDRINGER LIGNENDE LØSNINGER MJØLNER, AST OG IP NAKED OBJECTS KONKLUSION REFERENCER FIGUR OVERSIGT BILAG

4 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 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 ( 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

5 Sammenfatning og bidrag metamodeller generelt,.net/c# s grafiske udtryksmuligheder (GDI+) samt GUI design

6 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

7 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 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

8 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 , 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 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

9 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] 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 -

10 Baggrund (det eksisterende framework) har implementeret i prototypen FreeDesigner. Abstraktioner som Activity center, Task m.fl. har jeg udeladt 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 -

11 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 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) Contract handler om aftaler mellem Parties. F.eks. købs- og salgsordrer, som er opbygget af LineItems 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 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 ). 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

12 Baggrund (det eksisterende framework) svarer til den konkrete virksomheds behov og krav. Dette skridt kaldes konfiguration 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

13 Baggrund (det eksisterende framework) 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 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 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 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 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

14 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 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 Method En Metode (Method) manipulerer BO er og Elementer og er en procedure, der kan udføres på disse. Metoder kan fyre Events 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)

15 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 )) 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

16 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

17 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.)

18 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

19 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å

20 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 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