[Software Engineering] Functional Modeling 이해하기: Use Case와 Activity Diagram

 

 

 

요구사항을 정의했다고 끝이 아니다. 이제 그 요구사항을 토대로 시스템이 어떻게 동작할지를 시각화해야 한다. 이 단계에서 등장하는 것이 바로 Functional Modeling(기능 모델링)이며, 그 핵심 도구가 Use Case Diagram과 Activity Diagram이다.

 

 

Buisness Process and Use-case

우리는 고객이나 다른 직군에게서 모으고 분석하고 정의된 요구사항(Requirement)을 받게 된다. 근데 텍스트로만 되어 있으면 한계가 명확하기 때문에 시각적 표현을 만들어서 더 이해하기 쉽게 하는 과정이다.

 

여기서 중요한 개념이 바로 비즈니스 프로세스(Business Process)와 유스케이스(Use-case)이다. 둘이 비슷해 보이지만 스케일이 다르다.

1. Business Process(비즈니스 프로세스): 이건 회사가 돌아가는 전체적인 End-to-end workflow이다. 시스템 내부 활동뿐만 아니라, 시스템 밖의 사람의 수동 작업, 회사 정책, 외부 벤더(Vendors), 심지어 규제 절차 같은 것까지 다 포함하는 훨씬 넓은 범위이다. 
2. Use-case(유스케이스): 시스템이 사용자에게 제공하는 서비스나 상호작용(Interactions)만을 모델링하는 것이다. 즉, 시스템이 비즈니스 프로세스의 한 부분을 지원하기 위해 뭘 해야 하는지를 설명하는 것. 범위로 따지면 'Business Process > Use-case'로 표현할 수 있으며, 포함관계가 된다.

 

예를 들어, 온라인 예약 시스템의

• 비즈니스 프로세스에는 고객이 웹사이트에 접속 → 예약 → 결제 → 확인 메일 수신 같은 전체 흐름이 포함된다.
• 하지만 Use Case는 이 중 예약 관리 또는 결제 처리처럼 시스템이 직접 수행해야 할 기능 단위에 초점을 맞춘다.

 

 

 

우리가 요구사항을 기능 모델로 바꾸는 과정은, business process들을 외부 관점에서 파악하기 위해 use-case를 개발하고, 그 유스케이스들을 모델링하기 위해 activity diagram을 만드는 순서로 진행된다.

 

 

 

---

 

Use cases 역할과 정의

 

Use case는 만들려는 시스템이 사용자에게 제공하는 서비스와 상호작용을 모델링하는 도구이다.

 

Use case는 설계 활동의 primary driver이다. use cases가 정해져야, 이후의 모든 UML 다이어그램 기법을 계속 이어갈 수 있는 building blocks이 된다. (가장 high level로 다른 설계의 기반이 됨)

 

1. 비즈니스 프로세스의 개요 파악: Use case는 비즈니스 프로세스와 그 환경을 파악하는 데 쓰인다. 이는 비즈니스 프로세스에 대한 높은 수준의 개요(high-level overview)를 제공.
2. 외부 관점(External Perspective): 유스케이스는 사용자가 시스템을 어떻게 사용할지, 혹은 어떻게 바라볼지를 설명해 준다. 시스템 내부 구조는 아직 숨겨두고, 겉으로 드러나는 기능만 보는 것이다.
3. 기본 기능과 상호작용(interactions) 정의: 시스템의 기본 기능을 설명하는데, 이는 사용자가 무엇을 할 수 있는지와 시스템이 어떻게 응답하는지를 포함하며, 이 과정이 interactions이다.
4. 시나리오와 원칙: 유스케이스는 주어진 태스크에서 사용자와 시스템 간의 상호작용 단계(interaction steps)를 보여주는 전형적인 시나리오이다. 여기서 제일 중요한 원칙은, 한 use case는 (선택된 상세 수준에서) 오직 하나의 기능만을 설명해야 한다. (보고자 하는 level에서는 하나의 기능이고, 레벨이 내려가면 하나의 기능이 아닐 수 있다)

 

 

 

Type of Use cases

1. 목적 (The Purpose) 기반 분류

이 분류는 유스케이스를 작성하는 목표가 무엇인지에 따라 나뉜다.

• 개요 (Overview) 유스케이스
  
  • 특징: 요구사항에 대한 높은 수준의 개요(high-level overview)를 제공하는 데 초점을 둔다.
  • 용도: 프로젝트 초기에 시스템이 제공할 핵심 기능 목록을 빠르게 파악하고 이해관계자들과 공유할 때 유용.
• 상세 (Detail) 유스케이스
  • 특징: 유스케이스를 가능한 한 상세하게 문서화한다.
  • 용도: 액티비티 다이어그램에 있는 control flows나 activities을 기반으로 세부 단계를 구체적으로 적을 때 사용한다.

 

2. 정보의 양 (Amount of Information) 기반 분류

이 분류는 유스케이스에 구현 정보가 얼마나 포함되어 있는지, 즉 추상적인지 구체적인지에 따라 나뉘어.

• 필수 (Essential) 유스케이스
  
  • 특징: 필요한 기능을 이해하는 데 최소한으로 필수적인 이슈만 포함한다.
  • 용도: 구현과는 독립적인 수준에서, 시스템이 무엇을 해야 하는지에 집중해서 순수한 요구사항을 정의할 때 사용.
• 실제 (Real) 유스케이스
  • 특징: 구현을 위한 특정 단계를 포함한다.
  • 용도: 구체적인 기술 스택이나 인터페이스 디테일 등을 포함해서 설계 단계에 들어갈 수 있도록 상세하게 작성할 때 사용.

 

