[소프트웨어공학] 동작 모델과 모델 주도 아키텍처

동작 모델

• 시스템이 실행될 때의 동적 행동에 대한 모델
  • 시스템이 환경 자극에 반응할 때, 무엇이 일어나는지 또는 일어나도록 의도했는지 보여줌
  • 자극의 종류
    • 데이터 : 시스템이 처리해야 하는 데이터가 도착
    • 이벤트 : 시스템 처리를 활성화하는 이벤트가 발생
      
      
• 시스템 동작 방식
  • 데이터 처리 시스템
    • 시스템에서 보낸 데이터를 처리(예 : 전화 과금 시스템)
      
      
  • 실시간 시스템
    • 이벤트가 시스템을 작동, 이벤트와 연관된 데이터가 있을 수 있음(필수 X)(예: 유선전화기)
      
      

 

 

 

데이터 주도 모델링

• 데이터 주도 모델
  • 입력 데이터 처리와, 입력 처리와 연관된 출력 생성과 관련된 일련의 행동
    (= 처음부터 끝까지 시스템의 처리 사항을 보여줌)
    • 요구사항 분석 중에 사용될 수 있음
      
      
  • 처음으로 사용된 그래픽 소프트웨어 모델
    
    
• 데이터 흐름 모델
  • 특정 프로세스와 관련된 데이터가 어떻게 시스템을 통해 이동하는지 보여줌
    • 분석가와 설계자가 프로세스에서 일어나는 일을 이해하는데 도움
      
      
  • 간단하고 직관적 → 다른 모델보다 이해당사자들이 접근하기 쉬움
    → 이해당사자들 모델 검증 참여 가능

 

 

 

 

데이터 주도 모델링 예시

• 인슐린 펌프 동작의 액티비티 모델

 

 

• 주문 처리

• UML 시퀀스 다이어그램으로도 시스템에서의 처리 순서를 나타낼 수 있음
  • 시퀀스 다이어그램은 시스템의 객체를 강조
  • 데이터 흐름도는 오퍼레이션이나 액티비티를 강조

 

 

 

 

이벤트 주도 모델링

• 시스템이 외부와 내부 이벤트에 대해 어떻게 반응하는지 보여줌
  • 가정 : 시스템이 유한한 수의 상태를 가지고 이벤트가 한 상태에서 다른 상태로 전이를 일으킨다
    • 예 ) 밸브 제어 시스템 - 밸브 닫힘/열림
      
      
• 실시간 시스템 설계 및 문서화할 때 사용
  
  
  
• UML은 이벤트 주도 모델링을 Statecharts에 기반을 둔 상태 다이어그램을 이용하여 지원
  • 시스템의 전이 이벤트를 보여줌
    • 각 상태에서 수행되는 연산에 대한 추가 정보를 포함 가능
    • 시스템에서의 데이터 흐름을 보여주진 않음

 

 

 

 

 

마이크로웨이브 오븐의 상태 다이어그램

 

 

 

 

상태기반 모델링

• 문제점 : 가질 수 있는 상태의 개수가 빠르게 증가
  • 큰 시스템 모델을 위해서는 모델에서 상세한 내용을 숨길 필요 있음
    
    
• 상위상태(Superstate) : 여러 개의 서로 다른 상태들을 포함하는 상태
  • 상위 수준 모델에서는 하나의 상태로 보임
  • 더 자세히 보여주기 위해선 별도의 다이어그램 상에 확장해야 함
    
    
• 동작 상태는 여러 개의 하위 상태(substate)들을 포함
• 자극과 시스템 상태에 대한 더 자세한 설명을 가지고 확장해야 한다.
  • 시스템의 상태 모델이 이벤트 처리의 개요를 제공하지만, 자세하지 않다.

 

 

 

 

마이크로웨이브 오븐의 동작

 

 

 

마이크로웨이브 오븐의 상태와 자극

 

 

 

 

모델 주도 공학

• 프로그램보다 모델이 개발 프로세스의 주요 출력물인 소프트웨어 개발 접근법
  • HW/SW 플랫폼에서 실행되는 프로그램은 모델로부터 자동 생성됨
  • 모델 주도 아키텍처의 아이디어로부터 개발됨
    
    
• 모델 주도 아키텍처(MDA : model-driven architecture)
  • 소프트웨어 개발의 설계와 구현 단계에 초점
  • 큰 회사들이 개발 프로세스를 지원하기 위하여 채택한 SW공학 접근법
    
    
• 모델 주도 공학(MDE : model-driven engineering)
  • 소프트웨어 공학 프로세스의 모든 면과 연관
    • 모델 주도 요구공학, 모델 주도 개발 소프트웨어 프로세스, 모델 주도 테스팅
      (모델 주도 아키텍처는 포함 X)

 

 

 

 

모델 주도 공학의 장단점

• 장점
  • 시스템을 보다 더 상위 단계의 추상화 관점을 다룰 수 있음
  • 새로운 시스템 적용에 드는 비용이 저렴 ← 코드가 자동 생성돼서
    
    
• 단점
  • 구현을 위해서 반드시 적합하진 않음 ← 모델은 추상화를 위한 것이기 때문
  • 새로운 플랫폼용 변환기 개발 비용이 더 비쌀 수 있다.

 

 

 

 

 

모델 주도 아키텍처

모델 주도 아키텍처

