UML Best Practices

공간정보 2018.06.12 17:12 Posted by 드론쟁이 푸른하늘이

목적 : 지리정보를 UML로 모델링하기 위한 모범사례를 수집하고, 기계와 인간이 모두 지리정보 UML 모델을 잘 이해할 수 있도록 한다.

1. 개요

1.1 UML 기본

1.1.1 UML 소개

- UML은 객체지향 모델링을 위한 그래픽 언어

- UML 2.4.1 = ISO 19505:2012 

- 지리정보 모델링에는 3가지 정적 모델이 사용된다.

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

1.1.2 추상화 수준(Level of Abstraction)

ISO 19103의 요구사항 4는 "모델은 그 추상화수준에 대한 확실한 설명을 문서화해야 한다" 고 말한다.

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

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

1. 메타모델(가장 추상적임. ISO19109의 일반 지형지물 모델과 ISO19505의 UML 메타모델 등)

2. 개념스키마 - 추상 스키마 (기본개념에 대한 핵심 모델. 예 : ISO19107의 기하 및 위상 등)

3. 개념스키마 - 응용 스키마 (아직까지 개념 모델이나, 응용에 대해 구체적임. 예: 길, 건물 등)

4. 구현스키마(특정 구현을 위한 스키마. 예 : GML 응용스키마(XSD))

1.2 Enterprise Architect 사용하기

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

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

1.2.2 INSPIRE 투토리얼

INSPIRE_UML_repository_tutorial.pdf

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

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

1.3 참고 문헌

1.3.1 요구사항 및 권고사항

여러가지 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
    OGC Domain modelling cookbook
    Domain Modelling using Hollow World
    Presentation 2015(Data modelling and model driven implementation of data distribution)
- SVN 및 문서관리
- 프로필
- 구현
- 스크립트
    Querying EA's Database
    Scripting Enterprise Architect
    Fifty Enterprise Architect Tricks

2. 모범 사례

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

- 1.3.1 과 동일

2.2 모델링 모범사례

2.2.1 일반 - 추상화 수준

- 1.1.2와 동일

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

접두사(GM_, TP_ 등)

예전 UML 편집자의 잘못으로 인해 분류자(Classifier) 이름에 "네임스페이스" 접두사를 붙였으나, 현재는 문제가 없어 원칙적으로 이러한 접두사가 필요없다. 자세한 접두사 목록은 여기를 볼 것. 그리고 여기에는 더 복잡한 것도 있음. 

