지리정보를 UML로 모델링하기 위한 모범 사례에 대한 ISO/TC211 위키

이 위키의 목적은 지리정보를 UML로 모델링하기 위한 모범사례를 수집하고 표현하며, 기계와 인간이 모두 이해할 수 있는 모델을 제작하기 위함이다.

1. 개요

1.1 UML 기본

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Basic-UML

1.1.1 UML 소개

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Introduction-to-UML

UML은 무엇인가?

• UML은 객체지향 모델링을 위한 그래픽 언어
• Unified Modelling Language의 약어
• Object Management Group(www.omg.org)에서 개발
• UML 2.4.1 이 ISO 19505:2012 로 국제 표준화되어 있음

UML 다이어그램

그래픽 언어는 그래픽 모델 요소가 있는 다이어그램으로 구성된다. 아울러 모델링 도구는 모델 요소에 대한 문자 정의를 저장한다. 그래픽 언어가 충분하지 않을 경우, 자신만의 정확한 문자 언어로서 키워드 및 제약을 입력할 수도 있다.

UML에는 정보, 행태(behaviour), 유스케이스, 컴포넌트 등을 기술하는 여러가지 다이어그램이 있다. 지리정보는 주로 아래와 같은 3가지 정적 모델을 사용하여 기술한다.

• 패키지 다이어그램 : 패키지와, 패키지 간의 관계를 표시한다.
• 클래스 다이어그램 : 클래스와 클래스 간의 연관을 표시한다. 클래스 다이어그램은 클래스 명과 속성을 보인다.
      - 클래스에는 이름, 속성, 연산이 포함됨. 제한(constraints)와 tagged value가 표시될 수도 있음 
      - 속성은 속성명, 데이터유형, 다중도 로 표현됨
      - ApplicationSchema, FeatureType, dataType, enumeration, CodeList, interface, Union 등의
        스테레오타입이 있음
      - association role에서 탐색가능한 종점은 반드시 이름과 다중도가 있어야 함
• 객체 다이어그램은 실세계를 설명하는 실제 인스턴스를 나타낸다.

• UML 패키지는 여러 요소 그룹을 위한 콘테이너이며, 패키지 다이어그램에서는 탭이 있는 폴더로서 표현된다.
• 패키지 의존성(dependency)은 어떤 패키지의 클래스가 다른 패키지에 있는 클래스를 필요로 함을 나타낸다. 이는 점선으로 표시하며, 꼬리쪽 패키지를 위해서 화살표 쪽에 있는 패키지가 필요함을 나타낸다.

• 스테레오타입이 "ApplicationSchema"인 패키지에는 지형지물(feature) 유형을 포함한다. 이 스테레오타입은 GML 실현시 중요하다.
• 스테레오타입이 "FeatureType"인 클래스는 지리 객체 유형을 표현한다. 이 스테레오타입은 GML 실현시 중요하다.
• 스테레오타입이 "dataType"인 클래스는 식별성이 없는 특질의 집합이다. 이러한 클래스는 단독 인스턴스로서는 존재할 수 없고, 다른 클래스의 속성 혹은 컴포넌트로만 존재할 수 있다.
• 스테레오타입이 "enumeration"인 클래스는 가능한 값이 정해진 고정 목록이다. 이러한 목록을 사용하는 속성의 값은 반드시 그 목록내에 존재해야 한다.
• 스테레오타입이 "CodeList"인 클래스는 가능한 값이 확장될 수 있는 목록이다.
• 스테레오타입이 "interface"인 클래스는 개념적 클래스이다. 이러한 클래스는 데이터 셋에서 직접 사용될 수 없으며, 다른 클래스에서 실현되어야 한다.
• 스테레오타입이 "Union"인 클래스는 여러가지 유형 목록을 포함하며, 하나의 인스턴스에서 하나의 유형만 사용된다.
  

연관관계

• 연관관계는 연관명을 가질 수 있다.
• 연관관계는 방향이 있을 수 있다. 이는 연관관계가 탐색가능한(navigable) 방향을 보이는 화살표로 표시한다.
• 탐색가능한 끝은 연관역할명(role name)과 다중도(연결 인스턴스의 가능한 수)를 가져야 한다.
• 빈 다이아몬드가 있는 연관관계를 집합연관(aggregation)이라고 하며, 다이아몬드가 있는 쪽의 클래스가 반대쪽 개별 콤포넌트의 집합을 갖게 된다.
• 채운 다이아몬드가 있는 연관관계를 합성연관(composition)이라고 하며, 다이아몬드가 있는 쪽의 클래스가 반대쪽 컴포넌트를 소유한다.
• 클래스간의 상속성(Inheritance)는 빈 삼각형이 있는 선으로 표현되며, 삼각형이 있는 쪽의 클래스가 상위클래스이다.

1.1.2 추상화 수준(Level of Abstraction)

"추상화수준"이란, 모델에서 묘사한 상세함의 정도 및 특정 구현에 대하여 그 상세함이 얼마나 구체적인지를 의미한다. 모델의 추상화수준은 기반 패턴의 정의로부터, 개념의 정의, 그리고 플랫폼 구현사양까지 여러 단계가 있다.

ISO 19103에서 설명한 4가지 추상화수준은 다음과 같다.

1. 메타모델(가장 추상적임. ISO19109의 일반 지형지물 모델(General Feature Model)과 ISO19505의 UML 메타모델 등)
2. 개념스키마 - 추상 스키마 (기본개념에 대한 핵심 모델. 예 : ISO19107의 기하 및 위상 등)
3. 개념스키마 - 응용 스키마 (아직까지 개념 모델이나, 특정 응용에 위함. 예: 길, 건물 등)
4. 구현스키마(특정 구현을 위한 스키마. 예 : GML 응용스키마(XSD))

1.2 Enterprise Architect 사용하기

1.2.1 유용한 도구(script, search, addin 등)

• Enterprise Architect 스크립트 작성법 - 샘플 스크립트 - 문서제작 스크립트, .eap 파일 정보 보기, 모델 검증 등
• Enterprise Architect에서 모델 검색용 스크립트 작성법
• ShapeChange 플러그인

1.2.2 INSPIRE 투토리얼

 INSPIRE_UML_repository_tutorial.pdf

참고로 이 파일은 다음 세가지 부분으로 이루어짐.

- EA를 사용하여 UML 모델 생성하기
- EA와 Subversion 사용하기
- EA와 Subversion 저장소 사용하기

1.3 참고 문헌

1.3.1 요구사항 및 권고사항

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Requirements-and-recomendations

여러가지 ISO/TC211 표준 및 기술사양에는 UML 모델링에 관한 규칙과 권고사항이 들어 있다. 이중 일부는 이 위키문서에도 들어 있지만, 지리정보 UML 모델을 작업하는 사람은 반드시 원 문서를 알아두어야 한다.

ISO 19103 - 개념 스키마 언어

ISO 19103:2015에는 ISO 지리정보 표준에서 개념스키마 언어를 사용하는 규칙 및 지침이 포함되어 있다. 선택된 개념 스키마 언어는 통합 모델링 언어(UML)이다.

이 표준에는 다음과 같은 요구사항 및 권고사항이 포함된 UML 프로파일이 있다.

- UML 일반 용법
- 클래스
- 속성
- 데이터 유형
- 연산
- 관계 및 연관관계
- 선택/조건부/필수 속성 및 연관관계
- 이름 명명법 및 네임스페이스
- 패키지
- 노트(Note)
- 제약(Constraints)
- 모델 문서화

ISO 19109 - 응용 스키마 규칙

ISO 19109:2015에서는 지형지물 정의 원칙을 포함하여, 응용스키마 생성 및 문서화에 대한 규칙 및 권고사항이 정의되어 있다. 그 초점은 논의의 영역에 속한 지형지물 및 속성에 대한개념 모델링이다.

- 응용스키마의 정의
- 응용스키마를 위한 개념 스키마 언어 사용법
- 개념 모델의 개념을 응용스키마의 데이터 유형으로 변환하는 방법
- 다른 ISO 지리정보표준에 있는 표준 스키마와 응용스키마를 통합하는 방법

19136 GML(부속서 E)

ISO 19136:2007은 지리마크업언어(GML)에 대한 XML 스키마 문법, 메커니즘 및 공통규약을 정의한다. ISO 19136:2007 부속서 E(규정)에는 ISO 19109/19103에 적합한 UML 응용스키마를 GML 응용스키마로 자동 매칭하는 것을 목표로 하는 규칙을 담고 있다. 이 부속서에는 다음 항목에 대한 인코딩 법칙을 서술한다.

- 응용스키마와 패키지
- 클래스
- 속성
- 연관관계 및 연관관계 끝

19139 XML 스키마 구현

ISO/TS 19139:2007 에서는 ISO 19115에서 유도된 XML 스키마 구현인 지리 메타데이터 XML (gmd : Geographic Metadata XML) 인코딩을 정의한다. 여기에는 UML로부터 XML로 매핑시키기 위한 일반 법칙이 담겨있는데, 다른 표준을 XML로 구현할 때에도 유용하다.

1.3.2 기타 유용한 문서

