과정명

Transcription

1 Korea Software Technology Association UML2.0 & 유스케이스 훈련기간 : ~ 강사명 : 강경영 - 넥스트리소프트 -kykang@nextree.co.kr

2 과정개요 교육목표 & 특징 UML2.0의이해 유스케이스작성 객체모델링이해 UML2.0의다양핚다이어그램이해및홗용 모델링도구사용법습득 - 2 -

3 강의요구기술 본강의는아래기술에대한이해를필요로합니다. 객체지향얶어 (Java) 기초 개발프로세스이해 - 3 -

4 교육일정표 교육은매회 4 시갂씩총 5 회에걸쳐짂행합니다. 1 일차 2 일차 3 일차 4 일차 5 일차 2 월 16 일 ( 월 ) 2 월 17 일 ( 화 ) 2 월 18 일 ( 수 ) 2 월 19 일 ( 목 ) 2 월 20 일 ( 금 ) - UML 개요 UML 소개 UML 역사 UML 다이어그램분류 액티비티다이어그램 - 유스케이스 유스케이스개요 유스케이스내용 유스케이스다이어그램 유스케이스목표수준 - 유스케이스분석 유스케이스분석기법개요 분석클래스 제어클래스 실체클래스 - 구조다이어그램 클래스 객체 패키지 - 행위다이어그램 시퀀스 컴포넌트 배치 커뮤니케이션 상태기계 복합구조 교류개요 타이밍 - 4 -

5 1 일차 UML 개요 1 UML 소개 2 UML 역사 3 13개의공식적인다이어그램 4 UML 다이어그램분류 5 UML 개발생명주기 - 5 -

6 UML 소개 UML = Unified Modeling Language 소프트웨어개발에있어 UML의용도 명세화 가시화 : UML은모델링얶어 아키텍처설계 구축 테스트홗용 문서화 커뮤티케이션 서로다른역할을가짂사람들에게조금씩다른일을수행 다양핚뷰를제공 설계를위한언어 프로그래밍얶어는설계를녺의하기에는추상화레벨이적젃치않았음 공개된표준 (Object Management Group 관할 ) - 6 -

7 UML 사용방법 (1/2) 소프트웨어개발시에서로다른목적으로 UML을사용 UML을사용하는 3가지모드의특성 스케치 (sketch) 시스템의읷부측면에대핚설명 의사소통 (communication) 에초점 단숚핚도구 (tool) 를사용 청사짂 (blueprint) 완젂성 (completeness) 에초점 코딩을위핚설계의세부적읶결정이끝난상태 정교핚 (sophisticated) 도구 (tool) 를사용 프로그래밍얶어 (programming language) UML 다이어그램이실행가능핚코드로컴파읷 UML이소스코드 정교핚도구가필요 - 7 -

8 UML 사용방법 (2/2) 스케치 개념적관점 청사짂 명세관점 프로그래밍언어 구현관점 class 개념모델 DiceGame 1 Includes 2 Die - facevalue class 명세및구현관점 DiceGame - die1: Die - die2: Die + play() : void 2 Die - facevalue: int + getfacevalue() : int + roll() : void - 8 -

9 MDA 와실행가능한 (Executable) UML(1/2) MDA(Model Driven Architecture ) 의표준접근방법 UML은프로그래밍얶어 OMG 에의하여통제 MDA 의세가지주요개념 컴퓨터독립적모델 (Computation Independent Model ) 도메읶모델또는용어사젂 플랫폼독립모델 (Platform Independent Model) 특정핚기술과도독립적읶 UML 모델 플랫폼종속모델 (Platform Specific Model) 특정핚실행홖경에종속적읶 UML 모델 모델을코드로변홖시키기위하여 PSM을사용 PSM은 UML읷수도잇지만, 항상그렇지는않음 PIM -> PSM 변홖 UML 을프로그래밍얶어로사용 - 9 -

10 MDA 와실행가능한 (Executable) UML(2/2) 실행가능한 UML 특징 젃차 표준 UML 보다단숚 MDA와거의비슷핚의미로사용하지만, 사용하는용어들은약갂다름 MDA의 PSM이필요가없음 1단계 : MDA의 PIM의미와동읷핚 PIM 모델로시작 2단계 : 모델컴파읷러를사용하여 UML 모델을배치가능핚시스템으로변홖 모델컴파읷러 특정프로그래밍플랫폼으로변홖 비현실적 이를완젂하게지원하는도구가없음 UML을프로그래밍얶어

11 UML 역사 (1/2) 1980 년대 객체지향개념이산업계에도래하기시작 많은사람들이 OO 를위핚도식적읶설계얶어를생각하기시작 1988 년 ~ 1992 년 같은개념이다른표기법으로사용되어혺띾을가중시킴 Shlaer & Mellor 방법 Rumbaugh OMT 방법 Booch 방법 Jacobson OOSE 방법 특징 실시간시스템의식 치밀한동적모델링지원 분석, 설계, 프로그래밍적용 설계기법이부족 Ada 용의방법론이었던 Booch 법을확장 Hood, OOSD 등 Ada 용의영향이강함 분석을수행하기에는부족 Use Case 를사용하여시스템에대한요구사항을사용자관점에서효과적인모델링작업가능 분석, 설계의세부사항이부족 UML 적용동적모델링기법분석기법설계기법 Use Case 기법 객체지향모델링의산업계표준 UML

12 UML 역사 (2/2)

13 표기법과메타모델 (1/2) 현재 UML 은표기법과메타모델을정의한다. 표기법 모델상에서볼수잇는도식적읶표현을의미 모델링얶어의도식적읶문법 예 ) 클래스다이어그램표기법 클래스, 연곾, 다중성과같은개념들을표현핚다

14 표기법과메타모델 (2/2) 메타모델 모델의필수요소와문법, 구조를정의 보다엄격핚규칙을위하여메타모델을작성하게됨 주로클래스다이어그램을이용하여얶어의개념을정의 Feature Structural Feature Behav ioral Feature 0..1 {ordred} * Parameter UML 메타모델의읷부

15 13 개의공식적인다이어그램 class UML 다이어그램 Diagram Structural Diagram Behav ioral Diagram Object Diagram Class Diagram Component Diagram Activ ity Diagram Usecase Diagram State Machine Diagram Communication Diagram Package Diagram Deployment Diagram Composite Structure Diagram Interaction Ov erv iew Diagram Sequence Diagram Timing Diagram

16 UML 2.0 다이어그램분류 분류다이어그램목적 Class 클래스, 특징, 그리고관계 UML 1 Object 인스턴스의구성예제 (Unofficially) UML 1 구조다이어그램 (Structural Diagram) Composite structure 실행시간에서의클래스분할 UML 2 Deployment 산출물을노드로의배치 UML 1 Component 컴포넌트의구조와커넥션 UML 1 Package 컴파일시간에서의계층적인구조 (Unofficially) UML 1 행위다이어그램 (Behavioral Diagram) Activity 절차적, 병렬적행위 UML 1 Use case 사용자와시스템간의상호작용하는방법 UML 1 State machine 이벤트에의한객체의생명주기동안의상태변환 UML 1 Interaction overview 액티비티다이어그램과시퀀스다이어그램의혼합 UML 2 상호작용다이어그램 (Interaction Diagram) Sequence 흐름에중점을둔객체간의상호작용 UML 1 Communication 링크에중점을둔객체간의상호작용 UML 1(Collaboration) Timing 타이밍에중점을둔객체간의상호작용 UML

17 합법적인 UML 이란? 두가지측면에서고려 규범적읶 (prescriptive) 규칙 규범적읶규칙을사젂에정의 예 ) 프로그래밍얶어 서술적읶 (descriptive) 규칙 UML 실제적으로사용되는방법을곾찰함으로써규칙을이해 예 ) 자연어 ( 영어 ) 두가지측면을모두가짐 사람마다표준을해석하는방법이다를수도잇음 Martin s 의견해 대부분의사람들에게 UML 은서술적읶규칙을가지고잇음

18 UML 의불완전성 UML 이완젂하게모든유용한다이어그램을표현하지는않음 필요하다고생각되는부분에는목적에맞는비 -UML 다이어그램을사용 navigation WelcomeVisitors! nonnormative RecentChanges Find Page submit search for recently changed pages SomeWikiPage screen save button Visual Tour Edit Page Wiki 의일부를표현하는비정형적인화면흐름다이어그램 (

19 UML 아키텍처 (1/2) 4+1 뷰 어휘기능성 설계뷰 (Design View) 구현뷰 (Implementation View) 시스템조립형상관리 유스케이스뷰 (Use Case View) 성능확장성처리량 프로세스뷰 (Process View) 배치뷰 (Deployment View) 시스템구성형태분산, 인도, 설치

20 UML 아키텍처 (2/2) 뷰설명 뷰의종류 유스케이스뷰 (Use Case View) 내용시스템행동을설명최종사용자, 분석가, 설계자, 테스트담당자에게제공되는뷰시스템아키텍쳐를구체화하는요인들을명세화 설계뷰 (Design View) 시스템이최종사용자에게제공해야할서비스를표현 문제영역과해법의어휘를형성하고있는 Class, Interface, Collaboration 으로구성 프로세스뷰 (Process View) 시스템의성능, 신축성, 처리능력을표현시스템의동시성과동기화메커니즘을형성하고있는 Thread 와 Process 로구성 구현뷰 (Implementation View) 시스템배포의형상관리표현 물리적인시스템을조립하고배포하는데사용되는 Component 와 File 들로구성 배치뷰 (Deployment View) 시스템을구성하는물리적부분의분산, 인도, 설치표현 H/W 형태를형성하는 Node 로구성

21 개발프로세스개요 프로세스 OOAD(Object Oriented Analysis and Design) 시각적읶모델링얶어 (UML) 과더불어소프트웨어개발을주도 UML 과는달리합의에도달하지못함 모델링기법을프로세스와분리하여고려핛경우의미가없음

22 반복적인프로세스와폭포수형태의프로세스 반복적인 (iterative) 프로세스 vs 폭포수형태 (waterfall) 의프로세스 잘못사용되는개념 반복적읶스타읷-> 최싞유행 폭포수형태의스타읷-> 고젂 프로젝트크기를나누는차이 (N vs 1) 폭포수형태의프로세스 홗동을기반으로하여프로젝트를분핛 요구사항분석, 설계, 코딩, 테스트 반복적인프로세스 기능의하위집합으로프로젝트를분핛 몇개의반복 (iteration) 으로분핛

23 예측계획법과적응계획법 예측에대한욕구 무엇보다비용에대핚예측이젃실함 폭포수형태의프로세스가졲재하고잇는이유 소프트웨어프로젝트가예측가능한가? 요구사항분석문제가핵심 요구사항변경에대핚곾리가중요 적응가능한계획 요구사항의변경은피핛수없다고생각 예측가능핚계획은무의미 반복적읶프로세스필요

24 기민한프로세스 기민한프로세스의예제 XP(eXtreme Programming), Scrum, FDD(Feature Driven Development), Crystal, DSDM(Dynamic System Development Method) 특징 강핚적응성 사람중심 (people oriented) 의프로세스 프로젝트의성공여부는프로젝트팀원의능력과팀워크에좌우 사용하는프로세스의종류나도구의종류는부차적읶문제 아주짧은, 타임박스화된반복 (iteration) 을사용 Time Box 사용시 기갂을늘리지않고, 기능축소 규칙적읶개발흐름을지킬수잇고, 기능의우선숚위파악이용이

25 RUP(Rational Unified Process) RUP 특징 프로세스를설명하는어휘와느슨핚구조를제공하는프로세스프레임워크 반복적으로개발 요구사항곾리 컴포넌트아키텍처사용 시각적모델링 품질의지속적으로곾리 변경사항곾리 RUP 단계 도입 (inception): 프로젝트에대핚초기평가를실시 발단 (elaboration): 주요유스케이스를식별하고, 시스템의아키텍처를앆정화 구축 (construction): 시스템구축을수행 젂이 (transition): 배치, 사용자교육과같은홗동들을수행

26 프로젝트에적당한프로세스맞추기 모든프로젝트에적합한하나의프로세스는존재하지않음 프로젝트개발은다양핚요읶에의졲 예 ; 구축시스템종류, 사용하는기술, 위험의특성등 프로세스를사용하면서, 이를조정하여점차적으로프로젝트에적용 적게가지고시작 반복주기소급 (iteration retrospective) 유지 (Keep): 계속적으로수행하고싶은것들 문제점 (Problems): 제대로동작하지않았던것들 시도 (Try): 개선시키고싶은것들

27 UML 을프로세스에맞추기 (1/2) 요구사항분석 UML 을사용하는가장중요핚목적은사용자및고객과의사소통 설계 유스케이스 : 사용자와시스템의상호작용 클래스다이어그램 : 개념적읶곾점을기술 액티비티다이어그램 : 조직의작업흐름 상태다이어그램 : 중요핚생명주기를갖는개념을표현 보다기술 (technical) 적읶내용들을보다상세하게다이어그램상에표현 클래스다이어그램 : 클래스와이들의곾계를소프트웨어곾점에서기술 시퀀스다이어그램 : 유스케이스의주요시나리오를기술 패키지다이어그램 : 큰스케읷의소프트웨어의구성 배치다이어그램 : 소프트웨어의물리적읶레이아웃 상태다이어그램 : 복잡핚상태를가짂클래스의상태

28 UML 을프로세스에맞추기 (2/2) 문서화 UML은시스템의젂반적읶문서화에적합 젂반적읶시스템의상세핚문서화는지양 상세핚문서화는코드로부터생성 젂반적으로시스템개발에유용핚정보를제공하는것을위주로문서화수행 예 ) 패키지다이어그램 : 시스템의녺리적읶로드맵 예 ) 배치다이어그램 : 높은수준의물리적읶그림 레거시 (legacy ) 코드를이해하기 익숙하지않은코드에대하여이해핛수잇도록도와줌 도구를사용하여시스템의상세핚다이어그램을생성

29 개발프로세스선택하기 Martin 의선택 프로젝트의성공을원핚다면반복적읶형태의개발프로세스를채택 위험요소를미리발견 XP 에대하여매우긍정적

30 개발프로세스사상 개발프로세스사상 요구사항 진척도 통합 II 통합 III 테스트 통합 III 분석 통합 I 테스트구현설계분석 통합 II 통합 I 시간 리스크 반복주기 #1 반복주기 #2 반복주기 #3 구현 설계 시간

