Architect 공부 2일차 - UML/UseCase

UML

시스템 전체 구조, 각 컴포넌트들의 관계를 시각적으로 표현 

다양한 뷰로 표현 가능한데, 이는 고객/개발자/아키/디자이너 등 다양한 관점에서 바라보기 위함

 

구현을 위한 코드레벨에서의 도구라기보다는, 다른 관점을 지닌 사람들과 의사소통을 위한 시각적 도구 정도로 인식

-> UML Fever : UML 사용 시 부작용에 대한 내용. 대표적으로는 상세하게 기술한 거대한 UML 모델

 

View

1) 3 View : Model(정적) / Component(Runtme,시스템 아키)

                  Allocation (실제 시스템이 배치되었을때 운영환경, 디플로이 등 )

2) 4+1 View : 

각 사용자 별로 시스템을 바라보는 관점 

Logical : 엔드 유저

Process : 시스템 통합

Physical : 시스템 엔지니어

Development : 프로그래머

 

1) Use Case Model

사용자와 시스템 간의 상호작용을 표현

시스템의 기능적 요구사항을 획득하는 과정.

단순히 구현 기능 리스트를 만들기 보다는, 시스템을 이해하는 과정으로써 집중

※ 지금 공부는 구현단계가 아닌, 아키텍쳐 입장에서 설계서 작성이 목적으로 하자. ( 품질속성과 연관있는 유스케이스 )

 

크게 사용자인 엑터, 시나리오인 유스케이스(시스템이 제공하는 기능) 항목으로 이루어져 있으며,

사용자와 시스템 간의 상호작용을 그려준다.

 

. 표기법

 

<<include>> 는 선행관계가 아님.

ex: 쇼핑몰 리뷰를 남길 때, 상품 구매가 선행되어야하지만 이는 include가 아닌 precondition.

      리뷰 과정에, 구매가 포함되어있지 않기 떄문. 

      대출심사 과정에는 , 심사에 필요한 서류 제출이 포함되어있기때문에 include 사용가능.

 

. 예시

 

실습

1) 특정 주제에 대해 엑터와 유스케이스 간단하게 작성하기

  + 도출된 유스케이스를 다이어그램으로 표현하기

 

2) 렌트카 예약 시스템 그려보기 + 유스케이스 1개 잡고 Description.

. 피드백

  사고 접수와, 보험사의 보험처리간 연계가 될 수 있는 유스케이스 추가 필요

  Description 에서 사후조건으로 고객은 예약메세지를 받는데, 외부시스템으로 sms/카카오톡 등의 연계가 있었으면

유스케이스명	렌터카 예약
액터	고객
개요	고객이 원하는 날짜에 렌터카를 사용하기 위해 예약을 한다.
사전 조건	고객은 유효한 운전면허증을 소지해야한다.
기본 흐름	1.고객은 시스템에 접속해 원하는 날짜와 시간을 지정한다. 2.시스템은 이용 가능한 렌터카 리스트를 보여주고, 고객은 원하는 렌터카를 선택한다. 3.고객은 운전면허증을 인증한다. 4.고객은 원하는 보험을 선택하고, 시스템은 렌트비와 보험료를 계산한다. 5.‘결제’ 유스케이스를 실행한다.
대체흐름1	3a. 유효기간이 만료된 운전면허증일 경우 3a.1 시스템은 고객에게 면허증의 만료사실을 알리고 유스케이스를 종료한다
사후 조건	사용자는 예약번호를 메시지로 받는다.

 

BP