시스템 모델링(System Modeling)과 관점에 따른 모델 종류

시스템 모델링 (System Modeling)

시스템 모델링은 시스템의 추상적인 모델을 개발하는 과정으로, 각 모델은 시스템의 다양한 관점이나 시각을 제시합니다. 이는 분석가들이 시스템의 기능을 이해하고, 고객과 효과적으로 소통하는 데 도움을 주며, 주로 통합 모델링 언어(UML, Unified Modeling Language)의 표기법을 기반으로 합니다.

---

시스템 관점 (System Perspectives)

시스템 모델링은 여러 가지 관점(View)을 통해 시스템을 다각도로 분석하고 설계합니다. 주요 관점은 다음과 같습니다:

1. 외부 관점 (External Perspective) - 블랙박스(밖에서 본다)
   • 정의: 시스템의 맥락이나 환경을 모델링합니다.
   • 목적: 시스템 외부에 있는 요소들과 시스템 간의 상호작용을 이해하고 표현합니다.
   • 예시: Mentcare 시스템의 외부 환경 모델링.
2. 상호 작용 관점 (Interaction Perspective) - 블랙박스(밖에서 본다)
   • 정의: 시스템과 그 환경 간의 상호 작용 또는 시스템 구성 요소 간의 상호 작용을 모델링합니다.
   • 목적: 시스템이 외부와 어떻게 상호 작용하며, 내부 구성 요소들이 어떻게 협력하는지 이해합니다.
3. 구조적 관점 (Structural Perspective) - Static이 주가 됨
   • 정의: 시스템의 조직 구조나 시스템이 처리하는 데이터의 구조를 모델링합니다.
   • 목적: 시스템의 구성 요소와 데이터 구조를 명확히 이해하고 설계합니다.
4. 행동적 관점 (Behavioral Perspective)
   • 정의: 시스템의 동적 동작과 이벤트에 대한 응답을 모델링합니다.
   • 목적: 시스템이 이벤트에 어떻게 반응하고, 동적으로 어떻게 동작하는지 이해합니다.

---

소프트웨어 모델링 목적

상호작용에 대한 공통적인 이해
좋은 기능과 품질을 가진 소프트웨어 시스템을 개발하기 위함

---

아키텍쳐 개념 모델

---

아키텍쳐 4+1 view

 

유스케이스 뷰

4+1 View 모델에서 유스케이스(View)뷰는 다른 4개의 뷰를 통합하고 검증하기 위한 중심적인 역할을 하는 뷰입니다. 소프트웨어 시스템의 기능적 요구사항을 사용자 또는 외부 시스템 관점에서 설명하며, 시스템이 사용자와 상호작용하는 방식을 나타냅니다.
다이어그램에는 Activity Diagram, Information Flow Diagram, Use Case Diagram 등이 있습니다.

---

 
Conceptual View와 Physical View는 시스템 설계와 구현에서 다른 관점을 제시하는 두 가지 중요한 개념입니다. 이 둘은 시스템을 다른 수준에서 바라보며, 각각의 목적에 따라 다르게 표현됩니다.

Conceptual View (개념적 뷰)

• 설명: 개념적 뷰는 시스템의 고수준 설계를 나타냅니다. 주로 개념, 객체, 기능적 요소에 초점을 맞추어 시스템이 무엇을 해야 하는지를 설명합니다.

---

1. 로지컬 뷰 (Logical View)

• 설명: 로지컬 뷰는 시스템의 기능적 요구사항(FR)을 중심으로 시스템의 구조를 설명합니다. 이는 시스템의 주요 기능이 어떻게 객체, 클래스, 모듈 등으로 구성되어 있고, 이들 간의 관계가 어떤지에 초점을 맞춥니다.
• 목적: 소프트웨어 설계에서 기능적 측면을 강조하며, 시스템이 요구하는 기능이 어떻게 구현되는지를 보여줍니다.
• 대상: 소프트웨어 개발자나 설계자가 주로 참고하는 뷰입니다.
• 다이어그램 : Conceptual model class Diagram, implementation Diagram, Sequence Diagram을 통해 객체 지향적 구조를 설명합니다.
• 중점사항: 데이터 흐름과 객체 간 상호작용이 어떻게 이루어지는지에 초점을 맞추며, 기능적 분해를 통해 시스템의 복잡성을 다룹니다.