3D(Profile 3D, 19152:2012)
AD(Address model, 19133:2005)
AT(Accessibility Types, 19159-1:2014)
CA(Calibration, 19159-1:2014)
CC(Coordinates Common, 19111:2007)
CD(Coordiantes Datums, 19111:2007, 19111-2:2009)
CD(Feature Concept Dictionary, 19126:2009)
CD(Citation and Responsibility Extended, 19115-2:2017)
CI(Citation and Responsible party information, 19115:2003, 19115:2006, 19115-1:2014)
CL(Classification, 19114-1:2009)
CS(Coordinate Systems, 19111:2007, 19111-2:2009)
CT(Catalogues, 19139:2007)
CV(Coverage, 19123:2005, 19123:NWIP)
CVT(Temporal Coverage, 19156:2011)
DPS(Data Product Specification,19131:2007)
DQ(Data Quality:19157:2013, 19157:2017, 19115:2003, 19115:2006, 19109:2015)
DQM(Data Quality Measures, 19157:2013)
DS(Data Set, 19115:2003, 19115:2006, 19115-1:2014)
DT(Deviation Types, 19147:2013)
EG(Point Estimates, 19133:2005)
EM(Exchange Metadata:19118:2005)
EX(Extent information, 19115:2003, 19115:2006, 19115-1:2014)
FC(Feature Catalogue, 19109:2005, 19110:2005)
FD(Feature Data Model, 19133:2005)
FR(Feature Catalogue Registers, 19110:2015)
FT(Facility Types, 19147:2013)
GBA(Profile NL Ingezetenen, 19152:2012)
GF(General Feature Model, 19103:2015, 19109:2005)
GFI(General Feature Instance, 19156:2011)
GI(Exchange Model, 19118:2005)
GM(Geometry, 19103:2015, 19107:2003, 19152:2012)
GPLR(19145:2013)
HR(Hierarchical Feature Information Register, 19126:2009)
HUN(Profile Hungary, 19152:2012)
ID(Profile Indonesia, 19152:2012)
IE(Imagery Encoding, ISO/TS 19163-1:2016)
IF(IGCD Framework, 19129:2009)
IG(Reference model-Imagery, 19101-2:2008)
IM(Instance Model, 19118:2005)
IO(Identified Objects, 19103:2015, 19111:2007)
JP(Profile Japan, 19152:2012)
KF(Profile Korea, 19152:2012)
LA(Land Administration, 19152:2012)
LBS(Location Based Services, 19132)
LC(Land Cover, 19144-2:2012)
LE(Lineage Extented, 19115-2:2009, 19115-2:2014)
LE(Linearly Located Event, 19148:2012)
LI(Lineage, 19115:2003, 19115:2006, 19115-1:2014)
LM(Land Cover Meta Language, 19144-2:2012)
LR(Linear Referencing System, 19148:2012, 19133:2005)
LRO(Linear Referencing Offset, 19148:2012)
LROV(Linear Referencing Offset Vector, 19148:2012)
LRTR(Linear Referencing Towards Referent, 19148:2012)
LS(Linear Segmentation, 19148:2012)
LT(Location Transformation, 19133:2005)
MC(Measured Coordinates, 19133:2005)
MD(MetaData, 19115-1:2014, 19115:2003, 19115:2006, 1915901:2014
MF(Moving Features, 19141)
MI(Metadata Imagery, 19115-2:2009, 19115-02:2017)
MM(Multimodal, 19134)
MN(Multimodal Navigation, 19134)
MS(Map Services, 19128)
MX(Metadata Extention, 19115-2:2009, 19139:2007, 19157:2017)
NL(Profile Netherlands, 19152:2012)
NS(Navigation Services, 19133:2005)
NT(Network, 19133:2005)
OM(Observations and Measurements, 19156:2011)
PF(Portrayal, 19117:2012, 19117:2005)
PI(Place Identifier, 19155:2012, 19155-2:2016)
PS(Positioning Services, 19116:2004)
PT(Profile LADM_PT, 19152-2:2012)
PT(Language-characterset localization inforamtion, 19115-1:2014, 19139:2007)
QE(Quality Extended, 19115-2:2009)
QLD(Profile Queensland, 19152:2012)
RE(Registration, 19135:2005, 19135-1:2015)
RF(Profile Russian Federation, 19152:2012)
RS(Reference System, 19103:2015, 19111:2007, 19115:2003, 19115:2006)
RT(Restriction Types, 19147:2013)
SC(Spatial Referencing by Coordinates, 19103:2015, 19111:2007, 19111-2:2009)
SD(Sensor Data, ISO/TS 19130:2010)
SF(Services and Facilities, 19147:2013)
SF(Sampling Features, ISO 19156:2011)
SI(Spatial Referencing by Geographic identifier, 19112:2003)
SP(Spatial Profile, 19137:2007)
ST(Service Types, 19147:2013)
SV(Service, 19115-1:204, 19119:2005)
SY(Symbol, 19117:2012)
TK(Tracking, 19133:2005)
TM(Temporal, 19108:2006, 19111:2007)
TN(Transfer Node, 19147:2013)
TP(Topology, 1017:2003)
TR(Term, 19146:2010)
UPA(Ubiquitous Pubic Access, 19154:2014)
XX(Example, 19147:2013)

규칙과 권고사항

19103에는 여러가지 규칙이 있는데, 그중 핵심은 Requirement 16 "UML 요소의 이름은 네임스페이스에서 유일할 것. 대소문자 구분하지 않음. 공백없을 것"

19136 GML에서는 이름을 W3C XML 네임스페이스에 정의된 "NCName" 형식을 따르도록 정의함. 문자/숫자/("-",".","_") 등만 사용(특수문자 사용불가). 숫자/"-","." 로 시작할 수 없음.

속성과 역할은 네임스페이스가 클래스이므로, 다른 클래스에서 반복사용될 수 있으나, 19109의 권고사항(/rec/uml/property-name)에 따르면 응용스키마 내에서 유일 또는 다른 클래스에서 사용될 경우에는 동일한 의미. 이 권고사항은 GFM 권고사항인 rec/general/property-name과 밀접한 관계가 있음.

19103 Requirement 8 : classifier/속성/연산/매개변수 이름은 정확하고 이해가능한 기술적 이름 사용할 것
19103 Requirement 9 : 매개변수의 콘테이너나 유형에 의미가 있는 경우, short parameter명을 써야 함 (예: Building 클래스의 이름은, name 을 쓸 것. buildingName을 쓰지 말것)

19103 Requirement 10: UML요소의 이름은 정확하고 이해가능한 이름이 되도록 여러 단어를 중첩하여 사용하되, "-"나 "_"을 끼우지 말것
19103 Requirement 11: 속성/연관역할/매개변수는 lowerCamelCase, 패키지/클래스/연관은 UpperCamelCase 형

19103 Requrement 13: UML요소명은 실용적인한 짧게. 이해가능하면 약어 사용, 특별한 의미가 없는한 전치사와 동사는 생략.

다중언어 이름

ISO19109 응용스키마 패키지의 경우

/req/multi-lingual/package : 응용스키마가 있는 PACKAGE에는 TAGGED VALUE "language"에 주요 언어를 지정해야 함. 값은 IETF REC 5646의 언어코드 'ko', 'en', 'fr' 등

TAGGED VALUE "designation"에는 다른 언어 PACKAGE 이름

TAGGED VALUE는 여러가지 언어로 계속 반복가능. "{Name}"@{language} 형태
예 : "Observation et Mesures"@fr

유형, 속성, 역할, 연산도 TAGGED VALUE를 사용하여 다른 언어로 표현가능 

/req/multi-lingual/feature : TAGGED VALUE "designation"에는 다른 언어로 이름 지정

TAGGED VALUE "definition" 에 다른 언어로 정의 

TAGGED VALUE인 "designation" "definition" "description"은 여러 언어로 반복 가능

"{Name}"@{language} 형태. {language}는 IETF REC 5646의 언어코

실세계 이름과 UML 이름

UML 이름이 실제 이름과 약간 다르므로, alias로 실세계 이름 넣는 것이 좋다. 그러나, alias에 대한 표준은 없다. Enterprise Architect에는 "alias"가 있다. alias가 여러군데 사용된다면 TAGGED VALUE로 "alias"를 지정할 수도 있음.

2.2.3 일반 - 정의

모델요소 잘 정의해야 사람들이 잘 이해 가능. UML에서는 정의를 Notes필드나 tagged value에 쓴다. 19109에서는 패키지/클래스/속성의 정의에 대한 여러가지 규칙과 권고가 있다. 기본적으로 "모든 모델 요소에 정의를 작성하라"

19103 규칙 및 권고사항

일반 - Requirement 3 : 모든 클래스는 클래스/속성/연관/연산/데이터유형 정의를 이해할 수 있도록 정의를 포함시켜야 한다.

Enumeration/codelist - Requirement 7 : enumeration 유형의 모든 값은 정의가 있어야 한다.

Naming 과 네임스페이스 - Requirement 12 : UML 요소는 각요소의 의미를 설명할 수 있도록 documentation 필드를 사용해야 한다.

모델의 문서화 - Requirement 19 : 각 분류자는 의미를 설명하는 정의를 가져야 한다.
모델의 문서화 - Requirement 20 : 패키지/분류자/연산/속성/역할/연관/제한은 텍스트로 설명을 해야 한다.

10109 규칙 및 권고사항

응용스키마 문서화 /req/uml/documentation. 응용스키마는 문서화되어야. 클래스,속성, 역할, 연산, 제한의 텍스트 정의는 UML 도구의 문서화 기능을 이용해 기록해야 한다. (export 가능할 경우)

패키지/클래스.../제한의 2차설명 및 정보용 참고사항은 TAGGED VALUE "description"에 기록되어야 한다.

CLASS 등 UML 구성요소가 지형지물 카탈로그에 있는 요소를 구현할 것일 경우, 그 카탈로그에 대한 참조를 TAGGED VALUE "catalogue-entry"에 문서화 해야 한다.

정의 작성 방법

Enterprise Architect에서 "UML 도구의 문서화 기능"은 각각에 대한 "Note" 필드임. 정의는 다음과 같이 작성할 것

- 가능한한 간결하게. 예나 설명은 포함하지 않게. (예나 설명은 "description"에 넣을 것)
- "주소란..." "Address component is..." 으로 시작하지 말것
- 마침표로 끝낼 것

예 : 특정 지리적 구역, 위치 등의 식별자 또는 지리적 명칭

2차적 설명 - TAGGED VALUE "description"

자연언어 명칭, 보조적 설명, 등에 대한 내용임.

2.2.4 일반 - TAGGED VALUE

tagged value란?

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

예 : {author="Joe Smith", deadline = 31 March 1997, status = analysis}

Tagged value는 스테레오타입에 대한 속성으로서 정의된다. 예를 들어 스테레오타입 CodeList에대한 tagged value 인 codelist에는 별도 관리되는 원래의 리스트에 대한 URI 참조값을 나타낸다.

19103의 tagged value

CodeList        codelist        실제 외부 code list 를 참조하는 영구 URI

19109의 tagged value

스테레오타입

Tagged value 

설명 

 ApplicationSchema

 version

 응용스키마의 버전

 ApplicationSchema

 description

 2차 설명 및 정보

 ApplicationSchema

 catalogue-entry

 지형지물카탈로그에 대한 참조

 ApplicationSchema

 language

 주 언어 (IETF RFC 5646)

 ApplicationSchema

 designation

 다른 언어로 표현한 이름 "{Name}"@{language}

 FeatureType

 designation

 다른 언어로 표현한 이름 "{Name}"@{language}

 FeatureType

 description

 2차 설명 및 정보

 FeatureType

 definition

 다른 언어로 표현한 텍스트 정의. 반복가능

19136(부속서 E)의 tagged value

Package : documentation, xsdDocument, targetNamespace, xmlns, version, gmlProfileSchema

Class : documentation, byValuePropertyType, isCollection, asDictionary, xmlSchemaType

Attribute/Association end : documentation, sequenceNumber, inlineOrbyReference, isMetadata

2.2.5 일반 - 모델의 버전

3.2와 동일함

2.2.6 클래스 - 스테레오 타입

스테레오타입은 UML요소를 확장한다. 19103/19109에 스테레오타입이 정의되어 있다. 원래는 대소문자 구분하지 않지만, 19103/19109에서는 다음과 같은 형태를 사용한다.

- ApplicationSchema : 지형지물유형을 담는 패키지. GML에서 실현할 때 중요함

- FeatureType : 지리 객체 유형을 나타내는 클래스. GML에서 실현할 때 중요함

- dataType : 식별성 없는 속성의 집합. 독립 인스턴스로 존재하지 못하고, 속성/부품으로 존재

- enumeration : 고정된 리스트.

- CodeList : 확장 가능 리스트

- interface : 개념 클래스. 데이터셋에 직접사용할 수 없음. 다른 클래스 내에서만 사용

- Union : 여러가지 유형이 포함되어 있으나, 한가지만 존재 가능

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

상위클래스로 일반화, 하위클래스로 특수화

2.2.8 클래스 - 추상클래스

추상 클래스는 italic체로 이름을 쓴다. 인스턴스를 만들 수 없다.

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

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

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

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

따라서, 데이터타입보다는 지형지물유형을 사용하는 것이 더 좋다. 기본 법칙은 "잘 모르면 데이터타입 대신 클래스를 사용하라"

2.2.10 속성 - 속성/연관

클래스에는 연관을 사용하고, 데이터타입에는 속성을 사용하라

더 많은 정보는 이 글이 글을 참고할 것

객체의 특징을 나타내는 가장 간단한 방법은 19103의 원시 데이터유형(Integer, CharacterString 등)의 속성을 사용하는 것. 하지만 복합데이터유형이 속성이 될 경우(예 : 19115 CI_Citation), 언제 속성으로 넣을지, 언제 연관을 사용할지 고민이 될 수 있다.

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

지형지물 유형이라면 주 지형지물 외부에 존재할 수 있고, 따라서 연관으로 참조해야 한다. 반대로 datatype의 경우 속성으로 사용하라. 

2.2.11 속성 - 다중도(Multiplicity)

속성에는 다중도가 있어야 한다.

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

지형지물유형, 객체유형, 데이터유형, 유니온유형의 속성은 이름과 data type이 있어야 한다.(19109, 19136) 개념스키마에도 적용되고, 모델의 구현에도 중요하다.

data type은 ISO 19103의 원시데이터 유형또는 다른 표준에서 정의된 유형, UML모델에서 자체적으로 정의한 유형 등이 있다.

속성유형에 base class와 연결시키지 않은 이름을 할당하는 실수. (예: data 유형에 GM_Point라고 그냥 입력하면, 19107과 연결되지 않음.) 그림상으로는 올바른 것처럼 보여도, 연결이 빠졌기 때문에, 구현이나 의존성 점검시 오류가 발생한다.

Enterprise Architect에서 속성은 ClassifierID를 갖는다. 이것이 해당 데이터유형에 연결된다. 올바르게 연결이 되려면, 이름을 직접 쓰지말고, 모델에서 선택해야 한다. 

EA에는 속성이 데이터유형과 연결되는지를 체크하는 기능이 없다. 이 스크립트를 사용하여 처리할 수 있다.

2.2.13 연관 - 연관의 유형

연관에는 단순연관/합성/집합 등 세가지가 있다. 모든 연관은 단방향 혹은 양방향으로 탐색가능(navigable)할 수 있다. 화살표/다중도/role 등 세가지로 정의된다.

단순연관은 두개의 클래스가 동등한 입장. 

집합관계(aggregation). 빈 다이아몬드. 다이아몬드 쪽이 소유함. 하지만 둘다 독립적

합성관계(composition). 채운 다이아몬드. 다이아몬드쪽이 소유. 

집합관계는 단순연관에 비해 모델에 새로 추가시키는 것은 없다. 계층을 나타내는데만 도움된다.

합성관계는 모델을 결합하여, 구현에 영향을 미친다. 합성관계는 정말 필요하다고 확신할때만 사용해야 한다.

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

탐색가능성(navigability)

UML 클래스/데이터유형간의 연관은 탐색가능 방향을 가질 수 있다. 단방향/양방향. Unspecified를 하면 대부분 양방향과 동일하지만, 사용하지 않아야 한다. 화살표로 표시한다.

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

GML (부속서 E) 구현에서 모든 탐색가능한 끝은 반드시 화살표로 표시해야 한다. 

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

불가피한 경우를 제외하고 단방향 연관으로 설정하라.

Role name

구현에서는 연관은 속성과 비슷하다. 따라서 

탐색가능한 끝은 반드시 role name을 가져야 한다. 19136 부속서에 따르면 "NCName" 유형이어야 한다. (속성명과 동일)

다중도(Multiplicity)

ISO 19136 부속서 E : 모든 탐색가능한 끝의 다중도는 명확하게 설정해야 한다.

다중도 1과 1... 는 주의깊게 사용해야 한다. 

다중도 1 또는 1... 는 참조를 필수로 가져야 함.  따라서 한쪽의 다중도가 1이고, 다른쪽이 1...* 이면 데이터의 중복이 일어나게 된다.

2.2.15 역할 - INSPIRE Repository Tutorial 12-13쪽

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

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

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

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

클래스 다이어그램은 모델의 일부에 대한 뷰이다. 모든 요소를 보여주는 것이 아니다. 인간의 이해를 위해서 매우 중요하다.

2.3.1 필요한 다이어그램

19103에 모델 문서화에 대한 규칙/권고사항 있음. 

참고 : 문서화를 위해 포함시켜야 하는 다이어그램

패키지 다이어그램

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

19103 Requirement 17/21에 따르면 모든 패키지에 대해 하나이상의 패키지 다이어그램에 의존성을 표현해야 한다. (외부 패키지 포함)

클래스 다이어그램

가장 기본적인 법칙 : 모든 클래스가 적어도 하나의 클래스 다이어그램에 나타나야 한다. 아울러 모든 속성, 연관, 연산, 제한이 적어도 하나의 다이어그램에 표현되어야 한다.

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

모델 소개용. 주요 클래스와 연관만 표현함. 속성 및 역할은 숨겨야 함.

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

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

[[Perspective specific diagram]]

모델의 특정 부분, 주요 분류자에 중점을 둔 다이어그램. 모델의 이해에 유용함. LESS IS MORE 하나의 다이어그램에 등장하는 요소가 적을 수록 가독성이 높아진다. 관점에 관련 없는 속성은 표시하지 말것.

[[Codelist, enumeration, data types]]

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

[[각 분류자(classifier)에 대한 Context Diagram]]

19103 requirement 18에 따르면, 모든 분류자는 Context diagram에 표현해야 한다. 여기에는 모든 속성/연산 및 해당 분류자에서 탐색가능한 모든 관계를 표시해야 한다. 관계가 깊은 분류자의 경우, Context 다이어그램을 공유할 수 있다. Less is More. 등장요소가 높을 수록 가독성이 높아진다.

객체 다이어그램

객체 다이어그램은 모델의 이해와 테스트에 매우 중요. 19160-1에 객체 다이어그램의 예 있음. 

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

폰트/색

19103 Recommendation 15 : 반드시 가독성을 고려해야 한다. 폰트 크기는 확대/축소비율까지 고려하여 8포인트 이상이 되어야 함.(예: 12 pt font at 90% is 12*0.9 = 10.8 pt)

Less is More 원칙과 관련 깊음. 문서는 출력했을 때 해당 크기 이상이 되도록 작업해야 한다.

INSPIRE Repository tutorial 에 따르면 Ariel이 기본 폰트임.

다른 지형지물카탈로그에서 가져온 클래스를 다른 색으로 표현하면 이해하는 데 도움이 됨. 하지만 이것은 그래픽 표현일 뿐, 모델 의미론에는 색 정보는 저장될 수 없음

ISO 표준의 그림들엔 색이 없어야 한다. 실제로 사용될 수도 있는데, ISO 를 대상으로 할때는 반드시 흑백으로 export 시켜야함. 다른 목적으로(예: INSPIRE) 색깔을 사용할 수 있는데, 이 때는 반드시 범례를 만들 것.

19160-1 Addressing - 개념모델에서는 "(base) 클래스는 배경을 투명하게, 프로파일 해당 클래스의 경우엔 shaded fill color 배경을 사용할 것"

Less is More 원문은 여기

5 rules for better UML diagrams 를 참조할 것

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

예: 아래 그림 19157) 데이터품질 단위는 DQ_DataQuality와 하나 이상의 DQ_Element로 구성됨을 나타낸다. 따라서 DQ_Element의 속성 및 관련 요소(연관)은 모두 숨김 처리했다.

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

