System modelingPermalink

소프트웨어 시스템을 설계하고 구축하는 과정에서 우리는 그 시스템을 다양한 관점에서 이해하고 설명할 필요가 있다. 단순히 코드나 기능의 나열만으로는 전체 시스템의 구조와 동작을 포괄적으로 파악하기 어렵기 때문이다. 이때 중요한 도구가 바로 시스템 모델링(System Modeling)이다.

시스템 모델링은 시스템의 특정 측면을 추상화하여 표현하는 일련의 과정이다. 하나의 모델은 시스템 전체를 모두 나타내지는 않지만, 특정 관점—예를 들어 시스템과 외부 환경 간의 관계, 구성 요소 간의 연결 구조, 사용자의 상호작용 방식, 또는 시간에 따른 동작의 변화—을 명확히 보여준다. 이러한 모델을 통해 개발자는 복잡한 시스템을 보다 효과적으로 분석하고, 고객과의 소통 과정에서도 보다 직관적인 설명이 가능하다.

오늘날 시스템 모델링은 대부분 UML(Unified Modeling Language)을 기반으로 한 그래픽 방식으로 수행된다. UML은 객체지향 소프트웨어의 구조와 동작을 시각적으로 표현할 수 있는 통일된 표기법으로, 다양한 유형의 다이어그램을 통해 시스템을 여러 관점에서 모델링할 수 있게 해준다. UML의 등장은 시스템 모델링의 접근 방식을 통일시키고, 이해관계자 간 커뮤니케이션의 품질을 향상시키는 데 큰 기여를 했다.

결국 시스템 모델링은 코드 작성을 위한 사전 작업이자, 복잡한 요구사항을 정리하고 구체화하는 데 핵심적인 수단이라 할 수 있다. 또한 설계자가 시스템을 보다 높은 수준에서 바라보고, 문제 해결을 위한 창의적인 구조와 동작 방식을 탐색할 수 있도록 돕는다.

시스템 모델의 목적과 활용Permalink

시스템 모델은 소프트웨어 개발 생명주기의 여러 단계에서 다양하게 활용된다. 예를 들어, 기존 시스템의 모델은 요구사항 공학 단계에서 현재 시스템이 어떻게 작동하는지를 명확히 이해하는 데 도움이 된다. 이를 통해 어떤 점이 잘 작동하고 어떤 점이 개선되어야 하는지를 파악할 수 있으며, 이는 결국 새로운 시스템의 요구사항을 정의하는 데 기초 자료가 된다.

반면, 새로 개발될 시스템의 모델은 제안된 요구사항을 이해관계자에게 설명하는 데 사용된다. 이 과정에서 엔지니어들은 설계안을 토론하고, 이를 문서화함으로써 실제 구현 단계에서 참고할 수 있는 설계 기반을 마련하게 된다. 특히 모델 기반 개발(Model-Driven Engineering, MDE) 접근법에서는 시스템 모델이 단순한 문서가 아니라, 실제 코드의 일부 또는 전체를 자동으로 생성해내는 중심 수단이 되기도 한다.

시스템 모델링의 네 가지 관점Permalink

효과적인 시스템 모델링을 위해서는 시스템을 하나의 시각에서만 바라보는 것이 아니라, 다양한 관점(perspective)에서 바라보는 것이 중요하다. 일반적으로는 다음과 같은 네 가지 주요 관점을 중심으로 모델이 작성된다.

첫 번째는 외부 관점(External Perspective)이다. 이 관점에서는 시스템이 어떤 환경에 속해 있는지, 그리고 어떤 외부 시스템들과 상호작용하는지를 모델링한다. 즉, 시스템이 조직 내외에서 어떤 역할을 하며, 다른 시스템들과 어떤 관계를 맺는지를 나타내는 것이다.

두 번째는 상호작용 관점(Interaction Perspective)이다. 이 관점에서는 시스템과 외부 사용자 혹은 내부 구성 요소 간에 어떤 상호작용이 이루어지는지를 다룬다. 사용자의 입력에 따라 어떤 기능이 수행되는지, 혹은 컴포넌트 간 메시지 전달은 어떻게 이루어지는지를 모델링한다.