2. 프로세스 뷰 (Process View)

• 설명: 프로세스 뷰는 시스템의 비기능적 요구사항(NFR, QR), 특히 성능, 동시성, 스레드 관리와 같은 운영적 특성에 중점을 둡니다. 프로세스들이 어떻게 실행되고, 상호작용하며, 병렬 처리가 어떻게 이루어지는지를 설명합니다.
• 목적: 시스템의 동적 동작과 성능 요구사항을 이해하고, 동시성 문제를 해결하며, 처리량, 반응성, 데드락 등의 문제를 다룹니다.
• 대상: 주로 시스템 아키텍트나 퍼포먼스 엔지니어가 참고합니다.
• 구성요소: 프로세스 다이어그램, 스레드 모델, 상태 다이어그램 등이 사용됩니다.
• 중점사항: 병렬 처리, 프로세스 간 통신, 스케줄링 등이 중심이 되며, 시스템의 실행 시 동작을 설명합니다.

공통된 다이어그램(Logical & Process) view : Communiacation(collaboration) Diagram, Sequence Diagram, model class Diagram, state Machine Diagram

---

Physical View (물리적 뷰)

• 설명: 물리적 뷰는 시스템의 실제 구현을 다룹니다. 시스템이 어떻게 배포되고, 어떤 하드웨어와 네트워크 구조에서 동작하는지를 설명합니다.

---

1. Deployment View

• 설명: Deployment 뷰는 시스템의 물리적 인프라와 배포 방법을 설명합니다. 이 뷰는 소프트웨어가 실제로 어떤 하드웨어에 배치되고, 네트워크 구성이 어떻게 이루어지는지를 다룹니다. 즉, 소프트웨어 컴포넌트가 물리적 노드(서버, 클라이언트 등)에 어떻게 배포되는지를 설명합니다.
• 목적: 시스템이 어떻게 물리적으로 구성되고, 배포되어야 하는지에 대해 명확하게 이해하는 것이 목표입니다. 주로 성능, 확장성, 신뢰성과 관련된 설계를 지원합니다.
• 대상: 시스템 운영자, 인프라 엔지니어, 그리고 시스템 아키텍트가 참고하는 뷰입니다.
• 구성요소: 노드(Node) 다이어그램, 네트워크 다이어그램 등을 통해 물리적 배포를 표현합니다.
• 중점사항:
  • 서버, 네트워크, 데이터베이스 등의 물리적 자원과 소프트웨어 컴포넌트의 배포.
  • 시스템의 가용성, 성능, 부하 분산 및 장애 대응에 대한 설계.
  • 클라이언트-서버 관계, 데이터 센터 구성, 또는 클라우드 인프라 설계.

2. Implementation View (Development View)

• 설명: Implementation 뷰는 소프트웨어 시스템의 모듈화 및 코드 구조에 대한 설명을 다룹니다. 소프트웨어가 개발되는 동안 코드베이스가 어떻게 구성되고, 버전 관리나 빌드 프로세스가 어떻게 이루어지는지에 중점을 둡니다.
• 목적: 시스템의 모듈화 및 코드 조직을 효과적으로 관리하여 개발 과정에서의 효율성을 높이는 것이 목표입니다. 또한, 유지보수와 확장성을 용이하게 만들기 위해 코드가 어떻게 구성되어 있는지를 설명합니다.
• 대상: 주로 소프트웨어 개발자, 구현 담당자들이 참고하는 뷰입니다.
• 구성요소: Component Diagram, Package Diagram 등을 통해 모듈 간의 의존성을 설명하고, 코드베이스의 계층 구조를 표현합니다.
• 중점사항:
  • 코드 모듈의 구조, 패키지, 라이브러리 등과 같은 소프트웨어 아티팩트의 배치.
  • 각 모듈이 어떻게 상호 작용하고 의존하는지, 그리고 어떻게 관리되는지 설명.
  • 버전 관리, 빌드 자동화, 지속적 통합(CI) 같은 개발 과정의 기술적 관리.

