SEBoK: 논리 아키텍처 (Logical Architecture)

논리 아키텍처 모델 개발은 “후보 아키텍처 모델 및 뷰 개발” 활동의 작업으로 사용되거나, 시스템 아키텍처 설계 정의 프로세스의 하위 프로세스로 사용될 수 있습니다. 그 목적은 서비스 중에 작동할 미래의 엔지니어링 시스템의 기능과 동작을 모델과 뷰로 구체화하는 것입니다. 관심 있는 엔지니어링 시스템(SoI)의 논리 아키텍처 모델은 시스템의 논리적 운영을 지원하는 관련 기술 개념과 원칙의 집합으로 구성됩니다. 여기에는 기능 아키텍처 뷰, 행동 아키텍처 뷰, 시간적 아키텍처 뷰가 포함될 수 있습니다. 도메인에 따라 아키텍처 프레임워크에서는 추가적인 뷰도 제안될 수 있습니다.

참고: 논리 아키텍처(Logical Architecture)라는 용어는 시스템 아키텍처의 논리적 뷰(Logical View of the System Architecture)라는 표현의 축약형입니다.

 

1. 논리 아키텍처의 개념 및 원칙 (Logical Architecture: Concepts and Principles)

1.1 기능 아키텍처 모델

기능 아키텍처 모델은 시스템이 임무를 완료하기 위해 수행하는 변환을 정의하는 기능과 그 하위 기능들의 집합입니다.

 

기능과 입력-출력 흐름 - 시스템 아키텍처의 맥락에서, 기능과 입력-출력 흐름은 아키텍처 엔터티입니다. 기능은 입력을 변환하고 출력을 생성하는 행동으로, 여기에는 데이터, 물질, 에너지가 포함됩니다. 이러한 입력과 출력은 기능 간에 교환되는 흐름 항목입니다. 일반적인 수학적 함수 표기는 y = ƒ(x, t)로, 여기서 y와 x는 그래픽으로 표현될 수 있는 벡터이며 t는 시간입니다.

 

시스템의 모든 기능을 정의하려면 시스템과 그로부터 도출된 요구 사항에 의해 필요로 하는 모든 기능과 해당 기능의 입력 및 출력을 식별해야 합니다. 일반적으로 두 가지 유형의 기능이 있습니다:

1. 직접적으로 도출된 기능 - 이는 시스템 요구 사항을 충족하기 위해 필요한 시스템의 예상 서비스를 표현하는 기능입니다.
2. 물리적 아키텍처 모델의 대안 솔루션에서 파생된 기능 - 이러한 기능은 설계 결과에 따라 달라지며, 논리 아키텍처 모델 요소를 구현하기 위한 기술 선택에 의존합니다.

기능 계층 구조/기능의 분해 - 계층 구조의 최상위 레벨에서 시스템은 그림 1에서 보는 바와 같이 유일하고 중심적인 기능으로 표현될 수 있으며, 이는 시스템의 임무로 정의됩니다. 이때 시스템은 “블랙 박스”와 유사하게 “F0”으로 표시됩니다. 시스템이 수행하는 작업을 자세히 이해하기 위해, 이 “계층의 머리” (F0)는 하위 기능(F1, F2, F3, F4)으로 분해되어 하위 계층(계획 A0)을 형성하며, 이 과정은 계속됩니다. 기능 계층의 최종 레벨의 기능은 리프 기능(계획 A2의 F21, F22, F23, F24)이라고 불릴 수 있습니다. 계층 구조(또는 분해)는 복잡하거나 전반적인 기능을 물리적으로 실현 가능하거나 상상할 수 있는 일련의 기능으로 분해합니다.

그림 1. 기능 분해 (출처: Faisandier 2012, SEBoK v2.10)

 

