23. april Robert Nogal 24. maj Carletti Projekt 2012 Emil Thygesen Mads Pedersen. Carletti A/S 2012

Transkript

1 Carletti A/S 2012 Lavet af Robert Kristian Nogal Frederik Emil Pontoppidan Thygesen Side 1 af 75

2 Robert Kristian Nogal Frederik Emil Pontoppidan Thygesen Side 2 af 75

3 Indhold Informations Teknologi i Organisationer... 5 Carletti A/S (Robert & Frederik)... 5 SWOT (Fælles)... 6 Organisations form (Frederik)... 6 Produktionssystem (Mads)... 7 Produktions-filosofi... 7 Produktions-layout... 8 Produktionsstyring... 9 Produktionsformer... 9 Business Case (Fælles) Formål Forretningsmæssigt omfang IT omfang & krav Interessenter Alternativ løsning Risici Implementeringsstrategi Organisation Key Performance Indicators (KPI) Konsekvens af løsningen Logistisk effektivitet hvordan opnås det? (Robert) Leveringsservice Logistikomkostninger Vurdering af logistiksystemet Software Design Vision (Fælles) Krav (Mads & Frederik) Use-cases (Fælles) Use-case oversigt Aktør beskrivelse Use-case beskrivelser Sporbarhedsmatrix (Frederik) System sekvens diagram (SSD) (Frederik) Side 3 af 75

4 Design sekvens diagram (DSD) (Fælles) Analyse Klasse Diagram (Fælles) Tilstandsdiagrammer (Mads) Design Klasse Diagram (Fælles) Arkitektur (Mads) Testrapport (Mads) Modultest af Proces-klasse Use-case test af Opret Opskrift Status (Mads) Resume af forløbet (Robert) Refleksioner (Robert) Ordbog Software konstruktion Klassemodel (Fælles) Implementering af design-modellen Sammenhæng mellem klasserne Polymorfi JavaDoc Design Mønstre Implementering af arkitektur (Robert) Fejl håndtering (Frederik) JUnit test (Mads) Specielt interessant kode (Fælles) TimeThread & SystemDato klasserne checkvarestatus & beregnstatus metoderne ColorRender-klassen Guided Tour (Fælles) Konklusion Bilag Klassebeskrivelser Design Klasse Diagram Carletti Tidslinje Side 4 af 75

5 Informations Teknologi i Organisationer Carletti A/S (Robert & Frederik) Carletti A/S er en dansk chokolade- og slikfabrik, der har eksisteret siden Siden da er virksomheden vokset og er i dag en virksomhed, der i 2011, havde en omsætning på 644 mio. kr. 1. Carletti A/S producerer og sælger et bredt sortiment af chokolade og konfektureprodukter, som findes hovedsagligt i Danmark og Nordeuropa. Koncernen er vokset stødt siden da hvor de har indkøbt mange maskiner, fabrikker m.m. For den fulde tidsoversigt henviser vi til bilaget med tidslinjen over udviklingen. I dag består virksomheden af et moderselvskab, Carletti A/S, samt datterselskaberne, ASM Foods AB i Sverige, samt Carletti Polska i Polen hvor de ejer størstedelen af selskaberne. Derudover har de en stor andel af Oy NIS Nordic Industrial Sales, dog uden at have størstedelen. Hele koncernen har ikke skiftet ejerskab under forløbet og bliver den dag i dag stadig ejet af Givesco A/S i Give. Virksomheden består af en forholdsvis dyb funktionsbaseret struktur, med en vertikal arbejdsdeling, der er baseret på et linje- og stabsprincip. 2. Dette betyder at centraliseringen dannes i form af et hierarki. I toppen af dette hierarki finder vi administrerende direktør Niels Petersen, med et kontrolspænd på 7 underafdelinger. Stabsfunktionen findes i form af indkøbsdirektør Børge Hejlesen, der kan være med til at aflaste linjeledere og underafdelinger på tværs af organisationsdiagrammet. Denne type virksomhedsstruktur, der er baseret på funktionsprincippet, er meget typisk for en stordriftsfungerende produktionsvirksomhed som Carletti A/S. Idet der er mulighed for udvikling af kernekompetencer i nogle standardiserede opgaveudførelser som fx i produktionen baseret på bilag 1 Organisationsdiagram. Side 5 af 75

6 SWOT (Fælles) Stærke sider (strengths) Stor erfaring Solidt produkt Malkekos produkter Produktudvikling Faste storkunder (indtægter) Høj indgangsbarriere Leveringsservice Stor målgruppe Stort sortiment Dedikeret arbejdskraft INTERNE SITUATION Svage sider (weakness) Mellemlager problem Spild i produktion Sårbare overfor politiske tiltag (fx sukkerafgift) Finanskrise (en varer der let kan tilsidesættes) Dragémaskiner kører langsomt EKSTERNE SITUATION Muligheder (opportunities) Robotstyret lager og produktion Større produktudvikling Opkøbe Udvide markedet Flytte produktion til udlandet Forbedringer i produktionslinjen (dragéprodukter) Markedsføring (fx tv) Trusler (threats) Finanskrise Sukkerafgift Sundhedstrend Maskinstop SWOT-analysen er med i denne del af rapporten for at danne grundlag for de øvrige afsnit. For at tage et eksempel kan vi afsløre at senere i rapporten vil vi have fokus på bl.a. at komme med et forslag til en løsning der ville kunne løse problemstillingen i form af deres mellemlager-problem. Dette kan ses i SWOTanalysen som værende en af virksomhedens svage sider. Grunden til SWOT-analysen er med er for at få et overblik over de ting som virksomheden gør godt, samt virksomhedens svage sider som kan optimeres for bedre produktion. Organisations form (Frederik) Carletti A/S kan karakteriseres til at være en blanding af den mekaniske og organiske organisations struktur. Carlettis produktion styres efter ordrebestilling, sæson udsving og i støre mængder til lager bliver produceret efter tidligere års tendenser. En produktionsvirksomhed hvor der arbejdes i stabile omgivelser og med gentagne ensformige opgaver, er det mest effektivt, at designe organisationen efter mekanistiske principper, såsom: stabil arbejdsdeling og fast produktions rutine, præcise foreskrevne pligter, position i hierarkiet og faste kommunikations kanaler. Hvorimod virksomheder der skal have en hurtig reaktionsevne til at ændre arbejdsrutinerne, så de passer til de komplekse opgaver de får ind, er mere effektive ved at anvende de organiske principper opdeling af arbejdet varierer efter viden og erfaring, ansvaret bliver mere generelt fordelt og hvor den personlige erfaring tæller mere end ens position hierarkiet. Side 6 af 75

7 Den mekaniske forms stabile og funktionsbaserede arbejdsdeling er mest hensigtsmæssig ved produktionen af de større faste mængder slik til lageret. Hvor den organiske producerer efter ordrebestillinger og tidligere års tendenser. Udgangspunktet for Mintzberg s model er stabilitet, intern såvel som ekstern og hvordan man kan indstille strukturen i forhold til stabiliteten. Produktionssystem (Mads) For at kunne beskrive det egentlige produktionssystem som danner grund for den storproducerende Carletti Koncern skal man se på de fire dele som udgør dette. I den følgende tekst kan man læse omkring gruppens analyse af opbygningen af Carlettis produktionssystem. De fire dele er: produktions-filosofi, layout, styring samt form. Dette afsnit er lavet på baggrund af teksten omkring produktion samt logistik. Produktions-filosofi Da Carletti er en masseproducerende virksomhed inden for konfekture og chokolade ville dette gøre dem til en perfekt virksomhed til at benytte sig af Ford ismens principper. Når man snakker om Ford ismen inkludere det automatisk et vist fokus på området omkring høj produktivitet. Dette betyder at man opnår et så højt output af de specifikke vare hvor der er blevet brugt en så lille ressourceindsats som muligt. For at optimere denne produktivitet kræver det at man opdeler procesforløbet i forskellige underprocesser hvor der nemmere kan benyttes forskellige maskiner til at fuldføre denne. Samtidig gør det arbejdsopgaverne nemmere for de forskellige ansatte da de så kun skal tage sig af en lille, simplere, del af produktionsprocessen. Dette gør også at det er nemmere at oplærer nye ansatte i virksomhedens produktion da dette ikke kræver nær så lang tid, grundet den simplificerede proces. For at tage udgangspunkt i Carletti produktionsbeskrivelsen ved produktionen af dragé-produkter kan man ane brugen af Ford ismen. Denne proces er ideel til at benytte denne da der automatisk er så mange underprocesser. For at nævne nogle af underprocesserne hvor der indgår forskellige maskiner i kan man tage fat i: Støbning af kernen hvor der benyttes kedler Blanding af basisdrageringen Tørring af mellem- og færdigprodukter Påføring af ydre dragering. Ved hver af disse processer opholder produktet sig et bestemt sted i produktionen hvor lige præcis denne opgave bliver udført. Når man så står og mangler en medarbejder skal denne medarbejder ikke forstå hvordan hele produktionen af et dragé-produkt forløber men blot forstå og lære hvordan lige præcis hans station skal køres. Ulempen kan så være at hvis han skal forflyttes til en anden station i produktionen skal han på ny oplæres i denne funktion. Når man så tager fat i den anden kendte produktions-filosofi som kaldes Lean, er der både for og modargumenter for brugen af denne filosofi i en virksomhed som Carletti. En af hovedpointerne i denne filosofi er at man skal undgå at producere til et færdigvare-lager da dette gør at produktet bliver dyrere for kunden eftersom et lager medfører ekstra omkostninger. Dog kan det være svært for en virksomhed som Carletti at være så dynamiske at de hele tiden kan skifte deres produktions-opsætning til fordel for de forskellige kunders behov. Her er det relevant at finde en mellemvej hvor der stadig bliver benyttet et lager så kunderne altid kan få deres vare efter deres eget behov. Det at indføre en ren Lean filosofi som værende den eneste er ikke optimalt for virksomheder der producere i så stor kvantitet som en virksomhed af Carlettis størrelse. Dette kan forstås i forhold til et eksempel hvor en stor kunde laver en uforudset bestilling som en Lean tilgang ellers ikke ville kunne producere. Hvis denne storkunde ikke får sine vare til tiden kan Carletti risikere at miste kunden fordi de ikke havde varerne til tiden pga. Produktionssystemets filosofi. Derfor er Side 7 af 75

8 det vigtigt for en producent som dem at have et relativt stort lager så det ikke er grundet overskredne deadlines at kunder evt. forsvinder. Lean-tilgangen bliver derfor oftest benyttet på producenter der har forholdsvist små ordrestørrelser og derfor kan omstille sig meget hurtigt til de forskellige kundebehov der er i forhold til ordrene. Det en Lean-manager dog kan gøre i en virksomhed som Carletti er at se på de processer som allerede eksistere og gå ind og optimere på disse. Som et eksempel kan det være at Lean-manageren skal omrangere produktions-layoutet for at optimere det vare-flow der er, sørge for at spild på mellem-vare lageret bliver minimeret og andre lignende optimeringer. Her er det også aktuelt for at snakke om selve opgaveformuleringens problem stilling. Det at et mellem-vare lager er en flaskehals vil også være et af de områder som ville kunne løses af en Lean-manager. Produktions-layout Det er meget begrænset hvad vi igennem den udleverede beskrivelse har fået at vide omkring det fysiske layout af mellem-lager rummet samt produktionen i hele taget. Derfor holdes der fokus på det som der rent faktisk er viden om, nemlig mellemlageret hvor de forskellige bakker bliver lagret til tørring i perioder med forskellig tidslængde. Det der sker når en produktion har færdiggjort en proces som kræver en tørretid er at køre den ind og sætte den på mellem-lageret hvor den så, ved hjælp af ruller, bliver transporteret ned i den anden ende hvor den bliver plukket til dragering. Her kan man måske overveje om de forskellige procesforløb ikke skal have hver deres række eller endda deres helt eget niveau så man hele tiden kan holde styr på hvilken proces de skal til næste gang de bliver plukket. Men mere om det senere. Når man skal sammenholde det med den udleverede teori kan man begynde at argumentere for og imod forskellige typer af layouts. Som et eksempel kan man godt argumentere for at Carletti benytter et funktionslayout eftersom man kunne antage at der ikke var en lakridsstøbe kedel for hver type slik som benytter en eller anden lakrids komponent i den. Her vil man nok have et centralt lakridsstøbe kedel rum hvor al lakrids i virksomheden ville blive produceret hvor det efterfølgende vil blive transporteret videre til de processer som tager udgang i grundproduktet lakrids. Samtidig med at de måske benytter sig af et funktionslayout kan man også kigge på andre typer, så som linjelayoutet, flow produktionen. Som nævnt før er Carletti en virksomhed som producere en stor kvantitet af standardiserede vare, både ud fra ordre men også til lagering. Her vil et linjelayout være ideelt da der bliver produceret store mængder af det samme produkt på en kontinuerlig linje uden sideløbende produktioner af andre produkter (der ses her bort fra at de sandsynligvis har en fælles lakridsstøbe produktion til mange produktprocesser). Dette layout bliver benyttet til de produkter i et firma som firmaet ved, pr. statistik og erfaring, er rentable og de er sikre på at kunne få afsat. Dette kan i Carlettis tilfælde være skumbananer og P-tærter som de har stor succes med at sælge. Ser man det fra en medarbejders synspunkt kan denne type layout blive meget umotiverende og ensformigt hvilket i værste tilfælde vil resultere i utilfredse medarbejdere. Her er det en god ting at Carletti har multifunktionelle medarbejdere som hele tiden kan finde nye produktionsforløb at indgå i hvis de finder den nuværende monotom. På den måde får man en mere fleksibel arbejdsstyrke som gør at man ikke ligger inde med produktionsforløb der er afhængig af specialiserede medarbejdere som ikke ville kunne erstattes af andre. Dette problem har de dog med de medarbejdere der ligger inde med nogle af de få truckcertifikater. Dette er et typisk specialiseringsproblem hvor firmaet kan risikere store flaskehalsproblemer hvis disse medarbejdere er syge. Ud fra alt dette kan man komme med begrundelser for at disse to typer layout kombineret giver et gruppelayout som passer på Carlettis produktion som blev klassificeret som en jobshopproduktion. Dette giver nemlig et miks mellem linje og funktionslayout som gør at de kan kører små serier med svingende afsætning i selvstyrende teams. Side 8 af 75

9 Produktionsstyring Da teksten på dette område har været meget sparsom omkring viden på produktionsstyrings området kan vi dog kun komme ind på principperne og drage paralleller til den sparsommelige viden fra teksten. Produktionsstyringen består som basis af to dele, nemlig en planlægningsdel samt en overvågningsdel. Planlægningsdelen er typisk en funktion som bliver håndteret på mellemleder niveau, bl.a. fordi det er for administrativt for folket på gulvet og det vedkommer bl.a. heller ikke virksomhedens øverste direktør. På Carletti ville denne opgave typisk gå til produktionsplanlæggerne Peter og Leif. De vil få de forskellige ordrer passet ind så leveringstidspunktet samt kvantiteten bliver overholdt så det resultere i kunder der kommer igen. Når man så kigger på overvågningssystemet af produktionsstyringen bliver man nød til at lave nogle antagelser når det kommer til den konkrete virksomhed, i dette tilfælde Carletti. I denne virksomhed vil det typisk være en teamleder som rapportere til produktionsplanlæggerne om de overholder tidsplanen eller om planerne skal omlægges så de kommer til at passe. Produktionsformer Når man ser på de forskellige produktionsformer som bliver nævnt i den udleverede tekst er der to former giver mere mening at benytte i virksomheden Carletti. Den ene er typen jopshop produktionsformen. Det er her virksomhedens forskellige vare er standardiseret i forskellige udgaver som bliver produceret i små serier flere gange om året. Dog kan man debattere hvornår noget er i små serier, men ikke desto mindre kan man argumentere ud fra oplægget. Det der sker for Carletti nogle gange om året er at de enten får en stor ordre som kræver at hele fabrikken bliver omstillet på at producere lige præcis den kundes ordre, eller hvis det f.eks. bliver jul hvor der igennem prognoser for salg har vist sig at kræve ekstra arbejde for at holde trit med udbud og efterspørgsel. Dette kan argumentere for at Carletti benytter jobshop formen. Når det kommer til et argument for at Carletti benytter sig af flowproduktions formen kan man gå ind og se på hvor ofte deres produktion bliver omstillet for at tilgodese et specifikt produkt eller ordre. Hvis der dog forekommer relativt få omstillinger om året kan man godt argumentere for at virksomheden benytter flowproduction. Mens hvis der sker en omskiftning f.eks. to gange om måneden er virksomheden nok tættere på at benytte en jobshop form. Det der argumentere for en flowproductions form lige meget omstillings hyppigheden er det flow som produkterne gennemgår. Dette flow minder meget om en standard samlebånds princip som er en fast del af flow-produktions virksomheders opbygning. Side 9 af 75

