Editor til brugergrænseflade i C# WPF

Frans Saxbeck Larsen

Kongens Lyngby IMM-B.Eng-2008-51

ii

Technical University of Denmark Informatics and Mathematical Modelling Building 321, DK-2800 Kongens Lyngby, Denmark Phone +45 45253351, Fax +45 45882673 reception@imm.dtu.dk www.imm.dtu.dk

IMM-B.Eng-2008-51

iii

Abstract

For supervision of a cement factory a 2D SCADA application is used, which displays static a dynamic representations of materiel on the facility. The graphical interface for this application is created by an operator, through the use of an editor. Switching to C# and Windows Presentation Foundation, a new editor must be available to the operator.

The FLSmidths SCADA Supervision application ECS/ControlCenter for cement and minerals factories, which are to be updated to correspond to the new technologies, must now include a simple new editor. Therefore, an analysis is made, including the definition of a simple editor, how to improve the user interface, and which of this kind of editor is currently available. It is then decided if such an editor can be used for this purpose, as opposed to developing the editor in-house. A prototype of the simple editor is developed with few and simple functionalities, wrapped in an intuitive design. The application must be applicable with the current V8 technology.

iv

v

Resumé

Til overvågning af en cementfabrik anvendes et 2D SCADA program, som viser statiske og dynamiske repræsentationer af enheder på fabriksanlægget. Den grafiske brugerflade til dette program sammensættes af operatøren ved brug af en editor. Med overgangen til C# og Windows Presentation Foundation skal der tilbydes en ny editor til operatøren.

Der tages udgangspunkt i FLSmidths SCADA overvågningsprogram ECS/ControlCenter til cement- og mineralfabrikker, som skal opgraderes til nye teknologier og dermed have en ny simpel editor. Der foretages derfor analyse af hvad en simpel editor bør indeholde, hvordan en bedre brugergrænseflade kan opbygges, og hvilke eksisterende editors der findes på markedet, således at det kan bestemmes om disse kan benyttes. Dette sammenholdes med muligheden for at udvikle editoren selv. Der udvikles og afprøves en simpel prototype på den valgte editor metode, med få enkle funktioner, hvor der lægges vægt på det intuitive. Der bør endvidere tages højde for at løsningen kan integreres i eksisterende V8 teknologiplatform.

vi

Ordforklaring og forkortelser

Ord Forklaring

V8 FLSmidths kommende teknologiplatform

Mimikbillede Billede som en bruger sammensætter i en editor

Objektmappe Mappe hvori dynamiske objekter placeres

Statisk objekt Objekt som brugeren kan definere. Lige linje, kurvet linje, rektangel, ellipse, tekstfelt

Dynamisk objekt Objekt som hentes ind fra paletten til mimikområdet

Datapunkt Kilde der indeholder data fra en sensor

Ribbon Panel der indeholder knapper

Ribbonfane (engelsk: ribbon tab). En fane i en ribbon. En ribbon kan indeholde flere faner

Library En samling af objekter

Resize Betyder at ændre størrelse

Forkortelse Fuldt navn

WPF Windows Presentation Foundation

XAML Extensive Application Mark-up Language

VS2008 Visual Studio 2008

SCADA Supervisory Control And Data Acquisition

PLC Programmable Logic Controller

VB.NET (VB) Visual Basic .NET

CLR Common language runtime

GPU Graphical Processing Unit

vii

Indhold

1 Introduktion............................................................................................. 1 1.1 Virksomheden FLSmidth............................................................... 1 1.2 Den eksisterende løsning ............................................................... 1 1.3 Formål og motivation .................................................................... 3 1.4 Produktbeskrivelse......................................................................... 3 1.5 Afgrænsning .................................................................................. 4 1.6 Foruddefinerede Krav.................................................................... 4 1.7 Rapportskitse ................................................................................. 5 1.8 Kapitelresumé................................................................................ 6

2 Projektstyring .......................................................................................... 7 2.1 Udviklingsmetode.......................................................................... 7

2.1.1 Open Unified Process ............................................................... 7 2.2 Risikoanalyse................................................................................. 9 2.3 Tidsplan ....................................................................................... 10

2.3.1 Tidsfordeling........................................................................... 11 2.3.2 Milestones............................................................................... 12 2.3.3 Ændring af deadline................................................................ 12

2.4 Kapitelresumé.............................................................................. 12 3 Analyse.................................................................................................. 13

3.1 Værktøjer og teknologier ............................................................. 13 3.1.1 WPF ........................................................................................ 13 3.1.2 Visual Studio 2008.................................................................. 15 3.1.3 Microsoft Office Access ......................................................... 15

3.2 Det eksisterende program ............................................................ 16 3.3 Brugersamtaler............................................................................. 18 3.4 Eksisterende løsninger ................................................................. 18

3.4.1 Iconics Genesis64 ................................................................... 19 3.5 Use case diagrammer................................................................... 20 3.6 Systemsekvensdiagrammer.......................................................... 20 3.7 Kravspecifikation......................................................................... 20

3.7.1 Non-funktionelle krav............................................................. 21 3.7.2 Funktionelle Krav ................................................................... 21

3.8 Domænemodel............................................................................. 22 3.9 Valg af løsningsform ................................................................... 23 3.10 Kapitelresumé.............................................................................. 24

4 Design ................................................................................................... 25 4.1 Arkitektur .................................................................................... 25 4.2 Brugergrænsefladen..................................................................... 26

4.2.1 Intuitiv opbygning................................................................... 26 4.2.2 Ribbons ................................................................................... 27 4.2.3 Palet ........................................................................................ 28 4.2.4 Mimikområdet ........................................................................ 29 4.2.5 Parameterpanel........................................................................ 29

viii

4.3 Funktionslaget ............................................................................. 29 4.4 Datalaget...................................................................................... 30 4.5 Eksempel på objekt...................................................................... 30 4.6 Klassediagram ............................................................................. 31 4.7 Kapitelresumé.............................................................................. 33

5 Implementering ..................................................................................... 35 5.1 Den udviklede applikation........................................................... 35 5.2 Struktur af projektfiler ................................................................. 36 5.3 Brugergrænsefladens opbygning ................................................. 37

5.3.1 Ribbon..................................................................................... 38 5.4 Funktionslaget ............................................................................. 40

5.4.1 Programstart............................................................................ 40 5.4.2 HitTest .................................................................................... 40 5.4.3 Når musen flyttes .................................................................... 41 5.4.4 Ændring af parametre ............................................................. 41

5.5 Datalaget...................................................................................... 42 5.6 Eksempel på objekt...................................................................... 43

5.6.1 Demonstration af objektet....................................................... 45 5.7 Kapitelresumé.............................................................................. 45

6 Test........................................................................................................ 47 6.1 Indlæsning af objekter ................................................................. 47 6.2 Ændring af parametre .................................................................. 48 6.3 Objekt flyttes ............................................................................... 48 6.4 Ændring af objektstørrelse........................................................... 49 6.5 Kapitelresumé.............................................................................. 49

7 Konklusion ............................................................................................ 51 7.1 Udvidelsesmuligheder ................................................................. 52

8 Brugervejledning................................................................................... 53 8.1 Indhold af cd................................................................................ 53 8.2 Installation ................................................................................... 53 8.3 Anvendelse .................................................................................. 53

8.3.1 Tilføj objekter ......................................................................... 54 8.3.2 Ændr objekter ......................................................................... 54 8.3.3 Navigér ................................................................................... 54

8.4 Demonstration af objekt .............................................................. 55 9 Kilder ...................................................................................................... 2 10 Appendiks ............................................................................................... 4

Appendiks A: Milestones............................................................................. 4 Appendiks B: Use-cases .............................................................................. 7 Appendiks C: Sekvensdiagrammer ............................................................ 10 Appendiks D: Klassediagram for centrale klasser ..................................... 16

1 Introduktion

I dette kapitel gives en kort introduktion til firmaet FLSmidth, hvorefter der redegøres for den nuværende overvågning, og motivationen for at udvikle en ny editor. Det ønskede produkt beskrives, herunder hvad det skal og ikke skal indeholde. Endelig forklares hvordan denne rapport opbygges.

1.1 Virksomheden FLSmidth

FLSmidth er en 127 år gammel virksomhed, som beskæftiger sig med konstruktion og drift af cementfabrikker. Virksomheden, som startede som en konsulentvirksomhed inden for møller og dampmaskiner, blev grundlagt af Frederik Læssøe Smidth i 1882. Firmaet skiftede dog hurtigt fagområde, og begyndte at beskæftige sig med konstruktion af tegl og mursten, hvilket bragte det ind i cementindustrien, hvor det har været lige siden.

FLSmidth udviklede sig hurtigt, og har gennem tiden været blandt de tunge spillere på cementmarkedet, hvor de også har bidraget med en del innovation til faget. Firmaet har udviklet sig fra et enmandsfirma, til nu at være en verdensomspændende virksomhed med over 7000 ansatte. I dag leverer FLSmidth et totalprodukt, som indeholder alt fra de første tegninger af en fabrik til medarbejdertræning, samt drift og vedligeholdelse.

1.2 Den eksisterende løsning

I den daglige drift af enhver cementfabrik er der behov for opsyn af hele fabrikken, hvortil der benyttes et SCADA-system kaldet ECS Opstation. I cementfabrikkens kontrolrum sidder operatører og overvåger cementfabrikken, på de op til 150 skærme som hver indeholder et mimikbillede, der er sammensat i ECS Editor og åbnet i ECS Opstation. ECS

Introduktion

Opstation er et program, som FLSmidth har købt og videreudviklet, men det bygger stadig på forældede teknologier og trænger derfor til en modernisering.

En cementfabrik kan opfattes som en samling af maskiner, som arbejder sammen på kryds og tværs, automatisk eller kontrolleret af mennesker. For at sikre at maskinerne opererer som de skal bliver de overvåget, men man ønsker ikke at spilde ressourcer på at have en person stående ved hver maskine, og kontrollere om den kører eller ej. Derfor anvendes sensorer, som konstant måler parametre ved maskinerne, og disse data videre til en server. Derfra kan programmer som ECS Opstation hente og præsentere dataet for en operatør, som er i stand til at vurdere om maskinerne kører som de skal. Fordelen ved at overvåge en fabrik på denne måde er at driftsomkostningerne reduceres betragteligt, samt at operatøren kan overvåge flere maskiner ad gangen, uafhængigt af deres fysiske placering, og derved danne sig et overblik over situationen. Figur 1.1 herunder viser, noget simplificeret, forbindelsen mellem maskine og operatør.

Figur 1.1 - Overblik over dataflow

Figuren ovenfor beskriver ikke datasikkerheden i systemet, da den så skulle indeholde beskrivelse af de redundante dataveje, servere og PLC’er, som sikrer at dataet kommer frem.

1.3 Formål og motivation 3

Når en cementfabrik bygges, designer kunden og FLSmidth i fællesskab nogle mimikbilleder, som bruges til at overvåge fabrikken. Dette gøres i ECS Editor. Men hvis operatørerne senere finder ud af, at der kan forbedres på mimikbillederne, eller der installeres nye maskiner på fabrikken, skal de have fat i ECS Editor igen.

ECS Editor udleveres til operatørerne, således at disse kan foretage ændringer, hvis der bliver behov for det. Men da dette forekommer relativt sjældent, og ECS Editor ikke opfylder nutidens krav til brugervenlighed, bliver operatørerne sjældent fortrolige med programmet, hvilket ofte medfører at selv den mindste ændring sendes til FLSmidth, som spilder tid og ressourcer på opgaver de kunne være foruden.

1.3 Formål og motivation

FLSmidth står nu foran at opgradere deres software til en tidssvarende version, som har fået navnet V8 teknologiplatform. Denne bygger på C# og .NET, og det kræves at ECS programmerne genskrives så de kan tilknyttes V8 teknologiplatformen. Da en genskrivning nu bliver aktuel, ønskes det at der udvikles en ny simpel og brugervenlig version af ECS Editor, tiltænkt operatørerne, således at de let kan foretage små ændringer uden at skulle involvere FLSmidth. FLSmidths udviklere tiltænkes at benytte Expression Blend eller en avanceret editor som endnu ikke er udviklet.