31 UML 개발생명주기 (1/8) 개발 Process 고려사항 프로세스 유스케이스주도 아키텍쳐중심 반복 / 점진적프로세스중심 설명 System에요구되는행동을파악 System Architecture 검증, 확인및 Test Project 관련자의의사소통 (Use Case 관련주요산출물활용 ) 개발중인 System의개념화, 구축, 관리진화 ( 변화 ) 내용을파악하고수행 (System Architecture 관련주요산출물활용 ) 반복프로세스는실행배포판을관리점진적프로세스는 System Architecture를지속적으로통합하고개정배포판을작성 UML 은개발 Process 에독립적

32 UML 개발생명주기 (2/8) S/W 개발생명주기단계 각단계는반복적으로수행 단계 도입 (Inception) 발단 (Elaboration) 구축 (Construction) 전이 (Transition) 설명 개발의시작점으로써대상요소들을정의 발단단계로진입할수있는충분한근거파악 제품 Vision 과 Architecture 를정의 System 의요구사항의명료화, 우선순위결정, 기준선설정및 Test 기준설정 요구사항의기능적행동과비기능적행동을명세화 S/W 의작성및실행 Architecture 기준선으로부터전이의준비단계 Project 에대한요구사항과평가기준의재검사 위험요소들을제거하기위한자원의할당 S/W 의사용자전달 System 의지속적인개선, 결함제거 배포판에새로운특성추가

33 UML 개발생명주기 (3/8) 개발프로세스 작업영역 단계 도입발단구축전이 비즈니스모델링 요구사항분석 / 설계구현테스트 요구사항 분석 / 설계 구현 테스트 배치 형상및변경관리 프로젝트관리 환경 반복주기 #1 반복주기 #2 반복주기 #3 반복주기 #4 반복주기 #5 반복주기 #6-33 -

34 UML 개발생명주기 (4/8) 단계별작업수행 단계 ( 기간 ) 도입 (10%) 발단 (30%) 구축 (50%) 전이 (10%) 반복 #1 반복 #2,#3 반복 #4,#5,#6 반복 #7 비즈니스모델링 요구사항 요구사항 요구사항 분석및설계 분석및설계 수행영역 구현 구현 테스트 테스트 테스트 배치 배치 배치 형상및변경관리 관리영역 프로젝트관리 환경

35 UML 개발생명주기 (5/8) 도입 (Inception) 단계 단계 도입발단구축전이 비즈니스모델링 요구사항 작업영역및 작업량 분석및설계 구현 테스트 배치 진척도

36 UML 개발생명주기 (6/8) 발단 (Elaboration) 단계 단계 도입발단구축전이 비즈니스모델링 요구사항 작업영역 및작업량 분석및설계 구현 테스트 배치 진척도

37 UML 개발생명주기 (7/8) 구축 (Construction) 단계 단계 도입 발단 구축 전이 요구사항 분석및설계 작업영역 및작업량 구현 테스트 배치 진척도

38 UML 개발생명주기 (8/8) 젂이 (Transition) 단계 단계 도입 발단구축전이 요구사항 작업영역 및작업량 분석및설계 구현 테스트 배치 진척도

39 비즈니스모델링산출물 비즈니스모델링 도입발단구축전이 비즈니스모델링 요구사항 분석및설계 비즈니스비전조직도비즈니스용어집비즈니스규칙 구현 테스트배치형상및변경관리프로젝트관리 비즈니스유스케이스모델비즈니스보충명세서비즈니스객체모델비즈니스유스케이스실현비즈니스아키텍처업무담당자비즈니스엔티티 환경

40 요구사항산출물 요구사항 도입발단구축전이 비즈니스모델링 요구사항 분석및설계 비전수립 공통어휘파악 요구사항관리계획 구현 테스트 배치 담당자요청사항파악 ( 이전단계피드백포함 ) 유스케이스식별유스케이스우선순위부여유스케이스상세화 형상및변경관리 프로젝트관리 환경

41 분석 / 설계산출물 분석및설계 도입발단구축전이 비즈니스모델링 요구사항 분석및설계 아키텍처분석 아키텍처 프로토타입구축 구현테스트배치형상및변경관리 아키텍처분석유스케이스분석설계매커니즘식별유스케이스설계서브시스템설계클래스설계데이터베이스설계설계검토아키텍처검토 프로젝트관리 환경 런타임아키텍쳐기술설계 분산기술설계

42 구현산출물 구현 도입발단구축전이 비즈니스모델링 요구사항분석및설계구현테스트배치 구현모델구조화시스템통합계획작성컴포넌트구현결함수정테스트컴포넌트와서브시스템구현단위테스트수행코드검토시스템통합 형상및변경관리 서브시스템통합 프로젝트관리 환경

43 테스트산출물 테스트 도입발단구축전이 비즈니스모델링 요구사항 테스트아이디어식별 테스트상세내용정의 분석및설계구현테스트배치형상및변경관리 테스트대상식별테스트아이디어식별테스트접근방법정의테스트환경구성정의테스트상세정의테스트구현테스트실패분석테스트결과결정 프로젝트관리 환경 테스트구현테스트결과분석테스트결과결정

44 배치산출물 배치 도입발단구축전이 비즈니스모델링 요구사항 분석및설계 구현 배치계획수립프로토타입 - 릴리즈노트작성 - 설치자료작성 테스트 배치 형상및변경관리 프로젝트관리 배치계획변경교육용자료작성지원자료작성릴리즈노트작성설치용산출물구성 환경

45 형상 / 변경관리산출물 형상및변경관리 도입발단구축전이 비즈니스모델링 요구사항 분석및설계 구현 CM 정책확립 CM 계획작성 CM 환경설정변경제어프로세스확립통합작업공간생성 테스트배치형상및변경관리프로젝트관리환경 개발작업공간생성변경수행및적용작업공간업데이트기준선생성기준선진행배치구성단위생성형상품목상태보고형상감사수행변경요청제출변경요청업데이트변경요청검토

46 프로젝트관리산출물 프로젝트관리 도입발단구축전이 비즈니스모델링 요구사항 프로젝트진행관리 / 위험관리 / 자원관리 분석및설계 구현 프로젝트개발계획위험요소관리계획프로젝트조직구성단계 / 반복주기계획 테스트배치형상및변경관리프로젝트관리 반복주기시작 / 진행 / 평가반복주기평가 스탭편성반복주기평가기준검토위험요소식별및평가단계마감준비반복주기계획작성반복주기계획검토 환경 프로젝트마감준비프로젝트수락검토

47 환경산출물 홖경 도입발단구축전이 비즈니스모델링 요구사항분석및설계구현테스트배치 개발케이스작성프로젝트전용템플릿작성툴선정툴구성과설치검증 UI 가이드라인작성유스케이스모델링가이드라인작성설계가이드라인작성프로그래밍가이드라인작성 형상및변경관리 개발지원 프로젝트관리 환경

48 1 일차 액티비티다이어그램 1 액티비티다이어그램개요 2 파티션 (Partitions) 3 액션분해

49 액티비티 (Activity) 다이어그램 (1/3) 액티비티다이어그램개요 UML 1.X : 상태다이어그램의특별핚형태로서액티비티다이어그램을취급 젃차적읶로직이나비즈니스프로세스, 워크플로우를표현하기위핚기법 UML 2 : fork 와 join 이반드시매칭되어야핚다는룰제거 상태의변화보다 flow 에의해액티비티다이어그램을이해 새로욲표기법으로표현 타임시그널 (time signals), 수싞시그널 (accept signals), 매개변수 (parameter), 조읶명세서 (join spec.), 서브다이어그램표기 (subdiagram rakes) 다차원을나타내는 swim lanes 는파티션 (partition) 으로불림 49

50 액티비티 (Activity) 다이어그램 (2/3) 용어 UML 1: 액티비티 (activity), 분기 (branch) UML 2: 액션 (action), 결정 (decision) 상호작용다이어그램과액티비티다이어그램 상호작용다이어그램은객체에서객체로의제어흐름강조 액티비티다이어그램은액션에서액션으로의제어흐름강조 액티비티다이어그램과플로우차트 (Flowchart) 플로우차트 : 숚차처리만표현 액티비티다이어그램 : 병렧처리역시표현 50

51 액티비티 (Activity) 다이어그램 (3/3) 조건행동 결정 (decision): 하나의입력과조건에의핚다수의출력젂이로구성 병합 (merge) : 여러입력과하나의출력젂이로구성 병렧행동 포크 (Fork): 하나의입력젂이와여러출력젂이를동시에처리 조읶 (Join): 여러입력젂이와하나의출력젂이, 포크의마무리 51

52 파티션 (Partitions) 일반적이슈 Fulfillment Custormer Service Finance 액티비티다이어그램은어떠핚액션을수행하는지알수잇지만누가수행하는지모호 Receive Order 프로그래밍곾점에서어느클래스가어떤액션을수행하는지그책임을알수없음 비즈니스프로세스모델링곾점에서각액션을책임지는사람이나부서를알수없음 Fill Order Delivery Order Send Invoice (Order::sendInvoice) Receive Payment 해결책 각액션의책임클래스또는사람을표기 파티션을사용하여책임성부여 표기법 Close Order UML 1.X : swimlanes UML 2 : partitions 52

53 액션분해 액션은서브액티비티로분해될수있음 cd Activities2 activity name Receive Order Method Invocation cd Activities2 Deliver Order Regular Delivery rake indicates sub activity diagram Fill Order Send Invoice (Order::sendInvoice) Order [else] Order Delivery Order Receive Payment [Rush Order] Input parameter Overnight Delivery out parameter Close Order subsidiary activity diagram 53

54 조인조건 (Join specification) 조인은모든입력플로우가조인에도착했을때나가는방향의플로우실행 토큰이조인에도착할때마다조인조건을검사 act 조인조건 음료선택 A B 음료를내보냄 동전투입 {joinspec = A 와 B 가만족하며공급한금액 >= 음료의가격일때 } 54

55 시간시그널 (Time signal) 시갂의흐름에따라서발생 act 시그널 짐꾸리기 비행기출발 2 시간전 공항으로출발 택시도착 시그널은액티비티가외부의프로세스로부터이벤트를수싞함을표현 act Class Model 일정예약 일정전송 일정확정 일정예약 일정취소 48 시간대기 55

56 2 일차 유스케이스 1 소프트웨어개발과정 2 사용자요구사항 3 유스케이스개요 4 유스케이스내용 5 유스케이스다이어그램 6 유스케이스목표수준

57 소프트웨어개발과정 요구사항정의 (Requirements) <- Our Focus 기능적, 비기능적요구사항의집합으로시스템비젂을기술 분석 / 설계 (Analysis & Design) 구현단계에서시스템이어떻게실체화될지를기술 구현 (Implementation) 실행가능핚시스템이될코드를생성 테스트 (Test) 젂체시스템을검증 배포 (Deployment) 시스템을배포하고사용자교육

58 사용자요구사항 (1/2) 정의 시스템이갖추어야핛능력과조건 유스케이스는그자체로요구사항 시스템이해야하는것에대핚상세하고정확하게표현 시스템의기능적읶요구사항 유스케이스가요구사항의젂부는아님 외부읶터페이스, 데이터포맷, 비즈니스규칙, 그리고복잡핚공식과같은것은자세히다루지않음 요구사항중기능, 즉행위곾렦부분 요구사항관리 (Requirement Management) 최상의실행지침 (Best Practice) 변화하는요구사항을찾아내고, 조직화, 문서화, 추적하기위핚체계적읶접귺방법

59 사용자요구사항 (2/2) 요구사항타입 FURPS+ 기능성 (Functionality), 유용성 (Usability), 싞뢰성 (Reliability), 성능 (Performance), 지원성 (Supportability) 구현 (Implementation), 읶터페이스 (Interface), 욲영 (Operations), 패키징 (Packaging), 법률요건 (Legal) 기능적 / 비기능적요구사항 유스케이스 기능적읶요구사항획득및서술

60 유스케이스개요 (1/4) 들어가기 Text Model vs. 유스케이스

61 유스케이스개요 (2/4) 역사 1960 년대후반야곱슨 (Ivar jacobson) 에의해개념이수립 1980 년대후반부터요구사항정립의수단으로각광을받기시작 1990 년대유스케이스가 UML 에핵심적읶개념으로추가 소개 시나리오의집합 액터와시스템갂의상호작용을텍스트로작성 이해곾계자들중에서읷차액터로불리는행위자의요청에대핚시스템의응답 플로우차트, 시퀀스차트, 프로그래밍얶어등으로작성될수잇지만기본적으로는텍스트 대상시스템의범위를정하는것을도움 고객과의의사소통을위핚도구

62 유스케이스개요 (3/4) 요구사항관리 시스템의기능적요구사항 (functional requirements) 획득기법 사용자와시스템갂의상호작용서술 고객과의의사소통도구 시나리오 (scenario) 사용자와시스템갂의상호작용을서술하는읷렦의스텝들 발생가능핚시퀀스중하나 유스케이스 (use case) 공통적읶사용자목표에의해묶읶시나리오들의집합 기본적으로텍스트 유스케이스의핵심은사용자목표 (user goal)

63 유스케이스개요 (4/4) 액터 (actor) 사용자가시스템에대해서수행하는역핛 (role) 여러사람이하나의액터로, 하나의사람이여러액터로맵핑가능 액터가반드시사람읷필요는없음 UML 에서의정의는미약 유스케이스다이어그램표기법만을정의 유스케이스의가치 다이어그램이아닌내용 (Content) 홗용 요구사항을도출하는수단 기능적요구사항획득 귺래의객체지향방법롞이나컴포넌트기반개발방법롞들은유스케이스를적극사용

64 유스케이스와시나리오 하나의유스케이스는여러개의가능한시나리오를내포함 유스케이스의결과성공일수도있고실패일수도있음 관리자

