Kravspecifikation for dokumentationsværktøj til produktmodellering

Kravspecifikation for dokumentationsværktøj til produktmodellering Polyteknisk eksamensprojekt, 2002 Hovedrapport Vejledere: Lars Hvam & Jesper Riis Institut for Produktion og Ledelse Danmarks Tekniske Universitet Simon Pape, C958196 Publikationsnummer IPL-128-02

Kravspecifikation for dokumentationsværktøj til produktmodellering Polyteknisk eksamensprojekt Copyright c Simon Pape Printet med LATEX 2ε

Forord Denne rapport er resultatet af et halvårigt eksamensprojekt, udført ved Institut for Produktion og Ledelse (IPL) på Danmarks Tekniske Universitet (DTU) i perioden 1/3-15/10 2002. Projektet udgør afslutningen på civilingeniørstudiet og er udført under vejledning af lektor Lars Hvam og ph.d.-studerende Jesper Riis. Projektets formål er at få afdækket og specificeret kravene for et dokumentationsværktøj til produktmodellering og bunder i en frustration over arbejdsbyrden forbundet med manuel opbygning og vedligeholdelse af dokumentationen i forbindelse med arbejdet med produktmodeller. I den empiriske del af projektet har jeg samarbejdet med fire virksomheder: APC Denmark A/S, GEA Niro A/S, F.L. Smidth A/S og Vitral A/S, der alle har bidraget konstruktivt med holdninger til projektet. Resultatet er ud over en kravspecifikation for et dokumentationsværktøj et oplæg til, hvordan dokumentationsværktøjet kan udvikles, samt en idé til en mulig projektorganisation. Jeg vil gerne benytte lejligheden til at rette en tak til mine vejledere, Lars Hvam og Jesper Riis, for deres vejledning og inspiration. Især en stor tak til Jesper Riis for hans store engagement og mange konstruktive forslag samt tålmodige gennemlæsning af rapporten. En stor tak skal også lyde til medarbejderne i de fire virksomheder for deres interesse og engagement i projektet. Især vil jeg rette en tak til Mikkel Dalgas fra APC Denmark A/S, Søren Poulsen fra F.L. Smidth A/S og Aage Wind fra Vitral A/S. Herudover også en stor tak til ph.d.-studerende Martin Malis og Benjamin Loer Hansen for deres interesse og konstruktive indspark til projektet. Slutteligt skal lyde en stor tak til Sara Aabolt Christensen for utrættelig korrekturlæsning, og til Henrik Jørgensen, Martin Harss, Jørgen Lindegaard Pedersen og Kasper Edwards for deres store bidrag til det sociale liv på instituttet især gennem de altid livlige frokostdebatter og kaffepauser. Lyngby, 15. oktober 2002 Simon Pape C958196 i

Resumé Erfaringer fra arbejdet med produktmodeller har vist, at der eksisterer et behov for et IT-baseret dokumentationsværktøj, som kan understøtte arbejdet. Dette kan ske ved, at det varetager mange af de administrative og trivielle opgaver, der både er tidskrævende og kan udføres bedre af en computer. Hovedformålet med dette eksamensprojekt er at afdække kravene for et dokumentationsværktøj til produktmodellering. Kravene er blevet afdækket ved at undersøge produktmodelleringsprocessen hos fire virksomheder, der benytter sig af produktmodellering (GEA Niro A/S, APC Denmark A/S, F.L. Smidth og Vitral A/S). Forud for det empiriske arbejde er lavet et litteraturstudie for at afdække fire overordnede områder: - Udvikling af informationssystemer Introduktion til livscyklusmodeller og udviklingsprojekters faser. - Det objektorienterede paradigme Tankegangen bruges inden for produktmodellering og systemudvikling. - Produktmodellering Opbygning af forståelsesramme som baggrund for projektets domæne. - IT-understøttet dokumentation Afdækning af funktionalitet i CASE-værktøjer og PDM-systemer. På basis af kravspecifikationen undersøges om der findes et standardsystem, der kan imødekomme kravene, eller om egenudvikling er nødvendig. I den forbindelse laves også et estimat af omkostningerne forbundet med egenudvikling såvel som køb af standardsystemer. Under vurderingen af standardsystemerne undersøges også, hvordan disse kan integreres med virksomhedens øvrige informationssystemer. Rapporten konkluderer, at et værktøj baseret på Lotus Notes vil være en hensigtsmæssig løsning. Løsningen vil kunne imødekomme de opstillede krav, og samtidig være billig og fleksibel. Herudover lægges op til, at den videre udvikling af dokumentationsværktøjet sker i samarbejde mellem Center for Produktmodellering (CPM), et antal interesserede virksomheder og evt. et softwareudviklingsfirma. iii

Executive Summary Experience from the field of product modelling has revealed that a need exists for an IT-based documentation tool to support the product modelling process. Time can be saved by letting a documentation tool handle trivial time consuming tasks, as these tasks are often better handled by a computer. The main objective of this thesis is to reveal and document the requirements for a documentation tool for product modelling. The requirements have been gathered and structured based on an analysis of the existing product modelling process at four Danish companies (GEA Niro A/S, APC Denmark A/S, F.L. Smidth and Vitral A/S). Prior to the empirical work a theoretical study has been performed in order to cover four main fields: - Development of information systems Introduction to life cycle models and the phases of system development. - The object oriented paradigm The domain is applicable to product modelling and system development. - Product modelling A frame of comprehension for the domain of the project. - IT-based documentation Analysis of the functionality in CASE-tools and PDM-systems. Based on the requirement specification it has been analyzed if a standard system will be able to meet the requirements, or development from scratch is necessary. Estimates have been made to clarify the costs associated with both own system development and acquisition of standard systems. Included in the assessment of the standard systems is also an analysis of how they can be integrated with other information systems. The conclusion of the thesis is that a tool based on Lotus Notes will be an appropriate solution meeting the requirement specification and at the same time being a surprisingly affordable and scalable solution. In addition to this, it is suggested that the further development is carried out in co-operation between Centre for Product Modelling (CPM), a number of interested companies and perhaps a software development company. v

Indhold 1 Introduktion 1 1.1 Formål og baggrund......................... 1 1.2 Problemformulering......................... 3 1.3 Afgrænsning.............................. 4 1.4 Metode................................ 5 1.5 Opbygning af rapporten....................... 7 1.6 Læsevejledning............................ 7 I Teoretisk grundlag 9 2 Udvikling af informationssystemer 11 2.1 Systemudvikling som projekt.................... 12 2.2 Projektlivscyklus........................... 14 2.3 Mislykkede projekter......................... 16 3 Det objektorienterede paradigme 19 3.1 Objektorienterede fremgangsmåder................. 20 3.2 Centrale elementer.......................... 21 3.3 Objektorienteret analyse - OOA................... 23 3.4 Objektorienteret design - OOD................... 27 3.5 Objektorienteret implementering - OOI.............. 30 4 Produktmodellering 33 4.1 Introduktion til produktmodellering................ 34 4.2 Fremgangsmåde for opbygning af produktmodeller........ 38 4.3 Dokumentation af produktmodeller................. 40 5 IT-understøttet dokumentation 47 5.1 CASE-værktøjer........................... 48 5.2 PDM-systemer............................ 59 vii

Indhold II Empiri 67 6 Dokumentationsproces og kravanalyse 69 6.1 Analyse af eksisterende processer.................. 70 6.2 Den fremtidige proces........................ 84 7 Kravspecifikation 93 7.1 Overordnet systembeskrivelse.................... 94 7.2 Projektarbejde og produktmodeller................. 99 7.3 Brugsmønstre............................. 101 7.4 Specifikation af diagrammer..................... 105 7.5 Systemstruktur og diagrammer................... 110 7.6 Overgang fra dokumentation til konfigurator........... 114 7.7 Summering og prioritering af krav................. 119 8 Den videre udvikling 123 8.1 De kommende faser.......................... 124 8.2 Egenudvikling............................. 125 8.3 Tilpasning af eksisterende systemer................. 128 8.4 Projektorganisation.......................... 136 8.5 Afrunding............................... 138 III Afslutning 139 9 Konklusion 141 10 Perspektivering 143 Forkortelser 145 Ordforklaring 151 Litteratur 155 Bilagsrapport 161 Bilag A - Paradigma for projekt 163 Bilag B - IDEF0 for produktmodelleringsprocessen 167 Bilag C - Mødereferater 171 Bilag D - Brugsmønstre 197 Bilag E - Klassediagram 253 Bilag F - Skærmbilleder fra prototype 259 viii

Figurer 1.1 Fremgangsmåde for projektet.................... 5 1.2 Opbygning af rapporten....................... 6 2.1 Besparelse ved anvendelse af struktureret fremgangsmåde.... 13 2.2 Traditionel vandfaldsmodel..................... 14 2.3 Boehms spiralmodel......................... 15 2.4 Objektorienteret livscyklusmodel.................. 15 2.5 Fremgangsmåden ved objektorienteret systemudvikling...... 16 3.1 Eksempel på objekter og klasser.................. 21 3.2 Klassehierarki og beskyttelse ved nedarvning........... 22 3.3 Eksempel på brugsmønsterdiagram................. 24 3.4 Eksempel på klassediagram i UML-notation............ 26 3.5 Eksempel på sekvensdiagram i UML-notation........... 29 3.6 Eksempel på samarbejdsdiagram.................. 29 3.7 Eksempler på diagrammer i OOD.................. 31 3.8 Eksempel på komponentdiagram.................. 31 4.1 Anvendelse af produktmodeller i specifikationssystemet...... 35 4.2 Sammenhæng mellem produktkonfigurator og produktmodel... 36 4.3 Eksempel på konfigurator fra APC................. 36 4.4 Rammemodel for produktmodeller................. 37 4.5 Eksempel på Produkt-Variant Master............... 40 4.6 Eksempel på klassediagram..................... 43 4.7 Eksempel på CRC-kort........................ 45 5.1 OO projektlivscyklus, Upper- og Lower CASE........... 50 5.2 Gantt-kort, vertikale og horisontale CASE............. 51 5.3 Anvendelse af modeller som fælles sprog.............. 54 5.4 Funktionel struktur af PDM-system................ 60 5.5 Funktionalitet i PDM-systemer................... 61 5.6 Intern integration ved anv. af PDM-systemer........... 64 ix

Figurer 6.1 Struktur, procesanalyse og kravspecifikation............ 70 6.2 Eksempel på CRC-kort og træstruktur i Lotus Notes hos Niro.. 72 6.4 Dokumentationsværktøj og projektlivscyklus........... 85 6.5 Fremgangsmåde ved objektorienteret konfigurator......... 87 6.6 Princip ved overførsel af PVM til klassediagram.......... 87 6.7 Fremgangsmåde ved konventionel konfigurator........... 89 6.8 Anvendelse af klassediagram i konventionel konfigurator..... 90 7.1 Begrebsmæssig model for dokumentationsværktøj......... 95 7.2 Adgang til information i produktmodel............... 100 7.3 Brugermønsterdiagram for dokumentationsværktøj........ 101 7.4 Produkt-Variant Master (PVM) med alle elementer........ 106 7.5 Klassediagram med alle elementer................. 107 7.6 CRC-kort med alle felter....................... 108 7.7 Anvendelse af SKU-numre på CRC-kort hos APC......... 110 7.8 Eksempel på brugerdefineret felt i CRC-kort............ 111 7.9 Klassediagram for dokumentationsværktøj............. 111 7.10 Udveksling af data med dokumentationsværktøj.......... 114 7.11 Lagring og udveksling af information i Oracle Configurator... 116 7.12 Lagring og udveksling af information i Baan 98 og ibaan..... 117 7.13 Dataudveksling med dokumentationsværktøj........... 119 7.14 Begrebsmæssig systemmodel med grundmodul.......... 120 8.1 De kommende faser i udviklingen.................. 125 8.2 Forskellige omkostningsmodeller med forskellige grundformler.. 127 8.3 Udvidelse og tilpasning af Rational Rose.............. 130 8.4 Udvidelse og tilpasning af MS Visio................ 131 8.5 Alle elementer i Visio defineres i et ShapeSheet.......... 132 8.6 Eksempel på add-on i Visio..................... 132 C.1 Eksempel på CRC-kort og træstruktur i Lotus Notes hos Niro.. 176 C.2 Skærmbillede fra FLS s konfigurator................ 190 D.1 Brugsmønsterdiagram, topniveau.................. 199 D.2 Brugsmønsterdiagram, klynge: Administration........... 205 D.3 Brugsmønsterdiagram, klynge: PVM................ 213 D.4 Brugsmønsterdiagram, klynge: CRC-kort.............. 223 D.5 Brugsmønsterdiagram, klynge: Klassediagram........... 241 E.1 Klassediagram for dokumentationsværktøj............. 254 x

Figurer F.1 Prototype - Log på.......................... 261 F.2 Prototype - Vælg projekt...................... 262 F.3 Prototype - Indsæt ny klasse.................... 263 F.4 Prototype - CRC-kort for klasse................... 264 F.5 Prototype - Redigér attribut..................... 265 F.6 Prototype - Klassediagram efter PVM............... 266 F.7 Prototype - Nyt klassediagram................... 267 F.8 Prototype - Liste for CRC-kort................... 268 F.9 Prototype - Ny klynge........................ 269 F.10 Prototype - Klassediagram med klynge............... 270 F.11 Prototype - Klassediagram for klynge................ 271 F.12 Prototype - Links i CRC-kort.................... 272 xi

Tabeller 2.1 Typiske symptomer og årsager til mislykkede IT-projekter.... 17 4.1 Fremgangsmådens faser....................... 39 4.2 Anvendelse af UML i klassediagrammer ved produktmodellering 44 6.1 Niros erfaringer med og ønsker til dokumentationsværktøj.... 72 6.3 FLS s erfaringer med og ønsker til dokumentationsværktøj.... 77 7.1 Antagelser i brugsmønstre...................... 104 7.2 Sammenhæng mellem elementer i PVM og klassediagram.... 112 7.3 Sammenhæng mellem elementer i CRC-kort og database..... 113 8.1 Udgifter ved anskaffelse af standardsystemer............ 134 8.2 Udgift for udvikling af prototype i MS Visio............ 135 D.1 Oversigt over brugsmønstre..................... 198 E.1 Encyklopædi for klassediagram................... 255 xiii

Kapitel 1 Introduktion Indhold af dette kapitel 1.1 Formål og baggrund.................. 1 1.2 Problemformulering.................. 3 1.3 Afgrænsning...................... 4 1.4 Metode......................... 5 1.4.1 Empirisk grundlag................... 6 1.4.2 Teoretisk grundlag................... 6 1.5 Opbygning af rapporten............... 7 1.6 Læsevejledning..................... 7 1.1 Formål og baggrund Mange virksomheder har set fordelen i at opbygge IT-baserede konfigureringssystemer (produktkonfiguratorer) til at støtte aktiviteterne i specifikationsprocessen. Specifikationsprocessen dækker over de aktiviteter, der ligger mellem kunden og produktionen, og med et stigende krav fra kunderne om individuelt tilpassede produkter til lave priser bliver arbejdet i specifikationsprocessen hurtigt omfattende. Derfor har virksomheder som f.eks. Dell Computer opbygget produktkonfiguratorer, hvor kunderne selv kan konfigurere deres produkt (f.eks. en komplet computer med skærm og printer), hvorefter produktkonfiguratoren kan sende ordren til produktion eller levering helt eller delvist uden menneskelig indblanding. Besparelserne og fordelene er åbenlyse. Desværre går ikke alle af disse projektet godt. I nogle tilfælde lykkes det aldrig Nogle projekter mislykkes at opbygge et fungerende system, mens man i andre tilfælde nok får opbygget systemet, men må droppe det igen pga. store vanskeligheder med at vedligeholde og opdatere det. I Hvam og Mortensen [2002] er nævnt fire typiske grunde til, 1

Kapitel 1 - Introduktion at projekterne mislykkes, hvoraf to af dem kan relateres direkte til en dårligt opbygget produktmodel: - Produkterne er ikke umiddelbart konfigurérbare, og der er ikke klarhed over, hvilke varianter man ønsker at tilbyde sine kunder. - Den opbyggede produktmodel er ikke struktureret og dokumenteret, hvilket gør det vanskeligt eller helt umuligt at vedligeholde og videreudvikle modellen. Begge problemer kan undgås ved, at der følges en struktureret fremgangsmåde for opbygningen af produktmodellen, og ved at dokumentere produktmodellen sikres, at det er muligt at vedligeholde og udbygge produktkonfiguratoren i fremtiden. Ved Center for Produktmodellering (CPM) på Danmarks Tekniske Universitet (DTU) er udviklet en struktureret fremgangsmåde, som foreskriver gennemløbet af en sekvens af aktiviteter (se afsnit 4.2 på side 38), og som samtidig lægger op til en simpel, men dækkende dokumentation af produktmodellen. Manglende integration Gode erfaringer med CASE-værktøjer Dokumentationsarbejdet i forbindelse med udarbejdelse af en produktmodel er dog ofte præget af en stor mangel på integration. Dette medfører, at det administrative arbejde med dokumentationen hurtigt kommer til at udgøre en for stor andel af den samlede indsats i produktmodelleringsprocessen. Meget af arbejdet bruges på at sikre integriteten af modellen, ligesom der skal bruges ressourcer på konstant at sikre, at indholdet af dokumentationen er opdateret. Der er således et stort ønske om at finde løsning, som letter dokumentationsarbejdet, uden at der gås på kompromis med dokumentationens kvalitet. Inden for udvikling af informationssystemer anvender man i udpræget grad systemmodeller i udviklingsprocessen, og erfaringen har vist, at arbejdet med dokumentationen (diagrammer, leksika etc.) lettes med anvendelse af IT-baserede dokumentationsværktøjer (CASE-værktøjer). Og netop fremgangsmåden for opbygning af produktmodeller, der anvendes ved CPM, er kraftigt inspireret af principperne bag objektorienteret (IT-)systemudvikling, og det vil derfor være oplagt at trække på de samme gode erfaringer mht. at automatisere og støtte dokumentationsarbejdet. Med baggrund i de gode resultater fra anvendelse af CASE-værktøjer i ITverdenen og CPM s erfaringer med produktmodellering er det oplagt, at brugen af et IT-baseret dokumentationsværktøj med al sandsynlighed kan komme de ovenfor nævnte forhindringer til livs og dermed gøre dokumentationsarbejdet nemmere. Ved at samle og integrere dokumentationen i et IT-baseret dokumentationsværktøj gives samtidig mulighed for en nemmere adgang til indholdet i dokumentationen. Det bliver f.eks. muligt at søge efter bestemt information samt generere og udskrive rapporter med den ønskede information. Samlet set vil det i sidste ende betyde, at medarbejderne får mere tid til deres egentlige arbejde at opbygge produktmodellen i stedet for at skulle bruge deres kræfter på rutineprægede administrative opgaver, som håndteres bedre af en computer. 2

1.2 Problemformulering Desværre eksisterer et sådant værktøj ikke. Nogle virksomheder har lavet delvise Værktøj eksisterer ikke løsninger i standardiserede dokumenthåndteringssystemer, men disse løsninger løser ikke alle problemerne. Dokumentationsarbejdet bliver derfor omstændeligt og udgør en flaskehals i produktmodelleringsprocessen. 1.2 Problemformulering Med afsæt i ovenstående introduktion til domænet begynder grundlaget for en problemformulering at tage form. Udgangspunktet er en utilfredshed med den nuværende dokumentationsproces, og det grundlæggende spørgsmål er, hvilke krav der stilles til et IT-baseret dokumentationsværktøj. Forud for dette eksamensprojekt har man ved CPM gjort sig klart, at der eksisterer et svagt punkt i produktmodelleringsprocessen, og man har yderligere fået afdækket, at det svage punkt består i, at det er meget omstændeligt at opbygge og vedligeholde de omfattende mængder af dokumentation, der genereres i løbet af et produktmodelleringsprojekt. Grundlaget er således skabt til at starte på en analyse af de krav, der stilles til et sådant dokumentationsværktøj. Dette munder ud i følgende problemformulering: 1. Hvilke krav stilles til et dokumentationsværktøj til produktmodellering med udgangspunkt i fremgangsmåden fra CPM? 2. Kan kravene imødekommes med en løsning baseret på et standardsystem, og hvordan kan (og skal) dokumentationsværktøjet integreres med virksomhedens øvrige informationssystemer? 3. Hvordan bør projektet vedr. udvikling af dokumentationsværktøjet fortsættes (herunder også overordnede økonomiske betragtninger)? Ad 1: For at kunne afdække kravene til et kommende dokumentationsværktøj Proces og dokumentation er det nødvendigt at opbygge et grundigt kendskab til den nuværende produktmodelleringsproces. I den sammenhæng vil det være hensigtsmæssigt ud over at se på fremgangsmåden fra CPM at undersøge hvordan processen forløber i erhvervslivet. Ved hjælp af principperne bag objektorienteret analyse vil jeg klarlægge kravene til et kommende dokumentationsværktøj. Ad 2: Når kravene er afdækket, vil det være oplagt at vurdere, om de kan Standardsystem imødekommes med et eksisterende standardsystem. Mange ressourcer kan spares ved at undgå at genopfinde hjulet, men samtidig kan det betyde, at man må gå på kompromis med funktionaliteten. Med basis i kravspecifikationen skal samtidig undersøges, hvordan et standardsy- Integration stem kan integreres med virksomhedens øvrige informationssystemer. Hermed tænkes på, hvordan dokumentationsværktøjet kan trække på information fra f.eks. virksomhedens ERP-system, og hvordan en integration mellem dokumentationsværktøjet og konfigureringssystemer kan lade sig gøre. Det sidste vil være ønskeligt for at lette overgangen fra design til implementering og for at lette 3

Kapitel 1 - Introduktion den løbende vedligeholdelse. Begge områder vil blive undersøgt med fokus på muligheden for dataudveksling med dokumentationsværktøjet. Den videre udvikling Ad 3: Dette eksamensprojekt vil udgøre starten på det fulde projekt for udvikling af et dokumentationsværktøj til produktmodellering. Hovedopgaven er at afdække og dokumentere kravene til informationssystemet med anvendelse af teknikkerne bag objektorienteret analyse. For at lægge op til det videre arbejde vil det være givtigt at komme med overvejelser om, hvordan den videre udvikling bør forløbe, og hvordan centrale aspekter af systemet kan implementeres. Hensigten er at lægge op til et samarbejde mellem CPM og private virksomheder, der måtte have interesse i et dokumentationsværktøj. Den sidste gruppe dækker også over f.eks. softwarefirmaer, der som udviklingspartner kunne bidrage til en stabil udvikling og vedligeholdelse af værktøjet. 1.3 Afgrænsning Fokus gennem hele projektet vil være på at få afdækket kravene til et dokumentationsværktøj. Dette betyder, at en del interessante områder kun berøres overfladisk eller helt udelades. Der tages udgangspunkt i Hvam og Mortensens fremgangsmåde for opbygning af produktmodeller. Fremgangsmåden er resultat af mange års forskning og er afprøvet på adskillige projekter i samarbejde med danske og udenlandske virksomheder. Det antages derfor, at denne fremgangsmåde er hensigtsmæssig til formålet. Formålet med dokumentationsværktøjet er at understøtte selve modelleringsprocessen fra opbygning af Produkt-Variant Master (PVM) over implementering til vedligeholdelse og drift. Derfor vil de faser, der ligger uden for dette område, ikke blive behandlet nærmere. Da der er tale om en kravanalyse vil der som udgangspunkt ikke blive taget stilling til implementeringsmæssige detaljer. Af hensyn til den praktiske anvendelse vil der dog i visse tilfælde blive lavet vurderinger og forslag til, hvorledes enkeltstående detaljer kunne løses. Dette skal mere ses som en form for idébank end som en rettesnor for implementeringen, idet det sikrer, at gode idéer opstået i løbet af projektet er blevet indfanget og dokumenteret. Således vil der f.eks. ikke blive lavet en analyse af mulighederne for anvendelse af Standard for the Exchange of Product model data (STEP). 4

1.4 Metode Der vil ikke blive udarbejdet et fungerende IT-system, men blive fokuseret på en fyldestgørende kravanalyse støttet med prototyper af skærmbilleder. Dette arbejde svarer til indholdet af analysefasen i den objektorienterede projektlivscyklus, som er beskrevet i kapitel 3 på side 19 og illustreret i figur 2.5 på side 16. Ydermere er det sigtet blot overfladisk at undersøge mulighederne for en integration af værktøjet med forskellige standardsystemer for at belyse muligheden. Således vil ERP- og CAx-systemer ikke blive behandlet, ligesom simuleringssystemer ikke vil blive inddraget. Anvendelsen af et standardsystem som basis for implementeringen vil blive baseret på CPM s og de tilknyttede virksomheders erfaringer, og der vil således ikke blive foretaget en tilbundsgående analyse af de enkelte standardsystemers muligheder og begrænsninger. 1.4 Metode En stor opgave vil bestå i at opbygge et kendskab til produktmodellering. Kendskabet og forståelsen skal være på et niveau, der giver indblik i de grundlæggende principper for produktmodellering. Herudover vil det være nødvendigt med en indsigt i de involverede processer og behovet for dokumentation for at kunne lave en analyse af kravene til et kommende dokumentationsværktøj. Indsigten i produktmodellering vil både være baseret på litteraturstudier og praktiske erfaringer fra de tilknyttede virksomheder. Ved opbygningen af kravspecifikationen vil der blive taget udgangspunkt i strukturen og funktionaliteten fra eksisterende informationssystemer til håndtering af dokumentation og produktdata. Disse systemer har udviklet sig igennem mange år, og der eksisterer et stort antal vurderinger af deres anvendelse i praksis. Fremgangsmåden for projektet er illustreret i figur 1.1. -./ 0 0 /213 4 5 /6 0 7./"8:9 43./ 0 0 /:13 4 5 /6 0 # "!# $ % & ' (", $ $ $ )" $ ** ( + Figur 1.1: Fremgangsmåde for projektet 5

E O Kapitel 1 - Introduktion 1.4.1 Empirisk grundlag Den empiriske del vil tage udgangspunkt i interview og løbende samtaler med nøglepersoner i virksomhederne APC Denmark A/S, F.L. Smidth A/S, GEA Niro A/S og Vitral A/S. Herudover vil der blive trukket på CPM s erfaringer fra tidligere projekter, og der vil i projektet blive trukket på erfaringer fra tre ph.d.-projekter, der er under udførelse ved CPM: - Fremgangsmåde for opbygning af produktmodeller af Jesper Riis i samarbejde med demex electric A/S (med flere) Udvikling af fremgangsmåde for opbygningen af produktkonfiguratorer, herunder overvejelser om hvorledes produktmodeller vedligeholdes løbende og videreudvikles. - Udvikling af specifikationssystemer af Benjamin Loer Hansen i samarbejde med APC Denmark A/S Udvikling af fremgangsmåder for udvikling af specifikationssystemer samt opstilling af strukturelle beskrivelseskarakteristika for produktmodeller. - Application of Product Models in Extended Enterprises af Martin Malis i samarbejde med GEA Niro A/S Vurdering af strategiske aspekter i forbindelse med udvikling af produktmodeller samt undersøgelse af mulighederne for integration af konfiguratorer med interne systemer. 1.4.2 Teoretisk grundlag Det teoretiske grundlag for projektet vil kunne deles i fire hovedområder: - Udvikling af informationssystemer - Det objektorienterede paradigme - Produktmodellering - IT-understøttet dokumentation hvoraf de to første og det sidste er rigt beskrevet i talrige artikler og lærebøger. Derimod er produktmodellering et forholdsvist nyt område, og jeg vil primært støtte mig op ad CPM s arbejde inden for området. ; < =>? =?< =? @ A B < C D? F G? D C B H I G J < => @ I KLNMCG CB H? G? B J > D @ D? G A B > J D < C < I Figur 1.2: Opbygning af rapporten 6

1.5 Opbygning af rapporten 1.5 Opbygning af rapporten Rapporten består af en hovedrapport og en bilagsrapport. Hovedrapporten er opdelt i to overordnede dele: En teoretisk og en empirisk del. I den teoretiske del gennemgås projektets teoretiske grundlag inden for udvikling Teoretisk del af informationssystemer (kapitel 2), det objektorienterede paradigme (kapitel 3), produktmodellering (kapitel 4) og IT-understøttet dokumentation (kapitel 5). I den efterfølgende empiriske del analyseres og løses problemstillingerne med ud- Empirisk del gangspunkt i den gennemgåede teori. I kapitel 6 startes med en analyse af den eksisterende dokumentationsproces. På baggrund af denne opbygges en kravspecifikation i kapitel 7, og i kapitel 8 diskuteres, hvordan den videre udvikling kan forløbe, samt hvilke muligheder der eksisterer for implementering. Rapporten afsluttes med en konklusion i kapitel 9 og en perspektivering i kapitel 10. Ud over den overordnede indholdsfortegnelse forrest i rapporten er der for hvert Ordforklaring kapitel en mere detaljeret indholdsfortegnelse, og bagerst i rapporten er placeret en liste med forklaring af anvendte forkortelser og en ordforklaring for centrale begreber med henvisning til det sted i rapporten, hvor begrebet behandles. 1.6 Læsevejledning Rapporten er opbygget, så den mest hensigtsmæssige måde at læse den på er ved at læse den fra ende til anden, suppleret med opslag i bilagsrapporten. Afhængigt af læserens baggrundsviden kan den teoretiske del (eller dele heraf) udelades. For alle læsere vil det være mest hensigtsmæssigt at starte med at læse introduktionen. Den primære målgruppe er vejledere og censor og sekundært medarbejdere hos de involverede virksomheder. Da projektet lægger op til det videre arbejde med dokumentationsværktøjet, er rapporten også møntet på studerende og udviklere, der skal arbejde videre med projektet. Sidstnævnte gruppe bør som minimum læse kapitel 4 som en indføring til produktmodelleringsdomænet og evt. supplere med relevante kilder fra litteraturlisten. Herudover vil referaterne i bilag C være en god kilde til erfaringerne fra de involverede virksomheder. Læsere, der kun har erfaring med produktmodellering, bør før læsningen af den empiriske del som minimum læse kapitel 2 om udvikling af informationssystemer og evt. kapitel 3 om det objektorienterede paradigme. 7

Del I Teoretisk grundlag

Kapitel 2 Udvikling af informationssystemer Indhold af dette kapitel 2.1 Systemudvikling som projekt............ 12 2.2 Projektlivscyklus.................... 14 2.2.1 Vandfaldsmodellen................... 14 2.2.2 Spiralmodellen..................... 14 2.2.3 Den objektorienterede projektlivscyklus....... 15 2.3 Mislykkede projekter................. 16 I dette kapitel gives en indføring i, hvordan informationssystemer udvikles. Fokus vil være på anvendelsen af en struktureret fremgangsmåde, hvor udviklingen deles op i et antal faser, der tilsammen udgør hele projektlivscyklussen. Herudover beskrives nogle af årsagerne til, at IT-projekter ofte ikke ender succesfuldt. 11

Kapitel 2 - Udvikling af informationssystemer 2.1 Systemudvikling som projekt Fremgangsmåden for opbygning af informationssystemer har udviklet sig parallelt med den generelle udvikling inden for informationsteknologi. Siden 1950 erne har udviklingen inden for informationsteknologi gennemgået fire æraer, som strækker sig fra den spæde start uden standarder over anvendelsen af databaser og sammenkobling af computere i netværk til avancerede informationssystemer som Enterprise Resource Planning (ERP)- og Product Data Management (PDM)-systemer [Riis, 2002]. Kompleksiteten af et informationssystem fremgår af følgende definition: An information system (IS) is an arrangement of people, data, processes and interfaces that interact to support and improve day-to-day operations in a business as well as support the problem-solving and decision-making needs of management and users. [Whitten et al., 2001, s. 45] Det er blevet påvist, at der kan spares både tid og penge, samtidig med at produktivitet og kvalitet øges, efterhånden som en virksomheds 1 udviklingsprocesser modnes [Whitten et al., 2001]. Dvs. des bedre udviklingsprocessen håndteres som et projekt, og der følges en velstruktureret fremgangsmåde, des bedre bliver det endelige resultat både kvalitets- og omkostningsmæssigt. Capability Maturity Model (CMM) Denne sammenhæng har The Software Engineering Institute på Carnegie Mellon University beskrevet i the Capability Maturity Model (CMM) [Whitten et al., 2001]. Modellen bruges til at måle modenhedsniveauet (maturity level) for en virksomheds evner inden for udvikling af informationssystemer og evne til at styre udviklingsprocessen. Modellen har fem niveauer, hvor hvert niveau er forudsætning for det næste: 1. Initial Der følges ingen beskrevet fremgangsmåde, og indsatsen er ikke koordineret. Processen er uforudsigelig, og dokumentationen sporadisk. 2. Repeatable Man er blevet opmærksom på projektledelse, som nu har fokus frem for systemudvikling. Fremgangsmåder anvendes, men varierer fra projekt til projekt. Man forsøger at gentage tidligere successer. 3. Defined Der anvendes en standardiseret fremgangsmåde (en metodologi), som er integreret i hele virksomheden. Alle projekter anvender en tilpasset version af denne metodologi. Som resultat er projektets dokumentation og resultater konsistente og forudsigelige. 4. Managed Målbare mål for kvalitet og produktivitet er defineret. Ledelsen forsøger at agere frem for at reagere i forbindelse med problemer (omkostninger, tid, omfang), og selv når problemerne opstår, kan fremgangsmåden ændres baseret på forudsigelige virkninger. 1 I dette afsnit bruges betegnelsen virksomhed om den virksomhed eller organisation, der udvikler informationssystemer, medmindre andet er direkte angivet. 12

2.1 Systemudvikling som projekt 5. Optimized Fremgangsmåden overvåges og forbedres løbende baseret på analysen og målene fra niveau 4. Erfaringer deles effektivt på tværs af organisationen med henblik på at eliminere ineffektivitet i fremgangsmåden og fastholde kvaliteten. Næsten alle virksomheder starter på niveau 1 og arbejder sig derfra op. Flere organisationer, der har skullet købe et nyt informationssystem, har taget konsekvensen og vurderer nu mulige leverandører på deres niveau i CMM. Heriblandt den amerikanske regering, der fra og med 2002 bruger CMM som en del af deres kvalifikation af leverandører til alle statslige projekter. P.t. arbejder mange virksomheder hårdt for blot at opnå niveau 3, og der er mange ressourcer at spare på at blive bedre. I Whitten et al. [2001, s. 78] gengives en statistik for et udviklingsprojekt på 200.000 kodelinjer. Den viser, at hvor en virksomhed på CMM-niveau 1 bruger 600 mandemåneder og har en gennemsnitlig omkostning på USD 5,5 mio., bruger en virksomhed på CMM-niveau 3 kun 15 mandemåneder og har en gennemsnitlig omkostning på USD 728.000. CMM nævner anvendelsen af en metodologi som en af af de centrale forudsæt- Anvendelse af metodologi ninger for et godt resultat. En metodologi er i Whitten et al. [2001] defineret som... a very formal and precise system development process that defines (as in CMM Level 3) a set of activities, methods, best practices, deliverables, and automated tools for system developers and project managers to use to develop and maintain most or all information systems and software. [Whitten et al., 2001] Anvendelsen af en metodologi kræver umiddelbart en større indsats for virksomheden, men i det lange løb opnås store fordele både med hensyn til omkostninger og kvalitet. Denne sammenhæng understreges også i Vesterager [1989], som det fremgår af figur 2.1. Ressourceindsats Traditionel fremgangsmåde Struktureret fremgangsmåde Analyse Design Konstruktion Impl. og vedl. Tid Figur 2.1: Besparelse ved anvendelse af struktureret fremgangsmåde (metodologi) [Vesterager, 1989] 13

Kapitel 2 - Udvikling af informationssystemer 2.2 Projektlivscyklus På samme måde som et produkt udvikles, produceres, bruges og bortskaffes, har et projekt et forløb af faser, som det gennemgår. Inden for udvikling af informationssystemer taler man om en Systems Development Life Cycle (SDLC), og der er gennem tiden blevet udviklet mange forskellige modeller. Nogle af de klassiske er vandfaldsmodellen og den senere spiralmodel, som jeg vil beskrive i det følgende. 2.2.1 Vandfaldsmodellen Vandfaldsmodellen illustrerer den traditionelle fremgangsmåde for udvikling af informationssystemer. Som det fremgår af figur 2.2(a), opdeler modellen projektet i en række faser, hvor en fase er afhængig af, at den foregående er afsluttet. Bennett et al. [1999] nævner, at modellens navn afspejler, at det er svært at gå tilbage til en tidligere fase, når den er afsluttet på samme måde som det er svært at svømme mod strømmen i et vandfald. Iteration Selv om modellen har været brugt i mange år, har den en del ulemper, hvoraf den væsentligste netop går på manglen af iteration. Det er de færreste projekter, der kan følge en så simpel sekventiel livscyklus. I figur 2.2(b) er vist, hvordan man kan gå tilbage til tidligere faser, men disse iterationer kan hurtigt blive meget dyre [Bennett et al., 1999]. P Q R S T U V W X Y W T T Z Y W X h i j k l m n o p q o l l r q o p [ T \ ] Y Z T U T W S R ^ W _ ` Q R Y R s l t u q r l ml o k j v o w x i j q j a T R Y X W y l j q p o b T R S Y W X z l j k q o p c d W R S Z ] e S Y d W { o j k r u } k q o f W R S _ ` ` _ S Y d W ~ o j k w x x w k q o g"_ Y W S T W _ W e T "w q o k l o w o } l (a) Uden iterationer (b) Med iterationer Figur 2.2: Traditionel vandfaldsmodel for projektlivscyklus [Bennett et al., 1999, s. 46] 2.2.2 Spiralmodellen I modsætning til vandfaldsmodellen lægger spiralmodellen op til en mere integreret anvendelse af iteration. Spiralmodellen (figur 2.3 på følgende side) blev lanceret i 1988 af Boehm som et resultat af forskellige tilpasninger af vandfaldsmodellen på store statslige IT-projekter [Schwalbe, 2000]. Spiralmodellen lægger op til, at man løbende lancerer fungerende versioner af informationssystemet (eller dele heraf), hvor hver ny version har øget funktionalitet. Anvendelsen af prototyper tilskyndes af spiralmodellen, og på den måde kan man tidligt i processen få tydeliggjort seriøse misforståelser. 14

2.2 Projektlivscyklus Determine Objectives, Progress Alternatives, Through and Constraints Steps Cumulative Cost Evaluate alternatives, Identify, resolve risks Risk Analysis Risk Analysis Review Commitment Partition Plan Next Phases Requirements Plan Life Cycle Plan Development Plan Integration and Test Plan Risk Analysis Concept of operation Risk Analysis Requirements Validation Design Validation and Verification Implementation Prototype 1 Software Requirements Acceptance Test Prototype 2 Software Product Design Integration and Test Prototype 3 Unit Test Operational Prototype Simulations, Models, Benchmarks Detailed Design Code Develop, verify Next-Level Producty Figur 2.3: Boehms spiralmodel for projektlivscyklus [Schwalbe, 2000] 2.2.3 Den objektorienterede projektlivscyklus Med udviklingen af tankegangen bag det objektorienterede paradigme blev det nødvendigt at redefinere, hvordan udviklingsprojekter forløber. Object Management Group (OMG) har foreslået en livscyklusmodel for objektorienteret systemudvikling, som er illustreret i figur 2.4. I OMG s model fokuseres på, hvad der skal udføres, og ikke rækkefølgen hvori det skal udføres. Tværtimod lægges Parallelle op til, at flere af opgaverne kan udføres samtidig [Bennett et al., 1999]. Derfor aktiviteter kan modellen umiddelbart godt virke lidt utilgængelig og svær at omsætte til praksis, og det kræver derfor en nærmere detaljering af de enkelte faser. Life cycle Strategic Modelling Analysis Modelling Object Modelling Design Modelling Implementation Modelling Construction Full definition of the system Delivery Co-ordination and reuse Figur 2.4: Objektorienteret livscyklusmodel [Bennett et al., 1999, s. 52] I Bahrami [1999] gives et mere konkret bud på indholdet af faserne Analysis Konkretisering af OO-SDLC Modelling, Design Modelling, Implementation Modelling og Construction, og der lægges dermed op til, hvordan man griber et udviklingsprojekt an efter den objektorienterede tankegang. I figur 2.5 på følgende side er vist de tre overordnede aktiviteter, som udgør den objektorienterede SDLC. 15

Kapitel 2 - Udvikling af informationssystemer ˆ Š Œ Ž Œ š œ Š Š Œ Š ž ƒ " Ž Š " š ª Œ ž «««" Š Ÿ ƒ Ž «Š Š Š Š œ" š Ÿ ƒ ƒ ³ Š " Œ Š «Š Œ" µ Œ ˆ Š Œ Œ"Œ œ Š " Œ Ž «Š Š Š Š œ" Œ š ± ² ˆ Š Œ «Š «Œ «œ Figur 2.5: Fremgangsmåden ved objektorienteret systemudvikling (OO-SDLC) [Bahrami, 1999, s. 44] Analysis og Design svarer til henholdsvis Analysis Modelling og Design Modelling i OMG s livscyklusmodel, og Implementation svarer til summen af Implementation Modelling og Construction. Forudsætningen for Bahramis model er, at der forud for den første analysefase er lavet en forretningsmæssig analyse af behovet og omfanget af informationssystemet (svarende til fasen Strategic Modelling i figur 2.4 på foregående side). Bahrami fokuserer således på de rent udviklingsmæssige aktiviteter, som indgår i et projekt. Fokus på analyse I relation til dette eksamensprojekt passer fokuseringen godt, og som nævnt i indledningen vil jeg fokusere på den objektorienterede analyse (afsnit 3.3 på side 23), men for at give indsigt i sammenhængen vil jeg også kort beskrive de to overordnede faser, som følger analysefasen design og implementering (afsnit 3.4 på side 27). Forinden vil jeg dog give en kort introduktion til det objektorienterede domæne i kapitel 3 på side 19, da tankegangen er væsentligt forskellig fra den traditionelle strukturerede tilgangsvinkel, hvor data og procedurer (der udfører operationer på data) er opdelt. 2.3 Mislykkede projekter Der eksisterer mange skrækhistorier om IT-projekter, der er gået galt, og man kan hurtigt få det indtryk, at man skal have is i maven som leder, før man tør sætte et IT-projekt i gang. Og det er ikke et helt forkert indtryk! En forkert antagelse er dog ifølge The Standish Group 2, at mislykkede projekter skyldes 2 The Standish Group (www.standishgroup.com) er et velanset amerikansk forskning- og analysefirma, der beskæftiger sig med problemstillinger inden for informationsteknologi. 16

2.3 Mislykkede projekter Typiske symptomer -Misforståelse af brugernes krav og behov -Manglende evne til at håndtere ændring af krav -Moduler, der ikke passer sammen -Software, der er svært at vedligeholde og udvide -For sen opdagelse af seriøse fejl i projektet -Lav kvalitet af software -Uacceptabel ydelse fra software -Umuligt at rekonstruere, hvem der ændrede hvad, hvornår og hvorfor -En utroværdig udviklingsproces Grundlæggende årsager -Ad hoc-administration af brugernes krav -Uklar og upræcis kommunikation -Skrøbelige arkitekturer -Overvældende kompleksitet -Uopdaget inkonsistens imellem krav, design og implementering -Utilstrækkelig testning -Subjektiv vurdering af projektets status -Risici bliver ikke håndteret -Ukontrolleret udbredelse af ændringer -Utilstrækkelig grad af automatisering Tabel 2.1: Typiske symptomer og årsager til mislykkede IT-projekter [Kruchten, 1998, s. 4] mangel på penge og teknologi. Tværtimod anfører de mangel på forståelse for og anvendelse af selv helt basal projektledelse som en af de centrale årsager. En af deres undersøgelser fra 1995 er refereret i Schwalbe [2000]. Undersøgelsen viste, at man i de tidlige 1990 ere havde brugt mere end USD 250 mia. på omkring 175.000 IT-projekter. Et middelstort projekt kostede omkring USD 1,3 mio., og den totale succesrate var på kun 16,2%! Succesfulde projekter blev i den forbindelse defineret som projekter, der opfyldte projektmålene til tiden og inden for det afsatte budget. Herudover fandt de ud af, at 31% af IT-projekterne blev aflyst, før de var færdige, hvilket svarer til et tab på USD 81 mia. En opfølgende undersøgelse i 1998 viste, at branchen havde forbedret sig. Succesraten var nu oppe på 26%, mens 28% ikke opfyldte kravene inden for de økonomiske og tidsmæssige rammer. De resterende 46% blev gennemført, men kostede mere og tog længere tid end planlagt. Kruchten opstiller en liste over typiske symptomer for og mulige årsager til, Symptomer og årsager til fiaskoer at IT-projekter bliver en fiasko. Han understreger også, at det naturligvis ikke hjælper at bekæmpe symptomerne, men at man derimod skal sørge for at få tydeliggjort symptomerne for at kunne identificere årsagerne og behandle disse. I tabel 2.1 er symptomerne og årsagerne gengivet. Der er ikke direkte sammenhæng mellem symptomer og årsager, men projekterne mislykkes typisk som følge af en kombination af årsagerne. Mange af symptomerne og årsagerne har rod i projektets start, og i relation Årsager kan elimineres til dette eksamensprojekt kan flere af årsagerne elimineres ved at fokusere på en tilbundsgående analyse og et iterativt udviklingsforløb. På den måde skubbes risici for f.eks. opdagelse af fejl ikke længere frem i tiden, og man undgår overraskelsen over, at man har udviklet et informationssystem, der er dyrere 17

Kapitel 2 - Udvikling af informationssystemer end forventet, tog længere tid end antaget og kun indeholder en brøkdel af den ønskede funktionalitet. Anvendelsen af en velafprøvet metodologi er et godt middel til at undgå faldgruberne, og i afsnit 3.3 og 3.4 vil de to første faser af den objektorienterede fremgangsmåde blive beskrevet. 18

Kapitel 3 Det objektorienterede paradigme Indhold af dette kapitel 3.1 Objektorienterede fremgangsmåder........ 20 3.2 Centrale elementer.................. 21 3.3 Objektorienteret analyse - OOA.......... 23 3.3.1 Brugsmønsterdiagrammer............... 24 3.3.2 Klassediagrammer................... 25 3.4 Objektorienteret design - OOD........... 27 3.4.1 Modellering i designfasen............... 28 3.4.1.1 Interaktionsdiagrammer........... 28 3.4.1.2 Andre diagrammer.............. 30 3.5 Objektorienteret implementering - OOI...... 30 Den objektorienterede tankegang spiller en dobbelt rolle i dette projekt. For det første spiller den en central rolle inden for produktmodellering, og for det andet anvendes objektorienteret analyse til at fastlægge kravene for dokumentationsværktøjet. I dette kapitel gives en kort introduktion til den grundlæggende tankegang i det objektorienterede paradigme, og de centrale elementer beskrives. Herudover beskrives objektorienteret analyse, mens objektorienteret design og objektorienteret implementering kort gennemgås. 19

Kapitel 3 - Det objektorienterede paradigme 3.1 Objektorienterede fremgangsmåder UML Objektorienterede fremgangsmåder er relativt unge, men har vundet stor udbredelse. I slutningen af 1980 erne og starten af 1990 erne blev der anvendt et utal af forskellige objektorienterede metoder, og det gav anledning til problemer for systemudviklerne, som skulle lære mange forskellige metoder at kende [Whitten et al., 2001]. Situationen blev bedre, da the three amigos, Grady Booch, James Rumbaugh og Ivar Jacobson, samlede kræfterne med det formål at skabe én standardiseret proces for udvikling af objektorienterede informationssystemer. De samlede det bedste fra deres egne og andres metoder, og resultatet blev lanceringen af Unified Modelling Language (UML) ver. 1.0 i 1997 [Whitten et al., 2001]. UML er ikke en metodologi, men en standardiseret notationsform for objektmodellering. OMG adopterede hurtigt UML og har siden vedligeholdt specifikationen, og UML er i dag de facto standard for objektmodellering. Eksempler på procedurale sprog: - Pascal - Fortran - COBOL Inden for traditionel systemudvikling har målet været at implementere systemerne vha. procedurale programmeringssprog. Det er sprog, hvor et program består af en mængde data (variable) og et antal handlinger (procedurer), som udfører operationer på programmets data. Før systemet kan implementeres, skal man derfor have omsat kravene fra domænet, hvor informationssystemet skal bruges til procedurer og variable. En af de største ulemper ved denne type sprog er, at vedligeholdelsen bliver meget omstændelig, idet det er svært at overskue konsekvenserne af at ændre en procedure. Objekter I objektorienteret modellering anskues verden som bestående af objekter, som har nogle egenskaber og kan udføre nogle operationer. Et objekt er umiddelbart en abstrakt størrelse, men følgende definitioner giver en idé om meningen: An object is something that is or is capable of being seen, touched, or otherwise sensed, and about which users store data and associate behavior. [Whitten et al., 2001, s. 647] Objekt: En helhed med identitet, tilstand og adfærd. [Mathiassen et al., 1993, s. 60] The term object means a combination of data and logic that represents some realworld entity. [Bahrami, 1999, s. 15] Et eksempel på et objekt kunne således være en bil: Den har nogle data (f.eks. model, farve og vægt) og en adfærd/logik (den kan køre, dreje og dytte). På den måde skal et objekt opfattes som dels en abstraktion af et virkeligt objekt i et domæne, dels som element i et stykke software med en identitet, tilstand og adfærd. 20

3.2 Centrale elementer I objekter er al information om det virkelige objekt (bilen) indkapslet i det Indkapsling abstrakte objekt i informationssystemet. Objektets funktion udadtil er på den måde uafhængigt af objektets interne datastruktur og funktionalitet. For objektet defineres en ekstern funktionalitet (en grænseflade), som bruges i samspillet med andre objekter. Så længe denne grænseflade bibeholdes, vil objekter af andre klasser ikke være påvirket af, at der laves ændringer i klassen. Det bliver således nemmere at overskue konsekvenserne af de ændringer, man ønsker at lave. Dette kan sammenlignes med en bil: Så længe forhjulene drejes, når føreren drejer på rattet, så er det ligegyldigt, om der anvendes hydraulik, snekkedrev eller tandstangsstyring til at overføre kræfterne. Dette koncept betegnes ofte indkapsling og er helt centralt i den objektorienterede tankegang. 3.2 Centrale elementer I den objektorienterede modellering anvendes en række centrale elementer til at beskrive domænet og de krav, der stilles til informationssystemet. Klasse Klasser bruges til at adskille forskellige typer af objekter fra hinanden. En klasse defineres i Bahrami [1999, s. 16] som a set of objects that share a common structure and a common behavior, og et objekt er da blot en enkelt instans af klassen. Dette er illustreret i figur 3.1, hvor det fremgår, at en Ford Falcon, en Toyota Corolla og en Audi TT alle er instanser af den samme klasse, Bil. Klassen kan på den måde betragtes som en slags skabelon for objekterne ved at specificere deres egenskaber (attributter), adfærd (metoder) og mulighed for generalisering (nedarvning). Disse begreber beskrives nedenfor. ¹»º ¼ ½"¾ À Á ÂÄÃ Â Å Æ Ç ½ ÈÉÄÀ Ê ÂÄÃ Ë Å Ì ½ ÈÍ Î Â Ï Ã Ë Å Ì ½ ÈÍ Ì Í À"Ã Ì ÈÍ Ì Í À ½ РÀ Â Ñ Å Ò Ë Ó Ì Å Ô Â Õ Ö Ã Á Í Ë Î Ø Ë Ó Ù À Ú Ï Î Â Õ ÖÃ Ó Ì À Ë Å Ñ Û ÒÀ Â Ü Õ Ë Å Ì Ö Ã Á Í Ë Î Bil Figur 3.1: De tre biler er alle instanser (objekter) af klassen Bil Attribut En klasses egenskaber specificeres ved at tildele klassen attributter. Attributterne er fælles for alle instanser af klassen, men de kan antage forskellig værdi. For klassen Bil kunne attributterne være Farve, Mærke og Model. Værdierne for en af instanserne ville da være henholdsvis Sølv, Audi og TT. I informationssystemet kan attributterne implementeres på flere måder med anvendelse af forskellige typer af variable (f.eks. heltal, decimaltal, tekststrenge eller lister) eller ved at have en attribut, der er et objekt i sig selv. F.eks. kunne en instans af klassen Biler have en attribut Motor, som i sig selv er en instans af klassen Forbrændingsmotor. Ý»Þ ß ù ú û ü ý þäÿ þ ù Äü þ ÿ ù þ ÿ ù ü"ÿ ü à á â ã â ä å æç è é ê å ë â ì íî ï ð ç ñ ò ó ç è ôã õ ö ê ñ â ì í"î è é ã ç å ä æã â ø ì ç å é íî ï ð ç ñ 21

Kapitel 3 - Det objektorienterede paradigme! " # $! "! "! "! " % &(' ) ' * +,.- / 0 1 + 2 ' 3 4 5 6 7-8 9: > -/ ;() < = 1 8 ' 3 45 / 0 ) - + *,() '? 3 - + 0 4.5 6 7-8 Metode Mens attributterne beskriver, hvad objektet ved om sig selv, beskriver metoderne, hvad objektet kan. For eksemplet med en bil kunne metoderne være Brems, Accelerér og Drej. Metoderne skal definere alle de operationer, som et objekt skal kunne udføre, så objektet på den måde er ansvarlig for sin egen adfærd [Bahrami, 1999]. Herudover er det god skik at bruge metoder til at give andre objekter adgang til indholdet af attributterne. På den måde kan man nemmere opretholde en ensartet grænseflade til omgivelserne, og omfanget af fremtidigt vedligeholdelsesarbejde kan reduceres. Generalisering Generalisering (eller nedarvning) beskriver den egenskab, at objekter kan opbygges af andre objekter, og det er dermed muligt at genbruge fællestræk mellem ensartede klasser. I eksemplet med klassen Bil svarer det til, at denne klasse nedarver fra en overliggende klasse kaldet Køretøj. Klassen Ford kan derefter nedarve fra klassen Bil, og klassen Falcon kan igen nedarve fra Ford. Hvis klassen Bil har defineret en metode til at dreje bilen, nedarves denne metode til alle underliggende klasser, som derefter vil vide, hvordan de skal dreje. På samme måde kan ens attributter nedarves, f.eks. har klassen Bil en attribut Farve, som nedarves til alle biler. Princippet er illustreret i figur 3.2(a). Køretøj Køretøj Bil Lastbil! Sådan her: Drej() Bil + VisNrPlade() # Drej(int) Lastbil Ingen anelse... Lav din egen metode!? Ford Audi Hvordan drejer? man Ford Falcon Volvo FH12 Hvordan drejer man? Falcon Taunus Mondeo VisNrPlade() "AB 12 345" (a) Hierarki ved nedarvning (b) Beskyttelse af metoder og attributter Figur 3.2: Nedarvning og beskyttelse af metoder og attributter. Inspireret af Bahrami [1999, s. 22] 22

3.3 Objektorienteret analyse - OOA Relation Det er muligt for objekter at kommunikere med hinanden, hvis der er oprettet en relation mellem de tilsvarende klasser. Relationerne betyder populært sagt, at objekterne kender til hinandens eksistens og har mulighed for at tale sammen. Kommunikationen hænger tæt sammen med princippet om indkapsling, idet attributter som nævnt bør tilgås via metoder i stedet for direkte. Hvis et objekt ønsker information om en Ford Falcons nummerplade, sker dette ved at eksekvere Falcon-objektets metode VisNrPlade() frem for at læse attributten direkte (se figur 3.2(b) på foregående side). For at kunne styre adgangen til metoder og attributter er det muligt at give Symboler: disse en status som private, protected eller public. Private betyder, at en metode private eller attribut kun kan tilgås af objektet selv. Protected betyder, at metoden # protected eller attributten også kan tilgås fra objekter af klasser, der nedarver fra klassen. + public Public betyder, at alle objekter kan tilgå metoden eller attributten. Der eksisterer flere forskellige typer af relationer, og disse er beskrevet i afsnit 3.3 under gennemgangen af UML som dokumentation. 3.3 Objektorienteret analyse - OOA Analysefasen drejer sig om determining the system requirements and identifying classes and their relationship to other classes in the problem domain [Bahrami, 1999, s. 45], og hovedformålet er to capture a complete, unambiguous, and consistent picture of the requirements [Bahrami, 1999, s. 125]. Den første udfordring består således i at kunne forstå problemet og dets domæne. I analysefasen opbygges brugsmønsterdiagrammer og klassediagrammer, og fordelen i det objektorienterede domæne er, at de samme modeller/diagrammer kan bruges i analysefasen såvel som design- og implementeringsfaserne [Bahrami, 1999, s. 126]. I dette projekt anvendes UML som notationsform, og alle modellerne, der beskrives i det følgende, er derfor tegnet i henhold til denne standard. 23

Kapitel 3 - Det objektorienterede paradigme 3.3.1 Brugsmønsterdiagrammer Objektorienteret analyse (OOA) kaldes ofte usecase driven, dvs. drevet frem af brugsmønstre (usecases). Dette bunder i, at opbygningen af brugsmønstre er det første, der sker i fasen, og brugsmønstrene bruges centralt i dokumentationen for kravene til systemet. Der findes mange bud på definitionen af et brugsmønster, men et rimeligt dækkende findes hos Whitten et al., som definerer brugsmønster som Brugsmønster... a behaviorally related sequence of steps (a scenario), both automated and manual, for the purpose of completing a single business task. [Whitten et al., 2001, s. 656] Herudover består et brugsmønsterdiagram af aktører, der defineres som... anything that needs to interact with the system to exchange information. An actor is a user, a role, which could be an external system as well as a person. [Whitten et al., 2001, s. 656] Aktør Herudover består brugsmønsterdiagrammer af forbindelser, som forbinder aktører med brugsmønstre såvel som brugsmønstre med hinanden, og systemgrænser, der angiver omfanget af de aktuelle systemer. Et eksempel på et brugsmønsterdiagram er vist i figur 3.3. {b.z n xt}~tp vz x K L MN O P Q R f Q i Z Q M U V h K L M\ R aa M U Q Z N cn W cy Z Q X @BA CED A FHG IHJ f g V Q V h f g V Q V h STM U Q R V O PWL M Q R X Y R Z r(stp ttu vw(xty z x j.c N WcY Z Q X a R l`m n oqp K L M Q R [\ WQ ] ^ R N O P Q R p ƒ~(z}eoqvz n xtp K _`Vba ] c V Q R do NM e QbN O P Q R k M U X O N Q R Figur 3.3: Eksempel på brugsmønsterdiagram [Bahrami, 1999, s. 132] I forbindelse med aktører er det vigtigt at bemærke, at de repræsenterer roller frem for virkelige personer. I eksemplet med et bibliotek kan det f.eks. sagtens være den samme fysiske person, der har rollen som bibliotekar og udlåner bøger, men samtidig også varetager indkøbet af nye bøger. Men rent funktionsmæssigt 24

3.3 Objektorienteret analyse - OOA er der tale om to forskellige roller, og på et større bibliotek vil det måske også være to forskellige personer [Bahrami, 1999]. På figur 3.3 på foregående side er vist to andre forbindelser: «uses» og «extends». Den første bruges, når to brugsmønstre har en del til fælles, som med fordel kan udskilles af disse brugsmønstre og få sit eget. Lån bøger og Aflevér bøger vil begge kræve, at lånerkortet undersøges. Derfor er denne sekvens udskilt til brugsmønstret Undersøg lånerkort frem for at gentage sekvensen i begge brugsmønstre. Ud over at lette overskueligheden betyder det også, at hvis der skal ændres i måden, hvorpå et lånerkort undersøges, skal det kun gøres ét sted [Bahrami, 1999]. «extends»-forbindelsen bruges, når et brugsmønster er identisk med et andet, men gør lidt mere eller på en mere specialiseret måde. I eksemplet er Lån bøger det grundlæggende brugsmønster, og at låne en bog fra et andet bibliotek foregår på næsten samme måde der sker bare en anelse mere. Denne anelse mere beskrives så i det udvidede brugsmønster ( Lån fra andet bibliotek ). En anden måde at bruge denne forbindelse på er til beskrivelse af de situationer, som afviger fra det normale brugsmønster. I stedet for at beskrive variationerne direkte i brugsmønstret kan man lave en eller flere udvidelser, der beskriver situationen og samtidig indikerer, at scenariet kan foregå på lidt forskellige måder [Bahrami, 1999]. Hvert brugsmønster beskrives i separate dokumenter med angivelse af bl.a. forudsætninger, resultat og en beskrivelse af scenariet og angivelse af undtagelser. For at lette overskueligheden kan brugsmønsterdiagrammer inddeles i klynger, der hver især indeholder et mindre antal brugsmønstre [Bahrami, 1999]. Anvendelsen af brugsmønsterdiagrammer er en god måde at inddrage de kommende brugere af systemet tidligt i udviklingsprocessen. På en letforståelig måde illustrerer et brugsmønsterdiagram, hvordan brugen af systemet kommer til at foregå, og det kræver ikke den store indsigt og erfaring at forstå diagrammet og kunne komme med kommentarer. 3.3.2 Klassediagrammer Det centrale diagram til statisk modellering i UML er klassediagrammet [Bahrami, 1999]. Hele systemets statiske struktur fremgår af klassediagrammet, hvor klasserne naturligt er de centrale elementer. Klasser kan yderligere kategoriseres ved for hver klasse at angive dens stereotype. Stereotypen vises mellem og kan bruges til at angive en klasses rolle i systemet (f.eks. brugergrænseflade, kontrol, entitet), på samme måde som «extends» og «uses» blev brugt i brugsmønsterdiagrammet [Bennett et al., 1999]. Sammenhængen mellem klasserne vises med forskellige typer relationer, som gennemgås nedenfor. «Interface» Tastatur -AntalTaster +ModtagInput() 25

Kapitel 3 - Det objektorienterede paradigme. ˆ Š Œ Ž ˆ Š H. š œ Ÿž.. T. ª ª «. ± ± ² ³ µ ¹ º. ± ± ²T» ¼ ½ ¾ ¾ À Á  Á(Á à Á Ä Ä Å Â Á Æ ÇÈÄ É Á   ÈÇ Á ÄTÉ ÇÊ Ë Ë Á Svage aggregeringsrelationer bruges til opbygning af part-of relationer, hvor klasserne eksisterer uafhængigt af hinanden. Dvs. at underklassen eksisterer uafhængigt af overklassen. Kardinalitet kan frit anvendes til at angive mængdeforholdene 1. Stærke aggregeringsrelationer bruges i lighed med svage aggregeringsrelationer til opbygning af part-of relationer. Dog er denne relation stærkere, og underklasser lever og dør med overklassen, forstået på den måde at instanser af underklasserne kun kan eksistere, hvis der eksisterer en instans af overklassen. Af samme årsag er kardinaliteten for overklassen altid mindst 1. Associationsrelationer bruges til at sikre, at to klasser kender til hinanden. To klasser kan ikke kommunikere med hinanden (lave metodekald og tilgå offentlige ressourcer), hvis de ikke er forbundet med en relation. Såfremt klasserne ikke er forbundet med andre relationer, anvendes en associeringsrelation til at illustrere sammenkædningen. Kardinalitet kan frit anvendes til at angive mængdeforholdene.. ª ª «T Grænsefladerelationer bruges mellem to klasser, hvoraf den ene fungerer som en grænsefladeklasse. Dette kan illustrere en grænseflade mellem to systemer. Generaliseringsrelationer sammenkæder klasser i en nedarvningsstruktur. En underklasse (f.eks. en sportsvogn) kan arve egenskaber og funktionalitet fra en overklasse (f.eks. en bil). Klynger viser, at et antal forbundne klasser udgør en form for enhed en klynge. Typisk er klasserne inden for en klynge forbundet med enten generaliseringseller stærke/svage aggregeringsrelationer. Det er muligt at have klynger i klynger. På engelsk kaldes dette en package [Booch et al., 2001]. Noter kan indsættes i klassediagrammet. Noter kan med en stiplet linje kædes til et element i klassediagrammet (f.eks. en klasse eller en relation). Det er dog ikke muligt at indsætte illustrationer. Ì ÍÎ Ï Ï Ð Ò Ì ÍÎ Ï Ï Ð Ñ Õ Ö Ø Ù ÚÛÚ Ü Ý Ì ÍÎ Ï Ï Ð Ó Ì ÍÎ Ï Ï Ð Ô Temaer bruges i store modeller til at inddele klasserne i overskuelige enheder. Et tema identificeres ved at ophæve den centrale klasse i en struktur til et tema og alle ikke-forbundne klasser til hver sit tema. Det er muligt at have temaer i temaer. 1 -Styrer Lagerstyring -AntalTommePladser : int -AntalFyldtePladser : int +FindTomPlads() +NedskrivLager() +OpskrivLager() +UdskrivStatus() 1 -Styres af Lager -AntalPladser : int +OpbevarEmner() 1 0..* -Har ansat «Aktør» Lagerekspedient -EkspedientID +Hent() +Modtag() +ÆndrLagerstatus() +LavEmneBeskrivelse() -Opdeles i 1 -Arbejder hos 1..* Lagerplads -Udgør -Lokation : int -Sektion : int -Hylde : int -Beskrivelse : String -Antal : int +FindEmne() +FindKundeemne() Figur 3.4: Eksempel på klassediagram i UML-notation [Riis, 2002] 1 Kardinalitet angiver mængdeforhold vha. kardinaltal f.eks. mellem to klasser. I en aggregeringsrelation vil et kardinaltal på 2 betyde, at overklassen består af to underklasser. 26

3.4 Objektorienteret design - OOD I figur 3.4 på foregående side er vist et eksempel på et klassediagram. Her ses det, at for hver klasse vises metoder og attributter inde i klassen. Alt afhængig af situationen kan det være hensigtsmæssigt at skjule disse informationer eller nøjes med at vise dele af dem i diagrammet. Opbygningen af klassediagrammet kan forløbe på flere måder, og som tidligere nævnt definerer UML kun, hvordan diagrammet skal se ud, og ikke hvordan det fremkommer. I litteraturen findes mange forskellige forslag til, hvordan klasser identificeres og relateres til hinanden. I Bahrami [1999] og Whitten et al. [2001] lægges op til, at man tager udgangspunkt brugsmønsterdiagrammet, hvilket også er centralt i Jacobson et al. [1999]. Bahrami nævner disse retningslinjer for identifikation af klasser: - Se efter navneord og sætninger med navneord i brugsmønstrene (dvs. især i beskrivelserne af brugsmønstrene). - Nogle klasser er implicitte eller kan uddrages af almindelig viden. - Alle klasser skal give mening i systemets domæne; undgå derfor klasser, der bruges ved implementering gem dem til designfasen. - Vær omhyggelig med navngivning og definition af klasserne. Herudover understreges, at det er en iterativ proces at identificere klasser. Efterhånden som modellen opbygges, bliver man opmærksom på flere aspekter og detaljer, som løbende tilføjes. Sekvensdiagrammer er også en god kilde til identifikation af klasser og definition af relationerne imellem disse. 3.4 Objektorienteret design - OOD Opgaven i designfasen er to design the classes identified during the analysis phase and [to design] the user interface [Bahrami, 1999, s. 47]. Bennett et al. supplerer dette ved at citere Rumbaugh: [Design is about] how the system will be constructed without actually building it [Bennett et al., 1999, s. 236]. De slår yderligere fast, at det ofte kan være svært at definere en klar skillelinje mellem analyse- og designfasen, men generelt kan man sige, at analyse drejer sig om at spørge, Hvad? der skal laves, og design drejer sig om at spørge, Hvordan? det skal laves. Forudsætningen for designfasen er en kravspecifikation fra analysefasen, og resultatet er en designspecifikation, som kan implementeres vha. programmeringssprog, software og hardware til det endelige system. Designaspektet kan yderligere opdeles i logisk og fysisk design. Ved logisk design tager man ikke stilling til den endelige implementering, men fokuserer på den logiske struktur og opbygning. Fysisk design drejer sig derimod om, hvordan systemet reelt skal implementeres. Herudover designes ofte på to niveauer: Systemdesign, der fokuserer på systemet som helhed, og detaljeret design, som går i detaljen med f.eks. klasser og databasestrukturer [Bennett et al., 1999]. 27

Kapitel 3 - Det objektorienterede paradigme Den diffuse overgang mellem analyse og design udviskes yderligere af, at objektorienteret systemudvikling lægger op til en iterativ proces. På især større projekter er det dog essentielt, at man kan slå en streg i sandet mellem analyse og design. I Bennett et al. [1999] nævnes fire overordnede årsager hertil: - Projektledelse Af hensyn til bl.a. budgetter og tidsestimater. - Medarbejderevner og -erfaring Analytikere er gode til at afdække en klients behov, mens designere ofte har forståelse for teknologiske muligheder. - Klientens beslutninger Afslutningen på analysefasen er en oplagt milepæl, hvor klienten underskriver grundlaget for det videre arbejde (sign off ). - Valg af udviklingsmiljø Valget af materiel, databaser og programmeringssprog vil påvirke designet, og på et tidspunkt skal beslutningen tages for at kunne komme i gang med designet. 3.4.1 Modellering i designfasen Grundlæggende er designfasen blot en videreudvikling af arbejdet i analysefasen. Klassediagrammet udgør en central rolle og vil blive mere og mere detaljeret. At arbejdet bygger på analysefasens modeller, gør naturligvis, at des bedre analysen er, des nemmere bliver det at lave designet. Herudover gør det det let at sammenholde kravene fra analysen med designbeslutninger. Flere CASE-værktøjer understøtter dette, og det er centralt for at kunne udvikle informationssystemer af høj kvalitet. Den uklare skillelinje mellem analyse og design betyder, at det er svært at afgøre, hvilke diagrammer der hører til hvilken fase. Whitten et al. [2001] skelner således mellem et analyse-brugsmønster og et design-brugsmønster, hvor en af de mest afgørende forskelle er, at design-brugsmønstret indeholder mere detaljeret information om objekternes indbyrdes handlinger. Den direkte videreudvikling af brugsmønstrene sker ved opbygning af interaktionsdiagrammer. 3.4.1.1 Interaktionsdiagrammer Aktiviteterne i brugsmønstrene kan detaljeres og beskrives yderligere i interaktionsdiagrammer. Det danske udtryk interaktionsdiagrammer dækker over sekvens- og samarbejdsdiagrammer (sequence- og collaborationdiagrams), som er to forskellige måder at vise den samme information på. Med disse diagrammer tilføjes en tidsdimension til handlingerne, og det bliver mere overskueligt at se omfanget af brugsmønstret i relation til klasser og deres interaktion. En ulempe er, at det ikke umiddelbart er muligt at tydeliggøre løkker [Bahrami, 1999]. I eksemplet i figur 3.5 på følgende side er benyttet notationen fra Bennett et al. [1999], der foreslår, at løkker angives ved at sætte en * foran procedurekaldet. 28

3.4 Objektorienteret design - OOD ø`ù ú ûtü(ý þtü ÿ qü þ Tù ú è á éê á ë ì ß âß ô ß ä ò ß ì à ó(á å ì ótá å ì â æç à è á é ê á ë ì ß ä å æ ç è á é ê á ë ì ß ä ö è âæß ì à â æç à ítì ì î ì ï ß ä å æç ítì ì î ì ï ß ä à æ âð ñ ãítì ì î ì ï ß õ ò ß ì à è á ébê á ë ì ß Þ(ß à á âã ß ä ÞTß à á âã ß ä öè á éê á ë ì ß ù Tú Tù õ ò ß ì àítì ì î ì ï ß Þ(ß à á âã ß ä íqì ì î ì ï ß ÞTß à á âã ß ä öítì ì î.ì ï ß þ Tù ú Tú þ qù ú (ú Tù ú ú (ú ø Tü(þ Tù ú qù Eø.ù ü (ú ÿ(ü Tü å æç ó. ítì ì î ì ï ß ítì ì î ì ï ß ü (ú ú.ú Tþ Tù ú ì ítì ì î ì ï ß öítì ì î ì ï ß Figur 3.5: Eksempel på sekvensdiagram i UML-notation [Bennett et al., 1999, s. 173] 678 8 9 : ;<= 9 >? = @A 9 B"C"9 D? E CF 9 ) * & +, - "! # $ % (.* / +, "! # $ % ( 1* 2 % $ - "! # $ % 3 % - &4 % ( 5* 3 % - &4 % ( * & + % $ - * 0! # $ % "! # $ % & % ' % ( GIH J 9 8 K Figur 3.6: Eksempel på samarbejdsdiagram for sekvens 2 Vis kampagnedetaljer i figur 3.5 Et samarbejdsdiagram er blot en anden måde at vise informationen på. Et eksempel er givet i figur 3.6, hvoraf det fremgår, at et samarbejdsdiagram fremhæver klassernes interaktioner, men uden det overskuelige tidslige aspekt, som sekvensdiagrammerne fokuserer på. At diagrammerne indeholder den samme information bekræftes af, at det i Rational Rose er muligt at generere et samarbejdsdiagram fra et sekvensdiagram blot ved at trykke på en tast. Fordelen ved et samarbejdsdiagram er, at det er nemt at overskue, hvordan klasserne samarbejder. F.eks. vil det være helt tydeligt, hvis et enkelt objekt har en central rolle, da alle andre objekter vil stå ud fra det som i en stjerne. Når klassediagrammet er udbygget, kan sekvensdiagrammerne opdateres til at afspejle informationen i klasserne. Objekterne tilføjes navnene på klasserne, beskederne erstattes med metodekald og gives argumenter, der er i overenstemmelse med definitionen i klasserne. 29

Kapitel 3 - Det objektorienterede paradigme Dette arbejde understøttes i vid udstrækning af CASE-værktøjer (f.eks. Rational Rose og MS Visio), hvor man blot klikker på en besked og kan vælge den ønskede metode blandt dem, som er defineret for den modtagende klasse. Når modellen er fuldt udbygget med fuld definition af klasser og detaljerede sekvensdiagrammer, er meget af grundlaget for kodningen på plads, og nogle CASE-værktøjer kan automatisk generere kode på baggrund af modellen (f.eks. Rational Rose). Derfor skal man ofte tage stilling til, om man vil modellere med henblik på f.eks. Java, C++ eller Visual Basic. 3.4.1.2 Andre diagrammer I designfasen udvikles flere detaljerede diagrammer til at beskrive systemet. Disse omfatter bl.a. - Aktivitetsdiagrammer (Activity Diagram) Til anskueliggørelse af rækkefølgen af hændelser og parallelle hændelseforløb samt synkronisering af disse (figur 3.7(a) på følgende side). - Tilstandsdiagrammer (State Chart Diagram) Til beskrivelse af et objekts tilstand især anvendelig hvis objektet kan antage mange forskellige tilstande, eller til illustration af hvad der fører et objekt fra en tilstand til en anden (figur 3.7(b) på følgende side). - Anvendelsesdiagram (Deployment Diagram) Illustrerer, hvordan systemets struktur ser ud i driftssituationen, dvs. hvordan forskellige software- og hardwareelementer er koblet sammen og konfigureret (figur 3.7(c) på følgende side). I Bahrami [1999] lægges op til, at man opdeler systemet i et antal lag, f.eks. et acces layer og et view layer. Gennem arbejdet med disse lag skal brugergrænsefladen og datastrukturen lægges endeligt fast. Brugergrænsefladen udvikles bedst ved at lave flere prototyper, som testes over for brugerne. Til design og specifikation af datastrukturen eksisterer flere diagrammeringsmetoder (f.eks. entity-relationsship diagrammet), som er velegnede til dette. 3.5 Objektorienteret implementering - OOI Eksempler på OO-sprog: - C++ - Smalltalk - Java I designfasen (fysisk design) er implementeringen blevet planlagt og specificeret. I implementeringsfasen anvendes specifikationen fra designfasen som grundlag for den endelige programmering. Det er ikke nødvendigvis alt, der skal programmeres op fra bunden. I det objektorienterede domæne lægges der op til genbrug, og pga. princippet om indkapsling er det relativt let at genbruge klasser og klynger fra tidligere projekter (eller evt. kommercielle). Implementeringen foregår med anvendelse af objektorienterede programmeringssprog. Måske findes nogle Commercial Off The Shelf (COTS)-moduler, som med nogle små programstumper (middleware) kan løse nogle af opgaverne. Dette kan ofte være en bedre og billigere løsning end at bygge hele systemet fra bunden. 30

3.5 Objektorienteret implementering - OOI Skal der skiftes gear? Ja Nej Kør videre Ne w it em created Undeliv ered Produc t not on stock Backordered [ \ ] ^ ^ _ ` a b c k lm n o p o q r s Hold kobling nede Bevæg gearstang Picking lis t prin ted Stock receiv ed Un confirmed d X P P Qe f M Q g d h i N P j M N t u k vr wr sr x q Kør videre i nyt gear Qu antity confir me d Confirmed L M N O P Q R S T N U V W X N M Y Z T N (a) Aktivitetsdiagram (b) Tilstandsdiagram (c) Anvendelsesdiagram Figur 3.7: Eksempler på diagrammer anvendt i designfasen [Riis, 2002] «Header» SalesOrder.h «includes» «Body» SalesOrder.cpp «Object Code» SalesOrder.o «Executable» PrintOrder.exe Figur 3.8: Eksempel på komponentdiagram, der viser afhængigheder i C++ [Bennett et al., 1999, s. 418] UML s anvendelses- og komponentdiagrammer bruges til at dokumentere implementeringen, så det er let at vedligeholde systemet fremover. Anvendelsesdiagrammet er illustreret i figur 3.7(c) og komponentdiagrammet i figur 3.8. Implementeringsfasen er ikke en simpel opgave, men kræver god planlægning. Ud over selve programmeringen dækker implementeringsfasen også over aktiviteter som testning, konvertering af data fra gamle systemer og den helt afgørende opgave med at indføre det nye system i organisationen. Efter implementeringen følger vedligeholdelsesfasen, som naturligt strækker sig over resten af systemets levetid. Hvis ikke systemet er veldokumenteret og struktureret opbygget, kan det hurtigt blive meget omstændeligt hvis ikke umuligt at vedligeholde og udbygge systemet. I sidste instans betyder det, at man vælger at lave et helt nyt system i stedet for at udbygge det eksisterende. På den måde kan en ny analysefase starte, og livscyklussen er sluttet. 31

Kapitel 4 Produktmodellering Indhold af dette kapitel 4.1 Introduktion til produktmodellering........ 34 4.1.1 Produktmodeller og konfigurering........... 34 4.1.2 Rammemodel for produktmodeller.......... 37 4.2 Fremgangsmåde for opbygning af produktmodeller 38 4.2.1 Dokumentationsarbejdet................ 38 4.3 Dokumentation af produktmodeller........ 40 4.3.1 Produkt-Variant Master................ 40 4.3.2 Klassediagram..................... 42 4.3.3 CRC-kort........................ 43 I dette kapitel gives en introduktion til produktmodeller, og hvorledes produktmodeller anvendes i specifikationsprocessen. Herudover gennemgås fremgangsmåden for opbygning af produktmodeller fra CPM med særlig fokus på den dokumentation, som anvendes. Formålet er at afdække produktmodelleringsprocessen og behovet for dokumentation med henblik på den senere analyse af kravene til et IT-baseret dokumentationsværktøj. 33

Kapitel 4 - Produktmodellering 4.1 Introduktion til produktmodellering Et stadigt mere krævende marked har øget fokuseringen på produktudviklingsog specifikationsprocessen for at kunne imødekomme kundernes forventninger om mere kundetilpassede produkter med kort leveringstid og til konkurrencemæssige priser [Hvam og Mortensen, 2002; Pikosz, 1997]. Udviklingen inden for informationsteknologien har samtidig gjort det muligt at lave komplekse systemer, der kan understøtte de beslutningsprocesser, som indgår i specifikationen af et produkt ud fra en række krav. Et eksempel på anvendelsen af IT til understøttelse af konfigurering af et komplekst produkt er nævnt i Hvam og Mortensen [2002]. Her beskrives, hvorledes F.L. Smidth, der fremstiller cementfabrikker, med succes har taget et informationssystem i brug, der kan støtte op under udarbejdelsen af budgettilbud. Hidtil har udarbejdelsen af tilbud involveret 10-15 specialister og taget tre-fem uger. Med det nye informationssystem (en konfigurator) tager processen en-to dage og kan udføres af en enkelt sælger. Fordelene og besparelserne ved at bruge konfiguratoren frem for den manuelle metode er indlysende. 4.1.1 Produktmodeller og konfigurering For at undgå misforståelser og fejlfortolkninger er en præcisering af begreberne på sin plads. Hvam og Mortensen definerer en produktmodel således: En produktmodel betegner et system, der indeholder viden og information om selve produktets funktion og struktur. [Hvam og Mortensen, 2002] og supplerer om produktmodellering: Begrebet produktmodellering betegner opbygningen af en videnbase, der indeholder viden og information, der knytter sig til produktet i forskellige faser af dets livscyklus. [Hvam, 1994] Dette støttes af Krause et al., der beskriver produktmodellering som Product modelling can be interpreted as the logical accumulation of all relevant information concerning a given product during the lifecycle. [Krause et al., 1993, citeret i Riis [2001]] Denne information er basis for produktkonfigurering, som bl.a. er defineret i Riis [2001, s. 55] som... to combine well defined building blocks governed by rules and constraints into a product. Riis nævner også, at produktkonfigurering kan anvendes inden for flere anvendelsesområder, heriblandt tilbudsgivning/salg, produkttilpasning og produktionsforberedelse. Figur 4.1 på følgende side illustrerer de centrale aktiviteter i en virksomheds specifikationssystem. Specifikationssystemet omfatter alle de processer og akti- 34

4.1 Introduktion til produktmodellering Specifikationssystemet Specifikationssystemet Salg Kalkulation Salg Produktkonstruktion Produktionsforberedelse Produktkonstruktion Produktionsforberedelse Kalkulation Produktmodeller Indkøb Planlægning Produktion Levering/ montage Indkøb Planlægning Produktion Levering/ montage (a) Uden anvendelse af produktmodel (b) Med anvendelse af produktmodel Figur 4.1: Anvendelse af produktmodeller i specifikationssystemet [Hvam og Mortensen, 2002, s. 18] viteter, der tilsammen specificerer et produkt. Typisk vil disse aktiviteter være fordelt ud på flere afdelinger, og specifikationen af et produkt f.eks. i forbindelse med et salg vil derfor indebære megen kommunikation på tværs mellem afdelingerne (figur 4.1(a)). Med anvendelse af en produktmodel kan al information om produktet samles på tværs af organisatoriske opdelinger, og ud fra produktmodellen er det således muligt at definere, på hvilke måder et produkt kan struktureres. Med produktmodellen kan f.eks. en sælger egenhændigt specificere et produkt til en kunde ved at trække på informationen i produktmodellen (se figur 4.1(b)). Overblikket kan dog være svært at få for et menneske, da antallet af mulige kombinationer kan være astronomisk. Tænk f.eks. blot på, hvor mange varianter én enkelt bilmodel kan fås i (farve, laktype, dæk, motorstørrelse, ekstraudstyr mv.). Med anvendelse af informationssystemer kan alle restriktioner og muligheder til gengæld overskues man taler da om en produktkonfigurator. Hvam og Mortensen [2002] specificerer en produktkonfigurator som... et IT-system [... ], der er ideelt til at sammensætte fast definerede moduler i et produkt i forhold til en række givne begrænsninger. [Hvam og Mortensen, 2002, s. 24] Grundlaget i en produktkonfigurator er en produktmodel, som indeholder al den relevante viden, som f.eks. konstruktions- og produktionsingeniører har om produktet. Dette er bl.a. information om, hvilke underdele der indgår i produktet, og regler om hvordan disse kan sammensættes. Traditionelt har denne information været spredt i organisationen, men formålet med en produktmodel er at samle al denne information og gøre den tilgængelig for et bredere publikum gennem en produktkonfigurator (se figur 4.2 på følgende side). De nyeste konfiguratorer baseres på en objektorienteret produktmodel, hvor produktet kan modelleres med strukturer som i det objektorienterede domæne (se kapitel 3 på side 19). Dette giver helt nye muligheder for produktmodellering og ligger tæt op ad idéerne i CPM s fremgangsmåde, som beskrives i afsnit 4.2 på side 38. 35

Kapitel 4 - Produktmodellering z ˆ "ši š" " œ } z 0 z Š ŒŽ Ž Œ { y{z "}~z } z ƒ 0~I 0ˆ~ Figur 4.2: Sammenhæng mellem produktkonfigurator og produktmodel (simplificeret) Figur 4.3: Eksempel på konfigurator fra APC Et eksempel på en (meget simpel) produktkonfigurator findes hos APC, der sælger nødstrømsudstyr til f.eks. computere (se figur 4.3). På virksomhedens hjemmeside kan man indtaste, hvor mange computere, skærme, printere etc. der skal sikres, og systemet vil så på baggrund af denne information finde den bedste Uninterruptible Power Supply (UPS) i den givne situation. Som nævnt er det en simpel konfigurator, og for god ordens skyld skal nævnes, at APC snart lancerer en konfigurator for deres nye produkt PowerStruxure, som bygger på en meget kompleks produktmodel og bl.a. også anvender dynamisk visualisering som et centralt element i konfigureringsoprocessen 1. 1 Visualiseringen er resultatet af et netop afsluttet eksamensprojekt ved CPM [Kristensen, 2002]. 36

4.1 Introduktion til produktmodellering 4.1.2 Rammemodel for produktmodeller I Hvam og Mortensen [2002] er opstillet en model for produkt- og produktrelaterede modeller. Baggrunden er, at det ved produktmodellering ofte ikke vil være tilstrækkeligt kun at have en model af selve produktet. Når et produkt skal specificeres, foretages nogle valg, som påvirker produktets andre livsfaser. I figur 4.4 er rammemodellen vist med selve produktmodellen til venstre og modeller for alle faserne i produktets livsfoløb til højre. Produktmodel Funktion Struktur Relationsmodeller Salg Konstruktion Produktionsforberedelse Planlægning Indkøb Produktion Montage Anvendelse Destruktion Figur 4.4: Rammemodel for produktmodeller [Hvam og Mortensen, 2002] Rammemodellen viser, hvordan en produktmodel består af en funktionel og strukturel beskrivelse og kan være relateret til en række andre modeller. Den model, som skal fungere som basis for en produktkonfigurator, skal indeholde information om de områder, som konfiguratoren skal kunne dække. Ofte vil det ikke være hensigtsmæssigt (eller nødvendigt) at inddrage information om alle livsforløbets faser (relationsmodeller), og i stedet vælger man at fokusere på f.eks. produktets strukturelle opbygning og relationen til indkøb og montage. Med en sådan model som udgangspunkt er det muligt at konfigurere et produkt ud fra dets strukturelle opbygning (f.eks. hvor meget RAM en computer skal have), frem for at der tages udgangspunkt i det funktionelle behov (f.eks. til hvilket formål computeren skal anvendes). Med hensyn til relationsmodellerne betyder det, at konfigurationen tager hensyn til indkøbsfasen (f.eks. ved at generere en liste over de komponenter, der skal indkøbes) og montagefasen (f.eks. ved at angive en fordelagtig montagerækkefølge). Det betyder samtidig, at der f.eks. ikke tages hensyn til, hvordan produktet destrueres (f.eks. ved at give mulighed for at vælge om produktet må indeholde visse plasttyper). Med rammemodellen er det muligt at definere omfanget af den kommende specifikationsproces, idet der tages stilling til, hvilken information der skal være indeholdt i modellen. Men samtidig gøres også klart, hvad der ikke er indeholdt i modellen, og dermed hvad modellen ikke kan bruges til. 37

Kapitel 4 - Produktmodellering 4.2 Fremgangsmåde for opbygning af produktmodeller Anvendelsen af produktmodeller har en række fordele og kan forbedre specifikationsprocessen markant for både virksomhed og kunde. For at kunne drage nytte af produktmodellen i det lange løb og undgå faldgruber er det nødvendigt at anvende en struktureret fremgangsmåde [Hvam og Mortensen, 2002; Hvam og Riis, 1999]. Ved CPM på DTU er der blevet forsket inden for området de sidste ti år, og et af resultaterne er fremgangsmåden for opbygning af produktmodeller, som ud over forskningen også er baseret på erfaringer fra opbygning af produktmodeller i såvel danske som udenlandske virksomheder. Fremgangsmåden er beskrevet i Hvam og Mortensen [2002] og er kraftigt inspireret af objektorienteret udvikling af informationssystemer. Den grundlæggende filosofi er, at more work up front pays in the end, og det betyder, at der lægges stor vægt på de indledende faser med analyse og design af systemet. Al erfaring viser, at netop dette reducerer ressourcebehovet ved den efterfølgende implementering. I alt består fremgangsmåden af syv faser, som er kort beskrevet i tabel 4.1 på følgende side. Herudover har jeg for at give overblik over aktiviteterne i faserne lavet en funktionsmodel for fremgangsmåden baseret på Integration Definition for Function Modelling (IDEF0)-standarden (se bilag B på side 167). Af funktionsmodellen er det også tydeligt at se, hvilke ressourcer der er påkrævet for hver aktivitet, og hvad der er resultatet af aktiviteten. Fase 1 er en forretningsanalyse, der har til formål at beskrive såvel den eksisterende som den kommende situation og kontekst, før selve modelleringsarbejdet går i gang. Arbejdet med produktmodellens dokumentation starter i fase 2 (Produktanalyse), hvor der opbygges en PVM. Gennem faserne 3 og 4 videreudvikles produktmodellen, og der skabes mere dokumentation i form af klassediagrammer og CRC-kort, som udgør den endelige dokumentation for produktmodellen. I fase 5 bruges denne dokumentation som basis for programmeringen, og i fase 7 opdateres dokumentationen løbende, i takt med at produktmodellen og konfiguratoren vedligeholdes. Dokumentationen berøres ikke i fase 6, som primært omhandler opstart af anvendelsen af produktkonfiguratoren. 4.2.1 Dokumentationsarbejdet Arbejdet med dokumentationen starter som nævnt med opbygningen af PVM en. Dette arbejde udføres i samarbejde mellem bl.a. domæneeksperterne (som er eksperter i produktet), systemudviklerne (der skal programmere konfiguratoren) og sælgeren (som skal bruge konfiguratoren) og er en iterativ proces, hvor PVM en fungerer som det samlende kommunikationsmedium, som alle kan forstå. Under arbejdet med PVM en udfyldes CRC-kortene løbende for at dokumentere klasserne i PVM en. 38

4.2 Fremgangsmåde for opbygning af produktmodeller Fase Indhold Resultat 1 Procesanalyse Analyse af de specifikationsprocesser, der skal understøttes. Analyse af den opgave specifikationsprocessen skal løse. Konstruktion af fremtidig specifikationsproces. Herunder fastlæggelse af de produkt- og produktrelaterede modeller, der skal understøtte specifikationsprocessen og disses formål, synsvinkel og kontekst. 2 Produktanalyse Analyse af produktmodel. Opbygning af Produkt-Variant Master (PVM). 3 Objektorienteret analyse 4 Objektorienteret design Opbygning af objektorienteret analysemodel (OOA) Opbygning af objektorienteret designmodel (OOD). Beskrivelse af nuværende specifikationsproces. Beskrivelse af specifikationsprocessens opgave. Modellernes overordnede indhold. Formål, synsvinkel og kontekst. Komplet Produkt-Variant Master (PVM). OOA-model (evt. dynamik), brugergrænseflade og kravspecifikation. OOD-model. 5 Programmering Programmering og test. Programkode (for den givne konfigurator). 6 Implementering Implementering. Brugervejledning og uddannelsesplan. 7 Vedligeholdelse Vedligeholdelse, herunder udpegning af ansvarlige for vedligeholdelse og videreudvikling. Opdateret OOA-model og programkode. Ansvarlige for vedligeholdelse og videreudvikling. Tabel 4.1: Fremgangsmådens faser [Hvam og Mortensen, 2002] Udfyldelsen af CRC-kortene bør ifølge Hvam og Riis [1999] udføres af domæneeksperterne. For det første er de de eneste, der besidder den nødvendige viden, og for det andet vil det medvirke til at give dem en følelse af medejerskab i forhold til produktmodellen. Det sidste er især vigtigt i den efterfølgende vedligeholdelse og evt. udvidelser af modellen. Indholdet af CRC-kortene er tæt forbundet med indholdet af PVM en og klassediagrammet. Meget information går igen i de tre diagrammer, og det er derfor vigtigt at sikre, at den samme information rent faktisk er identisk i alle tre. Efterhånden som størrelsen og kompleksiteten af en produktmodel vokser, stiger behovet for at holde den opdateret. For det første er opgaven i sig selv større, og for det andet er en stor kompleks model svær at overskue, og fejl bliver derfor sværere at identificere. 39

Kapitel 4 - Produktmodellering I Hvam og Mortensen [2002] gøres opmærksom på, at hvis CRC-kort skal anvendes til den løbende dokumentation af en produktmodel, bør de være på elektronisk form eller ligefrem integreret i selve koden for produktmodellen. Hermed lægges op til, at ændringer i produktmodellen automatisk detekteres og måske endda automatisk opdateres i koden. 4.3 Dokumentation af produktmodeller I dette afsnit vil jeg med udgangspunkt i faserne i fremgangsmåden gennemgå den dokumentation, der anvendes ved produktmodellering. Fremgangsmåden baseres i høj grad på genbrug fra forskellige metoder, og dokumentationen er derfor ikke opfundet til lejligheden, men snarere tilpasset fra andre områder (med undtagelse af PVM en). 4.3.1 Produkt-Variant Master I fase 2 opbygges en PVM. Formålet med dette er at skabe et overblik over virksomhedens produktprogram og at definere strukturen i de produkt- og produktrelaterede modeller, der skal opbygges [Hvam og Mortensen, 2002, s. 38]. Overblikket kræver, at man gør sig klart, hvilke fællesdele en produktfamilie er opbygget af, og hvilke dele der gør, at produkterne i familien adskiller sig fra hinanden (dvs. hvor variansen skabes). Figur 4.5: Eksempel på Produkt-Variant Master [Harlou, 1999, s. 10] 40

4.3 Dokumentation af produktmodeller En PVM består af to overordnede dele: En part-of del og en kind-of del. Part-of Part-of ž Ÿ delen er i venstre side af PVM en og indeholder de moduler, dele eller klasser (herefter kaldt klasser 2 ), der indgår i alle produkter i familien (f.eks. har alle biler i en produktfamilie fire hjul). I Harlou [1999, s. 10] hentes definitionen af ª «part-of relationer fra det objektorienterede domæne, men der tages ikke stilling til, om der er tale om en stærk eller svag aggregeringsrelation 3. ± ² ³ µ ³ En klasse i part-of strukturen kan yderligere dekomponeres i et hierarki af un- ¹ º derklasser, og det er også muligt at tilføje attributter til hver klasse. For hver attribut er det hensigtsmæssigt at angive et værdiinterval, dvs. et interval eller en liste for de værdier attributten kan antage. En klasse i PVM en følger definitionen af klasser i det objektorienterede domæne;... a set of objects that share a common structure and a common behavior [Harlou, 1999, s. 10]. Í Î ÏÏ Ð Ñ ÍÒ Ó Ò Ô Ñ»"¼½ ¾" Ë ÆÌ IÇ ÀÂÁà ÁIÄ Í Î ÏÏ Õ Ñ Å ÆÇ È0ɹ 0Ê Kind-of delen er i højre side af PVM en, og hver kind-of struktur er relateret Kind-of Ö Ø til én klasse i part-of delen. En kind-of struktur beskriver, hvordan en klasse kan varieres. F.eks. kan en bil fås med enten benzin- eller dieselmotor. En klasse i en kind-of struktur er af samme slags som den klasse i part-of strukturen, der relateres til (en dieselmotor er en slags motor). På den måde svarer kind-of strukturer oftest til generaliseringsstrukturer i det objektorienterede domæne. à Ü á Ü Û æ Ü å ä ç Þ è Ù Ú Û Ü Ý Ý Þ Û ß â ã ä å é êåë ì êí Bindinger bruges i PVM en til at beskrive, hvordan klasserne kan kombineres. Bindinger 0ø ù En binding kan f.eks. være, at der kun skal være fire hjul, hvis bilen er en sportsvogn, fordi der ikke er plads til reservehjul. Begrænsninger visualiseres dog ikke kun med bindinger, idet kardinalitet og attributternes værdiinterval også begrænser mulighederne [Harlou, 1999, s. 10]. Som støtte til den formaliserede tegning af produktstrukturen indsættes ofte noter og illustrationer i PVM en. På den måde virker PVM en lidt som et dokument i et tegneprogram, og i praksis anvendes ofte f.eks. MS Visio eller et lignende program til at opbygge en PVM. ý ý ü ý ÿ ú û ü ý þ þ ÿ ü î ïð ñ ð òôó ð õ ö ï õ $%&'$(!"# Arbejdet med PVM en har også til formål at virke som et pædagogisk kommunikationsmedium [Hvam og Mortensen, 2002; Mortensen et al., 2000]. Ofte tegnes (eller udskrives) PVM en på et stort stykke papir, f.eks. 2 4 m, og på den måde er det nemt at overskue produktsortimentet. Produktmodelleringsopgaven gøres samtidig også mere synlig for de involverede personer. 2 Inden for konstruktionsteknik bruges betegnelsen modul, men inden for produktmodellering bruges flere betegnelser, hvoraf klasse bedst tydeliggør den tætte kobling til det objektorienterede domæne. 3 Både stærke og svage aggregeringsrelationer angiver, at en klasse udgøres af flere underklasser. For en stærk gælder, at underklasserne lever og dør med overklassen. Dvs. hvis overklassen ikke eksisterer, kan underklasserne heller ikke eksistere. I modsætning hertil kan underklasserne i en svag aggregeringsrelation godt eksistere uafhængigt af overklassen. 41

Kapitel 4 - Produktmodellering 4.3.2 Klassediagram Resultatet af fase 3 er et klassediagram, som beskriver produktsortimentet. Opbygningen af klassediagrammet er resultatet af de fem aktiviteter, som fase 3 består af: 1. Find klasser og objekter Identifikation af de klasser, som udgør produktsortimentet. 2. Identificér strukturer Opbygning af relationer mellem de fundne klasser. 3. Identificér temaer Gruppering af klasser i temaer (letter overskueligheden). 4. Definér attributter Hvad ved klasserne om sig selv? 5. Definér metoder Hvad kan klasserne gøre? Herunder identifikation af bindinger. Meget af arbejdet er allerede gjort i fase 2 under opbygningen af PVM en. Her er mange klasser og deres relationer beskrevet, og denne information er et godt udgangspunkt for aktiviteterne ovenfor. Med rækkefølgen af aktiviteterne lægges op til, at der først fokuseres på at opbygge den overordnede struktur. Derefter detaljeres modellen med opdeling i temaer og tilføjelse af attributter og metoder. Idéen bag klassediagrammet er baseret på konceptet fra det objektorienterede domæne, og notationen følger standarden i UML, som blev gennemgået i afsnit 3.3 på side 23. Et eksempel på et klassediagram i en produktmodel er vist i figur 4.6 på følgende side, og det fremgår, at ikke alle elementerne fra UML anvendes i klassediagrammet, hvilket er typisk for produktmodellering. Klasse Hjul -Diameter +AntalHjul() Systemmetoder Produktmetoder Attributter Klassen er det centrale element i klassediagrammet og... afspejler direkte tilsvarende fysiske eller begrebsmæssige koncepter i et problemdomæne [Hvam og Mortensen, 2002, s. 91]. En klasse beskrives ved dens attributter og metoder. Riis skelner i den forbindelse mellem system- og produktviden, og i relation til en klasses metoder betyder det, at der med fordel kan laves en opdeling i systemmetoder og produktmetoder [Riis, 2002, kapitel 2]. Systemmetoder beskriver klassens interaktion med de omgivende systemer og bruges også til opbygningen af IT-systemet. Et eksempel kunne være en metode, der beskriver, hvordan informationen i en klasse skal præsenteres i konfiguratoren eller overføres til eller fra virksomhedens ERP-system. Produktmetoder beskriver klassen i relation til produktmodellen eller livsfasesystemerne. Et eksempel her kunne være bindinger til andre klasser. Opdelingen betyder, at en metode entydigt skal kunne placeres i en af kategorierne, og domæneeksperter skal udelukkende have adgang til produktmetoderne. Attributter beskriver klassens egenskaber, og det er muligt at definere attributtens type, initialværdi, værdiinterval og enhed. 42

4.3 Dokumentation af produktmodeller Figur 4.6: Eksempel på klassediagram [Andersen og Jensen, 2001] Relationer beskriver, hvordan klasserne er forbundet med hinanden. Inden for Relationer produktmodellering anvendes kun et udvalg af UML s brede vifte. I Hvam og Mortensen [2002] nævnes kun svage aggregerings-, associerings- og generaliseringsrelationer, men Andersen og Jensen [2001] har i deres modeller herudover også anvendt stærke aggregerings- og implementeringsrelationer. Et af hovedformålene med Andersen og Jensens projekt var at afdække, hvordan anvendelsen af modelleringsteknik fra det objektorienterede domæne (og især UML) kunne udvides inden for produktmodellering. I Andersen og Jensen [2001] har de lavet en beskrivelse af, hvordan UML-elementerne kan anvendes, suppleret med eksempler på praktisk anvendelse i deres resultat. I tabel 4.2 på følgende side er sammenhængen mellem UML-elementer og klassediagrammet for produktmodellering opsummeret. Herudover anvendes i Andersen og Jensen [2001] et koordinatsystem, som ikke er en del af UML. Formålet er at skabe overblik og lette navigeringen i store, komplekse modeller på samme måde som man navigerer på et landkort eller et skakbræt. 4.3.3 CRC-kort Sammen med PVM en blev CRC-kort introduceret og brugt til at beskrive klasserne [Hvam og Riis, 1999; Mortensen et al., 2000]. Efter at Hvam og Mortensen introducerede brugen af klassediagrammet til at beskrive produktsortimentet, er CRC-kortet naturligt blevet brugt til at detaljere beskrivelsen af klasserne i klassediagrammet. Meget af informationen på et CRC-kort kan derfor uddrages af såvel PVM og klassediagram, som det fremgår ved at sammenligne figur 4.7 på side 45 med figur 4.5 på side 40 og figur 4.6. >? @ 8:9<;:= 2/011,3 5 6 2/011,4 2/011,7 )*+,-./011, 43

Kapitel 4 - Produktmodellering UML-element Klasse Metoder Attributter Aggregering, svag Aggregering, stærk Association Grænseflade Generalisering Klynger Temaer Note Koordinatsystem Anvendelse ved produktmodellering Afspejler typisk et fysisk modul i et produkt. F.eks. et bilsæde eller en motor i en bil. Opdeles i system- og produktmetoder. F.eks. beskrivelse af, hvordan en klasse udveksler information med et ERP-system (systemmetode), eller regler om hvordan farven på et stolesæde kan vælges ud fra valg af overflade (produktmetode, binding) Beskriver egenskaber ved en klasse. F.eks. højde, farve eller vægt. Part-of relation hvor objekterne eksisterer uafhængigt af hinanden (svag binding). F.eks. relation mellem en stol og ekstra tilbehør (en stolevogn). Part-of relation hvor objekterne lever og dør med hinanden (stærk binding). F.eks. relation mellem stolesæde og stoleben. Kende til relation til at sikre, at to klasser kender til hinandens eksistens og dermed kan kommunikere. F.eks. mellem stolesæde og en evt. polstring af sædet. Relation mellem to klasser, hvor den ene fungerer som grænseflade. F.eks. mellem to systemer; til at sammenkoble en funktions- og strukturmodel for samme produkt. Andersen og Jensen [2001] brugte denne relation, men vurderede, at anvendeligheden i produktmodellering ikke var stor. Sammenkæder klasser i et nedarvningshierarki, hvor underklasser kan arve egenskaber og funktionalitet fra overklasser. F.eks. at både læder og stof er en slags polstring. Samler klasser i enheder. F.eks. en samling af de klasser, der udgør stolen Syveren. Opdeler komplekse diagrammer i overskuelige dele. F.eks. opdeling i konfigurerings- og beregningsdel. Ubundet element til at tilføje valgfri noter. Blev introduceret af Andersen og Jensen [2001], men i projektet blev koordinatsystemet tegnet på klassediagrammet i hånden. Det var dermed svært at opdatere og fungerede ikke godt i praksis. Tabel 4.2: Anvendelse af UML-elementer i klassediagrammer ved produktmodellering [Andersen og Jensen, 2001; Hvam og Mortensen, 2002] Der er ikke nogen entydig definition på, hvilke felter et CRC-kort skal indeholde, men i Hvam og Riis [1999] er givet et bud på et generisk CRC-kort, som er en modificeret udgave af CRC-kortet fra det objektorienterede domæne. CRC-kortet i figur 4.7 på følgende side er næsten identisk med Hvam og Riis generiske CRC-kort, bortset fra at feltet Object Constraint Language (OCL) er tilføjet. Samtidig er det et eksempel på, at CRC-kortet kan tilpasses den aktuelle anvendelse. Stamoplysninger Hver klasse har netop ét CRC-kort tilknyttet, og øverst er klassens stamoplysninger samlet (ID, klassenavn, oprettelsesdato og forfatter). Felterne under Samling og Generalisering placerer klassen i klassestrukturen ved at liste over- og underklasser for de relationer, der forbinder klassen med andre klasser. 44

4.3 Dokumentation af produktmodeller Klassenr. : 3107 Samling Klassenavn : csyveren Dato : 09.08.2001 Generalisering Overdele : Overklasser : cprodukt Forfatter : PVA Underdele : cstoleskal (3107-1), cunderdel (3107-3), cskriveplad e (3107-2), ctilbehør (3107-4) Mission : Underklasser : Skitse : Attributter : eprodukt - Produktgruppe [#PStol]. Konstan t edesigner - Designer af produkt [#DArneJacobsen]. Konstan t eanvendelse - Produktets anvendelsesområder [#ABolig]. Konstant. wnumber - Antallet af stole, som indgår i f.eks. bestillingen. Metoder : fnmakepartlist() : List : Sammensætter styklister fra underliggende objekter til en færdig stykliste for Syveren ACB OCL : inv: cunderdel(3107-3)->select( ocltype = cdrejefod ) implies ctilbehør(3107-4)- >size = 0 and cskriveplade(3107-2)->size = 0 ACD ACE AFG cunderdel(3107-3).cdrejefod->select( ocltype = cdrejefod_armlæn ) or cunderdel(3107-3).c4benet->select( ocltype = c4benet_armlæn ) implies cskriveplade(3107-2)->size = 0 CTilbehør(3107-4).bSuspension = true implies cskriveplade(3107-2)->size = 0 ( cskriveplade(3107-2)->size = 1 ) and ( ctilbehør(3107-4).bclutch <> noclutch ) implies ctilbehør(3107-4).bclutch = #longclutch csyveren::fnmakepartlist() : List pre : --none post: --none Figur 4.7: Eksempel på CRC-kort Andersen og Jensen [2001] Klassens formål beskrives i feltet Mission, og derudover er det muligt at indsætte en illustration til støtte for beskrivelsen. Klassens attributter og metoder er alle listet med navn og indhold. I eksemplet Attributter er attributterne listet med deres navn, initialværdi og en kort beskrivelse. Der er dog umiddelbart ikke nogen gængs praksis for, hvordan attributter beskrives. Metoderne i figuren er opdelt i to typer Metoder og OCL. Opdelingen skyldes, Metoder at der i dette tilfælde er valgt at anvende OCL til at beskrive bindingerne. OCL er et formaliseret deklarativt sprog og er en del af UML. Sproget er udviklet for at kunne beskrive f.eks. begrænsningerne i et klassediagram på en måde, der for det første er utvetydig og for det andet kan forstås af ikke-programmører [Andersen og Jensen, 2001]. Ud over felterne i figur 4.7 nævner Mortensen et al. [2000] to mere. Det første Input/Output er Mode of action, der beskriver input- og output-parametre for klassens interaktion med omgivelserne. Dette kan f.eks. være i relation til brugeren af den kommende konfigurator. Det andet felt hedder Sources og indeholder informa- Sources tion om de kilder, der har bidraget med information til indholdet af CRC-kortet. Idéen er, at det skal være muligt at spore årsagen til f.eks. begrænsninger og attributter. 45

Kapitel 5 IT-understøttet dokumentation Indhold af dette kapitel 5.1 CASE-værktøjer.................... 48 5.1.1 Introduktion til CASE-værktøjer........... 48 5.1.1.1 Typer af CASE-værktøjer.......... 49 5.1.2 Anvendelse af CASE-værktøjer og metodologier... 51 5.1.2.1 Kommercielle vs. selvgjorte metodologier. 52 5.1.2.2 Modeldrevet udvikling............ 52 5.1.3 CASE-værktøjer og produktmodeller......... 55 5.1.3.1 Funktionalitet i CASE-værktøj....... 56 5.2 PDM-systemer..................... 59 5.2.1 Introduktion til PDM-systemer............ 59 5.2.2 PDM-systemer og produktmodellering........ 60 5.2.2.1 Funktionalitet i PDM-system........ 61 5.2.3 Muligheder og begrænsninger med PDM-systemer. 64 I dette kapitel vil jeg se nærmere på anvendelsen af IT-systemer til understøttelse af dokumentationsprocessen. Gennemgangen vil omfatte CASE-værktøjer, som støtter arbejdet med systemudvikling, og PDM-systemer som anvendes til automatiseret håndtering af produktdata. Viden om CASE-værktøjer er primært hentet fra domænet vedr. udvikling af IT-systemer, hvorimod PDM-systemer anvendes bredt i mange forskellige typer virksomheder. 47

Kapitel 5 - IT-understøttet dokumentation 5.1 CASE-værktøjer I sin umiddelbare betydning dækker Computer Aided Systems Engineering (CASE) over enhver anvendelse af IT i forbindelse med udvikling af informationssystemer. Op igennem tiden har CASE udviklet sig fra at betegne brugen af et simpelt tekstbehandlingsværktøj til at dække over den integrerede anvendelse af IT-baserede værktøjer til støtte for aktiviteter i alle faser af projektlivscyklussen. 5.1.1 Introduktion til CASE-værktøjer Siden 1970 erne er der inden for systemudvikling blevet anvendt forskellige grafiske teknikker og strukturerede diagrammer som en del af dokumentationen. Forud for implementeringen af systemerne er blevet opbygget mere eller mindre integrerede modeller, og strukturerede analyse- og designteknikker har gjort det muligt at håndtere udviklingen af systemer med stigende kompleksitet og stadig bevare overblikket. Men samtidig opstod hurtigt en begrænsning, idet de mange diagrammer og figurer var omstændelige og tidskrævende at vedligeholde og ændre, efterhånden som projektet skred frem. I starten af 1980 erne begyndte man at supplere simple tekstbehandlingsværktøjer med grafiske værktøjer til tegning af diagrammer og værktøjer til at støtte analyse- og designfaserne [Barclay og Padusenko, 2002]. De generelle tekstbehandlings- og tegneværktøjer blev hurtigt afløst af dedikerede værktøjer til de forskellige opgaver, information i simple dokumenter blev afløst af strukturerede databaser, og op gennem 1980 erne og 1990 erne blev udviklet og lanceret værktøjer, der støttede og integrerede udviklingsprocessen fra de tidlige analysefaser over design, kodning og test til ibrugtagning og vedligeholdelse. Således findes der i dag CASE-værktøjer, der støtter op om arbejdet i alle faserne i projektlivscyklussen og integrerer information på tværs af faserne. Krav opsamlet i analysefasen kan på den måde relateres til en given detalje i det endelige system og måden, hvorpå det er blevet testet. I løbet af 1980 erne og starten af 1990 erne blev udviklet et utal af CASEværktøjer med henblik på at understøtte det stadigt stigende antal af fremgangsmåder, der kom på markedet [Bennett et al., 1999]. Populariteten af objektorienteret systemudvikling satte kun yderligere skub i denne udvikling, og selv med anerkendelsen af UML 1 som en fælles notation eksisterer der i dag et meget stort antal af CASE-værktøjer både til at understøtte objektorienterede fremgangsmåder og ikke-objektorienterede (f.eks. Structured Analysis & Design (SA&D) og Information Engineering (IE)). I litteraturen findes mange definitioner på, hvad et CASE-værktøj er, og ingen af dem er særligt smalle. Det skyldes, at CASE-værktøjer dækker over et bredt spekter af IT-baserede værktøjer, som alt afhængig af det præcise anven- 1 I den forbindelse er det vigtigt at understrege, at UML ikke er en metodologi, men en notationsstandard. 48

5.1 CASE-værktøjer delsesområde støtter udviklingsarbejdet på en bestemt måde. CASE ses i litteraturen anvendt både for Computer Aided Systems Engineering og Computer Aided Software Engineering, men indholdet bag begge betegnelser er så sammenfaldende, at jeg i denne rapport har valgt at sidestille dem. Som i Kirkby og Kjærulff [1992] finder jeg også den første betegnelse mest dækkende, da Software kan lede tanken hen på et isoleret, selvstændigt program og ikke et integreret informationssystem. I Hogan [1999] og CMU [2001] anvendes næsten enslydende definitioner, som synes at være dækkende for anvendelsen i denne rapport: [A CASE tool is]... any computer-based product which is aimed at supporting one or more software engineering activities within a software development process. [Hogan, 1999, s. 1] I forlængelse af denne definition har [Kirkby og Kjærulff, 1992] karakteriseret CASE-værktøjer yderligere ved... at de overvejende kommunikerer grafisk med bruge[re]n, og at de på intelligent vis gemmer og behandler information om informationssystemet. [Kirkby og Kjærulff, 1992, s. 31] 5.1.1.1 Typer af CASE-værktøjer Inden for den brede definition har flere forfattere lavet mere præcise definitioner, der opdeler den brede vifte af CASE-værktøjer. CMU [2001] nævner de tre mest almindelige af disse opdelinger, hvoraf de to direkte baseres på CASEværktøjernes anvendelse i projektlivscyklussen. Disse to vil kort blive introduceret her. Upper CASE og Lower CASE I den første af de to skelnes mellem Upper CASE-tools og Lower CASE-tools. Den første kategori dækker over værktøjer, der anvendes i de første faser af projektlivscyklussen (såsom kravspecifikation, analyse og design). Inden for det objektorienterede domæne vil disse værktøjer støtte opgaverne inden for opbygning af bl.a. brugsmønsterdiagrammer, klassediagrammer og sekvensdiagrammer. Med brug af værktøjerne vil det være muligt at automatisere arbejdet og gøre det nemmere at opdatere diagrammerne og sikre, at de er konsistente. F.eks. vil et CASE-værktøj gøre det utroligt nemt at vedligeholde sekvens- og kollaborationsdiagrammer, da de indeholder nøjagtig samme information blot vist på to forskellige måder. I den situation vil et CASE-værktøj automatisk kunne generere det ene diagram ud fra det andet. Den anden kategori dækker over værktøjer, der anvendes i de senere faser i projektlivscyklussen. Typisk vil det være værktøjer til kodegenerering, fejlfinding og testning. Ved at anvende et CASE-værktøj til kodegenerering på baggrund af den opstillede model opnås en kode af høj kvalitet, der for det første er hurtig 49

Kapitel 5 - IT-understøttet dokumentation SCTVUWXNY[Z]\ ^V_ `RYV\ ^V\badcXV^eW flg h^ij klyewm \U\ HJILKNMOLPRQ P nyewuxvyjucel o j^\ j rnrntlž[ ~H LšsŽe v œ tž P]v œnv v tž žltlžvÿÿÿ `]k] ]}~Yel Z]\ Ulxdyzfbfb{V X ocvzfbf WYelxeT cxvy ana[ul YVxV^\ x p qsr[mtrqutniv Kv Q w[i Z\ ^V \ YVjU\ YVi jucvl TV\ YVgVUWUjmNƒ Rk j^v\ j\ Lwb tž HJ ~ [ bš Ž v œr trž P]v œnv v trž~žbtržvÿÿÿ pv trž Kv Qw[I KNIL Ž tl LPRt ]^V\UxelbiVWY\ \ ^e\ Š YelX ad^vjœcvxe\ XV^V Ul^NYejjUgeTj^ \ YelVXNXmVlYadUi SCTVUWXNcVg h^vi j adcxv^ew Z]\ ^Vz\ YjU\ YVi jucvl S TUWXdT\ Ulj^V YVi ^ YVlVX ^V YelXd Rk j^e\ j^v\ jšvt \ YVgVUWUjmbj^V\ j jš cvjcjm ^ trplqˆdi Figur 5.1: Objektorienteret projektlivscyklus, hvor Upper CASE-værktøjer støtter de tidlige faser (lys grå), og Lower CASE-værktøjer støtter de senere faser (mørk grå). Inspireret af Bahrami [1999, s. 44] at producere og også er overskuelig at vedligeholde, da der er tæt sammenhæng mellem den designede systemmodel og den resulterende kode [Hogan, 1999]. Opdeling i Upper- og Lower CASE-værktøjer var helt klar for tidlige CASEværktøjer [Bennett et al., 1999]. Værktøjerne var afgrænsede i deres funktionalitet og indeholdt kun funktionalitet til understøttelse af opgaver inden for en meget begrænset del af projektlivscyklussen (f.eks. tegning af statiske UMLdiagrammer). Op gennem tiden har CASE-værktøjer udviklet sig til at omfatte hele pakker (suiter) af produkter, der er mere integrerede og understøtter aktiviteter i mange (eller alle) af projektets faser. Disse pakker af produkter kaldes Integrated Computer Aided Systems Engineering (I-CASE) og vil ikke kunne placeres entydigt i en kategorisering i Upper og Lower CASE-værktøjer, men snarere dække over begge. Vertikale og horisontale værktøjer Den anden af de to opdelinger skelner mellem vertikale og horisontale værktøjer [CMU, 2001]. Inden for den første gruppe falder værktøjer, der understøtter aktiviteterne i enten en begrænset del af projektlivscyklussen eller inden for et begrænset domæne. Et eksempel kunne være et programmeringsværktøj eller værktøj til indsamling af krav. 50

Ø Ù Ú «ÛNµ ª[µV ª «]Ļ¹ ºz» ¼ ¹ º ½ ¾ ]º ÀÀº]ÁÂÃ Ä Å ÆeǺCÈɼ à ¼ ÀÊz¹ º zël¼]àâ ]º ÁÂÃzÄzÌɺ ¹ É u«ª ]ÍLº ¹CÂÄRÃ È À¼ ¹z¹ º]ÁR½ ÎCÏ Å Ð]ÆzÊzÄ ½ ¾ ]º À Å Ð]ÆzÊzÄ Ñ bò ¾ Ä Ð Á¾CɾzÉ ÊCÐ º ]Ļ CÓÔ]Áɺ ¹ É ±³² «± «µ «~ C J ]ÕRÁ¾CÄ]Á¼C½ ½~ºCÁ ÂÃ Ä ]ÖRÎz¼CÀÂɺeɹ ¹ ÂÈzÁ Âà ÄR ɺ ¹eÉ 5.1 CASE-værktøjer Ü ¾RÁ¹ ¾RÃzɼ ÀÉÝRÞ ßbà ábâlãnä]åæ ç èé êë ì êíîïdï å ð]ñvð îò ó ô õ ö ï ïdå ôzó íö ñ ËbºCÁ ábâlãnä]åæ ç èé É ÂÈV¼]ÀÉLÝLÞbß à õ ø ùeò ö êë ì êíî ù]èûvözô èö]èç ñ íñ ö ñ ð ú óeô úîð ô Figur 5.2: Gantt-kort med eksempler på vertikale og horisontale CASE-værktøjer. Vertikale støtter et snævert område, mens horisontale understøtter aktiviteter i flere faser eller domæner Horisontale CASE-værktøjer er værktøjer, der breder sig ud over et større område og understøtter aktiviteter i flere faser af projektlivscyklussen eller i flere domæner. Eksempler herpå kunne være dokumentationsværktøjer eller værktøjer til håndtering af ændringer. Kravene til henholdsvis et vertikalt og horisontalt CASE-værktøj vil derfor være meget forskellige. Ses på brugerne af f.eks. et vertikalt værktøj, vil de typisk have en meget ens profil bl.a. begrænset af deres faglige domæne. Brugerne af et horisontalt værktøj vil derimod være spredt over flere faglige domæner (analytikere, programmører, projektledere osv.) og dermed stille flere krav til, hvordan værktøjet skal virke for at kunne hjælpe dem i deres arbejde med projektet. 5.1.2 Anvendelse af CASE-værktøjer og metodologier Mange virksomheder har anerkendt fordelen ved at anvende en metodologi til systemudvikling. I forbindelse med systemudvikling har Whitten et al. [2001] defineret en metodologi som... A very formal and precise system development process that defines [... ] a set of activities, methods, best practices, deliverables, and automated tools... [Whitten et al., 2001] Ved at lægge systemudviklingen i faste rammer med anvendelsen af en metodologi opnår man, at der bruges en konsistent og gentagelig fremgangsmåde på alle projekter men det kræver naturligvis, at metodologien er gennemarbejdet, af høj kvalitet og anvendelig i den givne situation. På den måde kan en metodologi sammenlignes med en værktøjskasse, hvor man har samlet de bedste 51

Kapitel 5 - IT-understøttet dokumentation værktøjer til opgaven og samtidig vedlagt en grundig beskrivelse af, hvordan og i hvilken rækkefølge de skal bruges. At anvende en metodologi er således også en konsekvens af ønsket om at undgå at opfinde hjulet endnu engang. Synergieffekten af at anvende et CASE-værktøj i samspil med en metodologi har gjort, at kombinationen anvendes i velsagtens alle virksomheder, hvor der arbejdes seriøst med udvikling af informationssystemer. Men ifølge en undersøgelse fra IBM [Guinan et al., 1997] er samspillet også en nødvendighed. Undersøgelsen viste bl.a. at... for teams with well-structured processes, use of tools enhanced the process and improved performance, men lige så vigtigt at For teams with more informal or ad hoc processes, tool use abetted chaos. Anvendelsen af CASE-værktøjer alene er således ikke en silver bullet, men anvendelsen af CASE-værktøjer som støtte til i forvejen formelle og strukturerede fremgangsmåder gav ifølge undersøgelsen en forbedring i effektiviteten på op til 50%. 5.1.2.1 Kommercielle vs. selvgjorte metodologier Metodologier kan være mere eller mindre omfattende og kan enten være selvgjorte (baseret på en virksomheds erfaringer gennem årene) eller rent kommercielle, hvor en virksomhed som sin kernekompetence designer metodologier baseret på forskning og erfaringer. Et eksempel på det sidste er Rational Unified Process (RUP) fra Rational Software, som er beregnet på objektorienteret systemudvikling [Kruchten, 1998]. RUP består i sin essens blot af en beskrivelse af den designede proces til udvikling af informationssystemer. Arkitekturen bag RUP beskriver og støtter udviklingsprocessen i to dimensioner; i forhold til organisationen og i forhold til tiden (projektlivscyklussen), men lægger kraftigt op til, at man tilpasser metodologien til den enkelte situation. RUP er samtidig et eksempel på en metodologi, som er fuldstændigt understøttet af og integreret med et CASE-værktøj (Rational Suite Enterprise). På trods af den høje pris på kommercielle metodologier vælger mange virksomheder ofte at købe en kommerciel metodologi frem for at udvikle deres egen [Whitten et al., 2001]. For selv om prisen kan være høj, er det oftest billigere end at skulle afsætte personale til at udvikle virksomhedens egen metodologi, og ved at købe en kommerciel metodologi skal man ikke selv vente på at høste erfaringerne fra udviklingsarbejdet og tilpasse metodologien. Herudover er en af de helt store fordele, at kommercielle metodologier ofte er understøttet af eksisterende CASE-værktøjer, som det f.eks. er tilfældet med førnævnte RUP. 5.1.2.2 Modeldrevet udvikling Det er de færreste mennesker, der har overblik og indsigt til at kunne håndtere udviklingen af selv et mindre informationssystem. Og selv hvis én person kunne overskue systemet og alle detaljerne, så ville det være svært for vedkommende at dele denne viden med de andre personer, der var tilknyttet udviklingen. 52

5.1 CASE-værktøjer Det er et par af årsagerne til, at den mest almindelige måde at gribe udviklingsopgaven an på er at opbygge modeller forud for den egentlige opbygning og dermed drive projektet frem baseret på modellerne. Man taler da om modeldrevet udvikling. Whitten et al. [2001] beskriver det således Model-driven development (MDD) techniques emphasize the drawing of models to help visualize and analyze problems, define business requirements, and design information systems. [Whitten et al., 2001] og knytter et par kommentarer til projektlivscyklussen for modeldrevet udvikling, som har relevans for produktmodellering [Whitten et al., 2001, s. 94ff]: - Størstedelen af arbejdet placeres i de tidlige faser af projektet med henblik på at skabe et solidt fundament forud for det videre arbejde. Baggrunden for dette er, at projekter har en tendens til enten at være store eller hurtigt blive det, og med anvendelse af selv simple systemmodeller kan projektets omfang visualiseres. I relation til produktmodellering svarer det til at anerkende vigtigheden af at få opbygget en god model af produktet startende med en grundig opbygning af PVM en. Med basis i modellen opnås overblik over produktet med hensyn til bl.a. strukturel opbygning og variantskabelse, hvilket er essentielt for den senere implementering i en konfigurator. - I de fleste modeldrevne metoder lægges op til, at kravene dokumenteres i en logisk model; dvs. en model der er uafhængig af den endelige implementering. Inden for produktmodellering sker dette ved, at produktet modelleres i PVM og siden hen i klassediagrammet vha. UML-notationen. Med denne dokumentation kan produktmodellen i princippet implementeres i en vilkårlig konfigurator 2. Fordele ved modeldrevet udvikling Som en konsekvens af anvendelsen af modeldrevet udvikling er resultatet af hver fase i projektlivscyklussen, at der produceres systemmodeller, som siden hen fungerer som dokumentation for implementeringen. Generelt resulterer det i, at kravanalysen bliver mere tilbundsgående og bedre dokumenteret. I relation til produktmodellering svarer det til, at produktet bliver bedre gennemanalyseret, og f.eks. alle varianter afdækkes og dokumenteres. En anden fordel er, at modeller kan fungere som et fælles sprog. Inden for udvikling af informationssystemer eksisterer en stor barriere imellem de personer, der ved, hvad systemet skal kunne, og de personer, der kan implementere det. 2 Dog skal der ved modelleringen tages hensyn til, om konfiguratoren er objektorienteret eller konventionel. 53

Kapitel 5 - IT-understøttet dokumentation Til at udfylde dette gab bruger systemanalytikere (business- eller systemanalysts) modeller til at visualisere de indsamlede krav: Over for brugerne for at verificere deres udsagn og over for udviklerne for at beskrive kravene. På sin vis er anvendelsen af modeldrevet udvikling således helt i tråd med det gamle mundheld om, at et billede kan sige mere end tusinde ord. Et eksempel er anvendelsen af brugsmønsterdiagrammer til at beskrive forskellige brugergruppers interaktion med (dele af) systemet (se figur 5.3). ÿ ü ý þ ÿ ü ý þ ÿ eÿ þ ÿ ü ÿ ÿ þ þ ÿ]ÿ þ ÿ ÿ þ ÿ Figur 5.3: Eksempel på anvendelse af modeller som et fælles sprog: Et brugsmønsterdiagram i UML-notation Ud over at virke som et fælles sprog iblandt projektets medlemmer vil anvendelse af en given modeldrevet fremgangsmåde også ensarte den anvendte dokumentation. Hvis en virksomhed beslutter at anvende en bestemt fremgangsmåde (f.eks. en modeldrevet som RUP), der lægger op til en given notation (her UML), opnår man den fordel, at alle i virksomheden kender fremgangsmåden og den anvendte notation. Det vil således være relativt let for alle medarbejdere at sætte sig ind i et andet projekt og forstå dokumentationen. En yderligere fordel er, at eksisterende løsninger vil kunne bruges mere direkte i et nyt projekt, da dokumentationen er den samme. I forbindelse med produktmodellering trækkes også på anvendelsen af modeller som fælles sprog, især med anvendelsen af PVM en i de tidlige faser af projektlivscyklussen. Som nævnt i 4.3.1 på side 40 er en af de væsentligste fordele ved brugen af en PVM, at både domæneeksperter og udviklere kan forstå indholdet af diagrammet og dermed strukturen af produktet. Endnu en fordel ved modeldrevet udvikling, som skal nævnes her, er den basale egenskab hos en model til at fastholde information. Varigheden af et projekt har en tendens til at vokse i takt med projektets størrelse, og information indsamlet i projektets start er derfor nemt glemt senere i projektet især hvis det kun eksisterer som tykke dokumenter. Ved at bruge modeller som dokumentation lettes overblikket, og information fastholdes under hele projektet. Med modeller som dokumentation er det tilsvarende nemt for alle medlemmer af projektet (og lige så vigtigt: for nytilkomne) til enhver tid at danne sig et overblik, finde det rette sted og finde relevante detaljer frem. 54

5.1 CASE-værktøjer Ulemper ved modeldrevet udvikling Desværre vokser træerne ikke ind i himlen, og anvendelse af modeldrevet udvikling har også nogle ulemper, der ikke bør negligeres. For det første vil der i de fleste tilfælde gå længere tid, før det er muligt at se konkrete resultater. Som nævnt i afsnit 5.1.2.2 på side 52 lægges en stor del af arbejdet i de tidlige analyse- og designfaser med henblik på at indsamle og analysere al nødvendig viden forud for implementeringen. Formålet er naturligvis at implementere systemet korrekt første gang og undgå fordyrende ændringer og omfattende rettelser, men nogle personer har svært ved at forestille sig det kommende system, når man kun har en model at gå ud fra [Whitten et al., 2001]. Det svarer til, at bygherren ikke kan forestille sig den endelige bygning ud fra arkitektens tegninger. Som konsekvens heraf opbygges ofte flere prototyper igennem projektet, hvormed man kan teste forskellige aspekter af det endelige system (f.eks. placering af knapper mv., svartider på databaseforespørgsler osv.). Det svarer til, at arkitekten laver papmodeller af den kommende bygning som supplement til tegningerne. En af grundstenene i objektorienteret systemudvikling er af samme grund iteration og anvendelse af prototyper (se figur 5.1 på side 50). Resultatet af det øgede fokus på analyse- og designfaserne er, at det umiddelbart kan virke, som om projektet tager længere tid, end hvis man blot lavede en quick n dirty løsning. Resultatet af ikke at tage analyseopgaven alvorligt har dog mere hårdtslående konsekvenser, idet et mangelfuldt forarbejde meget ofte betyder, at uventede ændringer dukker op og fordyrer samt forlænger projektet. Ændringer, som med en større indsats i de tidlige faser kunne være opdaget og medtaget fra starten. Det er en klassisk faldgrube, som mange virksomheder gør et bekosteligt bekendtskab med, idet det man får meget større udbytte pr. krone ved at bruge den i starten af projektet end i slutningen [Schwalbe, 2000, s. 145f]. 5.1.3 CASE-værktøjer og produktmodeller Som det fremgår af teorien bag produktmodellering (se kapitel 4 på side 33) anvendes inden for produktmodellering mange af de samme metoder og teknikker som inden for objektorienteret udvikling af IT-systemer. Erfaringer med arbejdet har vist, at dokumentationen, som er kraftigt inspireret af UML, fungerer godt og udgør en konsistent dokumentation. Erfaringerne viser dog også, at dokumentationsarbejdet er omstændeligt og udgør en stor del af den samlede arbejdsindsats og derfor med fordel kan støttes af en IT-system (se afsnit 4.2 på side 38). Inden for udvikling af IT-systemer bruges i vid udstrækning CASE-værktøjer til at automatisere og understøtte arbejdet, og med den store lighed vil det være oplagt at trække på de samme erfaringer, som CASE-værktøjernes udvikling er manifestationen af. 55

Kapitel 5 - IT-understøttet dokumentation 5.1.3.1 Funktionalitet i CASE-værktøj Bennett et al. har lavet en gennemgang af, hvorledes et moderne I-CASEværktøj understøtter aktiviteterne i projektlivscyklussen med opdeling i to overordnede kategorier: diagrammer og programmelkonstruktion [Bennett et al., 1999, s. 56ff]. Mange af dem er direkte relevante for produktmodelleringsdomænet, og som oplæg til den videre analyse af kravene til et kommende dokumentationsværktøj vil jeg nedenfor gennemgå punkterne og relatere dem til produktmodellering. Diagrammer En stor del af en systemmodel består i de fleste tilfælde af diagrammer uanset valg af metodologi. Det er der ikke noget nyt i, men med muligheden for at oprette, redigere og sammenkoble diagrammer på en computer opnås så store fordele, at ethvert moderne CASE-værktøj indeholder funktionalitet til at understøtte denne opgave. Funktionaliteten dækker Syntaktisk korrekthed Baseret på syntaksen for de enkelte diagrammer sørger CASE-værktøjet for, at kun lovlige symboler bruges, og at de sammenkædes på en lovlig måde. Dette garanterer dog ikke, at indholdet af diagrammet giver mening og afspejler det ønskede. Et CASE-værktøj til produktmodellering bør således sørge for, at de rigtige streger og symboler tegnes, når der i PVM en tilføjes en underklasse til en eksisterende klasse. Dataleksikon Med et stort komplekst system og mange involverede medarbejdere er der behov for at have et samlet sted, hvor man én gang for alle definerer nøglebegreber for systemet. Behovet kan være lige stort, hvad enten der er tale om simple attributter eller mere uhåndgribelige begreber, da tvetydighed hurtigt leder til fejl. I forbindelse med produktmodellering er det vigtigt at have en utvetydig definition og beskrivelse af elementerne (f.eks. klasser og attributter). Ofte har elementerne kryptiske navne, som det kan være svært at huske, og med en voksende model med flere medarbejdere tilknyttet vil et dataleksikon forbedre overblikket og dermed arbejdet markant. Konsistens og fuldstændighed Mange metodologier understøtter muligheden for at bruge forskellige diagrammer til at vise forskellige aspekter af (dele af) systemet, og samtidig kræver nogle metodologier, at visse diagrammer skal eksistere og være fuldt dokumenterede. Et eksempel er anvendelsen af kollaboration- og sekvensdiagrammer i UML, ligesom IDEF0 foreskriver visse regler, f.eks. ICOM-reglerne 3. I et sådant tilfælde bør et CASE-værktøj kunne sikre, at diagrammerne er konsistente og veldokumenterede (i dataleksikonet). I modsat fald bør værktøjet kunne generere en rapport med angivelse af manglerne. Inden for produktmodellering bør det i denne sammenhæng overvejes, hvorledes PVM og klassediagram skal kobles i et CASE-værktøj, ligesom det 3 ICOM står for Input-Control-Output-Mechanism, og reglerne foreskriver kort fortalt, at alle Input s, Control s, Mechanism s og Output s, der går ind eller ud af en aktivitet skal bruges på den underliggende detaljering. Læs mere i CSL-NIST [1993] 56

5.1 CASE-værktøjer kan overvejes at lade CASE-værktøjet sikre konsistensen mellem CRC-kort og det tilhørende diagram (PVM eller klassediagram). Navigation i koblede diagrammer Des mere komplekse systemerne og dermed også modellerne bliver, des mere nødvendigt er det at sikre en simpel navigation imellem diagrammerne og nem adgang til relevante data. Ved f.eks. at dobbeltklikke på et diagram på et givet abstraktionsniveau kan CASEværktøjet automatisk åbne det underliggende, mere detaljerede diagram eller alternativt oprette et. For produktmodellering gælder de samme betragtninger som for punktet ovenfor, da der kun anvendes relativt få diagrammer. Det kunne dog overvejes, hvordan navigationen kan lettes ved f.eks. at se på koblingen mellem et diagram og de tilhørende CRC-kort. Ligeledes kan det med fordel vurderes, hvorledes eksterne dokumenter skal kobles til dokumentationen i produktmodellen. Lagdeling For at lette arbejdet med store komplekse systemer lægger mange metoder op til anvendelse af lagdeling. Et eksempel på lagdeling er, at man kan arbejde med diagrammer på forskellige detaljerings- eller abstraktionsniveauer præcis som der findes landkort i forskellig målestok. IDEF0 er f.eks. bygget op omkring denne filosofi. Et CASE-værktøj bør understøtte anvendelse af denne lagdeling og gøre det let at navigere mellem de forskellige lag. Inden for produktmodellering benytter man sig p.t. ikke af lagdeling, men det bør alligevel vurderes, hvorvidt man med anvendelse af et CASE-værktøj får automatiseret processerne og dermed åbner op for nye muligheder, så anvendelse af forskellige lag kunne blive interessante. Sporbarhed For at lette arbejdet med udviklingen og især vedligeholdelsen af systemet skal det være muligt at spore krav fra analysedokumentationen, gennem designdokumentationen og frem til den endelige kode. Hvis et krav ændrer sig, vil det dermed være let at finde frem til den kode, der er berørt af ændringerne. Kravene i forbindelse med opbygning af en produktmodel dokumenteres i PVM en, og sporbarhed i den sammenhæng vil da bestå i at kunne spore strukturen og indholdet af PVM en over klassediagram (med CRC-kort) til den endelige implementering i en konfigurator. Ofte sker ændringer på produktniveau (en variant udgår, eller en komponent bliver redesignet), og med sporbarhed i produktmodellen bliver det nemmere at ændre design og implementering, så valgmulighederne i konfiguratoren afspejler produktændringen. Det bør derfor overvejes, hvorledes CASE-værktøjet skal give mulighed for sporbarhed, hvilket indebærer overvejelser om, hvordan elementerne i dokumentationen skal sammenkobles. Rapportgenerering Des mere komplekst et system bliver, des mere information indeholder det. Det vil ikke give mening at bruge tid på at opsamle informationen og lagre det i et CASE-værktøj, hvis det ikke var tilsvarende nemt at trække informationen ud igen. Et CASE-værktøj har derfor ofte fleksible muligheder for at hente information fra modellen på tværs af elementer og i et format, som det er muligt for brugeren at tilpasse. Om det er udvikling af IT-systemer 57

Kapitel 5 - IT-understøttet dokumentation eller produktmodeller gør ingen forskel, og det bør derfor overvejes, hvordan et kommende dokumentationsværktøj skal kunne udskrive rapporter med den ønskede information på baggrund af produktmodellen. Herudover kan vurderes, hvilken information der skal kunne trækkes på, og i hvilket format informationen skal vises. I den forbindelse kan også overvejes, hvordan rapportgenereringen skal kunne tilpasses den enkelte bruger, både med hensyn til indhold og format. Systemsimulering Når modellen (eller dele heraf) er blevet opbygget, bør det være muligt at kunne simulere, hvordan systemet vil opføre sig inden for nogle begrænsede områder. På den måde kan man som designer få et indtryk af konsekvenserne af sit arbejde uden først at skulle skrive koden. Et eksempel på dette kunne være et virtuelt gennemløb af en tilstandsmaskine baseret på et tilstandsdiagram og valg af attributværdier. I forbindelse med produktmodellering er der tilsyneladende ikke gjort mange tanker om anvendelse af simulering, men da konfiguratorer er så grundlæggende forskelligt opbygget, bør det undersøges, om valget af konfigurator har indflydelse på forløbet af en simulering. Om simulering er anvendelig inden for produktmodellering, vil derudover kræve en dybere analyse af behovet, resultatet og dokumentationens karakter. Diagrammerne skal være entydige og mulige at fortolke for en computer. Ydelsesanalyse Ydelsen af et system vil i mange tilfælde være afgørende for vurderingen af systemets succes. At kunne vurdere ydelsesevnen og konsekvenserne af forskellige (designmæssige) ændringer er derfor en stærk funktionalitet, som nogle CASE-værktøjer understøtter. F.eks. kan det være muligt at lave hvad-hvis... -analyser for at undersøge forskellige alternativer. Produktkonfiguratorer er meget forskellige i deres opbygning, og de adskiller sig også fra hinanden i, hvorledes den endelige konfigurator kompileres. Det vil derfor være svært at vurdere ydelsesevnen baseret på produktmodellen alene, og en ydelsesanalyse vil derfor næppe være anvendelig i et dokumentationsværktøj for produktmodellering. Programmelkonstruktion Flere og flere CASE-værktøjer understøtter muligheden for at automatisere og integrere overgangen mellem designfasen og implementeringsfasen og dermed højne kvaliteten af implementeringen og gøre arbejdet lettere. Bennett et al. fremhæver følgende to punkter. Kodegeneratorer Med en kodegenerator bliver det for det første nemmere og hurtigere at producere fungerende (del)systemer, og for det andet er koden mere fejlfri og i overensstemmelse med designet. Herudover bliver det nemmere at implementere ændringer, idet et ændret design nemt kan overføres til fungerende kode. Der er næppe to produktkonfiguratorer, som anvender samme sprog til implementering hverken i deres underliggende produktmodel eller i bindinger. Derfor synes det umiddelbart som en omfattende opgave at understøtte kodegenerering til markedets konfiguratorer, men potentialet og fordelen er så stor, at det bør undersøges, hvorledes man kan udnytte funktionaliteten, måske med anvendelse af et neutralt mellemliggende filformat. 58

5.2 PDM-systemer Vedligeholdelsesfunktioner Mange CASE-værktøjer understøtter også faserne efter implementeringen af systemet. Som en af de primære funktionaliteter nævnes reverse engineering, hvor værktøjet kan opbygge en model baseret på eksisterende kode. Dette kunne umiddelbart være en værdifuld egenskab for et kommende dokumentationsværktøj, men som nævnt ovenfor er de anvendte sprog i konfiguratorerne meget forskellige, og at understøtte f.eks. reverse engineering for et bredt udvalg af konfiguratorer vil derfor givetvis være en stor opgave. 5.2 PDM-systemer Arbejdet med udvikling og vedligeholdelse af produkter indebærer håndtering af utrolige mængder information og opretholdelse af mange forretningsgange. Denne erkendelse er i sig selv ikke ny, men først med tilgængeligheden af kraftige computere er man for alvor begyndt at anvende informationssystemer til at understøtte og automatisere processerne og håndtere adgangen til informationen. 5.2.1 Introduktion til PDM-systemer Så længe der har eksisteret virksomheder, der har udviklet produkter, har der eksisteret et behov for at kunne styre de relaterede processer og de mange informationer, som knyttes til produktet. Begrebet kaldes PDM og er sammen med PDM-systemer defineret i CIMdata [1997] som... a tool that help engineers and others manage both data and the product development process. PDM systems keep track of the masses of data and information required to design, manufacture or build, and then support and maintain products. [CIMdata, 1997, s. 2] Tidlige PDM-systemer (IBM- og VAX-baserede legacy systems fra 1970 erne) var sjældent mere end centrale dokumentarkiver eller varelister. I nogle tilfælde blev produktstrukturer også understøttet, men systemerne var ikke fokuseret på at skulle integreres med virksomhedens andre informationssystemer [Pikosz, 1997]. Kravene til en kortere time-to-market og forbrugernes ønske om unikke varianter har øget virksomhedernes interesse for PDM-systemer og sat mere gang i udviklingen [Pikosz, 1997, s. 1]. Som det fremgår af definitionen, udgør brugerne af et PDM-system en broget skare bestående af alle de personer, der har noget med produktet at gøre, og PDM-systemer understøtter heller ikke kun arbejdet i udviklingsfasen, men arbejdet i alle faserne af produktets livscyklus. Under arbejdet med et produkt genereres en stor mængde information af meget forskellig karakter. Det kan f.eks. være kravspecifikationer, CAD-tegninger, testog analyseresultater eller styklister. Informationen findes i dag (i modsætning til tidligere) typisk på digital form, men i mange forskellige formater (ren tekst, CAD, regneark, billeder etc.). Behovet for at anvende informationen går på tværs 59

Kapitel 5 - IT-understøttet dokumentation 0.11$+ / 2" " / ')$%#* 34* 5 67 8 5"6"9(: ; < = >? @ : = A > B C(D < E F E ; A <(D E G H I,JKL #* 3$4* M A N O > D P P ; Q D(F < = N D F < R D < = D P O D O A CN S = D N TU V W XY Z[ V \ ZU ] ^ _ ^ ` a b c d b e _ f b a ] ^ _ ^ ` a b c "! " $#$ "% ] ^ _ ^ ` a b c &(') * ',+ + * "!.- / + * Figur 5.4: Funktionel struktur af PDM-system [CIMdata, 1997, s. 7] af arbejdsgrupper og organisatoriske opdelinger, og grundidéen bag et PDMsystem er at knytte alle disse dokumenter sammen og give brugerne mulighed for at genfinde dokumenterne. Strukturen er skitseret i figur 5.4. Af figuren fremgår det, at der i PDM-systemet indgår en metadatabase. Metadata er data om data, og i et PDM-system er der til hver ressource knyttet en række informationsfelter indeholdende f.eks. forfatter, titel, ændringsdato, beskrivelse, filnavn, filformat osv., og det er på baggrund af disse data, brugerne finder frem til dokumenterne. Et PDM-system gemmer således to typer data: produktdata, genereret af de forskellige applikationer (CAD-systemer, tekstbehandling etc.), og metadata, som håndteres direkte af PDM-systemet selv [CIMdata, 1997, s. 8]. PDM-systemet systematiserer adgangen til og håndteringen af produktdata, og når en bruger ønsker at tilgå et givet dokument, bruger PDM-systemet dokumentets metadata til at bestemme typen af dokumentet. På baggrund af typen beder PDM-systemet en passende applikation om at åbne dokumentet for brugeren. Således er et PDM-system også fleksibelt mht. hvilken hardware og hvilke operativsystemer, der anvendes. 5.2.2 PDM-systemer og produktmodellering I modsætning til tidlige PDM-systemer er et af de centrale krav til et moderne PDM-system, at det kan håndtere produktstrukturer. Denne funktionalitet giver mulighed for at overskue, hvordan et produkt er sammensat af forskellige komponenter, og hvordan der kan eksistere forskellige varianter af komponenterne, som dermed skaber varianter af produktet. For hver komponent skal systemet endvidere kunne styre historikken og håndtere revisioner. Især denne funktionalitet gør PDM-systemer interessante i relation til produktmodellering, da en sådan produktstruktur har mange ligheder med PVM en fra 60

g g g g g g g g g g 5.2 PDM-systemer produktmodellering (se afsnit 4.3.1 på side 40). CIMdata har lavet en oversigt over, hvilken funktionalitet et PDM-system bør have for at kunne understøtte enhver produktudviklingsproces [CIMdata, 1997]. Som optakt til den efterfølgende analyse vil jeg i det følgende gennemgå disse punkter med henblik på at relatere dem til produktmodellering og kravene til et kommende dokumentationsværktøj. 5.2.2.1 Funktionalitet i PDM-system Funktionaliteten i et PDM-system er i CIMdata [1997, s. 8] opdelt i to overordnede grupper som vist i 5.5. Brugerfunktionerne dækker den funktionalitet, som udgør brugergrænsefladen til PDM-systemet. Systemfunktionerne dækker over alle de opgaver, der udføres under overfladen, og de fungerer derved som støttefunktioner for brugerfunktionerne og muliggør integration til eksterne systemer. PDM-system Brugerfunktioner Styring og kontrol af database Styring af processer og arbejdsgange Styring af produktstruktur Klassifikation Programstyring Systemfunktioner Kommunikation og notifikation Transport af data Konvertering af data Illustrationsservice Systemadministration Eksterne systemer Filsystemer, brugerapplikationer, ERP-systemer etc. Figur 5.5: Opdeling af funktionaliteten i brugerfunktioner og systemfunktioner Brugerfunktioner Styring og kontrol af database Den elektroniske bankboks (eng.: data vault) indeholder enten selve dokumenterne eller information om, hvor de findes. I begge tilfælde vedligeholdes metadata for hvert dokument baseret på håndteringen af dokumentet. For dokumenter i den elektroniske bankboks ydes en høj sikkerhed, og systemet kan styre, hvem der har adgang til hvilke dokumenter. Disse dokumenter kan ikke tilgås uden om PDM-systemet. I relation til produktmodellering kan adgangsstyringen være essentiel for at sikre mod fejl, og at kun de rette personer kan ændre i modellen. Ved at lade håndteringen af filerne ske gennem systemet kan også laves en omfattende logning af aktiviteterne (ændringer mv.), som kan være central for dokumentationen. Sikkerhedsaspektet i at gemme dokumenter i en elektronisk boks kan måske i nogle tilfælde være af interesse. Styring af processer og arbejdsgange Ud over at være et stærkt, men passivt dokumenthåndteringsværktøj kan et PDM-system også være interaktivt og agere baseret på foruddefinerede processer og arbejdsgange. Inden for produktmodellering er dette næppe essentielt, men kunne alligevel være interessant, f.eks. i forbindelse med en godkendelse af et design eller en ændring, hvor der findes en defineret sekvens af gennemsyn og nødvendige godkendelser. 61

Kapitel 5 - IT-understøttet dokumentation Styring af produktstruktur For at give et overblik over den komplicerede sammensætning af et produkt kan et PDM-system understøtte konfiguration af produkter samt styring af styklister. Med nedbrydning af et produkt i eksempelvis undersamlinger, moduler og komponenter opnås et godt indblik i produktstrukturen, som kan styrkes af en grafisk visning af strukturen i stil med en PVM. Synsvinklen på produktstrukturerne kan ofte ændres, så strukturen vises med fokus på forskellige fagligheder (f.eks. produktion, konfiguration, vedligeholdelse, pakning etc.). Til hvert objekt i produktstrukturen kan knyttes relevante dokumenter fra PDM-systemet, og det er dermed let at finde al relevant information for et givet objekt. Denne funktionalitet er helt essentiel for et dokumentationsværktøj til produktmodellering og kan være til stor inspiration for arbejdet med PVM en og klassediagrammet, hvis ikke overføres næsten direkte. Klassifikation For at forbedre søgefaciliteterne og mulighederne for at genfinde information kan man ofte i et PDM-system klassificere standardobjekter (produktdele, processer og anden information). Med kategoriseringen kan man sammenkæde relaterede objekter, og der lægges således op til mere genbrug og muligheden for oprettelse af et bibliotek. Klassificeringen af ensartede objekter er helt i tråd med den objektorienterede tankegang bag produktmodelleringen nævnt i kapitel 3 på side 19. Sammen med andre objektorienterede aspekter skal klassificeringen inddrages i overvejelserne om, hvorledes en grundlæggende objektorienteret produktmodel skal udformes og siden hen implementeres i en database. Programstyring Program skal i denne sammenhæng forstås som en plan for et antal handlinger, der leder mod et defineret mål, og med denne funktionalitet lægges op til, at et PDM-system skal understøtte visse projektstyringsopgaver (f.eks. nedbrydning af processerne i en Work Breakdown Structure (WBS) og ressourcestyring). I forbindelse med produktmodellering er der naturligvis behov for styring af projektet som helhed, men til denne opgave findes utrolig stærke dedikerede værktøjer som f.eks. Primaveras SureTrak og Microsofts Project 4. Systemfunktioner Kommunikation og notifikation Med e-mail kan brugerne af et PDM-system bindes endnu tættere sammen på tværs af deres geografiske placering. Et kommunikationsmodul kan konfigureres til at give besked om f.eks. vigtige hændelser, eller når der er behov for handling. Forskellige hændelser kan sættes til at igangsætte udsendelsen af en meddelelse automatisk (f.eks. om at en ny version af et dokument netop er tilgængeligt). I produktmodelleringssammenhæng kan dette være utroligt anvendeligt, da arbejdsprocessen er præget af, at flere personer arbejder sammen og er afhængige af hinandens arbejde. Ved at kunne integrere produktmodelleringsarbejdet med kommunikation og notifikation kan spares meget ventetid og usikkerhed. 4 Se http://www.primavera.com/products/sure.html og http://www.microsoft.com/ office/project/default.asp. 62

5.2 PDM-systemer Transport af data Eftersom adgangen til al data går gennem PDM-systemet, behøver brugeren ikke bekymre sig om placeringen af de enkelte filer. Navngivning af filer behøver dermed heller ikke at ske i overensstemmelse med det pågældende filsystem, og man kan således benytte vilkårlige navne. Med operativsystemer som f.eks. hele Windows-familien er navngivningen dog ikke længere et problem, og generelt er placering af filer ikke det store problem med integrationen af netværksressourcer i nutidens brugervenlige operativsystemer. Efterhånden som projekter vokser til en vis størrelse, kan det dog være gavnligt kun at have ét centralt sted (omend i virtuel form), hvor alle relevante data kan findes, og i forbindelse med produktmodellering bør det derfor overvejes, hvor data er placeret, og hvordan de kan tilgås af systemet. Konvertering af data Data findes i et utal af formater, og ofte er det nødvendigt at kunne konvertere data fra et format til et andet for at kunne anvende den samme information i flere applikationer. Med et PDM-system kan systemadministratoren foruddefinere, hvilke konverteringsprogrammer der skal bruges til at konvertere mellem to formater; det skal brugeren ikke bekymre sig om. Konverteringsprogrammerne er ikke nødvendigvis en integreret del af PDM-systemet, men da PDM-systemet kender formatet (fra metadataene), kan et eksternt program kaldes. I forbindelse med dokumentationsarbejdet inden for produktmodellering arbejdes ikke med et større antal dataformater, og meget af informationen vil blive genereret og anvendt internt i systemet. Det er derfor umiddelbart tvivlsomt, om det kan svare sig at understøtte automatisering af konverteringsarbejdet. Til gengæld kan det overvejes, hvorledes informationen i systemet kan udveksles med eksterne systemer. Illustrationsservice Generelt bliver billeddata håndteret på samme måde som al andet data i et PDM-system. Men nogle systemer understøtter udveksling af data som billeder uanfægtet deres originale format (f.eks. CAD-tegninger og lign.). På den måde kan ledere og andre ikke-tekniske medarbejdere deltage i gennemsyn og vurdering af design på samme måde, som havde de fået tegningen på papir. I nogle systemer kan man desuden tilføje kommentarer med en virtuel tusch, og det er på den måde nemt at få kommentarer fra alle relevante deltagere i processen. Under arbejdet med produktmodellering udveksles mange kommentarer til forskellige designforslag, og især PVM en fungerer som et centralt kommunikationsmedium på papir. Anvendelsen af et virtuelt papir som nævnt her kunne derfor være interessant at overveje. Systemadministration Intet PDM-system kan tages i brug med det samme, men skal først tilpasses den enkelte virksomheds brug. I administrationsmodulet kan systemet konfigureres, brugeradgang styres, og datasikkerheden holdes i top. Ethvert informationssystem har brug for et administrationsmodul, hvor systemet kan tilpasses situation og konfigureres, og et dokumentationsværktøj for produktmodellering vil ikke være nogen undtagelse. Det skal i den sammenhæng overvejes, hvordan systemet skal opbygges i relation til fremtidige udvidelser og opdateringer, og på hvilke områder det skal være muligt at tilpasse systemet til situationen. Graden af fleksibilitet vil være en afvejning af, 63

Kapitel 5 - IT-understøttet dokumentation hvad der skal kodes direkte ind i systemet (ofte nemmere at implementere, men svært at vedligeholde), og hvad der skal være mere modulært opbygget (sværere at implementere, men nemmere at vedligeholde). 5.2.3 Muligheder og begrænsninger med PDM-systemer Som det fremgår af ovenstående gennemgang af funktionaliteten i PDM-systemer og relationen til et kommende dokumentationsværktøj for produktmodellering, er der mange ligheder. Det vil derfor være relevant forud for arbejdet med opbygningen af en kravspecifikation for et sådant værktøj at se på, hvilke muligheder og begrænsninger der er ved at anvende et PDM-system i produktudviklingsprocessen. Pikosz og Malmqvist har som del af et forstudie til et større forskningsprojekt med henblik på en reduktion af produktudviklingstiden undersøgt, hvilke muligheder og begrænsninger der er ved anvendelse af PDM-systemer i produktudviklingsprocessen [Pikosz og Malmqvist, 1996]. Udgangspunktet er at forbedre kommunikationen blandt de involverede medarbejdere, hvilket ofte kaldes integreret problemløsning [Clark og Fujimoto, 1991, citeret i Pikosz og Malmqvist [1996]]. For at definere den interne integration (og dermed kommunikationen) beskrives integrationen ud fra fem dimensioner. Disse er vist i 5.6 med angivelse af deres respektive ekstremer. Pikosz og Malmqvist har beskrevet PDM-systemer i forhold til hver af de fem dimensioner, og i figur 5.6 har jeg opsummeret resultatet ved at markere PDM-systemers score på de fem skalaer (mørk trekant). Sekventiel (faseopdelt) Rækkefølge af aktiviteter Overlappende (samtidig) Dokumenter, IT-netværk Grupperet (samling af data) Unilateral (envejs) Informationsrigdom Frekvens af informationsoverførsel Kommunikationsretning Ansigt til ansigt (høj båndbredde) Fragmenteret (stykke for stykke) Bilateral (feedback) Sen lancering af komplet information Timing af informationsflow Tidlig lancering af foreløbig kommunikation Figur 5.6: Vurdering af den interne integration i integreret problemløsning ved anvendelse af PDM-systemer. Bearbejdet fra Pikosz og Malmqvist [1996, s. 5] Muligheder Af figuren ses, at PDM-systemer typisk giver mulighed for bilateral kommunikation af fragmenteret information (3. og 4. dimension) [Pikosz og Malmqvist, 1996, s. 6]. Det bunder i, at alle afhængig af adgangsrettigheder har adgang til informationen, og at systemet automatisk arkiverer ny information og giver besked til de relevante personer herom. Notifikationen er også medvirkende til, at PDM-systemer lægger op til brugen af foreløbig information (5. dimension) [Pikosz og Malmqvist, 1996, s. 7]. Mulighederne kan opsummeres som følger: 64

5.2 PDM-systemer - Den største overordnede mulighed ved at anvende et PDM-system er, at man da har én samlet og integreret model for produkt- og projektdata, og al information er samlet ét sted. - Kvaliteten af dokumentationen bliver højnet, da man med et PDM-system altid arbejder med den gældende version af produktmodellen. Versionsstyring håndteres af systemet. - Et korrekt konfigureret PDM-system forbedrer logistikken i forløbet ved at bidrage til, at de rigtige personer får den rigtige information på det rigtige tidspunkt. - Klassificeringen af projekt- og produktinformation lægger op til genbrug og gør søgning markant lettere. - Med et PDM-system kan man automatisere de processer i udviklingsarbejdet, som ikke er værdiskabende. Begrænsninger Af figuren fremgår også, at PDM-systemer ikke ligger så højt inden for 1. og 2. dimension. Et PDM-system har svært ved at understøtte ustrukturerede processer, hvor aktiviteterne kan udføres parallelt (1. dimension) [Pikosz og Malmqvist, 1996, s. 6]. Da kommunikationen i et PDM-system går via skærmbilleder og dokumenter, er rigdommen i mediet relativt lavt (2. dimension) [Pikosz og Malmqvist, 1996, s. 6]. Ved anvendelsen af et PDM-system skal man da være opmærksom på følgende begrænsinger: - Processerne skal være veldefinerede og rækkefølgen sekventiel. - PDM-systemet håndterer dokumenterne som sorte bokse, og med systemet er det derfor kun muligt at søge i dokumenternes metadata. - Kommunikationen baseres på fattige medier og lægger derfor ikke op til løsning af indviklede designproblemer. Et PDM-system må derfor ikke afløse andre mere informationsrige kommunikationsmedier. Anvendelse af en virtuel tusch (se afsnittet Systemfunktioner på side 62) forbedrer dog dette aspekt. - Et PDM-system er meget dyrt i anskaffelse og tilpasning. Herudover skal brugerne trænes i brugen af systemet. 65

Del II Empiri

Kapitel 6 Dokumentationsproces og kravanalyse Indhold af dette kapitel 6.1 Analyse af eksisterende processer.......... 70 6.1.1 GEA Niro A/S..................... 71 6.1.2 APC Denmark A/S.................. 73 6.1.3 F.L. Smidth A/S.................... 76 6.1.4 Vitral A/S....................... 78 6.1.5 Krav til dokumentationsværktøj........... 79 6.1.6 Erfaringer fra CASE-værktøjer og PDM-systemer.. 80 6.2 Den fremtidige proces................. 84 6.2.1 Scenarie 1: Objektorienteret konfigurator...... 86 6.2.2 Scenarie 2: Konventionel konfigurator........ 88 6.2.3 Udvikling vs. drift................... 91 I dette kapitel præsenteres projektets deltagende virksomheder. Der gives en beskrivelse af, hvordan de arbejder med produktmodeller, og herefter analyseres disse processer for at afdække, hvordan den optimale fremtidige proces understøttes med et IT-baseret dokumentationsværktøj. I analysen tages udgangspunkt i den syvfasede fremgangsmåde fra CPM som målet for den fremtidige fremgangsmåde. 69

Kapitel 6 - Dokumentationsproces og kravanalyse 6.1 Analyse af eksisterende processer For at kunne vurdere hvordan et kommende IT-baseret dokumentationsværktøj skal udformes, er det nødvendigt først at have en forståelse for, hvordan de kommende brugere arbejder, når de skal opbygge en produktmodel. Som nævnt i indledningen skal dokumentationsværktøjet støtte aktiviteterne i fremgangsmåden for opbygning af produktmodeller fra CPM, og det er ikke formålet med dette projekt at lave en revurdering af fremgangsmåden. De deltagende virksomheder er alle i større eller mindre grad bekendt med CPM s fremgangsmåde og øvrige arbejde. Analysen af de eksisterende arbejdsprocesser skal således bruges til at afdække, hvilken funktionalitet et IT-baseret dokumentationsværktøj skal have for at kunne håndtere dokumentationen for en produktmodel på en måde, der er praktisk anvendelig. Jeg har gennem møder og samtaler med nøglepersoner i virksomhederne forsøgt at afdække deres ønsker og krav til et dokumentationsværktøj, og resultaterne vil jeg opsummere i dette afsnit. I bilag C på side 171 er notater fra møder og samtaler gengivet. Analysen af de eksisterende processer munder ud i en beskrivelse af, hvordan dokumentationsværktøjet skal støtte arbejdet fremover, og denne beskrivelse vil derefter være grundlaget for opbygning af kravspecifikationen for dokumentationsværktøjet. Dette er illustreret i figur 6.1. Virksomhederne omfatter som nævnt tidligere APC Denmark A/S (APC), F.L. Smidth A/S (FLS) og GEA Niro A/S (Niro), som alle har erfaring med produktmodellering heriblandt APC og FLS vel nok som de mest erfarne i Danmark. Hertil kommer virksomheden Vitral A/S (Vitral), som ikke har så stor erfaring med produktmodellering, men som øjner store muligheder på området. h ij k l m n"o k nqp i$jr,stku k p j n"v.w x$y wk"vqm"z n $w$y n}n j p x"j y wn"j {(y x"o k n}x p n$~ k" k l n"j n y z"n z"i$~ "v.n"y l x l iy k j iƒ n k k n"j ( zn"y.iv r{(, " ˆ j ~ l Š nj"iw s$œtk k k l n"v.n"j n k"~ j ˆ n o k nqx p i ˆ nj i$j z$y n l ˆ j ~ n"vqm"z n j x ˆ k n ƒ" p ~ x l i$y ŽqŽ({ Figur 6.1: Struktur for analyse af arbejdsprocesser og opstilling af kravspecifikation 70

6.1 Analyse af eksisterende processer 6.1.1 GEA Niro A/S Niro er del af den tyske gruppe af virksomheder GEA Group og har oparbejdet en markant kompetence inden for behandling og håndtering af pulver (f.eks. anlæg til spraytørring af mælkepulver, kaffe og metalgranulater). Niros erfaringer med produktmodellering og konfiguratorer startede for alvor i november 2000, da et ph.d.-projekt blev sat i værk i samarbejde med CPM med Martin Malis som projektstuderende. Arbejdet med produktmodeller Niros arbejde med produktmodeller er beskrevet i bilag C.1 og C.2 på side 173 og er yderligere baseret på løbende samtaler med Martin Malis. Hos Niro anvendes i grove træk fremgangsmåden fra CPM, idet produktmodellering netop blev introduceret hos Niro i forbindelse med Malis ph.d.-projekt. PVM en anvendes som udgangspunkt for produktmodelleringen, efter fase 1 i fremgangsmåden er afsluttet. Når PVM en når et detaljeringsniveau, der gør den for uoverskuelig, fortsætter modelleringen ved opbygningen af CRC-kort i en struktur svarende til PVM ens part-of struktur. CRC-kortene er således helt centrale for dokumentationen af produktmodellen og er blevet tilpasset Niros brug, bl.a. er alle rent objektorienterede elementer fjernet (generaliseringsoplysninger mv.). Hos Niro er blevet udviklet en løsning i Lotus Notes til at holde styr på CRCkortene. Satsningen på Notes skyldes, at det i forvejen var virksomhedens standardsystem for kommunikation og dokumenthåndtering. APC anvender også Lotus Notes som standardsystem og har fået lov at bygge videre på Niros Notesløsning. Notes-løsningen er nærmere beskrevet i bilag C.4 på side 181 (besøg hos APC). I sin enkelhed består det af en diskussionsdatabase, hvor det er muligt at organisere de enkelte indlæg i en hierarkisk struktur (svarende til strukturen i PVM en). Et indlæg svarer til et CRC-kort og er et dokument, der er baseret på en central skabelon (svarende til at basere dokumenter på skabeloner i MS Word). Dokumentet indeholder en række felter svarende til felterne på CRCkortet som beskrevet i afsnit 4.3.3 på side 43. Dog er CRC-kortene som nævnt ændret en anelse, da den hierarkiske struktur kun kan afbilde venstresiden af strukturen i en PVM, og man er således afskåret fra at benytte sig af f.eks. generaliseringsstrukturer. I Niros tilfælde er dette dog acceptabelt, da deres konfigurator ikke er objektorienteret 1. Et eksempel på et skærmbillede fra Niros Notes-løsning er vist i figur 6.2 på følgende side. Udviklingen og vedligeholdelsen af produktmodeller hos Niro foregår ikke kun i den danske afdeling i Søborg, men bl.a. i samarbejde med afdelingen i Frankrig. Hos Niro er to eksamensprojektstuderende fra Institut for Produktion og Ledelse (IPL) i færd med at undersøge, hvordan produktmodeller kan anvendes i 1 Niro anvender Oracle Product Configurator, som er en del af Oracles e-business Suite ver. 11.5.7 71

Kapitel 6 - Dokumentationsproces og kravanalyse virksomhedsnetværk på tværs af geografiske grænser. Et krav til et dokumentationsværktøj vil derfor være, at det kan anvendes på tværs af geografiske skel, og at produktmodellen kan opdeles i undermodeller, som udvikles og vedligeholdes af forskellige organisatoriske enheder i netværket. Niros erfaringer med Notes-løsningen er samlet i tabel 6.1. Figur 6.2: Eksempel på CRC-kort og træstruktur i Lotus Notes hos Niro Fordele ved eksisterende værktøj Ønsker om forbedringer 1. Versionsstyring (for hvert dokument). 2. Registrering af ændringer (log). 3. Adgangsstyring. 4. Meddelelsessystem. 5. Flere kan arbejde med systemet ad gangen. 6. Tilgængelighed via internet. 7. Bedre udnyttelse af diagrammerne fra fremgangsmåden. 8. Udnyttelse af mulighederne for automation (f.eks. automatisk opdatering af data om relationer mellem klasser). 9. Mere intelligent sammenkobling af diagrammer og CRC-kort. Dette giver overskuelighed i komplekse modeller, som man ønsker at kunne opbygge. Tabel 6.1: Niros erfaringer med og ønsker til dokumentationsværktøj 72

6.1 Analyse af eksisterende processer 6.1.2 APC Denmark A/S Fortroligt, ikke medtaget i denne udgave. 73

Kapitel 6 - Dokumentationsproces og kravanalyse Fortroligt, ikke medtaget i denne udgave. 74

6.1 Analyse af eksisterende processer Fortroligt, ikke medtaget i denne udgave. 75

Kapitel 6 - Dokumentationsproces og kravanalyse 6.1.3 F.L. Smidth A/S FLS er en del af FLS Industries, og produktporteføljen dækker komplette cementfabrikker, enkeltstående maskiner og renoveringsopgaver samt reservedele og kundeservice. FLS startede omkring 1998 med at udvikle en konfigurator, som de p.t. bruger til at støtte tilbudsprocessen med stor succes [Hvam og Mortensen, 2002]. Med brug af en konfigurator har de nedsat tiden, det tager at udfærdige et budgettilbud, fra uger til dage, samtidig med at det blot kræver en enkelt sælger frem for tidligere 10-15 specialister. Arbejdet med produktmodeller FLS s arbejde med produktmodeller er beskrevet i bilag C.5 på side 189. FLS har kun opbygget én fungerende konfigurator (opbygning af budgettilbud), men arbejder p.t. med opbygning af en ny, der skal støtte konfigureringen af typevalgte enheder i en cementfabrik (enheder til transport af materiale internt på fabrikken). Som hos APC startede man opbygningen af produktmodellen med at samle en arbejdsgruppe af modellører, som blev støttet af en følgegruppe af domæneeksperter. Al produktviden blev tastet direkte ind i konfiguratoren, og der eksisterer således ingen dokumentation for produktmodellen. I den anvendte konfigurator (BaanConfiguration 98.2) er der ingen logisk sammenhæng mellem produktdele og bindinger. Resultatet er en konfigurator, der består af spaghettikode, som er meget svær at overskue og vedligeholde. Problemet hos FLS er oplagt, at der ikke eksisterer nogen dokumentation, og at konfiguratoren samtidig tillader, at man koder uden nogen form for struktur. Hermed bliver modellørerne ikke opmuntret eller tvunget til at fokusere på overskuelighed og dokumentation. Opdateringer af konfiguratoren er derfor et meget stort arbejde. Man har hos FLS valgt at give domæneeksperterne ansvaret for hver deres lille del af konfiguratoren, og ændringer sker ved, at domæneeksperterne sender en e-mail til tilbudsafdelingen, som har ansvaret for konfiguratoren. På den måde får man rigtigt mange e-mails med en beskrivelse af ændringen, og man skal efterfølgende finde det relevante sted i konfiguratoren og foretage ændringen. I den forbindelse ville man ønske, at det var muligt automatisk at relatere e-mailen til det område af konfiguratoren, som ændringen vedrører. Men så længe der ikke eksisterer en struktureret produktmodel, er dette ikke umiddelbart inden for rækkevidde. Erfaringerne fra arbejdet med den nuværende konfigurator bruges i arbejdet med de kommende. Her opbygger domæneeksperterne (med støtte fra modellørerne) først en dokumentation bestående af et regneark for hver produktdel. Når dokumentationen er på plads, overgives denne til et hold af programmører, som skal opbygge konfiguratoren i Baans ny konfigurator ibaan, som er objektorienteret. Incitamentet for domæneeksperterne er her at lave dokumentationen 76

6.1 Analyse af eksisterende processer rigtig ellers vil de blive kontaktet i tide og utide af programmørerne, som skal have afklaret tvivlsspørgsmål. Spørgsmålet er da blot, hvorvidt domæneeksperterne reelt har mulighed for at sikre, at deres dokumentation er fyldestgørende. Regnearkene er nemlig ikke integrerede på nogen måde, og det er således ikke umiddelbart muligt at danne sig et overblik over produktmodellen. Herudover er det også tvivlsomt, om man udnytter alle fordelene ved den objektorienterede konfigurator, når dokumentationen opbygges i flade regneark. Resultatet vil givetvis være, at programmørerne må oversætte regnearkene til en objektorienteret model, inden de implementerer systemet. FLS er meget interesseret i et dokumentationsværktøj, da manglen på dokumentation og en struktureret produktmodel er den største barriere i en effektiv udnyttelse af konfiguratorer. FLS nyder stor glæde af fordelene ved at anvende en konfigurator, men er samtidig fanget af, at det er et uforholdsmæssigt stort arbejde at vedligeholde konfiguratoren, og har på den hårde måde lært, at dokumentation ikke kan laves efterfølgende, men skal være en integreret del af processen. I modsætning til APC ser FLS det som et problem at basere et dokumentationsværktøj på et standardsystem som Lotus Notes. Hos FLS er kommunikationsog dokumenthåndteringssystemet baseret på Microsofts produkter, og hvis et dokumentationsværktøj baseret på f.eks. Notes skal bruges af domæneeksperterne, vil det betyde, at en meget stor del af de ansatte i virksomheden skal anvende Notes ud over de eksisterende Microsoft værktøjer. Dette anses ikke umiddelbart for muligt hverken økonomisk eller organisatorisk og praktisk. FLS s erfaringer og ønsker til dokumentationsarbejdet er samlet i tabel 6.3. Fordele ved eksisterende værktøj Ønsker om forbedringer 1. Regneark er nemt at bruge for alle involverede. 2. Meddelelsessystem til støtte for udviklingsarbejdet (især til notifikation om ændringsforslag). 3. Hyperlinks bør kunne bruges i alle tekstfelter til internetressourcer og andre dokumenter. 4. Adgang til værktøjet via internet, så geografisk placering ikke er et problem. 5. Mulighed for at integrere information fra eksterne databaser (f.eks. ERP-system). 6. Mulighed for overførsel til konfigurator og sammenkobling af dokumentation og implementering i den løbende udvikling, så kun dokumentationen skal opdateres. Tabel 6.3: FLS s erfaringer med og ønsker til dokumentationsværktøj 77

Kapitel 6 - Dokumentationsproces og kravanalyse 6.1.4 Vitral A/S Fortroligt, ikke medtaget i denne udgave. 78

6.1 Analyse af eksisterende processer 6.1.5 Krav til dokumentationsværktøj Erfaringerne og forslagene fra ovenstående virksomheder kan opsummeres i en række krav til dokumentationsværktøjet. Numrene i margenen henviser til numrene i tabel 6.1 til 6.4 på siderne 72 78. En samlet produktmodel bør samle informationen fra PVM, klassediagram Niro 5,7,8,9 APC 7,8 og CRC-kort i et databasesystem. Ud fra den samme information i dette centrale lager (repository) kan PVM, klassediagram og CRC-kort dannes. Kigges diagrammerne efter i sømmene, vil det fremgå, at de indeholder meget af den samme information, blot vist på forskellige måder. Versionsstyring skal sikre, at man kan arbejde med flere versioner af samme Niro 1,2 APC 1,10 CRC-kort på samme tid. Med et tryk på en knap skal det være muligt at se dokumentationen for den struktur af CRC-kort, der p.t. er implementeret i konfiguratoren vel vidende at der måtte eksistere nyere versioner af CRCkort, der endnu ikke er implementeret. Ud over at hvert CRC-kort skal have et versionsnummer, bør de også have en tilstand en status (f.eks. Implementeret eller Skal godkendes) 2. Det skal være muligt at se, hvad der er ændret fra version til version, og hvem der har gjort det (registrering i en log). Adgangsstyring skal sikre, at brugerne kan tilgå systemet med forskellige ret- Niro 3,5 APC 2 tigheder. Adgangen skal kunne styres ned til CRC-kort-niveau, og der skal kunne skelnes mellem læse- og redigeringsadgang. Hvert CRC-kort har en ejer (owner) og et antal medredaktører (co-editors). Herudover er der visse opgaver, som kun en bruger med administratoradgang kan udføre (opsætning af systemet, tilretning af CRC-kort, ændring af brugeradgang mv.). Notifikation via e-mail eller lign. skal kunne automatiseres. Når f.eks. en do- Niro 4 FLS 2 mæneekspert har tilføjet et ændringsforslag til et CRC-kort, skal der kunne sendes en notifikation til ejeren af CRC-kortet om, at der skal tages stilling til forslaget. Notifikationsfunktionen skal opbygges, så den kan udbygges til at reagere på forskellige hændelser i systemet. Indlæringskurven for systemet må ikke være stejl. Det bør tilstræbes at lave Niro 7,9 systemet så intuitivt let tilgængeligt som muligt for at tilskynde især domæneeksperterne til at bruge værktøjet uden for meget forudgående uddannelse. Ved FLS 1 APC 4,9 at bruge PVM og klassediagram aktivt i brugergrænsefladen kan bidrages til dette mål. Adgang via internet er et krav, da systemet skal kunne fungere i et netværks- Niro 6 miljø på tværs af geografiske grænser. Det er dog ikke et krav, at systemet skal APC 3 afvikles i en browser. FLS 4 Integration til eksterne systemer skal gøre det muligt, at der i CRC-kortene APC 11 FLS 5 kan vises information fra f.eks. ERP-systemet. Det skal være muligt at indsætte felter i CRC-kortet, som henter data fra et eksternt databasesystem. 2 I versionsstyringssystemer som f.eks. Concurrent Version System (CVS) bruges betegnelsen tag for denne funktionalitet. Versionsnummeret benyttes således primært af systemet til at holde styr på ændringer. 79

Kapitel 6 - Dokumentationsproces og kravanalyse APC 6 Vitral 2 FLS 3 Vitral 1 APC 5 FLS 6 APC 12 Regler i CRC-kort må ikke være bundet til at skulle skrives i et formaliseret sprog (f.eks. OCL). Domæneeksperterne må ikke opleve nogle barrierer for at vedligeholde CRC-kortene; det er vigtigere at få beskrevet reglerne i ren tekst eller tabeller, frem for ikke at få dem beskrevet på grund af at domæneeksperterne ikke kan OCL. På den anden side kan det være en fordel for nogle udviklere at kunne dokumentere regler i et formaliseret sprog. Det bør derfor være muligt at dokumentere regler på begge måder. Hyperlinks skal kunne indsættes i alle tekstfelter i dokumentationen. På den måde kan der refereres til eksterne elektroniske dokumenter og diagrammer samt CRC-kort internt i modellen, og med klik på linket kan det refererede bringes frem. Fleksibel opbygning skal sikre, at systemet er nemt at udbygge. Det skal være muligt at tilføje brugerdefinerede felter til CRC-kortet, og integrationen med eksterne systemer bør også rumme muligheder for brugertilpasning. Integration med konfiguratorer er ikke et centralt krav, men FLS ser det som en oplagt mulighed i fremtiden. Virksomhederne er dog enige om, at blot det at kunne overføre attributnavne og lign. til konfiguratoren vil være en stor fordel, som er værd at inkludere om muligt. Sproget i dokumentationsværktøjet skal være engelsk (dvs. tekst på knapper, i menuer, hjælpetekster osv.). Alternativt kunne man lave en arkitektur, der gav mulighed for at sproget kunne ændres let. Det vil dog næppe være ulejligheden værd, da langt de fleste konfiguratorer og andre systemer, brugerne arbejder med, er på engelsk. 6.1.6 Erfaringer fra CASE-værktøjer og PDM-systemer I afsnit 5.1.3.1 på side 56 blev gennemgået, hvordan et moderne I-CASE-værktøj bør understøtte udviklingsarbejdet i projektlivscyklussen. Tilsvarende blev i afsnit 5.2.2.1 på side 61 gennemgået, hvilke overordnede funktionaliteter der kendetegner et PDM-system. I dette afsnit vil jeg koble disse overordnede erfaringer med kravspecifikationen for dokumentationsværktøjet til produktmodellering. Syntaktisk korrekthed Konsistens og fuldstændighed CASE-værktøjer Diagrammer udgør en central del af dokumentationen for en produktmodel, og der er mange aspekter fra gennemgangen, der er direkte anvendelige. Dokumentationsværktøjet skal sørge for, at syntaksen i diagrammerne til enhver tid opretholdes. Syntaksen for PVM skal forinden klart defineres, mens syntaksen for klassediagrammet kan hentes direkte fra dokumentationen for UML (f.eks. i Booch et al. [2001]). Den objektorienterede tankegang vil her være en god tilgangsvinkel, idet et diagram kan opdeles i en række objekter, som hver især kan tildeles ansvaret for at tjekke, om syntaksen opretholdes. Mens det er relativt enkelt at tjekke for syntaktisk korrekthed, er det ikke muligt at vurdere, om en produktmodel er fuldstændig. Det syntaktiske tjek skal foregå 80

6.1 Analyse af eksisterende processer løbende, ved at elementerne i diagrammerne ikke kan oprettes med syntaktiske fejl (f.eks. tegnes en svag aggregering korrekt, og to klasser kan ikke have samme navn). Med hensyn til fuldstændigheden kan dokumentationsværktøjet dog bruges til at tjekke, om der for alle klasser eksisterer et fuldstændigt CRC-kort. Dette kan foregå i to tempi; ved oprettelse skal alle CRC-kort forsynes med ID, navn, beskrivelse, ejer samt dato for oprettelse. Heraf kan værktøjet selv tildele ID (unik, fortløbende nummerering), dato (systemets dato) og ejer (brugeren, der opretter klassen). Brugeren skal derimod selv angive et navn og en beskrivelse. Anvendelsen af en central databasebaseret produktmodel vil gøre det nemt at Rapportgenerering trække information ud af systemet. Generering af rapporter vil derfor kunne opbygges som forespørgsler i databasesystemet. Hvis man samtidig laver en fornuftig objektorienteret model af diagramelementerne, vil det være muligt at bruge funktionaliteten fra en rapportgenerator til at opbygge et dataleksikon. I Dataleksikon den forbindelse skal der huskes på, at et dataleksikon også skal kunne indeholde abstrakte elementer, som ikke direkte er en del af produktmodellen (som f.eks. attributter og metoder er). Da PVM og klassediagram ikke er helt tæt koblede, vil det ikke være hensigts- Navigation i mæssigt at understøtte navigering mellem de to diagrammer. Koblingen mellem koblede en klasse i enten PVM eller klassediagram og dens CRC-kort er derimod entydig, og med et klik på en klasse i et af diagrammerne skal et vindue med diagrammer CRC-kortet for klassen vises 3. På samme måde skal det i så vid udstrækning som muligt kunne lade sig gøre at få adgang til information om et element i produktmodellen ved at klikke på elementet. Hvis f.eks. en klasse er nævnt i et felt i et CRC-kort, så skal klassens CRC-kort åbnes i et nyt vindue. Lagdeling i produktmodellering bruges i OOA-fasen (fase 3) til at strukturere Lagdeling fasen i overskuelige aktiviteter. I selve produktmodellen bruges lagdeling ikke på samme måde som kendt fra systemudvikling, hvorfor dokumentationsværktøjet ikke skal understøtte denne funktionalitet. I afsnit 4.3.3 på side 43 blev nævnt, at Mortensen et al. opererer med et felt på Sporbarhed CRC-kortet, der kaldes Source, som beskriver kilder til (baggrunds)information om klassen. For at have informationen så tæt på anvendelsen som muligt, bør det være muligt at tilknytte noter til diagrammernes elementer (attributter, relationer, metoder, klasser etc.). Når produktmodellen er færdig, bør dokumentationsværktøjet kunne støtte over- Kodegenerering førslen til konfiguratoren. Da de færreste eksisterende konfiguratorer er objektorienterede, vil det være vanskeligt direkte at overføre produktmodellen til konfiguratoren. Til gengæld vil det med en central database være muligt at give mulighed for, at eksterne systemer kan trække på produktmodellens informationer. Denne mulighed gennemgås nærmere i afsnit 7.6 på side 114. 3 Se evt. bilag F på side 259 med prototype-skærmbilleder for en uddybning af idéen bag navigationen mellem diagrammerne og CRC-kortene. 81

Kapitel 6 - Dokumentationsproces og kravanalyse Som nævnt ovenfor i afsnit 6.1.5 er versionsstyring et umiddelbart krav. I tilgift hertil vil det være meget anvendeligt at kunne overskue, hvad der faktisk er implementeret i konfiguratoren, og sammenholde dette med hvad der er dokumenteret. Dvs. at kunne sammenholde produktmodellen i konfiguratoren med produktmodellen i dokumentationsværktøjet. Denne funktion vanskeliggøres også af, at de færreste konfiguratorer er objektorienterede, og sammenligningsfunktionen kan derfor med fordel kategoriseres som nice to have og udskydes til en senere version af værktøjet. Som det også blev nævnt i afsnit 6.1.5 ovenfor, vil det dog være meget praktisk at kunne give klasserne i klassediagrammet en status f.eks. implementeret. Systemsimulering og ydelsesanalyse Styring og kontrol af database Styring af processer og arbejdsgange Styring af produktstruktur Klassifikation Programstyring CASE-værktøjer til udvikling af informationssystemer indeholder også ofte funktioner til systemsimulering og ydelsesanalyse, men i relation til dokumentationsværktøjet vurderes det, at disse funktioner ikke er relevante i det mindste ikke i en første version af systemet, der fokuserer på de centrale krav. PDM-systemer Adgangskontrollen og versionsstyringsfunktionen nævnt i forrige afsnit er centrale i forhold til styringen og kontrollen med databasen, der indeholder alle informationerne i dokumentationsværktøjet. Med disse funktioner skal sikres, at kun brugere med de rette rettigheder kan tilgå information, og samtidig skal føres en log over ændringer. Hvis udveksling af information med eksterne systemer medfører, at disse systemer skal tilgå dokumentationsværktøjets database, skal det sikres, at denne adgang kan styres både med hensyn til hvem (hvilke systemer) der kan tilgå databasen, og hvilke operationer der må udføres (læsning, skrivning, forespørgsler etc.). Dokumentationsværktøjet skal udformes til at støtte CPM s fremgangsmåde, men skal stadig være fleksibelt og kunne anvendes med andre fremgangsmåder. I forbindelse med ændringer i produktmodellen (CRC-kort) skal det dog sikres, at domæneeksperter kun kan stille ændringsforslag, mens en modellør skal godkende forslaget, før CRC-kortet ændres. Dokumentationsværktøjet er samlet omkring den underliggende produktmodel. Til forskel fra klassiske PDM-systemer er produktmodellen i dokumentationsværktøjet objektorienteret, men i lighed med PDM-systemerne skal det være muligt at lave referencer fra klasserne i produktmodellen til relevante dokumenter. Anvendelsen af en central database til lagring af informationer gør søgning i og deling af allerede eksisterende modeller let. En klassifikation af klasserne i en produktmodel kan gøres med anvendelse af stereotyper (se afsnit 3.3.2 på side 25), og det bør derfor være muligt at kunne definere dels et globalt sæt af generelle stereotyper, som dermed sætter en fælles standard for virksomheden, og dels et lokalt sæt, som er specifikt for det enkelte projekt. Redskaber til styring af selve projektet ville være meget anvendelige at have indlejret i dokumentationsværktøjet. Imidlertid ville det hurtigt blive omfattende, 82

6.1 Analyse af eksisterende processer og da der som tidligere nævnt eksisterer mange værktøjer til projektstyring, bør denne funktionalitet udelades af dokumentationsværktøjet. Notifikation hænger tæt sammen med styring af processer og arbejdsgange. I de Kommunikation og notifikation fleste virksomheder har man standardiserede systemer til at håndtere den elektroniske kommunikation, og det vil derfor ikke være formålstjenligt at udvikle endnu et system af denne slags. I stedet bør fokuseres på at lave en meddelesesfunktion, som støtter styringen af arbejdsgange og processer. Man kan måske med fordel få denne funktion til at benytte sig af virksomhedens eksisterende kommunikationssystem (f.eks. en mailserver eller lign.). I forbindelse med design af dokumentationsværktøjet bør det tilstræbes, at bru- Transport af data geren ikke skal bekymre sig om, hvor (produktmodellens) data er placeret. Når en bruger tilgår et projekt, bør det ske på baggrund af f.eks. titlen på projektet og ikke kræve viden om den fysiske placering af databasen og andre systemtekniske variable. Muligheden for automatisering af konvertering af data mellem forskellige forma- Konvertering af data ter anses ikke for at være en central funktionalitet i et dokumentationsværktøj. Konvertering vil være interessant i forbindelse med kommunikation med konfiguratorer, men dette er behandlet i forbindelse med Kodegenerering ovenfor. Kommunikation mellem især domæneekspert og modellør er karakteriseret ved Illustrationsservice en kommunikationskløft med hensyn til den tekniske indsigt i produktmodellering. Hvis det kunne gøres lige så nemt at kommentere på f.eks. et CRC-kort eller et klassediagram i elektronisk format, som det er at sætte de velkendte selvklæbende gule sedler på et stykke papir, så ville en del af kløften givetvis kunne nedbrydes. Funktionaliteten vurderes dog ikke som højeste prioritet. Til ethvert informationssystem skal vurderes, hvordan systemet skal administre- Systemadministration res. Ud over den sædvanlige funktionalitet omkring håndtering af brugere og opsætning af systemet bør der også tænkes på, hvordan dokumentationsværktøjet struktureres, så de i fremtiden nemt kan udbygges, dvs. hvilke elementer skal kunne konfigureres af en administrator, og hvad skal konfigureres via tilpasning af moduler (add-on) af en programmør. Al håndtering af kommunikation med konfiguratorer bør løses vha. den sidste løsning, da det kræver meget specifikke løsninger, som hurtigt kan blive meget omstændelige at indpasse i et fleksibelt modul, som kan tilpasses af en administrator. Herudover kræver tilpasning meget specifik tekniske viden, som en administrator næppe besidder. 83

Kapitel 6 - Dokumentationsproces og kravanalyse Er et PDM-system løsningen? Ovenstående gennemgang af PDM-systemers relevans for et dokumentationsværktøj efterlader det umiddelbare indtryk, at et PDM-system vil være en oplagt løsning. Funktionsmæssigt er denne betragtning helt korrekt, og som det også fremgik af afsnit 5.2 på side 59 om PDM-systemer, vil der være mange ligheder mellem et PDM-system og et dokumentationsværktøj til produktmodellering. En umiddelbar barriere ved at løse problemet med et PDM-system er omfanget og prisen for PDM-systemer. Som det også tidligere blev nævnt, er et PDMsystem et meget omfattende informationssystem med en kompliceret opbygning. Derfor er implementeringen af et PDM-system også forbundet med store omkostninger. Som eksempel kan nævnes Danfoss implementering af Metaphase 3.0, som har kostet mellem DKK 10-20 mio. at implementere 4. Det er således sjældent, at PDM-systemer implementeres i virksomheder med under 1.000 medarbejdere 5. En anden barriere er den objektorienterede produktmodel, som ikke traditionelt understøttes af PDM-systemer [Svensson og Malmqvist, 2001]. Såfremt der ønskes et dokumentationsværktøj, som understøtter mulighederne for generalisering, opbygning af klynger og temaer samt muligheden for at lave flere relationer mellem klasserne, er et PDM-system ikke løsningen. For virksomheder, der kun sigter mod implementering i en konventionel konfigurator, vil den hierarkiske produktstruktur, som klassiske PDM-systemer tilbyder, måske være tilfredsstillende. I så fald kan produktmodellen ikke blive mere avanceret, end venstresiden i en PVM. 6.2 Den fremtidige proces Fremgangsmåden for opbygningen af produktmodeller fra CPM beskriver aktiviteterne lige fra den strategiske analyse forud for produktmodelleringen, til produktmodellen er implementeret i en konfigurator og skal vedligeholdes løbende. Som nævnt i afsnit 4.3 på side 40 skal dokumentationsværktøjet understøtte arbejdet i alle faserne undtagen et og seks. I afsnit 4.2 på side 38 blev fremgangsmåden beskrevet, og som det er illustreret i figur 6.4 på følgende side, varierer anvendelsen af PVM, klassediagram og CRC-kort, afhængig af hvor langt man er nået i projektlivscyklussen. Fremgangsmåden er baseret på disse tre centrale elementer, og det vil derfor være oplagt at lade disse tre elementer have en central rolle i dokumentationsværktøjets brugergrænseflade. På den måde integreres dokumentationsværktøjet i høj grad med fremgangsmåden, og det bliver let at lære at bruge værktøjet. Filoso- 4 Ifølge Kristian Klit, Business System Manager hos Danfoss Drives (gæsteforelæsning 10/4 2002 i kurset Industrielle Informations- og Specifikationssystemer på DTU). 5 Danfoss Drives har ca. 1.500 medarbejdere som en del af Danfoss i alt ca. 19.000 medarbejdere. 84

Oker el sop O k e r e l s o p O k e r e l s o p O k e r e l s o p Oker e l s o p Oker e l s o p O k e r e l s o p O k e r e l s o p O k e r e l s o p Oker e l s o p Oker el sop O k e r e l s o p O k e r e l s o p O k e r e l s o p Oker e l s o p Oker e l s o p O k e r e l s o p O k e r e l s o p O k e r e l s o p Oker e l s o p Oker el sop Oker el sop Oker el sop Oker el sop Oker el sop Oker el sop Oker el sop O k e r e l s o p O k e r e l s o p O k e r e l s o p Oker e l s o p Oker e l s o p O k e r e l s o p O k e r e l s o p O k e r e l s o p Oker e l s o p Oker el sop Oker el sop Oker el sop Oker el sop Oker el sop Oker el sop Oke r e l s o p O k e r e l s o p O k e r e l s o p O k e r e l s o p O k e r e l s o p O k e r e l s o p 6.2 Den fremtidige proces fien skal være, at hvis man kan arbejde med diagrammerne og CRC-kortene på et stykke papir, så kan man også bruge dokumentationsværktøjet. Dog vil det være en del lettere at prøve idéer af og lave ændringer, og dokumentationsværktøjet vil være for domæneeksperter og modellører, hvad et CASE-værktøj som Rational Rose er for IT-systemarkitekter og programmører. Anvendelsen af klassediagrammet som dokumentation for implementeringen vil være fuldt ud tilstrækkeligt, når målet er en objektorienteret konfigurator (som f.eks. ibaan). Selvom fremtidens konfiguratorer med al sandsynlighed vil være objektorienterede, er der p.t. et behov for at kunne håndtere dokumentation for implementering i konventionelle (ikke-objektorienterede) konfiguratorer (som f.eks. Cincom og Oracle). Værktøjet skal derfor understøtte håndtering af denne dokumentation. Problemstillingen består i, at produktmodellen ofte opbygges med anvendelse af f.eks. nedarvning (generalisering og specialisering), mens den endelige struktur i en konventionel konfigurator vil være et relativt fladt hierarki. Løsningen er, at dokumentationsværktøjets funktioner bruges forskelligt afhæn- Anvendelse efter kontekst gigt af konfiguratortype. Det kræver, at man inden modelleringsarbejdet er nået for langt har gjort sig klart, om man sigter mod en objektorienteret eller en konventionel konfigurator. Nedenfor er beskrevet forløbet i disse to overordnede brugerscenarier baseret på fremgangsmåden fra CPM og erfaringerne fra virksomhederne. Fase 1 Procesanalyse etc.... etc.... Fase 2 Produktanalyse Fase 3 Objektorienteret analyse Gennemløb 1 Fase 4 Objektorienteret design Fase 5 Programmering Fase 6 Implementering Fase 7 Vedligeholdelse Gennemløb 2 Projektlivscyklus Gennemløb 3 Figur 6.4: Anvendelse af dokumentationsværktøjet gennem projektlivscyklussen 85

Kapitel 6 - Dokumentationsproces og kravanalyse 6.2.1 Scenarie 1: Objektorienteret konfigurator Når konfiguratoren er objektorienteret, vil produktmodellens klassediagram sammen med de detaljerede CRC-kort udgøre dokumentationen for implementeringsstrukturen i konfiguratoren på samme måde som et klassediagram dokumenterer strukturen i et objektorienteret IT-system (se 3.3.2 på side 25 vedr. klassediagrammer og UML). Fremgangsmåden i det objektorienterede tilfælde er skitseret i figur 6.5 på følgende side og gennemgås nedenfor. 1. Udgangspunktet er opbygningen af PVM en i samarbejde med domæneeksperterne. PVM en opbygges med brug af alle de tilgængelige elementer: Klasser oprettes, struktureres i aggregeringer og generaliseringer, relateres til hinanden med bindinger, noter tilføjes, og illustrationer indsættes. For hver klasse oprettes automatisk et CRC-kort, og er den nødvendige information til stede, kan man begynde at detaljere CRC-kortene. I CRC-kortene kan man f.eks. beskrive oplagte bindinger eller lave referencer til yderligere information i eksterne dokumenter eller databaser. 2. PVM en kan på et hvilket som helst tidspunkt eksporteres til klassediagrammet. Oftest vil dette dog ske, når PVM en er tæt på fuldendt. Klassediagrammet vil afbilde den samme struktur som PVM en, idet den venstre side vil blive oversat til aggregeringsstrukturer og højresiden til nedarvingsstrukturer. En generaliseringsklasse fra PVM ens venstreside vil i klassediagrammet blive forbundet med sin tilhørende nedarvningsstruktur. Princippet er illustreret i figur 6.6 på følgende side. Da klassediagrammet indeholder mere og anden information end PVM en, vil det eksporterede diagram ikke være fuldstændigt, men virke som et godt udgangspunkt for den videre modellering. For hver klasse i klassediagrammet oprettes nye CRC-kort, og evt. eksisterende information i PVM ens CRC-kort kopieres til de nye CRC-kort i klassediagrammet. På den måde bibeholdes al information, samtidig med at klassediagrammet er uafhængigt af PVM en og vice versa. Versionsstyringen vil tillade, at der kan arbejdes med flere versioner af det samme CRC-kort, og at det til enhver tid er tydeligt, hvilket klassediagram der afspejler implementeringen. 3. Når PVM en har tjent sit formål og er eksporteret til et klassediagram, foregår det resterende udviklingsforløb i klassediagrammet. Hvor arbejdet med udarbejdelsen af PVM en var fokuseret entydigt på at afbilde struktur og funktion i produktet, fokuseres nu også på strukturen i den endelige implementering. Klasser tilføjes, ændres og nedlægges, relationer redigeres, og CRC-kortene udfyldes med al nødvendig information. Resultatet er et komplet klassediagram, der afbilder produktet i en komplet objektorienteret model parat til implementering. 86

ß ß ß 6.2 Den fremtidige proces œ.žk.ÿ q K š(, } ž (, } š.!!!! # # " $! " ô õ ö ö óô ÆÆ Ì ÁÕ Ö Æ Ó óô ÆÆ Ì ÁÕ Ö Æ óô ÆÆ Ì ÁÕ Ö Æ ñ î Û Ã Æ ¾ Å Ã Ó ïð î Û Ã Æ ¾ Å Ã ïð î Û Ã Æ ¾ Å Ã ñ ïð î Û Ã Æ ¾ Å Ã ò ïð ô õ ö ö ó Ô ÆÆ Ì ÁÕ Ö Æ Ó ó Ô ÆÆ Ì ÁÕ Ö Æ ó Ô ÆÆ Ì ÁÕ Ö Æ ñ ø ù ú ûü ý ú þ ÿ ù ù ú ú ûü ûü ý ý ú ú ÿ ù ú ûü ý ú ÿ ÿ ô õ ö ö ó Ô ÆÆ Ì ÁÕ Ö Æ Ó ó Ô ÆÆ Ì ÁÕ Ö Æ ó Ô ÆÆ Ì ÁÕ Ö Æ ñ ù ù ú ú ûü ûü ý ý ú ú þ ÿ ù ú ûü ý ú ÿ ÿ ù ú ûü ý ú ÿ ô õ ö ö ó Ô Æ Æ ÌÁÕ Ö Æ Ó ó Ô Æ Æ ÌÁÕ Ö Æ ó Ô Æ Æ ÌÁÕ Ö Æ ñ ù ú ûü ý ú þ ÿ ù ù ú ú ûü ûü ý ý ú ú ÿ ù ú ûü ý ú ÿ ÿ ô õ ö ö ó Ô Æ Æ ÌÁÕ Ö Æ Ó ó Ô Æ Æ ÌÁÕ Ö Æ ó Ô Æ Æ ÌÁÕ Ö Æ ñ ù ù ú ú ûü ûü ý ý ú ú þ ÿ ù ú ûü ý ú ÿ ÿ ù ú ûü ý ú ÿ ª«± ² ³ µ ³ ³ ¹ º µ À ÁÂÃ Ä Å ÁÆ Ç ÁÃ È ÉÊ Ë Ã ÌÆ À ¾ Ì ¼ Æ Í Ã Âλ ¼ ½ ¾ ¼ Ï Ð Ã Ë Æ Ã Ì Ê Ñ ë ì í ô õ ö ö ô õ ö ö Ô ÆÆ Ì ÁÕ Ö Æ Ó Ô ÆÆ Ì ÁÕ Ö Æ ó Ô Æ Æ ÌÁÕ Ö Æ Ó ó Ô Æ Æ ÌÁÕ Ö Æ ó Ô ÆÆ Ì ÁÕ Ö Æ Ó Ø Â¼ Ë Ë Ã Ó Ø Â¼ Ë Ë Ã Ù î ó Ô Æ Æ ÌÁÕ Ö Æ ñ ó Ô ÆÆ Ì ÁÕ Ö Æ Û Ã Æ ¾ Å Ã Ó ï ð ó Ô ÆÆ Ì ÁÕ Ö Æ ñ î Û Ã Æ ¾ Å Ã ï ð Ô ÆÆ Ì ÁÕ Ö Æ Ï î Û Ã Æ ¾ Å Ã ñ ï ð ù ú ûü ý ú þ ÿ Ø Â¼ Ë Ë Ã Ú î Û Ã Æ ¾ Å Ã ò ï ð ù ú ûü ý ú ÿ ù ù ú ú ûü ûü ý ý ú ú ÿ ÿ Û Ã Æ ¾ Å Ã Ú Û Ã Æ ¾ Å Ã Ü ô õ ö ö ô õ ö ö Û Ã Æ ¾ Å Ã Ï ó Ô ÆÆ ÌÁÕ Ö Æ Ó Û Ã Æ ¾ Å Ã Ý ó Ô ÆÆ ÌÁÕ Ö Æ óô ÆÆ Ì ÁÕ Ö Æ Ó ó Ô ÆÆ ÌÁÕ Ö Æ ñ óô ÆÆ Ì ÁÕ Ö Æ óô ÆÆ Ì ÁÕ Ö Æ ñ Ø Â¼ Ë Ë Ã Ü ø ù ú ûü ý ú þ ÿ Ô ÆÆ Ì ÁÕ Ö Æ Ý ù ú ûü ý ú ÿ ù ù ú ú ûü ûü ý ý ú ú þ ÿ ÿ ù ú ûü ý ú ÿ Ø Â¼ Ë Ë Ã Ó Þ ù ú ûü ý ú ÿ ù ù ú ú ûü ûü ý ý ú ú ÿ ÿ ä ¼ ¼ Ë Ë Æ Ë å ½ à ¼ ¼ Ê æ à à á Å â á Ó ã Ü Ã çú Ì Ã Â Þ Ë Þ ¾ Î ½ ¼ Ê æ Ã Å Õ è á à é à à ÂË ¾ Ê Ç Ã Ì Ë Á¾ Ê áó éù â È Ê Ã Ì á ê é ¼ Ì ÂË ¾ Ê À ¾ Ì Í Ã ÂÎ Ò Î Ì Ã Ë Ë À Ó ô õ ö ö ó Ô Æ Æ ÌÁÕ Ö Æ Ó ó Ô Æ Æ ÌÁÕ Ö Æ ó Ô Æ Æ ÌÁÕ Ö Æ ñ ù ù ú ú ûü ûü ý ý ú ú þ ÿ ÿ ù ù ú ú ûü ûü ý ý ú ú ÿ ÿ Figur 6.5: Fremgangsmåde ved objektorienteret konfigurator. Numrene i figuren svarer til numrene i beskrivelsen %'& ( B C D 9 EF; > GH= A = < ) * + +, -. + / 01, 2, + 3 4 5 6 7 8 9 @1= A = < 7I? J K 8 J G= A = < : ; < < = >? < 8 LM8? >? 9 GH= A = < Figur 6.6: Princip ved overførsel af PVM til klassediagram 4. Når modellen er færdig, kan den overføres til konfiguratoren. Sigtet er ikke, at konfiguratoren er køreklar efter overførslen, idet der uvægerligt skal laves nogle små tilpasninger. Ved hjælp af overførslen slipper man for at skulle indtaste modellens information (klasser, metoder, attributter bindinger mv.) i konfiguratoren, og samtidig undgås indtastningsfejl. Hvor meget information, der kan overføres til konfiguratoren, afhænger af den enkelte konfigurator. Se afsnit 7.6 på side 114 for mere information om integrationen til konfiguratoren. 5. For at sikre at dokumentationen (produktmodellen visualiseret ved klassediagram og CRC-kort) og implementeringen er i overensstemmelse med hinanden, kan disse sammenlignes og synkroniseres. Et modul sammenligner de to strukturer mht. klasser, relationer, attributter og bindinger og markerer uoverensstemmelser. Brugeren skal da efterfølgende tage stilling til, om det er implementeringen eller dokumentationen, der ikke er opdateret, og foretage den nødvendige handling. 6. Er der behov for en større revidering af produktmodellen, kan et klassediagram eksporteres tilbage til en PVM. Her vil en del information uvægerligt gå tabt som et resultat af forskellen på de to diagrammer. Som ved eksport fra PVM til klassediagram oprettes nye CRC-kort til klasserne i PVM en, og indholdet fra klassediagrammets CRC-kort kopieres. PVM en vil efter eksporten være helt rå, og illustrationer samt noter skal efterfølgende tilføjes. 87

Kapitel 6 - Dokumentationsproces og kravanalyse 6.2.2 Scenarie 2: Konventionel konfigurator Når konfiguratoren ikke er objektorienteret, er fremgangsmåden lidt anderledes. Forskellen består i, at ikke alle elementerne i den objektorienterede modelleringsmetode kan anvendes. Helt grundlæggende er tankegangen anderledes, da attributter, metoder og bindinger i en konventionel konfigurator ikke er organiseret i en struktur af indkapslende klasser, men i et mere fladt hierarki hvor sammenhængende attributter og bindinger ikke nødvendigvis er placeret i nærheden af hinanden, og hvor der kan eksistere flere instanser af den samme information. Herudover vil det næppe give mening at benytte sig af generaliseringsstrukturer, da de ikke vil kunne implementeres i en konventionel konfigurator. Brug af samme diagrammer På trods af forskellene kan diagrammerne fra det objektorienterede scenarie bruges som dokumentation. Riis har i sit ph.d.-projekt i samarbejde med demex electric A/S opbygget en produktmodel og implementeret denne i en konventionel konfigurator (BaanConfiguration 98.4.1) [Riis, 2002]. Erfaringerne med arbejdet har vist, at dokumentationen kan opbygges bestående af de samme diagrammer (PVM, klassediagram og CRC-kort), når man blot ikke bruger generaliseringsstrukturer. Figur 6.7 på følgende side skitserer fremgangsmådens trin, som bl.a. er baseret på erfaringerne fra demex electric A/S. 1. Som i det objektorienterede scenarie startes med opbygning af PVM på traditionel vis. Eneste forskel er, at der ikke bør laves generaliseringsstrukturer (højre side af diagrammet), men udelukkende bruges aggregeringsstrukturer. 2. PVM en kan på ethvert tidspunkt eksporteres til et klassediagram. Fremgangsmåden er den samme som i det objektorienterede scenarie, men det resulterende klassediagram vil i sagens natur bestå af en ret flad struktur uden nedarvning. 3. I klassediagrammet arbejdes videre med produktmodellen under hensyntagen til implementeringsmuligheder og -begrænsninger. Navne på klasser og klynger kan bruges til at skabe lighed mellem dokumentationen og træstrukturen i konfiguratoren. Der kan ikke laves en komplet en-til-enrelation mellem en klasse i dokumentationen og en tilsvarende knude i konfiguratorens træstruktur, men navngivningen kan bruges til at skabe overblik, så det bliver lettere at finde regler og få en idé om strukturen i konfiguratoren. 4. Når modellen er modelleret færdig, skal den overføres til konfiguratoren. Såfremt konfiguratoren understøtter import af produktmodeldata (i større eller mindre omfang), kan overførslen ske mere eller mindre automatisk. Selv hvis konfiguratoren blot kan importere navne på regler og attributter, har man sparet et stort tastearbejde. 88

º º 6.2 Den fremtidige proces ~O\ 'VW ƒ Q [ ZH[MT OWQ' ˆ X 1[ Š' NPORQHSIT UWVYX Z1[ O\X ÉMÊ Ë Ì Í Î Ï ÐË Ì Ñ Ò Ó ÔÔ Õ Ö Ø Ô Ù Ó ÔÔ Õ Ö Ø Ô Ú Ó ÔÔ Õ Ö Ø Ô Û Ü ÝÞ ß ß à Ù Ü ÝÞ ß ß à Ú Ü ÝÞ ß ß à Û Ü ÝÞ ß ß à â Ó Ô Ô Õ Ö Ø Ô â Ó Ô Ô Õ Ö Ø Ô á Ó Ô Ô Õ Ö Ø Ô ã Ü ÝÞ ß ß à á s t u v v w x i i j j kk kk l l mn mn o o k k p q i ] ] j ^ ^ kk l mn `a `a o b b k r f c de de ] ] ^ ^ `a `a b b g h de de s t u v v w } i j kk l mn o k p i i j ] j kk ^ kk l _ l mn mn o `a o k b k q _ r c de ] ] ^ ^ `a `a b b f g de ] ^ _ `a b _ h de de s t u v v w i i j j kk kk l l mn mn o o k k p q i ] j ^ kk _ l mn ` a o b k _ r ] ^ _ ` a b _ f c de de ] ] ^ ^ ` ` a a b b h g de de s tu v v w z s tu v v w { ij ij kk kk l l mn mn o o k k p i j kk l mn o k p q i j kk l mn o k q ij y] ^ kk ^ _ l _ `a mn `a b o k b _ r i _ c f d e ] j ^ kk l _ mn `a o b k _ r c de ] ^ _ `a b _ g de ] ^ _ `a b _ f de de ] ^ _ `a b _ g de ] ^ _ `a b _ h de ] ^ _ `a b _ h de Œ Ž Œ u š w M œ w m mk m ª«lk l Ÿ k ž Ÿ Ÿ j kk l mn o k p j kk l mn o k q ³ ³ Ÿ p Ÿ j kk l mn o k ³ Ÿ µ k µ k k k ³ Ÿ j kk l mn o k ³ Ÿ p ¹ º k l «± s tu v v w x i i j kk lmn o k p i j ] j kk ^ kk lmn _ lmn o `a o k b k q _ r c de ] ] ^ ^ `a `a b b f g de de ] ^ _ `a b _ h de s tu v v w } i i j j kk kk lmn lmn o o k k p q i ] j ] ^ kk ^ _ lmn _ `a o `a b k b _ r _ f c de de ] ] ^ ^ `a `a b b g h de de Ÿ Ÿ» Ÿ ¼ ½ ¾ l k À Ÿ «Á ¼ p µ q ¹ ¹ q Ÿ «Á n à ¼» Ä» «l m «¼p Ä ½ «l¼ Å Ä Ÿ l «Æ Ç È s tu v v w ij ij kk l mn o k p ij kk ] ^ kk l _ l mn mn o `a o k b k q _ r c de ] ] ^ ^ `a `a b b f g de de ] ^ _ `a b _ h de s tu v v w { i i j kk lm n o k p i j ] j kk ^ kk lm _ lm n ` n o a o k b k q _ r c de ] ] ^ ^ ` ` a a b b f g de de ] ^ _ ` a b _ h de s tu v v w z i i j j kk kk lm lm n n o o k k p q i j y] ^ kk ^ _ lm _ ` ` a n a b o k b _ r _ c f de de ] ] ^ ^ ` ` a a b b g h de de l ² l p Figur 6.7: Fremgangsmåde ved konventionel konfigurator. Numrene i figuren svarer til numrene i beskrivelsen 5. En automatiseret opdatering fra konfigurator til dokumentation er næppe mulig. Det skyldes, at implementeringen i konfiguratoren ofte er præget af mindre struktureret kode, som ikke (eller med meget stort besvær) kan oversættes til dokumentationens diagrammer af en computer. Som det fremgår af beskrivelserne for de to scenarier, er fordelen ved anvendelse Fordele ved værktøj af et IT-baseret dokumentationsværktøj størst i det objektorienterede tilfælde, hvor en større del af arbejdet kan automatiseres. Der er dog stadig store fordele ved at anvende dokumentationsværktøjet i scenariet med den konventionelle konfigurator. For det første bidrager anvendelsen af klassediagrammer og CRCkort til en bedre strukturering af dokumentationen, og især med anvendelsen af klassediagrammet opnås et større overblik over produktmodellen og implementeringen i konfiguratoren. I beskrivelsen ovenfor under pkt. 3 fremgår det, at relationen mellem dokumen- Kompleks sammenhæng tationen og strukturen i konfiguratoren ikke er en-til-en, men kompleks. Ofte vil det f.eks. være nødvendigt at beskrive implementeringsdetaljer i almindelig tekst, hvilket let gør dokumentationen uoverskuelig. Alternativt kan man drage nytte af klassediagrammets overskuelighed og f.eks. benytte navnelighed mellem en klasse i træstrukturen i konfiguratoren og en klynge af klasser i klassediagrammet til at dokumentere en mere kompleks struktur. Et eksempel er givet i figur 6.8 på følgende side. 89

Kapitel 6 - Dokumentationsproces og kravanalyse Y1å êz í [ çiñ ì ë åiñ û ý ý û þ ÿ üõ ô õ ö ø ù ú û ü ö û ý ý û þ ÿ ÿ üõ ÿ ö ú ÿ ÿ ÿ ù ý ú ô ÿ ù ö ÿ ý ý ÿ ú ù ú û þ õ ý ÿ û ý ü û ý ú þ ÿ üý ù û ö ý üù þ ù þ ÿ PRQSTSTU V QXW V U äfå æ ç è é ê ë ì ë í å êiî ïmð ñ æ ë ò ó DE F G H I -. / 0 1 2 3 4 5 6 ) ø úú ÿ ú * ) ø úú ÿ ú + ),,,! "# $ % &' ( (( & ' 9 3 1 :1 ; ) ø úú ÿ ú * ) ø úú ÿ ú + ),,,! "# $ % &' ( (( & ' 7 8 / 3 ) ø úú ÿ ú * ) ø úú ÿ ú + ),,,! "# $ % &' (( ( &' A B 1 4> : 8 C 1 ) ø úú ÿ ú * ),,,! "# $ % &' (( ( &' < := 6 4 5 >.: 2? @ ) ø úú ÿ ú * ) ø úú ÿ ú + ),,,! "# $ % &' (( ( &' JKL M I N O Figur 6.8: Eksempel på anvendelse af komplekst klassediagram som dokumentation for implementering i en konventionel konfigurator I figuren ses en simpel produktmodel af et passagerfly, hvor der er fokuseret på flyets vinger. I konfiguratoren er vingen repræsenteret som en klasse i træstrukturen, og det er ikke umiddelbart nemt at overskue, hvilke andre klasser (og dermed f.eks. attributter og bindinger) der påvirkes, når indholdet af klassen Vinger ændres. Brug af klassediagram Bedre overblik Hvis man som i figuren dokumenterer implementeringen med et struktureret klassediagram, bliver overskueligheden noget bedre. Af klassediagrammet til højre i figuren fremgår det, at Vinger er en Vinge_krop bestående af en Overflade og et Skelet, der igen er relateret til Aluprofil_01. Af implementeringsmæssige årsager er disse klasser ikke nødvendigvis placeret i nærheden af Vinger i konfiguratorens træstruktur, men vha. klassediagrammet ses sammenhængen tydeligt. Endvidere ses det af klassediagrammet, at Vinger også er relateret til Flykrop, som i konfiguratorens træstruktur til venstre er placeret højere oppe. Laves der ændringer i Vinger, vil det måske have indvirkning mange steder i konfiguratoren, men med anvendelse af klassediagrammet bliver det lettere at få overblik over sammenhængen. 90

6.2 Den fremtidige proces 6.2.3 Udvikling vs. drift Arbejdet med dokumentationen stopper ikke, når produktmodellen er opbygget og lagt ind i en konfigurator. Snarere tværtimod, for når produktmodellen er implementeret i konfiguratoren, bliver det først rigtigt vigtigt at kunne overskue modellen for at kunne lave ændringer og tilføjelser. Arbejdet med dokumentationen stiller forskellige krav til et dokumentationsværktøj, afhængig af om man befinder sig i udviklings- eller driftsfasen. Karakteristisk for arbejdet i udviklingsfasen er, at man ønsker et værktøj, der Udviklingsfasen støtter op om udviklingsforløbet, og som samtidig er nemt og fleksibelt at arbejde med. På den måde kan man koncentrere sig om at opbygge produktmodellen og lade værktøjet udføre så meget som muligt af den administrative del af dokumentationsarbejdet. Dette kræver dog en gennemtænkt og -testet fremgangsmåde, som kan ligge til grund for arbejdet. I driftsfasen har man typisk to krav. For det første skal dokumentationen være Driftsfasen overskuelig og afspejle virkeligheden. Dvs. dette krav er faktisk et krav bagud til udviklingsfasen om, at dokumentationen skal opbygges med omhu. For det andet skal dokumentationsværktøjet gøre det let at navigere i dokumentationen. Dvs. det skal være let at overskue og genfinde, hvad man dokumenterede i udviklingsfasen. Dokumentationsværktøjet skal opfylde disse krav og understøtte dokumenta- Understøtte begge faser tionsarbejdet under såvel udvikling som drift. I udviklingsfasen vil udviklingsværktøjet lægge op til anvendelse af fremgangsmåden for opbygning af produktmodeller fra CPM, men det vil samtidig være muligt at bruge værktøjet på sin egen måde. Dokumentationsværktøjet vil i høj grad udføre mange af de administrative opgaver, som erfaringer fra produktmodelleringsarbejdet har vist, er en stor hæmsko. I driftsfasen skal dokumentationsværktøjet fungere dels som en effektiv struktureret søgemaskine, dels som et styringsværktøj for ændringer og rettelser (change management). Samtidig skal værktøjet kunne integreres med forskellige konfiguratorer og dermed lette arbejdet med at sikre, at dokumentation og implementation er ens. Dokumentationsværktøjet skal også kunne integreres med eksisterende informa- Integration med IT-systemer tionssystemer i virksomheden, og det skal være muligt at udveksle informationer med databaser i eksisterende ERP- og PDM-systemer. Typisk vil der være behov for at have let adgang til styklister, produktnumre, priser osv. Integrationen vil betyde, at disse informationer kan vises i f.eks. CRC-kortene, og ved at hente informationen fra de eksisterende informationssystemer sikres, at oplysningerne kun skal vedligeholdes ét sted. 91

Kapitel 7 Kravspecifikation Indhold af dette kapitel 7.1 Overordnet systembeskrivelse............ 94 7.1.1 Begrebsmæssig systemmodel............. 95 7.2 Projektarbejde og produktmodeller........ 99 7.3 Brugsmønstre...................... 101 7.3.1 Aktører......................... 102 7.3.2 Dokumentation af brugsmønstre........... 103 7.4 Specifikation af diagrammer............. 105 7.4.1 Elementer i Produkt-Variant Master......... 105 7.4.2 Elementer i klassediagram............... 107 7.4.3 Elementer på CRC-kort................ 108 7.5 Systemstruktur og diagrammer........... 110 7.6 Overgang fra dokumentation til konfigurator... 114 7.6.1 Kommunikation med Oracle.............. 116 7.6.2 Kommunikation med Baan.............. 117 7.6.3 Kommunikation med Cincom............. 118 7.6.4 Anbefaling til dokumentationsværktøj........ 118 7.7 Summering og prioritering af krav......... 119 7.7.1 Fleksibilitet gennem moduler............. 119 7.7.2 Prioritering af moduler................ 119 7.7.3 Prototype-skærmbilleder................ 121 I dette kapitel opstilles en kravspecifikation for et IT-baseret dokumentationsværktøj til produktmodellering. Specifikationen baseres på den forudgående gennemgang af CASE-værktøjer og PDM-systemer (kapitel 5 på side 47), gennemgangen af CPM s fremgangsmåde for opbygning af produktmodeller (kapitel 4 på side 33) og analysen af produktmodelleringsprocesserne hos fire danske virksomheder (kapitel 6 på side 69). Specifikationen støttes med brugsmønstre og et klassediagram for dokumentationsværktøjets centrale funktionalitet. 93

Kapitel 7 - Kravspecifikation 7.1 Overordnet systembeskrivelse I dette afsnit vil jeg give en overordnet beskrivelse af et forslag til, hvordan et dokumentationsværktøj bør opbygges. Forslaget tager udgangspunkt i analysen af de eksisterende dokumentationsprocesser og oplægget til den fremtidige proces (kapitel 6 på side 69), og sigter mod at tilgodese de opstillede krav fra afsnit 6.1.5 på side 79. OO-model som basis Et af de centrale krav er ønsket om en tættere kobling mellem de tre hovedelementer i dokumentationen. Ud af diagrammerne og CRC-kortene fremgår det, at det i vid udstrækning er den samme information, de indeholder. I dokumentationsværktøjet bør dokumentationen derfor håndteres som en objektorienteret produktmodel, der lagres i en central database. Ved at opbygge dokumentationen omkring en central databasebaseret produktmodel opnås flere fordele. F.eks. skal en del af informationen i dokumentationen hverken indtastes eller vedligeholdes af brugerne, men genereres og opdateres automatisk af dokumentationsværktøjet. Det gælder f.eks. information om relationerne mellem klasserne, der genereres automatisk ud fra strukturen i modellen. Fremgangsmåden fra CPM lægger op til, at PVM, klassediagram og CRC-kort med fordel kan anvendes som centrale elementer i brugergrænsefladen i værktøjet. CRC-kortet har allerede vist sin egnethed i bl.a. Niros og APC s Notesløsninger. I de samme løsninger har der også været stor tilfredshed med PVM ens hierarkiske struktur, som blev anvendt i Notes, mens man savnede de grafiske muligheder, en rigtig PVM giver. Klassediagrammet har ikke været anvendt primært på grund af begrænsningerne i Notes, men erfaringer fra Riis ph.d.- projekt og anvendelsen af fremgangsmåden i andre projekter samt de mangeårige erfaringer fra IT-verdenen har underbygget klassediagrammets berettigelse i en objektorienteret model. På den måde kan de velkendte grafiske elementer fra fremgangsmåden fungere som en visualisering af modellen og vil samtidig være den måde, hvorpå man navigerer rundt i modellen og tilføjer/ændrer information. Strukturelle ændringer foretages ved at ændre i PVM eller klassediagram, mens indholdsmæssige ændringer sker gennem CRC-kortene. Sammenhængen mellem PVM og klassediagram skal dog ikke være helt tæt, men PVM en skal snarere fungere som udgangspunkt for den videre modellering i klassediagrammet, jf. fremgangsmådens fase 2 og 3 (se afsnit 4.2 på side 38). 94

Ó 7.1 Overordnet systembeskrivelse Ž c i o œ imif dgf l mšhi Šž k f Ÿiš «eª ±²³² µ ±²³² µ ±²³² µ ±²³² µ ØgÙØ!v } y w ¹º»º¼½¾ ÀÁÂÃÄ ÅÆÇÈÉÊ ÀÁÂÃÄ ÅÆÇÈÉÊ {Ô Ë ÌÍÎ ÍÏ ÐÑ Ò ÕÖs u u q zs r y s «Ž Rhi k l f hi R R R R hi ghi R R R k dgf l hgjihgf ŒŽ Rmol dgf l mšhi hgjšhgf edi R o k f nr imš ik dgf Rk c e X œ Rmol df l m cedgf dihgf jik l mon ~ } r z p!q r s t r u v y u z} t u v u w x y z t r {! u w x y z t r ~ } r hi Š Rk f R R ª R k f R R k i š i Šd k f hihgjohf i ] ^ ƒ i ` a bx\ \X] ^ _ ` ] a b!\ ] ˆ Š ` ˆ a bx\! ` ] Ú Û ` Ü ƒ ^ ` ` ˆ ƒ ` ] ÜŠÝ ] ^ _ ` ] a bx\ Figur 7.1: Begrebsmæssig model for dokumentationsværktøj 7.1.1 Begrebsmæssig systemmodel I figur 7.1 er opstillet en begrebsmæssig model for dokumentationsværktøjet. Formålet med den begrebsmæssige model er at opsummere kravene og illustrere funktionaliteten i dokumentationsværktøjet og samtidig skitsere, hvordan de overordnede elementer hænger sammen. I det følgende vil komponenterne i modellen blive gennemgået sammen med en beskrivelse af funktionaliteten. For at lette læsningen bruges betegnelsen database for moduler, der retteligt burde betegnes DataBase Management System - DBMS. Produktmodeldatabase Den centrale database i dokumentationsværktøjet indeholder al information om produktmodellen, svarende til indholdet af PVM, klassediagram og CRC-kort samt de projektrelaterede oplysninger. I deres struktur har PVM en og klassediagrammet stor lighed med hinanden, og strukturen i produktmodeldatabasen skal derfor kunne udnytte denne lighed og dermed sikre en højere integritet. 95

Kapitel 7 - Kravspecifikation Brugerdatabase Hver klasse i modellen ejes af en bruger eller brugergruppe, som dermed er ansvarlig for at opdatere klassen. En bruger eller brugergruppe kan naturligvis eje flere klasser. Ændringsforslag til indhold eller struktur, der berører en given klasse, kan således ikke implementeres i modellen uden accept af ejeren af den/de berørte klasse(r). Som en del af datastyringen (se nedenfor) skal alle aktiviteter, der berører produktmodellen, registreres i en log, så ændringer til enhver tid kan spores til den udførende person. Brugerdatabasen indeholder oplysninger om alle brugere af dokumentationsværktøjet. Mange virksomheder har i forvejen oprettet brugerne af deres IT-netværk i brugerdatabaser, og det vil derfor være oplagt at forsøge at genbruge denne information i brugerdatabasen for dokumentationsværktøjet. Virksomhedsdatabaser Information skal kunne hentes fra eksterne databasesystemer. Meget af denne information skal direkte bruges i modelleringsarbejdet, mens andre blot vil være oplagte at have adgang til. Dataudvekslingen skal være baseret på modulær opbygning, så det er muligt at udvide systemet med understøttelse af databaser fra flere leverandører. Datastyring Adgangen til og håndteringen af informationen kræver et datastyringsmodul, der dækker over Adgangsstyring Håndtering af hvem, der har adgang til hvilke dele af modellen, og hvilke rettigheder de har. Baseres på oplysninger fra brugerdatabasen og rettighederne angivet for klasserne i modellen. De enkelte brugere skal kunne samles i grupper, og det skal være muligt at styre adgang på såvel gruppe- som brugerniveau. Versionsstyring Dokumentationsværktøjet skal kunne håndtere flere versioner af produktmodellen. Dette sker ved, at hvert CRC-kort kan gemmes i flere versioner. For hvert CRC-kort skal det derudover være muligt at angive, hvilken version af kortet der p.t. er implementeret i konfiguratoren. Yderligere skal det kunne angives, at et CRC-kort er under udarbejdelse eller blot passivt. På den måde kan produktmodellen virke som parkeringsplads for gode idéer til forbedringer (fra f.eks. domæneeksperterne), og disse idéer kan siden ophøjes til implementering. Log Alt arbejde på modellen skal registreres i en log. Laves ændringer i modellen, skal det automatisk fremgå, hvad der er lavet, hvornår og af hvem. Logik Specifikation af forretningslogik, dvs. regler og retningslinjer for hvordan datatransaktioner skal håndteres (f.eks. at når en klasse slettes, skal klassens relationer også slettes). 96

7.1 Overordnet systembeskrivelse Brugergrænseflade (GUI) Dette er brugerens kontaktflade til systemet. Systemet skal understøtte flere samtidig brugere, og at disse tilgår systemet via internet. Hermed lægges op til, at brugergrænsefladen overordnet kan implementeres på to måder. Enten kan man vælge en løsning, hvor brugeren arbejder med værktøjet gennem en browser (tynd klient), eller også kan vælges en løsning, hvor værktøjet afvikles på brugerens computer og blot kommunikerer med en central server over internet (tyk klient). Med begge løsninger sikres, at brugerne kan arbejde sammen om en produktmodel uafhængigt af deres geografiske placering. Overordnet kan brugergrænsefladen inddeles i to dele: en administratordel og en brugerdel. Administratordelen bruges til at administrere systemet (håndtere brugere, tildele adgangsrettigheder, tilrette skabeloner osv.) og tiltænkes således ikke brugt ofte. I bilag F på side 259 er lavet et scenarie for brugen af systemet suppleret med prototyper af skærmbilleder. Brugerdelen derimod skal bruges konstant under arbejdet med systemet. Grafisk skal denne brugergrænseflade baseres på de grafiske elementer, der indgår i fremgangsmåden, hvilket vil gøre værktøjet nemt at gå til. Dette omfatter primært PVM, CRC-kort og klassediagrammer. Det bærende koncept i udformningen af brugergrænsefladen vil være en afspejling af arbejdet med fremgangsmådens grafiske elementer, som brugerne forudsættes kendskab til. At arbejde med dokumentationsværktøjet bliver således ikke grundlæggende anderledes end at arbejde med PVM, CRC-kort og klassediagram på papir eller i et diagrammeringsprogram. Til gengæld tilføjes en stor del ny funktionalitet som følge af den tættere integration af elementerne. Mange virksomheder har eksisterende dokumentation liggende i forskellige dokumenter. Dette drejer sig f.eks. om resultater af funktionstest, ingeniørberegninger eller andet relevant materiale. I PVM og CRC-kort skal det være muligt at lave referencer til denne eksterne dokumentation. Dette betyder, at man i alle tekstfelter kan indsætte links, og i CRC-kortene kan oprettes nye brugerdefinerede felter, hvori der kan indsættes referencer til dokumenterne. Det er ikke hensigten, at dokumentationsværktøjet skal understøtte visning af indholdet af de eksterne dokumenter. Hertil skal benyttes de dedikerede programmer. På denne måde vil dokumentationsværktøjet med en simpel funktionalitet virke som et samlende system for et produkts samlede dokumentation. Sproget i dokumentationsværktøjet skal være engelsk. DBMS-kommunikation Et modul, der håndterer opgaven med kommunikation til alle interne såvel som eksterne databaser (eller rettere DataBase Management Systems). For at give bedst mulig fleksibilitet i forbindelse med vedligeholdelse og udbygning af dokumentationsværktøjet bør en struktureret arkitektur som treskemaarkitekturen anvendes ved implementering af databasestrukturen [Sadoski og Comella-Dorda, 2000]. 97

Kapitel 7 - Kravspecifikation Tredjepartssystem Dækker over alle eksterne systemer (på nær DBMS er), som systemet skal kommunikere med. P.t. er dette primært konfiguratorer. Kommunikation med ERPsystemer vil primært foregå gennem DBMS-kommunikation-modulet. Udvekslingen af data med konfiguratorer er yderligere behandlet i afsnit 7.6 på side 114. Eksport- og importmodul Modulet vil give mulighed for at eksportere (store dele af) modellen til et tredjepartssystem som f.eks. en konfigurator. Den umiddelbare fordel er, at en masse arbejde spares ved, at informationen i produktmodellen ikke skal indtastes manuelt i konfiguratoren. Dette minimerer samtidig risikoen for fejl ved indtastningen. Den anden fordel følger delvist af den forrige. Ved at gøre overgangen fra design (og dermed dokumentation) til implementering lettere lægges op til, at produktmodellen i dokumentationsværktøjet fungerer som hovedmodel, og at modellen i konfiguratoren afspejler hovedmodellen. Ultimativt laves alle ændringer i dokumentationsværktøjet, og derefter opdateres konfiguratoren relativt let. En mulighed i fremtidige versioner af dokumentationsværktøjet vil være at understøtte en slags reverse engineering ved at lave import-moduler, så man kan indlæse konfiguratorers produktmodeller i dokumentationsværktøjet. Eksportmodulet skal være modulært opbygget, så det er muligt at udvide dokumentationsværktøjet med mulighed for at eksportere til konfiguratorer fra flere leverandører. En plan for det videre forløb ville her være at etablere og udbygge samarbejdet med leverandører af konfiguratorer og løbende udvikle nye moduler til integration med nye konfiguratorer. Rapportgenerator En veludbygget produktmodel indeholder anseelige mængder information, som er vanskeligt at overskue. En rapportgenerator skal gøre det muligt at generere rapporter baseret på informationen i de tilknyttede databaser. Brugerne skal kunne tilpasse rapporterne, så de indeholder den relevante information, og det skal være muligt at definere rapportskabeloner. Rapportgeneratoren kan også bruges til at generere en encyklopædi for produktmodellen, dvs. en rapport over alle navne på modellens klasser, metoder, attributter etc. med tilhørende beskrivelse. På den måde kan skabes en oversigt over modellens elementer, og man kan hurtigt finde navnet på en ønsket klasse. Kommunikationssystem Eksternt system, der kan kommunikere med brugerne af dokumentationsværktøjet f.eks. via e-mail (det eksterne system vil da være en mailserver). 98

7.2 Projektarbejde og produktmodeller Meddelelsesmodul Modulet skal virke på en sådan måde, at der genereres en elektronisk meddelelse til de implicerede, f.eks. via virksomhedens e-mail-system (Notes, Outlook etc.). Kommunikationen bliver derved aktiv (informationen sendes til modtageren) og ikke passiv (modtageren skal opsøge informationen, f.eks. på en hjemmeside). Dette kræver samtidig, at man er bevidst om brugen af modulet, så der ikke sendes for meget information, men kun nødvendige meddelelser. Med modulet er det muligt at tilpasse værktøjet, så det understøtter arbejdsgangen i den enkelte virksomhed. Hvis man f.eks. har en politik om at revidere modellen hver tredje måned, kan modulet hjælpe ved at gøre brugerne opmærksom på, hvor deres opmærksomhed er påkrævet og henvise til det pågældende område i dokumentationen. Modulet kan konfigureres til, hvilke kombinationer af hændelser (klassers status, tid, ændringer osv.) der skal genere meddelelser og til hvem, hvormed virksomhedens arbejdsgang understøttes. Udskriftsmodul De tre hovedelementer i dokumentationen (PVM, CRC-kort og klassediagram) skal kunne udskrives på tilsluttede printere printere via operativsystemet. Især gælder det, at PVM en og klassediagrammet skal kunne udskrives i stort format. Dokumentationsværktøjet skal derfor understøtte - Udskrivning af store dokumenter på en alm. printer fordelt over flere sider ( tiled pages ), så udskrifterne kan sættes sammen med tape. - Udskrivning af store dokumenter på en storformatprinter (f.eks. plotter). Herudover skal det være muligt at udskrive de forskellige rapporter. 7.2 Projektarbejde og produktmodeller Produktmodelleringsarbejdet følger ofte en projektlignende arbejdsform (især i udviklingsfasen), og i forrige afsnit blev derfor lagt op til, at dokumentationsværktøjet skal indeholde funktionalitet til adgangsstyring på såvel bruger- som gruppeniveau. Projektarbejdsformen rejser en problemstilling omkring lagringen af informatio- Adgang til produktmodel nen i en produktmodel, nemlig hvordan adgangen til disse data skal håndteres. Det centrale spørgsmål er, hvorvidt information fra alle virksomhedens produktmodelleringsprojekter skal lagres i én central produktmodel, eller om informationen fra hvert projekt skal lagres i separate produktmodeller 1. Situationen er illustreret i figur 7.2 på følgende side. 1 Her tænkes kun på repræsentationen over for brugeren af systemet og ikke på den fysiske model, hvor al information givetvis vil blive lagret i samme database. 99

F G Kapitel 7 - Kravspecifikation Þoß à!á âã ägæ ó ó õ ÿ ù ý ýù õ û ÿ ù ñ ò ñ ó ô õ ö ø ö ý ÿ ö ó ø ù ú ûñ ü ûý ù þ ö ÿ ó ÿ õ þ ÿ ö Þ ß à!á âã äoå A B çè é êë ì í îœé êrïrð 819;=< >@? AED (a) Én samlet produktmodel %&"!!"#$ 8:9;=<>@? ACB ')(*,+.-./1023*,+.465 '7(*,+.-,/1023*,+,465 (b) Én produktmodel pr. projekt Figur 7.2: Adgang til information i produktmodel på tværs af projekter Figur 7.2 viser et eksempel med to projekter, hvor der i begge skal bruges et CRC-kort for en bestemt motor. I projekt A skal opbygges en konfigurator, der har fokus på logistik og forsendelsesomkostninger, mens man i projekt B sigter mod en konfigurator til konfigurering af motoren efter ønsker om ydeevne. Således spiller motoren to forskellige roller i de to projekter. Samlet produktmodel Opdelt produktmodel Vælges løsningen i figur 7.2(a), opnås den fordel, at der kan trækkes på eksisterende strukturer af klasser. Som nævnt i kapitel 3 er en af de store fordele i det objektorienterede paradigme netop den oplagte mulighed for genbrug, som kan spare tid i udviklingsprocessen. Ulempen er dog, at de mange klasser, der ikke er inkluderet i et givet projekt, hurtigt kan forringe overskueligheden. Samtidig vil det være et problem, at en given klasse kan have forskellige attributter, metoder eller noter tilknyttet alt efter projektet (illustreret med CRC-kortet for motoren). Klassen spiller således en unik rolle fra projekt til projekt. En bedre løsning er derfor at arbejde med opdelte produktmodeller som illustreret i figur 7.2(b). I denne løsning har hvert projekt sin egen produktmodel tilknyttet, og en klasse i produktmodellen kan kun redigeres i det pågældende projekt. Egenskaber for en klasse, der er fælles på tværs af projekter (part- 100

7.3 Brugsmønstre nummer, beskrivelse, typegodkendelser), kan med denne løsning lagres i ERPsystemets database og linkes til den enkelte klasse vha. DBMS-modulet. For at give mulighed for genbrug på tværs af projekter skal det dog naturligvis være muligt at søge i dokumentationen for andre projekter og kopiere klasser og klassestrukturer. Adgangsstyringsmodulet skal her sikre, at det ikke er muligt at redigere klasser i et andet projekt. 7.3 Brugsmønstre Sammenholdes kravene fra forrige kapitel med aktiviteterne i CPM s fremgangsmåde for opbygning af produktmodeller (se evt. IDEF0-diagrammet i bilag B på side 167), kan en række brugsmønstre identificeres (brugsmønstre blev behandlet i afsnit 3.3.1 på side 24). Som et første udkast til brugsmønstre har jeg valgt at fokusere på de centrale Fokus på centrale aktiviteter aktiviteter omkring håndtering af dokumentationen. Et overordnet brugsmønsterdiagram er vist i figur 7.3. I diagrammet indgår fire undersystemer (Administration, PVM, CRC-kort og Klassediagram) illustreret ved klynger. Disse undersystemer er detaljeret i selvstændige brugsmønsterdiagrammer i bilag D på side 197. Dokumentationsværktøj Administration Log på systemet Administrator Log af systemet Definér rapportskabelon «uses» Udskriv Domæneekspert Vis rapport Tiden PVM CRC-kort Kommunikationssystem Modellør Klassediagram Konfigurator Figur 7.3: Brugermønsterdiagram for dokumentationsværktøj 101

Kapitel 7 - Kravspecifikation 7.3.1 Aktører Af figuren fremgår det, at der i alt er identificeret seks aktører som brugere af systemet. Husk på, at opdelingen i aktører hentyder til roller frem for fysiske personer eller systemer. Den samme person eller system kan således godt have rollen som flere aktører. Modelløren er den primære bruger, som med værktøjet opbygger en produktmodel på basis af den information, der er indsamlet hos domæneeksperterne. Modelløren har både IT-teknisk indsigt og er specialist i produktudvikling og -modellering. Herudover har modelløren erfaring med implementering i konfiguratorer. Til gengæld er modelløren ikke nødvendigvis specialist inden for det modellerede produkt. På større projekter vil der være tale om en gruppe af modellører, der deler opgaverne imellem sig. Modellørerne har adgang til at ændre i produktmodellen. Domæneeksperten har den faglige indsigt i det modellerede produkt, men har ikke nødvendigvis indsigt i produktmodellering og konfiguratorer. Ofte er der for et produkt tale om en gruppe af domæneeksperter, der hver især har indsigt i en del af produktet. Formålet med at gøre domæneeksperten til bruger af værktøjet er at uddelegere ansvaret for, at konfiguratoren er opdateret. Domæneeksperten kan ikke ændre i modellen, men kan se indholdet og komme med ændringsforslag. Administratoren tager sig af konfigurering af systemet. Arbejdsbyrden er størst i forbindelse med opstart af nye projekter, og opgaverne er helt adskilt fra den egentlige produktmodellering. Konfiguratoren repræsenterer virksomhedens konfigurator, som skal udveksle information med dokumentationsværktøjet. Kommunikationssystemet varetager afsendelse og modtagelse af meddelser fra dokumentationsværktøjets meddelelsesmodul. Over for dokumentationsværktøjet er kommunikationssystemet passivt, idet det kun modtager ordrer og ikke selv initierer hændelser i dokumentationsværktøjet. Tiden bruges til at igangsætte forskellige hændelser og er dermed også en aktør [Whitten et al., 2001]. 102

7.3 Brugsmønstre 7.3.2 Dokumentation af brugsmønstre Brugermønstre beskrives uden hensyntagen til implementeringsmæssige aspek- Uafhængigt af implementering ter for at klarlægge forudsætningerne før brugermønsteret, handlingsrækkefølgen i brugermønsteret og resultatet af udførelsen. Alle brugsmønstrene er dokumenteret ved en beskrivelse inspireret af opstillingen i Whitten et al. [2001, s. 662] og findes i bilag D på side 197. I alt er der identificeret over 40 brugsmønstre, hvilket vidner om kompleksiteten af dokumentationsværktøjet. For at forbedre overskueligheden er brugsmønstrene grupperet i fem grupper: - Topniveau Brugsmønstre, der har generel anvendelse eller benyttes på tværs af klyngerne. - Administration Undersystem indeholdende brugsmønstre, der anvendes ved administration af dokumentationsværktøjet (oprettelse af brugere mv.). - PVM Undersystem indeholdende brugsmønstre, der anvendes ved arbejde med PVM en (oprettelse af part-of klasser mv.). - CRC-kort Undersystem indeholdende brugsmønstre, der anvendes ved arbejde i CRCkortene (ændring af metoder, attributter mv.). - Klassediagram Undersystem indeholdende brugsmønstre, der anvendes ved arbejde med klassediagrammer (redigering af relationer mv.). Ud fra brugsmønsterdiagrammerne fremgår det, at klyngen CRC-kort indeholder mange centrale brugsmønstre for dokumentationsprocessen, hvilket understreger, at CRC-kortet har en central rolle i arbejdet med dokumentationsværktøjet. Udarbejdelse af beskrivelserne for brugsmønstrene har bidraget til at afdække Iterativ afdækning af krav nogle brugsmæssige aspekter for dokumentationsværktøjet. Bl.a. at flere scenarier, der umiddelbart er forskellige, viser sig at være meget ens (f.eks. oprettelse af klasser i brugsmønster nr. 3.6 på side 219 og nr. 5.7 på side 248), og at nogle scenarier baseres på antagelser, som kræver en yderligere specifikation (f.eks. import af struktur fra PVM til klassediagram i brugsmønster nr. 5.11 på side 252). Blandt brugsmønstrene er der identificeret otte vigtige antagelser, som skal afklares (se tabel 7.1 på følgende side). I afsnit 7.2 på side 99 blev det nævnt, at produktmodellering ofte udføres som projekter. Inden for et projekt er det muligt at arbejde med flere klassediagrammer og PVM er, men da kun én version af hvert CRC-kort kan have status som implementeret, findes der også kun ét muligt klassediagram, som afspejler implementeringen. 103

Kapitel 7 - Kravspecifikation Brugsmønster Antagelse Afklaring 1.3, side 202 1.4, side 203 Information kan trækkes fra produktmodeldatabasen vha. et formaliseret forespørgselssprog (SQL). 1.5, side 204 Der kan udskrives via operativsystemet via en veldefineret grænseflade. 2.5, side 210 Det er muligt at lave link til ekstern database og forespørge via SQL. 2.7, side 212 4.12, side 235 4.13, side 236 Det er muligt at sende meddelelser via et eksternt kommunikationssystem. 5.1, side 242 Det er muligt entydigt at definere, hvordan produktmodellen skal overføres til konfiguratoren. 5.2, side 243 Det er muligt at tilgå konfiguratorens database. 5.10, side 251 Det er muligt at definere en algoritme for optimal placering af elementerne i et klassediagram. 5.11, side 252 Det er muligt entydigt at definere, hvordan PVM overføres til klassediagram. Tabel 7.1: Antagelser i brugsmønstre Anses ikke som et problem, idet langt størstedelen af databaser understøtter forespørgsler via SQL. Anses ikke som et problem for implementering under MS Windows, som understøtter udskrivning via et veldefineret API. Anses ikke som et problem, da de mange databasesystemer understøtter dataudveksling via et API (f.eks. ODBC). Anses ikke som et problem, da mange kommunikationssystemer understøtter afsendelse af e-mail via POP3-protokollen. Alternativt kan nemt installeres en (gratis) mailserver. Er en central problemstilling, som skal afklares for hver enkel konfigurator. Behandles i afsnit 7.6 på side 114. Er en central problemstilling, som skal afklares for hver enkel konfigurator. Behandles i afsnit 7.5 på side 110. Anses ikke for et problem, da der eksisterer adskillige flowchartprogrammer, der kan håndtere denne funktionalitet (bl.a. MS Visio og Rational Rose). Er en central problemstilling, som skal afklares. Behandles i afsnit 7.5 på side 110. 104

7.4 Specifikation af diagrammer 7.4 Specifikation af diagrammer Med PVM, klassediagram og CRC-kort som de centrale elementer i et dokumentationsværktøj er det vigtigt at få afklaret præcist, hvad der menes med disse tre begreber. Som det fremgår af afsnit 4.3 på side 40 og gennemgangen nedenfor, er der ikke en konsistent definition af udseendet af de tre elementer: - i PVM en bruges forskellige symboler for de samme ting, - i klassediagrammet er symbolikken fastlagt i forhold til UML, men det er ikke afklaret præcist, hvilke elementer der skal anvendes (der er f.eks. flere typer relationer, der ikke benyttes), og - CRC-kortet er løbende blevet udviklet og tilpasset de enkelte projekter. Med henblik på den fremtidige brug af et dokumentationsværktøj er eksisterende CRC-kort, PVM er og klassediagrammer blevet gennemgået. Dette har dannet basis for en vurdering af, hvilke elementer der bør indgå i de tre diagrammer. Resultatet er gennemgået nedenfor og illustreret i figurerne. På baggrund af PVM, klassediagram og CRC-kort er vurderet, hvordan information og struktur bør lagres, og som dokumentation herfor er opbygget et klassediagram fokuseret på den underliggende objektorienterede database. 7.4.1 Elementer i Produkt-Variant Master I afsnit 4.3.1 på side 40 blev PVM en gennemgået. Den grafiske fremstilling af elementerne i strukturen har antaget forskellige former, men den grundlæggende struktur og tankegang er meget ens. Grafikken i det følgende er baseret på Harlou [1999], men også inspireret fra andre kilder i enkelte detaljer (se f.eks. Andersen og Jensen [2001]; Mortensen et al. [2000]). I figur 7.4 på følgende side er vist et bud på en PVM med alle elementer. Elementerne gennemgås nedenfor. 105

Kapitel 7 - Kravspecifikation Klasse 0 Topklasse Attribut (med værdiområde) Attribut 1 [rød, grøn, blå] Kol 1 Kol 2 1-1 Noget tekst 1-2 Mere tekst... 2-1 Mere tekst... 2-2 Mere tekst... Note (tabel) Klasse Attribut 2 [3..25] Illustration [ 2 ] Klasse 1 Binding [ 2..8 ] Klasse 2 Kind-of relation [ 1.. ] Klasse 3 Part-of relation (med kardinalitet) [ 4 ] Klasse 4 Attribut 3 [0,1] Attribut 4 [0..999] Notetekst notetekst notetekst notetekst notetekst Klasse 5 Klasse 6 Klasse 7 [ 4 ] Klasse 8 Attribut 5 [3,4,7] Note (tekst) Figur 7.4: Eksempel på Produkt-Variant Master (PVM) med alle anvendte elementer Topklasse Produktet, der modelleres. Klasse Fællesbetegnelse for objekter med ens karakteristika. På PVM en vises en klasses metoder ikke, men disse kan tilføjes og redigeres via CRC-kortet (åbnes ved klik på en klasse). Attribut Data, der beskriver egenskaber for klassen. For hver attribut kan angives værdiområder som liste (f.eks. [blå,gul,grøn] eller [1,3,6]) eller interval (f.eks. [0..99]). Relationer PVM en indeholder to relationer. - Part-of Strukturering i klasser og underklasser. Underklasserne kan deles mellem flere overklasser ved, at en underklasse medtages flere gange i PVM en, og det er således ikke muligt at lave en entydig sammenhæng mellem part-of relationerne til enten en svag eller stærk aggregeringsrelation i et klassediagram. For hver relation kan angives kardinalitet (f.eks. [1..*] eller [4]). - Kind-of Strukturering i klasser og deres varianter. En variant kan være en enkelt klasse eller en part-of struktur. Binding En binding kan gives en tekst, som valgfrit kan vises på PVM en. Illustration Illustrationer kan vises på PVM en. Note Mulighed for at tilføje noter og tabeller til diagrammet med valgfri tekst. I noteteksten kan indsættes referencer til eksterne dokumenter eller ressourcer (hyperlinks), og ved at klikke på referencen åbnes den eksterne ressource i en passende applikation. 106

P P O P O P 7.4 Specifikation af diagrammer 7.4.2 Elementer i klassediagram I afsnit 4.3.2 på side 42 blev klassediagrammet gennemgået. Elementerne i et klassediagram til produktmodellering er som nævnt identisk med UML-notationen for klassediagrammer (se afsnit 3.3.2 på side 25). Dog anvendes typisk ikke nær så mange elementer, og efter gennemgang af flere produktmodelleringsprojekter i samarbejde med ph.d.-studerende på IPL er jeg kommet frem til, hvilke elementer et klassediagram i et fremtidigt dokumentationsværktøj skal indeholde. I figur 7.5 er vist et eksempel på et klassediagram til produktmodellering indeholdende disse elementer. m T]f]^TWy] z ]q]fovul]fuqp e ll^xuotu^q ƒw 1 ˆ RSTUVUTWX HYIKLLM1Z HJIKLLM:N HJIKLLM1i H=IKLLM1Q m Tvwfk oppf]p]fuqp j]klt ase]_:t]qnulquqpb r ^T] m nop1oppf]p]fuqp de TTfUgST` [\E]T^_]1cab [\E]T^_]C`ab TTfUgSTc H=IKLLMEh {C }=~YJ u Voll] e TTfUgST \E]T^_] Figur 7.5: Eksempel på klassediagram med alle anvendte elementer j]s o u VWqp] Klasse Fællesbetegnelse for objekter med ens karakteristika. Metode Formaliseret beskrivelse af klassens opførsel. Metoderne opdeles i to typer: klassemetoder og systemmetoder. De første er metoder, der beskriver klassens opførsel i forhold til andre klasser (typisk bindinger). De andre er metoder, der beskriver klassens opførsel i forhold til systemet og eksterne systemer (f.eks. interaktion med et ERP-system). Attribut Data, der beskriver egenskaber for klassen. Stereotype En udvidelse/tilpasning af UML-notationen til en given kontekst. En modellør kan f.eks. angive en stereotype for en klasse for at vise, at det grafiske element repræsenterer et mere specifikt element (f.eks. en grænseflade, en part etc.). Relationer For de fire første relationer kan angives mangfoldighed i hver ende. For alle relationer kan relationen beskrives i begge retninger. - Aggregering, svag Relation mellem klasser til opbygning af whole-part strukturer, hvor klasserne eksisterer uafhængigt af hinanden. - Aggregering, stærk Relation mellem klasser til opbygning af whole-part strukturer, hvor klassernes eksistens afhænger af hinanden. Klasser lever og dør med hinanden. 107

Kapitel 7 - Kravspecifikation - Association Simpel relation mellem klasser for at sikre, at klasserne kender til hinandens eksistens og kan kommunikere med hinanden (lave metodekald og tilgå offentlige attributter). - Generalisering Relation mellem klasser til opbygning af nedarvningsstrukturer. Tema Mulighed for gruppering af klasser i overskuelige enheder. Klynge Mulighed for at opdele klassediagrammet i underdiagrammer, hvor indholdet skjules på det overordnede diagram. Note Mulighed for at tilføje noter til diagrammet med valgfri tekst. Noten kan efter valg relateres til et andet element med en stiplet linje. I noteteksten kan indsættes referencer til eksterne dokumenter eller ressourcer (hyperlinks), og ved at klikke på referencen åbnes den eksterne ressource i en passende applikation. 7.4.3 Elementer på CRC-kort I afsnit 4.3.3 på side 43 blev CRC-kortet gennemgået. CRC-kortet fungerer som detaljeret dokumentation for klasserne i PVM og klassediagram, og med baggrund i inspiration fra Andersen og Jensen [2001]; Hvam og Riis [1999] og de praktiske erfaringer fra Notes-løsningerne hos APC og Niro er jeg kommet frem til, at et CRC-kort bør have en opbygning som vist i figur 7.6. 1 œ žÿ 1 œ œ J @œ Š Æ ² E Š Å ² :Œ=ŒJŠ ŒJ ± ² ³ Š =Œ ª «: µ ²² Šœ Š =Œ š«²² 1 Š»¼:½¾ µš Š ¾»¼:½¾ µš ¹6 =ºJ Š ¾ YÀ š«á «Â šy 1Š Œ= ŠŽ @à ÄÄÄ š 1Š Œ= ŠŽ J ÄÄÄ š Figur 7.6: Eksempel på CRC-kort med alle felter 108

7.4 Specifikation af diagrammer Klasse-ID Et unikt ID for hver klasse. Klassenavn Et valgfrit, men dog unikt navn for hver klasse. Dato Dato for oprettelsen af klassen. Klikkes på feltet, gives adgang til at se historikken for klassen. Ejer Navn på personen, der har oprettet denne klasse. Klikkes på feltet, gives adgang til at se en oversigt over, hvilke personer der har rettigheder til at tilgå klassen. Beskrivelse Består af en beskrivelse af klassen i ren tekst og mulighed for at indsætte et valgfrit billede. Aggregering Oversigt over klassens position i en evt. aggregeringsstruktur (både stærke og svage). Består af viser de underliggende klasser (parts), som klassen består af, mens Er del af er en oversigt over de(n) overliggende klasse(r) (wholes), som klassen er en del af. Generalisering Oversigt over klassens position i et evt. generaliseringshierarki. Overklasser dækker over de klasser, som klassen arver fra, mens Underklasser er en liste over de klasser, som nedstammer fra klassen. Klikkes på en klasse, åbnes CRC-kortet for den pågældende klasse. Attributter En oversigt over klassens attributter. Ved klik på attributten vises al information om attributten. ID - Navn viser attributtens unikke ID og valgfrie navn, mens Note viser den valgfrie notetekst. Metoder En oversigt over klassens metoder med indikation af metodens art som enten system- eller produktmetode (se afsnit 4.3.2 på side 42 for skelnen mellem metoder). Ved klik på metoden vises al information om metoden. For produktmetoder vises metodens tekst (f.eks. fri tekst eller OCL), og for systemmetoder vises beskrivelsen. Som for attributter viser ID - Navn metodens unikke ID og valgfrie navn. Relation til viser, hvilke andre klasser metoden påvirker/påvirkes af. Brugerfelt Brugerdefineret felt bestående af et vilkårligt antal variable. Der kan oprettes et vilkårligt antal brugerfelter, men felterne er fælles for alle CRCkort i modellen, på samme måde som hvert CRC-kort har feltet Klassenavn. Tankegangen bag brugerdefinerede felter er inspireret af APC s behov for at trække på information fra eksterne databaser (baseret på Stock Keeping Unit (SKU)-numre). I figur 7.7 på følgende side er vist et eksempel på APC s visning af SKU-detaljer, og i figur 7.8 på side 111 er eksemplificeret, hvordan dette tænkes implementeret i dokumentationsværktøjet ud fra CRC-kortet fra figur 7.6 på foregående side. 109

Kapitel 7 - Kravspecifikation Figur 7.7: Anvendelse af SKU-numre på CRC-kort hos APC 7.5 Systemstruktur og diagrammer På baggrund af de foregående analyser og gennemgange har jeg opbygget et klassediagram, som illustrerer strukturen for den underliggende produktmodeldatabase, hvori alle informationer for en produktmodel lagres. Klassediagrammet er vist i figur 7.9 på følgende side. Klassediagrammet findes også i bilag E på side 253 sammen med en encyklopædi for klassediagrammet. Formålet med klassediagrammet i figur 7.9 er at lave en struktur, der på den ene side repræsenterer al den nødvendige information og samtidig strukturerer det på en fornuftig måde, så den ønskede funktionalitet og integritet kan opnås. I det følgende vil jeg gennemgå sammenhængen mellem diagrammerne og CRCkort og sammenhængen med elementerne i klassediagrammet i figur 7.9. I gennemgangen bruges skrivemaskine skrifttype til at fremhæve ord med reference til det centrale klassediagram i figur 7.9 på følgende side. Eksempelvis vil Illustration henvise til hele klassen Illustration i klassediagrammet, mens Brugerfelt.Navn henviser til attributten Navn i klassen Brugerfelt. 110

O t t wt w t t w t t t t t w @8ABB6CDEF@8ABB6?AG? 26BL3<G68B6 EA9HJIK63 [6LB9 ZL<9B6 ;5536563<?5 26B9P3A7O I3N68A7O M6?63A8<B63<?5 QG63L8ABB63OSR?N63L8ABB63 ;993<=49963 DE CUAG? UH96 T69HN63 DE CUAG? UH96 <?NWH8N V X68A9<H?9<8 ;993<=49> 2345637689> ;993<=49: YYY ;993<=49? 2345637689: ;993<=49> ;993<=49: YYY ;993<=49? û ùýû- # û #. ÇÈÉÊËÌÍYÎÏÉÐÑÒÓÔ ØJÙ@Ú ÛYÜÝÞßàá *ùø+ù ûûù#,øû û, - /,ùø+ù ûûù#,øûûùüù ýûú ü/úù,ùø+ù 0 $. 0 û# ù # ê ùû 'ø -$, ùú+ ûû éêëëìì ÑÒÓEÕÖ Ï ÇÉâãÌäÊå=ÈæÈçÏÉ éþÿ å=âãïèëèíeï ú -$- û 1 íîïîðñíòó ôõ ö øù Yõ ùúûüúýý øû ì øû øû ëçéâãìäêóç =ÉÈäèÏYÑÊÈÊÌ Yÿ ÏâçÉÈ ä!èèèîèêö &Ïçâæ øùú "$# ÑÊÈÊÏ (ÇÉâ û éýù#% 'é"! æäï âìæêéï " é )êééöé " âíyí@ïæê ÿ %ûýúù " é 7.5 Systemstruktur og diagrammer Figur 7.8: Eksempel på brugerdefineret felt i CRC-kort g` } b c { h c c¹º º \ ƒ} a ¹ c {ƒ c{ gv c a\ ik a`» j} a c { c `{ a ƒc h } a ¼ c aj} } h ` `} ae`b{ƒ} b c c h _ v ^ c \ kc ½ ¾ ÀeÁ šš c c ah {{ `}  à ~$]e k ¹ ž ~$fkyk ž { Ä Â Åe inggc¹b g^ h h c a œ ^ a c { `b $xy v y$c cƒc a c g^ ^ j œ c { h ˆ { `g } _ c ah b c g` œ c c { v e \xy \z$^ \ ˆ _ c{ \z$} \] k c \ ˆ { g` d b h e} } gc ^ { ªkŽ Œ rm eo \ $c \ g~$xÿ d feg^ h h c \z$} ˆ c \ c ˆ { g` \ ƒ t g ~$ \ c h b t š $} c h b c a~ ž uevvw lnmo p q Ÿ $ rž ± qe± Ž r pež š nœ b ˆ { ^ b h ž lnmo p q rs r \] ^^ ^ ^ `ab cc haed ikjfeg^ d feg^ h h ch h c u vvw \ \ $`g ªkŒ c Ò g c Ò š y$^ { Æ{ $«r a $^ c g` Œ œ Ç } a ž c Ž o u vvw Šn Œ Ž \xy \y$^ \z$^ } _ { \ c a ~$} a \ \ ƒc c e $c ac } ˆ ^ cb eac a \z$} \ $b ` h c \f } { cc \ ^ hb h \feg^ \z$^ _ š È» h Šn { { h f$yk ž c o `^ Ž a^ Ì r«œ rm $o \ \ ˆ aac c gh c t \ \] š ` } h ` `} { c { ž \zk^ Šn Œ šeµ š c _ g { Ž pemœ e«œ ± É Ê Ë { ~$fkyk ž š $c a`j`² c \ \zk^ a ž š š ec } _ eb b{ h {~n] g^ h h } a ž $ ¹ ž c d feg^ h h c t š $c a`j`² c a ž w u vvw k rž \z$^ \ c b_ h { \ $c g~nxy d yk`^ a^ ~ c gc ƒc { uevvw u vvw É$«ÐŽ r \z$^ \ c h_ b{ \]ea} c a`_ b gc c gh cc \y$^ } ~ } a a t vvw u vvw Ï Ž ± Œ \z$^ _ { t Înrr«mÇ r \ \z$^ ˆ _ c{ \z$} \x{ ` `^ c g $ Æa ` u vvw \ e{ \ $ Æa œ c `º ƒa c \in{ \z$^ ln«^ _ { gi$ a Ž «Ž r tw ln«ž «Œ rr«mç r \z$^ \ $ Æa _ { \x{ $d ` } } gc ^ { \]eg^ \ e² a` ³nln mo š k`h ² y$^ c a`{ ^ ž Í s r³n ± Ž o r \ š È `» { yk} b c { ž ln«ž «p Œ rœ Ñ eç Œ Ž p Œ rœ Figur 7.9: Klassediagram, der viser et forslag til den underliggende produktmodelmodeldatabase 111

Kapitel 7 - Kravspecifikation PVM og klassediagram I afsnit 7.3.2 på side 103 blev lagt op til, at overgangen fra PVM til klassediagram skulle specificeres. Forløbet i produktmodelleringsarbejdet er beskrevet i afsnit 6.2 på side 84, og fælles for de to scenarier er, at der startes med opbygning af en PVM, som siden hen danner grundlag for opbygning af et klassediagram. Derfor skal PVM en nemt kunne transformeres til et klassediagram. Dette er relativt simpelt, da al information og struktur uden problemer kan overføres fra PVM til klassediagram. Tabel 7.2 viser sammenhængen. Element i Element i Kommentar PVM klassediagram Topklasse Klasse Topklassen kan have attributter og overføres derfor til en selvstændig klasse som øverste klasse i en aggregeringsstruktur for hele klassediagrammet (se også figur 6.6 på side 87). Klasse Klasse Oprettes som Klasse i PVM en og kopieres til nye instanser ved overførsel til klassediagram. Attribut Attribut Attribut findes i begge diagrammer som Klasse.Attribut. Part-of relation Svag aggregering Part-of relationer svarer til aggregeringer, som kan være enten stærke eller svage. Overføres til svage aggregeringer, men i klassediagrammet kan dette efterfølgende ændres for hver relation. Kind-of relation Generalisering Generaliseringsstrukturer kan overføres direkte. Relationen tilhører underklassen (barnet). Binding Metode Ved oprettelse af bindinger i PVM en oprettes disse som Klasse.Metode af den ønskede type (f.eks. OCL eller fritekst). Ved overførsel fra PVM til klassediagram overføres Klasse.Metode automatisk. Illustration Illustrationer understøttes ikke i et klassediagram. Note Note Noter findes i begge diagrammer. De oprettes som PVM.Note i PVM en og kopieres til Klassediagram.Note ved overførslen. Tabeller i PVM en overføres ikke til klassediagrammet, men kan kopieres manuelt til et vilkårligt notefelt på i et CRC-kort. Tabel 7.2: Sammenhæng mellem elementer i PVM og klassediagram 112

7.5 Systemstruktur og diagrammer CRC-kort og diagrammer Informationen i CRC-kortene hentes fra den underliggende produktmodelmodeldatabase, og CRC-kortet skal derfor snarere betragtes som en brugergrænseflade frem for et selvstændigt element. I tabel 7.3 er lavet en opstilling af alle elementerne i CRC-kortet, og for hvert element er angivet, hvor informationen skal hentes fra (i klassediagrammet i figur 7.9 på side 111). Element i Element i Kommentar CRC-kort modeldatabase Klasse -ID Klasse.ID Kan ikke redigeres. Klassenavn Klasse.Navn Dato Klasse.Dato_opr Kan ikke redigeres. Ved klik på dato vises historikken for klassen. Ejer Klasse.Ejer Ved klik på navn vises oversigt over de brugere, der kan tilgå klassen (Klasse.MedRedaktører) med mulighed for at fjerne og tilføje brugere. Beskrivelse - tekst Klasse.Note - skitse Klasse.Skitse Aggregering Ved klik på klasse åbnes CRC-kort i nyt vindue - består af Klasse.Relation.Rel_ID Der vises kun de relaterede klasser, hvor relationen er af typen aggregering, og som er underklasser. - er del af Klasse.Relation.Rel_ID Der vises kun de relaterede klasser, hvor relationen er af typen aggregering, og som er overklasser. Generalisering Ved klik på klasse åbnes CRC-kort i nyt vindue - overklasser Klasse.Relation.Rel_ID Der vises kun de relaterede klasser, hvor relationen er af typen generalisering og hvor klassen nedarver fra. - underklasser Klasse.Relation.Rel_ID Der vises kun de relaterede klasser, hvor relationen er af typen generalisering og som nedarver fra klassen. Attributter Ved klik på attribut vises al information med mulighed for ændring - ID Klasse.Attribut.ID - navn Klasse.Attribut.Navn - note Klasse.Attribut.Note Metoder - ID Klasse.Metode.ID Ved klik på en metode vises al information med mulighed for ændring - navn Klasse.Metode.Navn - note Klasse.Metode.Note Vises for metoder af typen Bind_OCL. - indhold Klasse.Metode.Tekst Vises for metoder af typen Bind_txt. - relation til Klasse.Metode.Rel_ID Rel_ID peger på en evt. klasse, der indgår i metoden. Såfremt der anvendes OCL, opdateres feltet automatisk, ellers må dette gøres manuelt for hver metode. Brugerfelt Indholdet af Brugerfelt.Navn vises i stedet for teksten Brugerfelt i CRC-kortet - attribut Brugerfelt.Brugerattribut.Navn - attributværdi Brugerfelt.Brugerattribut.Værdi Tabel 7.3: Sammenhæng mellem elementer i CRC-kort og den underliggende produktmodeldatabase 113

Kapitel 7 - Kravspecifikation 7.6 Overgang fra dokumentation til konfigurator Integrationen mellem dokumentationsværktøj og konfigurator har overordnet to formål: - at lette overgangen fra model til implementering ved at give mulighed for at overføre modellen digitalt til konfiguratoren. - at støtte vedligeholdelsesarbejdet ved at give mulighed for at sammenligne dokumentation og implementering. Det store spørgsmål er dog, i hvor vid udstrækning det kan lade sig gøre, dvs. hvor tæt en integration det er muligt at lave uden at integrationen skal tilpasses hver enkelt konfigurator med specialudviklede moduler, som kræver store udviklingsressourcer. I dette afsnit vil jeg kort beskrive mulighederne for at udveksle information mellem dokumentationsværktøjet og konfiguratorer med baggrund i et undersøgelse af mulighederne i følgende konfiguratorer: - Oracle Product Configurator (Niro A/S) - Cincom Knowledge Builder/Sales Configurator (APC Denmark A/S) - Baan Configuration 98 (F.L. Smidth A/S og Vitral A/S) - ibaan Configurator (F.L. Smidth A/S) ãkänå æ ç è é êë êìäkéeí î ïñð å êò ó ôõƒö øùú Õ Ö Ø Ø àûàáàâý Ù ÚÛÜ ØÝÞß û ü ý ö øù û ôõƒö ü ý ö øùú øù Ó Ô þnå å äké í êè ì ð kæeðë é ê$í ÿeí êä$ð êè ç þnå å äké í êè ì ð kæeðë é ê$í ÿeí êä$ð êè ç A B!"$# % & ')( * + #, -. /)# # 0 + #, -. /)# # 0 A B (a) Via individuelle moduler i dokumentationsværktøj (b) Via API i konfiguratorer Dokumentationsværktøj Produktmodel database API Eksternt system (konfigurator) Eksternt system (konfigurator) A B? @ A B CED F G H G I @ F J K LNM A G O P 1 2 3 4 5 6 7 8 3 4 9 :; 4 < 7 < = < > 9 Q RS T U V W X Y Z [ S T U V R T \ ] ^ 9 5 7 2 < :7 _ ` 3 2 8 < 7 a A J G D M F G J b J G D C c A @ F d I e B M H G @ M f a A J G D M F G J b J G D C c A @ F d I e B M H G @ M f A B (c) Via API i dokumentationsværktøj (d) Via neutralt filformat Figur 7.10: Udveksling af data mellem dokumentationsværktøj og konfiguratorer 114

7.6 Overgang fra dokumentation til konfigurator Overførsel til konfigurator Uden hensyntagen til den enkelte konfigurator kan dataudveksling ske på fem overordnede måder. Disse er skitseret i figur 7.10 på foregående side. En måde er, at dokumentationsværktøjet kan eksportere til konfiguratorernes format for den underliggende produktmodel (figur 7.10(a) på foregående side). Dette kræver, at dokumentationsværktøjet har et eksportmodul for hvert format (dvs. hver konfigurator), der skal eksporteres til. Det kræver yderligere, at man ved udformningen af logikken bag eksportmodulet har studeret konfiguratorens format meget grundigt, så man ikke risikerer at ødelægge konfiguratorens produktmodel. En anden måde er, at konfiguratorerne stiller et Application Programming Interface (API) til rådighed for eksterne systemer (figur 7.10(b) på foregående side). På den måde tilgås konfiguratorens produktmodel via en veldokumenteret grænseflade, og er API et standardiseret (som f.eks. Open DataBase Connectivity (ODBC) under Windows og unixodbc for ikke-microsoft systemer) kan man nøjes med at anvende ét sprog til at tilgå flere typer databaser med. Den tredje måde minder om den anden, blot er der byttet lidt om på rollerne (figur 7.10(c) på foregående side). Her er det konfiguratorerne, der kan tilgå dokumentationsværktøjets produktmodeldatabase via et API. Løsningen kan anvendes, hvis konfiguratoren er svær at eksportere til, men har gode muligheder for at importere data. Automationen er dermed lagt over til konfiguratoren, men det er samtidig muligt at tilpasse den enkelte konfigurator, så der hentes de data, der kan importeres i det enkelte tilfælde. Især med de nuværende ikkeobjektorienterede konfiguratorer er der stor forskel på, hvad der kan indlæses i konfiguratoren. En fjerde måde er at benytte sig af et neutralt filformat (figur 7.10(d) på foregående side), som både dokumentationsværktøj og konfigurator understøtter. Fordelen er selvsagt, at man kan koncentrere udviklingsressourcerne om dette ene format. Desværre findes der ikke umiddelbart et sådant format for udveksling af produktdata, som er bredt accepteret. En mulighed ville ellers være Standard for the Exchange of Product model data (STEP), men formatet har desværre ikke vundet bred anvendelse og er stadig under udvikling, hvorfor det må anses at være forbundet med en ikke negligerbar risiko at satse på formatet [Kern og Bøhn, 1995]. Hvis dokumentationen skal kunne sammenlignes med implementeringen med henblik på at afdække evt. uoverensstemmelser, skal dokumentationsværktøjet kunne indlæse konfiguratorens produktmodel for derefter at sammenholde denne med dokumentationen. Kommunikationen kan igen ske på flere måder. En måde er, at dokumentationsværktøjet via konfiguratorernes API er kan tilgå disses databaser og derefter sammenligne med dokumentationen (figur 7.10(b) på foregående side). Dette kræver igen, at konfiguratorerne tilbyder API er, og at strukturen er veldokumenteret. Og igen er fordelen størst, hvis API erne er standardiserede. 115

Kapitel 7 - Kravspecifikation En anden måde er at lave importmoduler i dokumentationsværktøjet, som kan indlæse de forskellige konfiguratorers produktmodeller (figur 7.10(a) på side 114). Igen kræver det, at konfiguratorernes format er veldokumenteret og tilgængeligt. Ulempen er naturligvis, at der skal laves et modul for hver konfigurator. Det tredje tilfælde er anvendelsen af et fælles filformat. Fordelene er igen store, men med samme begrundelse som i afsnittet ovenfor må denne løsning nok anses som utopisk. 7.6.1 Kommunikation med Oracle Oracles konfigurator er en del af Oracle e-busines Suite og er (naturligvis) baseret på en Oracle-database, hvor produktmodellen lagres. Databasen kan tilgås på to måder: enten indirekte via Oracles API (i Java) eller direkte via ODBC 2, som illustreret i figur 7.11. sutvxwy z gih jlklm nporq { x~ g}h jlknm nƒ {} ~ g o$qr $ƒ i E zxtˆ } Š E zœ Ž i zˆ v ˆ t E Figur 7.11: Lagring og udveksling af information i Oracle Configurator Ved brug af Oracles API kan man med en simpel kommando f.eks. oprette en ny attribut uden at skulle tænke på de databasetransaktioner, der skal til at udføre kommandoen. Således er man ikke afhængig af at kende til databasearkitekturen, og en applikation, der udnytter Oracles API, vil ikke være påvirket af versionsændringer fra Oracles side. API et er primært tiltænkt til automatisering af import af store mængder data (f.eks. i opstartsfasen). Oracles API understøtter dog ikke alle funktioner til udvikling og vedligeholdelse af produktmodellen. F.eks. er det ikke muligt gennem API et at tilgå bindingerne. For at redigere disse skal databasens tabeller tilgås direkte gennem ODBC API et. Dette giver fuld kontrol over databasen, og stiller dermed store krav til en rigtig forståelse af databasearkitekturen. Samtidig er en applikation, der tilgår databasen direkte, afhængig af databasearkitekturen og dermed ikke uafhængig af versionsændringer. 2 Oplysninger stammer fra telefonsamtale 3/10 2002 med Tobias Buch fra Buch & Ohmsen (som er Oracle e-business Suite Partner). 116

7.6 Overgang fra dokumentation til konfigurator 7.6.2 Kommunikation med Baan Baan har p.t. to typer konfiguratorer i drift: Baan 98 og den nyeste ibaan. Den underliggende produktmodel er forskellig for de to typer og er illustreret nedenfor 3. Baan 98 gemmer produktmodellen dels i en.bpc-fil og dels en MS Access database, men informationen i de to lagre er ens. MS Access-databasen kan let tilgås og manipuleres med Baans Visual Basic (VB) add-in. Det er dog ikke tilrådeligt, da konfiguratoren altid anser indholdet af databasen for korrekt, og der tjekkes således ikke for integritet. Derfor anbefales det at tilgå.bpc-filen, som er fuldt ud dokumenteret i Bacchus-Naur form i Beologic [1996]..BPC-filen læses af en intern parser 4, og dermed tjekkes syntaksen automatisk. Baan 98 ibaan Access DB Parser VB add-in.bpc fil Eksternt system (dokumentationsværktøj).cava fil Eksternt system (dokumentationsværktøj) (a) (b) Figur 7.12: Lagring og udveksling af information i Baan 98 og ibaan Med Baan 98 er det muligt at importere modeldata fra en eksisterende.bpcfil. Den eksisterende.bpc-fil kan så enten være en eksisterende Baan 98-model eller genereret af et eksternt system. Med kommandoen er det muligt at vælge, hvilke foldere (dvs. elementer) der skal importeres. Regler kan ikke importeres med samme måde, men kan indsættes vha. kopiér-indsæt fra et hvilket som helst tabelformat (f.eks. i Excel). I ibaan (Baans nye objektorienterede konfigurator) lagres informationen helt anderledes. I forbindelse med udviklingen af den nye konfigurator er der også blevet udviklet et programmeringssprog (Cava - Constraint Java), som bruges til at lagre oplysninger om produktmodellen. Sproget er dokumenteret med eksempler i Invensys [2002]. Da modellen er objektorienteret, indeholder Cava-filen al nødvendig information om klasserne, deres struktur og inhold (inkl. attributter og regler). Med ibaan er det muligt at importere Cava-filer direkte. 3 Oplysningerne stammer fra telefonsamtale 20/8 2002 med Niels Sander Christensen, QA Manager hos Baan Danmark. 4 En parser er et computerprogram, der oversætter tekst til (for computeren) genkendelige tekststrenge til videre analyse. 117

Kapitel 7 - Kravspecifikation 7.6.3 Kommunikation med Cincom Produktmodellen i Cincoms konfigurator vedligeholdes gennem en grafisk brugergrænseflade (Knowledge Builder). Den underliggende database kan gemmes i enten MS Access- eller MS SQL-format. Knowledge Builder har mulighed for at tilgå andre datakilder ved hjælp af ODBC og kan ad den vej importere data ind i produktmodellen. Herudover findes ifølge Mikkel Dalgas fra APC tre muligheder for at integrere Cincom med eksterne systemer: 1. I Cincom findes en type af objekter, der kaldes External References, som kan være links til eksterne programmer eller dokumenter. På den måde kan man afvikle eksterne programmer og pipe information. 2. Alle Cincoms interne objekter nedarver fra nogle basisklasser, som administratoren af systemet har adgang til at ændre på. Det er f.eks. muligt at tilføje et felt til et dokumentationslink, tekst eller lign. Disse nye felter vil så automatisk findes i alle objekter i systemet. 3. Det er muligt at importere/eksportere hele modeller og dele af modeller via extensible Markup Language (XML). Den sidste mulighed anses af Mikkel Dalgas som den mest optimale måde at tilgå de rå data. Det har ikke været muligt at få oplysninger om, hvordan Cincoms database er struktureret, og i forbindelse med en integration med en Cincomkonfigurator vil det derfor være nødvendigt at få dette afklaret. 7.6.4 Anbefaling til dokumentationsværktøj Med udgangspunkt i ovenstående gennemgang af, hvorledes information kan overføres mellem dokumentationsværktøjet og konfiguratorer, og med indblik i de forskellige måder, som Cincom og Baan lagrer og giver adgang til information på, bør et kommende dokumentationsværktøj understøtte følgende muligheder for kommunikation (se figur 7.13 på følgende side): - Dataudveksling gennem et API. Dette bør være standardiseret, og derfor foreslås ODBC. Hermed sikres en fleksibel mulighed for både import og eksport af data på en entydig måde med et bredt udvalg af databaser. Med denne grænseflade sikres, at dokumentationsværktøjet kan tilgå mange forskellige datakilder, ligesom det sikres, at mange forskellige konfiguratorer kan tilgå dokumentationsværktøjets information. - Mulighed for tilføjelse af moduler til import og eksport af data. På den måde kan laves tilpassede kommunikationsmoduler til enkelte konfiguratorer, som ikke understøtter ODBC. Tilføjelsesmodulerne udformes f.eks. på baggrund af eksisterende dokumentation af konfiguratorens dataformat eller et evt. API (forskelligt fra ODBC). Det er nødvendigt at være fleksibel mht., hvordan data kan tilgås, da dokumentationsværktøjet nødvendigvis må være åben for integration med de eksisterende 118

7.7 Summering og prioritering af krav $ẍ lªe«n l ) ± E²³Š µ š œ ž ŸE œ œ Ÿ ¹iºŒ» ¼ ½ ¾r ÀrÁ ¹}ÓŠÓÔ ÕŠÖ )Ø Ù Ú ÛEÜ Â ÃÄxÅ ÆÇ ÈÅrÄŒÉ$ÄŒÅ ÆŒÊ Ë ÃxÌ È$ÍÎ Ï Ð Ç ÑxÅ Ì ÇÒ Â ÃÄxÅ ÆÇ ÈÅrÄŒÉ$ÄŒÅ ÆŒÊ Ë ÃxÌ È$ÍÎ Ï Ð Ç ÑxÅ Ì ÇÒ A B Figur 7.13: Forslag til dataudveksling med dokumentationsværktøj og kommende konfiguratorer på markedet, og ikke omvendt. Muligheden for import af information og tilføjelse af moduler er nødvendig for at kunne placere håndteringen af en synkroniseringsfunktionalitet i selve dokumentationsværktøjet. 7.7 Summering og prioritering af krav For at give et overblik over de krav, der er opstillet i de foregående afsnit, vil jeg her opsummere resultaterne. Med henblik på de senere faser i udviklingsforløbet vil jeg også lave en prioritering af kravene, så det bliver muligt lave en vægtning af, hvad der er essentielt for et dokumentationsværktøj, og hvilke krav der kan kategoriseres som nice to have. 7.7.1 Fleksibilitet gennem moduler Som det fremgår af den begrebsmæssige model for dokumentationsværktøjet og figur 7.1 på side 95, er der lagt op til at bygge det op omkring moduler. Rent udviklingsmæssigt giver det mulighed for at udbygge og teste værktøjet løbende og dermed hurtigt fremkomme med moduler, der rent faktisk fungerer. Samtidig bliver det nemmere at imødekomme fremtidige krav, idet ny funktionalitet kan laves ved at udbygge værktøjet i bredden med nye moduler eller i dybden ved at udvide eksisterende moduler til f.eks. at understøtte flere leverandører af konfiguratorer. Det svarer til, at man f.eks. i Windows udvider med understøttelse af en ny printer. Samtidig giver opbygningen i moduler mulighed for at starte med et grundmodul og tilføje funktionalitet hen ad vejen. Figur 7.14 på følgende side illustrerer, hvordan dokumentationsværktøj ud fra den begrebsmæssige model kan adskilles i et grundmodul og moduler af øget funktionalitet, som kan tilføjes efterfølgende. 7.7.2 Prioritering af moduler Modulerne i figur 7.14 på følgende side har ikke samme prioritet, forstået på den måde at nok er alle modulerne et udtryk for et krav til et kommende dokumentationsværktøj, men ikke alle moduler er lige essentielle for arbejdet med dokumentationen af en produktmodel. På baggrund af analysen i kapitel 6 på side 69 foreslås nedenstående prioritering for en versionsmæssig udvikling af værktøjet. 119

b a ` Ý Þ d c Kapitel 7 - Kravspecifikation &&'& æ íè ç è ì lí)é ë è 1 -, 234546789 234546789 234546789 234546789 Z [ Z õ 0 ü ø ö :;<=<>?@A BCDEF GHIJKL BCDEF GHIJKL U ú V M NOPOQ RST W Xò ô ô ð ùò ñ ø ò Y û -'é ë ì. è é *) #() é é *) / ë ç è ì é ê)é è í)ì ç è ì lí)é é êé è Eç ë è î)í ë ç è ë æ"!#%$ í)ì ç è ì lí æšç è çé è êë ì í)î ï ð ñ ò ó ñ ô õ ô ö ø ùó ñ ý ü ñ ù 0 ý ü ñ ø ô ùü ó ô õ ú ûô ö ø ùó ñ + é ë è *), *ë è *) lë ç ë è éé ê)é è þ à ÿ á ÿ ã ä å ß ß à á â ã à ä å ß à ÿ ã ä å ß ã à \ ] ã ^ á ã ã ã à ^ _ à á â ã à ä å ß Figur 7.14: Begrebsmæssig systemmodel opdelt i grundmodul og andre moduler Prioriteringen er baseret på funktionelle krav. Under den videre udvikling af dokumentationsværktøj kan det dog snildt vise sig, at elementer, der er prioriteret langt nede på listen, kan implementeres med meget få ressourcer, og at man derfor vælger at implementere dem i en tidligere version. Prioritet 1 Et grundmodul består af de interne databaser, datastyringen og brugergrænsefladen. Databaserne er grundlaget for hele produktmodellen, og da designet af strukturen i databaserne er essentielt for, hvilken funktionalitet systemet kan yde, skal denne struktur fastlægges tidligt og samtidig være fleksibel i forhold til fremtidige udvidelser. Klassediagrammet fra figur 7.9 på side 111 kan være et godt udgangspunkt for denne struktur. Versionsstyring skal indtænkes allerede her. I forbindelse med datastyringen udelades funktionaliteten i Adgangsstyring og Log i de første prototyper. Brugergrænsefladen vil i sagens natur blive udviklet løbende, efterhånden som funktionaliteten udbygges, men som første prioritet bør de grundlæggende elementer dog være på plads til håndtering af information i databasen ved hjælp af PVM, klassediagram og CRC-kort. PVM, klassediagram og CRC-kort skal have elementer, som beskrevet i afsnit 7.5 på side 110, dog kan der ikke indsættes brugerdefinerede felter på CRCkortene. 120

y 7.7 Summering og prioritering af krav Produktmodellen understøtter ikke opdeling i undermodeller samt integration til eksterne brugerdatabaser. Prioritet 2 Der tilføjes funktionalitet til integration med eksterne databasesystemer via et DBMS-modul. Samtidig tilføjes funtionalitet til at tilføje brugerdefinerede felter på CRC-kortene. Prioritet 3 Et udskriftsmodul tilføjes, så det er muligt at udskrive de forskellige elementer (som beskrevet i brugsmønstrene). Samtidig tilføjes adgangsstyring. Prioritet 4 En rapportgenerator tilføjes, så det er muligt at udtrække data fra produktmodeldatabasen. Samtidig tilføjes også funktionaliteten i datastyringsmodulets Log. Prioritet 5 Et meddelelsesmodul tilføjes, som udnytter et eksternt kommunikationssystem til afsendelse af meddelelser baseret på hændelser i værktøjet. Samtidig udvikles et modul til konfigurering af meddelelsesmodulet. Som beskrevet i brugsmønstrene skal det være muligt, at systemet genererer meddelelser, når et ændringsforslag afventer godkendelse, samt når et CRC-kort med status under udarbejdelse ikke er blevet tilgået i et foruddefineret tidsrum. I senere versioner af dokumentationsværktøjet vil det være oplagt at tilføje muligheden for brugerdefinerede hændelser. Prioritet 6 Et eksportmodul tilføjes, så det er muligt at eksportere indholdet i produktmodellen til eksterne systemer. Prioriteten er her først og fremmest at etablere muligheden for integration via et API, f.eks. ODBC. Afhængig af udviklingsprojektets interessenter udvikles add-on moduler til integration med systemer, der ikke understøtter kommunikation via et API. Prioritet 7 Nederst på prioriteringslisten ligger muligheden for import af data fra eksterne systemer. Denne funktionalitet lapper ind over funktionaliteten i et API (se afsnit 7.6.0.0.24 på side 115) og kræver en grundig analyse af den enkelte konfigurators muligheder. 7.7.3 Prototype-skærmbilleder På baggrund af brugsmønstrene og de opstillede krav har jeg beskrevet et typisk scenarie, som illustrerer en del af de centrale funktioner i dokumentationsværktøjet. På baggrund af scenariet har jeg designet et antal skærmbilleder, som kan give et umiddelbart indtryk af, hvordan arbejdet med dokumentationsværktøjet kunne foregå. Scenariet og skærmbillederne kan findes i bilag F på side 259. Skærmbillederne giver et godt umiddelbart indtryk af mange af de funktionaliteter, som er beskrevet under gennemgangen af kravene til systemet. Skærmbillederne er baseret på et standard MS Windows-design, hvilket gør det nemt for brugerne at identificere sig med skærmbillederne og den underliggende funktion. F.eks. vil de fleste vide, at man ved at trykke på pilen til højre i en komboboks (vist i margen) kan vælge boksens værdi på en liste. Faren ved dette er, at nogle brugere vil opfatte prototyperne som et udtryk for det endelige design, hvorfor det er vigtigt at understrege, at det kun er prototyper. e fgh i j'k l m j h n o e fgh i j'k l m j h n o p q r x y m s t u v sr} k l m s w s o rq e z { h i s k l m ~ s o efg"h i jk l m j r} h n o n ~ t w s h i s k l m i s o gh i j' t i t n s k l m ƒ j o 121

Kapitel 8 Den videre udvikling Indhold af dette kapitel 8.1 De kommende faser.................. 124 8.2 Egenudvikling..................... 125 8.2.1 Valg af platform.................... 125 8.2.2 Økonomi og tid..................... 126 8.3 Tilpasning af eksisterende systemer........ 128 8.3.1 Lotus Notes....................... 128 8.3.2 Rational Rose...................... 129 8.3.3 MS Visio........................ 131 8.3.4 Økonomi og tid..................... 133 8.4 Projektorganisation.................. 136 8.4.1 Forslag til organisation................. 137 8.5 Afrunding........................ 138 I de forrige kapitler er blevet opbygget en kravspecifikation for et dokumentationsværktøj til produktmodellering. Som illustreret i figur 1.1 i indledningen er dette projekt kun startskuddet til det endelige design og ultimativt implementeringen af dokumentationsværktøjet. I dette kapitel vil jeg foregribe de kommende aktiviteter og se på forskellige overordnede måder at implementere værktøjet på. 123

Kapitel 8 - Den videre udvikling 8.1 De kommende faser I afsnit 3.4 på side 27 blev nævnt, at skillelinjen mellem analysefasen og designfasen som oftest er meget diffus. Jeg har i dette projekt tilstræbt at afdække kravene for et dokumentationsværktøj til produktmodellering ved at analysere behovet for funktionalitet og formulere disse i dels beskrivende tekst, og dels et klassediagram samt brugsmønstre. Efter denne analysefase overgår projektet til designfasen og derefter implementeringsfasen. Indholdet af faserne afhænger af, hvordan værktøjet skal implementeres. Sigtes efter en fuldstændig egenudvikling af værktøjet fra bunden (i et højniveausprog som f.eks. C++ eller Java), skal der i designfasen udarbejdes en omfattende designmodel for det kommende system, der beskriver alle aspekter alt er jo muligt, og der er principielt ingen begrænsninger. Sigter man i stedet på en løsning, der tager udgangspunkt i et eksisterende system (f.eks. et PDM-system eller et CASE-værktøj), bliver både design- og implementeringsfasen noget anderledes. Selv om leverandøren af det eksisterende system givetvis vil påstå, at systemet kan tilpasses til enhver situation, vil der ofte være en del begrænsninger og muligheder som følge af det valgte system. I så fald går en af de første opgaver i designfasen ud på at få afklaret, hvad det eksisterende system kan i forvejen, og hvilken funktionalitet der skal tilføjes. I denne rapport er blevet afklaret, hvad et dokumentationsværktøj skal kunne for at tilfredsstille de kommende brugere. Den første opgave herefter vil derfor være at få afklaret, hvordan dokumentationsværktøjet skal implementeres dvs. om der findes et eksisterende system, der kan tilpasses, eller om systemet skal udvikles fra bunden, og hvilken type programmeringssprog der skal anvendes til formålet. De kommende aktiviteter er illustreret i figur 8.1 på følgende side. Når valget mellem egenudvikling og tilpasning af et eksisterende system skal tages spiller en række faktorer ind, som ikke direkte er relateret til funktionaliteten af det endelige produkt. F.eks. lægger man hos Niro vægt på at nye IT-systemer kan køre på eksisterende servere og databaser. I forbindelse med dette valg spiller udviklingstid og pris naturligvis også ind. Jeg vil i de følgende afsnit kaste bolden op til det kommende arbejde med dokumentationsværktøjet ved at se på nogle forslag til, hvordan dokumentationsværktøjet kan implementeres, hvilke muligheder og begrænsninger der er ved de forskellige muligheder, og et groft estimat af de tidsmæssige og økonomiske omkostninger. Slutteligt vil jeg overveje, hvordan den kommende projektorganisation bag udviklingen af værktøjet kan opbygges. 124

8.2 Egenudvikling ˆ Š Œ Ž Ž "Š š " š ˆ Š œ " " š ž Š š Ÿ " " š š š š Š ' ' ˆ ˆ š Ž Š š ' š š Ÿ œ ˆ'Ž š Š š Š ž "Š š Ÿ ' š š % š ˆ"ª % š ˆ Figur 8.1: De kommende faser i udviklingen med alternative ruter 8.2 Egenudvikling Egenudvikling er den ultimative løsning, hvor alt er muligt inden for budgettets rammer. Med egenudvikling menes her, at dokumentationsværktøjet programmeres op fra bunden på baggrund af en designmodel. Hermed kan alle ønsker og krav implementeres på præcis den måde, som det ønskes. Brugergrænsefladen kan designes præcis som ønsket, integration af systemets interne moduler kan koordineres og optimeres, lagring og håndtering af data kan skræddersys til situationen, og grænseflader til eksterne systemer kan opbygges efter de opstillede krav. De eneste begrænsninger er de tekniske muligheder og budgettet, og i praksis vil dette nok være indskrænket til det sidste. 8.2.1 Valg af platform Et af de centrale valg, der skal tages, når egenudvikling er valgt, er stillingtagen til, hvilken platform der skal udvikles på, f.eks. C++, C#, VB, Cobol, Prolog, Fortran etc., eller måske et af de mere internetorienterede miljøer som J2EE (Java 2 Enterprise Edition) og.net (fra Microsoft). Mest oplagt er nok et af de traditionelle miljøer som f.eks. C++, men med kommunikation over internet som et af de centrale krav til dokumentationsværktøjet, kunne J2EE og.net være meget interessante. J2EE er seneste version af Java-platformen fra Sun, som er uafhængigt af operativsystem og hardware, mens.net er Microsofts konkurrerende platform, der baseres på det eksisterende VB og det nye C# (også fra Microsoft). I Mølsted [2002] refereres til erfaringer fra konsulenthuset TietoEnator, som umiddelbart viser, at det er svært at fremhæve den ene frem for den anden af de to platforme. Brugeren vil i sidste ende næppe kunne mærke forskel på, om værktøjet er udviklet på den ene platform eller den anden især fordi dokumentationsværktøjet 125

Kapitel 8 - Den videre udvikling ikke fordrer store realtidsprocesser, som kræver en meget optimal kode. Derimod kan valget af platform have stor indflydelse på udviklingstiden og dermed økonomien i projektet. Såfremt egenudvikling vælges, bør valg af platform bl.a. baseres på, hvilke kompetencer der besiddes af virksomheden, som skal udvikle værktøjet. 8.2.2 Økonomi og tid Egenudvikling er med største sandsynlighed den dyreste løsning. Forud for implementeringen skal alt designes, og implementeringen indebærer udvikling af hele systemet. Naturligvis findes der givetvis færdige moduler, der kan bruges i løsningen, men store dele vil skulle opbygges fra bunden. At estimere, hvor lang tid det vil tage at udvikle dokumentationsværktøjet selv og dermed også hvad det vil koste er en kompleks opgave, som er genstand for megen opmærksomhed såvel i erhvervslivet som i forskningsmiljøer. Der eksisterer en række forskellige estimeringsmetoder, bl.a. Function Point Analysis (FPA), Walston-Felix og COnstructive COst MOdel (COCOMO) og COnstructive COst MOdel, ver. 2 (COCOMO2). Disse er alle beskrevet i van Vliet [2000] og baseres på en generel formel af formen E = (a + bkloc c )f(x 1,..., x n ) hvor E er udtryk for den nødvendige indsats (effort), som oftest udtrykt i mandemåneder; KLOC står for kilo-lines-of-code i det endelige system; a, b og c er konstanter og f(x 1,..., x n ) er en korrektion afhængig af værdierne for x 1,..., x n. Formlens grundform E = a + bkloc c er fremkommet ved brug af regressionsanalyse 1 af eksisterende projektdata, og som det fremgår af formlen, er den primære faktor størrelsen af projektet, målt i antallet af kodelinjer. Dette nominelle estimat korrigeres for en række omstændigheder med de forskellige omkostningsfaktorer (cost drivers), som udtrykkes med f(x 1,..., x n ) 2. f(x) kan f.eks. have formen i omkostningsfaktor i som udtryk for, at den samlede korrektionsfaktor er et produkt af i omkostningsfaktorer. F.eks. er der i Walston-Felix modellen identificeret 29 variable, som indvirker på produktiviteten (brugergrænsefladens kompleksitet, medarbejdernes erfaring, andelen af brugerinitierede ændringer etc.) [van Vliet, 2000, s. 157]. Forskellige modeller har forskellige værdier af a, b og c (se figur 8.2 på følgende side), og det er ifølge van Vliet [2000] svært at sammenligne modellerne, da de bygger på meget forskellige (og ofte udokumenterede) forudsætninger. Fælles for alle modellerne er dog, at de er forbundet med store usikkerheder, og det kræver 1 Regressionsanalyse er en statistisk teknik, der kan bruges til at estimere sammenhæng mellem flere variable. 2 F.eks. kunne en af faktorerne udtrykke udviklingsgruppens erfaring ved at antage værdierne 1.50, 1.00 eller 0.50 for henholdsvis et lavt, gennemsnitligt eller højt erfaringsniveau [van Vliet, 2000]. 126

8.2 Egenudvikling et stort kendskab til det miljø, hvor systemet skal udvikles, for at eliminere usikkerheder, såsom - Hvor mange linjer kode bliver det endelige system på? - Hvor mange linjer kode kan en programmør producere pr. mandemåned? - Resultater af at bruge ti programmører i én måned frem for én i ti? - Hvor meget kode kan genbruges fra tidligere projekter? - Hvilke faser inkluderer estimeringsmodellen? - osv.... På trods af usikkerhederne og at omkostningsestimering er en tidskrævende proces, har især COCOMO2 og FPA fundet bred anvendelse men forudsætter stadig, at personerne, der anvender dem, har et solidt kendskab til den udførende organisation og tillige stor erfaring med systemudvikling og estimering [van Vliet, 2000]. Halstead E = 0.7KLOC 1.50 Boehm E = 2.4KLOC 1.05 Walston-Felix E = 5.2KLOC 0.91 Figur 8.2: Forskellige omkostningsmodeller med forskellige grundformler [van Vliet, 2000, s. 155] På det nuværende grundlag vil det derfor være meget svært at give et fornuftigt estimat af omkostningerne for egenudvikling, som kan lægges til grund for en vurdering af projektet. Et meget overordnet estimat kan dog baseres på de opstillede brugsmønstre. I Longstreet [2001] beskrives, hvordan brugsmønstre kan bruges som grundlag for en FPA, og i en tabel opstilles en erfaringsmæssig sammenhæng mellem mængden af brugsmønstre og antallet af Function Points (FPs). I kapitel 7.3 på side 101 blev identificeret lige knap 50 brugsmønstre, som dækkede den centrale funktionalitet af dokumentationsværktøjet, hvilket ifølge Longstreet [2001] svarer til 5.000 FPs. I van Vliet [2000, s. 168] nævnes som et typisk estimat, at ét FP svarer til 29 linjer C++-kode. 5.000 FPs vil således svare til omkring 145.000 linjer C++-kode. Hvis vi herefter regner med, at en programmør effektivt kan producere 80 linjer kode pr. dag (uafhængigt af programmeringssprog) 3, svarer det til, at det vil 3 Ifølge professor Dines Bjørner fra institut for Informatik og Matematisk Modellering (IMM) på DTU. Dines Bjørner var for år tilbage involveret i udviklingen af en oversætter til et større programmeringssprog. Systemet fyldte 220.000 linjer kildekode (i standard C), tog fire år at udvikle og kostede DKK 42 mio. 127

Kapitel 8 - Den videre udvikling tage 1.813 mandedage eller 91 mandemåneder (med 20 arbejdsdage pr. mandemåned). Antager vi, at en mandemåned koster DKK 100.000 4, vil udviklingen af dokumentationsværktøjet fra bunden dermed koste omkring DKK 9 mio. (ekskl. moms). En sådan udviklingstid og omkostning vil med al sandsynlighed diskvalificere egenudvikling som en mulighed. Dog skal der huskes på, at estimatet er utroligt usikkert. For at lave et mere pålideligt estimat er det som nævnt nødvendigt bl.a. at kende mere til den virksomhed, der skal udvikle systemet. Estimatet her bør derfor ikke bruges som eneste grundlag for en beslutning. 8.3 Tilpasning af eksisterende systemer En mere tiltalende mulighed vil derfor være at se på mulighederne for at tilpasse eksisterende systemer. Hvis man med tilpasning af et (eller en kombination af flere) eksisterende system(er) kan udvikle et system, der tilbyder den ønskede funktionalitet, kan der være store ressourcer at spare både økonomisk og tidsmæssigt. Ved at basere udviklingen på et eksisterende system elimineres risikoen for at genopfinde hjulet alt for mange gange, samtidig med at funktionaliteten og stabiliteten i systemerne (fra en pålidelig leverandør) er gennemtestet og dokumenteret. Herudover fås også automatisk en kompetent medspiller i udviklingsforløbet, idet købet af et eksisterende system vil give mulighed for at trække på leverandørens support-afdeling. Som oplæg til den videre udvikling har jeg her valgt at se på tre systemer. Lotus Notes, fordi både Niro og APC har gode erfaringer med systemet, som umiddelbart understøtter mange af de funktionaliteter, der blev opstillet som krav i kapitel 7. Rational Rose, som er et af de mest populære CASE-værktøjer til udvikling af informationssystemer, da et dokumentationsværktøj til produktmodellering som det fremgår af de tidligere kapitler har meget tilfælles med et CASE-værktøj. Og endelig MS Visio som et avanceret diagrammeringsværktøj, der har rige muligheder for udvidelser og tilpasninger (herunder integration med databaser). 8.3.1 Lotus Notes Lotus Notes, som siden 1995 har været ejet af IBM, anvendes i Niro og APC som virksomhedernes centrale kommunikations- og dokumenthåndteringssystem (læs mere om deres tilpasning til produktmodellering i afsnit 6.1 på side 70). Systemet er et avanceret client/server-baseret informationssystem med den centrale funktionalitet baseret på databaser og kommunikation via internet. 4 Ifølge en tidligere medarbejder hos Novo Nordisk IT er dette satsen, som udfaktureres. Ifølge Dines Bjørner fra IMM er dette ikke misvisende, da man gerne regner med et udfaktureret beløb på 2,5 gange månedslønnen (her DKK 40.000) til at dække overhead. 128

8.3 Tilpasning af eksisterende systemer Filosofien bag Notes arkitektur er, at systemet skal være opbygget af en række byggeklodser af funktionalitet, som brugeren herefter selv kan sammensætte til det endelige system. På den måde bruges Notes sjældent lige fra papæsken. Ofte bygger virksomheder deres egen applikation oven på et Notes-miljø for at opnå den ønskede funktionalitet [IBM, 2002]. En Notes-implementering består i grove træk af en Domino-applikationsserver og et antal Notes-klienter, som skal konfigureres og tilpasses den enkelte virksomheds behov. Som dokumenthåndterings- og informationssystem understøtter Notes uden problemer funktionalitet som versionsstyring og adgangskontrol (som beskrevet i forbindelse med APC og Niro). Den største udfordring vil derfor være at lave en grafisk brugergrænseflade til Notes, som understøtter aktiviteterne omkring PVM og klassediagram. Hos APC og Niro, hvor man har Notes-udviklere ansat, har man ikke erfaring med lignende udfordringer. Helt overordnet er det dog muligt at lave en applikation i Java, som kan kommunikere med den underliggende Domino-server 5, omend det nok vil være en stor opgave. Der findes dog et produkt (Lotus Workflow), som er beregnet på tilpasning af Notes til virksomhedens arbejdsgange, som måske kan være nyttigt. Med dette produkt er det nemlig muligt at tilpasse brugergrænsefladen til Notes-klienten. For at kunne afgøre hvorvidt en Notes-løsning kan imødekomme kravene til et dokumentationsværktøj, vil det være nødvendigt med en mere detaljeret analyse (f.eks. i samarbejde med APC s og Niros Notes-udviklere) af især muligheden for at opbygge en brugergrænseflade, der giver mulighed for at arbejde grafisk med PVM og klassediagram. Mange af de mere datanære funktionaliteter er allerede undersøgt og i brug hos APC og Niro. 8.3.2 Rational Rose Rational Corporation har udviklet en hel pakke af programmer, der kan understøtte aktiviteterne under udvikling af informationssystemer i næsten alle faser af projektlivscyklussen 6. Et af disse programmer er Rose, som er et CASEværktøj, der overordnet set består af funktionalitet til at udvikle og vedligeholde UML-diagrammer og generere kode baseret på diagrammerne. Hertil kommer funktionalitet som f.eks. adgangsstyring og versionsstyring. I sin grundform lægger hele Rationals pakke af produkter i Rational Suite Enterprise op til et flerbrugermiljø i enten et MS Windows- eller Unix-miljø. Rational Rose tager udgangspunkt i UML-notationen, men kan tilpasses på forskellige måder, som illustreret i figur 8.3 på følgende side. Med scripts er det muligt at automatisere Rose-specifikke funktioner og udføre funktioner, som det ikke umiddelbart er muligt at tilgå via den normale brugergrænseflade i Rose. Med automation kan for det første kaldes Object Linking 5 Ifølge Bjarne Thomsen fra IBM Danmark, Lotus-afdelingen. Brugergrænsefladen for webklienten til Notes er opbygget i Java. 6 Rational har udviklet Rational Unified Process (RUP), som er en metodologi for udvikling af informationssystemer. 129

Kapitel 8 - Den videre udvikling Rational Rose Script-udsagn i ren tekst Rational Rose Rational Rose Kald af OLE automationsobjekter fra scripts eller eksterne applikationer ActiveX DLL Kan laves med f.eks. Visual Basic Script Rational Rose Add-in Rational Rose Automation Rational Rose Extensibility Interface Diagrams Application Model Elements Figur 8.3: Mulighed for udvidelse og tilpasning af Rational Rose. Baseret på Conallen [1999]; Rational [2001] and Embedding (OLE)-objekter med henblik på at eksekvere funktioner i eksterne applikationer som f.eks. Word og VB. For det andet er det muligt at lade Rose fungere som OLE-server, så man fra andre applikationer kan tilgå Roses OLE-objekt. Roses mulighed for at tilføje add-ins er dog nok det mest interessante i forbindelse med et dokumentationsværktøj. Hvert af disse moduler er et ActiveX Dynamic Linked Library (DLL) og kan udvikles i ethvert programmeringssprog, hvorfra der kan genereres et ActiveX DLL, f.eks. VB [Conallen, 1999]. Eneste krav er, at der skal inkluderes en offentlig grænseflade, der kan kommunikere med Rose. Som et CASE-værktøj til udvikling af objektorienterede systemer understøtter Rose naturligvis udviklingen af klassediagrammer perfekt. Udfordringen vil derfor sandsynligvis primært bestå i at kunne tegne en PVM, hvor det vil være nødvendigt at kunne definere reglerne og syntaksen for diagrammet i Rose. Det har ikke været muligt at få entydigt svar på, om dette kunne lade sig gøre. En anden vigtig problemstilling, der kræver et mere detaljeret studium af mulighederne i Rose, drejer sig om, hvorvidt Rose understøtter, at modellens information gemmes i en database. Som standard lagrer Rose informationerne fra en objektorienteret model i et hierarki af filer i Roses eget filformat. Det er dermed muligt at opdele en model i undermodeller og kontrollere adgangen til disse. Dette betyder, at det umiddelbart er muligt at styre adgangen på klassediagram-niveau 7, men hvorvidt det er muligt at basere Roses diagrammer på information fra en ekstern database er mere tvivlsomt. 7 For hver undermodel (klynge) gemmer Rose elementerne i filer i en separat mappe, og mappestrukturen afspejler således klyngestrukturen i modellen. 130

8.3 Tilpasning af eksisterende systemer ¹ º"» ² º ¼ ² ± ¼¾½ ( º ¼ À Á  à µ Ä Å Æ µ»» µ Å ²» «Ç ³ Å È È ± É» ʾ µ µ ± ÊË Ë Ù ÚÚÛ ØÜ «± ² ± ³ µ «Ó*ÔÕ"Ö Ö Ø Þ'Á Ý Ê ½ ¾«Ñ Ò Ò Ñ Áݽ ¹ º"» ² º ¼ ² ± ¼ È È É ± ² ± à µ Ä ¼ ± È È É ± à ± ²«ß" ¼" º È ßß"² º ¼» ± º à á² º" È ± É» â É ±» Å ± à Ä ¼ ± Í º ¼ ±» ã»» ± äå æ ç èé æ ê ç ë Ä Ã È «ÝÄ Ê ì Ê Ë Ë µ µ ± í Ë Ë ¹ Ì Æ Í» ² µ Î ¹ Ϲ ¹»Ê Þ'½Â î È» ß ¼ º «Â Å Æ Ã Èà ± ﾺ à µ ² ¼ á² º È ± É» â É ±»½ Æ ± û  ß" µî ã Ä ¼ ± È ² º µ ² É "Ê Þ'½Â î È» ± Ä Ã È «Ý Ð Ù¾ÚÚÛ Ö Ü Ð¼ ¼  º «Â ¼ È Í ß º» ß" ¼'«ÝÐÂ È ¼ Figur 8.4: Mulighed for udvidelse og tilpasning af MS Visio. Baseret på Grabowski [1998a]; Grabowski og Zander [2002]; Microsoft [2002] 8.3.3 MS Visio Visio er et avanceret tegneprogram til tegning af tekniske diagrammer og flowcharts og er for nyligt blevet opkøbt af Microsoft. Visio 2002 er det nyeste skud på stammen, og Visio er dermed blevet en del af Microsoft Office-familien. På CPM har Visio i flere år været det foretrukne værktøj til tegning af PVM og klassediagram, og med relation til det sidste kan Visio faktisk fungere som et CASE-værktøj, idet der eksisterer en meget veludbygget skabelon (inkl. funktionalitet) for UML. På den grafiske side kan Visio tilfredsstille alle kravene til et dokumentationsværktøj også med hensyn til udskrivning i stort format. Den største udfordring bliver derfor givetvis at kunne tilpasse Visio med hensyn til integration med databasesystemer samt funktionalitet som versionsstyring og adgangsstyring. Visio har flere muligheder for udvidelser og tilpasninger som illustreret i figur 8.4. Add-ons som.exe eller.dll-filer fungerer på samme måde som et program, der eksekveres fra en kommandoprompt. Programmet kan kaldes med en parameter, når f.eks. en bestemt handling sker i Visio, eller en bestemt hændelse indtræffer (f.eks. at en relation skal slettes, når en klasse slettes). Et eksempel på et add-on er vist i figur 8.6 på følgende side, som stammer fra Visios omfattende skabelon til UML-diagrammer. Med dette add-on kan alle egenskaber for en klasse i et klassediagram ændres. Ved tryk på OK opdateres modellen. Et Visio-dokument med Visual Basic for Applications (VBA)-kode giver en lignende funktionalitet, men indlejrer koden i det enkelte dokument og er derfor ikke egnet til en kompleks funktionalitet, der skal være tilgængelig (og nem at opdatere) for mange brugere. Et add-in er et Component Object Model (COM)-objekt, som kan startes op af Visio, men ikke eksekveres direkte. Et add-in skal selv have rutiner til at holde øje med hændelser, der skal eksekvere noget handling (f.eks. at en PVM skal kopieres til et klassediagram). 131

Kapitel 8 - Den videre udvikling Figur 8.5: Alle elementer i Visio defineres i et ShapeSheet Figur 8.6: Eksempel på add-on i Visio I Visio kan diagrammer baseres på skabeloner (stencils) med predefinerede elementer (shapes). F.eks. findes der skabeloner for alle elementer i UML-diagrammer. Hver af disse former defineres på et ShapeSheet, der minder om et regneark. Et udpluk er vist i figur 8.5. Her ses det bl.a., at add-on et fra figur 8.6 kaldes, når der dobbeltklikkes på en klasse (tabellen Events, cellen EventDblClick). Visios mulighed for integration med en ekstern database består i, at indholdet af ShapeSheet et kan hentes fra en database, ligesom databasen kan opdateres efter redigering af en tegning i Visio. Al kommunikation foregår via ODBC, men Visio kan ikke selv foretage SQL-kald [Grabowski, 1998a,b]. Visio understøtter ikke funktionalitet som adgangsstyring, versionskontrol eller rapportgenerering. Denne funktionalitet vil skulle implementeres via f.eks. add-ons eller i databasesystemet. Til gengæld kan Visio stort set imødekomme alle andre krav for dokumentationsværktøjet inkl. muligheden for at linke til internetressourcer og eksterne filer. 132

8.3 Tilpasning af eksisterende systemer 8.3.4 Økonomi og tid Ved at basere dokumentationsværktøjet på et eksisterende system vil et estimat af de økonomiske konsekvenser bestå af to overordnede dele: Udgifter ved anskaffelse af standardsystemet og udgifter til tilpasning af systemet. Den første del er meget overskuelig at estimere, mens den anden kræver mere kendskab og en dybere analyse af mulighederne i de enkelte systemer og en mere detaljeret sammenkobling af disse med kravene i kravspecifikationen. I tabel 8.1 på følgende side er opstillet en sammenligning af udgifterne til anskaffelse af de forskellige systemer. Priserne er alle ekskl. moms og dækker kun den isolerede anskaffelse af standardsystemet. Det antages således - At virksomheden selv har (eller anskaffer) alt nødvendigt hardware. - At virksomheden selv har licenser til et operativsystem, der understøttes af standardsystemet (typisk Windows 98 eller 2000/XP). - At computerne er parate til, at standardsystemet bliver installeret. - At virksomheden selv afholder omkostninger til al installation og konfigurering. For at have et ensartet sammenligningsgrundlag er alle budgetter baseret på licenser til 25 brugere. Som det fremgår af tabellen, er en Notes-løsning umiddelbart billigst i anskaffelse, mens Rose og Visio ligger tæt op ad hinanden. Der er dog stadig mange ukendte variable, som skal afklares, før en endelig beslutning kan tages. Samtidig fremgår det, at Visio er klart den billigste løsning, hvis vi ser på et prototypeprojekt, hvor der ikke skal bruges så mange licenser, da den totale pris ganske enkelt skaleres lineært efter antallet af brugere (dog mindst fem). Det er dog svært at sammenligne løsningerne, da især Notes og Visio tilbyder noget funktionalitet, som kan være interessant for virksomheden i anden sammenhæng. Notes er et avanceret dokumenthåndterings- og informationssystem (med bl.a. e-mail- og kalenderfunktion), mens Visio er et avanceret tegneprogram, som kan bruges i mange andre sammenhænge. På baggrund af gennemgangen af mulighederne for de tre systemer virker Notes og Visio umiddelbart som de mest oplagte systemer at arbejde videre med. For begge systemer er der dog som nævnt enkelte områder, der skal klarlægges nærmere før en endelig beslutning kan tages. Herudover kommer analyse af de økonomiske omkostninger ved at tilpasse de to systemer til opgaven. En detaljeret analyse af de økonomiske konsekvenser ligger uden for rammerne af denne rapport, men for at give et indtryk af opgavens størrelse, vil jeg kort præsentere et estimat for tilpasning af Visio, der er blevet udarbejdet af Thorkild Grothe Møller (udvikler hos Invensys/Baan). 133

Kapitel 8 - Den videre udvikling Rational Rose Engangsudgift Rational Rose Professional (J Edition) a 31.520 Årlig udgift Supportlicens b 6.320 I alt, første år 37.840 Information fra Rational Software, august 2002 Lotus Notes Engangsudgift Domino Application Server 20.239 25 stk. Notes-licenser (trade-in) 634 Lotus Workflow CAL 721 Årlig udgift 0 I alt, første år 21.594 Information fra IBM Danmark, september 2002 Microsoft Visio Engangsudgift 25 stk. MS Visio 2002, Standard Edition c 35.300 Årlig udgift 0 I alt, første år 35.300 Information fra Eterra A/S, september 2002 Alle priser er DKK ekskl. moms. a Prisen er for floating licenser, hvor der opsættes en licensserver (gratis), som sikrer, at antallet af samtidige brugere ikke overstiger det tilladte. b Supportlicens er obligatorisk første år. c Forskellen på Standard- og Pro-udgaven er kun de medfølgende skabeloner. Tabel 8.1: Udgifter ved anskaffelse af standardsystemer Tilpasning af MS Visio Et bud på de økonomiske og tidsmæssige konsekvenser af tilpasning af Visio er vist i tabel 8.2 på følgende side 8. Som det fremgår, vil det koste ca. DKK 264.000 at tilpasse Visio, og lægges hertil anskaffelsesprisen for Visio (tabel 8.1), bliver den samlede pris DKK 299.300. Udviklingstiden er i estimatet vurderet til 44 arbejdsdage. I den forbindelse er det vigtigt at holde for øje, at en udvikler fra en ekstern organisation ikke arbejder 100% på opgaven, men også skal bruge tid på f.eks. møder og lign. i sin egen organisation (hvilket der naturligvis ikke skal betales for). Den effektive arbejdstid svarer således til måske fire dage om ugen 9. Bruges denne sats, vil de 8 Tidsestimatet er lavet af Thorkild Grothe Møller (udvikler hos Invensys/Baan), som har deltaget i arbejdet omkring udviklingen af dokumentationsværktøjet. 9 Ifølge erfaringer fra en tidligere medarbejder hos Novo Nordisk IT. 134

8.3 Tilpasning af eksisterende systemer Opgave Tidsforbrug Udgift a Tilpasning til grafik PVM 5 dage 30.000 Klassediagram 5 dage 30.000 CRC-kort 5 dage 30.000 90.000 Produktmodeldatabase Udvikling af databaseunderstøttelse 4 dage 24.000 24.000 Brugerdatabase Opsætning af Visio med login og roller 4 dage 24.000 24.000 Datastyring (PDM-funktionalitet) Adgangstyring, versionsstyring, log 20 dage 120.000 120.000 Udskrift Konfigurering af Visio til udskrift 1 dag 6.000 6.000 I alt 44 dage 264.000 Alle priser er DKK ekskl. moms. a Baseret på en timeløn på DKK 750, hvilket er, hvad Novo Nordisk IT fakturerer for en Advanced Developer (se også Grouleff [2002]). Bruges månedslønnen fra afsnit 8.2.2 på side 126, fås en timeløn på DKK 675 (20 dage/måned, 8 timer/dag). Tabel 8.2: Udgift for udvikling af prototype i MS Visio 44 arbejdsdage svare til 11 uger. Der bør naturligvis foretages en prioritering af opgaverne i tabel 8.2 med tilsvarende milepæle, så man undervejs i forløbet kan lancere prototyper af dokumentationsværktøjet med stigende funktionalitet. Størst usikkerhed ligger der omkring estimatet af tilpasningen af datastyringsfunktionaliteterne. Som nævnt i afsnit 8.3.3 på side 131 skal denne funktionalitet implementeres i moduler uden for Visio (f.eks. ved hjælp af add-on s eller i databasesystemet), og det vil kræve en nærmere analyse af mulighederne for at kunne gøre dette estimat mere præcist. Med et estimat på DKK 120.000 udgør denne post op mod halvdelen af den samlede omkostning for tilpasning af systemet, og man kunne derfor overveje om det ville være hensigtsmæssigt at opbygge en prototype uden disse funktioner. Hermed kunne en del af de centrale funktionaliteter afprøves til en overkommelig pris. Sideløbende kunne mulighederne for datastyringsfunktionaliteterne undersøges og evt. efterfølgende implementeres. 135

Kapitel 8 - Den videre udvikling 8.4 Projektorganisation Efter at kravene til dokumentationsværktøjet er klarlagt, forskellige implementeringsscenarier er opstillet, og estimater af økonomi samt tidsforbrug er lavet, melder et nyt spørgsmål sig: Hvordan skal projektorganisationen bag projektet udformes? Der er et par problemstillinger, som bør haves i baghovedet, når spørgsmålet afklares: 1. Hvordan skal projektet finansieres? 2. Hvordan sikres, at systemet faktisk bliver anvendt? 3. Hvordan sikres rettighederne til systemet fremover? 4. Hvordan styres projektet bedst muligt? 5. Kan ressourcer på DTU udnyttes? 6. Hvordan gøres virksomheder interesserede i et samarbejde? Ad 1 Den umiddelbare vurdering er, at hverken CPM eller en virksomhed vil have mulighed for at finansiere projektet alene ikke på det nuværende grundlag. En oplagt mulighed er derfor, at CPM går sammen med et antal virksomheder om udviklingen. Alternativt kunne der tages kontakt til DTU Innovation, som primært investerer i opstart af forskningsbaserede projekter 10. Ad 2 CPM s erfaringer inden for produktmodellering viser, at der eksisterer en mangel på et dokumentationsværktøj til produktmodellering. Ved at lave et tæt samarbejde mellem CPM og virksomheder med erfaring inden for produktmodellering sikres de optimale forhold for, at dokumentationsværktøjet udvikler sig til et praktisk anvendeligt værktøj. Virksomhedernes engagement skal dog sikres f.eks. ved at de engageres økonomisk i projektet og har medansvar for succes. Ad 3 Hvis behovet for et dokumentationsværktøj retteligt er så stort, som det antydes fra CPM, bør værktøjet være grundlag for en sund forretning. I den forbindelse er det vigtigt at få afklaret, hvem der har rettighederne til den fortsatte udvikling af værktøjet. Af hensyn til CPM s videre arbejde inden for området bør dette forhold vurderes nøje. På den ene side har CPM ikke kompetencer inden for udvikling af informationssystemer og vil derfor have svært ved at løfte opgaven som en stabil leverandør af værktøjet. På den anden side har CPM en enestående viden inden for produktmodellering, som kan gøre dokumentationsværktøjet optimalt. En mulighed er at købe IT-tjenester ad hoc fra f.eks. et konsulenthus. En anden og måske mere tiltalende mulighed ville være at opstarte et nyt selskab i samarbejde med en kompetent IT-udviklingsvirksomhed. En mulighed kunne være ConfigIT 11, som er et spin-off fra IT-højskolen i København. Som samarbejdspartner har de kompetencer inden for IT, har en akademisk og forskningsmæssig 10 Ifølge deres hjemmeside på www.dtu-innovation.dk. 136

8.4 Projektorganisation baggrund samt indsigt i konfigurering. Deres hjemmeside giver dog umiddelbart det indtryk, at deres tilgangsvinkel til konfigurering er via systemudvikling og matematiske algoritmer frem for produktmodellering. Et samarbejde med CPM kunne derfor være givtigt for begge parter. Ad 4 CPM bør være den koordinerende organisation i et fremtidigt samarbejde. De deltagende virksomheder vil hver især have individuelle interesser i dokumentationsværktøjet, og det vil da bl.a. være CPM s rolle at finde kompromiser og søge den bedste fælles løsning. For at kunne varetage denne rolle bør CPM også påtage sig ansvaret som projektleder og koordinere aktiviteterne. Ad 5 Projektet indeholder meget materiale, som kunne bruges i eksamensprojekter eller specialkurser. Internt på IPL kunne f.eks. i et specialkursus laves detaljerede undersøgelser af mulighederne med Lotus Notes og Visio. Såfremt man ønsker at satse på egenudvikling, er både design- og implementeringsopgaven en spændende udfordring for eksamensprojekter i samarbejde med IMM. Opbygningen af en forretningsplan kunne også være et spændende emne for et specialkursus, eller evt. i samarbejde med kursus 42435 Virksomhedsstart på DTU. Fordelen ved eksamensprojekter er, at man ofte får en meget grundig løsning af problemstillingen, da de projektstuderende typisk kan fordybe sig mere i emnet i forhold til en ansat i en virksomhed (pga. økonomi). Samtidig betyder det dog også, at man må væbne sig med mere tålmodighed, da et eksamensprojekt også indebærer teoretiske studier, som ikke direkte bidrager til den endelige løsning. Ad 6 Alle virksomhederne tilknyttet dette projekt har tilkendegivet deres interesse i at deltage i et udviklingsprojekt. For at virksomhederne skal bibeholde interessen for projektet, skal der være et synligt resultat, som kan anvendes i virksomhedens aktiviteter. Der bør derfor laves en forretningsplan, der beskriver projektet, økonomien og de fremtidige muligheder. 8.4.1 Forslag til organisation På baggrund af de ovenstående betænkninger vil jeg foreslå, at CPM indgik et samarbejde med Niro, APC, F.L. Smidth og Vitral om det fremtidige arbejde omkring dokumentationsværktøjet. Aftalen kunne lyde på, at man i fællesskab udviklede version 1.0 af dokumentationsværktøjet, som derefter kunne bruges vederlagsfrit af parterne. Virksomhederne kan frit videreudvikle på version 1.0 til eget brug, men CPM skal sikres rettighederne til den videre udvikling. Hermed har CPM et grundlag for udvikling af fremgangsmåden for opbygning af produktmodeller og et dokumentationsværktøj, der støtter fremgangsmåden. 11 ConfigIT er en nystartet innovationsvirksomhed, der udvikler konfiguratorer. Arbejder p.t. på et pilotprojekt med Danfoss og har netop fået tilført DKK 12,5 mio. i investeringskapital fra ACR Capital [Svarre, 2002]. Læs mere om ConfigIT på www.configit-software.com. 137

Kapitel 8 - Den videre udvikling Dokumentationsværktøjet bør ikke ses som et isoleret produkt, men en del af en portefølje, som består af dokumentationsværktøjet og undervisning i anvendelse af fremgangsmåden. Som et forskningsbaseret center er CPM s primære mål ikke at udvikle et produkt, der kan skabe størst mulig profit, men snarere at deltage i udviklingen af viden og produkter, som bliver anvendt i videst muligt omfang. Derfor skal evt. rettigheder til produktet ligge hos CPM frem for hos en kommerciel virksomhed. 8.5 Afrunding I et samarbejde som beskrevet ovenfor bør den første opgave bestå i en mere detaljeret analyse af mulighederne for anvendelse af et eksisterende system som basis for dokumentationsværktøjet. Valget af de tre standardsystemer er ikke baseret på en bred markedsanalyse af mulighederne, men på umiddelbare erfaringer fra projektet. Især virker Lotus Notes og Visio lovende, og der bør ofres tid på en nærmere analyse af især - Muligheder for rapportgenerering, adgangskontrol og versionsstyring med Visio. - Muligheder for udvikling af en grafisk brugergrænseflade til Notes, som understøtter diagrammerne i produktmodellering. Herefter kan laves et mere retvisende estimat af økonomien i projektet og en efterfølgende vurdering af, hvilken funktionalitet de enkelte versioner af dokumentationsværktøjet skal have (baseret på prioriteringen i afsnit 7.7 på side 119). Dokumentationsværktøjets succes er uløseligt forbundet med brugernes anerkendelse og accept af CPM s fremgangsmåde for opbygning af produktmodeller. Som det fremgår af kravspecifikationen skal dokumentationsværktøjet nok være fleksibelt og give brugerne frihed til at følge deres fremgangsmåde, men værktøjet er fokuseret omkring brugen af PVM, klassediagram og CRC-kort som dokumentation for produktmodellen, og såfremt anvendelsen af disse ikke vinder accept, vil dokumentationsværktøjet selvsagt heller ikke blive en succes. Andersen og Jensen har i deres rapport konkluderet, at såvel CPM s fremgangsmåde som dokumentationsform er hensigtsmæssig til produktmodellering [Andersen og Jensen, 2001, s. 118]. Ligeledes har flere projekter ved CPM underbygget dette, hvorfor der er al mulig god grund til at tro på såvel fremgangsmådens som dokumentationsværktøjets berettigelse. Men de to skal leve i symbiose: Uden fremgangsmådens succes, intet dokumentationsværktøj, og uden dokumentationsværktøj har fremgangsmåden svært ved at opnå succes i praksis pga. de administrative flaskehalse. 138

Del III Afslutning

Kapitel 9 Konklusion Hovedformålet med dette projekt var at få afdækket, hvilke krav der stilles til et dokumentationsværktøj til produktmodellering. I indledningen (side 3) blev problemformuleringen opstillet, bestående af tre spørgsmål, som jeg her vil besvare: 1 Dokumentationsværktøj og krav til dokumentationsværktøj Blandt de deltagende virksomheder arbejder især Niro og APC struktureret med deres opbygning af produktmodeller og dokumentation af disse. Niro og APC har til formålet udviklet et dokmentationsværktøj i Lotus Notes, der kan håndtere simple strukturerer af CRC-kort, dog uden brug af PVM og klassediagram. FLS og Vitral bruger ikke i samme grad en struktureret fremgangsmåde og dokumentation, men er med baggrund i denne erfaring enige i, at en struktureret fremgangsmåde og dokumentation er den rigtige løsning. Der er bred enighed om, at opbygning og vedligeholdelse af dokumentationen er en flaskehals i processen, som kan løses med et dedikeret dokumentationsværktøj. På baggrund af analysen af virksomhedernes produktmodelleringsprocesser og fremgangsmåden er lavet en specifikation af kravene til et dokumentationsværktøj, hvor hovedpunkterne er: - Én central produktmodeldatabase. Se side 79, 95 - Adgangsstyring, versionsstyring og log. Se side 79, 96 - Kommunikation via internet, så værktøjet kan tilgås fra flere steder. Se side 79, 97 - Integration til eksterne systemer (standard-api og add-on moduler). Se side 79, 97 - Brug af PVM og klassediagram i brugergrænsefladen. Se side 79, 97 - Tæt sammenkobling af indhold i PVM, klassediagram og CRC-kort. Se side 79, 97 - Meddelelsesmodul til optimering af arbejdsprocesser. Se side 79, 99 141

Kapitel 9 - Konklusion 2 Standardsystem og integration med øvrige informationssystemer På baggrund af de opstillede krav har jeg vurderet mulighederne med tre standardsystemer: Lotus Notes, Rational Rose og MS Visio. Af disse virker Lotus Notes og MS Visio mest lovende, og vil med tilpasning kunne imødekomme langt størstedelen af de opstillede krav. Med baggrund i opsummeringen i afsnit 8.5 vil jeg foreslå at man satser på en udvikling af dokumentationsværktøjet i Lotus Notes. Forinden skal dog afklares hvordan brugergrænsefladen kan tilpasses. Dette kan gøres i en gruppe bestående en systemanalytiker (med indsigt i denne kravspecifikation), Notes-udviklere fra f.eks. Niro og APC, samt evt. Notes-eksperter fra IBM. Satsningen på Lotus Notes giver en løsning, der er fleksibel og baseret på et pålideligt standardsystem. Samtidig kan systemet bruges i andre sammenhænge i virksomheden, og er samtidigt overraskende billigt i anskaffelse. APC s Notes-løsning har samtidig vist, at man kan opnå den ønskede integration med virksomhedens ERP-system (i CRC-kortene). Integrationen mellem dokumentationsværktøj og konfigurator anses ikke som et essentielt krav, men virksomhederne er dog enige om, at der kan spares meget arbejde ved at kunne eksportere information fra dokumentationen til konfiguratoren. Funktionaliteten kan opnås ved at give mulighed for, dels at konfiguratorer selv tilgår dokumentationsværktøjets produktmodeldatabase (via ODBC), dels ved at det er muligt at tilføje dedikerede eksportmoduler som add-ons til dokumentationsværktøjet. Dette vil også være muligt med Lotus Notes. 3 Den videre udvikling Den videre udvikling bør starte med en vurdering af de forskellige implementeringsalternativer, hvoraf fire er skitseret i denne rapport. Ud over de tre standardsystemer er også egenudvikling blevet vurderet som den ultimative løsning, der kan imødekomme alle krav. Omkostningerne er på dette tidlige stadie næsten umulige at estimere uden nærmere kendskab til virksomheden, der skal udvikle systemet. Et estimat anslår omkostningerne til DKK 9 mio. Dette skal ses i forhold til f.eks. en tilpasning af MS Visio, der estimeres til en omkostning på omkring DKK 300.000 (ekskl. moms, inkl. 25 licenser). I forbindelse med den videre udvikling foreslås, at CPM indgår et samarbejde med interesserede virksomheder og evt. DTU Innovation. Hertil kan evt. kobles et sofwarefirma for at sikre ressourcer til den løbende udvikling. Denne konstellation vil udgøre et slagkraftigt miks af forsknings- og erhvervsmæssig erfaring og samtidig gøre projektet økonomisk muligt. Dokumentationsværktøjets succes er 100% afhængigt af brugbarheden af dokumentationen i CPM s fremgangsmåde (PVM, klassediagram og CRC-kort). Samtidig gør dokumentationsværktøjet fremgangsmåden mere attraktiv, og de to bør derfor udvikles sideløbende. 142

Kapitel 10 Perspektivering Udviklingen af dokumentationsværktøjet lægger op til et spændende samarbejde Spændende samarbejde mellem CPM og et antal virksomheder. Samarbejdet rummer store muligheder for at styrke såvel værktøjet og fremgangsmåden for udvikling af produktmodeller, samt arbejdet inden for produktmodellering. I forbindelse med udviklingsarbejdet bør der holdes et vågent øje med udviklin- Konkurrence fra konfiguratorer gen af konfiguratorerne, og især de tilhørende modelleringsværktøjer. Modelleringsværktøjet i ibaan har allerede mulighed for at vise (meget) simplificerede klassediagrammer for objekterne i modellen. I sin nuværende udformning vil modelleringsværktøjet dog næppe udgøre en reel trussel mod et dedikeret dokumentationsværktøj, som beskrevet i denne rapport. I rapporten nævnes muligheden for at dokumentationsværktøjet kan integreres Større integration med konfiguratorer i en sådan grad, at det er muligt at synkronisere dokumentationen med implementeringen. Funktionaliteten er meget kompleks og gøres ikke lettere af at hver konfigurator lagrer den underliggende produktmodel forskelligt. Der kan dog givetvis spares mange ressourcer ved (delvist) at automatisere sammenkoblingen af dokumentation med konfigurator, og det vil derfor være oplagt at arbejde videre med denne mulighed fremover. En yderligere udbygning af dokumentationsværktøjet ville bestå i muligheden Tilknytning af relationsmodeller for at kunne tilknytte forskellige relationsmodeller til produktmodellen. På den måde vil man kunne konfigurere produktet i flere dimensioner og med hensyntagen til flere aspekter af produktlivscyklussen (f.eks. montage og miljøkonsekvenser). I en fremtidig version af dokumentationsværktøjet ville det være oplagt at ind- Opdeling i undermodeller bygge muligheden for at dele modellen op i undermodeller. På den måde kan der arbejdes med en overordnet produktmodel, hvor ansvaret for de underliggende modeller uddelegeres til de enkelte afdelinger, eller måske endda eksterne virksomheder. Alt i alt er der mange muligheder for at udbygge værktøjets funktionalitet modulært i takt med brugernes behov og værktøjets succes. 143

Forkortelser API.......... CASE........ CMM........ COCOMO.. Application Programming Interface Et sæt af rutiner i et system, som kan kaldes af andre systemer. Rutinerne kan f.eks. udveksle data eller udføre opgaver. Operativsystemer har f.eks. API er til forskellige filoperationer, og programmøren skal dermed ikke bekymre sig om den komplicerede håndtering. Computer Aided Systems Engineering Enhver anvendelse af IT til at automatisere og støtte en eller flere aktiviteter i projektlivscyklussen i forbindelse med systemudvikling. Nogle steder ses også udskrivningen Computer Aided Software Engineering, men i denne rapport bruges den første oversættelse. Se også CASE-værktøjer. Capability Maturity Model En strukur for vurdering af hvor gode virksomheder er til at udvikle informationssystemer. CMM placerer en virksomhed på et af fem niveauer, hvor niveau 5 er det bedste. I CMM lægges vægt på, at virksomheden er god til at anvende metodologier som basis for udviklingen og evner at genbruge erfaringer fra tidligere projekter. COnstructive COst MOdel En algoritmisk model fra 1981 til estimering af omkostninger i forbindelse med udvikling af informationssystemer. Er meget veldokumenteret, læs evt. mere i van Vliet [2000, s.158]. COCOMO2. COnstructive COst MOdel, ver. 2 En videreudvikling af den originale COCOMO (se denne) for at tilpasse modellen til projektlivscyklussen for 1990 erne og dette årti. 145

Forkortelser COM......... COTS........ CPM......... CVS.......... Component Object Model Microsofts standard for udveksling af information mellem objekter ( bag brugergrænsefladen). Herunder forhandlinger mellem grænseflader, styring af livscyklus (for objekter) og håndtering af hændelser og licenser. Commercial Off The Shelf Betegnelse for produkter, der ikke kræver egenudvikling, men kan købes færdige til at understøtte en eller flere forretningsfunktioner. Et (ultimativt) eksempel er ERP-systemer. Center for Produktmodellering Concurrent Version System Et versionsstyringssystem udviklet som open-source-projekt. Dvs. at kildekoden er tilgængelig og kan anvendes under lempelige betingelser. CVS er client/server-baseret, og der findes klienter til de fleste styresystemer. Se mere på www.cvshome.org DLL.......... DTU......... Dynamic Linked Library Samling af små computerprogrammer, som typisk bruges af flere store computerprogrammer. De små programmer kaldes efter behov fra det store program, og derved kan ressourcer deles og optimeres. Danmarks Tekniske Universitet ERP.......... Enterprise Resource Planning American Production & Inventory Control Society (APICS) definerer ERP som... identifying and planning the enterprisewide resources needed to take, make, ship, and account for customer orders. Se også ERP-system. FPA.......... I-CASE...... Function Point Analysis En metode til estimering af omkostninger i forbindelse med udvikling af informationssystemer. Baseres på en vurdering af mængden af Function Points (FPs), som svarer til forskellige datastrukturer (input-typer, output-typer, forespørgselstyper, logiske interne filer og grænseflader). Hermed fjernes fokus fra en direkte estimering af antallet af linjer kildekode (lines-ofcode, LOC). Integrated Computer Aided Systems Engineering CASE-værktøj (eller samling af integrerede CASE-værktøjer), der støtter alle aktiviteterne i projektlivscyklussen. Ifølge Bennett et al. [1999] er disse CASE-værktøjer ofte designet til brug i forbindelse med en bestemt fremgangsmåde, som f.eks. SA&D eller RUP (se disse). 146

Forkortelser IDEF0....... IE............ IMM......... IPL........... Integration Definition for Function Modelling Standard for funktionsmodellering fra National Institute of Standards and Technology. Blev lanceret i 1993 som Federal Information Processing Standard (FIPS) og er dokumenteret i FIPS 183. Metoden er beregnet på at modellere beslutninger, handlinger og aktiviteter for organisationer eller systemer. IDEF0 er baseret på de grafiske elementer bag Structured Analysis & Design (se SA&D) og er også velegnet som kommunikationsværktøj pga. de få, enkle grafiske elementer og den simple opbygning. Information Engineering En datacentreret men dog procesfølsom teknik til modellering af (forretnings)krav og design af systemer, der opfylder disse. Kravene dokumenteres i Entity relationship diagrams. institut for Informatik og Matematisk Modellering Institut for Produktion og Ledelse OCL.......... Object Constraint Language Formaliseret, deklarativt sprog i UML. Bruges i produktmodellering til at beskrive bindinger mellem klasser i et utvetydigt sprog, der kan forstås af ikke-programmører. Se f.eks. Bahrami [1999, s.218] ODBC....... Open DataBase Connectivity Et API (se dette) til kommunikation med databasesystemeter. OLE.......... OMG........ PDM......... Object Linking and Embedding Et sæt af API er (se denne), som udgør Microsofts standard for udveksling af information mellem applikationer under Windows. Er en del af COM (se denne). Object Management Group Et åbent, non-profit konsoritum, der udvikler og vedligeholder specifikationer for IT-industrien. Blandt specifikationerne er UML (se denne). Product Data Management I løbet af en produktudviklingproces genereres og anvendes store mængder data relateret til produktet. Data, som finder anvendelse i såvel udviklingsfasen som i alle efterfølgende faser af produktets levetid. Herudover benyttes en rækker processer til strukturering af arbejdet. PDM dækker over håndteringen og kommunikationen af disse produktrelaterede data og processer i hele produktets livscyklus. Se også PDM-system. 147

Forkortelser PVM......... RUP......... Produkt-Variant Master Diagram, der afbilder et produkts struktur og funktion ved at opdele produktet i aggregerings- og generaliseringsstrukturer. Hertil er mulighed for at tilføje illustrationer og forklaringer. Diagrammet er relativt simpelt at forstå og virker som et godt pædagogisk kommunikationsmiddel. Bruges i de tidlige faser i produktmodelleringsprojektlivscyklussen. Rational Unified Process En kommerciel metodologi for udvikling af objektorienterede informationssystemer. Udviklet hos Rational Software med the three amigos (Booch, Jacobson & Rumbaugh) som hovedmænd. SA&D....... SDLC........ SKU......... SQL.......... STEP........ UML......... Structured Analysis & Design Ifølge Whitten et al. [2001] to af de første formelle modelleringsteknikker. Den procesorienterede analysedel bruges til at afdække (forretnings)kravene til systemet. Disse dokumenteres i data flow diagrams. Designdelen er ligeledes procesorienteret, og her overføres analysemodeller til designmodeller, som dokumenteres i structure charts. Systems Development Life Cycle Et strukturelt skelet til beskrivelse af faserne i et projekt for udvikling og vedligeholdelse af informationssystemer. Stock Keeping Unit Et unikt nummer til identificering af produkter (især i forbindelse med databaser). Structured Query Language Struktureret forespørgselssprog til databaser. Er med tiden blevet de facto standard som forespørgselssprog til forespørgsler og vedligeholdelse af relationelle databaser. Standard for the Exchange of Product model data Den populære betegnelse for ISO 10303. Standardens formål er at skabe ét neutralt filformat for udveksling af produktmodeldata, som kan anvendes i hele produktets levetid. Unified Modelling Language En notation for elementerne i en objektorienteret systemmodel. Hovedelementerne tæller usecase-diagrammer, klassediagrammer, sekvensdiagrammer og tilstandsdiagrammer. Kan anvendes som dokumentation for et objektorienteret system. UML samler de bedste ting fra the three amigos s (Booch, Jacobson & Rumbaugh) objektorienterede metodologier i en fælles standard. Mange tror fejlagtigt, at UML er en metodologi. 148

Forkortelser UPS.......... VB........... VBA......... WBS......... XML......... Uninterruptible Power Supply En enhed, der placeres mellem en spændingskilde (f.eks. en stikkontakt) og en enhed (f.eks. en computer) for at beskytte enheden imod uønskede egenskaber i strømmen (f.eks. udfald eller over-/underspænding). Visual Basic Et højniveau-programmeringssprog fra Microsoft, som blev lanceret i 1991. Et relativt let tilgængeligt sprog, som har gjort udvikling af programmer til Windows-platformen meget lettere. Visual Basic for Applications Et programmeringssprog fra Microsoft, der er en udvidelse af Visual Basic (VB, se denne) med henblik på hurtig udvikling af Windows-applikationer. Work Breakdown Structure Fra Schwalbe [2000, s.92]: A work breakdown structure (WBS) is an outcome-oriented analysis of the work involved in a project that defines the total scope of the project. Med denne nedbrydning af arbejdet i overskuelige bidder har man et grundlag for at planlægge og styre tidsplan, omkostninger og ændringer i forbindelse med ethvert projekt. extensible Markup Language Et platform-uafhængigt sprog (ikke programmeringssprog) til håndtering af strukturerede data. I modsætning til HTML, som XML minder en del om, forbyder specifikationen af XMLapplikationer at gætte på meningen af en ufuldstændig XMLfil. I stedet skal transaktionen stoppes, og en fejl rapporteres. Se evt. www.w3.org/xml/1999/xml-in-10-points.html. 149

Ordforklaring Aggregering, stærk Side 26 UML-element, der angiver en relation mellem to klasser. Relationen viser, at en klasse er en del af en anden klasse (part-of), men bindingen er stærk, og underklassen kan derfor ikke eksistere uafhængigt af overklassen, nedlægges overklassen, nedlægges underklassen også. Kaldes også komposition. Se f.eks. Bahrami [1999, s.99]. Se også Aggregering, svag. Aggregering, svag Side 26 UML-element, der angiver en relation mellem to klasser. Relationen viser, at en klasse er en del af en anden klasse (part-of), men bindingen er svag, og underklassen kan derfor eksistere uafhængigt af overklassen. Se f.eks. Bahrami [1999, s.99]. Se også Aggregering, stærk. Association Side 26 En relation, der angiver, at to klasser kender til hinanden (og dermed kan kommunikere), uden at de i øvrigt påvirker hinanden. Brugsmønster Side 24 En adfærdsmæssig skevens af handlinger (et scenarie) såvel automatiserede som manuelle med henblik på at beskrive en forretningsopgave. Bruges inden for objektorienteret modellering til at afdække de funktionelle krav til et informationssystem. Sammenhængen mellem brugsmønstre og roller illustreres i et brugsmøsnterdiagram. CASE-værktøj, Horisontalt Side 50 CASE-værktøj, der understøtter aktiviteterne i flere faser af projektlivscyklussen eller et begrænset domæne. F.eks. et CASE-værktøj til opbygning af OOA&D-modeller ifm. systemudvikling. CASE-tool, Lower Side 49 CASE-værktøj til understøttelse af aktiviteterne i de senere faser af pro- 151

Ordforklaring jektlivscyklussen. Understøtter aktiviteter som f.eks. kodegenerering, fejlfinding og testning. Se også Upper CASE tool. CASE-tool, Upper Side 49 CASE-værktøj til understøttelse af aktiviteterne i de første faser af projektlivscyklussen. Understøtter aktiviteter som f.eks. opbygning af diagrammer og udvikling af kravspecifikation. Se også Lower CASE tool. CASE-værktøj, Vertikalt Side 50 CASE-værktøj, der understøtter aktiviteterne inden for en begrænset del af projektlivscyklussen eller et begrænset domæne. F.eks. et CASE-værktøj til opbygning af brugergrænseflader. Se også Horisontalt CASE-værktøj. CASE-værktøj Side 48 IT-baseret værktøj der støtter og automatiserer arbejdet med udvikling af systemer. Værktøjet er oftest udviklet til at støtte en bestemt fremgangsmåde, og integrerer analyse- og designfaserne ved at automatisere og/eller støtte tegning af diagrammer og systemmodeller og automatisere overgangen fra analyse over design til implementering. CRC-kort Class, Responsibility & Collaboration-kort Side 43 Stammer fra objektorienteret systemudvikling og er en formular (et kort), der beskriver en klasse (se denne). Et CRC-kort indeholder bl.a. information om klassens navn, attributter, metoder, underklasser, overklasser mv. Domæneekspert Side 38 En person, der er ekspert inden for et givet domæne. F.eks. en maskiningeniør med specifik viden om spraytørring. Begrebet bruges inden for systemudvikling til at skelne mellem personer, der har viden om det domæne, hvor informationssystemet skal bruges (f.eks. maskiningeniøren), og de personer der har viden om systemudvikling (f.eks. analysekonsulenter og programmører). ERP-system Side 42 Et informationssystem, der tilbyder funktionalitet til udførelse af aktiviteterne forbundet med ERP (se denne). Et ERP-system er et kompliceret og omfattende informationssystem, der bruges bredt i virksomheden. Se også ERP. Generalisering Side 22 En relation, der angiver at en klasse arver egenskaber (metoder og/eller attributter) fra en anden klasse. Klasse Side 21 En gruppering (klassificering) af objekter med samme struktur, adfærdsmønster og attributter. Se også Klassediagram. 152

Ordforklaring Klassediagram Side 25 Viser en struktur af klasser med deres indbyrdes relationer af forskellig art. Se også Klasse. Klynge Side 26 UML-element dækkende over et antal sammenhængende klasser, der udgør en form for helhed. Kan bruges i et klassediagram til at skjule detaljer på overordnede diagrammer. Konfigurator, konventionel Side 35 Dækker over alle konfiguratorer, der ikke er objektorienterede. Den underliggende produktmodel består typisk af en række attributter (typisk organiseret i en hierarkisk træstruktur), som relateres gennem en række bindinger, der også begrænser attributværdierne. Langt størstedelen af alle konfiguratorer er af denne type (bl.a. alle konfiguratorer fra Cincom og Oracle samt Baans tidligere udgaver). Konfigurator, objektorienteret Side 35 Dækker over konfiguratorer, hvor en underliggende produktmodel er objektorienteret (i modsætning til konventionelle konfiguratorer) og dermed opbygget af klasser, der indeholder attributter og metoder (bindinger). Sammenhørende information er således samlet i logiske enheder (klasser). Meget få konfiguratorer af denne type eksisterer (f.eks. Baans nyeste: ibaan). Livscyklus Side 14 En række faser, som beskriver tilstanden/situationen for et element. Elementet kan f.eks. være et produkt (som udvikles, produceres og til slut skrottes) eller et projekt (bestående af faser som opstart, udvikling, implementering og afvikling). Metadata Side 60 Betyder data om data og anvendes f.eks. om de informationer, der findes i et PDM-system, som beskriver dokumenterne i systemet (forfatter, ændringsdato, titel etc.). Metodologi Side 13 I forbindelse med systemudvikling (fra Whitten et al. [2001]): En formel og præcis definition af udviklingsprocessen med angivelse af aktiviteter, metoder, best practises, målsætninger, og hjælpeværktøjer. Anvendelsen af en metodologi sikrer, at en konsistent og gentagelig fremgangsmåde anvendes til alle projekter. Modeldrevet udvikling Side 53 En overordnet fremgangsmåde, som bygger på opbygning (tegning) af modeller for at visualisere problemstillinger og analysere problemer. Ydermere kan opbygges modeller som dokumentation for (og integreret del af) kravspecifikationen. I sidste instans ligger modellerne til grund for selve designet af systemet. 153

Ordforklaring Modul Side 41 En kombination af komponenter eller parts med en veldefineret grænseflade til omgivelserne. F.eks. en elmotor, hvor tilslutningerne til el og kraftudtag er veldefinerede. Nedarvning Side 22 Se Generalisering. Objekt Side 20 En abstrakt størrelse, der kombinerer data og logik som en repræsentation af en entitet i den virkelige verden. Se også Klasse. PDM-system Side 59 Et informationssystem, der tilbyder funktionalitet til udførelse af aktiviteterne forbundet med PDM (se denne). Et PDM-system er ofte et kompliceret og omfattende informationssystem, der bruges bredt i virksomheden. Tema Side 26 Inddeling af klasserne i et klassediagram i overskuelige enheder. Three amigos, the Side 20 En efterhånden udbredt betegnelse for Grady Booch, Ivar Jacobson & James Rumbaugh, som op gennem 1980 erne og 1990 erne hver især udviklede objektorienterede modelleringsteknikker (bl.a. the Booch Method, Object Modelling Technique - OMT og brugen af use cases. I løbet af 1990 erne samlede de kræfterne om udviklingen af en fælles notation for objektorienterede modeller, og i slutningen af 1990 erne så UML dagens lys. Se også UML. Usecase Side 24 Se Brugsmønster. 154

Litteratur Andersen, P. V. og Jensen, S. W. [2001], Konfigurering af design-møbler for Fritz Hansen, Master s thesis, Institut for Produktion og Ledelse, Danmarks Tekniske Universitet. IPL publikationsnummer IPL-093-01. Citeret på side: 43, 44, 45, 105, 108, 138, 259 Bahrami, A. [1999], Object Oriented Systems Development, Irwin/McGraw- Hill. Citeret på side: 15, 16, 20, 21, 22, 23, 24, 25, 27, 28, 30, 50, 147, 151 Barclay, S. og Padusenko, S. [2002], CASE Tools, Hjemmeside (sidst set 19/9 2002). http://www.educ.queensu.ca/~compsci/units/casetools.html Citeret på side: 48 Bennett, S., McRobb, S. og Farmer, R. [1999], Object-Oriented System Analysis and Design using UML, McGraw Hill. Citeret på side: 14, 15, 25, 27, 28, 29, 31, 48, 50, 56, 58, 146 Beologic [1996], File Formats in BEOLOGIC salesplus. Beologic A/S. Citeret på side: 117 Booch, G., Jacobson, I. og Rumbaugh, J. [2001], OMG Unified Modelling Language Specification, Object Management Group (OMG). Citeret på side: 26, 80 CIMdata [1997], Product Data Management: The Definition, fourth edn, CIMdata Inc. Citeret på side: 59, 60, 61 Clark, K. B. og Fujimoto, T. [1991], Product Development Performance, Harvard Business School Press. Citeret på side: 64 155

Litteratur CMU [2001], What is a CASE Environment, Hjemmeside (sidst set 19/9 2002). Carnegie Mellon University. www.sei.cmu.edu/legacy/case/case_whatis.html Citeret på side: 49, 50 Conallen, J. [1999], Creating Your Own Rose Add-In with Visual Basic, Rose Architect 1(3). www.therationaledge.com/rosearchitect/mag/archives/9904/f5.html Citeret på side: 130 CSL-NIST [1993], Integration Definition for Function Modelling (IDEF0), Technical report, Computer Systems Laboratory, National Institute of Standards and Technology. FIPS Publication 183. http://www.idef.com/downloads/pdf/idef0.pdf Citeret på side: 56 Grabowski, R. [1998a], Visio s Database Links - Part 1, Hjemmeside (sidst set 22/9 2002). www.cadinfo.net/visio/rgavt2.htm Citeret på side: 131, 132 Grabowski, R. [1998b], Visio s Database Links - Part 2, Hjemmeside (sidst set 22/9 2002). www.cadinfo.net/visio/rgavt3.htm Citeret på side: 132 Grabowski, R. og Zander, F. [2002], Learn Microsoft Visio 2002 for the Advanced User, Wordware Publishing. Citeret på side: 131 Grouleff, M. [2002], 16 kroner i timen til programmøren, artikel på Computerworld.dk. 26/9 2002. http://www.computerworld.dk/default.asp?mode=2&articleid=16274 Citeret på side: 135 Guinan, P. J., Cooprider, J. G. og Sawyer, S. [1997], The effective use of automated application development tools, IBM Systems Journal 36(1). http://www.research.ibm.com/journal/sj/361/guinan.html Citeret på side: 52 Harlou, U. [1999], A product family master plan as basis for product modeling and engineering design. Citeret på side: 40, 41, 105 Hogan, D. [1999], A Study of Case Tools. http://www.umsl.edu/~sauter/analysis/dfd/casetool.html Citeret på side: 49, 50 Hvam, L. [1994], Anvendelse af produktmodellering set ud fra en arbejdsforberedelsessynsvinkel, PhD thesis, Driftsteknisk Institut, Danmarks Tekniske 156

Litteratur Universitet. Citeret på side: 34 Hvam, L. og Mortensen, N. H. [2002], Produktmodellering, Institut for Produktion og Ledelse, Danmarks Tekniske Universitet. Citeret på side: 1, 4, 34, 35, 37, 38, 39, 40, 41, 42, 43, 44, 76 Hvam, L. og Riis, J. [1999], CRC cards for product modelling, in The 4th Annual International Conference on Industrial Engineering Theory Applications and Practice. www.produktmodeller.dk/litteratur/egne/artikler/ Citeret på side: 38, 39, 43, 44, 108 IBM [2002], The History of Notes and Domino, Hjemmeside (sidst set 24/9 2002). International Business Machines. www-10.lotus.com/ldd/whatisnotes Citeret på side: 129 Invensys [2002], ibaan E-Configuration Enterprise Language Reference Manual. Invensys International B.V. Citeret på side: 117 Jacobson, I., Rumbaugh, J. og Booch, G. [1999], The Unified Software Development Process, Object Technology Series, Addison-Wesley, Reading/MA. Citeret på side: 27 Kern, V. M. og Bøhn, J. H. [1995], STEP Databases for Product Data Exchange, in I International Congress of Industrial Engineering, Vol. 3, pp. 1337 1341. http://www.eps.ufsc.br/~kern/publ/kern95.pdf Citeret på side: 115 Kirkby, P. og Kjærulff, J. [1992], CASE for planlægning og analyse i CIMsystemudvikling, Master s thesis, Driftsteknisk Inistitut, Danmarks Tekniske Universitet. DI publikationsnummer DI.92.02-B. Citeret på side: 49 Krause, F. L., Kimura, F. og Kjellberg, T. [1993], Product Modelling, in Annals of the CIRP, number 42 in 2. Citeret på side: 34 Kristensen, J. H. [2002], Dynamisk visualisering til produktkonfigurering på Internettet, Master s thesis, Institut for Produktion og Ledelse, Danmarks Tekniske Universitet. IPL publikationsnummer IPL-039-02. Citeret på side: 36 Kruchten, P. [1998], Rational Unified Process: an Introduction, Addison- Wesley, Reading/MA. Citeret på side: 17, 52 157

Litteratur Longstreet, D. [2001], Use Cases and Function Points, Hjemmeside (sidst set 19/9 2002). www.ifpug.com/articles/usecases.htm Citeret på side: 127 Mathiassen, L., Munk-Madsen, A., Nielsen, P. A. og Stage, J. [1993], Objektorienteret analyse, 1 edn, Forlaget Marko. Citeret på side: 20 Microsoft [2002], MSDN Library, About Microsoft Visio Add-ons and COM Add-ins, Hjemmeside (sidst set 22/9 2002). msdn.microsoft.com/library/default.asp?url=/nhp/default.asp?contentid=28000456 Citeret på side: 131 Mølsted, H. [2002], Slaget om fremtidens IT-platforme er i gang, artikelserie i ugeavisen Ingeniøren. Nr. 36, 6/9 2002. Citeret på side: 125 Mortensen, N. H., Yu, B., Skovgaard, H. J. og Harlou, U. [2000], Conceptual Modeling of Product Families in Configuration Projects, in Product Models 2000-SIG PM. Citeret på side: 41, 43, 45, 81, 105 Pikosz, P. og Malmqvist, J. [1996], Possibilities and Limitations when Using PDM Systems to Support the Product Development Process, in Proceedings NordDesign 96, pp. 165 175. Citeret på side: 64, 65 Pikosz, P. [1997], Product Data Mangement in the Product Development Process. Licentiate Thesis, Machine and Vehicle Design, Chalmers University of Technology, report no. 1997-11-07. Citeret på side: 34, 59 Rational [2001], Using the Rose Extensibility Interface, Documentation report. Rational Software Corporation. Citeret på side: 130 Riis, J. [2001], Fremgangsmåde for opbygning af videnintegrerede produktog produktrelaterede modeller til udvikling af forretningsprocesser. Kundskabsprøve for Ph.D. projekt, Institut for Produktion og Ledelse, Danmarks Tekniske Universitet. Citeret på side: 34 Riis, J. [2002], Fremgangsmåde for opbygning af produktmodeller som understøtter specifikationsprocesser, PhD thesis, Institut for Produktion og Ledelse, Danmarks Tekniske Universitet. IPL publikationsnummer IPL-089-02. Citeret på side: 12, 26, 31, 42, 88, 94 Sadoski, D. og Comella-Dorda, S. [2000], Three Tier Software Architectures, Hjemmeside (sidst set 19/9 2002). Software Engineering Institute, Carnegie 158

Litteratur Mellon University. www.sei.cmu.edu/str/descriptions/threetier_body.html Citeret på side: 97 Schwalbe, K. [2000], Information Technology Project Management, Thomson Learning. Citeret på side: 14, 15, 17, 55, 149 Svarre, E. [2002], Ny software nøglen til succes, artikelserie i avisen Børsen. 20/8 2002. Citeret på side: 137 Svensson, D. og Malmqvist, J. [2001], Integration of Requirement Management and Product Data Management Systems, in Proceedings of the 2001 ASME Design Engineering Technical Conferences, The American Society of Mechanical Engineers (ASME). Citeret på side: 84 van Vliet, H. [2000], Software Engineering, 2 edn, John Wiley & Sons, Ltd. Citeret på side: 126, 127, 145 Vesterager, J. [1989], Beskivelse af CIM/GEMS projektet resultater, publikationer og opnået effekt. Drifsteknisk Institut, Danmarks Tekniske Universitet. Citeret på side: 13 Whitten, J. L., Bentley, L. D. og Dittman, K. C. [2001], Systems Analysis and Design Methods, Irwin/McGraw-Hill. Citeret på side: 12, 13, 20, 24, 27, 28, 51, 52, 53, 55, 102, 103, 148, 153, 197 159

Kravspecifikation for dokumentationsværktøj til produktmodellering Polyteknisk eksamensprojekt, 2002 Bilag Vejledere: Lars Hvam & Jesper Riis Institut for Produktion og Ledelse Danmarks Tekniske Universitet Simon Pape, C958196 Publikationsnummer IPL-128-02

Bilag A Paradigma for projekt Ifølge IPL s forskrifter skal følgende paradigma medtages som bilag A i rapporten. A.1 Projekttitel Dansk: Engelsk: Kravspecifikation for dokumentationsværktøj til produktmodellering Requirements for Documentation Tool for Product Modelling A.2 Projektvejledere Lars Hvam (lektor, på IPL) Jesper Riis (ph.d.-studerende på IPL) A.3 Projektfølgegruppe Mikkel Dalgas (APC Denmark A/S) Benjamin Loer Hansen (APC Denmark A/S, ph.d-studerende på IPL) Martin Malis (GEA Niro A/S, ph.d.-studerende på IPL) Søren Poulsen (F.L. Smidth A/S) Aage Wind (Vitral A/S) A.4 Formål med projektet At opbygge en kravspecifikation for et dokumentationsværktøj til brug ved produktmodellering med henblik på en efterfølgende implementering. 163

Bilag A - Paradigma for projekt A.5 Baggrund for projektet Med anvendelsen af IT-baserede produktmodeller i en virksomheds specifikationsproces åbnes for nye muligheder med relation til forholdet til kunderne. Muligheder, der kan give mere kundetilpassede produkter til konkurrencedygtige priser og med en kortere leveringstid. Anvendelsen af produktmodeller er dog relativ ny, og flere projekter er blevet droppet. Årsagen hertil skyldes ofte manglen på struktur i processen med deraf følgende mangel på overblik. Den manglende strukturelle opbygning resulterer i et system, der er vanskeligt at vedligeholde og udvikle, og dermed ikke rentabelt at drive. Ved Center for Produktmodellering har Lars Hvam og Niels Henrik Mortensen udviklet en struktureret fremgangsmåde for opbygning af produktmodeller, som består af syv faser. Dokumentationen af produktmodellen består af en række diagrammer og dokumenter, der p.t. vedligeholdes manuelt og ikke er integrerede. Der er derfor ikke mulighed for på en enkel måde at trække på information på tværs af diagrammerne og dokumenterne, og vedligeholdelsesarbejdet bliver hurtigt omfattende og uoverskueligt. Et IT-baseret dokumentationsværktøj vil kunne tilbyde en integration af informationen og vil ydermere kunne automatisere og støtte mange af vedligeholdelsesopgaverne. A.6 Opgaveformulering Målet er opbygningen af en kravspecifikation for det ønskede dokumentationsværktøj. Dette indebærer følgende aktiviteter: - Studie af teorien bag produktmodellering for opbygning af forståelse for domænet. - Studie af det objektorienterede domæne og livscyklussen for objektorienteret systemudvikling. - Studie af lignende dokumentationsværktøjer. - Analyse af dokumentationsprocessen i produktmodelleringsforløb - baseret på både virksomhedernes og CPM s erfaringer. - Dokumentation af ønsker og krav ved hjælp af brugsmønstre og klassediagrammer. - Opbygning af prototype (skærmbilleder). - Vurdering af implementeringsmulighederne og økonomien i projektet. A.7 Fagkombination For at få en bedre indføring i domænet omkring produktmodellering har jeg fulgt kurset 42450 Industrielle Informations- og Specifikationssystemer på DTU. 164

A.9 Projektets løbetid A.8 Eventuelt A.9 Projektets løbetid måned (inkl. som- Påbegyndes 1/3 2002 og afsluttes 15/10 2002, dvs. i alt 7 1 2 merferie). A.10 Antal point Projektet er normeret til 30 ECTS-point, svarende til et halvt årsværk på DTU. A.11 Studerende Projektet er udført af Simon Pape (C958196). 165

Bilag B IDEF0 for produktmodelleringsprocessen USED AT: IPL/DTU AUTHOR: PROJECT: Simon Pape Requirements for Documentation Tool NOTES: 1 2 3 4 5 6 7 8 9 10 DATE: REV: 10/09/02 Decomposed Leaf x WORKING DRAFT RECOMMENDED PUBLICATION READER DATE CONTEXT: Top Formål, synsvinkel og kontekst Metodologi Produktdata Procesdata Opbyg produktkonfigurator A0 P. 2 Konfigurator Modellør Domæneekspert Formål: At klarlægge processen for produktmodellering Synsvinkel: Procesanalytisk med henblik på systemudvikling. Fokus på dokumentationsopgaven og relaterede dokumenter Kontekst: Sigtet er at klarlægge kravene til et IT-baseret dokumentationsværktøj til understøttelse af produktmodelleringsprocessen NODE: A-0 TITLE: Funktionsanalyse af produktmodelleringsprocessen NUMBER: P. 1 167

Bilag B - IDEF0 for produktmodelleringsprocessen USED AT: IPL/DTU AUTHOR: PROJECT: Simon Pape Requirements for Documentation Tool NOTES: 1 2 3 4 5 6 7 8 9 10 DATE: REV: 10/09/02 Decomposed Leaf x WORKING DRAFT RECOMMENDED PUBLICATION READER DATE CONTEXT: Fase 1 Analysér proces A1 Overordnet indhold af model Formål, synsvinkel og kontekst Produkt-Variant Master Fase 2 Analyser produkt A2 OOA Model (CRC kort, klassediagrammer mm.) O1 Konfigurator I1 Produktdata P. 3 Fase 3 Udfør OOA A3 P. 4 Fase 4 Udfør OOD OOD Model (fuldt detaljeret OO model) A4 P. 5 Fase 5 Programmér og test Dokumentation for modeltransformation Konfigurator A5 P. 6 Fase 6 Implementér løsning Opdateringer/ ændringer M2 Domæneekspert Programmør Fungerende system A6 Fase 7 Vedligehold system A7 P. 7 NODE: A0 TITLE: Opbyg produkt- konfigurator NUMBER: P. 2 USED AT: IPL/DTU AUTHOR: PROJECT: Simon Pape Requirements for Documentation Tool NOTES: 1 2 3 4 5 6 7 8 9 10 DATE: REV: 10/09/02 Decomposed Leaf x WORKING DRAFT RECOMMENDED PUBLICATION READER DATE CONTEXT: I1 Produktdata Identificér part-of og kind-of strukturer A21 Aggregerings- og generaliseringsstrukturer Saml moduler i prod. master A22 Rå produktmaster Produktinfomration Tilføj forklaringer og figurer A23 O1 Produkt-Variant Master M1 Domæ neekspert Produkt-Variant Master til endnu et gennemløb (iterationer) NODE: A2 TITLE: Fase 2 Analyser produkt NUMBER: SP1 P. 3 168

USED AT: IPL/DTU AUTHOR: PROJECT: Simon Pape Requirements for Documentation Tool NOTES: 1 2 3 4 5 6 7 8 9 10 DATE: REV: 10/09/02 Decomposed Leaf x WORKING DRAFT RECOMMENDED PUBLICATION READER DATE CONTEXT: Find objekter og klasser Liste af klasser A31 Identificér strukturer Råt klassediagram (kun tomme klasser + rel.) I1 Produkt-Variant Master I2 A32 Identificér temaer Råt, temaopdelt klassediagram Produktdata A33 Definér attributter Attributdefinitioner OOA Model (CRC kort, klassediagrammer mm.) O1 A34 Metodedefinitoner Definér metoder A35 Opbyg kravspecifikation A36 Use-cases, spec. af græ nseflader mv. M1 Domæ neekspert NODE: A3 TITLE: Fase 3 Udfør OOA NUMBER: SP2 P. 4 USED AT: IPL/DTU AUTHOR: PROJECT: Simon Pape Requirements for Documentation Tool NOTES: 1 2 3 4 5 6 7 8 9 10 DATE: REV: 10/09/02 Decomposed Leaf x WORKING DRAFT RECOMMENDED PUBLICATION READER DATE CONTEXT: Specifikation af brugergræ nseflade (skæ rmbilleder, udskrifter mv.) samt kobling til andre systemer Brugerstudier og -analyser OOA Model (CRC kort, klassediagrammer mm.) I1 I2 Produktdata Definér grænsefladekomponent A41 Tilret OOA-model A42 Fuldt detaljerede CRC-kort samt klassediagrammer Valgt system OOD Model (fuldt detaljeret OO model) O1 Fastlæg system (std. vs. eget) A44 Analyse af alternativer Fastlæg dataarkitektur A43 Valgt datastruktur Valgt systemarkitektur M1 Domæ neekspert Programmør/ teknisk konsulent NODE: A4 TITLE: Fase 4 Udfør OOD NUMBER: SP3 P. 5 169

Bilag B - IDEF0 for produktmodelleringsprocessen USED AT: IPL/DTU AUTHOR: PROJECT: Simon Pape Requirements for Documentation Tool NOTES: 1 2 3 4 5 6 7 8 9 10 Valgt system DATE: REV: 10/09/02 Decomposed Leaf x WORKING DRAFT RECOMMENDED PUBLICATION READER DATE CONTEXT: OOD Model (fuldt detaljeret OO model) I1 Transformér model til valgt system A51 Transformeret model Dokumentér transformation A52 Konventioner mv. Testplaner Dokumentation for modeltransformation O1 Programmér system Utestet system/modul A53 Test system Fungerende system O2 A54 M1 Programmør Fejlbehæ ftet system/modul NODE: A5 TITLE: Fase 5 Programmér og test NUMBER: SP4 P. 6 USED AT: IPL/DTU AUTHOR: PROJECT: Simon Pape Requirements for Documentation Tool NOTES: 1 2 3 4 5 6 7 8 9 10 DATE: REV: 10/09/02 Decomposed Leaf x WORKING DRAFT RECOMMENDED PUBLICATION READER DATE CONTEXT: Opdateringer/ æ ndringer C3 Modellér æ ndring Opdateret produktmodel A71 Opdateret produktmodel Eksisterende model og dokumentation Opdatér dokumentation A72 O1 Konfigurator Opdateret dokumentation for modeltransformation Implementér æ ndringer I1 Konfigurator Eksisterende system A73 Opdateret system NODE: A7 TITLE: Fase 7 Vedligehold system NUMBER: SP5 P. 7 170

Bilag C Mødereferater På de følgende sider er notater fra møder og samtaler samlet. 171

C.1 GEA Niro A/S, notat fra besøg 7/3 2002 C.1 GEA Niro A/S, notat fra besøg 7/3 2002 Til stede: Jesper Nielsen (JN, v92@niro.dk) og Michael Dam (MD, v92@niro.dk). GEA Niro A/S www.niro.dk Gladsaxevej 305 2860 Søborg Tlf.: +45 3954 5454 Fax.: +45 3954 5800 C.1.1 Eksamensprojekt JN og MD skriver p.t. eksamensprojekt ved IPL i samarbejde med GEA Niro A/S (Niro). Niro er en del af den store tyske virksomhedsgruppe GEA Group og fremstiller spaytørringsanlæg. Projektet drejer sig om, hvorledes produktmodeller kan bruges til at udveksle produktrelateret viden i netværk. Med netværk menes f.eks. forskellige nationale afdelinger af samme internationale virksomhed eller led i forsyningskæden. I forbindelse med projektet udarbejdes en produktmodel for en roterende forstøver (atomizer), som indgår som en del af et større fabriksanlæg. Produktmodellem opbygges i Oracles nye konfigurator, som netop understøtter opdelingen i hoved- og undermodeller. Hos Niro er der allerede sat en standard for dokumentationen, som bygger på Lotus Notes. En database er oprettet til formålet, og strukturen i denne er en hierarkisk opbygning af produktporteføljen. Et problem allerede her er naturligvis, at relationerne i produktporteføljen (produktserierne) ikke er hierarkiske. Databasen indeholder alle CRC-kort for objekterne i modellen, og i den forbindelse er det jo uhensigtsmæssigt, at dokumentation for en objektorienteret model er organiseret i en hierarkisk struktur. Notes har et indbygget simpelt tekstbehandlingsværktøj, som CRC-kortene er lavet i. I disse dokumenter kan laves links til andre (relaterede) dokumenter, og man anvender naturligvis dette til under collaborations at lave links til CRC-kortene for de relaterede objekter. Fordelen ved at anvende Notes er således - En simpel integration af CRC-kortene med hinanden og muligheden for at kunne anvende links til andre dokumenter. - Muligheden for at styre adgangsrettigheder til dokumenterne. - Versionsstyring? Notes-systemet understøtter dog ikke: - Udtræk af information på tværs af objekter (verificer) f.eks. - Rapporter med listning af metoder og attributter for objekter 173

Bilag C - Mødereferater - Nem oversigt over objekter og deres indbyrdes relationer - Integritetssikring af data, så f.eks. opdatering af relationer i et CRC-kort afspejles i CRC-kortet for det relaterede objekt. Som sådan virker Notes som et dokumenthåndteringssystem for CRC-kortene. 174

C.2 GEA Niro A/S, notat fra møde 12/9 2002 C.2 GEA Niro A/S, notat fra møde 12/9 2002 Til stede: Martin Malis (MM, mam@niro.dk). GEA Niro A/S www.niro.dk Gladsaxevej 305 2860 Søborg Tlf.: +45 3954 5454 Fax.: +45 3954 5800 C.2.1 Introduktion til Niro Niro A/S (Niro) er del af den tyske virksomhedsgruppe GEA Group, hvor virksomhederne i Niro-gruppen (herunder Niro A/S) tilsammen udgør P-divisionen (Powder Technology Division). Niro-gruppen består af 55 virksomheder fordelt over hele verden med omkring 2.300 ansatte heraf 350 i Danmark. Til sammenligning består GEA Group af 200 virksomheder med omkring 16.000 ansatte. Som del af P-divisionen leverer Niro færdige løsninger til behandling af pulver, hvor der trækkes på 70 års erfaring inden for området. Løsningerne kan både være turnkey-projekter eller aftersale fra procesanlæg til færdig fabrik. C.2.2 Produktmodellering hos Niro Interessen for produktmodellering hos Niro stammer tilbage fra midten af 1990 erne, hvor eksterne konsulenter i forbindelse med indførelsen af et nyt ERP-system foreslog Niro at anvende mulighederne i en konfigurator. ERP-projektet blev imidlertid stoppet, men i november 2000 kom et ph.d.- projekt i stand mellem Niro og Center for Produktmodellering med MM som ph.d.-studerende. Visionen var at anvende en konfigurator i en division (for en produktgruppe) og derefter udbrede den forventede succes til resten af virksomheden. Hos Niro valgte man at anvende Oracle Configurator, som en del af Oracle e-business Suite ver. 11.5.7. Til dette formål blev oprettet en projektgruppe bestående af medarbejdere fra salg, konstruktion og procesteknologi (domæneeksperter) og MM som modellør. Hertil kom kræfter fra ledelse og IT-afdelingen efter behov. Hos Niro ønskede man et tættere samarbejde med kræfter fra det akademiske miljø, og anvendelse af fremgangsmåden for opbygning af produktmodeller fra CPM vakte begejstring og blev fulgt meget tæt (blev dog tilpasset løbende). Efter de indledende analyser anvendes PVM en, indtil det bliver for kompliceret, så overskueligheden bliver for dårlig. Herefter modelleres videre med anvendelse af CRC-kort i en hierarkisk struktur. Erfaringen er, at PVM en giver en god overordnet fornemmelse for produktets opbygning, men det ville være hensigtsmæssigt at kunne opdele den i under-pvm er ved udskrift, så man kunne fokusere på den del af PVM en, som hører den enkelte division. Under udarbejdelse af PVM en savnede man i høj grad et dedikeret tegneprogram, som 175

Bilag C - Mødereferater Figur C.1: Eksempel på CRC-kort og træstruktur i Lotus Notes hos Niro understøttede en standardiseret anvendelse af symboler og lettede tegneprocessen. Til håndtering af CRC-kortene blev udviklet en løsning i Lotus Notes, som APC efterfølgende fik adgang til og videreudviklede (se figur C.1). Notes-løsningen betød, at man ikke benyttede sig af klassediagrammet, da klasserne herpå ikke kunne sammenkobles med CRC-kortene på en intelligent måde i Notes-løsningen 1. Herudover er MM s erfaring med klassediagrammet, at det hurtigt bliver forvirrende, da de mange relationer mellem klasserne gør diagrammet uoverskueligt. Et ønske i den forbindelse var muligheden for at kunne slå visningen af en relation til og fra på klassediagrammet, så kun de vigtigste relationer vises. Herudover blev foreslået, at man ved at markere en klasse i klassediagrammet kunne få fremhævet alle de klasser, der var berørt af den markerede klasse. I forbindelse med udviklingen af Notes-løsningen blev CRC-kortet tilpasset i forhold til den oprindelige udformning. Bl.a. blev Does -feltet opdelt i systemmetoder og produktmetoder, og feltet med generaliserings-relationerne blev fjernet, da Notes-løsningen ikke kan vise dette (og konfiguratoren næppe understøtte det... ). Et forslag til et kommende dokumentationsværktøj ville derfor være muligheden for at kunne indstille modelleringsparadigmet til enten traditio- 1 Notes-løsningen er detaljeret beskrevet i bilag C.4 176

C.2 GEA Niro A/S, notat fra møde 12/9 2002 nel struktureret eller objektorienteret. Indstillingen skulle så afspejle sig i bl.a., hvilke felter der anvendtes på CRC-kortet. MM fremhævede Notes hierarkiske træstruktur som en god måde at navigere i sine klasser, men pointerede samtidig, at det var en stor ulempe, at det ikke var muligt at se bindingerne imellem klasserne. Vedligeholdelsen af produktmodellen bør efter MM s mening placeres hos domæneeksperterne, forstået på den måde, at domæneeksperterne er ansvarlige for, at indholdet er korrekt, mens modellører sørger for konsistens og korrekthed. I den sammenhæng er det vigtigt, at domæneeksperterne kan anvende alm. hverdagssprog og tabeller til at angive bindinger og regler. 177

C.3 APC Denmark A/S, notat fra telefonsamtale 7/3 2002 C.3 APC Denmark A/S, notat fra telefonsamtale 7/3 2002 Fortroligt, ikke medtaget i denne udgave. 179

Bilag C - Mødereferater Fortroligt, ikke medtaget i denne udgave. 180

C.4 APC Denmark A/S, notat fra besøg 18/4 2002 C.4 APC Denmark A/S, notat fra besøg 18/4 2002 Fortroligt, ikke medtaget i denne udgave. 181

Bilag C - Mødereferater Fortroligt, ikke medtaget i denne udgave. 182

C.4 APC Denmark A/S, notat fra besøg 18/4 2002 Fortroligt, ikke medtaget i denne udgave. 183

Bilag C - Mødereferater Fortroligt, ikke medtaget i denne udgave. 184

C.4 APC Denmark A/S, notat fra besøg 18/4 2002 Fortroligt, ikke medtaget i denne udgave. 185

Bilag C - Mødereferater Fortroligt, ikke medtaget i denne udgave. 186

C.4 APC Denmark A/S, notat fra besøg 18/4 2002 Fortroligt, ikke medtaget i denne udgave. 187

Bilag C - Mødereferater Fortroligt, ikke medtaget i denne udgave. 188

C.5 F.L. Smidth, notat fra besøg 15/8 2002 C.5 F.L. Smidth, notat fra besøg 15/8 2002 Til stede: Søren Poulsen (SP, soeren.poulsen@flsmidth.com). F.L. Smidth A/S www.flsmidth.com Vigerslev Allé 77 2500 Valby Tlf.: +45 3618 1000 Fax.: +45 3630 1820 C.5.1 Virksomheden F.L. Smidth A/S (FLS) er en del af FLS Industries. FLS s produkter kan opdeles i tre grupper: - komplette cementfabrikker - enkeltstående maskiner og renoveringsopgaver - reservedele og kundeservice Kontaktpersonen SP er ansat som IT-medarbejder i tilbudsafdelingen og indgår således ikke i virksomhedens IT-afdeling. SP er uddannet maskiningeniør og startede som montør i FLS. Siden hen kom han tilbage til hovedsædet og blev specialist i en afdeling med ansvar for styklister og ordrer. Som fuldtids ITmedarbejder er han primært tilknyttet arbejdet med budgetkonfiguratoren og de kommende konfiguratorer for typevalg (læs mere om disse senere). C.5.2 Produktkonfigurering hos FLS I virksomheden startede man omkring 1998 på at udvikle en konfigurator, som skulle støtte arbejdet med tilbudsgivning på komplette cementfabrikker. Projektet blev startet af Claus Torbøl, som stadig er ansat i FLS. Valget faldt dengang på en konfigurator fra Baan med begrundelse i, at deres udviklingsafdelingen var tæt på, og FLS derudover blev tilbudt at kunne indgå aktivt i udviklingen af konfiguratoren og dermed sætte sit eget præg på resultatet. Samarbejdet med Baan har fungeret godt, og man anvender stadig BaanConfiguration 98.2. Projektet startede med, at der blev nedsat en arbejdsgruppe, der skulle udvikle konfiguratoren. Hertil blev tilknyttet en følgegruppe, som bestod af (faglige) specialister. Deres rolle var at forsyne arbejdsgruppen med al den produktviden, de havde brug for. Arbejdsgruppen var således udviklere, mens følgegruppen var domæneeksperter. Al produktviden blev tastet direkte ind i konfiguratoren uden at lave en egentlig dokumentation sideløbende 2. I den anvendte konfigurator er der ikke mulighed for at relatere bindinger og produktdele. I konfiguratoren opbygges et hierarki af produktdele, og uafhængigt heraf laves en række bindinger, som opererer på 2 En studerende fra instituttet (Line Hemmingsen) har efterfølgende dokumenteret alle designreglerne (bindingerne) i et selvstændigt dokument ved at beskrive dem i ren tekst. 189

Bilag C - Mødereferater Figur C.2: Skærmbillede fra FLS s konfigurator produktdelene og disses egenskaber. Bindingerne kan ikke navngives og er derfor svære at identificere. Resultatet af udviklingen er, at man nu har en konfigurator, hvor koden minder mest om spaghetti. Ifølge SP er konfiguratoren delvis årsag til dette, da det er muligt at lave spaghetti-kode. Konfiguratoren lægger ikke selv op til en struktureret fremgangsmåde og dokumentation. Det betyder, at det er meget svært at se konsekvensen af at ændre f.eks. en enkelt binding. Tilbudsafdelingen har ansvaret for vedligeholdelse af konfiguratoren, og SP har del i dette arbejde. Alle relevante medarbejdere og afdelinger ved, at der eksisterer en konfigurator, som er afhængig af, at grundlaget er opdateret. Således har de enkelte afdelinger ansvaret for, at deres del af konfiguratoren regner rigtigt. Opdateringer foregår ved, at en specialist sender en e-mail til tilbudsafdelingen med angivelse af, hvad der skal ændres. På den måde får man i tilbudsafdelingen rigtig mange e-mails, og for hver e-mail skal den relevante kode i konfiguratoren findes og ændres. 190

C.5 F.L. Smidth, notat fra besøg 15/8 2002 C.5.2.1 Nye modelleringsprojekter Med ovenstående konfigureringsprojekt har man hos FLS gjort sig nogle erfaringer, som man naturligvis vil bruge i kommende projekter. For det første har man lært utroligt meget om modelleringsteknik eller rettere hvad konsekvenserne er af ikke at analyse og designe til bunds, inden kodningen går i gang. For det andet har man lært, at det ikke kan betale sig at lave dokumentation efterfølgende. Den næste projekt er udviklingen af konfiguratorer til konfigurering af dele af en fabrik (transportsystemer til materialetransport mellem de enkelte maskingrupper). Fremgangsmåden er her lidt anderledes, idet man først opbygger dokumentationen i samarbejde med domæneeksperterne. Dokumentationen består af primært regneark med beskrivelse af alle produkterne og de indgående dele. For hvert (del)produkt laves et regneark med beskrivelse af proces og designregler. Regneark er valgt, da de specialister, der har den fornødne viden, i forvejen er fortrolige med anvendelse af regneark til dels at skrive formler og lign. i, dels at tegne kasser og flowcharts. Regnearkene er på ingen måde integreret med hinanden eller andre systemer. Når dokumentationen er på plads overleveres denne til en gruppe programmører, som får til opgave at opbygge konfiguratoren. Specialisterne har således et incitament til at lave dokumentationen rigtigt, idet de ellers vil blive kontaktet senere af programmørerne, som skal have afklaring på nogle detaljer. Oven i udfordringen med den nye konfigurator er man i FLS ved at lægge sidste hånd på udviklingen af et nyt ERP- og PDM-system. Systemet udvikles af den interne IT-afdeling, og i relation til konfiguratorerne bliver udviklet nogle grænseflader, så systemerne kan integreres. C.5.3 Krav til dokumentationsværktøj Den største fordel ved et dokumentationsværktøj vil være at kunne få et overblik over produktmodellen og (især) bindingerne. En visualisering vil være meget anvendeligt (f.eks. som relationer mellem klasser). I den forbindelse har man med glæde set lanceringen af ibaan, som langt hen ad vejen giver et godt overblik over produktmodellen. De nye typevalgskonfiguratorer skal opbygges i ibaan. Med erfaringer fra det hidtidige arbejde med produktmodellering og udsigten til et kommende dokumentationsværktøj har SP en række krav eller ønsker, som vil gøre værktøjet mere interessant: Et meddelelsesmodul ville være utroligt anvendeligt, idet det kunne koble domæneeksperter og udviklere tættere sammen. Domæneeksperterne må ikke få adgang til at ændre i modellen, men det ville være formålstjenligt, hvis de kunne have læseadgang til modellen og på en simpel måde sende et ændringsforslag til den ansvarlige udvikler. 191

Bilag C - Mødereferater Hyperlinks bør kunne bruges i alle tekstfelter. Ofte er der brug for at kunne relatere til et eksternt dokument, og samtidig kunne et dokumentationsværktøj bruges som et centralt medium for dokumentation. Dokumentationsværktøjet skulle ikke nødvendigvis indeholde al informationen, men kunne linke videre til denne. Internettet bør være grundstammen for kommunikationen mellem klienten og den centrale server. FLS vil have brug for, at medarbejdere kan tilgå systemet uafhængigt af deres geografiske placering. Det er dog ikke essentielt, at værktøjet afvikles via en browser, idet brugeren altid vil have en personlig computer til rådighed, hvorpå klienten kan installeres. Det er ikke et krav, at man kan tilgå systemet fra en tilfældig computer med en browser. Eksterne databaser skal kunne integreres med værktøjet, så det er muligt at hente oplysninger om f.eks. pris og vægt for forskellige produktdele i virksomhedens ERP-system. Overførsel fra dokumentation til konfigurator vil klart være en fordel. Om ikke andet så for at slippe for at taste information ind manuelt flere gange. Visionen er at bruge produktmodellen i dokumentationsværktøjet som master og så lade konfiguratoren afspejle denne. Hvis det ikke er muligt at overføre automatisk, så kræver opdateringer to arbejdsgange: Opdatering af dokumentationen og opdatering af konfiguratoren. Hvis arbejdet med opdatering af dokumentationen ikke er besværligt, ser SP ikke noget problem i dette. Basering på standardsystemer bør efter SP s opfattelse undgås. Hvis man f.eks. forestiller sig, at værktøjet baseres på Lotus Notes, vil det kræve, at FLS skal indkøbe og indføre dette system for alle medarbejdere. Dette er i konflikt med den overordnede IT-politik og vil ikke være foreneligt med IT-afdelingens beslutninger på området for virksomhedens fælles IT-systemer (som p.t. er baseret på Microsofts produkter). Men det er ikke til hinder for, at værktøjet kan udformes på en sådan måde, at f.eks. Lotus Notes kan sammenkobles med værktøjet; det bør bare ikke være et krav. 192

C.6 Vitral A/S, notat fra besøg 9/4 2002 C.6 Vitral A/S, notat fra besøg 9/4 2002 Fortroligt, ikke medtaget i denne udgave. 193

Bilag C - Mødereferater Fortroligt, ikke medtaget i denne udgave. 194

C.6 Vitral A/S, notat fra besøg 9/4 2002 Fortroligt, ikke medtaget i denne udgave. 195

Bilag D Brugsmønstre Beskrivelserne for brugsmønstrene er medtaget på det følgende sider og er inspireret af opstillingen i Whitten et al. [2001, s. 662]. Tallene i Reference -feltet henviser til aktiviteterne i IDEF0-modellen (bilag B). En oversigt over alle brugsmønstre findes i tabel D.1 på følgende side. Overordnet brugsmønsterdiagram, side 199 Klynge: Administration, side 205 Klynge: PVM, side 213 Klynge: CRC-kort, side 223 Klynge: Klassediagram, side 241 197

Bilag D - Brugsmønstre ID Side Navn 1.1 200 Log på systemet 1.2 201 Log af systemet 1.3 202 Definér rapportskabelon 1.4 203 Vis rapport «uses»udskriv 1.5 204 Udskriv 2.1 206 Redigér projekt 2.2 207 Redigér bruger 2.3 208 Redigér gruppe 2.4 209 Redigér felt på CRC-kort «uses»redigér link til ekstern DB 2.5 210 Redigér link til ekstern DB 2.6 211 Definér global rapportskabelon «extends»definér rapportskabelon 2.7 212 Konfigurér meddelelsesmodul 3.1 214 Redigér illustration 3.2 215 Redigér note 3.3 216 Opret ny PVM «uses»vis PVM 3.4 217 Vis PVM «uses»udskriv PVM 3.5 218 Udskriv PVM «uses»udskriv 3.6 219 Tilføj part-of klasse «uses»redigér CRC-kort 3.7 220 Tilføj kind-of klasse «uses»redigér CRC-kort 3.8 221 Redigér PVM-klasse «extends»redigér CRC-kort 3.9 222 Redigér binding «extends»redigér metode 4.1 224 Vis historik for CRC-kort «uses»udskriv 4.2 225 Vis version af CRC-kort «extends»vis CRC-kort 4.3 226 Gem ny version af CRC-kort 4.4 227 Vis CRC-kort «uses»udskriv 4.5 228 Ændr CRC-kort status 4.6 229 Godkend ændringer «uses»sammenlign to versioner af CRC-kort 4.7 230 Sammenlign to ver. af CRC-kort «extends»vis CRC-kort 4.8 231 Redigér attribut 4.9 232 Redigér metode 4.10 233 Redigér CRC-kort «uses»gem ny verison af CRC-kort, Ændr CRC-kort status, Redigér attribut, Redigér metode «extends»vis CRC-kort 4.11 234 Godkend CRC-kort 4.12 235 Foreslå ændring «uses»send meddelelse om ændringsforslag 4.13 236 Send meddelelse om ændringsforslag 4.14 237 Send meddelelse om uberørt klasse 4.15 238 Søg i CRC-kort «uses»vis CRC-kort 4.16 239 Vis oversigt over CRC-kort 5.1 242 Overfør model til konfigurator 5.2 243 Sammenlign dokumentation med konfigurator 5.3 244 Redigér klynge «uses»vis klassediagram 5.4 245 Redigér tema 5.5 246 Redigér relation 5.6 247 Opret nyt klassediagram «uses»importér struktur fra PVM 5.7 248 Tilføj klasse «uses»redigér CRC-kort 5.8 249 Vis klasse «extends»vis CRC-kort 5.9 250 Vis klassediagram «uses»udskriv, Udlæg klassediagram 5.10 251 Udlæg klassediagram 5.11 252 Importér struktur fra PVM Tabel D.1: Oversigt over brugsmønstre 198

D.1 Topdiagram D.1 Topdiagram Dokumentationsvæ rktøj Administration Log på systemet Administrator Log af systemet Definér rapportskabelon «uses» Udskriv Domæ neekspert Vis rapport Tiden PVM CRC-kort Kommunikationssystem Modellør Klassediagram Konfigurator Figur D.1: Brugsmønsterdiagram, topniveau 199

Bilag D - Brugsmønstre ID - Navn Reference Aktør(er) Beskrivelse Forudsætning Resultat Typisk scenarie 1.1 - Log på systemet A0 Administrator, Modellør, Domæneekspert En bruger identificerer sig overfor systemet og gives adgang til funktionerne. Brugeren er logget af systemet. Brugeren er logget på systemet Aktør Trin 1: Initieres når en aktør starter systemet. System Trin 2: Vis en dialogboks, hvor brugernavn og adgangskode skal indtastes Alternativt scenarie Antagelser Trin 3: Brugernavn og adgangskode indtastes. Trin 5: Et projekt vælges. Der eksisterer mindst ét projekt. Trin 4: Hvis brugernavn eksisterer i brugerdatabasen og adgangskode er gyldig vises en ny dialogboks med en liste over eksisterende projekter. Trin 6: For det valgte projekt startes op med at vise det diagram, der var aktivt da denne aktør sidst loggede af. Trin 7: Der skrives et indlæg i loggen med information om tidpunkt og bruger. Trin 4: Hvis brugernavn ikke findes eller adgangskode ikke passer, vises en advarsel om dette og der startes fra trin 2. 200

D.1 Topdiagram ID - Navn Reference Aktør(er) Beskrivelse Forudsætning Resultat Typisk scenarie Alternativt scenarie Antagelser 1.2 - Log af systemet A0 Administrator, Modellør, Domæneekspert En bruger logger sig af systemet. Brugeren er logget på systemet. Brugeren er logget af systemet Aktør Trin 1: Initieres når en aktør ønsker at afslutte arbejdet med værktøjet. Trin 3: Valget bekræftes Ingen p.t. System Trin 2: Der vises en dialogboks, hvor aktøren skal bekræfte at ville logge af. Trin 4: Det noteres hvilket diagram, der er aktivt til brug for næste login. Trin 5: Der skrives et indlæg i loggen med information om tidspunkt og bruger. Trin 3: Hvis valget annulleres returneres til det aktive skærmbillede. 201

Bilag D - Brugsmønstre ID - Navn Reference Aktør(er) Beskrivelse Forudsætning Resultat Typisk scenarie Alternativt scenarie Antagelser 1.3 - Definér rapportskabelon A0 Administrator, Modellør Redigering og oprettelse af en skabelon for rapporter til udtræk af information fra produktmodellen. En skabelon er oprettet og tilgængelig for brugerne af systemet. Aktør Trin 1: Initieres når en aktør ønsker at lave en skabelon for en rapport. Trin 3: Der vælges hvilke felter rapporten skal bestå af, og også deres rækkefølge. Trin 4: Når felterne er valgt, navngives skabelonen. System Trin 2: Der vises en dialogboks, hvor det er muligt at angive hvilke datafelter rapporten skal bestå af. Der er mulighed for at definere rækkefølgen af felterne, og tilføje et filter-kriterie for hvert enkelt felt. Trin 5: Rapportskabelonen gemmes og er tilgængelig for brugerne af det aktuelle projekt. Trin 6: Der gives også mulighed for at åbne eksisterende skabeloner (ikke globale) og ændre i disse. Fortsæt fra trin 3 når skabelon er valgt. Information kan trækkes ud af produktmodeldatabasen vha. et formaliseret forespørgselssprog, f.eks. SQL. 202

D.1 Topdiagram ID - Navn Reference Aktør(er) Beskrivelse Forudsætning Resultat Typisk scenarie 1.4 - Vis rapport «uses»udskriv A0 Modellør En rapport vises med udtræk af information fra produktmodellen baseret på en foruddefineret skabelon. Rapporten kan udskrives. Der eksisterer mindst én tilgængelig rapportskabelon. En rapport er vist og evt. udskrevet. Aktør Trin 1: Initieres når en aktør vil have vist eller udskrevet en rapport. System Trin 2: Der vises en liste over tilgængelige rapportskabeloner både lokale og globale. Alternativt scenarie Trin 3: En rapportskabelon vælges. Trin 6: Aktøren vælger at udskrive rapporten. Trin 4: For den valgte skabelon genereres rapporten ud fra indholdet af produktmodeldatabasen. Trin 5: Rapporten vises på skærmen som en tabel, hvor kolonnerne svarer til rapportskabelonens felter og rækkene til indholdet af felterne. Det er muligt at vælge at udskrive rapporten. Trin 7: Kald Udskriv. Antagelser Information kan trækkes ud af produktmodeldatabasen vha. et formaliseret forespørgselssprog, f.eks. SQL. 203

Bilag D - Brugsmønstre ID - Navn Reference Aktør(er) Beskrivelse Forudsætning Resultat Typisk scenarie Alternativt scenarie Antagelser 1.5 - Udskriv A0 Modellør, Domæneekspert Forskellige elementer kan udskrives, og her beskrives hvordan man f.eks. kan udskrive en stor side over flere sider. Dette brugsmønster forventer at indholdet, der skal udskrives er defineret forud. Det aktuelle dokument er udskrevet på en tilsluttet printer. Aktør Trin 1: Initieres, når noget skal udskrives på en tilkoblet printer. Trin 3: Aktøren foretager sine valg og indstillinger og vælger at printe. System Trin 2: Der vises en dialogboks, hvor det er muligt at vælge printer, indstille printeren og vælge et sideinterval der skal udskrives. Herudover er det muligt at vælge udskrivning over flere sider (når dokumenter, der fylder mere end printerens papir skal udskrives). Trin 4: Dokumentet printes via operativsystemets printerdrivere. Trin 4: Hvis der i trin 3 er valgt at printe over flere sider, foretages en opdeling af det store dokument til printeresn papirstørrelse, så de udprintede sider overlapper hinanden lidt. Herefter printes via operativsystemets printerdrivere. Der eksisterer en veldefineret grænseflade til håndtering af udskrivning i operativsystemet, som kan bruges. 204

D.2 Klynge: Administration D.2 Klynge: Administration Administration Redigér projekt Redigér bruger 'Redigér'-brugsmønstre beskriver også oprettelse Redigér gruppe Redigér felt på CRC-kort «uses» Topdiagram::Administrator Redigér link til ekstern DB Definér global rapportskabelon «extends» Topdiagram::Definér rapportskabelon Konfigurér meddelelsesmodul Figur D.2: Brugsmønsterdiagram, klynge: Administration 205

Bilag D - Brugsmønstre ID - Navn Reference Aktør(er) Beskrivelse Forudsætning Resultat Typisk scenarie 2.1 - Redigér projekt A0 Administrator Redigering og oprettelse af et nyt projekt. Et projekt indeholder én produktmodel, men kan indeholde flere diagrammer. Det aktuelle projekt er redigeret (evt. oprettet). Aktør Trin 1: Initieres når et nyt projekt skal oprettes eller et eksisterende redigeres i administrationsmodulet. System Trin 2: Der vises en dialogboks med en liste over alle tilgængelige projekter. Herudover er det muligt at oprette et nyt projekt. Alternativt scenarie Antagelser Trin 3: Der vælges et projekt. Trin 5: Aktøren ændrer i egenskaberne og vælger at afslutte. Trin 7: Aktøren godkender ændringerne. Ingen p.t. Trin 4: Der vises en dialogboks med projektets egenskaber (projektnavn, beskrivelse, projektleder, medarbejdere). Det er muligt at ændre egenskaberne. Projektnavn og beskrivelse er rene tekstfelter, mens indholdet af projektleder- og medarbejder-felterne vælges fra en liste indeholdende brugerne fra brugerdatabasen. Trin 6: Det undersøges om alle felter har en værdi, og aktøren bliver bedt om at godkende, at der er foretaget ændringer. Trin 8: Ændringerne gemmes, og der returneres til skærmbilledet før dette brugsmønster. Trin 6: Hvis ikke alle felter har en værdi, returneres til trin 4. Trin 8: Hvis aktøren ikke godkender ændringerne afsluttes uden at gemme ændringer. 206

D.2 Klynge: Administration ID - Navn Reference Aktør(er) Beskrivelse Forudsætning Resultat Typisk scenarie 2.2 - Redigér bruger A0 Administrator Redigering og oprettelse af en bruger af systemet. Kun oprettede brugere kan tilgå systemet. Oplysningerne om den aktuelle bruger er opdateret (evt. ny bruger oprettet). Aktør Trin 1: Initieres når aktøren vælger Redigér bruger i administrationsmodulet. System Trin 2: En dialogboks vises med en liste over de oprettede brugere af systemet. Trin 3: Der vælges en bruger fra listen. Trin 4: En ny dialogboks vises med den valgte brugers informationer, herunder en liste over hvilke grupper brugeren er medlem af. En administrator kan ikke slette sig selv fra Administrator -gruppen. Alternativt scenarie Antagelser Trin 5: Aktøren foretager sine ændringer og afslutter. Trin 6: Ændringerne gemmes i brugerdatabasen. Trin 2: Hvis aktøren vælger Tilføj bruger i trin 2 gås til trin 4 oven for, hvor alle felterne blot er tomme. Brugerdatabasen samkøres ikke med virksomhedens centrale brugerdatabase. 207

Bilag D - Brugsmønstre ID - Navn Reference Aktør(er) Beskrivelse Forudsætning Resultat Typisk scenarie 2.3 - Redigér gruppe A0 Administrator Brugere kan være medlemmer af grupper. Adgang til at ændre i en model kan tildeles enten individuelle brugere eller grupper af brugere. Medlemmerne af en gruppe kan redigeres via dette brugsmønster. Der eksisterer mindst én bruger i systemet. Medlemslisten for en gruppe er opdateret (evt. en ny gruppe oprettet). Aktør Trin 1: Initieres ved at aktøren vælger Redigér gruppe i administrationsmodulet. System Trin 2: En dialogboks vises med en liste over de eksisterende grupper. Alternativt scenarie Antagelser Trin 3: Akøren vælger en gruppe fra listen. Trin 5: De ønskede ændringer foretages ved at trække brugere fra den ene liste til den anden med musen. Trin 3: Aktøren indtaster et navn. Ingen p.t. Trin 4: Der vises en dialogboks, hvor der er to lister; én med de brugere, der ikke er tilknyttet gruppen og én med de brugere, der er tilknyttet den aktuelle gruppe. Trin 6: Ændringerne gemmes i brugerdatabasen. En administrator kan ikke slette sig selv fra Administrator -gruppen. Trin 2: Hvis aktøren vælger Tilføj gruppe i trin 2 oven for vises en dialogboks, hvor navnet på den nye gruppe skal indtastes. Trin 4: Det tjekkes om der eksisterer en gruppe med det angivne navn. Hvis ikke oprettes en ny gruppe, og der fortsættes fra trin 4 oven for, hvor listen med brugere tilknyttet gruppen er tom. Hvis navnet eksisterer vises en advarsel om dette, og der returneres til dialogboksen, hvor navnet kan indtastes. 208

D.2 Klynge: Administration ID - Navn Reference Aktør(er) Beskrivelse Forudsætning Resultat Typisk scenarie 2.4 - Redigér felt på CRC-kort «uses»redigér link til ekstern DB A0 Administrator CRC-kort kan indeholde brugerdefinerede felter. Her beskrives hvordan disse oprettes og redigeres. Den globale skabelon for et CRC-kort er opdateret. Aktør Trin 1: Initieres ved at aktøren vælger Redigér felt på CRC-kort i adminstrationsmodulet. System Trin 2: En dialogboks vises med en liste over de eksisterende brugerdefinerede felter på CRC-kort skabelonen. Rækkefølgen i listen afspejler rækkefølgen på CRC-kortet. Alternativt scenarie Antagelser Trin 3: Et felt vælges fra listen. Trin 5: Der højreklikkes på et felt i tabellen og vælges Indsæt attribut. Trin 7: Der vælges en type. Trin 9: Der højreklikkes på symbolet og vælges Redigér indstillinger. Trin 3: Aktøren vælger Indsæt nyt felt. Ingen p.t. Trin 4: En dialogboks vises med en tabel, der afspejler opbygningen af det brugerdefinerede felt. I tabellens felter kan skrives formateret statisk tekst eller indsættes en brugerdefineret attribut. Antallet af rækker og kolonner kan justeres. Trin 6: Feltet ændres, så der ikke kan skrives statisk tekst og en dialogboks vises med en liste over de typer af attributter, der kan indsættes. Trin 8: Der returneres til tabellen, og et symbol indsættes for den givne attributtype. Trin 10: En dialogboks vises med en liste over indstillingsparametrene for den aktuelle attributtype og mulighed for at redigere værdien af parametrene. Hvis typen er et databaselink redigeres egenskaberne ved at kalde Redigér link til ekstern DB. Trin 4: En dialogboks vises, hvor et feltnavn skal angives. Når dette er angivet vises en tom tabel med 2*2 felter og der fortsættes fra trin 4. 209

Bilag D - Brugsmønstre ID - Navn Reference Aktør(er) Beskrivelse Forudsætning Resultat Typisk scenarie 2.5 - Redigér link til eksterne DB A0 Administrator De brugerdefinerede felter kan indeholde attributter, hvor værdien hentes fra eksterne databaser. Her beskrives hvordan disse links vedligeholdes og oprettes. Der eksisterer et brugerdefineret felt, hvor linket kan indsættes. Der eksisterer en database, der kan linkes til. Linket til databasen er opdateret (evt. oprettet). Aktør Trin 1: Intieres ved kald fra Redigér felt på CRC-kort. System Trin 2: En dialogboks vises med egenskaberne for et databaselink (placering af databasen og indhold af forespørgsel i SQL). Alternativt scenarie Trin 3: Databasens placering angives og et SQL udtryk indtastes. I SQL udtrykket kan refereres til feltværdier i CRC-kortet. Trin 4: Ændringerne gemmes. Antagelser Det er muligt at lave et link til en ekstern database og forespørge via SQL. 210

D.2 Klynge: Administration ID - Navn Reference Aktør(er) Beskrivelse Forudsætning Resultat Typisk scenarie Alternativt scenarie Antagelser 2.6 - Definér global rapportskabelon «extends»definér rapportskabelon A0 Administrator Udvider Definér rapportskabelon med muligheden for at lave skabeloner, der er tilgængelige for alle brugere af systemet. En global skabelon er opdateret (evt. oprettet) og tilgængelig for brugerne. Aktør Trin 1: Initieres ved at aktøren vælger Definér global skabelon i administrationsmodulet. Skabeloner kan gøres tilgængelige for alle brugere af systemet. System Trin 2: Forløbet svarer til trinene i Definér rapportskabelon, med forskel fra lagringen af skabelonen. Når skabelonen lagres gøres den tilgængelig for alle brugere af alle projekter i den givne installation. 211

Bilag D - Brugsmønstre ID - Navn Reference Aktør(er) Beskrivelse Forudsætning Resultat Typisk scenarie 2.7 - Konfigurér meddelelsemodul A0 Administrator Beskriver opsætning af integration med virksomhedens kommunikationssystem og ændring af tidsinterval for automatisk notifikation. Aktør Trin 1: Initieres når aktøren vælger Konfigurér meddelelsesmodul i adminstrationsmodulet. System Trin 2: En dialogboks vises, hvor det er muligt at ændre egenskaberne for opkobling til virksomhedens kommunikationssystem, og endvidere er det muligt at angive hvor lang tid en klasse med status Under udarbejdelse skal ligge uberørt før en meddelelse automatisk udsendes. Alternativt scenarie Trin 3: Aktøren ændrer i indstillingerne. Trin 4: Ændringerne gemmes. Antagelser Det er muligt at benytte et eksisterende kommunikationssystem til at sende meddelelserne. 212

D.3 Klynge: Produkt-Variant Master D.3 Klynge: Produkt-Variant Master PVM Redigér illustration «uses» Redigér note Opret ny PVM «uses» 'Redigér'-brugsmønstre beskriver også oprettelse CRC-kort::Indsæ t hyperlink Topdiagram::Domæ neekspert Vis PVM «uses» Udskriv PVM «uses» Topdiagram::Udskriv Tilføj part-of klasse «uses» Topdiagram::Modellør Tilføj kind-of klasse Redigér PVM-klasse «uses» «extends» CRC-kort::Redigér CRC-kort «uses» Redigér binding «extends» CRC-kort::Redigér metode Figur D.3: Brugsmønsterdiagram, klynge: PVM 213

Bilag D - Brugsmønstre ID - Navn Reference Aktør(er) Beskrivelse Forudsætning Resultat Typisk scenarie 3.1 - Redigér illustration A23 Modellør Ændring af størrelse og position for indsat illustration, samt indstillinger for link til illustrationsfilen (samt indsættelse af ny illustration). Der eksisterer en illustration i en understøttet filformat. Størrelse og position af indsat illustration er opdateret (evt. ny illustration indsat). Aktør Trin 1: Initieres ved at aktøren klikker på en eksisterende illustration eller vælger at indsætte en ny. Ved at trække i illustrationens hjørner kan størrelsen og positionen ændres. System Trin 2: Ændringer i størrelse og position vises løbende. Trin 3: Når aktøren klikker væk fra illustrationen, gemmes position og størrelse Alternativt scenarie Antagelser Trin 4: Ved at dobbeltklikke på illustrationen vises en dialogboks, hvor det er muligt at indtaste en lokal sti eller en URL til illustrations-filen. Herudover er det muligt at finde filer a la den klassiske Gennemse... -dialogboks fra Windows. Trin 1: Kan også initieres ved at vælge Indsæt illustration fra en menu. Herved gås til trin 4. Visning af illustrationer understøttes. Trin 5: Når dialogboksen lukkes gemmes ændringerne og noteres i loggen. 214

D.3 Klynge: Produkt-Variant Master ID - Navn Reference Aktør(er) Beskrivelse Forudsætning Resultat Typisk scenarie 3.2 - Redigér note A23 Modellør Noter kan indsættes i PVM en. En note redigeres med et lille tekstbehandlingssystem (understøtter tabeller). Indholdet af en note er opdateret (evt. oprettet). Aktør Trin 1: Initieres når aktøren klikker på en eksisterende note. Ved at trække i notens hjørner kan størrelsen og positionen af tekstfeltet ændres. Tekstlinjer ombrydes automatisk efter tekstfeltets bredde. System Trin 2: Notens tekst åbnes i et vindue a la et mini -tekstbehandlingsvindue, hvor det er muligt at formatere teksten (størrelse, skriftsnit osv.) samt indsætte tabeller. Trin 3: Det er også muligt at indsætte hyperlinks til andre dokumenter eller interne elementer. Alternativt scenarie Antagelser Trin 4: Aktøren redigerer teksten og vælger at afslutte. Trin 1: Kan også initieres ved at vælge Indsæt note fra en menu. Herved gås til trin 2. Ingen p.t. Trin 5: Vinduet lukkes, ændringerne gemmes og den nye tekst vises. Ændringerne noteres i loggen. 215

Bilag D - Brugsmønstre ID - Navn Reference Aktør(er) Beskrivelse Forudsætning Resultat Typisk scenarie 3.3 - Opret ny PVM «uses»vis PVM A2 Modellør Inden for det samme projekt kan arbejdes med flere PVM er. Her beskrives hvordan de redigeres og oprettes. Et projekt eksisterer. En eksisterende PVM er opdateret eller en ny oprettet. Aktør Trin 1: Initieres ved at aktøren fra en menu vælger at oprette en ny PVM. System Trin 2: Der vises en dialogboks, hvor PVM ens navn og beskrivelse indtastes. Alternativt scenarie Antagelser Trin 3: Aktøren indtaster den nødvendige information. Ingen p.t. Trin 4: Når informationen er indtastet og aktøren lukker dialogboksen, gemmes de indtastede oplysninger, og der tilføjes oplysninger om tidspunktet og hvem der oprettede PVM en. Trin 5: Herefter vises den tomme PVM ved at kalde Vis PVM. Oprettelsen noteres i loggen. 216

D.3 Klynge: Produkt-Variant Master ID - Navn Reference Aktør(er) Beskrivelse Forudsætning Resultat Typisk scenarie 3.4 - Vis PVM «uses»udskriv PVM A2 Modellør, Domæneekspert PVM en vises i overenstemmelse med retningslinjerne for det grafiske udseende. PVM en kan udskrives. Aktør Trin 1: Initieres når en PVM skal vises. System Trin 2: Hvis ikke det er angivet hvilken af projektets PVM er der skal vises, vises en dialogboks med en liste over projektets PVM er. Trin 3: Aktøren vælger en PVM. Trin 4: Dialogboksen lukkes og den valgte PVM tegnes i et nyt, maksimeret vindue. For hver klasse vises kun de attributter, hvor synlighed er slået til. Bindinger mellem klasser vises kun for de bindinger, hvor synlighed er slået til. Positionen for kind-of strukturer, noter og illustrationer kan ændres ved at trække dem rundt med musen. Alternativt scenarie Antagelser Trin 5: Aktøren kan herefter arbejde videre med PVM en eller udskrive denne. Vælges de sidste kaldes Udskriv PVM. Ingen p.t. 217

Bilag D - Brugsmønstre ID - Navn Reference Aktør(er) Beskrivelse Forudsætning Resultat Typisk scenarie Alternativt scenarie Antagelser 3.5 - Udskriv PVM «uses»udskriv A2 Modellør Udskriver hele PVM en eller udvalgte dele vha. Udskriv. PVM en er udskrevet. Aktør Trin 1: Initieres når aktøren har valgt at udskrive den aktive PVM. Ingen p.t. System Trin 2: Hvis en del af PVM en er markeret udskrives dette område (inkl. de markerede illustrationer og noter), ellers udskrives hele PVM en. I begge tilfælde kaldes Udskriv. 218

D.3 Klynge: Produkt-Variant Master ID - Navn Reference Aktør(er) Beskrivelse Forudsætning Resultat Typisk scenarie Alternativt scenarie 3.6 - Tilføj part-of klasse «uses»redigér CRC-kort A21 Modellør Part-of klasser tilføjes i strukturen i venstre side af PVM en. Her beskrives hvorledes de tilføjes til PVM en. En ny klasse er tilføjet i PVM ens part-of hierarki. Aktør Trin 1: Initieres når aktøren højreklikker på en klasse i PVM en og vælger Tilføj part-of klasse. Trin 1a: Kan også initieres ved på en tom PVM at højreklikke et vilkårligt sted på PVM en og vælge Ny topklasse. System Trin 2: En ny klasse oprettes i produktmodeldatabasen som underklasse til klassen, der blev højreklikket på i et aggregeringshierarki (med stærke aggregeringsrelationer). Herefter kaldes Redigér CRC-kort. Trin 3: Når indtastningen af oplysninger er færdig gentegnes PVM en, så den nye klasse vises. Ændringerne noteres i loggen. Trin 2a: Den første klasse i en PVM oprettes som topklasse, som alle andre klasser er underklasser til. Antagelser Trin 1b: Kan også initieres ved at aktøren højreklikker på en klasse og vælger Indsæt klasse efter. Ingen p.t. Trin 2b: En ny klasse oprettes på samme niveau som den, der blev højreklikket på. Herefter kaldes Redigér CRC-kort og fortsættes fra trin 3 ovenfor. 219

Bilag D - Brugsmønstre ID - Navn Reference Aktør(er) Beskrivelse Forudsætning 3.7 - Tilføj kind-of klasse «uses»redigér CRC-kort A21 Modellør Kind-of klasser tilføjes som strukturer relateret til en klasse i part-of hierarkiet. Her beskrives hvordan kind-of klasser tilføjes. Der eksisterer mindst én klasse i part-of hierarkiet. Resultat En kind-of struktur er tilføjet med mindst to klasser i. Typisk scenarie Aktør Trin 1: Initieres når aktøren højreklikker på en klasse i part-of hierarkiet i PVM en og vælger Tilføj kind-of klasse. System Trin 2: En dialogboks vises, hvor antallet af nye klasser skal vælges (minimum to). Alternativt scenarie Antagelser Trin 3: Aktøren vælger antallet af klasser. Trin 6: Akøren flytter den nye struktur på plads ved at tage fat i et af elementerne med musen og placere den et ønsket sted. Ingen p.t. Trin 4: Et antal nye klasser oprettes i produktmodeldatabasen i et generaliseringshierarki som underklasser til klassen der blev højreklikket på. Trin 5: For hver af de nye klasser kaldes Redigér CRC-kort, og til slut gentegnes PVM en, så de nye klasser vises. Ændringerne noteres i loggen. Trin 7: Forbindelseslinjen mellem klassen i part-of strukturen og den nye kind-of struktur tegnes automatisk. Trin 2: Hvis klassen der højreklikkes på i forvejen har en kind-of struktur tilknyttet, så gås direkte til trin 4, hvor der blot oprettes én ny klasse. 220

D.3 Klynge: Produkt-Variant Master ID - Navn Reference Aktør(er) Beskrivelse Forudsætning Resultat Typisk scenarie Alternativt scenarie 3.8 - Redigér PVM-klasse «extends»redigér CRC-kort A2 Modellør ved at dobbeltklikke på en klasse i PVM en kan klassen redigeres. Der eksisterer mindst én klasse i PVM en CRC-kortet for en klasse er opdateret (klasse evt. slettet). Aktør Trin 1: Initieres ved at der dobbeltklikkes på en klasse i PVM en. Trin 3: Aktøren vælger at slette klassen. System Trin 2: Redigér CRC-kort kaldes. Trin 4: Det undersøges om klassen har et andre klasser under sig, og hvis det er tilfældet gives en advarsel om, at disse klasser slettes samtidig. Antagelser Trin 5: Aktøren accepterer advarslen. Ingen p.t. Trin 6: Klassen og klasserne under den slettes fra produktmodeldatabasen, og sletningen ntoeres i loggen. 221

Bilag D - Brugsmønstre ID - Navn Reference Aktør(er) Beskrivelse Forudsætning Resultat Typisk scenarie 3.9 - Redigér binding «extends»redigér metode A22 Modellør Bindinger viser koblingen mellem klasserne i PVM en. Bindinger dokumenteres som klassens metoder, og her beskrives hvordan de redigeres (evt. oprettes). Der eksisterer to klasser. En binding er opdateret (evt. oprettet). Aktør Trin 1: Initieres ved at dobbeltklikke på en eksisterende binding. System Trin 2: Der vises en dialogboks, hvor bindingens navn og den tekst, der skal vises ved siden af bindingen kan ændres. Herudover er der mulighed for at åbne en ny dialogboks, hvor alle metodens egenskaber kan redigeres (en binding er en metode). Alternativt scenarie Antagelser Trin 3: Aktøren foretager de ønskede ændringer og vælger at redigere metodens egenskaber. Trin 5: Aktøren foretager de ønskede ændringer og afslutter. Trin 1: kan også initieres ved at højreklikke på en klasse og vælge Tilføj binding. Herved skal der i dialogboksen fra trin 2 også vælges hvilken klasse, der skal være den anden klasse i bindingen. Ingen p.t. Trin 4: Redigér metode kaldes. Trin 6: Ændringerne gemmes i produktmodeldatabasen og noteres i loggen. 222

D.4 Klynge: CRC-kort D.4 Klynge: CRC-kort ðîñ*ð%ò óô õ ö ù 4 ù ý ý ý ø ù úù û 2 ú ÿ 2 1 ø ù ù ú 1 úù ú ý ù / ý þ ú ú ù ú ' 5 $ ý ø ù ú ù û ú ú ÿ ùû ù ý ø ù úù û üý þ ÿ % &ÿ ù ù ú ù ý! ý ú ú ÿ ùû '$ ( ú ) ú *! ý ø ù ú ùû ú ú ÿ ù û ¾ýÿ ú ÿ(,- ÿ ú ú ú ù ý ý ø ù ú ù û ¾ý ÿ ú ÿ( ý ü ý þ ÿ ý ÿ ú ú ÿ ú ý ÿ ú ø ù ú ùû ú ÿ ý. ý ú ù/,0 ÿ ø ù ú ùû ú ÿ 1 ø ø ù ú ù û ø ù úù û üý þÿ % +'ý,- ú ú ù þ ú "# ÿ $ ý ù ý ú ù ý ú ý ù ø ù ' ú ÿ5 ú ÿ ÿ ú ú ù ú ý,- ÿ ù ý ù üýþ ÿ ü ÿ ú ' ú ÿ% ú ÿÿ ú ú ù ú ý ø 1 ú ù ù ú ü ý þ ÿ % 3ý ( ø ý ù ù ù ú Figur D.4: Brugsmønsterdiagram, klynge: CRC-kort 223

Bilag D - Brugsmønstre ID - Navn Reference Aktør(er) Beskrivelse Forudsætning Resultat Typisk scenarie Alternativt scenarie Antagelser 4.1 - Vis historik for CRC-kort «uses»udskriv A2, A3, A4 Modellør For hvert CRC-kort kan vises en liste over de ændringer, CRC-kortet har gennemgået. Listen kan udskrives. Der er foretaget ændringer i CRC-kortet. En liste over CRC-kortets ændringer vises (udskrives evt.). Aktør Trin 1: Initieres ved at markere en klasse og vælge Vis historik eller ved at vælge Vis historik i et åbent CRC-kort. Trin 3: Aktøren bladrer igennem listen og vælger at udskrive. Trin 3: Aktøren markerer et sammenhængende udvalg af ændringer og vælger udskriv. System Trin 2: Et nyt vindue åbnes med en liste over de ændringer der er foretaget i det pågældende CRC-kort (fra loggen). Listen kan sorteres efter kronologi eller brugernavn (for den der udførte ændringen). For hver ændring vises datoen for ændringen, hvem der udførte den, hvad der blev udført og CRC-kortets version samt status efter ændringen blev gemt. Listen kan udskrives. Trin 4: Listen formateres til udskrift og Udskriv kaldes. Trin 4: Kun de markerede ændringer formateres og Udskriv kaldes. I loggen gemmes information om ændringer, ændringstidspunkt, hvem der har foretaget ændringen, typen af ændring, og hvad der er ændret. 224

D.4 Klynge: CRC-kort ID - Navn Reference Aktør(er) Beskrivelse Forudsætning Resultat Typisk scenarie 4.2 - Vis version af CRC-kort «extends»vis CRC-kort A2, A3, A4 Modellør Der kan eksistere flere versioner af samme CRC-kort. Her beskrives hvordan en given version kan vises. Den ønskede version af CRC-kortet vises. Aktør Trin 1: Initieres på samme måde som Vis CRC-kort System Trin 2: En dialogboks vises med en liste over de tilgængelige versioner af CRC-kortet, hvor versionsnummer og den tilhørende kommentar vises. Alternativt scenarie Antagelser Trin 3: Aktøren vælger en version fra listen. Ingen p.t. Trin 4: Herfra er trinene som i Vis CRC-kort. 225

Bilag D - Brugsmønstre ID - Navn Reference Aktør(er) Beskrivelse Forudsætning Resultat Typisk scenarie 4.3 - Gem ny version af CRC-kort A2, A3, A4 Modellør Nye versioner af et CRC-kort gemmes manuelt. Versionsnummeret kan enten vælges af systemet eller angives af aktøren. En ny version af CRC-kortet er gemt med det ønskede versionsnummer. Aktør Trin 1: Initieres når aktøren vælger Gem ny version i et åbent CRC-kort. System Trin 2: En dialogboks vises, hvor der kan indtastes en kommentar til versionsændringen. Det nuværende versionsnummer vises, og det er muligt at angive det nye versionsnummer. Alternativt scenarie Antagelser Trin 3: Aktøren indtaster en kommentar og bekræfter at en ny version skal gemmes. Trin 3: Aktøren vælger selv et nyt versionsnummer. Ingen p.t. Trin 4: En ny version af CRC-kortet gemmes, hvor versionsnummeret er sat til det næste i rækkefølgen. Status sættes til under udarbejdelse for den nye version; status for det gamle CRC-kort er uændret. Ændringen gemmes i loggen. Trin 4: Hvis et nyt versionsnummer er angivet tjekkes om det er højere end det højest eksisterende. Hvis det er tilfældet bruges dette;hvis ikke vises en fejlmeddelse og der returneres til trin 2. 226

D.4 Klynge: CRC-kort ID - Navn Reference Aktør(er) Beskrivelse Forudsætning Resultat Typisk scenarie 4.4 - Vis CRC-kort «uses»udskriv A2, A3, A4 Modellør, Domæneekspert Indholdet af en klasse kan vises opstillet som et CRC-kort. CRC-kortet kan udskrives. Et CRC-kort er vist og evt. udskrevet. Aktør Trin 1: Initieres når et CRC-kort skal vises. System Trin 2: Et maksimeret vindue vises, opbygget som et CRC-kort (i henhold til specifikation). Det er ikke muligt at redigere i feltværdierne. Alternativt scenarie Antagelser Trin 3: Aktøren vælger at udskrive CRC-kortet. Ingen p.t. Trin 4: CRC-kortet formateres, så sideskift placeres mest hensigtsmæssigt og Udskriv kaldes. Trin 2: Hvis der eksisterer et brugerdefineret felt med link til en ekstern database oprettes dette link og forespørgslen udføres, så indholdet af feltet opdateres. Eventuelle referencer til felter på CRCkort omsættes til en værdi, som kan bruges i SQL-udtrykket. 227

Bilag D - Brugsmønstre ID - Navn Reference Aktør(er) Beskrivelse Forudsætning Resultat Typisk scenarie 4.5 - Ændr CRC-kort status A2, A3, A4 Modellør Et CRC-kort kan have forskellige statuser. Her beskrives hvordan denne ændres. Status for det aktuelle CRC-kort er ændret. Aktør Trin 1: Initieres ved at der vælges Ændr status i en menu for det åbne CRC-kort. System Trin 2: En dialogboks vises med angivelse af de mulige statuser, et CRC-kort kan have ( under udarbejdelse, passiv eller implementeret ). Den aktuelle status er markeret. Det er ikke muligt at vælge status godkendt, men muligheden vises. Alternativt scenarie Antagelser Trin 3: Aktøren vælger en ny status for CRC-kortet Ingen p.t. Trin 4: CRC-kortet gemmes med den nye status og ændringen noteres i loggen. Trin 4a: Hvis status ændres til implementeret tjekkes om der i forvejen findes en version af CRC-kortet, der har denne status. I så fald vises en advarsel om at gennemførelse af ændringen vil betyde, at det andet CRC-kort der har status implementeret vil få ændret dette til passiv, mens det aktive CRC-kort vil få status implementeret. Accepteres advarselen gemmes med disse ændringer; hvis ikke returneres til trin 2. Trin 4b: Hvis status ændres fra implementeret gives en advarsel om, at der ikke eksisterer en version af CRC-kortet med status implementeret. 228

D.4 Klynge: CRC-kort ID - Navn Reference Aktør(er) Beskrivelse Forudsætning Resultat Typisk scenarie 4.6 - Godkend ændringer «uses»sammenlign to versioner af CRC-kort A7 Modellør Domæneeksperters ændringer af CRC-kort skal godkendes af en modellør før de effektueres. Der eksisterer et ændringsforslag, og der er udsendt en meddelelse om forslaget til ejeren af CRC-kortet. Ændringsforslaget er enten accepteret eller afvist. Aktør Trin 1: Initieres når aktøren responderer på et link i en meddelelse fra systemet om, at der foreligger et ændringsforslag. System Trin 2: Sammenlign 2 ver. Af CRC-kort kaldes for at sammenligne det originale CRC-kort med det ændrede. Hver ændring kan enten accepteres eller afvises, og det er muligt for aktøren at rette i ændringen. Alternativt scenarie Antagelser Trin 3: Aktøren gennemgår ændringerne og accepterer/afviser disse. Ingen p.t. Trin 4: Når ændringerne er gennemgået gemmes CRC-kortet, og det noteres i loggen. I loggen noteres også, at ændringerne stammer fra et ændringsforslag, og det angives hvem der har stillet forslaget. 229

Bilag D - Brugsmønstre ID - Navn Reference Aktør(er) Beskrivelse Forudsætning Resultat Typisk scenarie 4.7 - Sammenlign to versioner af CRC-kort «extends»vis CRC-kort A0 Modellør To versioner af samme CRC-kort kan sammenlignes for forskelle. Forskelle vises ved hjælp af farver. Der eksisterer mindst to versioner af CRC-kortet. Aktør Trin 1: Initieres ved at aktøren vælger at ville sammenligne to versioner af et CRC-kort. System Trin 2: En dialogboks vises med en liste over de tilgængelige versioner for det pågældende CRC-kort. Alternativt scenarie Antagelser Trin 3: Aktøren vælger to versionsnumre. Ingen p.t. Trin 4: CRC-kortet for det laveste versionsnummer vises som i Vis CRC-kort, og forskellene i forhold til det højeste versionsnummer er fremhævet. En tilføjelse er markeret med en anden farve (for både tekst og symboler), og hvis noget er fjernet er dette vist ved at gennemstrege det frem for ikke at vise det (inspireret af Track changes -funktionen i MS Word). 230

D.4 Klynge: CRC-kort ID - Navn Reference Aktør(er) Beskrivelse Forudsætning Resultat Typisk scenarie 4.8 - Redigér attribut A2, A34 Modellør En klasses attributter kan redigeres i forbindelse med visning af klassens CRC-kort. Attributten er opdateret (evt. oprettet). Aktør Trin 1: Initieres ved at aktøren dobbeltklikker på en attribut i et CRC-kort. System Trin 2: En dialogboks vises med attributtens egenskaber (navn, type, enhed, værdiinterval og note). Typen vælges fra en liste og i noten kan indsættes hyperlinks til eksterne dokumenter og interne elementer. Det er muligt at slette attributten. Alternativt scenarie Antagelser Trin 3: Aktøren ændrer egenskaberne efter behov. Ingen p.t. Trin 4: Det sikres at attributten har et navn. Ændringerne gemmes og noteres i loggen. Trin 2: Hvis en attribut ikke eksisterer oprettes en ny i produktmodeldatabasen og dialogboksen vises, men med tomme felter. 231

Bilag D - Brugsmønstre ID - Navn Reference Aktør(er) Beskrivelse Forudsætning Resultat Typisk scenarie 4.9 - Redigér metode A2, A34 Modellør En klasses metoder kan redigeres i forbindelse med visning af klassens CRC-kort. Metoden er opdateret (evt. oprettet). Aktør Trin 1: Initieres ved at aktøren dobbeltklikker på en metode i et CRC-kort. System Trin 2: En dialogboks vises med metodens egenskaber (navn, type, tekst, PVM-tekst, evt. relateret klasse og note). Typen vælges fra en liste og i noten kan indsættes hyperlinks til eksterne dokumenter og interne elementer. En evt. relateret klasse vælges fra en liste med eksisterende klasser i modellen. Det er muligt at slette metoden. Alternativt scenarie Antagelser Trin 3: Aktøren ændrer egenskaberne efter behov. Ingen p.t. Trin 4: Det sikres at metoden har et navn. Ændringerne gemmes og noteres i loggen. Trin 2: Hvis en metode ikke eksisterer oprettes en ny i produktmodeldatabasen og dialogboksen vises, men med tomme felter. 232

D.4 Klynge: CRC-kort ID - Navn Reference Aktør(er) Beskrivelse Forudsætning Resultat Typisk scenarie 4.10 - Redigér CRC-kort «uses»gem ny version af CRC-kort, Ændr CRC-kort status, Redigér attribut, Redigér metode «extends»vis CRC-kort A2, A3, A4, A7 Modellør En klasses egenskaber ændres gennem visning af klassens CRC-kort. Klassens egenskaber er ændret. Aktør Trin 1: Initieres ved at aktøren vælger at redigere CRC-kortet i forbindelse med Vis CRC-kort. System Trin 2: Det undersøges om CRC-kortet er åbnet af andre brugere. Trin 3: Hvis ikke låses CRC-kortet (samt de elementer, der kan påvirke eller påvirkes af CRC-kortet) mod ændringer fra andre brugere. Trin 4: CRC-kortets værdifelter (undtagen ID, oprettelsesdato, attributter og metoder) kan redigeres direkte ved at skrive i felterne. Kun CRC-kortets ejer kan ændre i Ejer -feltet og Med-redaktører - feltet. Alternativt scenarie Trin 5: Aktøren ændrer i indholdet og dobbeltklikker evt. på attributter eller metoder. Trin 7: Afsluttes ved at aktøren lukker visningen af CRC-kortet. Trin 6: Dobbeltklikkes på en attribut kaldes Redigér attribut. Dobbeltklikkes på en metode kaldes Redigér metode. I en menu kan vælges at gemme en ny version af CRC-kortet eller ændre CRC-kortets status. Vælges disse kaldes Gem ny version af CRC-kort henholdsvis Ændr CRC-kort status. Trin 3: Hvis en anden bruger har låst CRC-kortet mod ændringer vises en besked om dette med oplysninger om hvem der har låst CRC-kortet. Antagelser Trin 8: Aktøren vælger at slette klassen. Trin 11: Aktøren accepterer advarslen. Ingen p.t. Trin 9: Samme tjek som i trin 2 oven for. Trin 10: Det undersøges om klassen har et andre klasser under sig, og hvis det er tilfældet gives en advarsel om, at disse klasser slettes samtidig. Trin 12: Klassen og klasserne under den slettes fra produktmodeldatabasen, og sletningen noteres i loggen. 233

Bilag D - Brugsmønstre ID - Navn Reference Aktør(er) Beskrivelse Forudsætning Resultat Typisk scenarie 4.11 - Godkend CRC-kort A4 Domæneekspert Domæneeksperter skal lave den endelige godkendelse af et CRC-korts udformning ved at ændre kortets status til Godkendt. CRC-kortets status er ændret til godkendt. Aktør Trin 1: Initieres ved at aktøren vælger Godkend CRC-kort i en menu for for det åbne CRC-kort. System Trin 2: En dialogboks vises med angivelse af CRC-kortets aktuelle status og mulighed for at godkende eller annullere godkendelsen. Alternativt scenarie Antagelser Trin 3: Aktøren vælger at trykke på knappen Godkend i dialogboksen. Trin 3: Brugeren vælger at annullere godkendelsen. Ingen p.t. Trin 4: CRC-kortet gemmes med den nye status, og ændringerne noteres i loggen. Trin 4: Dialogboksen lukkes og ingen ændringer gemmes. 234

D.4 Klynge: CRC-kort ID - Navn Reference Aktør(er) Beskrivelse Forudsætning Resultat Typisk scenarie 4.12 - Foreslå ændring «uses»send meddelelse om ændringsforslag A7 Domæneekspert Domæneeksperter kan ikke ændre en klasses egenskaber direkte, men kan stille ændringsforslag, som skal effektueres af en modellør. Besked herom sendes automatisk til modelløren. Et ændringsforslag er stillet og besked er sendt til ejeren af CRC-kortet. Aktør Trin 1: Initieres ved at en aktør vælger Foreslå ændring under visning af et CRC-kort (som beskrevet i Vis CRC-kort). System Trin 2: Under visningen af CRC-kortet kan aktøren kun se indholdet af felterne, men ikke redigere disse. Alternativt scenarie Antagelser Trin 3: Aktøren dobbeltklikker på en attribut eller metode. Trin 5: Aktøren trykker på Forslag til ændring. Trin 7: Aktøren foretager ændringer og vælger Send. Trin 3: Et forslag kan også stilles for andre elementer end attributter og metoder. Det gøres ved at højreklikke på elementet i CRC-kortet og vælge Forslag til ændring. Herved fortsættes fra trin 6. Ingen p.t. Trin 4: Attributtens eller metodens detaljer vises i et vindue, men kan ikke redigeres. I stedet kan vælges at sende et ændringsforslag. Trin 6: Detaljerne kan nu redigeres. Trin 8: Der gemmes en kopi af CRCkortet med de foretagede ændringer, og Send meddelelse om ændring kaldes med ejeren af CRC-kortet som modtager. 235

Bilag D - Brugsmønstre ID - Navn Reference Aktør(er) Beskrivelse Forudsætning Resultat Typisk scenarie Alternativt scenarie Antagelser 4.13 - Send meddelelse om ændringsforslag A7 Kommunikationssystem Når et ændringsforslag er stillet sendes besked til ejeren af CRC-kortet. Et ændringsforslag er stillet. Integrationen med kommunikationssystemet er konfigureret. Besked er sendt til ejeren af CRC-kortet. Aktør Trin 3: Der kvitteres med en bekræftelse af afsendelsen. Beskeder kan sendes via et eksternt kommunikationssystem. System Trin 1: Initieres ved kald fra Forslå ændring. Trin 2: Der dannes en standardbesked med et link til det ændrede element. Beskeden sendes via Kommunikationssystem. 236

D.4 Klynge: CRC-kort ID - Navn Reference Aktør(er) Beskrivelse Forudsætning Resultat Typisk scenarie Alternativt scenarie Antagelser 4.14 - Send meddelelse om uberørt klasse A2, A3, A4, A7 Tiden Når en klasse er under udarbejdelse sendes automatisk besked til ejeren, hvis klassen ikke er tilgået inden for et defineret tidsrum. Integrationen med kommunikationssystemet er konfigureret. Besked Aktør Trin 1: Initieres når et CRC-kort med status Under udarbejdelse ikke er blevet ændret af ejer eller med-redaktører i den foruddefinerede tidsperiode. Trin 3: Der kvitteres med en bekræftelse af afsendelsen. Beskeder kan sendes via et eksternt kommunikationssystem. System Trin 2: Der dannes en stanardbesked med henvisning (og link) til det pågældende CRC-kort. 237

Bilag D - Brugsmønstre ID - Navn Reference Aktør(er) Beskrivelse Forudsætning Resultat Typisk scenarie 4.15 - Søg i CRC-kort «uses»vis CRC-kort A2, A3, A4, A7 Modellør Det er muligt at søge på alle felter i CRC-kortene og på den måde finde et specifikt kort. En liste vises med CRC-kort, der matcher søgekriterierne. Aktør Trin 1: Initieres ved at der vælges Søg i CRC-kort. System Trin 2: Der vises en dialogboks med et felt hvor søgestrengen kan skrives og en liste over felterne på et CRC-kort. Det er muligt at markere flere felter på denne liste. Det er muligt at angive om søgningen skal begrænses til det åbne projekt, eller om der skal søges globalt i alle tilgængelige projekter. Som udgangspunkt er søgningen begrænset til det åbne projekt. Alternativt scenarie Antagelser Trin 3: Aktøren vælger hvilke felter der skal søges inden for, og skriver en søgestreng. Trin 6: Aktøren dobbeltklikker på et CRC-kort i listen. Ingen p.t. Trin 4: Produktmodeldatabasen søges igennem ved søgning i de valgte felter. Trin 5: Resultatet vises i en liste indeholdende felterne klassenavn, klasse ID, beskrivelse, dato for oprettelse samt de felter, der blev søgt i. Trin 7: Vis CRC-kort kaldes og viser det aktuelle CRC-kort. Trin 5: Hvis der ikke findes et CRCkort, der matcher søgekritereiet, vises en besked om dette, og der returneres til dialogboksen i trin 2. 238

D.4 Klynge: CRC-kort ID - Navn Reference Aktør(er) Beskrivelse Forudsætning Resultat Typisk scenarie 4.16 - Vis oversigt over CRC-kort A2, A3, A4 Modellør En oversigt over alle CRC-kort i modellen kan vises, sorteret efter navn. Det er muligt at søge i listen. En liste over alle CRC-kort vises i et separat vindue. Aktør Trin 1: Initieres ved at aktøren vælger Vis lister over CRC-kort. System Trin 2: Et vindue åbnes, hvor en liste over alle CRC-kort i produktmodellen vises. Er en PVM aktiv vises alle CRCkort, hvor kontekst er lig PVM ; er et klassediagram aktivt vises kun de CRCkort, hvor kontekst er lig Klassediagram. Ved hjælp af farver eller symboler angives for hvert CRC-kort om den tilsvarende klasse er inkluderet i det aktive diagram. Alternativt scenarie Antagelser Trin 3: Aktøren trækker med musen et CRC-kort fra listen over i det aktive diagram. Ingen p.t. Trin 4: Klassen tilføjes i diagrammet, og alle underliggende aggregeringsstrukturer og overliggende generaliseringsstrukturer tilføjes automatisk, hvis de ikke allerede eksisterer i diagrammet. I listen opdateres farven eller symbolet for de(n) tilføjede klasse(r). 239

D.5 Klynge: Klassediagram D.5 Klynge: Klassediagram 657 8!99:!;< 8= > 8? aq B G ^ M G LR C B U O D U P R N ^ DE JG W O R G `$W LL B N U DE N C R P J H L B N O W O DR N L B C(P R N ^ DE J G W O R G @ AB C DE F G @H I G J E K H LM N K O G BIBK P G DQ B G R E K S R T G B O O B UK B AB C DEF G O B L W a T G B O N b O P UW K K B H C DW E G W L [ J K B K \ c LT R G O F G K O G J P O J G ^ G W(d e Y V R T C DW E G W L(X X ] R N ^ DE J G W O R G e!dkp UW K K B [ B f O B N C K\ i-j(ï k lm!n o p p q5rsti5j(ï k lm!n o V R T C DW E G W L X X YR C B U U M G A B C DE F G P Ub N E B V D U^ M h P UW K K B [ J K B K\ edkp UW K K B C DW E G W L [ J K BK \ [ J K B K\ u vw o v!x y s$z u{ s v s z gagh P R G O X X AB C DE F G gagh P R G O [ J K B K \ Z C U_%E P UW K K B C DW H E G W L V R T C DWE G W L X X Z C K P G DQ m} y r ~!n ~ p p m ƒ x$v$v ls } v n o Figur D.5: Brugsmønsterdiagram, klynge: Klassediagram 241

Bilag D - Brugsmønstre ID - Navn Reference Aktør(er) Beskrivelse Forudsætning Resultat Typisk scenarie Alternativt scenarie Antagelser 5.1 - Overfør model til konfigurator A51 Modellør Afhængigt af den valgte konfigurator kan produktmodellen i dokumentationsværktøjet overføres til konfiguratoren. Konfiguratoren kan indlæse produktmodeller fra andre systemer. En fil (filsæt) er genereret og kan indlæses i konfiguratoren. Aktør Trin 1: Initieres ved at aktøren vælger Overfør til konfigurator. System Trin 2: På baggrund af det aktive klassediagram og retningslinjerne for konfiguratorens filformat genereres en fil (eller et sæt af filer), som konfiguratoren kan indlæse. Handlingen noteres i loggen. Det er muligt entydigt at definere hvordan produktmodellen skal overføres til konfiguratoren. 242

D.5 Klynge: Klassediagram ID - Navn Reference Aktør(er) Beskrivelse Forudsætning Resultat Typisk scenarie 5.2 - Sammenlign dokumentation med konfigurator A5, A7 Modellør, Konfigurator Produktmodellen fra dokumentationsværktøjet sammenlignes med strukturen i konfiguratoren, og forskelle tydeliggøres. Konfiguratorens produktmodel kan tilgås for eksterne systemer. Der vises en rapport, hvor forskellene summeres. Aktør Trin 1: Initieres når aktøren vælger Sammenlign med konfigurator. System Trin 2: Konfiguratorens produktmodel indlæses og analyseres. Trin 3: Der oprettes et nyt klassediagram med samme navn som det aktive, blot tilføjet - sammenligning <dato> (f.eks. Generator A11 - sammenligning 23/5 2002 ). Klassediagrammet kan ikke redigeres. I klassediagrammet anvendes samme notationsform som i Sammenlign 2 ver. af CRC-kort, dvs. fællestræk vises med en farve (sort), elementer der er i dokumentation, men ikke i konfigurator vises med en anden farve (rød) og elementer, der er i konfigurator men ikke i dokumentationen vises med en tredje farve (blå). Det er muligt at udskrive klassediagrammet; herved kaldes Udskriv på samme måde som i Vis klassediagram. Handlingen noteres i loggen. Alternativt scenarie Trin 4: Aktøren vælger at få udskrevet en rapport. Trin 6: Aktøren vælger at udskrive en rapport. Trin 5: En dialogboks vises, hvor aktøren kan vælge mellem tre rapporter; en rapport med alle forskelle, en rapport med de ting, der mangler i dokumentationen i forhold til konfiguratoren samt en rapport over de ting, der mangler i konfiguratoren i forhold til dokumentationen. Trin 7: Rapporten formateres med hensyn til valget af indhold og Udskriv kaldes. Antagelser Det er muligt at læse konfiguratorens produktmodel og entydigt analyse strukturen. 243

Bilag D - Brugsmønstre ID - Navn Reference Aktør(er) Beskrivelse Forudsætning Resultat Typisk scenarie Alternativt scenarie Antagelser 5.3 - Redigér klynge «uses»vis klassediagram A32 Modellør Klassediagrammet for en klynge redigeres (eller oprettes), så den omfatter de ønskede klasser. Klassediagrammet for en klynge vises og kan redigeres. Alternativt oprettes en ny klynge. Aktør Trin 1: Initieres ved at aktøren dobbeltklikker på på en eksisterende klynge Trin 1: Kan også initieres ved at aktøren vælger Opret klynge. Trin 3: Aktøren indtaster navnet på den nye klynge. System Trin 2: Vis klassediagram kaldes for at vise den pågældende klynge. Trin 2: En dialogboks vises, hvor aktøren skal indtaste navn for klyngen. Trin 4: En ny klynge oprettes og vises på klassediagrammet. Ændringen registreres i loggen. Klasser kan kopieres mellem klynger ved traditionel marker-kopiér-sæt-ind funktionalitet. 244

D.5 Klynge: Klassediagram ID - Navn Reference Aktør(er) Beskrivelse Forudsætning Resultat Typisk scenarie Alternativt scenarie Antagelser 5.4 - Redigér tema A33 Modellør Et tema redigeres (eller oprettes), så det omfatter de ønskede klasser. Der eksisterer mindst to klasser i klassediagrammet. Aktør Trin 1: Initieres ved at aktøren med musen tager fat i stregen, der repræsenterer temaet. Størrelse og position af temaet kan ændres med musen. Trin 1: Kan også initieres ved at aktøren vælger Opret tema". Ingen p.t. System Trin 2: Når temaet slippes med musen registreres ændringerne og gemmes i databasen. Det registreres også hvilke klasser, der er indbefattet af temaet. Ændringen noteres i loggen. Trin 2: En dialogboks vises, hvor aktøren skal indtaste navn for temaet. Musemarkøren ændrer udseende og der lægges op til at aktøren med musen skal trække en firkant i klassediagrammet fortsæt fra trin 1 oven for. 245

Bilag D - Brugsmønstre ID - Navn Reference Aktør(er) Beskrivelse Forudsætning Resultat Typisk scenarie 5.5 - Redigér relation A33 Modellør En relation redigeres (eller oprettes), for at forbinde to klasser. Der eksisterer mindst to klasser i klassediagrammet. Relationen mellem to klasser er opdateret (evt. oprettet). Aktør Trin 1: Initieres ved at aktøren dobbeltklikker på en relation i et klassediagram. System Trin 2: En dialogboks åbnes, hvor alle egenskaberne for relationen kan redigeres. Alternativt scenarie Antagelser Trin 3: Aktøren redigerer egenskaberne for relationen. Trin 1: Kan også initieres ved at aktøren vælger Tilføj relation. Trin 3: Aktøren trækker en linje mellem to klasser. Ingen p.t. Trin 4: Oplysningerne gemmes og relationen gentegnes så grafikken afspejler egenskaberne. Trin 2: Musemarkøren ændres til et linjesymbol. Trin 4: Der fortsættes fra trin 2 ovenfor. 246

D.5 Klynge: Klassediagram ID - Navn Reference Aktør(er) Beskrivelse Forudsætning Resultat Typisk scenarie 5.6 - Opret nyt klassediagram «uses»importér struktur fra PVM A3 Modellør Et nyt klassediagram oprettes og baseres evt. på strukturen fra en PVM. Et nyt klassediagram er oprettet. Aktør Trin 1: Initieres ved at aktøren vælger Opret nyt klassediagram. System Trin 2: En dialogboks vises hvor aktøren skal give klassediagrammet et navn. Alternativt scenarie Antagelser Trin 3: Aktøren navngiver klassediagrammet. Trin 1: Initieres også når Vis klassediagram kaldes, og der ikke eksisterer et klassediagram. Trin 3: Aktøren vælger desuden at basere klassediagrammet på en eksisterende PVM. Ingen p.t. Trin 4: Det tjekkes om der eksisterer et klassediagram med det samme navn. Hvis ikke oprettes et nyt, tomt klassediagram, som vises. Trin 2: Der gives mulighed for at basere det nye klassediagram på en eksisterende PVM. Trin 4: Det tjekkes om der eksisterer et klassediagram med det samme navn. Hvis ikke oprettes et nyt og Importér struktur fra PVM kaldes. 247

Bilag D - Brugsmønstre ID - Navn Reference Aktør(er) Beskrivelse Forudsætning Resultat Typisk scenarie Alternativt scenarie Antagelser 5.7 - Tilføj klasse «uses»redigér CRC-kort A3 Modellør Klasser kan tilføjes til et klassediagram fra listen over klasser i produktmodellen eller oprettes fra ny. En ny klasse er oprettet. Aktør Trin 1: Initieres ved at aktøren højreklikker på et tomt sted i klassediagrammet og vælger Tilføj klasse. Trin 1: Kan også initieres ved at vælge Tilføj klasse fra en menu, når et klassediagram er aktivt. Ingen p.t. System Trin 2: En ny klasse oprettes i produktmodeldatabasen. Herefter kaldes Redigér CRC-kort. Trin 3: Når indtastningen af oplysninger er færdig gentegnes klassediagrammet, så den nye klasse vises. Ændringerne noteres i loggen. 248

D.5 Klynge: Klassediagram ID - Navn Reference Aktør(er) Beskrivelse Forudsætning Resultat Typisk scenarie Alternativt scenarie Antagelser 5.8 - Vis klasse «extends»vis CRC-kort A3 Modellør, Domæneekspert En klasse vises ved at vise det tilhørende CRC-kort. CRC-kortet for klassen vises. Aktør Trin 1: Initieres ved at aktøren dobbeltklikker på en klasse i klassediagrammet. Trin 1: Kan også initieres ved at en klasse er markeret og aktøren vælger Vis klasse. Ingen p.t. System Trin 2: Vis CRC-kort kaldes. 249

Bilag D - Brugsmønstre ID - Navn Reference Aktør(er) Beskrivelse Forudsætning Resultat Typisk scenarie 5.9 - Vis klassediagram «uses»udskriv, Udlæg klassediagram A3 Modellør, Domæneekspert Et klassediagram kan tegnes som beskrevet i standarden for UML. Klasserne og deres relationer kan placeres automatisk af systemet. Klassediagrammet er tegnet og indholdet kan redigeres ved at klikke på elementerne. Aktør Trin 1: Initieres når en aktør vælger Vis klassediagram på et vilkårligt tidspunkt. System Trin 2: Såfremt der findes mere end ét klassediagram vises en dialogboks, hvor aktøren skal vælge mellem de eksisterende klassediagrammer. Alternativt scenarie Antagelser Trin 3: Aktøren vælger et klassediagram. Trin 6: Aktøren (kun Modellør ) vælger Udlæg klassediagram fra en menu. Ingen p.t. Trin 4: Et nyt vindue åbnes, hvor klassediagrammet tegnes som det så ud da det sidst blev gemt af en bruger. Trin 5: Aktøren (kun Modellør ) kan flytte alle elementer ved blot at flytte dem med musen. Forbindelser mellem elementerne opdateres og tegnes automatisk. Alle klasser i produktmodeldatabasen der er tilknyttet klassediagrammet, inkluderes på klassediagrammet. Trin 7: Udlæg klassediagram kaldes. 250

D.5 Klynge: Klassediagram ID - Navn Reference Aktør(er) Beskrivelse Forudsætning Resultat Typisk scenarie Alternativt scenarie Antagelser 5.10 - Udlæg klassediagram A3 Modellør Frem for manuelt at placere klasser og deres relationer kan systemet analysere strukturen og placere elementerne på den mest hensigtsmæssige måde. Klassediagrammet er re-organiseret så klasserne er placeret optimalt i forhold til relationerne. Aktør Trin 1: Initieres når aktøren vælger udlæg klassediagram fra en menu, når et klassediagram er aktivt. System Trin 2: Klassediagrammet udlægges ved at klasserne placeres optimalt i forhold til hinanden og forbindelserne mellem klasserne routes på den mest optimale måde (i forhold til det bedste grafiske layout, der giver det bedste overblik). Baseres på principperne for klassediagrammet i UML. Det er muligt at definere en algoritme for optimal placering af de forskellige elementer. 251

Bilag D - Brugsmønstre ID - Navn Reference Aktør(er) Beskrivelse Forudsætning Resultat Typisk scenarie Alternativt scenarie Antagelser 5.11 - Importér struktur fra PVM A31, A32 Modellør PVM en kan virke som udgangspunkt for et klassediagram, og her beskrives hvordan strukturen fra PVM en kan overføres til et klassediagram. Klasserne fra PVM en er kopieret til nye klasser, der er inkluderet i klassediagrammet i den samme struktur som på PVM en. Aktør Trin 1: Initieres ved kald fra Opret nyt klassediagram. Trin 3: Aktøren vælger én PVM. Trin 1: Kan også initieres ved at aktøren vælger Importér struktur fra PVM i en menu, når et klassediagram er aktivt. System Trin 2: Der vises en dialogboks med en liste over de eksisterende PVM er i projektet. Trin 4: Strukturen og indholdet fra PVM en analyseres og klasserne i PVM en kopieres med deres indhold til nye klasser, hvor egenskaben klassediagram sættes til sand. Trin 5: Relationer oprettes, så partof relationer fra PVM en oversættes til stærke aggregeringer i klassediagrammet og kind-of relationer oversættes til generaliseringsrelationer. Noter og illustrationer medtages ikke. Trin 6: Ændringerne noteres i loggen. Trin 2: Indholdet i det eksisterende klassediagram slettes og der fortsættes fra trin 2 oven for. Der eksisterer en entydig specifikation for, hvordan en PVM skal overføres til et klassediagram. 252

Bilag E Klassediagram På næste side er medtaget klassediagram for dokumentationsværktøjet. På de efterfølgende sider findes en encyklopædi for klassediagrammet med forklaring af de enkelte klasser og deres attributter samt metoder. 253

š š š š š š š š š š š š ú Bilag E - Klassediagram Þ #ŒŠ ßà Œ à Œ Š Œ! Œ¼á#á Ê Œ œ 0 Š â! Œ Š Êã! $ˆ œ Š Œ àœ Š ŒŠ Š(! Œ¼ÊŒ Œ ä å æç%è æéýê»ë»éì»í(½ µ0œš À Œ $ 5Ž0Ÿ-Ã Ä À Œ $ 5 (µ0 Ã Ä Å ŒÝ! ŒŠ  ŠŒ 5ž Ÿ œ Ÿ%Œ Œ ŒŠ% Œ  Œ! ˆŒ Š $ Œ  Œ Œ œ º¼»½ ¾ %» ž Ÿ %!ˆ Œ %! Œ µ0 Œ $ ¹( Œ %œ œ Ï0³ ± Ì% ª%Œ -ž ŸÍ Ž%!Œ Œ %! Œ! š (Î ¹Œ!Š š ¹Œ!Š Î À ª5! Œ Ã Ä œ œ ±²²³ ž Ÿ 5 ˆ Ÿ5 ( Š ŒŠ Œ %ª5Œ «%Š ŒŠ ŒŠ Œ!! Œ 5 Œ 5! $Œ Ž Œ $! Õ Ò%³ 5 ˆ Ž%!Œ Š Ê Àð â Ž-Ÿ-Ã Ä šœ œ 5!ˆ ø ³Ö ± œ œ Ð Ñ Ò ³Ð Ó ³ % ˆ Å! 5 Š Å Ð ï Ñ 5 ˆ Œ ž µ-üöš 5 Œ µ5üöš á Ê Š ß Œ (  Œ Å Æ#Ç È ÀÁ  %! Ã Ä ˆ Š Œ Š% Ž( $Œ ˆ Š Œ $ 0 Ž(! Œ Ô5Õ² ³Ö (Ö¼³ Ì (³ (œ œ ±²²³ % ±Ò(Ð ±Ö - ˆ À Œ $ 5Ž0Ÿ-Ã Ä À%Û ÜÝ Ã Ä À µ5œ Š Ø Œ Š Ã Ä Ë-Ì ³ 5 ˆ! $Œì Ž( $ Œ À %Œ 0 µå Ã Ä À ( $! Š Ã Ä À µ5œ Š Ø!ŒŠ Ã Ä 5 ˆ %Œ ª5Œ 0ž ŸÉ Ÿ0 Š Ê Œ Œ ÊŒ! š ñ ò#ó ô Ñ ²! Ð ± Ì- Œ «%Š Š Œ!Œ! À (Œ Ã Ä œ œ œ œ š ÅÐ ÑÒ(³Ð ± Ð ï Ñ 5 ˆ µ5üîš ž $ 5 ¹ Œ Ù Å Ú (ØŠ! ( ØŒŠ À µå Ÿ5! Ã Ä õ( Ù-Ì%ÚÑÖ ³ Àð â Ÿ% Ê#Œ $ Ã Ä Ï0± ûûì-ð ²Ú±ï³ Ì% Þ Œ ŒŠ - Üö Œ  Œ À Ÿ% ª% Š Ã Ä %œ œ %œ œ ñ5ð Ì!ù ³ Ú! 5 ˆ ¹ Œ $Š ˆŒ Œ %Š $ Œ Œ Œ Š Ÿ5! Š ÅÐ ÑÒ³ Ð ± ± Ì5ï± ³ ± ± Figur E.1: Klassediagram for dokumentationsværktøj 254

E.1 Encyklopædi for klassediagram E.1 Encyklopædi for klassediagram Tabel E.1: Encyklopædi for klassediagram Klasse (kursiv angiver abstrakte klasser) Navn Beskrivelse Attribut Navn Type InitialVærdi Note Værdiområde Enhed Bind_OCL ChkSyntaks Bind_txt Paavirker PaavirkesAf Brugerattribut Navn Værdi Input Brugerfelt Navn AntalAttr DBlink Script Placering VisData() Diagram_element Version Tegn_KD() Tegn_PVM() ExtDokument Sti ÅbnDokument() Illustration Type Størrelse Position Sti Tegn() En attribut i en klasse. Navn på attributten. Attributtens art (boolean, integer etc.). Attributtens startværdi i konfiguratoren. Beskrivelse af attributten. Interval eller liste for lovlige værdier, attributten kan antage. Attributtens enhed (f.eks. kg, meter etc.). En produktmetode med OCL-indhold Tjekker OCL-udtrykkets syntaks (validering). En produktmetode med alm. tekstindhold. En liste af referencer til de klasser, som bindingen påvirker. En liste af referencer til klasser, som bindingen påvirkes af. En brugerdefineret attribut i et brugerdefineret felt. Navnet på attributten. Attributtens indhold. Sand, hvis attributten skal modtage input fra brugeren. Falsk, hvis attributten skal vise information. Felt på CRC-kort indeholdende et antal brugerattributter. Brugerfeltets navn (titel). Antallet af tilknyttede attributter for brugerfeltet. En slags brugerattribut, der henter indhold fra en ekstern DB. Script, der foretager udvælgelsen af data (SQL). Link-oplysninger om opkobling til den pågældende database. Viser de hentede data på baggrund af scriptet. Abstrakt overklasse for alle elementer i et diagram. Indeholder versionsnummeret for diagramelementet. Tegner elementets grafik i et klassediagram. Tegner elementets grafik i en PVM. Reference til eksternt dokument (f.eks. Word. AutoCAD etc.). Sti til dokumentets placering (absolut). Kalder det eksterne program, der skal åbne dokumentet med de korrekte parametre. Reference til billedfil, der skal vises i PVM. Illustrationens format (jpeg, gif etc.). Bredde og højde af illustrationen (i PVM en). Positionen for øverste venstre hjørne af illustrationen (i PVM en). Sti til illustrationens placering. Tegner illustrationen på PVM en. fortsættes næste side 255

Bilag E - Klassediagram Tabel E.1: (fortsat fra forrige side) Klasse (kursiv angiver abstrakte klasser) Navn Beskrivelse Klasse Navn Dato_opr Ejer MedRedaktører Stereotype Note Skitse Kontekst Status Klassediagram Navn Tegn_KD() Udlæg() Verificer() Klynge Navn Klassediagram ÅbnKD() Metode ID Navn Type Note PVMtekst Synlig Note Navn Tekst Rel_ID Projekt Navn Beskrivelse Dato_opr Projektleder Repræsenterer en klasse i modellen. Klassens navn. Dato for oprettelsen af klassen. Reference til ejeren af klassen. Liste af referencer til medredaktører af klassen. Har en værdi, hvis klassen er en stereotype. Værdien angiver typen. Beskrivelse af klassen. Reference til tilknyttede billeder som støtte for beskrivelsen. Indikation om klassen eksisterer i en PVM eller i et klassediagram. Angiver klassens status (working, released etc.). En klasse eksisterer for hvert klassediagram i modellen. Klassediagrammets navn. Tegner klassediagrammet ved at bede alle elementer om at tegne sig selv. Placerer alle elementer i klassediagrammet på den mest hensigtsmæssige måde, og udlægger alle relationer. Tjekker at syntaksen i klassediagrammet er korrekt, og at diagrammet er konsistent. En klynge i et klassediagram Navn på klyngen (vises på diagram). Reference til det klassediagram, klyngen repræsenterer. Åbner det det relaterede klassediagram. Abstrakt overklasse for alle metoder Unikt ID for metoden. Metodens navn. Metoden type. Beskrivelse af metoden. Tekst, der skal stå i PVM ved bindingen. Sand, hvis bindingen skal vises på PVM, eller falsk. En note på enten klassediagram eller PVM. Notens navn. Notens indhold. Evt. reference til diagramelement. Hvis reference eksisterer, tegnes en linie til diagramelementet. Et projekt med tilhørende produktmodel. Projektets navn. Beskrivelse af projektet. Dato for oprettelse af projektet. Reference til lederen af projektet. fortsættes næste side 256

E.1 Encyklopædi for klassediagram Tabel E.1: (fortsat fra forrige side) Klasse (kursiv angiver abstrakte klasser) Navn Beskrivelse PVM Navn Topklasse Tegn_PVM() Eksport() Verificer() Rapportskabelon Felter Tilgængelighed DanRapport() Relation Rel_ID Type Note Synlig Mult_1 Mult_2 Beskr_1 Beskr_2 Route() System_metode Tema Navn PVM tilhørende et projekt. PVM s navn. Reference til klasse, der er topklasse for diagrammet. Tegner PVM en. Eksporterer PVM en til klassediagram efter foruddefinerede regler. Tjekker at PVM en syntaksmæssigt er lovlig. Skabelon for rapporter, enten lokal eller global. En liste af felter, der udgør rapporten. Angiver om skabelonen er tilgængelig globalt, eller kun for det aktuelle projekt. Danner rapporten på baggrund af felterne ved at lave en forespørgsel i databaserne. Relation mellem klasser i klassediagram. ID på den anden klasse, der relateres til. Relationens type (aggregering, generalisering etc.). En brugerindtastet note Sand hvis relationen skal vises på diagrammet, ellers falsk. Kardinaltal for værtsklassen. Kardinaltal for den relaterede klasse. Beskrivelse for relationen ved værtsklassen. Beskrivelse for relationen ved den relaterede klasse. Finder den bedste vej mellem de to klasser. Systemmetode med tekstindhold. Samling af klasser i klassediagram i et tema. Navn på temaet (vises på diagram) 257

Bilag F Skærmbilleder fra prototype De følgende skærmbilleder er baseret på et opdigtet scenarie, som er baseret på materiale fra Andersen og Jensen [2001]. Det er vigtigt at holde for øje, at skærmbillederne er prototyper og ikke et udtryk for det endelige design. Formålet er således at give et indtryk af dokumentationsværktøjets funktionalitet og understøttelse af arbejdsgangen frem for et bud på design af brugergrænsefladen. F.1 Scenarie for prototyper af skærmbilleder Baggrund En produktmodel er under opbygning, og der eksisterer allerede en struktur af af klasser for både PVM og klassediagram. Forløb Brugeren logger ind og vælger blandt de aktive projekter at arbejde med Figur F.1, s. 261 projektet AJ-stole. Da denne bruger sidst loggede af systemet fra dette projekt Figur F.2, s. 262 var et vindue med en PVM åben, og derfor åbnes dette vindue igen. I PVM en Figur F.3, s. 263 tilføjes en ny klasse, ved at en eksisterende klasse (Armlæn) markeres, og der trykkes på Indsæt klasse efter-knappen på værktøjslinjen. Et vindue åbnes med CRC-kortet for den nye klasse, og klassen navngives Skri- Figur F.4, s. 264 veplade. Herefter tilføjes en attribut ved at højreklikke i attributfeltet og vælge Add attribute. Herved åbnes et nyt vindue, hvor alle attributtens egenskaber Figur F.5, s. 265 kan redigeres. Den nye attribut navngives Overflade og tildeles værdiområdet [Højglans,Satin]. Der afsluttes ved at trykke på OK, hvorefter vinduet lukkes. CRC-kortet lukkes ved at trykke på krydset i øverste højre hjørne af vinduet. Brugeren vælger at oprette et nyt klassediagram ved at trykke på Opret nyt klassediagram-knappen på værktøjslinjen. Herved dannes et nyt klassediagram, og et nyt vindue åbnes, hvor brugeren navngiver klassediagrammet AJ-stole. Figur F.6, s. 266 I vinduet trykkes på Importér struktur fra PVM -knappen, hvorefter vinduet lukkes, og et nyt vindue åbnes med en liste over de eksisterende PVM er i Figur F.7, s. 267 det aktive projekt. Brugeren vælger PVM en AJ-stole fra før og trykker på OK. Herved lukkes vinduet, og et nyt vindue åbnes med et nyoprettet klassediagram, der er baseret på PVM en fra før. 259

Bilag F - Skærmbilleder fra prototype Figur F.8, s. 268 Figur F.9, s. 269 Figur F.10, s. 270 Figur F.11, s. 271 Figur F.12, s. 272 Brugeren ønsker en listning af alle klasserne i klassediagrammet og trykker på Vis CRC-kort liste-knappen på værktøjslinjen. Herved åbnes et vindue, som placerer sig til venstre for vinduet med klassediagrammet og tilpasser størrelse, så de begge kan være der. Brugeren vil organisere klasserne Stoleskal og Underdel i en klynge. Han trykker på knappen Opret ny klynge på værktøjslinjen, hvorefter en dialogboks vises, hvor klyngen skal navngives. Der indtastes Stolekrop og trykkes OK. Herved lukkes dialogboksen, og den nye klynge ses på klassediagrammet i listen over CRC-kort. Herefter markeres Stoleskal og Underdel og trækkes over på symbolet for klyngen Stolekrop. Herved vises de to klasser ikke mere på klassediagrammet, og flyttes i listen over CRC-kort fra klyngen AJ-stole til Stolekrop. Ved at dobbeltklikke på klyngen Stolekrop i listen over CRC-kort åbnes klassediagrammet for klyngen nu indeholdende klasserne Stoleskal og Underdel, samt Underdel s underklasser. Herudover vises klassen AJ-stole:AJ-stole, hvortil de to klasser er relateret med en aggregeringsrelation. Brugeren er interesseret i information om klassen Stoleskal, og ved at dobbeltklikke på klassen åbnes klassens CRC-kort. I feltet Beskrivelse er et link til en internetside, og ved at trykke på linket åbnes computerens browser og viser siden. Brugeren vender tilbage til dokumentationsværktøjet og logger af ved at trykke på knappen Log af på værktøjslinjen. En dialogboks vises, hvor brugeren skal bekræfte valget. Ved tryk på OK lukkes dokumentationsværktøjet ned. 260

? F.1 Scenarie for prototyper af skærmbilleder ü ýþéþ ÿ ÿ! "$# % #'& #)('* + #, -./.#))& 1 2-3 - "$# 00000000 4%5 6 7 89: ; <=:; > Figur F.1: Før enhver brug af værktøjet skal brugeren identificere sig over for systemet ved at logge på 261

Œ Ž Bilag F - Skærmbilleder fra prototype @A BCBED F G H G I J)K L MN OP K Q RK MS J T U V+W Q N X L WN N2YZK W[U W V \ RZ] XZ^)X _ ` WU P \U T a M` Q b ML c @A BCBED F G H G Ï nzo G H G pq$r I Ds G pq t)ml M` QWcU T a M` Q u U TV/Q fmel K N Q \)U T a M` Q Jb _ ƒ)tgq TU \)ƒ_ V% )L MU _ N Q TL M XU MWQ MPEPW Q M ˆ! Š)Š ) ˆ E Š)Š ˆ + ŠŠ v%w ẍ y z{ } ~= } \U T a M` Q d e TQ fk g[n ML M` Q MP hij i%hkkh%i l mh Figur F.2: Umiddelbart efter login skal vælges, hvilket projekt der skal arbejdes med 262

¾ ¼ ½ F.1 Scenarie for prototyper af skærmbilleder E =!š Zœ) ž Z 'Ÿ ) ª «% ª ± +²Z ³ «µ ±Z ± ¹ ª º» Ê!ËZÌ Í Î Ï+Ð Ñ Ò$Î ÏÐ Ñ$ÍZÓÔ=Ð Ù Ú Û Ù á âã Û Ù á é éê Û ÕÖ= ÑØ Ñ Ð ÊÜØ ÝÞÐ ßàÖ äå Ð æ=ñ$çè2ø Ò2Î Ï+Ð Ñ Í=Ó ÔÐ ë2ï%ì í2ñ Í ÓØ å î=ñ Ð ÍÑ ï$ð ñò ó ô õ$ö øù ú ûýü þ=ÿ ò ó õø õ ÿ ó ò ò ó ù ò ò ï ø ÿù ú ûýü þ=ÿ ó õ$ø õ ÿ ï =ó õ õø ýó àÿüù ú û ü ü)õ/ò õ$ø öz õ ï 2 õ=ù ø õ õzù ú û ü üõ õ ûüø õ=ó =õ ¹ ª )À Á ª ± $ À % Â'à Ä)Å)Æ Å%ÄÇÇÄ+Å È ÉÄ Figur F.3: Ny klasse indsættes efter den markerede ved tryk på knappen i værktøjslinjen 263

Y W X Bilag F - Skærmbilleder fra prototype!" #$#&%' ( ) ( * +,(-/.0) 12243 56 + 78 9;:<=>?A@:B C :=ED 9 FG HJI B > K <IE> >ML:IN0G IH O CP KQ;KR S I0G @ ZB B G : [\EB = P =EB ]F@ O0G F T =ES B U =0< V,1 (` Ž z { Ew ; 0v0w ^ _M` A R _(2E.0* h m0i h %f stu4vw0xay;z { } {u~w~ } w0z w0v e-gf( * ` OA=B =0GUI0a> =0acb VE=EB =0G ] d!% + ('h i %* 20`kj aafaa=l n 5;(i.o s;tuc 0{y } z wc{ ~xew0z } wv!* (10i h %f '1i ( ` n i 1;iAr2 A E E ª uz Ž { ~A«(* ± ² ³ pi ie* h q r0i (2 L IH4= FEB = E ; š š œ Až š Ÿ Ÿ œ Ÿ {weµ ;z u0 wz } {wx w we} w4 E} } z { E} w vv4 ;} } z { ; E} w #&(0i % ' (* L IH4= E ; Ÿ š Ÿ œ Ÿ FEB =J KFaAB =0aAB > Q;=0<IEB :F0aMB F O0G F T =S B Z R > B F0<= ƒ0 EG : E=V<I@0= 0 ˆ 4 0 0 4 Š 0Œ Figur F.4: I CRC-kortet indtastes al information om den nye klasse 264

é ç è X F.1 Scenarie for prototyper af skærmbilleder ¹º»¼»&½¾ À Á Âà 0ÄÆÅ0À ÇÈÈ&É ÊË Â ÌÍ ÎÏÐÑ;Ò ÓAÔÏÕ Ö ÏÑ Î ØÙ Ú4Û Õ Ò Ü ÐÛEÒ ÒJÝÏÛÞ0Ù Û0Ú ß Ö à Üá0Üâ ã Û0Ù Ô êõ Õ Ù Ï ë;ìaõ Ñ àñeõ íeø;ô ß;Ù Ø ä ÑEã Õ åñ0ð æ ÃÇ.g ð î ïð ï ÈEÅ0Á ö û0 ö ½õ (*) +,- /â 0 ôägõ Á ð ßAÑEÕ Ñ0Ù å Û0ñÒ Ñ0ñcò æañeõ Ñ0Ù í ó ¹½  ¾ö ½Á È;ðùø ñaøñañú ü Ê; Å0ý ¹Á Ç ö ½õ ¾Ç0 ð ü Ç; È /HE HI/JJ / F ) G K Á LMJ N O ¹º»»&½ ¾ À Á ÂQP;¾ö Ç Á ö ÿ 0 à Ç.g ð R*EÑ;Ù S ÐÛAÔ0Ñ î ïð /Aâ 0Aâ O þ AÁ ö ÿ 0 È B Ý A ÛÚJÑ 12354 6 6 7 89: 6 ; < = ; > 8? ; = @ YZû ð î õ ö ö Ç À[Ç À ð ï½.cç ö õ ð AØEÕ ` õ ö Ñ ð \ å ] ä ÞÐÛ0ñEÒ ^ 0ÛEÕ Ï ñ_ ý ð T U V -, W5,»& ½ ¾ Á B Ý A ÛÚJÑ 1235C*; 6 D 3 = < = ; > 8? ; = @ AØEÕ ÑE ÜØ0ñEÕ Ñ0ñEÕ Ò á;ñ0ðûeõ ÏØñMÕ Ø ß0Ù Ø ä Ñã Õ ;ê â Ò Õ Ø0ÐÑ AÙ Ï EÑ0æÐÛÔ0Ñ!"!#$$! % &' Figur F.5: Information om den nye attribut redigeres i et separat vindue 265

Ô Õ ÿ Bilag F - Skærmbilleder fra prototype a*b5cdcfe g hi hjqkqb l*cnmo pk q r e5i hns t uv ÈÉ ƒ { ÊË É} Ì É {Í Èyx ˆ } 5ƒ Î É Ï x ˆ w Ì5Ð 5Ñ x Ë wx y z { } Ò {ƒ Ó Ǿ Ù Ú Û œ Ö ÜºÛ œ º Ý*œ á â ã Þfß*à * à Qœ Ü Û œ Q Ý*œ á ç èé ã Øn äåœ æ ß a b ç cfe g h i h jqk õºhöø i ùqq g ú ù û j ù ü á ç èâ ã Ü š QêQœ Ý*ຠʊ} {x5š ˆ{ yx Š{Í õqù ünh5m } yƒ { ïi º ðœ Ý à Áñ òi à ź À* ó5 #À ô ƒ ËÉ Ï x ˆ ý þ m á ç èâ ã ë š œ ì ºí î % % š!"$# % # # Q Q œ ž Ÿ * 5 «ª * n ±5 Q Q ² ³ µ n 5 ¹ª5 5 ¹ ±5 Q º» ¼Q ½µ¾ ÁÀ µ¾  ¾ ªª ½¼ ± º Ã Ä # 5à ¼ ¼ Å«Ã ¼ «5 ª ª Ƶ¾ * ¹ ª ± QÇ5 À wx y z { } ~ } yƒ { ƒ x ˆ ƒ nš Œ Œ# ŽŽ #Œ Figur F.6: Et nyt klassediagram kan oprettes ved tryk på en knap og kan efter ønske baseres på en eksisterende PVM 266

p n o j k F.1 Scenarie for prototyper af skærmbilleder &$')(*( +,)-). -)/ 01&$. 233465 278/ 219;:<8=>0 3? +8. -A@ BCD EF G H>I JKF L M1F HN E OP QR L I S1G RI I T8F RUP RQ V M1W S8XSY Z RP K VP O [ HZ L l)hg m qr s t u vw x } ~x ~x w ƒ w x > q1 6w 6} yz ƒ x ˆw { ~x Š Œ Ž s x} x u x x v~ yu vw x tz {w s x} x u y w x v~ VP O [ HZ L \>]^ Y I L OG H _OL `F aubi HG HZ L HK c>d>e dcffc d)g hi Figur F.7: Det nye klassediagram, hvor klasserne har samme struktur som i PVM en 267

Ú Ø Ù Ô Õ Bilag F - Skærmbilleder fra prototype $ ) š )œ) œ)ž Ÿ8 8ž1 8ª>Ÿ «š8 œa >± ² ³ µ ± 1± ³¹ º» ¼ ½ ¾)² ½ À 8± ½Á» ½¼  8à ¾8Ä>¾Å Æ ½» » º Ç ³Æ ¾1²½ 6² ± ± ÍÁ Ö³² ÉÊ Å º² ³ $ # Ó # % & ' (" ) *# + ) ' ÛÜ Ý Þ ß àá â æç èâé èâ á #" (& #'! ìí á îâ ï ð>é Û1é ê6á ë6ç ãä é í ñâ òá å èâ ó ô õ ö ø ù ú õ û Ý î âç â ß ýé â þ â ÿ àè ãß à>á â Þä åá ü Ý î âç â ß ãð þ á â ÿ àè » º Ç ³Æ ÈÉÊ Å º² ³ Ë)º ̱ ÍÁb ³² ³Æ ³ ÎÏÐ ÏÎÑÑÎÏÒ ÓÏ Figur F.8: I klassediagrammet kan vælges at få CRC-kortene listet og sorteret 268

u s t o p F.1 Scenarie for prototyper af skærmbilleder,-/.0.21 3 4 5 4 687,5 9 ::;=< 9 >/6 9?A@ BC#7 :D 1 5 4E F G H I J K LM N OJ P Q/J LR IS T UWVP M X K V M MZY J V [ T VU \Q/] X ^ X _ ` VT O \#T S a L ` P X K V M MWK JM P J g[ œ žÿ q L K r c d _ M P SK L ž œ ª ³ œ µ ž ž œ ª «ª # œ (³ ¹ ª Ÿ º ¹ ª Ÿ ~z { } { vw x y z {# } ƒ} ƒ} ž œ ª #³ Ÿ ª (± ª œ ª ± ² ª #ˆ }Š # v 8 = ~ ˆ Œ} ƒ} Ž x } } z } } š {ƒ ~#z {# } y x } } z ~# } š {ƒ \#T S a L ` P b c d _ M P SK L e SP fj g[hm LK L ` P L O i j#k ji#ll ij m nl Figur F.9: Den nye klynge oprettes med et mappe-ikon i listen til venstre og med UML-symbolet i klassediagrammet 269

û ù ú õ ö Bilag F - Skærmbilleder fra prototype»(¼ ½¾½2 À Á  Á Ã8Ä/»Â Å Æ Æ2ÇÉÈ Å Ê/à ŠËAÌÍ/Î#Ä ÆÏ / Á Ð Ñ Ò Ó Ô#Õ Ö Ø ÙÚ Õ Û Ü Õ Ý Ô Þ ß àzá Û Ø â Ö áø ØWã/Õ á äß á à å Ü/æ â/ç#â è é áß Ú åß Þ ê é Û â Öá Ø Ø=Ö Õ Ø Û Õ! ä " #$ %'& (*)+, -/., 0 ì í è Ø Û Þ Ö 7Û Þ Ö îß Þø ì í è Ø Û Þ Ö ì ß à2ö12! 3 Õ Ö 4 /5 6ß > è 4! Û? è 4! Û ã ß ê *; ÞÚ 7Û Þ Ö Øî á Ö 7 6 ê Ö *; Þ#Ú <=!Ú ß Ú Ö 7îß Õ8 ø Ö á Ú 9:8 ß ; Ö á#ú * * Ö ø ü ü ý þ ÿ åß Þ ê é Û ë ì í è Ø Û ÞÖ åá éî á ä è/ì í è Ø Û Þ Ö ïð ñ ðïò òïð ó ôô Figur F.10: Klassediagrammet er opdateret efter flytning af de to klasser (med underklasser) 270

F.1 Scenarie for prototyper af skærmbilleder @BA=CDCFEG=H=I H=JLK @BI M'N NPÖ Q M'R:J M S2TUV E:I H W'J E=X2Y W'Z=K M'[ \ ]^_` ab]c d ]_ e \ fg hpi c ` j ^i*` `lk:]i m/g i/h n d o j:p/j'q r i/g b n/g f s _ r c j=^i ` ` ^ ]` c ] *m ˆ: Š 'Œ Ž* * / u'v q ` c f^_ x*c f^_/wg f/y q š _ *_*c q š _ *_*c k:g _ s _* f/b * * ª* x*c f'^_`*w i ^ x s ^_* f/b = b/_/g b/_/^ u'v q ` c f^_ u g h ^ 2 x/wg ] *_/y ^i b _ ž: _/g ^i b _ ] ^ š_'œ* /g ƒ=_/^ y Ÿ' * Ÿ * «' * * ±' ² ³ µ * / ² ³ * n/g f s _ r c tu'v q ` c f/^_ ni r*w i m _PqBx*c f^_wg f/y z{ {Pz/} }/zl{=~ / Figur F.11: En klynge har et separat klassediagram, hvor den detaljeres. Elementer fra andre klynger vises med grå farve 271

ê è é Bilag F - Skærmbilleder fra prototype B =¹º¹F»'¼=½=¾ ½= LÀ: ÂÁ BÀ Ã Ä ¼ÂÅ/ÆÇ»=¾ ½'È'ÉÄ=¾Ê É'Ë=À Ä=À Ì'Í ÎÏÐÑ Ò ÓÔ'ÏÕ Ö ÏÑ* Î ØÙ ÚlÛ Õ Ò Ü=ÐÛ*Ò ÒÞÝ:ÏÛ ß/Ù Û'Ú à Ö:á Ü:âÜ'ã ä Û/Ù Ô ëõ Õ Ù Ï ì í*õ Ñ álñ*õ î Ø Ô à/ù Ø å Ñ*ä Õ æ=ñ/ð ç Ü ÐÛ Ò Ò Ð ÏÒ Õ Ï ñ ß ë'ü ã Ò Õ ØÐÑ ý*õ ØÐÑ/þ*Ù Ø/ç ã ì*ññ Ñ*Õ ã ì*ññ Ñ*Õ Ý Ù Ñ å Ñw Ø/Ô ý*õ ØÐÑ*Òþ Û Ð ý v å ÐÑw ØÔ x=ñ*ô/ñ/ù Ô/Ñ/Ð ë'ü ã Ò Õ ØÐÑ ë Ù ÚFÐu2ñ ý/þ*ù Ïz*Ñ'ç Ð Û Ô Ñ {Bz*Ñ/Ù w ÐÛÔ Ñ y=ï Ð ìñ/î v/ù 9o p 9q r s q t LÄ2½ Å ï*ð Å þ ã Û ã ðâ½'è à 4/Ç»=ö :Ç Ç /Ç Ç ½È. Ý -Û/ÚÞÑ 56 798 : ; < =98 8 :9>?: @BA CD E9@ 69F C= GIHJ9E K : 69< @ LC ; D F > M @ NO@ D 7 @ ; < :98 8 F P :QD 7 @BRS: @GT7 C :98 = DUWV X ;6 798 :TY Z [ : @ :9>\ ]BA> P :>37 P ^?L@ :9>_ N59:IG?:9@ :Q7 Ga` @ F 6 btcd= > ; :9> ; G E J98 : @H e f!fgf?n D @ F 6 b R=9> ; :9> N C< N hij;3gq: @ :Q7GkH @ 7 C9A < 6 GT7 C : 8 8 : @ F > PTH e flfwf?n H @ 7C9A < 6 GI7C :98 8 :@ N C< N c!:98:t;: @ F : >3=9D UWV X ;6 7 8 :QJ 8 : SQGT7 C : 8 8 : @ : 6 ; 7 G : < ;= GT:9> ; H @ 7K :9< 6S: C m n!h N5:T@ = H H 7 @ 6 :9>IR: @BY n!^gx ;L S : @ :9> N HC D _ N! " " # $ % & " ' () ' * $ + ' ), ô õ2ö'½= Å àñ Õ Ñ/Ù:æÛ/ñ Ò Ñ/ñ ò ç*ñ*õ Ñ/Ù î ó :»=À ½¼: Ç»: È/Åùø ñøññ'ú -Ø*Õ Ñ Æ:ɽ'Ç Ã / B ½Ä Ç*» ö ¼=Ä'Ç ½ ÆÇ ÄÇ 'È 2 }~9o s q t B½ ƒ 9 ¹l½'Ç /'»'¼=È. Ý -Û/ÚÞÑ!0' " 1 ) () ' * $ + ' ), -Ø*Õ Ñ32LÜ'Ø/ñ*Õ Ñ/ñ*Õ Ò â'ñ/ðû*õ ÏØ/ñlÕ Ø à/ù Ø å Ñ ä Õ û ëü ã Ò Õ Ø/ÐÑ ý*õ Ø/ÐÑÒ*þ Û'Ð ÿ Pÿ /ÿ Figur F.12: I alle tekstfelter kan laves links til internetressourcer og eksterne dokumenter. Ved at klikke på disse links åbnes hjemmesiden eller dokumentet i en passende applikation (uden for dokumentationsværktøjet) 272