�ݺ�ߣ

소프트웨어 설계실 습2010년 9월 15일 (수)

유즈케이스 모델링(Use case Modeling)22010-09-15Intelligent Systems Research Lab.

유즈케이스 모델시스템의 행위 기술시스템의 기능적 측면을 사용자 관점에서 설명하는 명시적 모델시스템에서 제공되어야 할 기능을 기술32010-09-15Intelligent Systems Research Lab.

유즈케이스 모델특성사용자의 기능적 요구사항을 정의하는 직관적인 방법 개발하고자 하는 시스템과 시스템 사용자와의 관계를 정립하는 도구 사용자가 원하지 않는 시스템의 기능을 식별하는 것도 중요 개발자와 사용자간 상호 의사소통의 수단 Use Case Model은 시스템 개발 전 단계에 걸쳐서 영향을 미침 구현 문제는 생각하지 않음 42010-09-15Intelligent Systems Research Lab.

유즈케이스 모델구성 요소액터:시스템과 상호작용하는 주체유즈케이스: 시스템의 기능 행위를 표현유즈케이스 명세서 :각가의유즈케이스의 처리 흐름을 기술한 문서유즈케이스 다이어그램 :시스템 영역내의 유즈케이스와액터간의 관계를 도식화52010-09-15Intelligent Systems Research Lab.

유즈케이스 모델Use-Case Model유즈케이스의 관점에서 시스템의 기능적 요구사항을 묘사하는 모델시스템의 의도된 기능성(유즈케이스) 및 그와 관련된 환경(액터)ActorsUse Cases...Use-Case Specifications62010-09-15Intelligent Systems Research Lab.

액터(Actor)액터는 클래스의 스테레오타입액터는식별자; 사용자는 하나의 인스턴스액터는유즈 케이스를 발견하는 기준시스템 외부에서 시스템과 직접적으로 상호작용 하는 어떤 것시스템으로부터 입력을 제공하거나 출력을 획득액터72010-09-15Intelligent Systems Research Lab.

유즈케이스유즈케이스의 정의특정 액터를 위해 측정 가능한 결과치를 제공하기 위해 시스템에 의해 수행되는 일련의 트랜잭션하나의 유즈케이스는 반드시 액터에게 어떤 가치를 제공시스템이 사용될 때 어떻게 행동할 것인가에 대한 응집된 이야기각각의 액터가 시스템을 사용하는 목적을 달성하도록 하기 위해서 시스템이 제공해야 하는 기능.어떠한 기능들이 시스템에 의해서 액터에게 제공될 것인가를 정의시스템의 유즈 케이스를 모아 놓은 것은 시스템이 사용되어지는 모든 방법들을 구성 사용자 관점특정 액터가 시스템을 통해 수행하는 일련의 행위들(sequence of actions)을 모아놓은 것액터의 요구에 의해 시스템이 어떻게 사용될 것인가를 표현시스템이 액터에게 어떤 서비스를 제공하는지를 표현고객의 입장에서 본 기능적인 요구사항유즈케이스는 그 자체로 완전하고 하나의 의미를 갖는 업무 처리 단위82010-09-15Intelligent Systems Research Lab.

유즈케이스유즈케이스는 요구사항에 대한 문서화 목적이 아니라, 요구사항 파악을 목적으로 한다유즈케이스는 그 자체로 요구사항이다별도의 요구사항 목록으로 재정의 할 필요 없음유즈케이스가 요구사항의 전부는 아니다.유즈케이스는 시스템 행위의 기능적 측면만 표현성능(Performance), 신뢰성(Relaibility), 사용성(Availability)등 비기능적 요구사항을 표현하지는 못함비기능적 요구사항은 별도의 요구사항 목록으로 작성 필요92010-09-15Intelligent Systems Research Lab.

유즈케이스유즈케이스 식별을 위한 질문 리스트각 액터들이 해야 하는 일은 무엇인가?시스템에서 정보를 생성, 저장, 변경, 삭제 또는 조회하는 액터가 있는가?어떠한 유즈 케이스가 이러한 정보를 생성, 저장, 변경, 삭제 또는 조회하는가?갑작스러운 외부의 변경사항을 시스템에 통지하는 액터가 있는가?시스템에서 발생하는 어떤 상황들을 보고 받아야 하는 액터가 있는가?어떠한 유즈 케이스들이 시스템의 지원과 관리를 수행하는가?이 유즈 케이스들에 의해 시스템의 모든 기능적인 요구 사항들이 수행될 수 있는가?102010-09-15Intelligent Systems Research Lab.

유즈케이스 다이어그램Usecase Diagram시스템의 기능적 요구사항을 표현, 시스템의 사용자(액터)와 시스템 간 정형적인 상호작용 기술사용자 관점에서 시스템 행동을 조직화하고 Modeling112010-09-15Intelligent Systems Research Lab.

유즈케이스 명세서유즈케이스 그 자체는 “WHAT”에 관한 문제유즈케이스 명세서는 “HOW”에 관한 문제“어떻게 구현할 것인가”가 아니라 “내부 업무 흐름이 어떠한가?”임구현에 대한 How가 아니라 업무에 대한 How2010-09-1512Intelligent Systems Research Lab.<Use Case 이름>개요관련 액터사전조건Flow of Event사후조건특별요구사항<Use Case 이름>개요관련 액터사전조건Flow of Event사후조건특별요구사항고객정보관리구매성향분석

유즈케이스 명세서Flow of event유즈케이스의 작업이 완료되기 위한 여러 비즈니스 이벤트의 흐름(Scenario)시스템외부 발생 상황은 기술하지 않는다.액터와유즈케이스간 정보 교류 기술.UI에 관한 내용은 언급하지 않는다.가능한 쉬운 용어 사용해당 유즈케이스에 관한 것만 기술.자세하게 기술하기 보다는 정확하게 기술Basic Flow(기본흐름)일반적인 흐름을 기술.잘못된 경우는 기술하지 않음Alternative Flow(대체흐름)선택사항예외사항(Error)유즈케이스size가 큰 경우132010-09-15Intelligent Systems Research Lab.

유즈케이스 명세서유즈케이스 명세서 작성 지침액터의 관점에서 작성너무 세부적이지 않지만 정확하게 작성요구사항을 수집하고 정의하기 위해서 작성하는 것이지, 세부적인 분석, 설계를 하는 것은 아니다.완벽한 유즈케이스를만들수도 없고, 만들려고 노력할 필요는 없다.유즈케이스 명세서는 액터와유즈케이스간 상호작용을 설명한다.고객은 현금 인출카드를 넣고 비밀번호를 입력한다.시스템은 잔고에서 일정액을 차감한다.2010-09-1514Intelligent Systems Research Lab.

유즈케이스 명세서액터의 움직임이 아닌 의도를 보여준다사용자 인터페이스에서 사용자의 움직임을 서술할 필요 없음(인터페이스 상세 서술)문서가 길수로 읽기 어렵고, 유지보수 비용도 높아진다.서술된 대화(Dialogue)는 요구사항이기 보다는 그 순간에 작성자가 사용자 인터페이스를 상상하는 것에 가깝다.대화(Dialogue)는 시스템이 조금만 변경되어도 작성된 부분을 무효로 할 수 있다는 점에서 불안정 사용자 인터페이스의 의도를 파악일반적으로 한쪽 방향으로 전달되는 모든 데이터는 한 개의 행동 단계로 표현한다.2010-09-1515Intelligent Systems Research Lab.1.시스템이 이름을 묻는다.2.사용자가 이름을 입력한다.3.시스템이 주소를 묻는다.4.사용자가 주소를 입력한다.5.사용자가 ‘확인’을 클릭한다.6.시스템은 사용자 정보를 보여준다.1.사용자가 이름과 주소를 입력한다.2.시스템은 사용자 정보를 보여준다.

유즈케이스 명세서작성 서식유즈케이스 명개요짤막한 문장으로 해당 유즈케이스의 목적과 역할에 대해 기술관련 액터해당 유즈케이스와 상호작용하는 액터사전조건(Pre-Condition)유즈케이스가시작되기전에 반드시 만족해야 하는 조건예) 주문 상품 변경을 위해서는 해당 주문이 결제가 미완료 상태이여야 함.이벤트 흐름(Flows of Events)해당 유즈케이스에서 시스템에 해야 하는 행위에 대한 서술(textual description)복수의 이벤트 흐름이 존재(기본흐름, 대체흐름, 예외흐름)사후조건(Post-Condition)유즈케이스가 종료되면서 반드시 만족해야 하는 조건특별 요구사항2010-09-1516Intelligent Systems Research Lab.

유즈케이스 명세서2010-09-1517Intelligent Systems Research Lab.상품구입I.관련액터고객액터II.기본흐름1. 고객이 상품목록을 찾아보고, 구매할 상품을 선택한다. 2. 고객이 계산을 시작한다. 3. 고객이 배송정보를 입력한다.(주소, 익일배송인지 일반배송인지) 4. 시스템에서는 배송비를 포함한 총 금액을 보여준다. 5. 고객이 신용카드 정보를 입력한다. 6. 시스템이 구매를 승인한다. 7. 시스템이 판매가 완료되었음을 즉시 확인한다. 8. 시스템이 확인메일을 고객에게 발송한다.III.대체흐름3A.고객이 단골고객인 경우1. 시스템이 현재의 배송비, 가격, 지불정보를 표시한다. 2. 고객이 기본사항을 그대로 이용하거나, 정보를 갱신한 후, 6번으로 간다. 6A.시스템이 신용카드 승인에 실패한다. 1.고객이 신용카드 정보를 다시 입력하거나, 취소한다.

실습 과제Thinkwise로 작성한 요구사항을 기능적 요구사항, 비기능적 요구사항으로 구분기능적 요구사항을 유즈케이스 다이어그램으로 나타냄유즈케이스 명세서를 작성유즈케이스 명세서 템플릿은 홈페이지에 업로드2010-09-1518Intelligent Systems Research Lab.

실습한 내용을 보고서 템플릿에 맞춰 작성하세요실습한 파일 (RSA)과 보고서 파일을 업로드 하세요압축 필요하지 않으니 이제부터 압축하지 마세요1. 요구사항 분석 명세서를 작성해오세요!!홈페이지에 템플릿 업로드2.파워포인트 슬라이드 마스터를 공부하고, 멋진 슬라이드 마스터를 만들어오세요!! 기존 무료 슬라이드 수정 가능

슬라이드 마스터 메인페이지, 제목페이지 두 장만 업로드레포트2010-09-1519Intelligent Systems Research Lab.추석특집 숙제!!

참고자료Usecase사이의 관계Include 관계하나의 유즈케이스가유즈케이스 내의 작업 흐름의 과정 안에 다른 유즈케이스의 작업 흐름을 포함하는 관계여러 유즈케이스들 간에 비슷한 작업이 공통으로 발생하는 경우 특정 부분을 하나의 유즈케이스로 따로 분리하고 정의AA<<include>>구조화CBB<<include>>202010-09-15Intelligent Systems Research Lab.

참고자료Usecase사이의 관계Extend 관계하나의 유스케이스의 흐름이 다른 유스케이스 내의 작업 흐름의 과정에 추가되어 작업 흐름을 확장하는 관계<<extend >>AA구조화<<extend>><<extend >>212010-09-15Intelligent Systems Research Lab.

참고자료Usecase사이의 관계Generalization 관계객체 지향 개념에서의 상속 관계와 유사해서 자식 유스케이스가 부모 유스케이스가 가지는 속성, 작업 흐름, 확장 지점, 다른 유스케이스와의 관계 등을 모두 가진다는 의미현금결제결제카드결제222010-09-15Intelligent Systems Research Lab.

유스케이스 작성에 대한 10가지 잘못다른 형태의 요구사항 문서는 만들 필요가 없다. [유스케이스]면 요구사항을 충분히 반영할 수 있다. 아니다. 요구사항 문서는 요구사항을 가장 잘 반영할 수 있는 형태의 문서로 만들어야 한다. 데이터베이스 설계에 대한 요구사항은 ER모델이 적합하고, 화면 구조에 대한 요구사항은 그래픽이 가미된 문서가 더 적합하다. 읽는 사람이 [유스케이스]의 목적에 대해 이해하기 힘들게 한다. [유스케이스]의 이름을 지을 때 ‘작업하다’, ‘처리하다’와 같은 말을 사용하여 혼란스럽게 한다. 만약 읽는 사람을 혼란스럽게 하는 데 성공했다면 [유스케이스]를 실제로 구현할 때 어떻게 해도 상관없을 것이다.[유스케이스]를 이용해서 효과적으로 소프트웨어 시스템을 구현하기 위해서는 명확하게 [유스케이스]를 작성할 필요가 있다. 간혹 어떻게 [유스케이스]를 작성해야 하는지 모르는 경우에 이렇게 처리하는 경우가 있는데 좋지 않은 모습이다. [유스케이스]의 범위에 대해 혼란스럽게 한다. 범위는 어차피 점점 퍼져나갈 것이고 나중에 리펙토링을 하면 된다. 사용자는 어차피 생각을 계속 바꿀 것인데 왜 성가시게 범위를 미리 확정하겠는가?[유스케이스]는 만들려고 하는 시스템이 어떠한 범위를 다루는지를 표현하는 것에도 사용된다. 시스템의 범위를 명확히 하고 그것을 여러 관여자가 충분히 이해할 수 있도록 [유스케이스]를 작성해야 한다. 232010-09-15Intelligent Systems Research Lab.

