Kaj Jørgensen på vildspor i det digitale

Desværre er det Kaj Jørgensen, der er på vildspor på flere områder mht. klassifikationsanvendelse i det digitale byggeri. Og det gør det ikke bedre, at Kaj Jørgensen i både sit første og sit andet indlæg forsøger at opbygge forskellige mytologier om manglende dialog og kæmpe spild af tidligere og fremtidige ressourcer.

Kaj Jørgensens påstand om, at der ikke er nogen der vil gå i dialog med klassifikationssystemets kritikere og trækker andre rundt ved næsen holder fx ikke. Kaj Jørgensen har deltaget i masser af diskussioner, workshops og høringer gennem de sidste 5 år. Han har fået masser af kommentarer til sine egne teorier og masser af svar på sine spørgsmål og synspunkter. At der er mange, der ikke har været enige med ham, er ikke et udtryk for manglende dialog men manglende enighed med Kaj Jørgensen. Et faktum der øjensynligt er svært at erkende.

Kaj Jørgensen synes også at glemme, at mange af byggeriets virksomheder og deres medarbejdere har været med til at opbygge DBK-systemet, så det giver værdi i virksomhedernes daglige arbejde, og at disse er mindre interesseret i Kaj Jørgensens løbende teoretiseren og diskussioner med udgangspunkt i hans egen universitetsgerning. Det kan være, at det opfattes som arrogance, men det kunne også forstås som, at der er grænser for hvor megen tid nogen gider spilde.

Det gør det heller ikke bedre, at Kaj Jørgensen får det til at se ud som om, at man over de næste tre år vil bruge mellem 26 og 50 mio. kr. alene på at videreudvikle den del af DBK (Dansk Bygge Klassifikation), der har med referencesystemet for bygningsdele at gøre. Det er mig bekendt slet ikke korrekt og fremmer i hvert fald ikke tiltroen til, at Kaj Jørgensen overhovedet ved, hvad han taler om.

Den fejlagtige opfattelse af, at IT i sig selv løser alle problemer
Et af de vigtigste karaktertræk ved Kaj Jørgensens indlæg i debatten og ved hans skrifter vedr. emnet er hans tyrkertro på, at IT-systemernes virkemåde og modelleringsprocessen i sig selv vil skabe al den informationsværdi, byggeriets parter har brug for. Han har gang på gang vist, at han ikke er i stand til at skelne, mellem det dataobjekter er og kan, og den information om byggeriets fysiske objekter som brugerne skal anvende på en for dem meningsfuld måde. Et aspekt Kaj Jørgensen stort set aldrig forholder sig til. Byggeriets praksiserfaringer viser et stort behov for at kunne håndtere sidstnævnte, og ikke bare i Danmark men også på verdensplan, fx i buildingSMART-miljøet, arbejder man hårdt på at finde ud af, hvordan klassifikation og informationsstruktur skal sikre, at der via IT-systemerne kan skabes en relevant og værdiskabende brugergrænseflade af informationer for brugerne. Da Kaj Jørgensen interesserer sig for dette område, burde han have opdaget, at disse erkendelser breder sig i disse miljøer, og at Danmark har mulighed for at spille en fremadrettet rolle på dette område i stedet for at ty til gammeldags tænkt og anvendt byggeklassifikation.

Kaj Jørgensen har desværre endnu ikke forstået, at uden at håndtering af den virkelige byggeverdens begreber og informationsstruktur kommer på plads, bliver den nuværende IT-udvikling på området ved med at foregå ad hoc og på IT-systemernes præmisser – og ikke på brugernes.
Det betyder ikke, at Kaj Jørgensen ikke har ret i nogle af sine synspunkter og statements generelt om klassifikation og IT, men efter manges opfattelse bliver disse ikke sat ind i den rette sammenhæng, fx til gavn for byggeriets praksis.

Eksempler på misforståelser, fejlfortolkninger og manglende indsigt i byggeriets virkelighed
Det er ikke nemt på så relativ lille plads, at uddybe og imødegå de problemstillinger, som Kaj Jørgensen rejser i flæng. Men vi vil blot give nogle få eksempler på, at Kaj Jørgensen enten ikke har forstået de problemstillinger, der er relevante for byggeriet, eller alene forholder sig teoretisk til emnet og fokuserer på IT-systemers virkemåde og muligheder – ikke på byggeriets samlede praksisbehov:

Et citat: ”Referencesystemet handler altså om komposition, hvilket er det modsatte af klassifikation.” Dette postulat, fremfører Kaj Jørgensen hyppigt. At komposition er det modsatte af klassifikation, har Kaj Jørgensen hyppigt hævdet, men aldrig underbygget eller henvist til via fx videnskabelig dokumentation herfor. Referencesystemet er en måde at ordne de dele af en bygning, der er klassificeret som værende bygningsdele, i en del-helheds-relation, og hver af de herved relaterede objektklasser kan klassificeres detaljeret med de bygningsdelstyper, der måtte findes for disse, fx vægtyper, ventiltyper, vinduestyper, bjælketyper, søjletyper etc. Dette mener Kaj Jørgensen klares med et dataobjekt med vedhæftede egenskaber. Hvordan dette i praksis kan ske, har vi ventet i flere år på at få dokumenteret, på trods af hyppige opfordringer herom. Og at gentage det hyppigt, uden at dokumentere at det kan lade sig gøre i praksis, gør det ikke mere rigtigt.

Et andet citat: ”Som følge af at mange bygningsdele kan optræde flere steder i bygninger, vil der tillige forekomme et stort antal gentagelser af bygningsdels-klasser, der bliver kodet forskelligt. Alene af disse grunde må tabellen anses for at være uanvendelig i praksis.” Man behøver bare at spørge hvorfor, men man får aldrig noget svar herpå. Det er jo sådan i virkelighedens byggeri, at bygningsdele optræder mange steder i bygningen, og at byggeriets aktører har stort behov for entydigt at få identificeret hvilke forekomster af bygningsdele og hvilke bygningsdeltyper, der er og hvor. Dette gælder fx både i forhold til mængdeudtagning og -summering, logistisk planlægning for udførelsen og i forhold til en fremtidig vedligeholdelse af bygningen. Det er denne praksis, Kaj Jørgensen aldrig forholder sig til. Kaj Jørgensens svar herpå er, at disse relationer allerede findes i bygningsmodellen. Men Kaj Jørgensen synes at glemme, at i forhold til byggeriets virkelighed indeholder bygningsmodellen kun en delmængde af de objekter og informationer, der er nødvendige for at kunne projektere, udføre og drifte et byggeri, og at en lang række IT-systemer ikke en gang er i stand til at etablere disse relationer. Kaj Jørgensens byggeverden rækker kun så langt, som værktøjet for bygningsmodellen er i stand til at håndtere den. Skal vi andre nøjes med dette? For byggeriets praktiske aktører må svaret blive nej.

Et sidste citat: ”En bygningsdels primære funktion er den, der overvejende begrunder bygningsdelens eksistens… Denne definition har været meget central for udvikling af de udenlandske klassifikationssystemer og det engelske begreb 'element' samt det svenske begreb 'byggdel' er defineret ud fra dette grundlag. Der er altså væsentlig forskel på disse begreber og begrebet ’bygningsdel’, men i DBK bliver begreberne ligestillet, hvilket i øvrigt er i modstrid med den internationale standard ISO 12006-2. Det er en stor mangel, at der ikke klart er taget stilling til disse grundlæggende definitioner!” Udover at der ikke er logisk sammenhæng i Kaj Jørgensens redegørelse for dette, indeholder udsagnet igen en række postulater. DBK’s bygningsdelsbegreb tager netop udgangspunkt i ISO 12006-2’s definition i Resultatdomænet af en bygningsdel havende en karakteristisk funktion (til adskillelse fra andre med en anden funktion) svarende til definition og anvendelse i det amerikanske OmniClass, det engelske UniClass og det svenske BSAB. I referencestrukturen af bygningsdelforekomster sorterer vi imidlertid ikke efter, hvad der kunne være de overordnende kategorier eller overskrifter for disse funktioner, fordi det ikke giver speciel værdi for brugerne, men i de relaterede bygningsdelstypetabeller klassificeres der efter de karakteristika, som Kaj Jørgensen i øvrigt så udmærket beskriver i sin redegørelse for overklasser og underklasser. Igen har Kaj Jørgensen enten ikke læst DBK-vejledningerne tilstrækkelig grundigt omkring anvendelsen af begrebet bygningsdel og forholdet til ISO-standarden, eller også har han ikke forstået det. Det kan i øvrigt som et kuriosum bemærkes, at de forskellige udenlandske klassifikationssystemer ikke er enige om klassifikationskriterierne for over- og underklasserne, selvom de bygger på samme standard.

Hellere dialog og velargumenteret debat end ensidige beskyldninger og postulater
Således er en lang række af Kaj Jørgensens påstande om DBK’s manglende funktionalitet og forældede udgangspunkt rene postulater uden underbygning – hverken i form af videnskabeligt velargumenterede belæg eller baseret på baggrund af konkrete afprøvninger eller byggeriets praksisbehov. Dette har Kaj Jørgensen skyldt os at tage udgangspunkt i i debatten de seneste 2-3 år, hvis han gerne vil tages seriøst.

Det er muligt, at Kaj Jørgensen har viet sine kommende års universitetsgerning til dette område, men hvis han virkelig er interesseret i dette emne og gerne vil tages alvorligt, kunne han måske begynde at arbejde konstruktivt med i processen og gå i reel dialog omkring klassifikation i relation til specifikke løsningsbehov frem for at spænde ben for byggeriet med en spredning af ukorrekte og generaliserende postulater og uvidenskabeligt spin om et emne, der er af kæmpe betydning for hele byggeriets kommende informationsudveksling og videndeling. Det ville gøre byggeriets digitaliseringsproces og debatten herom en stor tjeneste.