1.4 Produktbeskrivelse

Produktet af dette projekt er en prototype på en editor-applikation, som lader en bruger sammensætte et mimikbillede, til overvågning af en cementfabrik. Brugeren har mulighed for at indsætte grafiske objekter, som repræsenterer maskiner eller materiel på fabrikken, samt at forbinde datakilder til disse objekter. Editoren skal ved opstart indhente de grafiske objekter, og præsentere dem for brugeren, som så kan vælge hvilke objekter der skal overvåges, og tilføje disse til mimikbilledet. Det skal desuden være muligt at definere visse simple objekter, så som streger, rektangler og tekst, for at kunne organisere og forbinde objekter, og evt. beskrive hvad de repræsenterer.

Når et objekt tilføjes til mimikområdet, har det nogle parametre som brugeren har mulighed for at modificere. Brugeren skal således til enhver tid kunne vælge et objekt, og derefter have mulighed for at aflæse de aktuelle parametre, og ændre disse.

Introduktion

For at demonstrere hvad editoren kan, skal der bruges nogle objekter. FLSmidth har defineret nogle få stykker i XAML, men disse er statiske objekter af meget basal opbygning. Der skal derfor udvikles et objekt som demonstrerer hvad produktet kan, og hvad den nye teknologi giver af muligheder.

Endelig er det vigtigt at understrege at der er tale om et nyt produkt, som ikke kan ses som en erstatning for ECS Opstation, men som et tilbud til operatøren, der skal foretage simple ændringer. Der vil derfor ikke være de samme editeringsmuligheder som i ECS Opstation, men de der er, vil være enkle og logiske at bruge.

1.5 Afgrænsning

Som der lægges op til allerede i abstractet, er produktet en prototype der skal vise hvad der er muligt med WPF og C#, og ikke et færdigt og gennemtestet produkt, der er klar til at blive taget i brug. Der implementeres derfor metoder for enkelte objekter som demonstration, men disse kan relativt let overføres til andre og flere objekter.

Det er vigtigt at huske at der er tale om en editor, der sammensætter mimikbilleder til en anden overvågningsapplikation, hvorfor editoren i sig selv ikke har nogle datainputs, og ikke er i stand til at overvåge noget.

1.6 Foruddefinerede Krav

Da dette først og fremmest er et eksamensprojekt, og dernæst et produkt som FLSmidth kan vælge at videreudvikle og integrere i deres softwarepakke, er der kun få restriktioner for hvordan produktet skal udformes. Det optimale er, at den valgte løsningsmodel stemmer overens med FLSmidths forhåbninger, men det er muligt at analysen af dette produkt viser, at den bedste løsningsmodel ikke er den forventede. I det tilfælde er det op til FLSmidth hvilken løsningsmodel de vælger, eftersom dette projekt baseres på resultatet analysefasen. Følgende ufravigelige krav skal opfyldes.

• Programmet skal udvikles i WPF for at give de bedste grafiske muligheder. Dertil kommer at de objekter der skal behandles, er defineret i XAML, hvorfor det er oplagt at benytte dette undersystem af .NET frameworket. Endeligt benytter FLSmidths V8 platform .NET, hvilket betyder at integration af dette produkt vil blive forenklet væsentligt.

1.7 Rapportskitse 5

• Programmeringssproget skal være C#, da dette er FLSmidths foretrukne sprog til programmering af Windows-applikationer. Alternativt kunne vælges VB.NET, men da de øvrige programmer i V8 er skrevet i C#, vil et sprogskifte ikke give nogle fordele.

• Løsningen skal optimeres til Windows-platformen, da alle brugere af programmet enten benytter Windows Vista eller Windows XP.

• Programmet skal kunne køre optimalt på almindelig tidssvarende kontormaskine, uden installation af andre applikationer end .NET frameworket. En tidssvarende kontormaskine vurderes til at have minimum 2 GB ram, 1,6 GHz CPU, 30 GB harddisk og et 64 MB grafikkort.

1.7 Rapportskitse

Abstract/Resumé Giver læseren et resumé af projektet og problemstillingen

Introduktion Giver læseren en introduktion til projektet, og redegør for hvad motivationen og formålet med projektet er.

Projektstyring Beskriver hvilke arbejdsmetoder der bruges, og hvordan projektets tidsplan ser ud.

Analyse Redegør for de teknologier der bliver benyttet i projektet. Der kigges nærmere på den eksisterende løsning, og mulige alternativer undersøges. Brugersamtaler afholdes, og disse danner grundlag for kravspecifikationen.

Design Forklarer hvordan applikationen opbygges, arkitektonisk såvel som indholdsmæssigt.

Implementering Beskriver hvordan applikationen er sammensat, samt hvordan de grundlæggende funktioner fungerer.

Test Verificerer at de implementerede funktioner virker som de skal

Introduktion

Konklusion Gør status over projektet, herunder produktet såvel som selve processen. Der redegøres for eventuelle udvidelsesmuligheder.

Brugervejledning Forklarer hvordan applikationen installeres og benyttes

Kilder Indeholder henvisninger til de kilder, som er benyttet. Henvisninger til kilder vil være i kantede parenteser, for eksempel [3]

Appendiks Indeholder relevante dokumenter som ikke er medtaget i den egentlige rapport.

1.8 Kapitelresumé

Der blev i dette kapitel redegjort hvordan overvågning foregår på nuværende tidspunkt, og hvad den nuværende editors rolle er. Der blev beskrevet hvad der er for en applikation der skal udvikles, og hvem den skal henvende sig til. Til slut blev der lavet en plan for hvordan projektet skal dokumenteres, i form af en rapportskitse.

2.1 Udviklingsmetode 7

2 Projektstyring

Herunder beskrives hvordan projektet udarbejdes. Der gøres rede for arbejdsmetoder og risici under projektforløbet. Når dette er på plads lægges der en tidsplan for projektet.

2.1 Udviklingsmetode

Da dette projekt hovedsagligt er et softwareprojekt, vælges der en arbejdsmetode som passer hertil. For at sikre en fornuftig arbejdsgang, hvor alle dele af projektet bliver vægtet tilpas, anvendes iterativ udvikling i form af Open Unified Process.

2.1.1 Open Unified Process

Open Unified Process, forkortet OpenUP, er en videreudvikling af Rational Unified Process. Metoden indeholder de grundlæggende principper fra RUP, så som iterativ udvikling, Use Cases, og risikoanalyse. OpenUP henvender sig til mindre grupper, og projekter med kort varighed, hvorfor det er velegnet til dette projekt. Ved brug af denne metode garanteres et ordentligt udviklingsforløb, hvor de grundlæggende funktioner udarbejdes først.

Projektstyring

Figur 2.1 - Organisation af et OpenUP-drevet projekt [Kilde 1, side 3]

Det er vigtigt at påpege, at iterationerne ikke afspejler enkelte faser, således at første iteration svarer til analysefasen. Første iteration vil typisk indeholde en stor del analyse, men også lidt design, og måske endda noget indledende implementeringsarbejde. I de efterfølgende iterationer vil der ligeledes indeholde opgaver fra flere faser af projektarbejdet.

2.2 Risikoanalyse 9

Figur 2.2 - Arbejdsforløb med Unified Process [Kilde 2]

I dette projekt arbejdes der desuden med milestones, som repræsenterer målet for hvad der skal være nået ved en endt iteration.

2.2 Risikoanalyse

Risikoanalysen kortlægger de største risici ved projektet, baseret på sandsynligheden for at de forekommer og konsekvensen hvis de forekommer. Der planlægges hvad der skal gøres hvis en af situationerne opstår, og beskrives hvilke forholdsregler der tages for at undgå disse situationer.

Risiko Sand-synlighed (1-10)

Konsekvens (1-10)

K-faktor (SxK)

Konsekvens, Forholdsregler

Tab af data ved nedbrud.

1 10 10 Konsekvens: Arbejde skal laves om, hvilket medfører skred i tidsplanen. Forholdsregler: Hyppig backup, fordelt på flere uafhængige datalagre Når og hvis: Revurder tidsplan og projektets omfang.

Projektstyring

Sygdom 4 2 8 Konsekvens: Muligt skred i tidsplanen, afhængig af sygdommens alvor og længde. Forholdsregler: Sørg for at have lidt buffer i tidsplanen. Når og hvis: Indhent i buffer, eller revurder tidsplan og/eller opgaveomfang.

Skred i tidsplan

2 5 10 Konsekvens: I bedste fald er det ikke mere end at det kan indhentes i den tid, der er sat af til forsinkelser. I værste fald skal projektets omfang og/eller deadline revurderes. Forholdsregler: Den sidste periode i tidsplanen indeholder en lille buffer Når og hvis: Revurder tidsplan og/eller opgaveomfang.

2.3 Tidsplan

Der udarbejdes fra start en tidsplan, som skal sørge for at enkelte områder ikke vægtes for tungt eller let, i forhold til andre, og for at fordele arbejdsbyrden ligeligt over hele projektperioden. Tidsplanen er lavet således at de forskellige arbejdsområder tildeles en procentdel af den samlede arbejdsperiode, ud fra skøn om hvor meget arbejde de hver især indeholder. Dernæst opstilles en række opgaver, som skal være udføres i løbet af projektperioden. Opgaverne kategoriseres inden for de forskellige arbejdsområder, og det kontrolleres om opgaverne er passende fordelt over arbejdsområderne, eller om f.eks. implementeringsopgaverne er for dominerende i forhold til projektbeskrivelsen. Denne metode sikrer at de rigtige arbejdsopgaver vælges, således at projektet fremstår som en helhed,

2.3 Tidsplan 11

og ikke som en mængde dokumenteret kildekode, eller en liste over ting der skal implementeres, hvoraf kun en brøkdel er realiseret.

Projektperioden deles op i iterationer, og de forskellige arbejdsopgaver fordeles efter hvornår de bør udføres. Da projektperioden er ca. 18 uger, og iterationerne skal have en hvis varighed for at det er muligt, at arbejde inden for flere arbejdsområder, virker det fornuftigt at benytte fire iterationer af længde på ca. 4-5 uger. I afsnit 2.3.2 ses hvilke opgaver der skal løses i hver enkelt iteration.

2.3.1 Tidsfordeling

Efter at have gennemlæst projektbeskrivelsen utallige gange, og sammenholdt den med listen over opgaver der skal løses, er nedenstående vægtning af arbejdsområderne kommet frem.

Analyse

30%

Design

20%

Implementering

25%

Test

5%

Projektafslutning

15%

Buffer

5%

Figur 2.3 - Fordeling af tid på de forskellige arbejdsopgaver

Som det kan ses er der lagt meget vægt på at få analyse og implementering, frem for f.eks. test. Dette skyldes som nævnt i afsnit 1.5, at det ikke er en

Projektstyring

færdig løsning der skal produceres, men en demonstration af hvad der er muligt, samt vurdering af hvad brugeren har brug for.

2.3.2 Milestones

Efter hver iteration skal en mængde delmål være nået. Disse delmål er fordelt på de fire milestones, og skal være nået til den pågældende dato. Der henvises til Appendiks A: Milestones for beskrivelse af milestones.

2.3.3 Ændring af deadline

Som nævnt i risikoanalysen, afsnit 2.2, kan der forekomme skred i tidsplan, og desværre skete det for netop dette projekt. Planen var at projektet skulle afleveres 5/1 2009, hvilket var en dato som blev fastsat i samråd med virksomhedsvejlederen, som formentlig gerne så projektet hurtigt afsluttet, med udsigt til en ny ansat i FLSmidth. Undertegnedes mangel på overblik på daværende tidspunkt, gjorde at afslutningen på projektet kolliderede med afsluttende eksamener og projekter på DTU.

