소프트웨어 공학 UML 과제 [UseCase Diagram]
Use Case Diagram [ 목 차 ] 2.1.Use Case Diagram 개요 2.2.Use Case 구성요소 2.3.Relationship 2.4.작성방법 2.5.참고문헌
1. Use Case Diagram 1.1 Use Case 모델링 개요 - Use Case 는 개발자가 아닌 사용자 입장에서 시스템을 보았을 때, 시스템이 제공해야 할 기능(functionality)을 나타 내야 하며 Actor정의서와 Use Case정의서가 보조적으로 활용 또한 Use Case Diagram은 모든 요구사항을 만족하는 지를 확인하기 위해 사용 - Use Case, Actor 간의 관계를 표현(Actor는 사람 또는 시스템을 가리키며, Actor는 Use Case를 수행 함) - 시스템이 제공하는 기본적인 기능을 설명하고, 사용자와 대화 수단 파악 및 내부 기능을 예측할 목적임 논리뷰 (Logical View) 분석가/설계자 구조 프로세스 뷰 (Process View) 시스템 통합자 성능,확장성,처리량 유즈케이스 뷰 (UseCase View) 사용자 기능성 구현뷰 (Implementation View) 프로그래머 소프트웨어관리 배치뷰 (Deployment View) 시스템 엔지니어 시스템구성 UML 아키텍쳐(4+1 View) 3
2.2 Use Case 구성요소 2.2.1 액터(Actor) 가. 액터 정의 - 시스템의 외부에 존재하면서 시스템과 상호작용하는 모든 것(사람, 기계 또는 타 시스템 등) - 사람 심볼(Stick Man)로 표기하고 Actor명을 기재하며 Actor명은 단일 명사를 사용 - Actor명은 물리적인 사람이나 조직명 보다는 역할 중심으로 추상화하여 Actor 이름을 정의 나. 액터를 찾는법 Actor1 교수 학생 - 특정한 요구사항에 관련된 사람은 누구인가? - 시스템을 사용하는 조직은 어디인가? - 시스템에 정보를 제공/사용/삭제하는 사람은 누구인가? - 누가 해당 기능을 사용하는가? - 시스템을 운영하는 사람은 누구인가? - 시스템이 외부 자원을 활용하는가? - 한 액터가 여러가지 역할을 하고 있지는 않는가? - 또는 여러명의 액터가 한가지 역할을 수행하고 있는가? 4
2.2.2 유즈케이스(Use Case) 가. 유즈케이스 정의 - 액터의 요구에 의해 시스템이 어떻게 사용될 것인가를 표현 - 고객의 입장에서 본 기능적인 요구사항 - Use Case 그 자체로 완전하고 하나의 의미를 갖는 업무처리단위 - 타원형으로 표기하고 Use Case 이름을 기재. - 시스템의 기능성을 나타내고 타원 아래, 또는 내부에 이름을 표시 - Use Case 이름은 목적어+서술형 종결어미 형태로 정의하며 다이어그램 안에서 식별 가능하도록 부여함 UseCase1 과제 제출 나. 유즈케이스 정의 방법 - 액터가 요구하는 시스템의 주요기능은 무엇인가? - 액터가 시스템의 어떤 정보를 수정, 조회, 삭제, 저장하는가? - 시스템이 액터에게 주는 이벤트가 있는가? - 액터는 시스템에게 어떤 이벤트를 전하는가? - 시스템의 입력과 출력으로 무엇이 필요한가? 그리고 입력과 출력이 어디에서 오고 어디로 가는가? - 시스템의 구현에서 가장 문제가 되는 점은 무엇인가? 5
2.2.3 시스템 경계(System Boundary-Optional) - 구축해야 할 Scope의 범위를 가리킨다. - 시스템의 경계와 시스템을 위한 유즈 케이스를 포함 - 액터들은 시스템 경계 외부에 위치한다. - 의미 없는 System Boundary는 피한다. System Boundary 6
2.3 Relationship 2.3.1 연관관계(Association) - 상호작용하는 Actor와 Use Case간의 관계를 표현함 - Actor와 Use Case, Use Case간, Use Case간 Generalization, Actor간 Generalization 네 가지 유형의 연관 관계를 가짐 - Actor는 하나 이상의 Use Case와 연관될 수 있으며, Use Case 또한 하나 이상의 Actor와 연관될 수 있음 - Use Case Logic안에 Actor가 등장하면 그 Actor와 Use Case는 연관관계를 가져야 함 - 연관의 의미는 Use Case, Actor 간의 연관성을 표시하기 위함이다. 과제 제출 상담자 7
2.3.2 확장(Extend) - 선택적인 행위관계, 어떤 특수한 조건에서만 수행 - 하나의 Use Case가 다른 Use Case의 행동을 추가함을 나타내는 두 Use Case 간의 관계 - 수행 순서는 화살표 반대 방향으로 발생 - 하나의 Use Case가 다른 Use Case를 경우에 따라 수행할 수도 있고 안 할 수도 있는 Optional하게 수행되는 경우에 사용 - 확장 유형에 따라 Extend Points를 가질 수 있다. 수수료 인하요청 <<extends>> 승인 요청 상담자 2.3.3 포함(Include) - 필수적인 행위관계, 단순 Use Case의 행위를 포함 - 하나의 Use Case가 다른 Use Case를 사용함을 나타내는 두 Use Case 간의 관계 - 수행 순서는 화살표 방향으로 발생하며 하나의 Use Case가 다른 Use Case를 반드시 수행되는 경우에 사용 됨 대출상담요청 <<include>> 원장조회 상담자 8
2.3.4 일반화(Generalization) - 일반적인 행위를 특수한 행위로 제한 - Actor간의 상속관계를 나타내는 두 Actor간의 관계 - 추상화된 Use Case를 상세화하는 Use Case 간의 관계를 표현할 때도 사용 됨 텔러 종업원 2.3.5 노트(Note) - 다이어그램의 표현을 돕기 위해 Note 사용 - Note를 이용하여 누구나 다이어그램을 이해할 수 있도록 표현 텔러 종업원 9
2.4 작성방법 2.4.1 작성지침 - 한 Diagram에 속한 여러 요소 중 특정한 요소의 크기를 다른 요소에 비해 크게 그리는 것은 해당 요소를 중요하게 생각 하는 오해를 불러 올 수 있으므로 각 요소의 크기를 통일 시켜야 함. - Use Case의 단위는 하나의 주요한 기능을 나타내야 하며 하나의 Use Case는 반드시 Actor에게 어떤 가치를 제공해야 함 - 모든 Use Case 는 하나 이상의 Actor와 관련을 갖아야 함. - 특정 Use Case에 해당하는 Actor가 없는 경우에는 가상의 Actor(Virtual Actor)를 정의하여 관계를 맺는다. - Use Case가 복잡하여 하나의 다이어그램으로 표현하기 어려운 경우에는 패키지를 이용하여 논리적으로 연관된 Use Case 끼리 묶어 여러 개의 Use Case 다이어그램을 생성함. 또는 상위 Use Case와 하위 Use Case로 분리하여 생성 - Use Case 다이어그램에서 가급적 Use Case 레벨의 깊이(depth)를 적게 함으로써 Use Case 가 지나치게 세분화되지 않도 록 함 - Use Case 는 Actor의 관점에서 완결성이 있는 하나의 작업이어야 함. 하나의 Use Case 행동은 상대적으로 짧은 시간에 완 결된다. 만약 Use Case의 일부가 오랜 시간에 걸쳐 수행된다면, 특히 서로 다른 Actor에 의해 수행된다면, 이러한 부분들 은 별도의 Use Case로 분리되는 것이 낫다. - 다이어그램을 작성할 때 확장(Extend) 관계와 포함(Include) 관계의 남용을 금한다. 이들을 많이 사용할 경우 이해도가 떨어 질 수 있다. - 최초에 식별된 Actor, Use Case 목록이 마지막 단계까지 동일한 상태로 유지되는 경우는 드물다. 시스템을 사용하는 역 할을 조사하고 해당 역할이 시스템과 상호 작용하는 방법을 검토함으로써 Actor, Use Case 의 목록을 반복적으로 정제한다. 10
2.4.2 작성절차 시스템 경계 정의 시스템이 어디에서 시작하고 어디에서 끝나는지를 명확하게 표현 시스템이 포함하고 있어야 할 기능들의 경계를 정의 Actor 정의 Use Case 정의 UseCase Description 서술 액터는 이벤트를 완결하기 위해 시스템과 상호작용하는 개체 액터가 시스템을 사용하는 사람일 필요는 없다. 액터는 다른 시스템, 외부 조직, 외부 디바이스, 시스템과 상호작용하는 어떤 것이라도 될 수 있다 액터가 사람일 경우, 시스템과 상호작용하는 사용자에 의해 수행되는 역할(Role)을 나타낸다. 유즈케이스를 찾기 위해서는 시스템의 목표를 검사해야 함. 액터에게 가치있는 정보를 제공하는 유즈케이스를 정의 시스템이 제공하여야 할 기능 위주로 도출 여러 유즈케이스에 공통적으로 발생하는 기능은 별도의 유즈케이스로 구성해야 함 주로 사용하는 Actor를 기술 하며 Trace가 가능하도록 Naming Rule에 의거 UseCase ID와 명칭을 기술 UseCase의 목적, 사전, 사후조건, 비 기능적 요구사항을 기술 주흐름이 되는 메인 흐름(Normal)을 기술 메인흐름에 대체가 될 수 있는 대안흐름(Alternate)을 기술 예외처리 사항을 기술 11
2.4.3 Actor Diagram(예시) 12
2.4.4 Use Case Diagram(예시) 13
2.4.5 Use Case 정의서(예시) 14
2.5 참고문헌 UML ebook 안영회, BIT 전문대학원 비즈니스 컴퓨팅 연구소, 2005. CBD 모델링 가이드(프로젝트 개발 표준 문서) xx은행, 2006. UML2의 13 Diagram KAIST, xxxx. 15