kravspeci˝kation for dokumentationsværktłj til...

Kravspecifikationfor dokumentationsværktøj

til produktmodellering

Polyteknisk eksamensprojekt, 2002

Hovedrapport

Vejledere: Lars Hvam & Jesper Riis Simon Pape, C958196

Institut for Produktion og Ledelse Publikationsnummer

Danmarks Tekniske Universitet IPL-128-02

Kravspecifikation

for dokumentationsværktøj


Polyteknisk eksamensprojektCopyright c© Simon Pape

Printet med LATEX2ε

Forord

Denne rapport er resultatet af et halvårigt eksamensprojekt, udført ved Institutfor Produktion og Ledelse (IPL) på Danmarks Tekniske Universitet (DTU) iperioden 1/3 - 15/10 2002. Projektet udgør afslutningen på civilingeniørstudietog er udført under vejledning af lektor Lars Hvam og ph.d.-studerende JesperRiis.

Projektets formål er at få afdækket og specificeret kravene for et dokumenta-tionsværktøj til produktmodellering og bunder i en frustration over arbejdsbyr-den forbundet med manuel opbygning og vedligeholdelse af dokumentationen iforbindelse 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 allehar bidraget konstruktivt med holdninger til projektet. Resultatet er ud over enkravspecifikation for et dokumentationsværktøj et oplæg til, hvordan dokumen-tationsvæ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 Hvamog Jesper Riis, for deres vejledning og inspiration. Især en stor tak til JesperRiis for hans store engagement og mange konstruktive forslag samt tålmodigegennemlæsning af rapporten.

En stor tak skal også lyde til medarbejderne i de fire virksomheder for deresinteresse og engagement i projektet. Især vil jeg rette en tak til Mikkel Dalgasfra APC Denmark A/S, Søren Poulsen fra F.L. Smidth A/S og Aage Windfra Vitral A/S. Herudover også en stor tak til ph.d.-studerende Martin Malis ogBenjamin Loer Hansen for deres interesse og konstruktive indspark til projektet.

Slutteligt skal lyde en stor tak til Sara Aabolt Christensen for utrættelig korrek-turlæsning, og til Henrik Jørgensen, Martin Harss, Jørgen Lindegaard Pedersenog Kasper Edwards for deres store bidrag til det sociale liv på instituttet – isærgennem de altid livlige frokostdebatter og kaffepauser.

Lyngby, 15. oktober 2002

Simon PapeC958196 i

Resumé

Erfaringer fra arbejdet med produktmodeller har vist, at der eksisterer et behovfor et IT-baseret dokumentationsværktøj, som kan understøtte arbejdet. Dettekan 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 do-kumentationsværktøj til produktmodellering. Kravene er blevet afdækket vedat undersøge produktmodelleringsprocessen hos fire virksomheder, der benyttersig af produktmodellering (GEA Niro A/S, APC Denmark A/S, F.L. Smidthog Vitral A/S).

Forud for det empiriske arbejde er lavet et litteraturstudie for at afdække fireoverordnede områder:

- Udvikling af informationssystemerIntroduktion til livscyklusmodeller og udviklingsprojekters faser.

- Det objektorienterede paradigmeTankegangen bruges inden for produktmodellering og systemudvikling.

- ProduktmodelleringOpbygning af forståelsesramme som baggrund for projektets domæne.

- IT-understøttet dokumentationAfdæ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 for-bindelse laves også et estimat af omkostningerne forbundet med egenudviklingsåvel som køb af standardsystemer. Under vurderingen af standardsystemerneundersøges også, hvordan disse kan integreres med virksomhedens øvrige infor-mationssystemer.

Rapporten konkluderer, at et værktøj baseret på Lotus Notes vil være en hen-sigtsmæssig løsning. Løsningen vil kunne imødekomme de opstillede krav, ogsamtidig være billig og fleksibel. Herudover lægges op til, at den videre udviklingaf dokumentationsværktøjet sker i samarbejde mellem Center for Produktmo-dellering (CPM), et antal interesserede virksomheder og evt. et softwareudvik-lingsfirma.

iii

Executive Summary

Experience from the field of product modelling has revealed that a need exists foran IT-based documentation tool to support the product modelling process. Timecan be saved by letting a documentation tool handle trivial time consumingtasks, as these tasks are often better handled by a computer.

The main objective of this thesis is to reveal and document the requirementsfor a documentation tool for product modelling. The requirements have beengathered and structured based on an analysis of the existing product model-ling 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 tocover four main fields:

- Development of information systemsIntroduction to life cycle models and the phases of system development.

- The object oriented paradigmThe domain is applicable to product modelling and system development.

- Product modellingA frame of comprehension for the domain of the project.

- IT-based documentationAnalysis of the functionality in CASE-tools and PDM-systems.

Based on the requirement specification it has been analyzed if a standard systemwill be able to meet the requirements, or development from scratch is necessary.Estimates have been made to clarify the costs associated with both own systemdevelopment and acquisition of standard systems. Included in the assessmentof the standard systems is also an analysis of how they can be integrated withother information systems.

The conclusion of the thesis is that a tool based on Lotus Notes will be anappropriate solution meeting the requirement specification and at the same timebeing a surprisingly affordable and scalable solution. In addition to this, it issuggested that the further development is carried out in co-operation betweenCentre for Product Modelling (CPM), a number of interested companies andperhaps a software development company.

v

Indhold

1 Introduktion 1

1.1 Formål og baggrund . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Problemformulering . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Afgrænsning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4 Metode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.5 Opbygning af rapporten . . . . . . . . . . . . . . . . . . . . . . . 71.6 Læsevejledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

I Teoretisk grundlag 9

2 Udvikling af informationssystemer 11

2.1 Systemudvikling som projekt . . . . . . . . . . . . . . . . . . . . 122.2 Projektlivscyklus . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.3 Mislykkede projekter . . . . . . . . . . . . . . . . . . . . . . . . . 16

3 Det objektorienterede paradigme 19

3.1 Objektorienterede fremgangsmåder . . . . . . . . . . . . . . . . . 203.2 Centrale elementer . . . . . . . . . . . . . . . . . . . . . . . . . . 213.3 Objektorienteret analyse - OOA . . . . . . . . . . . . . . . . . . . 233.4 Objektorienteret design - OOD . . . . . . . . . . . . . . . . . . . 273.5 Objektorienteret implementering - OOI . . . . . . . . . . . . . . 30

4 Produktmodellering 33

4.1 Introduktion til produktmodellering . . . . . . . . . . . . . . . . 344.2 Fremgangsmåde for opbygning af produktmodeller . . . . . . . . 384.3 Dokumentation af produktmodeller . . . . . . . . . . . . . . . . . 40

5 IT-understøttet dokumentation 47

5.1 CASE-værktøjer . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.2 PDM-systemer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

vii

Indhold

II Empiri 67

6 Dokumentationsproces og kravanalyse 69

6.1 Analyse af eksisterende processer . . . . . . . . . . . . . . . . . . 706.2 Den fremtidige proces . . . . . . . . . . . . . . . . . . . . . . . . 84

7 Kravspecifikation 93

7.1 Overordnet systembeskrivelse . . . . . . . . . . . . . . . . . . . . 947.2 Projektarbejde og produktmodeller . . . . . . . . . . . . . . . . . 997.3 Brugsmønstre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1017.4 Specifikation af diagrammer . . . . . . . . . . . . . . . . . . . . . 1057.5 Systemstruktur og diagrammer . . . . . . . . . . . . . . . . . . . 1107.6 Overgang fra dokumentation til konfigurator . . . . . . . . . . . 1147.7 Summering og prioritering af krav . . . . . . . . . . . . . . . . . 119

8 Den videre udvikling 123

8.1 De kommende faser . . . . . . . . . . . . . . . . . . . . . . . . . . 1248.2 Egenudvikling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1258.3 Tilpasning af eksisterende systemer . . . . . . . . . . . . . . . . . 1288.4 Projektorganisation . . . . . . . . . . . . . . . . . . . . . . . . . . 1368.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 . . . . . . . . . . . . . . . . . . . . 51.2 Opbygning af rapporten . . . . . . . . . . . . . . . . . . . . . . . 6

2.1 Besparelse ved anvendelse af struktureret fremgangsmåde . . . . 132.2 Traditionel vandfaldsmodel . . . . . . . . . . . . . . . . . . . . . 142.3 Boehms spiralmodel . . . . . . . . . . . . . . . . . . . . . . . . . 152.4 Objektorienteret livscyklusmodel . . . . . . . . . . . . . . . . . . 152.5 Fremgangsmåden ved objektorienteret systemudvikling . . . . . . 16

3.1 Eksempel på objekter og klasser . . . . . . . . . . . . . . . . . . 213.2 Klassehierarki og beskyttelse ved nedarvning . . . . . . . . . . . 223.3 Eksempel på brugsmønsterdiagram . . . . . . . . . . . . . . . . . 243.4 Eksempel på klassediagram i UML-notation . . . . . . . . . . . . 263.5 Eksempel på sekvensdiagram i UML-notation . . . . . . . . . . . 293.6 Eksempel på samarbejdsdiagram . . . . . . . . . . . . . . . . . . 293.7 Eksempler på diagrammer i OOD . . . . . . . . . . . . . . . . . . 313.8 Eksempel på komponentdiagram . . . . . . . . . . . . . . . . . . 31

4.1 Anvendelse af produktmodeller i specifikationssystemet . . . . . . 354.2 Sammenhæng mellem produktkonfigurator og produktmodel . . . 364.3 Eksempel på konfigurator fra APC . . . . . . . . . . . . . . . . . 364.4 Rammemodel for produktmodeller . . . . . . . . . . . . . . . . . 374.5 Eksempel på Produkt-Variant Master . . . . . . . . . . . . . . . 404.6 Eksempel på klassediagram . . . . . . . . . . . . . . . . . . . . . 434.7 Eksempel på CRC-kort . . . . . . . . . . . . . . . . . . . . . . . . 45

5.1 OO projektlivscyklus, Upper- og Lower CASE . . . . . . . . . . . 505.2 Gantt-kort, vertikale og horisontale CASE . . . . . . . . . . . . . 515.3 Anvendelse af modeller som fælles sprog . . . . . . . . . . . . . . 545.4 Funktionel struktur af PDM-system . . . . . . . . . . . . . . . . 605.5 Funktionalitet i PDM-systemer . . . . . . . . . . . . . . . . . . . 615.6 Intern integration ved anv. af PDM-systemer . . . . . . . . . . . 64

ix

Figurer

6.1 Struktur, procesanalyse og kravspecifikation . . . . . . . . . . . . 706.2 Eksempel på CRC-kort og træstruktur i Lotus Notes hos Niro . . 726.4 Dokumentationsværktøj og projektlivscyklus . . . . . . . . . . . 856.5 Fremgangsmåde ved objektorienteret konfigurator . . . . . . . . . 876.6 Princip ved overførsel af PVM til klassediagram . . . . . . . . . . 876.7 Fremgangsmåde ved konventionel konfigurator . . . . . . . . . . . 896.8 Anvendelse af klassediagram i konventionel konfigurator . . . . . 90

7.1 Begrebsmæssig model for dokumentationsværktøj . . . . . . . . . 957.2 Adgang til information i produktmodel . . . . . . . . . . . . . . . 1007.3 Brugermønsterdiagram for dokumentationsværktøj . . . . . . . . 1017.4 Produkt-Variant Master (PVM) med alle elementer . . . . . . . . 1067.5 Klassediagram med alle elementer . . . . . . . . . . . . . . . . . 1077.6 CRC-kort med alle felter . . . . . . . . . . . . . . . . . . . . . . . 1087.7 Anvendelse af SKU-numre på CRC-kort hos APC . . . . . . . . . 1107.8 Eksempel på brugerdefineret felt i CRC-kort . . . . . . . . . . . . 1117.9 Klassediagram for dokumentationsværktøj . . . . . . . . . . . . . 1117.10 Udveksling af data med dokumentationsværktøj . . . . . . . . . . 1147.11 Lagring og udveksling af information i Oracle Configurator . . . 1167.12 Lagring og udveksling af information i Baan 98 og iBaan . . . . . 1177.13 Dataudveksling med dokumentationsværktøj . . . . . . . . . . . 1197.14 Begrebsmæssig systemmodel med grundmodul . . . . . . . . . . 120

8.1 De kommende faser i udviklingen . . . . . . . . . . . . . . . . . . 1258.2 Forskellige omkostningsmodeller med forskellige grundformler . . 1278.3 Udvidelse og tilpasning af Rational Rose . . . . . . . . . . . . . . 1308.4 Udvidelse og tilpasning af MS Visio . . . . . . . . . . . . . . . . 1318.5 Alle elementer i Visio defineres i et ShapeSheet . . . . . . . . . . 1328.6 Eksempel på add-on i Visio . . . . . . . . . . . . . . . . . . . . . 132

C.1 Eksempel på CRC-kort og træstruktur i Lotus Notes hos Niro . . 176C.2 Skærmbillede fra FLS’s konfigurator . . . . . . . . . . . . . . . . 190

D.1 Brugsmønsterdiagram, topniveau . . . . . . . . . . . . . . . . . . 199D.2 Brugsmønsterdiagram, klynge: Administration . . . . . . . . . . . 205D.3 Brugsmønsterdiagram, klynge: PVM . . . . . . . . . . . . . . . . 213D.4 Brugsmønsterdiagram, klynge: CRC-kort . . . . . . . . . . . . . . 223D.5 Brugsmønsterdiagram, klynge: Klassediagram . . . . . . . . . . . 241

E.1 Klassediagram for dokumentationsværktøj . . . . . . . . . . . . . 254

x

Figurer

F.1 Prototype - Log på . . . . . . . . . . . . . . . . . . . . . . . . . . 261F.2 Prototype - Vælg projekt . . . . . . . . . . . . . . . . . . . . . . 262F.3 Prototype - Indsæt ny klasse . . . . . . . . . . . . . . . . . . . . 263F.4 Prototype - CRC-kort for klasse . . . . . . . . . . . . . . . . . . . 264F.5 Prototype - Redigér attribut . . . . . . . . . . . . . . . . . . . . . 265F.6 Prototype - Klassediagram efter PVM . . . . . . . . . . . . . . . 266F.7 Prototype - Nyt klassediagram . . . . . . . . . . . . . . . . . . . 267F.8 Prototype - Liste for CRC-kort . . . . . . . . . . . . . . . . . . . 268F.9 Prototype - Ny klynge . . . . . . . . . . . . . . . . . . . . . . . . 269F.10 Prototype - Klassediagram med klynge . . . . . . . . . . . . . . . 270F.11 Prototype - Klassediagram for klynge . . . . . . . . . . . . . . . . 271F.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 . . . . . . . . . . . . . . . . . . . . . . . 394.2 Anvendelse af UML i klassediagrammer ved produktmodellering 44

6.1 Niros erfaringer med og ønsker til dokumentationsværktøj . . . . 726.3 FLS’s erfaringer med og ønsker til dokumentationsværktøj . . . . 77

7.1 Antagelser i brugsmønstre . . . . . . . . . . . . . . . . . . . . . . 1047.2 Sammenhæng mellem elementer i PVM og klassediagram . . . . 1127.3 Sammenhæng mellem elementer i CRC-kort og database . . . . . 113

8.1 Udgifter ved anskaffelse af standardsystemer . . . . . . . . . . . . 1348.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 konfigurerings-systemer (produktkonfiguratorer) til at støtte aktiviteterne i specifikationspro-cessen. Specifikationsprocessen dækker over de aktiviteter, der ligger mellemkunden og produktionen, og med et stigende krav fra kunderne om individu-elt tilpassede produkter til lave priser bliver arbejdet i specifikationsprocessenhurtigt omfattende.

Derfor har virksomheder som f.eks. Dell Computer opbygget produktkonfigu-ratorer, hvor kunderne selv kan konfigurere deres produkt (f.eks. en kompletcomputer med skærm og printer), hvorefter produktkonfiguratoren kan sendeordren til produktion eller levering – helt eller delvist uden menneskelig ind-blanding. Besparelserne og fordelene er åbenlyse.

Desværre går ikke alle af disse projektet godt. I nogle tilfælde lykkes det aldrig Nogle projektermislykkesat 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 vedligeholdeog 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årligtopbygget produktmodel:

- Produkterne er ikke umiddelbart konfigurérbare, og der er ikke klarhedover, hvilke varianter man ønsker at tilbyde sine kunder.

- Den opbyggede produktmodel er ikke struktureret og dokumenteret, hvil-ket gør det vanskeligt – eller helt umuligt – at vedligeholde og videreudviklemodellen.

Begge problemer kan undgås ved, at der følges en struktureret fremgangsmådefor opbygningen af produktmodellen, og ved at dokumentere produktmodel-len sikres, at det er muligt at vedligeholde og udbygge produktkonfiguratoreni fremtiden. Ved Center for Produktmodellering (CPM) på Danmarks TekniskeUniversitet (DTU) er udviklet en struktureret fremgangsmåde, som foreskrivergennemløbet af en sekvens af aktiviteter (se afsnit 4.2 på side 38), og som samti-dig lægger op til en simpel, men dækkende dokumentation af produktmodellen.

Dokumentationsarbejdet i forbindelse med udarbejdelse af en produktmodel erManglendeintegration dog ofte præget af en stor mangel på integration. Dette medfører, at det admini-

strative arbejde med dokumentationen hurtigt kommer til at udgøre en for storandel af den samlede indsats i produktmodelleringsprocessen. Meget af arbejdetbruges på at sikre integriteten af modellen, ligesom der skal bruges ressourcer påkonstant at sikre, at indholdet af dokumentationen er opdateret. Der er såledeset stort ønske om at finde løsning, som letter dokumentationsarbejdet, uden atder gås på kompromis med dokumentationens kvalitet.

Inden for udvikling af informationssystemer anvender man i udpræget grad sy-Gode erfaringermedCASE-værktøjer

stemmodeller i udviklingsprocessen, og erfaringen har vist, at arbejdet med do-kumentationen (diagrammer, leksika etc.) lettes med anvendelse af IT-baserededokumentationsværktøjer (CASE-værktøjer). Og netop fremgangsmåden for op-bygning af produktmodeller, der anvendes ved CPM, er kraftigt inspireret afprincipperne bag objektorienteret (IT-)systemudvikling, og det vil derfor væreoplagt at trække på de samme gode erfaringer mht. at automatisere og støttedokumentationsarbejdet.

Med baggrund i de gode resultater fra anvendelse af CASE-værktøjer i IT-verdenen og CPM’s erfaringer med produktmodellering er det oplagt, at brugenaf et IT-baseret dokumentationsværktøj med al sandsynlighed kan komme deovenfor nævnte forhindringer til livs og dermed gøre dokumentationsarbejdetnemmere. Ved at samle og integrere dokumentationen i et IT-baseret dokumen-tationsværktøj gives samtidig mulighed for en nemmere adgang til indholdeti dokumentationen. Det bliver f.eks. muligt at søge efter bestemt informationsamt generere og udskrive rapporter med den ønskede information. Samlet setvil det i sidste ende betyde, at medarbejderne får mere tid til deres egentlige ar-bejde – at opbygge produktmodellen – i stedet for at skulle bruge deres kræfterpå 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 eksistererikkeløsninger i standardiserede dokumenthåndteringssystemer, men disse løsninger

løser ikke alle problemerne. Dokumentationsarbejdet bliver derfor omstændeligtog udgør en flaskehals i produktmodelleringsprocessen.

1.2 Problemformulering

Med afsæt i ovenstående introduktion til domænet begynder grundlaget for enproblemformulering at tage form. Udgangspunktet er en utilfredshed med dennuværende dokumentationsproces, og det grundlæggende spørgsmål er, hvilkekrav der stilles til et IT-baseret dokumentationsværktøj.

Forud for dette eksamensprojekt har man ved CPM gjort sig klart, at der ek-sisterer et svagt punkt i produktmodelleringsprocessen, og man har yderligerefået afdækket, at det svage punkt består i, at det er meget omstændeligt atopbygge og vedligeholde de omfattende mængder af dokumentation, der genere-res i løbet af et produktmodelleringsprojekt. Grundlaget er således skabt til atstarte 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 virksom-

hedens øvrige informationssystemer?

3. Hvordan bør projektet vedr. udvikling af dokumentationsværktøjet fortsæt-

tes (herunder også overordnede økonomiske betragtninger)?

Ad 1: For at kunne afdække kravene til et kommende dokumentationsværktøj Proces ogdokumentationer det nødvendigt at opbygge et grundigt kendskab til den nuværende produkt-

modelleringsproces. I den sammenhæng vil det være hensigtsmæssigt – ud overat se på fremgangsmåden fra CPM – at undersøge hvordan processen forløberi erhvervslivet. Ved hjælp af principperne bag objektorienteret analyse vil jegklarlæ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 sparesved 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. Hermedtænkes på, hvordan dokumentationsværktøjet kan trække på information fraf.eks. virksomhedens ERP-system, og hvordan en integration mellem dokumen-tationsvæ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


den løbende vedligeholdelse. Begge områder vil blive undersøgt med fokus påmuligheden for dataudveksling med dokumentationsværktøjet.

Ad 3: Dette eksamensprojekt vil udgøre starten på det fulde projekt for ud-Den videreudvikling vikling af et dokumentationsværktøj til produktmodellering. Hovedopgaven er

at afdække og dokumentere kravene til informationssystemet med anvendelse afteknikkerne bag objektorienteret analyse. For at lægge op til det videre arbejdevil det være givtigt at komme med overvejelser om, hvordan den videre udviklingbør forløbe, og hvordan centrale aspekter af systemet kan implementeres. Hen-sigten 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ækkerogså over f.eks. softwarefirmaer, der som udviklingspartner kunne bidrage til enstabil 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 doku-mentationsværktøj. Dette betyder, at en del interessante områder kun berøresoverfladisk eller helt udelades.

Der tages udgangspunkt i Hvam og Mortensens fremgangsmåde for opbygningaf produktmodeller. Fremgangsmåden er resultat af mange års forskning oger afprøvet på adskillige projekter i samarbejde med danske og udenlandskevirksomheder. Det antages derfor, at denne fremgangsmåde er hensigtsmæssigtil formålet.

Formålet med dokumentationsværktøjet er at understøtte selve modelleringspro-cessen fra opbygning af Produkt-Variant Master (PVM) over implementering tilvedligeholdelse 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 tagetstilling til implementeringsmæssige detaljer. Af hensyn til den praktiske anven-delse vil der dog i visse tilfælde blive lavet vurderinger og forslag til, hvorledesenkeltstå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éeropstået i løbet af projektet er blevet indfanget og dokumenteret. Således vil derf.eks. ikke blive lavet en analyse af mulighederne for anvendelse af Standard forthe 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. Dettearbejde svarer til indholdet af analysefasen i den objektorienterede projektlivs-cyklus, som er beskrevet i kapitel 3 på side 19 og illustreret i figur 2.5 på side16.

Ydermere er det sigtet blot overfladisk at undersøge mulighederne for en inte-gration af værktøjet med forskellige standardsystemer for at belyse muligheden.Således vil ERP- og CAx-systemer ikke blive behandlet, ligesom simuleringssy-stemer ikke vil blive inddraget.

Anvendelsen af et standardsystem som basis for implementeringen vil blive ba-seret på CPM’s og de tilknyttede virksomheders erfaringer, og der vil såledesikke blive foretaget en tilbundsgående analyse af de enkelte standardsystemersmuligheder og begrænsninger.

1.4 Metode

En stor opgave vil bestå i at opbygge et kendskab til produktmodellering. Kend-skabet og forståelsen skal være på et niveau, der giver indblik i de grundlæggendeprincipper for produktmodellering. Herudover vil det være nødvendigt med enindsigt i de involverede processer og behovet for dokumentation for at kunnelave en analyse af kravene til et kommende dokumentationsværktøj. Indsigteni produktmodellering vil både være baseret på litteraturstudier og praktiskeerfaringer fra de tilknyttede virksomheder.

Ved opbygningen af kravspecifikationen vil der blive taget udgangspunkt i struk-turen og funktionaliteten fra eksisterende informationssystemer til håndtering afdokumentation 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 /21�3 4 5 /�6 0 7 .�/"8:9 4�3�.�/ 0 0 /:1�3 4 5 /�6 0

# � � ��

Figur 1.1: Fremgangsmåde for projektet

5


1.4.1 Empirisk grundlag

Den empiriske del vil tage udgangspunkt i interview og løbende samtaler mednøglepersoner i virksomhederne APC Denmark A/S, F.L. Smidth A/S, GEA Niro A/Sog Vitral A/S. Herudover vil der blive trukket på CPM’s erfaringer fra tidligereprojekter, 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øbendeog videreudvikles.

- Udvikling af specifikationssystemer

af Benjamin Loer Hansen i samarbejde med APC Denmark A/SUdvikling af fremgangsmåder for udvikling af specifikationssystemer samtopstilling af strukturelle beskrivelseskarakteristika for produktmodeller.

- Application of Product Models in Extended Enterprises

af Martin Malis i samarbejde med GEA Niro A/SVurdering af strategiske aspekter i forbindelse med udvikling af produkt-modeller samt undersøgelse af mulighederne for integration af konfigura-torer 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ærtstøtte mig op ad CPM’s arbejde inden for området.

; < =�> ? = ?�< = ?@ A B < C D E ? F G ? D C B HI G J < =�> @ I

K�LNM�C G C B H ?G ? B J > D @ D ? G O 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 eropdelt 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 deneksisterende dokumentationsproces. På baggrund af denne opbygges en kravspe-cifikation i kapitel 7, og i kapitel 8 diskuteres, hvordan den videre udvikling kanforløbe, samt hvilke muligheder der eksisterer for implementering. Rapportenafsluttes 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 placereten liste med forklaring af anvendte forkortelser og en ordforklaring for centralebegreber 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å erved 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 atlæse introduktionen.

Den primære målgruppe er vejledere og censor og sekundært medarbejdere hosde involverede virksomheder. Da projektet lægger op til det videre arbejde meddokumentationsværktøjet, er rapporten også møntet på studerende og udviklere,der skal arbejde videre med projektet. Sidstnævnte gruppe bør som minimumlæse kapitel 4 som en indføring til produktmodelleringsdomænet og evt. suppleremed relevante kilder fra litteraturlisten. Herudover vil referaterne i bilag C væreen god kilde til erfaringerne fra de involverede virksomheder.

Læsere, der kun har erfaring med produktmodellering, bør før læsningen af denempiriske del som minimum læse kapitel 2 om udvikling af informationssystemerog evt. kapitel 3 om det objektorienterede paradigme.

7

Del I

Teoretisk grundlag

Kapitel 2

Udvikling af

informationssystemer


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. Fo-kus vil være på anvendelsen af en struktureret fremgangsmåde, hvor udviklingendeles op i et antal faser, der tilsammen udgør hele projektlivscyklussen. Herud-over 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 paral-lelt med den generelle udvikling inden for informationsteknologi. Siden 1950’ernehar udviklingen inden for informationsteknologi gennemgået fire æraer, somstrækker sig fra den spæde start uden standarder over anvendelsen af databa-ser og sammenkobling af computere i netværk til avancerede informationssy-stemer som Enterprise Resource Planning (ERP)- og Product Data Manage-ment (PDM)-systemer [Riis, 2002].

Kompleksiteten af et informationssystem fremgår af følgende definition:

An information system (IS) is an arrangement of people, data, pro-

cesses 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 atproduktivitet og kvalitet øges, efterhånden som en virksomheds1 udviklings-processer modnes [Whitten et al., 2001]. Dvs. des bedre udviklingsprocessenhåndteres som et projekt, og der følges en velstruktureret fremgangsmåde, desbedre bliver det endelige resultat – både kvalitets- og omkostningsmæssigt.

Denne sammenhæng har The Software Engineering Institute på Carnegie MellonCapabilityMaturity Model(CMM)

University beskrevet i the Capability Maturity Model (CMM) [Whitten et al.,2001]. Modellen bruges til at måle modenhedsniveauet (maturity level) for envirksomheds evner inden for udvikling af informationssystemer og evne til atstyre udviklingsprocessen. Modellen har fem niveauer, hvor hvert niveau er for-udsætning for det næste:

1. Initial – Der følges ingen beskrevet fremgangsmåde, og indsatsen er ikkekoordineret. Processen er uforudsigelig, og dokumentationen sporadisk.

2. Repeatable – Man er blevet opmærksom på projektledelse, som nu harfokus frem for systemudvikling. Fremgangsmåder anvendes, men variererfra 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 tilpassetversion af denne metodologi. Som resultat er projektets dokumentation ogresultater konsistente og forudsigelige.

4. Managed – Målbare mål for kvalitet og produktivitet er defineret. Ledelsenforsøger at agere frem for at reagere i forbindelse med problemer (omkost-ninger, 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, derudvikler 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 or-ganisationen med henblik på at eliminere ineffektivitet i fremgangsmådenog fastholde kvaliteten.

Næsten alle virksomheder starter på niveau 1 og arbejder sig derfra op. Flereorganisationer, der har skullet købe et nyt informationssystem, har taget konse-kvensen og vurderer nu mulige leverandører på deres niveau i CMM. Heriblandtden amerikanske regering, der fra og med 2002 bruger CMM som en del af dereskvalifikation af leverandører til alle statslige projekter.

P.t. arbejder mange virksomheder hårdt for blot at opnå niveau 3, og der ermange ressourcer at spare på at blive bedre. I Whitten et al. [2001, s. 78] gengi-ves en statistik for et udviklingsprojekt på 200.000 kodelinjer. Den viser, at hvoren virksomhed på CMM-niveau 1 bruger 600 mandemåneder og har en gennem-snitlig omkostning på USD 5,5 mio., bruger en virksomhed på CMM-niveau 3kun 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 afmetodologininger 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 virksom-heden, men i det lange løb opnås store fordele både med hensyn til omkostningerog kvalitet. Denne sammenhæng understreges også i Vesterager [1989], som detfremgår af figur 2.1.

Ressource-

indsats

Analyse Impl. og vedl.DesignTid

Struktureretfremgangsmåde

Traditionelfremgangsmåde

Konstruktion

Figur 2.1: Besparelse ved anvendelse af struktureret fremgangsmåde (metodologi)

[Vesterager, 1989]

13


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 in-formationssystemer taler man om en Systems Development Life Cycle (SDLC),og der er gennem tiden blevet udviklet mange forskellige modeller. Nogle af deklassiske er vandfaldsmodellen og den senere spiralmodel, som jeg vil beskrive idet følgende.

2.2.1 Vandfaldsmodellen

Vandfaldsmodellen illustrerer den traditionelle fremgangsmåde for udvikling afinformationssystemer. Som det fremgår af figur 2.2(a), opdeler modellen projek-tet 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 ersvært at svømme mod strømmen i et vandfald.

Selv om modellen har været brugt i mange år, har den en del ulemper, hvorafIteration

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, hvordanman kan gå tilbage til tidligere faser, men disse iterationer kan hurtigt blivemeget dyre [Bennett et al., 1999].

P Q R S T UV W X Y W T T Z Y W X[ T \ ] Y Z T UT W S R^ W _ ` Q R Y R

a T R Y X W

b T R S Y W X

c d W R S Z ] e S Y d W

f W R S _ ` ` _ S Y d W

g"_ Y W S T W _ W e T

(a) Uden iterationer

h i j k l mn o p q o l l r q o ps l t u q r l m�l o k jv o w x i j q j

y l j q p o

z l j k q o p

{ | o j k r u } k q | o

~ o j k w x x w k q | o

�"w q o k l o w o } l

(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 inte-greret anvendelse af iteration. Spiralmodellen (figur 2.3 på følgende side) blevlanceret i 1988 af Boehm som et resultat af forskellige tilpasninger af vand-faldsmodellen på store statslige IT-projekter [Schwalbe, 2000]. Spiralmodellenlægger op til, at man løbende lancerer fungerende versioner af informationssyste-met (eller dele heraf), hvor hver ny version har øget funktionalitet. Anvendelsenaf prototyper tilskyndes af spiralmodellen, og på den måde kan man tidligt iprocessen få tydeliggjort seriøse misforståelser.

14

2.2 Projektlivscyklus

Prototype1

OperationalPrototype

RiskAnalysis

Evaluatealternatives,Identify, resolverisks

Concept ofoperation

Requirements PlanLife Cycle Plan

DevelopmentPlan

Integration and Test Plan

RequirementsValidation

Design Validationand Verification

AcceptanceTestImplementation

PlanNextPhases

Develop,verifyNext-LevelProducty

SoftwareRequirements Software

ProductDesign

DetailedDesign

Integrationand Test

UnitTest

Code

DetermineObjectives,Alternatives,and Constraints

Commitment

PartitionReview

CumulativeCost

ProgressThroughSteps

Prototype2

Prototype3Risk

Analysis

RiskAnalysis

RiskAnalysis

Simulations, Models, Benchmarks

Figur 2.3: Boehms spiralmodel for projektlivscyklus [Schwalbe, 2000]

2.2.3 Den objektorienterede projektlivscyklus

Med udviklingen af tankegangen bag det objektorienterede paradigme blev detnødvendigt at redefinere, hvordan udviklingsprojekter forløber. Object Mana-gement Group (OMG) har foreslået en livscyklusmodel for objektorienteret sy-stemudvikling, som er illustreret i figur 2.4. I OMG’s model fokuseres på, hvadder skal udføres, og ikke rækkefølgen hvori det skal udføres. Tværtimod lægges Parallelle

aktiviteterop til, at flere af opgaverne kan udføres samtidig [Bennett et al., 1999]. Derforkan modellen umiddelbart godt virke lidt utilgængelig og svær at omsætte tilpraksis, og det kræver derfor en nærmere detaljering af de enkelte faser.

Life cycle

Co-ordination and reuse

ObjectModelling

Strategic Modelling

Analysis Modelling

Design Modelling

Implementation Modelling

Construction

Delivery

Fulldefinition

of thesystem

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 afOO-SDLCModelling, Design Modelling, Implementation Modelling og Construction, og der

lægges dermed op til, hvordan man griber et udviklingsprojekt an efter den ob-jektorienterede tankegang. I figur 2.5 på følgende side er vist de tre overordnedeaktiviteter, som udgør den objektorienterede SDLC.

15


�� "� � �

� � � � ��

� � � � � � � � � � ��

� ¢¡�� £ ¢£ � ¤ � ¤ � ¥��

� � � � ¦"§ ��¨ ©� � © ª� � � � � « ��¬ « � ¦ « � �"�� ¦� � � ¦ � � ¦ � �� « � � � � � � � � � � �� "®°¯ ��

±£ � � ²��

³ � � � ¦ �"� � � � � � � ´� � � � �� « � � � � � �� "�� µ � � �� "� � � � �� "� � � �

� � � � �� «� � � � « � � �� ¬ « � � � � � ¬ �� « � � � � � � � � � � �� ´ � � � � � � � � �"� � � � ´� � ��¯ �°� � � �

� ¤ £ ¶ � ¤ � ¥�� ·¢¶ £�¸�� £

Figur 2.5: Fremgangsmåden ved objektorienteret systemudvikling (OO-SDLC)

[Bahrami, 1999, s. 44]

Analysis og Design svarer til henholdsvis Analysis Modelling og Design Model-

ling i OMG’s livscyklusmodel, og Implementation svarer til summen af Imple-

mentation Modelling og Construction.

Forudsætningen for Bahramis model er, at der forud for den første analysefaseer lavet en forretningsmæssig analyse af behovet og omfanget af informations-systemet (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åri et projekt.

I relation til dette eksamensprojekt passer fokuseringen godt, og som nævnt iFokus på analyse

indledningen vil jeg fokusere på den objektorienterede analyse (afsnit 3.3 på side23), men for at give indsigt i sammenhængen vil jeg også kort beskrive de to over-ordnede faser, som følger analysefasen – design og implementering (afsnit 3.4 påside 27). Forinden vil jeg dog give en kort introduktion til det objektorienterededomæne i kapitel 3 på side 19, da tankegangen er væsentligt forskellig fra dentraditionelle strukturerede tilgangsvinkel, hvor data og procedurer (der udføreroperationer på data) er opdelt.

2.3 Mislykkede projekter

Der eksisterer mange skrækhistorier om IT-projekter, der er gået galt, og mankan hurtigt få det indtryk, at man skal have is i maven som leder, før man tørsætte et IT-projekt i gang. Og det er ikke et helt forkert indtryk! En forkertantagelse er dog ifølge The Standish Group2, at mislykkede projekter skyldes

2 The Standish Group (www.standishgroup.com) er et velanset amerikansk forskning- oganalysefirma, der beskæftiger sig med problemstillinger inden for informationsteknologi.

16

2.3 Mislykkede projekter

Typiske symptomer Grundlæggende årsager

-Misforståelse af brugernes krav og behov -Ad hoc-administration af brugernes krav

-Manglende evne til at håndtere ændringaf krav

-Uklar og upræcis kommunikation

-Moduler, der ikke passer sammen -Skrøbelige arkitekturer

-Software, der er svært at vedligeholde ogudvide

-Overvældende kompleksitet

-For sen opdagelse af seriøse fejl iprojektet

-Uopdaget inkonsistens imellem krav,design og implementering

-Lav kvalitet af software -Utilstrækkelig testning

-Uacceptabel ydelse fra software -Subjektiv vurdering af projektets status

-Umuligt at rekonstruere, hvem derændrede hvad, hvornår og hvorfor

-Risici bliver ikke håndteret

-En utroværdig udviklingsproces -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 forog 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øgelsenviste, 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,3mio., og den totale succesrate var på kun 16,2%! Succesfulde projekter blev iden forbindelse defineret som projekter, der opfyldte projektmålene til tiden oginden for det afsatte budget. Herudover fandt de ud af, at 31% af IT-projekterneblev 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. Suc-cesraten var nu oppe på 26%, mens 28% ikke opfyldte kravene inden for deøkonomiske og tidsmæssige rammer. De resterende 46% blev gennemført, menkostede mere og tog længere tid end planlagt.

Kruchten opstiller en liste over typiske symptomer for og mulige årsager til, Symptomer ogårsager til fiaskoerat 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 sam-menhæng mellem symptomer og årsager, men projekterne mislykkes typisk somfølge af en kombination af årsagerne.

Mange af symptomerne og årsagerne har rod i projektets start, og i relation Årsager kaneliminerestil dette eksamensprojekt kan flere af årsagerne elimineres ved at fokusere på

en tilbundsgående analyse og et iterativt udviklingsforløb. På den måde skub-bes risici for f.eks. opdagelse af fejl ikke længere frem i tiden, og man undgåroverraskelsen over, at man har udviklet et informationssystem, der er dyrere

17


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å fald-gruberne, og i afsnit 3.3 og 3.4 vil de to første faser af den objektorienteredefremgangsmåde blive beskrevet.

18

Kapitel 3

Det objektorienterede

paradigme


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. Fordet første spiller den en central rolle inden for produktmodellering, og for detandet anvendes objektorienteret analyse til at fastlægge kravene for dokumenta-tionsværktøjet. I dette kapitel gives en kort introduktion til den grundlæggendetankegang i det objektorienterede paradigme, og de centrale elementer beskri-ves. Herudover beskrives objektorienteret analyse, mens objektorienteret designog objektorienteret implementering kort gennemgås.

19

Kapitel 3 - Det objektorienterede paradigme

3.1 Objektorienterede fremgangsmåder

Objektorienterede fremgangsmåder er relativt unge, men har vundet stor udbre-UML

delse. I slutningen af 1980’erne og starten af 1990’erne blev der anvendt et utalaf forskellige objektorienterede metoder, og det gav anledning til problemer forsystemudviklerne, som skulle lære mange forskellige metoder at kende [Whittenet al., 2001]. Situationen blev bedre, da the three amigos, Grady Booch, Ja-mes Rumbaugh og Ivar Jacobson, samlede kræfterne med det formål at skabeén standardiseret proces for udvikling af objektorienterede informationssyste-mer. De samlede det bedste fra deres egne og andres metoder, og resultatetblev lanceringen af Unified Modelling Language (UML) ver. 1.0 i 1997 [Whittenet al., 2001]. UML er ikke en metodologi, men en standardiseret notationsformfor objektmodellering. OMG adopterede hurtigt UML og har siden vedligeholdtspecifikationen, og UML er i dag de facto standard for objektmodellering.

Inden for traditionel systemudvikling har målet været at implementere syste-Eksempler påprocedurale sprog:- Pascal

- Fortran

- COBOL

merne vha. procedurale programmeringssprog. Det er sprog, hvor et programbestår af en mængde data (variable) og et antal handlinger (procedurer), somudfører operationer på programmets data. Før systemet kan implementeres, skalman derfor have omsat kravene fra domænet, hvor informationssystemet skalbruges til procedurer og variable. En af de største ulemper ved denne type sproger, at vedligeholdelsen bliver meget omstændelig, idet det er svært at overskuekonsekvenserne af at ændre en procedure.

I objektorienteret modellering anskues verden som bestående af objekter, somObjekter

har nogle egenskaber og kan udføre nogle operationer. Et objekt er umiddelbarten 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.


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

sents 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 iet domæne, dels som element i et stykke software med en identitet, tilstand ogadfæ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å denmåde uafhængigt af objektets interne datastruktur og funktionalitet. For objek-tet defineres en ekstern funktionalitet (en grænseflade), som bruges i samspilletmed andre objekter. Så længe denne grænseflade bibeholdes, vil objekter afandre klasser ikke være påvirket af, at der laves ændringer i klassen. Det bli-ver således nemmere at overskue konsekvenserne af de ændringer, man ønsker atlave. Dette kan sammenlignes med en bil: Så længe forhjulene drejes, når førerendrejer på rattet, så er det ligegyldigt, om der anvendes hydraulik, snekkedreveller tandstangsstyring til at overføre kræfterne. Dette koncept betegnes ofteindkapsling og er helt centralt i den objektorienterede tankegang.

3.2 Centrale elementer

I den objektorienterede modellering anvendes en række centrale elementer til atbeskrive 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 instansaf 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 vedat specificere deres egenskaber (attributter), adfærd (metoder) og mulighed forgeneralisering (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. Attribut- Ý»Þ ß

à á â ã â ä å æ�ç è é ê å ë â ì í�î ï ð ç ñò°ó ç è ô�ã õ ö ê ñ â ì í"î è é ã ç å ä÷ æ�ã â ø ì ç å é í�î ï ð ç ñ

ù ú û ü ý þÄÿ þ � � �ù ��Äü � þ�ÿ � � �ù �� þ � ÿ � � �ù �� ü"ÿ � �� üterne 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ærdiernefor en af instanserne ville da være henholdsvis Sølv, Audi og TT. I informa-tionssystemet kan attributterne implementeres på flere måder med anvendelseaf 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 instansaf klassen Biler have en attribut Motor, som i sig selv er en instans af klassenForbrændingsmotor.

21


Metode

Mens attributterne beskriver, hvad objektet “ved” om sig selv, beskriver meto-�� !� ��" # � $ � � !� ��" ! " �� ! ��" ! " �% &(' ) ' * + ,.- / 0 1 + 2 ' 3 4 5 6 7 - 89�: - / ;() < = 1 8 ' 3 4�5 / 0 ) - + *> ,() ' ? 3 - + 0 4.5 6 7 - 8

derne, hvad objektet “kan”. For eksemplet med en bil kunne metoderne væreBrems, Accelerér og Drej. Metoderne skal definere alle de operationer, som etobjekt skal kunne udføre, så objektet på den måde er ansvarlig for sin egenadfærd [Bahrami, 1999]. Herudover er det god skik at bruge metoder til at giveandre objekter adgang til indholdet af attributterne. På den måde kan mannemmere opretholde en ensartet grænseflade til omgivelserne, og omfanget affremtidigt vedligeholdelsesarbejde kan reduceres.

Generalisering

Generalisering (eller nedarvning) beskriver den egenskab, at objekter kan opbyg-ges af andre objekter, og det er dermed muligt at genbruge fællestræk mellemensartede klasser. I eksemplet med klassen Bil svarer det til, at denne klassenedarver fra en overliggende klasse kaldet Køretøj. Klassen Ford kan derefternedarve fra klassen Bil, og klassen Falcon kan igen nedarve fra Ford. Hvis klas-sen Bil har defineret en metode til at dreje bilen, nedarves denne metode til alleunderliggende klasser, som derefter vil vide, hvordan de skal dreje. På sammemåde kan ens attributter nedarves, f.eks. har klassen Bil en attribut Farve, somnedarves til alle biler. Princippet er illustreret i figur 3.2(a).

Køretøj

Bil Lastbil

Ford

TaunusFalcon

Audi

Mondeo

(a) Hierarki ved nedarvning

Køretøj

Lastbil

Ford

Falcon FH12

Volvo

Bil+ VisNrPlade()# Drej(int)

Hvordandrejerman?

Sådanher:Drej()!

Hvordandrejerman ?

Ingen anelse...Lav din egenmetode! ?

VisNrPlade()

"AB 12 345"

(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 opretteten relation mellem de tilsvarende klasser. Relationerne betyder populært sagt,at objekterne kender til hinandens eksistens og har mulighed for at “tale” sam-men. 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 etobjekt ønsker information om en Ford Falcons nummerplade, sker dette vedat eksekvere Falcon-objektets metode VisNrPlade() frem for at læse attributtendirekte (se figur 3.2(b) på foregående side).

For at kunne styre adgangen til metoder og attributter er det muligt at give Symboler:− private

# protected

+ public

disse en status som private, protected eller public. Private betyder, at en metodeeller attribut kun kan tilgås af objektet selv. Protected betyder, at metodeneller attributten også kan tilgås fra objekter af klasser, der nedarver fra klassen.Public betyder, at alle objekter kan tilgå metoden eller attributten.

Der eksisterer flere forskellige typer af relationer, og disse er beskrevet i afsnit 3.3under gennemgangen af UML som dokumentation.


Analysefasen drejer sig om “determining the system requirements and identi-

fying 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ørsteudfordring består således i at kunne forstå problemet og dets domæne. I analy-sefasen opbygges brugsmønsterdiagrammer og klassediagrammer, og fordelen idet objektorienterede domæne er, at de samme modeller/diagrammer kan bru-ges i analysefasen såvel som designog implementeringsfaserne [Bahrami, 1999,s. 126].

I dette projekt anvendes UML som notationsform, og alle modellerne, der be-skrives i det følgende, er derfor tegnet i henhold til denne standard.

23


3.3.1 Brugsmønsterdiagrammer

Objektorienteret analyse (OOA) kaldes ofte usecase driven, dvs. drevet frem afbrugsmønstre (usecases). Dette bunder i, at opbygningen af brugsmønstre er detførste, der sker i fasen, og brugsmønstrene bruges centralt i dokumentationen forkravene 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ønstersom

. . . a behaviorally related sequence of steps (a scenario), both auto-Brugsmønster

mated and manual, for the purpose of completing a single business

task.


Herudover består et brugsmønsterdiagram af aktører, der defineres som

. . . anything that needs to interact with the system to exchange infor-

Aktør

mation. An actor is a user, a role, which could be an external system

as well as a person.


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ønster-diagram er vist i figur 3.3.

@BA CED A FHG IHJ

K L M�N O P Q R

STM U Q R V O P�W L M Q R X Y R Z

[�\ W Q ] ^ R N O P Q R

K _`Vba ] c V Q R

d�O N�M e QbN O P Q R

K L M�\ R a�a M U Q ZN c N W c Y Z Q X

f g V Q V h

f Q i Z Q M U V h

f g V Q V h

j.c N W c Y Z Q X a R

k M U X O N Q R

K L M Q R

l`m n oqp

r(sTp tTu v�w(xTy z x{b|.z n xT}�~Tp ��v�z x

��p ��~(z�}Eoqv�z n xTp

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. sagtensvæ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


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 kanudskilles 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 udskilttil brugsmønstret “Undersøg lånerkort” frem for at gentage sekvensen i beggebrugsmønstre. Ud over at lette overskueligheden betyder det også, at hvis derskal æ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 bibliotekforegår på næsten samme måde – der sker bare en anelse mere. Denne “anelsemere” beskrives så i det udvidede brugsmønster (“Lån fra andet bibliotek”). Enanden 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 variationernedirekte i brugsmønstret kan man lave en eller flere udvidelser, der beskriver si-tuationen 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. for-udsæ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 kom-mende brugere af systemet tidligt i udviklingsprocessen. På en letforståelig mådeillustrerer et brugsmønsterdiagram, hvordan brugen af systemet kommer til atforegå, og det kræver ikke den store indsigt og erfaring at forstå diagrammet ogkunne komme med kommentarer.

3.3.2 Klassediagrammer

Det centrale diagram til statisk modellering i UML er klassediagrammet

+ModtagInput()

-AntalTaster

«Interface»Tastatur[Bahrami, 1999]. Hele systemets statiske struktur fremgår af klassediagrammet,

hvor klasserne naturligt er de centrale elementer. Klasser kan yderligere katego-riseres 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 brugs-mønsterdiagrammet [Bennett et al., 1999]. Sammenhængen mellem klassernevises med forskellige typer relationer, som gennemgås nedenfor.

25


Svage aggregeringsrelationer bruges til opbygning af part-of relationer, hvor�.� � � � � � � � � � � � � � � � � � � ��H� � � � klasserne eksisterer uafhængigt af hinanden. Dvs. at underklassen eksisterer uaf-

hængigt af overklassen. Kardinalitet kan frit anvendes til at angive mængdefor-holdene1.

Stærke aggregeringsrelationer bruges i lighed med svage aggregeringsrela-�.� � � � � � � � � � � � � � � � � � � �� tioner 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 instanseraf 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” hinan- .¡ ¢ £ £ ¤�¥ .¡ ¢ £ £ ¤T¦

den. To klasser kan ikke kommunikere med hinanden (lave metodekald og tilgåoffentlige ressourcer), hvis de ikke er forbundet med en relation. Såfremt klas-serne ikke er forbundet med andre relationer, anvendes en associeringsrelationtil at illustrere sammenkædningen. Kardinalitet kan frit anvendes til at angivemængdeforholdene.

Grænsefladerelationer bruges mellem to klasser, hvoraf den ene fungerer som§.¨ © ª ª «�¬ §.¨ © ª ª «T

en grænsefladeklasse. Dette kan illustrere en grænseflade mellem to systemer.

Generaliseringsrelationer sammenkæder klasser i en nedarvningsstruktur.®.¯ ° ± ± ²�³ ®.¯ ° ± ± ²T´

En underklasse (f.eks. en sportsvogn) kan arve egenskaber og funktionalitet fraen 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 generaliserings-eller stærke/svage aggregeringsrelationer. Det er muligt at have “klynger i klyn-ger”. På engelsk kaldes dette en package [Booch et al., 2001].

Noter kan indsættes i klassediagrammet. Noter kan med en stiplet linje kædes» ¼ ½ ¾ ¾ ¿ À Á Â Â Á(Á Ã Á ÄÄ Å Â Á Æ Ç È Ä É Á ÂÂ È Ç Á ÄTÉ Ç Ê Ë Ë Átil et element i klassediagrammet (f.eks. en klasse eller en relation). Det er dogikke 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 temaog alle ikke-forbundne klasser til hver sit tema. Det er muligt at have “temaer itemaer”.

+OpbevarEmner()

-AntalPladser : int

Lager

+FindTomPlads()+NedskrivLager()+OpskrivLager()+UdskrivStatus()

-AntalTommePladser : int-AntalFyldtePladser : int

Lagerstyring

+Hent()+Modtag()+ÆndrLagerstatus()+LavEmneBeskrivelse()

-EkspedientID

«Aktør»Lagerekspedient

+FindEmne()+FindKundeemne()

-Lokation : int-Sektion : int-Hylde : int-Beskrivelse : String-Antal : int

Lagerplads-Styres af

1-Styrer1 -Opdeles i

1

-Udgør1..*

-Har ansat1

-Arbejder hos0..*

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 aggre-geringsrelation 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 sesdet, at for hver klasse vises metoder og attributter inde i klassen. Alt afhængigaf situationen kan det være hensigtsmæssigt at skjule disse informationer ellernøjes med at vise dele af dem i diagrammet.

Opbygningen af klassediagrammet kan forløbe på flere måder, og som tidligerenævnt definerer UML kun, hvordan diagrammet skal se ud, og ikke hvordan detfremkommer. I litteraturen findes mange forskellige forslag til, hvordan klasseridentificeres og relateres til hinanden. I Bahrami [1999] og Whitten et al. [2001]lægges op til, at man tager udgangspunkt brugsmønsterdiagrammet, hvilketogså er centralt i Jacobson et al. [1999]. Bahrami nævner disse retningslinjer foridentifikation af klasser:

- Se efter navneord og sætninger med navneord i brugsmønstrene (dvs. isæri 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. Ef-terhånden som modellen opbygges, bliver man opmærksom på flere aspekterog detaljer, som løbende tilføjes. Sekvensdiagrammer er også en god kilde tilidentifikation af klasser og definition af relationerne imellem disse.


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åryderligere fast, at det ofte kan være svært at definere en klar skillelinje mellemanalyse- og designfasen, men generelt kan man sige, at analyse drejer sig om atspø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 ana-lysefasen, 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 de-sign tager man ikke stilling til den endelige implementering, men fokuserer påden logiske struktur og opbygning. Fysisk design drejer sig derimod om, hvor-dan systemet reelt skal implementeres. Herudover designes ofte på to niveauer:Systemdesign, der fokuserer på systemet som helhed, og detaljeret design, somgår i detaljen med f.eks. klasser og databasestrukturer [Bennett et al., 1999].

27


Den diffuse overgang mellem analyse og design udviskes yderligere af, at ob-jektorienteret systemudvikling lægger op til en iterativ proces. På især størreprojekter er det dog essentielt, at man kan slå en streg i sandet mellem analyseog 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 oftehar forståelse for teknologiske muligheder.

- Klientens beslutninger

Afslutningen på analysefasen er en oplagt milepæl, hvor klienten under-skriver 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 meddesignet.

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. Atarbejdet bygger på analysefasens modeller, gør naturligvis, at des bedre analysener, des nemmere bliver det at lave designet. Herudover gør det det let at sam-menholde kravene fra analysen med designbeslutninger. Flere CASE-værktøjerunderstøtter dette, og det er centralt for at kunne udvikle informationssystemeraf høj kvalitet.

Den uklare skillelinje mellem analyse og design betyder, at det er svært atafgøre, hvilke diagrammer der hører til hvilken fase. Whitten et al. [2001] skelnersåledes mellem et analyse-brugsmønster og et design-brugsmønster, hvor en af demest afgørende forskelle er, at design-brugsmønstret indeholder mere detaljeretinformation om objekternes indbyrdes handlinger. Den direkte videreudviklingaf brugsmønstrene sker ved opbygning af interaktionsdiagrammer.

3.4.1.1 Interaktionsdiagrammer

Aktiviteterne i brugsmønstrene kan detaljeres og beskrives yderligere i inter-aktionsdiagrammer. Det danske udtryk interaktionsdiagrammer dækker oversekvens- og samarbejdsdiagrammer (sequence- og collaborationdiagrams), somer to forskellige måder at vise den samme information på.

Med disse diagrammer tilføjes en tidsdimension til handlingerne, og det blivermere overskueligt at se omfanget af brugsmønstret i relation til klasser og deresinteraktion. En ulempe er, at det ikke umiddelbart er muligt at tydeliggøreløkker [Bahrami, 1999]. I eksemplet i figur 3.5 på følgende side er benyttetnotationen fra Bennett et al. [1999], der foreslår, at løkker angives ved at sætteen ‘*’ foran procedurekaldet.

28


ÞTß à á â ã ß äå æ ç è á é�ê á ë ì ß ä

â æ ç à íTì ì î ì ï ß ä

å æ ç íTì ì î ì ï ß ä

à æ â ð ñ ã íTì ì î ì ï ß

ò ß ì à ó(á å ì

â æ ç à è á é�ê á ë ì ß ä

è á é�ê á ë ì ß â ß ô ß ä

õ ò ß ì à è á ébê á ë ì ß Þ(ß à á â ã ß ä

óTá å ì

ö è â æ ß ì à

íTì ì î ì ï ß

õ ò ß ì à íTì ì î ì ï ß Þ(ß à á â ã ß äíqì ì î ì ï ß ÞTß à á â ã ß ä

ö è á é�ê á ë ì ß

ì ÷ íTì ì î ì ï ß ö íTì ì î ì ï ß

ö íTì ì î.ì ï ß

ø`ù ú ûTü(ý�þTü ÿ��qü � þ � �Tù ú

� þ � �Tù ú �Tú ��

� þ � �qù ú �(ú �� Tù ú � ú �(ú

�� ø��Tü��(þ � �Tù ú ��qù�� Eø��

�� ü �(ú ú �� .ú��Tþ � �Tù ú

��.ù ��ü �(ú ÿ(ü ��Tü ��

��ù �� Tú ��Tù ��

å æ ç ó.÷ íTì ì î ì ï ß

Figur 3.5: Eksempel på sekvensdiagram i UML-notation [Bennett et al., 1999, s. 173]

�� "! � # $ % & % ' % (

) * & + , - � � "! � # $ % (.�* / + , � � "! � # $ % ( * ��& + % $ - * �� 0! � # $ %1�* 2 % $ - � � "! � # $ % 3�% - � & 4 % (5�* 3�% - � & 4 % (

6�7�8 8 9 : ;�< = 9> ? = @ A 9 B"C"9 D ? E C�F 9

GIH J 9 8 KFigur 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å. Eteksempel er givet i figur 3.6, hvoraf det fremgår, at et samarbejdsdiagram frem-hæver klassernes interaktioner, men uden det overskuelige tidslige aspekt, somsekvensdiagrammerne fokuserer på. At diagrammerne indeholder den sammeinformation bekræftes af, at det i Rational Rose er muligt at generere et samar-bejdsdiagram fra et sekvensdiagram blot ved at trykke på en tast. Fordelen vedet samarbejdsdiagram er, at det er nemt at overskue, hvordan klasserne sam-arbejder. F.eks. vil det være helt tydeligt, hvis et enkelt objekt har en centralrolle, da alle andre objekter vil stå ud fra det som i en stjerne.

Når klassediagrammet er udbygget, kan sekvensdiagrammerne opdateres til atafspejle informationen i klasserne. Objekterne tilføjes navnene på klasserne, be-skederne erstattes med metodekald og gives argumenter, der er i overenstem-melse med definitionen i klasserne.

29


Dette arbejde understøttes i vid udstrækning af CASE-værktøjer (f.eks. Ra-tional Rose og MS Visio), hvor man blot klikker på en besked og kan vælgeden ønskede metode blandt dem, som er defineret for den modtagende klasse.Når modellen er fuldt udbygget med fuld definition af klasser og detaljeredesekvensdiagrammer, er meget af grundlaget for kodningen på plads, og nogleCASE-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 medhenblik 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ændelsefor-lø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 kanantage mange forskellige tilstande, eller til illustration af hvad der fører etobjekt 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. hvor-dan forskellige software- og hardwareelementer er koblet sammen og kon-figureret (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. etacces layer og et view layer. Gennem arbejdet med disse lag skal brugergræn-sefladen og datastrukturen lægges endeligt fast. Brugergrænsefladen udviklesbedst ved at lave flere prototyper, som testes over for brugerne. Til design ogspecifikation af datastrukturen eksisterer flere diagrammeringsmetoder (f.eks.entity-relationsship diagrammet), som er velegnede til dette.

3.5 Objektorienteret implementering - OOI

I designfasen (fysisk design) er implementeringen blevet planlagt og specificeret.Eksempler påOO-sprog:- C++

- Smalltalk

- Java

I implementeringsfasen anvendes specifikationen fra designfasen som grundlagfor den endelige programmering. Det er ikke nødvendigvis alt, der skal program-meres 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 klyn-ger fra tidligere projekter (eller evt. kommercielle).

Implementeringen foregår med anvendelse af objektorienterede programmerings-sprog. Måske findes nogle Commercial Off The Shelf (COTS)-moduler, som mednogle små programstumper (middleware) kan løse nogle af opgaverne. Dette kanofte være en bedre og billigere løsning end at bygge hele systemet fra bunden.

30

3.5 Objektorienteret implementering - OOI

Kør videre

Hold kobling nede Bevæg gearstang

Kør videre i nyt gear

Skal derskiftes gear?

Ja

Nej

(a) Aktivitetsdiagram

Undelivered

Un confirmed

Confirmed

Backordered

Produc t not

on stock

Stock received

Picking lis t

prin ted

Quantity

conf irmed

Ne w item

created

(b) Tilstandsdiagram

L M N O P Q R S T N U V WX N M Y�Z T N

[ \ ] ^ ^ _ ` a b c

d X P P Q�e f M Q g d h i N P j M N

k l�m n o p o q r s

t u k v�r w r s�r x q

(c) Anvendelsesdiagram

Figur 3.7: Eksempler på diagrammer anvendt i designfasen [Riis, 2002]

«Header»SalesOrder.h

«Body»SalesOrder.cpp

«Object Code»SalesOrder.o

«Executable»PrintOrder.exe

«includes»

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 im-plementeringen, så det er let at vedligeholde systemet fremover. Anvendelses-diagrammet 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 aktivi-teter som testning, konvertering af data fra gamle systemer og den helt afgørendeopgave med at indføre det nye system i organisationen.

Efter implementeringen følger vedligeholdelsesfasen, som naturligt strækker sigover resten af systemets levetid. Hvis ikke systemet er veldokumenteret og struk-tureret opbygget, kan det hurtigt blive meget omstændeligt – hvis ikke umuligt– at vedligeholde og udbygge systemet. I sidste instans betyder det, at manvæ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


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 produkt-modeller anvendes i specifikationsprocessen. Herudover gennemgås fremgangs-måden for opbygning af produktmodeller fra CPM med særlig fokus på dendokumentation, som anvendes. Formålet er at afdække produktmodellerings-processen og behovet for dokumentation med henblik på den senere analyse afkravene 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å produktudviklings-og specifikationsprocessen for at kunne imødekomme kundernes forventningerom mere kundetilpassede produkter med kort leveringstid og til konkurrence-mæssige priser [Hvam og Mortensen, 2002; Pikosz, 1997]. Udviklingen inden forinformationsteknologien har samtidig gjort det muligt at lave komplekse syste-mer, der kan understøtte de beslutningsprocesser, som indgår i specifikationenaf et produkt ud fra en række krav.

Et eksempel på anvendelsen af IT til understøttelse af konfigurering af et kom-plekst produkt er nævnt i Hvam og Mortensen [2002]. Her beskrives, hvorledesF.L. Smidth, der fremstiller cementfabrikker, med succes har taget et infor-mationssystem i brug, der kan støtte op under udarbejdelsen af budgettilbud.Hidtil har udarbejdelsen af tilbud involveret 10-15 specialister og taget tre-femuger. Med det nye informationssystem (en konfigurator) tager processen en-todage og kan udføres af en enkelt sælger. Fordelene og besparelserne ved at brugekonfiguratoren 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 begrebernepå sin plads. Hvam og Mortensen definerer en produktmodel således:

En produktmodel betegner et system, der indeholder viden og infor-

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

cycle.

[Krause et al., 1993, citeret i Riis [2001]]

Denne information er basis for produktkonfigurering, som bl.a. er defineret iRiis [2001, s. 55] som “. . . to combine well defined building blocks governed by

rules and constraints into a product”. Riis nævner også, at produktkonfigure-ring kan anvendes inden for flere anvendelsesområder, heriblandt tilbudsgiv-ning/salg, produkttilpasning og produktionsforberedelse.

Figur 4.1 på følgende side illustrerer de centrale aktiviteter i en virksomhedsspecifikationssystem. Specifikationssystemet omfatter alle de processer og akti-

34


Salg Produkt-konstruktion

Produktions-forberedelse Kalkulation

Indkøb Planlægning Produktion Levering/montage

Specifikationssystemet

(a) Uden anvendelse af produktmodel

Salg Produkt-konstruktion

Produktions-forberedelse Kalkulation

Indkøb Planlægning Produktion Levering/montage

Specifikationssystemet

Produktmodeller

(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ærefordelt ud på flere afdelinger, og specifikationen af et produkt – f.eks. i forbin-delse med et salg – vil derfor indebære megen kommunikation på tværs mellemafdelingerne (figur 4.1(a)). Med anvendelse af en produktmodel kan al infor-mation om produktet samles på tværs af organisatoriske opdelinger, og ud fraproduktmodellen er det således muligt at definere, på hvilke måder et produktkan struktureres.

Med produktmodellen kan f.eks. en sælger egenhændigt specificere et produkttil 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 kom-binationer kan være astronomisk. Tænk f.eks. blot på, hvor mange varianter énenkelt bilmodel kan fås i (farve, laktype, dæk, motorstørrelse, ekstraudstyr mv.).Med anvendelse af informationssystemer kan alle restriktioner og muligheder tilgengæ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 define-

rede 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 denrelevante viden, som f.eks. konstruktions- og produktionsingeniører har om pro-duktet. Dette er bl.a. information om, hvilke underdele der indgår i produktet,og regler om hvordan disse kan sammensættes. Traditionelt har denne infor-mation været spredt i organisationen, men formålet med en produktmodel erat samle al denne information og gøre den tilgængelig for et bredere publikumgennem en produktkonfigurator (se figur 4.2 på følgende side). De nyeste kon-figuratorer baseres på en objektorienteret produktmodel, hvor produktet kanmodelleres med strukturer som i det objektorienterede domæne (se kapitel 3 påside 19). Dette giver helt nye muligheder for produktmodellering og ligger tætop ad idéerne i CPM’s fremgangsmåde, som beskrives i afsnit 4.2 på side 38.

35


y{z |"}�~�z �}�z ��0~I� � �0��~��{�

��z ��|"�I� �"��"� � }�|�z �0� ��z

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, dersælger nødstrømsudstyr til f.eks. computere (se figur 4.3). På virksomhedenshjemmeside kan man indtaste, hvor mange computere, skærme, printere etc.der skal sikres, og systemet vil så på baggrund af denne information finde denbedste Uninterruptible Power Supply (UPS) i den givne situation.

Som nævnt er det en simpel konfigurator, og for god ordens skyld skal nævnes, atAPC snart lancerer en konfigurator for deres nye produkt PowerStruxure, sombygger på en meget kompleks produktmodel og bl.a. også anvender dynamiskvisualisering som et centralt element i konfigureringsoprocessen1.

1 Visualiseringen er resultatet af et netop afsluttet eksamensprojekt ved CPM [Kristensen,2002].

36


4.1.2 Rammemodel for produktmodeller

I Hvam og Mortensen [2002] er opstillet en model for produkt- og produktre-laterede modeller. Baggrunden er, at det ved produktmodellering ofte ikke vilvære tilstrækkeligt kun at have en model af selve produktet. Når et produkt skalspecificeres, foretages nogle valg, som påvirker produktets andre livsfaser. I figur4.4 er rammemodellen vist med selve produktmodellen til venstre og modellerfor alle faserne i produktets livsfoløb til højre.

Salg Konstruktion Produktions-forberedelse

Planlægning Indkøb Produktion Montage Anvendelse DestruktionFunktion

Struktur

RelationsmodellerProduktmodel

Figur 4.4: Rammemodel for produktmodeller [Hvam og Mortensen, 2002]

Rammemodellen viser, hvordan en produktmodel består af en funktionel ogstrukturel beskrivelse og kan være relateret til en række andre modeller. Denmodel, som skal fungere som basis for en produktkonfigurator, skal indeholdeinformation om de områder, som konfiguratoren skal kunne dække. Ofte vil detikke være hensigtsmæssigt (eller nødvendigt) at inddrage information om allelivsforlø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 produktud fra dets strukturelle opbygning (f.eks. hvor meget RAM en computer skalhave), frem for at der tages udgangspunkt i det funktionelle behov (f.eks. tilhvilket formål computeren skal anvendes). Med hensyn til relationsmodellernebetyder det, at konfigurationen tager hensyn til indkøbsfasen (f.eks. ved at ge-nerere 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 derf.eks. ikke tages hensyn til, hvordan produktet destrueres (f.eks. ved at givemulighed for at vælge om produktet må indeholde visse plasttyper).

Med rammemodellen er det muligt at definere omfanget af den kommende spe-cifikationsproces, idet der tages stilling til, hvilken information der skal væreindeholdt i modellen. Men samtidig gøres også klart, hvad der ikke er indeholdti modellen, og dermed hvad modellen ikke kan bruges til.

37


4.2 Fremgangsmåde for opbygning af produkt-

modeller

Anvendelsen af produktmodeller har en række fordele og kan forbedre specifi-kationsprocessen markant for både virksomhed og kunde. For at kunne dragenytte af produktmodellen i det lange løb og undgå faldgruber er det nødvendigtat anvende en struktureret fremgangsmåde [Hvam og Mortensen, 2002; Hvamog Riis, 1999].

Ved CPM på DTU er der blevet forsket inden for området de sidste ti år, og etaf resultaterne er fremgangsmåden for opbygning af produktmodeller, som udover forskningen også er baseret på erfaringer fra opbygning af produktmodelleri såvel danske som udenlandske virksomheder.

Fremgangsmåden er beskrevet i Hvam og Mortensen [2002] og er kraftigt inspi-reret af objektorienteret udvikling af informationssystemer. Den grundlæggendefilosofi er, at more work up front pays in the end, og det betyder, at der læggesstor vægt på de indledende faser med analyse og design af systemet. Al erfaringviser, at netop dette reducerer ressourcebehovet ved den efterfølgende imple-mentering. I alt består fremgangsmåden af syv faser, som er kort beskrevet itabel 4.1 på følgende side. Herudover har jeg – for at give overblik over aktivi-teterne i faserne – lavet en funktionsmodel for fremgangsmåden baseret på In-tegration Definition for Function Modelling (IDEF0)-standarden (se bilag B påside 167). Af funktionsmodellen er det også tydeligt at se, hvilke ressourcer derer 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 eksiste-rende som den kommende situation og kontekst, før selve modelleringsarbejdetgår i gang. Arbejdet med produktmodellens dokumentation starter i fase 2 (Pro-duktanalyse), hvor der opbygges en PVM. Gennem faserne 3 og 4 videreudviklesproduktmodellen, og der skabes mere dokumentation i form af klassediagram-mer og CRC-kort, som udgør den endelige dokumentation for produktmodellen.I fase 5 bruges denne dokumentation som basis for programmeringen, og i fase7 opdateres dokumentationen løbende, i takt med at produktmodellen og kon-figuratoren vedligeholdes. Dokumentationen berøres ikke i fase 6, som primærtomhandler 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 ereksperter i produktet), systemudviklerne (der skal programmere konfigurato-ren) og sælgeren (som skal bruge konfiguratoren) og er en iterativ proces, hvorPVM’en fungerer som det samlende kommunikationsmedium, som alle kan for-stå. Under arbejdet med PVM’en udfyldes CRC-kortene løbende for at doku-mentere klasserne i PVM’en.

38

4.2 Fremgangsmåde for opbygning af produktmodeller

Fase Indhold Resultat

1 Procesanalyse Analyse af despecifikationsprocesser, derskal understøttes.

Beskrivelse af nuværendespecifikationsproces.

Analyse af den opgavespecifikationsprocessen skalløse.

Beskrivelse afspecifikationsprocessensopgave.

Konstruktion af fremtidigspecifikationsproces.Herunder fastlæggelse af deprodukt- ogproduktrelaterede modeller,der skal understøttespecifikationsprocessen ogdisses formål, synsvinkel ogkontekst.

Modellernes overordnedeindhold. Formål, synsvinkelog kontekst.

2 Produktanalyse Analyse af produktmodel.Opbygning afProdukt-VariantMaster (PVM).

Komplet Produkt-VariantMaster (PVM).

3 Objektorienteretanalyse

Opbygning afobjektorienteretanalysemodel (OOA)

OOA-model (evt. dynamik),brugergrænseflade ogkravspecifikation.

4 Objektorienteretdesign

Opbygning afobjektorienteret designmodel(OOD).

OOD-model.

5 Programmering Programmering og test. Programkode (for den givnekonfigurator).

6 Implementering Implementering. Brugervejledning oguddannelsesplan.

7 Vedligeholdelse Vedligeholdelse, herunderudpegning af ansvarlige forvedligeholdelse ogvidereudvikling.

Opdateret OOA-model ogprogramkode. Ansvarlige forvedligeholdelse ogvidereudvikling.

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æne-eksperterne. 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 iforhold til produktmodellen. Det sidste er især vigtigt i den efterfølgende vedli-geholdelse og evt. udvidelser af modellen.

Indholdet af CRC-kortene er tæt forbundet med indholdet af PVM’en og klas-sediagrammet. Meget information går igen i de tre diagrammer, og det er derforvigtigt at sikre, at den samme information rent faktisk er identisk i alle tre. Ef-terhånden som størrelsen og kompleksiteten af en produktmodel vokser, stigerbehovet for at holde den opdateret. For det første er opgaven i sig selv større, ogfor det andet er en stor kompleks model svær at overskue, og fejl bliver derforsværere at identificere.

39


I Hvam og Mortensen [2002] gøres opmærksom på, at hvis CRC-kort skal anven-des til den løbende dokumentation af en produktmodel, bør de være på elektro-nisk form eller ligefrem integreret i selve koden for produktmodellen. Hermedlægges op til, at ændringer i produktmodellen automatisk detekteres og måskeendda 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ådenbaseres i høj grad på genbrug fra forskellige metoder, og dokumentationen erderfor 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 pro-

duktrelaterede modeller, der skal opbygges” [Hvam og Mortensen, 2002, s. 38].Overblikket kræver, at man gør sig klart, hvilke fællesdele en produktfamilie eropbygget af, og hvilke dele der gør, at produkterne i familien adskiller sig frahinanden (dvs. hvor variansen skabes).

Figur 4.5: Eksempel på Produkt-Variant Master [Harlou, 1999, s. 10]

40


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 klasser2), der indgår i alle produkter i familien (f.eks. har allebiler i en produktfamilie fire hjul). I Harlou [1999, s. 10] hentes definitionen afpart-of relationer fra det objektorienterede domæne, men der tages ikke stillingtil, om der er tale om en stærk eller svag aggregeringsrelation3.

En klasse i part-of strukturen kan yderligere dekomponeres i et hierarki af un- ·¹¸ º »"¼�½ ¾"¿ÀÂÁ�Ã ÁIÄ Å�Æ�Ç È0É¹¿0ÊË�Æ�Ì�¿IÇÍ Î Ï Ï Ð Ñ

Í Ò Ó Ò Ô ÑÍ Î Ï Ï Õ Ñ

derklasser, og det er også muligt at tilføje attributter til hver klasse. For hverattribut er det hensigtsmæssigt at angive et værdiinterval, dvs. et interval elleren liste for de værdier attributten kan antage. En klasse i PVM’en følger defini-tionen af klasser i det objektorienterede domæne; “. . . a set of objects that share

a common structure and a common behavior ” [Harlou, 1999, s. 10].

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 klassekan varieres. F.eks. kan en bil fås med enten benzin- eller dieselmotor. En klassei 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-ofstrukturer 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 ensportsvogn, fordi der ikke er plads til reservehjul. Begrænsninger visualiseresdog ikke kun med bindinger, idet kardinalitet og attributternes værdiintervalogså begrænser mulighederne [Harlou, 1999, s. 10].

Som støtte til den formaliserede tegning af produktstrukturen indsættes oftenoter og illustrationer i PVM’en. På den måde virker PVM’en lidt som et do-kument i et tegneprogram, og i praksis anvendes ofte f.eks. MS Visio eller etlignende program til at opbygge en PVM.

Arbejdet med PVM’en har også til formål at virke som et pædagogisk kommuni-kationsmedium [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ådeer det nemt at overskue produktsortimentet. Produktmodelleringsopgaven gøressamtidig også mere synlig for de involverede personer.

2 Inden for konstruktionsteknik bruges betegnelsen “modul”, men inden for produktmodel-lering bruges flere betegnelser, hvoraf “klasse” bedst tydeliggør den tætte kobling til detobjektorienterede domæne.

3 Både stærke og svage aggregeringsrelationer angiver, at en klasse udgøres af flere under-klasser. For en stærk gælder, at underklasserne “lever og dør” med overklassen. Dvs. hvisoverklassen ikke eksisterer, kan underklasserne heller ikke eksistere. I modsætning hertilkan underklasserne i en svag aggregeringsrelation godt eksistere uafhængigt af overklassen.

41


4.3.2 Klassediagram

Resultatet af fase 3 er et klassediagram, som beskriver produktsortimentet. Op-bygningen af klassediagrammet er resultatet af de fem aktiviteter, som fase 3består af:

1. Find klasser og objekterIdentifikation af de klasser, som udgør produktsortimentet.

2. Identificér strukturerOpbygning af relationer mellem de fundne klasser.

3. Identificér temaerGruppering af klasser i temaer (letter overskueligheden).

4. Definér attributterHvad ved klasserne om sig selv?

5. Definér metoderHvad kan klasserne gøre? Herunder identifikation af bindinger.

Meget af arbejdet er allerede gjort i fase 2 under opbygningen af PVM’en. Herer mange klasser og deres relationer beskrevet, og denne information er et godtudgangspunkt for aktiviteterne ovenfor. Med rækkefølgen af aktiviteterne læggesop til, at der først fokuseres på at opbygge den overordnede struktur. Derefterdetaljeres modellen med opdeling i temaer og tilføjelse af attributter og metoder.

Idéen bag klassediagrammet er baseret på konceptet fra det objektorienterededomæne, og notationen følger standarden i UML, som blev gennemgået i af-snit 3.3 på side 23. Et eksempel på et klassediagram i en produktmodel er visti figur 4.6 på følgende side, og det fremgår, at ikke alle elementerne fra UMLanvendes i klassediagrammet, hvilket er typisk for produktmodellering.

Klassen er det centrale element i klassediagrammet og “. . . afspejler direkte til-Klasse

+AntalHjul()

-Diameter

Hjul svarende fysiske eller begrebsmæssige koncepter i et problemdomæne” [Hvam ogMortensen, 2002, s. 91]. En klasse beskrives ved dens attributter og metoder.

Riis skelner i den forbindelse mellem system- og produktviden, og i relation til enklasses metoder betyder det, at der med fordel kan laves en opdeling i system-metoder og produktmetoder [Riis, 2002, kapitel 2]. Systemmetoder beskriverSystemmetoder

klassens interaktion med de omgivende systemer og bruges også til opbygnin-gen af IT-systemet. Et eksempel kunne være en metode, der beskriver, hvordaninformationen i en klasse skal præsenteres i konfiguratoren eller overføres til el-ler fra virksomhedens ERP-system. Produktmetoder beskriver klassen i relationProduktmetoder

til produktmodellen eller livsfasesystemerne. Et eksempel her kunne være bin-dinger til andre klasser. Opdelingen betyder, at en metode entydigt skal kunneplaceres i en af kategorierne, og domæneeksperter skal udelukkende have adgangtil produktmetoderne.

Attributter beskriver klassens egenskaber, og det er muligt at definere attribut-Attributter

tens type, initialværdi, værdiinterval og enhed.

42


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 ogMortensen [2002] nævnes kun svage aggregerings-, associerings- og generalise-ringsrelationer, men Andersen og Jensen [2001] har i deres modeller herudoverogså anvendt stærke aggregerings- og implementeringsrelationer.

Et af hovedformålene med Andersen og Jensens projekt var at afdække, hvor-dan anvendelsen af modelleringsteknik fra det objektorienterede domæne (ogisæ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 klassediagrammetfor produktmodellering opsummeret.

Herudover anvendes i Andersen og Jensen [2001] et koordinatsystem, som ikke

) * + , - . / 0 1 1 ,2 / 0 1 1 , 3 2 / 0 1 1 , 45 62 / 0 1 1 , 7

8:9<;:=>?@

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 elleret skakbræt.

4.3.3 CRC-kort

Sammen med PVM’en blev CRC-kort introduceret og brugt til at beskrive klas-serne [Hvam og Riis, 1999; Mortensen et al., 2000]. Efter at Hvam og Mortensenintroducerede brugen af klassediagrammet til at beskrive produktsortimentet,er CRC-kortet naturligt blevet brugt til at detaljere beskrivelsen af klasserne iklassediagrammet. Meget af informationen på et CRC-kort kan derfor uddragesaf 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.

43


UML-element Anvendelse ved produktmodellering

Klasse Afspejler typisk et fysisk modul i et produkt. F.eks. et bilsædeeller en motor i en bil.

Metoder 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ædekan vælges ud fra valg af overflade (produktmetode, binding)

Attributter Beskriver egenskaber ved en klasse. F.eks. højde, farve eller vægt.

Aggregering, svag Part-of relation hvor objekterne eksisterer uafhængigt afhinanden (svag binding). F.eks. relation mellem en stol og ekstratilbehør (en stolevogn).

Aggregering, stærk Part-of relation hvor objekterne “lever og dør” med hinanden(stærk binding). F.eks. relation mellem stolesæde og stoleben.

Association “Kende til” relation til at sikre, at to klasser kender til hinandenseksistens og dermed kan kommunikere. F.eks. mellem stolesædeog en evt. polstring af sædet.

Grænseflade Relation mellem to klasser, hvor den ene fungerer somgrænseflade. F.eks. mellem to systemer; til at sammenkoble enfunktions- og strukturmodel for samme produkt. Andersen ogJensen [2001] brugte denne relation, men vurderede, atanvendeligheden i produktmodellering ikke var stor.

Generalisering Sammenkæder klasser i et nedarvningshierarki, hvor underklasserkan arve egenskaber og funktionalitet fra overklasser. F.eks. atbåde læder og stof er en slags polstring.

Klynger Samler klasser i enheder. F.eks. en samling af de klasser, derudgør stolen Syveren.

Temaer Opdeler komplekse diagrammer i overskuelige dele. F.eks.opdeling i konfigurerings- og beregningsdel.

Note Ubundet element til at tilføje valgfri noter.

Koordinatsystem Blev introduceret af Andersen og Jensen [2001], men i projektetblev koordinatsystemet tegnet på klassediagrammet i hånden. Detvar 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 inde-holde, 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) ertilføjet. Samtidig er det et eksempel på, at CRC-kortet kan tilpasses den aktuelleanvendelse.

Hver klasse har netop ét CRC-kort tilknyttet, og øverst er klassens stamoplys-Stamoplysninger

ninger samlet (ID, klassenavn, oprettelsesdato og forfatter).

Felterne under Samling og Generalisering placerer klassen i klassestrukturenved at liste over- og underklasser for de relationer, der forbinder klassen medandre klasser.

44


Klassenr. :

3107Klassenavn :

cSyverenDato :

09.08.2001Forfatter :

PVASamling Generalisering

Overdele : Overklasser :

cProdukt

Underdele :

cStoleskal (3107-1), cUnderdel (3107-3), cSkriveplade(3107-2), cTilbehør (3107-4)

Underklasser :

Mission :

Skitse :

Attributter :

eProdukt - Produktgruppe [#PStol]. Konstant

eDesigner - Designer af produkt [#DArneJacobsen]. Konstant

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

OCL :ACBACDACEA�F G

inv:cUnderdel(3107-3)->Select( oclType = cDrejefod ) implies cTilbehør(3107-4)->size = 0 and cSkriveplade(3107-2)->size = 0

cUnderdel(3107-3).cDrejefod->select( oclType = cDrejefod_Armlæn ) orcUnderdel(3107-3).c4Benet->select( oclType = c4Benet_Armlæn ) impliescSkriveplade(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ætteen 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. Derer 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. OCLer et formaliseret deklarativt sprog og er en del af UML. Sproget er udviklet forat kunne beskrive f.eks. begrænsningerne i et klassediagram på en måde, derfor 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 inter-aktion med omgivelserne. Dette kan f.eks. være i relation til brugeren af denkommende 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 ogattributter.

45

Kapitel 5

IT-understøttet

dokumentation


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øttelseaf dokumentationsprocessen. Gennemgangen vil omfatte CASE-værktøjer, somstøtter arbejdet med systemudvikling, og PDM-systemer som anvendes til au-tomatiseret håndtering af produktdata. Viden om CASE-værktøjer er primærthentet fra domænet vedr. udvikling af IT-systemer, hvorimod PDM-systemeranvendes 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 informa-tionssystemer. Op igennem tiden har CASE udviklet sig fra at betegne brugen afet simpelt tekstbehandlingsværktøj til at dække over den integrerede anvendelseaf IT-baserede værktøjer til støtte for aktiviteter i alle faser af projektlivscy-klussen.

5.1.1 Introduktion til CASE-værktøjer

Siden 1970’erne er der inden for systemudvikling blevet anvendt forskellige gra-fiske teknikker og strukturerede diagrammer som en del af dokumentationen.Forud for implementeringen af systemerne er blevet opbygget mere eller min-dre integrerede modeller, og strukturerede analyseog designteknikker har gjortdet muligt at håndtere udviklingen af systemer med stigende kompleksitet – ogstadig bevare overblikket. Men samtidig opstod hurtigt en begrænsning, idetde mange diagrammer og figurer var omstændelige og tidskrævende at vedlige-holde og ændre, efterhånden som projektet skred frem. I starten af 1980’ernebegyndte man at supplere simple tekstbehandlingsværktøjer med grafiske værk-tøjer til tegning af diagrammer og værktøjer til at støtte analyseog designfa-serne [Barclay og Padusenko, 2002].

De generelle tekstbehandlings- og tegneværktøjer blev hurtigt afløst af dedike-rede værktøjer til de forskellige opgaver, information i simple dokumenter blevafløst af strukturerede databaser, og op gennem 1980’erne og 1990’erne blev ud-viklet og lanceret værktøjer, der støttede og integrerede udviklingsprocessen frade tidlige analysefaser over design, kodning og test til ibrugtagning og vedlige-holdelse. Således findes der i dag CASE-værktøjer, der støtter op om arbejdet ialle 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 idet 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 CASE-værktøjer med henblik på at understøtte det stadigt stigende antal af frem-gangsmåder, der kom på markedet [Bennett et al., 1999]. Populariteten af ob-jektorienteret systemudvikling satte kun yderligere skub i denne udvikling, ogselv med anerkendelsen af UML1 som en fælles notation eksisterer der i daget meget stort antal af CASE-værktøjer – både til at understøtte objektorien-terede 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 in-gen af dem er særligt smalle. Det skyldes, at CASE-værktøjer dækker over etbredt 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 ennotationsstandard.

48


delsesområde støtter udviklingsarbejdet på en bestemt måde. CASE ses i litte-raturen anvendt både for Computer Aided Systems Engineering og ComputerAided Software Engineering, men indholdet bag begge betegnelser er så sam-menfaldende, at jeg i denne rapport har valgt at sidestille dem. Som i Kirkby ogKjæ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 integreretinformationssystem.

I Hogan [1999] og CMU [2001] anvendes næsten enslydende definitioner, somsynes 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] karakteriseretCASE-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 informations-

systemet.

[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 definitio-ner, der opdeler den brede vifte af CASE-værktøjer. CMU [2001] nævner detre mest almindelige af disse opdelinger, hvoraf de to direkte baseres på CASE-værktøjernes anvendelse i projektlivscyklussen. Disse to vil kort blive introdu-ceret 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 afprojektlivscyklussen (såsom kravspecifikation, analyse og design). Inden for detobjektorienterede domæne vil disse værktøjer støtte opgaverne inden for opbyg-ning af bl.a. brugsmønsterdiagrammer, klassediagrammer og sekvensdiagram-mer. Med brug af værktøjerne vil det være muligt at automatisere arbejdetog 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- ogkollaborationsdiagrammer, da de indeholder nøjagtig samme information – blotvist på to forskellige måder. I den situation vil et CASE-værktøj automatiskkunne generere det ene diagram ud fra det andet.

Den anden kategori dækker over værktøjer, der anvendes i de senere faser i pro-jektlivscyklussen. Typisk vil det være værktøjer til kodegenerering, fejlfindingog testning. Ved at anvende et CASE-værktøj til kodegenerering på baggrundaf den opstillede model opnås en kode af høj kvalitet, der for det første er hurtig

49


HJILKNM OLPRQ P

SCTVU W XNY[Z]\ ^V_`RYV\ ^V\badc�XVêW

fLg h ^�i�jk�l�YeW m \�U \

n�YeW U XVY�j U cel oj ^�\ j

p qsr[M tRqutNI�v K�v Q w[I

Z]\ U l�xdyzfbfb{V|`]k]|]}~Yel X o cV�zfbf� � c�xV� Y�aNa[U l xW Yel�xeT YVxV^�\

Z�\ ^V��\ YVj U \ � YVi j U cVlTV\ YVgVU W U j mN��Rkj ^V\ j \

��tRPLQ �dI

�]^V\�U xelbiVW Y�\ \ ê\ �XV^V� U l�^NYej j � U geT�j ^�\Yel�X�ad^Vj ��cVXe\

SCTVU W XNcVg h ^Vi jYelVXNX�mVl�Y�adU iadc�XVêW

S�T�U W XdT�\ ^V�U l�j ^V� � YVi ^�YVlVX� � cVj c�j m � ^

Z]\ ^V�z\ Y�j U \ � YVi j U cVlj ^V\ j �VT \ YVgVU W U j mbj ^V\ j �Yel�Xd�Rk�j ê\ j

p v tR� K�v Q w[IKNIL�� tL�LPRt

�Lwb��t��HJ�~�[� �b��v �R� tR�P]v �Nv v tR�~�btR�V� � �

¡rNrNtL�[�~H¢�¡�� L�s�e��v �� t��P]v �Nv v t��LtL�V� � �

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ængmellem den designede systemmodel og den resulterende kode [Hogan, 1999].

Opdeling i Upper- og Lower CASE-værktøjer var helt klar for tidlige CASE-værktøjer [Bennett et al., 1999]. Værktøjerne var afgrænsede i deres funktio-nalitet og indeholdt kun funktionalitet til understøttelse af opgaver inden foren meget begrænset del af projektlivscyklussen (f.eks. tegning af statiske UML-diagrammer). Op gennem tiden har CASE-værktøjer udviklet sig til at omfattehele pakker (suiter) af produkter, der er mere integrerede og understøtter akti-viteter i mange (eller alle) af projektets faser. Disse pakker af produkter kaldesIntegrated Computer Aided Systems Engineering (I-CASE) og vil ikke kunneplaceres entydigt i en kategorisering i Upper og Lower CASE-værktøjer, mensnarere 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øtteraktiviteterne i enten en begrænset del af projektlivscyklussen eller inden for etbegrænset domæne. Et eksempel kunne være et programmeringsværktøj ellerværktøj til indsamling af krav.

50


£¥¤§¦�¨ ©¢ª¡«

¬u«¡ª� ®¯¤

° ±³²¯¨ «�±´«§¤�µ�«~¶C ¤J®

·]¸L¹�ºz»�¼�¹�º�· ½�¾�¿]º�À À º]Á Â Ã�Ä·�Å�ÆeÇ ºCÈ�É ¼�Ã�¼�À Êz¹�º·zËL¼]À Â ¿]º�Á Â ÃzÄzÌ É º�¹�É

·]ÍLº�¹CÂ ÄRÃ§È�À ¼�¹z¹�º]ÁR½�ÎCÏ·�Å�Ð]ÆzÊzÄ¢½§¾�¿]º�À·�Å�Ð]ÆzÊzÄ�Ñ¡¸bÒ�¾�Ä¯Ð�Á ¾CÉ ¾zÉ ÊCÐ�º·]¸L¿CÓ Ô]Á�É º�¹�É

·]ÕRÁ ¾CÄ]Á ¼C½¢½~ºCÁ Â Ã�Ä·]ÖRÎz¼CÀ Â É ºeÉ ¹�¹�Â ÈzÁ Â Ã�ÄR×�É º�¹eÉ

Ø�¶�Ù�Ú�«§ÛNµ�ª[µV©¢¶��¤�®

Ü ¾RÁ Â ¹�¾RÃzÉ ¼�À É�ÝRÞ�ßbàábâLãNä]å æ�ç¢è é ê ë�ì�ê í î�ïdï�åð]ñVð î ò�ó ô¡õ�ö¡ï�ïdå ÷�ôzó�í ö ñ

ËbºCÁ É Â ÈV¼]À ÉLÝLÞbß�àábâLãNä]å æ�ç¢è é ê ë�ì�ê í îõ�ø�ù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 om-råde og understøtter aktiviteter i flere faser af projektlivscyklussen eller i fleredomæ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æremeget forskellige. Ses på brugerne af f.eks. et vertikalt værktøj, vil de typiskhave en meget ens profil bl.a. begrænset af deres faglige domæne. Brugerneaf 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 medprojektet.

5.1.2 Anvendelse af CASE-værktøjer og metodologier

Mange virksomheder har anerkendt fordelen ved at anvende en metodologi tilsystemudvikling. I forbindelse med systemudvikling har Whitten et al. [2001]defineret en metodologi som

. . .A very formal and precise system development process that defi-

nes [. . . ] a set of activities, methods, best practices, deliverables, and

automated tools . . .


Ved at lægge systemudviklingen i faste rammer med anvendelsen af en meto-dologi 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 meto-dologi sammenlignes med en “værktøjskasse”, hvor man har samlet de bedste

51


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åledesogså 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 hargjort, at kombinationen anvendes i velsagtens alle virksomheder, hvor der arbej-des seriøst med udvikling af informationssystemer. Men ifølge en undersøgelsefra IBM [Guinan et al., 1997] er samspillet også en nødvendighed. Undersøgelsenviste bl.a. at “. . . for teams with well-structured processes, use of tools enhan-

ced the process and improved performance”, men lige så vigtigt at “For teams

with more informal or ad hoc processes, tool use abetted chaos”. Anvendelsenaf CASE-værktøjer alene er således ikke en silver bullet, men anvendelsen afCASE-værktøjer som støtte til i forvejen formelle og strukturerede fremgangs-må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 “selv-gjorte” (baseret på en virksomheds erfaringer gennem årene) eller rent kom-mercielle, hvor en virksomhed som sin kernekompetence designer metodologierbaseret på forskning og erfaringer.

Et eksempel på det sidste er Rational Unified Process (RUP) fra RationalSoftware, som er beregnet på objektorienteret systemudvikling [Kruchten, 1998].RUP består i sin essens “blot” af en beskrivelse af den designede proces til udvik-ling af informationssystemer. Arkitekturen bag RUP beskriver og støtter udvik-lingsprocessen i to dimensioner; i forhold til organisationen og i forhold til tiden(projektlivscyklussen), men lægger kraftigt op til, at man tilpasser metodologientil den enkelte situation. RUP er samtidig et eksempel på en metodologi, somer fuldstændigt understøttet af og integreret med et CASE-værktøj (RationalSuite Enterprise).

På trods af den høje pris på kommercielle metodologier vælger mange virksom-heder 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 billigereend 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østeerfaringerne fra udviklingsarbejdet og tilpasse metodologien. Herudover er enaf de helt store fordele, at kommercielle metodologier ofte er understøttet afeksisterende 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åndtereudviklingen af selv et mindre informationssystem. Og selv hvis én person kunneoverskue systemet og alle detaljerne, så ville det være svært for vedkommendeat dele denne viden med de andre personer, der var tilknyttet udviklingen.

52


Det er et par af årsagerne til, at den mest almindelige måde at gribe udvik-lingsopgaven an på er at opbygge modeller forud for den egentlige opbygning ogdermed drive projektet frem baseret på modellerne. Man taler da om modeldre-

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


og knytter et par kommentarer til projektlivscyklussen for modeldrevet udvik-ling, som har relevans for produktmodellering [Whitten et al., 2001, s. 94ff]:

- Størstedelen af arbejdet placeres i de tidlige faser af projektet med henblikpå at skabe et solidt fundament forud for det videre arbejde. Baggrundenfor dette er, at projekter har en tendens til enten at være store eller hurtigtblive det, og med anvendelse af selv simple systemmodeller kan projektetsomfang visualiseres.

I relation til produktmodellering svarer det til at anerkende vigtighedenaf at få opbygget en god model af produktet startende med en grundigopbygning af PVM’en. Med basis i modellen opnås overblik over produktetmed hensyn til bl.a. strukturel opbygning og variantskabelse, hvilket eressentielt for den senere implementering i en konfigurator.

- I de fleste modeldrevne metoder lægges op til, at kravene dokumenteresi en logisk model; dvs. en model der er uafhængig af den endelige imple-mentering.

Inden for produktmodellering sker dette ved, at produktet modelleres iPVM og siden hen i klassediagrammet vha. UML-notationen. Med dennedokumentation kan produktmodellen i princippet implementeres i en vil-kårlig konfigurator2.

Fordele ved modeldrevet udvikling

Som en konsekvens af anvendelsen af modeldrevet udvikling er resultatet af hverfase i projektlivscyklussen, at der produceres systemmodeller, som siden henfungerer som dokumentation for implementeringen. Generelt resulterer det i, atkravanalysen bliver mere tilbundsgående og bedre dokumenteret. I relation tilproduktmodellering 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 ud-vikling 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 objektorientereteller konventionel.

53


Til at udfylde dette gab bruger systemanalytikere (business- eller systemana-

lysts) modeller til at visualisere de indsamlede krav: Over for brugerne for atverificere deres udsagn og over for udviklerne for at beskrive kravene. På sinvis er anvendelsen af modeldrevet udvikling således helt i tråd med det gamlemundheld om, at “et billede kan sige mere end tusinde ord”. Et eksempel er an-vendelsen af brugsmønsterdiagrammer til at beskrive forskellige brugergruppersinteraktion med (dele af) systemet (se figur 5.3).

ü ý þ ÿ �

�� ÿ �

þ � � � ÿ �

�� ÿ � �

ü ý þ�� ÿ �

�eÿ � � � þ � � � � � ÿ �

ü �� ÿ � � � � � ÿ � ��

þ � � ��þ � ÿ]ÿ ��þ ÿ �

Figur 5.3: Eksempel på anvendelse af modeller som et fælles sprog: Et brugsmønsterdia-

gram i UML-notation

Ud over at virke som et fælles sprog iblandt projektets medlemmer vil anven-delse af en given modeldrevet fremgangsmåde også ensarte den anvendte doku-mentation. 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 denanvendte notation. Det vil således være relativt let for alle medarbejdere atsætte sig ind i et andet projekt og forstå dokumentationen. En yderligere fordeler, at eksisterende løsninger vil kunne bruges mere direkte i et nyt projekt, dadokumentationen er den samme.

I forbindelse med produktmodellering trækkes også på anvendelsen af modellersom fælles sprog, især med anvendelsen af PVM’en i de tidlige faser af projekt-livscyklussen. Som nævnt i 4.3.1 på side 40 er en af de væsentligste fordele vedbrugen af en PVM, at både domæneeksperter og udviklere kan forstå indholdetaf diagrammet og dermed strukturen af produktet.

Endnu en fordel ved modeldrevet udvikling, som skal nævnes her, er den basaleegenskab hos en model til at fastholde information. Varigheden af et projekt haren tendens til at vokse i takt med projektets størrelse, og information indsamleti projektets start er derfor nemt glemt senere i projektet – især hvis det kuneksisterer som tykke dokumenter. Ved at bruge modeller som dokumentationlettes overblikket, og information fastholdes under hele projektet. Med modellersom dokumentation er det tilsvarende nemt for alle medlemmer af projektet (oglige så vigtigt: for nytilkomne) til enhver tid at danne sig et overblik, finde detrette sted og finde relevante detaljer frem.

54


Ulemper ved modeldrevet udvikling

Desværre vokser træerne ikke ind i himlen, og anvendelse af modeldrevet udvik-ling 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 sekonkrete resultater. Som nævnt i afsnit 5.1.2.2 på side 52 lægges en stor del afarbejdet i de tidlige analyseog designfaser med henblik på at indsamle og ana-lysere al nødvendig viden forud for implementeringen. Formålet er naturligvisat implementere systemet korrekt første gang og undgå fordyrende ændringerog omfattende rettelser, men nogle personer har svært ved at forestille sig detkommende 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 bygningud fra arkitektens tegninger.

Som konsekvens heraf opbygges ofte flere prototyper igennem projektet, hvor-med man kan teste forskellige aspekter af det endelige system (f.eks. placeringaf knapper mv., svartider på databaseforespørgsler osv.). Det svarer til, at ar-kitekten laver papmodeller af den kommende bygning som supplement til teg-ningerne. En af grundstenene i objektorienteret systemudvikling er af sammegrund iteration og anvendelse af prototyper (se figur 5.1 på side 50).

Resultatet af det øgede fokus på analyseog designfaserne er, at det umiddelbartkan 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 hardog mere hårdtslående konsekvenser, idet et mangelfuldt forarbejde meget oftebetyder, 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 ogmedtaget fra starten. Det er en klassisk faldgrube, som mange virksomhedergø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 tek-nikker som inden for objektorienteret udvikling af IT-systemer. Erfaringer medarbejdet har vist, at dokumentationen, som er kraftigt inspireret af UML, fun-gerer godt og udgør en konsistent dokumentation. Erfaringerne viser dog også,at dokumentationsarbejdet er omstændeligt og udgør en stor del af den samledearbejdsindsats 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øjertil at automatisere og understøtte arbejdet, og med den store lighed vil det væreoplagt at trække på de samme erfaringer, som CASE-værktøjernes udvikling ermanifestationen af.

55


5.1.3.1 Funktionalitet i CASE-værktøj

Bennett et al. har lavet en gennemgang af, hvorledes et moderne I-CASE-værktøj understøtter aktiviteterne i projektlivscyklussen med opdeling i to over-ordnede kategorier: diagrammer og programmelkonstruktion [Bennett et al.,1999, s. 56ff]. Mange af dem er direkte relevante for produktmodelleringsdo-mænet, og som oplæg til den videre analyse af kravene til et kommende do-kumentationsværktøj vil jeg nedenfor gennemgå punkterne og relatere dem tilproduktmodellering.

Diagrammer

En stor del af en systemmodel består i de fleste tilfælde af diagrammer – uansetvalg af metodologi. Det er der ikke noget nyt i, men med muligheden for atoprette, redigere og sammenkoble diagrammer på en computer opnås så storefordele, at ethvert moderne CASE-værktøj indeholder funktionalitet til at un-derstøtte denne opgave. Funktionaliteten dækker

Syntaktisk korrekthed Baseret på syntaksen for de enkelte diagrammer sør-ger CASE-værktøjet for, at kun lovlige symboler bruges, og at de sammenkædespå en lovlig måde. Dette garanterer dog ikke, at indholdet af diagrammet givermening og afspejler det ønskede. Et CASE-værktøj til produktmodellering børsåledes sørge for, at de rigtige streger og symboler tegnes, når der i PVM’entilføjes en underklasse til en eksisterende klasse.

Dataleksikon Med et stort komplekst system og mange involverede medarbej-dere er der behov for at have et samlet sted, hvor man én gang for alle definerernøglebegreber for systemet. Behovet kan være lige stort, hvad enten der er taleom simple attributter eller mere uhåndgribelige begreber, da tvetydighed hur-tigt leder til fejl. I forbindelse med produktmodellering er det vigtigt at have enutvetydig definition og beskrivelse af elementerne (f.eks. klasser og attributter).Ofte har elementerne kryptiske navne, som det kan være svært at huske, ogmed en voksende model med flere medarbejdere tilknyttet vil et dataleksikonforbedre overblikket og dermed arbejdet markant.

Konsistens og fuldstændighed Mange metodologier understøtter mulighe-den for at bruge forskellige diagrammer til at vise forskellige aspekter af (deleaf) systemet, og samtidig “kræver” nogle metodologier, at visse diagrammerskal eksistere og være fuldt dokumenterede. Et eksempel er anvendelsen afkollaboration- og sekvensdiagrammer i UML, ligesom IDEF0 foreskriver visseregler, f.eks. ICOM-reglerne3. I et sådant tilfælde bør et CASE-værktøj kunnesikre, at diagrammerne er konsistente og veldokumenterede (i dataleksikonet).I modsat fald bør værktøjet kunne generere en rapport med angivelse af mang-lerne. 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, atalle Input ’s, Control ’s, Mechanism’s og Output ’s, der går ind eller ud af en aktivitet skalbruges på den underliggende detaljering. Læs mere i CSL-NIST [1993]

56


kan overvejes at lade CASE-værktøjet sikre konsistensen mellem CRC-kort ogdet tilhørende diagram (PVM eller klassediagram).

Navigation i koblede diagrammer Des mere komplekse systemerne – ogdermed også modellerne – bliver, des mere nødvendigt er det at sikre en sim-pel navigation imellem diagrammerne og nem adgang til relevante data. Vedf.eks. at dobbeltklikke på et diagram på et givet abstraktionsniveau kan CASE-værktøjet automatisk åbne det underliggende, mere detaljerede diagram elleralternativt oprette et. For produktmodellering gælder de samme betragtnin-ger som for punktet ovenfor, da der kun anvendes relativt få diagrammer. Detkunne dog overvejes, hvordan navigationen kan lettes ved f.eks. at se på kob-lingen mellem et diagram og de tilhørende CRC-kort. Ligeledes kan det medfordel vurderes, hvorledes eksterne dokumenter skal kobles til dokumentationeni produktmodellen.

Lagdeling For at lette arbejdet med store komplekse systemer lægger mangemetoder op til anvendelse af lagdeling. Et eksempel på lagdeling er, at man kanarbejde med diagrammer på forskellige detaljerings- eller abstraktionsniveauer– præcis som der findes landkort i forskellig målestok. IDEF0 er f.eks. bygget opomkring denne filosofi. Et CASE-værktøj bør understøtte anvendelse af dennelagdeling og gøre det let at navigere mellem de forskellige lag. Inden for pro-duktmodellering benytter man sig p.t. ikke af lagdeling, men det bør alligevelvurderes, hvorvidt man med anvendelse af et CASE-værktøj får automatiseretprocesserne og dermed åbner op for nye muligheder, så anvendelse af forskelligelag kunne blive interessante.

Sporbarhed For at lette arbejdet med udviklingen og især vedligeholdelsen afsystemet skal det være muligt at spore krav fra analysedokumentationen, gen-nem designdokumentationen og frem til den endelige kode. Hvis et krav ændrersig, vil det dermed være let at finde frem til den kode, der er berørt af ændrin-gerne. Kravene i forbindelse med opbygning af en produktmodel dokumenteres iPVM’en, og sporbarhed i den sammenhæng vil da bestå i at kunne spore struk-turen og indholdet af PVM’en over klassediagram (med CRC-kort) til den en-delige implementering i en konfigurator. Ofte sker ændringer på produktniveau(en variant udgår, eller en komponent bliver redesignet), og med sporbarhedi produktmodellen bliver det nemmere at ændre design og implementering, såvalgmulighederne i konfiguratoren afspejler produktændringen. Det bør derforovervejes, hvorledes CASE-værktøjet skal give mulighed for sporbarhed, hvilketindebærer overvejelser om, hvordan elementerne i dokumentationen skal sam-menkobles.

Rapportgenerering Des mere komplekst et system bliver, des mere informa-tion indeholder det. Det vil ikke give mening at bruge tid på at opsamle infor-mationen og lagre det i et CASE-værktøj, hvis det ikke var tilsvarende nemt attrække informationen ud igen. Et CASE-værktøj har derfor ofte fleksible mulig-heder 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


eller produktmodeller gør ingen forskel, og det bør derfor overvejes, hvordanet 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 informatio-nen skal vises. I den forbindelse kan også overvejes, hvordan rapportgenereringenskal 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 detvære muligt at kunne simulere, hvordan systemet vil opføre sig inden for noglebegrænsede områder. På den måde kan man som designer få et indtryk af kon-sekvenserne 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å ettilstandsdiagram og valg af attributværdier. I forbindelse med produktmodelle-ring er der tilsyneladende ikke gjort mange tanker om anvendelse af simulering,men da konfiguratorer er så grundlæggende forskelligt opbygget, bør det under-søges, om valget af konfigurator har indflydelse på forløbet af en simulering. Omsimulering er anvendelig inden for produktmodellering, vil derudover kræve endybere analyse af behovet, resultatet og dokumentationens karakter. Diagram-merne 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 forvurderingen af systemets succes. At kunne vurdere ydelsesevnen og konsekven-serne 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. Produktkonfi-guratorer er meget forskellige i deres opbygning, og de adskiller sig også frahinanden i, hvorledes den endelige konfigurator kompileres. Det vil derfor væresvært at vurdere ydelsesevnen baseret på produktmodellen alene, og en ydel-sesanalyse vil derfor næppe være anvendelig i et dokumentationsværktøj forproduktmodellering.

Programmelkonstruktion

Flere og flere CASE-værktøjer understøtter muligheden for at automatisere ogintegrere overgangen mellem designfasen og implementeringsfasen og dermedhø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 oghurtigere at producere fungerende (del)systemer, og for det andet er koden merefejlfri og i overensstemmelse med designet. Herudover bliver det nemmere at im-plementere ændringer, idet et ændret design nemt kan overføres til fungerendekode. Der er næppe to produktkonfiguratorer, som anvender samme sprog tilimplementering – hverken i deres underliggende produktmodel eller i bindinger.Derfor synes det umiddelbart som en omfattende opgave at understøtte kode-generering til markedets konfiguratorer, men potentialet og fordelen er så stor,at det bør undersøges, hvorledes man kan udnytte funktionaliteten, måske medanvendelse af et neutralt mellemliggende filformat.

58

5.2 PDM-systemer

Vedligeholdelsesfunktioner Mange CASE-værktøjer understøtter også faserneefter implementeringen af systemet. Som en af de primære funktionaliteter næv-nes reverse engineering, hvor værktøjet kan opbygge en model baseret på eksi-sterende kode. Dette kunne umiddelbart være en værdifuld egenskab for et kom-mende dokumentationsværktøj, men som nævnt ovenfor er de anvendte sprog ikonfiguratorerne meget forskellige, og at understøtte f.eks. reverse engineeringfor 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åndteringaf utrolige mængder information og opretholdelse af mange forretningsgange.Denne erkendelse er i sig selv ikke ny, men først med tilgængeligheden af kraf-tige computere er man for alvor begyndt at anvende informationssystemer tilat understøtte og automatisere processerne og håndtere adgangen til informa-tionen.

5.2.1 Introduktion til PDM-systemer

Så længe der har eksisteret virksomheder, der har udviklet produkter, har dereksisteret et behov for at kunne styre de relaterede processer og de mange infor-mationer, som knyttes til produktet. Begrebet kaldes PDM og er sammen medPDM-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ældeblev produktstrukturer også understøttet, men systemerne var ikke fokuseretpå at skulle integreres med virksomhedens andre informationssystemer [Pikosz,1997].

Kravene til en kortere time-to-market og forbrugernes ønske om unikke vari-anter har øget virksomhedernes interesse for PDM-systemer og sat mere gang iudviklingen [Pikosz, 1997, s. 1]. Som det fremgår af definitionen, udgør brugerneaf et PDM-system en broget skare bestående af alle de personer, der har nogetmed produktet at gøre, og PDM-systemer understøtter heller ikke kun arbejdeti udviklingsfasen, men arbejdet i alle faserne af produktets livscyklus.

Under arbejdet med et produkt genereres en stor mængde information af megetforskellig karakter. Det kan f.eks. være kravspecifikationer, CAD-tegninger, test-og analyseresultater eller styklister. Informationen findes i dag (i modsætningtil 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


�� "!� "� $#$ "%��

&('�)�� * ',+ + ��* �"!��.- / + ��*

0.1�1$+ / 2" "� / '�)$%�#�* 3�4��* �5 6�7 8 5"6"9(: ; < = > ? @ := A > B C(D < E F E ; A <(D E G HI,JK��L #�* 3$4��* �M A N O > D P P ; Q D(F < = N DF < R D < = D P O D O A C�N S = D N

T�U V W X�Y Z�[ V \ Z�U

] ^ _ ^ ` a b c] ^ _ ^ ` a b cd b�e _ f b�a

] ^ _ ^ ` 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 PDM-system er at knytte alle disse dokumenter sammen og give brugerne mulighedfor at genfinde dokumenterne. Strukturen er skitseret i figur 5.4.

Af figuren fremgår det, at der i PDM-systemet indgår en metadatabase. Meta-data er “data om data”, og i et PDM-system er der til hver ressource knyttet enrække informationsfelter indeholdende f.eks. forfatter, titel, ændringsdato, be-skrivelse, filnavn, filformat osv., og det er på baggrund af disse data, brugernefinder frem til dokumenterne. Et PDM-system gemmer således to typer data:produktdata, genereret af de forskellige applikationer (CAD-systemer, tekst-behandling 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, ognår en bruger ønsker at tilgå et givet dokument, bruger PDM-systemet doku-mentets metadata til at bestemme typen af dokumentet. På baggrund af typenbeder PDM-systemet en passende applikation om at åbne dokumentet for bru-geren. Således er et PDM-system også fleksibelt mht. hvilken hardware og hvilkeoperativsystemer, der anvendes.

5.2.2 PDM-systemer og produktmodellering

I modsætning til tidlige PDM-systemer er et af de centrale krav til et modernePDM-system, at det kan håndtere produktstrukturer. Denne funktionalitet givermulighed for at overskue, hvordan et produkt er sammensat af forskellige kom-ponenter, og hvordan der kan eksistere forskellige varianter af komponenterne,som dermed skaber varianter af produktet. For hver komponent skal systemetendvidere kunne styre historikken og håndtere revisioner.

Især denne funktionalitet gør PDM-systemer interessante i relation til produkt-modellering, da en sådan produktstruktur har mange ligheder med PVM’en fra

60

5.2 PDM-systemer

produktmodellering (se afsnit 4.3.1 på side 40). CIMdata har lavet en oversigtover, hvilken funktionalitet et PDM-system bør have for at kunne understøtteenhver produktudviklingsproces [CIMdata, 1997]. Som optakt til den efterføl-gende analyse vil jeg i det følgende gennemgå disse punkter med henblik på atrelatere dem til produktmodellering og kravene til et kommende dokumenta-tionsværktøj.

5.2.2.1 Funktionalitet i PDM-system

Funktionaliteten i et PDM-system er i CIMdata [1997, s. 8] opdelt i to over-ordnede grupper som vist i 5.5. Brugerfunktionerne dækker den funktionalitet,som udgør brugergrænsefladen til PDM-systemet. Systemfunktionerne dækkerover alle de opgaver, der udføres “under overfladen”, og de fungerer derved somstøttefunktioner for brugerfunktionerne og muliggør integration til eksterne sy-stemer.

g Styring og kontrol af databaseg Styring af processer og arbejdsgangeg Styring af produktstrukturg Klassifikationg Programstyring

Brugerfunktioner

PDM-system

Eksterne systemerFilsystemer,

brugerapplikationer,ERP-systemer etc.

g Kommunikation og notifikationg Transport af datag Konvertering af datag Illustrationsserviceg Systemadministration

Systemfunktioner

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åndte-ringen af dokumentet. For dokumenter i den elektroniske bankboks ydes en højsikkerhed, og systemet kan styre, hvem der har adgang til hvilke dokumenter.Disse dokumenter kan ikke tilgås uden om PDM-systemet. I relation til pro-duktmodellering kan adgangsstyringen være essentiel for at sikre mod fejl, og atkun de rette personer kan ændre i modellen. Ved at lade håndteringen af filerneske gennem systemet kan også laves en omfattende logning af aktiviteterne (æn-dringer mv.), som kan være central for dokumentationen. Sikkerhedsaspektet iat gemme dokumenter i en elektronisk boks kan måske i nogle tilfælde være afinteresse.

Styring af processer og arbejdsgange Ud over at være et stærkt, men pas-sivt dokumenthåndteringsværktøj kan et PDM-system også være interaktivt ogagere baseret på foruddefinerede processer og arbejdsgange. Inden for produkt-modellering 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 derfindes en defineret sekvens af gennemsyn og nødvendige godkendelser.

61


Styring af produktstruktur For at give et overblik over den kompliceredesammensætning af et produkt kan et PDM-system understøtte konfigurationaf produkter samt styring af styklister. Med nedbrydning af et produkt i ek-sempelvis undersamlinger, moduler og komponenter opnås et godt indblik iproduktstrukturen, som kan styrkes af en grafisk visning af strukturen i stilmed en PVM. Synsvinklen på produktstrukturerne kan ofte ændres, så struktu-ren vises med fokus på forskellige fagligheder (f.eks. produktion, konfiguration,vedligeholdelse, pakning etc.). Til hvert objekt i produktstrukturen kan knyttesrelevante dokumenter fra PDM-systemet, og det er dermed let at finde al rele-vant information for et givet objekt. Denne funktionalitet er helt essentiel foret dokumentationsværktøj til produktmodellering og kan være til stor inspira-tion for arbejdet med PVM’en og klassediagrammet, hvis ikke overføres næstendirekte.

Klassifikation For at forbedre søgefaciliteterne og mulighederne for at gen-finde information kan man ofte i et PDM-system klassificere standardobjekter(produktdele, processer og anden information). Med kategoriseringen kan mansammenkæde relaterede objekter, og der lægges således op til mere genbrug ogmuligheden for oprettelse af et “bibliotek”. Klassificeringen af ensartede objekterer helt i tråd med den objektorienterede tankegang bag produktmodelleringennævnt i kapitel 3 på side 19. Sammen med andre objektorienterede aspekterskal klassificeringen inddrages i overvejelserne om, hvorledes en grundlæggendeobjektorienteret produktmodel skal udformes og siden hen implementeres i endatabase.

Programstyring “Program” skal i denne sammenhæng forstås som en plan foret antal handlinger, der leder mod et defineret mål, og med denne funktionalitetlægges op til, at et PDM-system skal understøtte visse projektstyringsopgaver(f.eks. nedbrydning af processerne i en Work Breakdown Structure (WBS) ogressourcestyring). I forbindelse med produktmodellering er der naturligvis behovfor styring af projektet som helhed, men til denne opgave findes utrolig stærkededikerede værktøjer som f.eks. Primaveras SureTrak og Microsofts Project 4.

Systemfunktioner

Kommunikation og notifikation Med e-mail kan brugerne af et PDM-systembindes endnu tættere sammen på tværs af deres geografiske placering. Et kom-munikationsmodul kan konfigureres til at give besked om f.eks. vigtige hændel-ser, eller når der er behov for handling. Forskellige hændelser kan sættes til atigangsætte udsendelsen af en meddelelse automatisk (f.eks. om at en ny ver-sion af et dokument netop er tilgængeligt). I produktmodelleringssammenhængkan dette være utroligt anvendeligt, da arbejdsprocessen er præget af, at flerepersoner arbejder sammen og er afhængige af hinandens arbejde. Ved at kunneintegrere produktmodelleringsarbejdet med kommunikation og notifikation kanspares 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. Navn-givning af filer behøver dermed heller ikke at ske i overensstemmelse med detpågældende filsystem, og man kan således benytte vilkårlige navne. Med ope-rativsystemer som f.eks. hele Windows-familien er navngivningen dog ikke læn-gere et problem, og generelt er placering af filer ikke det store problem medintegrationen af netværksressourcer i nutidens brugervenlige operativsystemer.Efterhånden som projekter vokser til en vis størrelse, kan det dog være gavnligtkun at have ét centralt sted (omend i virtuel form), hvor alle relevante data kanfindes, og i forbindelse med produktmodellering bør det derfor overvejes, hvordata 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ød-vendigt at kunne konvertere data fra et format til et andet for at kunne an-vende den samme information i flere applikationer. Med et PDM-system kansystemadministratoren foruddefinere, hvilke konverteringsprogrammer der skalbruges til at konvertere mellem to formater; det skal brugeren ikke bekymresig om. Konverteringsprogrammerne er ikke nødvendigvis en integreret del afPDM-systemet, men da PDM-systemet kender formatet (fra metadataene), kanet eksternt program kaldes. I forbindelse med dokumentationsarbejdet inden forproduktmodellering arbejdes ikke med et større antal dataformater, og megetaf informationen vil blive genereret og anvendt internt i systemet. Det er derforumiddelbart tvivlsomt, om det kan svare sig at understøtte automatisering afkonverteringsarbejdet. Til gengæld kan det overvejes, hvorledes informationen isystemet kan udveksles med eksterne systemer.

Illustrationsservice Generelt bliver billeddata håndteret på samme måde somal andet data i et PDM-system. Men nogle systemer understøtter udveksling afdata som billeder uanfægtet deres originale format (f.eks. CAD-tegninger oglign.). På den måde kan ledere og andre ikke-tekniske medarbejdere deltage igennemsyn og vurdering af design på samme måde, som havde de fået tegnin-gen 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 relevantedeltagere i processen. Under arbejdet med produktmodellering udveksles mangekommentarer til forskellige designforslag, og især PVM’en fungerer som et cen-tralt kommunikationsmedium – på papir. Anvendelsen af et “virtuelt papir” somnæ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 administrationsmodu-let kan systemet konfigureres, brugeradgang styres, og datasikkerheden holdesi top. Ethvert informationssystem har brug for et administrationsmodul, hvorsystemet kan tilpasses situation og konfigureres, og et dokumentationsværktøjfor produktmodellering vil ikke være nogen undtagelse. Det skal i den sam-menhæng overvejes, hvordan systemet skal opbygges i relation til fremtidigeudvidelser og opdateringer, og på hvilke områder det skal være muligt at til-passe systemet til situationen. Graden af fleksibilitet vil være en afvejning af,

63


hvad der skal kodes direkte ind i systemet (ofte nemmere at implementere, mensvært at vedligeholde), og hvad der skal være mere modulært opbygget (sværereat 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-systemerog relationen til et kommende dokumentationsværktøj for produktmodellering,er der mange ligheder. Det vil derfor være relevant forud for arbejdet med opbyg-ningen af en kravspecifikation for et sådant værktøj at se på, hvilke mulighederog begrænsninger der er ved at anvende et PDM-system i produktudviklings-processen.

Pikosz og Malmqvist har som del af et forstudie til et større forskningsprojektmed henblik på en reduktion af produktudviklingstiden undersøgt, hvilke mu-ligheder og begrænsninger der er ved anvendelse af PDM-systemer i produktud-viklingsprocessen [Pikosz og Malmqvist, 1996]. Udgangspunktet er at forbedrekommunikationen blandt de involverede medarbejdere, hvilket ofte kaldes inte-

greret 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 angivelseaf deres respektive ekstremer. Pikosz og Malmqvist har beskrevet PDM-systemeri forhold til hver af de fem dimensioner, og i figur 5.6 har jeg opsummeret resul-tatet ved at markere PDM-systemers “score” på de fem skalaer (mørk trekant).

Sen lancering afkomplet information

Tidlig lancering afforeløbig kommunikation

Sekventiel(faseopdelt)

Dokumenter,IT-netværk

Grupperet(samling af data)

Unilateral(envejs)

Overlappende(samtidig)

Ansigt til ansigt(høj båndbredde)

Fragmenteret(stykke for stykke)

Bilateral(feedback)

Rækkefølge af aktiviteter

Informationsrigdom

Frekvens af informationsoverførsel

Kommunikationsretning

Timing af informationsflow

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 kommuni-kation af fragmenteret information (3. og 4. dimension) [Pikosz og Malmqvist,1996, s. 6]. Det bunder i, at alle – afhængig af adgangsrettigheder – har adgangtil informationen, og at systemet automatisk arkiverer ny information og giverbesked 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, atman da har én samlet og integreret model for produkt- og projektdata, ogal information er samlet ét sted.

- Kvaliteten af dokumentationen bliver højnet, da man med et PDM-systemaltid arbejder med den gældende version af produktmodellen. Versionssty-ring håndteres af systemet.

- Et korrekt konfigureret PDM-system forbedrer logistikken i forløbet vedat bidrage til, at de rigtige personer får den rigtige information på detrigtige tidspunkt.

- Klassificeringen af projekt- og produktinformation lægger op til genbrugog gør søgning markant lettere.

- Med et PDM-system kan man automatisere de processer i udviklingsar-bejdet, 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 pro-cesser, hvor aktiviteterne kan udføres parallelt (1. dimension) [Pikosz og Malm-qvist, 1996, s. 6]. Da kommunikationen i et PDM-system går via skærmbillederog dokumenter, er rigdommen i mediet relativt lavt (2. dimension) [Pikosz ogMalmqvist, 1996, s. 6]. Ved anvendelsen af et PDM-system skal man da væreopmæ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 syste-met er det derfor kun muligt at søge i dokumenternes metadata.

- Kommunikationen baseres på fattige medier og lægger derfor ikke op tilløsning af indviklede designproblemer. Et PDM-system må derfor ikkeafløse andre mere informationsrige kommunikationsmedier. Anvendelse afen “virtuel tusch” (se afsnittet Systemfunktioner på side 62) forbedrer dogdette aspekt.

- Et PDM-system er meget dyrt i anskaffelse og tilpasning. Herudover skalbrugerne trænes i brugen af systemet.

65

Del II

Empiri

Kapitel 6

Dokumentationsproces og

kravanalyse


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 be-skrivelse af, hvordan de arbejder med produktmodeller, og herefter analyseresdisse processer for at afdække, hvordan den optimale fremtidige proces under-støttes med et IT-baseret dokumentationsværktøj. I analysen tages udgangs-punkt i den syvfasede fremgangsmåde fra CPM som målet for den fremtidigefremgangsmåde.

69

Kapitel 6 - Dokumentationsproces og kravanalyse

6.1 Analyse af eksisterende processer

For at kunne vurdere hvordan et kommende IT-baseret dokumentationsværk-tøj skal udformes, er det nødvendigt først at have en forståelse for, hvordan dekommende brugere arbejder, når de skal opbygge en produktmodel. Som nævnti indledningen skal dokumentationsværktøjet støtte aktiviteterne i fremgangs-måden for opbygning af produktmodeller fra CPM, og det er ikke formålet meddette projekt at lave en revurdering af fremgangsmåden.

De deltagende virksomheder er alle – i større eller mindre grad – bekendt medCPM’s fremgangsmåde og øvrige arbejde. Analysen af de eksisterende arbejds-processer skal således bruges til at afdække, hvilken funktionalitet et IT-baseretdokumentationsværktøj skal have for at kunne håndtere dokumentationen foren produktmodel på en måde, der er praktisk anvendelig.

Jeg har gennem møder og samtaler med nøglepersoner i virksomhederne forsøgtat afdække deres ønsker og krav til et dokumentationsværktøj, og resultaterne viljeg opsummere i dette afsnit. I bilag C på side 171 er notater fra møder og sam-taler gengivet. Analysen af de eksisterende processer munder ud i en beskrivelseaf, hvordan dokumentationsværktøjet skal støtte arbejdet fremover, og dennebeskrivelse vil derefter være grundlaget for opbygning af kravspecifikationen fordokumentationsværktøjet. Dette er illustreret i figur 6.1. Virksomhederne om-fatter 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 – her-iblandt APC og FLS vel nok som de mest erfarne i Danmark. Hertil kommervirksomheden Vitral A/S (Vitral), som ikke har så stor erfaring med produkt-modellering, men som øjner store muligheder på området.

h i�j k l m n"o k nqp i$j�r,s�tKu kp j n"v.w�x$y w�k"vqm"z�n

{(y�x"o |�k n}x pn$~ k"� k l n"j n�y�z"nz"i$~��"v.n"y l x l � i�y�k �� j i�� n k k�n"j

�(� z�n"y.i�v�r�{(�,�"�� j ~ l � � n�j"i�ws$��tK� k |�k l n"v.n"j

��j x � �k � n �"� p � ~ x l � i$y�q�({��n k"~ j � � n�o k�nqx pi � n�j i$j z$y n l� � j ~ n"vqm"z�n

�$w$y�n}n�j p x"j � y�w�n"j

Figur 6.1: Struktur for analyse af arbejdsprocesser og opstilling af kravspecifikation

70


6.1.1 GEA Niro A/S

Niro er del af den tyske gruppe af virksomheder GEA Group og har oparbejdeten markant kompetence inden for behandling og håndtering af pulver (f.eks. an-læg til spraytørring af mælkepulver, kaffe og metalgranulater). Niros erfaringermed 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 Malissom projektstuderende.

Arbejdet med produktmodeller

Niros arbejde med produktmodeller er beskrevet i bilag C.1 og C.2 på side 173 oger yderligere baseret på løbende samtaler med Martin Malis. Hos Niro anvendesi grove træk fremgangsmåden fra CPM, idet produktmodellering netop blevintroduceret hos Niro i forbindelse med Malis’ ph.d.-projekt.

PVM’en anvendes som udgangspunkt for produktmodelleringen, efter fase 1 ifremgangsmåden er afsluttet. Når PVM’en når et detaljeringsniveau, der gørden for uoverskuelig, fortsætter modelleringen ved opbygningen af CRC-kort ien struktur svarende til PVM’ens part-of struktur. CRC-kortene er således heltcentrale for dokumentationen af produktmodellen og er blevet tilpasset Nirosbrug, bl.a. er alle rent objektorienterede elementer fjernet (generaliseringsoplys-ninger mv.).

Hos Niro er blevet udviklet en løsning i Lotus Notes til at holde styr på CRC-kortene. Satsningen på Notes skyldes, at det i forvejen var virksomhedens stan-dardsystem for kommunikation og dokumenthåndtering. APC anvender ogsåLotus Notes som standardsystem og har fået lov at bygge videre på Niros Notes-lø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 or-ganisere de enkelte indlæg i en hierarkisk struktur (svarende til strukturen iPVM’en). Et indlæg svarer til et CRC-kort og er et dokument, der er baseretpå en central skabelon (svarende til at basere dokumenter på skabeloner i MSWord). Dokumentet indeholder en række felter svarende til felterne på CRC-kortet 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 afstrukturen 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 dereskonfigurator ikke er objektorienteret1. Et eksempel på et skærmbillede fra NirosNotes-løsning er vist i figur 6.2 på følgende side.

Udviklingen og vedligeholdelsen af produktmodeller hos Niro foregår ikke kun iden danske afdeling i Søborg, men bl.a. i samarbejde med afdelingen i Frankrig.Hos Niro er to eksamensprojektstuderende fra Institut for Produktion og Le-delse (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


virksomhedsnetværk på tværs af geografiske grænser. Et krav til et dokumenta-tionsværktøj vil derfor være, at det kan anvendes på tværs af geografiske skel, ogat produktmodellen kan opdeles i undermodeller, som udvikles og vedligeholdesaf 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

1. Versionsstyring (for hvert dokument).

2. Registrering af ændringer (log).Fordele vedeksisterendeværktøj 3. Adgangsstyring.

4. Meddelelsessystem.

5. Flere kan arbejde med systemet ad gangen.

6. Tilgængelighed via internet.

Ønsker omforbedringer

7. Bedre udnyttelse af diagrammerne fra frem-gangsmåden.

8. Udnyttelse af mulighederne for automation(f.eks. automatisk opdatering af data om rela-tioner mellem klasser).

9. Mere intelligent sammenkobling af diagrammerog CRC-kort. Dette giver overskuelighed ikomplekse modeller, som man ønsker at kunneopbygge.

Tabel 6.1: Niros erfaringer med og ønsker til dokumentationsværktøj

72


6.1.2 APC Denmark A/S

Fortroligt, ikke medtaget i denne udgave.

73



74



75


6.1.3 F.L. Smidth A/S

FLS er en del af FLS Industries, og produktporteføljen dækker komplette ce-mentfabrikker, enkeltstående maskiner og renoveringsopgaver samt reservedeleog 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 Mor-tensen, 2002]. Med brug af en konfigurator har de nedsat tiden, det tager atudfærdige et budgettilbud, fra uger til dage, samtidig med at det blot kræveren 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 aftypevalgte enheder i en cementfabrik (enheder til transport af materiale interntpå fabrikken).

Som hos APC startede man opbygningen af produktmodellen med at samle enarbejdsgruppe af modellører, som blev støttet af en følgegruppe af domæneeks-perter. Al produktviden blev tastet direkte ind i konfiguratoren, og der eksisterersåledes ingen dokumentation for produktmodellen. I den anvendte konfigurator(BaanConfiguration 98.2) er der ingen logisk sammenhæng mellem produktdeleog bindinger. Resultatet er en konfigurator, der består af “spaghettikode”, somer meget svær at overskue og vedligeholde.

Problemet hos FLS er oplagt, at der ikke eksisterer nogen dokumentation, ogat 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 hosFLS valgt at give domæneeksperterne ansvaret for hver deres lille del af kon-figuratoren, og ændringer sker ved, at domæneeksperterne sender en e-mail tiltilbudsafdelingen, som har ansvaret for konfiguratoren. På den måde får manrigtigt mange e-mails med en beskrivelse af ændringen, og man skal efterføl-gende finde det relevante sted i konfiguratoren og foretage ændringen. I denforbindelse ville man ønske, at det var muligt automatisk at relatere e-mailentil det område af konfiguratoren, som ændringen vedrører. Men så længe derikke eksisterer en struktureret produktmodel, er dette ikke umiddelbart indenfor rækkevidde.

Erfaringerne fra arbejdet med den nuværende konfigurator bruges i arbejdetmed de kommende. Her opbygger domæneeksperterne (med støtte fra model-lø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 objekt-orienteret. Incitamentet for domæneeksperterne er her at lave dokumentationen

76


rigtig – ellers vil de blive kontaktet i tide og utide af programmørerne, som skalhave afklaret tvivlsspørgsmål. Spørgsmålet er da blot, hvorvidt domæneeksper-terne 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 ikkeumiddelbart muligt at danne sig et overblik over produktmodellen. Herudoverer det også tvivlsomt, om man udnytter alle fordelene ved den objektoriente-rede konfigurator, når dokumentationen opbygges i flade regneark. Resultatetvil givetvis være, at programmørerne må oversætte regnearkene til en objekto-rienteret model, inden de implementerer systemet.

FLS er meget interesseret i et dokumentationsværktøj, da manglen på doku-mentation og en struktureret produktmodel er den største barriere i en effektivudnyttelse af konfiguratorer. FLS nyder stor glæde af fordelene ved at anvendeen konfigurator, men er samtidig fanget af, at det er et uforholdsmæssigt stortarbejde at vedligeholde konfiguratoren, og har på den hårde måde lært, at do-kumentation ikke kan laves efterfølgende, men skal være en integreret del afprocessen.

I modsætning til APC ser FLS det som et problem at basere et dokumentations-værktøj på et standardsystem som Lotus Notes. Hos FLS er kommunikations-og dokumenthåndteringssystemet baseret på Microsofts produkter, og hvis etdokumentationsværktøj baseret på f.eks. Notes skal bruges af domæneeksper-terne, vil det betyde, at en meget stor del af de ansatte i virksomheden skalanvende Notes ud over de eksisterende Microsoft værktøjer. Dette anses ikkeumiddelbart for muligt – hverken økonomisk eller organisatorisk og praktisk.

FLS’s erfaringer og ønsker til dokumentationsarbejdet er samlet i tabel 6.3.

Fordele vedeksisterendeværktøj

1. Regneark er nemt at bruge for alle involverede.

Ønsker omforbedringer

2. Meddelelsessystem til støtte for udviklingsarbej-det (især til notifikation om ændringsforslag).

3. Hyperlinks bør kunne bruges i alle tekstfelter tilinternetressourcer og andre dokumenter.

4. Adgang til værktøjet via internet, så geografiskplacering ikke er et problem.

5. Mulighed for at integrere information fra ek-sterne databaser (f.eks. ERP-system).

6. Mulighed for overførsel til konfigurator og sam-menkobling af dokumentation og implementeringi den løbende udvikling, så kun dokumentationenskal opdateres.

Tabel 6.3: FLS’s erfaringer med og ønsker til dokumentationsværktøj

77


6.1.4 Vitral A/S


78


6.1.5 Krav til dokumentationsværktøj

Erfaringerne og forslagene fra ovenstående virksomheder kan opsummeres i enrække krav til dokumentationsværktøjet. Numrene i margenen henviser til num-rene 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,9APC 7,8og CRC-kort i et databasesystem. Ud fra den samme information i dette cen-

trale lager (repository) kan PVM, klassediagram og CRC-kort dannes. Kiggesdiagrammerne efter i sømmene, vil det fremgå, at de indeholder meget af densamme information, blot vist på forskellige måder.

Versionsstyring skal sikre, at man kan arbejde med flere versioner af samme Niro 1,2APC 1,10CRC-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 ikonfiguratoren – vel vidende at der måtte eksistere nyere versioner af CRC-kort, der endnu ikke er implementeret. Ud over at hvert CRC-kort skal have etversionsnummer, 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 versiontil version, og hvem der har gjort det (registrering i en log).

Adgangsstyring skal sikre, at brugerne kan tilgå systemet med forskellige ret- Niro 3,5APC 2tigheder. 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, somkun 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 4FLS 2mæ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 stillingtil forslaget. Notifikationsfunktionen skal opbygges, så den kan udbygges til atreagere på forskellige hændelser i systemet.

Indlæringskurven for systemet må ikke være stejl. Det bør tilstræbes at lave Niro 7,9APC 4,9FLS 1

systemet så intuitivt let tilgængeligt som muligt for at tilskynde især domæne-eksperterne til at bruge værktøjet uden for meget forudgående uddannelse. Vedat bruge PVM og klassediagram aktivt i brugergrænsefladen kan bidrages tildette mål.

Adgang via internet er et krav, da systemet skal kunne fungere i et netværks- Niro 6APC 3FLS 4

miljø på tværs af geografiske grænser. Det er dog ikke et krav, at systemet skalafvikles i en browser.

Integration til eksterne systemer skal gøre det muligt, at der i CRC-kortene APC 11FLS 5kan 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 betegnelsentag for denne funktionalitet. Versionsnummeret benyttes således primært af systemet tilat holde styr på ændringer.

79


Regler i CRC-kort må ikke være bundet til at skulle skrives i et formaliseretAPC 6Vitral 2 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 teksteller tabeller, frem for ikke at få dem beskrevet på grund af at domæneeksper-terne ikke kan OCL. På den anden side kan det være en fordel for nogle udviklereat kunne dokumentere regler i et formaliseret sprog. Det bør derfor være muligtat dokumentere regler på begge måder.

Hyperlinks skal kunne indsættes i alle tekstfelter i dokumentationen. På denFLS 3Vitral 1 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 bringesfrem.

Fleksibel opbygning skal sikre, at systemet er nemt at udbygge. Det skalAPC 5

være muligt at tilføje brugerdefinerede felter til CRC-kortet, og integrationenmed eksterne systemer bør også rumme muligheder for brugertilpasning.

Integration med konfiguratorer er ikke et centralt krav, men FLS ser detFLS 6

som en oplagt mulighed i fremtiden. Virksomhederne er dog enige om, at blotdet at kunne overføre attributnavne og lign. til konfiguratoren vil være en storfordel, som er værd at inkludere – om muligt.

Sproget i dokumentationsværktøjet skal være engelsk (dvs. tekst på knapper, iAPC 12

menuer, hjælpetekster osv.). Alternativt kunne man lave en arkitektur, der gavmulighed for at sproget kunne ændres let. Det vil dog næppe være ulejlighedenværd, da langt de fleste konfiguratorer og andre systemer, brugerne arbejdermed, 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øjbør understøtte udviklingsarbejdet i projektlivscyklussen. Tilsvarende blev i af-snit 5.2.2.1 på side 61 gennemgået, hvilke overordnede funktionaliteter der ken-detegner et PDM-system. I dette afsnit vil jeg koble disse overordnede erfaringermed kravspecifikationen for dokumentationsværktøjet til produktmodellering.

CASE-værktøjer

Diagrammer udgør en central del af dokumentationen for en produktmodel, ogSyntaktiskkorrekthed der er mange aspekter fra gennemgangen, der er direkte anvendelige. Doku-

mentationsværktøjet skal sørge for, at syntaksen i diagrammerne til enhver tidopretholdes. Syntaksen for PVM skal forinden klart defineres, mens syntaksenfor klassediagrammet kan hentes direkte fra dokumentationen for UML (f.eks.i Booch et al. [2001]). Den objektorienterede tankegang vil her være en godtilgangsvinkel, idet et diagram kan opdeles i en række objekter, som hver isærkan tildeles ansvaret for at tjekke, om syntaksen opretholdes.

Mens det er relativt enkelt at tjekke for syntaktisk korrekthed, er det ikke muligtKonsistens ogfuldstændighed at vurdere, om en produktmodel er fuldstændig. Det syntaktiske tjek skal foregå

80


løbende, ved at elementerne i diagrammerne ikke kan oprettes med syntaktiskefejl (f.eks. tegnes en svag aggregering korrekt, og to klasser kan ikke have sammenavn).

Med hensyn til fuldstændigheden kan dokumentationsværktøjet dog bruges tilat tjekke, om der for alle klasser eksisterer et fuldstændigt CRC-kort. Dettekan 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, deropretter klassen). Brugeren skal derimod selv angive et navn og en beskrivelse.

Anvendelsen af en central databasebaseret produktmodel vil gøre det nemt at Rapport-genereringtrække information ud af systemet. Generering af rapporter vil derfor kunne

opbygges som forespørgsler i databasesystemet. Hvis man samtidig laver enfornuftig objektorienteret model af diagramelementerne, vil det være muligt atbruge funktionaliteten fra en rapportgenerator til at opbygge et dataleksikon. I Dataleksikon

den forbindelse skal der huskes på, at et dataleksikon også skal kunne indeholdeabstrakte 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 ikobledediagrammer

mæssigt at understøtte navigering mellem de to diagrammer. Koblingen mellemen klasse i enten PVM eller klassediagram og dens CRC-kort er derimod en-tydig, og med et klik på en klasse i et af diagrammerne skal et vindue medCRC-kortet for klassen vises3. På samme måde skal det i så vid udstrækningsom muligt kunne lade sig gøre at få adgang til information om et element iproduktmodellen ved at klikke på elementet. Hvis f.eks. en klasse er nævnt i etfelt 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øjetikke 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)informationom klassen. For at have informationen så tæt på anvendelsen som muligt, børdet 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 objekt-orienterede, vil det være vanskeligt direkte at overføre produktmodellen til kon-figuratoren. Til gengæld vil det med en central database være muligt at givemulighed for, at eksterne systemer kan trække på produktmodellens informa-tioner. 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 bagnavigationen mellem diagrammerne og CRC-kortene.

81


Som nævnt ovenfor i afsnit 6.1.5 er versionsstyring et umiddelbart krav. I tilgifthertil vil det være meget anvendeligt at kunne overskue, hvad der faktisk er im-plementeret i konfiguratoren, og sammenholde dette med hvad der er dokumen-teret. Dvs. at kunne sammenholde produktmodellen i konfiguratoren med pro-duktmodellen i dokumentationsværktøjet. Denne funktion vanskeliggøres ogsåaf, at de færreste konfiguratorer er objektorienterede, og sammenligningsfunk-tionen kan derfor med fordel kategoriseres som nice to have og udskydes tilen 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 enstatus – f.eks. implementeret.

CASE-værktøjer til udvikling af informationssystemer indeholder også ofte funk-Systemsimuleringog ydelsesanalyse tioner til systemsimulering og ydelsesanalyse, men i relation til dokumentations-

værktøjet vurderes det, at disse funktioner ikke er relevante – i det mindste ikkei en første version af systemet, der fokuserer på de centrale krav.

PDM-systemer

Adgangskontrollen og versionsstyringsfunktionen nævnt i forrige afsnit er cen-Styring og kontrolaf database trale 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 skalføres en log over ændringer. Hvis udveksling af information med eksterne syste-mer 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 (hvilkesystemer) der kan tilgå databasen, og hvilke operationer der må udføres (læs-ning, skrivning, forespørgsler etc.).

Dokumentationsværktøjet skal udformes til at støtte CPM’s fremgangsmåde,Styring afprocesser ogarbejdsgange

men skal stadig være fleksibelt og kunne anvendes med andre fremgangsmåder.I forbindelse med ændringer i produktmodellen (CRC-kort) skal det dog sik-res, at domæneeksperter kun kan stille ændringsforslag, mens en modellør skalgodkende forslaget, før CRC-kortet ændres.

Dokumentationsværktøjet er samlet omkring den underliggende produktmodel.Styring afproduktstruktur Til forskel fra klassiske PDM-systemer er produktmodellen i dokumentations-

værktøjet objektorienteret, men i lighed med PDM-systemerne skal det væremuligt at lave referencer fra klasserne i produktmodellen til relevante dokumen-ter.

Anvendelsen af en central database til lagring af informationer gør søgning iKlassifikation

og deling af allerede eksisterende modeller let. En klassifikation af klasserne ien 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 afgenerelle 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 ind-Programstyring

lejret i dokumentationsværktøjet. Imidlertid ville det hurtigt blive omfattende,

82


og da der som tidligere nævnt eksisterer mange værktøjer til projektstyring, børdenne funktionalitet udelades af dokumentationsværktøjet.

Notifikation hænger tæt sammen med styring af processer og arbejdsgange. I de Kommunikationog notifikationfleste virksomheder har man standardiserede systemer til at håndtere den elek-

troniske kommunikation, og det vil derfor ikke være formålstjenligt at udvikleendnu et system af denne slags. I stedet bør fokuseres på at lave en meddeleses-funktion, som støtter styringen af arbejdsgange og processer. Man kan måskemed fordel få denne funktion til at benytte sig af virksomhedens eksisterendekommunikationssystem (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åren bruger tilgår et projekt, bør det ske på baggrund af f.eks. titlen på projektetog ikke kræve viden om den fysiske placering af databasen og andre systemtek-niske variable.

Muligheden for automatisering af konvertering af data mellem forskellige forma- Konvertering afdatater anses ikke for at være en central funktionalitet i et dokumentationsværktøj.

Konvertering vil være interessant i forbindelse med kommunikation med konfi-guratorer, 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 produktmodelle-ring. Hvis det kunne gøres lige så nemt at kommentere på f.eks. et CRC-korteller et klassediagram i elektronisk format, som det er at sætte de velkendteselvklæbende gule sedler på et stykke papir, så ville en del af kløften givetviskunne nedbrydes. Funktionaliteten vurderes dog ikke som højeste prioritet.

Til ethvert informationssystem skal vurderes, hvordan systemet skal administre- System-administrationres. Ud over den sædvanlige funktionalitet omkring håndtering af brugere og op-

sætning af systemet bør der også tænkes på, hvordan dokumentationsværktøjetstruktureres, så de i fremtiden nemt kan udbygges, dvs. hvilke elementer skalkunne konfigureres af en administrator, og hvad skal konfigureres via tilpasningaf moduler (add-on) af en programmør. Al håndtering af kommunikation medkonfiguratorer bør løses vha. den sidste løsning, da det kræver meget specifikkeløsninger, som hurtigt kan blive meget omstændelige at indpasse i et fleksibeltmodul, som kan tilpasses af en administrator. Herudover kræver tilpasning me-get specifik tekniske viden, som en administrator næppe besidder.

83


Er et PDM-system løsningen?

Ovenstående gennemgang af PDM-systemers relevans for et dokumentations-værktøj efterlader det umiddelbare indtryk, at et PDM-system vil være en oplagtlø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 lighedermellem et PDM-system og et dokumentationsværktøj til produktmodellering.

En umiddelbar barriere ved at løse problemet med et PDM-system er omfangetog prisen for PDM-systemer. Som det også tidligere blev nævnt, er et PDM-system et meget omfattende informationssystem med en kompliceret opbygning.Derfor er implementeringen af et PDM-system også forbundet med store om-kostninger. Som eksempel kan nævnes Danfoss’ implementering af Metaphase3.0, som har kostet mellem DKK 10-20 mio. at implementere4. Det er såle-des sjældent, at PDM-systemer implementeres i virksomheder med under 1.000medarbejdere5.

En anden barriere er den objektorienterede produktmodel, som ikke traditio-nelt understøttes af PDM-systemer [Svensson og Malmqvist, 2001]. Såfremt derønskes et dokumentationsværktøj, som understøtter mulighederne for generalise-ring, opbygning af klynger og temaer samt muligheden for at lave flere relationermellem klasserne, er et PDM-system ikke løsningen. For virksomheder, der kunsigter mod implementering i en konventionel konfigurator, vil den hierarkiskeproduktstruktur, som klassiske PDM-systemer tilbyder, måske være tilfredsstil-lende. I så fald kan produktmodellen ikke blive mere avanceret, end venstresideni en PVM.

6.2 Den fremtidige proces

Fremgangsmåden for opbygningen af produktmodeller fra CPM beskriver akti-viteterne lige fra den strategiske analyse forud for produktmodelleringen, til pro-duktmodellen 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øttearbejdet i alle faserne undtagen et og seks.

I afsnit 4.2 på side 38 blev fremgangsmåden beskrevet, og som det er illustre-ret i figur 6.4 på følgende side, varierer anvendelsen af PVM, klassediagram ogCRC-kort, afhængig af hvor langt man er nået i projektlivscyklussen. Frem-gangsmåden er baseret på disse tre centrale elementer, og det vil derfor væreoplagt 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øjgrad 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/42002 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 medar-bejdere.

84


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 detvære en del lettere at prøve idéer af og lave ændringer, og dokumentationsværk-tøjet vil være for domæneeksperter og modellører, hvad et CASE-værktøj somRational Rose er for IT-systemarkitekter og programmører.

Anvendelsen af klassediagrammet som dokumentation for implementeringen vilvære fuldt ud tilstrækkeligt, når målet er en objektorienteret konfigurator (somf.eks. iBaan). Selvom fremtidens konfiguratorer med al sandsynlighed vil væreobjektorienterede, er der p.t. et behov for at kunne håndtere dokumentationfor implementering i konventionelle (ikke-objektorienterede) konfiguratorer (somf.eks. Cincom og Oracle). Værktøjet skal derfor understøtte håndtering af dennedokumentation.

Problemstillingen består i, at produktmodellen ofte opbygges med anvendelse aff.eks. nedarvning (generalisering og specialisering), mens den endelige strukturi en konventionel konfigurator vil være et relativt fladt hierarki.

Løsningen er, at dokumentationsværktøjets funktioner bruges forskelligt afhæn- Anvendelse efterkontekstgigt af konfiguratortype. Det kræver, at man – inden modelleringsarbejdet er

nået for langt – har gjort sig klart, om man sigter mod en objektorienteret elleren konventionel konfigurator. Nedenfor er beskrevet forløbet i disse to overord-nede brugerscenarier baseret på fremgangsmåden fra CPM og erfaringerne fravirksomhederne.

Fase 1Procesanalyse

Fase 2Produktanalyse

Fase 3Objektorienteret analyse

Fase 4Objektorienteret design

Fase 5Programmering

Fase 6Implementering

Fase 7Vedligeholdelse

Gennemløb 1

Gennemløb 2

Gennemløb 3

etc. ...etc. ...

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

Oker el sopO k e r e l s o pO k e r e l s o pO k e r e l s o p

O k e r e l s o pO k e r e l s o pO k e r e l s o p

Oker e l s o p

Oker e l s o p

Oker e l s o p

Oker el s op

Oker el s op

Oker el s op

Oker el s op

Oker el s op

Oker el s op



Oker e l s o p

Oker e l s o p

Oker e l s o p

Oker el s op

Oker el s op

Oker el s op

Oker el s op

Oker el s op

Oker el s op



Oker e l s o p

Oker e l s o p

Oker e l s o p

Projektlivscyklus

Figur 6.4: Anvendelse af dokumentationsværktøjet gennem projektlivscyklussen

85


6.2.1 Scenarie 1: Objektorienteret konfigurator

Når konfiguratoren er objektorienteret, vil produktmodellens klassediagram sam-men med de detaljerede CRC-kort udgøre dokumentationen for implemente-ringsstrukturen i konfiguratoren – på samme måde som et klassediagram doku-menterer 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øl-gende side og gennemgås nedenfor.

1. Udgangspunktet er opbygningen af PVM’en i samarbejde med domæne-eksperterne. PVM’en opbygges med brug af alle de tilgængelige elementer:Klasser oprettes, struktureres i aggregeringer og generaliseringer, relate-res til hinanden med bindinger, noter tilføjes, og illustrationer indsættes.For hver klasse oprettes automatisk et CRC-kort, og er den nødvendigeinformation til stede, kan man begynde at detaljere CRC-kortene.

I CRC-kortene kan man f.eks. beskrive oplagte bindinger eller lave refe-rencer til yderligere information i eksterne dokumenter eller databaser.

2. PVM’en kan på et hvilket som helst tidspunkt eksporteres til klassedia-grammet. Oftest vil dette dog ske, når PVM’en er tæt på fuldendt. Klas-sediagrammet vil afbilde den samme struktur som PVM’en, idet den ven-stre side vil blive oversat til aggregeringsstrukturer og højresiden til ned-arvingsstrukturer. En generaliseringsklasse fra PVM’ens venstreside vil iklassediagrammet blive forbundet med sin tilhørende nedarvningsstruk-tur. 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 etgodt udgangspunkt for den videre modellering.

For hver klasse i klassediagrammet oprettes nye CRC-kort, og evt. eksi-sterende information i PVM’ens CRC-kort kopieres til de nye CRC-kort iklassediagrammet. På den måde bibeholdes al information, samtidig medat klassediagrammet er uafhængigt af PVM’en og vice versa.

Versionsstyringen vil tillade, at der kan arbejdes med flere versioner af detsamme CRC-kort, og at det til enhver tid er tydeligt, hvilket klassediagramder 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 arbejdetmed udarbejdelsen af PVM’en var fokuseret entydigt på at afbilde strukturog funktion i produktet, fokuseres nu også på strukturen i den endeligeimplementering.

Klasser tilføjes, ændres og nedlægges, relationer redigeres, og CRC-korteneudfyldes med al nødvendig information. Resultatet er et komplet klasse-diagram, der afbilder produktet i en komplet objektorienteret model –parat til implementering.

86


��,�� }� �� .��.�K�.�� q�K� �(�� ¡��¢,£}¤¥� �� ¦(§¨ © ª�« ¬ ¨ ® ¯ ° ± ² ³ ´ µ ³ ¬ ¶ · ¸�© ³ ¹ · º µ» ¼ ½ ¾ ¿ ¼À Á Â Ã Ä Å Á Æ Ç Á Ã È É Ê Ë Ã Ì Æ À ¾ Ì ¿ ¼ Æ Í Ã Â Î

Ï Ð Ã Ë Æ Ã Ì Ê Ñ

À ¾ Ì Í Ã Â Î Ò Î Ì Ã Ë Ë À Ó

Ô Æ Æ Ì Á Õ Ö Æ ÓÔ Æ Æ Ì Á Õ Ö Æ ×Ø Â ¼ Ë Ë Ã ÓØ Â ¼ Ë Ë Ã ÙÔ Æ Æ Ì Á Õ Ö Æ ÏØ Â ¼ Ë Ë Ã ÚÛ Ã Æ ¾ Å Ã ÚÛ Ã Æ ¾ Å Ã ÜÛ Ã Æ ¾ Å Ã ÏÛ Ã Æ ¾ Å Ã ÝØ Â ¼ Ë Ë Ã ÜÔ Æ Æ Ì Á Õ Ö Æ ÝØ Â ¼ Ë Ë Ã Ó Þ ßÂ ¼ Ë Ë à ¼ ¿ Ã á â ã Ã Ì Ã Â Ë ¾ Îä ¼ Ë Æ å ½ ¼ Ê æ Ã Å á Ó Ü ç Ú × Þ Þ ×ß½ ¼ Ê æ Ã Å Õ è á à é à Ã Â Ë ¾ ÊÇ Ã Ì Ë Á ¾ Ê á Ó é Ùâ È Ê Ã Ì á ê é

ß¼ Ì Â Ë ¾ Ê

ë ì í

î Û Ã Æ ¾ Å Ã Ó ï ðî Û Ã Æ ¾ Å Ã × ï ðî Û Ã Æ ¾ Å Ã ñ ï ðî Û Ã Æ ¾ Å Ã ò ï ðó Ô Æ Æ Ì Á Õ Ö Æ Óó Ô Æ Æ Ì Á Õ Ö Æ ×ó Ô Æ Æ Ì Á Õ Ö Æ ñô õ ´ ö ö · ÷

ø ù ú û ü ý ú þ ÿ �� ù ú û ü ý ú � ÿ �� ù ú û ü ý ú � ÿ �� ù ú û ü ý ú � ÿ �

ó Ô Æ Æ Ì Á Õ Ö Æ Óó Ô Æ Æ Ì Á Õ Ö Æ ×ó Ô Æ Æ Ì Á Õ Ö Æ ñô õ ´ ö ö · �

� ù ú û ü ý ú þ ÿ �� ù ú û ü ý ú � ÿ �� ù ú û ü ý ú � ÿ �� ù ú û ü ý ú � ÿ �






î Û Ã Æ ¾ Å Ã Ó ï ðî Û Ã Æ ¾ Å Ã × ï ðî Û Ã Æ ¾ Å Ã ñ ï ðî Û Ã Æ ¾ Å Ã ò ï ðó Ô Æ Æ Ì Á Õ Ö Æ Óó Ô Æ Æ Ì Á Õ Ö Æ ×ó Ô Æ Æ Ì Á Õ Ö Æ ñô õ ´ ö ö · ÷

ø ù ú û ü ý ú þ ÿ �� ù ú û ü ý ú � ÿ �� ù ú û ü ý ú � ÿ �� ù ú û ü ý ú � ÿ �








� � � � �� ! �� ! �� ! �

� � � ! "

� � � � � � � � #� � � � � � � � "� � � � � � � � $

� � � ! #

Figur 6.5: Fremgangsmåde ved objektorienteret konfigurator. Numrene i figuren svarer til

numrene i beskrivelsen

%'& () * + + , - . + /01, 2 , +3 4 5 6

7 8 9

: ; < < = > ? < 8

@1= A = <

B C D 9 EF; > GH= A = <

7I? J K 8 J G�= A = <

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 erikke, at konfiguratoren er køreklar efter overførslen, idet der uvægerligtskal laves nogle små tilpasninger. Ved hjælp af overførslen slipper manfor at skulle indtaste modellens information (klasser, metoder, attributterbindinger mv.) i konfiguratoren, og samtidig undgås indtastningsfejl. Hvormeget information, der kan overføres til konfiguratoren, afhænger af denenkelte konfigurator. Se afsnit 7.6 på side 114 for mere information omintegrationen til konfiguratoren.

5. For at sikre at dokumentationen (produktmodellen visualiseret ved klas-sediagram og CRC-kort) og implementeringen er i overensstemmelse medhinanden, kan disse sammenlignes og synkroniseres. Et modul sammen-ligner de to strukturer mht. klasser, relationer, attributter og bindingerog markerer uoverensstemmelser. Brugeren skal da efterfølgende tage stil-ling til, om det er implementeringen eller dokumentationen, der ikke eropdateret, og foretage den nødvendige handling.

6. Er der behov for en større revidering af produktmodellen, kan et klas-sediagram eksporteres “tilbage” til en PVM. Her vil en del informationuvægerligt gå tabt som et resultat af forskellen på de to diagrammer.

Som ved eksport fra PVM til klassediagram oprettes nye CRC-kort tilklasserne i PVM’en, og indholdet fra klassediagrammets CRC-kort kopie-res. PVM’en vil efter eksporten være helt “rå”, og illustrationer samt noterskal efterfølgende tilføjes.

87


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 modellerings-metode kan anvendes. Helt grundlæggende er tankegangen anderledes, da attri-butter, metoder og bindinger i en konventionel konfigurator ikke er organisereti en struktur af indkapslende klasser, men i et mere fladt hierarki hvor sammen-hængende attributter og bindinger ikke nødvendigvis er placeret i nærheden afhinanden, 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.

På trods af forskellene kan diagrammerne fra det objektorienterede scenarie bru-Brug af sammediagrammer ges som dokumentation. Riis har i sit ph.d.-projekt i samarbejde med demex

electric A/S opbygget en produktmodel og implementeret denne i en konven-tionel konfigurator (BaanConfiguration 98.4.1) [Riis, 2002]. Erfaringerne medarbejdet har vist, at dokumentationen kan opbygges bestående af de sammediagrammer (PVM, klassediagram og CRC-kort), når man blot ikke bruger ge-neraliseringsstrukturer.

Figur 6.7 på følgende side skitserer fremgangsmådens trin, som bl.a. er baseretpå 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 generaliseringsstruk-turer (højre side af diagrammet), men udelukkende bruges aggregerings-strukturer.

2. PVM’en kan på ethvert tidspunkt eksporteres til et klassediagram. Frem-gangsmåden er den samme som i det objektorienterede scenarie, men detresulterende klassediagram vil i sagens natur bestå af en ret flad strukturuden nedarvning.

3. I klassediagrammet arbejdes videre med produktmodellen under hensyn-tagen til implementeringsmuligheder og -begrænsninger. Navne på klasserog klynger kan bruges til at skabe lighed mellem dokumentationen ogtræstrukturen i konfiguratoren. Der kan ikke laves en komplet en-til-en-relation mellem en klasse i dokumentationen og en tilsvarende knude ikonfiguratorens træstruktur, men navngivningen kan bruges til at skabeoverblik, så det bliver lettere at finde regler og få en idé om strukturen ikonfiguratoren.

4. Når modellen er modelleret færdig, skal den overføres til konfiguratoren.Såfremt konfiguratoren understøtter import af produktmodeldata (i størreeller 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


NPORQHSIT UWVYX Z1[ O\X

] ^ _ ` a b _ c d e] ^ _ ` a b _ f d e] ^ _ ` a b _ g d e] ^ _ ` a b _ h d e

i j k k l m n o k pi j k k l m n o k qi j k k l m n o k rs t u v v w x

y ^ _ ` a b _ c d e] ^ _ ` a b _ f d e] ^ _ ` a b _ g d e] ^ _ ` a b _ h d e

i j k k l m n o k pi j k k l m n o k qi j k k l m n o k rs t u v v w z


i j k k l m n o k pi j k k l m n o k qi j k k l m n o k rs t u v v w {


i j k k l m n o k pi j k k l m n o k qi j k k l m n o k rs t u v v w |


i j k k l m n o k pi j k k l m n o k qi j k k l m n o k rs t u v v w }

~�O\�'VW��Q�[ ZH[MT OWQ'��X �1[ �'�� u � � � � � w �M� � � � w � �� ¡ ¢ �£ m ¤ ¥ ¦ § m k ¨ m ¥ © ª « ¬ ¥ l k £ ¡ l ¢ � k ¥ ¤ ®

¯ ° ¥ ¬ k ¥ l « ±

£ ¡ l ¥ ¤ ® ² ® l ¥ ¬ ¬ £ p

j k k l m n o k pj k k l m n o k q³ ¤ � ¬ ¬ ¥ p³ ¤ � ¬ ¬ ¥ ´j k k l m n o k ¯³ ¤ � ¬ ¬ ¥ µ¶ ¥ k ¡ § ¥ µ¶ ¥ k ¡ § ¥ ·¶ ¥ k ¡ § ¥ ¯¶ ¥ k ¡ § ¥ ¸³ ¤ � ¬ ¬ ¥ ·j k k l m n o k ¸³ ¤ � ¬ ¬ ¥ p ¹ º¤ � ¬ ¬ » � ¢ ¥ ¼ ½ ¾ ¥ l ¥ ¤ ¬ ¡ ®¿ � ¬ k À � « Á ¥ § ¼ p · Â µ q ¹ ¹ qº � « Á ¥ § n Ã ¼ » Ä » ¥ ¤ ¬ ¡ «¨ ¥ l ¬ m ¡ « ¼ p Ä ´½ © « ¥ l ¼ Å Ä

º � l ¤ ¬ ¡ «

Æ Ç È


i j k k l m n o k pi j k k l m n o k qi j k k l m n o k rs t u v v w x

y ^ _ ` a b _ c d e] ^ _ ` a b _ f d e] ^ _ ` a b _ g d e] ^ _ ` a b _ h d e

i j k k l m n o k pi j k k l m n o k qi j k k l m n o k rs t u v v w z] ^ _ ` a b _ c d e] ^ _ ` a b _ f d e] ^ _ ` a b _ g d e] ^ _ ` a b _ h d e

i j k k l m n o k pi j k k l m n o k qi j k k l m n o k rs t u v v w {


i j k k l m n o k pi j k k l m n o k qi j k k l m n o k rs t u v v w |


i j k k l m n o k pi j k k l m n o k qi j k k l m n o k rs t u v v w }

ÉMÊ Ë Ì Í Î Ï Ð�Ë Ì Ñ ÒÓ Ô Ô Õ Ö × Ø Ô ÙÓ Ô Ô Õ Ö × Ø Ô ÚÓ Ô Ô Õ Ö × Ø Ô ÛÜ Ý Þ ß ß à ÙÜ Ý Þ ß ß à ÚÜ Ý Þ ß ß à Û

Ü Ý Þ ß ß à á

Ó Ô Ô Õ Ö × Ø Ô âÓ Ô Ô Õ Ö × Ø Ô áÓ Ô Ô Õ Ö × Ø Ô ã

Ü Ý Þ ß ß à â

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æppemulig. Det skyldes, at implementeringen i konfiguratoren ofte er prægetaf mindre struktureret kode, som ikke (eller med meget stort besvær) kanoversættes til dokumentationens diagrammer af en computer.

Som det fremgår af beskrivelserne for de to scenarier, er fordelen ved anvendelse Fordele vedværktøjaf 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 fordeleved at anvende dokumentationsværktøjet i scenariet med den konventionellekonfigurator. For det første bidrager anvendelsen af klassediagrammer og CRC-kort til en bedre strukturering af dokumentationen, og især med anvendelsen afklassediagrammet opnås et større overblik over produktmodellen og implemen-teringen i konfiguratoren.

I beskrivelsen ovenfor under pkt. 3 fremgår det, at relationen mellem dokumen- Komplekssammenhængtationen og strukturen i konfiguratoren ikke er en-til-en, men kompleks. Ofte

vil det f.eks. være nødvendigt at beskrive implementeringsdetaljer i almindeligtekst, hvilket let gør dokumentationen uoverskuelig. Alternativt kan man dragenytte af klassediagrammets overskuelighed og f.eks. benytte navnelighed mellemen klasse i træstrukturen i konfiguratoren og en klynge af klasser i klassedia-grammet til at dokumentere en mere kompleks struktur. Et eksempel er givet ifigur 6.8 på følgende side.

89


äFå æ ç è�é ê ë ì ë í å êIî ïMð�ñ æ ë ò ó

ô õ ö ÷ø ù ú û ü ö û ý ý û þ ÷ ÿ ÷ ÿ� ü õ � ÿ � ö� � ú � ÿ ÷ ÿ � ÿ � ù � ý ú � �ô � ÿ ù ÷ � � � ö ÿ ÷ ý ý � ÿ � � ú ù � ú û þ� õ ý ÷ ÿ� � � ÷ � û � ý ÷ ü� û ý ú þ � ÿ ÷ ü ý ÷� ù � � û ö ý ü ù þ� ù þ ÷ ÿ

� û ý ý û þ ÷ ÿ � ü õ

�� ! " # $ % & '� ( ( ( & '

) ø ú ú ÿ � ú *) ø ú ú ÿ � ú +) , , ,

- . / 0 1 2 3 4 5 6 � �! " # $ % & '� ( ( ( & '

) ø ú ú ÿ � ú *) ø ú ú ÿ � ú +) , , ,

7 8 / 3

� �! " # $ % & '� ( ( ( & '

) ø ú ú ÿ � ú *) ø ú ú ÿ � ú +) , , ,9 3 1 : 1 ;

� �! " # $ % & '� ( ( ( & '

) ø ú ú ÿ � ú *) ø ú ú ÿ � ú +) , , ,

< : = 6 4 5 > . : 2 ? @

� �! " # $ % & '� ( ( ( & ') ø ú ú ÿ � ú *) , , ,A B 1 4 > : 8 C 1

D�E F G H I J�K L M I N OPRQ�STSTUV QXW V U

Y1å ê�Z í [ çIñ ì ë åIñ

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æstruk-turen, og det er ikke umiddelbart nemt at overskue, hvilke andre klasser (ogdermed f.eks. attributter og bindinger) der påvirkes, når indholdet af klassenVinger ændres.

Hvis man som i figuren dokumenterer implementeringen med et struktureretBrug afklassediagram 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 Over-

flade og et Skelet, der igen er relateret til Aluprofil_01. Af implementeringsmæs-sige årsager er disse klasser ikke nødvendigvis placeret i “nærheden” af Vinger

i konfiguratorens træstruktur, men vha. klassediagrammet ses sammenhængentydeligt.

Endvidere ses det af klassediagrammet, at Vinger også er relateret til Flykrop,Bedre overblik

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 konfigurato-ren, men med anvendelse af klassediagrammet bliver det lettere at få overblikover sammenhængen.

90


6.2.3 Udvikling vs. drift

Arbejdet med dokumentationen stopper ikke, når produktmodellen er opbyggetog lagt ind i en konfigurator. Snarere tværtimod, for når produktmodellen erimplementeret i konfiguratoren, bliver det først rigtigt vigtigt at kunne overskuemodellen for at kunne lave ændringer og tilføjelser. Arbejdet med dokumenta-tionen stiller forskellige krav til et dokumentationsværktøj, afhængig af om manbefinder 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 ar-bejde med. På den måde kan man koncentrere sig om at opbygge produktmo-dellen og lade værktøjet udføre så meget som muligt af den administrative delaf dokumentationsarbejdet. Dette kræver dog en gennemtænkt og -testet frem-gangsmå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 detandet skal dokumentationsværktøjet gøre det let at navigere i dokumentatio-nen. Dvs. det skal være let at overskue og genfinde, hvad man dokumenterede iudviklingsfasen.

Dokumentationsværktøjet skal opfylde disse krav og understøtte dokumenta- Understøttebegge fasertionsarbejdet under såvel udvikling som drift. I udviklingsfasen vil udviklings-

værktøjet lægge op til anvendelse af fremgangsmåden for opbygning af produkt-modeller fra CPM, men det vil samtidig være muligt at bruge værktøjet på “sinegen måde”. Dokumentationsværktøjet vil i høj grad udføre mange af de admi-nistrative opgaver, som erfaringer fra produktmodelleringsarbejdet har vist, eren stor hæmsko.

I driftsfasen skal dokumentationsværktøjet fungere dels som en effektiv struktu-reret søgemaskine, dels som et styringsværktøj for ændringer og rettelser (change

management). Samtidig skal værktøjet kunne integreres med forskellige konfi-guratorer og dermed lette arbejdet med at sikre, at dokumentation og imple-mentation er ens.

Dokumentationsværktøjet skal også kunne integreres med eksisterende informa- Integration medIT-systemertionssystemer i virksomheden, og det skal være muligt at udveksle informationer

med databaser i eksisterende ERP- og PDM-systemer. Typisk vil der være be-hov for at have let adgang til styklister, produktnumre, priser osv. Integrationenvil betyde, at disse informationer kan vises i f.eks. CRC-kortene, og ved at henteinformationen fra de eksisterende informationssystemer sikres, at oplysningernekun skal vedligeholdes ét sted.

91

Kapitel 7

Kravspecifikation


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 dokumentations-værktøj til produktmodellering. Specifikationen baseres på den forudgående gen-nemgang af CASE-værktøjer og PDM-systemer (kapitel 5 på side 47), gennem-gangen af CPM’s fremgangsmåde for opbygning af produktmodeller (kapitel 4 påside 33) og analysen af produktmodelleringsprocesserne hos fire danske virk-somheder (kapitel 6 på side 69). Specifikationen støttes med brugsmønstre oget 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, hvordanet dokumentationsværktøj bør opbygges. Forslaget tager udgangspunkt i analy-sen af de eksisterende dokumentationsprocesser og oplægget til den fremtidigeproces (kapitel 6 på side 69), og sigter mod at tilgodese de opstillede krav fraafsnit 6.1.5 på side 79.

Et af de centrale krav er ønsket om en tættere kobling mellem de tre hovedele-OO-model sombasis menter i dokumentationen. Ud af diagrammerne og CRC-kortene fremgår det,

at det i vid udstrækning er den samme information, de indeholder. I dokumenta-tionsværktøjet bør dokumentationen derfor håndteres som en objektorienteretproduktmodel, der lagres i en central database.

Ved at opbygge dokumentationen omkring en central databasebaseret produkt-model opnås flere fordele. F.eks. skal en del af informationen i dokumentationenhverken indtastes eller vedligeholdes af brugerne, men genereres og opdateresautomatisk af dokumentationsværktøjet. Det gælder f.eks. information om re-lationerne mellem klasserne, der genereres automatisk ud fra strukturen i mo-dellen.

Fremgangsmåden fra CPM lægger op til, at PVM, klassediagram og CRC-kortmed fordel kan anvendes som centrale elementer i brugergrænsefladen i værk-tøjet. CRC-kortet har allerede vist sin egnethed i bl.a. Niros og APC’s Notes-løsninger. I de samme løsninger har der også været stor tilfredshed med PVM’enshierarkiske struktur, som blev anvendt i Notes, mens man savnede de grafiskemuligheder, 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årigeerfaringer fra IT-verdenen har underbygget klassediagrammets berettigelse i enobjektorienteret model.

På den måde kan de velkendte grafiske elementer fra fremgangsmåden fungeresom en visualisering af modellen og vil samtidig være den måde, hvorpå mannavigerer rundt i modellen og tilføjer/ændrer information. Strukturelle ændrin-ger foretages ved at ændre i PVM eller klassediagram, mens indholdsmæssigeændringer sker gennem CRC-kortene. Sammenhængen mellem PVM og klas-sediagram skal dog ikke være helt tæt, men PVM’en skal snarere fungere somudgangspunkt for den videre modellering i klassediagrammet, jf. fremgangsmå-dens fase 2 og 3 (se afsnit 4.2 på side 38).

94


\X] ^ _ ` ] a b!\

cedgf dihgf jik l mon

p!q r s t r u vu w x y z t r {!| y u z } t u vu w x y z t r~ } r

� ] � � ^ � � �i� � ` � a bX\

�� ] � � � �� ` � � a bX\!� ` ]

��Rmol ��dgf l ��m�hi�hgj�hgf ��

��k �i�� i��d�k f hihgjoh�f �i�

c��i�o��imif dgf l ��m�hi�� k ��f �i�

edi�R�o��k f �nR�im��ik dgf �Rk

c¢¡e£¥¤�� X��Rmol ��d�f l ��m

¦�¦�¦

£¥��R�R��§ hi�ghi��¨��R�R§

©��hi��Rk f ��¨��R�R§

ª �¨�R��k f ��¨��R�R§

«��Rhi��k l ¬ f hi��¨��R�R§

�R��k dgf l � hgjihgf ��

~ } r z ®

¯ «eª

° ± ² ³ ² ´ µ ¶ ·° ± ² ³ ² ´ µ ¶ ·° ± ² ³ ² ´ µ ¶ ·° ± ² ³ ² ´ µ ¶ ·° ± ² ³ ² ´ µ ¶ · ° ± ² ³ ² ´ µ ¶ ·

¸ ¹ º » º ¼ ½ ¾ ¿À ÁÂ Ã ÄÀ ÁÂ Ã ÄÀ ÁÂ Ã Ä À Á Â Ã ÄÀ Á Â Ã ÄÀ Á Â Ã ÄÅ Æ Ç È É ÊÅ Æ Ç È É Ê Å Æ Ç È É ÊÅ Æ Ç È É ÊË Ì Í Î Í Ï Ð Ñ Ò

Ó {�Ô

Õ�Ö s u u | q z s r y s ×ØgÙ�Ø!v ® } y w

Ú Û ` Ü � ^ ` �` � � � ` ] Ü�Ý ] ^ _ ` ] 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 illustrerefunktionaliteten i dokumentationsværktøjet og samtidig skitsere, hvordan deoverordnede elementer hænger sammen. I det følgende vil komponenterne i mo-dellen blive gennemgået sammen med en beskrivelse af funktionaliteten. Forat lette læsningen bruges betegnelsen database for moduler, der retteligt burdebetegnes DataBase Management System - DBMS.

Produktmodeldatabase

Den centrale database i dokumentationsværktøjet indeholder al information omproduktmodellen, svarende til indholdet af PVM, klassediagram og CRC-kortsamt de projektrelaterede oplysninger. I deres struktur har PVM’en og klasse-diagrammet stor lighed med hinanden, og strukturen i produktmodeldatabasenskal derfor kunne udnytte denne lighed og dermed sikre en højere integritet.

95


Brugerdatabase

Hver klasse i modellen “ejes” af en bruger eller brugergruppe, som dermed eransvarlig for at opdatere klassen. En bruger eller brugergruppe kan naturligviseje flere klasser. Ændringsforslag til indhold eller struktur, der berører en givenklasse, kan således ikke implementeres i modellen uden accept af ejeren af den/deberørte klasse(r).

Som en del af datastyringen (se nedenfor) skal alle aktiviteter, der berører pro-duktmodellen, registreres i en log, så ændringer til enhver tid kan spores til denudførende person. Brugerdatabasen indeholder oplysninger om alle brugere afdokumentationsværktøjet. Mange virksomheder har i forvejen oprettet brugerneaf deres IT-netværk i brugerdatabaser, og det vil derfor være oplagt at forsøgeat genbruge denne information i brugerdatabasen for dokumentationsværktøjet.

Virksomhedsdatabaser

Information skal kunne hentes fra eksterne databasesystemer. Meget af denneinformation skal direkte bruges i modelleringsarbejdet, mens andre blot vil væreoplagte at have adgang til. Dataudvekslingen skal være baseret på modulæropbygning, så det er muligt at udvide systemet med understøttelse af databaserfra 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 model-len, og hvilke rettigheder de har. Baseres på oplysninger fra brugerdataba-sen og rettighederne angivet for klasserne i modellen. De enkelte brugereskal 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 versio-ner af produktmodellen. Dette sker ved, at hvert CRC-kort kan gemmes iflere versioner. For hvert CRC-kort skal det derudover være muligt at an-give, 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 “parke-ringsplads” 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 model-len, skal det automatisk fremgå, hvad der er lavet, hvornår og af hvem.

Logik Specifikation af forretningslogik, dvs. regler og retningslinjer for hvor-dan datatransaktioner skal håndteres (f.eks. at når en klasse slettes, skalklassens relationer også slettes).

96


Brugergrænseflade (GUI)

Dette er brugerens kontaktflade til systemet. Systemet skal understøtte fleresamtidig brugere, og at disse tilgår systemet via internet. Hermed lægges optil, at brugergrænsefladen overordnet kan implementeres på to måder. Entenkan man vælge en løsning, hvor brugeren arbejder med værktøjet gennem enbrowser (tynd klient), eller også kan vælges en løsning, hvor værktøjet afviklespå brugerens computer og blot kommunikerer med en central server over internet(tyk klient). Med begge løsninger sikres, at brugerne kan arbejde sammen omen produktmodel uafhængigt af deres geografiske placering.

Overordnet kan brugergrænsefladen inddeles i to dele: en administratordel ogen brugerdel. Administratordelen bruges til at administrere systemet (håndterebrugere, tildele adgangsrettigheder, tilrette skabeloner osv.) og tiltænkes såledesikke brugt ofte. I bilag F på side 259 er lavet et scenarie for brugen af systemetsuppleret med prototyper af skærmbilleder.

Brugerdelen derimod skal bruges konstant under arbejdet med systemet. Grafiskskal denne brugergrænseflade baseres på de grafiske elementer, der indgår i frem-gangsmåden, hvilket vil gøre værktøjet nemt at gå til. Dette omfatter primærtPVM, CRC-kort og klassediagrammer. Det bærende koncept i udformningenaf brugergrænsefladen vil være en afspejling af arbejdet med fremgangsmådensgrafiske elementer, som brugerne forudsættes kendskab til. At arbejde med do-kumentationsværktøjet bliver således ikke grundlæggende anderledes end at ar-bejde med PVM, CRC-kort og klassediagram på papir eller i et diagrammerings-program. Til gengæld tilføjes en stor del ny funktionalitet som følge af dentættere integration af elementerne.

Mange virksomheder har eksisterende dokumentation liggende i forskellige do-kumenter. Dette drejer sig f.eks. om resultater af funktionstest, ingeniørbereg-ninger eller andet relevant materiale. I PVM og CRC-kort skal det være muligtat lave referencer til denne eksterne dokumentation. Dette betyder, at man ialle tekstfelter kan indsætte links, og i CRC-kortene kan oprettes nye bruger-definerede felter, hvori der kan indsættes referencer til dokumenterne. Det erikke hensigten, at dokumentationsværktøjet skal understøtte visning af indhol-det af de eksterne dokumenter. Hertil skal benyttes de dedikerede programmer.På denne måde vil dokumentationsværktøjet med en simpel funktionalitet virkesom 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 someksterne databaser (eller rettere DataBase Management Systems). For at givebedst mulig fleksibilitet i forbindelse med vedligeholdelse og udbygning af doku-mentationsværktøjet bør en struktureret arkitektur som treskemaarkitekturenanvendes ved implementering af databasestrukturen [Sadoski og Comella-Dorda,2000].

97


Tredjepartssystem

Dækker over alle eksterne systemer (på nær DBMS’er), som systemet skal kom-munikere med. P.t. er dette primært konfiguratorer. Kommunikation med ERP-systemer vil primært foregå gennem DBMS-kommunikation-modulet. Udveks-lingen af data med konfiguratorer er yderligere behandlet i afsnit 7.6 på side114.

Eksport- og importmodul

Modulet vil give mulighed for at eksportere (store dele af) modellen til et tred-jepartssystem som f.eks. en konfigurator.

Den umiddelbare fordel er, at en masse arbejde spares ved, at informationeni produktmodellen ikke skal indtastes manuelt i konfiguratoren. Dette minime-rer samtidig risikoen for fejl ved indtastningen. Den anden fordel følger delvistaf den forrige. Ved at gøre overgangen fra design (og dermed dokumentation)til implementering lettere lægges op til, at produktmodellen i dokumentations-værktøjet fungerer som “hovedmodel”, og at modellen i konfiguratoren afspejlerhovedmodellen. Ultimativt laves alle ændringer i dokumentationsværktøjet, ogderefter opdateres konfiguratoren relativt let.

En mulighed i fremtidige versioner af dokumentationsværktøjet vil være at un-derstøtte en slags “reverse engineering” ved at lave import-moduler, så man kanindlæse konfiguratorers produktmodeller i dokumentationsværktøjet.

Eksportmodulet skal være modulært opbygget, så det er muligt at udvide doku-mentationsværktøjet med mulighed for at eksportere til konfiguratorer fra flereleverandører. En plan for det videre forløb ville her være at etablere og udbyggesamarbejdet med leverandører af konfiguratorer og løbende udvikle nye modulertil integration med nye konfiguratorer.

Rapportgenerator

En veludbygget produktmodel indeholder anseelige mængder information, somer vanskeligt at overskue. En rapportgenerator skal gøre det muligt at generererapporter baseret på informationen i de tilknyttede databaser. Brugerne skalkunne tilpasse rapporterne, så de indeholder den relevante information, og detskal være muligt at definere rapportskabeloner.

Rapportgeneratoren kan også bruges til at generere en encyklopædi for pro-duktmodellen, dvs. en rapport over alle navne på modellens klasser, metoder,attributter etc. med tilhørende beskrivelse. På den måde kan skabes en oversigtover modellens elementer, og man kan hurtigt finde navnet på en ønsket klasse.

Kommunikationssystem

Eksternt system, der kan kommunikere med brugerne af dokumentationsværk-tø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 meddelelsetil de implicerede, f.eks. via virksomhedens e-mail-system (Notes, Outlook etc.).Kommunikationen bliver derved aktiv (informationen sendes til modtageren) ogikke 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 ikkesendes for meget information, men kun nødvendige meddelelser.

Med modulet er det muligt at tilpasse værktøjet, så det understøtter arbejds-gangen i den enkelte virksomhed. Hvis man f.eks. har en politik om at revideremodellen hver tredje måned, kan modulet hjælpe ved at gøre brugerne opmærk-som på, hvor deres opmærksomhed er påkrævet og henvise til det pågældendeområde i dokumentationen. Modulet kan konfigureres til, hvilke kombinationeraf hændelser (klassers status, tid, ændringer osv.) der skal genere meddelelserog 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ærgæ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 iudviklingsfasen), og i forrige afsnit blev derfor lagt op til, at dokumentations-værktøjet skal indeholde funktionalitet til adgangsstyring på såvel bruger- somgruppeniveau.

Projektarbejdsformen rejser en problemstilling omkring lagringen af informatio- Adgang tilproduktmodelnen i en produktmodel, nemlig hvordan adgangen til disse data skal håndteres.

Det centrale spørgsmål er, hvorvidt information fra alle virksomhedens produkt-modelleringsprojekter skal lagres i én central produktmodel, eller om informa-tionen fra hvert projekt skal lagres i separate produktmodeller1. Situationen erillustreret 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 fysiskemodel, hvor al information givetvis vil blive lagret i samme database.

99


Þ�ß à!á â�ã äoåÞoß à!á â�ã ägæ

ç�è é�ê�ë�ì�í î�é�êRïRð

A B

ñ ò ñ ó ô õ ö ÷ó ø ù ÷ ú û ñ ü û ý ù þ ö ÿó � � ý � � ý ù � � � õ û � � ÿ ùó � � ÷ó õ � ÿ ù ÷ø ÷ ÷ ö ý � � ÷ ÷ ÿ ö ÿ ÷ õ þ ÿ ö

(a) Én samlet produktmodel

� � � � � � ��

� � � � � � �� ! ! � � " # $ � � � � � �� % & " ��

')( *,+.-./10 23*,+.465 '7( *,+.-,/10 23*,+,465

8:9 ;=< >@? ACB819 ;=< >@? AED

F G

(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 etCRC-kort for en bestemt motor. I projekt A skal opbygges en konfigurator,der har fokus på logistik og forsendelsesomkostninger, mens man i projekt Bsigter mod en konfigurator til konfigurering af motoren efter ønsker om ydeevne.Således spiller motoren to forskellige roller i de to projekter.

Vælges løsningen i figur 7.2(a), opnås den fordel, at der kan trækkes på eksiste-Samletproduktmodel rende 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 kanspare tid i udviklingsprocessen. Ulempen er dog, at de mange klasser, der ikkeer inkluderet i et givet projekt, hurtigt kan forringe overskueligheden. Samtidigvil det være et problem, at en given klasse kan have forskellige attributter, me-toder eller noter tilknyttet alt efter projektet (illustreret med CRC-kortet formotoren). Klassen spiller således en unik rolle fra projekt til projekt.

En bedre løsning er derfor at arbejde med opdelte produktmodeller som illu-Opdeltproduktmodel streret 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ældendeprojekt. 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 ERP-systemets database og linkes til den enkelte klasse vha. DBMS-modulet.

For at give mulighed for genbrug på tværs af projekter skal det dog naturligvisvære muligt at søge i dokumentationen for andre projekter og kopiere klasser ogklassestrukturer. Adgangsstyringsmodulet skal her sikre, at det ikke er muligtat redigere klasser i et andet projekt.

7.3 Brugsmønstre

Sammenholdes kravene fra forrige kapitel med aktiviteterne i CPM’s fremgangs-må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 behandleti 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å centraleaktiviteteraktiviteter omkring håndtering af dokumentationen. Et overordnet brugsmøn-

sterdiagram er vist i figur 7.3. I diagrammet indgår fire undersystemer (Ad-ministration, PVM, CRC-kort og Klassediagram) illustreret ved klynger. Disseundersystemer er detaljeret i selvstændige brugsmønsterdiagrammer i bilag D påside 197.

Dokumentationsværktøj

Log på systemet

Domæneekspert

Modellør

Administrator

Administration

CRC-kort

Klassediagram

PVM

«uses»

Vis rapport

Definér rapport-skabelon


Udskriv

Log af systemet

Konfigurator

Tiden

Figur 7.3: Brugermønsterdiagram for dokumentationsværktøj

101


7.3.1 Aktører

Af figuren fremgår det, at der i alt er identificeret seks aktører som brugere afsystemet. Husk på, at opdelingen i aktører hentyder til roller frem for fysiskepersoner eller systemer. Den samme person eller system kan således godt haverollen som flere aktører.

Modelløren er den primære bruger, som med værktøjet opbygger en produkt-model på basis af den information, der er indsamlet hos domæneeksper-terne. Modelløren har både IT-teknisk indsigt og er specialist i produkt-udvikling og -modellering. Herudover har modelløren erfaring med imple-mentering i konfiguratorer. Til gengæld er modelløren ikke nødvendigvisspecialist inden for det modellerede produkt. På større projekter vil dervæ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 harikke nødvendigvis indsigt i produktmodellering og konfiguratorer. Ofte erder for et produkt tale om en gruppe af domæneeksperter, der hver isærhar indsigt i en del af produktet. Formålet med at gøre domæneekspertentil bruger af værktøjet er at uddelegere ansvaret for, at konfiguratorener opdateret. Domæneeksperten kan ikke ændre i modellen, men kan seindholdet og komme med ændringsforslag.

Administratoren tager sig af konfigurering af systemet. Arbejdsbyrden erstørst i forbindelse med opstart af nye projekter, og opgaverne er heltadskilt fra den egentlige produktmodellering.

Konfiguratoren repræsenterer virksomhedens konfigurator, som skal udveksleinformation med dokumentationsværktøjet.

Kommunikationssystemet varetager afsendelse og modtagelse af meddelserfra dokumentationsværktøjets meddelelsesmodul. Over for dokumenta-tionsvæ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 afimplementeringter for at klarlægge forudsætningerne før brugermønsteret, handlingsrækkeføl-

gen i brugermønsteret og resultatet af udførelsen. Alle brugsmønstrene er do-kumenteret 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 kompleksite-ten af dokumentationsværktøjet. For at forbedre overskueligheden er brugsmøn-strene grupperet i fem grupper:

- Topniveau

Brugsmønstre, der har generel anvendelse eller benyttes på tværs af klyn-gerne.

- Administration

Undersystem indeholdende brugsmønstre, der anvendes ved administra-tion af dokumentationsværktøjet (oprettelse af brugere mv.).

- PVM

Undersystem indeholdende brugsmønstre, der anvendes ved arbejde medPVM’en (oprettelse af part-of klasser mv.).

- CRC-kort

Undersystem indeholdende brugsmønstre, der anvendes ved arbejde i CRC-kortene (ændring af metoder, attributter mv.).

- Klassediagram

Undersystem indeholdende brugsmønstre, der anvendes ved arbejde medklassediagrammer (redigering af relationer mv.).

Ud fra brugsmønsterdiagrammerne fremgår det, at klyngen CRC-kort indehol-der mange centrale brugsmønstre for dokumentationsprocessen, hvilket under-streger, at CRC-kortet har en central rolle i arbejdet med dokumentationsværk-tøjet.

Udarbejdelse af beskrivelserne for brugsmønstrene har bidraget til at afdække Iterativ afdækningaf kravnogle brugsmæssige aspekter for dokumentationsværktøjet. Bl.a. at flere scena-

rier, der umiddelbart er forskellige, viser sig at være meget ens (f.eks. oprettelseaf klasser i brugsmønster nr. 3.6 på side 219 og nr. 5.7 på side 248), og at noglescenarier 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å side252). Blandt brugsmønstrene er der identificeret otte vigtige antagelser, somskal 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 somprojekter. Inden for et projekt er det muligt at arbejde med flere klassedia-grammer og PVM’er, men da kun én version af hvert CRC-kort kan have statussom “implementeret”, findes der også kun ét muligt klassediagram, som afspejlerimplementeringen.

103


Brugsmønster Antagelse Afklaring

1.3, side 2021.4, side 203

Information kan trækkes fraproduktmodeldatabasen vha.et formaliseret forespørgsels-sprog (SQL).

Anses ikke som et problem, idetlangt størstedelen af databaser un-derstøtter forespørgsler via SQL.

1.5, side 204 Der kan udskrives via opera-tivsystemet via en veldefineretgrænseflade.

Anses ikke som et problem for imple-mentering under MS Windows, somunderstøtter udskrivning via et vel-defineret API.

2.5, side 210 Det er muligt at lave link tilekstern database og forespørgevia SQL.

Anses ikke som et problem, da demange databasesystemer understøt-ter dataudveksling via et API (f.eks.ODBC).

2.7, side 2124.12, side 2354.13, side 236

Det er muligt at sende meddel-elser via et eksternt kommuni-kationssystem.

Anses ikke som et problem, damange kommunikationssystemer un-derstøtter afsendelse af e-mail viaPOP3-protokollen. Alternativt kannemt installeres en (gratis) mailser-ver.

5.1, side 242 Det er muligt entydigt at de-finere, hvordan produktmodel-len skal overføres til konfigura-toren.

Er en central problemstilling, somskal afklares for hver enkel konfigu-rator. Behandles i afsnit 7.6 på side114.

5.2, side 243 Det er muligt at tilgå konfigu-ratorens database.

Er en central problemstilling, somskal afklares for hver enkel konfigu-rator. Behandles i afsnit 7.5 på side110.

5.10, side 251 Det er muligt at definere en al-goritme for optimal placeringaf elementerne i et klassedia-gram.

Anses ikke for et problem, dader eksisterer adskillige flowchart-programmer, der kan håndteredenne funktionalitet (bl.a. MS Visioog Rational Rose).

5.11, side 252 Det er muligt entydigt at de-finere, hvordan PVM overførestil klassediagram.

Er en central problemstilling,som skal afklares. Behandles iafsnit 7.5 på side 110.

Tabel 7.1: Antagelser i brugsmønstre

104

7.4 Specifikation af diagrammer


Med PVM, klassediagram og CRC-kort som de centrale elementer i et doku-mentationsværktøj er det vigtigt at få afklaret præcist, hvad der menes meddisse tre begreber. Som det fremgår af afsnit 4.3 på side 40 og gennemgangennedenfor, 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 erikke afklaret præcist, hvilke elementer der skal anvendes (der er f.eks. fleretyper 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 eksisterendeCRC-kort, PVM’er og klassediagrammer blevet gennemgået. Dette har dannetbasis 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 afPVM, klassediagram og CRC-kort er vurderet, hvordan information og strukturbør lagres, og som dokumentation herfor er opbygget et klassediagram fokuseretpå 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 afelementerne i strukturen har antaget forskellige former, men den grundlæggendestruktur 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 sideer vist et bud på en PVM med alle elementer. Elementerne gennemgås nedenfor.

105


Klasse 0

Attribut 1 [rød, grøn, blå]

Attribut 2 [3..25]

Klasse 1

Klasse 2

Klasse 3

Attribut 3 [0,1]

Attribut 4 [0..999]

Klasse 4Notetekst notetekstnotetekst notetekstnotetekst

Klasse 5 Klasse 6 Klasse 7

Klasse 8

Attribut 5 [3,4,7]

[ 2 ]

[ 2..8 ]

[ 4 ]

[ 1.. ]

[ 4 ]

Kol 1 Kol 2Noget tekstMere tekst...Mere tekst...Mere tekst...

§ 1-1§ 1-2§ 2-1§ 2-2

Note(tabel)

Topklasse

Attribut(med værdiområde)

Klasse

Binding

Illustration

Part-of relation(med kardinalitet)

Note(tekst)

Kind-of relation

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 visesen 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 angi-ves 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 delesmellem flere overklasser ved, at en underklasse medtages flere gange iPVM’en, og det er således ikke muligt at lave en entydig sammenhængmellem part-of relationerne til enten en svag eller stærk aggregeringsrela-tion 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 enenkelt 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 enpassende applikation.

106


7.4.2 Elementer i klassediagram

I afsnit 4.3.2 på side 42 blev klassediagrammet gennemgået. Elementerne i etklassediagram til produktmodellering er som nævnt identisk med UML-notatio-nen for klassediagrammer (se afsnit 3.3.2 på side 25). Dog anvendes typisk ikkenær så mange elementer, og efter gennemgang af flere produktmodelleringspro-jekter i samarbejde med ph.d.-studerende på IPL er jeg kommet frem til, hvilkeelementer et klassediagram i et fremtidigt dokumentationsværktøj skal inde-holde. I figur 7.5 er vist et eksempel på et klassediagram til produktmodelleringindeholdende disse elementer.

HJI K L L M:N

OP

P

P

H=I K L L M1QO P

R S T U V U T W XHYI K L L M1Z[ \E] T ^ _ ]C` a b[ \E] T ^ _ ]1c a bd e T T f U g S T `d e T T f U g S T c

H=I K L L MEh

HJI K L L M1i

j ] k l T

e T T f U g S T\E] T ^ _ ]

m n o p1o p p f ] p ] f U q pr ^ T ]a sE] _:t ] q n U l q U q p bu V o l l ]

m T vwf k o p p f ] p ] f U q pe l l ^ x U o T U ^ q

m T ] f ] ^ T W y ]

z ] q ] f o V U l ] f U q p

{C| }=~Y�J��w�1��

u V W q p ]

j ] s o

Figur 7.5: Eksempel på klassediagram med alle anvendte elementer

Klasse Fællesbetegnelse for objekter med ens karakteristika.

Metode Formaliseret beskrivelse af klassens opførsel. Metoderne opdeles i totyper: klassemetoder og systemmetoder. De første er metoder, der beskriver klas-sens 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 detgrafiske 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 struk-turer, hvor klasserne eksisterer uafhængigt af hinanden.

- Aggregering, stærk Relation mellem klasser til opbygning af whole-partstrukturer, hvor klassernes eksistens afhænger af hinanden. Klasser “leverog dør” med hinanden.

107


- Association Simpel relation mellem klasser for at sikre, at klasserne “kendertil” hinandens eksistens og kan kommunikere med hinanden (lave metode-kald og tilgå offentlige attributter).

- Generalisering Relation mellem klasser til opbygning af nedarvningsstruk-turer.

Tema Mulighed for gruppering af klasser i overskuelige enheder.

Klynge Mulighed for at opdele klassediagrammet i underdiagrammer, hvor ind-holdet skjules på det overordnede diagram.

Note Mulighed for at tilføje noter til diagrammet med valgfri tekst. Noten kanefter valg relateres til et andet element med en stiplet linje. I noteteksten kanindsættes referencer til eksterne dokumenter eller ressourcer (hyperlinks), og vedat 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 fungerersom detaljeret dokumentation for klasserne i PVM og klassediagram, og medbaggrund i inspiration fra Andersen og Jensen [2001]; Hvam og Riis [1999] ogde praktiske erfaringer fra Notes-løsningerne hos APC og Niro er jeg kommetfrem til, at et CRC-kort bør have en opbygning som vist i figur 7.6.

�1� � �=� � � � � �J��

�1� � � � � � � �1� � � � � ¡ � ¢J¡ @� � £ ¤ ¥ � ��E� � ¦ � § ¢ � � � �

¨:�=�J� � �J� � § ¡=� ©:� ¡ � � � � § � � � § ¡=�ª � « ¬ ® ¯ °± ¬ ² � ³ � ® ¯ ° ´ µ ¬ � ¶ ® ² ² ¬ � ° · � « ¬ � ¶ ® ² ² ¬ � °

¨1� � � § ¸ � � � � �

¹6� � £=ºJ� �

» ¼:½ ¾ ® µ � ¾ ¿ � ¬

» ¼:½ ¾ ® µ � ¾ ¿ � ¬YÀ � � « Á ¿ « Â ¬ ® � � ¿ �Y� �

�1� � �=� � � � � �@Ã Ä Ä Ä

� � � � � � � � � � � � � � � � � � � � � � � � � � �Ä Ä Ä

Å ¶ � � ² ¬Æ ¬ ¶ ² �

Figur 7.6: Eksempel på CRC-kort med alle felter

108


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 sehistorikken for klassen.

Ejer Navn på personen, der har oprettet denne klasse. Klikkes på feltet, givesadgang 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 atindsæ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), somklassen 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 visesal information om attributten. ID - Navn viser attributtens unikke ID og valgfrienavn, mens Note viser den valgfrie notetekst.

Metoder En oversigt over klassens metoder med indikation af metodens art somenten system- eller produktmetode (se afsnit 4.3.2 på side 42 for skelnen mellemmetoder). Ved klik på metoden vises al information om metoden. For produkt-metoder vises metodens tekst (f.eks. fri tekst eller OCL), og for systemmetodervises beskrivelsen. Som for attributter viser ID - Navn metodens unikke ID ogvalgfrie navn. Relation til viser, hvilke andre klasser metoden påvirker/påvirkesaf.

Brugerfelt Brugerdefineret felt bestående af et vilkårligt antal variable. Derkan oprettes et vilkårligt antal brugerfelter, men felterne er fælles for alle CRC-kort i modellen, på samme måde som hvert CRC-kort har feltet Klassenavn.

Tankegangen bag brugerdefinerede felter er inspireret af APC’s behov for attræ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 visningaf SKU-detaljer, og i figur 7.8 på side 111 er eksemplificeret, hvordan dette tæn-kes implementeret i dokumentationsværktøjet ud fra CRC-kortet fra figur 7.6 påforegående side.

109


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 etklassediagram, som illustrerer strukturen for den underliggende produktmodel-database, hvori alle informationer for en produktmodel lagres. Klassediagram-met 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å denene side repræsenterer al den nødvendige information og samtidig strukturererdet 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 CRC-kort og sammenhængen med elementerne i klassediagrammet i figur 7.9. I gen-nemgangen bruges “skrivemaskine” skrifttype til at fremhæve ord med refe-rence til det centrale klassediagram i figur 7.9 på følgende side. Eksempelvis vilIllustration henvise til hele klassen ‘Illustration’ i klassediagrammet, mensBrugerfelt.Navn henviser til attributten ‘Navn’ i klassen ‘Brugerfelt’.

110


Ç È É Ê Ë Ì ÍYÎ Ï É Ð Ñ Ò Ó Ô Ñ Ò ÓEÕ Ö × ÏØJÙ@Ú�ÛYÜ Ý Þ ß à á Ç É â ã Ì ä Ê å=È æ È ç Ï É å=â ã Ï è Ë È ÍEÏé ê ë ë ì ìí î ï î ð ñ í ò ó ô õ ö ÷ ø ù ÷Yõ ù ú û ü ú ý ý é þ ÿ�� ø û � � ì � � � � � � � ø û � ø û � � � � � � � � � �Ç É â ã Ì ä Ê Ó Ç � �=É È ä è ÏYÑ Ê È Ê Ì �ë � � � � � � � � � � � � � ÷ � � �Yÿ � �� Ï â ç É È × � � ä ! È � è È Î � è � Ê Ö� ø ù ú � � � "$# � � � � � ÷ � û � é ý ù # % ÷& Ï ç � â æ �

� ' é " �Ñ Ê È Ê Ï � ( Ç É â ! � æ ä Ï �� " � é ) ê é é ö é " �� â Ì æ Ê É � Ï �

� â ÍYÍ@Ï æ Ê �ÿ � � � % û ý ú ù � " � é

* ù ø + � ù ÷ û û ù # , ø û - � �� # � . û # � � ÷ û ÷ , ÷ � �� û , ù ø + � ù ý � � û - � � # ÷ � û � �, ù ø + � ù ÷ û û ù # , ø û û � ù ü � ù ÷ ý û úü / ú ù , ù ø + � ù � �$. ÷ � � 0 û û �/ 0 ù � # � � � ê ÷ ù û ' ø -$, � ù ú + ú -$- � � û � � 1

2 3 4 5 6 3 7 6 8 9 :; 9 9 3 < = 4 9 > ; 9 9 3 < = 4 9 : ; 9 9 3 < = 4 9 ?

@ 8 A B B 6 C D EF@ 8 A B B 6 ? A G ? E A 9 HJI K 6 32 6 B L 3 < G 6 8 B 6

; 5 5 3 6 5 6 3 < ? 5 M 6 ? 6 3 A 8 < B 6 3 < ? 5I 3 N 6 8 A 7 O2 6 B 9 P 3 A 7 O Q G 6 3 L 8 A B B 6 3 OSR ? N 6 3 L 8 A B B 6 3O

; 9 9 3 < = 4 9 9 6 3

T 6 9 H N 6 3

D E C U A G ? U H 9 6

D E C U A G ? U H 9 6 V< ? N W H 8 N X 6 8 A 9 < H ? 9 < 8

2 3 4 5 6 3 7 6 8 9 > Y Y Y

; 9 9 3 < = 4 9 > ; 9 9 3 < = 4 9 : ; 9 9 3 < = 4 9 ?Y Y Y

Z L < 9 B 6[ 6 L B 9

Figur 7.8: Eksempel på brugerdefineret felt i CRC-kort

\ ] ^ ^ _ ` a b c aed feg ^ h h c\ ] ^ ^ _ ` a b c h ikj d feg ^ h h c

lnm o p q r s r

t

u v v w\ x y\ z$^ _ {\ y$^ | } ~$} � a\ � � c a\ ��c �e�$c � ^ b | �ea c a\ � | c a c } | � � c\ z$} | c\ �$b ` | h c\ f } { | c b h |\ � | ^ | � h

�n� � � � �\ x y\ z$^ _ {\ � � � c\ z$} | c\ ] �k��| c b h |\ � � { g ` ��d �e} } g c ^ {

�� e�

� �n� b � � { | ^ b h � �

lnm o p q �¡ £¢

\ z$^ _ {\ � c b h |\ �$c g ~nx y¤d yk` ^ � a ^ ¥£~ c g c ¥�c { |

¦k§ r �

tuev v w

� �$} � | c � �

\ �$c g ~$x y¨d feg ^ h h c\ � � � c\ z$} | c\ � � { g ` �\ �� g | ~ t\ �� g | ~$©\ � c h b a ~ t\ � c h b a ~ ©

ªk� � � r m §eo

\ z$^ _ {\ in{ | ^ g i$| | a

ln« ¬ � « ® � � r

¯$° � r � ±�qe±�� r § pe�

� �k` h y$^ | ^ � �\ �e² a ` � |\ ]eg ^ ² c a ` { �

³nln� m o ´

t

u v v w

� � c � { ~$fkyk� ��eµ � g ¶�� $c a ` j ` ² c a � �

\ zk^ _ {�n� � � � � pem � e« � ±

t

w

· } b � h�c a � ¸¹� c {�� { � c a \g ` � � c { � c¹º�º£\ ¥�} � c g vik| | a ` » � | | c a h } ¥¼� } h ` | ` } {�} h _ vj } a | c � { ` { ��c a � c a j } ae` b b c�¥�c � | ^ � c |

� � c � { ~$fkyk� �� c � { ~$]e�k�¹� �\ �kc a h ` } {½£¾ ¿ ÀeÁ ¿ Â�Ã � Ä � Â�� Åe�

tw

\ z$^ _ {\ �$¶Æa � `\ x { � � |$d � } } g c ^ {

ln« ¬ � « � r r « m Ç ¬ r

t

w

� È » { f$yk� �\ z$^ _ {\ feg ^ h h c � ` ^ � a ^ ¥

�n� ° o �

t wt w

t w

� �ec � { ~n] �$�¹� �� eb h � } a | � �� $c a ` j ` ² c a � �

\ zk^ _ {\ � } � b g ^ h h c�d feg ^ h h c

É Ê¡Ë

� � c � { � �

\ � � � c\ � | � a a c g h c\ ] } h ` | ` } {\ � | `

Ì � � ¬ � r « � r m §$o

t

t v v w

� È » { yk} b � ¥¡c { | � �\ � | `Í s r ³n§ ´ ¬ ±�� o r

\ z$^ _ {\ � � � c\ x { ` | ` ^ g �$¶Æa � `\ z$} | c\ �$¶Æa � ` º�¥�a ¸ � c\ �e{ � c �

Înr r « m Ç ¬ r

\ z$^ _ {Ï � ±��

t

t

u v v w

\ z$^ _ {\ � c h b a ` _ c g h c\ ]ea } � c b | g c � c a\ y$^ | } ~ } � a

É$« § Ð � ´ r

t

u v v w

t

u v v w

ln« ¬ � « p � r � Ñ � §eÇ � � �p � r �� y$^ { �$^ � � } a | � �\ · c g | c a\ �$` g � ¶Æ{ � c g ` � � c �

ªk� Ò Ò §$« r � ´ � Ç � � § o u v v wuev v w

ing g c¹b g ^ h h c a � ^ a c | � { ` b |$x y vy$c | | c�c a � � c g ^ � | ^ j � c { h � {| ` g } _ c a h b � c g ` � � c � c { v

Figur 7.9: Klassediagram, der viser et forslag til den underliggende produktmodelmodel-

database

111


PVM og klassediagram

I afsnit 7.3.2 på side 103 blev lagt op til, at overgangen fra PVM til klassedia-gram skulle specificeres. Forløbet i produktmodelleringsarbejdet er beskrevet iafsnit 6.2 på side 84, og fælles for de to scenarier er, at der startes med opbygningaf en PVM, som siden hen danner grundlag for opbygning af et klassediagram.Derfor skal PVM’en nemt kunne transformeres til et klassediagram. Dette errelativt simpelt, da al information og struktur uden problemer kan overføres fraPVM til klassediagram. Tabel 7.2 viser sammenhængen.

Element i Element i Kommentar

PVM klassediagram

Topklasse Klasse Topklassen kan have attributter og overføres der-for til en selvstændig klasse som øverste klasse i enaggregeringsstruktur for hele klassediagrammet(se også figur 6.6 på side 87).

Klasse Klasse Oprettes som Klasse i PVM’en og kopieres tilnye instanser ved overførsel til klassediagram.

Attribut Attribut Attribut findes i begge diagrammer somKlasse.Attribut.

Part-of relation Svag aggregering Part-of relationer svarer til aggregeringer, somkan være enten stærke eller svage. Overføres tilsvage aggregeringer, men i klassediagrammet kandette 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 oprettesdisse som Klasse.Metode af den ønskede type(f.eks. OCL eller fritekst). Ved overførsel fraPVM til klassediagram overføres Klasse.Metode

automatisk.

Illustration – Illustrationer understøttes ikke i et klassediagram.

Note Note Noter findes i begge diagrammer. De opret-tes som PVM.Note i PVM’en og kopieres tilKlassediagram.Note ved overførslen. Tabeller iPVM’en overføres ikke til klassediagrammet, menkan kopieres manuelt til et vilkårligt notefelt på iet CRC-kort.

Tabel 7.2: Sammenhæng mellem elementer i PVM og klassediagram

112


CRC-kort og diagrammer

Informationen i CRC-kortene hentes fra den underliggende produktmodelmodel-database, og CRC-kortet skal derfor snarere betragtes som en brugergrænsefladefrem for et selvstændigt element. I tabel 7.3 er lavet en opstilling af alle elemen-terne i CRC-kortet, og for hvert element er angivet, hvor informationen skalhentes 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 historikkenfor klassen.

Ejer Klasse.Ejer Ved klik på navn vises oversigt over de brugere,der kan tilgå klassen (Klasse.MedRedaktører) medmulighed 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 relationener af typen aggregering, og som er underklasser.

- er del af Klasse.Relation.Rel_ID Der vises kun de relaterede klasser, hvor relationener 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 relationener af typen generalisering og hvor klassen nedarverfra.

- underklasser Klasse.Relation.Rel_ID Der vises kun de relaterede klasser, hvor relationener af typen generalisering og som nedarver fraklassen.

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 Ved klik på en metode vises al information med mulighed for ændring

- ID Klasse.Metode.ID

- 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 meto-den. Såfremt der anvendes OCL, opdateres feltetautomatisk, ellers må dette gøres manuelt for hvermetode.

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 produktmodeldatabase113


7.6 Overgang fra dokumentation til konfigurator

Integrationen mellem dokumentationsværktøj og konfigurator har overordnet toformål:

- at lette overgangen fra model til implementering ved at give mulighed forat overføre modellen digitalt til konfiguratoren.

- at støtte vedligeholdelsesarbejdet ved at give mulighed for at sammenlignedokumentation 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 tilpas-ses hver enkelt konfigurator med specialudviklede moduler, som kræver storeudviklingsressourcer. I dette afsnit vil jeg kort beskrive mulighederne for atudveksle information mellem dokumentationsværktøjet og konfiguratorer medbaggrund 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í î ïñð å ê ò ó

ô õ�ö ÷ ø ù úû ü ý ö ÷ ø ù A

þnå í ê è ð é ê$í ÿeí ê è ç� å äké � ì �kæeð ë ê ä$ð �

Bþnå í ê è ð é ê$í ÿeí ê è ç� å äké � ì �kæeð ë ê ä$ð �

ô õ�ö ÷ ø ù úû ü ý ö ÷ ø ù

(a) Via individuelle moduler i dokumentationsværktøj

� � � � � � � � � ��

�� !�"$# � � % &

')( * A+�� # � �� ,� � � �- � �� . � /)��# � � ��# 0

B+�� # � �� ,� � � �- � �� . � /)��# � � ��# 0

(b) Via API i konfiguratorer


Dokumentationsværktøj

APIAEksternt system

(konfigurator)

BEksternt system(konfigurator)

(c) Via API i dokumentationsværktøj

1 2 3 4 5 6 7 8 3 4 9 : ;4 < 7 < = < > 9

? @ A B CED F G H G I @ F J K LNM A G O P

Q R�S T U V W XY Z [ S T U VR T \ ] ^ _ 9 5 7 2 < : 7` 3 2 8 < 7

Aa A J G D M F G J b J G D Cc A @ F d I e B M H G @ M f

Ba A J G D M F G J b J G D Cc A @ F d I e B M H G @ M f

(d) Via neutralt filformat

Figur 7.10: Udveksling af data mellem dokumentationsværktøj og konfiguratorer

114


Overførsel til konfigurator

Uden hensyntagen til den enkelte konfigurator kan dataudveksling ske på femoverordnede måder. Disse er skitseret i figur 7.10 på foregående side.

En måde er, at dokumentationsværktøjet kan eksportere til konfiguratorernesformat for den underliggende produktmodel (figur 7.10(a) på foregående side).Dette kræver, at dokumentationsværktøjet har et eksportmodul for hvert for-mat (dvs. hver konfigurator), der skal eksporteres til. Det kræver yderligere, atman ved udformningen af logikken bag eksportmodulet har studeret konfigura-torens format meget grundigt, så man ikke risikerer at ødelægge konfiguratorensproduktmodel.

En anden måde er, at konfiguratorerne stiller et Application Programming In-terface (API) til rådighed for eksterne systemer (figur 7.10(b) på foregåendeside). På den måde tilgås konfiguratorens produktmodel via en veldokumenteretgrænseflade, og er API’et standardiseret (som f.eks. Open DataBase Connecti-vity (ODBC) under Windows og unixODBC for ikke-Microsoft systemer) kanman 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 kananvendes, hvis konfiguratoren er svær at eksportere til, men har gode mulighederfor at importere data. Automationen er dermed lagt over til konfiguratoren,men det er samtidig muligt at tilpasse den enkelte konfigurator, så der hentesde data, der kan importeres i det enkelte tilfælde. Især med de nuværende ikke-objektorienterede konfiguratorer er der stor forskel på, hvad der kan indlæses ikonfiguratoren.

En fjerde måde er at benytte sig af et neutralt filformat (figur 7.10(d) på fo-regående side), som både dokumentationsværktøj og konfigurator understøtter.Fordelen er selvsagt, at man kan koncentrere udviklingsressourcerne om detteene format. Desværre findes der ikke umiddelbart et sådant format for udvekslingaf produktdata, som er bredt accepteret. En mulighed ville ellers være Standardfor the Exchange of Product model data (STEP), men formatet har desværreikke vundet bred anvendelse og er stadig under udvikling, hvorfor det må ansesat være forbundet med en ikke negligerbar risiko at satse på formatet [Kern ogBøhn, 1995].

Hvis dokumentationen skal kunne sammenlignes med implementeringen medhenblik på at afdække evt. uoverensstemmelser, skal dokumentationsværktøjetkunne indlæse konfiguratorens produktmodel for derefter at sammenholde dennemed 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 atstrukturen er veldokumenteret. Og igen er fordelen størst, hvis API’erne er stan-dardiserede.

115


En anden måde er at lave importmoduler i dokumentationsværktøjet, som kanindlæse de forskellige konfiguratorers produktmodeller (figur 7.10(a) på side114). Igen kræver det, at konfiguratorernes format er veldokumenteret og til-gængeligt. Ulempen er naturligvis, at der skal laves et modul for hver konfigu-rator.

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 ansessom utopisk.

7.6.1 Kommunikation med Oracle

Oracles konfigurator er en del af Oracle e-Busines Suite og er (naturligvis) base-ret på en Oracle-database, hvor produktmodellen lagres. Databasen kan tilgåspå to måder: enten indirekte via Oracles API (i Java) eller direkte via ODBC2,som illustreret i figur 7.11.

gih jlklm nporq

sut�vxw�y z

{}|�~� g�o$qr�$�

�i��E� zxt�� }��E� z�� i�� z�� v � � � � �� t �E� ��

{�|x~� g}h jlkNm n��

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 enny attribut uden at skulle tænke på de databasetransaktioner, der skal til atudføre kommandoen. Således er man ikke afhængig af at kende til databasear-kitekturen, og en applikation, der udnytter Oracles API, vil ikke være påvirketaf versionsændringer fra Oracles side. API’et er primært tiltænkt til automati-sering af import af store mængder data (f.eks. i opstartsfasen).

Oracles API understøtter dog ikke alle funktioner til udvikling og vedligehol-delse af produktmodellen. F.eks. er det ikke muligt gennem API’et at tilgåbindingerne. For at redigere disse skal databasens tabeller tilgås direkte gennemODBC API’et. Dette giver fuld kontrol over databasen, og stiller dermed storekrav til en rigtig forståelse af databasearkitekturen. Samtidig er en applikation,der tilgår databasen direkte, afhængig af databasearkitekturen og dermed ikkeuafhæ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.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 illustreretnedenfor3.

Baan 98 gemmer produktmodellen dels i en .BPC-fil og dels en MS Accessdatabase, men informationen i de to lagre er ens. MS Access-databasen kan lettilgås og manipuleres med Baans Visual Basic (VB) add-in. Det er dog ikketilrådeligt, da konfiguratoren altid anser indholdet af databasen for korrekt, ogder 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-filenlæses af en intern parser4, og dermed tjekkes syntaksen automatisk.

Access DB

Baan 98

VBadd-in

.BPCfil

Eksternt system(dokumentationsværktøj)

Parser

(a)

iBaan

.CAVAfil

Eksternt system(dokumentationsværktøj)

(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 .BPC-fil. Den eksisterende .BPC-fil kan så enten være en eksisterende Baan 98-modeleller genereret af et eksternt system. Med kommandoen er det muligt at vælge,hvilke foldere (dvs. elementer) der skal importeres. Regler kan ikke importeresmed samme måde, men kan indsættes vha. kopiér-indsæt fra et hvilket som helsttabelformat (f.eks. i Excel).

I iBaan (Baans nye objektorienterede konfigurator) lagres informationen heltanderledes. I forbindelse med udviklingen af den nye konfigurator er der ogsåblevet udviklet et programmeringssprog (Cava - Constraint Java), som brugestil at lagre oplysninger om produktmodellen. Sproget er dokumenteret med ek-sempler i Invensys [2002]. Da modellen er objektorienteret, indeholder Cava-filenal nødvendig information om klasserne, deres struktur og inhold (inkl. attribut-ter og regler). Med iBaan er det muligt at importere Cava-filer direkte.

3 Oplysningerne stammer fra telefonsamtale 20/8 2002 med Niels Sander Christensen, QAManager hos Baan Danmark.

4 En parser er et computerprogram, der oversætter tekst til (for computeren) genkendeligetekststrenge til videre analyse.

117


7.6.3 Kommunikation med Cincom

Produktmodellen i Cincoms konfigurator vedligeholdes gennem en grafisk bru-gergrænseflade (Knowledge Builder). Den underliggende database kan gemmesi enten MS Access- eller MS SQL-format. Knowledge Builder har mulighed forat tilgå andre datakilder ved hjælp af ODBC og kan ad den vej importere dataind i produktmodellen.

Herudover findes ifølge Mikkel Dalgas fra APC tre muligheder for at integrereCincom med eksterne systemer:

1. I Cincom findes en type af objekter, der kaldes External References, somkan være links til eksterne programmer eller dokumenter. På den mådekan man afvikle eksterne programmer og “pipe” information.

2. Alle Cincoms interne objekter nedarver fra nogle basisklasser, som admi-nistratoren af systemet har adgang til at ændre på. Det er f.eks. muligtat tilføje et felt til et dokumentationslink, tekst eller lign. Disse nye feltervil så automatisk findes i alle objekter i systemet.

3. Det er muligt at importere/eksportere hele modeller og dele af modellervia 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 Cincomsdatabase er struktureret, og i forbindelse med en integration med en Cincom-konfigurator 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 kanoverføres mellem dokumentationsværktøjet og konfiguratorer, og med indblik ide forskellige måder, som Cincom og Baan lagrer og giver adgang til informationpå, bør et kommende dokumentationsværktøj understøtte følgende mulighederfor kommunikation (se figur 7.13 på følgende side):

- Dataudveksling gennem et API. Dette bør være standardiseret, og der-for foreslås ODBC. Hermed sikres en fleksibel mulighed for både importog eksport af data på en entydig måde med et bredt udvalg af databa-ser. Med denne grænseflade sikres, at dokumentationsværktøjet kan tilgåmange forskellige datakilder, ligesom det sikres, at mange forskellige kon-figuratorer kan tilgå dokumentationsværktøjets information.

- Mulighed for tilføjelse af moduler til import og eksport af data. På denmåde kan laves tilpassede kommunikationsmoduler til enkelte konfigura-torer, som ikke understøtter ODBC. Tilføjelsesmodulerne udformes f.eks.på baggrund af eksisterende dokumentation af konfiguratorens dataformateller et evt. API (forskelligt fra ODBC).

Det er nødvendigt at være fleksibel mht., hvordan data kan tilgås, da dokumen-tationsværktøjet nødvendigvis må være åben for integration med de eksisterende

118

7.7 Summering og prioritering af krav

� � � � � � � E� � ¡ ¢ £� ¤ � ¤ ¥ ¤ ¦ ¡

§$¨x©lªE«¬N®l¯ °)¯ ± ¨�®E²�³�´¶µ ©�¯ ·�¸

¹iº�»¼ ½�¾r¿�ÀrÁ

Â�Ã�ÄxÅ Æ�Ç È�ÅrÄ�É$Ä�Å Æ�ÊË ÃxÌ�È$Í�Î Ï�Ð�Ç ÑxÅ Ì�Ç�Ò AÂ�Ã�ÄxÅ Æ�Ç È�ÅrÄ�É$Ä�Å Æ�ÊË ÃxÌ�È$Í�Î Ï�Ð�Ç ÑxÅ Ì�Ç�Ò B

¹}Ó�Ó�Ô Õ�Ö ×)Ø Ù ÚÛEÜ

Figur 7.13: Forslag til dataudveksling med dokumentationsværktøj

og kommende konfiguratorer på markedet, og ikke omvendt. Muligheden for im-port af information og tilføjelse af moduler er nødvendig for at kunne placerehåndteringen af en synkroniseringsfunktionalitet i selve dokumentationsværktø-jet.


For at give et overblik over de krav, der er opstillet i de foregående afsnit, vil jegher opsummere resultaterne. Med henblik på de senere faser i udviklingsforløbetvil jeg også lave en prioritering af kravene, så det bliver muligt lave en vægtningaf, hvad der er essentielt for et dokumentationsværktøj, og hvilke krav der kankategoriseres som “nice to have”.

7.7.1 Fleksibilitet gennem moduler

Som det fremgår af den begrebsmæssige model for dokumentationsværktøjet ogfigur 7.1 på side 95, er der lagt op til at bygge det op omkring moduler. Rentudviklingsmæssigt giver det mulighed for at udbygge og teste værktøjet løbendeog dermed hurtigt fremkomme med moduler, der rent faktisk fungerer. Samtidigbliver det nemmere at imødekomme fremtidige krav, idet ny funktionalitet kanlaves ved at udbygge værktøjet i bredden med nye moduler eller i dybden ved atudvide eksisterende moduler til f.eks. at understøtte flere leverandører af kon-figuratorer. Det svarer til, at man f.eks. i Windows udvider med understøttelseaf en ny printer.

Samtidig giver opbygningen i moduler mulighed for at starte med et grundmodulog 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 adskillesi 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 do-kumentationsværktøj, men ikke alle moduler er lige essentielle for arbejdet meddokumentationen af en produktmodel. På baggrund af analysen i kapitel 6 påside 69 foreslås nedenstående prioritering for en versionsmæssig udvikling afværktøjet.

119


Ý

Þ

ß à á â ã à ä å ß

æ�ç è ç�é è ê�ë ì í)î

ï ð ñ ò ó ñ ô õô ö ÷ ø ù ó ñ ú û ø ô ù ü ó ô õô ö ÷ ø ù ó ñý ü ñ

þ à ÿ � á � � ��ÿ � ã � ä å ß

� � à � � ÿ �� ã � � ä å ß ã à

� ��í)ì � ç è ì �lí)é��é ê�é è � �

�lë �� ç ë è é�é ê)é è ��

æ��í�è ç è ì �lí)é�� ë � è � �

Eç��ë è �î��)í��ë ç è ��ë

æ"! #%$�� í)ì � ç è ì �lí

& &'&

#(��) é�� é��*��)

+�� é��ë è ��*��)

, �*��ë è ��*��)

-'��é�� ë ì . è é��*��)

/ ��ë ç è ì � é ê)é è ��

ý ü ñ ù 0

1 - ,

2 3 4 5 4 6 7 8 92 3 4 5 4 6 7 8 92 3 4 5 4 6 7 8 92 3 4 5 4 6 7 8 92 3 4 5 4 6 7 8 9 2 3 4 5 4 6 7 8 9

: ; < = < > ? @ AB CD E FB CD E FB CD E F B C D E FB C D E FB C D E FG H I J K LG H I J K L G H I J K LG H I J K LM N O P O Q R S T

U ú V

W X ò ô ô û ð ù ò ñ ø ò YZ [ Z õ 0 ü ø ö

\ ] ã ^ � á ã �ã � � � ã à ^_ à á â ã à ä å ß

`

a

b

c

d

Figur 7.14: Begrebsmæssig systemmodel opdelt i grundmodul og andre moduler

Prioriteringen er baseret på funktionelle krav. Under den videre udvikling afdokumentationsværktøj kan det dog snildt vise sig, at elementer, der er prio-riteret langt nede på listen, kan implementeres med meget få ressourcer, og atman derfor vælger at implementere dem i en tidligere version.

Prioritet 1 Et grundmodul består af de interne databaser, datastyringen ogbrugergrænsefladen. Databaserne er grundlaget for hele produktmodellen, ogda designet af strukturen i databaserne er essentielt for, hvilken funktionalitetsystemet kan yde, skal denne struktur fastlægges tidligt og samtidig være flek-sibel i forhold til fremtidige udvidelser. Klassediagrammet fra figur 7.9 på side111 kan være et godt udgangspunkt for denne struktur. Versionsstyring skalindtænkes allerede her.

I forbindelse med datastyringen udelades funktionaliteten i Adgangsstyring ogLog i de første prototyper.

Brugergrænsefladen vil i sagens natur blive udviklet løbende, efterhånden somfunktionaliteten udbygges, men som første prioritet bør de grundlæggende ele-menter dog være på plads til håndtering af information i databasen ved hjælpaf PVM, klassediagram og CRC-kort.

PVM, klassediagram og CRC-kort skal have elementer, som beskrevet i af-snit 7.5 på side 110, dog kan der ikke indsættes brugerdefinerede felter på CRC-kortene.

120


Produktmodellen understøtter ikke opdeling i undermodeller samt integrationtil eksterne brugerdatabaser.

Prioritet 2 Der tilføjes funktionalitet til integration med eksterne databasesy-stemer via et DBMS-modul. Samtidig tilføjes funtionalitet til at tilføje bruger-definerede felter på CRC-kortene.

Prioritet 3 Et udskriftsmodul tilføjes, så det er muligt at udskrive de forskelligeelementer (som beskrevet i brugsmønstrene). Samtidig tilføjes adgangsstyring.

Prioritet 4 En rapportgenerator tilføjes, så det er muligt at udtrække data fraproduktmodeldatabasen. Samtidig tilføjes også funktionaliteten i datastyrings-modulets Log.

Prioritet 5 Et meddelelsesmodul tilføjes, som udnytter et eksternt kommu-nikationssystem til afsendelse af meddelelser baseret på hændelser i værktøjet.Samtidig udvikles et modul til konfigurering af meddelelsesmodulet. Som beskre-vet 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 senereversioner af dokumentationsværktøjet vil det være oplagt at tilføje mulighedenfor brugerdefinerede hændelser.

Prioritet 6 Et eksportmodul tilføjes, så det er muligt at eksportere indholdeti produktmodellen til eksterne systemer. Prioriteten er her først og fremmestat etablere muligheden for integration via et API, f.eks. ODBC. Afhængig afudviklingsprojektets interessenter udvikles add-on moduler til integration medsystemer, der ikke understøtter kommunikation via et API.

Prioritet 7 Nederst på prioriteringslisten ligger muligheden for import af datafra eksterne systemer. Denne funktionalitet lapper ind over funktionaliteten iet API (se afsnit 7.6.0.0.24 på side 115) og kræver en grundig analyse af denenkelte konfigurators muligheder.

7.7.3 Prototype-skærmbilleder

På baggrund af brugsmønstrene og de opstillede krav har jeg beskrevet et typiskscenarie, som illustrerer en del af de centrale funktioner i dokumentationsværk-tøjet. På baggrund af scenariet har jeg designet et antal skærmbilleder, som kangive et umiddelbart indtryk af, hvordan arbejdet med dokumentationsværktøjetkunne foregå. Scenariet og skærmbillederne kan findes i bilag F på side 259.

Skærmbillederne giver et godt umiddelbart indtryk af mange af de funktionali- ef�g h i j'k l m j h n o

ef�g h i j'k l m j h n op q r m s t u v s k l m s w s ox y ez { | h i r�} s k l m ~ s r�q oe�f�g"h i j k l m j h n o� � n ~ y t w s � h i r�} s k l m i s | og h i j'� t i | t n s k l m �� j o

teter, som er beskrevet under gennemgangen af kravene til systemet. Skærmbil-lederne er baseret på et standard MS Windows-design, hvilket gør det nemt forbrugerne 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 noglebrugere vil opfatte prototyperne som et udtryk for det endelige design, hvorfordet er vigtigt at understrege, at det kun er prototyper.

121

Kapitel 8

Den videre udvikling


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 dokumenta-tionsværktøj til produktmodellering. Som illustreret i figur 1.1 i indledningener dette projekt kun startskuddet til det endelige design og ultimativt imple-menteringen af dokumentationsværktøjet. I dette kapitel vil jeg foregribe dekommende aktiviteter og se på forskellige overordnede måder at implementerevæ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 design-fasen som oftest er meget diffus. Jeg har i dette projekt tilstræbt at afdækkekravene for et dokumentationsværktøj til produktmodellering ved at analyserebehovet for funktionalitet og formulere disse i dels beskrivende tekst, og dels etklassediagram samt brugsmønstre. Efter denne analysefase overgår projektet tildesignfasen og derefter implementeringsfasen.

Indholdet af faserne afhænger af, hvordan værktøjet skal implementeres. Sigtesefter en fuldstændig egenudvikling af værktøjet fra bunden (i et højniveausprogsom f.eks. C++ eller Java), skal der i designfasen udarbejdes en omfattendedesignmodel for det kommende system, der beskriver alle aspekter – alt er jomuligt, og der er principielt ingen begrænsninger.

Sigter man i stedet på en løsning, der tager udgangspunkt i et eksisterendesystem (f.eks. et PDM-system eller et CASE-værktøj), bliver både design- ogimplementeringsfasen noget anderledes. Selv om leverandøren af det eksiste-rende 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 valgtesystem. 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 skaltilføjes.

I denne rapport er blevet afklaret, hvad et dokumentationsværktøj skal kunnefor at tilfredsstille de kommende brugere. Den første opgave herefter vil derforvære at få afklaret, hvordan dokumentationsværktøjet skal implementeres – dvs.om der findes et eksisterende system, der kan tilpasses, eller om systemet skaludvikles fra bunden, og hvilken type programmeringssprog der skal anvendes tilformå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 ta-ges spiller en række faktorer ind, som ikke direkte er relateret til funktionalitetenaf det endelige produkt. F.eks. lægger man hos Niro vægt på at nye IT-systemerkan 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 do-kumentationsværktøjet ved at se på nogle forslag til, hvordan dokumentations-værktøjet kan implementeres, hvilke muligheder og begrænsninger der er vedde forskellige muligheder, og et groft estimat af de tidsmæssige og økonomiskeomkostninger. Slutteligt vil jeg overveje, hvordan den kommende projektorga-nisation 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 budgettetsrammer. Med egenudvikling menes her, at dokumentationsværktøjet program-meres op fra bunden på baggrund af en designmodel. Hermed kan alle ønskerog krav implementeres på præcis den måde, som det ønskes. Brugergrænsefla-den kan designes præcis som ønsket, integration af systemets interne modulerkan koordineres og optimeres, lagring og håndtering af data kan skræddersys tilsituationen, og grænseflader til eksterne systemer kan opbygges efter de opstil-lede krav. De eneste begrænsninger er de tekniske muligheder og budgettet, ogi 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 stillingtagentil, 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 afde traditionelle miljøer som f.eks. C++, men med kommunikation over internetsom et af de centrale krav til dokumentationsværktøjet, kunne J2EE og .Netvære meget interessante. J2EE er seneste version af Java-platformen fra Sun,som er uafhængigt af operativsystem og hardware, mens .Net er Microsoftskonkurrerende platform, der baseres på det eksisterende VB og det nye C#(også fra Microsoft). I Mølsted [2002] refereres til erfaringer fra konsulenthusetTietoEnator, som umiddelbart viser, at det er svært at fremhæve den ene fremfor den anden af de to platforme.

Brugeren vil i sidste ende næppe kunne mærke forskel på, om værktøjet er ud-viklet på den ene platform eller den anden – især fordi dokumentationsværktøjet

125


ikke fordrer store realtidsprocesser, som kræver en meget optimal kode. Deri-mod 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 udvikleværktøjet.

8.2.2 Økonomi og tid

Egenudvikling er med største sandsynlighed den dyreste løsning. Forud for im-plementeringen skal alt designes, og implementeringen indebærer udvikling afhele systemet. Naturligvis findes der givetvis færdige moduler, der kan bruges ilø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 genstandfor megen opmærksomhed såvel i erhvervslivet som i forskningsmiljøer. Dereksisterer en række forskellige estimeringsmetoder, bl.a. Function Point Analy-sis (FPA), Walston-Felix og COnstructive COst MOdel (COCOMO) og COn-structive COst MOdel, ver. 2 (COCOMO2). Disse er alle beskrevet i van Vliet[2000] og baseres på en generel formel af formen

E = (a + bKLOCc)f(x1, . . . , xn)

hvor E er udtryk for den nødvendige indsats (effort), som oftest udtrykt i man-demåneder; KLOC står for kilo-lines-of-code i det endelige system; a, b ogc er konstanter og f(x1, . . . , xn) er en korrektion afhængig af værdierne forx1, . . . , xn.

Formlens grundform E = a + bKLOCc er fremkommet ved brug af regres-sionsanalyse1 af eksisterende projektdata, og som det fremgår af formlen, erden primære faktor størrelsen af projektet, målt i antallet af kodelinjer. Dettenominelle estimat korrigeres for en række omstændigheder med de forskelligeomkostningsfaktorer (cost drivers), som udtrykkes med f(x1, . . . , xn)2.

f(x) kan f.eks. have formen∏

iomkostningsfaktori som udtryk for, at den

samlede korrektionsfaktor er et produkt af i omkostningsfaktorer. F.eks. er deri Walston-Felix modellen identificeret 29 variable, som indvirker på produkti-viteten (brugergrænsefladens kompleksitet, medarbejdernes erfaring, andelen afbrugerinitierede ændringer etc.) [van Vliet, 2000, s. 157].

Forskellige modeller har forskellige værdier af a, b og c (se figur 8.2 på følgendeside), og det er ifølge van Vliet [2000] svært at sammenligne modellerne, da debygger på meget forskellige (og ofte udokumenterede) forudsætninger. Fælles foralle 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ængmellem flere variable.

2 F.eks. kunne en af faktorerne udtrykke udviklingsgruppens erfaring ved at antage værdierne1.50, 1.00 eller 0.50 for henholdsvis et lavt, gennemsnitligt eller højt erfaringsniveau [vanVliet, 2000].

126

8.2 Egenudvikling

et stort kendskab til det miljø, hvor systemet skal udvikles, for at eliminereusikkerheder, 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ævendeproces, har især COCOMO2 og FPA fundet bred anvendelse – men forudsætterstadig, at personerne, der anvender dem, har et solidt kendskab til den udfør-ende organisation og tillige stor erfaring med systemudvikling og estimering [vanVliet, 2000].

Halstead E = 0.7KLOC1.50

Boehm E = 2.4KLOC1.05

Walston-Felix E = 5.2KLOC0.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 fornuftigtestimat af omkostningerne for egenudvikling, som kan lægges til grund for envurdering af projektet. Et meget overordnet estimat kan dog baseres på deopstillede brugsmønstre. I Longstreet [2001] beskrives, hvordan brugsmønstrekan bruges som grundlag for en FPA, og i en tabel opstilles en erfaringsmæssigsammenhæ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, somdækkede den centrale funktionalitet af dokumentationsværktøjet, hvilket ifølgeLongstreet [2001] svarer til 5.000 FPs. I van Vliet [2000, s. 168] nævnes som ettypisk estimat, at ét FP svarer til 29 linjer C++-kode. 5.000 FPs vil såledessvare til omkring 145.000 linjer C++-kode.

Hvis vi herefter regner med, at en programmør effektivt kan producere 80 linjerkode 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 etstørre programmeringssprog. Systemet fyldte 220.000 linjer kildekode (i standard C), togfire år at udvikle og kostede DKK 42 mio.

127


tage 1.813 mandedage eller 91 mandemåneder (med 20 arbejdsdage pr. mande-måned).

Antager vi, at en mandemåned koster DKK 100.0004, vil udviklingen af do-kumentationsværktøjet fra bunden dermed koste omkring DKK 9 mio. (ekskl.moms).

En sådan udviklingstid og omkostning vil med al sandsynlighed diskvalificereegenudvikling som en mulighed. Dog skal der huskes på, at estimatet er utroligtusikkert. For at lave et mere pålideligt estimat er det som nævnt nødvendigtbl.a. at kende mere til den virksomhed, der skal udvikle systemet. Estimatet herbø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 tilpasseeksisterende systemer. Hvis man med tilpasning af et (eller en kombination afflere) eksisterende system(er) kan udvikle et system, der tilbyder den ønskedefunktionalitet, kan der være store ressourcer at spare – både økonomisk og tids-mæssigt. Ved at basere udviklingen på et eksisterende system elimineres risikoenfor at genopfinde hjulet alt for mange gange, samtidig med at funktionalitetenog stabiliteten i systemerne (fra en pålidelig leverandør) er gennemtestet ogdokumenteret. Herudover fås også automatisk en kompetent medspiller i ud-viklingsforløbet, idet købet af et eksisterende system vil give mulighed for attræ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, somumiddelbart understøtter mange af de funktionaliteter, der blev opstillet somkrav i kapitel 7. Rational Rose, som er et af de mest populære CASE-værktøjertil udvikling af informationssystemer, da et dokumentationsværktøj til produk-tmodellering – som det fremgår af de tidligere kapitler – har meget tilfælles medet CASE-værktøj. Og endelig MS Visio som et avanceret diagrammeringsværk-tøj, der har rige muligheder for udvidelser og tilpasninger (herunder integrationmed databaser).

8.3.1 Lotus Notes

Lotus Notes, som siden 1995 har været ejet af IBM, anvendes i Niro og APC somvirksomhedernes centrale kommunikations- og dokumenthåndteringssystem (læsmere om deres tilpasning til produktmodellering i afsnit 6.1 på side 70). Syste-met er et avanceret client/server-baseret informationssystem med den centralefunktionalitet 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 ud-faktureret beløb på 2,5 gange månedslønnen (her DKK 40.000) til at dække overhead.

128


Filosofien bag Notes’ arkitektur er, at systemet skal være opbygget af en række“byggeklodser” af funktionalitet, som brugeren herefter selv kan sammensættetil 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 atopnå den ønskede funktionalitet [IBM, 2002].

En Notes-implementering består i grove træk af en Domino-applikationsserverog et antal Notes-klienter, som skal konfigureres og tilpasses den enkelte virk-somheds behov. Som dokumenthåndterings- og informationssystem understøt-ter Notes uden problemer funktionalitet som versionsstyring og adgangskontrol(som beskrevet i forbindelse med APC og Niro). Den største udfordring vilderfor være at lave en grafisk brugergrænseflade til Notes, som understøtter ak-tiviteterne omkring PVM og klassediagram. Hos APC og Niro, hvor man harNotes-udviklere ansat, har man ikke erfaring med lignende udfordringer. Heltoverordnet er det dog muligt at lave en applikation i Java, som kan kommunikeremed den underliggende Domino-server5, omend det nok vil være en stor opgave.

Der findes dog et produkt (Lotus Workflow), som er beregnet på tilpasning afNotes til virksomhedens arbejdsgange, som måske kan være nyttigt. Med detteprodukt 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 etdokumentationsvæ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 mulighedenfor at opbygge en brugergrænseflade, der giver mulighed for at arbejde grafiskmed PVM og klassediagram. Mange af de mere datanære funktionaliteter erallerede 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 un-derstøtte aktiviteterne under udvikling af informationssystemer i næsten allefaser af projektlivscyklussen6. Et af disse programmer er Rose, som er et CASE-værktøj, der overordnet set består af funktionalitet til at udvikle og vedligeholdeUML-diagrammer og generere kode baseret på diagrammerne. Hertil kommerfunktionalitet som f.eks. adgangsstyring og versionsstyring.

I sin grundform lægger hele Rationals pakke af produkter i Rational Suite Enter-prise op til et flerbrugermiljø i enten et MS Windows- eller Unix-miljø. RationalRose tager udgangspunkt i UML-notationen, men kan tilpasses på forskelligemåder, som illustreret i figur 8.3 på følgende side.

Med scripts er det muligt at automatisere Rose-specifikke funktioner og udførefunktioner, som det ikke umiddelbart er muligt at tilgå via den normale bruger-græ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 web-klienten til Notes er opbygget i Java.

6 Rational har udviklet Rational Unified Process (RUP), som er en metodologi for udviklingaf informationssystemer.

129


Rational Rose

ExtensibilityInterface

RationalRose

ScriptRational

Rose

AutomationRational

Rose

Add-in

RationalRose

Application

Diagrams

ModelElementsActiveX DLL

Kan laves med f.eks.Visual Basic

Script-udsagn i rentekst

Kald af OLE automationsobjekterfra scripts eller eksterne

applikationer

Rational Rose

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 ek-sterne applikationer som f.eks. Word og VB. For det andet er det muligt at ladeRose fungere som OLE-server, så man fra andre applikationer kan tilgå RosesOLE-objekt.

Roses mulighed for at tilføje add-ins er dog nok det mest interessante i for-bindelse med et dokumentationsværktøj. Hvert af disse moduler er et ActiveXDynamic Linked Library (DLL) og kan udvikles i ethvert programmeringssprog,hvorfra der kan genereres et ActiveX DLL, f.eks. VB [Conallen, 1999]. Enestekrav er, at der skal inkluderes en offentlig grænseflade, der kan kommunikeremed Rose.

Som et CASE-værktøj til udvikling af objektorienterede systemer understøt-ter Rose naturligvis udviklingen af klassediagrammer perfekt. Udfordringen vilderfor sandsynligvis primært bestå i at kunne tegne en PVM, hvor det vil værenødvendigt at kunne definere reglerne og syntaksen for diagrammet i Rose. Dethar 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 mu-lighederne i Rose, drejer sig om, hvorvidt Rose understøtter, at modellens in-formation gemmes i en database. Som standard lagrer Rose informationernefra en objektorienteret model i et hierarki af filer i Roses eget filformat. Deter dermed muligt at opdele en model i undermodeller og kontrollere adgangentil disse. Dette betyder, at det umiddelbart er muligt at styre adgangen påklassediagram-niveau7, men hvorvidt det er muligt at basere Roses diagrammerpå information fra en ekstern database er mere tvivlsomt.

7 For hver undermodel (klynge) gemmer Rose elementerne i filer i en separat mappe, ogmappestrukturen afspejler således klyngestrukturen i modellen.

130


«¬ ¬ ®¤¯ ¬ ° ± ² ± ³¤´ ¬ µ ¶�· «�¸�¯

¹ º" » ² º ¼ ² ± ¼¾½�¸¤¿(¬ º ¼ ® À� Á�¯ ¯ ÂÃ ¬ µ Ä Å ¶ Æ ¬ ¶ µ » » ¬ µ Å ² ¶ » «¬ ¬ ® ·Ç ³ Å ¬ È� È ± ¶ É ¶ » ¬ Ê¾¶ µ µ ¶ ± Ê�Ë Ë ·

¹ Ì ¶ Æ Í » ² ° µ ¶Î· ¹ Ï�¹

Ð�¼ ¼ Â ¬ º

½�¸¾«¬ ¬ ®¤Ñ Ò Ò Ñ

Ó*Ô�Õ"Ö ×Ö Ø

Ù¾Ú�Ú�Û Ö Ü

Ù¤Ú�Ú�Û Ø�Ü

Á�Ý�½�¸

Þ'ÁÝÊ

«¬ ¬ ® Â ¼ ® È Í ß ¶ º »ß"¶ ¼'«Ý�Ð�Â È ® ¼ ¶

¹ º" » ² º ¼ ² ± ¼ ¶ È ¶ È É ¶ ± ° ² ± Ã ¬ µ Ä ¼ ¶ ±¶ È ¶ È É ¶ ± ¶ �Ã ± ²�«�¬ ¬ ®¤ß"¶ ¼"¶ º

È ® ß ß"² º ¼ ® » ± ¶ º à ·á�² º" È ± ¬ É ¶ ¬ ¶ » â É ¶ ± » Å ± ® à Ä¼ ¶ ± Í º ¼ ¶ ± » ã » » ¶ ± ä�å æ ç è é æ ê ç ë ÄÃ · ¶ È · «Ý�Ä Ê ì ÊË Ë ¶ µ µ ¶ ± í Ë Ë · ¹ »�Ê Þ'½�Â ® ° î ¶ È » ß ¶ ¼ ¶ º

«¬ ¬ ® Â Å ¶ Æ ¬ Ã ¬ È�à ± ï¾º ¶ Ã µ ² ¼ ¶ ·á�² º È ± ¬ É ¶ ¬ ¶ » â É ¶ ± »�½�¬ Æ ± ® ® Ã » Â ß"¬ µ î ã Ä¼ ¶ ± È ² º¤µ ² É ¶"Ê Þ'½�Â ® ° î ¶ È » ¶ ± Ä Ã · ¶ È · «Ý Ð

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 flow-charts og er for nyligt blevet opkøbt af Microsoft. Visio 2002 er det nyeste skudpå 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 PVMog klassediagram, og med relation til det sidste kan Visio faktisk fungere som etCASE-værktøj, idet der eksisterer en meget veludbygget skabelon (inkl. funktio-nalitet) for UML. På den grafiske side kan Visio tilfredsstille alle kravene til etdokumentationsværktøj – også med hensyn til udskrivning i stort format. Denstørste udfordring bliver derfor givetvis at kunne tilpasse Visio med hensyn tilintegration med databasesystemer samt funktionalitet som versionsstyring ogadgangsstyring. Visio har flere muligheder for udvidelser og tilpasninger somillustreret i figur 8.4.

Add-ons som .EXE eller .DLL-filer fungerer på samme måde som et program, dereksekveres 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-oner vist i figur 8.6 på følgende side, som stammer fra Visios omfattende skabelontil UML-diagrammer. Med dette add-on kan alle egenskaber for en klasse i etklassediagram ændres. Ved tryk på ‘OK’ opdateres modellen.

Et Visio-dokument med Visual Basic for Applications (VBA)-kode giver en lig-nende funktionalitet, men indlejrer koden i det enkelte dokument og er derforikke egnet til en kompleks funktionalitet, der skal være tilgængelig (og nem atopdatere) for mange brugere.

Et add-in er et Component Object Model (COM)-objekt, som kan startes op afVisio, 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 skalkopieres til et klassediagram).

131


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 ele-menter (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. Etudpluk er vist i figur 8.5. Her ses det bl.a., at add-on’et fra figur 8.6 kaldes, nårder dobbeltklikkes på en klasse (tabellen Events, cellen EventDblClick). Visiosmulighed for integration med en ekstern database består i, at indholdet af Sha-peSheet’et kan hentes fra en database, ligesom databasen kan opdateres efterredigering af en tegning i Visio. Al kommunikation foregår via ODBC, men Visiokan ikke selv foretage SQL-kald [Grabowski, 1998a,b].

Visio understøtter ikke funktionalitet som adgangsstyring, versionskontrol el-ler rapportgenerering. Denne funktionalitet vil skulle implementeres via f.eks.add-ons eller i databasesystemet. Til gengæld kan Visio stort set imødekommealle andre krav for dokumentationsværktøjet – inkl. muligheden for at linke tilinternetressourcer og eksterne filer.

132


8.3.4 Økonomi og tid

Ved at basere dokumentationsværktøjet på et eksisterende system vil et estimataf de økonomiske konsekvenser bestå af to overordnede dele: Udgifter ved an-skaffelse af standardsystemet og udgifter til tilpasning af systemet. Den førstedel er meget overskuelig at estimere, mens den anden kræver mere kendskab ogen dybere analyse af mulighederne i de enkelte systemer og en mere detaljeretsammenkobling af disse med kravene i kravspecifikationen.

I tabel 8.1 på følgende side er opstillet en sammenligning af udgifterne til an-skaffelse af de forskellige systemer. Priserne er alle ekskl. moms og dækker kunden 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øttesaf 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 konfigu-rering.

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 anskaf-felse, mens Rose og Visio ligger tæt op ad hinanden. Der er dog stadig mangeukendte variable, som skal afklares, før en endelig beslutning kan tages. Samtidigfremgår det, at Visio er klart den billigste løsning, hvis vi ser på et prototype-projekt, hvor der ikke skal bruges så mange licenser, da den totale pris ganskeenkelt skaleres lineært efter antallet af brugere (dog mindst fem). Det er dogsvært at sammenligne løsningerne, da især Notes og Visio tilbyder noget funk-tionalitet, 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 kanbruges i mange andre sammenhænge.

På baggrund af gennemgangen af mulighederne for de tre systemer virker Notesog 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æggesnærmere før en endelig beslutning kan tages. Herudover kommer analyse afde økonomiske omkostninger ved at tilpasse de to systemer til opgaven. Endetaljeret analyse af de økonomiske konsekvenser ligger uden for rammerne afdenne rapport, men for at give et indtryk af opgavens størrelse, vil jeg kortpræsentere et estimat for tilpasning af Visio, der er blevet udarbejdet af ThorkildGrothe Møller (udvikler hos Invensys/Baan).

133


Rational Rose

EngangsudgiftRational Rose Professional (J Edition)a 31.520

Årlig udgiftSupportlicensb 6.320

I alt, første år 37.840

Information fra Rational Software, august 2002

Lotus Notes

EngangsudgiftDomino Application Server 20.23925 stk. Notes-licenser (trade-in) 634Lotus Workflow CAL 721

Årlig udgift– 0


Information fra IBM Danmark, september 2002

Microsoft Visio

Engangsudgift25 stk. MS Visio 2002, Standard Editionc 35.300

Årlig udgift– 0


Information fra Eterra A/S, september 2002

Alle priser er DKK ekskl. moms.

a Prisen er for floating licenser, hvor der opsættes en licensser-ver (gratis), som sikrer, at antallet af samtidige brugere ikkeoverstiger 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 Visioer vist i tabel 8.2 på følgende side8. Som det fremgår, vil det koste ca. DKK264.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 forbindelseer det vigtigt at holde for øje, at en udvikler fra en ekstern organisation ikkearbejder 100% på opgaven, men også skal bruge tid på f.eks. møder og lign. i sinegen organisation (hvilket der naturligvis ikke skal betales for). Den effektivearbejdstid svarer således til måske fire dage om ugen9. Bruges denne sats, vil de

8 Tidsestimatet er lavet af Thorkild Grothe Møller (udvikler hos Invensys/Baan), som hardeltaget i arbejdet omkring udviklingen af dokumentationsværktøjet.

9 Ifølge erfaringer fra en tidligere medarbejder hos Novo Nordisk IT.

134


Opgave Tidsforbrug Udgifta

Tilpasning til grafik

PVM 5 dage 30.000Klassediagram 5 dage 30.000CRC-kort 5 dage 30.000 90.000


Udvikling af databaseunderstøttelse 4 dage 24.000 24.000Brugerdatabase

Opsætning af Visio med login og roller 4 dage 24.000 24.000Datastyring (PDM-funktionalitet)

Adgangstyring, versionsstyring, log 20 dage 120.000 120.000Udskrift

Konfigurering af Visio til udskrift 1 dag 6.000 6.000I 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 enAdvanced 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 afopgaverne i tabel 8.2 med tilsvarende milepæle, så man undervejs i forløbet kanlancere prototyper af dokumentationsværktøjet med stigende funktionalitet.

Størst usikkerhed ligger der omkring estimatet af tilpasningen af datastyrings-funktionaliteterne. Som nævnt i afsnit 8.3.3 på side 131 skal denne funktionalitetimplementeres i moduler uden for Visio (f.eks. ved hjælp af add-on’s eller i da-tabasesystemet), og det vil kræve en nærmere analyse af mulighederne for atkunne gøre dette estimat mere præcist.

Med et estimat på DKK 120.000 udgør denne post op mod halvdelen af den sam-lede omkostning for tilpasning af systemet, og man kunne derfor overveje omdet ville være hensigtsmæssigt at opbygge en prototype uden disse funktioner.Hermed kunne en del af de centrale funktionaliteter afprøves til en overkom-melig pris. Sideløbende kunne mulighederne for datastyringsfunktionaliteterneundersøges og evt. efterfølgende implementeres.

135


8.4 Projektorganisation

Efter at kravene til dokumentationsværktøjet er klarlagt, forskellige implemen-teringsscenarier er opstillet, og estimater af økonomi samt tidsforbrug er lavet,melder et nyt spørgsmål sig: Hvordan skal projektorganisationen bag projek-tet udformes? Der er et par problemstillinger, som bør haves i baghovedet, nårspø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 vilhave mulighed for at finansiere projektet alene – ikke på det nuværende grund-lag. En oplagt mulighed er derfor, at CPM går sammen med et antal virksom-heder om udviklingen. Alternativt kunne der tages kontakt til DTU Innovation,som primært investerer i opstart af forskningsbaserede projekter10.

Ad 2 CPM’s erfaringer inden for produktmodellering viser, at der eksisterer enmangel på et dokumentationsværktøj til produktmodellering. Ved at lave et tætsamarbejde mellem CPM og virksomheder med erfaring inden for produktmo-dellering sikres de optimale forhold for, at dokumentationsværktøjet udviklersig til et praktisk anvendeligt værktøj. Virksomhedernes engagement skal dogsikres – f.eks. ved at de engageres økonomisk i projektet og har medansvar forsucces.

Ad 3 Hvis behovet for et dokumentationsværktøj retteligt er så stort, som detantydes fra CPM, bør værktøjet være grundlag for en sund forretning. I den for-bindelse er det vigtigt at få afklaret, hvem der har rettighederne til den fortsatteudvikling af værktøjet. Af hensyn til CPM’s videre arbejde inden for områdetbør dette forhold vurderes nøje. På den ene side har CPM ikke kompetencerinden for udvikling af informationssystemer og vil derfor have svært ved at løfteopgaven som en stabil leverandør af værktøjet. På den anden side har CPM enenestående viden inden for produktmodellering, som kan gøre dokumentations-væ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 sam-arbejde med en kompetent IT-udviklingsvirksomhed. En mulighed kunne væreConfigIT11, som er et spin-off fra IT-højskolen i København. Som samarbejds-partner 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 umiddelbartdet indtryk, at deres tilgangsvinkel til konfigurering er via systemudvikling ogmatematiske algoritmer frem for produktmodellering. Et samarbejde med CPMkunne 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 dokumen-tationsværktøjet, og det vil da bl.a. være CPM’s rolle at finde kompromiser ogsøge den bedste fælles løsning.

For at kunne varetage denne rolle bør CPM også påtage sig ansvaret som pro-jektleder og koordinere aktiviteterne.

Ad 5 Projektet indeholder meget materiale, som kunne bruges i eksamenspro-jekter eller specialkurser. Internt på IPL kunne f.eks. i et specialkursus lavesdetaljerede undersøgelser af mulighederne med Lotus Notes og Visio. Såfremtman ønsker at satse på egenudvikling, er både designog implementeringsop-gaven en spændende udfordring for eksamensprojekter i samarbejde med IMM.Opbygningen af en forretningsplan kunne også være et spændende emne for etspecialkursus, eller evt. i samarbejde med kursus 42435 Virksomhedsstart påDTU.

Fordelen ved eksamensprojekter er, at man ofte får en meget grundig løsning afproblemstillingen, da de projektstuderende typisk kan fordybe sig mere i emneti forhold til en ansat i en virksomhed (pga. økonomi). Samtidig betyder det dogogså, 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 in-teresse i at deltage i et udviklingsprojekt. For at virksomhederne skal bibeholdeinteressen for projektet, skal der være et synligt resultat, som kan anvendes ivirksomhedens aktiviteter. Der bør derfor laves en forretningsplan, der beskriverprojektet, ø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 etsamarbejde med Niro, APC, F.L. Smidth og Vitral om det fremtidige arbejdeomkring dokumentationsværktøjet. Aftalen kunne lyde på, at man i fællesskabudviklede version 1.0 af dokumentationsværktøjet, som derefter kunne brugesvederlagsfrit af parterne. Virksomhederne kan frit videreudvikle på version 1.0til eget brug, men CPM skal sikres rettighederne til den videre udvikling. Her-med har CPM et grundlag for udvikling af fremgangsmåden for opbygning afproduktmodeller 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 investeringskapitalfra ACR Capital [Svarre, 2002]. Læs mere om ConfigIT på www.configit-software.com.

137


Dokumentationsværktøjet bør ikke ses som et isoleret produkt, men en del af enportefølje, som består af dokumentationsværktøjet og undervisning i anvendelseaf fremgangsmåden. Som et forskningsbaseret center er CPM’s primære målikke at udvikle et produkt, der kan skabe størst mulig profit, men snarere atdeltage i udviklingen af viden og produkter, som bliver anvendt i videst muligtomfang. Derfor skal evt. rettigheder til produktet ligge hos CPM frem for hosen kommerciel virksomhed.

8.5 Afrunding

I et samarbejde som beskrevet ovenfor bør den første opgave bestå i en meredetaljeret analyse af mulighederne for anvendelse af et eksisterende system sombasis for dokumentationsværktøjet. Valget af de tre standardsystemer er ikkebaseret på en bred markedsanalyse af mulighederne, men på umiddelbare erfa-ringer fra projektet. Især virker Lotus Notes og Visio lovende, og der bør ofrestid på en nærmere analyse af især

- Muligheder for rapportgenerering, adgangskontrol og versionsstyring medVisio.

- Muligheder for udvikling af en grafisk brugergrænseflade til Notes, somunderstøtter diagrammerne i produktmodellering.

Herefter kan laves et mere retvisende estimat af økonomien i projektet og enefterfølgende vurdering af, hvilken funktionalitet de enkelte versioner af doku-mentationsværktøjet skal have (baseret på prioriteringen i afsnit 7.7 på side119).

Dokumentationsværktøjets succes er uløseligt forbundet med brugernes aner-kendelse og accept af CPM’s fremgangsmåde for opbygning af produktmodeller.Som det fremgår af kravspecifikationen skal dokumentationsværktøjet nok værefleksibelt og give brugerne frihed til at følge deres fremgangsmåde, men værk-tøjet er fokuseret omkring brugen af PVM, klassediagram og CRC-kort somdokumentation for produktmodellen, og såfremt anvendelsen af disse ikke vin-der accept, vil dokumentationsværktøjet selvsagt heller ikke blive en succes.

Andersen og Jensen har i deres rapport konkluderet, at såvel CPM’s fremgangs-måde som dokumentationsform er hensigtsmæssig til produktmodellering [An-dersen og Jensen, 2001, s. 118]. Ligeledes har flere projekter ved CPM underbyg-get dette, hvorfor der er al mulig god grund til at tro på såvel fremgangsmådenssom dokumentationsværktøjets berettigelse. Men de to skal leve i symbiose:Uden fremgangsmådens succes, intet dokumentationsværktøj, og uden doku-mentationsvæ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 stillestil et dokumentationsværktøj til produktmodellering. I indledningen (side 3)blev problemformuleringen opstillet, bestående af tre spørgsmål, som jeg her vilbesvare:

1 – Dokumentationsværktøj og krav til dokumentationsværktøj

Blandt de deltagende virksomheder arbejder især Niro og APC struktureret medderes opbygning af produktmodeller og dokumentation af disse. Niro og APChar til formålet udviklet et dokmentationsværktøj i Lotus Notes, der kan hånd-tere 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 do-kumentation, men er med baggrund i denne erfaring enige i, at en struktureretfremgangsmåde og dokumentation er den rigtige løsning. Der er bred enighedom, at opbygning og vedligeholdelse af dokumentationen er en flaskehals i pro-cessen, som kan løses med et dedikeret dokumentationsværktøj.

På baggrund af analysen af virksomhedernes produktmodelleringsprocesser ogfremgangsmåden er lavet en specifikation af kravene til et dokumentationsværk-tø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 stan-dardsystemer: Lotus Notes, Rational Rose og MS Visio. Af disse virker LotusNotes og MS Visio mest lovende, og vil med tilpasning kunne imødekomme langtstørstedelen af de opstillede krav.

Med baggrund i opsummeringen i afsnit 8.5 vil jeg foreslå at man satser på enudvikling af dokumentationsværktøjet i Lotus Notes. Forinden skal dog afklareshvordan brugergrænsefladen kan tilpasses. Dette kan gøres i en gruppe beståendeen systemanalytiker (med indsigt i denne kravspecifikation), Notes-udviklere fraf.eks. Niro og APC, samt evt. Notes-eksperter fra IBM.

Satsningen på Lotus Notes giver en løsning, der er fleksibel og baseret på etpålideligt standardsystem. Samtidig kan systemet bruges i andre sammenhængei virksomheden, og er samtidigt overraskende billigt i anskaffelse.

APC’s Notes-løsning har samtidig vist, at man kan opnå den ønskede integra-tion med virksomhedens ERP-system (i CRC-kortene). Integrationen mellemdokumentationsværktøj og konfigurator anses ikke som et essentielt krav, menvirksomhederne er dog enige om, at der kan spares meget arbejde ved at kunneeksportere information fra dokumentationen til konfiguratoren. Funktionalitetenkan opnås ved at give mulighed for, dels at konfiguratorer selv tilgår dokumen-tationsværktøjets produktmodeldatabase (via ODBC), dels ved at det er muligtat 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 implemente-ringsalternativer, hvoraf fire er skitseret i denne rapport. Ud over de tre stan-dardsystemer 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 skaludvikle systemet. Et estimat anslår omkostningerne til DKK 9 mio. Dette skalses i forhold til f.eks. en tilpasning af MS Visio, der estimeres til en omkostningpå omkring DKK 300.000 (ekskl. moms, inkl. 25 licenser).

I forbindelse med den videre udvikling foreslås, at CPM indgår et samarbejdemed interesserede virksomheder og evt. DTU Innovation. Hertil kan evt. kobleset sofwarefirma for at sikre ressourcer til den løbende udvikling. Denne konstel-lation vil udgøre et slagkraftigt miks af forsknings- og erhvervsmæssig erfaringog samtidig gøre projektet økonomisk muligt.

Dokumentationsværktøjets succes er 100% afhængigt af brugbarheden af do-kumentationen i CPM’s fremgangsmåde (PVM, klassediagram og CRC-kort).Samtidig gør dokumentationsværktøjet fremgangsmåden mere attraktiv, og deto bør derfor udvikles sideløbende.

142

Kapitel 10

Perspektivering

Udviklingen af dokumentationsværktøjet lægger op til et spændende samarbejde Spændendesamarbejdemellem CPM og et antal virksomheder. Samarbejdet rummer store muligheder

for at styrke såvel værktøjet og fremgangsmåden for udvikling af produktmo-deller, samt arbejdet inden for produktmodellering.

I forbindelse med udviklingsarbejdet bør der holdes et vågent øje med udviklin- Konkurrence frakonfiguratorergen af konfiguratorerne, og især de tilhørende modelleringsværktøjer. Modelle-

ringsværktøjet i iBaan har allerede mulighed for at vise (meget) simplificeredeklassediagrammer for objekterne i modellen. I sin nuværende udformning vilmodelleringsværktøjet dog næppe udgøre en reel trussel mod et dedikeret do-kumentationsvæ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 dokumenta-tionen med implementeringen. Funktionaliteten er meget kompleks og gøres ikkelettere af at hver konfigurator lagrer den underliggende produktmodel forskel-ligt. Der kan dog givetvis spares mange ressourcer ved (delvist) at automatiseresammenkoblingen af dokumentation med konfigurator, og det vil derfor væreoplagt at arbejde videre med denne mulighed fremover.

En yderligere udbygning af dokumentationsværktøjet ville bestå i muligheden Tilknytning afrelationsmodellerfor at kunne tilknytte forskellige relationsmodeller til produktmodellen. På den

måde vil man kunne konfigurere produktet i “flere dimensioner” og med hen-syntagen til flere aspekter af produktlivscyklussen (f.eks. montage og miljøkon-sekvenser).

I en fremtidig version af dokumentationsværktøjet ville det være oplagt at ind- Opdeling iundermodellerbygge muligheden for at dele modellen op i undermodeller. På den måde kan

der arbejdes med en overordnet produktmodel, hvor ansvaret for de underlig-gende modeller uddelegeres til de enkelte afdelinger, eller måske endda eksternevirksomheder.

Alt i alt er der mange muligheder for at udbygge værktøjets funktionalitet mo-dulært i takt med brugernes behov og værktøjets succes.

143

Forkortelser

API . . . . . . . . . . Application Programming Interface

Et sæt af rutiner i et system, som kan kaldes af andre syste-mer. Rutinerne kan f.eks. udveksle data eller udføre opgaver.Operativsystemer har f.eks. API’er til forskellige filoperatio-ner, og programmøren skal dermed ikke bekymre sig om denkomplicerede håndtering.

CASE . . . . . . . . Computer Aided Systems Engineering

Enhver anvendelse af IT til at automatisere og støtte en ellerflere aktiviteter i projektlivscyklussen i forbindelse med sy-stemudvikling. Nogle steder ses også udskrivningen Computer

Aided Software Engineering, men i denne rapport bruges denførste oversættelse. Se også CASE-værktøjer.

CMM . . . . . . . . Capability Maturity Model

En strukur for vurdering af hvor gode virksomheder er til at ud-vikle informationssystemer. CMM placerer en virksomhed pået af fem niveauer, hvor niveau 5 er det bedste. I CMM læggesvægt på, at virksomheden er god til at anvende metodologiersom basis for udviklingen og evner at genbruge erfaringer fratidligere projekter.

COCOMO . . COnstructive COst MOdel

En algoritmisk model fra 1981 til estimering af omkostningeri forbindelse med udvikling af informationssystemer. Er megetveldokumenteret, læs evt. mere i van Vliet [2000, s.158].

COCOMO2 . COnstructive COst MOdel, ver. 2

En videreudvikling af den originale COCOMO (se denne) forat tilpasse modellen til projektlivscyklussen for 1990’erne ogdette årti.

145

Forkortelser

COM . . . . . . . . . Component Object Model

Microsofts standard for udveksling af information mellem ob-jekter (“bag” brugergrænsefladen). Herunder forhandlinger mel-lem grænseflader, styring af livscyklus (for objekter) og hånd-tering af hændelser og licenser.

COTS . . . . . . . . Commercial Off The Shelf

Betegnelse for produkter, der ikke kræver egenudvikling, menkan købes færdige til at understøtte en eller flere forretnings-funktioner. Et (ultimativt) eksempel er ERP-systemer.

CPM . . . . . . . . . Center for Produktmodellering

CVS . . . . . . . . . . Concurrent Version System

Et versionsstyringssystem udviklet som open-source-projekt.Dvs. at kildekoden er tilgængelig og kan anvendes under lempe-lige betingelser. CVS er client/server-baseret, og der findes kli-enter til de fleste styresystemer. Se mere på www.cvshome.org

DLL . . . . . . . . . . Dynamic Linked Library

Samling af små computerprogrammer, som typisk bruges afflere store computerprogrammer. De små programmer kaldesefter behov fra det store program, og derved kan ressourcerdeles og optimeres.

DTU . . . . . . . . . Danmarks Tekniske Universitet

ERP . . . . . . . . . . Enterprise Resource Planning

American Production & Inventory Control Society (APICS)definerer ERP som “. . . identifying and planning the enterprise-

wide resources needed to take, make, ship, and account for cu-

stomer orders”. Se også ERP-system.

FPA . . . . . . . . . . Function Point Analysis

En metode til estimering af omkostninger i forbindelse medudvikling af informationssystemer. Baseres på en vurdering afmængden af Function Points (FPs), som svarer til forskelligedatastrukturer (input-typer, output-typer, forespørgselstyper,logiske interne filer og grænseflader). Hermed fjernes fokus fraen direkte estimering af antallet af linjer kildekode (lines-of-

code, LOC).

I-CASE . . . . . . 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 Ben-nett et al. [1999] er disse CASE-værktøjer ofte designet til brugi forbindelse med en bestemt fremgangsmåde, som f.eks. SA&Deller RUP (se disse).

146

Forkortelser

IDEF0 . . . . . . . Integration Definition for Function Modelling

Standard for funktionsmodellering fra National Institute ofStandards and Technology. Blev lanceret i 1993 som FederalInformation Processing Standard (FIPS) og er dokumentereti FIPS 183. Metoden er beregnet på at modellere beslutnin-ger, handlinger og aktiviteter for organisationer eller systemer.IDEF0 er baseret på de grafiske elementer bag Structured Ana-lysis & Design (se SA&D) og er også velegnet som kommunika-tionsværktøj pga. de få, enkle grafiske elementer og den simpleopbygning.

IE . . . . . . . . . . . . Information Engineering

En datacentreret – men dog procesfølsom – teknik til model-lering af (forretnings)krav og design af systemer, der opfylderdisse. Kravene dokumenteres i Entity relationship diagrams.

IMM . . . . . . . . . institut for Informatik og Matematisk Modellering

IPL . . . . . . . . . . . Institut for Produktion og Ledelse

OCL . . . . . . . . . . Object Constraint Language

Formaliseret, deklarativt sprog i UML. Bruges i produktmo-dellering til at beskrive bindinger mellem klasser i et utvetydigtsprog, 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 . . . . . . . . . . Object Linking and Embedding

Et sæt af API’er (se denne), som udgør Microsofts standardfor udveksling af information mellem applikationer under Win-dows. Er en del af COM (se denne).

OMG . . . . . . . . Object Management Group

Et åbent, non-profit konsoritum, der udvikler og vedligeholderspecifikationer for IT-industrien. Blandt specifikationerne erUML (se denne).

PDM . . . . . . . . . Product Data Management

I løbet af en produktudviklingproces genereres og anvendesstore mængder data relateret til produktet. Data, som finderanvendelse i såvel udviklingsfasen som i alle efterfølgende faseraf produktets levetid. Herudover benyttes en rækker processertil strukturering af arbejdet. PDM dækker over håndteringenog kommunikationen af disse produktrelaterede data og pro-cesser i hele produktets livscyklus. Se også PDM-system.

147

Forkortelser

PVM . . . . . . . . . Produkt-Variant Master

Diagram, der afbilder et produkts struktur og funktion ved atopdele 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 godtpædagogisk kommunikationsmiddel. Bruges i de tidlige faser iproduktmodelleringsprojektlivscyklussen.

RUP . . . . . . . . . Rational Unified Process

En kommerciel metodologi for udvikling af objektorienteredeinformationssystemer. Udviklet hos Rational Software med the

three amigos (Booch, Jacobson & Rumbaugh) som hovedmænd.

SA&D . . . . . . . Structured Analysis & Design

Ifølge Whitten et al. [2001] to af de første formelle modelle-ringsteknikker. Den procesorienterede analysedel bruges til atafdække (forretnings)kravene til systemet. Disse dokumenteresi data flow diagrams. Designdelen er ligeledes procesorienteret,og her overføres analysemodeller til designmodeller, som doku-menteres i structure charts.

SDLC . . . . . . . . Systems Development Life Cycle

Et strukturelt skelet til beskrivelse af faserne i et projekt forudvikling og vedligeholdelse af informationssystemer.

SKU . . . . . . . . . Stock Keeping Unit

Et unikt nummer til identificering af produkter (især i forbin-delse med databaser).

SQL . . . . . . . . . . Structured Query Language

Struktureret forespørgselssprog til databaser. Er med tidenblevet de facto standard som forespørgselssprog til forespørgs-ler og vedligeholdelse af relationelle databaser.

STEP . . . . . . . . Standard for the Exchange of Product model data

Den populære betegnelse for ISO 10303. Standardens formål erat skabe ét neutralt filformat for udveksling af produktmodel-data, som kan anvendes i hele produktets levetid.

UML . . . . . . . . . Unified Modelling Language

En notation for elementerne i en objektorienteret systemmo-del. Hovedelementerne tæller usecase-diagrammer, klassedia-grammer, sekvensdiagrammer og tilstandsdiagrammer. Kan an-vendes som dokumentation for et objektorienteret system. UMLsamler de bedste ting fra the three amigos’s (Booch, Jacobson& Rumbaugh) objektorienterede metodologier i en fælles stan-dard. Mange tror fejlagtigt, at UML er en metodologi.

148

Forkortelser

UPS . . . . . . . . . . Uninterruptible Power Supply

En enhed, der placeres mellem en spændingskilde (f.eks. enstikkontakt) og en enhed (f.eks. en computer) for at beskytteenheden imod uønskede egenskaber i strømmen (f.eks. udfaldeller over-/underspænding).

VB . . . . . . . . . . . Visual Basic

Et højniveau-programmeringssprog fra Microsoft, som blev lan-ceret i 1991. Et relativt let tilgængeligt sprog, som har gjortudvikling af programmer til Windows-platformen meget let-tere.

VBA . . . . . . . . . Visual Basic for Applications

Et programmeringssprog fra Microsoft, der er en udvidelse afVisual Basic (VB, se denne) med henblik på hurtig udviklingaf Windows-applikationer.

WBS . . . . . . . . . Work Breakdown Structure

Fra Schwalbe [2000, s.92]: “A work breakdown structure (WBS)

is an outcome-oriented analysis of the work involved in a pro-

ject that defines the total scope of the project”. Med denne ned-brydning af arbejdet i overskuelige bidder har man et grundlagfor at planlægge og styre tidsplan, omkostninger og ændringeri forbindelse med ethvert projekt.

XML . . . . . . . . . eXtensible Markup Language

Et platform-uafhængigt sprog (ikke programmeringssprog) tilhåndtering af strukturerede data. I modsætning til HTML,som XML minder en del om, forbyder specifikationen af XML-applikationer at “gætte” på meningen af en ufuldstændig XML-fil. 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 vi-ser, at en klasse er en del af en anden klasse (part-of), men bindingener stærk, og underklassen kan derfor ikke eksistere uafhængigt af over-klassen, 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 dermedkan kommunikere), uden at de i øvrigt påvirker hinanden.

Brugsmønster Side 24

En adfærdsmæssig skevens af handlinger (et scenarie) – såvel automatise-rede som manuelle – med henblik på at beskrive en forretningsopgave. Bru-ges inden for objektorienteret modellering til at afdække de funktionellekrav til et informationssystem. Sammenhængen mellem brugsmønstre ogroller illustreres i et brugsmøsnterdiagram.

CASE-værktøj, Horisontalt Side 50

CASE-værktøj, der understøtter aktiviteterne i flere faser af projektlivscy-klussen eller et begrænset domæne. F.eks. et CASE-værktøj til opbygningaf 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, fejl-finding 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 pro-jektlivscyklussen. Understøtter aktiviteter som f.eks. opbygning af dia-grammer 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 delaf projektlivscyklussen eller et begrænset domæne. F.eks. et CASE-værktøjtil 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 udviklingaf systemer. Værktøjet er oftest udviklet til at støtte en bestemt frem-gangsmåde, og integrerer analyseog designfaserne ved at automatisereog/eller støtte tegning af diagrammer og systemmodeller og automatisereovergangen 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. informa-tion 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 maski-ningeniør med specifik viden om spraytørring. Begrebet bruges inden forsystemudvikling til at skelne mellem personer, der har viden om det do-mæne, hvor informationssystemet skal bruges (f.eks. maskiningeniøren),og de personer der har viden om systemudvikling (f.eks. analysekonsulen-ter og programmører).

ERP-system Side 42

Et informationssystem, der tilbyder funktionalitet til udførelse af aktivi-teterne forbundet med ERP (se denne). Et ERP-system er et kompliceretog omfattende informationssystem, der bruges bredt i virksomheden. Seogså ERP.

Generalisering Side 22

En relation, der angiver at en klasse arver egenskaber (metoder og/ellerattributter) fra en anden klasse.

Klasse Side 21

En gruppering (klassificering) af objekter med samme struktur, adfærds-mønster og attributter. Se også Klassediagram.

152

Ordforklaring

Klassediagram Side 25

Viser en struktur af klasser med deres indbyrdes relationer af forskelligart. Se også Klasse.

Klynge Side 26

UML-element dækkende over et antal sammenhængende klasser, der udgøren 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 un-derliggende produktmodel består typisk af en række attributter (typiskorganiseret i en hierarkisk træstruktur), som relateres gennem en rækkebindinger, der også begrænser attributværdierne. Langt størstedelen afalle konfiguratorer er af denne type (bl.a. alle konfiguratorer fra Cincomog Oracle samt Baans tidligere udgaver).

Konfigurator, objektorienteret Side 35

Dækker over konfiguratorer, hvor en underliggende produktmodel er ob-jektorienteret (i modsætning til konventionelle konfiguratorer) og dermedopbygget af klasser, der indeholder attributter og metoder (bindinger).Sammenhørende information er således samlet i logiske enheder (klas-ser). 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. Ele-mentet kan f.eks. være et produkt (som udvikles, produceres og til slutskrottes) eller et projekt (bestående af faser som opstart, udvikling, im-plementering og afvikling).

Metadata Side 60

Betyder “data om data” og anvendes f.eks. om de informationer, der fin-des 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 formelog præcis definition af udviklingsprocessen med angivelse af aktiviteter,metoder, best practises, målsætninger, og hjælpeværktøjer. Anvendelsenaf en metodologi sikrer, at en konsistent og gentagelig fremgangsmådeanvendes til alle projekter.

Modeldrevet udvikling Side 53

En overordnet fremgangsmåde, som bygger på opbygning (tegning) af mo-deller for at visualisere problemstillinger og analysere problemer. Yder-mere kan opbygges modeller som dokumentation for (og integreret del af)kravspecifikationen. I sidste instans ligger modellerne til grund for selvedesignet af systemet.

153

Ordforklaring

Modul Side 41

En kombination af komponenter eller parts med en veldefineret græn-seflade til omgivelserne. F.eks. en elmotor, hvor tilslutningerne til el ogkraftudtag er veldefinerede.

Nedarvning Side 22

Se Generalisering.

Objekt Side 20

En abstrakt størrelse, der kombinerer data og logik som en repræsentationaf en entitet i den virkelige verden. Se også Klasse.

PDM-system Side 59

Et informationssystem, der tilbyder funktionalitet til udførelse af aktivite-terne forbundet med PDM (se denne). Et PDM-system er ofte et kompli-ceret 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 ud-viklede objektorienterede modelleringsteknikker (bl.a. the Booch Method,Object Modelling Technique - OMT og brugen af use cases. I løbet af1990’erne samlede de kræfterne om udviklingen af en fælles notation forobjektorienterede modeller, og i slutningen af 1990’erne så UML dagenslys. Se også UML.

Usecase Side 24

Se Brugsmønster.

154

Litteratur

Andersen, P. V. og Jensen, S. W. [2001], Konfigurering af design-møbler forFritz Hansen, Master’s thesis, Institut for Produktion og Ledelse, DanmarksTekniske 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/92002).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, CIM-data Inc.Citeret på side: 59, 60, 61

Clark, K. B. og Fujimoto, T. [1991], Product Development Performance, Har-vard Business School Press.Citeret på side: 64

155

Litteratur

CMU [2001], ‘What is a CASE Environment’, Hjemmeside (sidst set 19/92002). 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


CSL-NIST [1993], Integration Definition for Function Modelling (IDEF0), Te-chnical report, Computer Systems Laboratory, National Institute of Standardsand Technology. FIPS Publication 183.http://www.idef.com/Downloads/pdf/idef0.pdf


Grabowski, R. [1998a], ‘Visio’s Database Links - Part 1’, Hjemmeside (sidstset 22/9 2002).www.cadinfo.net/visio/rgavt2.htm


Grabowski, R. [1998b], ‘Visio’s Database Links - Part 2’, Hjemmeside (sidstset 22/9 2002).www.cadinfo.net/visio/rgavt3.htm


Grabowski, R. og Zander, F. [2002], Learn Microsoft Visio 2002 for the Ad-

vanced User, Wordware Publishing.Citeret på side: 131

Grouleff, M. [2002], ‘16 kroner i timen til programmøren’, artikel på Compu-terworld.dk. 26/9 2002.http://www.computerworld.dk/default.asp?Mode=2&ArticleID=16274


Guinan, P. J., Cooprider, J. G. og Sawyer, S. [1997], ‘The effective use ofautomated application development tools’, IBM Systems Journal 36(1).http://www.research.ibm.com/journal/sj/361/guinan.html


Harlou, U. [1999], ‘A product family master plan as basis for product modelingand 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


Hvam, L. [1994], Anvendelse af produktmodellering – set ud fra en arbejdsfor-beredelsessynsvinkel, PhD thesis, Driftsteknisk Institut, Danmarks Tekniske

156

Litteratur

Universitet.Citeret på side: 34

Hvam, L. og Mortensen, N. H. [2002], Produktmodellering, Institut for Produk-tion 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 An-nual International Conference on Industrial Engineering Theory Applicationsand 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/92002). International Business Machines.www-10.lotus.com/ldd/whatisnotes


Invensys [2002], ‘iBaan E-Configuration Enterprise Language Reference Ma-nual’. Invensys International B.V.Citeret på side: 117

Jacobson, I., Rumbaugh, J. og Booch, G. [1999], The Unified Software Devel-

opment 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 Ex-change, in ‘I International Congress of Industrial Engineering’, Vol. 3, pp. 1337–1341.http://www.eps.ufsc.br/~kern/publ/kern95.pdf


Kirkby, P. og Kjærulff, J. [1992], CASE for planlægning og analyse i CIM-systemudvikling, Master’s thesis, Driftsteknisk Inistitut, Danmarks TekniskeUniversitet. DI publikationsnummer DI.92.02-B.Citeret på side: 49

Krause, F. L., Kimura, F. og Kjellberg, T. [1993], Product Modelling, in ‘An-nals 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 Tek-niske 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 set19/9 2002).www.ifpug.com/Articles/usecases.htm


Mathiassen, L., Munk-Madsen, A., Nielsen, P. A. og Stage, J. [1993], Objekto-

rienteret analyse, 1 edn, Forlaget Marko.Citeret på side: 20

Microsoft [2002], ‘MSDN Library, About Microsoft Visio Add-ons and COMAdd-ins’, Hjemmeside (sidst set 22/9 2002).msdn.microsoft.com/library/default.asp?url=/nhp/default.asp?contentid=28000456


Mølsted, H. [2002], ‘Slaget om fremtidens IT-platforme er i gang’, artikelseriei ugeavisen ‘Ingeniøren’. Nr. 36, 6/9 2002.Citeret på side: 125

Mortensen, N. H., Yu, B., Skovgaard, H. J. og Harlou, U. [2000], ConceptualModeling of Product Families in Configuration Projects, in ‘Product Models2000-SIG PM’.Citeret på side: 41, 43, 45, 81, 105

Pikosz, P. og Malmqvist, J. [1996], Possibilities and Limitations when UsingPDM Systems to Support the Product Development Process, in ‘ProceedingsNordDesign ’96’, pp. 165–175.Citeret på side: 64, 65

Pikosz, P. [1997], ‘Product Data Mangement in the Product Development Pro-cess’. Licentiate Thesis, Machine and Vehicle Design, Chalmers University ofTechnology, report no. 1997-11-07.Citeret på side: 34, 59

Rational [2001], ‘Using the Rose Extensibility Interface’, Documentationreport. Rational Software Corporation.Citeret på side: 130

Riis, J. [2001], ‘Fremgangsmåde for opbygning af videnintegrerede produkt-og produktrelaterede modeller til udvikling af forretningsprocesser’. Kund-skabsprøve for Ph.D. projekt, Institut for Produktion og Ledelse, DanmarksTekniske Universitet.Citeret på side: 34

Riis, J. [2002], Fremgangsmåde for opbygning af produktmodeller som under-stø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


Schwalbe, K. [2000], Information Technology Project Management, ThomsonLearning.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 Managementand Product Data Management Systems, in ‘Proceedings of the 2001 ASMEDesign Engineering Technical Conferences’, The American Society of Mecha-nical 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, publi-kationer og opnået effekt’. Drifsteknisk Institut, Danmarks Tekniske Universi-tet.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

Kravspecifikationfor dokumentationsværktøj


Polyteknisk eksamensprojekt, 2002

Bilag

Vejledere: Lars Hvam & Jesper Riis Simon Pape, C958196

Institut for Produktion og Ledelse Publikationsnummer

Danmarks Tekniske Universitet IPL-128-02

Bilag A

Paradigma for projekt

Ifølge IPL’s forskrifter skal følgende paradigma medtages som bilag A i rappor-ten.

A.1 Projekttitel

Dansk: Kravspecifikation for dokumentationsværktøj til produktmodelleringEngelsk: 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 pro-duktmodellering 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 specifika-tionsproces åbnes for nye muligheder med relation til forholdet til kunderne.Muligheder, der kan give mere kundetilpassede produkter til konkurrencedyg-tige priser og med en kortere leveringstid.

Anvendelsen af produktmodeller er dog relativ ny, og flere projekter er blevetdroppet. Årsagen hertil skyldes ofte manglen på struktur i processen med deraffølgende mangel på overblik. Den manglende strukturelle opbygning resulterer iet system, der er vanskeligt at vedligeholde og udvikle, og dermed ikke rentabeltat drive.

Ved Center for Produktmodellering har Lars Hvam og Niels Henrik Mortensenudviklet en struktureret fremgangsmåde for opbygning af produktmodeller, sombestår af syv faser. Dokumentationen af produktmodellen består af en rækkediagrammer og dokumenter, der p.t. vedligeholdes manuelt og ikke er integre-rede. Der er derfor ikke mulighed for på en enkel måde at trække på informationpå tværs af diagrammerne og dokumenterne, og vedligeholdelsesarbejdet bliverhurtigt omfattende og uoverskueligt.

Et IT-baseret dokumentationsværktøj vil kunne tilbyde en integration af infor-mationen og vil ydermere kunne automatisere og støtte mange af vedligeholdel-sesopgaverne.

A.6 Opgaveformulering

Målet er opbygningen af en kravspecifikation for det ønskede dokumentations-værktøj. Dette indebærer følgende aktiviteter:

- Studie af teorien bag produktmodellering for opbygning af forståelse fordomænet.

- Studie af det objektorienterede domæne og livscyklussen for objektorien-teret systemudvikling.

- Studie af lignende dokumentationsværktøjer.

- Analyse af dokumentationsprocessen i produktmodelleringsforløb - baseretpå både virksomhedernes og CPM’s erfaringer.

- Dokumentation af ønsker og krav ved hjælp af brugsmønstre og klassedia-grammer.

- 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 fulgtkurset 42450 Industrielle Informations- og Specifikationssystemer på DTU.

164

A.9 Projektets løbetid

A.8 Eventuelt

–

A.9 Projektets løbetid

Påbegyndes 1/3 2002 og afsluttes 15/10 2002, dvs. i alt 7 1

2måned (inkl. som-

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

leringsprocessen

USED AT: CONTEXT:

NODE: TITLE: NUMBER:

AUTHOR:PROJECT:

NOTES: 1 2 3 4 5 6 7 8 9 10

DATE:REV:

WORKINGDRAFTRECOMMENDEDPUBLICATION

READER DATE

P.

Decomposed Leaf

Opbyg produkt-konfigurator

A0

P. 2

Produktdata

Procesdata

Modellør

Domæneekspert

Konfigurator

Metodologi

Formål, synsvinkelog kontekst

Formål: At klarlægge processen for produktmodelleringSynsvinkel: Procesanalytisk med henblik på systemudvikling. Fokus på dokumentationsopgaven og relaterede dokumenterKontekst: Sigtet er at klarlægge kravene til et IT-baseret dokumentationsværktøj til understøttelse af produktmodelleringsprocessen

Top

1

xRequirements for Documentation ToolSimon Pape

IPL/DTU

10/09/02

Funktionsanalyse af produktmodelleringsprocessenA-0

167

Bilag B - IDEF0 for produktmodelleringsprocessen

USED AT: CONTEXT:


AUTHOR:PROJECT:

NOTES: 1 2 3 4 5 6 7 8 9 10

DATE:REV:


READER DATE

P.

Decomposed Leaf

I1

Produktdata

M2

Domæneekspert

O1

Konfigurator

Fase 2Analyser produkt

A2

P. 3 Fase 3Udfør OOA

A3

P. 4 Fase 4Udfør OOD

A4

P. 5 Fase 5Programmér og

test

A5

P. 6

Programmør

OOD Model(fuldt detaljeret OO model)

Produkt-VariantMaster

OOA Model(CRC kort, klassediagrammer mm.)

Fase 6Implementér

løsning

A6

Fase 7Vedligehold

system

A7

P. 7

Opdateringer/ændringer

Konfigurator

Fase 1Analysérproces

A1

Dokumentation formodeltransformation

Fungerendesystem

Overordnet indhold af modelFormål, synsvinkel og kontekst

2


IPL/DTU

10/09/02

Opbyg produkt- konfiguratorA0

USED AT: CONTEXT:


AUTHOR:PROJECT:

NOTES: 1 2 3 4 5 6 7 8 9 10

DATE:REV:


READER DATE

P.

Decomposed Leaf

I1Produktdata

O1 Produkt-VariantMaster

M1

Domæ neekspert

Identificér part-of og

kind-of strukturer

A21

Saml moduler i prod. master

A22

Tilføj forklaringer og

figurer

A23

Produktinfomration

Aggregerings- oggeneraliseringsstrukturer

Rå produktmaster

Produkt-Variant Mastertil endnu et gennemløb(iterationer)

A2 3SP1


IPL/DTU

10/09/02

Fase 2 Analyser produkt

168

USED AT: CONTEXT:


AUTHOR:PROJECT:

NOTES: 1 2 3 4 5 6 7 8 9 10

DATE:REV:


READER DATE

P.

Decomposed Leaf

I1Produkt-VariantMaster

O1


M1Domæ neekspert

I2Produktdata

Find objekter og klasser

A31

Identificér strukturer

A32

Identificér temaer

A33

Definér attributter

A34

Definér metoder

A35

Liste af klasser

Råt klassediagram(kun tomme klasser + rel.)

Råt, temaopdeltklassediagram

Attributdefinitioner

Metodedefinitoner

Opbyg krav-specifikation

A36

Use-cases,spec. afgræ nseflader mv.

SP2 4


IPL/DTU

10/09/02

Fase 3 Udfør OOAA3

USED AT: CONTEXT:


AUTHOR:PROJECT:

NOTES: 1 2 3 4 5 6 7 8 9 10

DATE:REV:


READER DATE

P.

Decomposed Leaf

I1


O1


M1

Domæ neekspert

Definér grænseflade-komponent

A41

Tilret OOA-model

A42

Fastlæg data-arkitektur

A43

Brugerstudierog -analyser

Specifikation af brugergræ nseflade(skæ rmbilleder, udskrifter mv.)samt kobling til andre systemer

I2Produktdata

Fuldt detaljerede CRC-kortsamt klassediagrammer

Analyse afalternativer

Programmør/teknisk konsulent

Fastlæg system(std. vs. eget)

A44

Valgt system

Valgtsystemarkitektur

Valgt datastruktur

SP3 5


IPL/DTU

10/09/02

Fase 4 Udfør OODA4

169

Bilag B - IDEF0 for produktmodelleringsprocessen

USED AT: CONTEXT:


AUTHOR:PROJECT:

NOTES: 1 2 3 4 5 6 7 8 9 10

DATE:REV:


READER DATE

P.

Decomposed Leaf

I1


M1Programmør

O2

Fungerendesystem

Transformér model til valgt

system

A51

Dokumentér trans-

formation

A52

Programmér system

A53

Valgt system

Test system

A54

Konventioner mv.

Testplaner

Fejlbehæ ftetsystem/modul

Transformeretmodel

Utestetsystem/modul

O1

Dokumentation formodeltransformation

SP4 6


IPL/DTU

10/09/02

Fase 5 Programmér og testA5

USED AT: CONTEXT:


AUTHOR:PROJECT:

NOTES: 1 2 3 4 5 6 7 8 9 10

DATE:REV:


READER DATE

P.

Decomposed Leaf

C3

Opdateringer/æ ndringer

Modellér æ ndring

A71

Opdatér dokumen-

tation

A72

Implementér æ ndringer

A73Eksisterendesystem

Opdateretsystem

Opdateretproduktmodel

I1Konfigurator

O1

Konfigurator

Opdateret dokumentationfor modeltransformation

Eksisterende modelog dokumentation

Opdateretproduktmodel

SP5 7


IPL/DTU

10/09/02

Fase 7 Vedligehold systemA7

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, [email protected]) og Michael Dam (MD, [email protected]).

GEA Niro A/S – www.niro.dk

Gladsaxevej 3052860 SøborgTlf.: +45 3954 5454Fax.: +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 ogfremstiller spaytørringsanlæg. Projektet drejer sig om, hvorledes produktmo-deller kan bruges til at udveksle produktrelateret viden i netværk. Med netværkmenes f.eks. forskellige nationale afdelinger af samme internationale virksomhedeller led i forsyningskæden.

I forbindelse med projektet udarbejdes en produktmodel for en roterende for-støver (atomizer), som indgår som en del af et større fabriksanlæg. Produktmo-dellem opbygges i Oracles nye konfigurator, som netop understøtter opdelingeni 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 enhierarkisk opbygning af produktporteføljen. Et problem allerede her er natur-ligvis, at relationerne i produktporteføljen (produktserierne) ikke er hierarkiske.Databasen indeholder alle CRC-kort for objekterne i modellen, og i den for-bindelse er det jo uhensigtsmæssigt, at dokumentation for en objektorienteretmodel er organiseret i en hierarkisk struktur.

Notes har et indbygget simpelt tekstbehandlingsværktøj, som CRC-kortene erlavet i. I disse dokumenter kan laves links til andre (relaterede) dokumenter,og man anvender naturligvis dette til under “collaborations” at lave links tilCRC-kortene for de relaterede objekter.

Fordelen ved at anvende Notes er således

- En simpel integration af CRC-kortene med hinanden og muligheden for atkunne 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-kortafspejles 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


Til stede: Martin Malis (MM, [email protected]).

GEA Niro A/S – www.niro.dk

Gladsaxevej 3052860 SøborgTlf.: +45 3954 5454Fax.: +45 3954 5800

C.2.1 Introduktion til Niro

Niro A/S (Niro) er del af den tyske virksomhedsgruppe GEA Group, hvor virk-somhederne i Niro-gruppen (herunder Niro A/S) tilsammen udgør P-divisionen(Powder Technology Division). Niro-gruppen består af 55 virksomheder fordeltover hele verden med omkring 2.300 ansatte – heraf 350 i Danmark. Til sammen-ligning 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ådevæ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-systemforeslog 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 somph.d.-studerende. Visionen var at anvende en konfigurator i en division (for enproduktgruppe) og derefter udbrede den forventede succes til resten af virk-somheden. Hos Niro valgte man at anvende Oracle Configurator, som en del afOracle e-Business Suite ver. 11.5.7.

Til dette formål blev oprettet en projektgruppe bestående af medarbejdere frasalg, konstruktion og procesteknologi (domæneeksperter) og MM som modellør.Hertil kom kræfter fra ledelse og IT-afdelingen efter behov. Hos Niro ønskedeman et tættere samarbejde med kræfter fra det akademiske miljø, og anvendelseaf fremgangsmåden for opbygning af produktmodeller fra CPM vakte begej-string 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 anvendelseaf CRC-kort i en hierarkisk struktur. Erfaringen er, at PVM’en giver en godoverordnet fornemmelse for produktets opbygning, men det ville være hensigts-mæssigt at kunne opdele den i “under-PVM’er” ved udskrift, så man kunnefokusere på den del af PVM’en, som hører den enkelte division. Under udar-bejdelse af PVM’en savnede man i høj grad et dedikeret tegneprogram, som

175


Figur C.1: Eksempel på CRC-kort og træstruktur i Lotus Notes hos Niro

understøttede en standardiseret anvendelse af symboler og lettede tegneproces-sen.

Til håndtering af CRC-kortene blev udviklet en løsning i Lotus Notes, som APCefterfølgende fik adgang til og videreudviklede (se figur C.1). Notes-løsningenbetød, at man ikke benyttede sig af klassediagrammet, da klasserne herpå ikkekunne sammenkobles med CRC-kortene på en intelligent måde i Notes-løsningen1.Herudover er MM’s erfaring med klassediagrammet, at det hurtigt bliver for-virrende, da de mange relationer mellem klasserne gør diagrammet uoversku-eligt. Et ønske i den forbindelse var muligheden for at kunne slå visningen afen relation til og fra på klassediagrammet, så kun de vigtigste relationer vises.Herudover blev foreslået, at man ved at markere en klasse i klassediagrammetkunne 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 for-hold til den oprindelige udformning. Bl.a. blev “Does”-feltet opdelt i systemmeto-der og produktmetoder, og feltet med generaliserings-relationerne blev fjernet,da Notes-løsningen ikke kan vise dette (og konfiguratoren næppe understøttedet. . . ). Et forslag til et kommende dokumentationsværktøj ville derfor væremuligheden for at kunne indstille “modelleringsparadigmet” til enten traditio-

1 Notes-løsningen er detaljeret beskrevet i bilag C.4

176


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 navigerei sine klasser, men pointerede samtidig, at det var en stor ulempe, at det ikkevar muligt at se bindingerne imellem klasserne.

Vedligeholdelsen af produktmodellen bør efter MM’s mening placeres hos do-mæneeksperterne, forstået på den måde, at domæneeksperterne er ansvarligefor, at indholdet er korrekt, mens modellører sørger for konsistens og korrekt-hed. 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 telefonsamtale7/3 2002


179



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


181



182



183



184



185



186



187



188

C.5 F.L. Smidth, notat fra besøg 15/8 2002


Til stede: Søren Poulsen (SP, [email protected]).

F.L. Smidth A/S – www.flsmidth.com

Vigerslev Allé 772500 ValbyTlf.: +45 3618 1000Fax.: +45 3630 1820

C.5.1 Virksomheden

F.L. Smidth A/S (FLS) er en del af FLS Industries. FLS’s produkter kan opdelesi tre grupper:

- komplette cementfabrikker

- enkeltstående maskiner og renoveringsopgaver

- reservedele og kundeservice

Kontaktpersonen SP er ansat som IT-medarbejder i tilbudsafdelingen og indgårsåledes ikke i virksomhedens IT-afdeling. SP er uddannet maskiningeniør ogstartede som montør i FLS. Siden hen kom han tilbage til hovedsædet og blevspecialist i en afdeling med ansvar for styklister og ordrer. Som fuldtids IT-medarbejder er han primært tilknyttet arbejdet med budgetkonfiguratoren ogde 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, somskulle støtte arbejdet med tilbudsgivning på komplette cementfabrikker. Projek-tet blev startet af Claus Torbøl, som stadig er ansat i FLS. Valget faldt dengangpå en konfigurator fra Baan med begrundelse i, at deres udviklingsafdelingenvar tæt på, og FLS derudover blev tilbudt at kunne indgå aktivt i udviklingenaf konfiguratoren og dermed sætte sit eget præg på resultatet. Samarbejdet medBaan har fungeret godt, og man anvender stadig BaanConfiguration 98.2.

Projektet startede med, at der blev nedsat en arbejdsgruppe, der skulle udviklekonfiguratoren. 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 vardomæneeksperter.

Al produktviden blev tastet direkte ind i konfiguratoren uden at lave en egentligdokumentation sideløbende2. I den anvendte konfigurator er der ikke mulighedfor at relatere bindinger og produktdele. I konfiguratoren opbygges et hierarkiaf 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 de-signreglerne (bindingerne) i et selvstændigt dokument ved at beskrive dem i ren tekst.

189


Figur C.2: Skærmbillede fra FLS’s konfigurator

produktdelene og disses egenskaber. Bindingerne kan ikke navngives og er derforsvære at identificere.

Resultatet af udviklingen er, at man nu har en konfigurator, hvor koden mindermest om spaghetti. Ifølge SP er konfiguratoren delvis årsag til dette, da det ermuligt at lave spaghetti-kode. Konfiguratoren lægger ikke selv op til en struk-tureret fremgangsmåde og dokumentation. Det betyder, at det er meget sværtat se konsekvensen af at ændre f.eks. en enkelt binding.

Tilbudsafdelingen har ansvaret for vedligeholdelse af konfiguratoren, og SP hardel i dette arbejde. Alle relevante medarbejdere og afdelinger ved, at der eksiste-rer en konfigurator, som er afhængig af, at grundlaget er opdateret. Således harde enkelte afdelinger ansvaret for, at deres “del” af konfiguratoren regner rigtigt.Opdateringer foregår ved, at en specialist sender en e-mail til tilbudsafdelingenmed angivelse af, hvad der skal ændres. På den måde får man i tilbudsafdelingenrigtig mange e-mails, og for hver e-mail skal den relevante kode i konfiguratorenfindes og ændres.

190


C.5.2.1 Nye modelleringsprojekter

Med ovenstående konfigureringsprojekt har man hos FLS gjort sig nogle erfa-ringer, som man naturligvis vil bruge i kommende projekter. For det første harman lært utroligt meget om modelleringsteknik – eller rettere hvad konsekven-serne 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 dokumentationefterfølgende.

Den næste projekt er udviklingen af konfiguratorer til konfigurering af dele afen fabrik (transportsystemer til materialetransport mellem de enkelte maskin-grupper). Fremgangsmåden er her lidt anderledes, idet man først opbygger do-kumentationen i samarbejde med domæneeksperterne. Dokumentationen beståraf 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 designreg-ler. Regneark er valgt, da de specialister, der har den fornødne viden, i forvejener fortrolige med anvendelse af regneark til dels at skrive formler og lign. i, delsat tegne kasser og flowcharts. Regnearkene er på ingen måde integreret medhinanden 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 etincitament til at lave dokumentationen rigtigt, idet de ellers vil blive kontaktetsenere 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 sidstehånd på udviklingen af et nyt ERP- og PDM-system. Systemet udvikles afden interne IT-afdeling, og i relation til konfiguratorerne bliver udviklet noglegræ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 overblikover produktmodellen og (især) bindingerne. En visualisering vil være megetanvendeligt (f.eks. som relationer mellem klasser). I den forbindelse har man medglæde set lanceringen af iBaan, som langt hen ad vejen giver et godt overblikover produktmodellen. De nye typevalgskonfiguratorer skal opbygges i iBaan.Med erfaringer fra det hidtidige arbejde med produktmodellering og udsigtentil et kommende dokumentationsværktøj har SP en række krav eller ønsker, somvil gøre værktøjet mere interessant:

Et meddelelsesmodul ville være utroligt anvendeligt, idet det kunne kobledomæ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 kunnehave læseadgang til modellen og på en simpel måde sende et ændringsforslag tilden ansvarlige udvikler.

191


Hyperlinks bør kunne bruges i alle tekstfelter. Ofte er der brug for at kunnerelatere til et eksternt dokument, og samtidig kunne et dokumentationsværktøjbruges som et centralt medium for dokumentation. Dokumentationsværktøjetskulle ikke nødvendigvis indeholde al informationen, men kunne linke videre tildenne.

Internettet bør være grundstammen for kommunikationen mellem klienten ogden centrale server. FLS vil have brug for, at medarbejdere kan tilgå systemetuafhængigt af deres geografiske placering. Det er dog ikke essentielt, at værktøjetafvikles via en browser, idet brugeren altid vil have en personlig computer tilrå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 athente oplysninger om f.eks. pris og vægt for forskellige produktdele i virksom-hedens ERP-system.

Overførsel fra dokumentation til konfigurator vil klart være en fordel. Om ikkeandet så for at slippe for at taste information ind manuelt flere gange. Visionener at bruge produktmodellen i dokumentationsværktøjet som “master” og så ladekonfiguratoren afspejle denne. Hvis det ikke er muligt at overføre automatisk,så kræver opdateringer to arbejdsgange: Opdatering af dokumentationen ogopdatering af konfiguratoren. Hvis arbejdet med opdatering af dokumentationenikke er besværligt, ser SP ikke noget problem i dette.

Basering på standardsystemer bør efter SP’s opfattelse undgås. Hvis manf.eks. forestiller sig, at værktøjet baseres på Lotus Notes, vil det kræve, at FLSskal indkøbe og indføre dette system for alle medarbejdere. Dette er i konfliktmed den overordnede IT-politik og vil ikke være foreneligt med IT-afdelingensbeslutninger på området for virksomhedens fælles IT-systemer (som p.t. er ba-seret på Microsofts produkter). Men det er ikke til hinder for, at værktøjetkan udformes på en sådan måde, at f.eks. Lotus Notes kan sammenkobles medværktøjet; det bør bare ikke være et krav.

192

C.6 Vitral A/S, notat fra besøg 9/4 2002



193



194



195

Bilag D

Brugsmønstre

Beskrivelserne for brugsmønstrene er medtaget på det følgende sider og er in-spireret af opstillingen i Whitten et al. [2001, s. 662]. Tallene i “Reference”-feltethenviser 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 199Klynge: Administration, side 205Klynge: PVM, side 213Klynge: CRC-kort, side 223Klynge: Klassediagram, side 241

197

Bilag D - Brugsmønstre

ID Side Navn

1.1 200 Log på systemet1.2 201 Log af systemet1.3 202 Definér rapportskabelon1.4 203 Vis rapport «uses»Udskriv1.5 204 Udskriv2.1 206 Redigér projekt2.2 207 Redigér bruger2.3 208 Redigér gruppe2.4 209 Redigér felt på CRC-kort «uses»Redigér link til ekstern DB2.5 210 Redigér link til ekstern DB2.6 211 Definér global rapportskabelon «extends»Definér rapportskabelon2.7 212 Konfigurér meddelelsesmodul3.1 214 Redigér illustration3.2 215 Redigér note3.3 216 Opret ny PVM «uses»Vis PVM3.4 217 Vis PVM «uses»Udskriv PVM3.5 218 Udskriv PVM «uses»Udskriv3.6 219 Tilføj part-of klasse «uses»Redigér CRC-kort3.7 220 Tilføj kind-of klasse «uses»Redigér CRC-kort3.8 221 Redigér PVM-klasse «extends»Redigér CRC-kort3.9 222 Redigér binding «extends»Redigér metode4.1 224 Vis historik for CRC-kort «uses»Udskriv4.2 225 Vis version af CRC-kort «extends»Vis CRC-kort4.3 226 Gem ny version af CRC-kort4.4 227 Vis CRC-kort «uses»Udskriv4.5 228 Ændr CRC-kort status4.6 229 Godkend ændringer «uses»Sammenlign to versioner af CRC-kort4.7 230 Sammenlign to ver. af CRC-kort «extends»Vis CRC-kort4.8 231 Redigér attribut4.9 232 Redigér metode4.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-kort4.11 234 Godkend CRC-kort4.12 235 Foreslå ændring «uses»Send meddelelse om ændringsforslag4.13 236 Send meddelelse om ændringsforslag4.14 237 Send meddelelse om uberørt klasse4.15 238 Søg i CRC-kort «uses»Vis CRC-kort4.16 239 Vis oversigt over CRC-kort5.1 242 Overfør model til konfigurator5.2 243 Sammenlign dokumentation med konfigurator5.3 244 Redigér klynge «uses»Vis klassediagram5.4 245 Redigér tema5.5 246 Redigér relation5.6 247 Opret nyt klassediagram «uses»Importér struktur fra PVM5.7 248 Tilføj klasse «uses»Redigér CRC-kort5.8 249 Vis klasse «extends»Vis CRC-kort5.9 250 Vis klassediagram «uses»Udskriv, Udlæg klassediagram5.10 251 Udlæg klassediagram5.11 252 Importér struktur fra PVM

Tabel D.1: Oversigt over brugsmønstre

198

D.1 Topdiagram

D.1 Topdiagram

Dokumentationsvæ rktøj

Log på systemet

Domæ neekspert

Modellør

Administrator

Administration

CRC-kort

Klassediagram

PVM

«uses»

Vis rapport

Definér rapport-skabelon


Udskriv

Log af systemet

Konfigurator

Tiden

Figur D.1: Brugsmønsterdiagram, topniveau

199


ID - Navn 1.1 - Log på systemet

Reference A0

Aktør(er) Administrator, Modellør, Domæneekspert

Beskrivelse En bruger identificerer sig overfor systemet og gives adgang til funktionerne.

Forudsætning Brugeren er logget af systemet.

Resultat Brugeren er logget på systemet

Aktør SystemTypiskscenarie

Trin 1: Initieres når en aktør startersystemet.

Trin 2: Vis en dialogboks, hvor bruger-navn og adgangskode skal indtastes

Trin 3: Brugernavn og adgangskodeindtastes.

Trin 4: Hvis brugernavn eksisterer ibrugerdatabasen og adgangskode er gyldigvises en ny dialogboks med en liste overeksisterende projekter.

Trin 5: Et projekt vælges. Trin 6: For det valgte projekt startes opmed at vise det diagram, der var aktivt dadenne aktør sidst loggede af.

Trin 7: Der skrives et indlæg i loggenmed information om tidpunkt og bruger.

Alternativtscenarie Trin 4: Hvis brugernavn ikke findes eller

adgangskode ikke passer, vises en advarselom dette og der startes fra trin 2.

Antagelser Der eksisterer mindst ét projekt.

200

D.1 Topdiagram

ID - Navn 1.2 - Log af systemet

Reference A0

Aktør(er) Administrator, Modellør, Domæneekspert

Beskrivelse En bruger logger sig af systemet.

Forudsætning Brugeren er logget på systemet.

Resultat Brugeren er logget af systemet


Trin 1: Initieres når en aktør ønsker atafslutte arbejdet med værktøjet.

Trin 2: Der vises en dialogboks, hvoraktøren skal bekræfte at ville logge af.

Trin 3: Valget bekræftes Trin 4: Det noteres hvilket diagram, derer aktivt til brug for næste login.

Trin 5: Der skrives et indlæg i loggenmed information om tidspunkt og bruger.

Alternativtscenarie Trin 3: Hvis valget annulleres returneres

til det aktive skærmbillede.

Antagelser Ingen p.t.

201


ID - Navn 1.3 - Definér rapportskabelon

Reference A0

Aktør(er) Administrator, Modellør

Beskrivelse Redigering og oprettelse af en skabelon for rapporter til udtræk af information fraproduktmodellen.

Forudsætning

Resultat En skabelon er oprettet og tilgængelig for brugerne af systemet.


Trin 1: Initieres når en aktør ønsker atlave en skabelon for en rapport.

Trin 2: Der vises en dialogboks, hvordet er muligt at angive hvilke datafelterrapporten skal bestå af. Der er mulighedfor at definere rækkefølgen af felterne, ogtilføje et filter-kriterie for hvert enkelt felt.

Trin 3: Der vælges hvilke felter rapportenskal bestå af, og også deres rækkefølge.

Trin 4: Når felterne er valgt, navngivesskabelonen.

Trin 5: Rapportskabelonen gemmes oger tilgængelig for brugerne af det aktuelleprojekt.

Alternativtscenarie Trin 6: Der gives også mulighed for at

åbne eksisterende skabeloner (ikke globale)og ændre i disse. Fortsæt fra trin 3 nårskabelon er valgt.

Antagelser Information kan trækkes ud af produktmodeldatabasen vha. et formaliseret fore-spørgselssprog, f.eks. SQL.

202

D.1 Topdiagram

ID - Navn 1.4 - Vis rapport «uses»Udskriv

Reference A0

Aktør(er) Modellør

Beskrivelse En rapport vises med udtræk af information fra produktmodellen baseret på enforuddefineret skabelon. Rapporten kan udskrives.

Forudsætning Der eksisterer mindst én tilgængelig rapportskabelon.

Resultat En rapport er vist og evt. udskrevet.


Trin 1: Initieres når en aktør vil havevist eller udskrevet en rapport.

Trin 2: Der vises en liste over tilgængeligerapportskabeloner – både lokale og globale.

Trin 3: En rapportskabelon vælges. Trin 4: For den valgte skabelon genereresrapporten ud fra indholdet af produktmo-deldatabasen.

Trin 5: Rapporten vises på skærmensom en tabel, hvor kolonnerne svarer tilrapportskabelonens felter og rækkene tilindholdet af felterne. Det er muligt atvælge at udskrive rapporten.

Trin 6: Aktøren vælger at udskriverapporten.

Trin 7: Kald Udskriv.

Alternativtscenarie

Antagelser Information kan trækkes ud af produktmodeldatabasen vha. et formaliseret fore-spørgselssprog, f.eks. SQL.

203


ID - Navn 1.5 - Udskriv

Reference A0

Aktør(er) Modellør, Domæneekspert

Beskrivelse Forskellige elementer kan udskrives, og her beskrives hvordan man f.eks. kan udskriveen stor side over flere sider.

Forudsætning Dette brugsmønster forventer at indholdet, der skal udskrives er defineret forud.

Resultat Det aktuelle dokument er udskrevet på en tilsluttet printer.


Trin 1: Initieres, når noget skal udskrivespå en tilkoblet printer.

Trin 2: Der vises en dialogboks, hvordet er muligt at vælge printer, indstilleprinteren og vælge et sideinterval derskal udskrives. Herudover er det muligtat vælge udskrivning over flere sider(når dokumenter, der fylder mere endprinterens papir skal udskrives).

Trin 3: Aktøren foretager sine valg ogindstillinger og vælger at printe.

Trin 4: Dokumentet printes via operativ-systemets printerdrivere.

Alternativtscenarie Trin 4: Hvis der i trin 3 er valgt at printe

over flere sider, foretages en opdelingaf det store dokument til printeresnpapirstørrelse, så de udprintede sideroverlapper hinanden lidt. Herefter printesvia operativsystemets printerdrivere.

Antagelser Der eksisterer en veldefineret grænseflade til håndtering af udskrivning i operativ-systemet, som kan bruges.

204

D.2 Klynge: Administration


Administration

Topdiagram::Administrator

'Redigér'-brugs-mønstre beskriver

også oprettelse

Redigér linktil ekstern

DB

Redigér feltpå CRC-kort

Redigér gruppe

Konfigurér med-delelsesmodul

Topdiagram::Definér rapport-skabelon

«extends»Definér global

rapportskabelon

«uses»

Redigér brugerRedigér projekt

Figur D.2: Brugsmønsterdiagram, klynge: Administration

205


ID - Navn 2.1 - Redigér projekt

Reference A0

Aktør(er) Administrator

Beskrivelse Redigering og oprettelse af et nyt projekt. Et projekt indeholder én produktmodel,men kan indeholde flere diagrammer.

Forudsætning

Resultat Det aktuelle projekt er redigeret (evt. oprettet).


Trin 1: Initieres når et nyt projekt skaloprettes eller et eksisterende redigeres iadministrationsmodulet.

Trin 2: Der vises en dialogboks meden liste over alle tilgængelige projekter.Herudover er det muligt at oprette et nytprojekt.

Trin 3: Der vælges et projekt. Trin 4: Der vises en dialogboks medprojektets egenskaber (projektnavn, be-skrivelse, projektleder, medarbejdere).Det er muligt at ændre egenskaberne.Projektnavn og beskrivelse er rene tekst-felter, mens indholdet af projektleder- ogmedarbejder-felterne vælges fra en liste in-deholdende brugerne fra brugerdatabasen.

Trin 5: Aktøren ændrer i egenskaberneog vælger at afslutte.

Trin 6: Det undersøges om alle felter haren værdi, og aktøren bliver bedt om atgodkende, at der er foretaget ændringer.

Trin 7: Aktøren godkender ændringerne. Trin 8: Ændringerne gemmes, og derreturneres til skærmbilledet før dettebrugsmønster.

Alternativtscenarie 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


ID - Navn 2.2 - Redigér bruger

Reference A0


Beskrivelse Redigering og oprettelse af en bruger af systemet. Kun oprettede brugere kan tilgåsystemet.

Forudsætning

Resultat Oplysningerne om den aktuelle bruger er opdateret (evt. ny bruger oprettet).


Trin 1: Initieres når aktøren vælger “Re-digér bruger” i administrationsmodulet.

Trin 2: En dialogboks vises med en listeover de oprettede brugere af systemet.

Trin 3: Der vælges en bruger fra listen. Trin 4: En ny dialogboks vises med denvalgte brugers informationer, herunderen liste over hvilke grupper brugerener medlem af. En administrator kan ikkeslette sig selv fra “Administrator”-gruppen.

Trin 5: Aktøren foretager sine ændringerog afslutter.

Trin 6: Ændringerne gemmes i brugerda-tabasen.

Alternativtscenarie Trin 2: Hvis aktøren vælger “Tilføj

bruger” i trin 2 gås til trin 4 oven for, hvoralle felterne blot er tomme.

Antagelser Brugerdatabasen samkøres ikke med virksomhedens centrale brugerdatabase.

207


ID - Navn 2.3 - Redigér gruppe

Reference A0


BeskrivelseBrugere kan være medlemmer af grupper. Adgang til at ændre i en model kan tildelesenten individuelle brugere eller grupper af brugere. Medlemmerne af en gruppe kanredigeres via dette brugsmønster.

Forudsætning Der eksisterer mindst én bruger i systemet.

Resultat Medlemslisten for en gruppe er opdateret (evt. en ny gruppe oprettet).


Trin 1: Initieres ved at aktøren vælger“Redigér gruppe” i administrationsmodu-let.

Trin 2: En dialogboks vises med en listeover de eksisterende grupper.

Trin 3: Akøren vælger en gruppe fralisten.

Trin 4: Der vises en dialogboks, hvor derer to lister; én med de brugere, der ikke ertilknyttet gruppen og én med de brugere,der er tilknyttet den aktuelle gruppe.

Trin 5: De ønskede ændringer foretagesved at trække brugere fra den ene liste tilden anden med musen.

Trin 6: Ændringerne gemmes i brugerda-tabasen. En administrator kan ikke slettesig selv fra “Administrator”-gruppen.

Alternativtscenarie Trin 2: Hvis aktøren vælger “Tilføj

gruppe” i trin 2 oven for vises en dialog-boks, hvor navnet på den nye gruppe skalindtastes.

Trin 3: Aktøren indtaster et navn. Trin 4: Det tjekkes om der eksisterer engruppe med det angivne navn. Hvis ikkeoprettes en ny gruppe, og der fortsættesfra trin 4 oven for, hvor listen med brugeretilknyttet gruppen er tom. Hvis navneteksisterer vises en advarsel om dette,og der returneres til dialogboksen, hvornavnet kan indtastes.


208


ID - Navn 2.4 - Redigér felt på CRC-kort «uses»Redigér link til ekstern DB

Reference A0


Beskrivelse CRC-kort kan indeholde brugerdefinerede felter. Her beskrives hvordan disse opret-tes og redigeres.

Forudsætning

Resultat Den globale skabelon for et CRC-kort er opdateret.


Trin 1: Initieres ved at aktøren vælger“Redigér felt på CRC-kort” i adminstra-tionsmodulet.

Trin 2: En dialogboks vises med en listeover de eksisterende brugerdefineredefelter på CRC-kort skabelonen. Række-følgen i listen afspejler rækkefølgen påCRC-kortet.

Trin 3: Et felt vælges fra listen. Trin 4: En dialogboks vises med entabel, der afspejler opbygningen af detbrugerdefinerede felt. I tabellens felterkan skrives formateret statisk tekst ellerindsættes en brugerdefineret attribut.Antallet af rækker og kolonner kanjusteres.

Trin 5: Der højreklikkes på et felt itabellen og vælges “Indsæt attribut”.

Trin 6: Feltet ændres, så der ikke kanskrives statisk tekst og en dialogboks visesmed en liste over de typer af attributter,der kan indsættes.

Trin 7: Der vælges en type. Trin 8: Der returneres til tabellen,og et symbol indsættes for den givneattributtype.

Trin 9: Der højreklikkes på symbolet ogvælges “Redigér indstillinger”.

Trin 10: En dialogboks vises med enliste over indstillingsparametrene forden aktuelle attributtype og mulighedfor at redigere værdien af parametrene.Hvis typen er et databaselink redigeresegenskaberne ved at kalde Redigér link tilekstern DB.

Alternativtscenarie Trin 3: Aktøren vælger “Indsæt nyt felt”. Trin 4: En dialogboks vises, hvor et

feltnavn skal angives. Når dette er angivetvises en tom tabel med 2*2 felter og derfortsættes fra trin 4.


209


ID - Navn 2.5 - Redigér link til eksterne DB

Reference A0


Beskrivelse De brugerdefinerede felter kan indeholde attributter, hvor værdien hentes fra ek-sterne databaser. Her beskrives hvordan disse links vedligeholdes og oprettes.

Forudsætning Der eksisterer et brugerdefineret felt, hvor linket kan indsættes. Der eksisterer endatabase, der kan linkes til.

Resultat Linket til databasen er opdateret (evt. oprettet).


Trin 1: Intieres ved kald fra Redigér feltpå CRC-kort.

Trin 2: En dialogboks vises med egen-skaberne for et databaselink (placeringaf databasen og indhold af forespørgsel iSQL).

Trin 3: Databasens placering angives oget SQL udtryk indtastes. I SQL udtrykketkan refereres til feltværdier i CRC-kortet.

Trin 4: Ændringerne gemmes.

Alternativtscenarie

Antagelser Det er muligt at lave et link til en ekstern database og forespørge via SQL.

210


ID - Navn 2.6 - Definér global rapportskabelon «extends»Definér rapportskabelon

Reference A0


Beskrivelse Udvider Definér rapportskabelon med muligheden for at lave skabeloner, der er til-gængelige for alle brugere af systemet.

Forudsætning

Resultat En global skabelon er opdateret (evt. oprettet) og tilgængelig for brugerne.


Trin 1: Initieres ved at aktøren vælger“Definér global skabelon” i administra-tionsmodulet.

Trin 2: Forløbet svarer til trinene iDefinér rapportskabelon, med forskel fralagringen af skabelonen. Når skabelonenlagres gøres den tilgængelig for alle brugereaf alle projekter i den givne installation.

Alternativtscenarie

Antagelser Skabeloner kan gøres tilgængelige for alle brugere af systemet.

211


ID - Navn 2.7 - Konfigurér meddelelsemodul

Reference A0


Beskrivelse Beskriver opsætning af integration med virksomhedens kommunikationssystem ogændring af tidsinterval for automatisk notifikation.

Forudsætning

Resultat


Trin 1: Initieres når aktøren vælger“Konfigurér meddelelsesmodul” i admin-strationsmodulet.

Trin 2: En dialogboks vises, hvor deter muligt at ændre egenskaberne foropkobling til virksomhedens kommunika-tionssystem, og endvidere er det muligt atangive hvor lang tid en klasse med status“Under udarbejdelse” skal ligge uberørt føren meddelelse automatisk udsendes.

Trin 3: Aktøren ændrer i indstillingerne. Trin 4: Ændringerne gemmes.

Alternativtscenarie

Antagelser Det er muligt at benytte et eksisterende kommunikationssystem til at sende med-delelserne.

212

D.3 Klynge: Produkt-Variant Master


PVM

«uses»

Opret ny PVM

'Redigér'-brugs-mønstre beskriver

også oprettelse

Topdiagram::Modellør

CRC-kort::Redigér CRC-kort

Topdiagram::Udskriv

Redigér note

«uses»

«uses»

CRC-kort::Redigér metodeRedigér binding

«extends»

Redigér PVM-klasse

Redigér illustra-tion

«uses»Tilføj kind-of

klasse

Tilføj part-ofklasse

Topdiagram::Domæ neekspert

CRC-kort:: Indsæ t hyperlink

«uses»

Udskriv PVMVis PVM

«extends»

«uses»

«uses»

Figur D.3: Brugsmønsterdiagram, klynge: PVM

213


ID - Navn 3.1 - Redigér illustration

Reference A23


Beskrivelse Ændring af størrelse og position for indsat illustration, samt indstillinger for link tilillustrationsfilen (samt indsættelse af ny illustration).

Forudsætning Der eksisterer en illustration i en understøttet filformat.

Resultat Størrelse og position af indsat illustration er opdateret (evt. ny illustration indsat).


Trin 1: Initieres ved at aktøren klikkerpå en eksisterende illustration eller vælgerat indsætte en ny. Ved at trække iillustrationens hjørner kan størrelsen ogpositionen ændres.

Trin 2: Ændringer i størrelse og positionvises løbende.

Trin 3: Når aktøren klikker væk fra illu-strationen, gemmes position og størrelse

Trin 4: Ved at dobbeltklikke på illustra-tionen vises en dialogboks, hvor det ermuligt at indtaste en lokal sti eller enURL til illustrations-filen. Herudover erdet muligt at finde filer a la den klassiske“Gennemse. . . ”-dialogboks fra Windows.

Trin 5: Når dialogboksen lukkes gemmesændringerne og noteres i loggen.

Alternativtscenarie Trin 1: Kan også initieres ved at vælge

“Indsæt illustration” fra en menu. Hervedgås til trin 4.

Antagelser Visning af illustrationer understøttes.

214


ID - Navn 3.2 - Redigér note

Reference A23


Beskrivelse Noter kan indsættes i PVM’en. En note redigeres med et lille tekstbehandlingssy-stem (understøtter tabeller).

Forudsætning

Resultat Indholdet af en note er opdateret (evt. oprettet).


Trin 1: Initieres når aktøren klikker på eneksisterende note. Ved at trække i notenshjørner kan størrelsen og positionen aftekstfeltet ændres. Tekstlinjer ombrydesautomatisk efter tekstfeltets bredde.

Trin 2: Notens tekst åbnes i et vinduea la et “mini”-tekstbehandlingsvindue,hvor det er muligt at formatere teksten(størrelse, skriftsnit osv.) samt indsættetabeller.

Trin 3: Det er også muligt at indsættehyperlinks til andre dokumenter ellerinterne elementer.

Trin 4: Aktøren redigerer teksten ogvælger at afslutte.

Trin 5: Vinduet lukkes, ændringernegemmes og den nye tekst vises. Ændrin-gerne noteres i loggen.


“Indsæt note” fra en menu. Herved gås tiltrin 2.


215


ID - Navn 3.3 - Opret ny PVM «uses»Vis PVM

Reference A2


Beskrivelse Inden for det samme projekt kan arbejdes med flere PVM’er. Her beskrives hvordande redigeres og oprettes.

Forudsætning Et projekt eksisterer.

Resultat En eksisterende PVM er opdateret eller en ny oprettet.


Trin 1: Initieres ved at aktøren fra enmenu vælger at oprette en ny PVM.

Trin 2: Der vises en dialogboks, hvorPVM’ens navn og beskrivelse indtastes.

Trin 3: Aktøren indtaster den nødven-dige information.

Trin 4: Når informationen er indtastetog aktøren lukker dialogboksen, gemmesde indtastede oplysninger, og der tilføjesoplysninger om tidspunktet og hvem deroprettede PVM’en.

Trin 5: Herefter vises den tomme PVMved at kalde Vis PVM. Oprettelsen noteresi loggen.

Alternativtscenarie


216


ID - Navn 3.4 - Vis PVM «uses»Udskriv PVM

Reference A2


Beskrivelse PVM’en vises i overenstemmelse med retningslinjerne for det grafiske udseende.PVM’en kan udskrives.

Forudsætning

Resultat


Trin 1: Initieres når en PVM skal vises. Trin 2: Hvis ikke det er angivet hvilkenaf projektets PVM’er der skal vises, visesen dialogboks med en liste over projektetsPVM’er.

Trin 3: Aktøren vælger en PVM. Trin 4: Dialogboksen lukkes og denvalgte PVM tegnes i et nyt, maksimeretvindue. For hver klasse vises kun deattributter, hvor synlighed er slået til.Bindinger mellem klasser vises kun forde bindinger, hvor synlighed er slået til.Positionen for kind-of strukturer, noter ogillustrationer kan ændres ved at trækkedem rundt med musen.

Trin 5: Aktøren kan herefter arbejdevidere med PVM’en eller udskrive denne.Vælges de sidste kaldes Udskriv PVM.

Alternativtscenarie


217


ID - Navn 3.5 - Udskriv PVM «uses»Udskriv

Reference A2


Beskrivelse Udskriver hele PVM’en eller udvalgte dele vha. Udskriv.

Forudsætning

Resultat PVM’en er udskrevet.


Trin 1: Initieres når aktøren har valgt atudskrive den aktive PVM.

Trin 2: Hvis en del af PVM’en er mar-keret udskrives dette område (inkl. demarkerede illustrationer og noter), ellersudskrives hele PVM’en. I begge tilfældekaldes Udskriv.

Alternativtscenarie


218


ID - Navn 3.6 - Tilføj part-of klasse «uses»Redigér CRC-kort

Reference A21


Beskrivelse Part-of klasser tilføjes i strukturen i venstre side af PVM’en. Her beskrives hvorledesde tilføjes til PVM’en.

Forudsætning

Resultat En ny klasse er tilføjet i PVM’ens part-of hierarki.


Trin 1: Initieres når aktøren højreklikkerpå en klasse i PVM’en og vælger “Tilføjpart-of klasse”.

Trin 2: En ny klasse oprettes i pro-duktmodeldatabasen som underklassetil klassen, der blev højreklikket på i etaggregeringshierarki (med stærke aggre-geringsrelationer). Herefter kaldes RedigérCRC-kort.

Trin 3: Når indtastningen af oplysningerer færdig gentegnes PVM’en, så den nyeklasse vises. Ændringerne noteres i loggen.

Alternativtscenarie Trin 1a: Kan også initieres ved på en

tom PVM at højreklikke et vilkårligt stedpå PVM’en og vælge “Ny topklasse”.

Trin 2a: Den første klasse i en PVMoprettes som topklasse, som alle andreklasser er underklasser til.

Trin 1b: Kan også initieres ved ataktøren højreklikker på en klasse ogvælger “Indsæt klasse efter”.

Trin 2b: En ny klasse oprettes på sammeniveau som den, der blev højreklikketpå. Herefter kaldes Redigér CRC-kort ogfortsættes fra trin 3 ovenfor.


219


ID - Navn 3.7 - Tilføj kind-of klasse «uses»Redigér CRC-kort

Reference A21


Beskrivelse Kind-of klasser tilføjes som strukturer relateret til en klasse i part-of hierarkiet. Herbeskrives hvordan kind-of klasser tilføjes.

Forudsætning Der eksisterer mindst én klasse i part-of hierarkiet.

Resultat En kind-of struktur er tilføjet med mindst to klasser i.


Trin 1: Initieres når aktøren højreklikkerpå en klasse i part-of hierarkiet i PVM’enog vælger “Tilføj kind-of klasse”.

Trin 2: En dialogboks vises, hvor antalletaf nye klasser skal vælges (minimum to).

Trin 3: Aktøren vælger antallet af klas-ser.

Trin 4: Et antal nye klasser oprettes iproduktmodeldatabasen i et generalise-ringshierarki som underklasser til klassender blev højreklikket på.

Trin 5: For hver af de nye klasser kaldesRedigér CRC-kort, og til slut gentegnesPVM’en, så de nye klasser vises. Ændrin-gerne noteres i loggen.

Trin 6: Akøren flytter den nye strukturpå plads ved at tage fat i et af elementernemed musen og placere den et ønsket sted.

Trin 7: Forbindelseslinjen mellem klasseni part-of strukturen og den nye kind-ofstruktur tegnes automatisk.

Alternativtscenarie 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 blotoprettes én ny klasse.


220


ID - Navn 3.8 - Redigér PVM-klasse «extends»Redigér CRC-kort

Reference A2


Beskrivelse ved at dobbeltklikke på en klasse i PVM’en kan klassen redigeres.

Forudsætning Der eksisterer mindst én klasse i PVM’en

Resultat CRC-kortet for en klasse er opdateret (klasse evt. slettet).


Trin 1: Initieres ved at der dobbeltklikkespå en klasse i PVM’en.

Trin 2: Redigér CRC-kort kaldes.

Alternativtscenarie Trin 3: Aktøren vælger at slette klassen. Trin 4: Det undersøges om klassen har

et andre klasser “under sig”, og hvis deter tilfældet gives en advarsel om, at disseklasser slettes samtidig.

Trin 5: Aktøren accepterer advarslen. Trin 6: Klassen og klasserne “under” denslettes fra produktmodeldatabasen, ogsletningen ntoeres i loggen.


221


ID - Navn 3.9 - Redigér binding «extends»Redigér metode

Reference A22


Beskrivelse Bindinger viser koblingen mellem klasserne i PVM’en. Bindinger dokumenteres somklassens metoder, og her beskrives hvordan de redigeres (evt. oprettes).

Forudsætning Der eksisterer to klasser.

Resultat En binding er opdateret (evt. oprettet).


Trin 1: Initieres ved at dobbeltklikke påen eksisterende binding.

Trin 2: Der vises en dialogboks, hvorbindingens navn og den tekst, der skalvises ved siden af bindingen kan ændres.Herudover er der mulighed for at åbneen ny dialogboks, hvor alle metodensegenskaber kan redigeres (en binding er enmetode).

Trin 3: Aktøren foretager de ønskedeændringer og vælger at redigere metodensegenskaber.

Trin 4: Redigér metode kaldes.

Trin 5: Aktøren foretager de ønskedeændringer og afslutter.

Trin 6: Ændringerne gemmes i produkt-modeldatabasen og noteres i loggen.

Alternativtscenarie Trin 1: kan også initieres ved at høj-

reklikke på en klasse og vælge “Tilføjbinding”. Herved skal der i dialogboksenfra trin 2 også vælges hvilken klasse, derskal være den anden klasse i bindingen.


222

D.4 Klynge: CRC-kort


ðÎñ*ð%ò ó ô§õ ö

÷ ø ù ú�ù û

üý þÿ�� ¤ýÿ ú� � �� ú ÿ�� ý��

� ú �� ú � ù � ý�� ý��

÷ ú � � ú � ÿ ù�û�� ù � ú � ù � ý ��!� � ý��

"#� ÿ ��$�� ý�� ù � �� ø ù

ü�ý þ ÿ � �� %� � & ÿ ù � � � �

÷ ú � � ú � ÿ ù û

÷ ø ù ú�ù û

÷ ú � � ú � ÿ ù�û

'$��(� ú � � ��)�� ú � *�� !� � ý � �

�� ù �� ý��

ü�ý þ�ÿ�� %� � +'ý��,-� ú ú � ù þ ú � �÷ ø ù ú�ù û

.ý�� ú ù� / ,0� ÿ��

÷ ø ù ú ù�û

÷ ø ù ú ù�û

÷�ø ù ú ù�û� ú ÿ�� ú � ýÿ ú

� ú ÿ�� 1 ø �

÷ø ù úù û

2 � ú ÿ � � �� 2 � 1�� ø � ù �� ù � � ú 1 ú�ù � � � � ú �ý�� ù / ý þ�� ú � � ú ù ú

ü�ý�þÿ�� ü�� ÿ ú �üýþ ÿ�� %� � 3�ý��(� ø � � � �� ý�� ù ù � ù � ú �

�� ù�4 � ù � ý � � �� ý�� ý��

�¾ý�ÿ � ú � ÿ(,-� ÿ�� ú �

' � �5� ��$�� ý��

' ú � ÿ%� ú ÿ�ÿ ú� ú� ù ú ý��ø 1 ú � � � �� ù ù ú

' ú � ÿ5� ú ÿ ÿ ú� úù ú ý��,-� ÿ � � � � ù � ý�� ù ��

÷ø ù úù û

÷�ø ù úù û

�� ù ý � ú � ù � �� ý�� ú �� ý��

�¾ýÿ�� ú � ÿ(�� ý��

Figur D.4: Brugsmønsterdiagram, klynge: CRC-kort

223


ID - Navn 4.1 - Vis historik for CRC-kort «uses»Udskriv

Reference A2, A3, A4


Beskrivelse For hvert CRC-kort kan vises en liste over de ændringer, CRC-kortet har gennem-gået. Listen kan udskrives.

Forudsætning Der er foretaget ændringer i CRC-kortet.

Resultat En liste over CRC-kortets ændringer vises (udskrives evt.).


Trin 1: Initieres ved at markere en klasseog vælge “Vis historik” eller ved at vælge“Vis historik” i et åbent CRC-kort.

Trin 2: Et nyt vindue åbnes med enliste over de ændringer der er foretageti det pågældende CRC-kort (fra loggen).Listen kan sorteres efter kronologi ellerbrugernavn (for den der udførte ændrin-gen). For hver ændring vises datoen forændringen, hvem der udførte den, hvadder blev udført og CRC-kortets versionsamt status efter ændringen blev gemt.Listen kan udskrives.

Trin 3: Aktøren bladrer igennem listenog vælger at udskrive.

Trin 4: Listen formateres til udskrift ogUdskriv kaldes.

Alternativtscenarie Trin 3: Aktøren markerer et sammen-

hængende udvalg af ændringer og vælgerudskriv.

Trin 4: Kun de markerede ændringerformateres og Udskriv kaldes.

Antagelser I loggen gemmes information om ændringer, ændringstidspunkt, hvem der har fore-taget ændringen, typen af ændring, og hvad der er ændret.

224


ID - Navn 4.2 - Vis version af CRC-kort «extends»Vis CRC-kort



Beskrivelse Der kan eksistere flere versioner af samme CRC-kort. Her beskrives hvordan en givenversion kan vises.

Forudsætning

Resultat Den ønskede version af CRC-kortet vises.


Trin 1: Initieres på samme måde som VisCRC-kort

Trin 2: En dialogboks vises med enliste over de tilgængelige versioner afCRC-kortet, hvor versionsnummer og dentilhørende kommentar vises.

Trin 3: Aktøren vælger en version fralisten.

Trin 4: Herfra er trinene som i VisCRC-kort.

Alternativtscenarie


225


ID - Navn 4.3 - Gem ny version af CRC-kort



Beskrivelse Nye versioner af et CRC-kort gemmes manuelt. Versionsnummeret kan enten vælgesaf systemet eller angives af aktøren.

Forudsætning

Resultat En ny version af CRC-kortet er gemt med det ønskede versionsnummer.


Trin 1: Initieres når aktøren vælger “Gemny version” i et åbent CRC-kort.

Trin 2: En dialogboks vises, hvor der kanindtastes en kommentar til versionsæn-dringen. Det nuværende versionsnummervises, og det er muligt at angive det nyeversionsnummer.

Trin 3: Aktøren indtaster en kommentarog bekræfter at en ny version skal gemmes.

Trin 4: En ny version af CRC-kortetgemmes, hvor versionsnummeret er sat tildet 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.

Alternativtscenarie Trin 3: Aktøren vælger selv et nyt

versionsnummer.Trin 4: Hvis et nyt versionsnummer erangivet tjekkes om det er højere end dethøjest eksisterende. Hvis det er tilfældetbruges dette;hvis ikke vises en fejlmeddelseog der returneres til trin 2.


226


ID - Navn 4.4 - Vis CRC-kort «uses»Udskriv



Beskrivelse Indholdet af en klasse kan vises opstillet som et CRC-kort. CRC-kortet kan udskri-ves.

Forudsætning

Resultat Et CRC-kort er vist og evt. udskrevet.


Trin 1: Initieres når et CRC-kort skalvises.

Trin 2: Et maksimeret vindue vises,opbygget som et CRC-kort (i henholdtil specifikation). Det er ikke muligt atredigere i feltværdierne.

Trin 3: Aktøren vælger at udskriveCRC-kortet.

Trin 4: CRC-kortet formateres, så side-skift placeres mest hensigtsmæssigt ogUdskriv kaldes.

Alternativtscenarie Trin 2: Hvis der eksisterer et brugerdefi-

neret felt med link til en ekstern databaseoprettes dette link og forespørgslen ud-føres, så indholdet af feltet opdateres.Eventuelle referencer til felter på CRC-kort omsættes til en værdi, som kan brugesi SQL-udtrykket.


227


ID - Navn 4.5 - Ændr CRC-kort status



Beskrivelse Et CRC-kort kan have forskellige statuser. Her beskrives hvordan denne ændres.

Forudsætning

Resultat Status for det aktuelle CRC-kort er ændret.


Trin 1: Initieres ved at der vælges “Ændrstatus” i en menu for det åbne CRC-kort.

Trin 2: En dialogboks vises med angivelseaf de mulige statuser, et CRC-kort kanhave (“under udarbejdelse”, “passiv” eller“implementeret”). Den aktuelle status ermarkeret. Det er ikke muligt at vælgestatus “godkendt”, men muligheden vises.

Trin 3: Aktøren vælger en ny status forCRC-kortet

Trin 4: CRC-kortet gemmes med den nyestatus og ændringen noteres i loggen.

Alternativtscenarie Trin 4a: Hvis status ændres til “imple-

menteret” tjekkes om der i forvejen findesen version af CRC-kortet, der har dennestatus. I så fald vises en advarsel om atgennemførelse af ændringen vil betyde, atdet andet CRC-kort der har status “imple-menteret” vil få ændret dette til “passiv”,mens det aktive CRC-kort vil få status“implementeret”. Accepteres advarselengemmes med disse ændringer; hvis ikkereturneres til trin 2.

Trin 4b: Hvis status ændres fra “imple-menteret” gives en advarsel om, at derikke eksisterer en version af CRC-kortetmed status “implementeret”.


228


ID - Navn 4.6 - Godkend ændringer «uses»Sammenlign to versioner af CRC-kort

Reference A7


Beskrivelse Domæneeksperters ændringer af CRC-kort skal godkendes af en modellør før deeffektueres.

Forudsætning Der eksisterer et ændringsforslag, og der er udsendt en meddelelse om forslaget tilejeren af CRC-kortet.

Resultat Ændringsforslaget er enten accepteret eller afvist.


Trin 1: Initieres når aktøren respondererpå et link i en meddelelse fra systemet om,at der foreligger et ændringsforslag.

Trin 2: Sammenlign 2 ver. Af CRC-kortkaldes for at sammenligne det originaleCRC-kort med det ændrede. Hver ændringkan enten accepteres eller afvises, og deter muligt for aktøren at rette i ændringen.

Trin 3: Aktøren gennemgår ændringerneog accepterer/afviser disse.

Trin 4: Når ændringerne er gennemgåetgemmes CRC-kortet, og det noteres i log-gen. I loggen noteres også, at ændringernestammer fra et ændringsforslag, og detangives hvem der har stillet forslaget.

Alternativtscenarie


229


ID - Navn 4.7 - Sammenlign to versioner af CRC-kort «extends»Vis CRC-kort

Reference A0


Beskrivelse To versioner af samme CRC-kort kan sammenlignes for forskelle. Forskelle vises vedhjælp af farver.

Forudsætning Der eksisterer mindst to versioner af CRC-kortet.

Resultat


Trin 1: Initieres ved at aktøren vælgerat ville sammenligne to versioner af etCRC-kort.

Trin 2: En dialogboks vises med en listeover de tilgængelige versioner for detpågældende CRC-kort.

Trin 3: Aktøren vælger to versionsnumre. Trin 4: CRC-kortet for det laveste ver-sionsnummer vises som i Vis CRC-kort, ogforskellene i forhold til det højeste ver-sionsnummer er fremhævet. En tilføjelseer markeret med en anden farve (for bådetekst og symboler), og hvis noget er fjerneter dette vist ved at gennemstrege det fremfor ikke at vise det (inspireret af “Trackchanges”-funktionen i MS Word).

Alternativtscenarie


230


ID - Navn 4.8 - Redigér attribut

Reference A2, A34


Beskrivelse En klasses attributter kan redigeres i forbindelse med visning af klassens CRC-kort.

Forudsætning

Resultat Attributten er opdateret (evt. oprettet).


Trin 1: Initieres ved at aktøren dobbelt-klikker på en attribut i et CRC-kort.

Trin 2: En dialogboks vises med attri-buttens egenskaber (navn, type, enhed,værdiinterval og note). Typen vælgesfra en liste og i noten kan indsætteshyperlinks til eksterne dokumenter oginterne elementer. Det er muligt at sletteattributten.

Trin 3: Aktøren ændrer egenskaberneefter behov.

Trin 4: Det sikres at attributten har etnavn. Ændringerne gemmes og noteres iloggen.

Alternativtscenarie Trin 2: Hvis en attribut ikke eksisterer

oprettes en ny i produktmodeldatabasenog dialogboksen vises, men med tommefelter.


231


ID - Navn 4.9 - Redigér metode

Reference A2, A34


Beskrivelse En klasses metoder kan redigeres i forbindelse med visning af klassens CRC-kort.

Forudsætning

Resultat Metoden er opdateret (evt. oprettet).


Trin 1: Initieres ved at aktøren dobbelt-klikker på en metode i et CRC-kort.

Trin 2: En dialogboks vises med me-todens egenskaber (navn, type, tekst,PVM-tekst, evt. relateret klasse og note).Typen vælges fra en liste og i noten kanindsættes hyperlinks til eksterne doku-menter og interne elementer. En evt.relateret klasse vælges fra en liste medeksisterende klasser i modellen. Det ermuligt at slette metoden.

Trin 3: Aktøren ændrer egenskaberneefter behov.

Trin 4: Det sikres at metoden har etnavn. Ændringerne gemmes og noteres iloggen.

Alternativtscenarie Trin 2: Hvis en metode ikke eksisterer

oprettes en ny i produktmodeldatabasenog dialogboksen vises, men med tommefelter.


232


ID - Navn 4.10 - Redigér CRC-kort «uses»Gem ny version af CRC-kort, Ændr CRC-kortstatus, Redigér attribut, Redigér metode «extends»Vis CRC-kort

Reference A2, A3, A4, A7


Beskrivelse En klasses egenskaber ændres gennem visning af klassens CRC-kort.

Forudsætning

Resultat Klassens egenskaber er ændret.


Trin 1: Initieres ved at aktøren vælger atredigere CRC-kortet i forbindelse med VisCRC-kort.

Trin 2: Det undersøges om CRC-korteter åbnet af andre brugere.

Trin 3: Hvis ikke låses CRC-kortet (samtde elementer, der kan påvirke eller påvirkesaf CRC-kortet) mod ændringer fra andrebrugere.

Trin 4: CRC-kortets værdifelter (und-tagen ID, oprettelsesdato, attributterog metoder) kan redigeres direkte ved atskrive i felterne. Kun CRC-kortets ejer kanændre i “Ejer”-feltet og “Med-redaktører”-feltet.

Trin 5: Aktøren ændrer i indholdet ogdobbeltklikker evt. på attributter ellermetoder.

Trin 6: Dobbeltklikkes på en attributkaldes Redigér attribut. Dobbeltklikkes påen metode kaldes Redigér metode. I enmenu kan vælges at gemme en ny versionaf CRC-kortet eller ændre CRC-kortetsstatus. Vælges disse kaldes Gem ny versionaf CRC-kort henholdsvis Ændr CRC-kortstatus.

Trin 7: Afsluttes ved at aktøren lukkervisningen af CRC-kortet.

Alternativtscenarie Trin 3: Hvis en anden bruger har låst

CRC-kortet mod ændringer vises enbesked om dette med oplysninger omhvem der har låst CRC-kortet.

Trin 8: Aktøren vælger at slette klassen. Trin 9: Samme tjek som i trin 2 oven for.

Trin 10: Det undersøges om klassen haret andre klasser “under sig”, og hvis deter tilfældet gives en advarsel om, at disseklasser slettes samtidig.

Trin 11: Aktøren accepterer advarslen. Trin 12: Klassen og klasserne “under”den slettes fra produktmodeldatabasen,og sletningen noteres i loggen.


233


ID - Navn 4.11 - Godkend CRC-kort

Reference A4

Aktør(er) Domæneekspert

Beskrivelse Domæneeksperter skal lave den endelige godkendelse af et CRC-korts udformningved at ændre kortets status til “Godkendt”.

Forudsætning

Resultat CRC-kortets status er ændret til “godkendt”.


Trin 1: Initieres ved at aktøren vælger“Godkend CRC-kort” i en menu for for detåbne CRC-kort.

Trin 2: En dialogboks vises med angi-velse af CRC-kortets aktuelle status ogmulighed for at godkende eller annulleregodkendelsen.

Trin 3: Aktøren vælger at trykke påknappen “Godkend” i dialogboksen.

Trin 4: CRC-kortet gemmes med den nyestatus, og ændringerne noteres i loggen.

Alternativtscenarie Trin 3: Brugeren vælger at annullere

godkendelsen.Trin 4: Dialogboksen lukkes og ingenændringer gemmes.


234


ID - Navn 4.12 - Foreslå ændring «uses»Send meddelelse om ændringsforslag

Reference A7

Aktør(er) Domæneekspert

BeskrivelseDomæneeksperter kan ikke ændre en klasses egenskaber direkte, men kan stille æn-dringsforslag, som skal effektueres af en modellør. Besked herom sendes automatisktil modelløren.

Forudsætning

Resultat Et ændringsforslag er stillet og besked er sendt til ejeren af CRC-kortet.


Trin 1: Initieres ved at en aktør vælger“Foreslå ændring” under visning af etCRC-kort (som beskrevet i Vis CRC-kort).

Trin 2: Under visningen af CRC-kortetkan aktøren kun se indholdet af felterne,men ikke redigere disse.

Trin 3: Aktøren dobbeltklikker på enattribut eller metode.

Trin 4: Attributtens eller metodensdetaljer vises i et vindue, men kan ikkeredigeres. I stedet kan vælges at sende etændringsforslag.

Trin 5: Aktøren trykker på “Forslag tilændring”.

Trin 6: Detaljerne kan nu redigeres.

Trin 7: Aktøren foretager ændringer ogvælger “Send”.

Trin 8: Der gemmes en kopi af CRC-kortet med de foretagede ændringer, ogSend meddelelse om ændring kaldes medejeren af CRC-kortet som modtager.

Alternativtscenarie Trin 3: Et forslag kan også stilles for

andre elementer end attributter og me-toder. Det gøres ved at højreklikke påelementet i CRC-kortet og vælge “Forslagtil ændring”. Herved fortsættes fra trin 6.


235


ID - Navn 4.13 - Send meddelelse om ændringsforslag

Reference A7

Aktør(er) Kommunikationssystem

Beskrivelse Når et ændringsforslag er stillet sendes besked til ejeren af CRC-kortet.

Forudsætning Et ændringsforslag er stillet. Integrationen med kommunikationssystemet er konfigureret.

Resultat Besked er sendt til ejeren af CRC-kortet.


Trin 1: Initieres ved kald fra Forslåændring.

Trin 2: Der dannes en standardbeskedmed et link til det ændrede element. Be-skeden sendes via Kommunikationssystem.

Trin 3: Der kvitteres med en bekræftelseaf afsendelsen.

Alternativtscenarie

Antagelser Beskeder kan sendes via et eksternt kommunikationssystem.

236


ID - Navn 4.14 - Send meddelelse om uberørt klasse


Aktør(er) Tiden

Beskrivelse Når en klasse er under udarbejdelse sendes automatisk besked til ejeren, hvis klassenikke er tilgået inden for et defineret tidsrum.

Forudsætning Integrationen med kommunikationssystemet er konfigureret.

Resultat Besked


Trin 1: Initieres når et CRC-kort medstatus “Under udarbejdelse” ikke er blevetændret af ejer eller med-redaktører i denforuddefinerede tidsperiode.

Trin 2: Der dannes en stanardbeskedmed henvisning (og link) til det pågæl-dende CRC-kort.

Trin 3: Der kvitteres med en bekræftelseaf afsendelsen.

Alternativtscenarie

Antagelser Beskeder kan sendes via et eksternt kommunikationssystem.

237


ID - Navn 4.15 - Søg i CRC-kort «uses»Vis CRC-kort



Beskrivelse Det er muligt at søge på alle felter i CRC-kortene og på den måde finde et specifiktkort.

Forudsætning

Resultat En liste vises med CRC-kort, der matcher søgekriterierne.


Trin 1: Initieres ved at der vælges “Søg iCRC-kort”.

Trin 2: Der vises en dialogboks med etfelt hvor søgestrengen kan skrives og enliste over felterne på et CRC-kort. Det ermuligt at markere flere felter på denneliste. Det er muligt at angive om søgningenskal begrænses til det åbne projekt, ellerom der skal søges globalt i alle tilgængeligeprojekter. Som udgangspunkt er søgningenbegrænset til det åbne projekt.

Trin 3: Aktøren vælger hvilke felterder skal søges inden for, og skriver ensøgestreng.

Trin 4: Produktmodeldatabasen søgesigennem ved søgning i de valgte felter.

Trin 5: Resultatet vises i en liste inde-holdende felterne klassenavn, klasse ID,beskrivelse, dato for oprettelse samt defelter, der blev søgt i.

Trin 6: Aktøren dobbeltklikker på etCRC-kort i listen.

Trin 7: Vis CRC-kort kaldes og viser detaktuelle CRC-kort.

Alternativtscenarie Trin 5: Hvis der ikke findes et CRC-

kort, der matcher søgekritereiet, vises enbesked om dette, og der returneres tildialogboksen i trin 2.


238


ID - Navn 4.16 - Vis oversigt over CRC-kort



Beskrivelse En oversigt over alle CRC-kort i modellen kan vises, sorteret efter navn. Det ermuligt at søge i listen.

Forudsætning

Resultat En liste over alle CRC-kort vises i et separat vindue.


Trin 1: Initieres ved at aktøren vælger“Vis lister over CRC-kort”.

Trin 2: Et vindue åbnes, hvor en listeover alle CRC-kort i produktmodellenvises. Er en PVM aktiv vises alle CRC-kort, hvor kontekst er lig “PVM”; er etklassediagram aktivt vises kun de CRC-kort, hvor kontekst er lig “Klassediagram”.Ved hjælp af farver eller symboler angivesfor hvert CRC-kort om den tilsvarendeklasse er inkluderet i det aktive diagram.

Trin 3: Aktøren trækker med musenet CRC-kort fra listen over i det aktivediagram.

Trin 4: Klassen tilføjes i diagrammet, ogalle underliggende aggregeringsstrukturerog overliggende generaliseringsstrukturertilføjes automatisk, hvis de ikke alleredeeksisterer i diagrammet. I listen opdateresfarven eller symbolet for de(n) tilføjedeklasse(r).

Alternativtscenarie


239

D.5 Klynge: Klassediagram


657 8!9�9�:!;�< 8�=�> 8�?@ A�B C�D E F�G @ H I�G J E�K HL�M�N K O G B�I�B�K P G D Q B�GR E K S R�T G B O O B U K B

V R T C�D W E�G W L�X X Y�R C B�U U M G

V R T C�D W�E�G W L�X X Z C K P G D Q

[ J K B K \ V R T C D W�E�G W L(X X ]�R�N ^ D E�J G W O R G

[ J K B�K \Z C�U _%EP U W�K K B C D W�H E�G W L

`$W L�L B N U D E NC R P J H L B N O W O D R N�L B�C(P R N ^ D E J G W O R G

[ J K B K \

a T G B O N b OP U W K K B�H C�D W E�G W L

A�B�C�D E F�G P U b N E B

A�B C�D E�F G O B L W

c L�T�R G O F�G K O G J P O J G^ G W(d e Y[ B f O B N C K�\e!D K�P U W K K B

e�D K�P U W K K B C�D W E G W Lg�A�g�H P R G O X X A�B C D E�F�G g�A�g�H P R G O

a�Q B�G ^ M G L�R C B�U O D UP R N ^ D E J�G W O R G

V�D U ^ M h P U W�K K B[ J K B K�\

i-j(i�k l�m!n o p p q5r sti5j(i�k l�m!n o

u v�w o v!x�y s$z

u�{ s v s z

|�m�} y r ~!��n ~��p p ��m�� x$v$v l�s�} v n o

[ J K B K�\

Figur D.5: Brugsmønsterdiagram, klynge: Klassediagram

241


ID - Navn 5.1 - Overfør model til konfigurator

Reference A51


Beskrivelse Afhængigt af den valgte konfigurator kan produktmodellen i dokumentationsværk-tøjet overføres til konfiguratoren.

Forudsætning Konfiguratoren kan indlæse produktmodeller fra andre systemer.

Resultat En fil (filsæt) er genereret og kan indlæses i konfiguratoren.


Trin 1: Initieres ved at aktøren vælger“Overfør til konfigurator”.

Trin 2: På baggrund af det aktive klas-sediagram og retningslinjerne for konfigu-ratorens filformat genereres en fil (elleret sæt af filer), som konfiguratoren kanindlæse. Handlingen noteres i loggen.

Alternativtscenarie

Antagelser Det er muligt entydigt at definere hvordan produktmodellen skal overføres til kon-figuratoren.

242


ID - Navn 5.2 - Sammenlign dokumentation med konfigurator

Reference A5, A7

Aktør(er) Modellør, Konfigurator

Beskrivelse Produktmodellen fra dokumentationsværktøjet sammenlignes med strukturen i kon-figuratoren, og forskelle tydeliggøres.

Forudsætning Konfiguratorens produktmodel kan tilgås for eksterne systemer.

Resultat Der vises en rapport, hvor forskellene summeres.


Trin 1: Initieres når aktøren vælger“Sammenlign med konfigurator”.

Trin 2: Konfiguratorens produktmodelindlæses og analyseres.

Trin 3: Der oprettes et nyt klassedia-gram med samme navn som det aktive,blot tilføjet “- sammenligning <dato>”(f.eks. “Generator A11 - sammenligning23/5 2002”). Klassediagrammet kan ikkeredigeres. I klassediagrammet anvendessamme notationsform som i Sammenlign2 ver. af CRC-kort, dvs. fællestræk visesmed en farve (sort), elementer der er idokumentation, men ikke i konfiguratorvises med en anden farve (rød) og ele-menter, der er i konfigurator men ikkei dokumentationen vises med en tredjefarve (blå). Det er muligt at udskriveklassediagrammet; herved kaldes Udskrivpå samme måde som i Vis klassediagram.Handlingen noteres i loggen.

Trin 4: Aktøren vælger at få udskreveten rapport.

Trin 5: En dialogboks vises, hvor aktørenkan vælge mellem tre rapporter; en rapportmed alle forskelle, en rapport med de ting,der mangler i dokumentationen i forholdtil konfiguratoren samt en rapport overde ting, der mangler i konfiguratoren iforhold til dokumentationen.

Trin 6: Aktøren vælger at udskrive enrapport.

Trin 7: Rapporten formateres med hen-syn til valget af indhold og Udskriv kaldes.

Alternativtscenarie

Antagelser Det er muligt at læse konfiguratorens produktmodel og entydigt analyse strukturen.

243


ID - Navn 5.3 - Redigér klynge «uses»Vis klassediagram

Reference A32


Beskrivelse Klassediagrammet for en klynge redigeres (eller oprettes), så den omfatter de øn-skede klasser.

Forudsætning

Resultat Klassediagrammet for en klynge vises og kan redigeres. Alternativt oprettes en ny klynge.


Trin 1: Initieres ved at aktøren dobbelt-klikker på på en eksisterende klynge

Trin 2: Vis klassediagram kaldes for atvise den pågældende klynge.

Alternativtscenarie Trin 1: Kan også initieres ved at aktøren

vælger “Opret klynge”.Trin 2: En dialogboks vises, hvor aktørenskal indtaste navn for klyngen.

Trin 3: Aktøren indtaster navnet på dennye klynge.

Trin 4: En ny klynge oprettes og vises påklassediagrammet. Ændringen registreresi loggen.

Antagelser Klasser kan kopieres mellem klynger ved traditionel marker-kopiér-sæt-ind funktio-nalitet.

244


ID - Navn 5.4 - Redigér tema

Reference A33


Beskrivelse Et tema redigeres (eller oprettes), så det omfatter de ønskede klasser.

Forudsætning Der eksisterer mindst to klasser i klassediagrammet.

Resultat


Trin 1: Initieres ved at aktøren med mu-sen tager fat i stregen, der repræsenterertemaet. Størrelse og position af temaetkan ændres med musen.

Trin 2: Når temaet “slippes” med musenregistreres ændringerne og gemmes idatabasen. Det registreres også hvilkeklasser, der er indbefattet af temaet.Ændringen noteres i loggen.


vælger “Opret tema".Trin 2: En dialogboks vises, hvor aktørenskal indtaste navn for temaet. Musemar-køren ændrer udseende og der lægges optil at aktøren med musen skal trække enfirkant i klassediagrammet – fortsæt fratrin 1 oven for.


245


ID - Navn 5.5 - Redigér relation

Reference A33


Beskrivelse En relation redigeres (eller oprettes), for at forbinde to klasser.

Forudsætning Der eksisterer mindst to klasser i klassediagrammet.

Resultat Relationen mellem to klasser er opdateret (evt. oprettet).


Trin 1: Initieres ved at aktøren dobbelt-klikker på en relation i et klassediagram.

Trin 2: En dialogboks åbnes, hvor alleegenskaberne for relationen kan redigeres.

Trin 3: Aktøren redigerer egenskabernefor relationen.

Trin 4: Oplysningerne gemmes og rela-tionen gentegnes så grafikken afspejleregenskaberne.


vælger “Tilføj relation”.Trin 2: Musemarkøren ændres til etlinjesymbol.

Trin 3: Aktøren trækker en linje mellemto klasser.

Trin 4: Der fortsættes fra trin 2 ovenfor.


246


ID - Navn 5.6 - Opret nyt klassediagram «uses»Importér struktur fra PVM

Reference A3


Beskrivelse Et nyt klassediagram oprettes og baseres evt. på strukturen fra en PVM.

Forudsætning

Resultat Et nyt klassediagram er oprettet.


Trin 1: Initieres ved at aktøren vælger“Opret nyt klassediagram”.

Trin 2: En dialogboks vises hvor aktørenskal give klassediagrammet et navn.

Trin 3: Aktøren navngiver klassedia-grammet.

Trin 4: Det tjekkes om der eksisterer etklassediagram med det samme navn. Hvisikke oprettes et nyt, tomt klassediagram,som vises.

Alternativtscenarie Trin 1: Initieres også når Vis klassedi-

agram kaldes, og der ikke eksisterer etklassediagram.

Trin 2: Der gives mulighed for at baseredet nye klassediagram på en eksisterendePVM.

Trin 3: Aktøren vælger desuden at basereklassediagrammet på en eksisterendePVM.

Trin 4: Det tjekkes om der eksisterer etklassediagram med det samme navn. Hvisikke oprettes et nyt og Importér strukturfra PVM kaldes.


247


ID - Navn 5.7 - Tilføj klasse «uses»Redigér CRC-kort

Reference A3


Beskrivelse Klasser kan tilføjes til et klassediagram fra listen over klasser i produktmodelleneller oprettes fra ny.

Forudsætning

Resultat En ny klasse er oprettet.


Trin 1: Initieres ved at aktøren højre-klikker på et tomt sted i klassediagrammetog vælger “Tilføj klasse”.

Trin 2: En ny klasse oprettes i produk-tmodeldatabasen. Herefter kaldes RedigérCRC-kort.

Trin 3: Når indtastningen af oplysningerer færdig gentegnes klassediagrammet, såden nye klasse vises. Ændringerne noteresi loggen.


“Tilføj klasse” fra en menu, når et klasse-diagram er aktivt.


248


ID - Navn 5.8 - Vis klasse «extends»Vis CRC-kort

Reference A3


Beskrivelse En klasse vises ved at vise det tilhørende CRC-kort.

Forudsætning

Resultat CRC-kortet for klassen vises.


Trin 1: Initieres ved at aktøren dobbelt-klikker på en klasse i klassediagrammet.

Trin 2: Vis CRC-kort kaldes.

Alternativtscenarie Trin 1: Kan også initieres ved at en

klasse er markeret og aktøren vælger “Visklasse”.


249


ID - Navn 5.9 - Vis klassediagram «uses»Udskriv, Udlæg klassediagram

Reference A3


Beskrivelse Et klassediagram kan tegnes som beskrevet i standarden for UML. Klasserne ogderes relationer kan placeres automatisk af systemet.

Forudsætning

Resultat Klassediagrammet er tegnet og indholdet kan redigeres ved at klikke på elementerne.


Trin 1: Initieres når en aktør vælger “Visklassediagram” på et vilkårligt tidspunkt.

Trin 2: Såfremt der findes mere end étklassediagram vises en dialogboks, hvoraktøren skal vælge mellem de eksisterendeklassediagrammer.

Trin 3: Aktøren vælger et klassediagram. Trin 4: Et nyt vindue åbnes, hvor klasse-diagrammet tegnes som det så ud da detsidst blev gemt af en bruger.

Trin 5: Aktøren (kun “Modellør”) kanflytte alle elementer ved blot at flytte demmed musen. Forbindelser mellem elemen-terne opdateres og tegnes automatisk.Alle klasser i produktmodeldatabasen derer tilknyttet klassediagrammet, inkluderespå klassediagrammet.

Trin 6: Aktøren (kun “Modellør”) vælger“Udlæg klassediagram” fra en menu.

Trin 7: Udlæg klassediagram kaldes.

Alternativtscenarie


250


ID - Navn 5.10 - Udlæg klassediagram

Reference A3


Beskrivelse Frem for manuelt at placere klasser og deres relationer kan systemet analysere struk-turen og placere elementerne på den mest hensigtsmæssige måde.

Forudsætning

Resultat Klassediagrammet er re-organiseret så klasserne er placeret optimalt i forhold tilrelationerne.


Trin 1: Initieres når aktøren vælger“udlæg klassediagram” fra en menu, når etklassediagram er aktivt.

Trin 2: Klassediagrammet udlæggesved at klasserne placeres optimalt iforhold til hinanden og forbindelsernemellem klasserne “routes” på den mestoptimale måde (i forhold til det bedstegrafiske layout, der giver det bedsteoverblik). Baseres på principperne forklassediagrammet i UML.

Alternativtscenarie

Antagelser Det er muligt at definere en algoritme for optimal placering af de forskellige elemen-ter.

251


ID - Navn 5.11 - Importér struktur fra PVM

Reference A31, A32


Beskrivelse PVM’en kan virke som udgangspunkt for et klassediagram, og her beskrives hvordanstrukturen fra PVM’en kan overføres til et klassediagram.

Forudsætning

Resultat Klasserne fra PVM’en er kopieret til nye klasser, der er inkluderet i klassediagram-met i den samme struktur som på PVM’en.


Trin 1: Initieres ved kald fra Opret nytklassediagram.

Trin 2: Der vises en dialogboks meden liste over de eksisterende PVM’er iprojektet.

Trin 3: Aktøren vælger én PVM. Trin 4: Strukturen og indholdet fraPVM’en analyseres og klasserne i PVM’enkopieres med deres indhold til nye klasser,hvor egenskaben “klassediagram” sættestil sand.

Trin 5: Relationer oprettes, så part-of relationer fra PVM’en oversættes tilstærke aggregeringer i klassediagrammetog kind-of relationer oversættes til genera-liseringsrelationer. Noter og illustrationermedtages ikke.

Trin 6: Ændringerne noteres i loggen.


vælger “Importér struktur fra PVM” i enmenu, når et klassediagram er aktivt.

Trin 2: Indholdet i det eksisterendeklassediagram slettes og der fortsættes fratrin 2 oven for.

Antagelser Der eksisterer en entydig specifikation for, hvordan en PVM skal overføres til etklassediagram.

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 for-klaring af de enkelte klasser og deres attributter samt metoder.

253

Bilag E - Klassediagram

� �� %��(� ��$�� $�0��(� ��!��

��

�

�� 5��¡� �5��¢ £�¤(£�¥�� ¦�§ �� ¨��©%ª5��©��¢ «%� �� ¬�¢ �� £!¢ !¥�� 5£�¢ �� ¬5�!� ¢ �$�� £�¡�¢ ��$��¢� ¬�¢ �!¢ ®��

¯�° ±�²�²�³�� %�!��¡� ´��¥�� %£!¢ ��µ0¨¶¢ ��$� ¢� ¬��¡�� ·¸��¹(£�£�� ¡

º¼»�½ ¾�¿%»

À�Á�Â ��¬%�¡!¢ ��Ã Ä

�Å� ��Æ#Ç�È

� 5��¡� ´%��¢� ª5�� ¤0� �É��0� ��·�� Ê�¤�� Ê��¡!¢

Ë-Ì�� ³

��%� � �

À ª5£�®!¢ ��Ã Ä

��ª%�� ¤-� �Í��%� ��!�� ´��¥�� %£!¢ �� ¬�!¡�� ·� ¨¶®�� ¢ ¤ �� ¨¶®�� ¢ ¤(Î��¹��!� ¤ ��¹��!� ¤�Î

Ï0³�° ±�� Ì%�

�� %��¡� �Å¡!¢ �� 5¢ ¢ �

��Ð Ñ�Ò�³�Ð Ó ³�° �

Ô5Õ�²�� ³�Ö×�(Ö¼³�� Ì��(³

À µÅ� ��5�!¢ ��Ã Ä� ¬(Ø�� ¥!¢��(� ��Ø�� ¡�·

Ù��Å° � ��Ú

�

��

À ´��·�¡$¤5�0�-Ã ÄÀ%Û ©�� ÜÝ·�Ã ÄÀ µ5�� Ø�� Ã Ä

� -��¡¯�° ±�²�²�³��%� ±�Ò(Ð ±�Ö

�

�

Þ £��®��#��¥�ßà©��¡à®�¡�©�� ·�·��¡!©��¼á#á�� Ê¶£�©�� 0¢ ¢ � � â�®!¢ ¢ ��£�Êã¥�£��!� ¢ � £�¡¶£��$� �� £��¢ ��·�¡�� ¡�·à��©�� £��(� �!� �¼Ê��©�¢ ��·��¢

À ´��·�¡$¤5�0�-Ã ÄÀ ´��·�¡$¤5�(µ0¨×Ã Ä

� µ0�� £�¡ä�å æ�ç%è æ�éÝê�»�ë »�éì»�í(½

��

� 5��¡� µ5Üî� ©�� ¡�¥�®$¢5��¹�£�£�� ¡

�ÅÐ Ñ�Ò(³�Ð ±�� Ð � ï�Ñ��

�

�

À�ð â�¡��-�-Ã Ä� 5��¡� �%� ��!��©�� ·�� Ê

¯�° Õ��Ò%³

� ��

� �

À ´%��·�¡ ¤0��µÅ¨×Ã ÄÀ ¦(�$��¥!£�� ¢ Ã ÄÀ µ5�� Ø!�� Ã Ä

� 5��¡� ´�£�¥��!� ��$�ì��(� ��$��

ñ�ò#ó

À ´(��·�¡�Ã Ä

� ´��¥�� ¬�¢ «%� � �� !�� £��!� ¢ � £�¡� ¬�¢ �

ô ° ° Ñ�²!� Ð ±�� Ì-�

�

��

À�ð â�¡��%£��®�Ê#��¡$¢ Ã Ä� ¬�¢ �õ(�� Ù-Ì%Ú�Ñ�Ö¸³��

� 5��¡� ´��¥�� ¡�� ¢ � �� µ-Üö� ©�� 5£�¢ �� µ5Üö� ©�� á¶Ê×� ß�©�� ¦(¡ Â ��©

÷Å� � Ð � ï�Ñ��

� 5�!��¡ø�³�Ö¸±

�

�

��

� 5��¡� ¹��$� � �� %� £$§ �� ¢ � ��©�� 5��¢ £!¤�£�¥��

ñ5Ð Ì!ù ³�Ú!�

�

�(� � �

�

��

�ÅÐ Ñ�Ò�³�Ð ��±�� ± ú ° Ì5ï�±�° ³��±�� ±

À �%��¡�ª%��¥�¥�£�� ¢ Ã Ä� Þ �� ¢ �� ´-� � ·�Üö¡�·�� · Â ��©

Ï0±�û�û�Ì-Ð � ²�Ú�±�ï�³�° Ì%� �%� � ��%� � �

�Å� � �Ý�� !�� Â ��¢�®�¡�� ¢5� � ��%��¢ ¢ �×��%®�©�� ©�¢�� Â ��¡��!¡¢ � � £�� $®�� · Â ��©��¡ �

Figur E.1: Klassediagram for dokumentationsværktøj

254

E.1 Encyklopædi for klassediagram


Tabel E.1: Encyklopædi for klassediagram

Klasse (kursiv angiver abstrakte klasser)

Navn BeskrivelseAttribut En attribut i en klasse.

Navn Navn på attributten.Type Attributtens art (boolean, integer etc.).InitialVærdi Attributtens startværdi i konfiguratoren.Note Beskrivelse af attributten.Værdiområde Interval eller liste for lovlige værdier, attributten kan antage.Enhed Attributtens enhed (f.eks. kg, meter etc.).

Bind_OCL En produktmetode med OCL-indholdChkSyntaks Tjekker OCL-udtrykkets syntaks (validering).

Bind_txt En produktmetode med alm. tekstindhold.Paavirker En liste af referencer til de klasser, som bindingen påvirker.PaavirkesAf En liste af referencer til klasser, som bindingen påvirkes af.

Brugerattribut En brugerdefineret attribut i et brugerdefineret felt.Navn Navnet på attributten.Værdi Attributtens indhold.Input Sand, hvis attributten skal modtage input fra brugeren. Falsk,

hvis attributten skal vise information.Brugerfelt Felt på CRC-kort indeholdende et antal brugerattributter.

Navn Brugerfeltets navn (titel).AntalAttr Antallet af tilknyttede attributter for brugerfeltet.

DBlink En slags brugerattribut, der henter indhold fra en ekstern DB.Script Script, der foretager udvælgelsen af data (SQL).Placering Link-oplysninger om opkobling til den pågældende database.VisData() Viser de hentede data på baggrund af scriptet.

Diagram_element Abstrakt overklasse for alle elementer i et diagram.Version Indeholder versionsnummeret for diagramelementet.Tegn_KD() Tegner elementets grafik i et klassediagram.Tegn_PVM() Tegner elementets grafik i en PVM.

ExtDokument Reference til eksternt dokument (f.eks. Word. AutoCAD etc.).Sti Sti til dokumentets placering (absolut).ÅbnDokument() Kalder det eksterne program, der skal åbne dokumentet med de

korrekte parametre.Illustration Reference til billedfil, der skal vises i PVM.

Type Illustrationens format (jpeg, gif etc.).Størrelse Bredde og højde af illustrationen (i PVM’en).Position Positionen for øverste venstre hjørne af illustrationen (i PVM’en).Sti Sti til illustrationens placering.Tegn() Tegner illustrationen på PVM’en.

– fortsættes næste side –

255

Bilag E - Klassediagram

Tabel E.1: (fortsat fra forrige side)


Navn BeskrivelseKlasse Repræsenterer en klasse i modellen.

Navn Klassens navn.Dato_opr Dato for oprettelsen af klassen.Ejer Reference til ejeren af klassen.MedRedaktører Liste af referencer til medredaktører af klassen.Stereotype Har en værdi, hvis klassen er en stereotype. Værdien angiver ty-

pen.Note Beskrivelse af klassen.Skitse Reference til tilknyttede billeder som støtte for beskrivelsen.Kontekst Indikation om klassen eksisterer i en PVM eller i et klassedia-

gram.Status Angiver klassens status (working, released etc.).

Klassediagram En klasse eksisterer for hvert klassediagram i modellen.Navn Klassediagrammets navn.Tegn_KD() Tegner klassediagrammet ved at bede alle elementer om at tegne

sig selv.Udlæg() Placerer alle elementer i klassediagrammet på den mest hensigts-

mæssige måde, og udlægger alle relationer.Verificer() Tjekker at syntaksen i klassediagrammet er korrekt, og at dia-

grammet er konsistent.Klynge En klynge i et klassediagram

Navn Navn på klyngen (vises på diagram).Klassediagram Reference til det klassediagram, klyngen repræsenterer.ÅbnKD() Åbner det det relaterede klassediagram.

Metode Abstrakt overklasse for alle metoderID Unikt ID for metoden.Navn Metodens navn.Type Metoden type.Note Beskrivelse af metoden.PVMtekst Tekst, der skal stå i PVM ved bindingen.Synlig Sand, hvis bindingen skal vises på PVM, eller falsk.

Note En note på enten klassediagram eller PVM.Navn Notens navn.Tekst Notens indhold.Rel_ID Evt. reference til diagramelement. Hvis reference eksisterer, teg-

nes en linie til diagramelementet.Projekt Et projekt med tilhørende produktmodel.

Navn Projektets navn.Beskrivelse Beskrivelse af projektet.Dato_opr Dato for oprettelse af projektet.Projektleder Reference til lederen af projektet.

– fortsættes næste side –

256


Tabel E.1: (fortsat fra forrige side)


Navn BeskrivelsePVM PVM tilhørende et projekt.

Navn PVM’s navn.Topklasse Reference til klasse, der er topklasse for diagrammet.Tegn_PVM() Tegner PVM’en.Eksport() Eksporterer PVM’en til klassediagram efter foruddefinerede reg-

ler.Verificer() Tjekker at PVM’en syntaksmæssigt er lovlig.

Rapportskabelon Skabelon for rapporter, enten lokal eller global.Felter En liste af felter, der udgør rapporten.Tilgængelighed Angiver om skabelonen er tilgængelig globalt, eller kun for det

aktuelle projekt.DanRapport() Danner rapporten på baggrund af felterne ved at lave en fore-

spørgsel i databaserne.Relation Relation mellem klasser i klassediagram.

Rel_ID ID på den anden klasse, der relateres til.Type Relationens type (aggregering, generalisering etc.).Note En brugerindtastet noteSynlig Sand hvis relationen skal vises på diagrammet, ellers falsk.Mult_1 Kardinaltal for værtsklassen.Mult_2 Kardinaltal for den relaterede klasse.Beskr_1 Beskrivelse for relationen ved værtsklassen.Beskr_2 Beskrivelse for relationen ved den relaterede klasse.Route() Finder den bedste vej mellem de to klasser.

System_metode Systemmetode med tekstindhold.Tema Samling af klasser i klassediagram i et tema.

Navn 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 etudtryk for det endelige design. Formålet er således at give et indtryk af doku-mentationsværktøjets funktionalitet og understøttelse af arbejdsgangen frem foret bud på design af brugergrænsefladen.

F.1 Scenarie for prototyper af skærmbilleder

Baggrund En produktmodel er under opbygning, og der eksisterer allerede enstruktur 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

Figur F.2, s. 262projektet AJ-stole. Da denne bruger sidst loggede af systemet fra dette projektvar 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 dertrykkes 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ælgeAdd 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 vinduetlukkes, 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

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, somFigur F.8, s. 268

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 trykkerpå knappen Opret ny klynge på værktøjslinjen, hvorefter en dialogboks vises,hvor klyngen skal navngives. Der indtastes Stolekrop og trykkes OK. Hervedlukkes dialogboksen, og den nye klynge ses på klassediagrammet i listen overCRC-kort. Herefter markeres Stoleskal og Underdel og trækkes over på symboletFigur F.9, s. 269

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.Figur F.10, s. 270

Ved at dobbeltklikke på klyngen Stolekrop i listen over CRC-kort åbnes klas-sediagrammet for klyngen – nu indeholdende klasserne Stoleskal og Underdel,Figur F.11, s. 271

samt Underdel ’s underklasser. Herudover vises klassen AJ-stole:AJ-stole, hvortilde to klasser er relateret med en aggregeringsrelation.

Brugeren er interesseret i information om klassen Stoleskal, og ved at dobbelt-klikke på klassen åbnes klassens CRC-kort. I feltet Beskrivelse er et link tilFigur F.12, s. 272

en internetside, og ved at trykke på linket åbnes computerens browser og visersiden.

Brugeren vender tilbage til dokumentationsværktøjet og logger af ved at trykkepå knappen Log af på værktøjslinjen. En dialogboks vises, hvor brugeren skalbekræfte valget. Ved tryk på OK lukkes dokumentationsværktøjet ned.

260


ü�ý�þÉþ�ÿ�� ÿ�� ! �� "$#�� %� #'& #)('* �+� #�,�-�./.�#)�)��& ��

0�0�0�0�0�0�0�0

1�� 2� -�� 3

-�� "$#��

4%5 6�7�8�9�:�; <=:�; >

?

Figur F.1: Før enhver brug af værktøjet skal brugeren identificere sig over for systemet ved at logge på

261


@�A�BCBED�F�G�H G�IJ)K L M�N O�P�K Q R�K M�S J T�U V+W Q N X�L W�N N2YZK W�[�U W�V \ RZ] XZ^)X�_ ` W�U P \�U T a M�` Q b�M�L c

\�U T a M�` Q d e�T�Q f�K g�[�N M�L M�` Q M�P h�i�j i%h�k�k�h%i�l m�h

@�A�BCBED�F�G�H G�I�nZo�G�H G�p�q$r�I D�s G�p�qt)M�L M�` Q�W�c�U T a M�` Q�u U T�V/Q f�MEL K N Q

v%w x�y�z�{�|�} ~=|�} �

�

\)U T a M�` Q X�U M�W�Q M�PEP�W Q M

�� _ N Q T�L M\)��_ V%��)L M�UJ�b�_ �)T�g�Q T�U �� !��)��

� ��+��)�� E��)��

��

Figur F.2: Umiddelbart efter login skal vælges, hvilket projekt der skal arbejdes med

262


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


!�"�#$#&% '�(�) (�*�+�,�( -/.0) 1�2�243 5 6�+ 7 89;: < =�> ?A@ : B C�: =ED 9 F�G HJI B > K�< IE> >ML�: I�N0G I H O C�P K�Q;K R S I0G @ O0G F T =ES B U�=0< V

W XYZ�B B G : [�\EB = P�=EB ]�F�@

^ _M`OA=�B =0G�U�I0a�> =0acb VE=EB =0G ] de�-gf (�* `

!�%�+ (�'�h i %�* 20`kj aAF�aA= l_�( 2E.0* h m0i h %�f n 5;( i . o

p�i iE* h q�r0i ( 2

s t�u4v�w0xAy;z { | } { u�~�w�~ } w0z w0v�� s;t�uc|0{ y } ��z wc{ ~�xEw0z } w�v��

#&(0i %�'�( *

O0G F T =�S B ��Z�� R > B F0< = �0�EG : �E= V�< I�@0= �0�� 4�0��0�4�� 0�

�� z { �Ew�|;� �0v0w,�1��(�`�A��R �

�E�;�� A� � � �¡ � ¢ � £ � ¡ ¤ ¥FEB =¦ L

¥I�H4=

�E�;��§�� ¨ � ¡ �¡ � ¢ � £ � ¡ ¤Q;=0< IEB : F0aMB F

¥FEB =J©�K F aAB =0aAB >¦ L

¥I�H4=

ª u�z � { ~A«�A¬E© ¬�E®�® �!�* (�10i h %�f' 1 i (�`

n i 1;iAr 2¯�(�* °±®�² ³

´ { wEµ�|;z u0|�w z } { w�x¶ w�� wE} w4�E} } z { ·��E} w¸ v�v4�;} } z { ·;�E} w

Figur F.4: I CRC-kortet indtastes al information om den nye klasse

264


¹�º�»¼»&½�¾�¿�À ¿�Á�Â�Ã�¿0ÄÆÅ0À Ç È�È&É Ê�Ë�Â Ì ÍÎ�Ï Ð Ñ;Ò ÓAÔ�Ï Õ Ö�Ï Ñ�× Î Ø�Ù Ú4Û Õ Ò Ü�Ð ÛEÒ ÒJÝ�Ï Û�Þ0Ù Û0Ú ß Ö�à Ü�á0Ü â ã Û0Ù Ô ß;Ù Ø ä ÑEã Õ å�Ñ0Ð æ

ç èéê Õ Õ Ù Ï ë;ìAÕ Ñ à�ÑEÕ íEØ;Ô

î ï�ðßAÑEÕ Ñ0Ù�å�Û0ñ�Ò Ñ0ñcò æAÑEÕ Ñ0Ù í óô�Ägõ ¿�Á ð

¹�½�Â ¿ ¾�ö ÷ ½�Á È;ðùø ñAØ�ñAÑ úï�¿ ÈEÅ0Á ö û0÷ ö ½�õ ü Ê;¿ ÷ Å0ý

þ�÷ ÷AÁ ö ÿ��0÷ ¿ È

��

»&¿ ÷ ½�¾�¿�Á

ß0Ù Ø ä Ñ�ã Õ �;ê�� â Ò Õ Ø0Ð Ñ ��AÙ Ï �EÑ0æ�Ð Û�Ô0Ñ !" !# �$�$� �!�% &�'

(*) � � +��, -��Ã�Ç�.g¿�ð� /�â 0

1 2�354 6 6 7 8 9 : 6 ; <�= ; > 8 ? ; = @A�ØEÕ ÑB Ý A�Û�ÚJÑ

1 2�35C*; 6 D 3 = <�= ; > 8 ? ; = @á;Ñ0Ð ÛEÕ Ï Ø ñMÕ ØA�ØEÕ Ñ�E�Ü Ø0ñEÕ Ñ0ñEÕ ÒB Ý A�Û�ÚJÑ

F �� ) � ��G/�H E HI/�J�J�/¹�Á ¿ Ç ÷ ö ½�õ¾ Ç0÷ ¿�ð

ü ÷ Ç;÷�� ÈK�¿�Á LMJ�N O

¹�º�» »&½�¾�¿�À ¿�Á�ÂQP;¾�ö ÷�Ç ÷ ÷ Á ö ÿ��0÷ ¿R*�EÑ;Ù S Ð ÛAÔ0Ñ î ï�ðÃ�Ç�.g¿�ð

T�U V -��, W5�, �

X��/Aâ 0Aâ O

Y�Z�û ¿�ðî õ�ö ÷ ö Ç�À�[ Ç�À ��¿�ð

\ å�] ä Þ�Ð Û0ñEÒ ^ �0ÛEÕ Ï ñ�_ï�½�.cÇ�ö õ�ð`�õ�ö ÷ ð

Ã�½ ÷ ¿�ð

Figur F.5: Information om den nye attribut redigeres i et separat vindue

265


a*b5cdcfe�g�h�i h�jQkQb�l*cnmo�pk q r e5i hns t�u�v

w�x y z {�| } ~�� } y�� { �� x �� n� �� #��#��

�#�� #�Q�� Q�� ¡ ¢�£*¤�¥�¦5§ ¨�©«ª�¬*n® ¡�¯�°�±5£Q¦ £Q��² ³´¦ µ¶¡ ·¸n§ ¨5©¹ª5¬5¹® ¡�¯�°�±5£Q¦ £º��» ¯�® ¼Q¡ £½µ¾£�¿ÁÀ�¦ µ¾¡ ·Â¾§ ¨�©¶ ª�ª�£½ �¼�±�£º¦ ¤�¥�Ã ¿�£��Ä ¯#¥5Ã ¡ £�§ ¼�¿¶¼�Å«¿�¦ £�Ã £�§ ¼�¿«§ ¨5©¶ ª�ª�£Æµ¾£*¿¹©�ª�¦ ±�£QÇ5¡ À�¿�£

È É � {�� Ê�Ë�É } Ì�É {�Í È�y�x �� } � �5� �� Î�É ��Ï�x �� w Ì5Ð �5Ñ�� | ��x Ë w�x y z {�| } Ò�{�� ÓÔ ÕÖ ×

Ø´Ù�Ú ��Û ��

ÜºÛ �� º��Ý*�

Þfß*à��*� à��Q�á â ã

Øn� äå� æ¸ßá ç è é ã

Ü�� QêQ� Ý*àº�á ç è â ã

Ü�Û �� Q��Ý*�

ë�� ì��ºí�î��á ç è â ã

ïI��º� ð�� Ý�à��Áñ òI¥�Ã Åº¡ À*�©�ó5¯#À�® �ô

a�b�c¸cfe�g�h�i h�jQk�õºhöø÷�i ù�q�q�g�ú ù�û�j ù�ü

�� } y�� { ý þ mõQù�ünh5m

ÿ

� �Ê��} {�x5��{�� y�x��{ Í | � �� Ë�É ��Ï�x ��

��

� �� ! �"$#�% % %

Figur F.6: Et nyt klassediagram kan oprettes ved tryk på en knap og kan efter ønske baseres på en eksisterende

PVM

266


&$')(*(�+�,)-). -)/01&$. 2�3�3�465 2�78/ 219;:�<8=>0 3�? +8. -A@ B�C�DE�F G H>I J K�F L M1F H�N E O�P Q�R L I S1G R�I I�T8F R�U�P R�Q V M1W S8X�S�Y Z R�P K V�P O [ H�Z L

V�P O [ H�Z L \>]�^ Y I L O�G H _�O�L `�F a UbI H�G H�Z L H�K c>d>e d�c�f�f�c�d)g h�i

j kl)H�G m

n op

q�r s t u v�w x

y�u v�w x t�z {�w

|�} ~�x � ~�x w

q1� �6w �6}�� w � x � �>� y�z � � � x � w { ~ x� � � � � � � � �

� s � x�} x u

� s � x�} x u

�� x � x � v�~

y�� w x � v ~

Figur F.7: Det nye klassediagram, hvor klasserne har samme struktur som i PVM’en

267


�$�)��)�)� �)��8�� ¡�¡�¢¤£ �¥8� 1¦¨§�©8ª>� ¡�« �8� �A¬ �®�¯°>± ² ³�´ µ ¶�± · ¸1± ³�¹ ° º�» ¼�½ · ´ ¾)² ½�´ ´À¿8± ½�Á�» ½�¼ Â ¸8Ã ¾8Ä>¾�Å Æ ½�» ¶ Â�» º Ç ³�Æ ·

Â�» º Ç ³�Æ · È�É�Ê Å ´ · º�² ³ Ë)º�· Ì�± Í Áb´ ³�² ³�Æ · ³�¶ Î�Ï�Ð Ï�Î�Ñ�Ñ�Î�Ï�Ò Ó�Ï

Ô ÕÖ�³�² ×

Ø ÙÚ

Û�Ü Ý Þ ß à�á â

ã�ß à>á â Þ�ä å�á

æ�ç è�â�é è�â á

Û1é ê6á ë6çì�í á î â ï ð>é ã�ä é í ñ â ò á å è âó ô õ ö ÷ ø ù ú õ

û Ý î â�ç â ß

ü Ý î â�ç â ß

ý�é â þ â ÿ à�è

ã�ð þ á â ÿ à è

É�Ê Å ´ · º�² ³

¾1² ½�´ ´6² ± ´ · ± Í�Á ��

��

� � � �� ! ��

�� #" ��

$� �� #�Ó� �� #�

% � � & ��' ��

�(� & � �#' ��

�(" � � )��*#� ��+ )�� ' � ��

Figur F.8: I klassediagrammet kan vælges at få CRC-kortene listet og sorteret

268


,�-/.0.21 3�4�5 4�687�,�5 9�:�:�;=< 9�>/6 9 ?A@�B�C#7 : D 1�5 4�E F�G HIJ K L M NO�J P Q/J L�R I S�T UWV�P M X K VM MZY�J V[�T V�U \ Q/] X ^�X�_ ` V�T O \#T S a L` P

\#T S a L` P bc�d _ M P S�K L e S�P f�J g�[hM L�K L` P LO ij#k j�i#l�li�j m n�l

o p

q�L�K r

s tu

v�w x y z {#| }

~#z {#| } y�� |

�� } � ��}�|

v�� 8| �=��#� | � }�� #� ~�� }�� | � ��}� � � � � � � � �

� x � }�� } z

� x � } � } z

�� } � } � { �

~#� � | } � { �

c�d _ M P S�K L

X K VM MWK J M P J g [ �� ¡ ¢�£¤�¥ £ ¦

§�¨ © � ��ª ¢§ � «�ª ¬£

® ¥ ª ¯ ¢�°�±��² £ ¤�¢�� ¤¢�ª

�� ª ¢ #³ ��ª

�� ª ¢�³�� ´µ�© ¯�¢�£¢��

¶ � ¢ · ¢#¸ ��¤

�(± · ª ¢�¸ �¤

�(³ � ¥ ¹¢�´�ª �¤�¢º ¹¢�� ¸ ª ��¤¢

~�z {�| }�� {�

Figur F.9: Den nye klynge oprettes med et mappe-ikon i listen til venstre og med UML-symbolet i klassedia-

grammet

269


»(¼ ½¾½2¿�À Á Â Á Ã8Ä/»�Â Å�ÆÆ2ÇÉÈ Å�Ê/Ã Å�ËAÌ�Í/Î#Ä Æ�Ï ¿/Â ÁÐ Ñ�Ò�ÓÔ#Õ Ö ×Ø Ù Ú�Õ Û Ü�Õ ×�Ý Ô Þ�ß àZá Û Ø â Ö á�Ø ØWã/Õ áä�ß á�à å Ü/æ â/ç#â�è é á�ß Ú å�ß Þ ê ×é Û

å�ß Þ ê ×é Û ëì�í è Ø Û Þ�Ö × å áé�î áä×�è/ì�í è Ø Û Þ�Ö × ï�ðñ ð�ï�òò�ï�ð�ó ô�ô

õ ö

÷�×�Ö ø

ù úû

ü�ý þ ÿ � ��

ü��

� � � � � � � �

â�Ö áØ Ø=Ö Õ Ø Û Õ !ä "�#�$ %'&�(*)�+�,�-/. ,�0

ì�í è Ø Û Þ�Ö ×ì�ß à2Ö 12!

3 Õ Ö 4 ×/5�6�ß

7�Û Þ�Ö ×�î�ß Þ�ø

7�î�ß Õ 8�×�øÖ áÚ×9:8�×�ß ; Ö á#Ú×

�*� �� *� � ��ì�í è Ø Û Þ�Ö ×

7�6 ê Ö ×*; Þ#Ú<=!�Ú�×�ß Ú�×�Ö

7�Û Þ�Ö ×�Ø î áÖ

>è 4�×�!×�Û

ã�ß × ê ×*; Þ�Ú?è 4�×�!×�Û

Figur F.10: Klassediagrammet er opdateret efter flytning af de to klasser (med underklasser)

270


@BA=CDCFE�G=H=I H=JLK�@BI M'N�NPO�Q M'R:J M�S2T�U�V E:I H�W'J E=X2Y W'Z=K M'[\�] ^ _�` a�b�] c d�] _�e \ f�g 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

n/g f s _�r c t�u'v q ` c f/^ _ n�i�r*w i�m�_PqBx*c f�^ _�w�g f/y z�{�| {Pz/}�}/zl{=~ �/�

� �

�=_/^ y

� ��

u'v q ` c f�^ _

j=^ i�` `�^ ] ` c ] �*m �:�� '��*��*�/� ��

u'v q ` c f�^ _

u�g h�^ �2�

x�� s ^ _*� f/b�=��b/_/g b/_/^

x*c f'^ _�`*w i�^

��q ��_��*_*c

k:g _ s _*� f/b

��] ^ ��_'�*�/g

x/w�g ] �*_/y�^ i�b�_

�:��_/g � ^ i�b�_

x*c f�^ _/w�g f/y

�' ¡ ¢ £ ¤�¥ ¦*§ �� ¡ ¢ £ ¤�¥ ¦¨*£ ¤�¥ ¦ ¢*© ª*¥ «'¬ �¦*® �¦*¥

¯ ¡ ° ¦*¬ ¦ £ ±'® ¦ ² ¦ ³ ¤�

¨/´ ² ¥ ¦ ³ ¤*µ ¡ ° ¦*¬ ¦ £

¶�q ��_��*_*c

Figur F.11: En klynge har et separat klassediagram, hvor den detaljeres. Elementer fra andre klynger vises med

grå farve

271


·B¸=¹º¹F»'¼=½=¾ ½=¿LÀ:·ÂÁÂ·BÀ Ã�Ä�¿ ¼ÂÅ/Æ�Ç »=¾ ½'È'É�Ä=¾�Ê É'Ë=À Ä=À Ì'ÍÎ�Ï Ð Ñ�Ò Ó�Ô'Ï Õ Ö�Ï Ñ*× Î Ø�Ù ÚlÛ Õ Ò Ü=Ð Û*Ò ÒÞÝ:Ï Û�ß/Ù Û'Ú à Ö:á Ü:â�Ü'ã ä Û/Ù Ô à/Ù Ø å Ñ*ä Õ æ=Ñ/Ð ç

è éê

ë�Õ Õ Ù Ï ì�í*Õ Ñ áLÑ*Õ î�Ø�Ô

ï*ð�Å

à�Ñ�Õ Ñ/Ù:æ�Û/ñ�Ò Ñ/ñ�ò ç*Ñ*Õ Ñ/Ù î óô�õ2ö'½=¿ Å

·:»=À ½�¼:÷ Ç »:¿ È/Åùø ñ�Ø�ñ�Ñ'ú

à/Ù Ø å Ñ�ä Õ û�ë�ü ã Ò Õ Ø/Ð Ñ ý*Õ Ø/Ð Ñ�Ò*þ Û'Ð ÿ�� Pÿ��/ÿ��

�� LÄ��2½�Åþ ��ã Û�ã �

�:Ç Ç ¿ ÷ ��/Ç Ç ½�È

��! " " # $ %�& " ' (�) ' * $ + ' ) ,-�Ø*Õ Ñ. Ý -�Û/ÚÞÑ

¹l½'Ç�/'»'¼=È

��!0�' " 1 � ) (�) ' * $ + ' ) ,â'Ñ/Ð Û*Õ Ï Ø/ñlÕ Ø-�Ø*Õ Ñ32LÜ'Ø/ñ*Õ Ñ/ñ*Õ Ò. Ý -�Û/ÚÞÑ

ðÂ½'È�Ã�¿ ÷ 4/Ç�÷ »=ö Æ:É�½'Ç Ã�/5�6 798 :�;�< =98 8 :9>?:�@BA�C�D E9@ 69F�C�=�GIH�J9E�K :69< @ L�C�;�D F >�M�@ N�O�@D 7�@ ;�< :98 8 F P�:QD 7�@BR�S�:�@�GT7�C�:98 =D�UWV�X ;�6 798 :TY Z�[ :�@ :9>�\]BA�>�P�:�>37�P�^?L�@ :9>�_ N�59:IG?:9@ :Q7Ga`@ F 6 bTcd=>�;�:9>�;G�EJ98 :�@�H�e f!fgf?N D @ F 6 b�R�=9>�;�:9>�N C�< Nh�ij;3GQ:�@ :Q7�GkH�@ 7�C9A�<�6 GT7�C�:8 8 :�@ F >�PTH�eflfWf?N H@ 7�C9A�< 6 GI7�C�:98 8 :�@ N C�< N

c!:98 :T;�:@ F :>3=9D�UWV X ;�6 78 :QJ8 :�SQGT7�C�:8 8 :�@ :�6�;�7�G:<�;�=�GT:9>�;�H@ 7�K :9< 6�S�:�C�m n!h�N�5�:T@ =�H�H�7@ 6 :9>IR�:�@BY n!^gX;�L�S�:@ :9>N H�C�D _ N

ë'ü ã Ò Õ Ø�Ð Ñ

Ü�Ð Û�Ò Ò�Ð Ï Ò Õ Ï ñ�ß � 9o ��p��9q�r�s q�t

ë'ü ã Ò Õ Ø�Ð Ñë�Ù ÚFÐ u2ñ

ý�v å Ð Ñ�w Ø�Ôx=ñ*Ô/Ñ/Ù Ô/Ñ/Ð

��ã ì*Ñ�ñ�Ñ*Õ

Ý�Ù Ñ å Ñ�w Ø/Ô

y=Ï Ð ì�Ñ/î�v/Ù

ý/þ*Ù Ï z*Ñ'ç�Ð Û�Ô�Ñ{Bz*Ñ/Ù w Ð Û�Ô�Ñ

ý*Õ Ø�Ð Ñ/þ*Ù Ø/ç

|�ã ì*Ñ�ñ�Ñ*Õ

ý*Õ Ø�Ð Ñ*Ò�þ Û�Ð

}~ 9o ��s q�t��2 ��·B¿ ½�Ä�Ç*÷ »�ö�¼=Ä'Ç ½

Æ�Ç Ä�Ç��'È�B½�¿ ��9� �

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

tionsværktøjet)

272

kravspeci˝kation for dokumentationsværktłj til...

Documents