For at projektet ikke skulle lide denne forkerte beslutning om tidligere deadline, rettedes der henvendelse til Institutsdirektør Kaj Madsen, for at bede om at få udskudt deadline tre uger til den 26/1 2009, hvilket stadig er inden for den normerede projektperiode. Udsættelsen blev staks givet. Projektet er altså blevet udsat med tre uger i forhold til den oprindelige deadline, men er stadig inden for normeret tid.

2.4 Kapitelresumé

I dette kapitel blev valgt OpenUP som udviklingsmetode, og derfor redegjort for hvad OpenUP er. De tre største risici ved projektet blev identificeret, og der blev angivet forholdsregler for disse situationer. Da dette var på plads blev en tidsplan udarbejdet, baseret på milestones, som er at finde i appendiks A.

3.1 Værktøjer og teknologier 13

3 Analyse

I dette kapitel gives en introduktion til de værktøjer og teknologier der vil blive brugt i dette projekt. Der kigges nærmere på den eksisterende editor, ECS Editor, og der tales med brugene af denne. Derefter undersøges hvilke alternativer der er til den eksisterende editor, og, hvis der eksisterer alternativer, analyseres de. Der laves derefter use-cases og systemsekvensdiagrammer over de mest brugte funktioner, som den nye editor skal indeholde. Baseret på det ovenstående, udformes en kravspecifikation for den nye editor.

3.1 Værktøjer og teknologier

I dette afsnit beskrives de værktøjer og teknologier som projektet er bygget op af. Afsnittet er for de læsere der ikke er bekendt med WPF og Visual Studio 2008, hvorfor en kort introduktion kan være behjælpelig. Læsere der er bekendt med disse emner kan gå videre til næste kapitel

3.1.1 WPF

Windows Presentation Foundation, ofte forkortet WPF, er et af fire undersystemer i .NET-frameworket. WPF tilbyder en bred vifte af grafiske muligheder, der gør det muligt at en god brugergrænseflade, som kan kobles sammen med et bagvedliggende funktionslag. Windows Vista kommer med .NET 3.0 installeret, hvilket er den tidligste version hvor WPF er inkluderet – benyttes Windows XP skal brugeren selv installere frameworket. Der er kommet flere udvidelser til WPF i de senere versioner af .NET, hvor den seneste i skrivende stund er version3.5 SP1. Tidligere har Windows Forms været et meget anvendt værktøj til programmering af brugergrænseflader, men meget tyder på at WPF vil overtage for dette, da det giver mulighed for

Analyse

at lave de samme grafiske operationer, og samtidig indeholder en række forbedringer. Herunder er de mest væsentlige.

• WPF er hardwareaccelereret, hvilket giver en markant fordel når det kommer til tunge grafiske beregninger. Det er op til GPU’en at udføre disse beregninger baseret på Direct3D.

• XAML er et XML-baseret sprog, som WPF benytter til at beskrive de grafiske objekter, uafhængigt af hvilket .NET-sprog de bagvedliggende funktioner skrives i. Dette giver udviklere og designere en unik mulighed for at arbejde tæt sammen, uden at være afhængige af hinanden.

• Styles gør det muligt at definere et ensartet udseende, for alle objekter af en type. Man kan til en hvis grad sammenligne styles med CSS kendt fra hjemmesider.

• Common Language Runtime, forkortet CLR, er et platformsuafhængigt miljø, som giver mulighed for at køre højniveau programmeringssprog på forskellige computere, uden at der skal tages højde for hardwareforskelle. Dette er muligt fordi compileren konverterer koden til kode i et midlertidigt sprog, som sendes videre til den platformspecifikke CLR når programmet køres. CLR konverterer koden til den passende maskinkode, alt efter hvilket operativsystem den pågældende computer bruger. Udover det ovenstående tager CLR også hånd om en række aspekter, heriblandt sikkerhed og allokering af hukommelse.

• Grafiske objekter i WPF er vektorbaserede, hvilket gør det muligt at skalere objekter, uden at de bliver deforme og unøjagtige.

Herunder vises et eksempel på hvordan XAML og C# hænger sammen i en simpel funktion. Som nævnt ovenfor kan der frit vælges mellem .NET-sprog til brug i code-behind, uden at det har indvirkning på brugergrænsefladen. Det eneste der kræves i nedenstående eksempel, er at Button_Click eksisterer.

3.1 Værktøjer og teknologier 15

Figur 3.1 - Opbygning af WPF-applikation

3.1.2 Visual Studio 2008

Visual Studio er et kendt og udbredt udviklingsmiljø, som indeholder kompiler og editor til .NET programmering. VS2008 er den seneste version i rækken, og er et af de mest kendte udviklingsmiljøer, når det kommer til .NET-programmering. Denne er valgt på grund af det brede udvalg af funktioner til udvikling af WPF applikationer, heriblandt en meget veludviklet IntelliSense1 samt gode debugging muligheder.

3.1.3 Microsoft Office Access

Som datalager anvendes Access-databaser, da dette er FLSmidths format for datalagring. Access-databaser er relationelle databaser, som kan tilgås med databasekald eller via en grafisk brugergrænseflade, som følger med i Microsofts Office-pakke. Der vil i dette projekt ikke blive oprettet nogen databaser, men der hentes data fra de eksisterende.

1 Microsofts version af autocompletion som forsøger at forudse hvilket ord du vil skrive

Analyse

3.2 Det eksisterende program

For at få et overblik over hvad den nye editor bliver sammenlignet med, kigges der lidt nærmere på den eksisterende editor. Nedenstående kritik af programmet tager udgangspunkt i, hvordan det fungerer og fremstår for en utrænet bruger. En bruger, der skal bygge et mimikbillede op fra bunden, vil have brug for mange flere af funktionerne, end en operatør vil.

Det første der falder i øjnene er de mange små knapper, med små oftest farveløse ikoner. Der er ingen forklarende tekst til at hjælpe brugeren med at finde ud af, hvilken funktion der gemmer dig bag ved knapperne. Som ny bruger er det ikke let at navigere rundt mellem funktionerne, og det hjælper ikke at der knapperne er placeret til venstre, til højre og oven for mimikområdet. Man kan fristes til at tro at der er anvendt små knapper for at spare plads til mimikområdet, men hvorfor så ikke udnytte pladsen ordentligt, i stedet for at have tre kolonner med knapper til venstre, hvor ingen af kolonnerne udnytter hele skærmens højde, selv ved lavere opløsninger. Hvad der er mindst lige så uforståeligt, er at ingen af knapperne leder en hen til de objekter man kan tilføje.

For at tilføje et objekt skal man finde den rigtige palet, ved at vælge menuen Palettes, og derunder vælge menupunktet af samme navn. Der er ligeledes en menu der hedder Object, men denne har ikke noget med tilføjelse af objekter at gøre. Den lader en komme hen til de samme indstillinger som man kommer frem til, hvis man højreklikker på et objekt. Når man har klikket på menupunktet Palettes, åbnes et mindre vindue som indeholder en mappestruktur til venstre, og en liste over filer i den markerede mappe, til højre. Mappestrukturen afspejler undermapperne i mappen C:\FlsaDev\GMSPic\Ops, hvilket er en hårdt kodet sti. For at finde et bestemt objekt, er man altså nødt til at klikke sig vej frem til listen over paletter, og derefter vælge den rigtige palet ud fra palettens filnavn. Når en palet åbnes, vises endnu et vindue med palettens indhold, således at der nu er to ekstra vinduer at se, ud over hovedvinduet. Objekter kan nu tilføjes ved hjælp af drag and drop, hvilket er en udmærket metode, idet den er ligetil for brugeren. Figur 3.2 viser hvordan programmet ser ud, når et objekt skal tilføjes, hvis der samtidig ændres på et objekt. En bruger vil muligvis ikke gøre dette på en gang, men det viser meget godt hvordan man hurtigt kan miste overblikket på grund af de mange vinduer.

Ønsker man at editere et objekt, er der mulighed for at ændre nærmest alt ved objektet. Der er f.eks. muligt at skifte farve på objektet, og der kan frit vælges mellem de godt 200 forskellige farver, som identificeres ved et farvenummer. Farverne repræsenterer hver især et materiale eller en tilstand, og det er derfor vigtigt at vælge den rigtige farve. Desværre kender operatørerne sjældent farvenumrene, og de vælger så den der ligner mes muligt i deres øjne. Farve nummer 4 og farve nummer 36 er nærmest identiske, men

3.2 Det eksisterende program 17

kendere vil vide at nummer 4 repræsenterer vand, mens nummer 36 repræsenterer vand tilsat et andet stof. Konsekvensen ved at vælge den forkerte farve er begrænset, hvis operatøren der laver fejlen, også er den der benytter billedet, da han så vil forstå fejlen, og næppe lægge mærke til den. Men hvis en anden operatør overtager, eller en moderator skal redigere i mimikbilledet, kan der ske en fejlfortolkning, og i værste fald kan det ikke tydes hvad der rent faktisk overvåges.

Objekterne der er til rådighed, er meget kantede i deres udformning, og ofte ensfarvede, men meget simple, og dermed lette at forstå. Man skal huske på at der er tale om et overvågningsprogram, og ikke et program der skal have en stor wow-effekt, men objekterne vidner om at programmet ikke er udviklet i dette årti.

Figur 3.2 – Screen dump fra eksisterende program

Analyse

3.3 Brugersamtaler

For at finde ud af hvad der ønskes forbedret, og hvad der ønskes videreført fra den eksisterende løsning, er forskellige brugere blevet bedt om at give deres input. Der er foretaget brugersamtaler med både den erfarne moderator, som gerne vil sikre sig en ensartet opbygning af overvågningsbilleder, og med den utrænede operatør, som vil have et værktøj, der er let at forstå. Denne applikation er tiltænkt operatøren, hvilket gør feedback og ideer herfra meget vigtigt. Samtidig skal der tages højde for moderatorens ønsker, der besidder en masse knowhow. Ved at overvåge brugerne når det eksisterende program, ECS Editor, benyttes, dannes et indtryk af frekvensen for brugen af de enkelte funktioner. Det viste sig hurtigt at følgende handlinger udgør over 96 % af samtlige handlinger:

• Flyt objekt

• Tilføj objekt

• Skift datapunkt reference

• Skift visuel parameter

• Tegn statisk objekt (tekst, streg, osv.)

• Zoom

Brugsmønstret for moderatorer og operatører var overraskende identisk, selvom der kunne observeres enkelte uligheder. For at tilføje et objekt skulle operatøren ofte igennem flere paletter for at finde hvad han/hun søgte, mens moderatorerne kunne disse udenad. Placeringen af objektet tog flere forsøg for operatøren, og krævede brug af zoom funktionen, mens moderatoren oftest kunne placere objektet præcist i første forsøg.

3.4 Eksisterende løsninger

Der er et stort marked for SCADA systemer, da det er en let og relativt billig måde at overvåge maskiner på, sammenlignet med at have mennesker placeret fysisk ved maskinen. WPF er som bekendt kun ca. to år gammelt, hvilket betyder at producenter har haft begrænset tid til at udvikle et robust SCADA system, selv hvis de startede den dag .NET 3.0 udkom. Mange producenter har formentlig også været tøvende i starten, da det er dyrt at satse stort på en teknologi, som forbrugerne ikke tager til sig. Det betyder at der kun er få SCADA systemer baseret på WPF til rådighed, som ikke er bygget til en målgruppe, og af disse er der et produkt som skiller sig positivt ud. Firmaet Iconics fra Massachusetts, USA, har udviklet et produkt kaldet Genesis64, som blandt andet indeholder en SCADA editor. Ved et nærmere kig på Genesis64 viser det sig rigtig lovende, og er en værdig konkurrent til at udvikle sin egen løsning.

3.4 Eksisterende løsninger 19

3.4.1 Iconics Genesis64

