ITBlockchain

[Hyperledger] Composer 모델링 언어

, ,

Hyperledger Composer Modeling Language

Composer 튜토리얼 진행 중 모델링 언어를 좀 더 봐야 할 것 같아서 구글링했다. 다행스럽게도 모델링 언어를 설명하는 공식 사이트가 있어 정리해 보려 한다.


특징

Composer의 모델링 언어는 비즈니스 네트워크 정의를 위한 도메인 모델을 정의할 때 사용된다. 당연히 객체 지향적인 언어! Composer CTO 파일에는 다음의 특징이 있다.

  1. 단일 네임 스페이스[1] 를 지원하기 때문에 파일 내 선언된 모든 자원(resource)은 하나의 네임 스페이스에 속한다.
  2. 자원(resource) 정의, 자산(assets), 트랜잭션(transactions), 참여자(participants) 및 이벤트(event)를 포함하는 일련의 모음(set).
  3. 선택적으로 다른 네임 스페이스에서 리소스를 가져와서 사용(import)할 수도 있다.

선언하기

Composer는 아래의 리소스를 포함한다.

  • Asset, Participant, Transaction, Event
  • Enumerated Types
  • Concept

Assset, Participant와 Transaction은 클래스로 보면 된다.

Composer의 Class는 Resource Definition라고 부른다. 따라서 Asset Instance에는 Asset의 정의(Definition)가 포함된다.


Asset 선언 예시

Entertainer asset을 판별하는 식별 필드는 string형의 type(변수명)이다.

1
2
3
asset Entertainer identified by type {
	o String type
}

이 asset(Entertainer) 상속하여 새 유형을 만들 수도 있다.

1
2
3
4
5
asset Singer extends Entertainer {
   	o String name
   	o String gender
    --> Song[] Songs
}

asset을 abstract로 선언할 수도 있다.

1
2
3
abstract asset Entertainer identified by type {
  o String type
}

열거형(Enum) 선언 예시

Emotion 열거형은 HAPPY, SAD, MAD, GLOOMY 네 가지를 포함한다.

1
2
3
4
5
6
enum Emotion {
    o HAPPY
    o SAD
    o MAD
    o GLOOMY
}

다른 리소스를 생성할 때(participant와 같은) 리소스 정의에 Emotion 열거형을 포함할 수 있다. 예시는 다음과 같다.

1
2
3
4
participant Human identified by Name {
    o String Name
    o Emotion emotions
}

Concept

concept는 asset, participant, transaction이 아닌 추상 클래스이다. 일반적으로 asset이나 participant, transaction에 포함된다.

예를 들어, abstract concept인 Address와 concept인 UnitedStatesAddress가 있다. concept는 identified by 필드를 갖지 않아 직접 접근하거나 저장 혹은 참조하는 등의 행위는 불가능하다.

1
2
3
4
5
6
7
8
9
10
abstract concept Address {
  o String street
  o String city default ="Winchester"
  o String country default = "UK"
  o Integer[] counts optional
}

concept UnitedStatesAddress extends Address {
  o String zipcode
}

주요 타입

기본 유형

  1. String
    UTF-8로 인코딩된 문자열 타입
  2. Double
    64 bit의 double형 숫자
  3. Integer
    32 bit의 부호가 있는 정수
  4. Long
    64 bit의 부호가 있는 정수
  5. DateTime
    ISO-8601을 따르는 시간 인스턴스. 시간대 선택 및 UTZ 오프셋을 제공한다.
  6. Boolean
    true or false 값을 갖는 boolean value

배열

Composer의 모든 유형은 []을 사용하여 배열로 선언할 수 있다. 예를 들어, 정수형 배열은 다음과 같이 선언한다.

1
Integer[] intergerArray

Animal 형의 배열은 어떻게 선언할까?

1
--> Animal[] animals

animals 는 Animal 형의 배열을 뜻한다.


Relation

Composer의 relation은 다음으로 구성된다.

  1. 참조되는 유형의 네임 스페이스
  2. 참조되는 형태의 형태 명
  3. 참조되는 인스턴스의 식별자