10 Business Case (Fælles) Formål At få en bedre styring af mellemvarelageret, så tørretiderne bliver overholdt bedre og spildet formindskes. Forretningsmæssigt omfang En opdeling af mellemvarelageret, tilsvarende de 3 tørretidskategorier: min, perfekt og maks. Det skal fortsat fungere efter FIFO-princippet for at få en bedre styring af pluknings-rækkefølgen og sørge for at produkterne får den rette tørreperiode. Hvis der er en dominerende størrelse indenfor en bestemt kategori, så skal dette område kunne overtage den ubrugte plads fra de andre kategoriers lagerdel. For at holde styr på bakkernes indhold og vedrørende informationer implementeres hver bakke med en RFID-chip. Denne chip bruges også til at lokalisere bakkens placering og resterende tørretid. For at denne løsning kan anses for at værende succesrig, skal det systemet kunne måle den maksimale spildprocent på 2 % - alt over ville vise løsningen værende ineffektiv. En problemstilling ved denne løsning ville være at brugeren i mellemvarelageret ikke får lagt den rette information ind i bakkens chip, hvilket vil resultere i at bakkens indhold ikke vil være brugbart. Dette vil resultere i et yderligere spild i stedet for det ønskede resultat. De berørte brugere er de ansatte der styrer mellemvarelageret, der skal efteruddannes i brugen af det implementerede system. Dette inkluderer både indtastningen af information til chippen, samt placeringen af pallen på dens rette placering. Derudover skal brugerne også kunne aflæse bakkens information korrekt og derved få plukket korrekt. Side 10 af 75

11 IT omfang & krav Først og fremmest skal chippen fungere og implementeres i bakkerne. Når bakkerne kommer ind på mellemvarelageret skal de forbi et check-in ved indgangen, hvor informationen bliver skrevet til chippen, som blandt andet inkluderer dead-line for endt tørretid. Dette bliver gjort igennem computer. Det skal være muligt at aflæse bakkens information på et givent tidspunkt med en håndholdt scanner. Efter endt tørretid vil en alarm gøre medarbejderen opmærksom på at bakken/pallen skal sendes videre til forarbejdning. Bakkens placering kan ses på en skærm i lageret placeret og evt. på en skærm på trucken. På denne måde sikres det at den rette bakke bliver taget på det rette tidspunkt. Når bakken forlader mellemvarelageret skal det checkes ud. Systemet er delt op i 2 under systemer, overvågningsdelen og registrerings delen. Så hele systemet kommer til at bestå af RFID-chips i bakkerne, skærme til at aflæse bakkernes placering, samt scannere til aflæsning og indlæsning af data. Alt i alt bliver der brugt eksisterende og velfungerende teknologier, hvilket gør at der ikke skal investeres i yderligere udvikling. ID Beskrivelse Type Prioritet 1 Systemet skal have en alarm funktion ved endt tørretid Funktionelt M 2 Skal kunne vise en placering på et display Funktionelt M 3 Chippen i bakkerne skal kunne læses og ændres efter behov Funktionelt M 4 Systemet skal være brugervenligt og overskueligt Ikke S funktionelt 5 Oppetid på minimum 98 %. Stabilt og driftssikker, samt hurtigt. Ikke M funktionelt 6 Nemt at brugerdefinere til andre lagere Funktionelt C 7 Hver bakke skal kunne læses på et givent tidspunkt af en Funktionelt S skanner. 8 Muligt at printe en liste med alle bakker og deres informationer Funktionelt S Interessenter Interessenterne i dette system er hovedsagligt personalet der er tilknyttet mellemvarelageret, som direkte kommer til at bruge det. Derudover kan der argumenteres for at mellemledelse samt topledelsen har interesse i systemet eftersom det vil formindske spildet og forøge overskuddet. Alternativ løsning Nulløsningen ville være at fortsætte med det nuværende system og dermed acceptere spildet på min. 2 % - hvilket er et tabt pr. måned på minimum kr. ( kg*15 kr.*30 dage *0,02). Denne løsning løser intet! Risici En risiko kunne være at implementerings fasen bliver meget lang og brugerne har svært ved at vende sig til det nye system, dermed vil produktionsstyrken blive nedsat og der kan så opstå længere leveringstider. Eftersom dette system skal udvikles fra bunden vil der også være behov for opgradering når fejl findes. Dette kan også medføre stillestående produktion i visse tilfælde. Implementeringsstrategi Alt hardware installation foregår imens den daglige produktion foregår mere eller mindre uforstyrret. Dette gøres ved at nogle teknikkere bliver sendt ud på fabrikken for at sætte skærme og scannere til og chippen i bakkerne bliver implementeret når de løbende bliver ledige. Når alt udstyret er sat til og funktionstestet skal de forskellige teams fra fabrikken undervises i brugen af det nye system. Dette inkluderer brug af scannere, samt benyttelse af skærmene til plukning af bakker. Side 11 af 75

12 Dette kunne evt. foregå over en weekend i fabrikkens konference lokaler, hvor de ansatte også kommer ud og kan afprøve systemet grundigt igennem med en tekniker/underviser. Organisation Gruppen vil være repræsenteret som projektejere og har dermed ansvaret for evt. opdatering af business case. Gruppen er blevet nøje sammensat efter individuelle spidskompetencer og er derfor velkvalificeret til at løse Carletti A/S problemstilling. Key Performance Indicators (KPI) Det gennemgående nøgletal i denne case er spildprocenten på maks. 2 %. Problemstilling vil vise sig værende løst eller ej når spildprocenten ligger stabilt under 2 %. Konsekvens af løsningen Omkostninger til systemudvikling, hvilket inkluderer hardware så vel som software udvikling, vil blive dens største post i forløbet med implementering af systemet. Disse omkostninger kan forsvares, hvis man sammenligner dem med hvad virksomheden taber på nuværende tidpunkt pr. måned. Hvis vi antager at prisen for det færdige fungerende produkt ender på 1 million kroner og at de i øjeblikket har en spild procent på 4, vil det efter 4 måneder begynde at give overskud eftersom systemet garanterer en maksimal spildprocent på 2. Hvis virksomheden er villig til at investere dette beløb vil resultatet hurtigt kunne måles. Logistisk effektivitet hvordan opnås det? (Robert) Logistik stammer fra det græske ord logistikos og blev oprindeligt brugt i militære sammenhænge omkring håndteringen af forsyning i kamp. Lidt på samme måde bruger vi logistik i erhvervsmæssige sammenhænge, som færdigheden i håndtering og styring af blandt andet varer og informationer. Helt præcist inkluderer det strategisk håndtering af indkøb, transport, lagring, varer samt de dertil hørende knyttede procedurer. Side 12 af 75

13 Vi vil derfor lægge vægt på, hvad det betyder at være logistisk effektiv, ved at tage udgangspunkt i noten om logistik, der betegner effektiviteten som værende indeholdende to modsatrettede mål, nemlig leveringsservice samt logistikomkostninger. Hvert af disse mål indeholder nogle deleelementer, som vi vil gennemgå og diskutere hvordan kommer til udtryk hos Carletti A/S. Logistisk effektivitet Leveringsservice Leveringstid Lagerservicegrad Leveringsoverholdelse Leveringsfleksibilitet Leveringsinformation Logistikomkostninger Lageromkostninger Transportomkostninger Emballagehåndteringsomkostninger Administrative omkostninger Mangelomkostninger og Kort om de to mål kan der siges, at leveringsservice er en del af virksomhedens forhold til kunder i form af kundeservice (fx kort leveringstid som forøger salgsvolumen), mens logistikomkostninger indbefatter de omkostninger der skal til hos virksomheden, for at overholde den leveringsservice man stræber om at opnå til kunderne(fx lagerføre varer så man kan opnå kort leveringstid). Logistisk effektivitet er altså et samspil mellem disse to mål og kan for eksempel vurderes på at levere en god service og et godt produkt for at beholde og tiltrække potentielle kunder på en så omkostningseffektiv levering af indkomne ordre som muligt. Vi vil nu komme ind på nogle af de forskellige delemner Leveringsservice Leveringstiden går ud på, hvor hurtigt en kunde får sin vare, fra ordren er givet til kunden har modtaget varen. Denne proces kaldes også den logistiske leveringstid og indeholder fem delelementer. Afhængigt af, hvilken ordre der er givet behøves alle delelementer ikke indgå i en ordre. Da Carletti A/S arbejder både i jobshop-produktionsform og flow-produktionsform, betyder det at de har mange varer på lager, men at de samtidigt kan omstille sig til specialordre. At Carletti A/S har mange varer på lager, kan vi se ud fra et billede taget på Carletti A/S 3 (reference), som viser at de har en lagerservicegrad i gennemsnit på cirka 98 %. Lagerservicegrad regnes som en procentvis størrelse og er altså et tal der viser hvor mange ordrer der leveres direkte fra et lager. Antager vi, at der gives en ordre udelukkende indeholdende en meget populær vare som fx skumbananer, kunne man forestille sig, at denne ordre leveres direkte fra et lager. I sådan en situation, vil leveringstiden være kort, da ordren kun bliver berørt af en administrativ afdeling der tager imod ordren og betaling, og derefter distributionsafdelingen der sender varen. Antager vi, at det er en ordre der kræver at Carletti A/S skal lave produktet fra bunden af, går ordren igennem alle fem punkter. Teknisk ordrebehandling der laver beregninger for hele ordren (det kan fx være udregning af estimeret leveringstid, pris osv.), en administrativ afdeling, indkøbets leveringstid der står for indkøb af råvarer til produktion, produktionen samt distributionen. 3 Udleveret materiale Carletti billeder til ITO Side 13 af 75

14 For at levere en god kundeservice, skal man også kunne overholde leveringstiden, for blandt andet skabe tillid til kunderne og skabe et godt ry. I dette projekt har vi en problemstilling, der består af nogle problemer på et mellemvarelager og ifølge en dansk undersøgelse fra , er det også i produktionen at de fleste forsinkelser opstår. Her kan der altså opstå leveringsoverholdelsesproblemer. Carletti har som sikkerhed til kunderne, hvis Carletti skulle gå hen og være forsinket i leveringen, en aftale med kunder på forhånd, om en bøde til Carletti A/S. Fleksibiliteten kan måles i mange forskellige aspekter. Produktfleksibilitet vedrører evnen til at levere nye produkter. Her er Carletti A/S meget fleksible, ifølge årsrapporten lægges der stor vægt på udvikling af nye produkter 5 og ganske vist er der på deres hjemmeside også information om tre typer nyt slags slik 6. Funktionsfleksibilitet vedrører evnen til at levere forskellige varianter af samme varetype. Carletti A/S har en gang i en haste sag taget imod en ordre der skulle lave en type slik om til kosher-slik. Dette må siges at være utrolig fleksibelt, men samtidig blev de også betalt godt for dette 7. Carletti A/S ligger desuden inde med over 100 opskrifter chokolade 8, og man kunne godt forestille sig, at de kunne ændre chokoladeopskriften i en bestemt type vare, hvis ønsket. Leveringsinformationen er et svært punkt at komme ind på, da vi ikke rigtig ved hvordan Carletti A/S samarbejder helt præcist med sine kunder, udover de føromtalte sanktioner til dem selv. Logistikomkostninger Logistikomkostninger er som nævnt tidligere, en slags styring mod, hvordan man vil opnå den ønskede grad af leveringsservice. Carletti A/S har en relativ høj lagerservicegrad, hvilket betyder at de har bundet meget kapital i form af varer i store lagre, hvilket er en del af lageromkostninger. Ifølge årsrapporten 9 ligger de inde med varebeholdning for cirka 31 mio. kr., som også er en lageromkostning. Disse lagre kræver også de omkostninger de indbefatter(husleje, varme osv.). Da Carletti A/S både er masseproducerende, men samtidig også kan tage imod specialordre, må de også have maskiner til at kunne omstille sig efter ordre og behov. Dette må kræve avancerede maskiner, som også er en del af lageromkostninger. Valget om transportform har stor betydning for den logistiske effektivitet. Selve omkostningerne hos Carletti A/S er svære at vurdere, dog ses en gæld hos leverandører på cirka 16 mio. kr. 10. Carletti A/S s marked strækker sig over Danmark og Nordeuropa. Det er derfor måske sandsynligt, at der ikke er behov for dyre transportmidler som fx fly, men derimod noget billigere som fx tog. Carletti A/S har ikke de største omkostninger mht. emballage. Meget af Carletti A/S slik er pakket i standard plastikposter og med relative simple design. Pakningen af deres produkter sker fuldautomatisk på fabrikken, og nogle varer bliver endda ikke rørt af menneskehænder fra råvarerne bliver sendt fra fx Afrika, til kunden har slikket i hånden 11. Disse maskiner skal selvfølgelig købes, men pengene bliver nok tjent hjem igen, i forhold til at have personer til at pakke. 4 Note fra Fronter Logistikmål og logistikstrategier 5 Udleveret materiale Årsrapport del 1 side Undervisning + her ses en pose slik af Kosher Balls til 20 pund pr pose. (produktet findes ved at søge på Balls i søgefeltet) 8 Bilag 2 i udleveret ITO projekt-materiale 9 Udleveret materiale Årsrapport del 1 side Udleveret materiale Årsrapport del 1 side Bilag 2 i udleveret ITO projekt-materiale Side 14 af 75

15 Vurdering af logistiksystemet Grundet de mange kvalitative metoder logistisk effektivitet er baseret på, samt den begrænsede information tilgængelig, er det svært at give en helhedsvurdering af logistisk effektivitet hos Carletti. Vi har dog valgt at sammenligne nogle tal, fra nok den største danske slikproducent Toms med Carletti A/S, for derefter at give en vurdering. Vi kunne godt have tænkt os at vide mere om selve produktionen af fx dragéprodukterne. Ifølge procesbeskrivelsen af dragéprodukter 12, tager denne produktion 1-2 uger. Vi har dog ingen information om hvor lang hver proces er, udover to gange tørring som tager nogle dage. Antager vi, at nogle dage er to dage, kunne det godt ligne at vi har nogle logistikproblemer i forhold til hele processens længde på hele to uger, da også markedet ikke strækker sig længere end Nordeuropa. Her kan der måske være problemer med leverandører der er for langsomme. Desuden opstår der flaskehalsproblemer på mellemlageret, da selve dragéringsprocessen ikke kan følge med selve produktionen, hvilket også er et logistisk problem. Ser vi bort fra dette og sammenligner med Toms 13, kunne det måske alligevel tyde på, at Carletti A/S s logistiksystem er ret velfungerende, dog har det sin pris. 12 Udleveret ITO projekt-materiale side De følgende udregninger er lavet ud fra bilag 3 Side 15 af 75

16 Software Design Vision (Fælles) It-systemets formål er at understøtte en rationalisering af arbejdsgangene i forbindelse med mellemvarelageret hos Carletti samt at minimere spildet i forbindelse med dragering og tørring. Krav (Mads & Frederik) ID Beskrivelse Type Prioritet K1 Enkeltbrugersystem Funktionelt M K2 Afvikles på en almindelig computer Ikke Funktionelt M K3 Skal kunne finde næste portion der skal plukkes Funktionelt M K4 Det skal være hurtigt og nemt at finde placeringen på den ønskede portion. Ikke Funktionelt K5 Systemet skal kunne vise de portion som er klar til plukning Funktionelt M K6 K7 K8 K9 K10 K11 K12 Systemet skal kunne registrere en portion & en opskrift og dens behandlingsforløb. På en behandling skal det være muligt at registrere minimums, ideal og maksimum tørretid. Det skal være muligt at kunne oprette en portion i systemet og registrere påbegyndt tørretid (timestamp). Man skal med systemet kunne kalde en oversigt frem over portioner der står til tørring, der har overskredet maksimal tørretid. Systemet skal kunne beregne den gennemsnitlige tid en portion befinder sig på lageret. Skal kunne holde styr på hvor mange portioner der når at blive forældet. Systemet skal kunne beregne den optimale placering af en portion ud fra FIFO-princippet Funktionelt Funktionelt Funktionelt Funktionelt Funktionelt Funktionelt Funktionelt K13 Informationerne skal gemmes i en relationel database Funktionelt M M M M M S S S S Use-cases (Fælles) Følgende afsnit beskriver de use-cases vi er kommet frem til. Disse bliver uddybet igennem brug af vores use-case skabelon. Side 16 af 75

17 Use-case oversigt ID Navn U1 Find vare U2 U3 U4 U5 U6 U7 U8 U9 Pluk vare Beregn gennemsnitlig tid på lager Beregn antallet af forældede mellemvarer Print oversigt Opret opskrift Opret portion Registrer behandling Tilknyt behandling Aktør beskrivelse Brugerne af dette system vil være almene lagerarbejdere og en lagerchef, hvor vi antager at deres IT kunnen er begrænset. Systemet vil blive brugt i den daglige drift. Use-case beskrivelser Use Case Name: U6 - Opret opskrift Scenario: Trigger Event: Brief Description: Actors: Related use cases: Postcondition: Flow of events: Lagerchef opretter en opskrift Der skal oprettes en opskrift Der oprettes en opskrift til brug i systemet Lagerchefen Opret eller tilføj behandling Opskrift oprettet Actor 1. Lagerchefen taster navn ind i systemet System 1. Systemet gemmer opskrift med navn. 2. Lagerchefen opretter opskrift eller tilknytter behandling. Exceptional Flows: Side 17 af 75

