[DevOn MDD] 컴포넌트 상호작용 도출

junghan·2023년 10월 3일
1

MDD

목록 보기
4/6
post-thumbnail

컴포넌트 상호작용 기초설계

컴포넌트 상호작용은 시스템 내부의 컴포넌트간 상호작용을 정의하게 됩니다.
상호작용은 주로 오퍼레이션이라는 수단을 통해서 이루어지는데, 이를 위해 오퍼레이션 도출과 매개 변수로 사용되는 DTO의 정의가 이 과정의 주요 작업입니다.

컴포넌트 상호작용 기초설계의 작업 절차를 살펴보겠습니다. 살펴볼 절차는 MDD 방법론에 있어서의 일반적인 순서입니다.

  • 먼저 컴포넌트 실현을 생성하여 기능을 구현하는 컴포넌트 상호작용들을 위치시킬 작업 공간을 만듭니다.
  • 계속해서 오퍼레이션을 설계합니다. 단, 이는 프로세스 계열의 컴포넌트에 해당되는 사항이라는 것, 기억하기를 바랍니다.
  • 엔터티 컴포넌트의 경우에는 컴포넌트 실현을 생성하고 엔터티를 통해 달성할 기능에 대하여 오퍼레이션을 도출하면 됩니다.
  • 오퍼레이션 도출 후 서로 데이터를 주고 받기 위하여 DTO를 설계하게 되며 설계된 DTO를 이용하여 오퍼레이션에 입출력 매개변수들을 설정해줍니다.
  • 이렇게 컴포넌트의 기능에 해당되는 오퍼레이션에 관련된 정의를 마치면 컴포넌트 상호작용을 생성하고 오퍼레이션이 실제 동작되는 모습을 설계하기 위하여 상호작용 모델을 작성하게 됩니다.

오퍼레이션 설계부터 컴포넌트 상호작용 모델을 작성하는 일련의 작업은 컴포넌트를 구성하는 각각의 오퍼레이션에 대하여 반복적으로 수행해야 합니다.



컨포넌트 상호작용 절차

컴포넌트 실현 생성

컴포넌트 실현 / CORA(Component Operation Realization)

  • UML의 협업이라는 방법을 통해 작성
  • 컴포넌트의 기능 구현 즉, 상호작용을 설계하는 공간
  • 명명규칙: CORA_+컴포넌트명(CORA:Component Operation Realization)
  • 모든 종류의 컴포넌트 아래에 하나의 CORA를 작성합니다.
  • 스테레오타입: 없음
  • 작성 위치: 해당 컴포넌트 패키지 아래에 작성
    • CORA 안에는 오퍼레이션들의 시퀀스 다이어그램들이 들어있습니다.


오퍼레이션 설계

컴포넌트의 인터페이스를 식별했다면 인터페이스 안에 하나 이상의 오퍼레이션이 존재하게 됩니다. 오퍼레이션은 컴포넌트의 상호작용을 위한 수단입니다.

  • 명명규칙: 의미 있는 명사 + 동사형 명사
    • 오퍼레이션의 기능을 직관적으로 이해할 수 있는 의미 있는 명사에 동사형 명사를 붙여 어떤한 유형의 기능을 수행하는지에 대해 표현되도록 합니다.

작성방법 중 명명과 관련된 몇 가지 규칙을 살펴보겠습니다.

  1. PBI, CPBI, EBI를 명명할 때 사용하는 동사형 명사는 등록, 수정, 삭제, 조회, 저장, 검증 등 프로젝트에서 정의하는 규칙에 따름
  2. DAO의 동사형 명사는 등록, 수정, 삭제, 조회, 락조회 이렇게 다섯자리를 기본 사용 (락조회는 프로젝트에 따라 수정조회라 명명하기도 합니다.)
  3. Multi Data를 처리하는 오퍼레이션은 동사형 명사 앞에 '목록'을 붙임
  4. 데이터 처리 위해 오퍼레이션의 입력과 출력 매개변수 정의


DTO(Data Transfer Object) 설계

앞에서 설계한 오퍼레이션에서 정보를 주고 받는 매개체가 필요합니다. 이것을 DTO라고 말합니다.

  • 설계한 오퍼레이션에서 정보를 주고 받는 매개체 (한 마디로 정보를 담는 그릇)
  • 테이블에 정보를 등록하는 오퍼레이션을 설계한다고 할 때, 테이블 전체 정보를 DTO의 속성으로 만들어 상호작용시 사용합니다.
  • 조회 조건용 DTO나 화면 DTO도 설계합니다.
  • 하나의 DTO는 한 개 이상의 속성으로 구성되며, 속성은 String, Long, Big Decimal을 사용합니다.

