제 8 장

데이터 교환 vs 데이터 공유

8.1 서 론


  제조 기업에서 사용되는 소프트웨어 시스템간의 제품 데이터 교환의 개념은
STEP의 중심이 된다. 개발 작업에 착수한 이후, 제품 데이터 교환은 표준의 기본적인 목표였지만, 소프트웨어 시스템간의 제품 데이터 공유를 가능하게 만들고 싶은 욕구도 있었다. 문제는 “제품 데이터 공유의 개념이 무엇을 의미하고 있는가”라는 점이다. 이 문제에 대답하기 위해서는 먼저 데이터 교환의 개념을 자세하게 정의하고, 두개의 개념을 구별해 주는 특징을 찾아 낼 수 있어야 한다. 5장에서는 구현, 교환 및 공유에 대해서 소개하였는데, 여기서는 그 개념에 대해 자세하게 말하고자 한다.  

8.2 STEP 맥락에서 데이터 교환


  데이터 교환이란 단일 시점에서 정보의 상태를 표현하는 매체를 사이에 두고, 하나의 소프트웨어에서 다른 시스템으로 정보를 전송하는 일이다. 일반적으로, 이 정보는 ASCII 형태로 표현되거나, 2진 텍스트 코딩 된다. 그림 8-1은 데이터 교환의 예를 나타내고 있다. 한 달 동안의 은행 계좌 내역을 수신했을 때 은행으로부터 받은 고객의 정보는 단일 시점에서 제시된 데이터를 표현하고 있다.

  이 정보는 전자 파일로 표시되기 때문에 컴퓨터 운영체제에 의한 관리가 가능해지는 것이다. 한 컴퓨터에서 다른 컴퓨터로의 송신은 휴대용 보존 매체, 분산 파일 시스템, 전자 메일 및 다수의 네트워크 데이터 교환기능을 사이에 두고 이루어진다. 정보의 표현 및 송신은 필요하지만 소프트웨어 시스템간의 의미 있는 데이터 교환에서는 충분하지 않다. 정보의 해석은 데이터 교환보다 더 높은 측면에 있다. 지금까지, 하나로 정리하여 소프트웨어간의 정보를 공통 해석할 수 있는 다양한 STEP 기술에 관해서 살펴보았으며,  더 자세히 검토하기 위해서는 실제로 해석을 어떻게 하고 있는가를 중심으로 고찰해야 한다.  

  데이터 교환 파일을 생성하는 소프트웨어 시스템 (여기에서는 시스템 A이라고 한다)에서 시스템 A는 교환 정보를 표현하는 파일을 생성하는 기능을 실행해야 한다. 실제로 이 기능은 파일 엑스포트에 관한 기능이 된다. 이 파일 엑스포트 기능은 외부 파일로 교환되는 정보 내부 표현을 매핑하는 변환기이다. 교환 파일이 시스템 A 전용 또는 본래의 형식일 경우, 변환은 효율을 요구하는 정보의 파일 인코딩 구조 문제가 되며, 정보의 다른 표현을 생성하는 것은 아니다. 교환 파일의 구조 및 내용이 시스템 A에 의해서가 아니라 기타의 것(즉「중간」교환 파일)에 의해 정의될 경우, 교환 파일의 생성에는 지정된 표현을 통해 시스템 A의 내부 표현을 교환 파일용으로 변환하는 작업도 포함된다. 이와 같은 변환이 시스템 A에서 처음으로 내부적으로 표현될 때의 정보를 어느 정도로 정확하게 반영하고 있는가는 다음과 같은 조건으로 정해진다 :

l       중간 교환 파일이 요구하는 표현은 시스템 A의 표현과 얼마만큼의 정합성이 있을까, 아니면 같을까?

l       변환 소프트웨어가 어느 정도로 유효하게 구현되고 있는가?  

  시스템 A에 의해 작성된 중간 교환 파일을 수신하는 다른 하나의 소프트웨어 시스템을 시스템 B라 하면, 시스템 B는 내용을 해석하고 그 정보의 내부 표현을 작성할 뿐만 아니라 중간 파일에 엑세스하는 기능을 구현해야 한다. 일반적으로 파일에 엑세스하는 최초의 단계는 파일의 임포트(Import)라고 부른다. 제 2 단계인 해석은 변환 프로세스로, 이 경우에도 해석의 정밀도는 변환기 구현의 품질과 함께 중간파일 및 시스템 B의 표현의 정합성 또는 등가성에 의존하고 있다. 변환이 정확하게 완료되었다고 가정할 경우, 시스템 B는 중간 교환 파일 기구를 통해 엑스포트 할 경우, 시스템 A에 의해 제공된 정보 내부의 표현을 얻게 된다. 제 8장에서는 조작 공통성 시험으로서 시스템 A에 의해 제공된 정보 시스템 B의 내부 표현이 시스템 A의 내부 표현과 어떠한 차이점을 가지고 있는지에 대해서 기술했다. 여기에서는 시스템 B의 내부 표현이 시스템 A에 의해 제공된 정보와 같다고 기술하는 것으로 마치겠다. 