18 Use Case Name: Scenario: Trigger Event: Brief Description: Actors: Related use cases: Stakeholders Precondition: Postcondition: U2 - Pluk vare Lagermedarbejder skal plukke en vare Varen er færdig med at tørre eller tørret for lang tid. Når en vare er færdig med at tørre eller tørretiden er for længe skal den flyttes videre til behandling eller til spild. Lagermedarbejder Frigør lokation Carletti A/S Der er en vare på lager Varen er flyttet til viderebehandling Flow of events: Exceptional Flows: Aktør 1. Lagermedarbejder finder varen i systemet 2. Varen sendes til viderebehandling System 1. Placering vises 2. Placering bliver frigjort Use Case Name: Scenario: Trigger Event: Brief Description: Actors: Related use cases: Stakeholders Precondition: Postcondition: U7 - Opret portion Produkt/portion kommer fra produktionen og skal behandles i form af tørring og/eller dragering. Portion skal behandles Portionen får et varenummer, en start tid og bliver tilknyttet en behandling Lagerchefen Tilknyt behandling Carletti A/S Der kommer et produkt/portion til mellemlager Portion oprettet med tilknyttet behandling Flow of events: Aktør 1. Lagerchefen opretter portion System 1. Portion oprettes med navn, id og start tid 1.1 Der tilknyttes behandling(tørring og/eller dragering) Exceptional Flows: Side 18 af 75

19 Sporbarhedsmatrix (Frederik) Tabellen viser sammenholdet imellem vores use cases og de liste krav fra kravspecifikationen, ID K1 K2 K3 K4 K5 K6 K7 K8 K9 K10 K11 K12 K13 U1 X X X X U2 X X X X X U3 X X X U4 X X X U5 X X X X U6 X X X X U7 X X X X U8 X X X U9 X X X System sekvens diagram (SSD) (Frederik) System sekvens diagrammer har vi brugt til at illustrerer hvordan en use-case interagerer imellem aktøren og systemet. Dette skaber en forståelse for hvordan systemet fungerer, ved at bruge en beskrivelsesform der ligger sig tæt til programmeringsformen. Opret opskrift U6: Aktøren i denne use case er lagerchefen som interagerer med systemet. Lagerchefen opretter en opskrift ved at indtaste navnet på opskriften og tilknytte behandlinger. Den oprettede opskrift kan nu ses på listen. Side 19 af 75

20 Opret portion U7: Aktøren i denne use case er lagerchefen som interagerer med systemet. Lagerchefen opretter en portion ud fra den valgte opskrift, som indeholder behandlinger og behandlingsindeks. Her tildeles portionen et id og en starttid per automatik. Efter oprettelse bliver portionen flyttet til lageret og behandlingen går i gang. Pluk vare U2: Aktøren i denne use case er lager medarbejderen som interagerer med systemet. Systemet viser at en portion er færdig med den igangværende behandling, og dermed at den er klar til plukning dvs. at portionen enten skal sendes videre til den nye behandling eller til pakning. Når portionen sendes til pakning bliver den placering frigjort. Side 20 af 75

21 Design sekvens diagram (DSD) (Fælles) Design sekvens diagram er en udvidelse af SSD. Her udvides beskrivelsen så den ligger nærmere programmeringssproget, hvilket der er det centrale i DSD. Dette design giver et tilnærmelsesvis billede af, hvordan den specifikke use case en gang skal kodes. Opret opskrift: Der bliver oprettet en ny opskrift igennem service klassen, som kalder contructeren i Opskrift. Det nye objekt bliver returneret og tilføjet til listen i Dao. Ud fra en liste af behandlinger tilføjes disse til opskriften og der tildeles behandlingsindekser til behandlingerne. Processen i at tilføje behandlinger foregår i et loop da der kan være 1 til mange behandlinger. Side 21 af 75

22 Opret portion: Når der oprettes en portion, går vi igennem den pågældende Opskrift og tilføjer den en portion. Da vi i oprettelsen af opskriften har tilknyttet dens behandlinger, kan vi igennem portionen oprette processer, hvor der tilknyttes netop opskriftens behandlinger, behandlingsindeks samt starttider og behandlingen kan gå i gang. Side 22 af 75

23 Pluk vare: I denne use case forestiller vi os eksemplet hvor varen er blevet for gammel og derfor tilføjes til spild. Når portionen bliver markeret i listen over processer, har vi fat i en portions aktuelle proces hvor netop denne proces status bliver beregnet. Får vi som i eksemplet returneret statustypen old, fjernes portionen fra lageret og portionen tilføjes til spildlisten. Side 23 af 75

24 Analyse Klasse Diagram (Fælles) Dette diagram er som titlen indikerer meget generelt, derfor bliver klasserne forklaret i forhold til de koncepter og begrebsområder titlerne dækker over. Hvis større detalje ønskes, henledes opmærksomheden til Klassebeskrivelserne. Som en start kan man tage udgangspunkt i det man kan kalde systemets centrale klasse, nemlig Opskriftsklassen. Ud fra denne klasse bliver hele produktionsforløbet oprettet igennem. Det vil sige at det er denne klasse der kommer til at stå for oprettelsen af Portioner samt holde styr på den rækkefølge en Portion skal gennemgå for at kunne blive erklæret færdig. Dernæst kan man se på de forskellige behandlinger som en Portion skal igennem. De konkrete klasser er alle sammen en udvidelse af en fælles superklasse så det er muligt at have en generel liste i de forskellige klasser der finder dette nødvendigt. Disse Behandlings sub-klasser kan oprettes udenom fx Opskrift-klassen. Dette er fordi det skal være muligt for mange forskellige opskrifter at benytte sig af en fælles behandling fx Tørring, som har de samme minimum, ideel og maksimum værdier for tørretider. Der ville ikke være nogen grund til at tvinge oprettelsen af behandlinger til at skulle gå gennem en anden klasse. Dette bevirker også en hvis grad af re-use. Ligeledes har vi Placerings-klassen som også kan oprettes uden at skulle igennem en anden klasse. I dette design går vi ud fra at lageret består af et stort firkantet areal som kan omdannes til et stort gitter så det er muligt at benytte x og y koordinater til at lokalisere en given Portion som står til tørre. I designet er der også inkluderet to associationsklasser der er der af to forskellige grunde. Til at starte med kan man kigge på Proces-klassen. Lige præcis denne klasse giver designet et sted hvor man kan trække en hvis mængde statistik ud fra. For at tage et eksempel kan det være at man gerne ville gennemløbe en Portions processer for at finde ud af hvor lang tid den har stået til tørring. Det er her Proces-klassen kommer ind. Den indeholder både start og stop tider for alle de behandlinger en Portion har været igennem, som alle vil blive gemt i en liste i Portions-klassen. Den anden associationsklasse i designet er BehandlingsIndeks-klassen. Denne klasse er der for at holde styr på den rækkefølge en Opskrifts forskellige Side 24 af 75

25 behandlinger skal komme i. Disse objekter af denne type bliver opbevaret i Opskrift-klassen, hvor en portion altid har styr på hvilket indeks den er kommet til, hvor opskrift-objektet så kan kalkulere den næste behandling ud fra det nuværende indeks. Når man snakker om multipliciteter kan man starte med at kigge på forholdet mellem Placering og Portion. Grunden til at det er nul til en, til nul til en, er fordi en Portion kan enten være under en Dragerings- eller en Tørringsbehandling. Men eftersom den kun skal tildeles en placering hvis dens behandling er en Tørringsbehandling er det ikke et krav at den skal have en placering som standard. Når den så skifter behandlingstype fra fx Tørring til Dragering ville dette placeringsobjekt så blive frigjort og mulig for andre portioner der skal tørre. Som nævnt tidligere vil Opskrift-klassen i implementeringsfasen få en liste over Processer. Grunden til det er, at man skal kunne følge og evt. generhverve en portions proces-forløb samt udregne forskellige ting ud fra dette. Tilstandsdiagrammer (Mads) Eftersom lagersystemet er bygget på at en vare kan have forskellige tørretider, som forklaret i det udleverede oplæg, kan dette illustreres igennem et tilstandsdiagram. Grunden til at dette er muligt er fordi man kan antage at de forskellige tørretider samt start og slut knuderne i systemet er stadier en portion kan antage mens den er på lageret til tørring. I følgende afsnit vil x være et udtryk for de dage en given portion har stået og tørret. Både minimum, ideal og maksimum er tal som lagt til 0 beskriver den deadline hvor en portion skifter status. Til at starte med, når portionen først lige kommer til lageret, er den i en start-tilstand hvor den endnu ikke kan plukkes til videre behandling. Dette er ikke muligt da man ellers ville kunne plukke portioner der stadig er 'våde'. Så derfor vil det ikke være muligt at plukke portionen i intervallet 0 < x < minimum. Når en portion så har stået i minimum tørringstid vil det være muligt for den at blive plukket til behandling. Det skal dog siges at varen vil have minimum som status indtil den når ideal tørretiden, altså: (minimum <= x < ideal). Når den så opnår at stå på lageret i ideal tid vil den efter formularen skifte til ideal-status. Igen vil det være Side 25 af 75

26 muligt at kunne plukke varen i dette stadie og lige som tidligere vil den have denne status i følgende interval: (ideal <= x < maksimum). Når en portion så har statusen af maksimal-tørring kan den kun have denne status i en dag. Ergo skal den plukkes når x == maksimum. Hvis x bliver større end maksimum, altså x > maksimum, ender portionen automatisk i en slut-tilstand som er et udtryk for at den er overgået til spild. Disse intervaller er også et godt udgangspunkt for videre testing. Design Klasse Diagram (Fælles) Dette diagram findes også som bilag. Dette diagram er den centrale del af Design-Modellen i rapporten. Det er lavet på baggrund af analyse diagrammet som tidligere er beskrevet. Forskellen på analyse og design diagrammet er basalt set detaljeniveauet som kommer til udtryk i bl.a. indførelsen af typer på attributter samt metoderne der er i design klasse diagrammet. Dette er dog set med et meget generelt syn. Følgende er derfor en uddybelse af den udbygning der er på baggrund af analyse-diagrammet som ender med et produkt i form af design klasse diagrammet. Til at starte med kan man gå ind og se på hvad de forskellige værdier på de forskellige attributter skal være. For at tage et eksempel kan man se på Placerings-klassen. Her er der mange der vil argumentere for at dens x og y attributter burde være strings, så man måske kunne sætte et 'b' foran begge værdier for at indikere at placerings-objektet er den placering i buffer-området af lageret. Dette blev dog fravalgt da vi gik ud fra at lageret var et stort firkantet område i en hal hvor man kunne opdele dette i små firkanter og navngive dem med koordinater i form af tal, x og y. Disse attributter fik derfor værdien integers (hel tal). Der er ligeledes andre eksempler på disse valg, men for hurtigt at dække de trivielle valg kan man se på de forskellige tider (starttid og sluttid) som logisk nok blev sat til at være det allerede eksisterende Date objekt, da de skal være fælles for begge. Side 26 af 75

27 Dernæst er der sådan noget som varenr på en portion, samt navnet på en opskrift. Begge af dem kan man argumenter for og imod de valgte typer men at sætte varenr til at være et integer og navnet på opskriften til at være en string virkede som det mest logiske for udviklerne. I Proces-klassens status attribut kunne man have gjort mange forskellige ting, for at indikere hvilken status et givent proces-objekt har på et givent tidspunkt. Som et primitivt udgangspunkt kunne man give den en string værdi, hvor man så skulle sørge for at alle statusser blev skrevet på præcis samme måde, for at sikre at de agerede på samme måde ved en given status. Problemet med denne tilgang er den menneskelige del. Her vil der være for stor risiko for at der på et eller andet tidspunkt vil være en stavefejl, som vil kunne få systemet til at indeholde proces-objekter med ugyldige statusser. En anden tilgang, som i dette tilfælde er blevet benyttet, er at have en enum-klasse som indeholder statiske elementer som så skal benyttes som typen for status attributten i Proces-klassen. På den måde er det sikret at der kun bliver benyttet de konstanter som er defineret i enum-klassen. Vi vil nu kigge på de to ovenstående associationsklassers implementering. Som man kan se ud fra det øverste billede, som er et lille del af det tidligere beskrevet analyse diagram, kan man se at der er en associationsklasse mellem opskrift og behandling. Denne klasse sørger for at en behandling ikke har den samme placering i alle opskrifter. Måden dette gøres på er at indføre den som en fast klasse mellem de to klasser: Opskrift og Behandling. Denne BehandlingsIndeks klasse sikrer at behandlinger kan benyttes i forskellige opskrifter med forskellige placeringer i rækkefølgen. Men der bliver overset en lille ting, nemlig overgangen fra analyse diagrammets multiplicitet til design klassens, hvor der lige nu er inkluderet en BehandlingsIndeks klasse. Til at starte med kan man se at multipliciteten 0..* til 1..* forstået på den måde at intentionen var at en opskrift skal have mindst en behandling i rækkefølgen men en behandling kunne godt indgå i flere opskrifter. For at dette kunne lade sig gøre at holde styr på, blev BehandlingsIndeks indført. For at overføre dette til design klasse diagrammet kan man i dette tilfælde argumentere for, at et behandlingsindeks godt kan indgå i flere opskrifter. Derfor bliver diagrammet implementeret som Side 27 af 75

28 ovenstående illustrationer. At et behandlingsindeks skal have en opskrift, som den ikke kender til, og at et behandlingsindeks kan indgå i flere opskrifter (1 1..*). Dernæst kan man se at behandlingsindekset skal have en behandling og en behandling sagtens kan indgå i flere behandlingsindekser, men som før skal behandlingerne ikke vide hvilke behandlingsindekser de indgår i (0..* 1). Denne overgang er også gældende for den anden associationsklasse der indgår i analyse-diagrammet. Dog med den forskel at udviklerne fastslog at forholdet mellem Portion og Proces blev nødsaget til at være en komposition da det ikke ville give mening at en proces kunne stå alene uden nogen tilhørende Portion. Som man kan se af det over-all design klasse diagram er der en lille klasse som virker som om den er meget isoleret fra resten af modellen - nemlig SystemDato-klassen. Grunden til denne klasse er med i modellen, er for at kunne have et centralt sted for alle modelklasserne at hente deres Date-objekter til starttid og sluttid. Mange vil sige at det ville være nok bare at kalde new Date på disse tider når de skulle sættes, men eftersom udviklerne gerne ville kunne teste systemet ved at få tiden til at gå hurtigere, blev denne klasse implementeret så man fra andre klasser kunne sætte en ny tid for systemet. Derfor blev der også implementeret en TimeThread-klasse i Service pakken så den kunne håndtere hvornår og hvor ofte en ny dato skulle sættes. I selve implementeringen er denne klasse implementeret med to modes et test og real-time mode. I det sidste mode vil der blive tjekket om computerens dato er en ny dato til forskel for den der allerede er sat i SystemDato-klassen efter et givent interval indtil systemet lukkes. Hvis man ser bort fra interfacet der også er med i ovenstående illustration, kan man se sammenhængen mellem de tre klasser: Service, TimeThread og SystemDato. Tanken bag denne kobling er at vi gerne vil tilgå en 'nuværende' dato i modellen uden at kalde op i DAO-en og Service klasserne. Derfor var det nødvendigt at oprette SystemDato-en. For hvert interval der går i TimeThread-tråd klassen skal dens run-metode sætte en ny dato i SystemDato klassen, samtidig med at den skal kalde en metode i Service klassen der tjekker Side 28 af 75