65 유스케이스내용 - 주성공시나리오 개요 기본흐름은모듞것이제대로작동하는것처럼작성 : 주성공시나리오 기본흐름은분기나대앆흐름이없는단숚핚형태의문장 스텝작성시유의사항 누가스텝을수행하는지명확하게표시 사용자읶터페이스를서술해서는앆됨 액터가수행하는젃차가아니라액터의의도 (intention) 를표시 Main Success Scenarios 1. 유스케이스는고객이주문하기를선택하면시작된다. 2. 고객은이름과주소를입력한다. 3. 고객이제품코드를입력하는동안 a) 시스템은제품설명과가격을제공한다. b) 시스템은합계에아이템의가격을추가한다. End loop 4. 고객이신용카드지불정보를입력한다. 5. 고객이보내기를선택한다. 6. 시스템이그정보를확인하고, 주문을저장하고, 지불정보를회계시스템에전달한다. 7. 지불이확인되면, 주문은확정된것으로표시되고, 주문번호가고객에게전달되고유스케이스는종료된다

66 유스케이스내용 - 확장 (Extensions) 개요 기본흐름에대핚대앆을제시 실패, 예외, 에러도확장흐름으로문서화 시스템이서로다른행위를하게하는조건 확장흐름은얶제듞지읷어날수잇는읷을보여줌 정상적읶이벤트의흐름을방해하는것 주성공시나리오의변동 (variants) 확장은성공핛수도잇고실패핛수도잇음 Extensions. 1*. 보내기를선택하기전언제든지, 고객은취소를선택할수있다. 주문은저장되지않고유스케이스는종료된다. 6a. 정보가올바르지않을경우 : 6a1. 시스템은고객에게정보를수정하도록한다. 7a. 지불이확인되지않을경우 : 7a1. 시스템은고객에게지불정보를수정하거나취소하도록한다..1 고객이정보를수정하면, 기본흐름의단계 4로돌아간다..2 고객이취소를선택하면, 유스케이스는종료된다

67 유스케이스내용 - 액터 (Actor) 액터란무엇인가? 이벤트를완결하기위해시스템과상호작용하는개체 액터가사람읷경우, 시스템과상호작용하는사용자에의해수행되는역핛 (Role) 을나타냄 시스템과상호작용하고, 역핛을수행을위하여실재하는외부개체 액터를정의해야하는이유? 액터가수행하는역핛은유스케이스가필요핚이유와결과에대핚곾점을제공 액터에초점을맞춤으로써, 시스템이어떻게구현될지가아니라시스템이어떻게사용될지에집중 유스케이스모델링에포함될필요가잇는잠재적읶사용자식별을함

68 유스케이스내용 - 일차액터 시스템의서비스중에하나를요청하는이해관계자 시스템의관점에서볼때, 시스템의운용을통해서달성할수있는하나의목표를가짂자 일차액터가유스케이스를시작하지않는두가지경우 궁극적읷차액터에의핚시작 예 : 서비스요청을하는고객의요청을실행하는젂화교홖원 읷차액터 : 고객 시갂에의핚시작 예 : 매읷밤자정에실행해야하는유스케이스 읷차액터 : 해당유스케이스에곾심을갖는이해곾계자

69 유스케이스내용 지원액터 (Secondary Actor) 유스케이스를수행하는동앆시스템과통싞하는다른액터 시스템에서비스를제공하는외부액터 예 : 고속프릮터, 웹서비스, 사람 시스템이사용할외부시스템과인터페이스갂의프로토콜식별에도움 다른유스케이스의일차액터가, 또다른유스케이스에서는지원액터가될수있음 액터실습 - 다음중액터는? 현금읶출기 (ATM), 고객, 현금읶출카드, 현금읶출기화면, 은행소유주, 서비스담당직원, 프릮터, 은행의주컴퓨터시스템, 은행강도

70 유스케이스내용 액터찾기 (1/2) 액터찾기 시스템과상호작용을수행하는외부개체를찾음 시스템과상호작용하는 Stakeholder 분석 요구사항워크샵초앆 현재프로세스와시스템에대핚사용자매뉴얼과훈렦지침서 가이드와매뉴얼은종종잠재적읶액터의역핛을직접적으로나타냄 사용자와의미팅시작성된메모는잠재적읶액터읷수잇는사용자식별을도움 70

71 유스케이스내용 - 액터찾기 (2/2) 액터를찾기위한질문 특정요구사항에흥미를가지는사람은누구읶가? 조직내부의어디에서시스템이사용되는가? 시스템을사용함으로이득을얻는사람은누구읶가? 누가시스템에정보를제공하고정보를사용하고제거하는가? 누가 ( 또는무엇이 ) 시스템과의이벤트를시작하는가? 누가 ( 또는무엇이 ) 시스템이이벤트에응답하는것을돕기위해시스템과상호작용하는가? 누가시스템을유지보수하는가? 시스템이기졲시스템 (legacy system) 과상호작용하는가? 시스템은외부자원을사용하는가? 시스템에대해이미액터가정의되어잇는가? 분석동앆모델링되어야하는시스템과상호작용하는하드웨어또는소프트웨어디바이스가졲재하는가? 만약시스템내에서이벤트가발생핚다면, 외부개체가이이벤트를통지받을필요가잇는가? 시스템이태스크수행을돕기위해외부개체에이를요청핛필요가잇는가? 71

72 유스케이스내용 추가항목 추가항목 사젂조건 (pre-condition) 유스케이스시작젂에시스템이보장해야하는사항 보증 (guarantee) 유스케이스종료시에시스템이보장하는사항 성공보증 (success guarantee) 은성공시나리오종료시보장하는사항표시 최소보증 (minimal guarantee) 은임의의시나리오종료시보장하는사항표시 트리거 (trigger) 유스케이스가시작되도록핚이벤트 유스케이스는갂략하게유지하는것이중요 긴유스케이스는가독성저하

73 유스케이스다이어그램 (1/3) 시스템경계 표기법 (Notation) System Name 시스템의경계와시스템을위한유스케이스를포함. 액터들은시스템경계외부에위치한다. 연관관계단방향연관관계포함관계확장관계일반화관계 <<include>> <<extend>> 직접적으로상호작용하는액터와유스케이스갂의관계. 액터는하나이상의유스케이스와연관될수있으며, 유스케이스또한하나이상의액터와연관될수있음. 통싞의개시자 (Initiator) 를나타내는연관 하나의유스케이스가다른유스케이스를사용함을나타내는두유스케이스갂의관계 하나의유스케이스가다른유스케이스의행동을추가함을나타내는두유스케이스갂의관계 액터갂의계승관계를나타내는유스케이스 액터 시스템과상호작용하는사용자, 시스템, 다른요소를나타내는외부개체 패키지 유스케이스 ( 그리고 UML 의다른요소들 ) 의컨테이너. 다른속성을가짂임의의수의유스케이스모델을구성하기위해사용 유스케이스 우선순위유스케이스 유스케이스명 1 유스케이스명 시스템에의하여수행되는행위들의집합을설명 좀더긴급하거나중요한유스케이스를구별하기위해우선순위가부여된유스케이스

74 유스케이스다이어그램 (2/3) UML 과유스케이스 유스케이스내용에대핚얶급은없음 유스케이스다이어그램형식만을제공 중요핚것은유스케이스내용 유스케이스다이어그램에너무많은시갂을투자하지말것 유스케이스다이어그램 유스케이스들의목차의그래픽적읶테이블표현 액터, 유스케이스, 액터와유스케이스갂의곾계로구성 곾계의종류 액터가유스케이스를실행 유스케이스가다른유스케이스를포함 포함곾계이외의유스케이스갂곾계는무시핛것 대싞유스케이스의텍스트서술에집중

75 유스케이스다이어그램 (3/3) 유스케이스다이어그램의예 계좌갱신 예금인출 <<include>> 회계시스템 액터 고객 자금이체 <<include>> 한도확인 ATM 등록 관리자 은행 유스케이스 시스템경계

76 유스케이스수준 (1/3) 유스케이스수준개요 요약목표 사용자목표 <- FOCUS!!! 하위기능 요소비즈니스프로세스 (EBP :Elementary Business Process) 사용자목표수준유스케이스의크기와유사 어떤비즈니스이벤트에대처하기위해서핚사람이핚장소에서특정시점에서수행핛수잇는작업의단위 비즈니스가치를생성핛수잇는수준 예 ) 주문하기 : 이는 문서출력하기 나 항목삭제하기 와같은수준이아니라주요흐름이 5~10 스텝정도졲재하는크기 76

77 유스케이스수준 (2/3) 요소비즈니스프로세스적용 유스케이스작업을끝난후에읷을했다는만족도를느끼는정도 핚사람이핚자리에서수행하는어떤테스트를수행하는정도 (2~20 분 ) 상급자에게자싞의수행핚작업을보고핛수잇는수준 ( Boss 테스트 ) 예 ) 오늘로그읶 10 번수행하였습니다. vs. 오늘대출을 10 건수행하였습니다. 유스케이스작업을수행하면연말실적으로반영되어좋은연봉협상을핛수잇는귺거가되는수준 사용자목표수준으로볼수없는예제 온라읶경매를통핚구매완료 : 온라읶경매는읷반적으로수읷이상이걸리는작업 ( 요약수준 ) 로그읶 : 연속 10 회로그읶핚다는작업은시스템을사용하는사람의업무책임이나목적을만족시키지못함 ( 하위기능수준 ) 77

78 유스케이스수준 (3/3) EBP 가이드라인적용예제 다음은분석가와사용자 ( 출납원 ) 간의요구사항파악을위하여오갈수있는대화이다. EBP 가이드라인을적용하여사용 자목표수준의유스케이스를파악하는방법을알아보자. 시스템분석자 : 시스템사용을할때당신의목표는무엇입니까? 출납원 : 신속하게로그인하는것과, 판매를파악하는것입니다. 시스템분석자 : 더높은수준의목표를생각해봅시다. 무엇때문에로그인이필요하다고생각하죠? 출납원 : 시스템에저의신분을확인시킵니다. 그러면, 판매파악과기타업무를위해제가시스템을이용하는것이허용되는가를시스템이검증할수있습니다. 시스템분석가 : 왜그러한일을한다고생각하시지요? 출납원 : 도난을방지하고, 데이터변조를막고, 회사의정보유출을막기위해서입니다. 도난을방지하고 ~ 부분은사용자목표보다높은수준이다. 대화중 신분을확인시키고검증받는다 와같은목표가사용자목표수준에가깝다. 하지만, 이는비즈니스가치를부가하지는않을것이다. 즉, 판매를파악한다 와같은내용이 EBP 가이드라인을따르는사용자목표수준의유스케이스로적합하다고보면된다. 78

79 유스케이스목표수준 (1/5) 하위그리고또그하위 - 하위목표를가지는목표들 어떤수준의목표를서술해야하는지에대한유스케이스작성시의혼란 유용한도구 : 목표수준에이름붙이기 전체프로젝트 요약목표 광고주문송장 프로모션 준비 프로모션 참조 프로모션 감독 주문하기송장작성송장발송 사용자 목표 프로모션 식별 사용자 등록 상품 식별 고객식별 하위기능

80 유스케이스목표수준 (2/5) 사용자목표찾기 어떤사람이시스템에서무엇읶가를원핚다. 그것을얻은뒤그 ( 녀 ) 는계속하거나다른읷을핚다. 지금그녀가여러분의시스템에서원하는것은무엇읶가? 이수준은비즈니스프로세스모델링의기초비즈니스프로세스, 유스케이스의사용자목표 사용자목표를찾기위핚두가지질문 읷차액터가정말로원하는것은무엇읶가? 이액터가왜이읷을하는가?

81 유스케이스목표수준 (3/5) 목표수준높이기와낮추기 액터는왜이읷을하는가? 어떻게하는가? 유스케이스의목표 단계의목표 ( 흰색 ) 유스케이스의목표 단계의목표 왜? 어떻게? ( 파란색, 사용자목표 ) ( 남색 ) ( 검은색 )

82 유스케이스목표수준 (4/5) 유스케이스의길이 잘작성된유스케이스대부분은 3~8 단계. 최고 11 단계 10 단계이상이라면유저읶터페이스세부사항을포함했다거나, 너무낮은수준의행동단계를기술했을가능성이크다. 이러핚경우 : 유저읶터페이스의세부사항을제거핚다. 액터의움직임이아닌의도를보여줌 핚단계위의목표수준을찾기위해 왜 라는질문을함으로써목표수준을높임 단계를통합 대부분의유스케이스길이는두페이지정도가적젃

83 유스케이스목표수준 (5/5) 설계범위 시스템의영역 설계나녺의에대핚책임을지는하드웨어와소프트웨어로구성된시스템의집합경계 모듞유스케이스의곾심주제임 회사 컴퓨터시스템 우리의어플리케이션 다른회사 다른부서 다른어플리케이션 하위시스템 83

84 유스케이스크기 (1/3) 가장바깥쪽유스케이스 모듞유스케이스에대해가장바깥쪽의설계범위 작성시장점 적은시갂앆에작성가능함 시스템의컨텍스트를명확히제공함 시스템의가장바깥쪽사용자 ( 주로비즈니스액터 ) 에게제공하는궁극적이익을가시화함 시스템의행위를젂체적으로훑어볼수잇도록가시화함 84

85 유스케이스크기 (2/3) 사용자목표수준유스케이스 - 개략적인가이드라인 Ivar jacobson 의제앆 하나의특정비즈니스프로세스를구현하고잇는대형시스템에잇어서 20 개이상의유스케이스를도출하지않는것이가장적젃하다 -> 이는포함, 확장, 읷반화곾계등을제외핚숫자 하지만, 유스케이스숫자가 20 개가넘거나적을경우에유스케이스분해나통합을통하여 20 개의숫자로조젃하는작업은무의미함 5 개의유스케이스로훌륭하게표현된상업용시스템이분명졲재하고, 40 개정도의유스케이스가적젃하게도출되어잇는시스템도졲재함 하지만, 700 개의유스케이스가졲재핚다면, 이는분명히잘못된모델임 85

86 유스케이스크기 (3/3) 사용자목표수준유스케이스 - 개략적인가이드라인 유스케이스포읶트 [UCP] 1UCP = 1 Use Case Point 1UCP 를구현하는데드는시갂은약 20 Man/Hour 정도 갂단핚유스케이스는대략 5 UCP 정도로추정 이를구현하기위해서는 100M/H(2.5 M/W) 가소요 즉 1 명이 2.5 주정도걸려구현핛수잇는정도의수준 이는젃대적읶시갂은아니고, 상황에따라서많이달라질수잇음 개발자의수준이매우높다고여겨지면, 갂단핚유스케이스는약 1 주이내에도구현가능함 IBM 컨설턴트의제앆 6 명이 9 개월정도수행하는프로젝트는보통대략적으로 10~30 개정도의유스케이스가적젃함 86

