제 7 장

모델링

7.1 데이터 공유에 대한 정보 모델의 역할


  정확한 척도(기준)가 길이 측정의 표준이듯 ISO 10303은 제품 데이터에 대한 표준이다. 기준 그 자체는 객체의 길이에 관한 정보를 제공하지 않는다. 그 객체에 기준을 적용했을 때, 객체에 관한 것, 즉 그 길이를 측정하는 것이다. 이와 마찬가지로 STEP 역시 제품에 관해서는 아무 것도 나타내지 않지만 그 제품을 기술할 때에는 사용 가능한 특징을 자세히 나타낸다. 이 표준을 사용하여 정보를 전달하기 위해서는 특정 제품에 표준을 적용해야 된다. 그 적용의 결과는 제품에 관한 정보, 즉 측정치가 된다. 이 정보를 디지털로 부호화하고 소프트웨어 응용프로그램이 그 정보를 처리하여 제품에 관한 유효한 조작을 실행할 수 있도록 한다. 유효한 조작이란 제품 버전의 식별자 표시에서 복잡한 설계 분석에 이르기까지의 모든 조작을 말한다.

  제품 기술의 특징은 정보 모델에서 파악된다. 어느 제품의 「측정치」는 제품 데이터로서 참조된다. 본 장에서는 일반적인 정보 모델링에 관해 기술한 후, 모델링 언어로서의 EXPRESS에 대해서 상세히 기술했다. STEP은 산업 데이터 모델 개발을 목표로 한 합의에 입각하여 제조 정보 교환을 위한 기본적인 요구 조건을 만족시키는 수단이다.  

7.2 STEP에는 견고한(Robust) 모델링이 매우 중요


  제 5장에서 이미 언급했듯이, STEP은 각종 CAD/CAM 시스템, 기타 제조 관련 소프트웨어 및 벤더의 완전하고 정확한 제품 데이터의 교환이 가능하도록 개발되고 있다[75]. 모든 관여자가 정보의 의미에 합의하기 위해서는 형식적인 모델이 필요하다.

  이와 같은 모델 개발에 있어서 중요한 역할을 하는 요인은 기술적인 면에서 비기술적인 면에 이르기까지 폭넓은 영역에 이르고 있다. 예를 들어 기술적 요인에는 견고한 모델링 언어(robust modeling language), 기법, 프로토콜 및 툴의 존재와 작성 등이 있다. 비기술적인 요인에는 이와 같은 객체(표준)에 관한 합의, 재고 구현(off-the-shelf implementations)을 구입하는 것에 대한 가능성 여부 등이 있다. 제 5장에서는 STEP에 대한 특정 모델링 언어에 이르기까지의 과정에 대해 기술했다. 

  기술의 현상은 기술적인 문제를 좌우하지만 관여자의 상황은 모든 문제에 영향을 준다. 예를 들어 어떤 모델링 시스템을 다른 시스템으로 변환할 경우, 회사에 따라서는 도리에 맞지 않을 정도로 고가인 것이 되지만 다른 회사에게는 그렇지 않으므로, 충분한 기술적 솔루션이 있음에도 불구하고 분열이 생긴다.25)    

7.3 모델링 대체안


  모델링을 이용하여 정보를 전달한다는 개념은 새로운 것이 아니다. 공동 데이터 모델링(ADM, Associative Data Modeling )은 1969년 폴 ? 존스에 의해 고안되었다 . 또 카티존스 기법으로도 불리는 ADM은 강력하고 간단한 데이터의 모델링과 검증 방법을 제공하고 있다. ADM은 그것을 일반적인 영역에 도입함으로써 더욱 관심을 끌게 되었다[76]. 엔티티 관계(ER, Entity-Relationship)모델은 l976년에 첸 박사에 의해 제안되었다[77]. 이것은 일반적으로 문학에 등장하는 최초의 진정한 의미론적 데이터 모델 중의 하나로 인정받았지만 이때는「의미론」이라는 단어는 쓰이지 않았다. 그 외에도 1981년 Hammer와 McLeod에 의해 발행된 것으로, 도출 스키마 구성 요소의 개념을 강조한 의미론 데이터베이스 모델(SDM, Semantic Database Model) 등 과거의 개발에 공헌한 모델링 언어가 있다[78]. 그러나 이와 같은 초기의 모델링 언어는 차기의 모델링 개발의 단계를 설정한 것에 지나지 않는다. STEP 개발에 있어 키포인트가 되는 것은 NIAM, IDEF0, IDEF1X 및 EXPRESS 등과 같은 그 이후의 개발이었다. 다음 절에서는 이러한 모델링 시스템에 관한 각각의 배경과 기능적인 설명을 추가시켰다. 그림 7-1에서 7-3까지는 ISO 논문[79]에서 인용한 것으로 간단한 제조 시나리오에 입각하고 있다 :

「기술된 논문의 분야는 차량 등록과 관계되어 있으므로 등록 기관의 관점인 유효 범위로 한정되어 있다. 각 자동차 제조업체들은 독자적인 이름이 있으며 몇 개의 모델을 제조하고 있다, 자동차는 특정 모델이다. 제조업체는 제조하는 각 차에 일련번호를 붙이다. 이 일련번호는 제조업체의 어느 자동차에 대해서도 독자적인 것이다. 자동차 모델의 이름도 모든 자동차의 모델에 대해 독자적이다. 어떠한 특정 자동차 모델도 하나의 제조업체에서만 제조된다.」