29 hele systemets objekters status. Dette gør at vi kan forkorte en flere dages lang proces ned til fx et par sekunder. Alt dette overholder stadig at der ikke bliver kaldt ned i lagene i den brugte arkitektur. Arkitektur (Mads) Når man snakker om arkitektur i et software-udviklingsprojekt har undervisningen givet os to modeller at vælge imellem. Den ene er den traditionelle fire-lags arkitektur hvor alt går strikt gennem alle tre lag for at tilgå modellen i bunden. Altså GUI Service DAO Model, med ingen undtagelser. Der er mange forskellige holdninger til denne model. En af dem benytter argumentet med, at den ligger bund for mange unødvendige metodekald, eftersom alt skal igennem Service for bl.a. at kunne tilgå en given liste i DAO-en. Men på den anden side kan man også sige at det giver en større kontrol omkring hvad der virkelig foregår i de lavere-liggende lag i arkitekturen. Til dette projekt er der valgt en lidt anden tilgang til arkitekturen, ved at benytte en arkitektur som består af tre lag, men stadig med de samme fire elementer. Grunden til at denne er valgt, er for at effektivisere systemet, ved ikke at skulle følge en nær så stor 'method-call-path' ved evt. debugging. Desuden bliver det muligt at tilgå DAO-en direkte fra GUI-en. Det skal dog siges at der kun benyttes denne tilgang til at læse lister fra DAO-en, ikke til at ændre objekter i systemet. Denne arkitektur gør også at Service-klassen ikke bliver nær så lang og med et mindre indhold af lettere trivielle metoder. Som man kan se på modellen afhænger Service stadig af DAO-en. Grunden til dette er at når man endelig skal opdatere et objekt i dette tilfælde et objekt af typen Opskrift går dette stadig igennem Service for stadig at have en kontrol med hvad der bliver opdateret med hvilke værdier. Testrapport (Mads) Dette afsnit indeholder et afsnit omkring modul-test af en forretningsorrienterede klasse, i dette tilfælde er der valgt at det skal være Proces-klassen i en kobling med Toerring-klassen. Derudover er der et afsnit omkring en use-case test for en central use-case, her er der valgt use-casen: Opret Opskrift. Modultest af Proces-klasse /** Side 29 af 75

30 * Beregner den status en proces har ved metode-kaldet. Dette er forskelligt * alt afhængig af hvilken subklasse en behandling er. <br> * Krav: currentdate skal være 'større' end starttid * currentdate * den dato som systemet har på det givne tidspunkt den aktuelle status for den nuværende proces som vil være * portionens aktuelle proces */ public StatusType beregnstatus(date currentdate) I klassen Proces er der en metode der hedder beregnstatus som skal beregne den status den pågældende proces har ud fra en given dato som bliver givet med til metode-kaldet gennem en parameter. Det der kommer til at ligge bund for dette test-case er at Toerrings-klassen også benyttes da det er denne klasse der definere hvornår en proces har forskellige statuser. Så defor startes der med at definere et 'objekt' af klassen Toerring med værdier for minimum, ideal og maksimum tørringstider. Men for at dette kan lade gøres skal der kigges på de krav som er opstillet for oprettelse af denne klasse. Eftersom programmet ikke garantere brugbare resultater hvis disse krav ikke er opfyldt fra brugerens side. Derfor kigges der i dokumentationen for konstruktoren for denne klasse. /** * Oprettelse af en Tørring <br> * Krav: 0 < minimum < ideal < maksimum * minimum ideal maksimum */ public Toerring(int minimum, int ideal, int maksimum) Her kan man se hvordan konstruktoren for oprettelsen af dette objekt ser ud. Og der kan derfor læses at for at programmøren garentere et valid objekt af denne type skal følgende krav være opfyldt: 0 < minimum < ideal < maksimum Dette krav bunder i opfattelsen omkring problemstillingen for systemet. Her forståes der at en tørring ikke kan vare nul dage og der skal mindst være en dags forskel mellem de tre stadier for at et valid Toerrings objekt bliver returneret. Derfor vil det objekt der bliver benyttet bruge følgende værdier for tørringer: Side 30 af 75

