티스토리 뷰




[프로그래밍 방법론] 객체 지향 프로그래밍 - 

유스케이스 다이어그램(Use Case Diagram)




이 글에서는 유스케이스(혹은 유즈케이스, Use Case Diagram)에 대해서 알아보도록 하겠습니다.

유스케이스의 정의는 UML 스펙에 잘 정의되어 있지만, 실질적으로 유즈케이스를 작성하는 방법은 정해진 기준이 없습니다.


1. 유스케이스란?


유스케이스는 시스템의 기능적인 요구사항을 정리하기 위한 방법입니다. 이는 시스템을 개발하기에 앞서 청사진을 그리는데 많은 도움을 줄 수 있습니다. 그리고 시스템의 요구사항을 명확히 파악할 수 있는 방법이기도 합니다. 외부 Actor가 시스템에 대한 기능을 정리한 것으로써, 이를 기반으로 개발자는 사용자가 원하는 동작에 대한 정의를 할 수가 있습니다. 


유스케이스의 실질적인 목적은 위의 내용을 바탕으로 실질적은 시스템의 기능을 정의하는 것입니다. 

이를 통해서 시스템의 사용자, 설계자, 개발자들의 원활한 의사소통을 할 수 있게 해주게 됩니다. 


작성 방법 중 가장 선호되는 방법은 많은 모델링 툴에서 확인할 수 있는 Actor 기반의 다이어그램을 그리는 방식입니다. 아래의 그림은 간략히 DAQ System에 대한 요구사항을 정리해 놓은 다이어그램입니다. 물론 요구사항에 대해서 글로 작성을 할 수도 있습니다. 


일부 사람들은 모델링 툴을 통한 유스케이스 작성보다, 글로 작성하는것을 선호하고 있습니다. 글로 작성을 하게 되면 클래스 및 클래스의 구성요소를 만들어내는데 좀 더 효율적이라고 판단하기 때문입니다. 사람다마 선호도가 다를 수 있으니 여러가지를 시도해 보고 자신에게 가장 맞는 방식을 찾는것도 중요한 요소 중에 하나라고 생각을 합니다. 



2. 유스케이스의 구성요소


유스케이스 다이어그램은 크게 액터(Actor), 유스케이스(Use Case), 관계(Association 또는 Communication)으로 구성이 됩니다.


  • 액터 : 액터는 시스템을 수행하는 역할을 하는 요소로써, 시스템을 이용하는 사용자, 하드웨어 혹은 외부 시스템이 될 수 있습니다.
  • 유스케이스 : 액터와 개발할 시스템 사이의 기능을 나타냅니다. 시스템이 제공할 수 있는 기능들은 단위화 한것이라 볼 수 있습니다.
  • 관계 : 액터와 유스케이스 사이의 관계를 나타냅니다. 관계에는 포함 관계(include), 확장 관계(extend), 일반화 관계(Generalization)로 나뉩니다. 

    • 포함관계 : 특정 유스케이스의 동작이 다른 유스케이스를 포함하고 있을 때 사용합니다. 로깅이라는 유스케이스는 파일 저장이라는 유스케이스를 포함할 수 있습니다.

    • 확장관계 : 특정 유스케이스의 동작이 다른 유스케이스를 동작의 원인이나 이유가 될 때 확장 관계를 이용할 수 있습니다. 파일 저장을 하기 전에 폴더 및 파일 체크와 관리에 대한 유스케이스가 있다고 한다면 파일저장은 체크와 관리에 대한 확장 관계를 가질 수 있습니다.

    • 일반화 관계 : 상속의 개념이 들어가 있다고 볼 수 있습니다. 파일 저장은 TDMS 파일 저장, Excel 파일 저장의 상위 개념이 될 수 있습니다. 따라서 파일 저장은 TDMS, EXCEL을 바탕으로 일반화 할 수 있습니다.

관계의 사용 예는 아래의 그림과 같습니다. 위의 테이블에서 사용한 예를 바탕으로 유스케이스를 구현해 보았습니다. 하나의 유스케이스 다이어그램에는 다수의 액터, 유스케이스, 관계가 들어갈 수 있습니다. 아래의 그림에 액터가 하나밖에 없다고 하나만 만들어야 하는것은 아닙니다. 

아래의 그림에서 확인할 수 있듯이, 포함과 확장은 점선이 사용되고 일반화에는 실선이 사용이 됩니다. 모델링 툴에 따로 구분이 되어 있으니 사용에는 별다른 어려움은 없을것이라 생각이 드네요. 


유스케이스, 시스템 설계시 사용이 많이되는 다이어 그램입니다. 요구사항 분석 및 전체 시스템 분석에도 반드시 필요한 다이어그램이구요. 이번기회에 꼭 숙지하시길 기원드립니다.


이 글이 도움이 되셨나요?

그렇다면 아래의 그림을 클릭해주세요.



댓글