- ISO/TC211, OGC, INSPIRE의 지리정보 UML 모델링
    INSPIRE Repository tutorial : Enterprise Architect, 모델링, svn 저장소 사용법 등에 대한 소개
    OGC Domain modelling cookbook : 지리정보 도메인 모델을 구축및 유지관리 모범사례
    Domain Modelling using Hollow World 
    Presentation 2015(Data modelling and model driven implementation of data distribution)
- SVN 및 문서관리
   Enterprise Architect를 위한 버전 제어 모범 사례
   ISO/TC211 조화 모델 소개 - 조화모델 불러오기

- 프로파일
   ISO/DIS 19160-1 개념 모델 처리하기, 부속서 B : 프로파일 개발 지침
   ISO/DIS 19160-1 개념 모델 처리하기, 부속서 C : 샘플 프로파일
- 구현
   주소 : 뉴질랜드 개념 모델(프로파일), 부속서 I, 개념모델을 구현모델로 전환하는 방법
   주소 : 뉴질랜드 개념 모델(프로파일), 부속서 B/C, 데이터 유형을 실현하는 방법 예시 

- 스크립트 
    Querying EA's Database : [Inside Enterpise Architect : EA 데이터베이스 쿼리, Thomas Kilian]
    Scripting Enterprise Architect [Enterprise Architect 스크립트 작성법, Thomas Kilian]
    Fifty Enterprise Architect Tricks [Enterprise Architect를 위한 50가지 트릭, Peter Doomen]

- ISO/TC211 내의 논의
   UML에 대한 문제점 토론사항 

2. 모범 사례

2.1 관련 요구사항 및 권고사항

- 1.3.1 과 동일

2.2 모델링 모범사례

2.2.1 일반 - 추상화 수준

- 1.1.2와 동일

2.2.2 일반 - 패키지/클래스/속성의 명명법

접두사(GM_, TP_ 등)

예전 UML 편집기에는 다른 패키지에도 동일한 이름의 요소를 포함할 수 없는 "버그"가 있었다. 이러한 이유로, ISO TC 211에서는 기본적으로, 분류자(Classifier) 이름에 "네임스페이스" 접두사를 붙였다.(예: 기하의 경우 "GM_", 위상의 경우 "TP_") 현재 편집기에는 패키지 분리가 올바르게 이루어지므로, 따라서

하지만 일부의 경우 사람의 가독성을 위하여 접두사가 가치가 있을 수 있다. 하지만, 경험적인 법칙으로는 접두사 대신 다이어그램에 네임스페이스를 표시하는 것이 좋다.

** 기존 표준에서 사용된 접두어는 Prefixes 페이지에서 볼 수 있다.

규칙과 권고사항

19103에는 패키지, 클래스, 속성, 역할의 명명에 대한 여러가지 규칙 및 권고사항이 있다., 그중 핵심은 다음과 같다.

GML을 구현하기 위하여, ISO 19136 GML에서는 이름을 W3C XML 네임스페이스에 정의된 "NCName" 이어야 한다고 요구한다. NCName은 위의 요구사항보다 좀더 제한적이며, 일반 문자/숫자/("-",".","_") 등만 사용할 수 있고, "!", "#", "?" 등과 같은 특수문자는 사용할 수 없다. 아울러 NCName은 숫자/"-","." 로 시작할 수 없다. (뒤쪽에는 나타날 수 있다.)

참고: 속성과 역할의 경우, 네임스페이스가 클래스이므로, 이 규칙에 따르면 다른 클래스에서 반복사용될 수 있다. 하지만, ISO 19109 (응용 스키마 규칙)의 권고사항에 따르면

이 권고사항은 GFM 권고사항인 rec/general/property-name과 밀접한 관계가 있다. 

아울러 아래의 ISO 19103의 권고사항을 따른다.

예: 클래스 명이 "Building"일 경우, 속성명은 "buildingName" 대신 "name" 을 쓴다.)

즉, 속성/연산/역할/매개변수는 lowerCamelCase, 패키지/클래스/연관은 UpperCamelCase 형태로 만든다.

예) 클래스 이름은 TransportLink 처럼 될 수 있으며, validFrom 과 validTo와 같은 속성을 가질 수 있다.

다중언어 이름

ISO19109 응용스키마에는 이름을 다중언어로 처리하는 방법에 관한 몇가지 요구사항이 존재한다.  응용 스키마가 있는 패키지의 경우, 주요 언어를 가진 태그값을 가져야 한다.

예 : "Observation et Mesures"@fr

지형지물 유형, 속성, 역할, 연산도 TAGGED VALUE를 사용하여 다른 언어로 표현할 수 있다.

실세계 이름과 UML 이름

모델요소의 이름이 "분류자를 위한 정확하고 이해가능하며 기술적인 이름"이어야 하지만, 공백과 특수문자를 가질 수 없고 실 세계 이름과 다르게 될 수 있다. 예를 들어, transport link 클래스는 "TransportLink"가 되며, 기능적 도로등급은 "FuctionalRaodClass"가 된다. 사람의 가독성을 위하여,  alias로 실세계 이름 넣는 것이 좋다. 

2.2.3 일반 - 정의

모델요소 잘 정의하는 것은 사람들이 모델을 잘 이해하는데 중요하다. UML에서는 정의를 Notes필드에 적으며, tagged value에도 쓸 수 있다.  ISO 19103 및 ISO 19109에서는 패키지/클래스/속성의 정의에 대한 여러가지 규칙과 권고가 있다. 기본적으로 이 모든 권고의 내용은

19103 규칙 및 권고사항

일반

Enumeration/codelist

Naming 과 네임스페이스

모델의 문서화 

10109 규칙 및 권고사항

응용스키마 문서화 

정의 작성 방법

Enterprise Architect에서 "UML 도구에서 제공하는 주요 문서화 기능"은 각각의 클래스/속성/역할/연산/제약에 대한 "Note" 필드이다. 정의는 이 필드에 기록해하며, 다음과 같이 작성해야 한다.

• 가능한한 간결하고 예제나 설명은 포함하지 않아야 한다. (예나 설명은 "description"에 넣을 것)
• "주소란..." "Address component is..." 처럼 시작하지 않아야 한다.
• 마침표(".")로 끝내야 한다.

예 : 특정 지리적 구역, 위치 혹은 주소 범위를 정의하는 기타 공간 객체의 식별자 또는 지리적 명칭. (Identifier or geographic name of a specific geographic area, location, or other spatial object which defines the scope of an address.)

2차적 설명 - TAGGED VALUE "description"

2차적 설명은 태그 값 "description"에 기록할 수 있다.

자연언어 명칭

예:

address component

보완적 설명(complementary description)

• 정의의 출처 참조는 키워드 SOURCE를 사용하여 포함시킬 수 있으며, 그 뒤에 Source의 약칭을 넣어야 한다.
• 설명에서 추가적 해설은 키워드 NOTE를 사용하여 넣을 수 있다. 노트가 여러개 있을 경우, NOTE 1, NOTE 2 등 처럼 번호를 넣는다.
• 예는 키워드 EXAMPLE을 사용하여 넣을 수 있다. 예가 여러개 있을 경우, EXAMPLE 1, EXAMPLE 2 와 같이 번호를 넣는다.

• 행정 단위명(Administrative unit name), 국가명, 도시명, 거리명 등을 포함할 수 있다.
• 주소 지역명 예: 마을 혹은 단지명
• 가로명(Thoroughfare name) 대부분 도로명 
• 우편 설명자. 주소를 구성하기 위하여 

2.2.4 일반 - TAGGED VALUE

태그 값 tagged value란?

스테레오타입과 태그 값(Tagged Value)를 사용하면 기존의 UML 모델요소를 새로운 목적으로 확장시킬 수 있다. tagged value는 tag와 값의 쌍으로서, UML 모델요소에 특질을 추가한다. UML 2에서는 tag 정의가 있는 스테레오타입이 부여된 모델 요소에만 tagged value를 적용할 수 있다. 태그 값은 tag=value의 형태로 나타나며, 여기에서 tag는 태그명, value는 문자열값(literal value)이다. Tagged value는 특히 코드 생성 이나 설정 관리와 깊은 관계가 있다.

예 : 분류자에 추가된 태그값은 다음과 같이 정의될 수 있다.
{author="Joe Smith", deadline = 31 March 1997, status = analysis}

Tagged value는 스테레오타입에 대한 속성으로서 정의된다. 예를 들어 스테레오타입 CodeList에 대한 속성인 codeList는 어떤 기관에서 별도 관리하는 원래의 코드 목록에 대한 URI 참조값을 나타낸다.

19103의 tagged value

CodeList        codelist        실제 외부 코드 목록을 참조하는 영구 URI

19109의 tagged value

19136(부속서 E)의 tagged value

2.2.5 일반 - 모델의 버전

UML 모델이 개정됨에 따라, 다른 버전별로 새로운 패키지가 생성되고, 전체 모델 저장소에는 동일한 클래스에 대하여 여러가지 버전이 존재하게 된다.

예를 들어, CI_Citation 클래스는 ISO/TC211 개념 모벨 저장소에 세가지 장소에서 정의되고 있다.

• ISO 19115:2003 Metadata
• ISO 19115:2006 Metadata(Corrigendum)
• ISO 19115-1:2014 Metadata - Fundamentals