Den største ulykke for byggeriet ville være, hvis den videre udvikling på disse områder blev lagt i hænderne på folk, der alene har en teoretisk og IT-baseret tilgang til disse emner. Udgangspunktet må tages i de behov og de problemstillinger, som byggeriets virksomheder har og står over for, parret med den rette teoretiske indsigt.

Skærm-skrabning

At have et let overblik over typer af byggeelementer, forudsætter et godt objekthierarki. For så vidt, kræver dette altid en omhyggelig altomfattende analyse, og dette arbejde er ren teori.

Praktisk anvendelse handler altid også om konkrete byggevarer, og det forudsætter at den model, som man anvender, har nogle funktioner der evner at fiske i mange vidt forskellige vildfremmede databaser: Produktkataloger og byggesteders byggenormer og fx personaledatabaser.

For eksempel, mens man tegner: Hvis man i en 3D-model af en bygning, i en rumlighed, ønsker at udskifte træarten i et trægulv. I så fald behøver man, at softwaren automatisk fremfinder en liste over alternativer, med manuel sorteringsmulighed fx baseret på pris eller vægt eller holdbarhed eller lyddæmpningsgrad eller brandklasse eller skønhed i form af fotografier, eller sorteret efter forud aftalte indkøbsrabatter med diverse leverandører, eller sorteret efter antallet af ledige fageksperter eller hvilke nationalsprog som disse evner at tale og læse og skrive. Hvis man dernæst udvælger en træart, skal softwaren så vidt muligt evne (med et snuptag) at indsætte alle nødvendige data i 3D-modellen, således at softwaren kan gennemføre en konsekvensberegning, fx om en etageadskillelse indeholder en tilstrækkelig styrke til at bære den ændring som netop er sket, og om den ændrede rumlighed fortsat opfylder en brandnorm, og den ændrede totale byggepris. I praksis vil sådant kun være muligt, hvis leverandørernes produktkataloger er kompatible med den objektmodel som man anvender i sin software, eller hvis softwaren har en meget intelligent søgefunktion der evner at fiske data, fremvise dem, så man som tegner kan beslutte sig for om man vil stole på disse data, eller om man vil behøve at spørge en troværdig kilde, eller foretage en fysisk afprøvning, før man godkender dataene.

I praksis kan man opleve, at leverandør A tilbyder en mængderabat baseret på én opskrift, mens leverandør B tilbyder en anden art af mængderabat. Dette bør den software, som man tegner en bygning med, hjælpe med at overskue, efterhånden som man tegner. Desuden: Hvis man overvejer at udskifte alle vinduer med en anden mulighed, da bør softwaren evne at udregne følgevirkningerne, fx ændrede krav til kraner eller stilladser eller tidsforbrug under montering, eller ændrede krav til byggearbejderes evner, eller ændrede transportforsikringspriser, eller ændret risiko for at der vil ske tyveri på byggepladsen, og så videre. Sådanne arter af data er ofte subjektive, og nogle forældes hurtigt, og nogle er måske ligefrem ulovlige at opbevare i databaser, alligevel er de en nødvendig del af en beregning, skal altså kunne indtastes.

En ideel software skal som minimum evne at udregne alt hvad man behøver at beregne for at kunne afgive et bindende tilbud. Dette betyder, at softwaren skal evne at beregne mængden af nødvendige arbejdstimer og deres fordeling på arter af mandskab. I praksis skal beregningsresultatet altid sammenlignes med de begrænsede konkrete ressourcer som man vil kunne råde over i byggeperioden, begrænsninger der altid vil dreje sig om visse arter af mandskab og visse arter af byggevarer. I praksis kan man fx i April opnå en fortjeneste på et byggeprojekt, mens det samme byggeprojekt vil give tab i September, fx fordi mængden af ledige byggearbejdere med forstand på stålarmering vil forandre sig voldsomt i løbet af året, en faktor der altid afhænger af hvilke andre byggeprojekter der samtidig foregår i et lokalområde. En ideel software bør evne at indregne disse tidsmæssige variationer i varepriser og timepriser og knappe faktorer, således at man kan optimere på diverse parametre, særdeles relevant, fordi byggeprojekters igangsættelse (kontraktunderskrivelse) ofte bliver udsat, med årsag i, at kunde og leverandør ofte ikke har overblik over hvad udsættelser rent faktisk vil koste én eller begge af parterne.

Hvis en bygningsdesigner har en ideel software, da er det et godt spørgsmål, om leverandører af byggevarer vil ønske at understøtte. Ønsker en hvilken som helst leverandør at kunder kan lave prissammenligninger meget let og effektivt? Aldrig i livet.

Dette betyder, at en ideel software skal evne at indsamle data på fjendtlige måder. Dette kalder man for skærm-skrabning, dvs. specialsoftware der fuldautomatisk evner at fremkalde skærmbilleder med produkdata, aflæse disse data og overføre en kopi deraf til en database, dvs. datatyveri, således at tegnere får en fuld kopi af ugæstfrie leverandørers data til deres rådighed. Hvis man læser i de aftalevilkår som man typisk har med leverandører, vil man kunne læse, at skærmskrabning er forbudt?

Re: Kort foreløbig kommentar til Gunnar

Lad mig i denne omgang kun formulere et kortfattet svar til Gunnar Friborg og give et mere udførligt senere.

Faktum er at den tabel, som er forudsætning for at kunne angive en referencebetegnelse (kode) i de såkaldte produktaspekt er på over 1400 indgange!! Det kan man da vist ikke kalde overskueligt og let anvendeligt. Selv for et dokumentbaseret byggeri fremhæver DiKon afprøvningen da også, at der skal IT støtte til. Som det også er konstateret fra flere sider, er denne tabel ikke komplet, så den vil utvivlsomt vokse sig større. Hvor stor mon den skal være?

Faktum er også, at det en referencebetegnelse til denne tabel tilfører et beskrivelsesobjekt af en bygningsdel er en oplysning om, hvor bygningsdelen sidder i bygningens struktur af bestanddele. Jeg spørger bare, hvor vigtigt det er. Dernæst påviser jeg blot, at hvis man arbejder med bygningsmodeller, så er det en oplysning, man kan få gratis.

Jeg vil som nævnt straks komme tilbage til andre emner.

Re: Re: Kommentarer til Gunnar og Henrik

Gunnar Friborg og Henrik Balslev hævder begge, at jeg har en forkert opfattelse af objektbegrebet og at jeg ikke skelner klart mellem dataobjekter og de fysiske objekter. Lad mig her blot henvise til afsnit 1.1 i den rapport, som jeg var med til at udarbejde for nogle år siden. Den kan hentes fra siden http://www.iprod.aau.dk/bygit/...3B/. Jeg er fuldt ud klar over, at der stadig er et udbredt behov for at støtte de dokumentbaserede processer men Det Digitale Fundament var et projekt under Det Digitale Byggeri, så der er vel ikke noget forkert i at fokusere på "de digitale forhold" og dermed forsøge at række lidt frem i tiden. Der er jo ikke så meget værdi i udelukkende at fokusere og udvikle på noget, som kan forventes at blive forældet om få år. Så hvorfor ikke tilgodese begge hensyn?

En anden beskyldning går på, at jeg ikke skulle have indsigt i det arbejde, der foregår i BuildingSmart, det bl.a. udvikler IFC. Jeg har gennemført flere projekter med anvendelse af IFC og jeg har da deltaget i BuildingSmart arbejdet i længere tid end Gunnar har. Jeg ved ganske udmærket, hvad der arbejdes med og de mange BuildingSmart folk, jeg har kontakt med ser på forholdene på samme måde som jeg. Vurderingen er også her, at DBK's kan sidestilles med egenskabshåndteringen i IFC. Det er som om Gunnar modsiger sig selv, når han ikke vil indrømme det. Som jeg har klart har vist i mit andet indlæg, er en henvisning til en indgang i produktaspekt tabellen fuldstændigt det samme som at håndtere andre egenskaber. Referencen ’-205.02.01’ refererer til tabelindgangen ’vægsystem-vinduespanel-vindue’ på tilsvarende måde som f.eks. et 'produktnummer' henviser til et bestemt produkt fra en bestemt producent eller helt enkelt at man for en egenskab 'pris' kan angive en talværdi. Dermed vises, at standarden for referencebetegnelser mildest talt ikke er særligt avanceret.

Som nævnt er den bagved liggende tabel enorm stor og den bliver måske endnu større. Det må da være oplagt, at byggeriet hellere vil have en tabel, der er langt mindre og give den samme værdi eller mere. Tænk, hvis en tabel på 200 indgange eller måske bare 100 indgange kunne løse opgaven. Det ville da ikke mindst give god støtte til det dokumentbaserede byggeri. Her er det så at andre landes klassifikationssystemer påviser, at det kan gøres meget enklere og netop fordi der er tale om klassifikationssystemer i egentlig forstand. DBK indeholder på en række områder klassifikationstabeller men tabellen for produktaspektet er bare ikke en klassifikationstabel og det har jeg nøje påvist med henvisning til områdets litteratur. Det kan også let dokumenteres ved opslag på nettet. Se f.eks. en kort og overskuelig beskrivelse på http://www.icis.org/siteadmin/...pdf. Hvorfor bliver Gunnar og Henrik ved med at lægge røgslør ud om dette forhold. At jeg desuden har redegjort klart for at klassifikation og komposition er hinandens modsætninger, er komplementære, er en anden sag og for så vidt underordnet. Men uanset hvad så er jeg enig i, at det afgørende må være, hvordan man effektivt kan støtte de centrale aktiviteter i livsforløbet. Et første mål må være, at man kan etablere noget som i det mindste er lige så godt som det eksisterende SfB-system. Det tror jeg alle byggefolk sikkert kan tilslutte sig. Men er det ikke også klart bedre, er der jo ingen grund til at foreslå noget.