이 기능 계층 구조는 반복 과정에 따라 다양한 레벨에서 기능이 채워지는 정적 관점을 나타냅니다. 일반적으로 단일 상향식 분해에 의해 생성되지 않으며, 정적 기능 계층 구조만으로는 입력과 출력 흐름이 효과적으로 교환되는 방식을 나타내지 못할 수 있습니다. 따라서 아래의 다른 모델들과 함께 고려할 필요가 있습니다.

 

1.2 행동 아키텍처 모델

행동 아키텍처 모델은 기능과 그 하위 기능, 그리고 인터페이스(입력 및 출력)의 배열로, 시스템 요구 사항을 충족하기 위해 필요한 실행 순서, 제어 또는 데이터 흐름 조건, 성능 수준을 정의합니다 (ISO/IEC 26702:2007). 행동 아키텍처 모델은 기능 및/또는 운영 모드의 상호 관련된 시나리오 집합으로 설명될 수 있습니다.

 

제어(트리거) - 제어 흐름은 기능 실행의 조건으로서 기능을 활성화하는 요소입니다. 이 요소의 상태 또는 그것이 나타내는 조건에 따라 기능(또는 그 일부)이 활성화되거나 비활성화됩니다. 제어 흐름은 신호나 이벤트일 수 있으며, 예를 들어 스위치가 켜지는 것, 알람, 트리거, 온도 변화, 또는 키보드의 키를 누르는 것 등이 해당됩니다.

 

기능 시나리오 - 기능 시나리오는 입력을 출력으로 변환하기 위한 일련의 기능들을 순차적으로 수행하고, 제어 흐름 집합에 의해 동기화된 일련의 기능 연결을 나타냅니다. 기능 시나리오는 상위 레벨 기능의 동적 특성을 표현합니다. 행동 아키텍처는 각 기능 계층 및 시스템 계층의 시나리오를 고려하여 개발됩니다. 기능 시나리오와 행동 아키텍처 모델을 표현할 때, 모델링 기법으로서 기능 흐름 블록 다이어그램(FFBD) (Oliver, Kelliher, and Keegan 1997) 또는 SysML(OMG 2010)로 개발된 활동 다이어그램과 같은 다이어그램을 사용하는 것이 적절합니다. 아래 그림 2와 3은 이러한 다이어그램의 예를 제공합니다.

그림 3. 기능 흐름 블록 다이어그램 예 (출처: SEBoK v2.10)

그림 3. Activity Diagram 예 (출처: SEBoK v2.10)

 

운영 모드 - 기능 시나리오는 각 기능에서 입력을 출력으로 변환하는 과정을 추상화하여, 기능의 활성 또는 비활성 상태와 그 제어에 초점을 맞추어 볼 수 있습니다. 이러한 관점은 모드 시나리오라고 하며, 시스템의 다양한 모드 간 전환을 일련의 전환으로 수행하는 모드 체인을 나타냅니다. 한 모드에서 다른 모드로의 전환은 제어 흐름(이벤트/트리거)이 도착함에 따라 시작됩니다. 이벤트나 트리거가 도착한 후, 두 모드 사이의 전환에서 동작(기능)이 생성될 수 있으며, 이는 아래 그림 4에서 설명됩니다.

그림 4. 운영 모드 시나리오 예 (출처: SEBoK v2.10)

 

행동 패턴 - 시나리오 또는 행동 아키텍처 모델을 정의할 때, 아키텍트는 예상되는 변환과 행동을 나타내기 위해 이미 알려진 모델을 인식하고 사용할 수 있습니다. 패턴은 처리의 복잡성에 따라 더 또는 덜 복잡할 수 있는 일반적인 기본 모델입니다 (Gamma, Helm, Johnson, and Vlissides 1995). 패턴은 여러 가지 표기법으로 표현될 수 있으며, 행동 패턴은 여러 범주로 분류됩니다. 다음은 그 예입니다(또한 SEBoK Part 2: Patterns of Systems Thinking 참조):

 