8.3 STEP 문맥에서 데이터 공유


  데이터 공유에 의해서 복수의 소프트웨어 시스템이 엑세스하는 단일 논리 정보 공급원이 제공된다. 통상, 정보의 액세스나 정보의 갱신, 정보의 소유권 등에 대한 제어는 정보 공급원의 구현 및 관리에서 제공된다. 그림 8-1은 은행 수속의 예를, 그림 8-2는 동일한 상황의 데이터 공유를 나타내고 있다.

  정보 공급원은 데이터베이스 관리 시스템, 특수화 파일 시스템 또는 그 두개의 조합으로 이해할 수 있다. 제품 데이터 관리(PDM) 소프트웨어 시스템은 정보 소유권이나 리비전 유지 및 정보 액세스용으로 제공되는 기능에 관한 실시 현상을 유형화하고 있다. 본질적으로 PDM 시스템은 제품 레벨의 데이터 공유를 관리하고 있는, 즉 최소 액세스 단위가 제품 표현이 된다. 제품 표현에 이용되는 이 기구는 보통 디지털 인코딩 된 파일의 일종이다(중간 데이터 교환 파일 또는 전용 형식 파일의 경우도 있다). PDM 시스템과 인터페이스 하는 소프트웨어 시스템에서는 교환 파일의 변환과 해석의 문제가 발생한다. 제품 수준보다 세세한 수준에서 상세히 기술되는 데이터 공유에서는 정보 공급원 기반의 데이터 요소의 작성, 액세스 및 조작의 지원이 조건이 된다. 이와 같은 데이터 요소는 데이터 리비전 내의 액세스 제어의 문제 처리는 물론 제품 데이터 표현을 구성하고 있다. 이보다 더 상세한 레벨에서의 데이터 공유는 정보의 액세스를 유지하는 단일 논리 리소스에서 데이터를 작성하고 조작하는 응용프로그램의 밀접한 결합을 가능하게 하므로 바람직해진다. 정보 리소스가 정보의 일차 카피를 보관하게 되면 응용프로그램은 사용 중에 데이터의 독특한 로컬 카피를 유지하지 않아도 된다. 그러나 이것은 이론적으로는 이상적인 상황이지만 STEP의 맥락에서는 STEP이 지원하려고 하는 대부분의 소프트웨어 시스템 설계를 대폭적으로 변경할 필요성이 생긴다. 이 설계 변경은 STEP이 필요로 하는 표현과 소프트웨어 시스템에 존재하는 조건과의 차이에 의한 것이다.

8.4 공유 데이터와 교환 데이터의 비교


  데이터 공유와 데이터의 교환은 데이터의 중심과 소유권에 의해 구별된다. 교환 모델에서 소프트웨어 시스템은 그 데이터의 마스터 카피를 내부에서 보관하고 있으며 다른 시스템이 사용하기 위해 데이터의 단편을 엑스포트하고 있다. 이러한 사용은 내부 데이터의 변경이 교환 파일 버전에 어느 정도 통용되고 있는지 혹은 역으로 명시적인 제어 없이 이루어지고 있다. 교환 파일을 임포트하는 기타의 소프트웨어 시스템은 그 데이터의 소유권을 유효하게 가정해 왔다. 이와 같은 데이터는 송신 소프트웨어 시스템에 포함되는 데이터의「마스터」카피에 대해 동기화 되어 있지 않다. 그러므로 소프트웨어 시스템은 각 소프트웨어 시스템의 데이터 버전이 다르다는 유일한 가정으로 인해 데이터를 공유하지 않는다.

  공유 모델에는 소유권의 중심화 제어 및 데이터의 마스터 카피(정보 리소스에 의해 보관되는 카피)가 있다. 데이터의 마스터 카피에서는 제어된 상황 하에서 액세스하고 리비전할 수 있다. 데이터의 통용도를 강화하여 모든 소프트웨어가 동일한 데이터에 엑세스할 수 있다. 데이터의 마스터 카피 리비전의 이력을 추적할 수 있다.그 데이터의 소프트웨어 시스템 카피의 통용도를 검증할 수 있다.  

  이론적으로 데이터 공유 모델은 데이터 교환 모델에 관련되는 리비전 제어 문제를 경감하게 된다. 이 때문에 데이터 공유는 많은 노력이 요구되는 이상적인 것이다.
STEP 단체는 이와 같은 기능을 구현 수준으로 구별할 필요성이 있다고 이전부터 인식하고 있었다.

