프로그램 아키텍쳐/UML

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

본클라쓰 2010. 8. 28. 10:17

 

Use Case Diagram은 요구사항을 분석할 때 사용하는 모델링 언어로 구축 시스템이 실행할 작업이 무엇인지를 표현합니다. 요구 사항 분석부터 테스트까지 전반적으로 사용할 수 있는 모델 요소입니다.

 

 요구사항을 관리하는 것이 중요한 이유는 시스템의 성패는 요구사항이 잘 정의되고 관리되었는지에 달려 있기 때문입니다. 요구사항의 관리는 두 가지 측면을 만족시키는 시스템적 접근 방법입니다. 첫째, 요구사항을 정리하여 요구사항을 식별, 구조화, 문서화합니다. 둘째, 요구사항이 변경되었을 때 상황을 관리합니다. 요구사항이 변경으로 합의점을 도출하거나, 변경된 요구사항을 유지할 수 있습니다.

 

 하지만 요구사항은 관리하기 어렵습니다. 이유는 고객이나 사용자들도 그들이 원하는 것을 정확히 모르는 경우가 많으며, 개발자가 요구사항을 서술하는 스타일과 고객이 서술하는 스타일이 다르며, 요구사항은 언제나 불분명합니다. 또한 요구사항은 다양한 소스로부터 도출되며, 요구사항은 단어로 정확하게 표현하기 쉽지 않고, 다른 요건들 및 다른 개발 산출물과 관련이 많습니다. 또한 가장 큰 문제인 요구사항은 변하는 것입니다.

 

 개발시 좋은 요구 사항을 도출하기 위해서는 요구사항이 정확(Correct)하게 정말 "필요한 것"만을 나타내고, 완전(Complete)하기 요구사항을 구현하기 위해 필요한 것을 서술하며, 일관(Consistance)적으로 다른 요구 사항과 충돌하지 않고, 모호하지 않은(Unambigous) 단 하나의 해석만 가능하고, 고객이 이해할 수 있는(Understandable by the customer) 요구 사항의 정리가 필요합니다. 또한, 검증(Verifiable)로 구축된 시스템이 요구 사항을 만족시키는 지에 대해 검증할 수 있어야 합니다.

 

 일반적으로 프로젝트가 성공(정해진 납기와 예산의 범위 내에서 종료되는 것)에 기여하는 요소는 규모, 기간, 팀 규모로 프로젝트의 규모가 작을 수록, 기간이 짧을 수록 그리고 팀의 규모가 작을 수록 성공 확률이 높습니다. 또한, 프로그램은 '1-10-100 Rule'이라 하여 오류가 발생했을 때 요구사항 정의 단계에서 수정하면 1, 동일한 오류를 테스트 기간에 수정하면 10, 구축이 완료되고 유지보수 기간에 수정하면 100의 비용이 소용된다는 법칙이 통용됩니다.

 

 이와 같이 유즈케이스 다이어그램은 고객의 요구사항을 명확하게 하여, 프로그램의 설계 단계에서 오류를 검증하는 절차를 만들 수 있는 기본 모델링 언어입니다.

 

 Use Case Diagram를 작성하기 이전에 유즈케이스 명세서(Use Case Specification)를 작성합니다.

 


 


 Use Case Diagram은 Actor와 기능으로 구성한 단순한 다이어그램입니다. Actor는 시스템 외부에서 시스템과 상호 작용하는 사람 또는 사물입니다.