• 기본 패턴 또는 함수 연결 구조: 순서, 반복, 선택, 동시성, 다중 종료, 종료가 있는 루프, 복제와 같은 기능을 연결하는 기본 구조.

• 복잡한 패턴: 처리 모니터링, 메시지 교환, 사람과 기계 인터페이스, 모드 모니터링, 프로세스의 실시간 모니터링, 대기열 관리, 감독이 있는 지속적 모니터링.

• 고장 탐지, 식별, 복구(FDIR) 패턴: 수동 중복, 능동 중복, 반능동 중복, 성능이 감소된 상태에서의 처리.

 

1.3 시간적 아키텍처 모델

시간적 아키텍처 모델은 시스템의 기능을 실행 빈도에 따라 분류한 모델입니다. 시간적 아키텍처 모델은 동기 및 비동기 기능의 정의를 포함합니다. 시스템 내부에서 발생하는 결정 모니터링도 기능 모니터링과 관련이 있기 때문에 동일한 시간적 분류를 따릅니다.

 

시간적 및 결정적 계층 개념 - 모든 시스템 기능이 동일한 빈도로 수행되는 것은 아닙니다. 시간과 기능이 시작되고 실행되는 방식에 따라 빈도는 달라집니다. 따라서 여러 성능 등급을 고려해야 합니다. 주기적으로 실행되는 동기적 기능과 이벤트나 트리거가 발생한 후 실행되는 비동기적 기능이 있습니다.

 

더 구체적으로 말하자면, 실시간 시스템 및 명령-제어 시스템은 주기적 작업(동기적)과 사실적 측면(비동기적)을 결합합니다. 주기적 작업은 입력/출력 및 제어 흐름의 캡처 또는 분배 제약에 따라 기능의 실행을 빈도에 맞추어 분배하는 것을 포함합니다. 비동기 이벤트는 두 가지 유형으로 구분할 수 있습니다:

 

1. 고빈도에서의 방해 요소 (그림 5의 하단) - 발생한 수준 또는 그보다 한 단계 위에서 결정이 이루어집니다. 목표는 방해 요소가 저빈도에 영향을 미치지 않도록 하여 시스템이 미션 목표를 계속 달성할 수 있도록 하는 것입니다. 이는 예외 작업을 도입하는 방법으로, 일반적으로 고장이나 장애와 관련된 작업이 여기에 해당합니다.

2. 저빈도에서의 변화 (그림 5의 상단) - 상위 수준에서 이루어진 변화에 대한 결정이 이루어집니다. 궁극적인 목표는 이를 하위 수준으로 전파하여 수정 사항을 구현하는 것입니다. 대표적인 예로는 운영자 작업, 유지보수 작업 등이 있습니다.

그림 5. 시간 및 결정 계층 레벨 (Faisandier 2012, SEBoK v2.10)

 

2. 논리 아키텍처의 프로세스 접근법 (Logical Architecture: Process Approach)

2.1 논리 아키텍처 개발 목적

논리 아키텍처 모델 개발의 목적은 시스템의 논리 아키텍처 모델을 정의, 선택, 그리고 종합하는 것입니다. 이를 통해 미래의 시스템이 모든 운영 시나리오에서 시스템 요구 사항을 충족하는지 검증할 수 있는 프레임워크를 제공하며, 이 과정에서 시스템 요구 사항 간의 상충 관계를 탐색할 수 있습니다.

 

이 프로세스의 일반적인 입력은 시스템 요구 사항, 아키텍트들이 요구 사항을 해결하기 위해 식별하고 사용하는 일반적인 아키텍처 패턴, 시스템 분석 프로세스의 결과, 그리고 시스템 검증 및 검증 프로세스에서의 피드백을 포함합니다. 선택된 생명 주기 모델에 따라 이러한 입력 및 출력과 그들 간의 관계는 프로세스 전반에 걸쳐 반복적으로 진화하고 변경됩니다(생명 주기 프로세스 적용 참고).

 

