Danish Rox Hovedrapport vejleder: Steen Fredborg (skr@iha.dk) Gruppe 2 Jacob Arnvel 07251 Viet Vu 07803 Anders Damkjær 09966 Mikael Syska 06122 Thu Tran 05086 Jeremi Kiruparajan 07835
Steen Fredborg Vejleder Anders Damkjær Jacob Rune Arnvel Mikael Melballe Syska Viet Quoc Vu Jeremi Vinodeep Thu Tran 1
Resumé Dansk Formålet med projektet Danish Rox er at implementere en Scorbot ER-4U robot i produktionsapparatet for vores firma Dansk Beton. Scorbot ER-4U robotten med tilhørende programmel har til formål at automatisere en eksisterende manuel proces, hvad angår sortering og registrering af dimensionerne på de enkelte beton elementer. Registreringen foregår i en database, der er udviklet i henhold til projektets formål om at automatiserer registrering. Registreringen sker vha. Scorbot ER-4U robotten, der måler siderne på elementerne og flytter dem til en vejecelle. Det var projekt gruppens opgave at udvikle et interface til den udleverede vejecelle. På baggrund af dimensionerne, samt vægten på elementerne, er det muligt at udregne densiteten for elementerne. Densiteten af elementerne er opdelt i fem intervaller, som korresponderer med en farve, med tilhørende opbevaringsrum. Til Scorbot ER-4U robotten medfulgte programmel, usbc.dll, som gør det muligt at styre robotten. Det var projektgruppens opgave at kode et C# program op imod dette programmel, for at kunne programmere robotten til at udføre specifikke opgaver i henhold til automatiseringen af den manuelle proces. Til at styre Scorbot ER-4U robotten, og programmere den til at udføre sortering og registrerings processen, skulle projektgruppen udvikle en Graphical User Interface(GUI). Det skulle gennem GUI være muligt at starte/stoppe robotsystemet, aflæse status for sorteringsprocessen, arbejde med data i databasen og lave et programmerbart program til styring af robotten. Hvad angår de væsentligste resultater, i projektgruppens implementering af Scorbot ER-4U robotten, kan for de enkelte dele af projektets udvikling nævnes: - Databasen: Registreringen af dataen er persistent vha. en database. Brugen af LINQ 2 SQL har gjort persisteringen af data i databasen meget simplere da man herigennem har mappet sine entiteter til klasser. 2
- Vægten: Vejecellen er præcis nok, da der kun forekommer en afvigelse på 2,3% unøjagtighed. Til det miljø som Scorbot ER-4U robotten er opstillet i er en vejecelle som denne mere end tilstrækkelig. - Wrapper software til usbc.dll: Koden er logisk opbygget efter KISS princippet (keep it simple and stupid). Dette gør koden let at overskue og det er dermed let at bygge videre på koden og gøre videre brug af Scorbot ER-4U robottens funktionalitet. - GUI: Har et simpelt design, funktionaliteten fremgår tydeligt og den er logisk at navigere rundt i. GUI er ligeledes opbygget efter KISS princippet. Det er nemt at overtage koden og videreudvikle funktionaliteten i GUI. 3
English The project Danish Rox aims to implement a Scorbot ER-4U robot in the production environment at our company Dansk Beton. The Scorbot ER-4U robot and associated software is designed to automate an existing manual process in terms of sorting and recording the dimensions of the various concrete elements. The elements data is stored in a database, this is done to automate the registration process. The registration happens when the Scorbot ER-4U measures the sides and moves the elements to the load cell. The project team was tasked with developing an interface to the supplied loadcell. Given the dimensions and weight of the elements, it is possible to calculate the density. The density of elements is divided into five intervals, which is colorcoded, and each color is associated with a storage space. To Scorbot ER-4U robot is supplied with software, usbc.dll, that makes it possible to control the robot. The project group's task was to code a C # program against this software to program the robot to perform specific tasks according to the automation of the manual process. To program the Scorbot ER-4U and create the sorting algorithm and registration process, The project team was to develop a Graphical User Interface (GUI).It should be possible through the GUI to start / stop the robot system, read the status of the sorting process, work with data in the database and create a programmable program for controlling the robot. Regarding the main tinges of interest project team have encountered, in developing the program for the Scorbot ER-4U robot, we can for each part of the project development include: - Database: The registration of elements is made persistent using a database. Using LINQ 2 SQL has made persisting the data in the database much simpler, because in using this framework we have mapped the entities in the database to the classes in the program - Weight: The load cell is accurate enough, as there seems a discrepancy of only 2.3% inaccuracy. To the environment as Scorbot ER-4U robot is set in, this load cell as this is more than adequate. - Wrapper software to the usbc.dll: The code is logically structured according to the KISS principle (keep it simple and stupid). This makes the code easy to read and it is thus easy to extend and 4
implement other uses of Scorbot ER-4U robot's functionality. - GUI: Have a simple design, the functionality is clear and it is logical to navigate around in. GUI is also built on the KISS principle. It's easy to take the code and further develop the functionality of the GUI. 5
Indholdsfortegnelse Resumé... 2 Dansk... 2 English... 4 Indledning... 8 Læse vejledning... 9 CD ens mappestruktur.... 9 Projektbeskrivelse... 10 Projektgennemførelse...10 Arbejdsmetoder...10 Specifikations- og analysearbejdet...12 Database... 13 Log komponent... 13 Vægt og VoiceDetector... 14 RobotInterface... 15 Designproces...16 Design Processen... 16 Software design løsninger... 17 Singleton af AppLog... 19 Strategy Patterns... 19 GUI Opbygning... 19 Udviklingsværktøjer...21 Visual Studio 2008... 21 Microsoft Office Word 2007... 21 Microsoft Office Excel 2007... 21 Microsoft Office Project 2007... 21 Visual Paradigm 7.0 Standard edition... 21 SQL Server Management Studio 2008... 22 Visual Paradigm 7.1 Professional Edition... 22 CVS i projektet... 22 Enterprise Architecture... 23 Code Vision AVR... 23 Resultatet...23 6
Vægt... 23 Robot... 23 Databasen... 23 GUI... 24 Diskussion af Resultater...24 Vægt... 24 Databasen... 24 GUI... 24 Robot... 24 Projekt fortræffeligheder...25 AppLog/ILogger... 25 Drag n Drop... 25 Forslag til forbedringer af projektet og produktet...26 CRC check sum... 26 Understøttelse af flere forskellige databaser... 26 ILogger... 26 Konklusion... 27 Del konklusion...27 Vægt... 27 Robot... 27 Databasen... 27 GUI... 27 Afsluttende konklusion...28 Bilag... 29 7
Indledning Til projektet Danish Rox har vores firma Dansk Beton indkøbt en Scorbot ER-4u robot med tilhørende programmel, med det formål at automatisere en eksisterende proces, der indtil nu er blevet foretaget manuelt af medarbejdere. Processen består af følgende forløb: Rektangulære betonelementer af varierende massefylde og dimensioner ankommer i vilkårlig rækkefølge på et transportbånd. Elementerne stopper ved en sensor monteret på transportbåndet. Herfra måler Scorbot ER-4u robottens gripper dimensionerne på elementet og flytter dette til en vejecelle. Fra vejecellen flyttes elementet til et opbevaringsrum. Det er projektgruppens hovedopgave at implementere Scorbot ER-4u robotten med dertilhørende database, simulator, vejecelle, VoiceDetector interface samt GUI. Databasen skal gemme alle relevante data fra denne proces. Simulatorens formål er at simulere robotten uden at interagere med hardware. Vejecellen skal veje de enkelte elementer. VoiceDetector gør det muligt for brugeren at starte/stoppe robotten. GUI viser alle relevante oplysninger for brugeren, de forskellige logs, robotten samt IDE. GUI skal samtidig gøre det muligt at programmere robotten til at udføre specifikke opgaver. Formålet med denne rapport er at informere læseren om projektets størrelse, formål, arbejdsmetoder, udviklingsværktøjer, resultater samt opnåede erfaringer. Det er en forudsætning, for forståelse af denne rapport, at læseren har nogen viden inden for udvikling af projekter af denne type, samt har adgang til kravspecifikation, designdokumentet og brugervejledning. 8
Læse vejledning Der udarbejdes følgende dokumentation til projektet som afleveres med det færdige system. Udviklingsdokumentation som består af: o Kravspecifikation o Designdokument o Enhedstest o Accepttest o Hovedrapport Programdokumentation med kildekode (udleveres kun på CD-ROM). Brugervejledning Dokumentationen afleveres på papirform og på CD-ROM. CD ens mappestruktur. Bilag Diverse bilag til rapporten CodeVision guide Guide til at compile C kode i CodeVision Doxygen Doxygen installations filer, inkl graphviz Install Installations filer til TheClawInterface og sql filer opsætning af databasen Klasse Dokumentation Dokumentation genereret af Doxygen Rapport Vores 5 rapport dokumenter RobotProjekt Hele vores C# codebase til PC en Weight_C-kode Hele vores C codebase til vægten 9
Projektbeskrivelse Projektgennemførelse Da vi mødtes i gruppen første gang for at prøve at finde ud af hvordan vi skulle gribe denne opgave an, fandt vi hurtigt ud af at en af de store udfordringer, i forhold til det organisatoriske, ville blive vores skiftende skemaer. Der var kun 3 i gruppen der fulgte det samme skema. Det vi gjorde var at aftale på nogle specifikke tider i løbet af ugen, for at kunne holde hinanden opdateret - mandag kl 14.15 - onsdag kl 12.00 - fredag kl 12.00 Den primære dag vi sørgede for at være der var onsdag, da vi også den dag havde møde med vores vejleder. Vi startede med at holde et møde, hvor vi lavede et brain storm over hvad der skulle være med i systemet. Vores fokuspunkter i projektet var temmelig hurtig delt op. Mikael, Thu og Viet tog sig af Database delen, Jeremi og Thu fokuserede sig på vejcellen, Jeremi og Anders koncentrerede sig om Robot delen og ikke mindst Jacob samlede kravspecifikations dokumentet sammen. Disse grupperinger blev i stor grad bestemt af hvem der ikke havde skemalagte timer samtidig. Fordelen ved at foretage denne opdeling var at det betød at gruppen var meget fleksibel i udviklingen af systemet. I realiteten betød det at vi havde udviklet flere separate sub-systemer, som senere hen i projektet skulle merges sammen til et. Arbejdsmetoder I vores gruppe har vi valgt at arbejde efter scrum metoden, for at se hvordan det ville være at arbejde efter en anden metode end Unified Process. En ting vi var nødt til at tage højde for i vores arbejdsgruppe var at finde en måde hvorpå vi kunne arbejde sammen uden at skulle møde så tit. Dette blev vi nødt til fordi ud af de 6 personer der var i gruppen, var der kun 3 der fulgte det samme skema. Denne udfordring løste vi ved at opdele systemet i komponenter, og dette gjorde at vi delte gruppen op i mindre komponent grupper. De små komponent-grupper blev dannet efter skemaernes 10
ledigheds plads. Vi blev dog nødt til at lave vores egen afart af scrum bla.pga. de omstændigheder vi udviklede under. De ting vi havde med fra scrum var: - Dag møder, der blev til uge møde da det var det vores forskellige tids skemaer tillod. Her diskuterede vi hvor langt vi var kommet siden sidste uge og hvad vi skal lave til næste uge - En tavle til at repræsentere vores produkt backlog, hvor vi kunne samle alle de arbejdsopgaver vi havde identificeret, som skulle laves i forhold til projektet. Figur 1 Den ovenstående figur viser vores tavle hen imod slutningen af projektet. På denne tavle havde vi 4 aktive kategorier: - Projekt, hvor alle ting der kunne komme med i projektet blev skrevet op. - Tasks, de arbejdsopgaver som vi vurderede skulle med i projektet. - Progress, de arbejdsopgaver som et projekt medlemmerne havde taget ansvar for. - Done, de opgaver som var lavet færdig. 11
Da vi skal aflever en del dokumentation i forhold til projektet har vi stadig dele af UP med: - Kravspecifikation - Use Cases - Diverse diagrammer Disse dokumenter blev lavet undervejs i projektet som det passede i forløbet.eksempelvis lavede vi meget tidligt et pakke/ komponent diagram så vi kunne dele projektet op i mindre bidder som gruppe medlemmer kunne byde ind på. Men da vi havde valgt at bruge scrum, der hvor vi kunne, så vi valgte at lave 2 sprints.her valgte vi at kode de enkelte komponenter, i forhold til det som var mest need to have. Disse 2 sprints blev planlagt ind som 2 milepæle. Så kunne de enkelte grupper selv planlægge deres arbejdstid, så længe de holdt deres ugentlige møder. Specifikations- og analysearbejdet Resultatet af de komponenter, som vi ville have, ser således ud: - En GUI komponent. - RobotGUI - En komponent der interfacer med den dll der kontrollere robotten - RobotInterface. - En komponent til vægten - ComPort. - En komponent der sørger for at man kan logge forskellige ting BusinessLogic.log. - Databasen og et DAO objekt man kan tilgå den i gennem - Repository. - Til slut en komponent der kan binde alle komponenterne sammen - BusinessLogic 12
Database Faget DAB1 kørte parallelt med vores projekt.i DAB1 lavede vi et udkast til vores database til første iteration. Udviklingen af databasen blev sat på pause i forbindelse af eksaminer og afleveringer i andre fag. Da DAB1 faget var overstået, tilpassede vi databasen efter det system vi havde med at gøre. Vi startede, med at lave et ER diagram med de 3 komponenter, som blev vores første udkast til hvordan databasen skulle se ud. Derefter testede vi, at vi kunne INSERT, UPDATE og DELETE i vores database. Dette udkast passede ikke indtil systemet, som vi oprindeligt havde tænkt på. Så derfor valgte vi at lave et nyt udkast, som ville passe bedre med de krav vi havde til databasen.i udkastet havde vi valgt at logge en Bruger og Robotten, men senere hen kom der også et BatchJob. Det sidste vi skulle blive enige om var, hvilke data vi skulle logge ned i vores database. Det blev så vores endelig udkast til vores database. Log komponent Inden vi begyndte at lave log komponenten havde vi gennemtænkt en plan for, hvordan vi ville logge informationer for systemet. Gruppen blev enig om, at det skulle laves som en singleton, for at undgå at sende referencer rundt i systemet. Det gør det nemmere at bruge log komponenten, fordi man ikke skal holde øje med referencerne. Til at starte med dette, lavede vi en funktion med en switch case, som skulle logge dataene ned til databasen afhængig af hvilken slags logs vi vil logge til. Vi kom dog frem til at det ikke var så smart, da hele funktionaliteten ville ligge inde i en klasse. Derefter besluttede vi os for at splitte funktionaliteten ud i flere klasser, hvor de arver fra et interface klasse, som brugeren bruger. Dermed virker funktionaliteten ud fra hvad brugeren gør. Derefter lavede vi nogle test, for at se om dataene blev logget rigtig ned i databasen, når vi requestede det. 13
Vægt og VoiceDetector Vi skulle finde densiteten for beton elementerne. Hvilket gjorde vægten til en nødvendighed. I udviklingen af interfacet til vægten, gjorde vi os en del overvejelser. Ikke alle overvejelserne blev implementeret. Vægten havde ikke nogen lineær graf i intervallet fra 0-100 g og 850-950 g. Derfor overvejede vi at lave tre funktioner, en for hvert af de 3 intervaller: 0-100, 100-850 og 850-950. Vi besluttede os for kun at lave funktionen der tog sig af værdierne i intervallet fra 100g til 850g, da denne var lineær, og de vægt-værdier vi skulle bruge i projektet var fra 0g til 250g. Til at løse problemet med unøjagtighed i intervallet fra 0-100 g, valgte vi at sætte en 100g plade på vægten. Det ville være vores nye nulpunkt, og betyde at vi maksimalt kan komme op og måle en maksimal vægt på 750g. Disse måleresultater sættes ind i et Excel-dokument med tilhørende vægt-værdier. Dette gav os en graf med en forskrift f(x) = 0,976*x, hvilket gav os en afvigelse på 2,35 %, og dette kan ses ved den nedenstående graf. 800 700 y = 0,9765x R² = 1 600 500 400 300 200 100 0 0 100 200 300 400 500 600 700 800 Figur 2 Kalibreringsgraf En anden overvejelse vi gjorde os omkring implementeringen af vægten var at tilføje et CRC-check, så vi kunne bekræfte, at den modtagne data var identisk med det sendte over seriel kablet. Dette blev ikke implementeret, da det er en Nice to Have feature, samt det ikke var nødvendigt i vores system. Vi har valgt at ligge vægten og VoiceDetector i samme namespace, fordi de minder meget om hinanden. De læser begge fra SerielPorten. 14
RobotInterface Under konstruktion af Robot komponenten prøvede vi at tage en scrum tilgang til problemdomænet. Vi besluttede at dele vores udvikling process op i 2 store sprints og et mindre til sidst. Det mente vi at vi kunne nå på de 3 måneder, der var til rådighed. I det første sprint lagde vi primært vægt på en user story, hvor brugeren skulle kunne flytte robotten uden brug af koordinater. Det vi inkluderede i sprintet, var de funktioner der skulle implementeres, for at dette kunne lade sig gøre. Det vil sige både opstart af robotten, om den er online og at man kan åbne og lukke kloen blev dermed implementeret i dette sprint. Vi læste dokumentationen igennem og kom frem til denne liste af funktionalitet, der skulle være brugbart efter første sprint: Initialization(), Home(), Control(), CloseGripper(), OpenGripper(), GetJaw(), CloseManual(), MoveManual(), EnterManual(), IsOnlineOk() I andet sprint fokuserede vi på en user story, der handler om at brugeren skulle kunne flytte robotten rundt vha. koordinater. For at opnå dette skal man kunne gemme en position, definere en liste af koordinater i robotten og så lægge koordinater ind i listen. Derudover skulle vi også bruge et par funktioner fra sidste sprint. Det var metoden til at modtage et input fra sensoren, som er monteret på transportbåndet, og at kunne overvåge robottens bevægelser. Listen af funktionalitet, der skulle være brugbart efter andet sprint omfattede disse funktioner: WatchMotion(), GetCurrentPosition(), CloseWatchDigitalInp(), WatchDigitalInp(), DefineVector(), Teach(), MoveLinear(), CloseUSBC(), Stop() Sidst i hver sprint testede vi de funktioner vi havde implementeret. I det sidste sprint samlede vi de funktioner til et endeligt interface. Her beslutte vi f.eks. at samle forskellige funktioner til 15 Figur 3
en funktion i interfacet, så det blev nemmere at overskue for brugeren af interfacet. Et eksempel er: public bool RobotStartup() { InitializeRobot(); Control(); WatchMotion(); CloseGripper(); Home(); return IsOnLineOk(); } Undervejs i projektet, holdt vi styr på opbygningen af vores komponenter, med et simpelt klasse diagram tegnet på whiteboard. Ved siden af vores udviklings arbejde har vi synkroniseret vores komponenter med de Use Cases og kravspecifikation, som side løbende blev ud arbejdet. Dette blev gjort, fordi det skal være en del af dokumentationen, der skal afleveres til sidst. Designproces Design Processen I starten af semesteret lavede vi en Tidsplan, hvor vi satte nogle milepæle op for at se, hvornår del komponenterne skulle være færdige. Disse milepæle skulle de enkelte komponent-grupper bruge til at lave deres egne tidsplaner. I projektet havde vi to afleveringer, som vi skulle fremvise for vores gruppe. Den første store aflevering lå efter efterårsferien, hvor vi alle skulle være sikre på hvad problemdomænet var. Den anden store aflevering var til den 1. december, hvor implementeringen skulle være færdig, og hele projektet skulle være køreklar. De enkelte komponent-grupper havde frie tøjler, men de skulle bare overholde vores egne afleveringer tidspunkter. Herefter skulle vi lave Hovedrapport og dokumentation. Dette kan ses på CD`en på stien: CD/bilag/BILAG - Milepæl, som viser det grafiske tidsplan/milepæle. Opdelingen i de enkelte komponent-grupper en meget logisk opdelt. Logikken fremstod tydeligt hvis man så på de enkelte personers skemaer. Grunden til dette var fordi, nogle af os havde haft 16
database, og det var dem der tog sig robotten og dll`en. Dem der tog sig af vægten og VoiceDetector var dem, der havde/havde haft INF1. Databasen og GUI blev så lavet af dem der havde DAB1 og WIN1. Dll`en blev lavet i fire iteration som det ses i tidsplanen, som ligger på CD`en på stien: CD/bilag/BILAG - Tidsplan. I den første iteration gjaldt det om at få hul igennem dll`en, så vi kunne kommunikere med robotten. I den anden iteration valgte vi de funktioner vi synes, vi skulle bruge ud fra USBC-dokumentationen. I tredje iteration udvidede vi de valgte funktioner og tilføjede andre nødvendige funktioner. I fjerde iteration, som er den sidste iteration, samlede vi flere funktionerne i en funktion. F.eks. Startup, som indeholder Init, control, home og wacthdigitalinp, hvilket gør det nemmere for brugeren. Herudover blev der kommenteret i koden. Vægten blev lavet i to iterationer. For det første skulle vi lige forstå hvordan vægten fungerede. Herefter kunne vi se, at vi havde lavet en lignende opgave i et tidligere semester, men med nogle små forskelle. Så vi tog udgangspunkt i den tidligere vægt-opgave. I den anden iteration implementerede vi vægten, hvor der også blev lavet et interface til denne. Så vi brugte det samme princip i udviklingen af et interface til vores VoiceDetector, som vi brugte i udviklingen af interfacet til vægten. VoiceDetectoren er et komponent, som vi får af signal gruppen. Databasen blev lavet i to store iterationer. Databasen er meget sammenkoblet med DAB1 faget, hvor det også var en del af faget at prøve på at lave et udkast til projektet. Det var vores udgangspunkt. I anden iteration besluttede vi os for at bruge LINQ to SQL, for det ville gøre det nemmere at tilgå databasen, og dette var vores data-access layer. GUI`en blev også lavet i to iterationer. Den første iteration var selve design-beslutningen. Dette blev hele gruppen hurtigt enige om at det skulle være drag and drop, så det var vores udgangspunkt. Den anden var den sidste iteration, hvor GUI`en skulle være færdig. I hele forløbet havde vi ofte kommunikeret med de interne grupper. Både for at have en ide om hvor langt vi var kommet i projektet, men også for at kunne hjælpe hinanden. Denne teknik gjorde at vi ikke sad fast i det samme problem alt for længe. Software design løsninger Under forløbet af designet, har vi anvendt flere design patterns til at beskrive dele af den funktionalitet vi har tænkt os at implementere. Dette gør at man nemmere kan beskrive den 17
funktionalitet vi har implementeret. I IRobotInterface har vi gjort brug af adapter pattern, for at kunne oversætte dll en på en mere simpel måde. Vi har tænkt på at det kan være en god ide, også at anvende singleton pattern, men da der på sigt skulle være mulighed for at koble flere robotter til vores program, mener vi at dette vil være en forkert design beslutning. Der bliver også brugt observer pattern, i form af.net s events. De bliver brugt til at returnerer de asynkrone kald imellem vores tråde. 18
Singleton af AppLog Formålet med AppLog klassen er at holde informationer, som skal være tilgængelige alle steder i systemet. Dvs. det er en global variabel, samt globale tilgængelige metoder. Da klassen AppLog er lavet som Singleton, medfører det også, at man ikke kan arve fra denne klasse. Derudover er den også sikret mod multi-threads. Strategy Patterns Vi har valgt at bruge dette design mønstre, da indkapslingen af hver metode gør det nemmere at skifte og tilføje andre metoder. Strategy gør, at man kan variere metoder uafhængig af hvad klienten gør.filelogger, ConsoleLogger, ListLogger og SqlLogger kan ved hjælp af strategy pattern behandles ens. Det der skelnes imellem den er hvor de logges. Denne måde skjuler man også data, som brugeren ikke behøver at vide noget om. Derved får vi også low-coupling. Dermed undgår vi mange linje kode med if-sætninger, og adfærden flyttes til de enkelte klasser. GUI Opbygning Gui en er opbygget ud fra et Window, som har en Menu i toppen status bar i bunden, og så en Frame hvor vi navigere rundt i vores Pages som kan loades i den Frame. Der bliver kun brugt få dialog bokses og alle sammen bliver åbnet som en Modal dialog. Det er kun vores Log Window der bliver åbnet som en Modeless dialog. Overvejelser undervejs Figur 4 19
Vi havde inden vi besluttede os for omkringstående design skitser, tænkt på at lave det med en masse TabPages, men synes det gav et rodet design, og ikke fulgte KISS princippet. Så vi besluttede os for en simpel menu struktur, som de fleste brugere er bekendt med. Figur 5 20
Udviklingsværktøjer Visual Studio 2008 Anvendt til alle C# programmeringsopgaver til The Claw projektet. Det er et udmærket værktøj med indbygget debugger, der er ganske anvendelig til fejlfinding i et større projekt. Dog har det sine egne særheder man er nødt til at vende sig til. Det er umiddelbart ikke gennemskueligt hvor importerede filer er gemt på drevet, når de importeres i et projekt. Der bliver nemlig ikke linket til dem, når de importeres i projektet, men de skal være inkluderet rigtigt i kildekoden. Microsoft Office Word 2007 Word 2007 har vi brugt til at lave de forskellige tekstdokumenter. Havde det ikke været for Word s skyld ville det sikkert været en omgang rod med at kopiere, rette og lave indholdsfortegnelse til de forskellige dokumenter. Microsoft Office Excel 2007 Excel 2007 har vi brugt til at beregne en graf til vægten. Grunden til dette er at vi har foretaget nogle analoge målinger, som vi har indtastet i Excel, som så selv kunne beregne en graf og en forskrift for denne. Microsoft Office Project 2007 Project 2007 har vi brugt til at lave en tidsplan. Dette program gør det meget overskueligt, så man kan vise tidsplanen grafisk. Ud over tidsplan har vi også lavet den endelige procesgang i dette program. Visual Paradigm 7.0 Standard edition Der er blevet brugt Visual Paradigm for UML 7.0 Standard Edition til at lave de forskellige UML diagrammer. Det har været et godt program at bruge, medhenblik på at lave de forskellige 21
diagrammer. Det har været meget nemt og overskuelig at bruge, og til dels nem at redigere i efterfølgende. Derudover har programmet også den funktion at lave diagrammer om til et billede fil som man ønsker, så man ikke behøver at tage et screenshot af diagrammerne. SQL Server Management Studio 2008 SSMS er blevet anvendt til at lave vores database. Det har været meget lige til at bruge, med henblik på at oprette og slette tabeller i vores database. Det giver et utroligt godt overblik over relationerne i vores database. Derudover har det været nem at slette og redigere i efterfølgende. Derudover har vi brugt det til at oprette nogle views tabeller, og implementere nogle stored procedures. Man kan hurtigt finde ud af om, der er blevet ændret noget i databasen, ved at skrive nogle SQL kommandoer. Visual Paradigm 7.1 Professional Edition Visual Paradigm 7.1 Professional Edition 1 er blevet brugt til at generer ER diagrammer og stored procedures fra vores database. Det kræver dog, at man enten køber programmet, for at kunne bruge det, eller man kan vælge at prøve det gratis i 30 dage. Man skal registrere sig for at få tilsendt en key. Der var dog andre muligheder, at lave ER diagrammer på, som vi havde lært i DAB1 faget med DDS Lite, men det synes vi var lidt for uoverskueligt. Derfor besluttede vi os for, at bruge dette program. CVS i projektet I projektet har vi anvendt en CVS system til backup og udveksling af kode. På server siden har vi anvendt google code, på klient siden tortiosesvn, der arbejder på mapper i stifinder, og visualsvn., der integrerer direkte i visual studio 2008. Versionerings systemet har været en stor hjælp i projektet både til at udveksle kode imellem projekt deltagerne. Den kan også holde styr på hvilke version af et kodedokument, der er det nyeste. Hvis man kommer til at skrive på et der ikke er af det nyeste version kan programmet også, for det meste, finde ud af at flette dine ændringer ind i det eksisterende dokument. 1 http://www.visual-paradigm.com/download/dbva.jsp 22
Enterprise Architecture Til projektet har vi brugt Enterprise Architecture til at designe vores 3 lags model og UC diagrammer. Enterprise Architecture er et UML editor program, som overholder UML standarden. Det smarte ved programmet er, at vi kan definere et namespace og tilføje klasser til det bestemte namespace. Det giver overblik over alle vores namespaces, og de enkelte namespaces indhold. Yderligere kan man autogenerere klasserne ved hjælp af at loade cs-filerne fra projektet. Hvilket vil generere klasserne og associationerne mellem klasserne. Code Vision AVR Vi har brugt CodeVision til at programmere vores mikrocontroller. Programmets funktionalitet er generelt ok, men programmet har mange mærkelige måder at gøre ting på. Jeg forstår ikke udviklerne af programmet ikke følger de almindelige standarder, for hvordan en editor bør virke. Måden de har lavet deres på, er ikke innovativ eller på nogen måde bedre, tværtimod. Det virker mere som et skridt i den modsatte retning, hvilket er synd. Resultatet Vægt Vægten virker som den skal, for den kan sende os den målte vægt for et element over til PC`en. På PC-siden er der lavet et interface for at tilgå de måledata. Ved målinger er der forekommet en afvigelse på 2,3 %. Robot Vores dll-wrapper er en succes, fordi den vha. interfacet til vores komponent kan tilgå robots funktionalitet fra C#-kode. Uden at man skal tænke på managed og unmanaged kode problematikken. Databasen Database komponenten præsenteres som en funktionel database, som gør det muligt at lagre data til databasen. Efter der er kørt et batchjob i vores system gemmer systemet data ned i databasen, som matcher de opstillede krav i kravspecifikationen. Kommunikationen mellem databasen og vores applikation med LINQ, har været mere simpel end forventet, da entiterne er blevet mappet til klasser. 23
GUI GUI en har fået et utroligt simpelt look, dog stadig med brugervenlighed som den væsentlige faktor. En grafisk designer ville kunne give den et virkeligt professionelt udseende. Databinding på GUI elementer har virkelig været nemt via ObservableCollection og INotifyPropertyChanged. Diskussion af Resultater Vægt Det opnåede resultat er acceptabelt, for det skal bruges i et miljø, hvor det ikke kræver den store nøjagtighed. Med en afvigelse på 2,3 % er vejecellens nøjagtighed mere end tilstrækkelig. Databasen Vi er som gruppe stolte af resultatet af databasen og dens funktionalitet. Da den persisterer de valgte data ned i databasen. Funktionaliteten af databasen, udviklet til firmaet Dansk Beton, opfylder alle GUI ens krav for at persistere data. Vi har formået, at opnå målet som vi havde sat os fra starten af. Databasen opfylder alle kravene til dette system i forbindelse med det dataflow der er tiltænkt i dette projekt. GUI Gui ens simple opbygning har gjort det muligt for den almindelige bruger hurtigt at navigere rundt i brugergrænsefladen. Hvis vi ikke havde brugt databinding, havde vi helt sikkert skabt en masse problemer for os selv. Da vi så selv skulle stå for at kopiere data frem og tilbage mellem vores GUI og vores data klasser. Robot De funktioner vi har valgt at implementere dækker kun det behov som vi på nuværende tidspunkt har haft behov for. På sigt kan det være at der bliver brug for at implementere flere funktioner. Dette har vi ikke taget højde for. Men den opbygning vi har lavet i komponenten er det simpelt at tilføje nye funktioner. 24
Projekt fortræffeligheder AppLog/ILogger Implementeringen af ILogger interfacet hører ind under strategy patterns. Det smarte ved denne implementeringen er, at det nemt kan udvides med andre måder at logge på. Det kunne eksempelvis være til Windows EventLog 2. Der skal så bare arves fra det interface, og implementerer de nødvendige metoder og properties. Drag n Drop Som man kan se på skitsen til højre var vores første ide at man skulle bruge en knap til at overføre BatchJobTaskPositions til BatchJobTask listen. Men da det også skulle være muligt at ændre på rækkefølgen af tasks i listen, ville det kræve flere knapper. Da vi følger KISS princippet3, synes vi det blev for meget. Vi valgte derfor at implementere Drag n Drop, som giver en super lækker bruger oplevelse. Figur 6 2 http://en.wikipedia.org/wiki/event_viewer 3 http://en.wikipedia.org/wiki/kiss_principle 25
Forslag til forbedringer af projektet og produktet CRC check sum Vi kunne have brugt en CRC check sum mellem vægtcellen MP40 og PC en. Dette vil sikre os, at data som bliver sendt over seriel kablet RS-232 er den samme som den vi modtager. Det vil sige at med CRC, kan vi verificere data som vi modtager i PC siden. Der genereres en checksum for hvert payload og denne tilføjes som header. Når et payload overføres, sammenlignes checksummen (CRC-filen) for det afsendte payload med en ny genereret checksum ved modtagelsen. Hvis der er uoverensstemmelser, meddeles CRC-fejl. CRC er nødvendigt, fordi at der kan, i værste tilfælde, forekomme støj på serielkablet. Det vil påvirke resultatet og vægten af vores målte element vil være mere upræcist. Vi mente at CRC ikke var et Need to have, men Nice to have. I stedet for CRC har vi implementeret en funktion som frasorterer mulige fejl der kan opstå under en transmission. Understøttelse af flere forskellige databaser Der kunne laves udvidelser for at understøtte flere forskellige databaser. Ved at ekstrahere et interface fra Repository med alle brugte methods, og derefter lade den arve fra det. Derefter kan man lave en OracleRepository klasse som arver fra det interface. Implementere de nødvendige metoder og i stedet for at bruge en LINQ to SQL datacontext, kan man bruge de forskellige klasser fra: System.Data.OracleClient for kommunikere med en Oracle database. ILogger Der kunne laves en ILogger mere, som logger til event loggen i Windows. Det kunne være smart hvis firmaet kun havde en computer med TheClawInterface 26
Konklusion Del konklusion Vægt I udviklingen af interfacet til vejecellen til dette projekt er vi nået frem til et tilfredsstillende resultat. Med en vægt afvigelse på 2,3 % er vægten henved optimal til at fungere som en måleenhed i dette system. Koden er implementeret på en forståelig måde og sammenholdt med kommentarerne i koden, kan man let sætte sig ind i den. Den procentvise afvigelse er kun i intervallet af 100-850 gram, idet vi kun benytter regneforskriften for dette interval. Dog er det en prækondition at der skal være en 100 grams offset plade på vægten, hvilket fungerer som et nyt nulpunkt for vejecellen. Der foretages 100 målinger af hvert element, der placeres på vejecellen. Dette medfører at den statiske støj undertrykkes. Dette giver igen et mere pålideligt resultat. Robot Under udvikling af USBC-komponenten har vi stiftet bekendtskab med problematikken mellem managed og unmanaged kode. Den viste sig at være en stor udfordring, men da vi gik til opgave med en metodisk tankegang, synes vi, at vi fik lavet en god løsning. Vi mener selv at vi har lavet en let overskuelig komponent, dvs. vi har fuldt KISS princippet meget godt. Databasen Til at starte med var det svært at finde ud af hvordan databasen skulle bygges op og hvordan man kommunikerede med databasen. Derfor blev der brugt en del tid på at finde ud af hvordan LINQ 2 SQL fungerede. Da vi så endelig havde fået, banket det ind i hovedet kørte det der ud af. Dog synes vi, at der godt kunne tilbydes bedre værktøjer til at oprette en database og lave de forskellige diagrammer. GUI En af de ting som er rigtigt fedt ved WPF er muligheden for at skinne sine controls via XAML. Det har vi dog ikke haft muligheden for at bruge, da vi ikke har en grafiskdesigner i gruppen, som kunne lave et virkelig smooth design til os. WPF er virkelig et kvalitets produkt fra Microsoft, hvilket også kan ses på Silverlight, som også bygger på mange af de samme koncepter som WPF. 27
Afsluttende konklusion Projektet har været en god oplevelse på mange måder. Der har været mere udfordring i dette projekt, set i forhold til forrige semester projekter.dette semester projekt har været et meget mere selvstændigt projekt. Til dette projekt fik vi udleveret et meget skrabet produktoplæg set i forhold til tidligere semestre. Dette gav os meget frie hænder hvad angår specielt udviklingen af GUI, men også hvordan vi valgte at udforme vores database. Tildels også hvordan vi valgte at programmere robotten, ved enten at kode op imod Robot.dll en eller ved at hacke fortolkeren. Situationen med frie hænder i forbindelse med projektet var derfor nyt og spændende. Den øvrige dokumentation vi fik udleveret var meget omfattende, næsten uoverskuelig. Dette betød at de beslutninger vi tog tidligt i forløbet har haft langt større konsekvenser for resten af forløbet end vi tidligere har prøvet. Vi delte systemet op i delkomponenter, for at vi kunne arbejde uafhængig af hinanden i mindre arbejdsgrupper. Det har været virkeligt fænomenalt at arbejde på denne måde, så hver arbejdsgruppe ikke har været så afhængig af hinanden. Det reflekterer arbejdsgangen i en moderne IT virksomhed. Det samlede resultat af projektet, har gjort det muligt for os at automatisere en eksisterende manuel proces af sorteringen samt registrering af beton elementer. Denne foregår vha. GUI hvor det også er muligt at programmere robotten. Registreringen af elementer, logs, densitet med mere er opfyldt i forhold til kravspecifikation, som er udarbejdet af det udleverede projektoplæg. Ligeledes er kravene omhandlende automatisering af sorteringen opfyldt. Databasen opfylder kravene om registrering af data og, underforstået, persistering af denne data. Vejecellen er blevet implementeret i systemet vha. vores udviklede interface. Vægten spiller, lige som de andre elementer i systemet, en central rolle i opfyldningen af de udstukne krav de krav som nævnes i projektoplægget og som er uddybende beskrevet i kravspecifikationen. Vi ser hermed alle de opstillede krav som opfyldt. 28
Bilag BILAG - consol test til irobotinterface.txt BILAG - funktions Liste fra usbc.dll.pdf BILAG - dll mountpoints.txt BILAG Milepæl.pdf BILAG ProjektTidsplan.pdf BILAG SamletTidsplan.pdf BILAG - USBC-documentation.pdf BILAG Databasen.pdf BILAG - Møde Referat.pdf BILAG - consol test til irobotinterface.txt 29