세 번째는 구조적 관점(Structural Perspective)으로, 시스템이 어떤 구성 요소로 이루어져 있으며, 이들 사이에 어떤 정적인 관계가 존재하는지를 보여준다. 예를 들어 클래스 간의 연관성, 계층 구조, 집합 관계 등을 설명할 수 있다.

마지막은 행위 관점(Behavioral Perspective)이다. 이 관점은 시스템이 시간의 흐름이나 외부 사건에 따라 어떻게 변화하고 반응하는지를 설명한다. 상태 전이, 이벤트 처리, 데이터 흐름 등이 포함된다.

이러한 다양한 관점을 통해 우리는 시스템을 보다 입체적으로 이해할 수 있으며, 이를 바탕으로 더 정교한 설계와 구현이 가능해진다.

UML 다이어그램의 유형Permalink

앞서 언급한 관점들을 효과적으로 표현하기 위해, UML은 여러 유형의 다이어그램을 제공한다. 각 다이어그램은 특정 관점에서의 시스템 특징을 시각화하는 데 특화되어 있다.

• 활동 다이어그램(Activity Diagram)은 프로세스의 흐름이나 데이터 처리 단계를 보여주며, 전체 비즈니스 로직이나 작업 흐름을 시각화할 수 있다.

• 유스케이스 다이어그램(Use Case Diagram)은 시스템과 외부 사용자(또는 다른 시스템) 간의 상호작용을 보여주는 데 사용된다.

• 시퀀스 다이어그램(Sequence Diagram)은 특정 유스케이스 내에서 객체 간의 메시지 교환 순서를 시각적으로 표현한다.

• 클래스 다이어그램(Class Diagram)은 시스템의 클래스 구조와 클래스 간의 연관 관계, 상속 등을 설명한다.

• 상태 다이어그램(State Diagram)은 시스템이 특정 이벤트에 따라 어떤 상태로 전이되는지를 나타내며, 실시간 시스템에서 자주 사용된다.

이러한 UML 다이어그램들은 각각의 목적에 따라 선택적으로 사용되며, 개발자뿐 아니라 고객, 기획자 등 다양한 이해관계자들과의 소통을 원활하게 만들어준다.

그래픽 모델의 활용 방식Permalink

그래픽 모델은 단순히 보기 좋은 시각 자료를 넘어, 실제 개발 과정의 다양한 목적에 활용된다. 크게 세 가지 방식으로 정리할 수 있다.

첫째, 의사소통 도구로서의 모델이다. 초기 단계에서는 모델이 다소 부정확하거나 불완전하더라도, 개발자와 고객 간의 논의를 이끌어가는 데 중요한 역할을 한다.

둘째, 기존 시스템의 문서화 수단으로 모델을 사용하는 방식이다. 이 경우에는 모델이 시스템을 실제와 가깝게 반영해야 하지만, 모든 세부 사항을 포함할 필요는 없다.

셋째, 시스템 구현을 위한 상세 명세로서의 모델이다. 이 단계에서는 모델이 정확하고 완전해야 하며, 경우에 따라서는 모델 자체가 코드로 자동 변환될 수 있도록 구성되기도 한다.

Context models - 시스템의 운영 환경을 이해하는 방법Permalink

시스템을 설계하고 개발할 때, 그 시스템이 단독으로 존재하지 않는다는 사실을 잊어서는 안 된다. 대부분의 소프트웨어 시스템은 다양한 외부 시스템, 사용자, 조직 구조 안에서 함께 작동하며, 이와 같은 맥락을 고려하지 않고서는 시스템의 정확한 요구사항조차 정의하기 어렵다. 이러한 외부 환경과의 관계를 시각적으로 표현하는 모델이 바로 컨텍스트 모델(Context Model)이다.