ISO standarden 12006-2 er ganske rigtigt en betydningsfuld standard for netop dette område og selv om den på en række punkter er problematisk og trænger til en revision, er det vigtigt at forholde sig til den. Man skal bemærke sig at denne standard dækker bredere, nemlig både byggeri og anlæg. Derfor kan man på visse punkter ikke sammenligne nøjagtigt. I standarden er defineret et begreb 'construction entity part' og det vil for byggeriet alene svare til 'building part'. Kan vi ikke være enige om, at dette begreb er meget nærliggende kan sammenlignes med det gode danske 'bygningsdel'. Men lige præcis dette forhold er overhoved ikke berørt i DBK. I stedet griber man fat i et andet begreb i standarden, nemlig 'element' og problemet er, at de to begreber er vidt forskellige, hvilket fremgår af mange kilder. Det er blot det, jeg vil fremhæve og kan man ikke godt forvente, at der er helt styr på det?

Det er ret beskæmmende, at Gunnar Friborg i sit indlæg kommer med så mange løse udtalelser om mig og mit arbejde mens han skriver så lidt om de egentlige problemstillinger. Ærgerligt, eftersom han jo har stået i spidsen for udviklingen af DBK. Man bør kunne forvente, at han derfor vil kunne holde sagligheden i højsædet.

Re: Re: Re: Kommentarer til Kaj Jørgense

Generelt vil jeg sige, at blogformen på noget, der er så komplekst som det her, måske ikke er den mest velegnede. Både fordi man kortfattet (men utilsigtet) kan komme til at virke personlig (det beklager jeg, men konstaterer samtidig, at det opleves lige sådan den anden vej), men også fordi emnet næsten kræver, at eventuelle deltagere på sidelinjen er rigtig godt inde i det materiale, der ligger til grund for debatten. Jeg vil derfor foreslå, at den videre debat kommer til at foregå inden for rammerne af det arbejde og de retningslinjer, der skal varetages af et kommende Videncenter for øget produktivitet i byggeriet, og som bl.a. også skal tage sig af dette emne. Så dette indlæg/svar bliver mit sidste i denne sammenhæng, også fordi de opfordringer til præciseringer af belæg og begrundelser af påstande og konklusioner, vi er kommet med, for fleres vedkommende alligevel ikke bliver taget op, men blot bliver gentaget.

Kaj Jørgensen kommer i sine sidste to indlæg med en række nye bemærkninger, som dog tages op nedenfor.

For at dække det samme, som DBK’s referencestruktur med de ca. 1400 indgange (klassifikationskoder) kan, skal man i fx det amerikanske OmniClass anvende de to tabeller Elements and Work results, der tilsammen er på mere end 2200 indgange. Det mener Kaj Jørgensen altså er gjort meget enklere i udlandet? Det må da vist tælle på den positive side, at der er færre indgange i DBK, og at de er kombineret i én struktur, hvor der ikke findes både forskellige men også de samme objekter, der er klassificeret i to forskellige tabeller. Det burde tiltale Kaj Jørgensen, som gerne vil tænke objektorienteret.

Hverken OmniClass eller DBK hævder at være komplette men skal fortsat udbygges. Så ja der vil sikkert komme flere klassifikationskoder til med tiden. Men det er ikke størrelsen, der er det afgørende, men om det, der er udviklet, dækker byggeriets behov. Og byggeriets behov er, at aktørerne skal kunne finde, identificere og kode de objekter (bygningsdele, rum mv.), der er i byggeriet – hverken mere eller mindre.

I øvrigt lægger vi ikke røgslør ud. Vi har altid sagt, at DBK’s tabel for bygningsdelsforekomster var en meget bevidst valgt referencestruktur med mulighed for at tilkoble klassificerede bygningsdeltyper. Det er kun andre, der har haft travlt med at skyde os i skoene, at vi skulle have sagt, at det var en traditionel klassifikationstabel.

Det kunne godt se tillokkende ud at forsimple med fx 200 indgange (kodede bygningsdele), men hvilke aktørers bygningsdele skulle da have forrang frem for andres? Det er måske mere interessant, at se på hvilke af de enkelte aktører, der skal benytte hvilken del af den samlede struktur, der er relevant for dem, og derfor vil udgøre deres view på nogle bestemte bygningsdele. For mange aktører i byggeprocessen vil man måske kun i det daglige arbejde med fra 50-200 bygningsdele. Men hvilke bygningsdele, man vil skulle håndtere, vil variere ud fra hvilken aktør man er, hvilket fag eller hvilken rolle man repræsenterer i byggeprocessen osv. Det skal en bygningsdelsstruktur kunne rumme.

Både OmniClass og DBK giver mest værdi, hvis de IT-undertøttes og anvendes i it-værktøjer. Det ved man i USA og det ved man i Danmark. Analogt er der nok ikke megen vej frem, og der har heller aldrig været nogen, der har kunnet hele SfB-bygningsdelstavlen udenad. Jeg har i hvert fald endnu ikke mødt dem.

Det er tydeligt i Kaj Jørgensens skrifter, at Kaj primært interesserer sig for indgangen til byggeriets digitalisering og til emnet klassifikation via Cad-værktøjer, der kan genere geometriske bygningsmodeller, og for de modelleringsmekanismer, disse værktøjer håndterer. Deraf sikkert også det tidligere nævnte begreb ”abstraction mechanism” anvendt om henholdsvis komposition og klassifikation. Et begreb jeg kun kan finde anvendt i forbindelse med datamodellering, også jf. Kaj Jørgensens egen henvisning til og i hans og Jørn Skauges på mange områder udmærkede rapport fra 2007 om dette emne. Dog er klassifikationsproblematikken også her ganske stedmoderligt behandlet.

Cad-værktøjer er kun en (om end vigtig) del af byggeriets samlede palette af værktøjer. Fx arbejder men i bygningsdelbeskrivelser med langt flere bygningsdelsobjekter, end Cad-værktøjet tit håndterer og tit også med flere og mere detaljerede informationer om disse. Eksemplet kunne være en væg modelleret som et objekt i cad men håndteret som måske 5-6 objekter i bygningsdelsbeskrivelser, hvor væggens bestanddele skal håndteres af forskellige fagområder under udførelsen. Der kunne gives mange lignende eksempler. Og DBK kan også håndtere dette.

Et citat fra Kaj Jørgensens indlæg: ”Faktum er også, at det en referencebetegnelse til denne tabel tilfører et beskrivelsesobjekt af en bygningsdel er en oplysning om, hvor bygningsdelen sidder i bygningens struktur af bestanddele. Jeg spørger bare, hvor vigtigt det er. Dernæst påviser jeg blot, at hvis man arbejder med bygningsmodeller, så er det en oplysning, man kan få gratis.”

Faktum er, at det sidstnævnte gør værktøjerne forskelligt, IT-orienteret og ikke brugerorienteret. Og cad-værktøjet er ikke det eneste anvendte it-værktøj.
Og ja det er utrolig vigtigt. Det vil man vide, hvis man har været praktisk beskæftiget med byggeri og har forstået, hvor problemerne ligger mht. informationsudveksling og –anvendelse samt grænsefladeproblematikker mellem parterne og på tværs af IT-værktøjerne.
Det er derfor, Kaj Jørgensen er på vildspor og hans eget udgangspunkt er forkert – eller i hvert fald for snævert.

Men tak for debatten!

Klasser og objekter

Han har gang på gang vist, at han ikke er i stand til at skelne, mellem det dataobjekter er og kan, og den information om byggeriets fysiske objekter som brugerne skal anvende på en for dem meningsfuld måde.

Der er ikke nogen modsætning imellem objekter i IT terminologi og objekter i den virklige verden, tværdigtmod. Men for at forstå hvordan virkligheden kan modelleres som objekter, er det vigtig at forstå hvad en klasse og en klassifikation er.

Begrebet klasse bruges til at klassificere enheder eller entiterer i den virklighed, det problem domæne, der skal modelleres. Hvis problem domænet omhandler sygehusvæsenet, kunne en klasse være et syghus, en patient eller en sygdom. Et objekt derimod, er et konkret tilfælde af en klasse. Dvs. hr. Hansen kunne været et objekt af typen patient eller Rigshospitalet kunne være et konkret sygehus.

Klasser kan ordnet i såkaldte arvehierakier. I et sådan hieraki, arbejder man med generalisering mod toppen af hierakiet og specialisering mod bunden. Det er dog klasserne der indornes i hierakiet, ikke objekter. Objekter er konkrete instanser (tilfælde) af en klasse.

Opbygningen af DBKs referencesystem handler i denne sammenhæng ikke om klasser, tværdigtmod er omdrejningspunktet identiteter, dvs. de konkrete bygningsdele eller objekter. Som sådan er der absolut ingen sammenhæng imellem en objektorienteret model manifisteret i et klassediagram og DBKs referencesystem.

DBKs referencesystemet ønske om at identificere bygningsdele er en helt anden sag end at klassificere dem. En klasse ville være en bygningdel som en mursten eller en tagsten. Næste niveau kunne være ler tegl, betontagsten, stålplader etc. Et konkret produkt, et objekt, en identitet ville være en type af disse klasser. Heri består forskellen mellem identiteter repræsenteret som objekter og typer repræsenteret som klasser.

Problem domænet i ISO 81346 er da også identifikation: ”The reference designation identifies objects for the purpose of creation and retrieval of information about an object, and where realized about its corresponding component.”.

Det er ikke klassifikationen.