DTO 작성 기준

  • PBI, CPBI, IBI : 기본적으로 하나의 오퍼레이션 당 한 쌍의 입출력 DTO 생성
    • DTO명에 입력, 결과라는 이름을 붙여 어떠한 오퍼레이션의 입출력으로 사용되는지 명시
  • EBI: 테이블 전체의 컬럼에 상응하는 DTO와 PK 속성을 지닌 DTO 생성
    • 이는 등록, 수정, 테이블 전체에 대한 조회 시에 공통으로 사용될 수 있습니다.
  • 스테레오타입: << dto >>, << dtoTb >>, << dtoPk >>
    • 일반적으로 << dto >>라는 스테레오타입을 사용
    • 테이블 전체의 내용을 가지고 있는 경우엔 << dtoTb >>
    • 테이블의 키를 가지고 있는 경우엔 << dtoPk >>
    • DTO를 설계하는 이유는 속성들을 담기 위함이며, 속성들 역시 attr이라는 스테레오타입을 갖습니다.
      • 속성 스테레오타입: << attr >>
    • 물론, 입력이나 출력이 필요 없는 오퍼레이션의 경우에는 속성을 주거나 받을 일이 없기 때문에 DTO를 설계하지 않아도 됩니다.
  • 작성위치: 각 컴포넌트 내 DTO 패키지 안에 작성

PBI DTO와 EBI DTO의 작성위치를 화면에 제시된 예시를 통해 확인해 보시기 바랍니다.

더미 DTO

지금까지 살펴본 DTO와 달리 조금 특별한 DTO인 더미 DTO에 대해 알아보도록 하겠습니다. DTO에서 오퍼레이션의 입력과 리턴 매개변수는 하나만 가능합니다.
그런데 두 개 이상의 DTO를 입력하고 리턴 매개변수로 사용해야 하는 경우가 많이 있습니다.
이를 해결하기 위하여 DTO를 포함하는 DTO를 사용해야 하는데, 이와 같이 다른 DTO를 포함하는 관계형 DTO를 더미 DTO라고 합니다.

아래의 화면에는 여러 개의 입력항목과 결과항목이 있습니다.

고객연락처관리를 조회할 때 입력 매개변수는 고객번호와 조회이용목적입니다.

이것을 '고객연락처조회입력' 이라는 하나의 DTO로 입력 매개변수를 설계할 수 있습니다.

처리 결과는 '고객기본사항', '조회결과', '상세정보'로 구분하여 화면에 보여줍니다.

'고객기본사항'은 고객성명, 인격코드, 실명번호 등을 속성으로 가지고 있고, '조회결과'는 그리드로 복수의 건을 보여줍니다.

결과를 구성하는 항목을 만일 하나의 DTO로 설계한다면 매우 복잡하고 관리하기 어려울 뿐만 아니라 단건과 복수건을 같이 처리하기가 어렵습니다. 따라서 이들을 각각의 DTO로 설계하고 3개의 DTO를 묶어서 더미 DTO로 설계해야 합니다.

더미 DTO 작성 방법

더미 DTO 작성 방법에 대해 살펴보도록 하겠습니다.

  • 더미 DTO는 메시지 다이어그램으로 더미 DTO와 다른 DTO와의 관계를 도식화 하여 생성합니다.
  • 더미 DTO는 속성(attribute)을 가질 수 없고, 다른 DTO를 포함할 수만 있습니다.
  • 더미 DTO에 포함되는 DTO의 다중성이 1이면 단건 DTO. *이면 DTO 배열이 됩니다.
    • 즉, 더미 DTO는 단건 또는 DTO 배열 모두를 포함 할 수 있습니다.

더미 DTO 메시지 다이어그램의 예시를 자세히 살펴보도록 하겠습니다.
메시지 다이어그램은 UML의 클래스 다이어그램으로 작성합니다.

그림에서 속성을 가지지 않는 DTO인 '고객계좌더미'가 더미 DTO입니다. 고객계좌더미는 고객기본 DTO와 계좌 DTO를 포함하게 됩니다

이 때 단건인 경우엔 DTO명과 동일한 이름으로, 배열인 경우엔 DTO명에 '목록'을 붙여서 DTO연관명을 설정합니다.
참고로 DTO 연관명은 더미 DTO가 자신이 포함한 하위 DTO를 나타내는 참조 변수명으로서, 하위 DTO에 접근할 때 사용됩니다.

참고: DTO 연관명은 더미 DTO가 자신이 포함한 하위 DTO를 나타내는 참조 변수명

그리고 하위 DTO의 다중성은 숫자 1 또는 enter image description here로 표시합니다. 다중성이 1이면 단건 DTO, enter image description here이면 DTO 배열입니다.


입력 및 출력 매개변수 설정

이번에는 오퍼레이션에 입력, 출력 매개변수를 설정하는 방법에 대해 알아보겠습니다.

오퍼레이션의 입력이나 출력으로 매개변수를 설정할 때 데이터 유형은 DTO또는 기본 데이터 타입을 정의한 UMLType을 사용할 수 있습니다.

출력 매개변수는 리턴과 출력, 두 종류가 있는데, 일반적으로 리턴 매개변수를 사용하며 전표나 장표 등을 위한 정보를 추가적으로 다룰 때 출력 매개변수를 사용합니다.