컨텍스트 모델은 시스템이 작동하는 운영 환경을 이해하고 설명하기 위한 도구이다. 이는 시스템의 경계(boundary)를 명확히 하고, 외부 요소들과의 상호작용을 도식화함으로써, 시스템이 어떤 맥락 속에서 작동하는지를 파악하게 해준다. 예를 들어, 어떤 시스템이 고객 데이터베이스, 결제 게이트웨이, 정부 API 등과 연결되어 있다면, 컨텍스트 모델은 이러한 외부 시스템들과의 연결관계를 중심으로 시스템의 위치를 시각적으로 표현한다.

시스템 경계 설정의 중요성Permalink

컨텍스트 모델을 작성하면서 가장 먼저 고려해야 할 것은 시스템 경계(system boundary)를 어디에 둘 것인가 하는 결정이다. 시스템 경계는 시스템 내부와 외부를 구분하는 기준선이며, 이 기준에 따라 어떤 기능이 시스템에 포함되어야 하고, 어떤 기능은 외부 시스템에 위임될지를 결정하게 된다.

하지만 이 경계 설정은 단순한 기술적 판단만으로 이루어지지 않는다. 조직 내부의 정치적 고려사항이나 이해관계자들의 요구사항에 따라 경계가 확장되거나 축소될 수 있다. 예를 들어, 어떤 부서는 특정 기능을 시스템에 포함시켜 자신들의 업무를 자동화하려 하고, 다른 부서는 해당 기능을 자신들이 계속 직접 관리하고 싶어할 수도 있다. 따라서 시스템 경계의 설정은 정치적 판단(political judgment)의 요소를 가지며, 개발자와 분석가는 이러한 요소를 충분히 고려해야 한다.

시스템 경계가 한 번 결정되면, 그것은 요구사항 정의 전체에 중대한 영향을 미친다. 시스템이 외부 시스템에 의존하는 정도, 외부 시스템과의 통신 방식, 그리고 보안, 인증, 데이터 흐름까지 모든 요소가 경계에 따라 달라지기 때문이다.

The context of the Mentcare systemPermalink

이러한 컨텍스트 모델의 실제 예로, 멘트케어(Mentcare) 시스템을 들 수 있다. 이는 정신 건강 관리 시스템으로, 다양한 외부 시스템과 상호작용하면서 환자 정보를 관리하고 치료 과정을 지원한다. 멘트케어 시스템의 컨텍스트 모델은 이 시스템이 환자 기록 시스템, 병원 관리 시스템, 외부 진료 기관 등과 어떻게 연결되어 있는지를 보여준다. 이를 통해 시스템이 단순히 내부 데이터만 처리하는 것이 아니라, 광범위한 환경 속에서 상호작용하며 운영된다는 점을 이해할 수 있다.

이러한 컨텍스트 모델은 시스템 설계의 초기 단계에서 필수적으로 고려되어야 하며, 시스템이 조직 전체와 어떻게 조화를 이루는지를 시각적으로 보여주는 매우 중요한 역할을 한다.

프로세스 관점에서의 확장Permalink

컨텍스트 모델은 외부 시스템과의 연결 상태를 중심으로 설명하기 때문에, 시스템이 어떻게 사용되는지에 대한 정보를 직접적으로 제공하지는 않는다. 예를 들어, 어떤 사용자가 어떤 순서로 시스템을 통해 업무를 수행하는지, 또는 시스템이 업무 프로세스 내에서 어떤 위치에 놓이는지는 별도로 다루어야 한다.

이를 보완하기 위한 것이 바로 프로세스 모델(Process Model)이다. 프로세스 모델은 시스템이 전체 비즈니스 프로세스 안에서 어떤 방식으로 활용되는지를 표현한다. 이러한 모델은 특히 시스템이 기존 업무 흐름에 어떤 영향을 주는지를 설명할 때 유용하다.