Genesis64 Suite, som er programmets fulde titel, tilbyder en række muligheder for kontrol og styring af en fabrik. Genesis64 tilbyder blandt andet editoren GraphWorX64, hvor man kan indsætte grafiske objekter som følger med Genesis64. Finder man ikke at de medfølgende objekter er tilstrækkelige til at repræsentere sin fabrik, er det også muligt at lave sine egne.

Genesis64 har en god opbygning, som er inspireret af designeren fra VS 2008, hvilket betyder at der er en palet til venstre, og en liste med de parametre til højre. Nedenstående figur viser hvordan programmet ser ud.

Figur 3.3 – Screen dump fra Genesis64

Analyse

For oven har man valgt at benytte ribbons, som også er benyttet i den nyeste version af Microsoft Office. Således kan den samme plads benyttes flere gange, da der skiftes mellem de forskellige faner, alt efter hvilken type objekt der er markeret. Det er også muligt for brugeren selv at skifte til en anden fane end den foreslåede.

Endeligt er der display området, hvor brugeren kan tilføje de ønskede objekter. Indholdet af dette område er produktet af brugerens arbejde, og når der gemmes er det kun indholdet herfra der skrives til en fil, med de parametre der er sat i parameterområdet.

3.5 Use case diagrammer

Der udvikles use case diagrammer for de grundlæggende funktioner i applikationen. Der er derfor lavet use cases for følgende:

• Opret objekt

• Tilføj objekt fra palet

• Skift størrelse på objekt

• Slet objekt

• Ændr parameter

• Zoom ind

Use case diagrammerne kan findes i appendiks B

3.6 Systemsekvensdiagrammer

Der er udviklet et systemsekvensdiagram for hver use case, for at illustrere hvordan interaktionen mellem bruger og system forløber. Systemsekvensdiagrammerne kan ses i appendiks C.

3.7 Kravspecifikation

Herunder defineres de krav, som den nye editor skal opfylde. Kravene er baseret på analysen af den eksisterende editor, brugersamtaler og brugsmønstre, samt der foruddefinerede krav fra FLSmidth.

3.7 Kravspecifikation 21

3.7.1 Non-funktionelle krav

NON-FUNK1. Brugergrænsefladen har en intuitiv opbygning.

NON-FUNK2. Der skal holdes en klar linje mellem simpel og avanceret funktionalitet, og kun den simple skal implementeres.

NON-FUNK3. Der skal defineres farvestandarder med passende betegnelser

NON-FUNK4. Programmet skal tilpasses mest muligt V8-platformen, så senere kan forløbe lettest muligt

NON-FUNK5. Programmet skal udvikles i C# WPF og køres på en Windows platform

NON-FUNK6. Import og eksport foregår i XAML format

NON-FUNK7. Mimikområdet skal være af størrelsen 1600x1200

3.7.2 Funktionelle Krav

FUNK1. Brugeren skal præsenteres for alle relevante editeringsmuligheder i parameterpanelet, herunder mulighed for at ændre tekst, farve, punktreference, grænser osv.

FUNK2. Brugeren kan oprette, åbne, editere og gemme mimikbilleder

FUNK3. Resizing af objekter skal være mulig, men uønsket resizing skal forebygges

FUNK4. Mulighed for markering og editering af flere objekter på en gang

FUNK5. Mulighed for direkte opslag i punktdatabase

FUNK6. Objekter kan have egne visualiseringsegenskaber

FUNK7. Brugeren skal, foruden de prædefinerede objekter, kunne tegne og editere simple modeller som streger, rektangler og cirkler

FUNK8. Objekter må ikke kunne placeres uden for mimikbilledet

FUNK9. Prædefinerede objekter skal have logiske standardværdier

Analyse

FUNK10. Brugeren skal kunne zoome ind og ud på områder i mimikbilledet

FUNK11. Ved zoom må der ikke ske forvridning af objekter

FUNK12. Mulighed for import af objekter, enten som enkelte objekter eller som hele libraries

3.8 Domænemodel

Domænemodellen herunder forklarer hvordan de forskellige objekter og områder hænger sammen.

* 1

Indeholder

Statisk objekt Dynamisk objekt

Mimikbillede

Parameterpanel

Palet

Parameter

*

1

Indeholder

*

1

Indeholder

*

1

Har

*

1

Har

*1

Indeholder

Figur 3.4 - Domænemodel

3.9 Valg af løsningsform 23

3.9 Valg af løsningsform

Der er reelt set kun to løsningsmodeller som egner sig til dette projekt. Det ene er at udvikle en applikation fra bunden, hvilket giver ubegrænset valgfrihed, men også klart den største arbejdsbyrde. Den anden er at benytte Genesis64, som uden tvivl er et gennemarbejdet stykke software, men som til en hvis grad låser virksomheden fast til også at benytte dette system til andre opgaver, da der er tale om en suite af programmer der arbejder godt sammen. For at beslutte hvilken løsning der er den bedste, kigges der nærmere på forskellene på de to løsninger, og hvad der passer bedst til den simple bruger.

Genesis64 benytter som sagt deres egne filtyper kaldet sdfx og gdfx, men indholdet af filerne er XAML kode, hvilket gør det relativt let åbne filerne i et overvågningsprogram.

For at operatøren lettest muligt kan forbinde et objekt med et datapunkt, skal der præsenteres en liste over datapunkter til rådighed. Det nuværende system benytter en Access database til at gemme information om de forskellige datakilder, hvilket kunne også gøres på mange andre måder. Der er ikke defineret noget ønske fra FLSmidth om hvordan dette gøres fremover, så dette er ikke nogen hindring for nogle af løsningsmodellerne.

Genesis64 har en fornuftig opbygning, hvor der er let adgang til alle funktionerne. Selv den utrænede bruger vil hurtigt forstå grundprincipperne i drag and drop fra paletten til display området, og ændring af parametre er også ligetil. En lignende opbygning vil blive brugt til en egenudviklet applikation, hvis Genesis64 ikke foretrækkes.

Det springende punkt er at der ønskes en simpel editor til den utrænede operatør, som skal foretage simple ændringer eller lave få tilføjelser, og dertil er Genesis64 simpelthen for kompliceret og omfattende. Der er ingen fordele ved at skulle starte så tung en applikation, for at tilføje et simpelt objekt. Dertil kommer at der skal betales brugerlicens for Genesis64, mens en egenudviklet applikation frit kan distribueres. Det operatøren har brug for er f.eks. en kort liste af farver som er fornuftigt navngivet, alt efter hvad farven skal repræsentere, og ikke en kæmpe palet af unavngivne farver, som giver rig mulighed for inkonsistens. F.eks. skal vand altid have en bestemt farvekode, og ikke den som operatøren synes er den bedste til formålet. Ligeledes har operatøren heller ikke behov for at kunne lave sine egne objekter.

Ud fra disse overvejelser vurderes det, at den bedste løsning er at udvikle en applikation fra bunden. Denne beslutning er taget ud fra at FLSmidth ikke ønsker at benytte hele Genesis64 suite, da dette vil give et helt andet beslutningsgrundlag.

Analyse

3.10 Kapitelresumé

Den eksisterende editor og alternativer til denne er blevet analyseret, og der er redegjort for værktøjer og teknologier der vil blive brugt, herunder WPF. Der er defineret use-cases og systemsekvensdiagrammer for de funktioner, som den nye editor skal udføre. De udarbejdede use-cases findes i appendiks B, og tilsvarende systemsekvensdiagrammer i appendiks C. Endeligt blev en kravspecifikation defineret, som beskriver hvad der skal implementeres, før første version at editoren er færdig.

4.1 Arkitektur 25

4 Design

I dette afsnit forklares hvordan applikationen skal opbygges. Først gøres rede for arkitekturen, hvorefter de enkelte lag i applikationen designes. Endelig defineres et klassediagram der viser hvordan programmet bygges op.

4.1 Arkitektur

Applikationen bygges op efter en trelagsmodel, hvor den grafiske repræsentation udgør øverste lag, den funktionelle del udgør det midterste lag, og de statiske objekter og data udgør det nederste lag. Ved at dele programmet op på denne måde, kan der let foretages ændringer i et enkelt lag, uden at resten af programmet skal ændres tilsvarende. Herunder er de tre lag illustreret.

Figur 4.1 - Applikationens arkitektur

Design

4.2 Brugergrænsefladen

4.2.1 Intuitiv opbygning

Det er essentielt at brugergrænsefladen opbygges så simpelt og intuitivt som muligt, således at operatøren hurtigt kan benytte programmet, uden at skulle bladre gennem en tyk manual. Der lægges vægt på at brugeren skal præsenteres for de funktioner, der er relevante for det aktuelle indhold i mimikbilledet. For at hjælpe brugeren, skal objekter være til rådighed og let tilgængelige under hele programforløbet. Der stræbes efter at applikationsvinduet kun ændres hvis det er nødvendigt, og der vil derfor ikke forekomme ekstra vinduer, som skygger for hovedvinduet, og medvirker til at brugeren mister overblikket.

Til at tilgå funktioner i en grafisk brugergrænseflade, bliver der oftest anvendt knapper, og det er også tilfældet for den gamle version af Opstation editor. Knapperne var imidlertid meget små, og ikke særligt forklarende, og der var rigtig mange på en gang. I denne applikation vil der stræbes efter at lave større knapper med mere forklarende ikoner og tilhørende tekst. Der vælges derfor at ribbons benyttes, idet de gør det muligt at udnytte den allokerede plads effektivt, og desuden opfylder førnævnte mål. Uddybende forklaring af brugen af ribbons følger i afsnit 4.2.2.

I stedet for den gamle palet med objekter, introduceres en ny palet, som er tilgængelig hele tiden. Ideen med en palet med objekter, som er fornuftigt grupperede, er god, men hvis brugeren skal huske hvilken palet et objekt tilhører, falder ideen til jorden. I denne applikation anvendes stedet en palet i form af en søjle til venstre i programvinduet. Nærmere forklaring følger i afsnit 4.2.3.

Mimikområdet er brugerens arbejdsplads, og skal derfor overlades til denne hvordan indholdet organiseres. Der anvendes derfor et hvidt område, hvor brugeren frit kan tilføje de ønskede objekter, og foretage ændringer efter behag.

Endeligt skal det også være muligt at ændre parametre ved objekter. I den Opstation editor skete dette ved at man højreklikkede på et objekt, og valgte et menupunkt, hvorefter en nyt vindue kom frem med en masse parametre der kunne ændres, men også en masse der var deaktiverede, fordi de ikke var aktuelle for det valgte objekt. I denne applikation vil der kun blive vist de parameterindstillinger, som brugeren rent faktisk kan ændre. For at undgå at skulle have flere vinduer åbne på samme tid, laves en søjle i stil med paletten, men hvor denne i stedet for objekter indeholder parameterindstillinger. Denne søjle vil være placeret til højre for mimikområdet. Se afsnit 4.2.5 for nærmere forklaring af parameterpanelet.

4.2 Brugergrænsefladen 27

Brugergrænsefladen har nu mulighed for at tilbyde al den funktionalitet, som funktionslaget tilbyder, og det på en meget enkel og overskuelig måde. Figuren herunder skitserer hvordan applikationsvinduet kommer til at se ud.

EditorEditor

Tab1 Tab2 Tab3

Group1 Group2

Palet

Parameterpanel

Ribbon

Mimik

Figur 4.2 - Applikationsvinduets opbygning

Ved at opbygge applikationsvinduet på denne måde, undgår man at benytte sig af menulinjer, med menuer fyldt med ugennemskuelige underpunkter. Ligeledes vil der til enhver tid være ét og kun ét aktivt programvindue, hvilket sænker kravet til operatørens overblik betydeligt. For at denne opbygning er effektiv, skal der konstant være et opdateret parameterpanel og en fornuftigt valgt ribbonfane til rådighed, hvilket er en af de opgaver som funktionslaget udfører.

4.2.2 Ribbons