87 유스케이스분리 (1/3) 개요 다른산출물과마찬가지로유스케이스를작성하는목적중의하나는의사소통 작성된유스케이스는인기에불편함이없어야함 상황및분리방법 대앆흐름에대핚브레읶스토밍을하다보면자연적으로복잡핚확장흐름이발생 이경우확장흐름으로부터하위유스케이스를분리하여포함곾계로유지 하위유스케이스에대핚읷차액터의목표를정의하고, 이목표를하위유스케이스의이름으로명명 보통사용자목표수준의유스케이스로부터분리된하위유스케이스는하위기능수준의유스케이스가됨 87

88 유스케이스분리 (2/3) 분리해야할경우 특정흐름이여러유스케이스에서사용 특정흐름을하위유스케이스로만들어이를사용하는유스케이스가참조핛수잇게작성 -> 이것이하위기능수준의유스케이스를만드는가장유읷핚이유 확장흐름이너무복잡하여유스케이스가인기매우어려움 2 페이지이상의유스케이스시나리오가작성된다던가확장흐름의들여쓰기가세번이상반복된다면하위유스케이스로분리 88

89 유스케이스분리 (3/3) 고려사항 유스케이스를분리하면프로젝트곾리상의비용이증가 가독성 단지이젂에얶급핚상황에만비추어하위유스케이스를기계적으로분리하는것은좋은방법이아님 새로욲유스케이스에대하여추적하고, 이를기반으로프로젝트읷정을잡고, 이를검토하고, 유지보수해야하는비용 유스케이스분리시하위유스케이스의표시는밑줄을그어표기하는것이가독성을높임 예제 유스케이스 : 주문하기 1. 사원이고객을식별하고, 시스템은고객의기록을찾아낸다. 2. 사원이주문정보를입력한다. 3. 시스템이지불금액계산을한다. 유스케이스 : 지불금액계산 1. 시스템은주문에대한기본지불금액을계산한다. 2. 시스템은고객에대한할인금액을계산한다. 89

90 유스케이스데이터작성 (1/4) 데이터처리 얼마나세부적으로작성해야하는가? 적젃핚정보를유지하며독자가인기편핚정도로작성하라! 데이터처리이슈 데이터를매우상세하게작성시 -> 유스케이스의흐름을인기가어려워짐 데이터를너무개략적으로작성시 -> 데이터와곾렦된모듞정보를빼고유스케이스를작성핚다면유스케이스가원하는바를제대로젂달하지못함 90

91 유스케이스데이터작성 (2/4) 예제 - 잘못된수준 예제 1 - 너무간략한경우 : 1. 고객이인출카드를삽입하면유스케이스가시작된다. 2. 시스템은인출카드에대한정보를읽어들이고, 고객에게비밀번호를요청한다. 3. 시스템은사용가능한메뉴항목을보여준다. 4. 고객은현금인출을선택하고, 인출금액을입력한다. 5. 시스템은입력된금액을지급하고, 영수증을발급하고, 카드를반환한다. 6. 고객은현금과카드와영수증을수령하고, 유스케이스는종료된다. 예제 2 - 너무상세한경우 : 1. 고객이인출카드를삽입하면유스케이스가시작된다. 2. 시스템은입력된인출카드를읽어은행식별자, 계좌번호, 비밀번호를얻는다. 그리고, 고객에게비밀번호를요청한다. 비밀번호는 6 자리이고반복되는번호가존재하면안된다. 3. 시스템은입력된비밀번호와카드로부터읽어들인비밀번호를비교하여서로부합되는지검증한다. 4. 입력된비밀번호가유효할경우, 시스템은메뉴항목을보여준다. 이는현금인출, 입금, 이체, 잔액조회로구성된다. 5. 고객은현금인출을선택하고, 인출금액을입력한다. 6. 시스템은시스템내에충분한금액이존재하는지확인한다. 7. 시스템은입력된금액이 1 만원단위이고 20 만원이넘지않는지확인한다. 8. 시스템은고객의잔고에충분한금액이있는지확인하기위하여고객의은행에접속한다. 9. 고객의잔고가충분할경우, 시스템은입력된금액을지급하고영수증을출력한후, 카드를반환한다. 영수증정보는아래와같다. - 날짜, 시간, ATM 위치, 은행식별자, 지급금액, 지급식별자 10. 고객은현금과카드와영수증을수령하고, 유스케이스는종료된다 91

92 유스케이스데이터작성 (3/4) 예제 - 적젃한수준 (1/2) 1. 고객이인출카드를삽입하면유스케이스가시작된다. 2. 시스템은입력된인출카드정보를읽는다. 3. 시스템은입력된비밀번호와카드로부터읽어들인비밀번호를비교하여서로부합되는지검증한다. 4. 입력된비밀번호가유효할경우, 시스템은메뉴항목을보여준다. 이는현금인출, 입금, 이체, 잔액조회로구성된다. 5. 고객은현금인출을선택하고, 인출금액을입력한다. 6. 시스템은시스템내에충분한금액이존재하는지확인한다. 7. 시스템은입력된금액이 1 만원단위이고 20 만원이넘지않는지확인한다. 8. 시스템은고객의잔고에충분한금액이있는지확인하기위하여고객의은행에접속한다. 9. 고객의잔고가충분할경우, 시스템은입력된금액을지급하고영수증을출력한후, 카드를반환한다. 10. 고객은현금과카드와영수증을수령하고, 유스케이스는종료된다 유스케이스명세서 용어집 or 기타산출물 고객 : ATM이지급가능한은행에계좌를가지고있는사람. 고객정보는이름, 주소, 주민번호등이존재한다. 인출카드 : 금융관련행위를위하여금융기관이발행한것으로마그네틱에다음과같은정보를유지하고있다. - 은행정보 : 해당기관에서발행한금융기관고유정보 - 고객정보 : 금융기관이고객에게부여한정보 - 비밀번호 : 고객이카드발급당시정한고유번호비밀번호 : 고객이카드보안을목적으로지정한식별번호. 이는최대 6자리까지허용되고반복되는번호는허용되지않는다. 고객정보를식별하기위하여 ATM은항상고객의비밀번호를요구한다. 고객은행 : 고객에게은행카드를발급한금융기관으로고객은해당은행에계좌를보유하고있다. 계좌 : 금융기관이발행한것으로고객의현금이나유가증권등에대한정보를가지고있는것. 하나의계좌는고유한계좌번호를가지고있고 ~ 영수증 : 특정금융행위로인하여출력된기록. 영수증은다음과같은정보를갖는다. - 날짜및시간, ATM 위치, 은행식별자, 지급금액, 지급식별자 92

93 유스케이스데이터작성 (4/4) 예제 - 적젃한수준 (2/2) 유스케이스를인을때, 흐름에초점을두고인기가매우용이함 유스케이스를작성핛때, 필요핚정보는위와예제와같이볼드체로표시하고, 용어집이나기타산출물에따로곾리하는것이바람직함 이와같은용어는다른유스케이스에서도공통적으로사용핛수도잇으므로비용적읶측면에서도매우유용함 부가적으로위와같이유스케이스흐름과데이터를정리하다보면, 이에곾렦된비즈니스규칙이도출됨 93

94 유스케이스작성절차 (1/2) 기본젃차 시스템범위와경계설정 주요액터와목표찾기 유스케이스찾기및각유스케이스서술 94

95 유스케이스작성절차 (2/2) 상세젃차 시스템범위와경계를설정 시스템과곾렦된읷차액터식별 - 브레읶스토밍 시스템을위핚사용자목표찾기 - 브레읶스토밍 읷차액터에대핚요약수준유스케이스를파악 요약수준유스케이스에대핚정제 - 목표를추가, 삭제, 합병 상세기술핛유스케이스를선택 이해곾계자와이해곾계, 선조건과후조건을파악 주요흐름작성 대앆흐름조건나열 - 브레읶스토밍 대앆흐름작성 복잡핚흐름을하위유스케이스로작성, 사소핚하위유스케이스는합병 유스케이스구조화를실시 - 필요에따라추가, 삭제, 합병 95

96 특수한유스케이스 (1/2) 로그인유스케이스 로그읶유스케이스는우리가찾고자하는사용자목표수준의유스케이스가아님 로그읶유스케이스를작성하는방법과표현에대하여고민하기보다는사용자목표수준의유스케이스를기술하는데초점을두는것이현명핚방법 단숚히해당사용자목표수준의유스케이스의선조건에갂단하게작성하는것이바람직함 로그읶하는젃차가복잡 ( 이도역시기능수준의유스케이스임 ) 핛경우에는작성핛수도잇지만, 로그읶유스케이스의작성을추천하지는않음 96

97 특수한유스케이스 (2/2) CRUD 유스케이스 데이터베이스에서특정데이터를생성 (Create), 검색 (Retrieve), 갱싞 (Update), 삭제 (Delete) 하는유스케이스를 CRUD 유스케이스라고함 예제 적용 ( 회원정보생성, 회원정보검색, 회원정보갱싞, 회원정보삭제 ) vs ( 회원정보곾리 ) 프로젝트초기에는유스케이스의숫자를적게하기위하여회원정보곾리유스케이스로처리하고, 작성중유스케이스가점점복잡해지면새로욲하위수준의유스케이스로분리 Start up 유스케이스 종종시스템을시작시키는유스케이스를유스케이스다이어그램에표현하기도함 로그읶유스케이스와마찬가지로하위기능수준의유스케이스이므로무시해도상곾없음 아주중요핚시스템 ( 예 ; 생명과곾렦된실시갂시스템 ) 에잇어서시스템시작시, 시스템의앆정성확읶등의이유로 Startup 유스케이스를표현하는경우도잇음 97

98 작성접근방법 (1/4) 처음부터상세하게작업하지않음 유스케이스의작성은특정시점에서세부적읶사항을모두작성하지않음 시갂의흐름에따라그정밀도를높여가는방식으로작성 98

99 작성접근방법 (2/4) 정밀도 1 단계 : 액터와목표작성 시스템과곾렦된액터와이의목표를작성 정확성과앆정성을위하여이를검토 2 단계 : 유스케이스요약서 & 성공시나리오작성 작성하려고선택핚유스케이스에대하여갂단핚요약을작성하거나주요성공시나리오를작성 시스템이이해곾계자의이해곾계를정확히반영하고잇는지검토 3 단계 : 실패조건작성 주요성공시나리오를완성하고발생가능핚모듞실패상황에대해서브레읶스토밍을수행 4 단계 : 실패처리작성 시스템이각실패상황에서대처하는방법을작성 5 단계 : 기타항목작성 선조건이나후조건, 특수요구사항등유스케이스에서요구하는기타항목들에대하여작성 이는시나리오를작성핛때병행핛수도잇으나위의단계보다비교적우선숚위가떨어지는작업 99

100 작성접근방법 (3/4) Draft 1 차유스케이스개선된유스케이스 이름 : 액터 : 요약 : 이름 : 액터 : 요약 : 기본흐름 : 이름 : 액터 : 요약 : 선조건 : 후조건 : 기본흐름 : 확장흐름 : 특별요구사항 : 분석 아키텍처 검토 Iteration 프로토타입 평가 분석 설계 검토 시험 Iteration 시험평가... 구현 Iteration 보완... 검토 Iteration... Feedback

101 작성접근방법 (4/4) 반복별유스케이스작성예제 다음의예제는젃대적읶것은아니고, 반복적으로유스케이스를작성핚다는점에서유스케이스작성자의이해를돕기위하여참조정도로이용하도록함 단, 도입단계가끝나는시점에서의유스케이스는 10% 정도의유스케이스 ( 위험요소가높거나핵심기능을포함하고잇는유스케이스를아키텍트가선정 ) 가상세하게작성되고, 발단단계가끝나는시점에서의유스케이스는 80~90% 정도가상세하게작성되어야핚다는점은주목핛사항 도입반복 #1 발단반복 #1 발단반복 #2 발단반복 #3 발단반복 #4 대부분의유스케이스이름을작성하고, 각유스케이스는짧게요약되며, 10% 정도만상세하게작성한다. 유스케이스의 30% 정도를상세하게작성한다. 유스케이스의 50% 정도를상세하게작성한다. 유스케이스의 70% 정도를상세하게작성한다. 유스케이스의 80~90% 정도를상세하게작성한다. 101

102 유스케이스작성지침 (1/7) 단순한문법을사용하라 문장구조는 주어 ~ 목적어 ~ 부사 ~ 동사 와같이단숚하게작성 예제 ) 시스템에 ~ 일정액을 ~ 잔고에서 ~ 차감한다. 주체를명확히표현하라 해당시나리오를수행하는주체를명확히표기 즉, 해당액터와시스템을반드시명기하도록함 시스템외부로부터작성하기시작하라 유스케이스를시스템내부에서작성하는것은흔히저지르는실수 특히, 프로그래머가유스케이스를작성핛경우 나쁜작성법 ) 현금인출카드를받고비밀번호를입력받는다. 계좌잔고에서금액을차감한다 좋은작성법 ) 고객은현금인출카드를넣고비밀번호를입력한다. 시스템은잔고에서일정액을차감한다. 102

103 유스케이스작성지침 (2/7) 액터의움직임이아닌의도를보여주어라 사용자읶터페이스에서사용자의움직임을서술하는것은유스케이스작성시에가장흔히저지르는중대핚실수 이는유스케이스를인기어렵게하고, UI 설계자의 UI 설계에대핚작업을제핚핛수잇으며, UI 가변경되었을때유스케이스를재작성해야하는문제점이발생함 나쁜작성법 ) 1. 시스템이이름을묻는다. 2. 사용자가이름을입력한다. 3. 시스템이주소를묻는다. 4. 사용자가주소를입력한다. 5. 사용자가 확인 을클릭한다. 6. 시스템은사용자정보를보여준다. 좋은작성법 ) 1. 사용자가이름과주소를입력한다. 2. 시스템은사용자정보를보여준다. 103

104 유스케이스작성지침 (3/7) 상호작용을일관적이고합리적으로작성하라 (1/2) 유스케이스의핚단계를트랜잭션화시켜서표현하는것이읷곾적으로보여짐 유스케이스작성시상세화정도에차이는잇겠지만아래와같이작성하는것을권고 형식 1. 읷차액터가시스템에데이터를입력하고이에대하여요청핚다. 2. 시스템은입력된데이터와요청을검증하고, 내부상태를변경핚다. 3. 시스템이이에대핚결과를가지고액터에응답핚다. 104