유스케이스 작성에 대한 10가지 잘못[유스케이스] 기술서에 비기능적 요구사항과 사용자 인터페이스 디테일을 포함시킨다.유스케이스의 작업 흐름에 사용자 인터페이스에 대한 세부 내용을 포함시키면 작업 흐름이 늘어나게 된다. 사용자 인터페이스를 요약한 내용을 추가하면 되지 상세한 내용까지는 포함시킬 필요가 없다. 초기 [유스케이스] 다이어그램에 포함 관계와 확장 관계를 많이 사용한다. 그러면 유스케이스를 작은 단위의 것으로 나눌 수가 있다.초기 버전의 유스케이스는 상위레벨의 유스케이스를 작성하고 반복을 거치면서 보다 상세화한 유스케이스를 작성하는 것이 좋다. CRUD를 처리하는 유스케이스가 대표적인데, 초기에는 ‘관리하다’라는 유스케이스로 하나로 만들고 이후에 반복을 통해 ‘생성’, ‘조회’, ‘수정’, ‘삭제’ 유스케이스로 세분화한다.비즈니스 룰을 정의하는 것에는 관여하지 말라.비즈니스 룰을 만들고 사용하는 것은 사용자이지만 그것을 산출물로 표현하도록 하는 것은 매우 중요하다. 룰 자체를 만드는 것에는 관여할 필요가 없지만 그것을 [유스케이스]를 통해 표현하도록 독려해야 한다.242010-09-15Intelligent Systems Research Lab.

유스케이스 작성에 대한 10가지 잘못[유스케이스]의 작성에 도메인 전문가를 관여시키지 말라. 그들은 질문이나 해댈 뿐이다.[유스케이스]는 요구사항에 대한 표준 표기법인데, 소프트웨어 시스템에 대한 요구사항을 가장 잘 알고 있는 것은 도메인 전문가이다. 물론 이들이 작업을 성가시게 할 수도 있지만 좋은 결과를 내기 위한 고통이라 생각해야 한다.만약 사용자를 [유스케이스] 정의에 관여시킨다면 그냥 그래라. 왜 사용자와의 미팅을 준비하는 데 골머리를 썩힐 것인가? 많은 양의 문서나 만들게 되고, 어쨌든 그들은 계속 마음을 바꾸게 될 것이다.될대로 되라는 식의 태도는 좋지 않다. 사용자에게 [유스케이스]를 충분히 이해시키고 [유스케이스]를 통해 효과를 볼 수 있도록 노력해야 한다.[유스케이스]를 한 번에 아주 상세하게 만들어라.반복적으로 점증적으로 [유스케이스]를 작성하는 것이 좋다. [유스케이스]를 검증하거나 평가하지 말라. 재작업이나 만들어 낼 뿐이다.반복적으로 점증적으로 작성하고 중간중간 계속 사용자나 도메인 전문가의 피드백을 받아야 한다. 252010-09-15Intelligent Systems Research Lab.

좋은 유즈케이스의조건정형적인 정답은 없다. 그렇지만,하나의 유즈 케이스는 시작과 종료까지 완전한 하나의 주요 단위기능을 표현해야 한다. 하나의 유즈 케이스는 하나의 액터에게 어떤 의미 있는 값을 전달해야 한다. 예 1: 유즈 케이스를 3개 또는 1개 어느 것으로 보아야 하는가 ? 학생은 반드시 한 학기의 수강 과목을 선택해야 한다.

학생은 반드시 한 학기의 강좌에 반드시 등록해야 한다.

수업료가 학생에게 청구 되어야 한다.예 2: 유즈 케이스를 3개 또는 1개 어느 것으로 보아야 하는가 ? 학적과의 직원은 과목을 추가, 삭제, 변경 등의 작업을 수행한다.262010-09-15Intelligent Systems Research Lab.

�ݺ�ߣ

SoftwareEngeneering3rd

More Related Content

SoftwareEngeneering3rd