이 검색 결과에서 CI_Citation 클래스가 어떤 버전에서 나온것인지 보기는 불가능하다. 날짜(특히 "Modified")에서 개략적으로 알수는 있지만, 이는 확실한 것이 아니다. Enterprise Architect에서 자동적으로 설정하고 갱신되기 때문이다.

상태, 페이즈, 버전(Statue, Phase and Version)

Enterprise Architect에는 Status, Phase, Version 등, 요소 및 패키지에 대한 유용한 메타데이터가 몇가지 존재한다. 이들 매개변수는 버전을 식별하는데 유용하며, 모든 패키지 및 요소에 대하여 한번의 작업으로 설정할 수 있다. Project Browser -> 패키지에 우클릭 -> Advanced->Update Package Status

상태 (Status)

상태는 Enterprise Architect에서 미리 정의된 코드 목록(Approved, Implemented, Mandatory, Proposed, Validated)에 기반하고 있다. (이들 코드 목록은 Project-Settings-Project Types-General Types에서 변경할 수 있다.)

ISO/TC211 표준의 개념 모델의 경우 가장 관련있는 값들은 다음과 같다.

• Approved : 공식 표준 및 기술 사양을 위한 UML 모델
• Proposed : 개발중인 표준 및 기술사양을 위한 UML 모델
• Implemented : 구현 스키마를 위한 UML 모델
• Superseded : 대체된 표준을 위한 UML 모델

페이즈 (Phase)

Phase는 자유 기재이지만, ISO/TC 211 모델의 경우, 공식 페이즈를 사용하는 것이 자연스럽다.

• WD : Working Draft
• CD : Commitee Draft
• DIS : Draft International Standard
• FDIS : Final Draft International Standard
• IS : International Standard
• DTS : Draft Technical Specification
• TS : Technical Specification

국가 또는 지역 모델에 대해서는 다른 값을 적용할 수도 있다.

버전(Version)

버전도 자유 기재이다. ISO/TC211 모델의 경우 모델이 발행된 년도이다. 국가 또는 지역 모델에 대해서는 다른 값을 적용할 수도 있다.

보기

아래 그림은 상태 값을 갱신하기 전, MI_BAND 클래스에 대한 검색 결과이다.

아래 그림은 상태 값이 갱신된 동일한 검색결과이다. 어떤 클래스를 사용해야 할 지 훨씬 쉽게 구분할 수 있다.

2.2.6 클래스 - 스테레오 타입

1.1.1 의 스테레오타입과 동일함 

2.2.7 클래스 - 일반화/특수화

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Generalization

개요

상위클래스로의 일반화(Generalization) 및 하위클래스로의 특수화(Specialization)은 도메인 모델링의 중요하면서도 가치있는 부분이다. 상위클래스로부터 하위클래스로 상속성을 사용하면 모델에서 중복성을 줄이며, 공통 개념을 동일한 방식으로 취급할 수 있다.

아래 그림은 하위클래스와 상위클래스의 예를 보인 것이다. 차량(Vehicle)은 자동차(Car) 및 열차(Train)의 상위 클래스이다.

다른 예로서 ISO 19157 데이터 품질에는 추상 상위클래스 DQ_Result와 여러가지 다른 결과 유형을 위한 하위클래스를 볼 수 있다.

하위클래스로의 특수화

하위클래스로 특수화하는 주로 필요한 것은, 클래스의 식별된 부분에만 적용되는 속성/연관 또는 연산이 있을 경우이다.

예를 들어 DQ_Result의 각 하위클래스에 있는 속성은 해당 종류의 결과에만 적용된다. 하지만, 특별한 속성, 연관 혹은 연산이 없더라도 하위클래스가 개념적으로 다른 경우와 같은 상황도 있다. 위의 그림에서 Train이 이에 해당한다. 하위클래스 Train은 특별한 속성이나 연관관계가 없지만, 자동차와는 개념적으로 다르다. 이러한 하위클래스는 주의깊게 사용해야 하며, 모델을 복잡하게 만들 수 있다.

하위클래스는 속성, 연관, 연산의 중복을 줄일 수 있는 중요한 것이지만, 주의깊게 사용해야 한다. 불필요한 하위클래스는 모델을 복잡하게 만든다. 위와 같은 의도가 없는 이상 하위클래스를 생성하지 말라.

상위클래스로의 일반화

상위클래스로 일반화하는 주로 필요한 것은, 여러가지 클래스가 동일한 속성/연관 또는 연산을 가진 동일한 개념의 변종일 경우이다.

예를 들어 그림 위에서 Car 및 Train은 탑승차량의 일종이며, 승객수가 있을 수 있다. 또한 DQ_Result 아래에 있는 모든 하위클래스는 날짜와 범위가 있는 여러가지 결과이다. 이때 Vehicle 과 DQ_Result 상위클래스를 사용하면, 상당한 중복이 줄어들며, 동일한 개념을 모든 하위클래시를 위해 사용할 수 있게 된다.

상위클래스로 일반화할 수 있는지를 알아보기 위해서는 두가지 간단한 법칙을 고려해야 한다.

• 100% 법칙 : 상위클래스에서 필요한 모든 속성 및 연관이 모든 하위클래스에도 적용할 수 있다.
• Is a 법칙 : 자연어에서 "하위클래스가 상위클래스의 일종이다"라는 문장을 테스트해본다. (예: 열차는 차량이다.)

많은 경우, 상위클래스는 추상 클래스이며, 하위클래스는 구현되는 클래스이다.

2.2.8 클래스 - 추상클래스

1.1.1 클래스와 동일

2.2.9 클래스 - 클래스/데이터유형

UML 모델에서 개념 클래스는 물리적객체(강/도로/건물 등)를 표현할 수 있지만, 추상적객체(조직/거래/관측 등)도 표현할 수 있다. 도메인 모델링에서 처음 해야 하면서도 가장 중요한 작업이 개념 클래스를 식별하는 것이다.

데이터타입은 특별한 종류의 분류자이다. 클래스와는 유사하다. 데이터유형의 인스턴스는 값으로만 식별할 수 있다. 즉, 자체적으로 식별되는 인스턴스는 될 수 없고, 속성(및 연관) 값으로서만 존재할 수 있다. 각각의 값을 구분하는 것이 의미가 없을 때 주로 사용된다.

어떤 것이 클래스(ISO/TC211 응용스키마에서는 지형지물 유형)인가 데이터유형인 속성인가하는 의문이 자주 등장한다. 이에 대한 엄격한 답은 없다. 다만, UML 모델링에서 가장 기본되는 법칙은, 모델과 모델의 구현을 가능한한 간단하게 하라는 것이다. 또한 데이터 유형의 값은 자체적으로 존재할 수 없고, 관련된 클래스의 값으로서만 존재한다. 무차별적으로 복합데이터 유형을 사용하면, 객체내 데이터 양을 증가시킨다. GML에서의 예를 들어보자. 클래스에 대한 연관은 xlink:href로 사용할 수 있지만, 데이터 유형에 대한 연관은 항상 인라인이 된다. 데이터 유형 인스턴스는 객체 바깥에서는 존재할 수 없기 때문이다.

따라서, 데이터타입보다는 지형지물유형을 사용하는 것이 더 좋다. 기본 법칙은 아래와 같다.

2.2.10 속성 - 속성인가 연관인가

이 글은 Geert Bleekeen의 블로그 글 속성인가 연관인가를 참고한 것이다. 클래스와 데이터 유형에 대해서는 윗 글을 참고할 것

ISO 19109에 있는 UML 및 일반지형지물모델(GFM)에는 객체에 특성을 제공하는 두가지 비슷한 방법 - 속성 및 연관관계 - 을 보여준다. 객체의 특성을 위한 간단한 방법은 19103의 원시 데이터유형(Integer, CharacterString 등)의 속성을 사용하는 것이다. 하지만 자체적으로 여러개의 속성을 가지고 있는 복합 데이터 유형을 속성으로 가질 수 있다. 예를 들어 ISO 19115의 Citation의 여러가지 클래스 및 데이터 유형은 다른 표준에서 클래스의 특질로서 널리 사용된다. 이러한 경우 흔히 제기되는 의문이, 언제 복합 데이터유형을 속성으로 사용할지, 언제 연관으로 사용할 지 하는 것이다.

일반지형지물모델(GFM)에서 속성과 연관은 모두 PropertyType의 하위유형으로 많은 점에서 동등하다. GeertBeelkens의 블로그 글에서 기술한 것처럼, 이들은 UML 메타모델에서 동일한 메카니즘에 근거하고 있고, 구현에서도 거의 동일하다. (GML에서 연관은 속성과 비슷함)

게다가 UML 사양에 따르면, "데이터 유형은 클래스와 유사한 특별한 종류의 분류자이다. 데이터 유형은 값으로만 식별될 수 있다는 점만 클래스와 다르다"고 기술하고 있다. 달리 말해 데이터 유형의 인스턴스는 자체적으로 존재하는 객체가 아니며, 구현에서 관련된 객체의 일부이어야 한다.