Ribbons skal indeholde alt hvad menuer og toolbars tidligere har gjort, hvilket indebærer alle generelle objekter og al programfunktionalitet, så som ’opret nyt mimikbillede’ eller ’luk programmet’. Ribbons er opgaveorienterede og mere forklarende end menuer og toolbars, pga. sine visuelle egenskaber. Ribbons består af en applikationsknap og tabulatorer, hvor applikationsknappen indeholder de funktioner som ikke har noget med mimikbilledet at gøre, og tabulatorerne indeholder de funktioner der kan ændre på mimikbilledet. Hvis der f.eks. vælges et objekt, skal der være en ribbonfane, som indeholder knapper med funktioner der er relevante for det

Design

objekt, f.eks. mulighed for at flytte objektet eller zoome ind på det. Er der ikke valg noget objekt, kan det tænkes at brugeren ønsker at tilføje et nyt, og den ribbonfane, der indeholder de statiske objekter, vises.

En af fordelene ved ribbons er, at den samme plads kan benyttes flere gange, hvilket er grunden til at ribbons kan indeholde større knapper med mere beskrivende indhold.

Ribbons opbygges efter Microsofts UX guidelines for ribbons[3], hvilket sikrer at der er en rød tråd i programmets opbygning, som lægger sig op ad andre Windows-applikationers opbygning, hvilket kan hjælpe brugeren til at komme hurtigere ind i programmet. Dog synes det at disse guidelines er meget fastlåste omkring ribbonfaner, navnlig deres navngivning og placering, som bærer præg af at de i eksemplet benytter et tekstbehandlingsprogram. Denne applikation vil på enkelte punkter bevidst afvige fra disse guidelines, men kun hvor der er et indlysende alternativ.

I første omgang skal denne ribbon indeholde to ribbonfaner, hvoraf den første er Home, og den anden er Edit. Home skal indeholde de grundlæggende funktioner, som indtil videre er begrænset til de statiske objekter, som brugeren kan oprette, altså tekstfelter, streger, ellipser, rektangler og buede streger. Disse funktioner vil normalt være at finde i ribbonfanen Indsæt, men da de er en del af programmets væsentligste funktionalitet, er de placeret her. Den anden ribbonfane, Edit, indeholder de funktioner som bruges til at editere et enkelt objekt, herunder vælg, flyt, og ændr størrelse på objekt. Denne fane indeholder desuden også zoomfunktioner, da disse vurderes til hovedsageligt at skulle bruges til editering af et objekt.

Ud over fanerne indeholder en ribbon også en applikationsknap, og en hurtigstart-bjælke. Applikationsknappen indeholder funktionerne, som normalt er at finde i fil-menuen i en menubar, nemlig Ny, åbn, gem og luk.

Hver knap skal, jf. [kilde 3, afsnit ’Icons’], have stort og lille billede, således at knappen let kan indlæses både som normal funktionsknap, og som knap i hurtigstart-bjælken.

4.2.3 Palet

Paletten indeholder de objekter som brugeren kan tilføje til mimikbilledet. For at tilføje et objekt til mimikbilledet anvendes træk og slip, og en kopi af objektet er derefter tilføjet til mimikområdet. Hvilke objekter der findes i paletten kommer an på hvilke objekter der ligger i objektmapperne. Når programmet startes indlæses disse objekter, hvilket betyder at det er let at tilføje flere objekter til paletten, da man blot skal kopiere sin fil med definition af et objekt ind i en objektmappe.

4.3 Funktionslaget 29

Nogle objekter er muligvis for brede til at kunne blive vist i paletten. Disse objekter vil blive nedskaleret så de kan være der, og skaleres ned med en tilsvarende faktor, således at objektet ikke risikerer forvridning til ukendelighed. Objektet der tilføjes mimikområdet er naturligvis fuld størrelse.

Denne paletmodel er med til at gøre programmet mere overskueligt, da der ikke skal åbnes et separat paletvindue, som skygger for en del af mimikområdet.

4.2.4 Mimikområdet

Det område som brugeren skal bruge til at sammensætte et overvågningsbillede kaldes mimikområdet. Det er fra start tomt og klar til at få tilføjet objekter, enten fra paletten eller fra programmets ribbon, i form af de statiske objekter. Mimikområdet er defineret med en fast størrelse på 1600x1200, hvilket betyder at kun en del af mimikområdet kan vises på skærmen ad gangen på de fleste af nutidens skærme. Det er muligt at scrolle vertikalt og horisontalt ved hjælp af rullepaneler, for at komme frem til en ønsket del af mimikområdet. Mimikområdet kan vel bedst beskrives som et tomt lærred.

4.2.5 Parameterpanel

Sidste del af brugergrænsefladen er parameterpanelet. Indholdet af dette panel skifter jævnligt alt efter hvad der markeres i mimikområdet. Det typiske indhold er en række rullemenuer, som lader brugeren vælge, hvilke parametre der skal være gældende for de valgte objekt. Alternativt til rullemenuer, kan panelet også indeholde tekstfelter, eller hvilke som helst andre elementer, som brugeren kan ændre indholdet af. Når en parameter ændres, overføres ændringen til det valgte objekt i mimikbilledet.

4.3 Funktionslaget

Funktionslaget, også kendt som logiklaget, er det midterste lag i applikationen, og det lag så står for al logik og beregning. Når der trykkes på en knap i brugergrænsefladen, sendes der en forespørgsel videre til funktionslaget, som håndterer denne forespørgsel. Hvis forespørgslen kræver data fra datalaget, er det funktionslaget der henter det nødvendige data, og sender det tilbage til brugergrænsefladen.

Men at udføre funktioner som brugere kalder gennem brugergrænsefladen, er ikke den eneste opgave som funktionslaget varetager. Når programmet starter gennemgås applikationens objektmapper, og alle filer af filtypen XAML eller

Design

DLL, der er placeret i disse mapper, gennemlæses for objekter. Når objekterne er indlæst, sendes de til paletten som visualiserer dem.

Funktionslaget står desuden for, at det er den rigtige ribbonfane der vises, hvilket betyder at der skal holdes øje med, hvad brugeren foretager sig i mimikbilledet. Når et objekt vælges, gennemløbes en liste af mulige objekttyper, for at finde den type der matcher det valgte objekt. Denne tabel indeholder de parametre som brugeren har mulighed for at ændre ved objekter, og disse sendes til parameterpanelet.

Fælles for alle funktioner er det, at de ikke må blokere for hinanden, med mindre de er funktioner inden for samme kategori. Det betyder at det f.eks. skal være muligt at zoome ud, og derefter flytte på objekter i denne tilstand.

Klassediagrammet sidst i dette kapitel redegør for de forskellige klasser, der skal implementeres.

4.4 Datalaget

Datalaget indeholder informationer som skal gemmes mellem programkørslerne. Det betyder at datalaget i denne applikation består af filer der beskriver de objekter der indlæses, og en database med datapunkter som objekterne kan forbindes til. Databasen og objekterne, med undtagelse af et, er udviklet af FLSmidth, og ikke som en del af dette projekt.

Databasen består af en samling tabeller, hvoraf kun en har relevans for dette projekt. Denne tabel indeholder de koder som bruges til at identificere et datapunkt, og en beskrivelse der hjælper til at forstå hvad det data, som kan aflæses fra datapunktet, repræsenterer.

Objekterne er delt op i filer, således at en fil indeholder et enkelt grafisk objekt, som er beskrevet i XAML. Objekterne skal placeres i objektmapperne ’Dynamic Models’, ’Dynamic Gismos’ eller ’User Controls’, for at være tilgængelige i paletten.

4.5 Eksempel på objekt

Da det er meget begrænset hvad FLSmidth har udviklet af objekter til WPF, skal der, udover applikationen, udvikles et objekt som demonstrerer hvilke muligheder der er med den nye teknologi. De objekter som allerede er udviklet, er meget basale, og giver ikke et ordentligt indblik i, hvad der er muligt i WPF. Objektet der udvikles til demonstration skal være lidt mere avanceret, og vise hvad der nu kan lade sig gøre.

4.6 Klassediagram 31

På en cementfabrik findes der et robotlaboratorium, som løbende står for at teste den cement som fabrikken producerer. Laboratoriet indeholder en indbakke, en udbakke, og tre maskiner der foretager diverse prøver. Imellem disse fem enheder, som er placeret i en halvcirkel, står en robot-arm med fem akser, hvis opgave er at fragte prøverne frem og tilbage mellem de fem enheder.

Der skal udvikles et objekt som forestiller det omtalte robotlaboratorium, indeholdende alle seks enheder. Objektet skal kunne udføre de samme bevægelser, som det rigtige robotlaboratorium gør, hvilket vil sige at robot-armen skal kunne bevæge sig imellem de øvrige fem enheder. Bevægelserne skal ske ud fra det data som objektet modtager.

Det er overvejet om dette objekt kan erstattes med et objekt der streamer video fra robotlaboratoriet, men dette er fravalgt, da det stiller helt andre krav til datakilden, og ikke mindst forbindelsen til det fysiske robotlaboratorium.

4.6 Klassediagram

Klassediagrammet, som ses i Figur 4.3, viser hvordan de forskellige klasser hænger sammen. Det er værd at bemærke at brugergrænsefladen ikke er en klasse, men en del for sig, og derfor ikke optræder i klassediagrammet. Brugergrænsefladen er defineret i XAML og er forbundet til EditorWindow-klassen.

Design

Figur 4.3 – Klassediagram

4.7 Kapitelresumé 33

Som det ses på klassediagrammet, er der tre klasser der udgør den centrale funktionalitet i applikationen, nemlig EditorWindow, PropertiesUpdater og PaletteUpdater.

EditorWindow nedarver fra System.Windows.Window, og er en partiel klasse til brugergrænsefladen, hvorfor den står for kommunikation med brugergrænsefladen. Når brugeren f.eks. vælger et objekt i mimikbilledet, viderebringer EditorWindow dette til PropertiesUpdater. PaletteUpdater henter objekterne fra objektmapperne, hvorefter EditorWindow tilføjer dem til paletten. Programmets grundlæggende funktionalitet gennemgås i afsnit 5.4. Indholdet af de tre omtalte klasser kan ses i appendiks D.

4.7 Kapitelresumé

Det blev besluttet at applikationens arkitektur skal formes som en trelagsmodel, med lavest mulig kobling lagene imellem. Brugergrænsefladens udformning blev designet, og funktionslagets og datalagets roller blev forklaret. Der blev defineret et klassediagram, som redegør for hvordan de forskellige klasser hænger sammen. Endelig blev det besluttet at udvikle et eksempel på et objekt, til demonstration af applikationen.

Design

5.1 Den udviklede applikation 35

5 Implementering

De overvejelser der er lavet i analysen, dannede grundlag for hvordan applikationen blev designet, og dette design overføres til programkode. Det valgte programmeringssprog er, som nævnt tidligere, C# med anvendelse af .NET frameworket. Brugergrænsefladen beskrives i XAML. Der vil blive gennemgået hvilke klasser der er implementeret, og deres rolle i applikationen, hvorefter de vigtigste vil blive set nærmere på. Gennemgangen af implementeringen vil følge samme linje, som gennemgangen af designet, altså som applikationens arkitektur, startende med det øverste lag.

5.1 Den udviklede applikation

Herunder ses applikationen i den nuværende version. Brugeren har på figuren tilføjet et objekt og oprettet et tekstfelt, og er i gang med at skifte farve på teksten i tekstboksen.

Implementering

Figur 5.1 - Screen dump fra den udviklede editor

5.2 Struktur af projektfiler

Programmet indeholder en række filer, som hver især kan tilknyttes et programlag. Dette er skitseret i figuren nedenfor.

5.3 Brugergrænsefladens opbygning 37

Figur 5.2 - Projektfiler opdelt i lag

