시드니랩

[Software Engineering] 8. UML 2 -Requirement Capturing, UP 본문

랩/Software Engineering

[Software Engineering] 8. UML 2 -Requirement Capturing, UP

시드니효상 2020. 10. 13. 19:12

 

 

◉ 비즈니스 프로세스에 있어서 UML의 활용 - Activity Diagram

 

 예를들어, 주문을 접수 하는 Use Case 가 있다.

주문 접수 UseCase

마찬가지로, 재고를 채워넣는 Use Case 가있다.

 

재고 채워넣기 Use Case

위 두개의 자연어 Use case를 갖고 아래 Activity Diagram을 만들 수 있다.

 

Activity Diagram은 사용 시나리오를 염두에 두고, 소프트웨어 개발 초기 에 사용하기 좋은 UML이다.

 

Activity Diagram

 

 Activity diagram에서 각 비즈니스 부서들의 Responsibility 를 나누기 위해서 Swimlane (점선)을 그리기도 한다. 

 

또, 각 프로세스를 연결하기위해 Connector (커넥터) 를 사용한다.

 

Swimlane 과 Connector

 

◉ Advanced Notation

Activity Diagram에서 사용할 수 있는 여러 notation들이 있는데, 다양한 경우에 아래 기호들을 사용할 수 있다. 

 

1. Termination : 소프트웨어 종료

2. Abort Action : 소프트웨어 일시 중지

3. Time Event : 특정 기간에만 해당 이벤트 실시

4. Exception handling : 예외처리

5. Interrupts : 특수 요청 처리 ( 고객의 소프트웨어 주문 취소 )

 

◉ Requirement Capturing

 

Use Case Model : System Behaviour 을 User 관점에서 표현한다.

 

Actor : 소프트웨어와 별도인 외부 객체로, 시스템과 상호작용을 하는 주체다. 예를들어, Buyer, Seller, Accounting System

 

모든 Actor 은 Responsibility 와 Needs 를 가지고 있고, Needs는 주로 Use Case 가 된다.

 

Use cases

빨간색 밑줄이 각 Actor의 Needs이다. 

 

이를 바탕으로 아래 Use Case Diagram 을 만들어 낼 수도 있다.

 

Use Case Diagram

 

 

예시 : Pay Invoice Usecases

 

1. 일반적인 이벤트의 시나리오 Flow 를 작성

 

2. 일반적이지 않은 Alternative Flow Path 작성

 

3. 예외 작성

 

4. Use Case 이후의 Postconditions 작성

 

Use Case 작성 이후 진행해야할 사항은 아래와 같다.

 

After Use Case 

 

☞ Structuring Use Cases 

 

각 Use Case의 관계를 정의한다.

예를들어, place order 은 반드시 validate user을 포함한다거나,

check password는 반드시 validate user을 한다던가.

 

하지만 반드시 모든 Usecase를 사전설계 하는것이 아니라 20%만 위 과정에 투입한다. 

 

But only Critical Use cases which is about 20% of the entire use cases.

 

Critical Usecase 는 일반적으로,

 

- 시스템 아키텍처에 영향을 준다거나

 

- 설계시 절대 변하지 않는 부분 ( 예를들어, 자바 스프링프레임워크로 진행을할때 스프링 프레임워크를 사용한다는 사실 )

 

 

 

◉ Unified Development Process

 

Incremental and iterative

 - Final version 에 도달할때 까지 repeat하며, 내용 추가시 추가한다.

 

Use Case Driven

- 각 Iteration 마다 재확인

 

Architectural Centric 

- Unchange 하는 특징에 주목한다.

 

 예를들어, 첫 반복에서 requirements, analysis, design, implementation, test 까지의 5가지 작업이 수행된다. 첫번째 반복이 끝났음에도 불구하고 목적한 산출물이 나오지 않으면, 두번째 반복으로 이어진다. 일반적으로 각 Iteration은 2주를 넘기지 않는다!!

 

Unified Development Process

 또한, Elaboration 단계가 끝나고 Construction 단계 진입 전에는

 

반드시 모든 Architectural Decision이 Finalize 되어야 한다.

 

 

 

Comments