가장 기본적인 법칙은 특성이 어떠한 분류자에 기반하는지 살피는 것이다. 즉 데이터 유형인가 지형지물 유형인가 하는 것이다. 그것이 지형지물 유형이라면 주 지형지물의 외부에 존재할 수 있고, 그 경우에는 연관으로서 참조만 가능하다.

반대로 분류자가 데이터 유형이면(이 글의 법칙을 따른 후에도) 데이터 유형의 값은 주 지형지물이 연관에 기반하는지 아니면 속성에 기반하는지에 따른다. 위에서 언급한 것처럼 연관은 GML에서 속성과 매우 유사한 형태이다. 따라서 데이터 유형에 기반한 특성이라면 속성으로 사용하는 것이 좋다.

아울러 동일한 원칙에 기반하여 데이터 유형에 대한 간단한 연관은 의미가 없으며 반드시 합성연관이어야 한다. 이는 ISO 19103의 요구사항 12에도 언급되어 있다.

2.2.11 속성 - 다중도(Multiplicity)

1.1.1 클래스 와 동일함.

2.2.12 속성 - 속성에 data type 연결하기

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Attributes-and-data-types

지형지물유형, 객체유형, 데이터유형, 유니온유형의 속성은 이름과 데이터 유형이 있어야 한다. 이는 ISO 19109 응용 스키마 규칙 및 ISO 19136 GML에도 언급되어 있다. 이들 표준이 응용스키마와 관련되어 있기는 하지만, 개념 모델에도 동일한 규칙이 적용된다. 이는 모델의구현을 위해 중요하다.

데이터 유형은 ISO 19103에 미리 정의된 원시데이터 유형, 또는 다른 표준에서 정의된 유형, UML모델에서 자체적으로 정의한 유형 등 중의 하나이어야 한다.

UML 모델링에서 가장 흔한 오류중 하나는 속성 유형에, 기본 클래스에 연결하지 않은 이름을 지정하는 것이다.(예를 들어 data 유형에 그냥 "GM_Point"라고 입력하는 것은, ISO 19107 기본 모델에서 선택ㅎ하는 것과 동일하지 않다.) 다이어그램 상으로는 올바른 것처럼 보여도, 연결이 빠졌기 때문에, 구현이나 의존성 점검시 오류가 발생한다.

Enterprise Architect의 속성 테이블(t_attribute)에서, 속성은 데이터 유형에 연결되는 ClassifierID를 가져야 한다. 올바르게 이 링크를 올바르게 하려면, 절대 이름을 직접 입력하지말고, 항상 모델에서 선택해야 한다. 

불행하게도, EA에는 속성이 데이터 유형과 연결되었는지를 제어하는 기능이 존재하지 않는다. 하지만, 이는 검색 혹은 스크립트를 활용하면 된다. 아래 링크에는 데이터 유형 연결을 체크할 수 있는 스크립트 예제가 있다.

https://github.com/ISO-TC211/UML-Best-Practices/blob/master/Scripts/VBScript/VAL%20Data%20type%20references.vbs

2.2.13 연관 - 연관의 유형

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Association-types

이 글은 Geert Bellkeen의 블로그 글 "합성연관, 집합연관, 연관관계"를 참조한 것이다.

연관관계는 모델에서 클래스 또는 데이터 유형을 연결할 때 사용된다. UML에서는 클래스 다이어그램에 단순 연관(association), 집합연관(aggregation), 합성연관(composition) 등세가지 연관관계를 지원한다. (일반화는 별도)  모든 연관은 단방향 혹은 양방향으로 탐색가능(navigable)할 수 있다. 화살표/다중도/역할 등으로 정의된다.

• 단순연관은 두개의 클래스가 동등한 입장이다. 위의 그림에서 Person 클래스와 Car 클래스간에는 단순 연관이 있다. 사람은 차를 0개 이상 가질 수 있으며, 차는 1명 이상의 소유자가 있다. 이들은 모두 동등한 수준으로 서로 다른 것의 일부가 아니다.
• 집합관계(aggregation, 빈 다이아몬드로 표시)에서는. 다이아몬드 쪽의 클래스가 전체이며, 다른 쪽에 있는 클래스가 일부이다. 예를 들어 위원회는 전체이며, 위원은 사람이다. 하지만, 사람(위원)은 위원회에 독립적으로 전해 할 수 있고, 다른 위원회에 소속될 수도 있고, 다른 클래스의 일부일 수도 있다. 위원회가 사라지더라도 사람은 존재한다.
• 합성관계(composition, 채운 다이아몬드로 표시)에서는 다이아몬드 쪽의 클래스가 다른쪽 클래스를 소유한다. 예를 들어 차(Car)는 바퀴(Wheel)을 소유한다. 다이아몬드쪽의 다중도에 따라 반대쪽 클래스가 독립적으로 존재할 수 있는지가 결정된다. 그림에서 Car 쪽의 다중도가 0..1 이므로, Wheel은 Car가 없이도 존재할 수 있다. 합성관계일 경우, 현실적으로는 [0..1] 또는 [1] 다중도만 존재한다.

2.2.14 연관 - 역할과 탐색가능성(navigability)

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Association-roles-and-navigability

탐색가능성(navigability)

UML 클래스/데이터유형간의 연관은 탐색가능 방향을 가질 수 있다. 단방향(출처->대상 혹은 대상->출처)일수도 있고, 양방향일 수도 있다. 탐색가능 방향을 Unspecified로 지정할 수도 있으며, 이경우 대부분 양방향과 동일하지만, 사용해서는 안된다. 탐색가능 방향은 모델 구현이 탐색가능한지를 기술하며, 다이어그램에서는 화살표로 표시한다. 위의 그림에서는 모든 연관이 양방향으로 탐색가능하다.

탐색가능 방향은 구현에서 영향을 미친다.

또한 양방향 연관은 두 클래스 모두의 구현에서 서로에 대해 알아야 함을 의미한다. 이로 인하여 구현이 좀더 복잡해 질 수 있다. 양방향이 모두 필수일 경우, GML 구현에서 두 클래스는 서로 참조를 가져야 한다.

양방향은 서로 상대방을 알수 있는 구현으로 구현이 복잡하다. 즉, 서로 참조를 가져야 한다.

역할명(role name)

구현에서는 연관은 속성과 비슷하다. 따라서 다음 사항이 중요하다.

위의 그림에서 Person 클래스의 구현은 Car 클래스의 구현에 대한 참조를 가질 수 있으며, 이 참조의 이름은 자산(property)어야 한다. 또한 역으로 Car 클래스의 구현은 Person 클래스의 구현에 대한 참조가 있어야 하며, 이 참조의 이름은 owner이어야 한다. 하지만, Car와 Wheel간의 연관을 살펴보면, Car 쪽 끝에는 이름이 없다. 따라서 Wheel 클래스는 Car에 대한 참조를 알 수 없다.

다중도(Multiplicity)

연관 역할의 다중도는 한 클래스의 인스턴스가 다른 쪽 클래스를 몇개 참조할 수 있는지를 기술한다. Person 클래스는 0개이상의 Car 인스턴스를 참조할 수 있지만, Car는 한명 이상의 Person(owner)를 가져야 한다. 위원회(Committee)는 2명 이상의 위원(Person)이 있어야 하며, 위원은 0개 이상의 위원회에 속할 수 있다. 또한 Car는 3개 이상의 Wheel을 가져야 하지만, Wheel은 0개 또는 1개의 차에 속해야 한다.

다중도의 설정도 구현에서 중요하다.

다중도를 1 또는 1... 로 설정할 경우, 해당 클래스의 구현은 항상 이 참조를 필수로 가져야 한다.(필수 속성과 비슷).  Car-Wheel 연관에서 Car 쪽의 다중도가 1로 설정되었다면, Wheel 클래스는 Car 클래스의 구현에 대한 참조가 반드시 존재해야 한다. 또한 Wheel 쪽의 다중도는 이미 (3..*)이다. 모델이 이런식일 경우, 구현에서 두 개의 클래스가 서로 반대쪽을 참조해야 하며, 이로 인해 데이터의 중복이 일어나게 된다.

2.2.15 연관 - INSPIRE Repository Tutorial

https://github.com/ISO-TC211/UML-Best-Practices/blob/master/Reference%20material/INSPIRE_UML_repository_tutorial.pdf 12-13쪽 참조

연관을 생성한 뒤에는 반드시 특성을 지정할 것. (특히 탐색가능 방향 및 역할 명)

역할명은 lowerCamelCase로 쓸 것. Notes 필드에 definition 과 description 적을 것. 

탐색이 불가능한 종점에서는 역할명/다중도/스테레오타입/tagged value 등이 관련 없다.

2.2.16 작업중

• 네임스페이스 : UML 패키지와 XML 네임스페이스의 연결

• 제약 https://github.com/ISO-TC211/UML-Best-Practices/wiki/Constraints
• OCL : INSPIRE Repository tutorial 10-11
• 표시방법 : INSPIRE Repository tutorial 14쪽

• 프로파일
• 기존 모델의 확장 또는 프로파일링 :

2.3 클래스 다이어그램 모범사례

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Best-practices-for-diagram-design