31 Parameter Værdi Minimum 1 Ideal 3 Maksimum 5 Disse værdier overholder det opstillede krav fra programmørens side og vil derfor give et valid objekt til videre brug i test-casene. Når det så kommer til oprettelse af proces-objektet antages der at der er et tilhørende portions-objekt som selvfølgelig også har et opskrifts-objekt. Dernæst antages der at starttid attributten på proces-objektet er sat til som udgangspunkt. Når der så skal testes antages der at currentdate (parameteren i metodekaldet) er en nyere Date-objekt end starttid så at sige. I tabellen over tests der er foretaget vil det være differencen mellem starttid og currenttid-parameteren som er med. Det der så testes for er om de forskellige StatusTyper der bliver returneret er passenden i forhold til den difference der er mellem starttid og currenttime. Følgende tabel giver et overblik over hvornår procesobjekten skal have specifikke status i henhold til differencen. De variabler som bliver brugt i beskrivelsen af intervalet for hvornår statusen er valid er en reference til de tørretidsspecifikationer som er opgivet ved oprettelsen af Toerrings-objektet. Ligeledes er x et udtryk for den førnævnte difference mellem starttid og currentdate. StatusType Inteval for status Ækvivalensklasse StatusType.NOT_DONE 0 <= x < minimum [0;minimum[ StatusType.MINIMUM minimum <= x < ideal [minimum;ideal[ StatusType.IDEAL ideal <= x < maksimum [ideal;maksimum[ StatusType.MAKSIMUM maksimum == x [maksimum;maksimum] StatusType.OLD x > maksimum ]maksimum; [ I ovenstående tabel er der som forklaret intervallet for hvornår statustypen er valid men også en kollonne for de ækvivalensklasser som er blevet beregnet udfra disse intervaller. Ud fra disse kan man frem til de grænseværdier og yderligere værdier som skal benyttes til at teste med. Grænseværdierne er normalt defineret som værdierne der danner rammerne for ækvivalensklasserne. Derudover skal der testes for værdier lige under og lige over disse ækvivalensklasse-grænser. Dette gøres efter antagelsen om at hvis disse værdier giver de ønskede resultater så vil resten af værdierne i de forskellige intervaller give de samme ønskede resultater for de individuelle værdier. Side 31 af 75

32 Altså er grænseværdierne for disse test et udtryk for en specifik difference mellem starttid og currentdate. starttid - currentdate Forventet resultat Faktiske resultat 0 StatusType.NOT_DONE StatusType.NOT_DONE minimum - 1 StatusType.NOT_DONE StatusType.NOT_DONE minimum StatusType.MINIMUM StatusType.MINIMUM minimum + 1 StatusType.MINIMUM StatusType.MINIMUM ideal - 1 StatusType.MINIMUM StatusType.MINIMUM ideal StatusType.IDEAL StatusType.IDEAL ideal + 1 StatusType.IDEAL StatusType.IDEAL maksimum - 1 StatusType.IDEAL StatusType.IDEAL maksimum StatusType.MAKSIMUM StatusType.MAKSIMUM maksimum + 1 StatusType.OLD StatusType.OLD maksimum + n StatusType.OLD StatusType.OLD Som man kan se ud fra ovenstående tabel overholder metoden de forventninger der er stillet til den. Der vil dog ikke blive testet for ulovlige værdier som fx en negativ difference mellem starttid og currentdate da dette ikke er en mulighed i systemet. Nu hvor hele processen af testing er gennemgået for den største del af Proces-klassen, kan den følgende del let gennemgåes ud fra nogle få linjers forklaring. Det vil sige at følgende tabeller er en test gennemgang hvis en proces' behandling er af typen Dragering. Det brugte Dragerings-objekt har en varigheds-attribut med værdien tre. Denne attribut er den eneste interessante i Dragerings-klassen. StatusType Inteval for status Ækvivalensklasse StatusType.NOT_DONE 0 <= x < varighed [0;varighed[ StatusType.DONE x >= varighed [varighed;varighed] I ovenstående tabel bliver der gået ud fra at der er plads på lagerert når en proces er færdig, har fået statustypen StatusType.DONE, hvilket forklare den sidste ækvivalensklasse. Hvis dette ikke var en antagelse ville det være nødvendigt at udvide ækvivalensklassen til at have følgende opbygning: [varighed; [ og endda gennemtænke om en dragering skal have muligheden i at blive for gammel selvom den endnu ikke er kommet ind på lageret. Med ækvivalensklasserne deffineret kan grænseværdierne samt de forventede resultater opsættes efterfulgt af testenes egentlige resultater. Side 32 af 75

33 starttid - currentdate Forventet resultat Faktiske resultat 0 StatusType.NOT_DONE StatusType.NOT_DONE varighed - 1 StatusType.NOT_DONE StatusType.NOT_DONE varighed StatusType.DONE StatusType.DONE varighed + 1 StatusType.DONE StatusType.DONE Ovenstående antagelse med at værdierne for x er en difference som er udtrykt fra den forud-deffineret værdi for Dragerings-objektets varigheds-attribut. Use-case test af Opret Opskrift I nedenstående mock-up af den tidligere beskrevet use-case er der kort forklaret lidt omkring use-casen 'Opret Opskrift'. Denne case er opdelt i fire kategorier som der bliver arbejdet udfra ved udarbejdelsen af denne use-case test. Use-case #U6 Opret en opskrift Success guarantees Der bliver opretttet en opskrift i systemet Main success scenario 1. Brugeren indtaster et navn på en opskrift 2. Brugeren tilføjer x antal behandlinger til opskriften. 3. Brugeren vælger at konfirmere oprettelsen af opskriften. Extensions 1a. Brugeren glemmer at skrive navnet på opskriften 2a. Brugeren kan ikke finde en given behandling og ønsker at oprette en ny 2aa. Der eksistere ikke den ønsket behandlingstype (hverken tørring eller dragering kan bruges) 2b. Brugeren tilføjer ingen behandlinger Ud fra ovenstående use-case mock-up kan man så danne et use-case test skema som danner bund for alle de kombination af udfald den givne use-case kan resultere i. Nedenstående tabel er af sådan en type tabel: Side 33 af 75

34 Test case ID Test Source Initial State System Input Expected Results U6-1 Use case #6 Programstart fra hovedvindue U6-2 Use case #6 extens. 1a U6-2 Use case #6 extens. 2a U6-3 Use case #6 extens. 2aa U6-4 Use case #6 extens. 2b Programstart fra hovedvindue Programstart fra hovedvindue Programstart fra hovedvindue Programstart fra hovedvindue (a) Opskrift navn Lakrids (b) Mindst behandling tilføjes (c) Trykker på OK (a) Mindst behandling tilføjet (b) Trykker på OK en en (a) Opskrift navn Lakrids (b) Trykker på 'Opret Behandling' (c) Mindst en behandling tilføjes (d) Trykker på OK (a) Opskrift navn Lakrids (b) Trykker på 'Opret Behandling' (c) Trykker på luk i 'Opret Behandling's-vinduet (d) Trykker på luk i Opskrift's- 'Opret vinduet (a) Opskrift navn Lakrids (b) Trykker på OK (a) En ny opskrift vil blive oprettet (b) Brugeren kommer tilbage til hovedvinduet (c) Listen over opskrifter vil vise den nye opskrift (a) Brugeren får at vide de skal angive et navn for at kunne oprette en opskrift (a) Brugeren opretter en ny behandling med de nødvendige og gyldige værdier (b) En ny opskrift vil blive oprettet (c) Brugeren kommer tilbage til hovedvinduet (d) Listen over opskrifter vil vise den nye opskrift (a) Brugeren kommer ud til hovedvinduet (b) Ingen ny opskrift er oprettet eller vises i listen over opskrifter. (a) Brugeren vil få at vide at der skal være mindst en behandling tilføjet (b) Brugeren bliver på 'Opret Opskrift's-vinduet Status (Mads) Som systemet ser ud nu på et designmæssigt niveau er der stadig nogle fejl, dog skal det siges at det ikke er noget udviklerne på nuværende tidspunkt kan identificere. Der er dog stadig mulighed for videre udvikling af systemet. Der vil fx kunne blive implementeret et kort over det pågældende lager hvor man selv ville kunne assigne forskellige fysiske områder til at have buffer-status eller lignende. Ud over det kan der implementeret en fane i GUI-en til at håndtere den over-all statistik så der fx kan blive genereret grafer ud fra gennemsnitlige tørretider over et foruddeffineret tidsinterval. Side 34 af 75

35 Hvis man skal kigge på manglerne er der rigtig mange ting man kan argumentere for og imod. Men for at tage nogle eksempler kan man tage udgangspunkt i håndteringen af opskrifter. Lige nu kan systemet ikke håndtere hvis en lagerchef gerne vil slette en opskrift. Grunden til dette ikke er implementeret er fordi der på nuværende tidspunkt ikke er en log-tabel i databasen som man kan gemme sådanne ændringer i. Hvis man lige nu kunne slette en opskrift ville man ikke kunne fortryde det ved at hente dens data i log-tabellen. Dernæst kan man se på en lignende sag, nemlig håndteringen af behandlinger i systemet. Disse objekter kan heller ikke opdateres til at have andre attributværdier. Dette er valgt eftersom hvis det var muligt ville det påvirke alle de opskrift og portions-objekter som benytte det pågældende behandlings-objekt. Derfor er disse gjort 'statiske'. For at runde af på denne status del af rapporten kan man godt konkludere at hvis det som blev beskrevet i oplægget er det som kunden gerne ville have ville dette system godt kunne tages i brug. Resume af forløbet (Robert) Som udgangspunkt har vi aftalt at mødes kl. 08:30 hver dag, for derefter at arbejde til omkring middag eller til målene for dagen er nået. Vi startede med ITO-delen og blev hurtigt enige om at vi ville arbejde med klar arbejdsfordeling, for derefter at samle vores materiale og gennemgå det og eventuelt tilpasse det. Efter et kort møde med vores vejleder, holdte vi i gruppen et møde om hvordan opgaven skulle løses. Det største problem vi havde med ITO er fagets omfang og derfor at finde vores relevante fokuspunkter. Efter at have løst problemet angående relevant materiale og endelig overvandt frustrationen, nåede vi hvad der lignede et færdigt resultat og slog derefter over til næste opgave, nemlig software design delen. Vi fastholdte under hele processen de samme arbejdstider, med små dellegeringer til hjemmearbejde og begyndte nu på software design. Dette krævede en del gruppearbejde og de første par dage foregik meget på samme skærm, for at være fælles om den endelige grundstruktur for software konstruktionen. Arbejdsmetoden ændredes dog efter at have lavet analyse og design diagrammer. Ligesom i ITO var det nemlig fordelagtigt at dele arbejdet op i tre dele, da mange af opgaverne i software design er relative overkommelige for ene mand. Da vi følte os godt klædt på til at begynde med kodning, gik vi i gang med at kode modellen. Dette gjorde vi i nogenlunde fællesskab, for hele tiden at kunne diskutere den optimale løsning af metoder og være sikker på at vi overholdte blandt andet vores multipliciteter. Vi kom hurtigt i gang med GUI og efter at have tegnet og blevet enig om vores design, blev vi enige om at lave GUI hver mand for sig, da det viste sig at vi havde hver sin måde at programmere det på. Det største problem her var, at blive enige om brugen af Layouts, hvor vi endte med at blive enige om et par specielle Layouts men også absolutte designs hvor mange knapper og lister drillede. Da vi var færdige med denne version af programmet, var vi klar til JPA-versionen. Vi implementerede JPA uden de store problemer og testede derefter at objekterne blev gemt i mysql. Da dette var en succes, følte vi os nu godt klædt på til at kalde os stort set færdige med programmeringsdelen. Enden på projektet synes endelig håndgribelig og vi satte os sammen for at lave en liste med nuværende mangler. Disse opgaver blev fordelt og lavet over en weekend, for derefter at blive samlet. Sidste proces gik ud på at samle projektet og rette for fejl og mangler. Side 35 af 75

36 Refleksioner (Robert) Unified process(up) er et redskab til at skitsere systemudviklingens cyklus. Det er ud fra denne cyklus, at vi har arbejdet med Carletti projektet. For at forstå denne cyklus, skal man præsenteres for de fire faser som beskriver cyklussen. I dette projekt lægger vi dog ikke vægt på den fjerde og sidste fase transition, som omhandler udførelsen (også kaldet deployment) af projektet i form af implementering hos kunden. Et redskab man bruger mens man arbejder ud fra UP er det iterative princip. Ved at arbejde iterativt, arbejder man sig igennem nogle faser, hvormed projektet vokser inkrementelt og de isolerede faser samles til en enhed. Man deler altså projektet op i små miniprojekter, hvor man opstiller nogle målbare artefakter eller krav. Dette hjælper med at skabe et overblik over projektet og dets forløb. Den første fase hedder inception og inkluderer faget ITO og SD. Denne fase handler blandt andet om business modelling eller med andre ord forretningsudvikling. For at kunne gennemføre et projekt, skal man skabe sig noget overordnet baggrundsviden og forståelse for hvilket forretningsområde man befinder sig i. I denne fase udvikles desuden nogle simple use cases, der skaber forståelse for simple overordnede funktioner i systemet. Dette er hvad vi har gjort i ITO og SD. Denne viden har kunnet bringe os videre til næste fase, elaboration. I denne fase arbejder vi videre med software design. Her skabes de centrale dele af systemet samt en dybere forståelse af systemets krav. Her udarbejdes detaljerede forklaringer af use cases, klassediagrammer og andre software design redskaber. Efter denne fase skal man have nået så langt, at man kan udarbejde en grovplan for resten af projektet. Man er nået så langt, at enden er håndgribelig. Disse redskaber udvikles i en iterativ proces, hvor man med udgangspunkt i den midlertidige løsning, gentager processen og skaber en bedre løsning. Et nyt krav kan for eksempel være grunden til ændring i en use case og på den måde forbedrer vi produktet. De centrale dele af systemet skabes og en simpel version af programmet kodes. Her blev der lavet en lille version af programmet, som var i stand til at køre en simpel simulering af en opskrift som skulle igennem en behandling. I den sidste fase construction, forsættes implementeringen af programmet. Her er der arbejdet på at samle alt vores materiale samt færdiggørelsen af programmet, så det er klar til præsentation. Udviklingsværktøjer: I dette projekt har vi udover det udleverede materiale også hentet information fra internettet. Kilderne fra internettet, der er brugt i projektet, er selvfølgelig refereret til. Derudover har vi til udviklingen af vores system design brugt Visual Paradigm og til vores java-kodning programmet Eclipse. Til JPA delen brugte vi mysql til at teste, at vores program virkede efter hensigt. Side 36 af 75

37 Ordbog Udtryk Analyse Diagram Associationsklasse BehandlingsIndeks Behandling Collection-framework Dragering DrageringsType DSD Enkeltbrugersystem Grænseværdier Lagermedarbejder Lagerchef Modultest Opskrift Placering Plukke vare Portion Proces sluttid SSD starttid StatusType Definition Et generelt diagram der viser koblingerne mellem begreber i systemet En klasse der bliver indsat i en forbindelse mellem to klasser for at sørge for at alle klasser af en given type ikke. En associationsklasse der håndtere den rækkefølge forskellige behandlinger har i en opskrift. En abstrakt klasse der gør det muligt at have en liste med både tørring og drageringsbehandlinger i Dette er et framework som Java er udstyrret til håndtere forskellige former af samlinger af objekter Set, Tree, List En klasse der modellere en drageringsbehandling hvor den er deffineret med en varighed en drageringsbehandling tager En enumklasse der indeholder to konstanter som beskriver en type af dragering, enten en farve- eller en sukker-dragering. Design Sekvens Diagrammer Disse diagrammer bliver brugt i design fasen hvilket inkludere kaldene klasserne imellem Et system der kun skal bruges af en bruger af gangen dette gør at der ikke skal tages nær så høj forbehold for samtidighedsproblemer Bruges i test-verdenen sammen med ækvivalensklasser hvor grænseværdier er et udtryk for de tal i ydrekanten af intevallet. Aktør som hovedsageligt står for at plukke portionerne og sende dem videre til behandling Aktør som hovedsageligt står for at oprette opskrifter samt portioner. Dette er en testform hvor man kigger på fx en metode som tager forskellige parametre for derefter at resultere i noget bestemt. Ved at bruge denne testmetode kan man kontrollere udfra intervaller om disse resultater er valide. En klasse der indeholder en liste over de BehandlingsIndekser (behandlinger) en portion skal igennem for at få en status som færdigbehandlet En klasse der modellere en placering på lageret ud fra et koordinatsystem Når en portion har opnået en hvis status har den mulighed for at blive plukket. Dette betyder at portionen En klasse der modellere en portion af en opskrift, altså en form for aktivt objekt i proces-forløbet. En klasse der modellere en aktuel proces som en given portion lige nu er ved. Beskriver det tidspunkt når enten en portion eller en proces bliver afsluttet. System Sekvens Diagrammer Disse diagrammer bliver brugt for at give et helhedsindtryk af hvordan interaktionen mellem system og bruger er. Beskriver det tidspunkt når enten en portion eller en proces bliver påbegyndt. En enumklasse der indeholder alle de konstanter som beskriver en pågælden Side 37 af 75

38 Tilstandsdiagram Toerring Usecase test Ækvivalensklasse status for en proces. Et diagramtype der viser hvornår man kan gå fra en tilstand til en anden og hvad der skal være opfyldt for at det er validt. Sagt på en anden måde så er det et diagram der viser systemets forskellige tilstande. En klasse der modellere en tørringsbehandling som er deffineret med en minimal, ideal og maksimum tørretid En testtype som tester om den interaktion mellem aktøren og systemet er håndteret korrekt eller om der sker uforudsete ting. Et begreb der bliver brugt indefor test-verdenen. Det beskriver basalt set et interval af tal hvor alle de tal resultere i det samme resultat når de sættes ind som parametre i en metode. Software konstruktion Klassemodel (Fælles) Følgende tekst beskriver hvordan den teoretiske model fra Software Design er implementeret ud fra de mønstre og principper fra undervisningen de foregående to semestre. Der vil være en beskrivelse af selve modellen i form af en forklaring af sammenhængene mellem klasserne, hvilket inkluderet en begrundelse for de valg af Collection-frameworket, samt en gennemgang af evt. polymorfi. Dernæst vil der være en kort forklaring på den genererede Java-doc, som er blevet genereret ud fra de kommentarer som ligger i koden. Der udover er der en gennemgang af de design-mønstre der er valgt, både mellem klasserne men også af opbygningen af individuelle klasser. Implementering af design-modellen Dette delafsnit beskæftiger sig mest med de valg der er blevet truffet ved implementeringen af modellen med hovedfokus på koblingerne mellem klasserne samt de Collections dette medfører. Sammenhæng mellem klasserne For at starte et sted kan der med fornuft begyndes med koblingen mellem Opskrift-klassen og Portionklassen. Ifølge modellen er denne kobling af typen komposition. Dette betyder at en række ting skal være opfyldt for at denne kobling kan siges at være korrekt implementeret. For det første må det ikke være muligt at kunne oprette objekter af typen Portion på andre måder end igennem et objekt af typen Opskrift. Derfor skal konstruktoren i Portion-klassen have access-modify-eren 'package-private' da dette gør at det kun er muligt at oprette Portions objekter inde i den pågældende package og på den måde begrænse muligheden for oprettelse af det pågældende objekt. Nu hvor emnet er konstruktoren i Portions-klassen skal man huske at kigge på den pågældende multiplicitet for denne association. Her er det nemlig en kobling med multipliciteten en til mange hvilket betyder at det oprettede objekts konstruktor skal medtage et objekt af typen som oprettende objekt har. Side 38 af 75

39 Dernæst kan der ses nærmere på de metoder som skal være til stede for at en komposition er gyldigt implementeret. Der skal som minimum være en metode som opretter Portions objekter. Normalt vil sådan en metode få de samme parametre med, som konstruktoren for den klasse som gerne vil oprettes har. Dog skal det siges, at i dette tilfælde har Opskrift-klassen alle de fornødne data til at kunne oprette et objekt af typen Portion, hvilket resulterer i at metoden ikke har nogle parametre med og derfor er kommet til at se ud som følger: public Portion opretportion() Ovenstående metode kalder så konstruktoren i Portion-klassen som returnerer det nyoprettede objekt til brugeren som så kan benytte det derfra. Ved kald til denne metode bliver objektet også tilføjet til en liste over portioner som Opskrift-objektet har oprettet indtil nu. Der udover har udviklerne valgt at implementere en valgfri metode som gør det modsatte af den ovenstående metode. Den går nemlig ind og fjerner et Portions-objekt fra listen hvis listen vel at mærke indeholder det givne Portions-objekt. Her skal der lægges mærke til at valget af listen er faldet på typen ArrayList med en generisk type Portion. Baggrunden for dette valg ligger i at man er garanteret for at det samme objekt aldrig kan finde sted to gange i denne liste, da der for det første ikke er nogen 'tilføj'-metode som tilføjer objekter til listen. Dette ekskluderede valget af et Set da dette interface primært bliver brugt pga. denne egenskab. Derudover var det antagelsen at det altid skulle være muligt, hurtigt og nemt at tilgå og lave en iteration igennem listen, så man kunne tilgå et givent objekt nemmest, hvilket et ArrayList giver mulighed for. Vi hopper nu videre til koblingen mellem Portion-klassen og Placering. Denne association er en dobbeltrettet association med multipliciteten 0..1 til Dette betyder at man her enten kan vælge at lade begge klasser stå for vedligeholdelse af dette link, eller man kan se på det forretningslogiske og vælge én klasse til at tage dette ansvar. I denne implementering er det Placering-klassen der skal stå for vedligeholdelse af dette link, da tanken bag dette var, at man gik hen til en placering og aktivt fjernede portionen fra placeringen. Derfor har Portion-klassen en 'package-private' setplacering metode som kun kan tilgås gennem et Placerings-objekt, ergo har Placerings-klassen ansvaret. Med denne multiplicitet er ingen af klasserne tvunget til at have et objekt af modsatte parameter i dens konstruktor. I stedet har klassen en private attribut som har denne type, som så kan sættes til at være et konkret objekt af denne type på et givent tidspunkt. Dette gælder både for Placerings- og Portions-klassen. Dernæst kan man se på associationen mellem Portion- og Proces-klassen. Dette er af den samme type med Side 39 af 75

40 samme multiplicitet, som den sidst beskrevet komposition mellem Opskrift og Portion. Det inkluderer de samme krav for en gyldig implementation, i form af en ændring på konstruktorens access-modifyer, samt metode til oprettelse af objekter af typen Proces. Valget af collections i denne klasse er igen af typen ArrayList af den simple grund, at det skulle være muligt at få fat på den sidst tilføjede proces i listen over processer oprettet af den pågældende portion. Dette betød at Set ikke ville kunne benyttes da dette interface ikke indeholder implementering, som giver mulighed for at udtage specifikke elementer i henhold til et givent indeks. For at afslutte gennemgangen af valg af Collections skal der ses på associationen mellem Opskrift- og BehandlingsIndeks-klassen. Denne association vil resultere i, at der skal være en form for Collection i Opskrift-klassen over de BehandlingsIndeks-objekter som udgør den rækkefølge af behandlinger en portion skal igennem. Denne Collection kunne godt have været, uden problemer, af typen Set. Dog kom udviklerne ud for at dette var sværere at teste på under udviklingen af model-pakken. Et andet argument for at det kunne have været af typen Set var at lige præcis Opskrift-klassen indeholder en metode til at tilføje BehandlingsIndekser til listen. Dette kunne medføre at et objekt af denne klasse kunne blive tilføjet to gange, hvilket ikke vil give mening, da der så vil være to behandlingsindekser med den samme værdi for deres indeks attribut. Polymorfi I denne implementering er der næsten ikke benyttet polymorfi. Og her understreges næsten. I denne implementering har man, som man kan se af design klasse diagrammet, valgt at have en superklasse Behandling som også er en abstrakt klasse. Denne klasse har to subklasser som i teorien ville nedarve alle dens egenskaber. Men eftersom der her er valgt, at Behandling-klassen ikke har skullet have nogen egenskaber, hverken attributter eller metoder, men blot være der for at man kunne skabe en liste som både indeholdte objekter af typen Toerring samt Dragering, nedarver de to subklasser derfor ikke nogen egenskaber. JavaDoc Som en fast del af udviklingen af software systemer er det vigtigt at kommentere alle de metoder og svære logiske valg man har lavet inde i fx en metode. Dette har derfor resulteret i, at der i source-koden er blevet kommenteret for alle de metoder som ikke gav sig selv ud fra metodenavnet. Det skal derfor forstås på den måde at trivielle gettere og settere ikke er blevet kommenteret, da dette kun vil gøre source-koden linjemæssig længere. Måden der er blevet kommenteret på er ifølge en generel skabelon, som kan beskrives ud fra dette eksempel: Side 40 af 75

41 /** * Metoden opretter et objekt af typen Portion. Den får det første * behandlingsindeks med i constructoren så den ved hvilken behandling den * skal gennemføre først.<br> * Hvis der ikke er noget behandlingsindeks med indeks nummer 1 vil det * returnerede portions-objekt blive sat til null.<br> * Krav: En gyldig starttid, opskrift-objektet har et behandlingindeks i sin * liste med indeks-nummer 1 * skabte portions objekt til senere brug til fx. styrring af * behandlinger */ public Portion opretportion() Den ovenstående kommentar er taget fra Opskrift-klassen for opretportion-metoden. Her kan man se en lang beskrivelse som indeholder forskellige elementer som indgår i en JavaDoc (alle er dog ikke repræsenteret her). Det første er en kort beskrivelse af hvad den gør, efterfulgt af et html-linjeskift. Dernæst kommer der en uddybende forklaring på hvad der sker ved forskellige tilstande af objekter og systemer. Denne del indeholder også en beskrivelse af de krav metoden kræver, for at metoden opfører sig gyldigt og ikke sætter systemet i fare for evt. sammenbrud. Hvis en udefrakommende programmør skal benytte denne klasse til noget andet, er det kun garanteret at den vil fungere, hvis disse krav er opfyldt og ellers er det han/hendes egen skyld. I ovenstående eksempel er der vist hvordan et return-statement er medtaget. Denne del indeholder ikke et navn på det returnerede objekt eftersom et evt. navn på den interne variabel ikke påvirker objektet. I stedet er der en kort beskrivelse af det objekt som der bliver returneret og hvorfor det bliver returneret som det gør. For at vise en metode som medtager parametre tages der udgangspunkt i følgende eksempel: /** * Oprettelse af en Tørring <br> * Krav: 0 < minimum < ideal < maksimum * minimum ideal Side 41 af 75

42 maksimum */ public Toerring(int minimum, int ideal, int maksimum) Dette eksempel er forholdsvis simpelt da det er en konstruktor som tager tre heltal som parametre som har navnene minimum, ideal og maksimum. Når en kommentar-blok så bliver genereret bliver det vist som notation. Hvis det ikke var fordi disse tre værdier er meget trivielle og lette at gætte sig til hvad repræsenterer, så ville man kunne give en kort beskrivelse af hvad de betød og evt. skulle bruges til. Som før ses, der at der til denne metode er stillet et krav for gyldig udførelse, som her er et simpelt matematisk udtryk, hvor de tre parametre indgår i. Hvis det ønskes kan resten af dokumentationen, JavaDoc, findes i source-koden eller bagerst i denne rapport som bilag. Design Mønstre For at optimere systemet så meget som muligt, er der også i dette system blevet benyttet design-mønstre. I dette system er der blevet brugt tre mønstre som udgangspunkt: observer-, singleton-, og strategy-pattern. Følgende tekst vil forklare hvordan og hvor disse patterns er fundet og implementeret i systemet. Observer Det klassiske observer mønster består normalt af fire elementer. For at starte på et generelt niveau er der to interfaces, Observer samt Subject, som indeholder metoder til at registrere og fjerne observerende objekter (Subject-interfacet) samt en metode til at update en observers tilstand (Observer-interfacet). Når man så har implementeret dem, kan man implementere de konkrete versioner af de to interfaces, som så er tvunget til at implementere de metoder som interfacene definerer. For at tage udgangspunkt i dette system er der også blevet implementeret to interfaceses med de repræsentative navne. Derudover er MainFrame klassen implementeret til at benytte Observer-interfacet og Service klassen til at benytte Subject-interfacet. Grunden til dette ligger i at udviklerne gerne vil have at visningen bliver opdateret når der rent faktisk er sket noget væsentligt i de underliggende lag i systemet. Dette gøres på den måde at MainFrame bliver registreret som observer på Service-klassen, som så siger til MainFrame at den skal opdatere visningen for hver gang TimeThread finder ud af at der er gået en ny dag og Service har opdateret alle portioners aktuelle processers status. Efter denne opdatering af status bliver update metoden i Observer-interfacet kaldt på den konkrete klasse MainFrame, som derefter vil opdatere visningen til at være akkurat som modellen. På den måde vil der altid være en valid aktuel visning af alle processer i GUI-en. I det normale Observer mønster er det muligt for det konkrete Subject at registrere mange observere. Dette Side 42 af 75

43 kunne også være gjort i dette systems tilfælde, men eftersom opgaven lød på at udvikle, og fremstille et GUI ville det ikke være nødvendigt, da det blev valgt kun at have ét sted som central visning med kun én klasse. Singleton Da det ønskes at der gemmes objekter et centralt sted i systemet, eller sørges for at der kun bliver opdateret igennem et objekt, var det nødvendigt at benytte dette mønster da det sikrer denne egenskab bedst. Pointen ved dette mønster er, at der kun bliver oprettet højest et objekt af klassen i hele systemets run time. Måden at gøre dette på er at gøre konstruktoren i klassen privat og lave en statisk metode som alle ville kunne tilgå, public access modifyer, som så tjekkede om der allerede eksisterede et objekt (statisk attribut af klassens type i klassen), hvorefter den enten vil oprette et hvis det ikke var tilfældet og så returnere det eller blot returnere det allerede oprettede objekt. Når denne getinstance metode først bliver kaldt bliver attributten sat til et nyt objekt af klassens type. Det betyder at hvis dette var et multi-bruger system skulle en klasse der var designet efter Singleton mønstret gennemtænkes endnu engang. Ved implementeringen af getinstance metoden skulle der så tages højde for at denne metode skulle implementeres så det ikke er muligt, ved et tilfælde, at systemet fx fik oprettet to objekter af typen DAO. Dette kunne gøres, og er gjort i dette system, ved at implementere metoden med acces-modifyeren synchronized. Dog er dette ikke nødvendigt da beskrivelsen af systemet inkluderede begrænsningen at systemet var et single-user system. Dette er dog gjort alligevel da det vil danne en bedre grund for evt. videreudvikling af systemet. public class Service implements Subject { private static Service unique;... public static synchronized Service getinstance() { if (unique == null) unique = new Service(); return unique; private Service() { dao = DAO.getInstance(); dato = SystemDato.getInstance(); Side 43 af 75

44 ... I dette system er der benyttet singleton på DAO, Service og SystemDato. De to første klasser er allerede blevet forklaret hvorfor de er blevet implementeret således. Grunden til at SystemDato-klassen er implementeret på den måde ligger i at systemet kun skal hente de nødvendige datoer fra én klasse, så der ikke opstår en uens udvikling i tiden. Hvis der var to, ville det være muligt at nogle objekter fik deres datoer fra et SystemDato objekt mens andre fik fra en anden. Oven i det ville de to objekter af SystemDato kunne have to forskellige udgangsdatoer Strategy Pointen i strategy-mønstret er at generalisere klasserne hvor der på et eller andet punkt er en central klasse som alle subklasser nedarver fra. På den måde kan man benytte superklassen som en type definition på fx en attribut i ens application. På den måde kan der assignes et objekt af en subklasse til attributten som så ikke skal have skiftet værdi. Dette gør også at det er muligt at udvide systemet nemmere ved blot at lave en klasse som nedarver fra superklassen. Så længe attributten er defineret til at være af superklassens type, vil der ikke være noget yderligere problem i det. Grunden til at dette mønster er taget med i dette afsnit, ligger i implementeringen af Behandlings-, Toerrings- og Dragerings-klassen. Hele konceptet i strategy-mønstret kan ses her. Når et BehandlingsIndeks oprettes kræver det nemlig en eller anden form for behandling som en fast del af BehandlingsIndeks objektet. Hvis man ikke benyttede strategy mønstret kunne man fx have to attributter, en med typen Dragering, og en med typen Toerring. Så skulle der blot testes for hvilken af de to attributter der ikke var null for derefter at udføre behandling ud fra det andet. Men hvad hvis man havde ti forskellige behandlinger? Det ville så inkludere ti forskellige attributter i klassen der benytter en af behandlingerne, hvilket ikke er effektivt. Derfor er der i systemet implementeret en abstrakt klasse som både Toerring- og Dragering-klassen nedarver fra. På den måde skal der blot være en attribut i BehandlingsIndeks klassen som både kan have et konkret objekt værdi af typen Toerring og Dragering. Selv hvis systemet kommer til at inkludere flere behandlingstyper, er det kun oprettelsen af den nye behandlingstype som klasse der nedarver fra Behandling som skal implementeres, og intet i andre klasser - som udgangspunkt. Side 44 af 75

45 Implementering af arkitektur (Robert) Vi vil nu vise hvordan vores 3 lags arkitektur er blevet implementeret i praksis. Dette vil vi gøre ved at vise hvordan en bestemt use case, nemlig Opret opskrift, er implementeret. Som beskrevet i dens beskrivelse, går denne use case ud på at oprette og tilføje en opskrift til systemet. Den første fase i implementeringen gik ud på, hvad en opskrift skal indeholde. Vi blev enige om, at en opskrift som fx Lakrids, skal gemmes i en liste, samt en antagelse om at en opskrift skal indeholde en eller flere behandlinger. Dette kræver at man har nogle behandlinger og disse et behandlingsindeks. Alt dette er blevet kodet på model-plan og sammenhængen kan tydes ud fra design klassediagrammet, samt DSD for use casen. For at vise sammenhængen i arktiekturen vil vi nu gennemgå use casen. Når vi opretter en opskrift i vores GUI, kalder vi en OpretOpskrift -metode i vores service klasse. Denne metode henter da constructeren fra Opskrift-klasssen i modellen og kalder Dao for at gemme opskriften. De valgte behandlinger til opskriften bliver hentet til GUI fra Dao i form af en liste, hvor vi igen henter en metode fra service for at give behandlingerne til opskriften et behandlingsindeks.. GUI: private class OkButtonActionListener implements ActionListener {.. if(opskrift == null){ Opskrift o = Service.getInstance().opretOpskrift(navn); int indeks = 1; for (Behandling b : valgte) { o.addbehandlingsindeks(service.getinstance().opretbehandlingsindeks( indeks, b)); indeks++; Ovenstående viser hvordan vi kalder service klassen. Desuden henter listen valgte sine behandlinger fra dao. Service: public Opskrift opretopskrift(string navn) { Opskrift o = new Opskrift(navn); dao.addopskrift(o); return o; Ovenstående viser hvordan Service bruger modellen og Dao. Side 45 af 75

46 Vi har i vores arkitektur model en forbindelse fra GUI en direkte til DAO. Denne forbindelse er, udover eksemplet med listen valgte, for eksempel implementeret når en portion har stået for længe til tørre og derfor skal tilføjes til spild. Tanken bag denne forbindelse ligger i, at der ikke skal andet end en simpel tilføjelse af et portion-objekt til en ArrayListe for at dette kan lade sig gøre. Her kunne man kalde en metode i Service som så kalder denne funktion i Dao, men det fandt vi i gruppen som unødvendigt da det blot skaber mere uoverskuelighed. private class BtnPlukListener implements ActionListener { public void actionperformed(actionevent e) { if (!list.isselectionempty()) { Proces p = (Proces) list.getselectedvalue(); if (p.getstatus()!= StatusType.NOT_DONE) { if (p.getstatus() == StatusType.OLD) { JOptionPane.showMessageDialog(MainFrame.this, "Tilføj til spild", "Næste behandling", JOptionPane.INFORMATION_MESSAGE); dao.addtilspild(p.getportion()); else { Her kalder vi direkte til Dao klassen for at tilføje den valgte Portion til spild (dao.addtilspild(p.getportion()); Fejl håndtering (Frederik) I vores system har vi gået ud fra at den daglige bruger af systemet har modtaget et minimum af undervisning i hvordan systemet fungerer. Derfor har vi sigtet efter at gøre systemet meget brugervenligt og fejlfrit. Til at håndtere disse fejl har vi gjort følgende. If sætninger Vi bruger hovedsagligt if - sætninger til at kontrollere at der bliver tastet et gyldigt input og at de overholder systemets krav, ved den pågældende handling der udføres. if (navn.length()!= 0 && valgte.size()!= 0) { if (opskrift == null) { Opskrift o = Service.getInstance().opretOpskrift(navn); int index = 1; for (Behandling b : valgte) { o.addbehandlingsindeks(service.getinstance().opretbehandlingsindeks(index, b)); index++; else { Service.getInstance().updateOpskrift(opskrift, navn, valgte); Det ovenstående eksempel viser at man ikke kan lave en opskrift uden at der er indtastet navn og valgt minimum en behandling, fra listen valgte behandlinger. Try catch Try catch bliver brugt til at håndtere exceptions. Ved oprettelsen af en behandling har vi eksempelvis brugt en Try catch til at sørge for at der ikke bliver indtastet bogstaver, hvor der forventes en talværdi. try { catch (NumberFormatException ex) { Side 46 af 75

47 JOptionPane.showMessageDialog(BehandlingCDialog.this, "Vær venlig at brug tal", "Fejl ved input", JOptionPane.ERROR_MESSAGE); Til at vise hvilke fejl brugeren begår, har vi lagt stor vægt på fejlmeddelelser i Gui i form af en JOptionPane der kommer med en given løsning. Derudover er der også visse knapper og felter der først bliver aktiveret når de korrekte foregående handlinger er gjort. Dette viser vi senere i vores guidede tour af systemet. For at beskytte imod yderligere fejl har vi lavet JUnit-test. Her henviser vi til afsnittet med JUnit-test og testdata, for at vise netop hvilke fejl vi forebygger imod. JUnit test (Mads) Når en testcase er opstillet ud fra ækvivalensklasser samt grænseværdier skal det også bruges til noget. Derfor er der i den første version af dette system blevet implementeret JUnit test for de fleste af de mere interessante klasser med de metoder som ikke blot er af typen get og set. I dette afsnit vil der blive gennemgået en JUnit test ud fra den modul test som tidligere er blevet gennemgået af klassen Proces. Grunden til at denne klasse er valgt var af den grund at den indeholdte klare intervaller hvor objektet kunne have forskellige tilstande. Der er mange måder man kan implementere en sådan test og her vil der blive gennemgået to forskellige for at vise hvor meget kode der kan være til forskel, mellem en minimalistisk og en slavisk implementering. Til at starte med kan man kigge på grænseværdierne i tabellen som tidligere opstillet, og lave et assert-tjek for hver af resultaterne og sammenligne med de forventede resultater. Denne metode er en meget direkte tilgang, men kræver meget kopiering af kode som kan resultere i svær debugging ved evt. copy-paste fejl. Nedenstående udpluk af kode kommer fra testklassen for Proces-klassen. Her kan man se hvordan man kan tjekke for hver grænseværdi i tabellen. public class ProcesTest public void testberegnstatus_toerring_sd(){ Date curdate = null; proces = portion.getaktuelproces(); Date start = proces.getstarttid(); Toerring t1 = (Toerring) b1; curdate = DateUtil.createDate(start, 0); asserttrue(proces.beregnstatus(curdate) == StatusType.NOT_DONE); curdate = DateUtil.createDate(start, t1.getminimum() - 1); asserttrue(proces.beregnstatus(curdate) == StatusType.NOT_DONE); curdate = DateUtil.createDate(start, t1.getminimum() - 1); asserttrue(proces.beregnstatus(curdate) == StatusType.NOT_DONE); curdate = DateUtil.createDate(start, t1.getminimum()); asserttrue(proces.beregnstatus(curdate) == StatusType.MINIMUM); curdate = DateUtil.createDate(start, t1.getminimum() + 1); Side 47 af 75

48 asserttrue(proces.beregnstatus(curdate) == StatusType.MINIMUM); curdate = DateUtil.createDate(start, t1.getideal() - 1); asserttrue(proces.beregnstatus(curdate) == StatusType.MINIMUM); curdate = DateUtil.createDate(start, t1.getideal()); asserttrue(proces.beregnstatus(curdate) == StatusType.IDEAL); curdate = DateUtil.createDate(start, t1.getideal() + 1); asserttrue(proces.beregnstatus(curdate) == StatusType.IDEAL); curdate = DateUtil.createDate(start, t1.getmaksimum() - 1); asserttrue(proces.beregnstatus(curdate) == StatusType.IDEAL); curdate = DateUtil.createDate(start, t1.getmaksimum()); asserttrue(proces.beregnstatus(curdate) == StatusType.MAKSIMUM); curdate = DateUtil.createDate(start, t1.getmaksimum() + 1); asserttrue(proces.beregnstatus(curdate) == StatusType.OLD); curdate = DateUtil.createDate(start, t1.getmaksimum() + 5); asserttrue(proces.beregnstatus(curdate) == StatusType.OLD); Som man kan se på ovenstående eksempel er der rigtig meget kode for ikke særlig meget test. Derfor kan man optimere det ved at lade kode itterere igennem alle værdier fra den første grænseværdi og til den sidste. Nogen vil argumentere for at dette ikke er i henhold til ækvivalensklasse-testing eftersom man benytter sig af alle værdierne frem for blot grænseværdierne. public class ProcesTest public void testberegnstatus_toerring(){ proces = portion.getaktuelproces(); Date start = proces.getstarttid(); Toerring t1 = (Toerring) b1; for(int i = 0; i < t1.getmaksimum() + 3; i++){ Date curdate = DateUtil.createDate(start, i); if(i < t1.getminimum()) asserttrue(proces.beregnstatus(curdate) == StatusType.NOT_DONE); else if(i >= t1.getminimum() && i < t1.getideal()) asserttrue(proces.beregnstatus(curdate) == StatusType.MINIMUM); else if(i >= t1.getideal() && i < t1.getmaksimum()) asserttrue(proces.beregnstatus(curdate) == StatusType.IDEAL); else if(i == t1.getmaksimum()) Side 48 af 75

49 asserttrue(proces.beregnstatus(curdate) == StatusType.MAKSIMUM); else asserttrue(proces.beregnstatus(curdate) == StatusType.OLD);... Som man kan se på ovenstående eksempel er dette meget mere minimalistisk at læse og forstå. Dog skal det siges at det dog kræver at man sætter de forskellige if-else if statements rigtigt op for at få de korrekte resultater i henhold til programmets nuværende implementering. Dette er dog ikke noget problem da disse statements blot skal laves i henhold til ækvivalensklassernes deffinitationer fra før. For at færdigøre denne gennemgang af JUnit test skal der også tages forbehold for at det ikke blot er tørrings behandlinger der kan være i et proces-objekt. Dette tjek er designet på samme måde som ved Toerrings-objektet så derfor henvises der blot til source-koden da det ville være redundant at gennemgå dette igen. For at have endegyldigt testet denne klasse skal konstruktoren i klassen også testes. Dette kan gøres ved at opstille de forventninger man har til den, som fx initialisering af forskellige lister og elementer ved at tjekke om de er null. Grunden til at gøre dette er for at undgå forskellige exceptions som fx null-pointer exceptions pga. ikke initializerede lister. I dette test-case er tjekket af konstruktoren designet som følgende hvor største delen af klassens attributter bliver tjekket om de er sat til det ønskede. public class ProcesTest public void testproces() { asserttrue(proces.getstarttid()!= null); asserttrue(proces.getbehandling() == b1); asserttrue(proces.getportion() == portion); asserttrue(proces.getstatus() == StatusType.NOT_DONE); Specielt interessant kode (Fælles) Som ved alle andre systemer er der altid noget kode som er mere interressant end så meget andet. Derfor er dette afsnit tildelt til lige præcis dette, nemlig en gennemgang af det kode som udviklerne har fundet særlig interessant at arbejde med. TimeThread & SystemDato klasserne En af de sjovere problemer som dette system har været udsat for har været, hvordan skal det testes nu hvor systemet skal opdatere hver gang der er gået en ny dag? Det nemme svar ville være at implementere en knap til opdatering, men nu hvor undervisningen har vist at dette kan håndteres igennem brugen af tråde i programmeringen var dette det absolutte mest optimale valg. Og det sjoveste, nu hvor det fik GUI-en til at skifte farve automatisk. Side 49 af 75

50 Så hvad er det lige der er blevet gjort for at systemet er kommet til at kunne automatisk opdatere systemet i real-time men samtidig at opdatere lidt oftere når systemet bliver testet? Det første problem der skulle overvindes var at lave en tråd som konstant kører, sideløbende med hovedsystemet. Så derfor var det nødvendigt at implementere en klasse til lige præcis dette formål, nemlig TimeThread-klassen. public class TimeThread extends Thread { private final int DELAY = 10000; private final boolean TEST = true; Denne klasse extender som en selvfølge Thread superklassen for at det er muligt at kører den som en tråd sideløbende med resten. For at håndtere både hvor ofte tråden skal tjekke for om der er gået en ny dag (real-time) eller inkrementere test-systemets dato med en (test), samt håndtere om den skal gøre det ene eller andet er der i klassen blevet deffineret to konstanter. Nemlig DELAY som håndtere hvor ofte den skal gøre noget samt TEST som håndtere om det er det ene eller andet mode systemet skal kører efter. public class TimeThread extends Thread { public void run() { Date date; try { if (TEST) { while (true) { Thread.sleep(DELAY); date = DateUtil.createDate(dato.getDato(), 1); dato.setdato(date); service.checkvarestatus(); else { while (true) { Thread.sleep(DELAY); date = new Date(); if (DateUtil.daysDiff(date, dato.getdato())!= 0) { dato.setdato(date); service.checkvarestatus(); catch (InterruptedException e) { Så er det basale på plads, så er der faktisk kun en interessant metode tilbage, nemlig run-metoden. Denne metode bliver brugt når tråden, som noget af det første i programmet, bliver initialiceret hvilket gør at det der er deffineret i denne metode skal danne rammer for hele systemets levetid. For at håndtere det at Side 50 af 75

51 tråden ikke skal slutte er der i denne lavet et tjek på om systemet er i det ene eller andet mode for derefter at begynde en uendelig løkke. Til at starte med i loopet bliver tråden sat til at sove i det antal milisekunder som er deffineret i DELAY konstanten for at danne et interval for hvornår tråden skal gentage sine aktioner. Når dette så er overstået er det så afhængigt af om systemet er i test-tilstand eller ej hvad den så gør. Hvis den er i test-tilstand henter den så systemets nuværende dato fra singleton klassen SystemDato som den så tilføjer en dag til efterfulgt af at den sætter SystemDato til at have den nye dato. Så for hver DELAY milisekunder bliver systemets dato inkrementeret med en. Men hvis systemet ikke er i test men i real-time tilstand går den ind og tjekker på om computerens nuværende dato er en anden end den i SystemDato klassen. Hvis dette er sandt vil SystemDato blive sat til at have den aktuelle computer dato. Igen, dette tjek vil blive foretaget for hvert DELAY milisekunder. Som en afsluttende del i både test og real-time modes bliver service metoden checkvarestatus kaldt. Denne metode bliver beskrevet som det næste. SystemDato klassen er en af de mere centrale klasser i systemet. Denne klasse holder altid den aktuelle dato om systemet så er i test-mode eller ej. Grunden til at denne klasse er i model pakken er alene fordi de klasser som fx Portion og Proces der skal tilgå en eller anden form for dato som skal repræsentere start- og slut-tider bliver nød til ikke bare direkte at tilgå computerens dato da dette ville gøre det umuligt at benytte et test-mode. På den måde henter de datoen fra denne klasse som altid har systemets aktuelle date objekt lige meget modet. checkvarestatus & beregnstatus metoderne Nu hvor systemets tidshåndtering er blevet forklaret er disse metoder det naturlige næste-valg, siden det er de metoder som bliver kaldt for hver gang TimeThread gennemgår en itteration. For hurtigt at gennemgå meningen med systemet, kan det sumeres op på få linjer. For hver 'dag' der går i systemet så skal systemets aktuelle processer (aktive portioner) opdateres, forstået på den måde at der skal tjekkes for om de skal have en ny status ud fra både den nuværende behandling samt forløbet de har været i behandlingen indtil nu. public class Service implements Subject { public void checkvarestatus() { for (Opskrift o : dao.getopskrifter()) { for (Portion p : o.getportioner()) { Proces pp = p.getaktuelproces(); if (pp.getstatus()!= StatusType.DONE && pp.getstatus()!= StatusType.SPILD) { pp.beregnstatus(dato.getdato()); notifyobserver(); Den metode som så bliver kaldt for hver dags-inkrementering er checkvarestatus. Nogle vil nok mene at denne metode i sig selv, absolut ikke er interessat da det blot er to for-løkker med et enkelt tjek i midten. Men enkelt er nogle gange godt. Her tager vi alle opskrift-objekterne fra DAO-en, og som vi ved kan vi kører alle dens portioner igennem da de ligger som lister i opskrift-objekterne og derefter tjekke den aktielle processes status. Hvis den aktuelle proces ikke har status af DONE, hvilket vil betyde at portionen er færdig, Side 51 af 75

52 eller SPILD, hvilket betyder at den aktuelle portion er overført til spild, skal der kaldes en beregnstatus på portionen. Grunden til at dette tjek af den nuværende status er nødvendigt er fordi hvis de er færdige er de faktisk pakket og hvis de er spild, ja så er de godt på vej ud til en grisse-farm som fodder. public class Proces { public StatusType beregnstatus(date currentdate) { if (behandling instanceof Dragering) { if (DateUtil.daysDiff( getdonedate(((dragering) behandling).getvarighed()), currentdate) == 0) { sluttid = currentdate; status = StatusType.DONE; portion.naestebehandling(); else if (behandling instanceof Toerring) { Toerring t = (Toerring) behandling; int mindiff = DateUtil.daysDiff(getDoneDate(t.getMinimum()), currentdate); int idealdiff = DateUtil.daysDiff(getDoneDate(t.getIdeal()), currentdate); int maxdiff = DateUtil.daysDiff(getDoneDate(t.getMaksimum()), currentdate); if(status!= StatusType.SPILD && status!= StatusType.DONE){ if (mindiff >= 0 && idealdiff < 0) { status = StatusType.MINIMUM; else if (idealdiff >= 0 && maxdiff < 0) { status = StatusType.IDEAL; else if (maxdiff == 0) { status = StatusType.MAKSIMUM; else if (DateUtil.daysDiff(getDoneDate(t.getMaksimum()), currentdate) > 0) { status = StatusType.OLD; portion.setsluttid(systemdato.getinstance().getdato()); if (status!= StatusType.NOT_DONE) sluttid = currentdate; return status; Det beregnstatus så gør er faktisk slavisk arbejde, så at sige. Den har en parameter i form af den nuværende dato som start-tiden for processen skal tjekkes op i mod. Som man måske kan gætte sig til er det datoen fra SystemDato som normalt bliver givet med. Så hvorfor overhovedet have denne parameter med? Jo, for at kunne teste uden at skulle sætte SystemDato-klassen op, simpel dovenskab, og en lille bonus... Klassernes afhængighed bliver ikke nær så stor. Det selve metoden gør at tjekke for om behandlingen er af en bestemt type for efterfølgende at gennemgå en lang række tjeks for at se om der er sket nok til at processen skal skifte status. Som en start kan behandlingen fx være af typen Dragering. I dette tilfælde kan processen have to forskellige statustyper, NOT_DONE og DONE. Det skal så siges at en dragering har en varigheds-attribut som repræsentere den tid Side 52 af 75

53 behandlingen tager. For derfor at gå fra NOT_DONE til DONE kræver det at currentdate er lig med starttidattributten plus varigheds-attributten. Hvis dette er tilfældet skiftes der status og den næste behandling i opskriften bliver kaldet. Men hvad hvis den nu behandlingen er af typen Toerring? Jo her er det mere interessant da dette, som beskrevet i afsnittet omkring testing, indeholder nøje implementerede tjek for værdierne. Hver af disse tjeks kan resultere i at processen skifter status til MINIMUM til IDEAL til MAKSIMUM til OLD. Dette er den naturlige gang en proces kan komme igennem, forhåbentligt bliver portionen plukket før den ender med status OLD. Når alle portioner er blevet tjekket igennem kaldene i checkvarestatus er der et sidste metodekald til notifyobserver som leder til den sidste del af dette afsnit, nemlig ColorRender-klassen i MainFrame-klassen. ColorRender-klassen Det er okay bare at inkludere en processes status i dens tostring metode for at indikere hvor langt den er nået i tørringen på lageret, men det giver ikke rigtig noget illustrativt til at idendikere den pågældende status. Altså det er nemmere at overse tekst med samme farve men med forskellig indhold. Derfor har udviklerne haft den ide, lige fra starten af designprocessen at der skulle være en eller anden form for farvekodning for hvornår en proces har en given status. public class MainFrame extends JFrame implements Observer { private class ColorRenderer extends BasicComboBoxRenderer { private static final long serialversionuid = private JList private Border border; public ColorRenderer(JList list) { this.list = list; border = new LineBorder(Color.WHITE); public Component getlistcellrenderercomponent(jlist list, Object value, int index, boolean isselected, boolean cellhasfocus) { super.getlistcellrenderercomponent(list, value, index, isselected, cellhasfocus); settext(value.tostring()); StatusType status = ((Proces) value).getstatus(); if (status == StatusType.NOT_DONE) setbackground(listopskrifter.getbackground()); else if (status == StatusType.MINIMUM) setbackground(color.yellow); else if (status == StatusType.IDEAL) setbackground(color.green); else if (status == StatusType.MAKSIMUM) setbackground(color.red); else if (status == StatusType.OLD) { Side 53 af 75

54 setbackground(color.black); setforeground(color.white); if (isselected) setbackground(new JList().getSelectionBackground()); return this; Til denne opgave er der blevet implementeret en privat klasse i GUI-pakkens MainFrame-klasse. Det klassen gør er at nedarve fra BasicComboBoxRender som basalt set er den der håndtere hvordan det illustrativt skal vises i GUI-en og ikke mindst hvad der skal stå i de forskellige elementer i JListen. Når listens indehold så bliver sat ved at kalde setlistdata bliver hver objekt som bliver sat i listen tjekket for dens pågældende status for derefter at sætte en tilhørende baggrundsfarve for at indikere den illustrativt. Denne illustrative funktion gør det muligt for folk der måske er ordblinde også at arbejde med dette system. Oven i det kan det være at det gør at folk, gennem læsningen af farver, undgår at der er særlig mange vare som går til spilde. Guided Tour (Fælles) Vi vil i vores guided tour vise hvordan vores system virker i en simulering. I det gennemgående eksempel vil vi vise hvordan en ny opskrift oprettes og oprette en portion med denne. Når programmet startes mødes vi af et vindue, hvor vi har valgt at bruge tabs til at manøvrere rundt i programmet. En opskrift tab der viser en liste over opskrifter, samt to knapper: enten til at oprette en ny opskrift eller få vist hvilke behandlinger en opskrift indeholder. Vi starter med at se hvad NiceLakrids indeholder, for derefter at lave en ny opskrift. Side 54 af 75

55 Vælges en behandling, aktiveres knapperne i midten, hvorefter man kan rykke op og ned på behandlingernes behandlingsindeks. Det er også muligt at fjerne en behandling fra NiceLakrids, eller tilføje en ekstra fra Alle behandlinger. Det er ikke muligt at fjerne en behandling fra Alle behandlinger. Vi opretter nu en ny opskrift og opretter og tilføjer denne en tørrings behandling, med minimum tørring 1 dag, ideal tørring 2 dage og maksimum tørring 3 dage. Dette bliver denne opskrifts eneste behandling. Vi trykker nu Ok knappen og opskriften bliver tilføjet listen over opskrifter i vores Opskrift tab. Side 55 af 75

56 Vi trykker nu på vores Portion tab. Her findes en liste over alle igangværende processer. Til at starte med er listen altså lige nu tom. Vi trykker på Opret Portion og får en liste med de mulige opskrifter. Vi vælger nu den netop oprettede opskrift og sætter en portion i gang. Da denne portions første og eneste behandling er af typen tørring, skal den ind på mellemvarelageret og have en placering. Vi vælger derfor en placering. Side 56 af 75

57 Når en placering er valgt, sættes processen i gang. Portionens aktuelle proces vises i listen. I dette eksempel er der kun en behandling, som er en tørring. Denne tørring bør plukkes efter 2 dage, da den der har den ideelle konsistens. Til at illustrere processens status markeres portionen i listen i forskellige farver. Grå når portionen ikke har nået minimal tørring endnu og derfor ikke kan plukkes, gul ved minimal tørring, grøn ved ideel tørring, rød ved maksimal tørring og sort når tørringen har været for længe på lager og skal plukkes til spild. I dette eksempel plukker vi ved ideel tørring og portionen sendes derfor til pakning. Sammenligner vi de to virksomheders nettoomsætning, er Toms 4,31 gange større end Carlettis. Toms har dog endnu mere på lager end Carletti i forhold til omsætning da Toms varebeholdning er 5,9 gange større end Carlettis. Antager vi, at gælden til leverandørerne, er hvad der er blevet brugt på dette punkt, har Toms brugt 4,6 gange mere end Carletti. Side 57 af 75

58 Toms har meget mere på lager, men Carletti bruger mere på leverandører i forhold til beholdningen. Dette kan tyde på at Carletti vil gøre mere for at komme af med deres varer, men at de også må betale sig fra det i form af flere penge på transport eller leverandører. Disse tal kan selvfølgelig ikke sammenlignes ordentligt, da vi har lavet nogle antagelser, samt vi ikke kender grunden til fx Toms store varebeholdning. Der kan være forskel på fx produktionstiden hos Toms, som gør at varerne skal ligge længere tid på lageret. Som endelig vurdering af logistik systemet, må man sige at Carletti A/S er velfungerende, da de trods alt har et stort overskud(reference). Det ser ud til, at de er gode til at få sendt deres varer af sted fra deres lager, selvom de har en høj lagerservicegrad. Deres samspil mellem leveringsservice og logistikomkostninger ses fx i form af, at de både er masseproducerende men samtidig kan omstille sig. Dette viser, at de er leveringsfleksible og samtidig har logistikomkostningerne til at kunne fuldføre dette. Et spil som resulterer i logistisk effektivitet. Konklusion Delkonklusion - Informations Teknologi i Organisationer: Arbejdet med ITO har været en stor udfordring og en periode med mange frustrationer. Det var utrolig svært at begrænse sideantallet, da ITO er et meget vidt begreb og de givne problemstillinger kunne angribes på mange måder. Da vi endelig synes at have overkommet vores frustration og vi var kommet frem til en fornuftig indgangsvinkel, kunne vi begynde at skrive. Vores resultat i ITO er endt med at have størstedelen af fokus på hvordan Carletti fungerer som produktionsvirksomhed, samt en løsning på mellemvarelager problemet. Delkonklusion - Software Design: Efter at have lavet en business case i ITO blev vi hurtigt enige om nogle centrale use cases. Dette gjorde at arbejdet med system design blev sat hurtigt i gang, da vi allerede har skabt os et godt overblik over, hvordan vores IT-løsning i sidste ende skal fungere. Dog faldt vi over nogle frustrationsmomenter, blandt andet synes iterationsprocessen uendelig, i det man hele tiden skulle vurdere og revurdere ens arbejde i forhold til nye tiltag. Vores resultat i SD gav et godt startskud til vores software konstruktionen. Vi synes især vores færdiggørelse af design diagrammet gav grundlag for gode centrale løsninger i forhold til use cases og derefter andre SD redskaber. Delkonklusion - Software Konstruktion: Vores software konstruktion er lavet på baggrund af vores system design. Det var derfor relativt hurtigt at få lavet programmets model og lave en simpel simulering uden GUI. SK forløbet handlede derfor at lægge sig tæt op ad vores design, som var en af udfordringerne i SK. Side 58 af 75

59 Den største udfordring i software konstruktionen var at lave vores GUI, hvis simple design vi trods alt er meget tilfredse med. Alt i alt synes vi dog at vores program er yderst velfungerende og at det er lykkedes at opnå et brugervenligt enkeltbrugersystem. Overordnet konklusion: I dette projekt har vi arbejdet ud fra problemstillingen med et mellemvarelager problem angående overskridende tørretider, og vores opgave har været at lave et system der løser dette. Vores system håndterer oprettelsen af opskrifter, portioner, behandlinger, samt placeringer. Derudover bliver tørretidernes status vist i en liste med portioner i farvekoder til hurtigt at skabe et overblik over portionens status i handlingsforløbet. I forhold til Carlettis nuværende system med sedler, synes vi at dette er en fremragende løsning til deres problem med spildprocent. Samarbejdsmæssigt har vi været gode til i gruppen, at uddelegere opgaver men samtidigt assistere hinanden. Side 59 af 75

60 Bilag Klassebeskrivelser Navn: Opskrift Mening med klassen: Denne klasse er roden til at hele modellen kan fungere. Uden den her klasse vil mange af de følgende klasser ikke kunne eksistere. Opskrift-klassen er en simpel klasse der modellere en opskrift på et produkt som fx drageret lakrids. Denne klasse kunne dog godt have indeholdt en liste over ingredienser og lignende, men eftersom dette er et lager system var det kun nødvendigt med en rækkefølge af behandlinger. Attributter: Metoder: navn : String o Dette er en form for overskrift på opskriften som fx Drageret Lakrids, som identificere objektet count : int o Denne variabel holder styr på hvor mange portiner der er lavet af den specifikke opskrift og danner bund for et ID på portion-objekterne der bliver skabt ud fra opskriften portioner : List<Portion> o Dette er en link-attribut som holder styr på alle de portioner som enten stadig er under behandlig eller som er færdigbehandlede. Spildte portioner bliver fjernet fra denne liste. behandlingsindekser : List<BehandlingsIndeks> o Denne liste er også en link-attribut. Dens opgave er holde objekter af typen BehandlingsIndeks som holder styr på de behandliger en opskrift skal igennem og i hvilken rækkefølge de skal igennem dem. Opskrift(navn : String) o Konstruktoren for klassen som opretter et objekt med et specifikt navn opretportion() : Portion o Metode til at oprette et nyt portions-objekt. Denne metode får ingen parametre med da klassen indeholder nok information til selv at oprette et Portions objekt med de rette informationer. Dette sikre også at brugeren ikke videregiver forkerte data til metoden. Når den objektet er blevet oprettet vil det oprettede objekt både blive tilføjet til listen over portioner samt returneret til brugeren. fjernportion() o Metode til at fjerne et specifikt portions objekt fra listen med opskriftens portioner. Denne metode vil normalt vis kun blive brugt hvis en portion er blevet for gammel og skal flyttes til spild. naestebehandlingsindeks(indeks : int) : BehandlingsIndeks o Når en portion så er færdig med en behandlig og skal videre til den næste behandling i rækkefølgen af behandlinger bliver denne metode kaldt ud fra portionens nuværende behandlingsindeks. Det nye BehandlingsIndeks vil derefter blive fundet frem og returneret. Hvis portionen har været ved den sidste behandling vil der bliver returneret null. addbehandlingsindeks(behandlingsindeks : BehandlingsIndeks) o Denne metode tilføjer et BehandlingsIndeks til opskriften. Der skal dog sørges for at Side 60 af 75

61 Multiplicitet og association: behandlingsindeksernes indeks kommer i en kontinuerlig rækkefølge så der startes fra nummer et og ellers to, tre, og fire osv. Der må bare ikke optræde nogle gaps mellem dem. Denne klasse har to associationer til andre klasser. Den ene er hen til klassen BehandlingsIndeks som er en enkeltrettede association mod den sidstnævnte klasse. Grunden til dette er at en Opskrift kan skal have mindst et BehandlingsIndeks, ergo mindst en behandling, men kan have flere. Modsat er det ikke nødvendigt for BehandlingsIndekserne at vide hvilken Opskrift de tilhører da man på den måde kan bruge dem til andre Opskrift-objekter så længe det giver meningen i deres rækkefølge. Denne multiplicitet bliver implementeret gennem en liste i Opskrift objektet over BehandlingsIndekser. Den anden association er over til klassen Portion (beskrevet senere). Denne sammenhæng er af typen komposition af den grund at en Portion altid skal have en Opskrift tilknyttet, derfor skal den af gode grunde oprettes igennem en Opskrift. Dette sikre at Portionen får en Opskrift tilknyttet da det kan videregives ved oprettelsen. Selve multipliciteten er næsten allerede forklaret. En Opskrift kan have mange portioner på en gangn men en Portion skal have en Opskrift. Selve implementeringen af dette ligger i bl.a. en liste i Opskrift-klassen samt metoder til at oprette en Portion. Portions-klassens konstruktor er derfor gjort package-private så det kun er interne klasser i model pakken der kan benytte den her tiltænkt Opskrift-klassen. Side 61 af 75

62 Navn: Portion Mening med klassen: Denne klasse er til for at modellere en portion af en opskrift forstået på den måde at det er når man har besluttet sig for at der skal laves mere af en type Opskrift oprettes der et objekt af Portions-klassen for at illustere en nybegyndt omgang af en Opskrift. Attributter: Metoder: varenr : int o Dette nummer et ID på hvor i rækkefølgen af oprettede portioner af en specifik opskrift denne portion er. Dette nummer er videregivet fra Opskrift-objektet som opretter Portionen. starttid : Date o Når en portion bliver oprettet gennem en opskrift bliver der registreret en dato på hvornår portionen blev startet/oprettet. sluttid : Date o Når en portion har været gennem alle behandlinger bliver der registreret en dato for hvornår portionen blev færdig. opskrift : Opskrift o Som beskrevet tidligere er dette en link-attribut til Opskrift-klassen som bliver videregivet ved oprettelsen af Portions-objektet gennem kaldet til opretportion. processer : List<Proces> o Liste over de processer (behandlinger) en portion har været igennem indtil nu. Hvis det sidste element i listen er null er det en indikation på at portionen er færdig. placering : Placering o Denne attribut beskriver den placering den specifikke portion har på lageret når den står og udfører en proces med en behandling af typen Toerring Portion(opskrift : Opskrift, varenr : int, behandlingsindeks : BehandlingsIndeks) o Klassens konstruktor, package private, som opretter og initialisere de forskellige attributter klassen har. Her iblandt sætter opskrifts objektet, varenr samt det første behandlingsindeks i rækkefølgen af behandlingsindekser naestebehandling() o Denne metode får fat i det næste BehandlingsIndeks fra Opskrift objektet hvor efter den begynder en ny Proces med den pågældende Behandling som ligger i BehandlingsIndeksobjektet opretproces(behandling : Behandling) : Proces o Når et Portions-objekt skal til sin næste behandling skal denne registreres gennem oprettelsen af et Proces-objekt som holder behandlingen samt status for denne. getaktuelproces() : Proces o Når man ønsker at finde ud af hvor en Portion pt. er i hele forløbet kaldes denne metode. Hvis en portion er færdig vil den returnere null ellers vil den sidste proces i portionens liste over processer blive returneret. Multiplicitet og association: Denne klasse har tre associationer til andre klasser, men eftersom den ene af dem allerede er blevet beskrevet vil der her blive forklaret de to andre. Den første association er til klassen Placering. Her kan en Side 62 af 75

63 portion enten have nul eller en placering forstået på den måde at enten er Portionen på lageret (optager en placering) ellers er den til dragering (optager ingen placering). Implementeringen af denne er en simpel attribut i klassen af typen Placering som kan sættes gennem kald til setplacering(placering : Placering). Den anden association er til klassen Proces. Denne association er af typen komposition som gør at Portion skal stå for oprettelsen af objekter af Proces-klassen. Forholdet mellem Portion og Proces er en til nul til mange, alene af den grund at en portion har været igennem mange processer. Nogen vil dog mene at en portion kun burde have en proces, men eftersom vi gerne vil holde styr på hvad en portion har været igennem og hvornår, er der her valgt at holde multipliciteten som en til nul til mange. Implementeringen af dette forhold er som i tidligere beskrivelse. Nemlig i form af en liste med processer i Portions-klassen samt et objekt af typen Portion i Proces-klassen som bliver givet ved oprettelsen af Proces-objekterne. Side 63 af 75

64 Navn: Proces Mening med klassen: Klasse til at modellere en proces, en specifik portion har været igennem på en specifikt tidspunkt. En proces er derfor noget der bliver oprettet løbende når en Portion er blevet færdig med en foregående behandling og så skal til en ny. Attributter: Metoder: starttid : Date o Når en proces bliver oprettet bliver der registreret en tid sluttid : Date o Når en proces, dens behandling, er færdig bliver der ligeledes registreret en tid behandling : Behandling o Link-attribut som beskriver den behandling en proces skal igennem før den kan erklæres færdig. portion : Portion o Link-attribut som er det objekt, af typen Portion, som har oprettet den specifikke proces. status : StatusType o For hver gang beregnstatus() bliver kaldt bliver attributten sat til at være den nye status processen har se beskrivelse af enumklasse. Attributten beskriver hvor i behandlingen en proces er. StatusType.NOT_DONE når en behandling ikke er færdig (behandlingsuafhængig) StatusType.MINIMUM når en tørring har opnået minimum tørretid StatusType.IDEAL når en tørring har opnået ideal tørretid StatusType.MAKSIMUM når en tørring har opnået maksimum tørretid StatusType.DONE når en dragering er færdig StatusType.OLD når en portion har tørret længere tid end maksimum Proces(behandling : Behandling, portion : Portion) o Konstruktoren for klassen. Denne er package-private da denne klasse har et kompositionsforhold til Portions-klassen. Når denne bliver kaldt bliver den kaldt så den kan oprette en ny proces for en specifik portion med en specifik behandling. beregnstatus(currentdate : Date) : StatusType o Metode til at beregne en eventuel ny status for processen. Denne metode får en dato med som den bruger til at sammenligne med Proces-objektets starttid. Hvis beregningerne ud fra currentdate så opfylder kravet for et status-skift bliver statusattributten sat til den nye beregnede status. Denne vil også blive returneret. Det er forskelligt hvad kravenen for sådan et skift er, alt afhængig af om det er en behandling af typen toerring eller dragering. Multiplicitet og association: Denne klasse har to associationer, hvor af den ene allerede er blevet forklaret. Der vil nu blive forklaret den anden. Den anden er en enkeltrettet association til klassen Behandling. For at forklare dette er det vigtigt af forstå at grunden til at Proces-klassen er i modellen er for at vi kan køre statistik på hvornår de forskellige processer er startet, sluttet og for hvilke behandling. Derfor er en proces en form for indpakning af en behandling der gør at vi kan tilføje flere data til en behandling som ikke ville have noget Side 64 af 75

65 direkte med en behandling at gøre. Så en proces har en behandling den holder styr på men behandlingen kender ikke noget til processen da den er enkeltrettet og kan derfor bruges i mange processer, bl.a. for andre portioner og opskrifter samt behandlingsindekser. Side 65 af 75

66 Navn: Placering Mening med klassen: Klassen skal repræsentere de placeringer der er på lagergulvet på lageret. De bliver beskrevet ud fra to koordinater så de nemt kan findes. Attributter: Metoder: x : int o Koordinat værdien for x-aksen y : int o Koordinat værdien for y-aksen portion : Portion o Objektet af typen Portion som bliver sat når en portion kommer ind på den specifikke placering. Placering(x : int, y : int) o Klassens konstruktor som opretter et objekt med et koordinatsæt x og y frigoer() o Når en portion skal til en dragerings-behandling og lige har stået på lageret bliver denne metode kaldt som så vil frigive placeringen og sætte portionens placerings-attribut til null så placerings-objektet kan optages af en ny portion optag(portion : Portion) o Når en portion skal have en plads på lageret kaldes denne metode som så både vil sætte dens egen portions-attribut til at være portionen men også sætte portionens placeringsattribut til at være den valgte placering. isfri() : Boolean o Tjekker om portions-attributten er sat, hvis den er bliver der returneret false ellers true. Multiplicitet og association: Denne multiplicitet er allerede forklaret tidligere. Side 66 af 75

67 Navn: BehandlingsIndeks Mening med klassen: Klasse til at kunne holde styr på i hvilken rækkefølge de forskellige behandlinger skal komme i. Attributter: Metoder: indeks : int o Nummer som beskriver den placering en behandling har i forhold til andre i opskriftens behandlingsforløb behandling : Behandling o Behandlingen på det specifikke indeks som en portion skal igennem når den kommer til dette indeks Indeholder almene get metoder til brug i andre klasser. Multiplicitet og association: Denne klasse har to associationer hvoraf den ene er beskrevet tidligere. Den anden association er en enkeltrettet nul til mange til en til klassen Behandling. Der skal derfor forståes at et behandlingsindeks skal have en behandling for at kunne eksistere men behandlingen behøver ikke at vide hvilket indeks den ingår i. Dette gør derfor også at den samme behandling kan indgå i mange forskellige behandlingsindekser. Side 67 af 75

68 Navn: Behandling Mening med klassen: Denne klasse er en abstrakt klasse der gør det muligt at generalisere de to under-klasser som værende den samme type. Dette er den hovedsagelige grund til at denne klasse er med i systemet. Eftersom de to under-klasser ikke har noget attribut-mæssigt til fælles er denne klasse tom. Attributter: Metoder: Multiplicitet og association: Side 68 af 75

69 Navn: Toerring Mening med klassen: Denne klasse skal modellere en tørring af en portion ud fra nogle givne attributter der beskriver hvor lang tid en portion skal være på lager for at opnå en specifik tørre-status. Hvis en portion står længere end til maksimum tid vil portionen få StatusType.OLD. Dette bliver beregnet, som beskrevet, i Proces-klassen Attributter: Metoder: minimum : int o Antal dage en portion skal stå, beregnet ud fra processens starttid, for at få StatusType.MINIMUM ideal : int o Som ved minimum blot får portionen StatusType.IDEAL maksimum : int o Som ved minimum blot får portionen StatusType.MAKSIMUM Multiplicitet og association: Denne klasse er en sub-klasse til super-klassen Behandling. Grunden til dette er en del af designet, er for at man kan generellisere mellem de to behandlingstyper, tørring og dragering, så man kan lave en liste med begge typer behandlinger i, i Proces klassen. Side 69 af 75

70 Navn: Dragering Mening med klassen: Er med i modellen for at modellere en behandling af typen dragering Attributter: Metoder: type : DrageringsType o Denne attribut er af en enum-type som begrænser hvilke værdi attrubutten får DrageringsType.FARVE type en Dragering får hvis portionen skal have et farvelag på DrageringsType.SUKKER type en Dragering får hvis portionen skal have et sukkerlag på varighed : int o Beskriver den varighed det tager, i dage, før at portionen er færdig med den pågældende dragerings-behandling. Multiplicitet og association: Denne klasse er en sub-klasse til super-klassen Behandling. Grunden til dette er en del af designet, er for at man kan generellisere mellem de to behandlingstyper, tørring og dragering, så man kan lave en liste med begge typer behandlinger i, i Proces klassen. Side 70 af 75

71 Navn: SystemDato Mening med klassen: Denne klasse er med for at have et centralt sted objekter i modellen kan hente en dato fra. I samarbejde med TimeThread gør det det muligt at simunere en eksekvering af systemet så man ikke skal vente en hel dag på at se om systemet opdatere en proces' status. Grunden til at den ligger i modellen er at hvis den lå andre stedder vil model-klasserne ikke kunne tilgå den da det vil give et kald op i de fire(tre) lag af modellen, hvilket ikke er en valid aktion. Klassen er designet efter singleton-mønstret hvilket betyder at der i hele systemet kun er et objekt af denne type. Attributter: Metoder: dato : Date o Denne attribut holder på systemets nuværende dato. Den vil ved initialisering blive sat til systemets nuværende dato igemmen kald til Date-konstruktoren Multiplicitet og association: Denne klasse har ikke et forhold til andre klasser som den har kendskab til. Se beskrivelsen for TimeThread-klassen for større uddybelse. Side 71 af 75

72 Navn: TimeThread Mening med klassen: Denne klasse håndtere det at tjekke for om der er gået en dag. Klassen er en udvidelse af java klassen Thread hvilket gør at den kører sideløbende med resten af programmet. Klassen er opbygget så den har to tilstande, en til test og en til real-time. Det gør at man kan teste så man siger at for hver gang der er gået et konstant antal sekunder vil der være 'gået' en dag. Dette gør at når systemet skal testes for fx skift i portioners statuser skal programmøren der tester det ikke vente en hel dag på at se et skift i status. Den anden tilstand er den som bliver valgt når systemet skal kører ude på lageret. Her tjekker tråden for om der er gået en dag, igen, hver gang der er gået et antal sekunder. I begge tilstande vil der ske det samme når kravene for et dag-skifte er opfyldt, uafhængig af hvilken tilstand der er tale om. Det der sker er at singleton-objektet af klassen SystemDato bliver sat til en ny dato og Service klassens metode, checkvarestatus bliver kaldt for at opdatere alle portioners status. Attributter: Metoder: final DELAY : int o Denne konstant bestemmer hvor ofte der skal ske noget, om det er tjek for ny dag (realtime mode) eller om det er at der skal inkrementeres en dag. Denne konstant er udtryk for de millisekunder tråden skal sove før den tjekker igen. final TEST : boolean o Konstant til at holde styr på om det er test-mode eller ej. Hvis true den sat til test-mode. Multiplicitet og association: Denne klasse har to forhold der er værd at forklare, dette er kort beskrevet i meningen med klassen. Når kriterierne for et tjek er opfyldt går klassen ind og opdatere datoen på singleton objektet af SystemDato samt kalder checkvarestatus i singleton objektet i Service. Multipliciteten er lidt triviel at forklare da den kun kan trække et objekt fra hver klasse da der kun er muligt at oprette et af begge objekter. Side 72 af 75

73 Navn: Service Mening med klassen: Klasse som har ansvaret for at oprette objekter samt lagre dem i DAO-en. Det er også denne klasses ansvar at tjekke alle portioners dato hver gang TimeThread sætter den til det. Denne klasse er som DAO og SystemDato også designet ud fra singleton-mønstret. Attributter: Metoder: opretopskrift(navn : String) : Opskrift o Metode til at oprette og opbevare et Opskrift-objekt ud fra et givent navn. opretbehandlingsindeks(indeks : int, behandling : Behandling) : BehandlingsIndeks o Metode til at oprette og returnere et behandlingsindeks ud fra et indeks og en behandling opretplacering(x : int, y : int) : Placering o Metode til at oprette et Placerings-objekt samt opbevare det. oprettoerring(minimum : int, ideal : int, maksimum : int) : Toerring o Metode til at oprettet et Toerrings-objekt ud fra givne værdier for forskellige stadier for tørring. Det er dog et krav at følgende udtryk er overholdt: 0 < minimum < ideal < maksimum. Dette objekt bliver også opbevaret i DAO-en. opretdragering(type : DrageringsType, varighed : int) : Dragering o Metode til at oprette et Dragerings-objekt udfra dens type samt varighed. Dette objet bliver også opbevaret i DAO-en. checkvarestatus() o Denne metode bliver hovedsageligt kaldt af TimeThread som efter et givent tidsrum kalder den. Derefter tjekker metoden om der er nogle ændringer i de forskellige portioners status ved at kalde beregnstatus(currentdate : Date) hvor parameteren er datoen fra SystemDato-klassen. Når disse er tjekket bliver der kaldt en notifyobserver metode der siger til GUI-en at der er sket ændringer i de forskellige statuser og den skal derfor opdatere sine grafiske repræsentationer i form af lister. Multiplicitet og association: Denne klasse er en af de mere centrale og interessante klasser når man snakker om forhold til andre klasser. Til at starte med så har den et forhold til SystemDato-singletonklassen. Grunden til dette er at når TimeThread-klassen tjekker og udfører aktionerne ved et gyldigt tjek er at kalde checkvarestatus som går ind og sammenligner den nuværende SystemDato dato med de forskellige deadlines som portionerne har. Derfor skal den kunne hente SystemDato objektet for at hente dens dato og sammenligne ud fra den. Der udover har den et forhold til DAO-klassen. Da denne klassen fx opretter en Opskrift skal denne også kunne gemmes efter oprettelsen. Dette gøres ved at hente DAO-singleton-objektet og gemme den i det. Dog behøver DAO-en ikke kende noget til Service klassen, derfor den givne multiplicitet. Dernæst har denne klasse en implementering af interfacet Subject. Grunden til dette er for at hvergang klassen har kørt dens checkvarestatus skal den sende besked til dens observere, som i dette tilfælde er GUI-en, MainFrame, da denne så skal opdatere dens respektive grafiske lister. Side 73 af 75

74 Design Klasse Diagram Side 74 af 75

75 Carletti Tidslinje Historisk tilbageblik fra første pc bliver købt Posepakkemaskine anskaffes til dragé afdelingen omsætningen stiger til 109 mio. kroner 1991 stor ekspansion ved tilkøb af nye maskiner opkøb af tempereringsmaskiner fra nedlagte tyske fabrikker køb af affugtningsanlæg til forbedring af skumprodukter. Salg og eksport stiger til 125 mio. kroner 1992 edb-systemet Concorde anskaffes Jomet-pakkemaskine bliver købt til pakning af posevarer og p-tærter. Salget af posevarer fortsætter med at stige. Big Ben flyttes til Bentsfors hvorefter det flyttes til Warszawa et par år senere. Erling støbeanlægget flyttes ligeledes til Polen Nordic Candy lukker opkøber bøttepakker og SQC-system. Mangel på tørreplads og udbygning af kontor Pålægschokolade pakningen bliver fuldautomatisk Fabrik i Mjölby opkøbes. Pladsmangel udbygning af fabrikken, hal 4 bliver til, en top moderne chokoladefabrik Hal 4 trækker mange ressourcer, yderligere investeringer bliver udskudt Carletti opkøber Brdr. Christensen. Produktsortimentet udvides med velindarbejdet varer, såsom pålægschokolade. Salgsstyrken vokser og omsætningen stiger med over 30 mio. kroner. Dog er der underskud på 5 mio. kroner 1996 Concorden bliver udvidet med nye moduler: databasemodul, lønmodul og edi-modul Brdr. Christensen implementeres og det ny indkøbte grej køres ind i produktionen. Fabrikken i Skødstrups pakkesystem opgraderes og omsætningen dette år steg til over 400 mio. kroner Mange ældre maskiner bliver skiftet ud med nyere og Guernsey Bell bliver opkøbt pga. deres is produkter. Der bliver satset mere og mere på produkter der tjenes penge på Dansk Chokoladefabrik indlemmes. En konkurrent mindre AXAPTA bliver implementeret. Fedt siloen i Skødstrup kan ikke længere opfylde fabrikkens krav Der bliver satset stort på pålægschokoladen og det giver pote Bulk-pakker alt pakning tiden bliver reduceret kraftigt. P-tærte og skumbananernes 50 års jubilæum. Side 75 af 75