Filerne i de to første lag bliver kompileret med i den eksekverbare fil af C# kompileren, mens filerne i datalaget distribueres uden modifikationer. Det betyder at det kompilerede program, som afleveres til brugeren, vil indeholde en eksekverbar fil som erstatter filerne i de to øverste applikationslag.

5.3 Brugergrænsefladens opbygning

Brugergrænsefladen består hovedsagligt af elementer fra Systems.Windows.Controls-namespacet, hvilket betyder at alle elementer i dette afsnit, der ikke angives namespace for, antages at komme herfra.

Applikationsvinduet er af typen System.Windows.Window, og indeholder et Grid. Dette Grid er opdelt i tre kolonner og to rækker, og bruges til at placere brugergrænsefladens fire områder. Øverste række spænder over alle tre kolonner, og indeholder programmets ribbon, der er af typen Microsoft.Windows.Controls.Ribbon.Ribbon. Den nederste række i det grundlæggende Grid, er opdelt i tre kolonner, hvor hvert felt indeholder en ScrollViewer. Den midterste ScrollViewer indeholder et Canvas, der udgør mimikområdet, mens de to øvrige ScrollViewers indeholder StackPanels,

Implementering

som udgør paletten og parameterpanelet. For at give bedre overblik over denne opbygning, er den skitseret på figuren herunder.

Grid

ScrollViewerScrollViewer ScrollViewer

Microsoft.Windows.Controls.Ribbon.Ribbon

Canvas StackPanelStackPanel

Figur 5.3 - Brugergrænsefladens opbygning

Indholdet af programmets ribbon er ikke skitseret, men vil være forklaret i afsnit 5.3.1. Mimikområdet, paletten og parameterpanelet er alle tomme ved opstart, berøres derfor ikke yderligere før afsnit 5.4, hvor deres indhold defineres.

5.3.1 Ribbon

Til opbygning af Programmets ribbon er benyttet en betaudgave at et ribbon library, hentet fra [3], som Microsoft udsender i løbet af 2009. Dette library indeholder objekter, der kan bruges til at sammensætte en fornuftig ribbon.

Da det anvendte ribbon library stadig er i en betaudgave, er der visse fejl og mangler som man skal tage højde for, samtidig med at der ikke stilles nogen garanti fra Microsoft, om funktionaliteten af objekterne. Et eksempel på dette er, at der ikke er nogen sammenhæng mellem CLR-namespace og XML-namespace, hvilket betyder at der ikke er muligt at anvende indholdet i dette library, hvis man bruger den almindelige xmlns=”http…” notation, til at henvise til library’et. I stedet er det nødvendigt lave henvisningen gennem CLR-namespace’et, hvilket kommer til at se således ud:

5.3 Brugergrænsefladens opbygning 39

xmlns:rib="clr-namespace:Microsoft.Windows.Controls.Ribbon;

assembly=RibbonControlsLibrary"

For at få en fornuftig ribbon, laves der først nogle ribboncommands, som bruges til at tilgå funktionslaget. Disse bindes op til eventhandlers i Editorvinduets partielle klasse, således at en ribboncommand tilkobles funktionalitet i det underliggende lag. Med disse kommandoer på plads kan der defineres visuelle objekter til en ribbon. En ribboncommand kan se ud som følgende:

<rib:RibbonCommand x:Key="RectangleCommand"

LabelTitle="Rectangle"

SmallImageSource="Images\Rectangle-small.png"

LargeImageSource="Images\Rectangle-large.png"

ToolTipTitle="Rectangle"

ToolTipDescription="Draw a Rectangle"

Executed="RectangleCommand_Executed" />

Ved at benytte ribboncommands, er der mulighed for at have flere knapper med samme funktion, hvilket er nødvendigt hvis en funktion både skal være tilgængelig i hurtigstarts-bjælken, og som en normal funktionsknap. Jævnfør [3] opbygges en ribbon som ribbonfaner, der indeholder ribbongrupper, der igen indeholder ribbonknapper. Derudover indeholder en ribbon også en applikationsknap og en hurtigstarts-bjælke. Efter disse regler opbygges programmets ribbon, hvilket betyder at kodens outline bliver som følger:

<rib:Ribbon x:Name="Ribbon" Grid.ColumnSpan="3" Grid.Column="0"

Grid.Row="0">

<rib:Ribbon.ApplicationMenu>

<rib:RibbonApplicationMenu Command="{StaticResource

SomeButtonCommand }">

<rib:RibbonApplicationMenu.Items>

<rib:RibbonApplicationMenuItem

Command="{StaticResource SomeButtonCommand}"/>

</rib:RibbonApplicationMenu.Items>

</rib:RibbonApplicationMenu>

</rib:Ribbon.ApplicationMenu>

<rib:Ribbon.QuickAccessToolBar>

<rib:RibbonQuickAccessToolBar>

<rib:RibbonButton Command="{StaticResource

SomeButtonCommand}"/>

</rib:RibbonQuickAccessToolBar>

</rib:Ribbon.QuickAccessToolBar>

<rib:RibbonTab x:Name="TabName" Label="NameOfTab">

<rib:RibbonGroup Command="{StaticResource

SomeGroupCommand}">

<rib:RibbonButton Command="{StaticResource

SomeButtonCommand}" />

</rib:RibbonGroup> </rib:RibbonTab>

</rib:Ribbon>

Implementering

Det ses af ovenstående at både ribbon og ribbonfane i eksemplet tildeles et navn. Dette gøres for at funktionslaget kan angive hvilken en fane der skal være synlig.

For at kunne benytte objekter fra ribbon library’et skal filen RibbonControlLibrary.dll være til stede, i samme mappe som den eksekverbare fil.

5.4 Funktionslaget

Som nævnt i afsnit 4.3 er dette lag det klart mest omfattende, og der definerer programmet. Dette lag indeholder størstedelen af projektfilerne, og samtlige klasser i klassediagrammet. I dette afsnit vil den væsentligste funktionalitet blive gennemgået.

5.4.1 Programstart

Når programmet startes, gennemsøger PaletteUpdater objektmapperne, for at finde de objekter som brugeren skal kunne bruge. XAML-filerne i mapperne ’Dynamic Models’ og ’Dynamic Gismos’ læses, ved hjælp af en System.Windows.Markup.XamlReader i funktionen PaletteUpdater.getUIElementFromFile. PaletteUpdater gennemsøger også objektmappen ’User Controls’ for dll-filer, ved hjælp af en System.Activator i funktionen LoadDLL. Hver gang et objekt indlæses, tilføjes der en eventhandler til objektet, som tilføjes til paletten. Denne eventhandler sørger for, at der hver gang der klikkes med venstre museknap på et objekt, laves en kopi af objektet i mimikområdet. Når alle objekter er indlæst åbnes hovedvinduet, og editoren er klar til brug.

5.4.2 HitTest

Efter at have tilføjet et objekt, skal det være muligt at få fat i elementet i mimikområdet, sådan at det kan flyttes, slettes, få ændret parametre, størrelse og så videre. Der udføres derfor en HitTest, hver gang venstre museknap trykkes ned, såfremt den aktive funktion tillader det. Dette gøres ved at gemme musens position, og derefter gennemløbe alle objekter i mimikbilledet. Hvis et objekt rammes vil det have en lavere (x,y)-værdi end markørens, og dets (x-værdi plus objektets bredde, y-værdi plus objektets højde) være højere end markørens. Er dette tilfældet vælges det ramte element. Nedenstående skitse illustrerer dette.

5.4 Funktionslaget 41

Figur 5.4 - Skitse af HitTest

5.4.3 Når musen flyttes

Hver gang musen flyttes i applikationsvinduet, opstår en event som håndteres af eventhandleren OnMouseMove. Denne funktion overskrives, for at gøre det muligt at flytte objekter rundt i mimikområdet. UIElementet EditorWindow.elementBeingAltered refererer til det objekt der er i gang med at blive ændret, forudsat der er sådan et. Når musen flyttes og referencen ikke er null, flyttes objektet sammen med markøren, hvis det er den funktion der er aktiv. Det er også denne funktion der ændrer størrelsen på det grå rektangel, der kommer frem, når der zoomes ind på et område, eller skal angiver område for et tekstfelt.

5.4.4 Ændring af parametre

Når et objekt vælges, anvendes PropertiesUpdater-klassen til at indlæse de elementer, som giver brugeren mulighed for at ændre parametre ved et objekt. Hvis der er tale om et valg fra en mængde valgmuligheder, anvendes System.Windows.Controls.ComboBox til at vise valgmulighederne. Hvis brugeren skal angive en vilkårlig værdi, anvendes en

Implementering

System.Windows.Controls.TextBox. alle elementer i parameterpanelet skal have en eventhandler, således at ændringen videreføre til det valgte objekt i mimikområdet.

I den nuværende version angives hvilke parametre der skal kunne ændres, i PropertiesUpdater-klassen som en række if-sætninger, betinget af objektets type. Denne del kunne med fordel lægges ud i et library for sig, således at ændringer kunne rettes i dette library, så systemet skulle kunne håndtere en ny objekttype, men da der hele tiden foretages ændringer og eksperimenteres med nye objekter, er det ikke gjort endnu.

Parameterpanelet vil for de fleste objekter være tomt, idet alle de objekter der indlæses, er af typen System.Windows.Shapes.Polygon, som ikke indeholder noget der er værd at ændre på for brugeren. For at illustrere hvordan parameterpanelet bør virke, er det implementeret for tekstfelt-objektet. Ved et tekstfelt har brugeren således mulighed for at ændre skriftstørrelse, tekst og skriftfarve gennem parameterpanelet, hvorefter objektet opdateres. For at vise hvordan en punktreference ser ud, er denne også mulig at definere for et tekstfelt, selvom et tekstfelt ikke bør have en sådan reference.

5.5 Datalaget

Datalaget består af flere elementer, nemlig dataobjekterne i XAML-filer, og datapunkterne i databasen, som bruges til at knytte datapunkt med objekt. I denne applikation er databasen placeret lokalt, hvilket ikke bliver tilfældet i den færdige version. For at forbinde til en database på en anden placering, skal der blot oprettes en ny DBConnection med den nye sti som parameter.

Dataobjekterne skal være placeret i de tre objektmapper, for at være tilgængelige i editoren. Det er lavet tre objektmapper for at adskille objekterne efter deres type, således at de statiske objekter, og de dynamiske objekter som ikke kræver en forbindelse til et datapunkt, placeres i mappen ’Dynamic Models’. De objekter der har behov for reference til et datapunkt, men er simple nok til udelukkende at kunne defineres i XAML, placeres i mappen ’Dynamic Gismos’. De mest avancerede objekter, som indeholder sin egen kode, eksporteres til sit eget DLL-library, og placeres i mappen User Controls. Fælles for alle objekter gælder det at de namespaces de benytter, bør være deklareret i objekt-filen, som vist nedenfor, for at XamlReaderen kan tolke dem korrekt.

<Polygon

xmlns="http://schemas.microsoft.com/winfx

/2006/xaml/presentation"

xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml

Stroke="{x:Static Brushes.Black}" StrokeThickness="0"

Points="0,0 160,0 160,200 100,280 60,280 0,200"

>

5.6 Eksempel på objekt 43

… </Polygon>

Hvis der ikke er defineret namespace for objektet, forsøger PaletteUpdater.getDataFromFile selv at finde typerne i de to standard namespaces. Så længe at man udelukkende bruger typer fra standard namespaces, er det da ikke påkrævet at definere namespaces, men det er god skik at gøre det.

5.6 Eksempel på objekt

Objektet skal forestille et robotlaboratorium der foretager målinger på cementprøver. For at demonstrere mulighederne i WPF, implementeres hele robotlaboratoriet i 3D. Objektet implementeres som UserControl, da det skal indeholde mere avancerede funktioner end hvad der kan klares med triggers.