Faktum er at den tabel, som er forudsætning for at kunne angive en referencebetegnelse (kode) i de såkaldte produktaspekt er på over 1400 indgange!! Det kan man da vist ikke kalde overskueligt og let anvendeligt. Selv for et dokumentbaseret byggeri fremhæver DiKon afprøvningen da også, at der skal IT støtte til. Som det også er konstateret fra flere sider, er denne tabel ikke komplet, så den vil utvivlsomt vokse sig større. Hvor stor mon den skal være?

Såfremt en klassifikation opbygges hierakisk, er antallet af klassifikationer irrelevant. Som i et klassehieraki, med generalisering mod toppen og specialisering mod bunden, kan man vælge det niveau der er passende til situationen.

Eksempelvis benytter de danske sygehusvæsen en SKS klassifikation (Sundhedsvæsenets KlassifikationsSystem). Der findes i skrivende stund ca. 75.000 SKS koder. Jo dybere i hierakiet, jo mere specifikt. Hierakiet tillader samtidig at vælge et passende niveau ift. situationen.

F.eks. har man brug for en tagsten, men er i første omgang ligeglad med om det er en lertegn, betontagsten, stålplade etc.

Jo mere og mere specialiseret produkterne bliver, jo mere specialiseret kan klassifikationssystemet laves. Det er dog kun en gevinst, i form af øget præcisering, så længe klassifikationssystemet er opbygget hierakisk og så længe processen er digitaliseret.

Referencesystemet er en måde at ordne de dele af en bygning, der er klassificeret som værende bygningsdele, i en del-helheds-relation, og hver af de herved relaterede objektklasser kan klassificeres detaljeret med de bygningsdelstyper, der måtte findes for disse, fx vægtyper, ventiltyper, vinduestyper, bjælketyper, søjletyper etc. Dette mener Kaj Jørgensen klares med et dataobjekt med vedhæftede egenskaber.

En klasse med navnet bygningsdel, med hver en reference til de øvrige klasser bestående af ” fx vægtyper, ventiltyper, vinduestyper, bjælketyper, søjletyper etc”. Konkrete instanser ville så være de konkrete produkter og type klasserne ville indeholde de forskellige typer. Det er en hel banal model. Kompleksiteten, hvis der er nogen, består i relationerne.

Læs mit indlæg om mytedannelse, spin og it-fiksering i Kaj Jørgensens to indlæg under hans andet indlæg!

Det er i vist begge to lige gode om. Jeg læser i hvert fald masser af forvrøvling af objekt-, model- og klassifikationsbegreberne.

Re: Klasser og objekter

Opbygningen af DBKs referencesystem handler i denne sammenhæng ikke om klasser, tværdigtmod er omdrejningspunktet identiteter, dvs. de konkrete bygningsdele eller objekter. Som sådan er der absolut ingen sammenhæng imellem en objektorienteret model manifisteret i et klassediagram og DBKs referencesystem.

Et gæt er, at denne mangel skyldes, at tanker om digitaliseret byggeri stammer fra en fortid hvor objektklasser i programmering ikke var alment kendt lærdom. At programmere således, blev først almindeligt kendt omkring 1990.

Programmering med objekter er meget vigtigt, hvis den tilknyttede fysiske verden er hierarkisk opdelt, således som anvendte byggevarer i særdeleshed er, for eksempel:

Lokalområde -> byggeplads -> bygning -> tag -> tagsten.

Eller: Hus -> dør -> dørhåndtag.

Eller: Persongruppe -> anfører -> følgeselskab -> tjenere -> hunde.

Konceptuelt, altså ikke-fysisk, kan et alternativt hierarki udformes, for eksempel: "Udstykningsområde" -> "parcelhus" -> "etage" -> "rumlighed" -> "funktion" (hvor "funktion" fx kan være "arbejdsområde" eller "hvileområde" eller "omklædningsområde" m.m.

Ved at krydse fysiske hierarkier med konceptuelle hierarkier, og indprogrammere sådant, kan man tegne et bygning særdeles hurtigt med CAD, ved hele tiden at udvælge en objekttype, dvs. man skaber en digital kopi af et objekt som man udvælger fra en database og man giver kopien et konkret navn og anbringer det i sin tegning. I så fald, hvis man udvælger en objekttype ved navn "dagligstue", da propper softwaren fx straks en rumlighed ind i tegningen med fire vægge og to døre og tre ruder og syv lyskontakter og ni stikkontakter. Hvis man i tegningen dernæst undersøger fx en af dørene, vil man måske se, at denne i sig selv er et medhevet objekt, allerede udstyret med et håndtag og en lås. Hvis softwaren er intelligent, vil fx mure automatisk skifte tykkelse, hvis man fra databasens valgmuligheder vælger at indsætte en bedre dør i tegningen (hvis fx denne dør kræver en stærkere mur). Hvis softwaren gør dette, da sørger softwaren måske også automatisk for at udskifte etageadskillelsen med en stærkere type, hvis man udskifter rumligheden til en art som vil forøge belastningen af bygningen. Desuden, når man er færdig med at tegne, kan man lade sin software gennemtrevle tegningen og optælle fx alle priser og alle vægte, summer som man har behov for, for at kunne få sig et overslag over den samlede byggepris. Softwaren kan måske også fuldautomatisk udregne mængden af stål og cement og sand og kabler, og så videre, som skal indkøbes til projektet, og udregne antallet af lastvogne som vil behøve at levere. Hvis man indtaster byggearbejsgrundens størrelse (den plads hvor lastbiler og skurvogne vil kunne parkere), kan softwaren måske udregne en foreløbig tidsplan, og så videre.

Jo flere arter af sådanne output, som softwaren evner at skabe ud fra en digital bygningstegning, jo større gavn har man af at anvende CAD-tegning som værktøj når man tegner byggeopgaver. I min fortid lavede jeg fx et værktøj, der fuldautomatisk beregnede om et tegnet hus opfyldte de danske krav til soliditet (statik).

Derimod: Hvis man blot ønsker sig en tegning af bygningen, da er det meget lettere at nøjes med blyant og papir og en kopimaskine. Tegnede data, på digital måde, har eksplosiv "eksponentiel" værdi, men kun hvis dataene bliver genbrugt fuldautomatisk af et mangfoldighed af intelligent software, herunder måske også en fælels digital kalender og en personaledatabase og et regnskabssystem, og et salgssystem, og et kvalitetssikringssystem. Når man har CAD-tegnet et hus, bør softwaren fx evne på fuldautomatisk måde at udskrive et skriftligt salgstilbud til en bygherre, eller, hvis brugeren er en bygherre, da skal softwaren evne fuldautomatisk at udskrive en invitation til entreprenører om at byde på opgaven, dvs. en fuldautomatisk udskrivning af et brev og en bygningsbeskrivelse med tegninger og hele molevitten. Cirka noget i den stil, lavede jeg engang for Udenrigsministeret, dengang handlede det om på forhånd at kvalitetssikre danske ingeniørselskabers leverancer når disse afgav tilbud på rådgivningsopgaver til ministeriet.

En investering i at lave de mange hierarkier af klasser, er især nødvendigt, hvis man vil anvende intelligent software i kraftfulde computere, en metode som i dag er nødvendigt, hvis man vil bygge store og komplekse bygninger. Man kan fx lade en computer tegne et hotel i samtlige detaljer uden menneskelig indvirken, ved blot at føde softwaren med en række parametre, eksempler: A) Antal gennemsnitlige gæsteankomster pr. dag, B) Gæstegruppers gennemsnitlige antalstørrelse, C) Gæsters gennemsnitlige højde, D) Gæsters gennemsnitlige vægt, E) Den gennemsnitlige udendørstemperatur, F) Den gennemsnitlige udendørs luftfugtighed, G) Lokalområdets gennemsnitlige niveau for støjforurening og rystelser, H) Lokalområdets gennemsnitlige niveau for luftforurening, I) Lokalområdets gennemsnitlige niveau for overfald og tyverier og røverier, J) Byggegrundens grad af soliditet, K) Byggepladsens byggearbejdsareals størrelse, og så videre ... X) Gæsters grad af krav om luksus.

Med sådanne data, kan intelligent software gennemtrevle objekthierarkier, og udregne fuldautomatisk hvordan hotellet skal indrettes og hvor store rumligheder skal være, hvor de skal anbringes i bygningen, antallet af komfurer i køkkenet, receptionens størrelse, hotellets bemanding, og så videre. Hvis softwaren er virkelig intelligent, kan den vælge alternative måder at bygge styrken i hotellet, afhængig af (for eksempel) om armeret stål er meget dyrt for tiden eller ej. Ved at skrue på parametre, kan tegneren fx vælge, om hotellet skal optimeres totalt for gæsterne (som fx kan få softwaren til at tegne en bygning med mange unikke vinkler og mange unikke detaljer), eller om byggeprisen skal blive så billig som mulig (som fx kan få softwaren til at danne en bygning med mange gentagne ens byggeopgaver og med samtlige vinkler i form af kun rette vinkler og kun i visse ganske få standardlængder). En ideel software vil evne at finjustere på detaljer, afhængig af det prispres som en bygherre forlanger.

Det siger sig selv, at sådan software, baseret på titusindevis af data der er sorteret i mange alternative hierarkier af klasser, er en meget stor investering at gøre sig. Til gengæld, når man har skabt sådant, kan man skalere sig op i størrelse, dvs. bygge mange flere store projekter end ellers, eller optimere et bygningsværk i langt større grad. Visse bygninger, fx hoteller, vil få en voldsomt forbedret indtjeningsevne, fordi intelligent tegnesoftware gør det muligt at tage højde for mange flere parametre end en manuel tegneproces gør muligt. En "manuel" tegneproces kan i den forbindelse godt være digitaliseret, sådant gør ikke processen spor bedre, medmindre at der er intelligens i softwaren.

