5. UML(1) - 유스케이스 다이어그램

2025. 3. 25. 19:15
반응형

소프트웨어 개발에서 팀 프로젝트를 진행할 때는 먼저 시스템 도메인을 정의하고, 이를 기반으로 시나리오를 작성한다. 이 시나리오를 바탕으로 유스케이스(Use Case) 를 도출하며, 이후 클래스 설계(Class Design), 상호 작용 다이어그램(Interaction Diagram), 배포 다이어그램(Deployment Diagram) 등의 다양한 설계 산출물로 발전한다.

 

다이어그램(Diagram)이란 쉽게 말해 시스템을 시각적으로 표현한 그림이다. 이러한 다이어그램을 활용하면 시스템의 구조와 동작 방식을 직관적으로 이해하고, 효과적으로 문제를 해결할 수 있다.

 

특히, 유스케이스 도출 단계는 프로젝트의 방향과 결과에 결정적인 영향을 미치는 핵심 과정이다.

 

이번 글에서는 UML 유스케이스 다이어그램에 대해 심도 있게 살펴보고, 이를 바탕으로 보다 명확하고 체계적인 시스템 설계 방법을 제시하고자 한다.

1. 액터

유스케이스 다이어그램을 이해하려면 먼저 액터(Actor) 의 개념을 알아야 한다. 액터는 시스템과 상호작용하는 외부 요소를 의미하며, 시스템을 사용하는 사람 또는 다른 시스템을 포함할 수 있다. 그림은 다음과 같이 표현할 수 있다.

 

사용자 액터는 이렇게 표시된다. 추가적으로 이러한 액터틑 사람만을 의미하는 것이 아닌 시스템도 가능하다. 그 이유는 사용자가 시스템이 될수도 있기 때문이다. 이들은 다음 처럼 표현할 수 있다.

  • 사용자 액터(User Actor): 시스템을 직접 사용하는 사람 (예: 고객, 관리자)
  • 시스템 액터(System Actor): 시스템과 데이터를 주고받는 외부 시스템 (예: 결제 시스템, 데이터베이스)
  • 주요 액터(Primary Actor): 시스템의 주요 기능을 수행하는 핵심 사용자
  • 보조 액터(Secondary Actor): 직접적인 사용자는 아니지만 시스템 운영에 영향을 미치는 대상
  • 프록시 액터(Proxy Actor): 특정 사용자의 역할을 대신 수행하는 시스템 또는 서비스

이러한 액터의 이름은 구체적으로 만드는 것이 좋으며 추상적으로 만들지 않는 것이 특징이다. 

 

이처럼 그냥 직원이여도 교직원이 있을수도 있고 행정직원이 있을 수도 있다. 이를 구체적으로 작성하는 것이 중요하다.

 

2. 유스케이스

 

액터를 알아봤으니 중심적인 개념인 유스케이스에 대해서 알아보겠다.

 

유스케이스(Use Case)란 시스템이 제공하는 기능이나 서비스의 사용 사례를 표현하는 것을 의미한다. 쉽게 말해, 사용자가 시스템을 어떻게 활용하는지를 정리한 것이라고 볼 수 있다. UML 다이어그램에서는 타원(○) 형태로 표기된다.

 

 

유스케이스는 후보 유스케이스 도출, 핵심 유스케이스 선정, 유스케이스 다이어그램 작성 순으로 만들어지는데 가장 첫번째 단계는 윗처럼 후보를 도출하게 된다.

 

그 결과, 위와 같이 표현할 수 있다. 그러나 왼쪽처럼 모든 항목을 하나로 통합해서 작성하면 안 되며, 반드시 오른쪽과 같은 방식으로 작성해야 한다. 그 이유는 첫 번째 방식으로 작성하면 복잡해질 가능성이 있기 때문이다

 

이름 같은 경우에는 이와 같이 만들어야한다. 

 

가장 핵심은 구체적인 방법으로 적어야한다는 점이다. 또한 동사형 명사로 만들어 적는 것이 더욱 더 좋다.

 

3. 관계

앞서 액터(Actor)와 유스케이스(Use Case)에 대해 알아보았다. 이제 이 둘을 개별적으로 표현하는 것이 아니라, 유스케이스 다이어그램에서 어떻게 연결되고 활용되는지 살펴보겠다.

 

이를 통해 액터와 유스케이스 간의 관계를 효과적으로 표현하는 방법을 이해할 수 있다.

 

3.1. 엑터 -> 유스케이스 관계

 

위와 같이 쓰여진다. 시스템 액터도 유스케이스 제어의 주체가 될 수 있다는 점도 잊지 않아야 한다. 

 

3.2. 유스케이스 -> 엑터 관계

 

유스케이스가 액터에세 알려줄 때는 이와 같이 그릴 수 있다. 

 

3.3. 유스케이스 -> 시스템 액터 관계

 

이와 같은 경우에는 이렇게 사용하면 된다.

 

3.4. 액터의 일반화 관계

 

일반화와 특수화의 관계는 이런 관계이므로 다음과 같이 표현하면 된다.

 

 

여기서 화살표의 끝이 빈 원으로 표시된 경우, 이는 상속 관계를 나타낸다는 의미이다.

 

3.5. 액터 간의 연관 관계

 

둘이 이러한 연관관계가 있다면 위처럼 그릴 수 있다.

 

3.6. 포함 관계

 

포함 관계는 위와 같이 표현된다. 여기서 <<>>는 stereotype을 나타내며, 실선이 아닌 점선은 의존 관계를 의미한다. include는 포함된 관계를 뜻한다. 이 관계는 매우 중요하며, 잘 설계된 시스템에서는 포함 관계가 명확히 정의되어 있는 경우가 많다.

 

* 포함 관계와 선행 단계

 

추가적으로 윗처럼 포함 단계와 선행 단계와 햇갈리는 경우가 있다. 이를 생각하면서 관계를 그려줘야 한다.

 

3.7. 확장 관계

 

추가적으로 어떤 것에서 더욱 확장해서 만든다고 할 때는 위처럼 표현하면 된다.

 

 

하지만 이처럼 드물게 발생하는 경우는 확장 관계로 정의할 필요가 없다.

 

유스케이스 다이어그램을 그렸다면 다음은 클래스 다이어그램을 그려야한다. 이에 대한 추가적인 내용은 다음 포스터에서 다루도록 하겠다.

 

출처: 쉽게 배우는 소프트웨어 공학

 

쉽게 배우는 소프트웨어 공학 - 예스24

소설처럼 술술 익히는 소프트웨어 공학중요하지만 다소 뜬구름 잡는 얘기 같았던 소프트웨어 공학 이론을 핵심만 추려 명쾌하게 정리해준다. 일상에서 흔히 접할 수 있는 예시를 통해 소프트웨

www.yes24.com

 

반응형

BELATED ARTICLES

more