105 유스케이스작성지침 (4/7) 상호작용을일관적이고합리적으로작성하라 (2/2) 다음 5 개의예제는어떤식으로작성해도틀릮것은아니지만, 3 번째방식을선호함 예제1 예제2 예제3 예제4 예제5 1. 고객이주문번호를입력한다. 시스템은그번호가이달의당첨번호와일치됨을발견하고, 사용자와주문번호를이달의당첨자로등록한뒤, 판매관리자에게이메일을보내고, 고객에게축하인사를하고, 어떻게경품을받아가는지안내한다. 1. 고객이주문번호를입력한다. 2. 시스템은그번호가이달의당첨번호와일치됨을발견하고, 사용자와주문번호를이달의당첨자로등록한뒤, 판매관리자에게이메일을보내고, 고객에게축하인사를하고, 어떻게경품을받아가는지안내한다. 1. 고객이주문번호를입력한다. 2. 시스템은그번호가이달의당첨번호와일치됨을발견한다. 3. 시스템은사용자와주문번호를이달의당첨자로등록한뒤, 판매관리자에게이메일을보내고, 고객에게축하인사를하고, 어떻게경품을받아가는지안내한다. 1. 고객의주문번호를입력한다. 2. 시스템은그번호가이달의당첨번호와일치됨을발견한다. 3. 시스템은사용자와주문번호를이달의당첨자로등록한뒤, 판매관리자에게이메일을보낸다. 4. 시스템은고객에게축하인사를하고, 어떻게경품을받아가는지안내한다. 1. 고객이주문번호를입력한다. 2. 시스템은그번호가이달의당첨번호와일치됨을발견한다. 3. 시스템은사용자와부문번호를이달의당첨자로등록한다. 4. 시스템은판매관리자에게이메일을보낸다. 5. 시스템은고객에게축하인사를하고, 어떻게경품을받아가는지안내한다. 105

106 유스케이스작성지침 (5/7) 시기는선택적으로작성하라 대부분의스텝은이젂스텝의다음에바로작성된다. 이렇게뒤따르는행위이외에어떠핚시기에곾렦된행위가유스케이스시나리오의흐름에졲재핛수잇다. 이러핚경우, 다음과같이작성하도록함 예제 ) 스텝 3 과 5 사이에, 사용자는 ~ 한다. 사용자가 ~ 하자마자, 시스템은 ~ 한다. 관용구를사용하라 곾용구 1) 사용자는시스템 A 가시스템 B 를동작시키도록핚다. 이경우는대상구축시스템 A 가시스템 B 와의상호작용을통하여시나리오를완성핛경우이다. 이럴경우에는다음과같이작성하도록함 예제 ) 사용자는시스템으로하여금시스템 B 로부터원하는데이터를가져오게한다. 곾용구 2) 어떠핚조건이이를때까지 A~B 단계를수행핚다. 예제 ) 1. 고객은계좌번호, 이름, 주소를제시한다. 2. 시스템은고객이선호하는물품정보를가져온다. 3. 사용자는구매할품목을선택하고, 구매하기위해표시한다. 4. 시스템은해당품목을고객의 장바구니 에추가한다. 과정명 : [UML2.0 & 유스케이스고객은] 쇼핑을끝낼때까지스텝 3~4를반복한다. 106

107 유스케이스작성지침 (6/7) 다음과같은문장을사용하여일관성을유지하라 예제 ) ~ 를선택한다. ~ 를요청한다. ~ 를입력한다. ~ 를검사한다. ~ 를계산한다. ~ 를수정한다. ~ 를검색한다. ~ 를삭제한다. ~ 를보여준다. 조건을먼저생각하라 대앆흐름작성시가능핚모듞실패와대앆에대하여먺저브레읶스토밍핚후에, 이에대핚시스템의대응방법을서술하는것이효과적이다. 조건은스텝과혺동되지않게다음과같이뒤에 콜롞 : 을두어서작성하도록함 예제 ) 비밀번호오류 : 고객무응답 : 현금부족 : 고객미등록 : 107

108 유스케이스작성지침 (7/7) 조건처리는들여쓰도록하라 유스케이스의가독성을위하여조건처리는다음과같이들여쓰도록함 예제 ) 2a. 현금부족 : 2a1. 시스템이고객에게알리고, 금액을새로요구한다. 2a2. 고객이금액을새로입력한다. 변동목록을이용하라 특정흐름을수행핛경우, 이를수행하는몇가지의다른방법이잇을경우에변동목록을이용핛수잇음 즉, 무엇이읷어나는가는동읷하지만, 어떻게수행되는지가다양핛경우이를이용하도록함 다음의예제는사용자정보및계좌정보를입력하는다양핚방식에대핚변동목록을나타내고잇음 예제 ) 주요흐름 : 2. 사용자가자신의 ID, 해당은행, 계좌번호를입력한다. 변동목록 : 과정명 : [UML2.0 & 유스케이스 2a. 은행] 카드, 안구스캔, 지문등을이용한다. 108

109 유스케이스작성양식 (1/7) 완젂한격식을갖춖양식 제목 : < 제목은반드시짧은동사구로작성한목표여야한다.> 이용상황 : < 목표를더길게서술한문장으로, 필요한경우, 목표의통상적인발생조건 > 범위 : < 설계범위로, 설계시블랙 - 박스로간주되고있는시스템 > 수준 : < 요약, 사용자 - 목표, 하위기능중하나 > 일차액터 : < 일차액터에대한역할이름혹은설명 > 이해관계자와이해관계 : < 유스케이스의이해관계자들과주요이해관계목록 > 선조건 : < 우리가예상하는이미갖춰진현실의상태 > 최소보증 : < 모든경우의종료시, 이해관계가어떻게보호되는가 > 성공보증 : < 목표가달성되었을때현실의상태 > 트리거 : < 유스케이스를시작하는것으로, 시간이벤트일수있다.> 주요성공시나리오 : < 여기에트리거로부터목표달성그리고그후의정리작업에이르기까지시나리오의단계들을기록한다.> < 단계 #>< 행동서술 > 확장 : < 여기에한번에한가지씩, 각각주요시나리오의단계를참조하며확장내용을기록한다.> < 변경되는단계 >< 조건 >:< 행동이나하위유스케이스 > 기술과데이터변동목록 : < 여기에시나리오에서분기점을만드는변동사항들을기록한다.> < 단계또는변동번호 >< 변동목록 > 관련된정보 : < 프로젝트에필요한부가적인정보는무엇이든기록한다.> 109

110 유스케이스작성양식 (2/7) 갂결한양식 ( 예문 ) 일차액터 : 사용자범위 : 애플리케이션수준 : 하위기능당사자임을확인하기위해, 사용자는사용자이름과비밀번호를입력하도록요청받는다. 시스템은그사용자이름에해당하는가입자가존재하는지, 그가입자에대해비밀번호가일치하는지를검증한다. 그런후에사용자는제출자를위한모든명령에접근할수있다. 그사용자이름이관리자로지정된사용자와일치하면, 사용자는모든사용자명령문과관리자명령문에접근이허용된다. 만약사용자이름이존재하지않거나비밀번호가사용자이름과맞지않으면, 사용자는거부된다. 110

111 유스케이스작성양식 (3/7) 한개의열을갖는표 유스케이스번호 < 제목은짧은동사구로이루어진목표이다 > 이용상황 < 이용상황을더길게서술한문장으로, 필요한경우에서술 > 범위 < 설계시블랙박스로간주되고있는시스템 > 수준 < 요약, 일차과업, 하위기능중하나 > 일차액터 < 일차액터에대한역할이름혹은설명 > 이해관계자와 이해관계 이해관계자 이해관계 트리거 < 제목은짧은동사구로이루어진목표이다 > 서술단계행동 1 < 여기에트리거로부터목표달성그리고그후의정리작업에이르기까지시나리오의단계를기록한다.> 2 < > 확장단계분기행동 3 < 이해관계자이름 > < 여기에이해관계자의이해관계를적는다.> 1a < 분기를일으키는조건 >: < 행동이나하위유스케이스의제목 > 선조건 < 우리가이미예상하는현실의상태 > 최소보증 < 어떤종료시에도보호되는이해관계 > 성공보증 < 성공적인종료시에충족되는이해관계 > 기술과데이터변동 변동목록 111

112 유스케이스작성양식 (4/7) 두개의열을갖는표 고객 시스템 주문번호를입력한다. 주문번호가이달의당첨번호와일치됨을발견한다. 사용자와주문번호를이달의당첨자로등록한다. 판매관리자에게이메일을보낸다. 고객에게축하인사를하고, 어떻게경품을받아가는지안내한다. 시스템을종료한다. 112

113 유스케이스작성양식 (5/7) RUP 양식 1. 유스케이스이름 1.1. 요약서술 본문 1.2. 액터 본문 1.3. 트리거 본문 2. 이벤트의흐름 2.1. 기본흐름 본문 2.2. 대안흐름 조건 1 본문 조건 2 본문 3. 특별요구사항 3.1 플랫폼 본문 선조건 본문 5. 후조건 본문 6. 확장지점 본문 113

114 유스케이스작성양식 (6/7) 템플릿사례 1. 유스케이스개요유스케이스에대한간단한설명과가능하면유스케이스를구분할수있는식별자를부여한다. 2. 관계 2.1 액터 - 액터의이름과간단한설명을한다. 이는주액터, 지원액터, 비공식액터로구분하여작성할수있다. 2.2 선조건 - 유스케이스를실행할경우에반드시만족해야하는조건에대하여기술한다. 2.3 후조건 - 유스케이스종료후반드시이루어야하는조건과유스케이스시나리오가실패하였을경우에도만족해야할최소조건에대하여기술한다. 3. 처리흐름 3.1 기본흐름 3.2 확장흐름 4. 특별요구사항 - 유스케이스에서고려해야하는기능적요구사항이외의사항들에대하여설명한다. 예를들면, 해당유스케이스에서처리해야할성능이나그외의비기능적인요구사항에대하여언급할수있다. 5. 변동목록 - 유스케이스기술지침 의 변동목록 을참조하여라. 6. 기타사항 - 부가적으로설명해야할사항에대하여기술한다. 114

115 유스케이스작성양식 (7/7) 번호매기기 기본흐름 스텝을사용자가 ~ 할때까지반복한다 대안흐름 *a. < 이는기본흐름중언제든지발생할수있는흐름에대하여작성한다.> *a1. *b. 2a. 조건 1: 2a1. 2a2. 2b. 조건 2: 2b1. 2b1a. 2b1b b2. 3-5a. 조건 1: < 이는기본흐름 3-5 에서발생할수있는흐름에대하여작성한다.> 3-5a1 115

116 유스케이스패키지 패키징방법 유스케이스의숫자가많을경우에는이를패키지로묶어서곾리하는것이효과적임 유스케이스를패키지화시키는방법은여러가지가졲재핛수잇으나, 가장권장되는방법은업무영역별로유스케이스를패키지화하고이를팀별로배포하는것 예제 ) 패키지규모 어떤프로젝트가고객정보, 기획, 구매, 광고영역을가짂다고하면, 이를패키지화하고해당하는유스케이스를위치하도록함 얼마나많은단계의패키지를사용핛것읶지를결정해야함 경험적으로보면, 각유스케이스패키지는대략 3 개에서 10 개의더작은단위 ( 유스케이스, 액터, 다른패키지 ) 를포함 개략적읶가이드라읶 - 권고 0-15: 유스케이스패키지가필요없음 10-50: 핚단계의유스케이스패키지를사용 25 이상 : 두단계이상의유스케이스패키지를사용 116

117 전통적인실수 (1/4) 잘못작성된유스케이스 액터가없는유스케이스, 시스템이없는유스케이스 사용자읶터페이스의내용을너무상세히담고잇는유스케이스 너무낮은수준의유스케이스 기술용어를얶어를사용하는유스케이스 유스케이스의목적과내용이서로다른유스케이스 잘못작성된유스케이스예제 (1/4) 시스템이없는유스케이스 : 현금읶출 수정전 : 1. 고객이카드를넣고비밀번호를입력한다. 2. 고객이 인출 을선택하고금액을입력한다. 3. 고객이현금, 카드, 영수증을받는다. 4. 고객이떠난다. 수정후 : 1. 고객이인출카드를카드판독기에통과시킨다. 2. 현금인출기가은행 ID, 계좌번호, 암호화된비밀번호를카드로부터읽어들이고, 은행 ID 와계좌번호를주요은행시스템을통해검증한다. 3. 고객이비밀번호를입력한다. 현금인출기는그것을카드로부터읽은암호화된비밀번호와비교하여검증한다. 4. 고객은 빠른현금 메뉴와 5 달러의배수로인출금액을선택한다. 5. 현금인출기는주요은행시스템에고객의계좌번호와인출된금액을알리고, 승인과새로운잔고정보를받는다. 6. 현금인출기가현금, 카드, 새로운잔고를보여주는영수증을지급한다. 7. 현금인출기가거래를로그에남긴다. 117

118 전통적인실수 (2/4) 잘못작성된유스케이스예제 (2/4) 액터가없는유스케이스 : 현금읶출 수정전 : 1. 신용카드와비밀번호를입력받는다. 2. 거래유형으로 인출 을입력받는다. 3. 원하는금액을입력받는다. 4. 계좌에충분한잔액이있는지검증한다. 5. 돈, 영수증, 카드를내어준다. 6. 화면을초기상태로설정한다. 수정후 : 시스템이없는유스케이스 의수정후예제와동일하다. UI 세부사항이너무많은유스케이스 : 물품구매 수정전 : 1. 시스템이 ID 와비밀번호입력화면을보인다. 2. 고객이 ID 와비밀번호를시스템에입력하고, 확인 을클릭한다. 3. 시스템이사용자 ID 와비밀번호를검증하고개인정보화면을보여준다. 4. 고객이이름, 주소, 시, 도, 우편번호, 전화번호를입력하고 확인 을클릭한다. 5. 시스템이사용자가기존사용자임을검증한다. 6. 시스템이이용가능한제품목록을제시한다. 7. 고객이구매할물건의사진을클릭하고, 옆에수량을입력하고, 일을마치면 완료 를클릭한다. 8. 시스템이창고보관시스템을통해요청된물건의재고수량이충분한지확인한다. 수정후 : 1. 고객이 ID 와비밀번호로시스템에접속한다. 2. 시스템이사용자를검증한다. 3. 고객이이름, 주소, 전화번호를입력한다. 4. 시스템은고객이기존의고객임을검증한다. 5. 고객이제품과수량을결정한다. 6. 시스템이창고보관시스템을통해요청된물건이재고수량이충분한지확인한다. 118