주요 차이점

• Deployment 뷰는 소프트웨어가 실제 하드웨어에 배포되는 방법과 운영 인프라에 중점을 두며, 물리적 시스템의 구성을 다룹니다. 반면, Implementation 뷰는 소프트웨어의 모듈화된 코드 구조와 개발 과정을 다루고, 소프트웨어가 개발되는 동안 코드베이스가 어떻게 조직되고 관리되는지에 집중합니다.
• 대상자: 디플로이먼트 뷰는 시스템 운영자와 인프라 엔지니어에게, 임플리멘테이션 뷰는 소프트웨어 개발자나 개발 팀에게 더 유용합니다.

---

그래픽 모델의 사용 - UML (Use of Graphical Models - UML)

UML(Unified Modeling Language)은 시스템 모델링을 위한 표준화된 그래픽 언어로, 다양한 다이어그램을 통해 시스템의 다양한 측면을 시각적으로 표현합니다. 주요 UML 분석 다이어그램은 다음과 같습니다:

1. 유스케이스 다이어그램 (Use Case Diagram)
   • 정의: 시스템과 그 환경 간의 상호 작용을 보여줍니다.
   • 용도: 시스템이 제공하는 기능과 그 기능을 사용하는 외부 액터(사용자, 다른 시스템 등)를 시각적으로 표현합니다.
2. 시퀀스 다이어그램 (Sequence Diagram)
   • 정의: 특정 유스케이스 동안 발생하는 객체 간의 상호 작용 순서를 보여줍니다.
   • 용도: 시스템 내 객체들 간의 메시지 교환과 시간 흐름을 시각적으로 표현합니다.
3. 클래스 다이어그램 (Class Diagram)
   • 정의: 시스템 내 객체 클래스와 클래스 간의 관계를 보여줍니다.
   • 용도: 객체 지향 시스템에서 클래스의 구조와 상호 관계를 시각적으로 표현합니다.
4. 상태 다이어그램 (State Diagram)
   • 정의: 시스템이 내부 및 외부 이벤트에 어떻게 반응하는지를 보여줍니다.
   • 용도: 객체나 시스템의 상태 변화와 그 상태 변화에 따른 행동을 시각적으로 표현합니다.
5. 액티비티 다이어그램 (Activity Diagram)
   • 정의: 프로세스나 데이터 처리 과정에서의 활동을 보여줍니다.
   • 용도: 비즈니스 프로세스나 데이터 흐름을 시각적으로 표현합니다.

---

외부 모델 (External Models)

외부 모델은 시스템의 외부 환경과의 관계를 모델링하여, 시스템이 어떻게 환경과 상호 작용하는지를 이해하는 데 도움을 줍니다.

---

컨텍스트 모델 (Context Models)

• 정의: 시스템의 운영 맥락(경계)을 나타내는 모델입니다.
• 특징:
  • 외부 관점: 시스템 경계 밖에 있는 요소들을 모델링합니다.
  • 목적: 시스템이 속한 환경과 시스템 간의 관계를 시각적으로 표현합니다.
• 예시: Mentcare 시스템의 컨텍스트 모델.

---

프로세스 모델 (Process Models)

• 정의: 시스템이 비즈니스 프로세스에서 어떻게 사용되는지를 보여주는 모델입니다.
• 특징:
  • 비즈니스 환경에서 시스템과 다른 시스템들이 어떻게 사용되는지 보여줍니다.
  • UML 액티비티 다이어그램 등을 사용하여 비즈니스 프로세스를 정의할 수 있습니다.
• 예시: 강제구금 시스템의 프로세스 모델.