• 시스템 기술에 UML 모델의 일부를 사용하는 소프트웨어 설계와 구현에 대한 모델 중심 접근법
• 서로 다른 추상화 수준에 있는 모델 생성
  • 원칙적으로, 상위 수준의 플랫폼 독립 모델로부터 사람의 개입 없이 동작하는 프로그램 생성 가능
    
    
• 세 가지 유형의 추상 시스템 모델을 생성할 것을 권장
  • 계산 독립 모델(CIM)
    • 시스템에서 사용되는 중요한 도메인 추상화를 모델링(도메인 모델로도 불림)
      
      
  • 플랫폼 독립 모델(PIM)
    • 구현을 참조하지 않고 시스템의 동작을 모델링
    • UML의 정적 시스템 구조와 외부와 내부 이벤트에 대한 반응을 보여주는 모델을 이용하여 기술
      
      
  • 플랫폼 특화 모델(PSM)
    • 각 응용 플랫폼별로 플랫폼 독립 모델을 변환한 것
    • 각 계층에서 플랫폼에 특화된 세부사항을 추가하는 PSM 계층들이 존재할 수도 있음

 

 

 

 

 

추상 시스템 모델 예시

 

 

 

 

모델 기반 공학

• 구현의 상세함에 신경 쓰지 않고 시스템에 대해 추상화의 상위 수준에서 생각하게 해 줌
  • 오류 가능성 낮아짐, 설계 및 구현 프로세스 속도 증가
  • 재사용 가능하고 플랫폼 독립적인 응용 모델 생성 가능
    
    
• 시스템을 새로운 플랫폼 기술에 적용시키기 위해 모델 번역기를 만듦
  • 모든 플랫폼 독립적인 모델은 새로운 플랫폼에 빠르게 다시 호스팅 가능
    
    
• MDA(모델 주도 공학)의 근간
  • 모델들 간의 변환이 정의되고 소프트웨어 도구에 의해서 자동으로 적용될 수 있다는 개념

MDA 변환

• 실행 소프트웨어는 상위 수준 시스템 모델로부터 생성
  • 실제로 모델에서 코드로의 완전한 자동 번역은 불가능
    
    
• 서로 다른 CIM(계산 독립 모델)에서 사용되는 개념들을 연결해야 함 → 어려운 문제
  → CIM의 개념을 이해하는 사람만 대응 가능
  
  
• PIM(플랫폼 독립 모델)에서 PSM(플랫폼 특화 모델)으로의 번역은 간단한 기술적 문제
  • PIM으로부터 공통 플랫폼으로부터의 번역기를 사용 가능(상업적 도구 및 오픈소스)
    • 플랫폼 특화 규칙들과 PIM을 PSM으로 바꾸는 패턴들의 대규모 라이브러리 사용
      
      
• 소프트웨어 시스템이 다른 플랫폼에서 실행되는 것으로 의도된 경우
  • 단일한 PIM만 유지하면 됨, 각 플랫폼을 위한 PSM은 자동으로 생성됨

 

 

 

 

다중 플랫폼 특화 모델

 

 

 

MDA 도입의 어려움

• MDA는 도구들을 부분적으로 지원
  • PIM을 PSM으로 번역하는 부분적인 지원만 제공
  • 시스템을 위한 실행 환경은 표준 실행 플랫폼 이상의 것
    • 다른 응용 프로그램, 응용 라이브러리, 외부 서비스, 사용자 인터페이스 라이브러리 포함
      
      
• 지역 환경에서 가용한 설비를 활용할 수 있도록 특별한 목적의 번역기가 생성되어야 할 수 도 있음
  → 회사들이 모델 주도 접근법 채용을 꺼리는 이유
  
  • 회사들은 자체적 도구 개발 및 유지를 원치 않음
    
    
• 특별한 도구가 없다면 MDA는 추가의 수작업 코딩이 필요
  • MDA 접근법의 경제성을 감소하시키게 됨

 

 

 

 

MDA가 SW 개발의 주류 접근법이 되지 못한 이유

• 모델은 소프트웨어 설계에 대한 토론에 좋은 방법
  → 구현에 맞는 추상화인 것은 아님
  
  
• 대부분의 복잡한 시스템들은 구현이 주요 문제가 아님
  • 요구공학, 보안성, 확실성, 기존 시스템과의 통합, 테스팅이 더 중요
  • MDA를 사용함으로써 얻는 이득이 제한됨
    
    
• MDA의 도입과 도구사용 비용이 비용절약을 초과할 가능성이 큼
  • 크고 수명이 긴 시스템에 대해서만 플랫폼 독립성에 대한 주장이 유효
    
    
• MDA가 대두되던 시기에 애자일 기법이 채택
  → 모델 주도 접근법에 대한 관심 하락

 

 

 

기타 MDA와 관련된 사항들

• MDA의 성공 사례들
  • 주로 시스템 제품을 개발하는 회사들
    • 긴 수명을 가진 하드웨어 기술 변화를 반영하도록 수정되어야 할 수 있음
    • 응용 도메인 이해도가 높고 CIM으로 정형화될 수 있음
      
      
  • 재사용을 촉진할 때 유용하고 주요 생산성 향상
    
    
• 애자일 기법과는 안 맞음
  • 애자일 선언에는 ‘자동화된 코드 생성은 실용적이지 않다’
    → MDA의 선행 모델링은 애자일 선언과 모순
    
    
    • Motorola - 자동화된 코드 생성과 함께 애자일 기법 사용