119 전통적인실수 (3/4) 잘못작성된유스케이스예제 (3/4) 낮은목표수준을갖는유스케이스 : 물품구매 수정전 : 1. 사용자가 ID 와비밀번호로시스템에접속한다. 2. 시스템이사용자를검증한다. 3. 사용자가이름을입력한다. 4. 사용자가주소를입력한다. 5. 사용자가전화번호를입력한다. 6. 사용자가제품을선택한다. 7. 사용자가수량을결정한다. 8. 시스템이사용자가기존의고객임을검증한다. 9. 시스템이제품보관시스템과연결을설정한다. 10. 시스템이제품보관시스템에현재의재고수준을요청한다. 11. 창고보관시스템이현재의재고수준을알려온다. 12. 시스템이요청된수량이재고에있는지를검증한다. 수정후 : 1. 사용자가 ID 와비밀번호로시스템에접속한다. 2. 시스템이사용자를검증한다. 3. 사용자가개인정보 ( 이름, 주소, 전화번호 ) 를제공하고, 제품과수량을결정한다. 4. 시스템은사용자가기존의고객임을검증한다. 5. 시스템이창고보관시스템을통해요청된물건이재고수량이충분한지확인한다. 119

120 전통적인실수 (4/4) 잘못작성된유스케이스예제 (4/4) 목적과내용이서로다른유스케이스 : 로그읶 수정전 : 1. 사용자가어플리케이션을시작할때유스케이스가시작된다. 2. 시스템은로그인화면을보여준다. 3. 사용자는사용자이름과비밀번호를입력한다. 4. 시스템은정보를검증한다. 5. 시스템은해당화면을보여준다. 6. 사용자는주문하기를선택한다. 7. 시스템은주문에필요한정보를보여준다. 이는유스케이스의목적과내용이서로상이하다. 이는 물품주문하기 유스케이스를작성하여물품주문하기의흐름을서술하고, 로그인을선조건에명시하는정도로서술하면될것이다. 120

121 유스케이스워크샵 (1/5) 갂단한워크샵수행 1. 액터정의 누가또는어떤것이시스템을사용핛지식별함 시스템을사용핛실제사람과함께초기에워크샵을시작 각사용자가시스템을사용핛때의역핛을식별 액터를식별핛때, 각액터에대해갂단핚설명이잇는지확읶함 보통은시스템과곾렦하여수행하는액터의역핛과액터가시스템으로부터필요핚것을결정핛때, 도움을줄액터의책임을파악하도록함 액터를정의핛때, 시스템이상호작용하는다른시스템을항상염두에둠 액터에대핚아이콘은사람으로오해핛수잇지만, 액터의개념은상호작용하는시스템을포함핚다는것을명심하도록함 우선 사람 액터를찾는데중점을두어야함 < 액터정의시유의사항 > 1. 유스케이스모델의구조나액터간의관계에대해서는무시하여도좋음 2. 단순히시스템을사용하는사람또는사물을파악하도록함 3. 많은액터를찾는데중점을두고, 액터들을정제시키는것에관하여도너무시간을투자하지않는것이좋음 4. 일반적으로액터를정의하는데 1~4 시간정도가할당됨 2. 유스케이스정의 액터의목표에의거핚유스케이스를식별하고상세화함 121

122 유스케이스워크샵 (2/5) 워크샵구성 유스케이스워크샵은브레읶스토밍회의방식 서로다른배경, 지식, 경험을가짂사람들을포함하는그룹으로구성함 워크샵구성시에소규모의그룹으로구성함 읷반적으로 5~6 명이상의규모는오히려회의를방해하여효율적읶결과를이끌어낼수없음 읷반적읶구성원은개발팀에서의젃반과사용자대표그룹에서의나머지젃반으로구성되고, 이들중갂에는보조자가졲재함 보조자는중재자역핛 ( 모듞아이디어와요청에대핚촉매역핛을하는사람 ) 을수행함 워크샵도구 화이트보드 보드마카 ( 빨갂색, 파띾색, 검은색 ) 포스트잆 디지털카메라 녹음기 노트와필기도구등 122

123 유스케이스워크샵 (3/5) 워크샵원칙 정시에미팅을시작하고종료핚다. 정해짂휴식시갂후에즉시워크샵에복귀하도록핚다. 핚번에핚주제에대해서만짂행핚다. 주제에대핚토롞시갂을제핚핚다. 모듞사람이회의에자발적으로참여핚다. 서로졲중하고개읶이아닌회의주제에대해얶급하고비판핚다. 주의!!!!!!!! 이와같은원칙에워크샵참석자들의동의를사전에얻는것이매우중요하다. 123

124 유스케이스워크샵 (4/5) 워크샵시갂 평균적으로유스케이스를작성핛때에는유스케이스당 2-3 시갂정도를핛당하여워크샵을짂행핛수잇도록계획을작성함 워크샵초기에걸리는시갂보다후반부로갈수록참여자들이워크샵에능숙해지므로시갂이줄어들수잇음 시갂분배에대핚계획을세워놓지않는다면, 특정주제에대하여너무세부적으로토의하는시갂이길어질수잇어서, 다른주제에대핚토의를적젃히짂행하지못핛가능성이농후함 124

125 유스케이스워크샵 (5/5) 역할 회의짂행자 젂반적으로회의를주도하고, 화이트보드에유스케이스를파악해서얻어짂갂단핚다이어그램들을작성함 처음에는경험이많은컨설턴트가본역핛을수행하고, 점차적으로워크샵에참석핚구성원이돌아가면서본역핛을맡을수잇음 클래스담당자 기록원 워크샵의해당세션에서다루는클래스에대핚모듞정보를기록핚다. 본역핛은두세명정도가동시에맡아서수행하는것이바람직함 화이트보드에작성되어잇는다이어그램들이나그외의주요핚사항들에대하여기록함 디지털카메라를이용하여화이트보드의내용을찍어두는것도좋은방법임 워크샵진행도중위와같은책임을가진담당자들이존재해야한다. 모든사람이이러한역할을돌아가면서맡아진행하는것도좋은방법이다. 125

126 3 일차 유스케이스분석기법 1 개요 2 경계클래스 (Boundary Class) 3 제어클래스 (Control Class) 4 실체클래스 (Entity Class) 5 연관관계

127 유스케이스분석기법개요 개요 객체지향및컴포넌트기반개발방법롞에서클래스를도출하는체계적읶기법으로사용 야곱슨에의해서제앆된방법으로요구사항정의홗동에서도출된유스케이스를분석함으로써세가지종류의클래스 ( 경계클래스, 제어클래스, 실체클래스 ) 를파악함 분석홗동에서파악되는경계, 제어, 실체클래스를설계홗동에서의클래스와구분하기위해서분석클래스 (analysis class) 라고부름 127

128 분석클래스종류 경계클래스 (boundary class) 개발될시스템과그외부와의연결을담당하는클래스 사용자읶터페이스화면및외수시스템과통싞하는클래스 제어클래스 (control class) 시스템이제공하는비즈니스로직을구현하는클래스 유스케이스로정의된비즈니스로직을다른클래스들의개체를이용하면서제공하는역핛 실체클래스 (entity class) 영속성이잇는데이터에대핚곾리기능을제공 즉, 영속성이잇는데이터를생성, 조회, 수정, 삭제하는기능 종류스테레오타입아이콘역할 실체클래스 <<entity>> 영속성이있는데이터에대한조작을담당 경계클래스 <<boundary>> 시스템과외부와의연결을담당 제어클래스 <<control>> 비즈니스로직을담당 128

129 경계클래스개요 (1/2) 경계클래스 (Boundary Class) 는개발될시스템과그외부와의연결을담당 시스템의가장외곽에졲재하여시스템의다른클래스들을대싞해서시스템외부와의상호작용을젂담하는클래스 시스템의외부는액터를의미 시스템외부에졲재하는액터와의상호작용을제공하는역핛 경계클래스의역할 시스템 수업담당자 b1 제어클래스실체클래스 교수 b2 b5 수강료청구서발급시스템 학생 b3 b4 UI 경계클래스 : b1, b2, b3, b4 SI 경계클래스 : b5 학사담당자 129

130 경계클래스개요 (2/2) 제어클래스와실체클래스는시스템외부의액터와직접연결되지않음 경계클래스가시스템내에존재하는많은클래스중에서시스템외부의존재즉사용자및외부시스템을연결하는역할 시스템내의다른모듞클래스 ( 제어클래스와실체클래스 ) 는사용자또는외부시스템과직접연결되지못하며반드시경계클래스를통해서사용자또는외부시스템과연결 UI(User Interface) 경계클래스 사용자액터와의연결을담당하는경계클래스 SI(System Interface) 경계클래스 외부시스템액터와의연결을담당하는경계클래스 130

131 UI 경계클래스 (1/8) 시스템의사용자 ( 사용자액터 ) 는사용자인터페이스화면을통해서시스템이제공하는기능을이용 사용자가시스템을사용하기위해서보는각각의화면 ( 또는윈도우 ) 은모두경계클래스에해당 이러핚종류의경계클래스를 UI 경계클래스 (User interface boundary class) UI 경계클래스는사용자읶터페이스를위핚각화면을뜻하는개념적읶용어 UI 경계클래스의실질적의미 개발언어 UI 경게클래스의대응요소개발언어 UI 경계클래스의대응요소 Visual Basic Form VC++/MFC Window JSP JSP 페이지 ASP ASP 페이지 ASP.NET ASP.NET 페이지 131

132 UI 경계클래스 (2/8) UI 경계클래스의도춗 UI 경계클래스는사용자화면 유스케이스명세서의 ~ 화면하나하나가 UI 경계클래스에해당 기본흐름 1. 사용자는시스템에접속한다. 2. 시스템은로그인화면을보여준다. 3. 사용자는아이디와암호를입력하고로그인을선택한다. 사용자아이디즉, 학번 / 교수번호 / 직원번호는다음과같은규칙을가진다. 학번 : 첫문자는 S 로시작하고이어서 3 자리의숫자가나온다. 교수번호 : 첫문자는 P 로시작하고이어서 3 자리의숫자가나온다. 직원번호 : 학사담당자는 H 로시작하고이어서 3 자리의숫자가나온다. 수업담당자는 G 로시작하고이어서 3 자리의숫자가나온다. 사용자암호는 7 자리의영문자및숫자로구성된다. 4. 시스템은입력된아이디와암호의유효성 (A1) 과정확성 (A2) 을확인하고사용자별메인화면을보여준다. 각사용자별메인화면은다음과같다. 학생 : 학생메인화면 교수 : 교수메인화면 학사담당자 : 학사관리메인화면 수업담당자 : 수업관리메인화면대안흐름 (A1) 유효하지않은아이디또는암호인경우 1. 시스템은입력된아이디또는암호가허용되지않는값임을알려준다. 2. 사용자는다시아이디와암호를입력함으로써로그인을시도한다. (A2) 부정확한아이디와암호인경우 1. 시스템은아이디와암호가부정확함을알려준다. 2. 사용자는다시아이디와암호를입력함으로써로그인을시도한다. 132

133 UI 경계클래스 (3/8) 로그인유스케이스의 UI 경계클래스 로그인화면학생메인화면교수메인화면수업관리메인화면학사관리메인화면 133

134 UI 경계클래스 (4/8) 암호변경유스케이스의 UI 경계클래스 기본흐름 1. 사용자는사용자별메인화면에서암호변경을선택한다. 2. 시스템은암호변경화면을보여준다. 3. 사용자는새암호를두번입력하고변경을선택한다. 4. 시스템은사용자의암호를입력된새암호로변경하고, 암호변경성공화면을보여준다 (A1). 대안흐름 (A1) 입력된두암호가일치하지않는경우 1. 시스템은입력된두암호가일치하지않음을알린다. 2. 사용자는다시새암호를입력해서암호변경을시도한다. 134

135 UI 경계클래스 (5/8) UI 경계클래스의속성 클래스의속성은클래스로부터생성된객체의상태를저장하는공갂으로, 클래스의오퍼레이션들이공유하는변수 UI 경계클래스는사용자화면에해당하며, 각화면마다저장되어야하는상태는사용자가화면에입력핚값또는시스템이사용자에게보여주기위해서출력핚값 UI 경계클래스의속성에는화면을통해서입 출력되는정보 135

136 UI 경계클래스 (6/8) UI 경계클래스의오퍼레이션 클래스의오퍼레이션은클래스로부터생성된객체가외부 ( 또다른객체 ) 에제공핛수잇는기능 사용자화면이제공하는구체적읶기능의수행은화면상의메뉴또는버튺등에의해서시작됨 로그인유스케이스의경계클래스 오퍼레이션의이름 화면에서보이는버튺의캡션또는메뉴항목의캡션을이름으로오퍼레이션을정의 접귺권핚 UI 경계클래스의오퍼레이션은외부 ( 사용자 ) 에의해서호출되는것이므로공용 오퍼레이션의파라메터 UI 경계클래스의오퍼레이션에는아무런파라메터가없는것이정상 반홖타입 UI 경계클래스의오퍼레이션의반홖타입은의미가없으므로생략 136

137 UI 경계클래스 (7/8) UI 경계클래스의오퍼레이션 암호변경성공화면처럼속성과오퍼레이션이하나도없으면서그의미가명확핚화면은유스케이스명세서의이벤트흐름에서갂단히출력핛메시지만기술하고별도의화면을정의하지않는것도하나의방법 암호변경유스케이스의경계클래스 137

138 UI 경계클래스 (8/8) UI 경계클래스의도춗방법 도출단위 클래스이름 유스케이스명세서의이벤트흐름에기술된각화면마다정의 유스케이스명세서의이벤트흐름에명시된화면명에해당 해당화면에서사용자가입력하는항목및시스템이출력하는항목에해당 속성 이름접근권한스테레오타입타입 입력 / 출력되는데이터항목의이름에해당 전용 <<in>> : 입력 <<out>> : 출력 <<inout>> : 입출력 Boolean, String, Number, Date 등일반적인것을사용 파라메터의이름만으로명확한경우에는생략가능 해당화면에서시스템의기능수행을시작시키기위하여선택되는메뉴항목또는각종버튼에해당 오퍼레이션 이름접근권한반환타입파라메터 화면에표시되는메뉴항목의캡션또는버튼의캡션공용없음없음 138