프로세스의 일반적인 출력은 단일 논리 아키텍처 모델이거나 후보 논리 아키텍처 모델 세트입니다. 이들 중에서 독립적인 논리 아키텍처 모델이 선택되며, 그 선택에 대한 근거도 함께 포함됩니다. 최소한의 출력물로는 기능적, 행동적, 시간적 관점을 포함한 뷰와 모델, 논리 아키텍처 모델 요소와 시스템 요구 사항 간의 추적 매트릭스가 포함됩니다.

 

2.2 프로세스의 활동

이 프로세스 동안 수행되는 주요 활동과 작업은 다음과 같습니다:

 

• 기능적 및 행동적 요소 식별 및 분석:

• 시스템 요구 사항에서 기능, 입출력 흐름, 운영 모드, 모드 전환, 운영 시나리오를 분석하여 식별합니다.

• 각 기능에 필요한 입력과 제어(에너지, 물질, 데이터 흐름) 및 해당 기능에서 사용하는 입출력 흐름을 정의하여 필요한 기능을 도출합니다.

• 시스템 요구 사항을 기능적 및 행동적 요소에 할당:

• 성능, 효율성 및 제약 요구 사항을 할당하여 기능 표현과 속성을 공식적으로 특성화합니다. 특히 요구 사항에서 시간적 측면을 연구하여 기능에 지속 시간, 응답 시간 및 빈도를 할당합니다.

• 인터페이스, 효율성, 운영, 시간적 제약 요구 사항을 할당하여 입출력 및 제어 흐름의 표현과 속성을 공식적으로 특성화합니다.

• 시스템 요구 사항과 이러한 기능적 및 행동적 요소 간의 추적 가능성을 확립합니다.

• 후보 논리 아키텍처 모델 정의:

• 시스템 요구 사항에 명시된 운영 모드를 분석하고, 이전에 정의된 요소를 사용해 운영 모드의 시퀀스와 모드 전환을 모델링합니다. 모드를 하위 모드로 분해한 후, 각 운영 모드에 대해 하나 이상의 기능 시나리오를 설정하고, 관련된 행동 패턴을 인식하거나 사용합니다.

• 이러한 기능 시나리오를 통합하여 시스템의 행동 아키텍처 모델을 완성합니다.

• 구현을 향해 이전에 정의된 논리 요소를 필요한 만큼 분해합니다.

• 시간 제약(기간, 지속 시간, 빈도, 응답 시간, 타임아웃, 중지 조건 등)을 논리 요소에 할당하고 통합합니다.

• 시스템 운영을 모니터링하고 시간에 따른 처리 우선순위를 설정하기 위해 여러 실행 빈도 수준을 정의하고, 이러한 빈도 수준 간에 기능을 공유하여 시간 아키텍처 모델을 생성합니다.

• 기능 고장 모드 및 영향 분석을 수행하고 논리 아키텍처 요소를 업데이트합니다.

• 가능한 경우 시뮬레이터를 사용하여 모델을 실행하고, 예상된 특성을 얻기 위해 모델을 조정합니다.

• 선택된 독립 논리 아키텍처 모델 종합:

• 후보 논리 아키텍처 모델을 시스템 요구 사항과 관련된 평가 기준에 따라 평가하고, 시스템 분석 프로세스를 사용해 평가를 수행하고, 의사 결정 관리 프로세스를 통해 선택합니다. 선택된 논리 아키텍처 모델을 독립 논리 아키텍처 모델이라고 하며, 이는 가능한 한 구현 결정에서 독립적입니다.

• 설계 필요성에 따라 생성된 논리 아키텍처 모델 요소를 식별하고 정의하며, 해당 요구 사항을 적절한 시스템(현재 연구 중인 시스템 또는 외부 시스템)에 할당합니다.