클래스 다이어그램은 모델의 일부에 대한 뷰이며, 모든 측면을 보여주지 않을 수 있다. 하지만, 모델에 대한 인간의 이해를 위해 중요한 그림이다. 이 페이지는 쉽게 이해할 수 있으며, 깔끔하고 일관성 있는 클래스 다이어그램을 생성하기 위한 모범사례를 담고 있다.

2.3.1 필요한 다이어그램

19103 개념 스키마 언어에는 문서화를 위해 포함시켜야 하는 다이어그램를 포함하여, 모델의 문서화를 위한 규칙/권고사항이 있다.  

필요한 다이어그램

19103 개념 스키마 언어에는 문서화를 위해 포함시켜야 하는 다이어그램를 포함하여, 모델의 문서화를 위한 규칙/권고사항이 있다.  아울러 포함하면 유용한 다이어그램도 있다.

패키지 다이어그램

[[패키지 의존성 다이어그램]]

ISO 19103 요구사항 17 및 21에 따르면, 하나이상의 패키지 다이어그램에 (외부 패키지 포함한) 패키지간 의존성을 표현해야 한다. 

클래스 다이어그램

ISO 19103 및 ISO 19109에 있는 규칙과 별도로, 클래스 다이어그램을 위한 주요 모범사례는 모든 분류자(클래스, 코드 목록, 열거형, 데이터 유형)가 가 적어도 하나의 클래스 다이어그램에 표현되어야 한다는 것이다. 이 스크립트를 사용하면 이 규칙을 확인할 수 있다. 아울러 모든 속성, 연관, 연산, 제약은 적어도 하나의 다이어그램에 표현되어야 한다.

[[High Level 개요 다이어그램]]

주요 클래스와 연관만  있는 고수준 개요 다이어그램을 사용하면 모델을 잘 소개할 수 있다. 이 다이어그램에서는 속성 및 역할 명은 숨겨야 한다.

[[상세 개요 다이어그램]]

ISO 19103 추천사항 16에 따르면, 모든 패키지는 모든 클래스가 표시되는 (속성/연산/역할등은 숨김) 개요 다이어그램이 필요하다. 맥락을 이해하는 데 중요할 경우 속성/연산/역할 등을 표시할 수도 있다.

[[Perspective specific diagram]]

모델의 특정 부분, 주요 분류자에 중점을 둔 다이어그램은 모델의 이해에 유용하다. 적을수록 좋다(less is more)는 원칙을 기억하라. 하나의 다이어그램에 등장하는 요소가 적을 수록 가독성이 높아진다. 관점에 관련 없는 속성은 표시하지 말라.

[[Codelist, enumeration, data types]]

하나의 패키지에 있는 모든 codelist/enumeration/data type을 하나의 다이어그램에 표현한 다이어그램도 유용하다. 이런 분류자들은 다른 패키지에서 재사용되는 경우가 많으므로, 이처럼 하나의 다이어그램에 모두 모아두면 많이 도움이 된다.

[[각 분류자에 대한 Context Diagram]]

ISO 19103 요구사항 18에 따르면, 모든 분류자는 Context diagram에 표현해야 한다. 여기에는 모든 속성/연산 및 해당 분류자에서 탐색가능한 모든 관계를 표시해야 한다. 관계가 깊은 분류자의 경우, Context 다이어그램을 공유할 수 있다. 하지만,적을수록 좋다(less is more)는 원칙을 다시 한번 기억하라. 한 다이어그램에 등장요소가 적을수록, 관점이 적을 수록가독성이 높아진다.

유스케이스 및 시퀀스 다이어그램

유스케이스 다이어그램과 시퀀스 다이어그램은 모델 개발 과정에서 중요한 역할을 한다.

---- 앞으로 설명 및 예제를 추가할 예정 ---

객체 다이어그램

클래스의 인스턴스가 들어 있는 객체 다이어그램은 모델의 이해와 테스트에 매우 중요하다. ISO/TC211에 있는 객체 다이어그램의 예는 ISO 19160-1에서 볼 수 있다. ISO 19160-1 프로파일을 개발할 때, 몇몇 샘플 주소를 위한 객체 다이어그램이 필수이다. 

아래 그림은 ISO 19160-1의 INSPIRE 프로파일을 위한 객체 다이어그램이다.

2.3.2 클래스 다이어그램 디자인

폰트/색

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Colours-and-fonts

[[폰트]]

19103 개념스키마 언어에는 다이어그램의 폰트 크기에 관한 추천사항이 하나 있다.

이 권고사항도 모범사례 적을수록 좋다(less is more)와 관련이 있다. 다이어그램은 추천된 폰트 크리로 프린트할 수 있는 정도의 크기어야 한다.

INSPIRE Repository tutorial 의 규약에 따르면

모든 모델에서 이 규칙을 따를 것을 추천한다.

[[색]]

다른 지형지물 카탈로그에서 가져온 클래스를 다른 색으로 표현하면 이해하는 데 도움이 된다. 하지만, 다음 사항을 기억해야 한다.

ISO 표준(문서)의 그림들엔 색이 없어야 한다. 하지만, ISO 모델 및 기타 모델에서 다이어그램에 색이 사용되고 있다. 하지만, ISO 표준 및 동일한 요구사항이 있는 문서에서 사용할 경우, 반드시 흑백으로 export 시켜야 한다. 예를 들어, INSPIRE와 관련된 국가 사양에서는 INSPIRE 클래스에 색깔을 사용할 수 있다. 하지만 다음 사항을 지켜야 한다.

ISO 19160-1 주소 - 개념모델에서는 표준 프로파일 문서화를 위한 요구사항 및 추천사항이 있다. 이들은 다른 모델에도 적용할 수 있다. (7.5.2장)

[[속성]]  

현재 색이 다른 클래스에 대해 속성을 부여하는 것이 불가능하다. 여기 및 여기를 참고할 것. (두개 모두 깨진 링크)

적을수록 좋다(Less is more)

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Less-is-more

이 글은 Geert Bellkeen의 블로그 글 5 rules for better UML diagrams 를 참조한 것이다.

• 복잡한 모델을 위한 대형,  압도적인 다이어그램 보다는, 여러개의 작은 다이어그램으로 분리
• 각각의 UML 다이어그램은 소수의 요소에 집중하고 정의된 관점이 있을 것.
• 다이어그램의 관점과 관련이 먼 속성/연관/제한은 숨길 것

ISO 19157에서 가져온 아래 그림에서, 목적은 데이터품질 단위가 DQ_DataQuality와 하나 이상의 DQ_Element로 구성됨을 보이는 것이다. DQ_Element의 속성은 이 관점에서는 관련이 없으므로, 보이지 않도록 하였다. 아울러 DQ_Element의 연관요소도 관련이 없으므로 숨김 처리했다.

요소가 많이 들어 있는 개요 다이어그램도 있을 수 있다. 이러한 다이어그램은 요소와 연관만 보이고 속성은 숨겨야 한다. 연관의 역할명도 숨기는 것이 좋을 수 있다.

[[속성 표시여부 선택하기]]

한 요소의 속성/연산/제약/노트 표시/숨기기 : 해당 요소 우클릭 - Features & Properties -> Feature and Compartment Visibility (Cntl-Sht-Y)
모든 요소의 속성/연산/제약/노트 표시/숨기기 : 해당 다이어그램 선택(F5) - Properties - Element

[[역할명 표시여부 선택]]

하나의 역할 명 : 레이블 우클릭 -> Hide label
연관의 모든 레이블 숨기기 : 연관 우클릭 - Visibility -> Hide all labels
연관 label 중 일부 숨기기 : 연관 우클릭 -> Visibility -> Set label visibility

[[연관 표시여부]]

하나의 연관 : 연관 우클릭 - Visibility - Hide Connector
여러개의 연관 : Diagram - Visible Relations?? (Cntl-Sht-I)
모든 연관 : Diagram 을 우클릭 - Properties - Connectors - Show relations

연관 관계 선을 직각 표시(Orthogonality)

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Orthogonality

이 글을 Geert Bellkeen의 블로그 글 5 rules for better UML diagrams 를 참조한 것이다.

잘 정돈된 다이어그램은 어지러운 것보다. 이해하기 쉽다. 요소들을 수평/수직으로 정돈하고 직각 연결선을 사용하는 것은 가독성을 향상시키기 위한 첫번째 단계이다.

아래 첫 그림에서, 요소는 자동 정렬되어 있고, 연결선은 직선으로 되어 있다. 그 다음 그림은 수평/수직으로 정렬되어 있으며, 동일한 간격으로 조화된 크기로 맞췄으며, 연결선은 직간으로 처리했다. 이 그림은 좀더 정렬되어 이해하기 쉽다.

지저분함:

정렬된 그림:

요소를 정렬하고 높이를 맞추는 도구는 원하는 요소들을 선택하고 우클릭하면 접근할 수 있다. 라인 스타일은 선 선택 - 우클릭 - Line Style에서 설정할 수 있다. 위 예제의 라인 스타일은 Tree Style - Vertical 이다. 이 스타일은 세개의 하위 클래스가 모두 DQ_Result에 대하여 동일한 관계가 있기 때문에 사용할 수 있다. 만약 이들 중 하나가 다른 관계(예: 집합관계)가 있을 경우, 이는 별ㄷ의 선으로서 표시되어야 한다.