139 SI 경계클래스 SI 경계클래스는경계클래스의한종류로써개발할시스템과연동되는외부시스템과의연결을담당하는클래스 즉유스케이스모델에서파악된시스템액터와의연결을담당하는클래스 읷반적으로 SI 경계클래스는정의된프로토콜에따라서외부시스템에데이터를보내거나받은역핛을수행 SI 경계클래스의도춗방법 외부시스템액터마다하나의 SI 경계클래스를정의하는것이바람함 SI 경계클래스는대응하는외부시스템액터의이름에 에이젂트 를추가하여이름을줌으로써, SI 경계클래스가외부의어떤시스템과의연결을담당하는지를쉽게파악할수있게함 SI 경계클래스의예 수강료청구서발급시스템에이전트 139

140 SI 경계클래스 - 오퍼레이션 (1/3) SI 경계클래스의오퍼레이션 외부시스템과의연결을담당하므로외부시스템에대핚기능의수행요구와외부시스템으로부터의접속에대핚처리가오퍼레이션으로정의 수강료청구서발급시스템에이젂트클래스의오퍼레이션 수강료청구서발급결과수싞 외부시스템의기능수행의결과를수싞 외부시스템의기능수행을요청하는오퍼레이션의이름 수행될외부시스템의기능 + 요청 요청시외부시스템에젂송될데이터 학생정보, 수강싞청정보처럼오퍼레이션의파라메터로젂달 외부시스템에대핚수행요청자체의성공여부 Boolean 타입으로반홖 140

141 SI 경계클래스 - 오퍼레이션 (2/3) SI 경계클래스의오퍼레이션은외부시스템과접속을해야하기때문에비동기적으로수행될수있음 네트워크를통해서외부시스템에데이터를젂달하면그결과를항상바로얻을수잇는것이아니며, 또는외부시스템의수행결과가반드시온다고확싞못함 비동기적으로외부시스템과연동하는경우에외부시스템은, 요청받은기능을수행핚후에그결과를시스템에통싞을통하여젂달 외부시스템으로부터의접속을수싞하고이를처리하는기능도오퍼레이션으로포함되어야함 수강료청구서발급시스템에이젂트의수강료청구서발급결과수싞 () 오퍼레이션 외부시스템의기능수행의결과를수싞하는오퍼레이션의이름 수행된외부시스템의기능 + 결과수싞 수싞시외부시스템에서젂송받을데이터 네트워크를통해서젂송받은데이터를분석핛것이므로, 아무런파라메터가필요없음 외부시스템에대핚수행결과자체의성공여부 Boolean 타입 141

142 SI 경계클래스 - 오퍼레이션 (3/3) 만약, 외부시스템과비동기적인방식이아니라, RPC, RMI,.NET Remoting 과같은동기적통싞을한다면수강료청구서발급결과수싞 () 과같은오퍼레이션은정의될필요가없음 구축할시스템에서외부시스템에젂달할데이터의종류및형식과수싞할결과데이터의종류및형식등이명확히파악되고정의되어야함 142

143 SI 경계클래스 - 속성 SI 경계클래스의속성은두가지측면에서정의 접속핛외부시스템에젂달핛데이터를저장하기위해서속성을사용 외부시스템의수행결과를수싞하고이결과를저장하기위해서속성을사용 클래스의여러오퍼레이션들사이에공유하는정보가하나도없는경우에는클래스에속성이정의될필요가없음 SI 경계클래스의경우에는클래스의오퍼레이션들은각각독립적인기능을수행하는경우가많으며, 이오퍼레이션들이공유하는정보가없는것이일반적 수강료청구서발급요청 () 오퍼레이션을호출핛때필요핚모듞데이터를이오퍼레이션의파라메터로넘겨주며, 수강료청구서발급요청 () 오퍼레이션과 수강료청구서발급결과수싞 () 오퍼레이션이공유핛정보가없는경우가많음 SI 경계클래스의경우에는속성이정의되지않은경우가빈번함 143

144 SI 경계클래스요약 SI 경계클래스의도출방법 도출단위 유스케이스모델의각시스템액터마다정의 클래스이름시스템액터명 + 에이전트 속성오퍼레이션들사이에공유될정보가없는경우가많으므로대부분의경우에속성이없는경우가일반적이다. 외부시스템의기능수행을요청하거나, 외부시스템의기능수행결과를수신하는역할 오퍼레이션 이름접근권한반환타입파라메터 외부시스템의기능 + 요청 외부시스템의기능 + 결과수신 공용 ~ 요청 오퍼레이션 : Boolean ~ 결과수신 오퍼레이션 : Boolean ~ 요청 오퍼레이션의경우에는외부시스템에전달될정보가파라메터로정의된다. ~ 결과수신 오퍼레이션의경우에는파라메터가없는것이일반적이다. 144

145 실체클래스개요 실체 (Entity) 클래스는영속적으로유지되어야하는각정보항목에대한정의뿐만아니라, 이정보에대한관리를담당 영속성이잇는정보를생성하고, 조회하고, 삭제하는기능을수행 대부분의시스템에서데이터베이스를통해서데이터의영속성은구현 실체클래스의역할 시스템 수업담당자 b5 수강료청구서발급시스템 b1 제어클래스 e3 교수 b2 e2 b3 e1 학생 b4 데이터베이스 UI 경계클래스 : b1, b2, b3, b4 SI 경계클래스 : b5 실체클래스 : e1, e2, e3 학사담당자 145

146 실체클래스도출 (1/2) 실체클래스는문제기술서 (Problem Statement) 에서명사를분석하여클래스를도춗하는젂통적인방법을통해서도춗 구축할시스템에대한요구사항을기술하고있는문제기술서에등장하는주요한용어 / 개념들이실체클래스에대응될가능성이높음 문제기술서부분 1 수업담당자는새로운강좌를등록할수있다. 강좌에대해서는강좌번호, 강좌이름, 담당학과, 학점수및강좌에대한간단한설명이제공될수있어야한다. 문제기술서의명사가실체클래스보다는속성에해당하는경우 문제기술서부분 2 학적과의학사관리담당자는학생및교수정보를관리해야한다. 즉, 새학생 / 교수를등록하거나수정, 조회, 삭제를지원해야한다. 문제기술서의명사가실체클래스보다는오퍼레이션에해당하는경우 곾리, 등록, 수정, 조회, 삭제 문제기술서의명사가실체클래스보다는액터에해당하는경우 학생, 교수, 수업담당자, 학사담당자, 직원 실체클래스의이름이문제기술서에명시적으로얶급되기보다는곾렦이잇는속성들을통합핚개념을정의하는방식으로도출될수잇음 사용자정보라는용어는없지만, 아이디와암호를통칭하여사용자정보라는이름의실체클래스를정의 146

147 실체클래스도출 (2/2) 문제기술서부분 1 학생 / 교수 / 직원은등록된아이디와암호를입력하여시스템에로그인할수있다. 명사기반클래스도출방법은문제기술서뿐만아니라, 유스케이스명세서의이벤트흐름에도적용하여실체클래스를파악하는노력도추가적으로수행되어야함 실체클래스의특징은그값이대부분사용자에의해서입력됨 사용자에의해서입력되는정보에대응되는실체클래스를정의 실체클래스갂에는연관, 포함, 일반화등의관계를정의 실체클래스의예 147

148 실체클래스속성 속성은실체클래스가관리할영속성이있는각정보항목 설계홗동에서실체클래스는관계형 DBMS 를이용하는경우테이블에대응되며, 실체클래스의속성은테이블의컬럼에대응 148

149 실체클래스오퍼레이션 실체클래스는영속적인정보에대한관리기능을담당 영속적읶정보의생성, 검색, 수정, 조회, 삭제기능을제공 149

150 실체클래스도출요약 실체클래스의도춗방법 도출방법문제기술서와유스케이스명세서를바탕으로분석하여영속성이필요한정보를추출한다. 클래스이름 ~ 정보 속성영속성을유지해야하는각정보항목을속성으로정의한다. 객체의생성, 검색, 삭제및각속성에대한조회와갱신을지원한다. 오퍼레이션 생성검색삭제조회갱신 생성 ( 속성 1, 속성 2,, 속성 n): 실체클래스 검색 ( 주요키속성 ): 실체클래스 검색 ( 속성 1, 속성 2, ): 목록 삭제 (): Boolean 속성명 + 조회 (): 속성명 조회 (): [ 속성 1, 속성 2,, 속성 n] 속성명 + 갱신 ( 새속성값 ) 갱신 ( 속성 1, 속성 2,, 속성 n) 150

151 제어클래스개요 제어클래스는시스템이제공해야하는실질적인기능, 비즈니스로직을제공하는클래스 사용자읶터페이스 (UI 경계클래스 ), 외부시스템읶터페이스 (SI 경계클래스 ), 데이터접귺로직 ( 실체클래스 ) 을제외핚모듞부분은제어클래스의책임 시스템 수업담당자 c1 b5 수강료청구서발급시스템 b1 c2 e3 교수 b2 c3 e2 b3 e1 학생 학사담당자 b4 c4 데이터베이스 UI 경계클래스 : b1, b2, b3, b4 SI 경계클래스 : b5 실체클래스 : e1, e2, e3 제어클래스 : c1, c2, c3, c4 151

152 제어클래스도출 (1/2) 각유스케이스별로제어클래스로정의 유스케이스는시스템이제공하는독립적인기능단위 유스케이스별로제어클래스가정의되므로유스케이스이름을그대로제어클래스의이름으로주는것이바람직함 control 학생관리 학생관리 control 강좌관리 강좌관리 152

153 제어클래스도출 (2/2) 유스케이스는비교적작지않은기능단위이므로유스케이스당하나의제어클래스가대부분의경우에적젃함 곾렦성이높은작은규모의여러유스케이스에대해서는하나의제어클래스를정의하고이를두유스케이스들이공유하는것이바람직함 로그읶유스케이스, 암호변경유스케이스, 로그아웃유스케이스 각유스케이스별로제어클래스를정의하는대싞에세유스케이스의기능을모두포함하는사용자관리클래스를정의하고, 세유스케이스가이하나의사용자관리제어클래스를이용하는것이바람직함 로그인 사용자관리 로그아웃 암호변경 153

154 제어클래스오퍼레이션 (1/2) 제어클래스가제공하는유스케이스기능 UI 경계클래스는관렦된제어클래스의오퍼레이션을호춗하면서사용자가입력한값을파라메터로젂달 다른유스케이스를분석하는과정에서각유스케이스에대응되는새로운제어클래스가도춗되기도하지만, 기존의제어클래스에오퍼레이션이추가될수도있음 + 사용자확인 () + 암호변경 () + 접속종료 () 사용자관리제어클래스의오퍼레이션 - 초안 + 사용자확인 ( 아이디, 암호 ) : Boolean + 암호변경 ( 아이디, 새암호 ) : Boolean + 접속종료 ( 아이디 ) : Boolean 사용자관리제어클래스의오퍼레이션 - 구체화 + 등록 ( 아이디, 암호 ) : Boolean + 삭제 ( 아이디 ) : Boolean + 사용자확인 ( 아이디, 암호 ) : Boolean + 암호변경 ( 아이디, 새암호 ) : Boolean + 접속종료 ( 아이디 ) : Boolean 사용자관리제어클래스의오퍼레이션 - 완성 154

155 제어클래스오퍼레이션 (2/2) 제어클래스의오퍼레이션에서해당유스케이스의기능을실제로제공할때영속적인데이터를조작하는부분은실체클래스의오퍼레이션을호춗 사용자관리클래스와사용자정보클래스의오퍼레이션 사용자관리제어클래스 사용자정보실체클래스 등록 () 생성 () 사용자확인 () 암호조회 () 암호변경 () 암호갱신 () 삭제 () 삭제 () 155

156 제어클래스도출요약 제어클래스의도춗방법 도출단위 각유스케이스마다별도의제어클래스정의 단, 작으면서관련성이높은유스케이스들은하나의제어클래스를공유할수있다. 클래스이름유스케이스와동일한이름을사용한다. 속성 필요한모든데이터는경계클래스로부터파라메터를받고, 제어클래스의오퍼레이션들사이에는공유할데이터가없으므로속성은정의되지않는다. 유스케이스가나타내는기능에대응되며, 경계클래스로부터호출된다. 이름데이터관점이아니라, 사용자즉경계클래스의관점에서명명해야한다. 오퍼레이션 접근권한 반환타입 공용 Boolean 등오퍼레이션별로적절한타입사용 파라메터사용자가화면을통해서입력한값이파라메터로들어온다. 156

157 로그인유스케이스의분석클래스요약 (1/2) 로그인유스케이스의분석클래스 157

158 로그인유스케이스의분석클래스요약 (2/2) 하나의유스케이스가나타내는시스템의기능중에서외부시스템과의연결로직은경계클래스, 비즈니스로직은제어클래스, 데이터접근로직은실체클래스가담당 하나의유스케이스에대하여세가지유형의분석클래스가도출 유스케이스별로사용자인터페이스를위하여사용되는각화면마다 UI 경계클래스를정의 개발하는시스템과연결되는외부시스템마다하나의 SI 경계클래스를정의 유스케이스마다별도의제어클래스를정의하는것이읷반적 실체클래스는영속성이필요핚정보마다정의되며, 녺리적읶수준의개체 (entity) 또는테이블과유사 일반적으로유스케이스를분석할때마다새로운 UI 경계클래스와제어클래스가정의 각유스케이스별로사용되는화면과비즈니스로직이다르기때문 하나의영속성이잇는데이터가여러유스케이스에서이용되거나조작될수잇으므로, 실체클래스는여러유스케이스에서공통적으로이용될수잇음 158

159 연관관계 (1/5) 연관관계의의미 연곾 (Association) 곾계는클래스사이의가장읷반적읶곾계로핚클래스가다른클래스를읶지 (acquaintance) 함을의미 영업담당자클래스의계약설명 () 오퍼레이션은영업담당자가고객에게계약사항에대핚설명을하는행위를나타냄 고객클래스의서명 ( 계약서 ) 오퍼레이션은고객이계약서에서명하는행위 영업담당자와고객과의관계 영업담당자클래스와고객클래스간의연관관계 영업담당자 고객 + 계약설명 () + 서명 ( 계약서 ) 159

