[시스템 거동 도메인 개발 1] 거동 도메인 솔루션에 대한 주요 요소

[시스템 거동 도메인 개발 2] 거동 아키텍처 개발

[시스템 거동 도메인 개발 3] 거동 도메인 솔루션 개발방법

거동 아키텍처 개발

시스템이나 개체 운용 아키텍처가 진화하면서 성숙됨에 따라 그다음 단계는 그 시스템과 연관된 개체(UML 행위자)가 다양한 운용자와 외부 시스템 자극과 충격이 어떻게 상호작용하며 반응하는지를 이해함에 있다. 이러한 기초적인 이해는 다음과 같이 시작된다.

· 운용 아키텍처에서 식별된 개체
· 시스템 성능규격(SPS) 또는 개체 개발규격과 같은 규격에 제시된 능력

시스템이나 개체 개발 단계에서 그 개체란 단순하게 추상적으로 나타난다. 이는 추상적인 분석으로서 우리는 이를 가리켜 논리적이거나 연상적인 관계라고 생각한다. 여기서 우리의 도전은 이러한 관계를 표시하는 논리적/기능적 구조를 생성하는 일이다. 우리는 이를 가리켜 논리적 또는 기능적 아키텍처라고 부른다.

1. 논리적 아키텍처 기반
논리적 또는 기능적 아키텍처는 주요 능력, 다중 레벨 논리적 또는 기능적 능력과 운용 도메인 솔루션 요소 사이에 상호관계를 나타낸다. 논리적/기능적 아키텍처는 그 시스템이나 개체가 다양한 임무와 시나리오에 어떻게 주어진 운용환경에 대응하는 거동 상호작용을 표현하기 위한 구조를 제공해 준다. 

그 시스템이나 개체에 입력 프로세스를 수행함에 따라 이는 거동형태와 특성을 나타낸다. 내부적인 프로세스를 수행하기 위하여 시스템이나 개체는 입력 세트를 거동, 제품, 부산물 및 서비스로 전환하기 위하여 하나 또는 그 이상의 능력을 제공하게 된다. 

그 시스템이 주어진 운용환경에서 상호 호의적 또는 적대적 관계를 유지하려고 한다면, 추가적인 능력이 이러한 개체의 상호작용 동안에 생존성이나 상호 운용성 레벨을 확인해야 한다. 

시스템 상호작용에 대한 보다 많은 정보를 위해 운용환경과의 시스템 상호작용과 시스템 인터페이스 분석, 설계 및 통제 실무를 참조하기 바란다.

우리가 이러한 환경을 분석해감에 따라 우리는 그 시스템에 의해 파생되는 거동, 제품, 부산물 또는 서비스를 나타내거나 상호작용하는 버츄얼 및 물리적 시스템 개체 또는 사람, 능력, 운용, 기능, 이벤트, 역할, 제약사항 및 통제와 같은 행위자(UML)가 있다는 사실을 발견하게 된다. 우리는 이러한 사람, 능력, 운용, 기능, 이벤트, 역할, 제약사항 및 통제를 객체, 개체 또는 행위자로 분류한다. 일반적으로 그 행위자, 객체 또는 개체는 사람, 장소, 사물과 같이 명사로 식별된다.

논리적/기능적 아키텍처는 그 임무를 수행하기 위하여 시스템이 수행할 능력에 기여하기 위해 무슨 관계와 상호작용이 요구되는지를 나타낸다. 이러한 특성은 객체와 상호작용이 어떻게 물리적으로 적용되어야 하는지를 나타내진 않는다. 여기서 물리적 도메인 솔루션은 물리적 아키텍처로 어떻게 수행되는 지를 나타내게 된다. 항상 기능이 형태와 적용보다 먼저 주어진다.

2. 논리적/기능적 아키텍처 개발 방법
우리는 논리적/기능적 아키텍처는 그 대상, 개체, 또는 행위자를 나타낸다는 사실을 살펴보았다. 이는 하부시스템인 제품, 아셈부리 그리고 이들 상호간의 관계처럼 주어진 추상적이고 클래스 개체 내에서 존재한다. 그러면 우리가 어떻게 이러한 아키텍처를 개발할 것인가라고 질문해 본다.
하나의 접근방법은 아래와 같은 단계로 구성된 간단한 방법을 적용하는 방법이다.

1 단계 : 논리적 객체 또는 개체를 식별하라.
2 단계 : 각 개체 능력을 식별하라.
3 단계 : 논리적 상호관계 매트릭스를 생성하라.
4 단계 : 논리적/기능적 아키텍처를 생성하라.

이러한 각 단계에 대하여 보다 상세하게 살펴보자.