가로 작대기는 and를 의미하고 세로 작대기는 if를 의미합니다.

---

상호 작용 모델 (Interaction Models)

상호 작용 모델은 시스템 내외부의 다양한 상호 작용을 모델링하여, 사용자 요구사항을 식별하고 시스템 간의 통신 문제를 해결하는 데 도움을 줍니다.

high, low level까지 그릴 수 있는 모델입니다

---

유스케이스 모델링 (Use Case Modeling)

use case = requirements OOAD에서 반드시 적용합니다

• 정의: 시스템과 외부 액터 간의 상호 작용을 나타내는 모델입니다.
• 특징:
  • 유스케이스는 시스템과 외부 액터 간의 특정 작업이나 기능을 나타냅니다.
  • 액터는 사람이나 다른 시스템일 수 있습니다.
  • 유스케이스 다이어그램은 모든 유스케이스를 개관적으로 보여줍니다.
• 예시: Mentcare 시스템의 "데이터 전송(Transfer Data)" 유스케이스.

그림에서 표는 text기반 brainstroming입니다.

---

시퀀스 다이어그램 (Sequence Diagrams)

high level Design 입니다

• 정의: 특정 유스케이스 동안 발생하는 객체 간의 상호 작용 순서를 보여줍니다.
• 특징:
  • 객체와 액터는 다이어그램의 상단에 나열됩니다.
  • 메시지 교환은 화살표로 표시되며, 시간 순서대로 배치됩니다.
• 예시: Mentcare 시스템의 "환자 정보 보기(View Patient Information)" 유스케이스.

alt부분이 if문이고, head에 적힌 것에 따라서 high와 low를 구분할 수 있습니다.

---

구조적 모델 (Structural Models)

구조적 모델은 시스템의 조직과 구성 요소 간의 관계를 모델링하여, 시스템의 구조를 이해하고 설계하는 데 도움을 줍니다.

정적, 동적 측면 보여주는데 유용합니다.

---

클래스 다이어그램 (Class Diagrams)

• 정의: 시스템 내 클래스와 클래스 간의 연관 관계를 보여주는 모델입니다.
• 특징:
  • 클래스는 시스템 객체의 일반적인 정의입니다.
  • 연관 관계는 클래스 간의 관계를 나타냅니다.
  • 사용 목적: 객체 지향 시스템의 구조를 시각적으로 표현하여, 클래스와 객체 간의 관계를 이해하고 설계합니다.

비즈니스 모델 vs 개념적 모델 vs 구현 모델

• 비즈니스 모델은 비즈니스 전략과 프로세스에 중점을 두고, 비즈니스 운영 방식과 가치를 설명합니다. 관계들로 이어진 비즈니스 모델을 안의 Attribute으로 넣으면 개념적 모델이 됩니다.
• 개념적 모델은 시스템의 핵심 개념과 그 관계를 설명하며, 비즈니스 요구 사항을 분석하고 사용자 관점에서 시스템을 설명하는 데 사용됩니다.
• 구현 모델 은 시스템의 구체적인 설계와 코드 구조를 나타내며, 개발자를 위한 구체적인 구현 지침을 제공합니다.

---

유스케이스에서 Contract, Implementation Model까지

 
유스케이스를 통해 System Interation Diagram(SID)를 만들면 SID안에 있는 Operation들을 뽑아서 인터페이스인 System Operations를 만듭니다.
각 Operation당 Responsibility랑 Post-Condition(인스턴스 추가 삭제, 속성 변경, Association 생성 해제)을 이용해서 Contracts를 만듭니다.
Contract에 명시된 설명이랑 Conceptual Model을 이용해서 Implementaion Model을 Design할 수 있다.

---

일반화와 집계 (Generalization and Aggregation in Class Diagram)

• 일반화 (Generalization):
  • 상위 클래스(슈퍼클래스)와 하위 클래스(서브클래스) 간의 상속 관계를 나타냅니다.
  • 예시: "동물(Animal)" 클래스가 "포유류(Mammal)"와 "조류(Bird)" 클래스의 슈퍼클래스일 수 있습니다.
