Fremgangsmåde for opbygning af konfigureringssystemer i ...

More documents

Recommendations

Info

25 Klassenavn: Dato: Forfatter/version: Klassens opgave (responsibilities): Aggregering Generalisering Overdele: Overklasser: Underdele: Underklasser: Skitse: Attributter: Klassen samarbejder med : Systemmetoder: Produktmetoder: Figur 12: Klassebeskrivelseskort (CRC-kort). CRC-kortene udfyldes løbende under den objektorienterede analyse. Formålet med CRC-kortene er at dokumentere detaljeret viden om attributter og metoder, under de enkelte objektklasser, samt at beskrive klassernes indbyrdes relationer. CRC-kortene tjener som dokumentation overfor både domæneeksperter og systemudviklere og bliver således sammen med produktvariantmasteren og klassediagrammet et vigtigt middel til at kommunikere og dokumentere viden i projektgruppen. I [Hvam et al., 2004] er der givet en uddybende beskrivelse af de enkelte felter på CRC-kortet og CRC-kortenes anvendelse. Udover selve den objektorienterede klassemodel foretages en definition af systemets brugergrænseflade, kravspecifikation, dynamik, samt integration til øvrige systemer. Den objektorienterede modelleringsteknik er i princippet uafhængig af hvilket software det vælges at implementere systemet i, og den opbyggede model kan således anvendes som dokumentation uanset valg af implementeringsværktøj. I praksis vil det dog ofte være nødvendigt at foretage en række justeringer i modellen inden modellen kan implementeres i et konkret konfigureringssoftware. Udgangspunktet for valg af konfigureringssoftware er systemets kravspecifikation, der udover den opbyggede model omfatter en række krav til systemet og leverandøren som eksempelvis mulighed for integration til andre systemer, svartid, driftssikkerhed og mulighed for support fra leverandøren. De standardsystemer, der idag findes til produktkonfigurering er ikke alle fuldt objektorienterede. Det vil derfor ofte være nødvendigt at tilpasse den objektorienterede model til de muligheder, der findes for at strukturere modeller i det konkrete konfigureringssoftware. I den forbindelse fastlægges hvorledes man ønsker at dokumentere eventuelle forskelle mellem strukturen i den opbyggede produktmodel og strukturen i konfigureringssystemet Fremgangsmåde for opbygning af konfigureringssystemer i byggebranchen, -erfaringsopsamling.
Den tilrettede objektorienterede model kaldes en objektorienteret design model (OOD). Desuden foretages detailspecifikation af brugergrænseflade, dynamik og integration til øvrige systemer i forhold til det valgte konfigureringssoftware. 2.2.4 Programmering Den objektorienterede model med klassediagram, klasse-beskrivelseskort og beskrivelsen af systemets dynamik og brugergrænseflade mv. danner grundlag for programmering af konfigureringssystemet. Ofte vil man vælge at implementere modellerne i et standard konfigureringssystem. En stor del af de standard konfigureringssystemer, der er tilgængelige på markedet idag er videnbaserede systemer, dvs. de indeholder en videnbase og en inferensmaskine. Programmøren bør have et indgående kendskab til det standardsystem, der anvendes. Som nævnt vil det ofte være muligt at uddanne modelbygger eller domæneeksperter til at varetage dele af programmeringsarbejdet. Erfaringer viser dog at det kan være svært for en ikke programmør effektivt at programmere komplekse regler og tilhørende applikationer som eksempelvis kundemodul eller integration til øvrige systemer. Hvis konfigureringssystemet ikke er objektorienteret kan strukturen i den opbyggede produktmodel ikke uden videre implementeres i konfigureringssystemet. Et konfigureringssystem, der ikke er objektorienteret understøtter ikke eksempelvis ikke indkapsling af objektklasser, relationer mellem objektklasser og nedarving. I stedet lægges attributter og metoder i en ”flad” struktur af fil-mapper (folders). På baggrund af den opbyggede klassemodel defineres strukturen af de folders, der indeholder attributter (defineret som datatyper eksempelvis ”Single”, ”OneOf”, ”At Most One” o.s.v.) og deres variationsmuligheder. På samme måde oprettes en tilsvarende folder-struktur med metoder, der eksempelvis kan implementeres i form af ressourcer og kalkulationer. Der findes der idag en række standard konfigureringssystemer, der understøtter anvendelse af tabeller til at repræsentere regler i systemet. Ved at anvende tabeller til at beskrive regler lettes implementeringen betydeligt. Desuden er det lettere at kommunikere mellem modelbygger, domæneeksperter og programmører ved anvendelse af tabeller, bl.a. fordi en del af viden om virksomhedens produktsortiment allerede er repræsenteret i form af tabeller. Hvis konfigureringssystemet er objektorienteret kan den opbyggede klassemodel implementeres direkte i systemet. Et objektorienteret ekspertsystem bygger på principperne i objektorienteret modellering og kan derved håndtere indkapsling af objektklasser, nedarving og relationer mellem objektklasser. Ved programmering af et objektorienteret konfigureringssystem oprettes klassestrukturen først, hvorefter attributter og metoder programmeres samlet for hver objektklasse. Anvendelse af et objektorienteret konfigureringssystem gør det lettere at strukturere videnbasen, hvilket gør det betydeligt lettere at vedligeholde og videreudvikle konfigureringssystemet. Fremgangsmåde for opbygning af konfigureringssystemer i byggebranchen, -erfaringsopsamling. 26
Page 1 and 2: Fremgangsmåde for opbygning af kon
Page 3 and 4: Indholdsfortegnelse 1 Introduktion
Page 5 and 6: 1 Introduktion til problemstillinge
Page 7 and 8: 1.2.1 Industrielle specifikationer
Page 9 and 10: Udviklingssystem / Forberedende sys
Page 11 and 12: • Erfaringer er løbende opnået,
Page 13 and 14: Vedligeholdelse og videreudvikling
Page 15 and 16: I nedenstående Figur 7 er vist den
Page 17 and 18: Den første fase i fremgangsmåden
Page 19 and 20: Efter at version 3 af systemet er i
Page 21 and 22: drifts-/ vedligeholdelsesfasen er u
Page 23 and 24: På tilsvarende måde kan de livsfa
Page 25: Den optegnede produktvariantmaster
Page 29 and 30: forsvinder. Til gengæld skal f.eks
Page 31 and 32: 3 Erfaringer Dette kapitel opsamler
Page 33 and 34: Development of materials, parts, mo
Page 35 and 36: af de forskellige bilmodeller. Plat
Page 37 and 38: 3.1.3 Stor omsætning af tilbud ell
Page 39 and 40: karakteriserer softwaresystemerne o
Page 41 and 42: Figur 19: Udsnit af produktionstegn
Page 43 and 44: 3.2 Erfaring med selve fremgangsmå
Page 45 and 46: • Større grad af industrialiseri
Page 47 and 48: Indsamling og dokumentation af vide
Page 49 and 50: Figur 20: Udsnit af en produktvaria
Page 51 and 52: Modsat kan det tænkes at der er to
Page 53 and 54: Figur 22: CAD-modeller struktureret
Page 55 and 56: medført at der i forskellige proje
Page 57 and 58: • Betonhal i Inventor Product Con
Page 59 and 60: 4 Konklusion og perspektivering PKB
Page 61: 5 Litteraturliste [bips nyt, 2003]

Fremgangsmåde for opbygning af konfigureringssystemer i ...

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?