(1) 논리적 객체 또는 개체 식별
논리적 또는 기능적 아키텍처를 개발하기 위한 첫 번째 단계는 시스템이나 개체의 요구능력을 식별하여 목록을 단순하게 생성함에 있다. 그리고 다음 그림 3에서와 같이 유사하게 계층 트리로 목록을 정리하는 일이다.

그림 3. 자동차-운전자 논리적 요소

여기에 나타난 사례는 자동차-운전자 시스템을 보여주고 있다.

(2) 각 개체 능력 식별
한 번 당신이 시스템이나 개체의 주요 능력을 식별하고 나면, 다음 단계는 그 능력 상호간의 관계를 형성함에 있다. 사용되는 기법은 시스템이나 개체의 크기와 복잡도에 달려있다. 만일 당신이 시스템 블록선도, SBD로 시작한다면, 그 방법은 매우 도전적일 수 있다. 당신은 당신이 그 관계만을 정리하는 것뿐만 아니라 그래프로 나타내는 길을 제시하게 된다. 상호 연결하는 선은 그 도표를 불필요하게 복잡하거나 혼돈을 가져오지 않도록 하는 상호 교차하는 길을 알려주는 역할을 하게 된다.

(3) 논리적 상호관계 매트릭스
그러면 우리는 어떻게 시스템의 논리적/기능적 및 상호작용 관계를 모델화 할 것인가? 첫 번째로 우리는 그림 4의 상단 왼쪽에 있는 매트릭스를 생성하여 이를 할 수 있다.

그림 4. 거동 솔루션 능력 상호작용

이러한 N×N 매트릭스는 입력사항인 자극과 출력사항인 반응처럼 하나의 능력을 다름 능력으로 연결해 주는 도표이다. 능력 A는 능력 B로, 능력 B는 능력 C로, 그리고 더 아래로 논리적 개체관계를 보여주고 있다. 대형 복합 시스템에 대하여 요약 매트릭스는 다음 단계에 대한 기반을 조성해 준다.

별도의 단계를 생성하기 위해 나타난다 할지라도 매트릭스는 중요한 분석적 비교 모델로 역할하게 된다. 상호 대응 방법에서 우리는 하나의 요소에 집중하며 매트릭스 줄을 넘은 각 나머지 요소와 함께 개체 관계를 가진다면 그때에 결정하게 된다. 다음 단계는 프레젠테이션 목적을 위해 논리적 아키텍처를 그래프로 전환하는 단계이다. 만일 우리가 다음 단계를 먼저 생성하려고 한다면, 매트릭스의 강점과 N×N 접근방법으로서 모든 상호작용으로 여겨지는 분명한 방법을 무시하고 있게 된다.

(4) 논리적 및 기능적 아키텍처 생성
만일 논리적 상호작용 매트릭스가 형성되고 나면, 그림 4의 오른쪽 하단에 나타난 N×N 도표를 그래프로 전환하게 된다. 각 능력은 기대되는 산출물과 성능레벨을 생산하기 위해 요구되는 활동을 수행하는 다중 레벨의 운용 또는 업무를 나타낸다.
N×N 방법에 대한 대안은 그림 5에 나타난 객체지향(OO) 표기방법이다.

그림 5. 논리적 개체에 대한 객체지향 표기법

이 방법은 각 능력에 대한 이름, 속성, 운용에 대한 내용을 기술한다. 유사한 표기법은 그림 4에 나타난 N×N 도표에 이를 부가하여 사용할 수 있다.

지금까지 우리는 기본적인 논리적/기능적 아키텍처를 어떻게 형성하는가를 소개했다. 여기에서 가장 중요한 점은 시스템이나 개체의 일차 기능을 식별함에 있다. 우리가 이를 어떻게 식별하느냐 하는 것은 그 시스템이 잘 알려졌느냐 또는 잘 알려지지 않으냐에 달려있다. 따라서 기본적인 아키텍처 요소가 알려질 경우에는 불필요한 분석을 하지 않아도 된다.

3. 잘 알려진 시스템의 논리적/기능적 아키텍처 개발
대부분의 인공 시스템은 잘 알려진 시스템이다. 이미 입증된 아키텍처와 기술은 기존 설계를 향상함에 달려있다. 다음 사례를 살펴보자.

잘 알려진 시스템으로 자동차는 새시, 엔진, 등으로 구성되어 있다. 비록 당신이 창의적인 설계 솔루션을 제한하고 ‘주어진 틀 속에서 생각’의 패러다임을 피할 필요가 있지만, 우리는 자동차의 근본적인 설계를 기능적으로, 예를 들면 새시, 엔진, 바디를 생성하기 위해 재설계할 필요는 없다. 우리는 초기단계에서 기존의 자동차 아키텍처를 재사용하면 된다.