프로세스 모델은 UML의 활동 다이어그램(Activity Diagram)을 활용하여 작성할 수 있으며, 이를 통해 다양한 업무 절차나 사용자의 작업 흐름을 시각적으로 표현할 수 있다. 예를 들어, “강제 입원 프로세스(Involuntary Detention Process)”를 모델링할 때, 환자의 상태 평가, 보호자 및 기관의 동의, 법적 승인 등의 절차를 흐름도 형식으로 표현할 수 있다. 이처럼 프로세스 모델은 시스템의 실제 사용 흐름을 명확히 함으로써, 요구사항 분석과 기능 정의에 큰 도움을 준다.

이 활동 다이어그램은 시스템이 비즈니스 프로세스 내에서 어떤 역할을 수행하는지를 시각화한 것이다. 특히, Mentcare 시스템이 어떤 시점에서 활용되는지, 인간 주체와 어떤 절차를 분담하는지를 알 수 있다. 현실 세계의 법적・의료적 의사결정 흐름을 반영하고 있기 때문에, 시스템 요구사항 분석에 중요한 기초가 된다.

Interaction models - 시스템 간의 소통을 이해하는 방식Permalink

복잡한 시스템을 설계할 때 단순히 내부 구조만을 고려하는 것은 불충분하다. 실제 시스템은 다양한 사용자, 다른 시스템, 내부 구성 요소들과 끊임없이 상호작용(interaction)하며 작동한다. 이러한 상호작용을 시각적으로 표현하고 분석하는 것이 바로 상호작용 모델(Interaction Model)의 목적이다.

상호작용 모델은 다음과 같은 세 가지 주요 목적에서 활용된다.

1. 사용자와의 상호작용 파악

가장 먼저 고려해야 할 상호작용은 사용자와 시스템 간의 상호작용이다. 사용자는 시스템의 주요 기능을 트리거하는 존재이며, 이러한 사용자의 행위는 요구사항 분석에 매우 중요한 단서를 제공한다. 예를 들어, 사용자가 로그인하고, 데이터를 검색하고, 결과를 다운로드하는 일련의 행위는 단순한 클릭의 연속이 아니라 시스템이 제공해야 할 기능의 흐름을 의미한다.

이러한 사용자 중심의 상호작용을 모델링하면, 개발자는 사용자의 업무 흐름이나 행동 패턴을 보다 명확히 파악할 수 있으며, 이는 곧 사용자 친화적인 시스템 설계로 이어진다.

1. 시스템 간 상호작용 분석

현대의 많은 소프트웨어는 독립적으로 존재하지 않는다. 여러 시스템이 서로 연결되어 데이터를 교환하거나, 기능을 위임받아 처리하는 방식으로 구성되어 있다. 예를 들어, 병원 시스템은 진료 기록을 건강보험청 시스템과 공유하고, 의약품 데이터베이스와 실시간으로 연동되며, 외부 진료기관과 정보를 주고받는다.

이러한 시스템 간 통신은 때때로 데이터 포맷의 불일치, 요청 지연, 인증 실패 등 복잡한 문제를 유발하기도 한다. 상호작용 모델을 통해 시스템 간의 데이터 흐름과 상호 작용 경로를 명확히 하면, 이러한 통신 문제를 사전에 식별하고 해결할 수 있다.

1. 내부 구성 요소 간 상호작용 구조 설계

시스템 내부에서의 상호작용도 중요한 분석 대상이다. 하나의 큰 시스템은 여러 개의 모듈 또는 컴포넌트(component)로 구성되어 있으며, 이들은 서로 데이터를 주고받거나, 특정 작업을 위임하기도 한다.

이때 각 구성 요소가 정의된 인터페이스를 통해 명확하게 의사소통하고, 시스템의 성능과 안정성에 영향을 주지 않도록 설계되어야 한다. 컴포넌트 간 상호작용 모델은 이런 구조를 명확하게 파악하고 설계의 적절성을 검토하는 데 도움을 준다.

상호작용 모델링을 위한 대표 도구 : Usecase & Sequence DiagramPermalink

상호작용을 모델링하기 위해 자주 사용되는 두 가지 UML 도구가 있다. 바로 유스케이스 다이어그램(Use Case Diagram)과 시퀀스 다이어그램(Sequence Diagram)이다.