7.3.1 NIAM


  Nijssen 정보 분석 방법(NIAM, Nijssen Information Analysis Methodology)은 그래픽 데이터의 모델링 언어와 방법이다. NIAM은 자연어 문장에 초점을 맞추고 있다. 각각의 명사는 양방향, 2진수 관계의 복잡한 연결의 절점으로 표현된다. 이것은 두 절점 간의 관계를 더욱 정밀하게 하는가 혹은 복수 관계의 제한을 지정하는가에 따라 제약된다. NIAM 언어의 기본 구조는「객체」와 「사실」또는 관계이다.  

  NIAM에는 도식과 구조화된 언어 표현이 있는데 이를 기반으로 하는 방법을 필요로 한다[80]. 현재 NIAMORM―Object-Role Modeling으로 알려져 있다.  

  그림 7-1 부분적인 NIAM 모델

7.3.2 IDEF0


  제 2장에서는 기능 모델링(IDEF0)과 IDEF1X의 통합 정의의 기원에 대해 기술했다. 이것은 1970년대 미 공군 ICAM 프로그램의 결과로 탄생되었다. IDEF0(Integration DEFinition language 0)은 더글라스 T.로스와 SofTech, Inc.에 의해 개발된 SADT (Structured Analysis and Design Technique(TM))에 기초를 두고 있다. 그 원형으로 IDEF0은 그래픽 모델링 언어(구문 및 의미)의 정의와 모델 개발의 포괄적인 방법을 기술하고 있다.  

  IDEF0를 이용하여 여러 종류의 자동화 시스템 및 자동화되지 않은 시스템을 모델화 할 수 있다. 새로운 시스템의 경우, IDEF0를 이용하여 처음에는 요구 조건을 정의하고 기능을 특정화하고, 다음으로 요구 조건을 충족시키는 구현을 설계함으로써 그 기능을 실행할 수 있다. 기존의 시스템에서는 IDEF0를 이용하여 시스템이 실행하는 기능을 분석하고 그것이 실시된 기구(수단)를 기록할 수 있다.

  IDEF0를 시스템에 적용한 결과는 그림, 텍스트 및 용어의 상호 참조를 포함하는 모델이다. 두 개의 주요 모델링의 구성 요소는 기능(그림에는 사각형으로 표현됨) 및 그 기능을 상호 관련시키는 데이터와 객체(화살표로 표현)이다.

  기능 모델링 언어로서 IDEF0에는 다음과 같은 특징이 있다 :

7.3.3 IDEF1X


  산업계가 ICAM이 정의한 모델링의 기술을 적용한 것은 1982년 데이터베이스 설계 그룹의 R.G. 브라운에 의한 논리 데이터베이스 설계 기술(LDDT, Logical Database Design Technique)의 개발과 관련이 있다. 이 기술은 E.F.Codd 박사의 관계 모델, 첸 박사의 엔티티 관계 모델(ER, Entity-Relationship), J.M. 스미스와 D.C.P 스미스의 일반화 집합체 모델 등에 기초를 두고 있다.  ER 모델에는 '엔티티, 속성 및 관계가 기본적인 의미 요소라는 개념이 있다. 관계 모델은 정당함을 관리하는 규칙을 추가한다. 일반화 집합체 모델은 일반화 관계(형태 및 하위형의 표현)와 집합체 관계(그룹 분할을 표현)의 구별에 도움이 된다[82].

  LDDT는 기업 내에서 정보에 대한 개념적인 견해를 표현할 경우에 복수 레벨의 모델과 그래픽 패키지를 부여한다. D. Appleton Company의 M.E.S. Loomis의 기술적인 주도 아래, LDDT의 본질적인 하위형은 IDEF1의 방법과 결합되어 1985년에 ICAM 프로그램으로 발행되었다. 이 기술은 IDEF1 확장 또는 단순히 IDEF1X이라고 불린다.  

  IDEF1X의 주요 목표는 통합을 지원하는 일이다. IDEF1X 기술은 다음과 같은 요구 조건을 만족시키기 위해 개발되었다 :

  그림 7-2 IDEF1X 모델의 일부

7.3.4 EXPRESS


  EXPRESS[84]는 데이터에 관한 정보의 전달 용어로 설계되어 있다. 몇 개의 데이터베이스 정의 언어와 프로그래밍 언어에는 공통된 부분이 있다. 모두 데이터 구조의 정의에 사용될 수 있다.[85]. EXPRESS는 SQL[86]과 같은 데이터베이스 언어 또는 C[87] 등의 프로그래밍 언어와는 다르므로 정보 모델링 작업을 프로그래밍이나 데이터베이스 설계 작업으로 혼동할 필요 없으며, 또한 특정 프로그래밍이나 데이터베이스 시스템 특유의 것도 아니다.  

  그림 7-3 EXPRESS 모델의 일부

7.4 모델링 정보 - 무엇이 요구되고 있는가?  


  STEP은 표준의 규범적인 형식을 컴퓨터가 해석 가능한 언어 : EXPRESS를 포함하고 있지 않는 다는 점에서 IT에 관한 다수의 기타 표준과는 다르다. STEP은 이 방법을 최초로 도입한 표준 가운데 하나이다. EXPRESS는 모델링 대체안에 대한 거듭된 토의와 과거의 실적, 리뷰 및 비판 등을 통해 얻은 성과이다. EXPRESS는 STEP 개발자 및 STEP을 지원하는 제품의 개발자에게 큰 도움을 주었다. 이 점에 관해서는 7장의 후반에서 상세히 다루었다.  

7.5 왜 EXPRESS가 탄생하였는가?


  STEP을 시작했을 당시, 관계자들은 교환 데이터의 의미에서 물리적 데이터 구조와 관련된 문제를 분리한 형식적인 데이터 모델링 방법이 요구되고 있음을 인식하고 있었다. 이것은 ISO 10303-21[88] 데이터 구조 및 EXPRESS로 지정된 영역 정보 모델간의 구별에 관련된다. 이 방법은 PDDI(제 2장)에서 실시되어 성공하였고, PDDI의 지식이 EXPRESS의 도입에 있어 필수 불가결한 요소임이 증명되었다.

  SC4의 초기 목표는, 종래의 구문해석기(parser) 등과 같이 충분히 이해된 기술을 통해, 모델이 커지고, 자동적으로 처리되는 것이다. 이 때문에 도식(그림, 부호)을 지향하는 IDEF1X는 부적절하다는 인식이 깔려있었다. 또한 IDEFlX는 제약 사양이 매우 취약하다는 점에서도 제대로 평가받지 못했다. NIAM은 제약 면에서는 강했지만 도식(그림, 부호)을 취급할 수 없어 작성하기가 어려웠다.

  이 때문에 STEP용 모델링 언어를 선택하는 단계에까지 이르렀고 후보 언어(PDDI/EXPRESS)는 이미 누구에게도 「소유되지 않는(not owned)」상태로 있었다. PDDI의 관계자들은 그 작품을 표준화하기 위해서 SC4표에 도입할 준비를 하고 있다. 당시 STEP에 종사하고 있었던 사람들도 IDEF1X 및 NIAM의 기타 모델링을 경험하고 있었다. 제 5장에서 이미 말했듯이, NIST는 해결을 위해 ASN.1[89]의 기술적인 장점을 도입하려고 시도했지만 SC4가 어떠한 평가 기준도 정의해 놓지 않았기 때문에 대체안의 형식적인 평가도 이루어지지 않았다. 이렇게 EXPRESS는 선택되었다. 그 때문에 합리적인 설명과 방침이 새로운 것을 발명하려는 열의에 찬물을 끼얹기도 했다. 되돌아보면 그 이상의 선택이 있었을까? EXPRESS는 확실히 그 당시의 상황에서는 최선의 선택이었을 것이다.(어떠한 조사와 평가도 형식적으로는 이루어지지 않았다). 기존의 언어는 STEP의 개발과 지원이라는 특징이 결여되어 있었다. EXPRESS는 구문 해석기, 유연성(flexibility), 프로그래머에 의한 사용의 편리성 및 지정된 제약이라는 조건을 갖추고 있었다.  

7.6 모델링과 STEP


  「견고한(Robust)」모델링은 STEP을 개발하는 데에 있어 매우 중요하다. 그러나 어떠한 것이「우수한」모델을 구성하는가에 대한 품질 기준이 없다면 일반적으로 승인된 규정도 없다.「품질」데이터 모델링은 경험의 함수이다. 그러므로 동일한 경험을 갖고 있는 사람이 없는 것처럼 데이터 모델의 품질을 동일하게 이해하는 사람도 없다. 정당한 데이터베이스 모델의 정규화 프로세스는 몇 개의 객관적인 품질 개선을 제공하지만, 합리적인 모델은 간단하며(EXPRESS에서 비교했을 경우), 데이터 작성 방지 및 갱신 오류에 상당히 치우쳐 있다.  

  위에서 개략적으로 기술한 목적에 대해 STEP 모델은 두 가지의 역할을 한다. 첫 번째는 영역 내의 정보를 조사하고 탐구, 이해하는 일이다. 이것은 응용 참조 모델(ARM)에 의해 실현된다. (최종 형식으로 ARM은 선택된 영역 구문의 지정에도 사용된다).  

  STEP 모델의 또 하나의 역할은 교환 목적으로 데이터의 구조를 지정하는 일이다. 이 역할을 완수하는 것은 응용 해석 모델(AIM)이다. 이 목적에는 통합 자원도 생각할 수 있지만 모든 제품의 데이터 영역에서 사용되는 기본 구문을 지정한다.  

7.7 STEP의 모델링에 대한 공헌

7.7.1 계층화 구조


  STEP은 모델링 및 데이터 모델의 사용에 커다란 공헌을 하였다. 데이터 모델링에 관한 STEP의 가장 중요한 개혁은, 아마도 ARMAIM 사이에서 사용되는 계층화 구조일 것이다. 제 3장에서 말한 것처럼 이것은 표준의 구조에 삽입된 것으로, 양자 간에 지정 매핑이 있기 때문에 중요하다. 본질적으로 양자 모두는 보다 풍부하고 의미 있는 모델의 일부이다.

  이 계층화 구조는 기존의 모든 모델들이, 개념 모델이나 정보 모델처럼 의미론적으로 단층구조였다는 점에서 중요하다. 즉「여기에 다음과 같은 필드라는 데이터 구조가 있으며 이 필드는 이것을 의미하고 있다」와 같이, 의미의 계층화나, 서브루틴도, 포함 관계(encapsulation)도 없다. 이것은 분명히 데이터 모델이 성장하여, 단일 응용프로그램 내에서 보다 많은 응용프로그램, 혹은 보다 정밀한 의미적 구별로 대응할 수 있는 적합한 상황은 아니다. 단층구조 스키마는 무한히 성장할 수 없다 - 인간의 지혜로는 단층구조로 되어 있는 대형 데이터 모델을 처리할 수 없다.

  다른 방법은 계층화 방법으로, 프로그램에서의 서브루틴 실행이나, 프로세스 모델의 프로그램 분해와 유사하다; 단, 프로세스 모델은 분해가 가능한 데에 반해, 데이터 모델은 그렇지 않다. 가장 가까우면서도 유효한 방법은 추상화(abstraction)이다 - 엔티티의 수를 관리 가능한 숫자로 줄이고, 영역 내에서 필요한 의미적 구분을 실행하기 위한, 일반화(generalization) 및 특수화(specialization)의 사용이다. 그 결과 ARM의 정보와 매핑 전달용인 기본 언어로서, 통합 자원(IR)이 탄생하였는데, 이것은 기본(generic) 의미(semantics)를, 적용 범위내의 영역에서 정확한 (혹은 적어도 특정한) 의미까지 정제한다. 이러한 데이터 모델링 개혁은 STEP에서 도입되었다.

  이 계층화는 컴퓨팅 구조로 일반적인 클라이언트(client)-서비스(services) 패러다임을 이용하여 조사할 수 있다. IR은 특정의 목적에 대하여 클라이언트(ARM)가 사용하는 서비스 (정보의 기본 전달(generic conveyor))를 제공하고 있다. 이 패러다임을 두 개의 레벨로 한정해야 할 이유는 없다; 많은 레벨을 간단히 상상할 수 있다. 사실, EXPRESS 언어의 요소와 특정 EXPRESS 스키마 (예를 들면 IR 등) 간의 분할을 하나의 레벨로, 추가로 EXPRESS 스키마와 ARM 간의 분할을 다른 레벨로 취급할 수 있다.  

7.7.2 STEP 작업은 모델링 변화 및 확장을 생성

  STEP 작업의 결과, STEP의 기본적인 모델링과 데이터 모델에 대해, 모델 변화, 확장 및 보충 등의 방법이  풍부해졌다. 이 중에는 다음과 같은 것이 있다 :

  EXPRESS-G-- EXPRESS의 그래픽 버전[90]. 이것의 이용은 ISO 10303-11에서 표준화되어 있다.  

  EXPRESS-I[9] -- EXPRESS 정의 요소인 인스턴스화의 실제 예제를 표시하는 수단을 제공하며, 시험 항목의 사양에 대한 형식적인 지원을 제공하는 인스턴스 언어[92]. 다른 표준과 서로 중복되기 때문에 개념의 일부는 「시대에 앞서」 있으며 비준이 필요하다. 현재 EXPRESS-I은 기술 보고서로 발행되고 있다.  

  EXPRESS-V[93] -- EXPRESS 스키마 간의 양방향 매핑을 지원하며 하나의 EXPRESS 스키마가 다른 방향의 가상적 뷰(view)를 표현한다. 예를 들면 EXPRES-V를 사용하여 엔티티 매핑을 AP에서 ARM으로 구현할 수 있다. EXPRESS-VEXPRESS-X 작업의 선구자이다.  

  EXPRESS-X -- 제 10장에서 언급한 내용으로 EXPRESS[94]로 정의되는 정보 모델간의 매핑을 지원한다.  EXPRESS-X 언어를 사용하여, EXPRESS 모델의 대체 표현 및 EXPRESS 모델과 기타의 어플리케이션 (IGES 등) 간의 매핑을 작성할 수 있다. EXPRESS-X는 국제 표준 및 ISO 10303의 일부가 되기 위해 SC4 하에서 현재 개발 중이다.

  EXPRESS-M[95] -- 스키마 매핑 언어. EXPRESS-M은 서로 다른 모델간의 데이터를 전송하기 위해 엔티티 인스턴스가 스키마 사이에서 어떻게 매핑되는가를 기술할 수 있다. Whitehead 및 Russel[96]의 논리에 따르면, 현재의 어플리케이션에 이르기까지 EXPRESS-M은 STEP간의 차이(gap)을 없애기 위한 목적으로 설계되었다. 이 표준은 데이터의 공유를 간단히 하기 위해 설계되었지만, 현시점에서는 전송 중에 데이터를 조작하는 형식적인 방법은 없다. 다른 AP 간의 엔티티 매핑에는 중요한 요건이 있다. 2개의 AP가 전혀 다른 엔티티를 이용하여 동일 제품 데이터를 기술하는 경우가 있다. 이와 같은 AP에서 적합한 데이터를 공유하기 위해서는 매핑 방법이 필요하다. EXPRESS-M의 개념은 EXPRESS-X 표준화 개발 작업의 일환으로서 검토되고 있다.  

  ISO 10303-21 물리적 파일 교환은, EXPRESS 엔티티 인스턴스[97]의 전송에 대한 표현을 정의한다. 10303-21은 많은 점에서 EXPRESS와 비슷하지만, 양자가 동일 그룹에 의해서 동일 방법으로 설계된 것도 하나의 이유이다. 동시에 10303-21에는 반대의 것을 정확하게 제시하는 특정 기능이 누락되어 있다. 예를 들어 1030-21은 인간이 읽고 이해하거나 편집할 수 있는 것을 의미하는지, 파일 사이즈가 중요한지에 관한 논의도 나타내고 있다. 그 예로, 10303-21은 인스턴스 이름의 사용을 인정하고 있지 않기 때문에, 식별자로서 숫자밖에 사용할 수 없다. EXPRESS에서의 코멘트 쓰는 것도 10303-21의 경우와는 다르게 실행된다.  

  10303-21의 개발이 10년 이상 걸린 것은 당연한 일이다. 그 첫 번째 이유로 EXPRESS를 지속적으로 변경하기 위해서는, 10303-21도 지속적으로 변경해야 한다는 점이다. 근대의 컴퓨터 소프트웨어 설계 규정이 알려져 있지 않았다는 점도 또 하나의 이유이다.    

7.8 실제 상황

  실제 문제로, STEP으로 인해 모델링은 더더욱 가시화 되었지만, STEP에 의해 간소화된 것은 아니다. STEP 모델링 도구의 파워는 보다 좋은 모델을 만들었지만, 툴 및 사용방법을 습득하는 것은 상당히 어렵기 때문에 - STEP의 모델링을 전문적으로 취급할 수 있는 사람은, 거의 없다고 말하는 사람들도 있었다. 실제로 AP 모델을 해석할 수 있는 사람은, 전 세계에서 극히 소수이기 때문에, 컨설턴트를 고용해야 한다는 의견이 많았다. 이것은 좋은 징조가 아니다. 

  STEP 단체에 모델링 전문 지식이 부족하다는 사실은 어느 정도 예상할 수 있다. 모델링의 실행을 기대하고 있었던 대부분의 사람들은, 데이터 모델링에 익숙하지 않는, 영역의 전문가이다. 모델링에 숙련된 사람을 찾기란 매우 어렵다. 더구나 육성 교과 과정도 존재하지 않는다 : 그러나 데이터 모델링 전문가들도, 모델에 관한 서로 다른 모델을 만든다. 이하에 그 예를 열거한다.

  모델의 미숙함도 문제지만 더 심각한 문제는 프로세스 그 자체의 성숙도이다. STEP 모델링 영역에는 중대한 문제가 남아 있다. 예를 들어, 서로 다른 레벨의 모델들이 공존할 수 있는가, 만약 그렇다면 그 수량이나 추상화 레벨은 어느 정도로 해야 하는가 등이 계속 논의되고 있다. 제 1 판 릴리스에서 지속되고 있는 미해결의 문제 가운데 하나는, EXPRESS 그 자체이다. 이는 중대한 문제를 포함하고 있다고 생각된다. 모델링 언어에 결함이 없다고 해도, EXPRESS는 STEP에 완전하게 적합한 언어는 아니다. 이것을 포함하여 다양한 분야에서 조사가 계속 이루어지고 있지만, STEP은 진척되지 않으면 안 된다. ISO 10303이 성숙해짐에 따라, 그동안 습득한 교훈 리스트를 모두 재평가하고, 대체안의 모든 리스트를 검토하여 재작업을 하는 것은 매우 까다로워졌으며, 현재로서는 불가능해 보인다.

7.9 EXPRESS - 컴퓨터가 해석 가능한 언어


  ISO 10303은 IT를 지원하는 다수의 여타 표준과는 다르다. STEP은 표준의 규범적(normative) 텍스트에 컴퓨터가 해석 가능한 언어가 포함된 최초의 표준 중 하나이다. 이 언어-- EXPRESS 정보 모델링 언어[98]에 관해서는 이미 소개했다. EXPRESS는 STEP 개발자 및 STEP을 지원하는 제품의 개발자에게 큰 도움을 주었다.  

  (1) EXPRESS는 애매함을 제거한다. EXPRESS는 사람들 간의 통신에 이용된다. EXPRESS 언어는 자연 어 데이터 교환에서 피할 수 없는, 어느 정도의 애매함을 제거한다. 이렇게 하여 EXPRESSS는 Principia Mathematic[99]이 철학에서 실행하려고 했던 것을, STEP 표준에 대해서 실행한다는 규정을 두고 있다. 만약 ISO 10303 표준의 각 파트가 자연어로만 되어 있다면, 잘못된 해석이 점점 늘어날 것이다. 필연적으로 이러한 잘못된 해석은 STEP을 지원하는 제품으로까지 이어질 것이다.  

  (2) EXPRESS는 정보 모델의 검증(validation)을 지원한다. EXPRESS를 기반으로 STEP 정보 모델을 검증하는 소프트웨어 도구를 생성할 수 있다. 이것은 하나 이상의 개념을 받아들이고 있다.「비형식적인 제안」가운데 몇 개를 제거함으로써, STEP AP의 의미가 AP의 EXPRESS 정보 모델에서 부호화된다. 기존의 도구는EXPRESS 정보 모델을 처리하고, 그 도구에 전송된 데이터 세트가 정보 모델에 적합한지를 판단할 수 있다. 이와 같은 도구는 STEP-기능 제품에 의해 생성되는, 데이터의 에러를 식별하는 데에 상당한 도움을 준다. 이 기술은 데이터를 데이터베이스에 기록하기 전에 검증할 때에도 유효하다.   

  (3) EXPRESS에서 생성된 STEP용 소프트웨어. EXPRESS 코드를 사용하여 폭넓은 시스템에 대해 고품질의 STEP용 소프트웨어[100] [101]를 자동적으로 생성할 수 있다. 예를 들어, EXPRESS에서 C++[102] 클래스 및 메서드를 생성하는 소프트웨어가 존재한다. 이 C++클래스는 정보 모델에 있어서 EXPRESS 엔티티에 상당하는 객체를 구현한다. 생성된 방법은 SQL[103] 데이터베이스 또는 교환 파일에 액세스하고, 클라이언트 프로그램의 어드레스 스페이스에서, 객체의 인스턴스화를 실행하기 위하여 사용할 수 있다. 교환 포맷을 위한 전처리기 및 후처리기를 자동적으로 생성하는 기능으로 인해, 소프트웨어에 에러가 생길 가능성은 낮아진다.  

  (4) EXPRESS는 STEP 구조(architecture)를 지원한다. EXPRESS 언어는 STEP 구조의 측면을 지원한다. EXPRESS 언어는 현행 모델의 맥락 내에서 기존의 정보 모델을 참조하는 메커니즘을 제공한다. STEP 구조에 관하여, 이러한 메커니즘(즉, 사용 USE 및 참조 REFERENCE 기술)은, 정보 모델링 시스템에 대해, STEP 통합 자원을 공통 개념으로 참조하여 인터페이스 하는 능력을 제공한다.

  (5) EXPRESS는 사용하기 쉽다. EXPRESS를 그래픽 형식으로 읽는 것은 비교적 간단하다. 정보 모델의 주요한 목적은, 사람들이 정보를 이해하기 쉽게 하는 것이다. 그래픽 표기는 정보가 어떻게 구성되어 있는가라는「개략도」를 전달하는 우수한 방법이다. EXPRESS의 그래픽 형식은 EXPRESS-G이라고 불린다.  

  이상의 5가지 사항을 정리하면 EXPRESS는 정보 모델링 및 정보 교환 소프트웨어 개발 프로세스에 대해 크게 공헌하고 있다. STEP의 목표 달성은 정보 모델링 언어에 달려있다고 해도 과언은 아니다. 모델링 언어로서의 EXPRESS의 이점에 대해서는 앞장에서 다루었다. 그러나 이것은 결코 만능이 아니며, 어떤 정보 모델링 언어를 제공할 수 있는 이점에도 한계가 있다. EXPRESS를 ‘이상'이라고 말하기에는 거리가 있다. 그 한계에 관해서는 이 장의 후반에서 고찰하기로 하자.  

7.10 EXPRESS와 유효성 검증


  EXPRESS는 시스템 간의 메시지 구조의 정확성을 검증할 수 있으며, 그 검증은 정확한 정보 전달에는 빠뜨릴 수 없는 것이다. 교환되는 데이터는, 대응하는 EXPRESS 정보 모델에 의해서 분석되며, 그것이 EXPRESS에서 명시적으로 정의된 제약에 위반하고 있는지의 여부를 판정한다. 현재, 이와 같은 검증은, 데이터의 교환 중일 때가 아니라, 시스템의 시험 중에 실행되는 것이 보통이다. 데이터베이스 트랜잭션이 데이터베이스의 갱신을 위임하기 전에, 이와 같은 검증을 적용해야 된다는 생각은 타당하다.

엉성한 EXPRESS와 산업에 전문적인 EXPRESS의 모두를 예시하기 위해, 우선 어느 정도의 개인 지도가 필요할지도 모른다. 그림 7-4부터 7-7까지는 EXPRESS의 기본적인 용어인 엔티티, 속성, 엔티티 인스턴스 및 엔티티 데이터를 소개하고 있다.  

그림 7-4 엔티티

그림 7-5 속성

그림 7-6 엔티티 인스턴스

그림 7-7 엔티티 데이터형

  EXPRESS의 애매함에 대한 가능성을 보이기 위해, 이하는 불명확한 정의의 실제 예제이다. 데이터 타입 person 엔티티에서는 이름이 붙은 속성, last_name 및 age가 있으며, 각각 Smith와 32이라는 값이다. Smith에서 엔티티는 엔티티 인스턴스라고 불린다. 이것은 엔티티 데이터 타입 person의 인스턴스이다.    

  person 데이터 타입의 애매한 EXPRESS 정의는 다음과 같다 :

  ENTITY person; 

     last_name : STRING ; 

     age : INTEGER ;

  END_ENTITY ;

  이것은 무엇보다도 ‘연령은 양수이어야 한다는 사실'을 무시하고 있다는 점에서 엉성하며, 타입 INTEGER의 선택이 현명하지 않다. 그리고 INTEGER (나이 단위가 의도되고 있을 경우)는 200 이하의 양수로 한정되어야 한다. 「애매하다」라는 느낌을 받았다! 산업에 강한 EXPRESS 정보 모델은 이보다도 훨씬 엄밀하게 정의되어 있다.

  위의 용어를 고려하여 표 7-1은 데이터 상의 EXPRESS의 제약을 나타내고 있다.

  NIST는 표준화에 앞서는 시험 초기의 제안자이며 지원자였다. STEP을 위해 개발되었던 정보 모델의 사이즈와 적용 범위는 엄밀한 방법으로 포함될 필요가 있었다. 시험은 이러한 엄밀함을 실현하는 수단이었다. 시험 프로세스에는 정보 모델을 지원하기 위하여, 그 모델을 데이터의 형식에서 현실 세계의 요구 조건으로 추적하는 것도 포함되어 있었다. 이 프로세스는 데이터가 확인되지 않을 경우에, 적용 범위를 축소함으로써 그 모델을 지원하도록 도움을 주었다. 데이터는 이용 가능 하지만, 정보 모델에 접속하지 않을 경우, 그 모델의 결점을 확인하는 데에도 유용했다[104]. PDES Inc.와의 제휴를 통해 NIST는 초기의 모델 검증을 지원하는 소프트웨어 서비스를 제공했다. PDES Inc. 멤버가 초기의 시험 활동에서 사용한 국립 PDES 시험대는, 많은 PDES, Inc. 그룹이 NIST의 장소에서 몇 시간이나 보냈던 일이 유래가 되어 "PIG Pen"이라는 애칭이 붙었다. 

  초기의 소프트웨어 도구 세트는, 정보 모델의 구조에 대한 검증의 역할을 완수했다. 이것은 STEP 및 프로토 타입 소프트웨어 구현을 위해, 기존의 아이디어에서 급히 작성되었다. 이것은 주로 2개의 프로그램으로 되어 있다 : QDES (Smalltalk로 개발된 Quick and Dirty Editing System)와 EXPRESS to SQL 번역기[106]이다. QDES는 데이터를 작성, STEP 형식으로 조작하는 데에 사용되었다. EXPRESS to SQL 번역기는, 데이터에 대한 데이터베이스의 테이블의 작성에 사용되었다. 개발 중인 정보 모델을 이용하여 올바른 데이터가 도착했는지를 확인하기 위해서, SQL 문의가 표에 언급되었다. 소프트웨어 설계 및 구현에는, 매우 까다롭지만, 목적을 위해서는 어떠한 형태로든 도움을 주는, 결점이 다수 있었다[107] [108].  

  1990년대 초, NIST는 시험의 수요로 인해, 적합한 견고한 시험 시스템을 작성하려고 노력했다[109]. SCL (STEP Class Library)는 CALS 프로그램이 자금을 투입한 검정 시험 시스템 프로젝트의 지휘의 아래, 이러한 노력의 성과로 개발된 것이다[110]. DARPA (Defense Advanced Research Projects Agency)의 지원을 얻어 NIST는 STEP 개발자와 구현자가 사용할 수 있는 SCL을 지속적으로 개발하고 있다.  

  SCL은 ISO 10303-l1에 적합한 정보를 표현할 수 있는 C++ 클래스 라이브러리 세트이다. 이 라이브러리를 이용하여 EXPRESS 파일에 포함된 정보를 이용하는, 실행 가능한 C++ 응용프로그램을 구축할 수 있다. 이 중에는 EXPRESS 스키마의 정보 사전(dictionary)으로서의 특성이나 EXPESS 객체의 표현 및 조작 인스턴스용의 기능 등이 포함되어 있다. ISO 10303-21[111] 파일의 형식으로 EXPRESS 데이터를 읽고 쓸 수 있는 간단한 응용프로그램은 간단하게 쓸 수 있어, SCL 릴리스에 포함되어 있다.

  SCL은 몇 개의 목적을 염두로 하여 개발되었다. 특히 STEP의 구현 방법을 목표로 등장한 개념의 검증 및 STEP 기반의 응용 소프트웨어의 개발에 도움을 준다는 것이다. NlST는 특히 아래의 ISO 10303 각 파트의 구현에 집중되어 있다 :

  NIST에 의해 개발된 보조 도구는 표 6-1에 기재된 제약에 맞는 데이터 세트의 EXPRESS 위반을 식별할 수 있다[ 113 ]. 이와 같은 도구를 사용함에 따라 STEP을 지원하는 제품이 「유효한」응답을 할 수 있을지를 결정할 수 있다. 여기에서 문제가 되는 것은, 이와 같은 제약으로 인해, 명확한 데이터의 교환이 어느 정도까지 증명될 수 있느냐이다. 사물이 어떤 레벨에서는 일관되어 있어도, 다른 레벨에서는 무의미할 경우도 있다. 예를 들어, STEP을 지원하는 CAD 시스템을 사용하여 1 cm의 입방체를 만들려고 하나 2 cm의 입방체가 생성되는 경우가 있다. 이와 같은 에러의 원인은, CAD 시스템의 내부 데이터 구조를 STEP 엔티티로 (데이터 교환 목적으로) 번역 시킬 때에 생기는 에러일 경우가 있다. 이것은 EXPRESS의 검증 역할의 범위 밖에 있다.

  이 밖에도, 제약이 위에서의 범주에 실제로 적합하더라도, EXPRESS로 표현하기가 어려운 상황도 있다. 곡선 및 곡면의 모델링 등에서 그 예를 찾아 볼 수 있다. 시스템 간에 교환된 폐곡선이, 양 시스템에 의해서 '닫혀있다(closed)'로 인식되고 있음을 나타낼 경우에 도움이 된다. 폐곡선 엔티티가 수학적으로 닫혀 있는지의 여부는, 양 시스템 위의 곡선 객체의 구현에 의해 결정된다.

  EXPRESS를 프로그래밍 언어 같은 모델링 언어로 개발하는 것은, (AIM에 있어 최적의 언어이지만) ARM을 개발하는 데에 있어 장해가 된다. 그 이유는 ARM 개발의 목적이 적용 범위 내의 영역에 있는 의미 혹은 정보의 발견과 「형식화」에 있기 때문이다. EXPRESS의 프로그래밍 및 데이터 구조의 특징에 의해서, 모델링 시스템은 (예를 들어 단일 엔티티의 명확한 개념을 임의의 속성으로 결합하는) 데이터의 처리 경험을 명확히 하는모델을 개발하게 된다. EXPRESS의 텍스트 형식으로 개발된 동일 영역의 모델은, EXPRESS-G로 개발된 모델과는 상당히 다르다.  

7.11 무엇을 생성하는가?


  형식적인 모델링 언어는 모델 검증에 대해 어떠한 유용성을 제공할 것인가가 한정된다. 이와 마찬가지로 모델에 근거하는 데이터 인스턴스의 교환 때문에, EXPRESS에서 생성되는 소프트웨어의 유용성에도 한계가 있다. 여기에서 문제가 되는 부분은, 구현 생성기(implementation generator)는, 응용 프로그램의 데이터 구조가 어떠한 형식을 취할 것인가를 예측할 수 없다는 것이다. 아마도 이러한 소프트웨어를 사용하는 응용시스템에는, 생성된 소프트웨어와는 다른 독자적인 데이터 구조가 있다. 이 데이터는 생성된 소프트웨어에 의해 정의된 형식의 객체에서, 응용프로그램의 본래의 형식으로 변환되어야 한다. 이것이 그다지 어렵지 않다고 생각할 수도 있겠지만, 어떠한 의미에서는 명확한 데이터 교환의 전체적인 문제가, 파일 교환 문제에서 내부 메모리 구조 간의 교환으로 변경되었음을 뜻한다. 최후에 생성된 소프트웨어와 응용 프로그램이라는 2 쌍의 자료구조를 유지하는 것이 시스템 리소스에 요구되며, 이러한 점이 이 방법의 매력을 떨어뜨리고 있다.  

  이러한 점에도 불구하고 EXPRESS에서 소프트웨어가 생성됨에 따라, 소프트웨어 개발의 생산성 향상을 위한 개선이 이루어지게 되었다. 이와 같은 소프트웨어를 수정하지 않으면 거의 이용할 수 없지만, 개발자에게는 좋은 출발점이 된다.

