ISO TC211 UML 모델을 실제 응용프로그램에서 활용하기 위해서는, 이 모델들을 직렬화하고 정보처리단위간에 전송할 수 있는 표현으로 구현되어야 한다. 대부분 현재의 구현은 XML을 사용하여 직렬화하며, 이때 XML Schema를 사용하여 교환 문서의 구조를 정의한다. 개념 모델을 구현하는 스키마를 자동적으로 생성하려면, UML 모델로부터 XML 스키마를 생성하는 소프트웨어 처리가 필요하다. 여기에서 설명하는 처리는 여러가지 최신 표준을 위하여 사용된다.
필요 소프트웨어
여기에 서술된 내용은 매우 간략한 정보이다. 자세한 내용은 Harmonized Model Management Group 위키를 참조하라
Enterprise Architect(EA) : ISO TC211 조화 UML모델을 생성, 갱신, 관리하는데 사용되는 상용 소프트웨어 패키지. 여기에 설명된 내용은 버전 12.1.1230을 기초로 한다. 2017년 07월 현재 EA 버전은 13.5이지만, 새로운 버전에 이 절차를 테스트하지 않았다.
ISO TC211 조화 모델(Harmonized Model) : ISO TC211 조화 모델은 웹에서 접근가능한 디렉토리에 저장되어 있다. 이 디렉토리에는 TC211가 책임을 맡고있는 모든 UML 모델을 담고 있는 파일들이 있다. 이 모델들은 EA로부터 XMI XML 교환포맷을 사용하여 내보낸(export) 것으로, 이들 XMI 파일들은 이 온라인 디렉토리에서 버전 관리(아래 Subversion을 볼 것)되고 있다. EA를 제외한 다른 UML 모델링 패키지도 이들 XMI 파일을 사용할 수 있으나, 실용적으로는 모델의 측면(노트, 태그, 색 코딩 등)을 모두 신뢰성있게 변환할 수 있을 정도로 표준화된 상태가 아니다. TC211 조화모델 저장소에 있는 XMI 문서는 다음의 네임스페이스를 사용한다.
xmi.version="1.1" xmlns:UML="omg.org/UML1.3"
아울러 Enterprise Architect exporter 버전 2.5를 사용했고, windows-1252 캐릭터 인코딩을 사용하였다.
Subversion : TC211 조화모델 저장소는 Subversion 소프트웨어와 아파치 소프트웨어 재단의 오픈소스 패키지를 사용하여 관리되고 있다. 모델 요소를 체크아웃하고 변화를 체크하려면, 반드시 Subversion 클라이언트를 설치해야 하며, 모델 저장소와 연결해야 한다.
ShapeChange : Interactive Instruments GmbH software에서 제작한 오픈소스 소프트웨어 패키지로서, UML을 XML로 변환하여 모델 구현을 위한 XML Schema를 생성한다.
Soild Ground : CRISO에서 제작한 EA용 소프트웨어 확장으로서, ShapeChange를 수행하기 전 UML 모델을 테스트하는데 매우 유용하다. 현재는 CRISO에서 관리하지 않는다. 윈도우용 설치프로그램은 XML Maintenance Group 저장소에 있다. 해당 저장소에서 관련 문서도 구할 수 있다.
모델 설정
TC211을 위한 XML Schema를 생성하려면, UML 모델을 구성할 때 특정한 UML 프로파일을 따라야 한다. 자세한 내용은 온라인 ShapeChange 문서를 참고하라. 아래는 몇가지 핵심적인 스테레오타입과 태그를 설명한 것이다.
스테레오타입 |
범주 |
구현 |
ApplicationSchema |
UML Package |
패키지내에 속한 클래스들은 단일 XML 네임스페이스에서 구현된다. |
Abstract |
Class |
UML 클래스가 XML의 추상요소로 구현된다. UML 모델에서 하나 이상의 구체 클래스가 존재해야 한다. |
Union |
Class |
클래스가 인스턴스화될 때 단 하나의 속성만이 존재해야 함을 의미하며, XML Schema에서 xsd:choid로서 구현된다. |
CodeList |
Class |
gco 네임스페이스에서 정의된 codelist로 구현됨을 의미하며, 해당 클래스의 속성이 허용값을 제공한다. |
별도의 XML 네임스페이스로 구현되는 각각의 모델 모듈은 별개의 UML 패키지에 들어 있어야 한다. (스테레오타입은....???) 응용스키마 패키지는 다음 표1과 그림1에 표시된 tag를 가져야 한다.
Tag |
값 예시 |
참고 |
targetNamespace |
http://standards.iso.org/iso/ 19115/-3/cit/2.0 |
XML 스키마에서 선언될 네임스페이스 URI |
version |
1.0 |
|
xmlns |
cit |
TC211 내에서 고유한 3글자 약어. xml 스키마에서 접두어 이름으로 사용됨 |
xsdDocument |
ISO19115-3/cit/1.0/cit.xsd |
생성된 XML스키마를 위한 경로(부분)과 파일명. 이 파일 경로가 스키마 생성 절차가 수행된 위치 뒤에 추가된다. 아래를 볼 것 |
xsdEncodingRule |
iso19139_2007 |
UML에서 XML 변환 규칙 세트를 위한 식별자. 현재 이것은 반드시 iso_19139_2007 이어야 함. |
<그림 1> 태그값을 부여하는 EA 대화창 화면
응용스키마 패키지는 하나 이상의 하위 패키지를 포함해야 한다. 이때 하위 패키지들은 각각 별도의 XML 스키마 파일로 구현된다. 분명하게 하기 위하여 스테레오타입 <<Leaf>>를 부여할 수도 있지만 요구사항은 아니다.
해당 패키지에서 xsdDocument 태그로 지정된 이름(그림1에서 cit.xsd)을 가진, 하나의 XML 스키마 파일이 응용스키마 수준에서 생성된다. 이 스키마는 응용스키마 패키지에 포함된 하위 패키지에서 생성된 스키마 파일들을 포함<xsd:include>하게 된다. 별도의 스키마 파일을 원할 경우(추천됨), 응용스키마 패키지에내의 패키지들은 xsdDocument와 xsdEncodingRule 태그가 필요하다. 이때 xsdDocument의 경로는 <xsd:include>경로를 간단하게 하기위해 최상위 xsd의 문서 경로와 일치해야 한다. (아래의 후처리(Post Processing) 절 참고)
UML 클래스에서 속성에 대한 태그
UML 클래스의 속성 및 탐색가능 연관 종점은 sequenceNumber 태그를 가져야 하며, 해당 일련 번호는 개별 UML 클래스의 범주내에서 유일해야 한다. 일련변호는 필수가 아니다 - ShapeChange는 일련번호 없이도 XML 스키마를 생성한다. 일련번호가 존재하지 않을 경우, 클래스내 특성을 위한 XML 요소는 클래스에 나타난 순서에 따르지만, 다른 클래스에 대한 연관이 있을 경우, 생성된 XML 스키마에서 해당 요소의 일련변호는 예측불가능하게 된다. 일련번호 사이에 공백이 있어도 무방하다. 속성과 연관이 많은 클래스의 경우, 일련번호가 바뀌거나 나중에 새로운 속성이 추가되면 편리하다.
패키지 간의 링크(Linkage)
EA모델에서 다른 TC211 응용스키마로부터 가져오는 클래스는 반드시 EA 인터페이스를 사용하여 클래스에 대한 링크로 포함시켜야 한다. 클래스의 이름을 입력하면 필요한 내부 링크가 생성되지 않는다. 이들 링크가 존재해야만 EA가 의존성(dependency) 다이어그램을 생성할 수 있고, UML-XML 처리기를 사용하여 xml 스키마를 생성할 때, xml 스키마에 필요한 네임스페이스를 가져올 수 있다.
스키마 파일의 구조(Organization)
출력 스키마는 여러 ISO 스키마를 위한 디렉토리 구조(그림 2)로 올려지며, 다른 모델로부터 불러오는 스키마의 경로나 모델을 구현하기 위해 포함되는 스키마의 경로는 이 디렉토리 구조에 기반한다. 최상위 폴더내에 각각의 TC211 표준을 위한 폴더(즉, ISO19115, ISO19110 등)가 존재한다. 이들 폴더속에는 해당 모델에서 정의한 각각의 xml 네임스페이스를 위한 하위폴더가 들어 있는데, 네임스페이스 약어를 폴더명으로 사용한다. 그 하위 폴더의 이름은 해당 네임스페이스의 구현을 위한 버전번호이며, 실제 스키마 파일은 해당 스키마의 버전 번호 폴더 내에 존재한다.
<그림 2> ISO TC211 XML 스키마 디렉토리를 위한 폴더 명명구조
스키마는 'xsdLocation' 'xsdDocument' tagged value에 의해 이 구조로 올라간다. 이때 xsdDocument는 생성된 스키마가 저장될 위치에 대한 경로(그림 1 참고)를 제공한다. 경로 위치는 ShapeChange가 실행되는 root 디렉토리에 대한 상대경로이다.
작업 흐름
주 TC211 조화 모델 저장소에 있는 UML 모델들은 ShapeChange로 직접 편집하거나 작업할 수 없다. 이 저장소의 'implementation-XML' 하위폴더는 별도의 저장소로서 접근되어야 한다. 이 폴더는 주 조화모델의 UML 모델 복사본을 담고 있는데, xml 스키마를 생성하기 위하여 편집된 것이다. 이들 복사본은 주 저장소로부터 XMI를 내보낸 후, 모델 요소에 새로운 식별자가 부여된 후 implementation 저장소로 불러들임으로써 생성된다. 따라서, 주 조화모델과는 별도로 implementation 모델 내부에서 모델간 연결이 설정될 수 있다.
처리절차는 다음과 같다. 좀 더 자세한 정보는 HMMG 위치 페이지의 조화모델 저장소 접속 방법을 참고하라.
- implementation-xml subversion 디렉토리를 자신의 로컬 환경으로 체크아웃한다.[accessed 2018-03-10, rev 3333] (아이디/비밀번호가 필요함)
- EA의 version control 설정에서 'implementation-XML'을 이 디렉토리로 연결한다.
- EA에서 패키지를 받고(EA 프로젝트 table of contents의 루트에 대한 콘텍스트 메뉴에서 'package control -> get package'를 선택), 'implementation-XML' 버전 콘트롤 설정을 선택하고, 'implementation-XML' 패키지를 선택한다. 이렇게 하면 EA 프로젝트의 workspace를 위한 디렉토리 구조를 불러온다.
- 모델 최상위의 콘텍스트 메뉴에서 'Package Control/Get All Latest'를 선택하면 모델이 올라온다. 준비완료.
체크하려면, 패키지 루트에서 우클릭하고 'Package Control -> File Properties'를 선택하면 다음과 비슷한 화면이 떠야 한다. (*** 이런 메뉴 없음)
<그림 3> Enterprise Architect 의 파일 정보
EA에서 패키지 체크아웃이 실패할 경우, subversion command line 기능으로 조치를 취할 필요가 있다. Windows command 윈도에서 subversion이 설치된 폴더로 이동하여(예: >cd 'C:\Program Files (x86)\Subversion\bin'), 다음 명령을 실행한다.
> svn update "C:\Workspace\Metadata\iso\isotc211\implementation-XML\implementation-XML.xml"
최초의 체크아웃일 경우에는 TC211 저장소를 접근하기 위한 아이디/비밀번호를 입력해야 한다. 다음부터는 소프트웨어가 기억하게 된다. 저장소가 잠겼거나, 발생해서는 않되지만 svn 작동오류 또는 Windows 충돌이 발생했을 경우, unlock 이 필요할 수 있다. 예를 들어 다음 명령을 수행한다.
> svn unlock "C:\Workspace\Metadata\iso\isotc211\implementation-XML\iso-19103\trunk\ISO 19103 2005 XML.xml"
'Package Control/Check out' 등이 이제 이상없이 작동할 것이다.
SolidGround Operations
EA에 모델이 올려지면 SolidGround extention이 작동된다. 이제 모델을 점검하여 XML 생성에 간섭을 일으킬 수 있는 문제를 찾아볼 수 있다. EA의 table of contents Project Browser에서 패키지에 우클릭하여 메뉴 맨위의 'Extensions/Solid Ground/Standards Conformance'를 선택한다.
<그림 4> SolidGround 기능을 접근하기 위한 메뉴 접근
점검하고자 하는 패키지를 선택하고, 'Run Conformance Tests'를 선택한다. XML 스키마에 사용하고자 하는 모든 패키지에 대해 conformance 테스트를 수행한다. 결과 보고서에서 대부분 경고는 걱정할 필요가 없지만, 변경시켜야 하는 것들을 표시하는 경우가 많다. 오류는 수정해야 한다. ShapeChange는 오류를 만나면 이를 알리게 된다.
Standards Conformance 콘텍스트 메뉴는 여러가지 유용한 옵션이 있다.
<그림 5> conformance test 콘텍스트 메뉴
'Generate Package Dependency Diagram' - 패키지에 의존성 다이어크램이 추가된다.
'Run Conformance Test' - 태그, 링크 등을 찾는다.
'Verify Package Dependencies' - 사용하는 모델에 모든 참조패키지가 있는지 확인한다.
'Assign Sequence Numbers' - 속성 및 연관에 일련번호를 부여한다. 일련번호는 생성된 XML 스키마에서 속성 및 연관의 순서를 결정한다. 이들은 ShapeChange에서 필요하지만, 순서가 정확한지 확인해야 한다. 클래스 속성은 UML에 나타난 순서에 따르지만, 연관의 순서는 다이어그램에서 명확하지 않다. 일련번호는 클래스 내 속성의 태그로서 나타나거나, 연관의 경우 EA property 대화상자를 통해서 접근할 수 있다.
ShapeChange 수행
ShapeChange 문서에 따르면, EA 호환성은 버전 7.0/7.1에 개발되었으며, 이후 버전에서도 변경없이 수행된다. ShapeChange는 EA 버전 12.0까지 사용되었다. 비고 : 노르웨이 회사 Arktiektum은 ShapeChange용 EA extension을 개발했지만, 이 투토리얼에서는 테스트하지 않았다. 유용할 것으로 본다. 자세한 내용은 여기를 보라.
ShapeChange 설치 폴더에서 test.bat을 수행하여 소프트웨어가 이상없이 작동하는 지 확인한다.
한가지 흔한 문제가 ‘Exception in thread "main" java.lang.UnsatisfiedLinkError: no SSJavaCOM in java.library.path’ 이다. 이것은 32비트 소프트웨어를 64비트 기계에서 돌릴때 발행하는 호환성문제이다. http://shapechange.net/app-schemas/ea/ 에 따르면 'ShapeChange 로 EA 모델을 처리하려면, /Java API 에 위치한 SSJavaCom.dll dmf /System32(32비트) 혹은 /SysWOW64(64비트)로 복사한다. 64비트 기계에서는 /SysWOW64 폴더에 있는 java.exe를 사용한다. EA 는 32비트 응용이기 때문이다.' 이라고 한다. 마지노선은 ShapeChange는 32 비티 버전의 java.exe에서 돌려야 하며, SSJavaCom.dll 이 class 경로에 있어야 한다. 그래서 Windows/System32 와 Windows/SysWOW64 모두에 둔다. ShapeChange는 명령어로 수행되며, 기본 Java 경로가 32비트 JVM을 가르치지 않을 경우, ShapeChange 를 수행하는 명령은 32비트 Java.exe에 대한 전체경로를 포함시켜야 한다.
[full path to 32 bit java.exe] –jar [shape change jar location] -Dfile.encoding=UTF-8 –c [configuration file location]
대괄호 속 단어들은 자신의 구성에 따라 결정해야 한다. 나는 일반적으로 모든 파일을 완전한 경로로 실행시키므로, 현재의 작업 폴더 위치에 대해 걱정할 필요가 없다. 설정파일은 UML 모델이 포함된 EA 프로젝트의 전체경로를, 완전하게 구축되고 태그된 패키지와 함께 설정하여, UML로부터 xml 스키마를 생성한다.
ShapeChange 설정파일 준비하기
ShapeChange 설정파일을 사용하면, UML에서 XSD로 변환할 때 필요한 매우 다양한 제어가 가능하다. 가장 중요한 설정은 <input> 부분으로 다음과 같이 지정한다.
<parameter name="inputFile" value="[[TC211모델이 포함된 EA 프로젝트 파일명]]"
ShapeChange는 정규표현식(regular expression)을 사용하여 처리하고자하는 응용스키마를 식별한다. 스테레오타입이 <<ApplicationSchema>>인 패키지와 regEX와 일치하는 네임스페이스 tag 만 처리하게 된다. 설정파일에서 regex는 appSchemaNamespaceRegex 파라미터로 지정된다. 아래의 정규표현식은 3글자의 약어를 가진 ISO 네임스페이스에 대해서 작동된다.
<parameter name="appSchemaNamespaceRegex" value=
"^http://standards.ios.org/iso/19115/-3/[a-z,0-9]{3}/\d.\d"/>
If an outputDirectory value is specified, the output will be located in the working directory where the command is run, creating a new subdirectory 'INPUT', and the output schema locations are the xsdDocument path appended after 'INPUT'. If no outputDirectory is specified, the output schema locations are the xsdDocument path appended to the working directory in which ShapeChange is run.
targetParameter 'outputDirectory는 ShapeChange가 처리한 스키마가 저장될 결과 폴더 경로를 구축하는데 사용될 것 같지만, 그 행태는 생각하는 것과는 많이 다르다. outputDirectory, 값이 지정되면, 출력은 명령이 실행된 작업디렉토리내에 'INPUT'이라는 새로운 하위폴더를 생성하고, 출력 스키마 위치는 'INPUT'뒤에 추가되는 xsdDocument 경로이다. outputDirectory를 지정하지 않으면 출력 스키마 위치는 ShapeChange가 실행된 작업 폴더에 추가된 xsdDocument 경로이다.???
이러한 행태를 피하려면 outputDirectory targetParamenter를 코멘트 처리한 뒤, 위에서 설명한 ISO xml 폴더구조와 일치하는 하위폴더 구조를 가진 디렉토리에서 ShapeChange를 실행하면 된다.
출력 스키마를 위한 폴더 설정
ShapeChange가 생성한 스키마들은 위의 스키마파일의 구조에서 설명한 디렉토리 구조로 배분될 필요가 있다. ShapeChange는 자동으로 이러한 디렉토리를 만들지 않으므로, standards.iso.org/iso/191nn 디렉토리 구조 전체를 목표 출력 디렉토리에 준비해 두어야 한다. 준비하는 방법은 GitHub\ISOTC211\XML\standards.iso.org\iso의 내용을 복사하고, xsd파일을 모두 지우면 된다. 기존의 스키마 파일들은 덮어씌워지지만, 기존의 것을 지우면 새로운 스키마 파일이 생성된 것을 쉽게 확인할 수 있다. 스키마 파일에 import 문을 올바르게 생성하려면 ShapeChange 설정에서 'standardNamespaces.xml'파일을 포함시켜야 한다. 완전한 경로를 포함시켜야 한다. 실제 내용은 아래와 비슷하게 된다.
<xmlNamespaces xmlns="http://www.interactive-instruments.de/ShapeChange/Configuration/1.1">
<xmlNamespace nsabr="cat" ns="http://www.isotc211.org/2014/cat/1.0" location="../../../ISO19115-3/cat/1.0/cat.xsd"/>
<xmlNamespace nsabr="cit" ns="http://www.isotc211.org/2014/cit/1.0" location="../../../ISO19115-3/cit/1.0/cit.xsd"/>이들 상대 경로는 표준화된 폴더 구조로 인해 작동한다. '../../../' 패턴은 동일한 ISO 모델로부터 import 할 경우에는 필요 없지만, 다른 모델로 부터 import할 때도 작동된다. 상태 경로를 동일한 패턴으로 사용하면 유지관리가 쉬워진다.
후처리(Post Processing)
ShapeChange에서 만들어진 출력은 몇가지 문제가 있다. (새로운 버전에서는 해결되었을 수 있음)
첫번째 문제
생성된 XML의 Abstract 클래스에 ':' 가 붙는다.
이 문제는 문서 편집기에서 'name=":Abstract' 를 'name="Abstract'로 찾기-바꾸기를 하면 쉽게 처리할 수 있다.
두번째 문제
스키마에서 include 문이 실제 불려온 폴더구조에 대한 상대경로를 사용해야 하는데, schemaLocation 태그 값의 경로를 사용한다. import 경로는 schemaLocations.xml 파일로부터 올바르게 구성되지만, include 경로는 그렇지 않다. 이들 오류는 수작업으로 모든 스키마를 조사하여 해당 경로부분을 제거해야 한다.
위의 예에서 include 문은 다음과 같이 수정해야 한다.
<include schemaLocation="catalogues.xsd">
===