• 유스케이스 다이어그램은 사용자가 시스템과 어떻게 상호작용하는지를 보여준다. 시스템 외부에 존재하는 ‘액터(Actor)’와 시스템 내부의 유스케이스 간의 관계를 시각적으로 나타낸다. 이 다이어그램은 요구사항 분석 단계에서 매우 유용하며, 시스템이 제공해야 하는 주요 기능들을 식별하는 데 쓰인다.

Tabular description of the ‘Transfer data’ use-case

Use cases in the Mentcare system involving the role ‘Medical Receptionist’

• 시퀀스 다이어그램은 유스케이스보다 더 구체적이다. 특정 유스케이스가 실행될 때, 시스템 내부와 외부 객체 간에 어떤 메시지가 어떤 순서로 오가는지를 시간 축에 따라 시각적으로 표현한다. 이 다이어그램은 특히 시스템 설계나 테스트 단계에서 시나리오 기반 분석에 많이 사용된다.

Sequence diagram for View patient information

상호작용 모델이 갖는 실질적 가치Permalink

상호작용 모델은 단지 시스템 작동 방식을 보여주는 시각 자료에 그치지 않는다. 이를 통해 요구사항 누락을 줄이고, 통신 오류를 예방하며, 모듈 간 결합도를 분석할 수 있다. 더 나아가 사용자 경험(UX)을 개선하고, 시스템의 성능이나 보안 요구사항까지 점검할 수 있는 중요한 단서를 제공한다.

또한 이해관계자와의 의사소통 측면에서도 매우 효과적이다. 다이어그램은 누구나 이해하기 쉬운 시각 언어이므로, 비전문가인 고객이나 관리자도 시스템의 동작 방식을 빠르게 파악할 수 있게 된다.

Structural models - 시스템의 뼈대를 그리다.Permalink

시스템이 어떻게 동작하는지를 이해하는 것도 중요하지만, 그보다 먼저 시스템이 무엇으로 구성되어 있는지, 즉 정적인 구조(static structure)를 명확히 파악하는 일은 필수적이다. 마치 건물을 짓기 전에 기둥, 벽, 설비 등의 구조를 먼저 설계하듯이, 소프트웨어도 기능을 수행하기 이전에 어떤 구성 요소들이 어떻게 연결되어 있는지를 정의해야 한다. 이러한 구조를 시각화한 것이 바로 구조적 모델(Structural Model)이다.

구조적 모델은 소프트웨어 시스템을 이루는 구성 요소(component)들—예를 들어 클래스, 객체, 모듈 등—을 식별하고, 이들 사이의 관계(association)를 표현하는 데 중점을 둔다. 시스템이 작동하기 전, 설계 초기 단계에서 만들어지는 이 모델은 시스템의 전반적인 형태를 잡는 설계도의 역할을 한다.

정적 모델과 동적 모델의 구분Permalink

구조적 모델은 정적 모델(static model)과 동적 모델(dynamic model)로 나눌 수 있다. 정적 모델은 시스템이 실행되기 전의 설계 상태를 나타낸다. 클래스 다이어그램, 컴포넌트 다이어그램 등이 대표적이다. 반면 동적 모델은 실행 시점에서의 객체 생성, 관계 변화 등을 포함한다. 구조적 모델에서는 일반적으로 정적 모델이 주로 사용된다.

시스템 설계를 위한 클래스 다이어그램Permalink

가장 널리 사용되는 구조적 모델이 바로 UML 클래스 다이어그램(Class Diagram)이다. 이 다이어그램은 시스템 내의 객체 유형(Object Class)과 이들 간의 관계를 시각적으로 표현한다.

(UML classes and association)

각 클래스(Class)는 시스템 내에서 하나의 개념적 단위를 나타내며, 그 안에는 속성(attribute)과 연산(operation)이 포함된다. 예를 들어, 병원 관리 시스템에서 Patient, Doctor, Appointment와 같은 클래스가 있을 수 있다. 이들은 현실 세계의 개체를 추상화한 것으로, 실제 객체 인스턴스는 런타임에서 생성된다.