가설적으로 만일 당신이 두 개의 통제 그룹과 동일 시스템에 대하여 논리적 아키텍처를 생성하기 위하여 각 개별로 임무를 부여한다면, 그 그래프는 달라져도 좋다. 한 아키텍처는 맞고 다른 아키텍처는 틀린 것인가? 일반적으로 그렇지 않다. 항상 동일한 엔지니어링 문제점을 해결함에 있어서 다양한 접근방법이 있을 수 있다. 우리는 자동차, 컴퓨터, 텔레비전과 같은 상업제품에서 이러한 점을 볼 수 있다. 일반적으로 유사한 마켓 솔루션 영역 가정을 할 수 있다. 예를 들면, 운송, 조향 및 이와 유사한 경우를 생각해 볼 수 있다.

4. ‌잘 알려지지 않은 시스템의 논리적/기능적 아키텍처 개발
상대적으로 잘 알려져 있지 않은 시스템은 시스템의 논리적/기능적 아키텍처를 접근함에 있어서 주어진 태두리 영역 밖에서 생각하는 새로운 방법을 요구하고 있다. 다음 사례를 생각해 보자.

NASA가 이전에 달나라에 무인 비행선에 성공했다 할지라도, 아폴로 달나라 비행은 사람이 타고 달 표면에 내리고 다시 비행하는 첫 번째 설계이다.

NASA의 우주정거장 프로그램은 인간이 무중력 상태에서 연장된 일정 기간에 특정 업무를 수행하기 위한 우주 공간에서의 실험 환경에서 사람이 거주할 수 있는 최초의 환경을 제시했다.

잘 알려지지 않은 시스템이의 경우라면, 개발팀은 가상 임무 또는 과학적 목표로부터 논리적/기능적 아키텍처를 도출함에 있다. 이는 ‘크고 장엄한 과학을 적용하라’는 의미로 볼 수 있다. 이러한 경우에 시스템 엔지니어는 연구 주 책임자와 협력하여 그 시스템의 능력을 도출하고 생성하게 된다. 일부 획득자는 연구계약이나 개념제시계약을 시도하기도 한다. 이는 시스템 능력을 구하기 위해 일련의 점진적인 계약 단계를 통해 수행하기도 한다.

5. 논리적/기능적 아키텍처 모델링
논리적/기능적 아키텍처는 시스템이나 개체의 내장 요소 및 그들의 상호관계를 나타내기 위해 시스템 블록선도(SBDs), 목표 도표, 기타 그래픽 기법으로 모델기반 표기방법으로 사용하고 있다. 그러나 SBDs는 행위자 또는 객체 상호간 발생하는 데이터 교환이나 거동 상호작용의 논리적 순서를 제시하진 않는다. 

따라서 각 후보 아키텍처 솔루션의 전반적인 효과도를 평가하기 위하여 시계열, 성능 예산 및 안전 마진 할당과 연계하여 거동 모델링 도구가 사용된다. 이러한 거동 모델링 도구로서는 N×N 도표, UML 상호작용 도표, 기능흐름선도(FFBD), 통제 및 데이터 흐름선도 등이 사용되고 있다.

당신은 왜 우리가 논리적/기능적 아키텍처 모델을 생성할 필요가 있는지를 질문해 보아야 한다. 논리적/기능적 아키텍처 모델링과 내부능력 처리 프로세스는 다음과 같은 내용에 필수적으로 요구된다.

· 아직 발견되지 않은 요구사항을 도출하고 알아보기 위함
· 시스템이나 개체의 성능 예산과 마진을 설정
· 시스템 성능 최적화를 위한 ‘로드’ 배분
· 요구사항을 하위레벨로 할당과 분할하고 품목 개발규격 제시

6. 소결론
논리적 개체 관계는 우리로 하여금 확인된 운용 요구에 근거하여 둘 또는 그 이상의 논리적 개체상의 연합이나 연계성을 알아보기 위해 사용된다. 이는 필요성에 입각한 상호관계이기 때문에 다음 사항이 강조되어야 한다.

· 누가 누구와 상호 작용하고 있는가.
· 무슨 사항이 상호작용하거나 소통되어야 하는가.
· 언제 그 거동 상호작용이 일어나는가.
· 어떤 상태에서 일어나는가.

이러한 논의에 근거하여 거동 도메인 솔루션을 개발하기 위해 사용되는 기본 방법을 기술해 보자. 이러한 방법을 당신의 비즈니스 요구에 적합하도록 적용해 보라.
지금까지 우리는 거동 도메인 솔루션에 대한 구조로서 나타나는 논리적/기능적 아키텍처를 생성하는 방법을 기술해 보았다. 이제 우리는 그 초점을 시스템이나 개체의 전반적인 거동 도메인 솔루션을 생성하기 위한 방법을 알아보도록 하자.

민성기  시스템체계공학원장 (sungkmin0@gmail.com)

정리 : 임근난 기자 (fa@hellot.net)