Core Components Technical Specification

Core Component Technical Specification (CCTS) er en måde at udtrykke, hvad data betyder og hvordan de hænger sammen. CCTS er en måde at bygge modeller over de datasæt og dokumenter som anvendes i forretningsprocesser, med det formål at gøre det muligt at effektivisere anvendelsen af data, fx ved at gøre det klart, hvilke oplysninger, der anvendes flere steder.

Hvor kommer det fra?

CCTS er en international standard som vedligeholdes af FNs datastandardiseringsorganisation, UN/CEFACT. Organisationen består af flere hundrede forretningseksperter og teknikere fra alle verdenshjørner.

De store træk?

Grundlæggende er der tre forskellige elementer i CCTS (som i stort set alle andre objekt-modellerings-tilgange):

Simple elementer
Sammensatte elementer
Relationer mellem objekter

For eksempel kan egenskaben stelnummer være et simpelt element som indgår i det sammensatte element cykel og det sammensatte element kan have relationen ejerskab til en person som kan have et navn osv.

Dette er rygraden i datamodellering og dermed også i CCTS.

Det obligatoriske

For alle CCTS-objekter gælder det, at de skal have

Et udtryk der angiver, hvad objektet hedder
En definition som forklarer hvad objektet er
Et unikt navn som gør det muligt at identificere et givet objekt i forhold til alle andre objekter. Dette navn kaldes i CCTS for Dictionary Entry Name (DEN).

Sammensatte elementer har desuden information om, hvilke simple eller sammensatte elementer, de består af, og hvor mange gange hvert underelement kan optræde (skal der være mindst en eller er det valgfrit, kan der højst være et bestemt antal eller vilkårligt mange?).

Relationer har naturligvis også information om, hvilke objekter, de forbinder.

Simple elementer har desuden en datatype som angiver udfaldsrum, altså hvilke værdier, der er gyldige for elementet. Et element kan for eksempel skulle være et heltal, et positivt heltal, et tal mellem 5 og 10 og så videre. Dette svarer nogenlunde til strukturen i XML, hvor der erklæres typer som angiver udfaldsrum og elementer som angiver tag-navne i XML-filerne.

Men der er jo mere…

Det ovenstående er kun en meget simpel metode til at lave enkeltstående datamodeller, men CCTS har til formål at støtte både udvikling, vedligeholdelse og sammenkobling af modeller, så der er mange andre muligheder i specifikationen. Kernekomponenter kontra forretningsenheder Først og fremmest skelner CCTS imellem på den ene side ”Core Components” (CCer) og på den anden side ”Business Information Entities” (BIEer) ved, at CCer er generaliserede objekter såsom ”navn”, hvorimod BIEer er specialiseret til en bestemt sammenhæng – fx en ansøgers personnavn. I praksis er der mange, der kun udvikler enten CCer eller BIEer, da det nemt kan komme til at virke som unødigt dobbeltarbejde først at erklæret noget som CC og der ud fra danne en BIE.

Versionering

Det er også muligt at versionere CCTS-objekter. Man kan versionere både i traditionel forstand, hvor en ny version af et objekt kan erstatte en gammel og ved at udforme det samme objekt på flere sprog – i Danmark vil det nok oftest være relevant at lave definitioner mv. på dansk og engelsk.

Kontekst

Et andet potentielt stærkt aspekt af CCTS er angivelser af kontekst. Det vil sige, at det er muligt at angive, hvor et givet objekt er relevant – en ”prøve” kan jo være to forskellige ting henholdsvis på et hospital og en skole. Denne side af CCTS er endnu ikke rigtigt moden, men der arbejdes på at få specifikationerne helt på plads.

Meddelsessammensætning

Et udestående i videreudviklingen af CCTS er en fælles standard for, hvordan man danner ensartede dokumenter ud fra CCTS-elementer. Dette emne diskuteres aktuelt i UN/CEFACT som forventes at fremlægge et forslag til løsning en gang i 2009.

Navngivning

I CCTS er der egentlig ret stramme regler for navngivning af objekter, altså formkrav til DENer. Alle navne skal have tre dele som angiver henholdsvis, hvilket objekt, der er tale om (som Person), hvilken egenskab, der beskrives (for eksempel Navn) samt hvordan det specificerede fremtræder (såsom Tekst). Desuden har BIEer såkaldte kvalifikatorer, som angiver deres anvendelsessammenhæng (eksempelvis Ansøger). Disse regler kan virke meget rigide, og de kan give nogle meget særprægede resultater, men overordnet set gør reglerne det lettere at holde styr på navngivningen og at lave værktøjer som understøtter brugen af CCTS.

Hvordan gør man så i praksis?

Overordnet dannes CCTS-objekter efter en afklaringsproces, hvor man først gør sig klart, hvad man laver og hvordan (forretningsprocesser). Derefter identificeres de data, der skal bruges i hvert trin af processerne samt hvor de data kan komme fra (skal de tastes ind som led i processen, kan de hentes udefra eller er de allerede tilgængelige et sted i processen). På baggrund af det specificeres de enkelte datasæt og dataelementer som skal hentes eller skabes – og det er faktisk først her, at CCTS for alvor kommer i spil.

Der findes intet autoritativt format for notering af CCTS-objekter. De fleste der bruger CCTS lagrer objekterne i regneark (Webside ikke længere tilgængelig), og der er bagerst i denne folder et link til det format, som UN/CEFACT anvender. UN/CEFACT arbejder pt. på at udvikle et XML-format som kan anvendes til registrering og udveksling CCTS-objekter, men det arbejde forventes tidligst afsluttet i slutningen af 2009.

Der er også en del værktøjer som understøtter CCTS, deriblandt FX fra GEFEG og Enterprise Architect fra Sparx Systems.

Eksterne links

UN/CEFACTs hjemmeside, www.unece.org/cefact/

Den formelle specifikation af CCTS er indeholdt på UN/CEFACTs hjemmeside: