1 5 장 유즈 케이스 다이어그램 5.1 Usecase 에 대하여 5.2 UseCase 모델링의 목적 5.3 Usecase 다이어그램의 요소와 표기법 5.4 UseCase 사이의 관계 5.5 액터와 유즈케이스의 추출법과 추출규칙 5.6 기타 특징들.

Presentation on theme: "1 5 장 유즈 케이스 다이어그램 5.1 Usecase 에 대하여 5.2 UseCase 모델링의 목적 5.3 Usecase 다이어그램의 요소와 표기법 5.4 UseCase 사이의 관계 5.5 액터와 유즈케이스의 추출법과 추출규칙 5.6 기타 특징들."— Presentation transcript:

1 1 5 장 유즈 케이스 다이어그램 5.1 Usecase 에 대하여 5.2 UseCase 모델링의 목적 5.3 Usecase 다이어그램의 요소와 표기법 5.4 UseCase 사이의 관계 5.5 액터와 유즈케이스의 추출법과 추출규칙 5.6 기타 특징들

2 2 5.1 Use case 에 대하여 (1) 정의 UseCase 란 사용의 사례로서 시스템의 사례들을 그려 놓은 것 Usecase 란 시스템의 외부에서 본 기능 개발자와 사용자와의 상호작용으로 표시한 것 Usecase 의 목적은 시스템의 기능을 정의하는 것 ( 기능의 실현방법은 기술하지 않음 ) CD 를 빌린다. 비디오를 빌린다. 유즈케이스 대여 시스템

3 3 5.1 use case 에 대하여 (2) use case 의 특징  의사 소통 수단이다.  의뢰인 혹은 사용자와 개발자는 시스템의 형태에 대해서 결정  이러한 결정을 위해서 UseCase 를 사용함  구현이 독립적이다.  Use Case 다이어그램을 그릴 때 시스템의 내부적인 수행과정은 포함하지 않음.  시스템의 기능을 알려주면 의뢰인의 이해를 더 감소시키는 영향을 미침  테스트의 기본이다.  의뢰인과 개발자간의 합의로 인해 시스템의 기능이 확정됨  Use Case 다이어그램은 앞으로 개발되는 중간결과물에 대한 테스 트의 기본

4 4 5.2 Use Case 모델링의 목적  개발하려고 하는 시스템의 기능적인 요구사항 (Functional Requirements) 을 최종 사용자와 개발자와의 합의하에 결정하고 표현  시스템의 기능을 요구분석단계 (Requirement Analysis Process) 에서 명 확하고 일관성있게 표현함으로써, 개발자들간의 의사소통의 수단으로 이용  최종적으로 개발된 시스템의 기능을 초기의 요구사항과 비교, 검증하는 데 이용  개발된 시스템을 구성하는 실제 클래스와 오퍼레이션들을 통해 기능적 인 시스템의 확장과 유지보수의 용이성을 도모 설계 Design 구현 Implementation 분석 Analysis 검사 Test 요구사항분석 Requirement Analysis Use Case Modeling ( 그림 ) Use Case 모델의 역할

5 5 5.3 use case 다이어그램의 요소와 표기법 (1) 유즈 케이스 다이어그램에서 사용하는 주요 모델요소 Actor Use CaseUse Case 1Use Case 2 관련 (Association) 관계 ( 그림 ) Use Case Diagram

6 6 5.3 use case 다이어그램의 요소와 표기법 (1) 유즈 케이스 다이어그램에서 사용하는 주요 모델요소  액터  액터는 시스템의 일부가 아니다.  시스템 사용자가 수행하는 역할을 나타낸다.  유즈 케이스를 기동하는 것은 액터가 된다.  시스템과 활발하게 정보교환을 하거나, 수동적으로 정보를 수 취한다.  인간 ( 시스템의 이용자 ), 하드웨어, 외부 시스템 ( 개발대상 이외 의 시스템 ) 이 액터가 될 수 있다.  유즈 케이스  유즈 케이스는 액터와 시스템 사이의 대화를 모델화한다.  유즈 케이스는 액터에 의해 개시되는 시스템의 기능 ( 시스템 밖 에서 본 동작 ) 을 나타낸다.  시스템 사용자가 시스템을 이용하여 수행하는 단위업무의 하 나를 추상화한 것  유즈 케이스를 모두 모으면, 시스템이 어떻게 사용되는지 전부 드러남

7 7 5.3 use case 다이어그램 (2) Use Case Diagram 의 표기와 의의  액터와 유즈케이스의 하단에는 각각 액터명과 유즈케이스명을 기록한다.  액터와 유즈케이스의 관계는 선의 연결로 표기한다.  유즈 케이스는 시스템의 내부, 액터는 외부로 포착할 수 있다.  유즈 케이스 다이어그램에 시스템 경계를 명시하는 경우는 유즈 케이스를 큰 장방형으로 둘러싸고, 장방형의 안쪽에 시스템명을 기술한다.  액터, 유즈 케이스 및 그러한 관련을 표현한 것을 유즈 케이스 모델이라 한다.  Actor 는 시스템과 상호작용하는 어떤 사람이나 어떤 것이다.  시스템과의 상호작용이란 시스템과 어떠한 정보의 교환을 한다는 의미이다.  Actor 는 시스템의 개인사용자가 아니라 하나의 역할을 나타낸다.  Use Case 는 시스템의 핵심적인 기능을 표현한 하나의 단위이다. 유즈 케이스 시스템 액터

8 8 5.3 use case 다이어그램 (3) 도큐먼트에 대하여  개요 : 유즈 케이스의 목적을 몇 행으로 기술한다.  event flow: 유즈 케이스가 언제, 어떻게 개시, 종료하는지, 액 터와 유즈 케이스와의 상호작용에 대해 문장으로 기술한다.  시나리오 : 유즈 케이스의 실례를 문서로 기술한다. 각 유즈 케 이스는 여러 시나리오의 집합으로서 표현된다.

9 9 5.3 use case 다이어그램 (4) Use Case Diagram 의 예 액터 (Acter) : 이용자, 음료물 품 공급자, 현금회수자 Use Case : 음료수를 구입한 다, 음료물품을 보충한다, 현 금을 회수한다 액터 현금회수업자 음료수를 구입한다. 음료수를 보충한다. 현금을 회수한다. 물품공급업자 자동판매기의 유즈 케이스 모델 음료자동판매기

10 10 5.4 Use Case 사이의 관계 (1) Use Case 간의 관계  포함관계 (Include) 기본 유스케이스에서 포함 유스케이스로 향하는 관계이다. 포함 유스케이스에 정의된 행위가 명시적으로 기본 유즈케이스에 정의된 행위로 삽입되는 방법을 설명한다. 구매자 주문한다. 재고를 확인한다. 상품을 발송한다. > [ 주문한다 ] 고 하는 처리는 [ 재고를 확인한다.] 라고 하는 처리와 [ 상품을 발송한다 ] 라고 하 는 처리를 [ 포함하고 ] 있다.

11 11 5.4 Use Case 사이의 관계 (1) Use Case 간의 관계  확장관계 (Extend)  유즈케이스의 변형 (variation) 을 늘릴 때에 확장을 개념을 이용한다.  확장은 기저 유즈케이스로 확장점을 선언해서 이용한다.  기술은 의존관계와 관련하여 스테레오타입 > 를 부여해서 나타낸다. 발송담당 상품을 발송한다. 상품을 일부를 재고한다. > [ 상품의 일부를 발송한다 ] 고 하는 처리는 [ 상품을 발송한다 ] 고 하는 처리가 근원이 되 고 있다.

12 12 5.4 Use Case 사이의 관계 (1) Use Case 간의 관계  일반화관계 (Generalization)  유즈케이스 다이어그램에서도 액터와 유즈케이스의 범용화를 행할 수가 있다.  동작의 변형 (variation) 을 늘리는 것도 가능해진다. 미끄럼타는 사람 스키타는 사람 스노보더라는 사람 스키로 미끄러지다. 스노보드로 미끄러지다. 스키타는 사람, 스노보드타는 사람과 같이 미끄러지는 행위를 하는 사람 스키나 스키보드 모두 미끄러진다고 하는 행위

13 13 5.4 Use Case 사이의 관계 (2) Use Case 의 관계 사용사례  포함 (Include) 이용자 물품공급업자 현금회수업자 음료수를 구입한다. 음료물품을 보충한다. 잠금장치를 연다. 앞문을 연다. > 음료물품을 보충한다. 잠금장치를 연다. 앞문을 연다. > 그림설 명  [ 음료물품을 보충하다 ] 는 [ 잠금장치를 연다 ] 를 포함하고 있다.  [ 음료물품을 보충하다 ] 는 포함하는 측이고, [ 잠금장치를 연다 ] 는 포함되는 측이므로 독립하여 사용할 수 없다. 음류수자동판매기

14 14 5.4 Use Case 사이의 관계 (2) Use Case 의 관계 예  확장 (Extend) 앞문을 닫는다. 물품을 보충한다. 확장점 팔린 물품을 보충하다. 판매개수에 따라 물품을 보충하다. > 팔린 물품을 보충한다. 그림설 명  [ 물품을 보충하다.] 은 판매개수에 따라 물품을 보충할 수 있으므로 이 관계를 확장이라고 할 수 있다. >

15 15 5.4 Use Case 사이의 관계 (2) Use Case 의 관계 예  일반화 (Generalization) 그림설 명  [ 커피음료수를 구입하다.] 는 유즈 케이스는 [ 음료수를 구입하다.] 의 하위 유스 케이스가 된다.  상위 케이스로부터 계승한 또다른 [ 설탕을 추구하다.], [ 밀크를 섞는다 ] 등의 독자 행동양식을 갖고 있다. 음료수를 구입하다. 커피 음료수를 구입하다. 하위 UseCase 는 상위 UseCase 의 의미와 행동양식을 계승할 수 있다.

16 16 5.5 액터와 유즈 케이스의 추출법과 추출 규칙 (1) Actor 추출법과 관련성 추출규칙 ① 시스템의 주기능을 사용하는 사람은 누구인가 ? ② 누가 시스템으로부터 업무지원을 받는가 ? ③ 누가 시스템을 운영, 유지보수하는가 ? ④ 시스템과 정보를 교환하는 외부 시스템은 무엇인가 ? ⑤ 시스템이 내어놓은 결과를 누가 관심을 가지는가 ? ⑥ 한 사람이 여러가지 역할을 하는가 ? ⑦ 시스템이 기존의 시스템과 상호작용하는가 ? ⑧ 여러 사람이 동일한 역할을 하는가 ?

17 17 5.5 액터와 유즈케이스의 추출법과 추출규칙 (2) Use Case 추출법과 후부 추출규칙 ① Actor 가 요구하는 시스템의 주요기능은 무엇인가 ? ② Actor 가 시스템의 어떤 정보를 수정, 조회, 삭제, 저장하는가 ? ③ 시스템이 Actor 에게 주는 어떤 Event 가 있는가 ? ④ Actor 가 시스템에 주는 어떠한 Event 가 있는가 ? ⑤ 시스템의 입력과 출력으로 무엇이 필요한가 ? ⑥ 입력과 출력이 어디에서 오고 어디로 가는가 ? ⑦ 시스템의 구현에서 가장 문제가 되는 점은 무엇인가 ?

18 18 5.6 기타 특징들 (1) Event Flow (1) Event Flow (2) 시나리오  Main Flow of Event : Use Case 의 행위의 중심적 흐름을 나타낸다.  Alternte Flow of Event : Main Flow of Event 중 선택적인 상황이 발생할 경우를 나타낸다.  Exceptional Flow of Event : 예외적인 상황이 발생할 경우를 나타낸다. (3) 실제화 (Realization) 이벤트의 흐름을 실례 (Instance) 화하여 텍스트로 나타낸 것을 말한다. 실제 UseCase 는 다이어그램에서는 구현에 관한 표현은 하지 말아야 한다. ( 단 내부 구현이 필요할 경우는 Collaboration 으로 표현 )

19 19 보충자료 Use Case Diagram  System 이 해야 할 행동을 명세화  System, Sub-System, Class 의 각 요소 행동을 모형화 하는도 구로써 요소 이용법을 파악하고, 개발자가 요소를 구현 가능 하도록 하는 도구 Cellular network User Actor Place phone call Place Conference call Receive Phone call Receive Additional call Use scheduler > 확장 (Extend) Use Case 연관 (Association) System 경계

20 20 보충자료 System 문맥 Modeling  System 외부에 존재하는 것 (Actor) 과 System 과의 교류를 명세화  System 문맥 Modeling 방법  System 으로부터 도움을 받아 Task 를 수행해야 할 Group 을 식별하여 Actor 를 식별  Actor 중에서 유사한 것이 존재하면 일반화 / 특수화 계층으로 조직  Actor 를 Stereotype 으로 표현하여 이해에 도움을 줌  Use Case 다이어그램에 식별된 Actor 를 표현하고 Actor 로 부터 Use Case 에 대화 경 로 명시 Perform Card transaction Process Customer bill Reconcile transactions Manage Customer account Creit Card Validation System Customer Individual customer Corporate customer Retail institution Sponsoring Financial institution

21 21 보충자료 System 요구 사항 Modeling  요구사항은 System 의 설계 특성, Property, Behavior  System 요구 사항 Modeling 방법  System 외부의 Actor 를 식별하여 System 문맥을 설정  Actor 별로 System 에 요구하는 내용 / 행동을 파악  공통 행동을 Use Case 로 만들고 명칭을 붙임  공통 행동을 분해하여 새로운 Use Case 를 만들고 다른 곳에서도 사용 가능하도록 확장  Use Case, Actor, Relationship 를 Modeling 하여 Use Case Diagram 작성 Customer Retail institution Sponsoring Financial institution Perform Card transaction Process Customer bill Reconcile transactions Manage Customer account Report on Account status Detect Card fraud Manage Network outage Credit Card Validation System

22 22 보충자료  구조화가 좋은 Use Case Diagram  System 의 정적인 Use Case 관점에서 한 부분의 대화에만 초 점을 맞춤  해당 부분을 이해하는데 필수적인 Use Case 와 Actor 만을 포 함  추상화 수준별로 일관성 있게 상세 사항을 추가  중요한 의미는 적절한 정도의 크기로 분해  Use Case Diagram 작성법  목적을 알 수 있는 명칭의 사용  교차되는 Line 이 가능하면 최소화 되도록 요소를 배치  행동, 역할, 의미가 연관이 있는 것은 인정하여 배치  Note 등의 활용으로 가시적 효과를 이용하여 중요한 특성을 부각 시킴  관계는 너무 많이 표현하지 않고 반드시 필요한 것 만을 표현

23 23 보충자료 순공학과 역공학  Use Case Diagram 순공학  Diagram 에 있는 각 Use Case 마다 사건 흐름과 예외사건 흐 름을 식별  시험을 깊이 있게 하려면 각 흐름별 시험 Script 를 생성  Use Case 와 교류하는 각 Actor 를 대표하는 Test 기초 생성  Use Case Diagram 이 적용되는 요소를 배포할 때마다 Tool 을 사용하여 Test  Use Case Diagram 역공학  System 과 교류하는 Actor 파악  Actor 별로 Actor 가 System 과 교류하는 방법을 파악  Actor 별로 관련 있는 실행 System 에서의 사건 흐름을 추적  관련되는 흐름들을 묶고 적절한 Use Case 명칭을 부여  Actor 와 Use Case Diagram 을 도식하고 Relationship 을 설정