Den grafiske udformning af objektet er defineret i XAML som GeometryModel3D- og Transform3DGroup-objekter, som er lagt i en Viewport3D. Elementerne er alle 3D-modeller fra forskellige CAD-programmer, som er eksporteret til XAML og lagt ind i samme Viewbox3D. Desværre var den eneste model af robotten, som det var muligt at få fat i, en produktionsmodel, hvor alle dele af robotten er detaljeret så præcist, en ny robot kan bygges efter denne model. Det betyder at den eksporterede model er tilsvarende detaljeret, hvilket får den grafiske definition til at fylde over 28.000 kodelinjer, og dermed gør objektet unødigt krævende at vise. Havde robotten været af samme detaljegrad som de øvrige elementer i objektet, havde den grafiske del fyldt ca. 5.000 kodelinjer.

Ud fra datainput skal objektet kunne illustrere hvad der foregår i det rigtige robotlaboratorium, hvilket betyder at robot-armen skal kunne bevæge sig i bestemte mønstre. XAML-koden for robot-armen inddeles derfor i fem dele, hvor første del er hele robot-armen med undtagelse af foden, da den ikke skal bevæge sig. Den næste del udgør en er den del der skal bevæge sig om den næste akse i robot-armen, og således forsætter opdelingen af robot-armen for hver akse den indeholder. Del et indeholder således den del af robot-armen som skal bevæge sig om den første akse, del to, det der skal bevæge sig om den anden akse, og så fremdeles. Den del af koden der udgør del fem er således også en med i del fire, tre, to og et.

<Model3DGroup x:Name="Group_0">

…

<RotateTransform3D CenterX="0.09" CenterZ="1.47158">

<RotateTransform3D.Rotation>

<AxisAngleRotation3D x:Name="group0rotation"

Axis="0,1,0"/>

</RotateTransform3D.Rotation>

</RotateTransform3D>

…

Implementering

<Model3DGroup x:Name="Group_1">

…

<RotateTransform3D CenterX="0.55" CenterZ="0.79387">

<RotateTransform3D.Rotation>

<AxisAngleRotation3D x:Name="group1rotation"

Axis="0,0,1"/>

</RotateTransform3D.Rotation>

</RotateTransform3D>

…

<Group 2, 3 & 4>

</Model3DGroup>

</Model3DGroup>

For at få objekterne til at bevæge sig, er der tilknyttet en AxisAngleRotation3D, som gør det muligt at rotere gruppen et ønske antal grader. Der er implementeret animationer til at lave disse bevægelser, således at de fremstår glidende. Når objektet modtager ordrer om an flytte robotarmen, udføres en række animationer, som matcher den rigtige robotarms bevægelser.

Da objektet er defineret i 3D, skal det også være muligt at se det fra forskellige vinkler. Der er derfor lavet tre forskellige kamerapositioner, som kan vælges, enten af brugeren ved tryk på en af objektets knapper, eller ved hjælp af datainput fra en datakilde. Der implementeres desuden en klasse kaldet TrackBall, hentet fra [8], som giver brugeren mulighed for at flytte kameraet rundt om objektet med musen, samt at zoome ind og ud. For at forhindre at brugeren kommer til at flytte kameraet, er TrackBall-klassen deaktiveret for alle andre kamerapositioner end ’Camera 3’.

5.7 Kapitelresumé 45

Figur 5.5 - Billede af objektet

5.6.1 Demonstration af objektet

Da editoren ikke modtager nogle data, udvikles der en simpel applikation, som lader brugeren sende data til objektet og dermed se hvordan det fungerer. Denne applikation består af et vindue som indeholder en Viewbox3D, hvori objektet vises. Der er desuden to tekstfelter, hvor brugeren kan bestemme kameravinkel og få robotten til at bevæge sig, ved at sende data til objektet.

5.7 Kapitelresumé

Projektets filer er blevet redegjort for, og opbygningen af hver enkelt lag er beskrevet. De vigtigste klasser er udpeget, og programmets opbygning og funktionalitet er gennemgået. Opbygningen af eksempel-objektet blev gennemgået, og en lille testapplikation til dette blev forklaret kort.

Implementering

6.1 Indlæsning af objekter 47

6 Test

Herunder testes om de implementerede funktioner agerer som de skal, udføres en black box test af applikationen. Der angives for hver test, handling, som beskriver hvad der testes, forventet resultat, og faktisk resultat. For at bestå en test, skal det faktiske resultat stemme overens med det forventede resultat. Hvis en test ikke består, vil det blive forsøgt forklaret hvorfor resultatet ikke er som forventet.

6.1 Indlæsning af objekter

Indlæsning af objekter fra objektmapperne testes

Test Handling Forventet resultat Faktisk resultat

1 Objekter forsøges indlæst, hvor alle objekter er korrekt defineret

Alle objekterne indlæses og vises i paletten

Som forventet

2 Objekter forsøges indlæst, hvor et objekt ikke har namespace defineret

Alle objekter indlæses og vises i paletten.

Som forventet

3 Objekt-fil uden korrekt XAML-kode forsøges indlæst.

Objektet indlæses ikke

Som forventet

4 Filer med forkerte filtyper placeres i objektmapperne, og applikationen startes

Der indlæses kun filer med korrekt filtype

Som forventet

5 Dll-fil som ikke indeholder objekt, placeres i objektmappen

Korrekt definerede user controls indlæses

Som forventet

Test

User Controls, og applikationen startes

Ud fra ovenstående test ses det at applikationen kun indlæser de korrekt definerede objekter og udelader de resterende.

6.2 Ændring af parametre

Ændring af parametre i parameterpanelet testes. Denne test er udført på objektet tekstfelt, da det er det objekt med flest parameterindstillinger.

Test Handling Forventet resultat Faktisk resultat

1 Der ændres tekst i parameterpanelet

Objektet i mimikbilledet opdateres tilsvarende med ændringen af teksten

Som forventet

2 Et objekt, der har fået ændret sine parametre, vælges

Parameterpanelet vises, hvor de opdaterede parametre er valgt

Som forventet

3 Der ændres farve op objektet

Objektet i mimikbilledet opdateres tilsvarende med ændringen af farven

Som forventet

Når en parameter ændres, opdateres objektet tilsvarende, og de aktuelle parametre indlæses når objektet vælges næste gang.

6.3 Objekt flyttes

Det testes om det er mulig at flytte et objekt. Forud for hver af nedenstående tests er funktionen ’Move’ valgt.

Test Handling Forventet resultat Faktisk resultat

1 Et objekt forsøges flyttet til en ny placering i mimikområdet

Objektet følger markøren indtil museknappen slippes

Som forventet

2 Et objekt forsøges flyttet til en ny placering uden for mimikområdet

Objektet følger markøren indtil kanten af mimikområdet nås.

Som forventet

6.4 Ændring af objektstørrelse 49

Et objekt kan flyttes til en vilkårlig placering inden for mimikområdet, men ikke udenfor.

6.4 Ændring af objektstørrelse

Det testes om det er muligt at ændre størrelse på et objekt. Forud for hver af nedenstående tests er funktionen ’Resize’ valgt.

Test Handling Forventet resultat Faktisk resultat

1 Et oprettet objekt, som ikke er en kurvet linje, (tekstfelt, lige linje, rektangel, ellipse) forsøges ændret

Objektets størrelse ændrer sig som følge af musens bevægelser

Som forventet

2 En oprettet kurvet linje forsøges ændret

Det er ikke muligt at vælge den kurvede linje, og derfor ændres størrelsen ikke

Som forventet

3 Et objekt af typen Polygon, fra mappen ’Dynamic Models’ forsøges ændret

Da polygoner ikke kan skaleres ændres objektet ikke

Objektet ændrer størrelse, men den grafiske repræsentation gør ikke

4 Et objekt af typen RobotUC, fra mappen ’User Controls’ forsøges ændret

Objektets størrelse ændrer sig som følge af musens bevægelser

Som forventet

Det ses at det er muligt at ændre størrelse på de fleste objekter, men at det ikke er muligt for objekter af typen Polygon. Dette skyldes at Polygoner er sammensat af punkter med streger imellem, og i af vektorer.

6.5 Kapitelresumé

De implementerede funktioner blev testet, og alle undtagen en test gave det forventede resultat. Resultatet af test 6.4.3 viste at polygoner ikke er skalerbare, i modsætning til de andre testede objekter.

Test

6.5 Kapitelresumé 51

7 Konklusion

Den eksisterende editor blev analyseret, og dannede, sammen med samtaler med brugere af denne, grundlag for kravene til den nye editor. Det blev undersøgt om en sådan applikation allerede eksisterer, og det viste sig at Genesis64 kunne opfylde kravene. Det blev efter nærmere analyse vurderet, at den var for omfattende til formålet.

Der er udviklet en prototype af en editor som lader brugeren sammensætte mimikbilleder, ved at tilføje objekter, der repræsenterer virksomhedens maskiner. Brugeren kan desuden oprette statiske objekter, såsom tekstfelter og basale figurer. Der er implementeret mulighed for at ændre parametre for nogle af disse objekter. Applikationen er intuitivt opbygget, således at brugeren hurtigt kan sætte sig ind i hvordan den fungerer.

For at første version af editoren kan testes af slutbrugeren mangler følgende krav fra kravspecifikationen at blive implementeret:

• FUNK2: Det er muligt at lave et nyt mimikbillede, men ikke muligt at gemme og åbne mimikbilleder.

• FUNK4: Kun et objekt kan editeres ad gangen i den nuværende implementering

• FUNK12: Objekter kan ikke importeres, men inkluderes ved at blive lagt i en objektmappe

Desuden ville følgende funktionalitet, som ikke er nævnt i kravspecifikationen, sandsynligvis også implementeres:

• Klip, kopier og indsæt

• Mulighed for at ændre hvilket objekt der ligger øverst

Den udviklede editor kan relativt let integreres i FLSmidths V8 teknologiplatform, da den er skrevet i samme programmeringssprog, og med

Konklusion

en adskilt brugergrænseflade. FLSmidth kan derfor let få deres designere til at strømline udseendet til de øvrige dele af V8, og derefter lægge det ud i en User Control,

Kildekode til editoren, det udviklede objekt, og programmet til at demonstrere det, er vedlagt denne rapport på cd, både på kompileret form, og som projekter. Skulle der være problemer med cd’en kan dens indhold hentes som zip-fil på www.xbeck.dk/eksamensprojekt.zip

7.1 Udvidelsesmuligheder

Ud over den funktionalitet, som skal implementeres før første version er færdig, er der visse muligheder for at gøre applikationen bedre.

Først og fremmes vil en opdatering af paletten være på sin plads, så den kan håndtere opdeling af objekter ud fra hvilken mappe de er hentet fra. Hvis objekter blev sorteret i undermapper i objektmapperne, ville dette også kunne give mulighed for yderligere kategorisering. Endelig bør det være muligt at klappe en palet sammen, således at brugeren ikke skal scrolle forbi alle objekter, for at komme til det nederste.

Inspireret af forskellige Microsoft applikationer kan der implementeres Live Preview, således at et objekt ændrer sig midlertidigt alt efter hvilken en parameter der er markeret, men endnu ikke er valgt.

Endelig bør paletten opdatere sig selv, således at et objekt kan tilføjes ved at blive kopieret til den rigtige objektmappe.

8.1 Indhold af cd 53

8 Brugervejledning

8.1 Indhold af cd

På den vedlagte cd ligger kildekode, både som enkeltfiler indeholdende kode, og som hele projekter, som kan åbnes i Visual Studio. Førstnævnte ligger i CD\Kildekode\Kildekode som enkeltfiler\<projektdel> hvor projektdel angiver om det er editor, objekter, udviklet objekt eller testapplikation til udviklet objekt. Ønskes projektfilerne findes de i CD\Kildekode\Projektfiler\<projektdel>

De kompilerede applikationer editor og RoborTest lægger som zip-filer i roden af cd’en.

Denne rapport er vedlagt på cd’en i doc-format og pdf-format, i mappen CD\Rapport.

8.2 Installation