입력 및 출력 매개변수 설정 시 명명규칙:

  • 입력 매개변수 : i + 오퍼레이션명
  • 리턴 매개변수 : r + 오퍼레이션명

단, PBI 오퍼레이션의 경우엔, DTO 타입의 매개변수만 사용이 가능합니다.

이체한도검증 오퍼레이션의 매개변수 유형을 셋팅하는 경우에 대해 알아보겠습니다.

입력 매개변수에 이체한도검증입력DTO를 셋팅하면 param이라는 스테레오 타입이 붙는 매개변수의 왼쪽에 화살표가 안으로 들어가는 아이콘 모양을 확인할 수 있습니다.
출력의 경우에는 리턴 매개변수를 사용합니다. 이체한도검증결과 DTO로 리턴을 셋팅하면 화살표가 밖으로 나가는 모습의 아이콘이 나타납니다.

이체한도검증 오퍼레이션을 클릭해서 셋팅된 매개변수 정보를 확인하거나 변경할 수 있습니다.
또한 매개변수가 Single Data인지 Multi data인지를 나타내는 다중성도 셋팅할 수 있습니다.


컴포넌트 상호작용 작성 (ACSD)

오퍼레이션에 대한 설계를 마치면 컴포넌트 상호작용을 설계할 수 있습니다. 상호작용은 시퀀스 다이어그램을 사용하며, 이를 위한 설계 공간을 만들어야 하는데, 이를 ACSD라고 부릅니다.

  • 설계한 오퍼레이션을 기준으로 생성
  • 명명 규칙: ACSD_+오퍼레이션명
  • 작성 위치: PBI/EBI 패키지의 CORA 아래

컴포넌트 상호작용 생성의 예시를 함께 볼까요?
예시에는 포인트 사용이라는 기본흐름이 있습니다. 포인트사용PBI로 식별된 것을 볼 수 있습니다.

기본 흐름인 포인트사용등록, 포인트사용조회는 오른쪽에서 각 이름에 대응하는 오퍼레이션으로 설계되고 다시 이를 기준으로, ACSD로 식별되었습니다. 이제 공간에서 시퀀스 다이어그램이라는 모델링 방법을 통해 기능을 설계하면 됩니다.

ACSD를 생성한 후 컴포넌트 상호작용 모델, 즉 시퀀스 다이어그램의 내부 로직을 작성하는 방법에 대해 살펴보도록 하겠습니다.
MDD 방법론에서의 시퀀스 다이어그램은 UML의 시퀀스 다이어그램과 조금의 차이가 있습니다.
MDD에서는 시퀀스 다이어그램을 기반으로 소스코드를 자동으로 생성하기 때문에 구현하고자 하는 오퍼레이션마다 시퀀스 다이어그램을 각각 작성해야 하며, 작성 수준 역시 상세해야 합니다. 이를 위하여 논리표현식이라는 방법을 정의하여 사용하고 있습니다.

컴포넌트 상호작용 모델 작성

그럼, 상호작용 모델의 기본적인 작성 방법에 대해 알아보도록 하겠습니다.

  1. 우선 구현하고자 하는 오퍼레이션은 Client의 호출로부터 시작하는 것을 기본으로 합니다.
  2. 다음으로 구현하고자 하는 오퍼레이션이 포함된 컴포넌트의 인터페이스를 Drag & Drop하고 이를 기준으로 모든 상호작용들이 이루어집니다.
  3. 구현하고자 하는 오퍼레이션이 상호작용 하는 컴포넌트가 있다면 해당 컴포넌트의 인터페이스를 다이어그램에 Drag & Drop 하여 가져옵니다.
  4. 모든 상호작용은 기본적으로 동기 메시지 호출을 통하여 설계합니다
  5. 기타 업무 로직을 구현하는데 필요한 요소는 논리표현식을 통하여 설계합니다.

상호작용의 구성요소들을 예시를 보며 살펴보겠습니다.

  • 라이프라인 : 호출모듈이나 컴포넌트, << code >> 등 상호작용에 필요한 객체 및 그것의 생명주기

→ 다이어그램의 위쪽에 보이는 Drag & Drop 시킨 객체들, 즉, 호출모듈, 컴포넌트들, Code 등의 요소들을 라이프라인이라 부르며 이는 상호작용의 기본 요소입니다.

  • 기준 오퍼레이션: ASCD(시퀀스 다이어그램)의 주인이 되는 오퍼레이션

  • 메시지 : 다른 컴포넌트의 오퍼레이션 호출이나 논리표현식 작성에 사용되는 화살표 모양의 표기법

오퍼레이션을 호출할 때 나타나는 매개변수와 관련하여 오퍼레이션의 괄호 안에는 입력 매개변수의 정보가 나타납니다.



출처:
https://wikidocs.net/130234

profile
42seoul, blockchain, web 3.0

0개의 댓글