다른 표준에서 온 클래스 표시

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Illustrate-classes-from-other-standards

대부분의 표준은 다른 표준으로부터 클래스나 코드목록을 포함한다. 다이어그램을 잘 이해하기 위해서는 이들 요소들이 어느 표준에서 유래했는지를 도시해야 한다. 이 페이지에서는 이를 위한 두가지 접근법을 제시한다.

[[첫번째 방법 : 경계선(Boundary)]]

외부 요소를 표시하는 간단하면서도 유용한 방법은 다이어그램에서 요소 둘레로 경계선을 추가한 뒤, 표준의 이름과 번호(및 연도)를 텍스트로 추가하는 것이다. 이렇게 하면 쉽고도 직관적인 표현이 가능하다.

아래 그림은 ISO19157:2013 지리정보-데이터 품질에서 사용한 방법이다.

Enterpise Architect에서는 Toolbox 중에서 Common 그룹에 들어 있다.

이 방법의 단점은 외부 표준의 이름이 변경되었을 경우, 텍스트가 자동적으로 변경되지 않는다는 점이다.

[[두번째 방법 : 네임스페이스를 모두 표시]]

또다른, 좀더 유용한 해법은 아래 그림과 같이 외부 클래스의 완전한 네임스페이스를 모두 표시하는 방법이다. 이렇게 하면, 표준명 뿐만 아니라, 어떤 패키지가 이 요소를 소유하는지를 보일 수 있다. 하지만, 문장이 길어지고 혼란스러워질 수 있다.

완전한 네임스페이스를 보이려면, 다이어그램을 선택한뒤, Properties - Diagram - Show Namespace 및 Fully Qualified Namespace 를 선택하면 된다. (단, 외부에서 가져온 것 뿐만 아니라, 모든 것의 네임스페이스가 표시됨)

선을 교차시키지 말것

https://github.com/ISO-TC211/UML-Best-Practices/wiki/No-crossings

이 글은 Geert Bellkeens 의 블로그 글 5 rules for better UML diagrams 중에서 2번째 규칙을 참조한 것이다.

상위 요소를 위쪽으로 배치

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Parents-up

이 글은 Geert Bellkeens 의 블로그 글 5 rules for better UML diagrams 을 참조한 것이다.

게층에서 가장 높은 요소는 다이어그램에서도 제일 높은 곳에 위치해야 한다. 

• 하위 클래스는 상위 클래스 아래에 위치시킨다.
• 집합 관계의 경우, 소유하는 측의 요소가 부분 요소의 아래로 내려가서는 안된다.
• 구현의 경우, 원 요소가 위에 있어야 한다.

크기를 조화롭게

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Harmonize-sizes

이 글은 Geert Bellkeens 의 블로그 글 5 rules for better UML diagrams 을 참조한 것이다.

모델 요소의 크기를 조율하면, 가독성을 향상시킬 수 있다. 중요도가 동일한 하위클래스와 연관클래스는 가능한 한 크기가 같아야 한다. 또한 직교성을 유지하기 위해서는 요소의 높이를 통일시킬 필요가 있다.

아래의 그림에서 DQ_Result의 하위 클래스 3개는 모두 중요도가 같지만, 속성의 수가 다르다. 원하는 요소들을 한꺼번에 선택한 후, 우클릭 - Same Height and Width를 선택하면 모두 동일한 크기로 설정할 수 있다.

아래 그림에서 DQ_Element에 대한 연관 클래스도 중요도가 동일하다는 것을 보이기 위해 동일한 크기로 설정하였다. 연관 클래스의 속성은 그림과 관련 없기 때문에 가독성 향상을 위하여 숨김처리하였다. (적을수록 좋다를 참고할 것)

제약(Constrains) 표시

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Constraints

[[제약이란]]

제약이란, "요소의 의미론을 선언하기 위한 목적으로 자연언어 혹은 기계가독언어로 표시한 제한이나 조건"이다(ISO 19103).  제약은 예를 들어, 어떠한 조건하에 속성이 필수가 되는지 등의 조건을 설정함으로써, 모델에 정밀함을 추가하므로 중요하다. 개념 수준에서 제약을 표현하는 것은 검증, 관리 및 데이터 관리에 중요하다.

ISO 19109에는 여러가지 제약의 예가 있다.

• 제약은 하나이상의 지형지물 인스턴스(다른 데이터 유형에 속한 것도 무방)에 있는 속성 값의 허용 조합을 지정할 수 있다.
• 제약은 지형지물 인스턴스간의 연관관계 다중도를 제한할 수 있다.
• 제약은 실세계 현상이 어떤 크기일 경우, 지형지물 인스턴스가 어떤 GM_Object의 하위유형으로 표현될 것을 요구할 수 있다.
• 지형지물 연산에서 정의된 지형지물의 행태는, 제약으로서 제한할 수 있다.

UML에서 제약은 자연언어 또는 기계가독언어, 일반적으로 객체 제약 언어(OCL, Object Constraint Language)로 표현할 수 있다. ISO 19103 권고사항14에 따르면, "제약은 OCL 2.0에 정의된 객체 제약 언어를 사용하여 표현한다. 또한 제약은 모델에 대한 문서에서 자연언어로 기술한다."고 되어 있다. OCL 표현은 구현에 중요하며(필수는 아님), 자연언어 표현은 인간의 이해에 중요하다.

[[자연어로서 먼저 작성하라]]

OCL로 제약을 작성하는 것은 직관적이지 않으므로, 먼저 자연어를 기술한 후, 이를 근거로 OCL을 추가한다.

[[OCL 작성방법]]

• INSPIRE Repository tuturial 10-11에는 OCL을 작성하는 방법에 관한 힌트가 있다.
• 과거 및 현재의 OCL 사양은 http://www.omg.org/spec/OCL/에서 볼 수 있다.
• OCL 작성을 위한 지침. CABOT, Jordi and GOGOLLA, Martin. Object Constraint Language (OCL): A Definitive Guide. In : Formal Methods for Model-Driven Engineering. Springer Berlin Heidelberg, 2012. p. 58–90. Lecture Notes in Computer Science.

[[구현에서 제약 활용 방법]]

제약을 구현에서 사용함에 있어, ISO 19136 (GML) 부속서 E 의 내용을 참조한다. "모든 OCL 제약은 무시한다. 인스턴스 모델이 제약조건에 맞는지 평가하는 것은 GML인스턴스를 처리하는 응용에서 담당할 몫이다. 비고: Schematron 언어를 사용하여 OCL 제약을 GML 응용스키마를 표현하는 XML 스키마의일부로서 표현할 수 있다." 이는 GML 응용 스키마는 제약을 포함하지 않으며, 제약은 Schematron이나 데이터를 처리하는데 사용하는 응용에서 처리해야 한다는 의미이다.

ShapeChange를 사용하면 스키마에 정의된 OCL 제약을 파싱할 수 있다. ShapeChange는 OCL 제약으로부터 Schematron 규칙을 유도할 수 있다. OCL->Schematron 변환에 관한 자세한 내용은 여기를 참고하라.)

[[EA에서 제약 사용하기]]

== 클래스 수준에서 제약 기술하기

• 제약은 반드시 클래스에 대한 특질으로서 서술되어야 한다. 다이어그램 및 다른용도, 모델 문서화에서 제약이 항상 클래스 를 따라다니도록 하기 위함이다.
• 제약을 속성 수진에서도 쓸수 있지만, 추천하지 않는다. 다이어그램에서 속성에 추가된 제약을 표현할 방법이 없는 것처럼 보이기 때문이다.
• 다이어그램 노트로서 제약을 쓸 수도 있지만, 이렇게 해서는 안된다. 이렇게 만들면 제약이 다이어그램의 일부가 되고, 클래스의 일부가 안되기 때문이다.

클래스/열거형/데이터 유형의 제약은 Properties 다이얼로그에서 Constraints 탭에서 접근할 수 있다.

• OCL을 쓸경우, Type=OCL로 선택하라. 자연언어 표현은 다음방법으로 추가할 수 있다.
• 해당 제약의 이름
• 코멘트 /*... */로 처리하여 제약 내부
• 자연언어로만 제약을 작성할 경우에는 Type=Invariant로 선택하라.

== 제약을 다이어그램에 표시하는 방법

제약은 UML 다이어그램에서 2가지 방법으로 표시할 수 있다. 첫번째는 요소에 첨부된 노트, 두번째는 클래스를 나타내는 요소 내에 표현하는 방법이다. 일반적으로제약은 클래스 내부에 표현하는 것을 추천한다. 아래 그림은 제약을 클래스 내에 표시하는 방법과, 노트로서 표현하는 방법을 보인 것이다.

• 다이어그램 전체의 제약을 표시하려면, 다이어그램 우클릭(F5) - Properties - Element 를 선택하고 Constrains 를 켠다.
• 특정 한 요소의 제한을 표시하려면, 요소 우클릭 - Feature and Compartment Visibility(Cntrl-Sht-Y)를 선택하고 Constrains 를 켠다.

