2. UML
• 요구분석, 시스템설계, 시스템 구현 등의 시스템 개발 과
정에서, 개발자간의 의사소통을 원활하게 이루어지게 하
기 위하여 표준화한 모델링 언어이다.
• UML is a universal visual modeling language.
• UML models the world as systems of interacting objects.
An object is a cohensive cluster of data and function.
• 세상은 object들이 상호간 interaction을 하면서 이루어지
는 시스템들의 묶음이다.
3.
4. Diagrams in UML
Diagrams
static model
(system structure)
dynamic model
(system behavior)
class diagram
component diagram
deployment diagram
object diagram
use case diagram
sequence diagram
collaboration diagram
state-chart diagram
activity diagram
6. 요구 사항 분석
• 모든 시스템은 요구 사항이 있다. 어떻게 하
면 이러한 요구 사항들은 사람들이 쉽게 이
해하고 빠진 요구 사항들을 찾아낼 수 있을
까?
• Functional Requirement
– Use Case Diagram을 그리자.
– Use Case Specification을 작성하자.
7. Use Case Modelling Step
• Find the system boundary
• Find the actors
• Find the use cases:
– specify the use case
– create scenarios
• actors
• use cases
• relationships
• system boundary
8. System boundary
• 시스템 구축을 생각하는 시점에 근본적인 요소가 바로 시
스템 범위 결정.
• 시스템 범위 따라서 요구사항이 달라진다.
• 시스템 범위란?
– inside system boundary
• 어떠한 부분들이 시스템 내부에 포함되어 구성이 되어질까?
– outside system boundary
• 어떤 것들을 시스템 외부로 칭해야 할까?
예. 변환서비스는 Docs 시스템 외부? 내부?
• use case diagram에서는 상자에 시스템 이름을 기록
9. Actor
• Actor는
– 시스템 외부에 위치.
– 시스템과 직접적인 교류가 있는 역할
• 동일한 사람이 다른 role을 취하는 경우 다른 actor
– 예. 일반 사용자 / 관리자.
• 역할이기 때문에 타 시스템도 actor로 취급
– 예. NOS Publisher (post to docs 경우)
• Who or what uses or interacts with the system?
<<actor>>
NOS Publisher
Admin Time
10. Use case
• use case는
– 앞서 정의한 actor가 시스템이 해주기를 바라는 것들.
– actor에 의해서 시작
– actor 관점에서 상세 내용이 기술된다.
• How does each actor use the system?
• What does do for each actor?
SuspendUser
11. Use Case Diagram은
시스템의 기능적 요구
사항을 분석하며, 시스템
역할을 쉽게 이해하도록
도움이 되도록 최대한
간단히 그려져야 한다.
Use Case Diagram만
그리다가 모델링 포기하는
사람이 많다.
Use Case Diagram은
점차적으로 반복적으로
갱신되면서 완성되가는
것이다.
Use Case Diagram은
최대한 단순화를 시키도록
그려간다.
12. Detail a use case
Use Case modelling을 diagram 그리
는 순간에서 마무리 하는 경우가 많다.
이로 인해 많은 문제 발생했었다. 이
로 인해 Use Case Diagram 반대론자
들도 나타났었다.
이는 상세화 과정이 없었기 때문이다.
13.
14. 예외 상황들에 대한 처리 (1)
• If / Else, For, While 기법 적용
• alternative flow: post condition에 기술
– 어느 시점에나 발생될 수 있는 상황에 대한 기술
– 예. 사용자가 사이트를 도중에 나가버린다.
15. 예외 상황들에 대한 처리 (2)
• scenario는
– 정상적인 use case 동작(primary scenario) 경우 외 경
우에 대해서 별도 use case spec.(secondary
scenarios)로 정리
– a use case = primary scenario + secondary scenarios
– scenario 사용 경우에는 branch가 없다.
• secondary scenario들은 별도 use case spec. 으
로 정리. 표기는 타이틀에 대상 Use case 기록 후
추가로 secondary scenario 명시
18. advanced topics
• Actor generalization
– 일반화 할 수 있는 역할과 세분화 가능 역할
• Use case generalization
– 일반화 가능한 use case에 이에 대해 세분화 가능한 use case 관계
• <include>>
– 특정 use case가 다른 use case를 포함하는 경우
• <<extend>>
– 기본 use case가 있고 특정 부분에 대해서 이를 확장하는 use case가 있는 경우
• 추가로 사용되는 위 개념들은 최대한 use case model을 단순화 하기
위해서만 사용되어야 합니다.
19. Actor generalization - target case
• 유사 use case가 중복되는 경우에 이에 대해서
common한 actor(role)로 처리하는 경우
21. Use case generalization
• the child use case
– 부모 use case 특정 속성들을 상속
– 새로운 특징들 또는 경우들 포함
– 기존 기능들을 경우에 따라서 구체화 (template)
• use case spec. 표기법
– normal text: 부모 use case 그대로 상속 부분
– Italic text: 특정 부분에 대해서 child 만의 특성 살림
– Bold text: child에서 추가된 부분
25. <<extend>>
• <<extend>>는 이미 존재하는 use case에 대해서 새로운 동작을 추가
하는 방법이다.
• <<extend>>되기 전에도 정상적인 use case. <<include>>가 없이는
정상적인 use case가 아닌 것과 차이가 있음.
• 예. 도서관에서 사서가 책을 반납 받는 use case.
• 반납 시점에 연체료가 있는 사용자에 대한 추가적인 조치가 필요한
use case도 있다.