8.5 STEP 구현 수준


  1988년 Ontologic이 인솔한 IPO내의 특별 그룹은 상상이 가능한 STEP 구현의 성질을 정의하려고 시도했다. 제 7장에서 소개한 특별 그룹은 당시의 테크놀로지를 기초로 예상되는 4가지 종류의 구현을 비공식적으로 식별했다. 제 7장에서 정의한 각 레벨 중, 레벨 1은 ISO 10303의 제 1 판 발표를 목적으로 시도된 유일한 구현 기구였다. 이것은 현재 사용 중인 주요 구현 기구이기도 한다.

  STEP 위원회는 구현 방법을 데이터로부터 분리하였다. STEP 구현 기구는 데이터 지정 사양으로서의 형식적인, 컴퓨터 해석이 가능한 EXPRESS 언어[114]를 가짐으로써 특정의 데이터 사양으로부터 독립하게 되었다. 이렇게 ISO 10303-21 교환 파일[115]의 클리어 텍스트 인코딩으로 알려진 것의 개발에 종사하고 있던 그룹은 EXPERSS에서만 도출되는 교환 파일의 사양을 고안해 내는 문제를 떠안고 있었다.

  교환 파일 사양 개발 작업은 1986년경 개시되었다. Boeing이나 독일의 원자력 리서치 센터 (KfK), McDonnell-Douglas, NIST, Rutherford Laboratory, Structural Dynamics Research Corporation (SDRC) 및 그 외의 다수 기관이 깊이 관여해 왔다. 거기에는 IGES로 실현된 것보다 더 우수한 파일 구조를 제공하려고 하는 의도가 숨어있었다. IGES 파일은 Hollerith 카드의 영역(필드 및 기록지향)에서 파일 구조를 도출해 냈다.  IGES 파일은 인간이 간단하게 해석할 수 있는 것이 아니기 때문에 교환 문제를 식별하는 수동 해석이 많이 이루어졌다. 그 때문에 STEP 교환 파일 구조를 보다 쉽게 해석하고자 하는 시도가 이루어지기 시작했다. 

  그 결과 파일 구조를 텍스트 형식의 파일로 실현화했다. 그러나 IGES보다 콤팩트한 파일 구조를 고안해 내려는 (논쟁을 불러일으킬 만한 소지가 있는)목표도 있었다. 이 목표는 텍스트 파일 구조의 사용을 부정하는 대신 2진수 인코딩 등의 대체 안을 주장하였다. 결국 텍스트 인코딩이 승리하여 이해(利害)가 보증된 대체 인코딩의 개발에 경고가 붙게 되었다(컴퓨터 그래픽스 메타 파일 표준[116]의 경우에 실시되었던 것처럼). 기재에 대한 대체 인코딩을 더 이상 연구하지 않았는데 이것은 파일 압축 소프트웨어 툴이 콤팩트의 문제를 경감했기 때문이었다.26)

  프로세스에 있어서 최대의 난점은 엔티티간의 상속에 대해 EXPRESS가 제공한 능력의 처리였다.「단일 상속」과 같이 엔티티가 단일 선조로부터 속성을 이어받을 경우에는 교환 파일용의 매핑 고안에서는 그다지 문제가 되지 않는다. 그러나「다중 상속」의 경우에는 그렇지 않다. 다중 상속이 있을 경우, 엔티티의 인스턴스화는 본질적으로 복수의 선조로부터 동시에 계승받는 복수형의 인스턴스화가 된다. 교환 파일의 매핑에서는 이와 같은 인스턴스의 교환 파일 표명이 그 파일에 충분한 정보를 어떠한 방법으로 제공할지를 전달하는 알고리즘의 개발이 요구되고 있다. 이에 따라 해석 소프트웨어는 그 속성이 어느 선조의 엔티티에 속하고 있는지, 그 속성이 어떻게 처리될지를 결정할 수 있게 되었다. STEP에서 개발된 초기의 EXPRESS 모델의 대부분은 「다중 상속」의 특성을 이용하지 않았으나 그 후의 모델은 이용하고 있다.

  교환 파일 매핑은 EXPRESS 언어와 함께 개발되고 있었기 때문에 교환 파일 개발자가 언어 개발자와 보조를 맞추지 못하는 상황이 빈번하게 생겨났다. EXPRESS 발전의 단계에서는 계승, 이른바「디폴트」모델이 완전하게 반전되는 상황이 벌어졌다. 이것은 기존의 EXPRESS 모델 전체를 교환 파일 매핑과 함께 부정확한 것으로 인식했다. 이 때문에 모든 프로트타입 교환 파일 및 EXPRESS와 교환 파일을 해석하기 위해 NIST가 개발한 시험적 소프트웨어 툴은 곧 시대에 뒤떨어지게 되었다. 동일한 시점에서 개발된 언어를 처리할 경우에는 이와 같은 문제가 발생한다.  

  제 7장에서 설명했듯이, 구현 수준을 위한 노력은 계속되었다. 특히 구현 수준 2와 3[117]과 하위 수준 4와 관련하여 일어났다. STEP의 SDAI(SDAI)[118]는 이러한 노력의 결실이었다. SDAI는 수준 2와 3에 대한 최초의 버전[119] 중 몇 개를 대상으로 하고 있다. 기존 기술을 활용하면서 구현의 자유 및 유연성의 필요성이 인식됨에 따라 SDAI의 초기 적용 범위가 조정되었다. 수준 4의 구현은 현재까지 알려지지 않은 상태이다.  