Det helt store problem med kompleks intelligent software er, at softwaren hele tiden skal ændres, fordi verden forandrer sig. Hidtil har denne faktor gjort sådan software meget problematisk, fordi sådan software først blev skrevet til gamle dages mainframes, og dernæst til personlige computer baseret på DOS-operativsystem, og dernæst til diverse udgaver af Windows, måske endda med et sidespring til en udgave af et operativsystem fra IBM, og sidenhen til diverse udgaver af browsere til Internet, og ingen af disse platforme har været kompatible med hinanden. Denne faktor vil næppe blive bedre i fremtiden, og som betyder, at man så vidt som overhovedet muligt skal skabe alt i form af data i relationsdatabaser og i form af programmerede standardfunktioner, den slags moduler der også i fremtiden vil kunne blive anvendt af mange vidt forskellige softwareprogrammer på vidt forskellige fremtidige IT-platforme.

Hierakisk klassifikation

Lokalområde -> byggeplads -> bygning -> tag -> tagsten.

Eller: Hus -> dør -> dørhåndtag.

Eller: Persongruppe -> anfører -> følgeselskab -> tjenere -> hunde.

Overstående er ikke eksepler på et klassehieraki eller et klassifikationshieraki.

Er en tagsten et specialiseret lokalområde? Nej vej.

Er et dørhåndtag et specialiseret hus? Nej vel.

Er en hund en specialisering af en persongruppe. Nej. Er en persongruppe en generalieret hund?

Overstående eksempel beskriver selvstændige klasser (konceptuelt set objekter faktisk) der ikke kan ordnes meningsfyldt i et klassehieraki eller et klassifikationshieraki.

Det er her misforståelse opstår. Disse eksempler har intet med hierakisk klassifikation at gøre.

Ideen i hierakisk klassifikation

Ideen i hierakisk klassifikation består i at en identitet kan betragtes dels som det den er klassificeret som samt alle overstående klassifikationer i hierakiet.

Eksempelvis:
Jeg kan klassificeres som et menneske (Homo H. sapiens)
Jeg er også en primat
Jeg er også en pattedyr
Og jeg er et dyr.

Som identitet er jeg Carsten Sonne Larsen. Noget helt andet end klassifikationen menneske.

Re: Hierakisk klassifikation

Disse eksempler har intet med hierakisk klassifikation at gøre.

Jeg kan se, rigtigt, at jeg har taget fejl af kørebanen.

Alligevel, lad mig forsøge, om jeg kan forklare:

Grundreglen er: Når man tegner eller programmerer med objekter, da vælger man sine objekthierarkier således, at flest mulige objekter kan arve mest muligt fra sine forfædre, altså fokus på arvemasse størrelse. Jo mere arvemasse, jo simplere og hurtigere er det at skabe noget, og jo simplere er det at foretage ændringer i noget, ved hjælp af programmeret software, fx i en tegning.

Det er fx sandt, at et dørhåndtag ikke er et specialtilfælde af en dør, men et dørhåndtag kan med naturlighed i beregninger arve fra en dør, fx farve, tykkelse, styrke, kunstnerisk art. På tilsvarende måde kan man overveje, om man vil lade en dør være en arving fra en dørramme, og lade en dørramme være en arving fra en mur. Med "overveje" menes en analyse af den måde som en bygning hænger sammen, om der er nogle sammenhænge der har betydning for beregninger.

Når man fx skal beregne den nødvendige styrke i en etageadskillelse, da kan der i en tegning være en fysisk sammenhæng således, at hvis man forøger styrken, så vokser måske også vægten, og da skal måske også mure forstærkes, som betyder at de måske bliver tungere, og hvis, da skal måske også bygningens fundament gøres stærkere, og hvis, da skal fundamentets pæle måske forstærkes. Alle disse udregninger vil typisk trække på et antal af beregningsfunktioner der ligner hinanden meget, som betyder at man kan overveje at relatere de nævnte ting i et hierarki: Pilotering - fundament - mur - etageadskillelse - møbler (møbler på grund af deres vægte og fylde, i dette tilfælde). Måske bør man også lade "mennesker" og "trafikmængde" indgå i et sådant hierarki, således at hvis antallet af mennesker og deres trafik bliver forøget af en bygherre (krav derom), da vil en tegner måske meget let, ved at indtaste nogle få data, bringe sin software til halvautomatisk eller fuldautomatisk at ændre på gulve og så videre.

Eksempel: Hvis vi kigger på "mur", da kan en arving derfra måske være fx en "dør", men altså måske også en "etageadskillelse", to børn der i teoretisk forstand ikke er spor søskende. Alligevel giver hierarkiet måske mening i en byggetegning, og hvis, da betyder det, at hvis man foretager en ændring af en murtykkelse, da vil hierarkiet automatisk opfange at også dørrammer i muren skal ændres, og dermed måske også dørene, og måske også håndtagene og låsene. Samtidig vil hierarkiet opfange at der sker en ændring af bygningens samlede vægt, og at lastbiler skal tilbringe en forandret vægt til byggepladsen, og indkøbslister bliver automatisk ændret, som kan betyde at en tegner får foræret tusindevis af tegningsmæssige ændringer ved blot at forandre på en murs tykkelse (alt dette blot et eksempel).

Essensen er, at ved at vælge et optimalt hierarki til den bygningsart som man vil tegne, da vil flest mulige konkrete objekter i en tegning sørge for at kalde til færrest mulige forskellige beregningsfunktioner, som gør det hurtigere og lettere at programmere og overskue og tegne, og især hurtigere og lettere at foretage ændringer i en tegning.

Essensen er også, at hvis man som tegner leder i produktkataloger efter et dørhåndtag, da er det muligvis ikke smart at lede i et hierarki af lutter dørhåndtag, fordi der i verden findes tusinder af dørhåndtag der omtrentligt ligner hinanden, som kan være tidsspilde at bladre i sådant. Derimod, hvis man på forhånd har fat i en murtype, da kan man måske via et hierarki bladre i et overskueligt antal af dørrammer der passer til murtypen, og dermed kan man via et hirarki måske bladre i et overskueligt antal af døre der passer til dørrammen, og ved at pege på en dør, da kan man måske nøjes med at bladre i et overskueligt antal af dørhåndtag der passer til døren. Alternativt kan det tænkes at en bygherre vil begynde med at pege på et konkret dørhåndtag og sige: »Jeg vil have et hotel der passer til dette håndtag.« I så fald har en tegner behov for en relationsdatabase der kan udpege de kompatible døre, og dørrammer, og mure, og så videre. Objektmæssige hierarkier, som en tegner benytter sig af, kan således måske være kun midlertidige, anvendt af ham/hende i en indledende fase.

Alt dette betyder i praksis, at byggevarer, i produktkataloger, behøver et unik identifikationsnummer og skal være beskrevne med et tilstrækkeligt antal af fysiske data og disse data skal være angivet på en standardiseret måde, fordi man da med CAD og relationsdatabaser kan nøjes med at hive fat i kun relevante (filtrerede) lister når man har behov for at indsætte et objekt i en tegning. Desuden vil intelligent software automatisk omberegne styrken i fx en mur, hvis tegneren ændrer på den valgte art af fx mursten, forudsat at alle relevante data til beregningen findes i produktkataloget.

Hvordan byggevarer er sorteret indbyrdes i produktkataloger, er ikke vigtigt for en tegner, fordi tegneren selv vil vælge sit hierarki, afhængig af byggemåde, og normalt have sin egen software til at bladre i byggevarer.

Et spørgsmål: Hvorfor overhovedet i produktkataloger sortere byggevarer indbyrdes på en ganske særlig måde og tildele varerne standardiserede klassenavne? Svaret er muligvis, at det er gammeldags, fra en tid da man stort set kun havde opslagsbøger (behov for, for mennesker at kunne lære sig selv at søge i et katalog i et fysisk bibliotek), og at myndigheder dengang lovgav på måder der var kompatibelt med det valgte hierarki af klasser. Helt sikkert også, havde man i gamle dage igen praktiske evner til at foretage præcise beregninger i tegninger, som betød at man havde behov for at foretage især kun simplere standardiserede beregninger, og dertil havde man behov for standardiserede byggevarer, således at hvis man på forhånd kendte til en byggevares klasse, da vidste man cirka om hvad sådant betød for beregningers resultater. Og, som en konsekvens af dette, fordi man fik et velsorteret hierarkisk katalog, blev det let for producenter at opdage når konkurrenter begyndte at sælge påståede tilsvarende varer, som nu og da straks kunne alarmere alle om at en producent var begyndt at sælge varer med påstande om fx holdbarhed der var løgne. Og, nu og da, viste det sig, at der ikke var tale om løgne, men om at en defineret klasse var temmelig unøjagtigt defineret, dvs. at der var visse egenskaber for varer i en klasse som i praksis var kendte, men aldrig hidtil blevet beskrevet, og derfor overset af fx en fjern udenlandsk producent.

I dag, med computere til at beregne på samtlige detaljer i en tegning, har man ikke længere nær så stort behov for klasser, derimod behov for præcise standardiserede fysiske måledata, fx om farver og længder og vægt og elasticitet og så videre.

Re: Klasser og objekter

Til Carsten Sonne Larsen

Tak for dit indlæg om objekter og klasser. Jeg kan 99% tilslutte mig din fremstilling (kun enkelte ligegyldige detaljer fanger jeg ikke helt). På den baggrund undrer jeg mig så lidt over din sidste bemærkning, at også jeg har vrøvlet. Det vil jeg da gerne have preciseret.

Jeg bemærker altså en klar enighed om, at Referencesystemet ikke er klassifikation. En pointe jeg har fremhævet mange gange.

Jeg bemærker også en meget vigtig karakteristik af det at arbejde med hirarkiske klassifikationstabeller, nemlig at man kan folde ud og folde sammen efter behov og kan vælge det neveau, der passer bedst i en given situation.