한요소 : 클래스 우클릭 - Features & Properties -> Feature and Compartment Visibility 
           (Cntl-Sht-Y)
모든요소: Diagram - 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 직각으로

5 rules for better UML diagrams 를 참조할 것

잘 정돈된 다이어그램은 이해하기 쉽다. 수평/수직으로 정돈하고 직각 연결선 사용

- 수평/수직 정렬 및 크기 조절은 여러개의 요소 선택후 우클릭
- 선 스타일은 선 우클릭 - Line Style (Tree style - Vertical)

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

다른 표준에서 온 클래스는 다이어그램에서 어디에서 왔는지 표시해야 한다.

첫번째 방법 : 경계선

경계선을 치고 해당 표준의 이름과 버전을 표시. 

Toolbox - Common(2,3)에 있음

두번째 방법 : 

네임스페이스를 모두 표시하는 방법 (단, 텍스트가 길어질 수 있음)

Diagram Properties - Diagram - Show Namespace - Fully Qualified Namespace

선을 교차시키지 말것

5 rules for better UML diagrams 를 참조할 것

절대 교차시키지 말것. 불가피하면 별도의 다이어그램으로 분리할 것. 아니면 모든 관계가 올바른지, 현재의 다이어그램에 반드시 포함시켜야 하는지 여부를 고민해볼 것. Less is More