8.6 SDAI의 진화


  PDES, Inc. 및 당시의 가맹 조직, 특히-NIST, IBM, 디지털 에크이프먼트 코퍼레이션(DES), 일렉트릭 포트 코퍼레이션
27), STEP 툴 Inc. 및 SDRC-는 STEP 데이터용인 프로그램 인터페이스의 확립을 위하여 ISO 프로젝트의 선두에 나서고 있다. PDES,Inc. 멤버는 SDAI를 개발하는 ISO 작업 그룹에 참가하고 있으며 그 영역내의 중대한 프로트타입의 작성에도 참여하고 있다. 해외에서는 유럽의 ESPRIT IMPPACT 프로젝트가 SDAI의 개발에 참여하고 있는데 특히 데이터 사전의 중요한 부분을 지정하고 있다. 기타의 많은 나라들(특히 독일, 일본, 영국)도 연구 프로젝트의 참여를 지원하고 있다.  

  SDAI의 초기의 아이디어에는 SQL[120] 등의 표준 인터페이스의, 관계 데이터베이스 관리 시스템에의 인터페이스가 상정되어 있었다. 인터페이스에 의한 실험 결과, 설계 데이터 관계 시스템의 매핑에 의해 수용이 가능한 성능을 얻을 수 없게 되었다. 또 응용프로토콜 개발자들도 시스템에 입각한 정보 모델의 시험을 개발하기가 어려웠다. 그 결과, SDAI를 제공하는 저장소로써의 객체 지향 데이터베이스 시스템의 조사와 연관되었다.

  NlST가 초안한 최초의 SDAI 사양은 1990년 센트 루이스 합동 연구 발표회의 석상에서 CAM-I의 AIS (AIS)와 함께 산업에 제시되었다. 이 연구 발표회에서는 초기 및 후기 경계 인터페이스에 대한 필요성이 강조되었다. 그 결과 SDAI 사양이 변경되었으며 이것은 초안의 다음 버전에 반영되었다. 이 문서는 PDES Inc.가 실행, NIST가 주도한 중요 프로트타입 작성 작업의 핵심이 되는 부분이었다. DEC 및 SDRC 외에 몇 개의 객체 지향 데이터베이스 벤더(Versant 및 0bjectivity) 등은 프로토타입 작성 활동에 관여했다. 프로토타입 작성 결과의 강도(및 프로토타입 작성 작업의 벤더-위탁)는 SDAI 수법으로 주의를 끌기 위한 사양이었다. 이와 같이 주의가 집중됨에 따라, SDAI 작업 그룹이 활동함에 따라 관심도는 더욱 높아졌다. 특정 프로그래밍 언어에 대한 바인딩 사양은 구현 방법에 의존하지 않는 ISO 10303의 SC4 목표를 유지하기 위해 SDAI의 기능적 사양의 프로젝트로서 분리되었다. 이것은 기능적인 사양에 초점을 맞추는 데에는 유효하지만 표준화의 진전은 여전히 느리다. 이것은 작업 그룹의 관여자 및 어플리케이션 고유의 표준에 대한 범용 인터페이스의 사용을 둘러싼 문제점들이 증대한 것에 따른다. 작업 그룹은 교환 파일 포맷의 SDAI 정합성과 AP 사이의 조작 공통성에 대한 지원 및 SDAI의 실시 모델 등에 관한 논쟁으로 곤경에 빠져 있다.  

  l988년에 제시된 STEP 구현의 4 수준은 최근 이용되고 있는 분산 연산의 가능성을 예측한 것은 아니었으나, 최근의 작업에서는 이 기능을 활용하는 안이 중시되어 왔다. 즉, NIIIP (National Industrial Information Infrastructure Protocols) 컨소시엄 회원사(NIST, 제너럴 다이나믹스, STEPTools, IBM)들은 프로토타입이 가상 기업에 대한 유효성을 나타내고 있던 SDAI 인터페이스 정의 언어(IDL) [121][122] 바인딩 사용을 추진하고 있다. 또한 NIIIP는 새로운 ISO 작업 항목에 EXPRESS-X(제 6장 및 제 10장에 기술)로서 알려진 매핑 언어 및 JAVA[l23]로의 SDAI 바인딩을 지정하는 중요한 입력을 행하였다. 이렇게 제한된 방법들은 데이터 분산을 지원하는 방향으로 가속화되고 있다.