På baggrund af disse forhold er det så, at jeg undres over, hvor lidt argumentation, der har været om at klassifikation skal erstattes med et referencesystem (noget helt andet) og dermed afvige så drastisk i forhold til andre betydende nationer.

(Jeg vil snarest fortsætte diskussionen)

Hvad er formålet?

@Kaj A. Jørgensen

På den baggrund undrer jeg mig så lidt over din sidste bemærkning, at også jeg har vrøvlet. Det vil jeg da gerne have preciseret.

Jeg vil indrømme at det meste vrøvl ikke kommer fra dig. Jeg kan dog ikke se den modsætning der tilsyneladende bliver fremstillet imellem en model og den virkelighed modellen afspejler samt at et meget lavt antal klassifikationer skulle være ønskværdigt. Det kan ske jeg har misforstået dig.

@Carsten Scherrebeck Møller

Grundreglen er: Når man tegner eller programmerer med objekter, da vælger man sine objekthierarkier således, at flest mulige objekter kan arve mest muligt fra sine forfædre, altså fokus på arvemasse størrelse.

Den grundregel kan jeg ikke nikke genkendende til. Hverken fra mit arbejde, fra litteraturen eller blandt kollegaer.

Det vigtigste for en model er derimod at den afspejler virkeligheden. Ikke i detaljer, men på et passende niveau, deraf termen model.

Hvad er virkeligheden så? Virkeligheden er den som aktøre i problem domænet opfattelser som virkeligheden. At tage Dansk Bygge Klassifikation og betragte det som et klassifikationshieraki, er nok ikke en virkelighed der er særlig mange, som kan genkende.

Du får nok svært ved at overbevise Hr. Hansen, der er ved at få bygget et hus om at i virkeligheden så er et dørhåndtag bare en specialiseret dør. Eller den håndværker der skal montere døre. Ikke engang den ingeniør der skal regne på kræfterne eller den arkitekt der sidder med sit CAD software vil kunne nikke genkendende til den fremstilling af virkeligheden. Derfor er en sådan virkelighed så kunstig at man med rette kan kalde modellen for virkelighedsfjern.

Det er korrekt, at i visse tilfælde benyttes et design, hvor et sæt klasser arrangeres i et kunstigt arvehieraki med det formål at benytte polymorfisme og arv til at opnå et mere robust og vedligeholdesesvenligt design ift. forretningslogik, f.eks. beregninger. Det er bare ikke en teknik der benyttes i modeller, som skal afspejle koncepter i et domæne.

Wikipedia:

I begrebshierarkier kan der være tale om forskellige typer af semantiske relationer: generiske relationer eller del helhedsrelationer. En generisk relation kaldes også en slægts-art relation, en "is-a"- relation eller en forældre-barn relation. Fx relationen mellem pattedyr og tigre: En tiger er et pattedyr, tigeren "arver" alle de egenskaber, som overkategorien pattedyr besidder. Dette er ikke tilfældet i del-helheds relationer. Sjælland er en del af Danmark, et rat er en del af en bil.

For interesserede i objekt orienteres analyse, kan jeg kraftigt anbefale at læse Craig Larmanns bog ”Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development” og Martin Fowlers ”Patterns of Enterprise Application Architecture”. Sidstnævnte sætter førstnævnte i kontekst og beskriver begrebet rige domæne modeller.

Eksempel: Hvis vi kigger på "mur", da kan en arving derfra måske være fx en "dør", men altså måske også en "etageadskillelse", to børn der i teoretisk forstand ikke er spor søskende. Alligevel giver hierarkiet måske mening i en byggetegning, og hvis, da betyder det, at hvis man foretager en ændring af en murtykkelse, da vil hierarkiet automatisk opfange at også dørrammer i muren skal ændres, og dermed måske også dørene, og måske også håndtagene og låsene. Samtidig vil hierarkiet opfange at der sker en ændring af bygningens samlede vægt, og at lastbiler skal tilbringe en forandret vægt til byggepladsen, og indkøbslister bliver automatisk ændret, som kan betyde at en tegner får foræret tusindevis af tegningsmæssige ændringer ved blot at forandre på en murs tykkelse (alt dette blot et eksempel).

For mig at høre lyder det som om du forsøget at løse et helt andet problem end klassifikation. Det lyder i højere grad mere som om du har behov for et formaliseret sprog/notation, der kan beskrive afhængigheder imellem elementer ift. en matematisk beregning af kræfter, et såkaldt domæne specifikt sprog (Domain Specific Language el. DSL).
Det er klart i et DSL der skal understøtte den type beregninger og valg, der skal alle atomare elementer indeholde nogle velkendte minimumsegenskaber, f.eks. vægt og elasticitet. Andre egenskaber kunne være valgfrie, f.eks. farve og dimension.
Det problem løses bare ikke med et klassifikationssystem som Dansk Bygge Klassifikation. Det problem løses ved at have data om de relevante enheder og et sprog der kan beskrive afhængighederne i mellem bygningselementerne.

Samtidig må man definere koncepter som bygningselement og byggedele. For mig at se er det ikke det samme koncept. En bygningsdel ville være toppen i et naturligt klassifikationshierarki. Bygningselementer ville derimod være et bestemt type bygningsdel i en bestemt kontekst.

Essensen er også, at hvis man som tegner leder i produktkataloger efter et dørhåndtag, da er det muligvis ikke smart at lede i et hierarki af lutter dørhåndtag, fordi der i verden findes tusinder af dørhåndtag der omtrentligt ligner hinanden, som kan være tidsspilde at bladre i sådant. Derimod, hvis man på forhånd har fat i en murtype, da kan man måske via et hierarki bladre i et overskueligt antal af dørrammer der passer til murtypen, og dermed kan man via et hirarki måske bladre i et overskueligt antal af døre der passer til dørrammen, og ved at pege på en dør, da kan man måske nøjes med at bladre i et overskueligt antal af dørhåndtag der passer til døren. Alternativt kan det tænkes at en bygherre vil begynde med at pege på et konkret dørhåndtag og sige: »Jeg vil have et hotel der passer til dette håndtag.« I så fald har en tegner behov for en relationsdatabase der kan udpege de kompatible døre, og dørrammer, og mure, og så videre. Objektmæssige hierarkier, som en tegner benytter sig af, kan således måske være kun midlertidige, anvendt af ham/hende i en indledende fase.

Igen, overstående problem løses ikke med et klassifikationssystem. Det løses ved at have en fornuftigt opbygget datamodel , ift. den virkelighed som der er beskrevet, i en relationel database med data om de konkrete produkter man muligvis ønsker at anvende. Det problem har i sig selv intet med et hierarki klassifikationssystem at gøre.

Alt dette betyder i praksis, at byggevarer, i produktkataloger, behøver et unik identifikationsnummer...

Ja, EL og EAN numre har lige præcis nog et med identitet og identifikation at gøre. De har intet med klassifikation at gøre. Heller ikke selv om nummeret er opbygget i et fast system med faste nivauer. At en identitet (primær nøgle) så ikke engang er entydig, viser hvor ugennemtænkt systemet er. En identitet afhænger af placering. Dvs. jeg er ikke den samme hvis jeg sidder er i min stue eller jeg er i mit køkken. Det er jo noget sludder og vil skabe mange problemer den dag disse ikke entydige identiteter skal modeleres i en faktisk database eller et faktisk stykke software for ikke at tale de mennesker der skal arbejde med disse tvetydige produktkoder.

En lille tegning siger mere end

På Byggebloggen har jeg foreslået en tegning af problemstillingen. Se her:

http://ing.dk/artikel/106881-v...riet

Men fortsæt gerne her med tekst - så tar vi tegningen på Byggebloggen.

ing.dk's redaktion kan hjælpe jer med at få lagt tegningen rigtigt ind.

Re: Hvad er formålet?

Den seneste diskussion mellem Carsten Sonne og Carsten Scherrebeck fremhæver en række problemstillinger og berører nogle ofte forekommende misforståelser om klassifikation, som jeg også selv har mødt adskillige gange. I sagens natur kan en diskussion derfor let blive diffus og læserne kan let miste orienteringen. Det viser netop derfor vigtigheden af at der kommer en egentlig afklaringsproces i gang, så eventuelle misforståelser kan fjernes. Jeg vil ikke her gå nærmere ind i denne diskussion men blot udtrykke min overvejende støtte til Carsten Sonnes fremstilling.

Re: Re: Hvad er formålet?

Betegnelsen 'forekomst' er måske det, der skiller vandene

Der er vigtigt at skelne mellem to niveauer: 1) arbejdet med konkrete objekter (i konkrete projekter) og 2) det at udvikle forskrifter, oversigter, mv. generelt gældende for branchen (rettet mod alle projekter). Det er det sidste, der fra starten har været mit udgangspunkt, og det vil jeg gerne, at vi holder fast i. Jeg noterer mig i den forbindelse, at Gunnar Friborg fremhæver betegnelsen 'forekomst', en betegnelse som meget udbredt i DBK. Denne betegnelse er, så vidt jeg kan bedømme, et helt afgørende udtryk for forskellen i opfattelse af, hvad det drejer sig om.

Før "noget" bliver til en forekomst, skal det skabes og skabelsen/fødslen sker mest effektivt ved, at man vælger at tage udgangspunkt i "noget foreliggende". Helt almindeligt udtrykkes det ved at man vælger en type (eller en klasse) og danner et eksemplar/forekomst/objekt heraf. 'Type/klasse' skal foreligge generelt og 'forekomst' hører til det projektspecifikke. Hvis typen/klassen er hensigtsmæssigt udformet, får man ved skabelsen et antal passende egenskaber/attributter, der kan benyttes til at definere/specificere objektet i form af konkrete værdier. Det er altså disse typer/klasser, der er grundlaget for en effektiv skabelsesproces. Et velkendt eksempel på dette er valg af konkrete modelobjekter i et cad-værktøj. Det kan konkret foregå lidt forskelligt men generelt har alle cad-værktøjer et bibliotek af objekttyper (klasser), som brugeren kan vælge fra. Når brugeren vælger en type skabes et objekt af denne type og en række attributter bliver til rådighed. I cad-værktøjer fokuseres naturligt nok på attributter til beskrivelse af geometri men andre kan også forekomme.

