본문 바로가기

별걸다하는 IT/기타IT

[시스템설계] USE CASE DIAGRAM 유스케이스 다이어그램에 대한 상세 과정과 개념 정리

반응형

안녕하세요 양햄찌 주인장입니다 ㅎㅎ

오늘은 무슨 포스팅을 할까~~~~ 고민을 하다가,

소프트웨어 공학 또는 시스템 설계에 관련된 포스팅이 아직 없는 것 같아 하나 작성해보려고 해요.

UseCase Diagram 유스케이스 다이어그램이란?

혼자 개발할 땐 사실 코딩부터 하기 일수지,

일정을 나눠서 기한에 관한 도표를 그리고, 꼭 필요한 기능 목록들을 나열해서 정리해보고, 유저 입장에서 어떤 흐름으로 흘러갈건지 그림을 그려보고 테이블 명세서를 세세하게 작성하고 등등... 이렇게 하는 사람은 거의 없죠..?!

 

하지만 회사에서 진행하는 프로젝트들은 규모가 크기 때문에 혼자가 아닌 여러 개발자가 나눠서 분담하는 경우가 많고

담당자가 아닌 이후 인력을 위해서라도 문서 작성이 필수입니다!!

그리고 당연히 프로젝트를 체계적으로 계획을 해서 진행해야 원하는 방향으로 이끌어 기한 내 목적을 달성할 수 있겠죠~ 이 외에도 설계와 문서의 중요성에 대해 여러가지 이유가 있는데

오늘 포스팅의 주인공은 유스케이스이므로!! 어느정도 안다는 가정하에 포스팅을 진행하도록 할게요

 

혹시 이렇게 생긴 그림을 보신적이 있으신가요??

위 그림이 바로 Use Case 다이어그램이랍니다. ㅎㅎ 유즈케이스 다이어그램이란 개발하고자 하는 시스템을 목적에 맞게 사용자 입장에서 시나리오를 최적화 다이어그램입니다.

USE CASE는 개발하고자 하는 시스템이 어떤 용도로 쓰일 수 있는지 체계적으로 하기 위해서 머릿속으로 그림을 그려보는 거예요. 

바로~ 저렇게 그림을 그리는건 아니고요 (시스템이 복잡할 수록 정리하기 힘들답니다) 그리기 위한 과정을 알아봅시다!

 

Two techniques for identifying use cases 

유스 케이스를 구분하기 위한 두 가지 방법.

▶User goal technique

▶Event decomposition technique

 

유즈케이스 그리기 위한 밑작업 첫 번째 방법

USER GOAL TECHNIQUE

 

잘 정돈된(?) 그림을 그리기 위해서는 먼저 user goal technique이 명확해야 합니다.

개발하다 산으로 가면 안되니 결국 시스템의 메인 목적!이 당연히 명확해야겠죠.

 

Use Case 라는 단어자체가 쓰임새라는 뜻인데요,

A use case is an acitivity the system performs, usually in response to a request by a user. 

그 중 use case는 이 시스템을 사용하고자 하는 유저 입장에서 여러 요구사항들이 있을 건대 시스템이 사용자를 만족시키기 위해 제공하는 기능들을 정리한 것이라 생각하면 돼요 ㅎㅎ

 

사진출처: Introduction to Systems Analysis and Design

자 여기 어떤 시스템의 유저goal을 정리해놓은 샘플 테이블을 봅시다.

해당 시스템을 사용할 전체 유저를 다 뽑아서 정리할 필요는 없어요!

가장 메인이 될 특정 계층을 분류한 다음, 각각 계층이 내 시스템을 사용할 때 어떤 기능이 필요한지를 도출하는 과정입니다.

 

자 이 RMO CSMS라는 시스템은 주된 사용자로 잠재적고객(Potential Customer), 마케팅 매니저 (Marketing manager), 운송 직원 (Shipping personnel)을 뽑았네요.

그리고 고객에게는 '아이템 검색', '장바구니 담기', '제품 별점과 댓글 확인하기'등이 이 시스템을 사용하는데 꼭 필요한 기능으로 도출되었어요.

 

아~ 판매사이트 만들어야지~ 이렇게 막연히 생각하기보다, 내가 판매사이트 만들면 일단 가장 많은 사용자는 고객이겠지? 그리고 판매사이트를 이용하는 고객에게는 어떤 기능이 필요할까. 이렇게 분석함으로써 좀더 체계적으로 개발 방향을 잡을 수 있는거죠ㅎㅎ USER GOAL TECHNIQUE은 각 계층마다 필요한 것을 도출하는 가장 간단한 방법입니다.

이를 도출하는 방법으로는 설문지가 있을 수도 있고, 직접 체험해볼 수도 있고, 그 부서에서 어떤 문서 형식을 사용하는지 참고해도 얻을 수 있고, 관련 기업의 의견들을 취합해서 얻는 등 다양한 방법이 있을 수 있습니다.

 

유즈케이스 그리기 위한 밑작업 두 번째 방법

EVENT DECOMPOSITION TECHNIQUE

유저 골을 도출하는 방법 말고 또 다른 방법 하나는 이벤트를 분해하는 방법입니다.

이벤트는 무엇을 이벤트라고 하나요? 시스템은 가만히 있으면 동작을 하지 않아요.

결국 이벤트가 있을 때 프로세스를 통해서 원하는 결과를 도출하는데 그렇게 시스템이 동작할 때 조건이 이벤트입니다.

사진출처: 사진출처: Introduction to Systems Analysis and Design

이벤트의 종류는 3개로 나눠볼 수 있습니다.

1. External event 외부 이벤트

2. Temporal event 시간적 이벤트 

3. State event 상태 이벤트 

 

사람 모양의 아이콘 세 개는, 유저의 액션에 의해서 동작되는 external events입니다.

한 예로 유저가 반품을 하기 위해 반품 버튼을 누른다던가 그런건 다 external event 외부 이벤트가 되는거죠!

고객이 주문하거나 장바구니에 담는다던가 이런건 다 외부이벤트입니다. 유저에 의해서 동작한다는 특징이 있어요.

 

그리고 가운데 시계 아이콘은 temporal event라고 해서 특정한 시간이 동작 됐을 때 자동으로 실행되는 이벤트예요.

뭐 매달 말일 판매실적이 엑셀파일로 저장된다던가 이런건 시간에 따라 동작하는 이벤트겠죠!

 

state event라는 것도 있는데 이는 상태가 변화되었을 때 동작하는 이벤트를 말합니다.

한 예로 주문을 받았는데 재고가 없어요, 그럼 주문에 대한 배송은 재고가 채워 졌을 때 돌아갈 수 있겠죠?

 

USE CASE TABLE 유스케이스 테이블 

위의 방법들로 도출한 USE CASE를 표로 정리한 게 USE CASE TABLE입니다. 

시스템이 처리할  있는 기능적인 것을 use case 뽑고

시나리오를 최적화 하기 위해서 이런 use case 뽑습니다.

사진출처: 사진출처: Introduction to Systems Analysis and Design

이름을 보면 대략적으로 어떤 역할을 하는지 알지만 세부적으로 없기 때문에 문장 형태로 상세하게 기술해 놓은 것이 오른쪽 컬럼의 Description이예요. 왼쪽에 있는 use case이름보다 오른쪽의 description이 문장형태로 세밀하게 기술되어 있기 때문에 시나리오를 정확하게 알게 도움이 됩니다.

 

그런데 사실 이 description도 충분하지 않아요. 그래서 나중에 fully use case description(유스케이스 기술서)을 추가로 작성하게 되는데 여기서 사전조건 사후조건, actor 등 여러 내용들이 더 세부적으로 들어가게 된답니다. 

 

USE CASE 다이어그램 구성요소 

그럼 이제 그림을 그리기 전에 각각 심볼들이 무엇을 의미하는지 봅시다. 

사진출처: 사진출처: Introduction to Systems Analysis and Design

1. 졸라맨 

요기 맨 왼쪽에 보이는 졸라맨 있죠! 보통 유저를 이렇게 졸라맨으로 표시하고 공식적인 용어로는 actor라고 부릅니다.

결국 actor는 시스템을 사용하는 사용자를 말해요. 

 

2. 박스

박스는 시스템을 말해요. 큰 시스템은 하위 시스템 여러개로 이루어져 있을 수도 있다는거!

 

3. 타원형 동그라미

그리고 타원형은 우리가 그동안 정리했던 use case를 나타냅니다. 

 

4. 선

졸라맨과 use case 동그라미 사이에 선이 있는 것을 볼 수 있는데요. 관계를 나타냅니다.

졸라맨에 연결되어 있는 선을 따라가면 액터가 어떤 기능을 사용할 수 있는지 알 수 있게 해주는거죠.

 

사진출처:사진출처: Introduction to Systems Analysis and Design

자 위 그림을 봅시다. 좌우에 졸라맨이 두 마리 보여요. 즉 이 시스템에는 actor가 두 명이 있다는 거죠! 

그리고 각각의 actor 시스템을 사용할 있는 기능을 타원형으로 표현했어요.

매니저는 공급자를 찾아볼 수 있는 기능(Look up supplier)이 있고, 연락정보를 입력하거나 업데이트 할 수 있는 기능이 (Enter/update contact information) 있죠.

 

결국 시스템을 사용하는actor 어떤 기능을 사용할 있는지 있는 그림이기 때문에 use case diagram이라고 합니다. 요 다이어그램은 결론적으로 시나리오를 표현하는 그림이예요.

그러므로 위 그림의 경우 "구매 에이전트는 4가지 시나리오를 활용할 있고 매니저라고 하는 actor 가지 시나리오를 활용할 있다" 이렇게도 표현할 수 있어요.

 