8.7 SDAI의 목적


  SDAI는 EXPRESS 정보 모델에 의해 기술되는 데이터에 응용 프로그래밍 인터페이스(
API)를 제공한다. 표준 API의 사양은 데이터를 임포트 하거나 엑스포트하며 데이터 교환 소프트웨어의 유효성을 최적화 하는 응용프로그램의 데이터 교환 소프트웨어의 분리를 지원하고 있다. API은 응용프로그램 및 그 데이터를 저장하고 관리하는 소프트웨어와 중개 역할을 한다(그림 8-3[124]).  

  디스크 위의 데이터는 다양한 방법으로 표현될 수 있지만 그 중의 하나는 10303-21로 기술된 것처럼 포맷된 ASCII 파일이다. 또한 데이터는 최신의 데이터베이스 소프트웨어를 사용하고 저장할 수 있다. SDAI의 설계자는 데이터베이스 내의 저장을 지원하는 인터페이스에게 충분한 유연성을 주지만 한편으로는 파일 기반 저장의 가능성도 규정하고 있다.

  SDAI는 여러 면에서 SQL[l25] 또는 CODYSAL[126]과 같은 종래의 데이터베이스 관리 시스템(DBMS)의 인터페이스와 유사하다. SDAI를 기타의 데이터 인터페이스와 구별하는 것은 ISO I0303의 기타의 부분에서 맥락에 채택되었을 때에 의미 베이스의 인터페이스를 정의하는 것과 같다. 이와는 반대로 종래의 데이터베이스 표준이 정의하는 것은 익명의 데이터 액세스 메커니즘뿐이다. 기타의 방법으로, SDAI는 데이터가 실제로 표현되는 방법은 아니며, EXPERSS 모델에 근거하는 데이터의 표준 뷰(View)를 정의한다.  

  ISO l0303의 기타 부분과 결합하면 SDAI는 CAM-I의 AIS와 같은 고유 영역 인터페이스와 유사하다. 이것은 데이터의 고유 영역 인터페이스를 제공한다. 그러나 AIS 인터페이스는 데이터의 뷰 이상의 것을 주며 데이터 상의 함수를 지정한다. STEP의 이러한 기능을 오랫동안 요구해 왔지만 아직도 정의되어 있지 않다.

  SDAI와 SQL과의 큰 차이점 중의 하나는 데이터 액세스의 형식이다. SQL은 데이터형 수가 한정된 기록 지 향 데이터용으로 설계되어 있다. STEP으로 기술되는 데이터는 각각의 인스턴스[127][l28]가 비교적 적은, 상호 접속된 복잡한 데이터 타입 망을 형성한다. 이 데이터는 대용량 처리보다도 링크의 통과를 우선적으로 사용한다. 관계 데이터베이스 패러다임은 직감적으로 사용할 수 있는 방법으로는 복잡한 통과를 지원하지 않는다. STEP의 데이터 액세스 필요성에는 객체 지향 데이터베이스 시스템의 표현 능력과 정합성이 있다[129].  

8.8 SDAI과 표준 패밀리


  SDAI에서는 실제로 표준의 결합이 필요하다. 시리즈 ISO 10303-22[130] 중 최초의 시리즈는 기능적 수법이다. 이것은 프로그래밍 언어에 의존하지 않는다. ISO 10303-23[131], -24[132] 및 -25[133]은 SDAI를 특정의 프로그래밍 언어 : 각각 C++, C 및 FORTRAN에 바인딩 한다. 실제로 Fortran 바인딩 개발 작업에 대한 관심도는 실제로 낮아지고 있기 때문에 중지되었다. 

  10303-23, -24, -25에 관한 작업이 시작된 이래, 소프트웨어 단체들은