En velorganiseret klassifikationstabel kan støtte denne skabelsesproces, idet den dels giver et hensigtsmæssigt overblik og dels leder til valg af, hvor specifikt objektet skal være på det givne tidspunkt. Det er altså klassifikationen (typer/klasser), der går forud for skabelsen og efterfølgende håndtering af objekter. Men når objektet dermed ved, af hvilken type det er, så kan dette også bruges i den fremadskridende detaljeringsproces. Her kan klassifikationstabellen anvendes igen ved at objektet kan specialiseres yderligere (man går dybere i hierarkiet) og flere specifikationer kan opsøges og hægtes på. Det sidste kan gøres ved at oprette flere attributter og tildele disse attributter værdier, manuelt eller vha. specialsoftware f.eks. vedrørende energiberegninger.

Af ovenstående følger, at klassifikationstabeller er direkte rettet mod at understøtte denne arbejdsproces (generelt beskrevet). Enhver kan se, at referencebetegnelser helt kan sidestilles med andre attributter/egenskaber, så, hvis nogle ønsker at angive disse, kan de uden problemer hægtes på og bæres med objekterne i deres videre færd. Anvendelse af klassifikationstabeller kommer altså først og den konkrete struktur dannes efterhånden som objekterne skabes og der knyttes relationer mellem dem.

Det afgørende er altså, at der udarbejdes et overblik over bygningsdelsklasser generelt for byggeriet, så de dels kan støtte ovennævnte processer og dels kan danne grundlag for at dataudbydere kan publicere forskellige mængder af information til gavn for projekterne.

For at illustrere karakteren af en klassifikationstabel vises nedenstående udspil rettet mod de først valg af objekter (dataobjekter generelt eller modelobjekter). Det understreges, at det ikke er et konkret forslag men blot en illustration for at eksemplificere. Kendere af SfB-systemet vil se en del ligheder og det er ikke tilfældigt. Meget i SfB er godt så en ny tabel behøver ikke at bryde fuldstændig med det, som kloge hoveder en gang fandt ud af. Visse forhold skal dog gribes anderledes an. Kritikere af klassifikation vil sige, at ligegyldigt hvilken inddeling man laver, så vil det være svært at placere alle bygningsdelsklasser det "rigtige" sted. Ja, jeg siger ikke, at det er nemt, så det er her praktisk erfaring skal benyttes sammen med grundlæggende retningslinier. Kik på tabellen og se, hvor enkelt det (måske) kan gøres.

Bygningsdel
. Konstruktionsbygningsdel
. . Basal bygningsdel
. . . Væg
. . . Dæk
. . . Bjælke
. . . osv.
. . Supplerende bygningsdel
. . . Spærfag
. . . Trappe
. . . Gulv
. . . Loft
. . . osv.
. . Kompletterende bygningsdel
. . . Dør
. . . Vindue
. . . Rækværk
. . . osv.
. . Elementardel, konstruktion
. . . osv.
. . Enhed, konstruktionsdel, kompleks
. . . Tag
. . . Bro
. . . Badekabine
. . . Kvist
. . . osv.
. Installationsbygningsdel
. . Rørdel
. . . Enhed, rørdel
. . . . Toilet/WC
. . . . Vask
. . . . Badekar
. . . . Beholder
. . . . osv.
. . . Elementardel, rørdel
. . . . Rør
. . . . Fitting
. . . . osv.
. . . Anlæg, rørdel
. . . . Friskvandsanlæg
. . . . Afløbsanlæg
. . . . Pumpeanlæg
. . . . Sprinkleranlæg
. . . . osv.
. . Elektrisk/elektronisk del
. . . Enhed, elektrisk/elektronisk
. . . . Transformer
. . . . Måler, elektrisk/elektronisk
. . . . Display
. . . . Konvektor, el
. . . . Betjeningspanel
. . . . osv.
. . . Elementardel, elektrisk/elektronisk
. . . . Kabel
. . . . Terminal, elektrisk/elektronisk
. . . . . Afbryder
. . . . . Udtag, lampe
. . . . . osv.
. . . . Sensor
. . . . osv.
. . . Anlæg, el
. . . . Alarmanlæg
. . . . Adgangskontrolanlæg
. . . . Belysningsanlæg
. . . . osv.
. . Enhed, installation, kompleks
. . . Ovn
. . . Kedel
. . . Elevator
. . . Escalator
. . . Køleenhed
. . . osv.
. . Anlæg, installation
. . . Varmeanlæg
. . . Ventilationsanlæg
. . . Luftkonditioneringsanlæg
. . . Transportanlæg
. . . Køleanlæg
. . . osv.
. Fast inventar
. . Brusekabine
. . Kabinet
. . Reol
. . osv.
. Udstyr
. . Støvsuger
. . Køleskab
. . TV-apparat
. . Computer
. . osv.
. Møbel
. . Stol
. . Bord
. . osv.


NB! Identifikation af de enkelte indgange i form af koder er ikke påsat.

Objekter og hierarkier i tegninger

At tegne/programmere med objekter, betyder en distribueret intelligens i software i form af en slags selvtænkende klumper (objekter) der er indbyrdes forbundet i hierarkier.

En konkret klump, et objekt, fødes under praktisk anvendelse af et værktøj (software), ved at der bliver skabt en klon (en samling af data i hukommelse) ud fra en forud programmeret objekttype. Den forud programmerede objekttype er normalt altid en samling af variabelnavne og konstanter og funktionsnavne og procedurenavne og al tilhørende programkode, og med et tilknyttet typenavn, fx "Carport". Det særlige er, at når et konkret objekt (fx "Carport A") dernæst bliver født under programkørsel, da kan man spørge objektet: Hvad indeholder du netop nu? Hvilke børn har du? Hvem er din far?

Svarene, at man lader softwaren anvende dem til noget, er essensens i objektprogrammering, og det er mere smart end man umiddelbart forventer, her er forklaringen:

I et CAD-værktøj (Computer Assisteret Design), vil en tegner måske begynde med at forudprogrammere en stamfader, fx "Byggegrund". Til denne objekttype vil tegneren måske tilkoble en arving-type, altså endnu en forud programmeret objekttype, fx "Bygning".

Når en tegner dernæst anvender dette, da anbringer tegneren fx "Bygning 1" (et barn) på "Byggegrund A" (faderen). Dette medfører typisk, at tegneren har sørget for, at faderen (byggegrunden) straks selv opdager at der er et barn, og at dette får faderen til at affyre en række af spørgsmål til barnet, for eksempel: Hvor meget vejer du netop nu, hvor meget fylder nu netop nu, og hvad koster dine ingredienser netop nu?

Svarene, som faderen (byggegrunden) modtager, kan faderen straks anvende i nogle af sine egne beregninger (forud programmeret af tegneren), fx beregne og skrive et (foreløbigt) salgstilbud til en potentiel bygherre, eller beregne restgrundens størrelse, og ud fra dette bliver en anlægsgartnerregning måske beregnet, blot et eksempel.

Barnet i tegningen, "bygning 1", er blevet født med sin egen intelligens (fra sin objekttype, forud programmeret af tegneren). Dette betyder, at barnet kan undersøge sig selv, om det har nogle børn, fx etager, og huske at inkludere dette i sine svar til sin far. Hver etage er i sig selv et objekt og kan hver især have sine egne børn, fx rumligheder. Og hver rumlighed, et objekt hver især, kan have sine egne børn, fx gulv og loft og vægge. Og hver væg kan have sine egne børn, fx beklædning og døre og vinduer og stikkontakter og ventilationsriste. Essensen er, at hver gang tegneren i sin tegneproces tilføjer eller fjerner eller flytter på noget, vil kæderne opdage forandringen og fuldautomatisk beregne alt, alle vegne. En stikkontakt kan desuden beregne sin egen position i bygningen, ved at spørge sin far, en væg, om hvor væggen befinder sig i bygningen, et spørgsmål som væggen kan bringe videre til sin far, en rumlighed, som kan spørge sin far, en etage, en kæde af spørgsmål der bringer et svar tilbage til en stikkontakt, så den kan give et samlet absolut svar til en spørger, som fx kan være et objekt der er i færd med at beregne de optimale veje at anbringe kabler i bygningen. Hvis tegneren sidenhen flytter på stikkontakten, vil alle disse spørgsmål og beregninger automatisk blive justeret.

Puritanere bør lægge mærke til, at sådanne hierarkier især giver mening i en dynamisk tegneproces, det vil sige i en proces hvor en tegner eksperimenterer sig frem til et færdigt resultat, eller en proces hvor en tegner ikke har kontrol over sin egen proces. Hvis fx bygherren opfinder undervejs i tegneprocesseen, at der mangler en garage, da kan tegneren anbringe et garageobjekt på byggegrunds-objektet, og straks vil byggegrunds-objektet selv opdage at det har fået sig et nyt barn og sørger for at genberegne alle sine totaler, fx restgrundens størrelse, sådan at fx en budgetteret anlægsgartnerudgift bliver justeret. Og: Hvis bygherren pludselig midt i tegneprocessen ønsker sig en etage mere på bygningen, da opdager bygningen at den har fået sig et nyt barn, og genberegner automatisk sine totaler, fx sit behov for soliditet i fundament, og behov for mures styrke og tykkelser, og så videre. Hvis bygherren ønsker sig en vaskemaskine mere, da vil en stamfar til vaskemaskine, fx "elektrisk installation" huske at ændre på sin kapacitet, og diverse børn/søskende vil huske at ændre på antallet af fx sikringer, og at trække et elkabel i tegningen og anbringe et gulvafløb og en vandledning. Sådanne forudprogrammerede evner, i et tegneværktøj, vil producere resultater i en tegning, som en tegner ikke nødvendigvis er enig i hver gang, men manuelle flytninger og tilpasninger vil altid være en mulighed, forudsat at tegneren forbinder objekterne i tegningen på en lovlig måde i forhold til de forud programmerede objekthierarkier.