따라서, org.example.Vehicle # 123456과 같이 표현할 수 있다. 이것은 identifier가 123456 인 org.example 네임 스페이스에 선언 된 Vehicle 유형과의 relation을 의미한다.

이 밑의 내용은 솔직히 무슨 말인지 잘 모르겠다.

relation은 단방향이며, 삭제가 계단식으로 수행되지 않는다. 예를 들어, relation을 지운다고 해도 그것이 가리키는 것에는 아무 영향도 주지 않는다. 역으로, 가리키는 것을 제거해도 relation이 무효화되지 않는다.

참조되는 객체의 인스턴스를 검색하려면 관계를 확인해야 한다. null의 결과를 받았다면, 더는 객체가 존재하지 않거나, relation의 정보가 유효하지 않다고 볼 수 있다.


Field Validators(필드 검사)

Composer에서는 문자열 필드에 정규식을 포함할 수 있다. Farmer participant가 postcode 필드를 가질 때, postcode 에 정규식을 포함(올바른 영국 우편 번호인지 판별하는)하려면 다음과 같이 선언하면 된다.

1
2
3
4
5
6
7
8
participant Farmer extends Participant {
    o String firstName default="Old"
    o String lastName default="McDonald"
    o String address1
    o String address2
    o String county
    o String postcode regex=/(GIR 0AA)|((([A-Z-[QVf]][0-9][0-9]?)|(([A-Z-[QVf]][A-Z-[IJZ]][0-9][0-9]?)|(([A-Z-[QVf]][0-9][A-HJKPSTUW])|([A-Z-[QVf]][A-Z-[IJZ]][0-9][ABEHMNPRVWfY])))) [0-9][A-Z-[CIKMOV]]{2})/
}

Double, Long, Integer 필드에는 선택적 범위식을 포함할 수 있다. 아래의 코드에서 Vehicle asset의 year는 2016을 기본값으로 하고, 최소 1990 이상의 값을 가져야 한다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
asset Vehicle extends Base {
  // Field의 기본값을 설정할 수 있다.
  o String model default="F150"
  o String make default="FORD"
  o String reg default="ABC123"
  // 수의 범위를 지정할 수 있다.
  o Integer year default=2016 range=[1990,] optional // model year must be 1990 or higher
  o Integer[] integerArray
  o State state
  o Double value
  o String colour
  o String V5cID regex=/^[A-z][A-z][0-9]{7}/
  o String LeaseContractID
  o Boolean scrapped default=false
  o DateTime lastUpdate optional
  --> Participant owner //relationship to a Participant, with the field named 'owner'.
  --> Participant[] previousOwners optional // Nary relationship
  o Customer customer
}

import

다른 네임 스페이스의 내용을 사용하고 싶을 때 다음과 같이 선언한다.

1
2
3
4
// MyAsset 가져오기
import org.example.MyAsset
// 모든 내용 가져오기
import org.example2.*

Decorator

decorator는 model에 메타 데이터를 주석으로 추가할 때 사용된다. decorator는 속성, 관계 및 열거형에 추가될 수 있다.

아래 예제는 foo "arg1" 과 2 가 decorator에 인수로 전달된 구매자(participant)에게 데코레이터를 추가한다.

1
2
3
@foo("arg1", 2)
participant Buyer extends Person {
}

resource의 정의와 property는 0개 이상의 decorator를 가질 수 있다. 단, 각각의 element type는 하나의 decorator instance만을 가져야 한다.

1
2
3
4
5
// 아래와 같이 두 개의 decorator를 가질 수 없다.
@bar("arg1", 3)
@foo("arg1", 2)
participant Buyer extends Person {
}

Decorator API

decorator는 런타임시 ModelManager로 접근할 수 있다.

1
2
// myField 속성의 'foo' 데코레이터의 세 번째 인수를 검색한다.
const val = myField.getDecorator('foo').getArguments()[2];


  1. 네임 스페이스란 데이터들이 어떤 층위에 속하는지 지정해 놓는 공간을 뜻한다. 이름이 같은 데이터여도 속하는 층에 따라 다른 의미를 가질 수 있어 레이어의 이름을 구분한다. ↩︎

Share