Spring Framework 4.0과 4.1의 주요 업데이트 내용을 정리했습니다. 그리고, Spring I/O 2015 | The conference 에서 공개된 4.2의 소식들을 모아보았습니다. :)
ps. 제가 웬만하면 자료는 한글로 바꾸는 편인데... 이번에는 시간이 너무 부족해서 대부분 영어를 그대로 사용했네요. 다음에 기회가 되면 한글화시키는걸로...
spring.io 레퍼런스(sagan project)를 통해서 배우는 spring 개발사례에 대해서 발표하고 정리한 프레젠테이션입니다. 작년에 SpringOne에서 발표된 inside spring.io 내용과 저의 개인적인 분석을 통해서 내용을 정리했습니다.
'입문자' 분들을 대상으로 정리했기 때문에 가능한한 간결하고 직관적으로 내용들을 표현했으며 깊게 들어가는 내용들은 거의 생략을 하였습니다.
자세한 내용들을 원하시면 프레젠테이션 중간중간에 관련 link를 첨부하였으니 같이 보시면은 도움이 되실것 같습니다.
Spring Framework 4.0과 4.1의 주요 업데이트 내용을 정리했습니다. 그리고, Spring I/O 2015 | The conference 에서 공개된 4.2의 소식들을 모아보았습니다. :)
ps. 제가 웬만하면 자료는 한글로 바꾸는 편인데... 이번에는 시간이 너무 부족해서 대부분 영어를 그대로 사용했네요. 다음에 기회가 되면 한글화시키는걸로...
spring.io 레퍼런스(sagan project)를 통해서 배우는 spring 개발사례에 대해서 발표하고 정리한 프레젠테이션입니다. 작년에 SpringOne에서 발표된 inside spring.io 내용과 저의 개인적인 분석을 통해서 내용을 정리했습니다.
'입문자' 분들을 대상으로 정리했기 때문에 가능한한 간결하고 직관적으로 내용들을 표현했으며 깊게 들어가는 내용들은 거의 생략을 하였습니다.
자세한 내용들을 원하시면 프레젠테이션 중간중간에 관련 link를 첨부하였으니 같이 보시면은 도움이 되실것 같습니다.
Spring framework 3.2 > 4.0 — themes and trendsArawn Park
제 13회 한국 자바 개발자 컨퍼런스 커뮤니티 세션에서 공유한 `Spring Framework 3.2 > 4.0 — Themes and Trends` 의 발표 자료
Spring Framework 3.1에 공개된 후 약 1년만에 Spring Framework 3.2개 공개되었습니다.
3.2에는 비동기 요청 처리와 향상된 JAVA 7 지원, Spring MVC Test framework 합류 등으로 자바 엔터프라이즈 애플리케이션을 개발하는데 있어 편리함과 함께 세련미를 더해주고 있습니다.
최근 Spring Framework 핵심 개발자인 Juergen Hoeller는 springsource blog에 "NEXT STOP: SPRING FRAMEWORK 4.0"라는 제목으로 앞으로 Spring Framework에 어떤 변화들이 찾아올지에 대해서 미리 귀뜸을 해주었습니다.
이 시간을 통해 Spring Framework 3.2의 새로운 기능들과 개선사항을 살펴보고, Spring Framework의 미래 모습에 대해 이야기를 나눠보는 자리를 만들고자 합니다.
2015 년 오픈클라우드 엔진 핸드북입니다. 지난 2012년 부터 3년간의 국산 오픈소스 플랫폼 제품들을 클라우드 컴퓨팅의 주제로 통합하고 있는 프로젝트입니다. 본 자료는 기업과 서비스 제공자 들의 클라우드 컴퓨팅 전환에 있어 요구되는 사항들을 짚어보고, 2015년 지금까지 노력해온 오픈클라우드엔진의 제품들이 어떻게 그 요구사항들에 부합될 수 있는지에 대한 내용을 담고 있습니다.
[Uws] enterprise application architecture, msa, java9, spring 소개HYUN-JOO LEE
회사 교육용으로 만든 자료입니다. 엔터프라이즈 어플리케이션 아키텍처의 개념부터 시작하여 마이크로서비스 아키텍처와 기존 모놀리식 아키텍처 비교하고 왜 우리가 자바9에 집중해야 하는지 설명하려고 만든 자료입니다. 현재 회사에서 진행하고 있는 클라우드 어플리케이션 통합/아키텍처링 사업과 PoC 플랫폼 개발을 위한 회사 내부 교육용으로 만들었습니다. MSA 부분은 IBM Blumix 밋업 자료에서 발췌했습니다. 잘못된 부분이나 다른 의견이 있으신 분 댓글이나 메세지 주세요. hjlee@uws.co.kr
Spring framework 3.2 > 4.0 — themes and trendsArawn Park
제 13회 한국 자바 개발자 컨퍼런스 커뮤니티 세션에서 공유한 `Spring Framework 3.2 > 4.0 — Themes and Trends` 의 발표 자료
Spring Framework 3.1에 공개된 후 약 1년만에 Spring Framework 3.2개 공개되었습니다.
3.2에는 비동기 요청 처리와 향상된 JAVA 7 지원, Spring MVC Test framework 합류 등으로 자바 엔터프라이즈 애플리케이션을 개발하는데 있어 편리함과 함께 세련미를 더해주고 있습니다.
최근 Spring Framework 핵심 개발자인 Juergen Hoeller는 springsource blog에 "NEXT STOP: SPRING FRAMEWORK 4.0"라는 제목으로 앞으로 Spring Framework에 어떤 변화들이 찾아올지에 대해서 미리 귀뜸을 해주었습니다.
이 시간을 통해 Spring Framework 3.2의 새로운 기능들과 개선사항을 살펴보고, Spring Framework의 미래 모습에 대해 이야기를 나눠보는 자리를 만들고자 합니다.
2015 년 오픈클라우드 엔진 핸드북입니다. 지난 2012년 부터 3년간의 국산 오픈소스 플랫폼 제품들을 클라우드 컴퓨팅의 주제로 통합하고 있는 프로젝트입니다. 본 자료는 기업과 서비스 제공자 들의 클라우드 컴퓨팅 전환에 있어 요구되는 사항들을 짚어보고, 2015년 지금까지 노력해온 오픈클라우드엔진의 제품들이 어떻게 그 요구사항들에 부합될 수 있는지에 대한 내용을 담고 있습니다.
[Uws] enterprise application architecture, msa, java9, spring 소개HYUN-JOO LEE
회사 교육용으로 만든 자료입니다. 엔터프라이즈 어플리케이션 아키텍처의 개념부터 시작하여 마이크로서비스 아키텍처와 기존 모놀리식 아키텍처 비교하고 왜 우리가 자바9에 집중해야 하는지 설명하려고 만든 자료입니다. 현재 회사에서 진행하고 있는 클라우드 어플리케이션 통합/아키텍처링 사업과 PoC 플랫폼 개발을 위한 회사 내부 교육용으로 만들었습니다. MSA 부분은 IBM Blumix 밋업 자료에서 발췌했습니다. 잘못된 부분이나 다른 의견이 있으신 분 댓글이나 메세지 주세요. hjlee@uws.co.kr
『클라우드 시스템을 관리하는 기술』 - 맛보기복연 이
토머스 리몬첼리 외 공저 / 류광 옮김 | 한빛미디어 | 2016년 2월 | 36,000원
예스24: http://www.yes24.com/24/goods/24557610
“클라우드 규모 서비스를 실현하는 이론과 실전 노하우를 정리한 지침서”
이 책은 대규모 클라우드 인프라와 서비스의 구조와 설계 패턴, 그리고 이를 운영하는 방법까지, 시스템과 팀이 유기적으로 움직이는 비법을 제시한다.
저자들의 구글, 엣시(Etsy), 트위터, 페이스북, 넷플릭스, 아마존 등 거대 기업에서의 사례와 경험에서 시기를 타지 않는 근본적인 원리(principle)와 관행(practice), 특정 제품이나 시스템을 선택할 때 독자가 반드시 살펴봐야 할 품질 요소들을 이 책에 담았다. 이러한 접근법 덕분에 시간이 흘러 기술이 변해도 독자는 이 업계에서 여전히 준비된 전문가로 남게 될 것이다.
시스템공학 기본(Fundamental of systems engineering) - Day1 se generalJinwon Park
* 폰트가 지원되지 않아 다운로드 받아 내용 보시길 추천합니다.
조선소/해군 등 함정공학 분야에 종사하는 설계전문가를 대상으로 개발된 '시스템공학 기본(Fundamental of systems engineering)' 강의자료로 시스템공학 전반에 대한 이론과 실습으로 구성되어 개념설계에 참여하는 전문가에 대한 속성 교육자료입니다. 함정공학이나 특수선설계, 방위사업분야에 관심있는 분에게 유용할 것으로 봅니다. 교육자료는 다음과 같이 구성되었습니다.
Day1. SE general
Day2. Requirement Development
Day3. Requirement analysis and OMOE
Day4. Functional analysis and allocation
Day5. Design synthesis 1
Day6. Design synthesis 2
Day8. System analysis and control 1
Day9. System analysis and control 2
* Day7은 '통계분석 및 설계최적화'로 자료보다는 실습위주로 운영되어 별도 자료는 없습니다.
* 자료 관련 문의사항 있으시면 jwpark1@gmail.com으로 연락 바랍니다.
2. 유즈케이스 모델링 (Use case Modeling) 2 2010-09-15 Intelligent Systems Research Lab.
3. 유즈케이스 모델 시스템의 행위 기술 시스템의 기능적 측면을 사용자 관점에서 설명하는 명시적 모델 시스템에서 제공되어야 할 기능을 기술 3 2010-09-15 Intelligent Systems Research Lab.
4. 유즈케이스 모델 특성 사용자의 기능적 요구사항을 정의하는 직관적인 방법 개발하고자 하는 시스템과 시스템 사용자와의 관계를 정립하는 도구 사용자가 원하지 않는 시스템의 기능을 식별하는 것도 중요 개발자와 사용자간 상호 의사소통의 수단 Use Case Model은 시스템 개발 전 단계에 걸쳐서 영향을 미침 구현 문제는 생각하지 않음 4 2010-09-15 Intelligent Systems Research Lab.
5. 유즈케이스 모델 구성 요소 액터:시스템과 상호작용하는 주체 유즈케이스: 시스템의 기능 행위를 표현 유즈케이스 명세서 :각가의유즈케이스의 처리 흐름을 기술한 문서 유즈케이스 다이어그램 :시스템 영역내의 유즈케이스와액터간의 관계를 도식화 5 2010-09-15 Intelligent Systems Research Lab.
6. 유즈케이스 모델 Use-Case Model 유즈케이스의 관점에서 시스템의 기능적 요구사항을 묘사하는 모델 시스템의 의도된 기능성(유즈케이스) 및 그와 관련된 환경(액터) Actors Use Cases ... Use-Case Specifications 6 2010-09-15 Intelligent Systems Research Lab.
7. 액터(Actor) 액터는 클래스의 스테레오타입 액터는식별자; 사용자는 하나의 인스턴스 액터는유즈 케이스를 발견하는 기준 시스템 외부에서 시스템과 직접적으로 상호작용 하는 어떤 것 시스템으로부터 입력을 제공하거나 출력을 획득 액터 7 2010-09-15 Intelligent Systems Research Lab.
8. 유즈케이스 유즈케이스의 정의 특정 액터를 위해 측정 가능한 결과치를 제공하기 위해 시스템에 의해 수행되는 일련의 트랜잭션 하나의 유즈케이스는 반드시 액터에게 어떤 가치를 제공 시스템이 사용될 때 어떻게 행동할 것인가에 대한 응집된 이야기 각각의 액터가 시스템을 사용하는 목적을 달성하도록 하기 위해서 시스템이 제공해야 하는 기능. 어떠한 기능들이 시스템에 의해서 액터에게 제공될 것인가를 정의 시스템의 유즈 케이스를 모아 놓은 것은 시스템이 사용되어지는 모든 방법들을 구성 사용자 관점 특정 액터가 시스템을 통해 수행하는 일련의 행위들(sequence of actions)을 모아놓은 것 액터의 요구에 의해 시스템이 어떻게 사용될 것인가를 표현 시스템이 액터에게 어떤 서비스를 제공하는지를 표현 고객의 입장에서 본 기능적인 요구사항 유즈케이스는 그 자체로 완전하고 하나의 의미를 갖는 업무 처리 단위 8 2010-09-15 Intelligent Systems Research Lab.
9. 유즈케이스 유즈케이스는 요구사항에 대한 문서화 목적이 아니라, 요구사항 파악을 목적으로 한다 유즈케이스는 그 자체로 요구사항이다 별도의 요구사항 목록으로 재정의 할 필요 없음 유즈케이스가 요구사항의 전부는 아니다. 유즈케이스는 시스템 행위의 기능적 측면만 표현 성능(Performance), 신뢰성(Relaibility), 사용성(Availability)등 비기능적 요구사항을 표현하지는 못함 비기능적 요구사항은 별도의 요구사항 목록으로 작성 필요 9 2010-09-15 Intelligent Systems Research Lab.
10. 유즈케이스 유즈케이스 식별을 위한 질문 리스트 각 액터들이 해야 하는 일은 무엇인가? 시스템에서 정보를 생성, 저장, 변경, 삭제 또는 조회하는 액터가 있는가? 어떠한 유즈 케이스가 이러한 정보를 생성, 저장, 변경, 삭제 또는 조회하는가? 갑작스러운 외부의 변경사항을 시스템에 통지하는 액터가 있는가? 시스템에서 발생하는 어떤 상황들을 보고 받아야 하는 액터가 있는가? 어떠한 유즈 케이스들이 시스템의 지원과 관리를 수행하는가? 이 유즈 케이스들에 의해 시스템의 모든 기능적인 요구 사항들이 수행될 수 있는가? 10 2010-09-15 Intelligent Systems Research Lab.
11. 유즈케이스 다이어그램 Usecase Diagram 시스템의 기능적 요구사항을 표현, 시스템의 사용자(액터)와 시스템 간 정형적인 상호작용 기술 사용자 관점에서 시스템 행동을 조직화하고 Modeling 11 2010-09-15 Intelligent Systems Research Lab.
12. 유즈케이스 명세서 유즈케이스 그 자체는 “WHAT”에 관한 문제 유즈케이스 명세서는 “HOW”에 관한 문제 “어떻게 구현할 것인가”가 아니라 “내부 업무 흐름이 어떠한가?”임 구현에 대한 How가 아니라 업무에 대한 How 2010-09-15 12 Intelligent Systems Research Lab. <Use Case 이름> 개요 관련 액터 사전조건 Flow of Event 사후조건 특별요구사항 <Use Case 이름> 개요 관련 액터 사전조건 Flow of Event 사후조건 특별요구사항 고객정보관리 구매성향분석
13. 유즈케이스 명세서 Flow of event 유즈케이스의 작업이 완료되기 위한 여러 비즈니스 이벤트의 흐름(Scenario) 시스템외부 발생 상황은 기술하지 않는다. 액터와유즈케이스간 정보 교류 기술. UI에 관한 내용은 언급하지 않는다. 가능한 쉬운 용어 사용 해당 유즈케이스에 관한 것만 기술. 자세하게 기술하기 보다는 정확하게 기술 Basic Flow(기본흐름) 일반적인 흐름을 기술. 잘못된 경우는 기술하지 않음 Alternative Flow(대체흐름) 선택사항 예외사항(Error) 유즈케이스size가 큰 경우 13 2010-09-15 Intelligent Systems Research Lab.
14. 유즈케이스 명세서 유즈케이스 명세서 작성 지침 액터의 관점에서 작성 너무 세부적이지 않지만 정확하게 작성 요구사항을 수집하고 정의하기 위해서 작성하는 것이지, 세부적인 분석, 설계를 하는 것은 아니다. 완벽한 유즈케이스를만들수도 없고, 만들려고 노력할 필요는 없다. 유즈케이스 명세서는 액터와유즈케이스간 상호작용을 설명한다. 고객은 현금 인출카드를 넣고 비밀번호를 입력한다. 시스템은 잔고에서 일정액을 차감한다. 2010-09-15 14 Intelligent Systems Research Lab.
15. 유즈케이스 명세서 액터의 움직임이 아닌 의도를 보여준다 사용자 인터페이스에서 사용자의 움직임을 서술할 필요 없음(인터페이스 상세 서술) 문서가 길수로 읽기 어렵고, 유지보수 비용도 높아진다. 서술된 대화(Dialogue)는 요구사항이기 보다는 그 순간에 작성자가 사용자 인터페이스를 상상하는 것에 가깝다. 대화(Dialogue)는 시스템이 조금만 변경되어도 작성된 부분을 무효로 할 수 있다는 점에서 불안정 사용자 인터페이스의 의도를 파악 일반적으로 한쪽 방향으로 전달되는 모든 데이터는 한 개의 행동 단계로 표현한다. 2010-09-15 15 Intelligent Systems Research Lab. 1.시스템이 이름을 묻는다. 2.사용자가 이름을 입력한다. 3.시스템이 주소를 묻는다. 4.사용자가 주소를 입력한다. 5.사용자가 ‘확인’을 클릭한다. 6.시스템은 사용자 정보를 보여준다. 1.사용자가 이름과 주소를 입력한다. 2.시스템은 사용자 정보를 보여준다.
16. 유즈케이스 명세서 작성 서식 유즈케이스 명 개요 짤막한 문장으로 해당 유즈케이스의 목적과 역할에 대해 기술 관련 액터 해당 유즈케이스와 상호작용하는 액터 사전조건(Pre-Condition) 유즈케이스가시작되기전에 반드시 만족해야 하는 조건 예) 주문 상품 변경을 위해서는 해당 주문이 결제가 미완료 상태이여야 함. 이벤트 흐름(Flows of Events) 해당 유즈케이스에서 시스템에 해야 하는 행위에 대한 서술(textual description) 복수의 이벤트 흐름이 존재(기본흐름, 대체흐름, 예외흐름) 사후조건(Post-Condition) 유즈케이스가 종료되면서 반드시 만족해야 하는 조건 특별 요구사항 2010-09-15 16 Intelligent Systems Research Lab.
17. 유즈케이스 명세서 2010-09-15 17 Intelligent Systems Research Lab. 상품구입 I.관련액터 고객액터 II.기본흐름 1. 고객이 상품목록을 찾아보고, 구매할 상품을 선택한다. 2. 고객이 계산을 시작한다. 3. 고객이 배송정보를 입력한다.(주소, 익일배송인지 일반배송인지) 4. 시스템에서는 배송비를 포함한 총 금액을 보여준다. 5. 고객이 신용카드 정보를 입력한다. 6. 시스템이 구매를 승인한다. 7. 시스템이 판매가 완료되었음을 즉시 확인한다. 8. 시스템이 확인메일을 고객에게 발송한다. III.대체흐름 3A.고객이 단골고객인 경우 1. 시스템이 현재의 배송비, 가격, 지불정보를 표시한다. 2. 고객이 기본사항을 그대로 이용하거나, 정보를 갱신한 후, 6번으로 간다. 6A.시스템이 신용카드 승인에 실패한다. 1.고객이 신용카드 정보를 다시 입력하거나, 취소한다.
18. 실습 과제 Thinkwise로 작성한 요구사항을 기능적 요구사항, 비기능적 요구사항으로 구분 기능적 요구사항을 유즈케이스 다이어그램으로 나타냄 유즈케이스 명세서를 작성 유즈케이스 명세서 템플릿은 홈페이지에 업로드 2010-09-15 18 Intelligent Systems Research Lab.
19.
20. 슬라이드 마스터 메인페이지, 제목페이지 두 장만 업로드레포트 2010-09-15 19 Intelligent Systems Research Lab. 추석특집 숙제!!
21. 참고자료 Usecase사이의 관계 Include 관계 하나의 유즈케이스가유즈케이스 내의 작업 흐름의 과정 안에 다른 유즈케이스의 작업 흐름을 포함하는 관계 여러 유즈케이스들 간에 비슷한 작업이 공통으로 발생하는 경우 특정 부분을 하나의 유즈케이스로 따로 분리하고 정의 A A <<include>> 구조화 C B B <<include>> 20 2010-09-15 Intelligent Systems Research Lab.
22. 참고자료 Usecase사이의 관계 Extend 관계 하나의 유스케이스의 흐름이 다른 유스케이스 내의 작업 흐름의 과정에 추가되어 작업 흐름을 확장하는 관계 <<extend >> A A 구조화 <<extend>> <<extend >> 21 2010-09-15 Intelligent Systems Research Lab.
23. 참고자료 Usecase사이의 관계 Generalization 관계 객체 지향 개념에서의 상속 관계와 유사해서 자식 유스케이스가 부모 유스케이스가 가지는 속성, 작업 흐름, 확장 지점, 다른 유스케이스와의 관계 등을 모두 가진다는 의미 현금결제 결제 카드결제 22 2010-09-15 Intelligent Systems Research Lab.
24. 유스케이스 작성에 대한 10가지 잘못 다른 형태의 요구사항 문서는 만들 필요가 없다. [유스케이스]면 요구사항을 충분히 반영할 수 있다. 아니다. 요구사항 문서는 요구사항을 가장 잘 반영할 수 있는 형태의 문서로 만들어야 한다. 데이터베이스 설계에 대한 요구사항은 ER모델이 적합하고, 화면 구조에 대한 요구사항은 그래픽이 가미된 문서가 더 적합하다. 읽는 사람이 [유스케이스]의 목적에 대해 이해하기 힘들게 한다. [유스케이스]의 이름을 지을 때 ‘작업하다’, ‘처리하다’와 같은 말을 사용하여 혼란스럽게 한다. 만약 읽는 사람을 혼란스럽게 하는 데 성공했다면 [유스케이스]를 실제로 구현할 때 어떻게 해도 상관없을 것이다.[유스케이스]를 이용해서 효과적으로 소프트웨어 시스템을 구현하기 위해서는 명확하게 [유스케이스]를 작성할 필요가 있다. 간혹 어떻게 [유스케이스]를 작성해야 하는지 모르는 경우에 이렇게 처리하는 경우가 있는데 좋지 않은 모습이다. [유스케이스]의 범위에 대해 혼란스럽게 한다. 범위는 어차피 점점 퍼져나갈 것이고 나중에 리펙토링을 하면 된다. 사용자는 어차피 생각을 계속 바꿀 것인데 왜 성가시게 범위를 미리 확정하겠는가?[유스케이스]는 만들려고 하는 시스템이 어떠한 범위를 다루는지를 표현하는 것에도 사용된다. 시스템의 범위를 명확히 하고 그것을 여러 관여자가 충분히 이해할 수 있도록 [유스케이스]를 작성해야 한다. 23 2010-09-15 Intelligent Systems Research Lab.
25. 유스케이스 작성에 대한 10가지 잘못 [유스케이스] 기술서에 비기능적 요구사항과 사용자 인터페이스 디테일을 포함시킨다.유스케이스의 작업 흐름에 사용자 인터페이스에 대한 세부 내용을 포함시키면 작업 흐름이 늘어나게 된다. 사용자 인터페이스를 요약한 내용을 추가하면 되지 상세한 내용까지는 포함시킬 필요가 없다. 초기 [유스케이스] 다이어그램에 포함 관계와 확장 관계를 많이 사용한다. 그러면 유스케이스를 작은 단위의 것으로 나눌 수가 있다.초기 버전의 유스케이스는 상위레벨의 유스케이스를 작성하고 반복을 거치면서 보다 상세화한 유스케이스를 작성하는 것이 좋다. CRUD를 처리하는 유스케이스가 대표적인데, 초기에는 ‘관리하다’라는 유스케이스로 하나로 만들고 이후에 반복을 통해 ‘생성’, ‘조회’, ‘수정’, ‘삭제’ 유스케이스로 세분화한다. 비즈니스 룰을 정의하는 것에는 관여하지 말라.비즈니스 룰을 만들고 사용하는 것은 사용자이지만 그것을 산출물로 표현하도록 하는 것은 매우 중요하다. 룰 자체를 만드는 것에는 관여할 필요가 없지만 그것을 [유스케이스]를 통해 표현하도록 독려해야 한다. 24 2010-09-15 Intelligent Systems Research Lab.
26. 유스케이스 작성에 대한 10가지 잘못 [유스케이스]의 작성에 도메인 전문가를 관여시키지 말라. 그들은 질문이나 해댈 뿐이다.[유스케이스]는 요구사항에 대한 표준 표기법인데, 소프트웨어 시스템에 대한 요구사항을 가장 잘 알고 있는 것은 도메인 전문가이다. 물론 이들이 작업을 성가시게 할 수도 있지만 좋은 결과를 내기 위한 고통이라 생각해야 한다. 만약 사용자를 [유스케이스] 정의에 관여시킨다면 그냥 그래라. 왜 사용자와의 미팅을 준비하는 데 골머리를 썩힐 것인가? 많은 양의 문서나 만들게 되고, 어쨌든 그들은 계속 마음을 바꾸게 될 것이다.될대로 되라는 식의 태도는 좋지 않다. 사용자에게 [유스케이스]를 충분히 이해시키고 [유스케이스]를 통해 효과를 볼 수 있도록 노력해야 한다. [유스케이스]를 한 번에 아주 상세하게 만들어라.반복적으로 점증적으로 [유스케이스]를 작성하는 것이 좋다. [유스케이스]를 검증하거나 평가하지 말라. 재작업이나 만들어 낼 뿐이다.반복적으로 점증적으로 작성하고 중간중간 계속 사용자나 도메인 전문가의 피드백을 받아야 한다. 25 2010-09-15 Intelligent Systems Research Lab.
30. 유즈케이스 유즈케이스 식별을 위한 질문 리스트 각 액터들이 해야 하는 일은 무엇인가? 시스템에서 정보를 생성, 저장, 변경, 삭제 또는 조회하는 액터가 있는가? 어떠한 유즈 케이스가 이러한 정보를 생성, 저장, 변경, 삭제 또는 조회하는가? 갑작스러운 외부의 변경사항을 시스템에 통지하는 액터가 있는가? 시스템에서 발생하는 어떤 상황들을 보고 받아야 하는 액터가 있는가? 어떠한 유즈 케이스들이 시스템의 지원과 관리를 수행하는가? 이 유즈 케이스들에 의해 시스템의 모든 기능적인 요구 사항들이 수행될 수 있는가? 2010-09-15 27 Intelligent Systems Research Lab.
31. 액터(Actor) 액터 도출 가이드 어떠한 요구사항에 관심을 가지는 사람은 누구인가 ? 조직 안에서 시스템이 사용되는 곳이 어디인가 ? 누가이 시스템을 사용함으로 이익을 얻는가 ? 누가 시스템에 이 정보 (예.학생정보)를 제공하고 사용하고 제거시키는가 ? 누가 시스템을 관리하고 지원할 것인가 ? 시스템은 외부 자원을 사용하는가? 한사람이 여러 역할을 하는가 ? 여러 사람이 같은 역할을 하는가 ? 액터는 시스템을 사용하는 역할이기 때문에 한 사람이 여러 역할을 한다면 여러 액터가 되는 것이고 여러 사람이 같은 역할을 하고 있다면 하나의 액터가 되는 것이다 시스템이 기존 시스템과 상호 작용하는가 28 2010-09-15 Intelligent Systems Research Lab.