Den store gevinst med objektprogrammering, er fleksibilitet i en kreativ anvendelsesproces. Samtidig er der ingen grænser for hvor megen intelligens som man kan indlægge i objekterne, som betyder at man fx kan lade en CAD-tegning beregne og udskrive salgstilbud, og ansøgninger om byggetilladelser, og beregne en byggeplan i kalender, og beregne indkøbslister, og beregne transportbehov, og beregne det nødvendige antal af kraner, alt sammen blot eksempler.

Gevinsten er også, at en tegner kan pege på et sted i en tegning, fx pege på en mur, og sige til sit værktøj: »Lige netop her, ønsker jeg at anbringe en dør.« I så fald kan værktøjet straks aflæse murens data, og bede muren om at spørge sin far (en etage) om yderligere data, og etagen kan spørge sin far (en bygning) om yderligere data, og alle disse samlede data kan værktøjet affyre til en produktkalog med ordren: »Vis mig en liste over døre der er kompatible med alle disse data.« Som resultat får tegneren en liste over døre, og udvælger en dør, og anbringer den i tegningen. Straks dernæst, opdager muren at der er sket en ændring, som fører til en kæde af reaktioner igennem hele byggetegningen, indtil samtlige data og beregninger og tekster og streger er blevet opdateret.

Det siger sig selv, at en tegner, der investerer tid i at forudprogrammere intelligens, for eksempel intelligens der hjælper ham/hende med at tegne fx et hotel, at en sådan tegner måske investerer mere tid i at forudprogrammere, end der opnås som gevinst imod målet at skabe den færdige tegning. Balancen er, at hvis en tegner forventer at skulle tegne fx flere hoteller i fremtiden, eller bygninger der minder derom, da er det vigtigere at anvende objektmetoder i sin tegneproces, end ellers.

Dokumentation

Links til dokumentation kan findes i f Christian Munch-Petersens blog:
http://ing.dk/artikel/106881-v...riet

En præsentation af Gunner Friborg kan ses her:
http://www.bips.dk/Bips/DDF/db....ppt

I øvrigt er Kaj A. Jørgensen beskrivelse helt i overensstemmelse med min opfattelse. Jeg kunne ikke have forklaret det bedre selv.

Tidligere omtale produktkoder syntes ikke at være en del af DBK trods dette er nævnt at flere i debatten trods nævnt af flere debattører.

Jeg beklager hvis jeg har spredt forvirring.

Timeout?

Tidligere omtale produktkoder syntes ikke at være en del af DBK trods dette er nævnt at flere i debatten trods nævnt af flere debattører.

Skulle have være:

Tidligere omtale produktkoder syntes ikke at være en del af DBK trods dette er nævnt at flere i debatten.

Re: Objekter og hierarkier

Til Carsten Scherrebeck Møller

I din beskrivelse berører du en del sider af den måde, man kan anvende objektorienteret programmering ved software udvikling og anvendelse af software klasser. Men jeg synes desværre, at der er behov for en berigtigelse. Du skriver:

<
I et CAD-værktøj (Computer Assisteret Design), vil en tegner måske begynde med at forudprogrammere en stamfader, fx "Byggegrund". Til denne objekttype vil tegneren måske tilkoble en arving-type, altså endnu en forud programmeret objekttype, fx "Bygning".

Når en tegner dernæst anvender dette, da anbringer tegneren fx "Bygning 1" (et barn) på "Byggegrund A" (faderen). Dette medfører typisk, at tegneren har sørget for, at faderen (byggegrunden) straks selv opdager at der er et barn, og at dette får faderen til at affyre en række af spørgsmål til barnet, for eksempel: Hvor meget vejer du netop nu, hvor meget fylder nu netop nu, og hvad koster dine ingredienser netop nu?
>

Hierarkier kan være mange slags, så det er vigtigt at skelne, også i formuleringer. De to slags hierarkier vi har på bordet i denne diskusion er dels slægtskabshierarkier, nemlig klassifikation, og dels 'del-helhed' hierarkier. Den sidste slags er, hvad DBK's produktaspekt fokuserer på. De to slags er meget forskellige. Som nævnt i andetsteds: klassifikation er forudsætning for skabelse af objekter som så efterfølgende kan relateres til hinanden, eksempelvis i 'del-helhed' relationer.

Det jeg blot vil anholde er, at betegnelserne 'fader', 'barn' og 'arv' kan misforstås. Principielt kan de ganske vist i snæver forstand anvendes om positioner i alle hierarkier, men som oftest bruges de kun om klassifikationshierarkier. Det følger af, at 'fader' og 'barn' netop udtrykker slægtskabsrelationer og arv. Ud fra dette er det uheldigt (eller forvirrende), at du bruger disse betegnelser i de to afsnit. Det du nemlig omtaler er ikke slægtskabsrelationer og arv. Du omtaler i stedet en anden vigtig side af objektorientering, nemlig at objekter "kommunikerer" med hinanden.

Re: Re: Objekter og hierarkier

Du omtaler i stedet en anden vigtig side af objektorientering, nemlig at objekter "kommunikerer" med hinanden.

Jeg er delvist enig. "kommunikerer" som betegnelse er jeg ikke begejstret for, at nøjes med at kalde det for, selv om at dette er korrekt. Samtidig er jeg helt enig i at jeg anvender et sprogbrug som ikke stemmer med hvad programmeringssprog typisk kalder sådant for. Problemet er, at begrebsnavngivning i programmeringssprog ikke stemmer overens med vort dagligdags sprog.

Når en tegner anbringer fx en dør i tegningen, da er naturligvis relevant hver gang at vælge en objekttype der i den givne sag har en brugbar specialiseringsgrad, fx at anvende en type ved navn "terrassedør" i stedet for måske en mere generel type der måske blot er navngivet "dør". I forudprogrammeringen vil den overordnede type, "dør", typisk indeholde nogle programkoder som alle arter af døre har behov for, og som den specialiserede type, "terrassedør", kan arve (det vil sige anvende), således at forudprogrammeringen af den specialiserede "terrassedør" kun behøver at indeholde de programmeringsmæssige særheder der er nødvendigt for en sådan type. I den forstand er der programkodemæssigt tale om et arvehierarki, og sådan er det navngivet i et programmeringssprog. Reelt er der tale om genbrug ved at gøre henvisninger.

Dermed: Dette arvehierarki, at man kalder det for sådant i programmeringssprog, er temmelig forkert navngivet (min mening), fordi man indirekte med et sådant sprog siger, at et specielt barn kan arve fra et barn (~ en terrassedør kan arve fra en dør). I vort daglige sprog kommer et barn jo fra en mor, ikke fra et barn. Og samtidig: Hvad er det, som fx en terrassedør kan arve fra en almindelig generel dør? Det er kun konstanter og funktioner og metoder (at ligne med opskrifter på DNA), det vil sige ikke variabler (det vil sige ikke levende DNA), fordi faderen (den almindelige dør, som er en objekttype) ikke er et levende objekt under programkørslen, når det handler om den specialiserede dør (som under programkørsel er et konkret objekt der bliver født, og altså ikke er kun en ufødt type).

Dermed: Når man i programmeringssprog taler om arvehierarkier, da taler man om genbrug af faststøbt (kompileret) computerkode (definerede konstanter og variabler og funktioner og metoder) ved at gøre henvisninger, populært sagt: »Hvis jeg som objekt får et spørgsmål som jeg ikke forstår, da vil jeg slå op i min families bog, skrevet af en forfader, om der er en opskrift i hvordan at svare.«

Man kan populært sige, at samtlige fædre, mødre, forfædre, forbliver døde under programkørslen, det er kun forfædres opskrifter som fremkaldes. At tale om "far" og "barn" giver dermed ikke mening, fordi man normalt i dagligt sprog vil antage at faderen er i live, når barnet bliver født, at de begge lever på samme tid.

I en "levende" tegning, dvs. en bygningstegning hvor man har behov for at regne på kryds og tværs med hensyn til rumligheder, åbninger, styrke, elektricitet, vand, spildevand, trafikstrømme, og normalt gøre mange ændringer undervejs i tegningsprocessen, da giver det en slags biologisk mening at betragte indholdet som en kæde af skiftevis fædre og børn, for eksempel: »Man har en byggesag, som føder en byggegrund, som føder en bygning, som føder en etage, som føder en rumlighed, som føder en væg, som føder en dør, som føder et dørhåndtag.« Vi kender det som børnesang: På en gren, på et træ, på en bakketop, i en skov ..., en fysisk sammenhæng, forgrening, fordi et dørhåndtag ikke kan svæve selv midt i luften. Ved at betragte kæderne af forgreninger som "nedarvninger" (desværre en uheldig betegnelse i forhold til fagtermer i programmeringssprog), giver det mulighed for at lade beregninger foregå på de niveauer hvor de er beskyttet imod tegningsmæssige forandringer: Man kan flytte, ændre, slette, tilføje detaljer, uden at behøve at bekymre sig om langt de fleste andre detaljer i tegningen. I stedet for at kalde det for et arvehierarki, kan kan mere korrekt kalde det for "kommunikation", men dette ord er en temmelig upræcis beskrivelse af hvad der foregår, fordi "kommunikation" beskriver at noget foregår, uden at forklare om i hvilke særlige retninger at det foregår.