상위를 위쪽으로 배치

5 rules for better UML diagrams 를 참조할 것

상위 클래스는 하위클래스 위쪽에 배치
집합관계의 경우, 소유하는 요소가 위로 배치
실현화 관계에서는 원 요소가 위로 배치

크기를 조화롭게

5 rules for better UML diagrams 를 참조할 것

크기를 조화롭게 하면 가독성을 높인다. 중요도가 동등한 하위클래스나 연관 클래스는 동일한 크기로. 요소의 높이를 같게하면 직교성 유지도 쉬움

제한(Constrains) 표시

ISO 19103 "제한이란 요소의 의미론을 선언하기 위한 목적으로 자연언어나 기계가독언어로 표시한 제한이나 조건"

19103 Recommendation 14 : 제한은 OCL 2.0으로 표시해야 한다. 또한 자연언어로 해당 모델의 문서화와 함께 표시해야 한다."

OCL은 직관적이지 않으므로 먼저 자연언어를 쓰고 OCL을 추가한다.

여러가지 참조문헌들 있음

구현에서.... 19136 부속서 E "모든 OCL 제한은 무시한다. 인스턴스가 제한조건에 맞는지는 GML인스턴스를 처리하는 응용의 몫이다. 비고: XML 스키마의 일부로서 Schematron 언어를 사용하여 OCL 제한을 표현할 수 있다."

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

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