For at anvende applikationen skal den installeres på en placering hvor brugeren har skriverettigheder, og kan derfor ikke køres direkte fra Cd’en. For at installere applikationen skal filen Editor.zip udpakkes til en placering på harddisken. Foruden dette kræves det, at computeren har .Net 3.5 SP1 installeret. Dette kan hentes gratis fra [6]

8.3 Anvendelse

Editoren startes ved at køre filen Editor.exe. Editoren indlæser objekterne i objektmapperne og programvinduet vises. Når programmet er startet, har brugeren følgende muligheder.

Brugervejledning

8.3.1 Tilføj objekter

1. Tilføj objekt fra paletten. Dette gøres ved at klikke på det ønskede objekt, og trække det ind til på den ønskede placering i mimikområdet. Bemærk at det ikke er muligt at trække objekter ud af mimikområdet, hvilket betyder at objektet kun følger markøren inden dette.

2. Definér et objekt selv. For at definere et objekt selv, vælges den ønskede objekttype i Home-fanen, og det markeres med musen hvor objektet skal defineres. Objekterne der kan vælges imellem er tekstfelt, lige linje, kurvet linje, rektangel og ellipse. Det bør noteres at den kurvede linje endnu ikke er færdigudviklet, hvilket betyder at den ikke kan vælges på et senere tidspunkt.

8.3.2 Ændr objekter

1. Ændr parametre for objekt. For at ændre parametre for et objekt skal et objekt først vælges. Dette gøres ved at trykke på ’Select’ i Edit-fanen, hvorefter de parametre der er mulige at ændre ved det valgte objekt, kommer frem i parameterpanelet til højre. Det valgte objekt kan kendes på, at objektet får en sort skygge omkring sig.

2. Ændr størrelse på objekt. Vælg ’Resize’ i Edit-fanen, og klik derefter på det objekt du vil ændre størrelse på. Der kommer nu en firkant til syne i hvert hjørne at objektet, som kan flyttes med musen, hvorefter objektet skifter størrelse.

3. Flyt objekt. Vælg ’Move’ i Edit-fanen og træk objektet til sin nye position.

4. Slet objekt. Dette gøres ved at vælge et objekt, og derefter trykke på ’Delete’ på tastaturet. Der er endnu ikke nogen knap i programvinduet der tilbyder denne funktionalitet.

8.3.3 Navigér

1. Scroll til et område af mimikbilledet. Som i enhver anden Windows-applikation kan der scrolles ved hjælp af rullepanelerne.

2. Zoom ind. Vælg ’Zoom in’ i Edit-fanen og marker det område du vil zoome ind på. Når venstre museknap slippes, zoomes der ind på det valgte område. Bemærk at det ikke er muligt at zoome ind to gange i træk. For at komme tilbage til normal visning skal der trykkes på ’Reset zoom’ i samme fane.

8.4 Demonstration af objekt 55

3. Zoom ud. Tryk på ’Zoom out’ i Edit-fanen. Der zoomes ud så hele

mimikbilledet kan være i programmets vindue. For at komme tilbage til normal visning skal der trykkes på ’Reset zoom’ i samme fane.

8.4 Demonstration af objekt

Til at teste det udviklede objekt kan applikationen RobotTester, som er vedlagt på Cd’en, bruges. Programmet er en simpel eksekverbar fil med tilhørende robot-fil (RobotUC.dll), der kan føres direkte fra Cd’en, men det anbefales at kopiere de to filer til harddisken og køre dem derfra.

Når programmet er startet kan der sendes data til objektet, enten for at skifte kameravinkel eller for at køre en animation. I inputfelterne accepteres kun tal, hvor der findes fra animation 0 til animation 3, og kamera 0 til kamera 3. For at få objektet til at udføre animation 0 skrives 0 i øverste inputfelt, og der trykkes på ’Animate’. For at skifte kameravinkel indsættes 0, 1, 2 eller 3 i nederste tekstfelt, og der trykkes på ’Change Camera Position’.

For at prøve selv at bevæge kameraet skal kameravinkel 3 vælges. Når dette er gjort navigeres på følgende måde. Holdes venstre museknap ned roteres om objektet. Holdes højre museknap nede flyttes kameraet til siden eller op og ned. Bruges musens scrollhjul zoomes ind og ud. Kameravinklen kan altid skiftes til en af de andre vinkler, så vær ikke bange for at fare vild.

Kilder

9 Kilder

1. http://www.eclipse.org/epf/general/OpenUP.pdf Dokument der forklarer principperne i OpenUP.

2. http://en.wikipedia.org/wiki/Unified_Process Unified Process på Wikipedia.

3. http://msdn.microsoft.com/en-au/library/cc872782.aspx UX guidelines for ribbons - Regler for hvordan en ribbon opbygges .

4. http://msdn.microsoft.com/officeui Microsoft hjemmeside, hvor fra det er muligt at hente det anvendte RibbonControlLibrary.

5. Mathiassen, Munk-Madsen, Nielsen og Stage. Objektorienteret

analyse og design. Marko, 1997. ISBN 87-7751-129-8. Bog om analyse og design i UML.

6. http://www.microsoft.com/downloads/details.aspx?familyid=ab99342f-5d1a-413d-8319-81da479ab0d7&displaylang=en .NET 3.5 Framework Service Pack 1.

7. Charles Petzold. Application = Code + Markup: A guide to

Microsoft Windows Presentation Foundation, Microsoft Press, 2006. ISBN 0-7356-1957-3 Bog om programmering i WPF

8. http://viewport3d.com/trackball.htm Forklaring af trackball-klassen, og link til download af denne

8.4 Demonstration af objekt 3

9. http://dvuyka.spaces.live.com/Blog/cns!305B02907E9BE19A!124.e

ntry Link til site der indeholder ResizingAdorner.cs

Appendiks

10 Appendiks

Appendiks A: Milestones

Herunder ses de fire milestones, som definerer målene på de fire iterationer. Datoen i parentesen er deadline for den pågældende milestone, og dermed sidste dag i den tilhørende iteration.

Milestone 1 (Man 6/10 2008)

Analyse (60 %)

• Gennemgå nuværende løsning

• Find mulige forbedringer

• Find allerede eksisterende softwareløsninger som kan bruges

• Afhold samtaler med brugere og udviklere af den tidligere version

• Undersøg brugerfærdigheder

• Brugsmønstret klarlægges (hvilke funktioner er de mest brugte?) Understøt med use-cases)

• Lav interessentanalyse ud fra samtaler med brugerne

• Definer kravspecifikation for både funktionelle og non-funktionelle krav

Design (20 %)

• Påbegynd design af den grafiske brugerflade Implementering (20 %)

• Overfladisk programmering af udvidelser til eksisterende løsninger for at få fornemmelse af hvad der er muligt

Milestone 2 (Man 3/11 2008)

0 Appendiks A: Milestones 5

Analyse (50 %)

• Studér V8-teknologiplatform.

• Undersøg metoder til intuitiv opbygning af en brugergrænseflade

• Definér grænse mellem simpel og avanceret editor

• Fastlæg hvordan programmet opbygges, så det er mest intuitivt Design (30 %)

• Definér prototypernes opbygning (diagrammer og modeller)

• Færdiggør design af første version af den grafiske brugerflade

• Design funktionslaget Implementering (20 %)

• Påbegynd implementering af de forskellige løsningsmodeller

• Grundlæggende brugergrænseflade implementeres ud fra det definerede design

Milestone 3 (Man 15/12 2008)

Analyse (10 %)

• Foretag valg af funktionalitet som skal implementeres Design (30 %)

• Afslut design af både funktionslag og brugergrænseflade Implementering (50 %)

• Implementer løsningsmodellerne Test (10 %)

• Test af løsningsmodellerne

Milestone 4 (Man 26/1 2009)

Implementering (10 %)

• Implementering afsluttes Test (10 %)

• Test af løsningsmodellerne Projektafslutning(60 %)

• Reflektér over projektets resultat og konkludér derudfra hvilken løsningsmodel der er mest fornuftig

• Sammensæt endelig dokumentation af projektet

Appendiks

Buffer (20 %)

• I tilfælde af at tidsplanen skrider indhentes det forsømte her

0 Appendiks B: Use-cases 7

Appendiks B: Use-cases

Use Case Opret objekt

Mål At oprette et objekt i overvågningsbilledet hvor placering, størrelse og parametre kan ændres.

Antagelser Programmet er startet

Skridt Handling

1 Brugeren trykker på knap med en objekttype

2 Brugeren vælger et område, hvor objektet skal indsættes

3 Et tekstfelt indsættes på det markerede område

4 Parameterpanelet opdateres så den indeholder de parametre som er relevante for objektet

5 Standardværdierne for objektet indlæses i parameterpanelet

6 Brugeren ændrer parametre i parameterpanelet

7 Objektet opdateres løbende ud fra de ændringer der laves i parameterpanelet

8 End

Use Case Tilføj objekt fra palet

Mål At tilføje et objekt fra paletten til mimikområdet

Antagelser Programmet er startet, og der findes objekter i paletten

Skridt Handling

1 Brugeren klikker på et objekt i paletten

2 Der laves en kopi af det valgte objekt i mimikområdet

3 Brugeren flytter objektet hen på en ønsket placering og slipper museknappen

4 Objektet vælges som det aktuelle objekt, og parameterpanelet opdateres

Use Case Skift størrelse på objekt

Mål At ændre størrelse på objekt

Antagelser Programmet er startet, og der er tilføjet/oprettet et objekt til mimikområdet. Polygoner kan ikke skifte størrelse.

Skridt Handling

1 Brugeren vælger ’Resize’

Appendiks

2 Brugeren vælger objekt i mimikområdet

3 Objektet markeres som valgt, og en firkant vises i hvert hjørne af objektet

4 Brugeren flytter en af firkanterne med musen

5 Objektet skifter størrelse afhængigt af firkanterne

Use Case Slet objekt

Mål At fjerne et objekt fra mimikbilledet

Antagelser Programmet er startet, og der er tilføjet/oprettet et objekt til mimikområdet.

Skridt Handling

1 Brugeren vælger et objekt

2 Objektet markeres som valgt

3 Brugeren trykker på ’Delete’

4 Objektet fjernes fra mimikområdet, og intet objekt er valgt

Use Case Ændr parameter

Mål At modificere et objekt, ved at ændre på dets parametre

Antagelser Programmet er startet, og der er tilføjet/oprettet et objekt til mimikområdet. Objektet har parametre der kan ændres.

Skridt Handling

1 Brugeren vælger et objekt

2 Objektet markeres som valgt

3 Parameterpanelet opdateres, så det indeholder parametre for objektet

4 Brugeren klikker på den parameter der skal ændres

5 En liste med samtlige mulige parametre kommer til syne

6 Brugeren vælger en parameter

7 Listen med mulige parametre lukkes

8 Objektet opdateres med den nye parameter

Use Case Zoom ind

Mål At zoome ind på et område

Antagelser Programmet er startet

Skridt Handling

0 Appendiks B: Use-cases 9

1 Brugeren trykker på ’Zoom in’

2 Brugeren markerer et område i mimikbilledet

3 Zoom faktor skiftes til at passe med det markerede område

4 Der scrolles automatisk til det markerede område

Appendiks

Appendiks C: Sekvensdiagrammer

Figur 10.1 - Opret objekt

0 Appendiks C: Sekvensdiagrammer 11

Figur 10.2 - Tilføj objekt

Appendiks

Figur 10.3 - Skift størrelse på objekt

0 Appendiks C: Sekvensdiagrammer 13

SystemBruger

Vælg objekt

Marker objekt

Tryk på ’Delete’

Fjern objekt

Figur 10.4 - Slet objekt

Appendiks

Figur 10.5 - Ændr parameter

0 Appendiks C: Sekvensdiagrammer 15

Figur 10.6 - Zoom ind

Appendiks

Appendiks D: Klassediagram for centrale klasser

Figur 10.7 - Detaljeret klassediagram for centrale klasser