• 선택된 논리 아키텍처 모델을 가능한 한 실행 가능한 모델로 검증 및 검증하고, 필요한 경우 수정하며, 시스템 요구 사항과 논리 아키텍처 모델 요소 간의 추적 가능성을 확립합니다.

• 논리 아키텍처 모델 개발 및 시스템 요구 사항 피드백:

• 물리적 아키텍처 모델 개발 프로세스 후에 이 활동을 수행합니다.

• 가능한 경우 논리 아키텍처를 시스템 및 시스템 요소에 할당하고, 필요한 경우 기능적, 행동적, 시간적 요소를 추가하여 기능과 처리를 동기화합니다.

• 선택된 논리 및 물리 아키텍처 모델에서 유도된 논리 및 물리 요소를 정의 또는 통합하고, 대응되는 요구 사항을 정의하여 적절한 논리 및 물리 아키텍처 요소에 할당합니다. 이러한 요구 사항을 영향을 받는 시스템의 요구 사항 베이스라인에 통합합니다.

 

2.3 산출물, 방법 및 모델링 기법

논리 아키텍처 설명에는 여러 유형의 모델을 활용하는 모델링 기법이 사용됩니다. 이러한 유형의 모델을 지원하기 위해 여러 방법들이 개발되었으며, 일부는 실행 가능한 모델입니다.

 

• 기능적 모델 – 여기에는 구조적 분석 설계 기법(SADT/IDEF0), 시스템 분석 및 실시간(SA-RT), 확장된 기능 흐름 블록 다이어그램(eFFBD), 기능 분석 시스템 기법(FAST) 등이 포함됩니다.

• 의미적 모델 – 여기에는 엔터티-관계 다이어그램, 클래스 다이어그램, 데이터 흐름 다이어그램 등이 포함됩니다.

• 동적 모델 – 여기에는 상태 전이 다이어그램, 상태 차트, eFFBD, 상태 기계 다이어그램(SysML), 활동 다이어그램(SysML)(OMG 2010), 페트리 넷(Petri nets) 등이 포함됩니다.

 

도메인 유형(예: 방위, 기업 등)에 따라 아키텍처 프레임워크는 아키텍처의 추가 측면/뷰를 나타내는 데 도움이 되는 설명을 제공합니다. ‘기업 시스템 엔지니어링 핵심 개념’의 ‘기업 아키텍처 프레임워크 및 방법론’ 섹션을 참조하십시오. 또한 ISO/IEC/IEEE 42010(ISO 2011) 관련 일반 템플릿을 사용하는 실용적인 방법도 참조할 수 있습니다.

 

 

3. 논리 아키텍처의 실질적 고려사항 (Logical Architecture: Practical Considerations)

앞서 설명한 바와 같이, 논리 아키텍처 모델의 목적은 시스템이 명시된 요구를 충족하기 위해 수행해야 할 작업을 설명하는 것입니다. 이는 모든 이해관계자의 요구와 우려를 해결할 수 있는 솔루션을 보장하고, 현재의 기술 기반 솔루션뿐만 아니라 혁신적인 솔루션도 고려할 수 있도록 돕습니다. 그러나 실제로는 문제 이해관계자가 자신의 요구를 강조하려 하거나, 솔루션 설계자 또는 아키텍트가 자신이 익숙한 솔루션을 제안하는 경향이 있습니다. 논리 아키텍처 모델이 선택한 생명 주기와 제대로 연계되지 않으면, 문제와 솔루션의 이해관계자들이 이를 무시하고 자신의 편견으로 돌아가는 것이 쉬워집니다(Part 5: 시스템 엔지니어링 지원 참조). 이러한 문제는 논리 아키텍처 모델이 자체 목적이 되거나, 주요 생명 주기 활동과 단절될 때 악화될 수 있습니다. 이는 추상적인 언어 또는 표기법을 사용하거나, 세부 사항의 수준이 과도하게 높거나, 시간이 오래 걸리거나, 생성된 최종 아키텍처가 처음 설계된 목적과 맞지 않을 때 발생할 수 있습니다. 아키텍처의 언어, 범위 및 적시성이 문제 이해관계자 또는 솔루션 제공자와 일치하지 않으면, 그들이 아키텍처를 무시하기 쉬워집니다. 이러한 논리 아키텍처 모델과 관련된 문제를 방지하는 데 도움이 되는 주요 함정과 모범 사례는 다음 두 섹션에서 설명됩니다.

 