API로 사용되는 범용 프로그래밍 언어 바인딩을 정의하기 위해 작업에 착수했다. 특히 소프트웨어 단체는 lDL구동[134]의 표준화를 진행하고 있다.  ISO 10303-26에 대한 동기 부여 요인은 그 이상의 언어 바인딩에 대한 필요성을 제거하는 것이었다. 실제로 이것은 실현되지 않았으나 최근에 이르러서야 Java 바인딩에 대한 작업이 시작되었다.

  국제 표준으로 추진된 최초의 언어 바인딩은 C++바인딩, lSO 10303-23이었다. C++ 바인딩을 기존의 객체 지향 데이터베이스 시스템과 정합시키기 위한 수많은 시도들이 거듭되었다. NIST 및 전 세계의 기타 단체(특히 독일, 일본, 미국, 영국)는 이와 같은 시스템의 기본형을 개발했다.

  언어 바인딩 이외에 SDAI 인터페이스를 식별하는 특성은 초기 대 후기의 바인딩 형식의 특성이다. 초기의 경계 인터페이스는 EXPRESS 언어를 프로그래밍 언어 구조에 직접 매핑하고 그에 따라 데이터 모델을 누적 시간의 인터페이스로 구분하는 것이다. 후기 Binding 인터페이스는 응용프로그램이 정보 모델의 액세스에 랜덤 딕셔너리를 사용한다는 점에서 딕셔너리 구동형이다. Late 바인딩 응용프로그램은 런 타임에서 데이터 모델을 변경할 수 있다(그림 8-4). C++ 및 IDL 바인딩은 양쪽의 인터페이스 형태를 규정하고 있지만 요구하는 것은 아니다.C 바인딩은 후기 바인딩 인터페이스만을 지정하고 있다.

8.9 EXPRESS와 SDAI 상호성


  SDAI는 EXPRESS 스키마에 따라서 작성된 데이터 인스턴스에 액세스하고 조작하는 것을 목표로 한다. SDAI는 개념상 2개의 부분으로 이루어져 있다. 결국 SDAI 스키마와 목표 언어 구조로의 EXPRESS의 매핑이다
28)3). SDAI 스키마는 액세스하고 있는 데이터와 관계없이 SDAI를 실행하는 데에 필요한 구조를 지정한다.  

  EXPERSS 정보 모델은 2 종류의 방법으로 SDAI를 표현한다. 첫 번째는 데이터 딕셔너리를 통하여 표현하는 방법이며, 두 번째는 프로그래밍 언어로 유효한 데이터 구조에서 직접 표현하는 방법이다. ISO 10303-22는 데이터 딕셔너리의 내용을 기술한다. 이 딕셔너리는 EXPRESS 언어 전체를 보충하고 있지 않기 때문에 한정된 수의 명시적인 제약과 함께 EXPRESS의 중심 데이터 구조를 파악하고 있다.

  특정 프로그래밍 언어에 대한 EXPRESS 매핑의 정도는 바인딩 언어에 따라 달라진다. 대부분의 EXPRESS 구조는 응용프로그램의 누적 시간을 체크할 수 없는 소정의 프로그래밍 언어로는 직접 표현되지 않는다. 예를 들면, EXPERSS형 시스템은 C로 간단하게 매핑할 수 없다. 따라서 C 언어 바인딩에는 초기의 경계 매핑이 포함되어 있지 않다. 한편 C++형 시스템은 풍부하고 EXPERSS형 시스템의 부분 집합을 대상으로 삼을 수 있어서 가능한 한 적용된다. 형태 시스템이 대폭적으로 다를 경우, C++ 컴파일러형 체크 기능 대신 런 타임형 검사를 사용해야 한다.

  SDAI의 언어 바인딩은 API의 특정 사항을 정의한다. 상이한 언어 바인딩은 언어의 표현 능력에 근거하는 EXPRESS의 의미를 지원하는 데에 있어서도 다르다. lSO 10303-23 및 10303-26의 결과로 얻을 수 있었던 C++ API는 이러한 차이점을 강조한다. ISO 10303-23은  C++언어의 기능을 이용하여 EXPRESS 구조[135]에 강건한 지원을 제공할 수 있다. ISO 10303-26의 결과로 얻을 수 있었던 C++ API는 다수의 EXPRESS 구조에 대한 지원에 있어서 최소의 것이다. 예를 들면 EXPRESS의 배열형은 배열 경계 및 기타의 형태에 관한 제약을 안전하게 처리할 수 있는, 보다 풍부한 인터페이스뿐만 아니라 최소 인터페이스(C 형식 배열에 필요한 것 등)를 지원하는 클래스로서 C++로 표현 할 수 있다. SDAI IDL 바인딩은 IDL 열(列)열 형태의 형식 배열의 표현에 대한 최소한의 인터페이스를 지정한다. IDL열은 배열의 경계와 같은 응용프로그램에 정보를 전달하지 않으며 그 배열이 응용프로그램에 설정되어 있는가를 시험하지 않는다.  

  프로그래밍 언어가 EXPRESS 구조에 대한 직접적인 지원을 제공하지 않을 경우에도 여전히 그 구조의 일부를 강화시키는 것은 SDAI 구현의 책임이다. 형태 검사는 그 중의 한 예이다. 또 배열의 누적 시간 지원은 SDAI에 바인딩된 언어에 의해서도 지원되지 않는다. 그러나 응용프로그램에서 배열이 규정된 경계를 지키고 있는지의 여부를 검사하도록 트리거 시키는 함수는 SDAI로 정의되어 있다.  

  EXPRESS FUNCTION 구조는 SDAI 언어 바인딩으로는 지원되지 않고 있다. SDAI는 응용프로그램에서 정보 모델의 함수를 트리거하는 단서를 주고 있다. 프로그래밍 언어에 대한 함수의 바인딩은 SDAI의 적용 범위 밖이며 현행의 바인딩 문서 중 어느 쪽에서도 다루어지지 않았다.  