제한은 반드시 클래스에 대한 속성으로서 서술되어야 한다. 속성에 대해 제한을 쓸수도 있지만, 이를 속성에 연결시키도록 표시하는 방법이 없다. 제한을 노트에 적어서는 안된다.

OCL을 쓸경우, Type=OCL로 둘 것. 해당 자연언어는 코멘트 /*... */안에 적을 것. 자연언어로만 제한을 적을 때는 Type=Invariant로. OCL의 경우, 저장할 때 EA에서 간단한 점검을 함.

[[제한을 다이어그램에 표시]]

다이어그램 전체의 제한 표시 - 다이어그램 우클릭 - Properties - Element - Constraints on

특정 한 요소의 제한 표시 - 요소 우클릭 - Feature and Compartment Visibility - Constrains on

노트에 표시하고 싶을 경우, 우선 노트를 생성한다. 링크로 연결한다. 링크 우클릭 - "Link this note to an element feature" - Feature Type = Constraint - 해당 제한 선택

2.3.3 모델 문서화

아래 3.1 모델의 자동 문서화를 볼 것

2.3.4 도움말 구현 모범사례

여기에 있는 내용은 모델이 구현되는데 영향을 미칠 수 있는 중요 모델링 관련 문제. 

ISO TC211 XMGISO TC211 GOM 도 참고할 것