클래스 간에는 다양한 관계가 존재할 수 있으며, 이를 통해 시스템 구조의 복잡성을 관리할 수 있다.

• 연관(Association): 두 클래스 간에 의미 있는 연결이 있을 때 사용된다. 예를 들어, Doctor는 여러 명의 Patient와 연관될 수 있다.
• 일대다 관계(1:N), 다대다 관계(M:N), 역방향 연관 등도 명시할 수 있다.

실생활 예시: MHC-PMS 시스템Permalink

정신건강 환자 관리 시스템(MHC-PMS)의 클래스 다이어그램을 예로 들어보면, Patient, Consultation, Medication, Therapist 등의 클래스가 존재한다. Patient는 여러 번의 Consultation을 가질 수 있고, 각 상담에는 특정 Therapist가 지정되며, 필요시 Medication도 처방된다. 이런 관계들이 시각적으로 표현되면, 데이터 흐름과 책임 분배 구조를 한눈에 파악할 수 있다.

(Classes and associations in the MHC-PMS)

(The Consultation class)

일반화(Generalization) 관계Permalink

소프트웨어 설계에서는 유사한 클래스들을 상위 개념으로 묶는 일반화(generalization)가 자주 사용된다. 이는 복잡성을 줄이고 코드 재사용을 가능하게 한다.

예를 들어, Doctor와 Nurse 클래스는 모두 MedicalStaff라는 상위 클래스로 일반화될 수 있다. 이들은 공통적으로 employeeID, department, schedule() 등의 속성과 메서드를 가질 수 있으며, 각 하위 클래스에서는 이를 기반으로 특수화된 기능을 추가한다.

프로그래밍 언어에서는 이러한 일반화를 상속(inheritance)을 통해 구현한다. Java나 C++ 같은 객체지향 언어에서는 상위 클래스의 속성과 연산을 하위 클래스가 자동으로 상속받으며, 추가적인 연산은 개별 클래스에서 확장할 수 있다.

집합 관계(Aggregation)와 구성 관계(Composition)Permalink

구조적 모델링에서 자주 사용되는 또 다른 관계는 집합 관계(aggregation)와 구성 관계(composition)이다. 이들은 “부분-전체” 관계를 표현하는 방식이다.

• Aggregation은 구성 요소가 독립적으로 존재할 수 있는 관계다. 예를 들어, Department는 여러 Employee를 가질 수 있지만, Employee는 Department와 분리되어도 존재할 수 있다.

• Composition은 보다 강한 결합 관계로, 전체가 없어지면 부분도 함께 소멸된다. 예를 들어, Order가 삭제되면 그 안에 포함된 OrderItem들도 함께 삭제된다.

이러한 관계 모델은 시스템의 데이터 구조를 명확히 정의하고, 객체 간 의존성을 조율하는 데 중요한 역할을 한다.

하나의 환자 기록이 환자와 여러 상담을 포함한다.(Aggregation)

Study pack이 다양한 학습 구성 자료들로 구성(Aggregation). 즉, Study pack과 구성 요소들 간의 관계는 모두 Aggregation (◇) 으로 연결되어 있다. 이건 객체 간에 “부분-전체” 관계가 존재하지만, 각 부분이 독립적으로 존재 가능하다는 의미이다.

구조적 모델의 의의Permalink

구조적 모델은 시스템의 기반 구조를 설계하는 데 결정적인 기여를 한다. 기능 중심으로만 시스템을 설계하면 통합과 유지보수가 어려워질 수 있지만, 클래스 중심의 구조 설계를 기반으로 하면 기능의 확장, 테스트, 재사용이 훨씬 용이해진다.

또한 구조적 모델은 기술적 구현 이전 단계에서 설계의 품질을 검토하고, 모듈화 수준과 책임 분산 구조를 평가할 수 있는 기반 자료를 제공한다.