• 집계 (Aggregation):
  • 클래스 간의 부분-전체 관계를 나타냅니다.
  • 예시: "자동차(Car)" 클래스가 "엔진(Engine)" 클래스의 집계일 수 있습니다.

---

행동적 모델 (Behavioral Models)

행동적 모델은 시스템의 동적 동작과 이벤트에 대한 반응을 모델링하여, 시스템이 어떻게 작동하고 반응하는지를 이해하는 데 도움을 줍니다.

system들이 섞여 있을때, 실행할때 반응을 보여줍니다

---

데이터 기반 모델 (Data-Driven Models)

• 정의: 데이터 처리에 의해 주도되는 시스템을 모델링합니다.
• 특징:
  • 데이터 입력에 의해 시스템의 동작이 제어됩니다.
  • 주요 활동: 데이터 처리, 입력 데이터의 시퀀스, 출력 생성.
  • 사용 도구: 데이터 흐름도(DFD), UML 액티비티 다이어그램.
• 예시: 비즈니스 시스템에서 데이터 입력에 따라 다양한 처리를 수행하는 시스템.

---

이벤트 기반 모델 (Event-Driven Models)

reactive control : 시스템이 외부에서 발생하는 이벤트나 상태변화에 즉각적으로 반응하도록 설계되는 제어 방식

up에서 UML로 state model을 사용합니다.

high, low level 전부 가능합니다.

• 정의: 외부 및 내부 이벤트에 의해 주도되는 시스템을 모델링합니다.
• 특징:
  • 이벤트는 시스템의 상태를 변화시키는 자극입니다.
  • 시스템 상태와 이벤트에 따른 상태 전환을 모델링합니다.
  • 사용 도구: 유한 상태 기계(FSM).
• 예시: 실시간 시스템에서 이벤트 발생 시 시스템의 상태가 변화하는 경우.

각각 박스의 윗부분(Waiting)은 state이고, 아래(do)는 action입니다.

화살표는 event이고 빨간색 사각형에 Automata가 있을수 있습니다.

상태 기계 모델 (State Machine Models)

state에 따라 반응이 다르므로 reactive system으로 볼 수 있습니다

• 정의: 시스템이 이벤트에 반응하여 상태를 어떻게 변화시키는지를 모델링합니다.
• 특징:
  • 시스템 상태: 노드로 표현됩니다.
  • 이벤트와 전환: 상태 간 이동을 트리거하는 이벤트는 화살표로 표시됩니다.

• 목적: 시스템의 동적 행동을 명확히 이해하고 설계하는 데 도움을 줍니다.
• 예시: 은행 ATM의 상태 기계 모델, 주문 처리 시스템의 상태 전환.

---

시스템 모델링의 요약

시스템 모델링은 다양한 UML 다이어그램과 모델을 통해 시스템의 여러 측면을 시각적으로 표현함으로써, 분석가들이 시스템의 기능과 구조를 이해하고, 고객과 효과적으로 소통할 수 있도록 돕습니다. 다음은 각 모델의 주요 역할과 목적입니다:

• 외부 모델: 시스템의 경계와 외부 환경과의 관계를 정의.
• 프로세스 모델: 비즈니스 프로세스에서 시스템의 사용 방식을 설명.
• 상호 작용 모델: 시스템 내외부의 상호 작용을 상세히 설명.
• 구조적 모델: 시스템의 구성 요소와 그들 간의 관계를 정의.
• 행동적 모델: 시스템의 동적 동작과 이벤트에 대한 반응을 설명.

이러한 모델들은 소프트웨어 개발 생명 주기 전반에 걸쳐 반복적으로 사용되며, 각 단계에서 발생하는 요구사항과 설계 결정을 시각적으로 표현하여 개발의 효율성과 품질을 높이는 데 기여합니다.

---

다음 포스트에는 Model-Driven Engineering에 대해서 알아보겠습니다!