Namespace/Dependency/codelist 등이 있으나, 아무런 내용도 없음

ShapeChange를 이용하여 조화를 이룬 Model로부터 XML 스키마  - 문서하단 여기 볼것

3. 모델 문서화

3.1 모델의 자동 문서화

아래 문서를 참고할 것. 별도 정리 예정

Automatic generation of documentation from UML models.docx

EA 용 템플릿 :  ISOTC11_EA_report_template.zip

ShapeChange 설정 : 여기를 볼 것

3.2 모델의 버전

새로운 버전의 패키지가 등장함에 따라 동일한 클래스에 여러 버전이 존재하게 됨

예: CI_Citation은 다음과 같은 3가지 장소에서 정의된다. 따라서 아래처럼, 다이어그램에서 표시해두면 좋다. 

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

그런데, Enterprise Architect에서 검색을 해보면 어떤 게 어떤 버전인지 확인하기가 쉽지 않다.

위에서 보이는 Status/Phase/Version을 이용하여 표시할 수 있다. 

Package에 우클릭->Advanced->Update Package 하면 Package의 모든 요소가 변경된다.

Status - Approved/Proposed/Implemented/Superseded

Phase - WD/CD/DIS/FDIS/IS/DTS/TS

Version - free text. 모델 발행년도

3.3 다이어그램 내보내기

