'2019/10'에 해당되는 글 2건

1. 유즈케이스(Use case)

 사용자가 시스템을 어떻게 사용하는지를 나타내는 것.

 시스템의 기본적인 기능들(사용자가 시스템을 사용하여 어떤 일들을 할 수 있는지, 시스템이 어떤 방식으로 반응하는지)를 나타내는 것.

 하나의 유즈케이스는 사용자가 어떤 작업을 처리할 때 수행하는 일련의 과정들이다.

 유즈 케이스는 소프트웨어를 설계하는 과정에서, 건축용 블록과 같은 역할을 한다.

 각각의 유즈케이스들은 각각 하나의 역할만을 설명한다.

2. Usecase 다이어그램

2.1 Usecase 다이어그램의 기본 구성

 유즈케이스는 다음과 같은 요소들로 구성되는 다이어그램으로, UML(Unified Modeling Language)로 표현한다.

- 액터 : 시스템을 이용하려고 하는 서브젝트 외부의 사람, 혹은 시스템. 스틱맨으로 표현하기도 하고, 박스로 표현하기도 함

- 유즈케이스 : 시스템 기능의 주요한 조각.

- 서브젝트 : 주제의 범위를 나타내는 것.

예시

병원 진료 예약 시스템의 유즈케이스 다이어그램

 이 예시에서 시스템은 예약 조율, 스케줄 제공, 가능한 시간 입력이라는 기능을 제공한다.

 각각의 기능들은 유즈케이스로 표현, 진료예약 시스템이라는 Subject로 범위 제한, 액터는 환자, 관리자, 의사 이렇게 3명이다.

 각각의 유즈케이스들은 환자, 관리자, 의사라는 액터와 상호작용하므로 Association 관계로 표현한다.

2.2 Usecase 간의 관계

 유즈케이스들 간에 서로 Genalization, Inclusion, Extension 관계를 가질 수 있다.

- Genalization : 일반화(generalized)된 유즈케이스는 좀 더 자세하게 정의된 유즈케이스다.

- Inclusion : A가 B를 Include한다는 것은, A의 작업이 B를 포함한다는 것을 나타낸다.

- Extension : 예외적인 상황을 커버하기 위해 사용되는 관계.

예제

병원 진료 예약시스템 확장판

 몇 가지만 살펴보자.

 우선 환자가 예약을 하는 유즈케이스(Manage Appointments)는 환자가 신규 환자, 기존 환자 두 가지 타입으로 늘어났으니, 신규 환자 예약(Make New Patient Appt)과 기존 환자 예약(Make Old Patient Appt) 두 가지로 나누어야한다. 그래서 Genalization 관계를 적용해 두 가지 유즈케이스로 나누었다.

 새로운 환자가 예약을 잡는 유즈케이스는(Make New Patient Appt) 신규 환자 등록이라는 유즈케이스(Create New Patitent)를 포함하므로 includsion 관계로 표현한다.

 환자 정보를 업데이트하는 유즈케이스(Update Patient)는 기존 환자가 예약을 잡는 유즈케이스(Make Old Patient Appt)에서 특별한 경우(환자 데이터를 업데이트 해야하는 경우)에만 사용되므로 Make Old Appt 유즈케이스에서 확장되어 extension 관계로 표현된다. (화살표 방향을 쉽게 헷갈리므로, 헷갈리지 않게 주의)

3. UseCase Description

 유즈케이스를 문서에 포함할 땐 유즈케이스 다이어그램은 필수로 들어가야하고, 유즈케이스 Description은 선택적으로 넣는다. 유즈케이스 Description은 유즈케이스 다이어그램 작성에 필요한 모든 정보들을 담는 것으로, 하나의 UseCase Description이 하나의 UseCase를 설명한다. (유즈케이스 다이어그램 전체를 설명하는 것이 아니다.)

 개인적인 경험상 유즈케이스들마다 일일히 Description을 작성하려면 시간 소모가 커서 굳이 필요하지 않다면 생략하는게 나을 듯 싶다.

 UseCase Description은 다음의 세 부분으로 구성된다.

- Overview : 이름, ID, 종류, 가장 중요한 액터, 간략한 요약, 중요도 레벨, Stakeholders(관계자들), 트리거

- Relationships : 유즈케이스들 간의 Association, Extend, Include, Generalization.

- The flow of events : Normal flow(보통의 활동들), Sub flow(유즈케이스를 간단하게 하기 위해 Normal flow를 분해한 것), Alternate/Exceptional flow()

- 기타 사항들

예시

4. 유즈케이스 작성 요령

* Kiss 원칙 : Keep It Simple Stupid의 약자. 원칙이라기보다는 복잡한 것 보다는 간단한 게 좋다는 일종의 격언이다.

5. Use Case Description 작성 요령(순서)

6. 레퍼런스

System Analysis & Design 5th - WILEY

https://ko.wikipedia.org/wiki/KISS_%EC%9B%90%EC%B9%99 - KISS 원칙

1. 개요

 헐리우드 원칙은 프로그래밍 원칙 중 하나다.

 헐리우드 원칙을 적용하면, 저수준 구성요소에서고수준 구성요소를 집적 호출 할 수 없게 하고, 고수준 구성요소가 저수준 구성요소를 직접 호출 하는것은 허용하게 됩니다.

 이렇게 하면 의존성 부패(dependency rot) 현상을 방지할 수 있습니다.

2. 의존성 부패

의존성 부패현상이란, 고수준 구성요소가 저수준 구성요소에 의존하고, 또 그 저수준 구성요소는 고수준 구성요소에 의존하고, 고수준 구성요소가 또다른 구성요소에 의존하고... 이런식으로 의존성이 복잡하게 꼬이는 것을 말한다.

 시스템이 이런식으로 구현되면 시스템이 어떤식으로 디자인 된 것인지 알아보기가 어려워진다.

3. 레퍼런스

- Head First Design Pattern(O'REILLY media)

- https://zetawiki.com/wiki/Hollywood_%EC%9B%90%EC%B9%99 : 제타위키