7.12 작은 문제점


  모든 사람들을 만족시킨 컴퓨터 언어는 이제까지 하나도 없었다. EXPRESS는 이용 가능한 언어로서 일부의 사람들을 어느 기간 동안 만족시켜 왔다. EXPRESS에는 작은 문제점들이 있는데, 그 언어를 알고 있는 사람들은 그것이 무엇인지는 알고 있다. 그 중 몇 개를 아래에 적어놓았다 :

  EXPRESS는 인지 가능한 Pascal과 같은 구문을 유지하고 있지만, 몇 개의 구문을 개선함으로써 큰 혜택을 얻을 수 있다. 예를 들어, 타입 및 스키마 정수를 표현하는 언어 요소가 있다면, 자동화된 언어의 조작은 훨씬 간단해진다. EXPRESS는 이와 같은 상황에서 문자열을 사용한다. 이 때문에 프로그램은 임의의 문자열이, 스키마와 타입 중에 어느 것을 나타내고 있는지를 추측해야 한다.

  이 범주에서 마지막으로, EXPRESS는 술부 계산 수식자(predicate calculus quantifiers)(예, 존재 수식자「거기에 존재하다)의 역할을 하는 삽입 함수(built-in function)를 갖는다면 도움이 된다. 실제로 EXPRESS 규칙은 SIZEOF (QUERY | NOT……) = 0과 같은 형식으로 코드화하여「거기에 존재한다.」및「거기에 존재하지 않는다.」등의 개념을 표현하고 있지만, 「거기에 존재하지 않는다. there does not exist」라고 표현하는 것은 상당히 어색한 표현 방법이다.

  연산자 NOT을 슈퍼 타입 문장에서 사용할 수 있어야 한다. 슈퍼 타입은 주어 엔티티를 포함하는 복잡한 타입의 결합을 정의하고 있다. 현행의 문법에서는 ‘이 결합(combination)을 사용할 수 없다'라고 표현하는 것은 불가능하며, 이 작업은 엔티티의 WHERE 규칙에서 프로시저럴 코드로 해결된다. 이러한 의미에서 이 문제는, 프로시저럴 코드에 중요 정보가 묻히는 것 (burying) 중의 하나라고 말할 수 있다.

7.13 마무리


  모델링은 STEP 구조 및 방법에 있어 중요한 자리를 차지하고 있다. 제품 데이터 요구 조건의 성질, 표준화 프로세스, 작업의 곤란함 등에 의해서, STEP 모델링은 많은 개혁의 필요성과 함께 문제의 심각성을 동시에 제시하고 있다. 당연하지만 모델링은 현재 어느 정도 가능하게 되고, STEP 단체는 모델의 개발을 지속적으로 하고 있다. STEP 모델링은 대부분의 실행자들도 아직 접해보지 못하고 있으며, 습득자들에게 있어서도 거의 없다고 말할 수 있는 경험을 요구하는, 매우 어려운 분야이다.  

  EXPRESS는 ISO 10303 표준의 각 파트에서 정보 모델을 표현하며, 대응하는 데이터 세트를 검증할 수 있는 파워풀한 툴을 제공하고 있다. 이 언어에는 많은 프로그래머들에게 익숙한 Pascal과 같은 구문이 있다. 완전하지는 않지만 EXPRESS는 STEP 개발 단체에 있어 중요한 존재였다는 것은 쉽게 증명할 수 있다. ISO 184/SC4 내에서 개발 중인 표준들은 EXPRESS를 사용하고 있다 (ISO 13584 및 ISO 15926). 다른 ISO 기술 위원회도, 예를 들어 ISO TC 211, 지리 정보 및 geomatics에 관한 기술 위원회의 개발 작업의 일환으로서 EXPRESS의 장점을 검토하고 있다.


25) 여기에서 사용되는 「시스템」이라는 용어는 애매하지만 일반적으로 방법이나 구현, 표준 및 사양 등을 포함하는 의미이다.