8.10 응용 프로토콜AP의 SDAI 지원


  스키마 간의 참조 기능은 EXPERSS가 제공하는 가장 중요한 특성이며, SDAI에서는 제공되지 않는다. SDAI 구현에 대한 전제는, 이 인터페이스의 인스턴스에 의해 지원되는 스키마가 「확장된 스키마 형식」 [136] 이른바「long form」에 입각하고 있다는 것이다. SDAI의 인스턴스에 대한 스키마는 모든 EXPRESS 정의가 그 스키마에 포함되어 있다고 가정함에 따라서, 모든 스키마 참조를 완전하게 확장한 스키마이다. 원래의 스키마에 관한 정보는 유실되었으며, 아마도 데이터 딕셔너리 역시 유실되었을 것이다. 그러나 SDAI 딕셔너리는 복수의 스키마를 처리하는 최소 지원을 제공하고 있다. 이 딕셔너리는 각 AP가 단일 스키마(long form 스키마)로 표현될 경우에, 복수의 AP에 대응된다. 하지만 2개의 AP 스키마를, 동일 기반이 되는 리소스 부품에서 도출할 수 있다는 사실은, 언급하고 있지 않다.

8.11 ISO 10303-21과 ISO 10303-22의 비교


  ISO 10303-22는 ISO 10303-21[137]과 마찬가지로 교환 형식을 기술하지만, 양 표준의 유사점은 거기에서 종료한다. 10303-21은 ASCII로 기록되지만, 상태(state)에 관한 정보는 제공하지 않으며, 시간의 개념이 없이 단면(snapshot)을 표현한다. SDAI는 형식 변환을 하지 않고, 응용프로그램이 이용할 수 있는 형식으로 데이터를 제공한다. 공유 데이터 저장소로 사용될 경우, SDAI는 유동적으로 변화하는 데이터의 응용프로그램 액세스를 지원한다. 또한 SDAI는 변화하는 데이터를 지원하고, 그 데이터가 완전하면서도 일관된 상태로 안팎을 이동하게 한다. SDAI는 응용프로그램이 데이터의 완전성 및 일관성의 검사를 개시할 수 있도록 함수를 지정한다.

  개발 중인 ISO 10303-22의 조건 중의 하나는, SDAI 응용프로그램이 데이터 저장소에서, 10303-21 교환 파일을 작성할 수 있도록 하는 것이다. 이렇게 해서 10303-22는 10303-21과 상위 정합성(upwardly compatible)을 갖게 된다.

  양 파트에 포함되는 현저한 구조는 SCOPE 구조이다. 이 SCOPE 개념은 참조 및 존재 관계의 적용 범위 [138]를 정의한다. 이 구조는 표준의 구현 방법만을 나타낸다. EXPRESS나 정보 모델 그 자체에는, 데이터의 인스턴스에 적합하다는 개념이 있기 때문에 표현할 필요는 없다. 실제로 이 표준을 채택한 대부분의 미국 사용자은 이 기능을 무시하고 있다. 그러나 유럽이 주로 사용하고 있다는 사실은 무척 흥미롭다. 이 개념을 유지할 가치가 있을지의 여부는 여전히 논의 중이다.  

8.12 ISO 10303-22의 구현 클래스

  lSO 10303-22는 5개의 특징(표 7-1)을 기초로 6개의 구현 클래스를 정의하고 있다. 첫 번째의 구현 클래스는 데이터 교환에 최소 지원을 제공하는데, 실질적으로는 교환 파일의 API이다. 클래스가 위가 될 만큼 보다 세련된 특성이 제공됨에 따라, 최종적으로는 EXPRESS 표현의 평가에 대해 충분히 지원한다. 이와 같은 풍부한 지원을 통해서, 도출된 속성의 완전한 제약을 검사하고 계산할 수 있게 되었다.

구현클래스

트랜잭션

표현

세션 기록

적용 범위

영역 등가

1

없음

없음

no

no

no

2

없음

단순

no

yes

no

3

없음

복잡

no

yes

yes

4

모델

단순

yes

no

no

5

full

단순

yes

no

yes

6

full

복잡

yes

