[소프트웨어 공학] System modeling(2)

Behavioral Models(행위 모델)

Behavioral models는 시스템이 실행 중일 때 나타나는 동적(dynamic) 동작을 표현한다. 이러한 모델은 시스템이 외부로부터 자극(stimulus)을 받았을 때, 무슨 일이 일어나는지, 또는 어떻게 반응하는지를 시각적으로 보여준다.

Behavioral modeling은 특히 실시간 시스템(real-time systems)이나 사용자와의 인터랙션이 중요한 시스템에서 매우 중요하다. 왜냐하면, 시스템이 단지 어떤 구조를 가지는지만이 아니라, ‘어떻게 반응할 것인가’, 즉 행동의 흐름이 요구사항 만족 여부를 결정하기 때문이다.

자극(Stimulus)의 유형

시스템의 동작을 유발하는 자극은 두 가지 유형으로 구분된다.

1. 데이터 기반 자극(Data-driven stimulus)
   • 새로운 데이터가 시스템에 입력되었을 때 이를 처리해야 하는 경우
   • 예: 사용자가 웹 양식에 정보를 입력하면, 시스템이 이를 검증하고 저장하는 흐름
2. 이벤트 기반 자극(Event-driven stimulus)
   • 외부 혹은 내부 이벤트가 발생했을 때 시스템이 이를 감지하고 반응하는 경우
   • 예: 센서가 임계치를 초과했을 때 경고 알림을 보내거나 장치를 차단하는 동작

모델의 활용

Behavioral models는 시스템이 특정 상태에 있을 때, 어떤 자극이 주어지면 상태가 어떻게 변화하는지를 시각적으로 표현한다.

대표적으로 두 가지 모델링 접근이 있다:

1. Data-driven modeling(데이터 중심 모델링)
   • 이 방식은 데이터의 흐름에 따라 시스템의 동작을 표현한다.
   • 많은 비즈니스 시스템에서 사용되며, 사용자가 입력한 데이터가 어떤 단계들을 거쳐 처리되고 출력으로 이어지는지를 활동(activity)의 흐름으로 표현한다.
   • UML Activity Diagram이 대표적 도구이다.
   • 예: 인슐린 펌프의 동작 모델 -> 각 단계별로 센서 데이터 수집, 계산, 투여 등이 순차적으로 이루어진다.

   

   • Order Processing

   

2. Event-driven modeling (이벤트 중심 모델링)
   • 이벤트 발생을 중심으로 시스템의 상태 변화를 모델링한다.
   • 시스템은 유한한 상태 집합을 가지며, 이벤트가 발생하면 특정 상태에서 다른 상태로 전이(transition)한다.
   • 이러한 모델은 State Machine Diagram(상태 기계 다이어그램)으로 표현된다.
   • 특히 실시간 시스템이나 디바이스 제어에 적합하다.
   • 예: 전자레인지 오븐 -> 문 열림, 시간 설정, 시작 버튼, 조리 완료 등 다양한 이벤트에 따라 “대기->설정->작동->완료”등의 상태로 변화한다.

   

   

상태 기계 모델(State Machine Models)

• 상태(State)는 시스템이 어떤 상황에 처해 있는지를 나타낸다.
• 이벤트(Event)는 상태의 변화의 트리거가 된다.
• UML의 StateChart는 상태와 전이의 관계를 시각적으로 나타내는 대표적인 도구이다.

Model-Driven Engineering(모델 기반 개발)

Model-Driven Engineering (MDE)은 소프트웨어 개발을 모델 중심으로 수행하는 접근 방식이다. 전통적인 개발 방식에서는 프로그래머가 코드와 아키텍처를 수동으로 작성하지만, MDE에서는 모델이 개발의 핵심 산출물이 되며, 프로그램 코드는 이 모델들로부터 자동 생성된다.

MDE는 개발자가 세부적인 프로그래밍 언어나 플랫폼의 구현 방식에 의존하지 않고, 보다 높은 수준의 추상화에서 시스템을 설계할 수 있게 해준다.

“모델이 곧 코드다.” : 개발자는 UML 등으로 정의된 정형화된 모델을 만들고, 모델 변환 도구를 통해 프로그램 코드로 자동 변환한다. 즉, 모델->중간 표현->실행 가능한 코드로 이어지는 구조이다. 이 접근은 단순히 문서를 잘 만드는 수준을 넘어서, 모델로부터 코드가 생성될 수 있어야 한다는 점이 핵심이다.

⚙️ MDE의 전제: 모델 계층 구조

MDA는 시스템을 다음과 같은 3가지 모델 계층으로 구성하여 표현한다. 이 계층들은 점진적인 추상화 수준 차이를 통해 구분된다.

1. Computation Independent Model (CIM)

CIM은 시스템이 다루는 도메인 개념을 모델링하며, 시스템 구현에 대한 세부 정보는 포함하지 않는다. 이 모델은 종종 도메인 모델(domain model)이라고도 불리며, 비즈니스 전문가가 시스템의 목적과 사용 시나리오를 이해하고 표현하는 데 활용된다.

1. Platform Independent Model (PIM)

PIM은 시스템의 동작을 특정 구현 플랫폼과 독립적으로 정의한 모델이다. UML 클래스 다이어그램, 상태 다이어그램, 활동 다이어그램 등을 통해 시스템 구조와 이벤트 반응 방식을 기술한다. 이 모델은 이후 플랫폼에 맞게 변환되기 위한 중간 단계 역할을 한다.