어떤 경우, 어떤 특정한 제약을 요소에 첨부된 노트로서 표시하는 것이 좋을 수 있다. 이 경우, 다이어그램에 노트를 추가하고, 요소에 이를 연결하면 된다. 링크 우클릭 - "Link this note to an element feature"를 선택한다. 이때 나타나는 다이얼로그에서 Feature Type = Constraint 를 선택하고, Feature 목록에서 원하는 제약을 선택한다.

2.3.3 모델 문서화

• 다이어그램을  이미지 파일로 내보내기  
• 모델의 자동 문서화 (아래 3. 모델문서화 링크)

3. 모델 문서화

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Documentation

3.1 모델의 자동 문서화

https://github.com/ISO-TC211/UML-Best-Practices/wiki/DocumentationOfUmlModels

ISO/TC 211 애드혹 그룹에서는 UML로부터 문서화하는 방법에 대해 조사하였다. 적용 범위는 어떤 모델인지 명확하지 않았지만, 작업과정에서 ISO/TC 211 조화모델에 있는 UML 모델에 집중하였다. 이는 UML모델 저장소로서 ISO/TC 211 표준의 일부이다.

하지만, 문서화 도구는 조화모델 포함 여부에 관계없이, ISO 19103에 따라 모델링된 어떠한 UML 모델에도 적용할 수 있다. 

UML 문서 자동생성은 전세계, 지역, 지역(국가) 수준의 UML 응용스키마에 대해서도 유용할 것이다.

문서화 도구는 아래 문서에서 사용할 수 있다. 링크는 여기

 Automatic generation of documentation from UML models.docx

EA 용 템플릿은 아래에 있다. 링크는 여기

 ISOTC11_EA_report_template.zip

ShapeChange 설정 방법 및 UML 모델 테스트는 여기를 볼 것

3.2 모델의 버전

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Model-versions

2.2.5 일반 - 모델의 버전와 동일함

3.3 다이어그램을 이미지 파일로 내보내기

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Diagram-export

Enterprise Architect에 있는 Diagram 메뉴에서 다이어그램을 이미지로 저장할 수 있다.(단축키 Ctrl-T) 다이어그램을 클립보드로 복사하려면 Ctrl-B를 누른다.

기본값으로서, 다이어그램은 shading 되고, 다이어그램 이름이 레이블로 달리는 프레임이 생성된다. 쉐이드, 프레임, 레이블을 없애는 방법은 다음과 같다.

쉐이드 삭제

Tools - Options - Diagram - Themes 에 들어가서 Monochrome for printing을 선택한다.

프레임 제거:

Tools - Options - Diagramsㅇ로부터 Diagram Frames를 제거한다. 아울러 scale을 200%로 저장하면 문서에서 최적의 해상도를 얻을 수 있다.

4. 도구, 스크립트 등

4.1 Enterprise Architect 스크립트

4.1.1 EA 샘플 스크립트

https://github.com/ISO-TC211/UML-Best-Practices/tree/master/Scripts

아래는 Visual Basic Script의 내용임

https://github.com/ISO-TC211/UML-Best-Practices/tree/master/Scripts/VBScript

모델을 바꿔주는 스크립트(CHG)

• CHG Sort elements.vbs - 선택된 패키지에서 요소들 정렬
• CHG Save Project As.vbs - 프로젝트 복사본 저장

• DOC Count subpackages.vbs - 선택된 패키지에서 1단계 하위 패키지 수 
• DOC Export diagrams as images.vbs - 다이어그램을 이미지 파일로 저장
• DOC Export mapping files.vbs - 태그값에 기반한 매핑 파일 내보내기
• DOC List prefixes.vbs - 클래스와 열거형을 위한 모든 접두사 목록

• VAL Data type references.vbs - 데이터 유형 참조 목록을 만들고 빠진 참조 보고
• VAL Duplicate element names.vbs - 중복 요소명 식별
• VAL Elements in diagrams.vbs - 선택된 패키지 혹은 하위패키지에 있는 다이어그램에서 사용되지 않는 요소 식별
• VAL Missing definitions.vbs - 정의가 없는 요소 및 속성 목록
• VAL Model Validation.vbs - ISO 19103:2015 및 ISO 19109:2015에 정의된 규칙에 따른 모델 요소 검증

• VC Add Subpackages.vbs - 버전 관리를 위한 패키지 추가
• VC Get All Lates.vbs - 선택된 패키지 및 하위패키지를 위한 모든 최신 것을 가져옴
• VC Resync Status.vbs - 버전 관리 청소 - 선택된 패키지 및 하위패키지를 루핑하면서 VC Provider에 상태를 다시 싱크함
• VC Remove Version Control.vbs - 버전 관리 제거. 선택된 패키지 및 하위패키지를 루핑하면서 버전 관리 제거

• HMMG Script
• Version Control Script

• 노르웨이 매핑기관의 스크립트 : https://github.com/kartverket/UML-modelleringsskript

4.2 EA에서 모델 찾기

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Model-searches-in-Enterprise-Architect

4.2.1 EA 모델에서 검색

EA에서, 원하는 요소를 빨리 찾기 위해서는 model searches를 시행하면 된다. (Project Browser Toolbar에서 접근가능한, Find in Project Browser 버튼을 사용한 검색과 혼동하지 말라). Search는 Edit - Find in Project or Edit - Search in Model(Ctrl-F 또는 Ctrl+Alt+A)에서 접근할 수 있다. Search 드롭다운에서 검색을 한 뒤 Run 버튼을 누른다.

"Find in Project(Ctl-F)"의 여러가지 기능 (Start - Explore - Search - Search in Model)

[[미리 정해진 찾기 기능(Built-in Search)]]

EA의 Search 드롭다운에는 "Built-in"이라는 미리 정의된 검색 이 있다.

[[XML 파일로부터 가져온 검색]]

검색을 XML 로부터 import할 수 있다.(최상위 태그가 <RootSearch>) Search Builder Toolbar에서 Import Search를 누르면된다. XML파일로부터 가져온 검색은 검색 드롭다운에서 "My Searches" 범주에 나타난다.

[[MDG Technology의 일부인 검색]]

MDG Techonology(최상위 태그가 <MDG.Technology>)는 Tools - MDG Technology Import에서 가져올 수 있다. MDG Techonology의 일부로 가져온 검색은 검색 드롭다운에서 MDG Techonology라는 이름의 범주로 나타난다.

4.2.2 새로운 검색 정의 생성

1. Edit - Find in Project (Ctrl-F 또는 Ctrl+Alt+A)
2. Builder 버튼을 클릭한다.
3. 새로운 검색 정의를 생성한다. 이름을 주고 Editor Type이 SQL Editor인지 확인한다.

4.2.3 검증시 검색을 사용하기

검색을 사용하여 클래스, 속성, 기타 UML 요소가 특정 요구사항이나 권고사항에 부합하지 않는 요소를 알아낼 수 있다.

---- 향후 작업

4.2.4 검색 공유

검색 불러오기 및 내보내기

Search Builder 툴바에 있는 Export Search 버튼을 사용하면 다이얼로그 박스가 나타나고, 여기에서 XML 파일로 내보내고자하는 검색을 선택할 수 있다. 이 XML 파일을 Import Search 버튼을 사용하면 다른 사람이 불러올 수 있다.

참고로, 불러들이는 검색 정의가 이미 있는 검색정의와 이름이 중복될 경우, 동일한 이름을 가진 두개의 검색 정의가 생긴다. 

이러한 XML 파일은 UML 모델과 동일한 저장소에 저장할 수도 있다.

MDG Technology에서 Bundle Search

--- 향후 작업

4.2.5 검색 팁

CLASSGUID 와 CLASSTYPE

결과 셋(result set)의 일부로 CLASSGUID 와 CLASSTYPE을 지정할 경우, EA는 각 결과줄 앞에 해당 아이콘을 그려준다. 결과 셋에서 더블클릭하면 요소, 연산 및 속성이 직접 열린다. 다이어그램과 패키지는 직접 열리지 않는다. 이들은 Alt-G를 통해 프로젝트 브라우저에서 찾은 후 열어야 한다. Inside Enterprise Architect, EA User Guide 참고

4.3 ShapeChange plugin

https://kartverket.no/geodataarbeid/standarder/sosi/programmer-og-verktoy/

이 페이지에서는 SOSI 정의 파일의 품질관리 및 제품사양 생성에 도움이 되는 프로그램과 도구를 다운로드 받을 수 있다.

EA용 설정 프로젝트 파일

이 프로젝트 파일에는 SOSI 전체 모델 등록물을 포함하며, 문서화 템플릿, SOSI 모델 검증기, SOSI UML 프로파일 5.0 등이 있다. EA에서 여는 방법은 설치 가이드를 참고하라.

Download SOSI Model Register (eap, 350 MB)

SOSI 문서화 템플릿 (EA)

최종 SOSI 제품사양의 정보모델(5장)에 해당하는 UML 모델의 그림 및 텍스트 설명을 내보내기 위하여 EA에 설치해야 할 RTF 템플릿

Download SOSI documentation template in EA (xml) - updated 28.09.2017

SOSI 문서 RTF로부터 DOCS

EA 보고서를 향상시키는 마크로가 담겨있는 Word 템플릿. 정보모델을 제품사양서에 입력하기 전.