yes

yes

    시스템 발전을 지원하면서 SDAI의 구현 클래스는 소프트웨어 모듈화에도 지침을 내리고 있다. 응용프로그램이 보다 새로운 SDAI 구현에 적합할 경우, 그 응용프로그램에 의해 요구되는 보다 많은 기능들은 SDAI 구현에 상주하게 된다. 이 점을 염두 해 두고 SDAI에 기초를 둔 응용프로그램을 설계하며, 그것이 발전에 따른 악영향을 받지 않도록 한다. 

8.13 SDAI의 테스트


  SDAI 구현에 대한 적합성 시험 방법을 정의하기 위해서 ISO 10303-35[139]의 작업을 개시하였다. 대부분의 개발은 이 영역에서 이루어져야 한다. 대부분의 활동은 복수 제품의 데이터를 포함한 공유 데이터베이스의 적합성에 대한 시험을 중요시하지 않았다. 장기 트랜잭션에 대한 SDAI의 지원은, 시험에 관한 업무를 더욱 복잡하게 만들었다. 그러나 시험이 실시되지 않으면 SDAI 시스템의 유용성은 한정되어 버린다. 제 6장에서는 시험에 관해 자세히 기술했다.

  SDAI를 포함하는
STEP의 각 파트는 몇 개의 적합성 레벨을 정의하고 있다. 또한 SDAI를 사용한 시스템은, 10303-22 및 10303-23, -24 또는 -26으로 지정된 언어 바인딩뿐만 아니라, 복수의 응용프로토콜을 이용하여 구축되고 있다. 이것은 폭 넓은 하드웨어 플랫폼, 네트워크와 방화벽, 소프트웨어 등으로 구성되는 (그 이상 복잡하지 않은) 균일한 계산 기초 구조에 모두 배치되어야 한다. STEP을 사용한 개방형 시스템의 유연한 조립체 및 발전에는 적합성 시험 및 호환성(interoperability) 시험에 대한 강력한 지원이 필요하다. 따라서 이것이 실현되는 정의 방법은 연구의 여지를 남겨 둔 미완성 영역이다.  

8.14 마무리


  SDAI는 데이터 공유에 필요한 하나의 구성 요소에 지나지 않지만, 현 시점에서는
STEP 환경의 제품 데이터 공유에 대한 최선의 대답이다. 현행의 SDAI 제약에는 아래와 같은 지원하지 않는 사항들이 포함되어 있다.

l       복수 응용프로그램 의한 복수 SDAI 세션의 동시 액세스

l       원격지 저장소의 접속

l       데이터의 의미론에 근거하는 액세스 또는 조작

l       데이터 형식의 사양

l       저장소의 작성, 삭제 또는 명명

  그러나 현행의 제약이 있다하더라도 SDAI는 :

l       EXPRESS로 지정할 수 있는 데이터베이스(저장소)의 표준 액세스 메커니즘을 지정한다.  

l       특정 프로그래밍 언어의 바인딩에서 인터페이스를 분리한다.   <

l       데이터 저장 기술로부터 응용프로그램의 독립을 인정한다.  

l       구현과 관계없이 데이터를 객체 지향 지향으로 뷰(View)한다.  

  제품 데이터 공유의 목표는 데이터 교환에 많은 이점을 제공하면서도, 현재 제약된 설정에서만 실현되고 있다. 현재까지 지식 베이스 기술의 적용에 대한 관심은 없지만, 인터넷, 관련 기술의 폭발적인 이용에 의해서, STEP의 구현작업은 분산 액세스를 둘러싼 문제에 집중하도록 방향이 설정되어 있다. 제 10장에서는 장래에 SDAI 및 지원 기술이, STEP 단체를 어디로 이끌어 나갈 것인지에 관한 흥미로운 의견에 대해 다루었다.



26) 규범적 STEP 엔티티에서(로) 단축 명을 만들기 위한 알고리즘은 Rutherford Appleton Laboratory에 의해 개발되었다. 알고리즘을 구현 하는 프로그램은 지속되는 표준 개발 프로세스 관리의 일부로서 NIST에서 실시된다. 그 결과로 얻어진 약어는 표준 문서 중에 포함되며 NIST의 레지스토리에 보관된다. 그 프로세스의 실제 에펙트는 생략된 엔티티 명을 사용하는 STEP 데이터 교환 파일의 사이즈를 축소한다. ISO 10303에서는 단축 명을 사용하지 않으면 안 된다. 기타의 SC4 표준도 ISO 13549 부품 라이브러리와 같이 단축 명을 요구한다.

27) 구 제너럴 다이나믹스 일렉트로닉 보드

28) 초기의 구석을 규정하는 수법이지만 바인딩언어로의 EXPRESS의 매핑을 기술한다.