1. Platform Specific Model (PSM) PSM은 PIM을 기반으로 특정 플랫폼에 맞게 변환한 모델이다. 예를 들어, Java 플랫폼을 위한 PSM, .NET을 위한 PSM 등 각 플랫폼마다 별도의 모델이 생성된다. 복잡한 시스템에서는 여러 층의 PSM이 존재할 수 있으며, 각 단계에서 플랫폼 특화된 세부사항이 점진적으로 추가된다.

• MDA transformations

• Multiple platform-specific models

모델 변환과 자동화

MDA의 중요한 메커니즘은 모델 간 변환이다. 즉, CIM → PIM → PSM → 코드의 흐름을 자동화된 도구를 통해 수행함으로써, 개발자는 구현 세부사항에서 자유로워지고 설계와 구조에 집중할 수 있다. 이런 자동화된 변환이 성공적으로 이뤄질 경우, MDA는 소프트웨어 생산성과 품질을 동시에 향상시킬 수 있다.

또한, 하나의 PIM에서 여러 플랫폼에 맞는 PSM들을 생성할 수 있기 때문에, 다양한 운영환경이나 디바이스에서 동일한 시스템을 재사용하기 쉬워진다.

Agile 방법론과의 관계

MDA는 반복적인 개발 방식을 지원한다고 주장하지만, 그 철학은 Agile 소프트웨어 개발의 기본 이념과 충돌할 수 있다. Agile은 ‘작동하는 소프트웨어’를 가장 중요한 산출물로 간주하며, 광범위한 사전 모델링보다는 빠른 피드백과 점진적 개선을 강조한다.

이에 비해 MDA는 상당한 사전 모델링 작업을 요구하기 때문에, 대부분의 Agile 개발자들은 이 방식에 익숙하거나 편안함을 느끼지 않는다. 그러나 만약 모델 변환이 충분히 자동화되어 코딩 없이도 프로그램이 생성될 수 있다면, MDA는 Agile 개발 안에서도 유용하게 통합될 수 있을 것이다.

MDA의 도입 한계

실제로는 MDA의 도입이 여러 가지 이유로 제한되고 있다.

1. 전문화된 도구의 필요

MDA는 각 모델 계층 간 변환을 위해 전문적인 모델링 도구를 필요로 한다. 그러나 이들 도구는 사용법이 복잡하거나, 기업 환경에 맞게 커스터마이징을 요구하는 경우가 많다.

1. 도구의 한정된 가용성

사용 가능한 도구가 제한적이며, 상용 도구의 경우 고가이거나 폐쇄적인 구조를 가지고 있어, 기업 내부에서 직접 도구를 개발하거나 유지보수해야 할 수 있다.

1. 장수 시스템에 대한 우려

장기적인 시스템에서는, 도구를 만든 회사가 없어질 경우 유지보수가 어려워지기 때문에, 기업 입장에서는 도입을 꺼리는 경우가 많다.

1. 모델과 구현 간의 간극 모델은 설계 토론에 유용하지만, 현실의 구현에서는 그 수준의 추상화가 적절한 세부사항을 반영하지 못할 수도 있음.

2. 복잡한 시스템의 본질적인 과제 MDA는 구현 자동화에 초점을 두지만, 실제로는 요구사항 분석, 보안 및 신뢰성 확보, 레거시 시스템 통합, 테스트 등이 훨씬 더 중요한 문제인 경우가 많다.

3. 시장 흐름의 변화 MDA가 발전하던 시기, 시장에서는 Agile이 널리 채택되기 시작했고, 이로 인해 모델 기반 접근법은 주류에서 멀어졌다.

Model-Driven Architecture(MDA)는 소프트웨어를 모델 기반으로 설계하고 자동화된 방식으로 구현하는 방법론이다. 추상화 수준에 따른 모델 계층(CIM, PIM, PSM)을 통해 플랫폼 독립성과 재사용성을 제공하며, 이론적으로는 코드 작성 없는 개발을 가능하게 한다. 그러나 높은 도구 의존도, Agile과의 불협화음, 현실적 도입 비용 등의 문제로 인해 실제 산업 현장에서의 채택은 제한적인 편이다.

Key Points

• 모델은 시스템의 세부사항을 생략한 추상적 표현이며, 시스템의 맥락, 상호작용, 구조, 행위 등을 각기 다른 관점에서 보여줄 수 있다.
• Context models는 시스템이 어떤 환경과 다른 시스템 및 프로세스와 연결되어 있는지를 보여준다.
• Use case diagrams와 sequence diagrams는 사용자가 시스템과 어떻게 상호작용하는지를 설명한다.
  • Use case는 외부 행위자와의 상호작용을 보여주고,
  • Sequence diagram은 시스템 내부 객체 간의 상호작용 순서를 구체적으로 표현한다.
• Structural models는 시스템의 조직과 아키텍처를 표현하며, Class diagram은 클래스의 정적 구조와 연관 관계를 정의하는 데 사용된다.
• Behavioral models는 시스템이 실행 중일 때의 동적 동작을 표현하며, 데이터 처리나 이벤트에 대한 반응을 모델링한다.
• Activity diagram은 데이터 처리 흐름을, State diagram은 내부 또는 외부 이벤트에 대한 시스템의 상태 변화를 모델링하는 데 사용된다.
• Model-driven engineering (MDE)은 시스템을 모델 집합으로 표현하고, 이를 기반으로 자동으로 실행 가능한 코드로 변환하는 소프트웨어 개발 방식이다.