Publish - Save Image - Save to File (.bmp/jpg 등 선택)
Publish - Save Image - Save to Clipboard (.wmf 포맷)

색 x : Layout - Appearance - Theme and appearance - Theme - Diagram Theme - 
                Monochrome for printing 
        또는 Start - View - Preference ....
프레임 x : Theme and appearance option - Diagram - Diagram Frames에서 선택

4. 도구, 스크립트 등

EA 샘플 스크립트

EA에서 모델 찾기

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

- 여러가지 미리 정해진 찾기 기능(Built-in Search)

- import Search (XML) - XML로 만들어둔 Search???

- MDG Technology의 일부 검색 ??

- SQL을 사용한 검색 정의 가능 (나중에 필요시 정리할 예정임)

ShapeChange plugin

- 노르웨이 제품사양작업을 간단히 할 수 있는 플러그인. UML을 노르웨이 표준으로 실현화.
- 플러그인의 일부로서 SOSI UML 프로파일을 설치함
Download ShapeChange plugin in EA (zip)

ShapeChange를 이용하여 조화를 이룬 Model로부터 XML 스키마 생성

- 별도 정리 필요

==

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

댓글을 달아 주세요

BLOG main image
드론과 지도
드론이 세상을 바꾸고 있습니다.드론의 활용처가 계속 넓어지고 있고, 글로벌 기업들의 참여가 많아지고 있으며, 새로운 기술들이 속속 등장하고 있습니다. 하지만 우리나라의 드론 산업은 일부 기업을 제외하면 중국에서 생산된 드론을 가져다가 조립하는 수준이 대부분입니다. 드론은 하드웨어, 소프트웨어, 데이터처리가 복합된 기술입니다. 어떤 기술들을 어떻게 조합할지에 성패가 달렸죠. 5년뒤 10년뒤에 이 블로그엔 어떤 글이 적힐까요? 그것이 궁금합니다.
by 푸른하늘이
Profile for bluesky61

달력

«   2018/09   »
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30            

카테고리

전체보기 (1586)
구글어스 (829)
공간정보 (236)
사진 (103)
드론/쿼드콥터 (239)
지오캐싱 (47)
기타 (131)
  • 4,491,867
  • 201574
TNM Media textcube get rss

드론과 지도

푸른하늘이's Blog is powered by Tistory. / Supported by TNM Media.
Copyright by 푸른하늘이 [ http://www.ringblog.com ]. All rights reserved.

Textcube TNM Media
푸른하늘이's Blog is powered by Tistory. Designed by Qwer999. Supported by TNM Media.