Download SOSI documentation from RTF to DOCX (dotm) - updated 28.09.2017

Shape Change

ShapeChange는 UML 모델로부터 GML을 생성하는데 사용된다. 자세한 매뉴얼은 www.shapechange.net에서 확인할 것

EA의 SOSI 플러그인

이 플러그인은 UML 모델로부터 SOSI 관리 및 SOSI 실현을 위한 정의 파일을 생성하기 위한 것이다. 이 플러그인의 일부로서 SOSI UML 프로파일이 설치된다.

이 EA 플러그인은 Arkitektum AS에서 개발하였다.

Download SOSI plugin in EA version 2.0.0.28 (exe)

SOSI UML 프로파일 5.0

이 프로파일은 표준 스테레오타입을 정의한다.

Download SOSI UML profile (xml)

SOSI 모델 검증 Add-on 1.0

이 도구는 EA 애드온으로서, 당신의 모델이 UML Modelling 5.0 규칙의 요구사항 및 권고사항을 충족시키는지를 점검하기 위한 목적이다.

Download SOSI Model Validation from the Mapping Authority's Github account .

UML 모델링 스크립트

노르웨이 매핑기관의 Github 계정에는 UML 모델을 작업할 때 도움이 되는 (예를 들어, 제품사양을 위한 모델 준비시 사용하는)스크립트를 몇개 올려두었다. 이들 스크립트는 EA용이다. 

SOSI_ps

제품 사양 문서를 위한 출발점을 생성하는 프로그램

Download SOSI_ps version 28.10.2013 (zip)

4.4 ShapeChange를 이용하여 조화 모델로부터 XML 스키마 생성

ISO TC211 UML 모델을 실제 응용에서 활용하기 위해서는, 정보처리 에이전트간에 직렬화되고 전달할 수 있는 표현으로 구현되어야 한다. 대부분의 현재 구현은 XML을 직렬화 스킴으로 사용하는데, 이때 XML 스키마 문서를 사용하여 교환 문서의 구조를 정의한다. 개념 모델을 구현하는 스키마를 자동으로 생성하기 위해서는, UML 모델로부터 XML 스키마를 자동적으로 생성하는 소프트웨어 절차가 필요하다. 여기에서 설명하는 절차는 여러가지 최신 표준에서 사용될 수 있다.

4.4.1 소프트웨어 요구사항

이 절은 아주 개략적인 내용이다. 자세한 내용은 조화모델 관리그룹 위키를 보라

Enterprise Architect(EA) : ISO/TC 211 조화 UML 모델을 개발/갱신관리하는데 사용되는 상용 소프트웨어 패키지. 여기에서 설명하는 내용은 12.1.1230을 기반으로 한다. 2017-07 현재 EA의 버전은 13.5이나, 여기에 있는 절차는 새로운 버전으로 테스트하지 못했다.

ISO/TC 211 조화 모델 : ISO/TC 211 조화모델은 웹에서 접근가능한 디렉토리에 저장되어 있으며, 여기에는 TC 211 작업과정에서 만들어진 모든 UML 모델을 담고 있는 파일이 들어있다. 모델은 EA로 부터 XMI(XML interchange format for UML)을 사용하여 export하였으며, 이들 XMI 파일은 온라인 디렉토리에서 버전관리를 하고 있다.(,아래의 Subversion 참고) Enterprise Architect외의 UML 모델링 소프트웨어 패키지도 XMI 파일을 사용할 수 있지만, 실질적으로 모델의 모든 측면(노트, 태그, 색깔 등)을 번역할 수 있을 만큼 충분히 신뢰할 정도로 포맷이 표준화되어 있지 않다. TC 211 조화모델에 있는 XML 문서는 다음과 같은 네임스페이스를 사용하고 있으며(xmi.version="1'1", xmlns:UML="omg.org/UML1.3", EA exporter 버전은 2.5이고, windows-1252 캐릭터 인코딩을 사용하고 있다.

Subversion : TC 211 조화모델 저장소는 Subversion 소프트웨어를 사용하여 관리되고 있다. Subversion은 Apache Software Foundation의 오픈소스 패키지이다. 모델 컴포넌트를 체크아웃하고 변화를 체크하기 위해서는 자신의 컴퓨터에 subversion client가 있어야 한다.

ShapeChange : Interactive Instruments GmbH 소프트웨어의 오픈소스 패키지로서, UML 에서 XML 변환을 구현하여 모델 구현을 위한 XML 스키마를 생성해준다.

SolidGround : CSIRO에서 원래 제작한 EA를 위한 소프트웨어 확장으로서, ShapeChange를 수행하기 전, UML 모델을 테스트할 때 매우 유용하다. 이 소프트웨어는 더이상 CSIRO에서 관리하지 않는다. Windows 설치자(Solid_Ground_Setup.msi)는 XML Maintenance Group 저장소에 있다. 이 저장소에는 약간의 문서도 준비되어 있다. 

4.4.2 모델 설정

TC 211용 XML 스키마를 생성하기 위해서는 UML 모델을 구성할 때 특정한 UML 프로파일을 따라야 한다. 문제가 있으면 온라인 ShapeChange 문서를 참고하라. 핵심적인 스테레오타입 몇개를 소개하면 다음과 같다.

별도의 XML 네임스페이스로서 구현되는 각각의 모델 모듈은 별도의 UML 패키지로서 존재해야 하며, 이들 패키지의 스테레오타입은 <<Application Schema>>이어야 한다. Application Schema 패키지는 표 및 그림에 있는 태그가 존재해야 한다.

응용스키마 패키지는 반드시 하나이상의 하위 패키지를 가져야 하며, 이들 각각은 별도의 xml 스키마 파일에서 구현된다. 명확성을 위하여, 이들에게 스테레오타입 <<Leaf>>를 부여할 수 있으나. 이는 요구사항이 아니다.

응용스키마 수준에서 하나의 XML 스키마 파일이 생성된다. (이름은 해당 패키지의 xsdDocument 태그로 지정함(위의 예에서는 cit.xsd) 이 스키마파일은 <xsd:include>요소를 사용하여, 응용스키마 패키지 내에 있는 하위 패키지에서 생성된 스키마 파일을 include시킨다. 별도 분리된 스키마 파일을 원하는 경우(추천됨), 응용스키마 패키지내의 패키지에 xsdDocument 및 xsdEncodingRule 태그가 있어야 한다. 참고로 xsdDocument 경로는 <xsd:include> 경로가 간단해지도록, 최상위 xsd의 문서 경로와 일치하는 것이 좋다. (자세한 내용은 아래의 후처리를 참고)

UML 클래스 속성을 위한 태그

UML 클래스의 속성 및 탐색가능한 연관역할은 sequenceNumber 태그를 가지는 것이 좋으며, 이때 일련번호는 개별 UML 클래스 범위내에서 고유해야 한다. 일련번호는 필수가 아니며, 없을 경우 ShapeChange에서 자동생성한다. 존재하지 않을 경우, 특질을 위한 XML 요소는 클래스에 나타난 순서를 따르지만, 클래스에 다른 클래스로의 연관이 존재할 경우, 생성된 XML 스키마내에서의 이러한 요소의 순서는 예측불가능하다. 일련번호 사이에 공백이 있어도 무방하며, 속성이나 연관이 많고 나중에 새로운 속성이 추가되거나 순서나 변경될 가능성이 있는 경우 이런 공백이 도움이 될 수 있다.

패키지 간의 연결

EA 모델에서 다른 TC 211 응용스키마의 클래스는 반드시 EA 인터페이스를 사용하여, 해당 클래스에 대한 링크로서 포함해야 한다. 클래스명을 직접입력하면 필요한 내부 링크가 만들어지지 않는다. 이들 링크가 있으면 EA에서 의존성(dependency) 다이어그램을 자동 생성하고, UML-XL 프로세서로 생성할 때, 필요한 네임스페이스를 xml 스키마로 가져온다.

4.4.3 스키마 파일의 구조

결과 스키마는 여러 ISO 스키마를 위한 디렉토리구조로서 불러진다.(아래그림) 다른 모델에서 import 또는 하나의 모델의 여러 부분을 구현하는 스키마를 include하는 경로는 이 디렉토리 구조를 따른다. 최상위 폴더에는 각각의 TC211 표준을 위한 폴더가 있다.(ISO19115, ISO19110등) 이들 폴더에는 모델에서 정의된 각각의 xml 네임스페이스를 위한 하위폴더가 있는데, 네임스페이스 약어가 폴더명으로 사용된다. 다음 수준의 하위폴더는 각 네임스페이스 구현을 위한 버전 번호로 이름이 부여되며, 실제 스키마 파일은 해당 스키마를 위한 버전번호 폴더 내에 존재한다.

스키마는 'xsdLocation' 태그값에서 지정한 구조로 불러들여지게 된다. 이 태그값은 생성된 스키마가 저장될 위치에 대한 경로를 제공한다. 경로 위치는 ShapeChange가 수행된 최상위 디렉토리에 대한 상대경로가 된다.

4.4.4 작업 순서

==

원문 : https://github.com/ISO-TC211/UML-Best-Practices/wiki