Januar 1996
V seminarju je predstavljen mednarodni standard ISO 10303, ki pripravlja pogoje za prezentacijo in izmenjavo podatkov. Prikazana so pravila, ki jih je potrebnoo upostevti pri kreiranju dokumentov, v nadaljeanju pa se del Part-205 imenovan Exchange of Sculptured Surfaces Models, ki omogoca predstavitev teles na razlicnih izvedbenih stopnjah.
1 SOLIS - Step On Line Information Service
1.1 Predstavitev
1.3 Navodila za uporabo AMS - Archive Mail Server - ja
2 Napotki za nacrtovanje in prezentacijo dokumentov ISO 10303
2.1.1 Kaj upostevamo pri oblikovanju elementov, ki so sestavni deli ISO 10303
2.1.2 Uvodni elementi
2.1.3 Splosni dolocilni elementi
2.1.4 Tehnicni dolocilni elementi
2.1.5 Dopolnilni elementi
2.2 Zahtevani formati pri pisanju dokumentov ISO 10303
2.3.1 Aneksi
2.4 Dokumentiranje aplikacij v ISO 10303
3 Izmenjava oblikovnih modelov
3.1 Vloga aplikacij pri izmenjavi oblikovnih modelov
3.2 Razdelitev na izvedbene stopnje
3.3 Oblika, topologija in geometrija
3.3.1 Oblika
3.3.2 Topologija
3.3.3 Geometrija
3.3.3.1 Elementi geometrije
3.3.4 Elementi, ki jih SS-AP ne podpira
3.4 Izvedbeni nivoji
3.4.1 Izvedbeni nivo 1
3.4.2 Izvedbeni nivo 2
3.4.3 Izvedbeni nivo 3
3.5 Primeri zapisa
3.5.1 Primeri zapisa iz naslova oblike
3.5.2 Primeri zapisa iz naslova topologije
3.5.3 Primeri zapisa iz naslova geometrije
Slika 1 - Primer tekstualnega definiranja
Slika 2 - Zahtevani elementi pri dokumentiranju aplikacij
Slika 3 - Odnosi med elementi oblike
Slika 4 - Odnosi med elementi topologije
Slika 5 - Odnosi med elementi geometrije
Slika 6 - Seznam elementov pri posamezni definiciji
Slika 7 - Osnovni elementi iz B_Spline_Surface_Form
Slika 8 - Osnovni elementi iz B_Spline_Curve_Form
Slika 9 - Koordinatni sistem
Slika 10 - Transformacija
Slika 11 - Smer in vektor
Slika 12 - Tocka v kartezijskem koordinatnem sistemu
Slika 13 - Tocka na krivulji
Slika 14 - Tocka na povrsini
Slika 15 - Opcije v IL 1
Slika 16 - Opcije v IL 2
Slika 17 - Opcije v IL 3
Tabela 1 - Ureditev elementov
ISO 10303 je mednarodni standard za racunalnisko prezentacijo
in izmenjavo podatkov o izdelkih. Namen projekta je ustvariti
nevtralen mehanizem, ki bo sposoben popisovanja podatkov o izdelku
skozi ves njegov proizvodni proces, neodvisno od sistema, v katerem
bo produkt nastajal. Narava podatkovnega zapisa bo tako omogocala
razne operacije s temi podatki in arhiviranje.
ISO 10303 je organiziran kot skup posameznih delov krovnega standarda,
ki pa se zdruzujejo v posamezne sklope glede na vsebino dela.
Vsak del standarda je v okviru krovnega standarda samostojna enota.
Vzporedno z nastajanjem proizvoda nastaja skupek podatkov o tem
proizvodu. Ti podatki se med proizvodnim procesom uporabljajo
v najrazlicnejse namene. V tem procesu lahko sodeluje
vec racunalniskih sistemov, ki so lahko postavljeni
v razlicnih organizacijah. Pri takih pogojih mora biti
zagotovljena moznost prenosa podatkov mad razlicnimi
sisteni.
Namen standarda je torej zagotoviti jasen mehanizem za predstavitev
in izmenjavo podatkov o dolocenem produktu in procesu,
v katerem ta produkt nastaja, neodvisno od sistema, v katerem
se odvija proces. ISO 10303 dovoljuje uporabo razlicnih
izvedbenih tehnologij za shranjevanje, dostop do podatkov, prenos
in arhiviranje, vendar je potrebno prilagajanje. Te izvedbene
oblike morajo biti preverjene.
Prezentacija zagotovi poenoteno definicijo informacije o produktu,
ki pa mora imeti lastnost, da se jo da prikrojiti katerikoli aplikaciji.
Standard ISO 10303 uporablja oblikovni jezik, imenovan EXPRESS,
ki omogoca prezentacijo podatkov o posameznih produktih.
Uporaba formalnega jezika omogoca natancnost in
zgoscenost predstavitve ter pospesuje hitrost
razvoja in izvedbe.
V ISO 10303 so definirane metode, ki naj se uporabljajo pri prenosu
podatkov v podporo prezentaciji le teh. Prav tako so dolocene
metodologije za preskusanje.
ISO 10303 je razdeljen v sedem glavnih skupin - serij, od katerih
ima vsaka svojo funkcijo v sistemu standarda. Vsaka skupina nadalje
vsebuje veè delov. Struktura standarda je tako:
-- Descriptions metods, Parts 11 - 19;
-- Integrated resources: Generic resources, Parts 41 - 99;
-- Integrated resources: Application resources, Parts 101 - 199;
-- Application protocols, Parts 201 - 1199;
-- Conformance testing metodology and framework, Parts 31 - 39;
-- Abstract test suites, Parts 1201 - 2199;
-- Implementation methods, Parts 21 - 29.
V nadaljevanju je predstavljen del, ki spada v skupino aplikativnih
protokolov. Ti vsebujejo definicijo podrocja, kjer so npr.
definirane funkcije, procesi ali informacije, ki jih zaradi jasnosti
dokumenta iz njega izkljucimo ter povezave in informacije
oz. zahteve. Izjave v glavnem delu dokumenta, njegovo podrocje
se lahko podpre z raznimi modeli, ki povecujejo jasnost
dokumenta. Vsaka zahteva, izrazena v glavnem delu, mora imeti
za seboj vsaj en primer, s katerim lahko izjavo oz. zahtevo testiramo,
preverimo.
Nadaljevanje je razdeljeno na tri dele:
-- V prvem delu je predstavljen postopek prakticnega dostopa
do iformacij v raèunalniski mrezi.
-- V drugem delu je predstavljen dokument, ki se imenuje "Supplementary
Directives for the Drafting and Presentation of ISO 10303".
Predsatitev je samo okvirna in ne podaja natancnih dolocil
za oblikovanje in prezentacijo, temvec nanje samo opozarja
in jih skusa povrsno predstaviti bralcu. Originalna
oblika dokumenta je prilozena v angleskem jeziku. "Supplementary
Directives for the Drafting and Presentation of ISO 10303, Version
3, September 1991". Nekateri izrazi so zaradi boljse
pomenske razumljivosti ostali neprevedeni v angleskem jeziku.
-- V tretjem delu je predstavljen del standarda, ki spada v skupino
Application protocols. To je Part 205 ali Exchange of Sculptured
Surfaces Models. Pojasnjena je njegova uporabna vloga in razvojne
smernice, ki so projekt usmerjale v smer, po kateri se danes razvija.
Predstavljeni so trije nacini, oblike, topologije in geometrije,
s pomocjo katerih se lahko lotimo opisovanja posameznega
produkta, ki sodeluje v nekem procesu. Opis lahko nadalje prilagajamo
glede na zahteve oz. potrebnost predstavitve v treh razlicnih
izvedbenih stopnjah, ki se med seboj razlikujejo po nacinu
opazovanja produkta (kot telo ali samo kot osnovno sliko, ki jo
vidimo s pogledom od spredaj itd.). Princip predstavitve je v
bistu sestavljanje posameznih osnovnih elementov, kot je npr.
tocka, s pomocjo logicnih struktur v visje
nivojske elemente in te spet naprej, v koncno obliko ali
geometrijsko strukturo, odvisno od zahtevanega. Na koncu so predstavljeni
primeru posameznih elementov in logicnih struktur, ki se
nanasajo na originalni dokument (prilozen). V originalnem
dokumentu je predstavljen glavni del dokumenta in aneks, v katerem
je podan primer za uporabo AP. Ostalih aneksov v original nisem
vkljuceval, ker so ze vkljuceni v glavnem delu.
Prevajalnika, s katerim bi lahko s pomocjo primera preveril
dejansko funkcioniranje AP, nisem imel na razpolago, zato tega
dela v nadaljevanju ni. Originalni del prav tako nima nobenih
slikovnih prikazov, tako, da so slike v nadaljevanju narisane
na osnovi dejstev, podanih v tekstovnem delu dokumenta.
V posameznih datotekah STEP On-Line Information Service (SOLIS),
so identificirani dokumenti o standardih, aplikacijah, podatki
o komercialnih produktih, itd.. Identifikacija ne vsebuje priporocila
National Institute of Standards and Technology (NIST), niti ne
vsebuje garancije, da so ti produkti najboljsi mozni
med produkti, ki so na razpolago.
Katerkoli software, pridobljen preko SOLIS-a, nima garancije in
ga je dovoljeno prosto kopirati in uporabljti. Vendar ni jamstva,
da bo ta software deloval na uporabnikovem racunalniskem
okolju, oziroma, da bo opravljal naloge, za katere je bil predviden.
Mozni so trije nacini dostopa do on - line kopij posameznih
STEP delov, SC4 in dokumentacije delovnih skupin z zapisniki ter
ostale dokumentacije: anonimen ftp, Kermit server in Email archive
server.
V njem je moc dobit razne dokumente, zapisnike, software,
dokumentacijo, ki je nastajala in nastaja vzporedno z razvojem
sistema. Ta materijal je dostopen vsem uporabnikom, ga je mogoce
prosto kopirati, vendar ni nobene garancije, da, npr. software,
deluje brezhibno. Premikanje po samem sistemu naceloma
ni tezko. Tezje pa je iskanje zeljenih datotek,
saj njihovi naslovi najveckrat ne sugerirajo njihove vsebine.
V ta namen je potrebno pregledati izpis direktorija, kjer je poleg
imena datoteke podana tudi njena velikost, datum nastanka in opis
v nekaj besedah. Obstajajo pa tudi posebne datoteke, v katerih
so izpisani nalslovi delov posameznega sklopa. V pomoc
iskalcu so oznacene datoteke, ki so starejsega datuma
in je s tem njihova aktualnost nicna. to velja predvsem
za razne zapisnike, dokumente, ki se dodelujejo in podobno. Glede
na vrsto datotek (koncnica), je razlicen tudi vpogled
v datoteko. Nekatere datoteke lahko pregledamo takoj, na primer
datoteke oblike *.txt, za vpogled v druge pa potrebujemo dodaten
software. Predvsem za te zadnje se izkaze, da predstavljajo
v vecini ze nekako dodelane dokumente, vendar spet
brez garancije, da so povsem popolne in da bodo zadovoljile odjemalceve
zelje. To so datoteke oblike *.tex in *.sty, ter druge te
vrste.
Sam sistem STEP nastaja ze dalj casa. Zdruzuje
se delo razlicnih projektnih skupin, ki dodelujejo posamezne
sklope. S tem se ustvarja neka tehnicna stabilnost dokumentov,
ki s privolitvijo drzav clanic ISO, STEP uvrsca
med standarde. Metode, ki so bile uporabljene pri nastajanju standarda
STEP, pa se ze uporabljajo pri drugih projektih standardizacije.
Navodila za uporabo ftp (file transfer protocol) nacina
za dostop na STEP On-Line Information Service (SOLIS):
-- ls-lt izpise seznam datotek glede na cas
nastanka datoteke;
-- ls a* izpise vse datoteke, ki se zacnejo
na 'a'.
Primer: get drafting.w51
mget <seznam datotek>.
Seznam datotek lahko podamo na isti nacin, kot je to prikazano
v koraku 7 zgoraj. Ce kopirate veliko stevilo datotek
in ne zelite potrjevati kopiranje vsake datoteke posebej,
preklopite na non-prompt nacin z ukazom prompt.
Opozorilo: Nekatere verzije ftp zahtevajo 'bye'.
Navodila za uporabo STEP Archiv Mail Server-ja. Prosnje posljite
na [email protected]. Vsaka prosnja mora vsebovati niz
ukazov, ki jih napisete po enega v vsako vrstico. Ce
naletite na kakrsenkoli problem, posljite e-mail na
[email protected].
Seznam veljavnih mail server ukazov:
-- HELP
Uporaba ukaza 'help' priklice seznam veljavnih
ukazov.
-- INDEX [<item>]
Uporaba ukaza 'index' priklice glavni izpis direktorijev.
Uporaba ukaza 'index <dname>' priklice izpis
datotek specificnega direktorija.
Primer: 'index part11'
Uporab ukaza 'index all' priklice izpis
datotek vseh direktorijev.
-- SEND <item> [<item>...]
Uporaba ukaza 'send step/<dname>' prekopira vse
datoteke direktorija na vaso pozicijo.
Primer: 'send step/part11'
Opozorilo: Bodite pozorni na prostor, ki ga lahko zasede v celoti
prekopiran direktorij.)
Uporaba ukaza 'send step/<dname>/<filename>'
omogoca kopiranje dolocene datoteke.
Primer: 'send step/part11/iso.sty'
-- MCI
-- UUENCODE
-- BTOA
Ti trije formati prekodirajo iz binarnega zapisa v ascii tekst,
primeren za prenos. Pri *.txt datotekah
prekodiranje ni potrbno. Posebno je potrebno omeniti prekodiranje
v povezavi z ukazom 'send', kjer bi bila ne uporaba le tega nepravilna.
Primer: Ce uporabljate MCI mail in potrebujete binarni
dokument, imenovan foo,
uporabite na step direktoriju naslednji "mail message".
mci
send step/foo
Posledica je, da bo poslan dokument prekodiran v ustrezen MCI
nacin.
-- LIMIT <number>
Najvecje stevilo bytov, ki bodo poslani po racunalmiski
posti. Ukaz 'limit' se povezuje zukazom 'send'.
-- RESEND <item> <part> [<part>...]
Poslje zeljene <parts> iz dolocenega <item>.
Format in limit morata biti identicna kot v originalni
prosnji 'send'.
-- PATH <path>
Opise povratno pot. Ta ukaz se uporablja, kadar nismo sigurni,
ce nam bo "mail system" pravilno
generiral povratni naslov.
-- END
-- EXIT
V sistemu SOLIS se uporabljajo datoteke naslednjih tipov:
-- *.c1x ChartX datoteka;
-- *.com Izvrsilen sistemski ukaz;
-- *.dir ASCII tekstovna datoteka, ki izpise seznam datotek
na direktoriju;
-- *.dvi 'Device-Independent' datoteka (narejena v TeX);
-- *.exe Datoteka, ki se odkomprimira, ko je izvrsena na
DOS-u;
-- *.mac Datoteka, narejena s katerokoli Macintosh aplikacijo;
-- *.pak Datoteka, ki je bila komprimirana s 'pak' programom;
-- *.ps PostScript;
-- *.tex LaTeX datoteka, ASCII format;
-- *.sty LaTeX 'style' datoteka, ASCII format;
-- *.trz Komprimirana 'tar' datoteka;
-- *.txt ASCII tekstovna datoteka;
-- *.w42 WorldPerfect Version4.2;
-- *.w50 WorldPerfect Version 5.0;
-- *.w51 WorldPerfect Version 5.1.
Dokument v obliki napotkov podaja zahteve, s pomocjo katerih
bi se poenotila oblika vseh dokumentov v ISO 10303 (International
Organization for Standardization), z namenom enotne prezentacije
in moznosti zamenjave.
Dokument je sestavljen iz petih glavnih delov, od katerih opisujejo:
-- prvi sestavne elemente ISO 10303;
-- drugi zahtevane formate teh elementov;
-- tretji ustvarjanje pomoznih shem;
-- cetrti uporabniske protokole;
-- peti pisanje v obliki EXPRESS.
Z upostevanjem teh pravil pri pisanju dokumentov, ki so del
standarda ISO 10303, bi bilo dosezeno poenotenje strukture,
stila in terminologije ne samo v okviru tega standarda, temvec
v celi seriji leteh.
Standard je sestavljen iz uvodnih, dolocilnih in dopolnilnih
elementov.
Dokument predstavimo z naslovno stranjo, ki jo oblikuje vsak pisec
dokumenta sam, vendar za dokoncno obliko naslovne strani
poskrbi 'ISO Central Secretariat'. Vsak dokument mora biti opremljen
s kazalom in seznamom slik in tabel, od katerih vsakega pisemo
na svojo stran. Vsak dokument mora imeti uvodno besedo. Ta je
obvezna, medtem ko so posamezni deli uvodne besede poljubni. Predvidana
so besedila, ki naj se v uvodni besedi uporabljajo. To je samo
okvirno besedilo, saj mora pisec dokumenta v ta okvir vnesti podatke,
ki so specificni za doticni dokument. Priporoceno
je tudi vkljucevanje besedila, ki omenja sponzorje oz.
podpornike (samo mednarodne), ki so pri projektu sodelovali ali
ga gmotno podprli.
Kadar nek dokument ponovno izdajamo, je to potrebno natancno
oznaciti. Omeniti je potrebno tudi povezave s katerimikoli
drugimi enotami standarda.
Uvod zakljucimo z besedilom, ki doticni dokument
poveze z ostalimi, spodaj nastetimi dokumenti, v vecji
sklop, ki obravnava neko doloceno podrocje. Koncno
obliko uvodne besede doloci 'ISO Central Secretariat'.
Predstavitve posameznih dokumentov so potrebne. Dolocena
so celo besedila, s katerimi predstavimo dokumente standarda oziroma
dele 4x in 1xx, aplikacije in druge dele standarda ISO 10303.
Vsak dokument je potrebno nasloviti. To naredimo z dvodelnim naslovom,
ki dokument pripise vecji skupini, ki obdeluje isto
tematiko, ter opredeli vsebino tega standarda v tej vecji
skupini. Opredeliti je potrebno tudi podrocje oziroma povezave
in specifikacije. Pri imenovanju standarda ISO zahteva, da se
uporablja izraz "Mednarodni Standard".
Za boljse razumevanje dokumenta, temu prilozimo seznam
definicij, ki morajo natancno razloziti pomen nerazumljivih
strokovnih izrazov, ter seznam kratic in simbolov. Ponavadi vse
te tri elemente zdruzimo v enega. Med tehnicne dolocilne
elemente stejejo tudi dolocilni aneksi, ki morajo
biti nedvoumno oznaceni in postavljeni za glavni del dokumenta
in pred informativne anekse.
Med dopolnilne elemente stejeo informativni aneksi, v katerih
se podajo dodatne informacije o temi, ki jo dokument obravnava.
Postavljeni so za dolocilnimi aneksi. Narava informativnih
aneksov mora biti nedvoumno dolocena, tako po naslovu,
kot po vsebini. Razumljivost dokumenta se lahko poveca
z dodajanjem opomb, preglednost pa se poveca z razdeljevanjem
snovi na poglavja in podpoglavja, ter dalje na posamezne odstavke
, ki pa jih ne stevilcimo. V dokumentu opisana dejstva
se lahko se najbolj nazorno prikaze s pomocjo
primerov.
V napotitvah za nacrtovanje in prezentacijo dokumentov
ISO10303 so natancno predpisani formati, ki naj se uporabljajo.
Za kazalo je npr. predpisano, da mora biti med naslovom 'Kazalo'
in kazalom prazna vrstica, da morajo biti naslovi na levi poravnani,
prav tako stevilke na desni strani (povezava s pikami). Nadalje
se natancno dolocajo postavitve glavnih naslovov
in naslovov poglavij in podpoglavij ter stevilo praznih vrstic
med njimi in tekstom. V bistvu gre tu za naslavljanje na razlicnih
nivojih. Vzporedno z naslavljanjem je predpisano tudi ostevilcenje
naslovov, aneksov in strani (ostevilcimo jih v spodnjem
zunanjem kotu strani). Uporabljajo se arabske stevilke, zacensi
z ena.
Nadalje je predpisana uporaba velikih crk v naslovih in
v tekstu, poravnavanje besedila na levi in na desni strani, razmiki
med vrsticami, itd..
Tabele je potrebno postaviti takoj za tekst, ki se nanasa
na podatke v njih, ce se le da, na isto stran. Ce
smo primorani tabelo postaviti na sredino strani, jo od teksta
locimo s tremi praznimi vrsticami. Tekstovnih poglavij
ali podpoglavij se s tabelo ne sme razbiti. Predpisana je oblika
ostevilcenja in naslavljanja tabel (uporaba velikih
crk v naslovu tabel). Tabelo je dovoljeno deliti, tako
da jo prikazemo na dveh ali vecih straneh. Pravila,
ki jih je potrebno upostevati pri oblikovanju, ostevilcenju,
postavljanju v tekst in naslavljanju slik, so zelo podobna pravilom
za oblikovanje tabel.
Obicajne so povezave dokumenta z nekim drugim (drugimi)
dokumentom. Povezave oz. napotitve je potrebno omeniti s predpisanimi
besednimi zvezami (tudi ce se sklicujemo na nek drug standard).
Nadalje je predpisana oblika raznih dopolnilnih elementov, kot
so opombe, primeri, itd.. Pri nastevanju je potrebno nastevanje
najprej nasloviti, potem pa pisati tocke vsako v svojo
vrsto.
Za izrazanje zahtev ali priporocil, so namesto raznih
moznih besednih zvez, nekatere natancno predpisane.
Tako se predpisuje uporaba naslednjih besednih zvez (v anglescini,
ki je edini dovoljeni jezik v mednarodni uporabi dokumentov ISO
10303):
-- "shall";
-- "shall not";
-- "should";
-- "should not";
-- "may";
-- "need not";
-- "can";
-- "cannot".
Na koncu je predpisana se vrsta pisave, ki se jo sme uporabljati
in njena velikost ter slovarji, iz katerih naj se crpajo
pravopisnia pravila.
Dokument je sestavljen iz glavne sheme, v kateri je opisan glavni
problem oz. tema, ki jo dokument obravnava in pomozne sheme,
ki glavni shemi dodajo razne pomozne in dodatne informacije.
Tako se lahko zgodi, da se deli pomoznih shem ujemajo s tistimi,
ki to niso. V takih primerih je potrebno nakazati odnos med njimi.
V predstavitvenem delu dokumenta se posvetimo predvsem tehnicni
dovrsenosti standarda. V nadaljevanju sledi dokumentacija
o doloceni temi. Tu se povdarjajo predvsem aplikativna
podrocja in razlage o tehnicnih omejitvah. Uporabljata
se primarni in sekundarni oznacitveni mehanizem. Prvi je
v obliki pripovednega teksta in opisuje razna pravila, omejitve
in dogovore, ki dolocajo, kaj naj bi se v dele standarda
vkljucilo in kaj ne. Pri drugem mehanizmu pa se uporabljajo
aktivni modeli, opisi stalisc, relacije do drugih
modelov in aplikacij, kjer se informacije lahko koristi.
Struktura poglavja zahtev naj bi bila:
x <ime sheme>
x.1 Predstavite
x.2 Temeljna zamisel in predpostavke
x.3 <Ime sheme> definicije: <Ime funkcionalne skupine>
:
:
Sledijo se definicije tipa, pravil, funkcij ter na koncu
x.n <Ime sheme> Razporeditvena struktura.
Enotno interpretacijo oz. branje dokumentov omogoca pisanje
v obliki EXPRESS. Iz te oblike prevajalnik prevede dokument v
enotno berljivo (zgoraj omenjene oblikovne zahteve) obliko. Berljivost
in razumljivost se lahko poveca s funkcionalnim grupiranjem,
ki pa ni nujno. Pri tem je pomembna ureditev, ki med drugimi
dopusca hierarhicen odnos med deli. Ce
ni predpisano drugace, se uporablja preprosta alfanumericna
ureditev.
Pri dokumentiranju sheme se je potrebno drzati predpisanih
pravil. Nekatera so:
-- potrebna je natancno predpisana predstavitev sheme;
-- deklaracija sheme z vsemi smernicami
*)
SCHEMA <schema_1 name>;
REFERENCE FROM <schema_2 name>
(<e1 name, e2 name>);
(* ;
-- razne opombe...
Shemo je potrebno natancno predstaviti (ponavadi je predstavljena
ze v uvodnih dokumentih, vendar mora biti predstavitev tu
poglobljena). Na tem mestu se ponavadi predstavijo perspektive
in opisi glavnih komponent.
Pri predstavitvi se pretezno uporablja tekst, vendar je slikovna
predstavitev zaradi nazornosti boljsa, bolj zazeljena.
V tem primeru naj bo ta spisana v obliki EXPRESS.
Temeljne zamisli in predpostavke so bistvo dokumenta, ki predstavijo
avtorjeve zamisli in moznosti razvoja in so pomembne pri
razumevanju dokumenta. Zapisane so lahko v tekstovni obliki ali
pa v bolj strukturirani, z nastevanjem in krajsimi opisi.
Pri opisu glavnih zahtev, se je prav tako potrebno drzati
pravil. Z upostevanjem teh ima tekstovno definiranje obliko,
kot je prikazano na sliki 1.
Slika 1 - Primer tekstualnega definiranja
Formalni predlogi morajo biti napisani v obliki EXPRESS in uporabljeni
samo v primeru, ko je vrednotenje odvisno od vrednosti atributov.
PRIMER:
UR1: Ime naj bo edinstveno.
WR1: Vrednost naj bo pozitivna.
Neformalni predlogi naceloma niso napisani v obliki EXPRESS,
vendar kljub temu obstajajo pravila o obliki. Tudi neformalne
predloge je moc razumeti kot zahteve.
Tudi za popisovanje funkcij in postopkov v obliki EXPRESS, veljajo
dolocena pravila.
Funkcija, pravilno opisana v obliki EXPRESS.
PRIMER
1 Funkcija oz. pravilo je v podpoglavju:
*)
FUNCTION function_name (x: INTEGER) : LOGICAL;
<function body in EXPRESS>
END_FUNCTION;
(*
PRIMER
2 Funkcija oz. pravilo je v glavnem delu dokumenta, njegovem
bistvu:
*)
ENTITY ....
....
WHERE
WR1: function_name (...) ;
END_ENTITY;
(*
..........
Formal proposition:
WR1: _ _ _
Funkcije, ki ne delujejo v obliki EXPRESS, vendar za njih potrebujemo
posebne aplikacije.
PRIMER
3 Funkcija oz. pravilo je v podpoglavju:
*)
FUNCTION function_name (x: INTEGER) : LOGICAL;
(* <text which explains what the function is supposed to do.
Note that the text is commented out between the function head
and tail.> *)
END_FUNCTION;
(*
PRIMER
4 Funkcija oz. pravilo je v glavnem delu dokumenta, njegovo bistvo:
*)
ENTITY ....
....
WHERE
WR1: function_name (...);
....
END_ENTITY;
(*
..........
Formal propositions:
WR1: function_name (...);
....
Funkcije, ki so neizvedljive.
PRIMER
*)
ENTITY ....
....
WHERE
....
END_ENTITY;
(*
..........
Informal proposition:
<constraint name or title>
<constraint explanation> .....
Vsako shemo zakljucimo z zakljucno deklaracijo.
*)
END_SCHEMA; - - <schema_name>
(*
Aneksi so del dokumenta, ki so predstavljeni cisto na koncu.
Njihova naloga je poglabljanje glavne teme oz. dodajanje informacij,
ki so z glavnim dokumentom povezane, niso pa omenjene v glavnem
delu dokumenta. Oznacujemo jih z velikimi crkami.
Aneksa A in B sta dolocilna aneksa. Prvega naslovimo z
"Annex A-EXPRESS source listing", drugega pa z "Annex
B-Entity and type abbreviations".
Aneks C je bibliografija, kjer se opisejo vsi dokumenti,
ki so bili uporabljeni pri nastajanju sestavnega dela ISO 10303.
Aneks D je predstavitev tehnicnih razprav, ki so nastajale
med razvojem standarda. Pripomore predvsem k boljsemu razumevanju
namena in vsebine dokumenta.
Aneks E je naslovljen kot "Annex E-Model Scope" in je
poljuben. Tu se skusa dejstva, omenjena v dokumentu, prikazati
z modeli, slikami in preglednicami. Posamezne elemente se skusa
predstaviti v globalnem, kasneje uporabnem okolju.
V aneksu F so predstavljeni primeri. Primerov ne dajemo v jedro
dokumenta, ker bi ga to precej povecalo. Z njimi skusamo
plasticno predstaviti elemente oz. dejstva, ki jih dokument
standarda obdeluje.
V aneksu G so predstavljeni modeli, ki so spisani v drugih graficnih
jezikih, kot sta IDEFIX in NIAM. Iz teh dveh oblik se prevede
v EXPRESS obliko in model, najveckrat sliko, predstavi
v aneksu G.
Aplikacije so v standardu ISO 10303 predstavljene posebej. Za
le te veljajo v vecini ista pravila, kot so opisana zgoraj,
le nekatera so specificna za aplikacije. Informacije o
aplikacijah in njihovem razvoju je moc dobiti pod uradnim
naslovom "Guidelines for the Development and Approval of
STEP Application Protocols." Zahtevani dolocilni elementi
pri dokumentiranju aplikacij so prikazani na sliki 2. Uvod
1. SOLIS - Step On Line Information Service
1.1 Predstavitev
1.2 Navodila za uporabo ftp
1.3 Navodila za uporabo AMS - Archive Mail Server-ja
2 Napotki za nacrtovanje in prezentacijo dokumentov
ISO 10303
2.1 Sestavni elementi ISO 10303
2.1.1 Kaj upostevamo pri oblikovanju el., ki so sestavni
deli dokumentov ISO 10303
2.1.2 Uvodni elementi
2.1.3 Splosni dolocilni elementi
2.1.4 Tehnicni dolocilni elementi
2.1.5 Dopolnilni elementi
2.2 Zahtevani formati pri pisanju dokumentov ISO 10303
2.3 Dokumentacija ISO 10303
x . x . x <ENTITY NAME>
_ _ _<entity definition>_ _ _
EXPRESS specification:
*)
ENTITY ; _ _ _ _ _ _
a : INTEGER;
b: REAL;
UNIQUE
UR1: a, b;
WHERE
WR1: f (a, b);
END ENTITY;
(*
Attribute definitions:
<attribute1 name>: _ _ _ _ _ _ _
<attribute2 name>: _ _ _ _ _ _ _
Formal propositions:
UR1: _ _ _ _ _ _
WR1: _ _ _ _ _ _
Informal propositions:
<proposition 1>: _ _ _ _ _
2.3.1 Aneksi
2.4 Dokumentiranje aplikacij v ISO 10303
Foreword Introduction 1 Scope 2 Normative references 3 Definitions 4 Information requirements 4.1 Construct definitions; 4.2 Construct assertions 5 Application interpreted model 5.1 ARM to AIM mapping; 5.2 AIM EXPRESS short form 6 Conformance requirements and test purposes 6.1 Conformance requirements; 6.2 Test group structure; 6.3 Conformance test purposes Annex A AIM EXPRESS long form (required and normative) Annex B PICS (Protocol Implementation Conformance Statament) proforma (required and normative) Annex C Implementation specific requirements (required and normative) Annex D Application activity model (required and normative) D.1 AAM definitions; D.2 AAM diagrams Annex E Application reference model (required and normative) E.1 Units of functionality: E.1.1 UOF definitions; E.1.2 UOF and ARM correspondence; E.2 ARM diagrams Annex F AIM EXPRESS-G (required and normative) Annex G Application protocol usage guide (optional and informative) Annex H Tehnical discussions (optional and informative) Annex J Bibliography (optional and informative)
Slika 2 - Zahtevani elementi pri dokumentiranju aplikacij
Pri dokumentiranju nekega podrocja. moramo zaradi usklajevanja, dokumentu dodati opis nekaterih pomembnejsih katakteristik:
-- Type of product;
-- Typed of product data;
-- Supported stages in the life cycle of the product;
-- Supported application uses of the product data;
-- Discipline views of the product that are acommodated;
-- Exclusions from scope;
-- Associations with other APs.
Pri dokumentiranju aplikacij moramo ravno tako poskrbeti za definicije, zahteve (formalne in neformalne), itd., kot je to omenjeno v prejsnjih poglavjih. Dodano je podpoglavje, ki definira zgradbo aplikacije. Pri prikazu zgradbe aplikacije se je potrebno drzati predpisanih pravil.
Pri aplikacijah imajo pomembno vlogo razlicni modeli. Aplikativno Interpretiran Model (AIM) je npr. zapis v obliki EXPRESS, ki vzporedno z glavno shemo dokumenta pomaga pri razumevanju aplikacije. Ustreznost oz. skladnost med AIM in ARM, ki je tudi ena izmed oblik modela, je potrebno podati na predpisan nacin.
AIM model lahko interpretiramo v kratki ali dolgi obliki. Interpretacija v kratki obliki izgleda:
USE FROM a_resource_schema (an_entity );
ENTITY aim_entity
SUBTYPE OF (an_entity );
- - maybe some additional attributes
WHERE
- - some constraints
END_ENTITY
(* definitions and propositions appropriate to this "new" entity *)
Dolgo obliko AIM modela prikazemo v aneksu A (za aplikacije).
Aplikacijam dodamo tudi poglavje, katerega namen je prilagajanje in testiranje aplikacij na doloceni stopnji njenega razvoja oziroma dopolnjevanja.
Pri aplikacijah anekse oznacujemo:
-- A AIM EXPRESS long form (required and normative);
-- B PICS (Protocol Implementation Conformance Statement proforma
(required and normative);
-- C Implementation specific requirements (optional, but normative if appears);
-- D Application activity model (required and normative);
-- E Application reference model (required and normative);
-- F AIM EXPRESS-G (required and normative);
-- G Application protocol usage guide (optional and informative);
-- H Tehnical discussions (optional and informative);
-- J Bibliography (optional and informative).
Dolocilni aneksi so A, B in C, ki je neobvezen, a dolocilen, ce se pojavi. V aneksu A je predstavljena prej omenjena dolga oblika modela AIM, ki pa temelji na njeni krajsi inacici. Napisana je v obliki EXPRESS, pri cemer se dovoljuje pisanje opomb, ki niso pisane v tej obliki. V aneksu B se poda vse funkcije, elemente, procedure, parametre, opcije in druge sposobnosti aplikacije. Vse aplikacije morajo imeti anekse D, E in F, ki so informativni, aneksi G, H in J so prav tako informativni, vendar neobvezni.
EXPRESS je oblika pisanja dokumentov. Ko tako napisan dokument spustimo skozi prevajalnik, dobimo koncno, enotno obliko dokumentov, slik, itd.. Pri pisanju v tej obliki veljajo nekatera pravila. Pri pisanju shem moramo v dokument vkljuciti naslednje elemente, ki pa so med seboj popolnoma enakovredni:
-- uporaba napotitvenih izjav;
-- deklaracija bistev;
-- deklaracija tipov;
-- pravila;
-- funkcije in procedure.
Deklaracije, ki jih locujemo med seboj s prazno vrstico, so sestavljene iz:
-- sheme;
-- uporabe;
-- napotitev;
-- konstant;
-- bistva;
-- tipa;
-- pravila;
-- funkcije;
-- procedure.
Vse deklaracije, ki so pisane v obliki EXPRESS, locimo od ostalih delov dokumenta z oznako " *) " na zacetku in " (* " na koncu.
Nacrt sheme predstavimo:
SCHEMA . . . . ;
TYPE . . .
ENTITY . . . . ;
END_SCHEMA;
Pri predstavitvi zvez oz. odnosov uporabimo enega od naslednjih dveh nacinov:
USE FROM s-name
(e1 AS s1,
e2 AS s2);
ali
REFERENCE FROM s-name
(e1 AS s1,
e2 AS s2);
Konstante predstavimo:
CONSTANT
name1 : NUMBER := 1000;
name21 : NUMBER := name1**2;
END_CONSTANT;
Tipski nacrt lahko predstavimo na tri nacine:
TYPE name = SET OF ent;
END_TYPE;
ali
TYPE name = SELECT
(ent1,
ent2);
END_TYPE;
ali
TYPE name = ENUMERATION OF
(enum1,
enum2);
END_TYPE;
Nacrt algoritma predstavimo:
PROCEDURE procedure_name (parameter_list);
LOCAL
local declarations
END_LOCAL
-- explains following section
code body
-- explains following section
code body
END_PROCEDURE;
Parametre predstavimo na nacine:
FUNCTION func_name (a, b, c: INTEGER;
d, e, f: REAL;
x, y, z: AGGREGATE OF point) : REAL;
PROCEDURE proc_name (a, b, c: INTEGER;
d, e, f: REAL;
VAR x, y, z: AGGREGATE OF point);
Spremenljivke predstavimo na nacin:
LOCAL
i, j, k: INTEGER;
END_LOCAL;
Glabno telo, v katerem so predstavljeni odnosi med posameznimi elementi izgleda:
IF cond THEN
statement;
ELSE
statement;
END_IF;
REPEAT . . . ;
statement;
. . .
END_REPEAT;
CASE . . . ;
label : statement;
label :
BEGIN
statement;
statement;
. . .
END;
END_CASE;
BEGIN;
statement;
. . .
END;
Pri pisanju v EXPRESS moramo posamezne elemente poimenovati, najveckrat funkcije. Tu se drzimo pravila, da naj bo ime cim bolj sugestivno, vendar brez odvecnih besed (predlogov, veznikov).
Aplikacija za izmenjavo oblikovnih modelov je predstavljena v sestavnem delu 205 standarda ISO 10303 (STEP Part 205 - Exchange of Sculptured Surface Models). Koncept te aplikacije je bil predstavljen leta 1989 v Frankfurtu kot mozno orodje pri koristni uporabi STEP-a (STEP - mednarodni standard za izmenjavo podatkov). Projekt CADEX je sploh eden prvih, ki se ukvarja z aplikacijami, ki bi se lahko uporabile v okviru projekta STEP. Vse verzije so v glavnem se v uvodni, pripravljalni fazi.
Pri razvoju aplikacij bi se stvaritelji lahko opirali na vac razvojnih smernic. Razvoj bi lahko temeljil na informacijah, ki so specificne za posamezne produkte (npr. avtomobilske karoserije) ali na informacijah, ki so specificne za posamezne proizvodnje procese. Odlocili so se za princip, ki ga uporablja CAD modeliranje.V prvem obdobju razvoja bodo aplikacije dovoljevale le prenos podatkov o mrezah, povrsinah itd., kasneje pa bi bile lahko postale osnova pri dolocenih proizvodih in proizvodnih procesih. Po tem je pokazala potrebo prav analiza razvoja karoserij in njihovih oblik. Vzporedno se je pokazla potreba po delitvi na geometrijo in topologijo, kar omogoca bolj natancen pristop na podrocjih kot so oblikovanje karoserij, raznih analizah oblik in podobno.
Topolosko gledano se ponujajo tri moznosti, razdeljene v tri izvedbene nivoje ali IL - Implementation Level:
-- IL 1, podatki brez topoloskih informacij;
-- IL 2, podatki, ki opredeljujejo pogled od spredaj;
-- IL 3, podatki, ki opredeljujejo topologijo na osnovi skoljke oz. lupine.
Celovitost prikaza in analize objektov je mozna s pogledom iz razlicnih zornih kotov. Oblike, topologije in geometrije:
-- ipim_nominal_topology_schema;
-- ipim_topology_schema;
-- ipim_geometry_schema,
pri cemer ipim pomeni Integrated Product Information Model.
Pri obravnavanju oblike si lahko pomagamo z naslednjimi elementi, ki so med seboj soodvisni oz. povezani v hierarhicno drevesno strukturo (Slika 1):
-- Surface-Model;
-- Shell-Based-Surface-Model;
-- Face-Based-Surface-Model;
-- Geometric-Set;
-- Geometric-3D-Surface-Set.
Slika 3 - Odnos med elementi oblike
Z elementi Shell-Based-Surface-Model, Face-Based-Surface-Model in Geometric-3D-Surface-Set prikazemo osnovne elemente oblikovnega prikaza. To je prikaz na osnovnem, najnizjem nivoju. Sledi zdruzevanje s katerim dobimo prikaza na visjem nivoju, to sta Surface_Model in Geometric_Set. Zadnja, najvisja opcija, ki jo dobimo z zdruzitvijo S_M in G_S je oblikovni model oziroma Shape_Model
Pri obravnavanju topologije si pomagamo z naslednjimi elementi, ki so med seboj hierarhicno soodvisni (Slika 4) in logicnimi strukturami:
-- Shell;
-- Open-Shell;
-- Connected-Face-Set;
-- Face;
-- Loop;
-- Edge-Loop;
-- Vertex-Loop;
-- Edge;
-- Vertex;
-- Shell-Logical-Structure;
-- Edge-Logical-Srtucture;
-- Curve-Logical-Structure;
-- Face-Logical-Structure;
-- Surface-Logical-Structure;
-- Loop-Logical-Srtucture.
Slika 4 - Odnos med elementi topologije
Topologijo nekega predmeta predstavimo z elementi edge, loop, shell, conected_face_set in vertex. Elementa loop in shell prikazemo s podelementi, vertex_loop in edge_loop za prvega in open_shell za drugega. Pri oblikovanju si pomagamo z logicnimi strukturami za shell, face, surface, loop, edge in curve.
Geometrijo predmeta oblikujemo z naslednjimi hierarhicno soodvisnimi elementi:
-- Surface;
-- Bounded-Surface;
-- B-Spline-Surface;
-- Curve;
-- Bounded-Curve;
-- B-Spline-Curve;
-- Curve-On-Surface;
-- Pcurve;
-- Surface-Curve;
-- Intersection-Curve;
-- Point;
-- Cartesian-Point;
-- Point-On-Curve;
-- Point-On-Surface;
-- Vector;
-- Direction;
-- Transformation;
Slika 5 - Odnos med elementi geometrije
Pri poglavju o geometriji so podane tudi definicije, ki se lahko koristno uporabijo pri SS-AP (Sculptured Surfaces Applocation Protocol). To so:
-- Type definitions utilized in the SS - AP geometry subset;
-- Enumeration-Curve1-Pcurves1;
-- Bspline-Curve-Form;
-- Bspline-Surface-Form;
-- Intersection-Enumeration;
Slika 6 - Seznam elementov pri posamezni definiciji
Slika 6 prikazuje tipe definicij, ki se uporabljajao v podpoglavju Geometrija. Tu so prikazane osnovne oblike ploskev, linij, krivulj in njihovih kombinacij.
Slika 7 - Osnovni elementi iz Bspline_Surface_Form
S kombinacijo osnovnih elementov iz naslova Bspline_Surface_Form lahko oblikujemo poljubno zeljeno povrsino. Na sliki so prikazane le osnovne povrsine:
-- ravna;
-- cilindricna;
-- konicna;
-- sfericna.
Poleg teh so mozne se npr. toroidna povrsina, kvadratasta itd...
Slika 8 - Osnovni elementi iz Bspline_Curve_Form
Slika 8 prikazuje nekaj osnovnjih linij, s kombinacijo katerih lahko predstavimo poljubno zeljeno linijo oz. konturo.
Z zdruzevanjem elementov pod naslovom geometrija, dosezemo predstavitev geometrije nekega predmeta oz. telesa. V nadaljevanju je prikazanih nekaj elementov iz podpoglavja geometrija.
Koordinatni sistem je element, s pomocjo katerega natancno dolocimo lego tocke, krivulje ali kakega drugega elementa v ravnini ali prostoru. Koordinatni sistem je naceloma poljuben in ni nujno, da je kartezijev pravokotni koordinatni sistem, kot je to prikazano na sliki. Pri koordinatnem sistemu je pomembno definiranje osnovne enote oz. "en.", kot je to ozanceno na sliki 9.
Slika 9 - Koordinatni sistem
Transformacija je element, s pomocjo katerega preslikamo nek objekt - tocko iz prvotnega koordinatnega sistema (1, 2, 3) preko transformacije u1, u2, u3 v OBJ'. Transformacija je prikazana z ortogonalnimi komponentami zaradi boljse preglednosti.
Slika 10 - Transformacija
Smer oziroma "Direction" je podopcija vektorja. Smer je podana s premico, ki povezuje izhodisce koordinatnega sistema z neko tocko, ki je podana s T(x, y, [z]). Ko smeri pripisemo neko dolzino, velikost, dobimo vektor, ki ima poleg smeri tudi velikost. Glede na dvodimenzionalen oz. trodimenzionalen prostor, ga dolocata dve oz. tri koordinate.
Slika 11 -Smer in vektor
Tocko lahko predstavimo na tri nacine. Pri prvem jo predstavimo kot tocko v kartezijevem koordinatnem sistemu. Glede na dimenzijo prostora jo predstavimo z dvema ali tremi realnimi vrednostimi.
Slika 12 - Tocka v kartezijskem koordinatnem sistemu
Tocka na krivulji je drugi nacin dolocitve tocke. Dolocimo jo z enim parametrom pp ali point_parameter. Poznati moramo osnovno krivuljo, za parameter pa velja odnos:
{parametric_lower_limit (bassis_curve) < point_parameter <
parametric_upper_limit (basis_curve)}
Slika 13 - Tocka na krivulji
Tocka na povrsini ali point_on_surface je tretji nacin dolocitve tocke. Dolocena je z dvema koordinatama oz. dvema parametroma. To sta pp1 in pp2 (point_paarameter). Parametra pp1 in pp2 zavzemata vrednost med zgornjo in spodnjo vrednostjo parametra ena ali dva. Velja odnos:
{parametric_lower_limit (bassis_surface) [1] < point_parameter_1 <
parametric_upper_limit (basis_surface) [1] }
Podoben odnos lahko pripisemo tudi parametru pp2. Slika 14 - Tocka na povrsini
V poglavju Geometrija sta predstavljeni se opciji krivulja in povrsina ter njune kombinacije.
Pri oblikovanju podatkov obstajajo tudi omejitve. So elementi, ki jih za razliko od zgoraj navedenih, SS-AP (Sculptured Surfaces Application Protocol) ne podpira. Ti elementi so:
-- Podopciji od Shape_Model (solid_model in wireframe_model);
-- Podopcije od Geometric_Set (geometric_2d_set, geometric_projective_set in
geometric_3d_curve_set);
-- Podopcije od Topology (path, subface, connected_edge_set in region);
-- Podopcije od Shell (vertex_shell, wire_shell in closed_shell);
-- Podopcija od Loop (poly_loop)
-- Podopcija od Geometry (axis_placement);
-- Podopcije od Bounded_Surface (rectangular_trimmed_surface, curve_bounded_surface in
rectangular_composite_surface);
-- Podopcije od Curve (line, conic_curve in offset_curve);
-- Podopcije od Bounded_Curve (poly_line, trimmed_curve in composite_curve);
-- Podopcija od Curve_On_Surface (composite_curve_on_surface);
-- Podopcije od Vector (vector_with_magnitude, default_x_axis, default_y_axis in
default_z_axis)
Prvi izvedbeni nivo pokrije osnovne potrebe pri prenosu in predstavitvi
podatkov. Na tem nivoju je mozen prenos oblikovanih krivulj
in povrsin skupaj s kartezijskimi tockami ali nizom
teh. Vecinoma opcij, ki se uporabljajo pri IL 1 je predstavljeno
pod naslovom Geometrija. Vse oblike krivulj in povrsin so
predstavljene pod naslovi b_spline_curve in b_spline_surface.
Tocke v kartezijevem koordinatnem sistemu so predstavljene
pod opcijo cartesian_point. Niz tock predstavimo s pomocjo
opcije cartesian_point in geometric_3d_surface_set.
Slika 15 - Opcije v IL 1 (oblika in geometrija)
IL 2 se posveca urejevanju, grupiranju in topologiji.Pri
tem se uporabljajo naslednje opcije:
Slika 16 - Opcije v IL 2 (oblika in topologija)
Pod naslovom Geometrija se pri IL 2 uporabljajo vse opcije, kot so prikazane na sliki 5.
Kot je razvidno s slik, je IL 2 razsirjena IL 1 po topoloski in geometrijski plati. Pomembno pa je, da geometrijske opcije (point_on_curve, point_on_surface in curve_on_surface), niso nujno potrebne za modeliranje face_based_surface_models. Te vsebujejo topoloske lastnosti, ki jih lahko oblikujemo z drugimi topoloskimi opcijami. Smotrnost vkljucevanja nujno nepotrebnih opcij v sistem je predvsem dolgorocna. Izkaze se, da je precej operacij bolj ucinkovito izvrsljivih v parameterski obliki, kot v 3d prostoru. Pri tem je potrebno upostevati tudi dejstvo, da razlicni sistemi razlicno podajajo podatke. STEP pa mora tu poskrbeti za univerzalnost ob cim manj moznih pretvorbah.
IL 3 je naslednja razvojna stopnja, ki omogoca prezentacijo
in izmenjavo trdnih teles.
Slika 17 - Opcije v IL 3 (oblika in topologija)
Pod naslovom Geometrija se pri IL 3 uporabljajo vse opcije, kot so prikazane na sliki 3.
-- Shell_Based_Surface_Model
shell_based_surface_model_occurrence = ENTITY_NAME "="
"SHELL_BASED_SURFACE_MODEL" [sb_sm_scope_section]
"(" reference_list ")" ";" .
#500 = Shell_Based_Surface_Model((#490));
Zadnji primer predstavlja dejansko obliko podatka. Kazalec #490 se nanasa na opcijo iz topologije, Shell_Logical_Structure, ki je pod to stevilko tudi dolocena. (Glej original dokumenta Part 205)
-- Face_based_Surface_Model;
face_based_surface_model_occurrence = ENTITY_NAME "="
"FACE_BASED_SURFACE_MODEL" [fb_sm_scope_section]
"(" reference_list ")" ";" .
#380 = Face_Based_Surface_Model((#370));
Zadnji primer predstavlja dejansko obliko podatka. Kazalec #370 se nanasa na opcijo iz topologije, Connected_Face_Set, ki je pod to stevilko tudi dolocena. (Glej original dokumenta Part 205)
-- Geometric_3d_Surface_Set.
geometric_3d_surface_set_occurrence = ENTITY_NAME "="
"GEOMETRIC_3D_SURFACE_SET" [geometric_3d_surface_set_scope_section]
"(" reference_list "," reference_list "," reference_list ")" ";" .
#660 = Geometric_3d_Surface_Set((),(#130),((#1));
Zadnji primer predstavlja dejansko obliko podatka. Prvi kazakec, v tem primeru ga ni, bi definiral tocko. Drugi kazalec, #130, doloca krivuljo, ki je definiran apod tem naslovom, #1 pa definira povrsino, ki je definirana pod naslovom #1.
-- Shell_Logical_Structure
shell_logical_structure_occurrence = ENTITY_NAME "="
"SHELL_LOGICAL_STRUCTURE" [shell_logical_structure_scope_section]
"(" ENTITY_NAME "," ".TRUE." ")" ";" .
#490 = Shell_Logical_Structure(#480,.TRUE.);
Zadnji Primer predstavlja dejansko obliko podatka. Pod naslovom #480 (v tem primeru) je definirana oblika, na katero se Logical_Structure nanasa. V tem primeru kazalec #480 definira Open_Shell. Oblika je podobna za vse ostale Logical_Structure, le da se kazalec nanasa na tisto opcijo, ki jo Logical_Structure doloca. To so se:
-- Face_Logical_Structure
-- Surface_Logical_Structure
-- Loop_Logical_Structure
-- Edge_Logical_Structure
-- Curve_Logical_Structure
-- Open_Shell
open_shell_occurrence = ENTITY_NAME "=" "OPEN_SHELL"
[open_shell_scope_section] "(" reference_list ")" ";" .
#480 = Open_Shell((#470));
Zadnji promer predstavlja dejansko obliko podatka. Kazalec #470 se nanasa na opcijo Face_Logical_Structure, ki Open_Shell doloci.
-- Connected_Face_set
connected_face_set_occurrence = ENTITY_NAME "=" "CONNECTED_FACE_SET"
[connected_face_set_scope_section] "(" reference_list ")" ";" .
#370 = Connected_Face_Set((#360);
Zadnji primer predstavlja dejansko obliko podatka. Kazalec #360 se nanasa na opcijo Face, ki Connected_Face_Set doloci.
-- Face
face_occurrence = ENTITY_NAME "=" "FACE" [face_scope_section]
"(" reference_list "," ENTITY_NAME ")" ";" .
#360 = Face((#330,#340),#350);
Zadnji primer predstavlja dejansko obliko podatka. Kazalca #330 in #340 se nanasata na opcijo Loop_Logical_Structure, Kazalec #350 pa na opcijo Surface_Logical_Structure.
-- Edge
edge_occurrence = ENTITY_NAME "=" "EDGE" [edge_scope_section]
"(" ENTITY_NAME "," ENTITY_NAME "," ENTITY_NAME ")" ";" .
#240 = Edge(#220,#221,#230);
Zadnji primer predstavlja dejansko obliko podatka. Kazalca #220 in #221 se nanasata na opcijo Vertex, kazalec #230 pa na opcijo Curve_Logical_Structure.
-- Cartesian_Point
cartesian_point_occurrence = ENTITY_NAME "="
"CARTESIAN_POINT" "(" REAL "," REAL "," [ REAL ] ")" ";".
#111 = Cartesian_Point(100.0000,-50.0000,-0.1629E-4)
Zadnji primer predstavlja dejansko obliko podatka. Podatki voklepaju predstavljajo koordinate kartezijskem koordinatnem sistemu.
-- Point_On_Curve
point_on_curve_occurrence = ENTITY_NAME "="
"POINT_ON_CURVE" [ ponc_scope_section ]
"(" ENTITY_NAME "," REAL ")" ";" .
#99 = Point_On_Curve(#60,0.50000);
Zadnji primer predstavlja dejansko obliko podatka. Pod naslovom #60 je definirana krivulja, na katero postavljamo tocko. tevilka 0.50000 je Point_Parameter, ki doloca pozicijo tocke na krivulji.
-- Point_On_Surface
point_on_surface_occurrence = ENTITY_NAME "="
"POINT_ON_SURFACE" [ pons_scope_section ]
"(" ENTITY_NAME "," REAL "," REAL ")" ";" .
#98 = Point_On_Surface(#60,0.50000,0.40000);
Zadnji primer predstavlja dejansko obliko podatka. Pod naslovom #60 je definirana povrsina, na katero postavimo tocko. Ta je dolocena z dvema parametroma. 0.50000 je pp1 in 0.40000 je pp2.
Krivulje, kot so B_Spline_Curve, Pcurve in Surface_Curve, definiramo z osnovnimi enotami, kartezijskimi tockami. Na isti nacin definiramo tudi povrsine, npr. B_Spline_Surface. Ko so definirane vse tocke, ki predstavljajo krivulje ali povrsine, jih je potrebno zdruziti v te elemente. To dosezemo z logicnimi strukturami, ki podane tocke zdruzijo v zeljeno konturo oz. obliko. Konstrukcija slikovnega prikaza se nato nadaljuje na podoben nacin, ko ze ustvarjene elemente zdruzujemo, vkljucujemo v nastalo sliko.