3.1 주요 함정

1. 아키텍처 모델 입력과 문제 관련성

• 너무 깊은 분해: 논리 아키텍처 모델은 임무 분석에서 생성된 운영 시나리오와 관련이 있어야 합니다. 아키텍처 정의 활동을 위한 주요 입력은 시스템 요구사항 세트와 관련되며, 이 요구사항들이 적절한 수준의 아키텍처를 다루지 못하는 경우가 있습니다. 그 결과, 아키텍트는 요구사항을 무시하고 자신이 이해한 내용을 바탕으로 솔루션을 제시하게 됩니다. 초보자들이 흔히 저지르는 실수는 기능을 너무 깊게 분해하거나, 시나리오 또는 현재 시스템 블록의 기능 아키텍처 모델에 너무 많은 기능 및 입출력 흐름을 포함시키는 것입니다.

2. 함께 고려되지 않은 입력과 출력

• 함께 고려하지 않은 입력과 출력: 또 다른 흔한 실수는 지원하는 기능의 행동만 고려하고 그 기능을 분해하면서 입력과 출력을 무시하거나 너무 늦게 고려하는 것입니다. 입력과 출력은 기능의 필수적인 부분입니다.

3. 정적 기능 분해만 고려함

• 정적 기능 분해만 고려함: 정적 기능 분해는 가장 작은 기능 아키텍처 모델 작업이며 “이것은 어떻게 이루어지는가?“라는 기본 질문에 답합니다. 정적 분해의 목적은 기능 목록의 관리나 탐색을 용이하게 하는 것입니다. 정적 분해는 시나리오가 생성되고 논리 아키텍처가 거의 완료된 시점에만 수행되어야 합니다.

4. 거버넌스, 관리 및 운영 혼합

• 거버넌스, 관리 및 운영 혼합: 복잡한 시스템에서 거버넌스(전략적 모니터링), 관리(전술적 모니터링) 및 기본 운영이 종종 혼재됩니다. 논리 아키텍처 모델은 행동 아키텍처 모델뿐만 아니라 시간적 아키텍처 모델도 함께 다뤄야 합니다.

 

3.2 모범 사례

1. 기능 시나리오 구성

• 기능 분해 트리를 구성하기 전에 시스템의 행동을 모델링하고, 기능 시나리오를 설정하며, 하위 기능의 시나리오로 기능을 분해해야 합니다.

2. 분석 및 종합 사이클

• 많은 기능을 포함하는 시스템에 직면할 때는 기준을 사용하여 더 높은 추상화 수준으로 기능을 종합하려고 시도해야 합니다. 분석만 수행하지 말고, 소규모 분석(분해)과 종합 사이클을 반복해야 합니다. 시나리오를 사용하는 기술은 이러한 설계 실천을 포함합니다.

3. 기능적 및 행동적 관점의 교차 활용

• 기능(동사로 표현된 작업 예: “이동”)과 실행 상태/운영 모드(예: “이동 중”)는 유사하고 상호 보완적인 두 가지 관점입니다. 이를 활용하여 시스템의 행동적 관점을 고려하고 한 운영 모드에서 다른 모드로의 전환을 허용합니다.

4. 기능 시나리오 구성 순서

• 기능 시나리오를 생성할 때는 먼저 기능의 (제어) 흐름을 설정한 후, 입력과 출력 흐름을 추가하고, 마지막으로 동기화를 위한 트리거나 신호를 추가하는 것이 더 효율적입니다.