여기서 Overview - Real 유스케이스를 함께 사용하는 경우는 거의 없다. 높은 수준의 개요를 제공하려고 하는데, 실제 구체적인 스펙이나 디테일을 포함한다는게 모순이기 때문이다.

 

 

 

---

 

Use case diagrams

Use case diagrams은 시스템의 기능과 사용자 간의 상호작용을 시각적으로 모델링.

 

 

 

Use case diagrams의 요소

• Actors: 시스템과 상호작용하는 사용자나 외부 시스템. 사람 모양 아이콘으로 표시
• Use-case: 시스템이 제공하는 기능 하나하나. 타원으로 표시
• Associations: Actor와 Use-case의 상호작용을 나타내는 선. 실선으로 나타냄
• Subject boundary: 시스템의 범위를 나타냄. Use-case들을 둘러싸는 직사각형 상자

 

 

 

 

 

Use-case 간의 관계

복잡한 시스템에서는 Use-case들끼리도 관계를 맺는다. 이 관계들을 잘 모델링하면, 나중에 코드를 설계할 때도 재사용과 유연성을 높일 수 있다.

 

1. 일반화 (Generalizations): 클래스 다이어그램의 상속과 비슷하다. 하나의 일반화된 유스케이스가 여러 비슷한 유스케이스를 대표하고, 특수화된 유스케이스가 그 세부사항을 제공하는 방식이다.

 

 

2. 포함 (Inclusions): 여러 유스케이스 간의 공통점(을 표현하기 위해 사용된다. 반복되는 세부사항을 피하고 , 낮은 수준의 목표를 가진 하위 작업(lower-level task)을 나타낼 때 유용하다. A가 B를 include한다는 말은 A가 실행되면 B도 실행된다는 말과 같다.

 

 

3. 확장 (Extensions): 선택적인 상호작용이나 예외적인 경우(exceptional cases)를 처리할 때 사용한다. 이 관계를 사용하면 기본 유스케이스의 설명은 단순하게 유지할 수 있다.

 

 

 

세 관계의 차이를 간단히 정리하면,

• 일반화(Generalization): 상속처럼 공통 기능을 상위 Use Case로 묶음
• 포함(Inclusion): 반복되는 공통 절차를 다른 Use Case에서 재사용
• 확장(Extension): 예외적이거나 선택적인 흐름을 분리

 

 

다음은 Use-case의 예시이다. Use-case들의 관계도 표시가 된 것을 볼 수 있다.

 

 

 

---

 

 

Activity Diagrams

유스케이스 다이어그램이 '무엇(What)'을 할지 보여줬다면, 이제 액티비티 다이어그램은 '어떻게(How)' 그 일이 진행되는지, 즉 활동의 순서(sequence of activities)를 보여준다.

 

비즈니스 프로세스 모델링

Activity Diagram은 객체와 독립적으로 행동을 모델링하고 , 어떤 종류의 프로세스에도 사용될 수 있다. 객체 지향 관점에서는 프로세스 모델링을 강화해서 약화로 여겨질 수도 있지만 , 현재 요구사항에 대해 분석가와 사용자 간의 강력한 소통 수단이 된다.

 

Use-case diagrams과 Activity diagrams의 관계

Use-case diagrams의 수와 Activity diagrams의 복잡도는 반비례 관계이다. Activity diagrams은 하나의 Use-case에 대해서 그려지기 때문에 Activity diagrams의 복잡도가 증가하면 소수의 Use-case가 복잡해지는 것이고 반면에 Activity diagrams의 복잡도가 낮아지면 다수의 Use-case가 단순해지는 trade-off 구조이기 때문이다. 이 선택은 시스템에 따라서 다르게 된다.

 

 

Acitivity diagrams의 주요 요소

• 액션/활동 (Action or Activity): 특정 비즈니스 목적으로 수행되는 행동. '동사 + 명사'로 이름 지음 (예: Get Patient Information). 활동은 세분화 가능하지만 액션은 불가.
• Control flow: 실행 순서를 나타냄
• Object Flows: 객체의 흐름을 모델링함
• Object Nodes: 한 활동에서 다른 활동으로의 정보 흐름을 나타냄
• Control Nodes: 흐름을 제어하는 7가지 유형의 노드

 

Control Nodes: 흐름을 제어하는 7가지 노드

 

 

Acitivity diagrams의 예시

 

appointment system의 Use-case diagram을 보자. 보통 주요한 Use-case에 대해서 activity diagrams를 그린다. 여기서는 Manage Appointments에 대해서 그려보자.

 

 

 

 

---

 

 

Swimlanes: 책임 할당

액티비티 다이어그램에 Swimlanes을 추가하면, 누가 그 활동을 수행하는지 책임(responsibility)을 할당할 수 있다. 이는 객체 또는 개인 간의 역할 분리(separation of roles)를 나타내며, 수평 또는 수직으로 그릴 수 있다. 책임 분리를 통해 병렬적으로 처리가 가능하고 효율성이 증가한다.

 

 

 

 

결론: 두 다이어그램의 역할

1. 유스케이스 다이어그램: 시스템의 기능적 범위와 사용자 역할을 정의하는 것. (시스템의 무엇(What))
2. 액티비티 다이어그램: 그 기능들이 어떤 순서와 규칙으로 처리되는지 비즈니스 흐름을 명확히 하는 것. (프로세스의 어떻게(How))

 

 

 

 

 

 

 

출처: 경북대학교 손정주 교수님, “소프트웨어설계” 강의 자료