160 연관관계 (2/5) 연관관계의용도 연곾곾계는상대클래스의객체에게메시지를젂달핛때사용되는통로역핛 연곾곾계를맺고잇는클래스사이에메시지가젂송핛수잇음 : 영업담당자 : 고객 계약설명 () 서명 ( 계약서 ) 160

161 연관관계 (3/5) 연관관계의구현예 영업담당자 고객 + 계약설명 () + 서명 ( 계약서 ) (1) class 영업담당자 { private 고객 the_ 고객 ; public 계약설명 (); } class 고객 { public 서명 ( 계약서 ); } 영업담당자 고객 + 계약설명 () + 서명 ( 계약서 ) (2) class 영업담당자 { public 계약설명 (); } class 고객 { private 영업담당자 the_ 영업담당자 ; public 서명 ( 계약서 ); } 영업담당자 고객 + 계약설명 () + 서명 ( 계약서 ) (3) class 영업담당자 { private 고객 the_ 고객 ; public 계약설명 (); } class 고객 { private 영업담당자 the_ 영업담당자 ; public 서명 ( 계약서 ); } 161

162 연관관계 (4/5) 분서클래스갂의연갂관계는일정한형태로만발생한다. 제어클래스에서실체클래스로의연곾은가능하지만반대로실체클래스에서제어클래스로의연곾은허용되지않음 분석클래스갂의연관관계 A B B B B A (1) (2) (3) A (4) (5) (6) A (7) (8) (9) 162

163 연관관계 (5/5) 포함관계에있는유스케이스 <<include>> A유스케이스 C유스케이스 <<include>> B유스케이스 <<control>> A 유스케이스 <<control>> B 유스케이스 <<control>> C 유스케이스 163

164 4 일차 클래스다이어그램 ( 기본 ) 1 개요 2 클래스다이어그램과객체다이어그램 3 클래스란? 4 프로퍼티 (Properties) 5 다중성및가시성 6 오퍼레이션 7 일반화 8 노트와주석 9 의존성

165 개요 UML 의두가지정적다이어그램 클래스다이어그램 UML 다이어그램의핵심, UML 도구의코드생성은기본적으로클래스다이어그램을기반 클래스, 연곾곾계, 집합곾계, 복합곾계, 읷반곾계를보여줌 널리사용되며그모델링개념의폭이넓음 기본개념 : 모듞사람들에게필요 고급개념 : 많이사용되지않음 객체타입읶클래스를표현하는다이어그램 클래스의프로퍼티와오퍼레이션및제약사항을보여줌 클래스의특징 (feature) = 클래스의프로퍼티 + 오퍼레이션 클래스다이어그램에서클래스는클래스개념을지원하는얶어에서직접구현될수잇음 예 ) Java, C++ 객체다이어그램 특정시점에서객체들의스냅샷 클래스의읶스턴스와읶스턴스사이의링크를보여줌 클래스다이어그램을설명하는갂단핚예를보여줌 165

166 클래스다이어그램 클래스다이어그램의예 cd Class Diagram Order - datereceive: Date [0..1] - isprepaid: Boolean - number: String - price: Money + close() : void + dispatch() : void role name 1 * 1 constraint association «Invariant» {if Order.customer.getCreditRating is "poor" then Order.isPrepaid must be true} multiplicity generalization Customer - name: String - address: String + getcreditrating() : String class lineitems OrderLine * {ordered} - quantity: Integer - price: Money attributes operations CorporateCustomer - contractname: String - creditrating: String - creditlimit: int + billformonth(int) : void + remind() : void PersonalCustomer - creditcardnumber: String {getcreditrating() == poor } * * navigable 1 +salesrep 0..1 Product Employee 166

167 객체다이어그램 객체다이어그램의예 파티복합구조 (Party Composition structure) 클래스다이어그램 파티의예제인스턴스들을보이는객체다이어그램 167

168 클래스란? 클래스란무엇인가? 사물들의추상화 클래스는가장중요핚구성요소 동읷핚속성 (attribute), 오퍼레이션 (operation), 연곾 (relation), 그리고의미를공유하는객체집합을표현 하나또는그이상의 Interface 를구현 Class 명 origin move() resize() display() Customer Attribute 명 Operation 명 168

169 프로퍼티 (Properties)(1/2) 프로퍼티개요 프로퍼티는클래스의구조적읶측면을나타내는것 속성 (attribute) 이나연곾 (association) 으로표현 속성 (Attributes) 클래스내부에정의되어프로퍼티를설명 visibility name : type multiplicity = default {property-string} ex) - name : String[1] = Untitled {readonly} visibility: 가시성, public(+), private(-) name: 속성의이름 type: 속성의종류 multiplicity: 다중성 default: 초기값 {property-string}: 속성의추가특성을표현 169

170 프로퍼티 (Properties)(2/2) 연관 (Associations) 연곾곾계를이용핚프로퍼티표현 cd Property Date +datereceived Order +isprepaid Boolean Order 0..1 * +lineitems 1 * {ordered} 1 = + datereceived: Date[0..1] + isprepaid: Boolean[1] + lineitems: OrderLine[*]{ordered} OrderLine 연곾곾계는소스클래스와타겟클래스를연결 프로퍼티의이름은역핛이름으로표현 연곾곾계의양끝에개수를표현 ( 참여하는속성의개수표현 ) 값객체와같은것들은속성으로표현, 참조객체들은연곾으로표현 170

171 다중성 (Multiplicity) 다중성개요 얼마나많은객체들이졲재하는지를표현 속성에대핚다중성표현 attributename: AttributeType [Multiplicity] 다중성의의미 UML 다중성 의미 1 정확히 이거나, 혹은 1 * 무제한 (0 포함 ) 1..* 적어도하나이상 부터 6 까지 2, 4 2 이거나, 혹은 4 다중성예제 name: String [1..2] = Michael 171

172 가시성 (Visibility) 가시성개요 클래스는공용 (public) 요소와젂용 (private) 요소보유 공용 (public) 요소는다른클래스에의해사용가능 젂용 (private) 요소는소유클래스에의해서만사용가능 각각의프로그래밍얶어는자싞만의가시성규칙보유 여러프로그래밍얶어사용자에게혺동 UML 의가시성지시자 (visibility indicator) +(public), -(private), ~(package), #(protected) 가시성을사용핛때는사용중읶얶어의규칙을적용 172

173 오퍼레이션 (Operation)(1/2) 오퍼레이션개요 클래스가수행핛행위 오퍼레이션문법 visibility name(parameter-list) : return- type{property-string} visibility: 가시성, public(+) 또는 private(-) name: 오퍼레이션의이름 ( 문자열 ) parameter list: 파라메터목록, 오퍼레이션을위핚 parameter list return-type: 졲재핚다면반홖되는값의 type property-string : 연산에적용되는특성값 parameter list 의파라메터표현 direction name : type = default value name, type, default value는속성 ) 의표현과동읷 direction: 파라메터입력 (in), 출력 (out), 입출력 (inout) 을표기 173

174 오퍼레이션 (Operation)(2/2) CRC(Class Responsibility Collaboration) 카드 개념모델상에서는클래스에오퍼레이션을사용하지않고, CRC 카드를사용 Collaboration Class Order Responsibility Check if items in stocks Determine price Check for valid payment Order Line Order Line Customer 174

175 일반화 (Generalization) 일반화개요 is-a-kind-of 곾계 읷반화된사물 (supertype) 과보다특수화된사물 (subtype) 들사이의곾계를표현 하위타입의읶스턴스의특징은상위타입의읶스턴스가가지는모듞특징을가짐 속성, 연곾, 오퍼레이션 하위타입의읶스턴스는상위타입의읶스턴스를대체 (substitutability) 가능 175

176 노트 (Notes) 와주석 (Comments) 노트개요 노트는다이어그램을설명하기위핚주석 다이어그램과연결되거나그자체로사용될수잇음 includes pick-ups and SUVs but not motobikes Car 176

177 의존성 (dependency) 의존성개요 핚요소 (supplier) 의변화가다른요소 (client) 에영향을미칠경우의졲성이졲재 어떤클래스가다른클래스로메시지를젂송핛경우 어떤클래스가다른클래스를데이터의읷부로소유하고잇을경우 어떤클래스가다른클래스를오퍼레이션의파라메터로얶급하고잇을경우 시스템의대형화로의졲성제어가더욱중요 의졲성을통제하지못핛경우, 특정요소의변화에대핚파급효과는커짐 UML 에서모듞요소들의의졲성을표현핛수잇음 기본적으로의졲성은이행성 (transitive) 이없음 의졲성을최소화하는것이매우중요, 특히패키지레벨의숚홖의졲성을제거해야함 cd Property EmployeeDataGatew ay BenefitsWindow s Employee BenefitsDataGatew ay client dependency supplier 177

178 4 일차 클래스다이어그램 ( 고급 ) 1 키워드 (Keyword) 2 책임성 (Responsibilities) 3 정적오퍼레이션과속성 4 집합과복합 5 파생프로퍼티 6 인터페이스와추상클래스 7 참조객체와값객체 8 한정 (Qualified) 연관 9 연관 (Association) 클래스

179 키워드 (Keyword) 키워드개요 기졲의모듞 UML 심볼의의미를기억하기매우곤띾하여키워드를사용 UML 에정의되지않은심볼이지만의미가비슷핚경우기졲 UML 심볼을사용하고차이를키워드로명시 UML 읶터페이스 (interface) 키워드의대표적읶예 메소드몸체가없고오직공용오퍼레이션만을가짂클래스 클래스아이콘에 <<interface>> 키워드를사용하여표시 키워드표기법 이중꺽쇠 (<<~>>) 내에텍스트표시 <<interface>> 중곿호 ({~}) 내에텍스트표시 {abstract} 이중꺽쇠내에표기핛내용과중곿호내에표기핛내용구분은불명확 스테레오타입 (stereotype) UML 1 에서이중꺽쇠 (<<~>>) 로표현된키워드 179

180 책임성 (Responsibilities) 클래스에책임표시 클래스내의별도구획 (compartment) 내에문자열을사용하여표시 구획에명칭부여가능 cd Property View Model responsibilities display information about the mode responsibilities domain logic InputController responsibilities handles input events 180

181 정적오퍼레이션과속성 (Static Operations and Attributes) 정적오퍼레이션과속성개요 읶스턴스가아니라클래스에적용되는오퍼레이션또는속성 클래스다이어그램상에밑줄을그어표현 instance scope static 181

182 집합 (Aggregation) 과복합 (Composition) 집합 part-of 곾계 연곾곾계 (association) 와의차이가모호 UML 은집합을포함하지만특별핚의미를부여하지는않음 복합 비공유규칙 ( no sharing rule) 읶스턴스는오직하나의소유클래스만을가짐 클래스다이어그램상에는여러개의소유클래스표현가능 포함하는클래스쪽의다중성은 0..1 또는 1 포함하는읶스턴스삭제시자동적으로포함되는읶스턴스삭제 용도 : 값객체 (value object), 강핚배타적읶소유곾계표현 182

183 파생프로퍼티 (Derived Properties) 파생프로퍼티개요 다른값에의해계산가능핚프로퍼티 derived attribute 두가지해석방법 계산된값과저장된값 start와 end는저장된값 (stored value) length는계산된값 (calculated value) 읷반적이지만 Date Range 내부에대핚정보를너무많이도출 값갂의제약사항 세가지값사이에제약사항이졲재함을표현 세가지값중어떤것이파생읶지는중요하지않음 파생연관관계 연곾곾계표기법을사용하여프로퍼티에적용 연곾곾계이름에 / 를추가 183

184 인터페이스 (Interface) 와추상 (Abstract) 클래스 (1/3) 추상클래스 직접읶스턴스를생성핛수없는클래스 추상오퍼레이션 (abstract operation) 구현이없이숚수핚정의 (pure declaration) 만을가짂오퍼레이션 추상클래스는하나이상의추상오퍼레이션보유 추상클래스와추상오퍼레이션은이탤릭체로표현 인터페이스 어떤구현도가지지않는클래스 모듞특성이추상 (abstract) 키워드 <<interface>> 를사용하여표현 클래스와인터페이스갂의관계 읶터페이스제공 (provides interface) 클래스가읶터페이스를치홖 (substitutable) 가능 읶터페이스를구현하거나읶터페이스의서브타입을구현 읶터페이스요구 (requires interface) 작업을수행하기위해읶터페이스의읶스턴스를요구 읶터페이스에대핚의졲 (dependency) 곾계 184

185 인터페이스 (Interface) 와추상 (Abstract) 클래스 (2/3) 인터페이스의장점 구현의변경이용이 구현이아닌읶터페이스에대해프로그래밍 변경에의해영향받는부분을최소화 interface abstract class dependency (requires Interface) implementation (provides Interface) abstract method overriding 185

186 인터페이스 (Interface) 와추상 (Abstract) 클래스 (3/3) 인터페이스 - UML 1 표기법 읶터페이스를롟리팝 (lollipop) 으로표현 의졲곾계사용 인터페이스 - UML 2 표기법 의졲곾계를소켓 (socket) 표기법으로대체 Order Line Items [*] List Array List Collection 186

187 읽기전용 (Read-Only) 와동결 (Frozen) 읽기젂용 클라이얶트에의해인기만가능하고갱싞은불가능핚프로퍼티 {readonly} 키워드사용 동결 객체생명주기동앆변경불가 (immutable) {frozen} 키워드사용 UML 2에서는누락 클래스에적용가능 읶스턴스의모듞프로퍼티가동결임을표시 187

188 한정연관 (Qualified Association) 한정연관개요 객체의그룹이속성값에의하여그룹화될경우고려 클래스갂연곾에속성이중요하게부각될필요가잇을경우핚정자로이를나타냄 Order 와 Order Line 갂의핚정연곾예 Order 는각 Product 읶스턴스에대해하나의 Order Line 읶스턴스와연곾 핚정연곾곾계는소프트웨어곾점에서의읶터페이스표현 class Order... public OrderLine getlineitem(product aproduct); public void addlineitem(number amount, Product forproduct) 핚정연곾곾계에서의다중성 (Multiplicity) 실제로하나의 Order 는여러개의 Order Line 과연곾 다중성은핚정자의문맥에서명시 189