유즈케이스에서 스테레오타입 표기법 알아보기 (포함관계, 확장관계)

사진출처: Introduction to Systems Analysis and Design

요 그림을 봅시다. 어라? 선은 실선만 있는줄 알았는데 점선에다가 include라고 써있네요..?

요런걸 스테레오타입 표기법이라고 하는데 두 가지가 있습니다.

하나는 그림에서 보이는 include가 있고, 또 다른 하나는 extend가 있어요. 우리말로는 포함관계, 그리고 확장관계라고 얘기합니다. 

 

include - 포함 관계

extend - 확장 관계

 

◆ INCLUDE 포함관계란?

이게 두 관계가 머냐! use case 세밀하게 표현하는 방법이라고 생각하면 됩니다.

그림을 볼까요? 왼쪽에 보이는 actor 고객은 장바구니 채우는 기능이 있어요. (fill shopping cart)

그리고 이 유즈케이스는 '아이템 검색(search for item)'과 includes로 연결되어 있네요. 자, 생각해보면 아이템 검색을 해야 장바구니에 담을 수 있는거 아네요?? 

네 맞습니다. 개념적으로 보면 저기 include로 가리킴을 당하는 세 가지 유즈케이스(search for item, view product comments and ratings, view accessory combinations)는 장바구니를 채우는(Fill shopping cart) 기능에 포함이 되는거예요. 그니까 장바구니채우기를 하려면 저 세가지 중 하나가 먼저 선행되어야 한다는거!

사실 이렇게 생각해보면 저 세개의 유스케이스 중 하나를 통해서야, 그니까 저 기능이 진행된 다음에 '장바구니 채우기'가 이뤄지니까 '장바구니 채우기'에 화살표가 꽃혀야 할거 같은데.. 반대로 꽃혀있어서 헷갈릴 수 있어요.

정확히는 이 장바구니 채우기 기능이 저 세개의 시나리오를 참조해서 이뤄진다는 의미입니다. 그래서 화살표 방향이 use case를 포함해야 하는 쪽으로 가리키게 되는 거예요. 주변에 있는 저 세 개의 유스케이스가 장바구니담기기능을 할 때

포함이 된다. 

화살표는 먼저 수행되는 것에서 나중에 수행되는 것으로 꽃힌다!

 

◆ 좀 더 쉬운 예시를 들어볼까요!

자판기 운영자가 돈을 수거해요. 돈을 수거 때는 먼저 잠금 장치를 풀어야죠. 잠금 장치를 풀 줄 모르면 돈을 수거할 수가 없어요!

시간에 대한 선행관계가 아니고, include 관계를 갖는 요 use case 없이는 요 기능이 동작할 수 없다. 그러니까 돈을 수금할 때에도 자물통을 열고 잠그는 장치를, 잠그는 use case 없다면 수금을 못한다는 거에요. 그러니까 선행과 후행관계 보다는, 반드시 따라서 사용해야 되는 쓰임새일 경우에 include여야 된다. 없어도 되는 기능은 인클루드 관계가 아닌거죠. 반드시 포함해야 되는 관계가 include관계.

 

<<includes>> relationship

a relationship use cases in which one use case is stereotypically included within the other use case.

<<인클루드>> 관계

어떤 유스케이스가 다른 유스케이스 안에 고정적으로 포함되어야 하는 관계를 말한다. 

 

◆ EXTEND 확장 관계란?

 

사진출처: http://www.ropley.com/use-case-extend-relationships.aspx

인클루드가 꼭 포함되어야 하는 없어서는 안되는 기능이라면, 익스탠즈는 해도 되고 안해도 되고! 필수가 아닌 확장이라는 개념이예요! 

그림을 볼까요?? includes 관계를 먼저 봅시다. 고객이라는 유저가 캔음료를 사면 비용을 지불해야해요! 아무것도 안사고 비용을 지불할 수는 없다는거죠. 또 핸드폰을 충전하면 필수적으로 비용을 지불해야해요! 여기까진 바로 이해되셨을 거예요. 그런데 비용을 지불하고 영수증은 받아도 되고 안받아도 되죠?? 말그래도 그러한 기능이 있긴 한대, 확장팩처럼 확장옵션인거지 선택을 하지 않아도 되는게 extends 입니다.

 

오늘 포스팅은 여기까지입니다. 사실 유스케이스라는게 CRUD부터, 중복제거법, 유스케이스 상세기술서 등... 더 자세하게 적으려면 적을 수 있는데.. 포스팅이 아무래도 너무 길어지면 읽는 사람 입장에서도 지칠 것 같아서 중요한 부분만 추려서 정리해봤어요 ㅎㅎ 도움이 되셨다면 좋아요! 방문에 감사드립니다. 오늘도 고생많았으요~!

반응형