유스케이스와 UML

Preface

 

이번 장에선 각종 다이어그램을 통해 인터넷 쇼핑몰 사이트 구현 방법을 알아보았다.

 

실무에서 사용될 법한 예시들을 하나하나 자세히 살펴보며 공부하다보니 내가 실제로 하나의 웹사이트를 구축하고 있는 것 같다는 느낌이 들어 뿌듯했지만, 한 가지 의아한 부분이 있었다.

 

바로 '관리자의 온라인 입금 내역 확인' 부분이다.

 

해당 책에선 관리자가 직접 사용자의 주문에 따른 입금 내역을 확인한다고 서술되어 있다.

나 역시 직접 인터넷 쇼핑몰을 이용하며 결제를 완료한 후 일정 시간이 지나야 '입금 대기' 상태가 '결제 완료' 상태로 바뀌는 것을 확인한 경험이 있기 때문에 처음엔 대수롭지 않게 여겼다. 그러나 생각할수록 입금 내역 확인을 시스템이 아닌, 관리자가 직접 한다는 것을 이해할 수 없었다.

 

만약 복잡성 문제로 인해 시퀀스 다이어그램에서 해당 시스템을 표현하지 못한다면, 액티비티 다이어그램을 사용하여 시스템이 결제 액티비티에서 특정 값을 입력받음에 따라 결제 완료 상태를 출력하도록 설계한다면 관리자가 직접 시스템에 관여하는 수고가 사라지지 않을까?

---

※ 추후 복습 필요

 

- 데이터베이스 정규화란 무엇인가?

 

- 유스케이스 모델링 : 행위자를 식별한 후 구체적인 사용 사례를 찾아 유스케이스로 식별하고 상세화하는 과정을 통해 시스템 전체의 요구사항을 알아내는 것

 

- null : 없다

---

1. 유스케이스 기법 개요

 

- 유스케이스 기법 : 고객과 시스템 개발자 간의 의사소통을 위한 도구

① 고객의 적극적인 참여 유도

② 신속한 요구사항 파악

 

- 유스케이스 기법 진행 과정

---

- 외부 사용자를 찾아낸다

① 행위자 = 액터(actor) = 외부 객체

② 주행위자(primary actor) : 주체가 되는 행위자

③ 부행위자(secondary actor) : 주행위자의 목적 달성에 도움을 주는 행위자

 

- 각 행위자는 시스템에 대해 각자 다른 관점과 용도를 가진다

① 외부 관점(external views) : 데이터베이스 상에서 각 행위자의 서로 다른 관점

② 유스케이스 = 사용 예 : 특정 행위자가 어떤 기능·임무를 달성하기 위한 시나리오의 집합

 

- 각 유스케이스에 대해 시나리오를 작성한다

① 기본 시나리오

② 대안 시나리오 : 정상적이지만 기본 시나리오와 다름

③ 예외적 시나리오 : 에러 발생 시 작성

---

---

2. 유스케이스 다이어그램

 

- 유스케이스와 행위자 간의 관계를 나타낸 다이어그램이다.

 

- 유스케이스 : 타원에 해당하며 유스케이스 이름을 표시하여 나타냄

 

[유스케이스]

 

- 행위자 : 사람의 형태 혹은 허수아비 형태로 나타냄

→ 시스템을 보조하는 하드웨어나 다른 시스템도 행위자가 될 수 있음

 

[행위자]

 

- 일반화 관계 : 기본적 목적이 같지만, 구체적 수행방법이 여러가지 존재하는 관계

 

[일반화 관계]

 

- 포함 관계 : 하나의 유스케이스를 수행할 때, 다른 유스케이스 행동을 포함하는 관계

→ 이벤트 중복 방지

 

[포함 관계]

 

- 확장 관계 : 특정 조건에서 다른 유스케이스 행동으로 확장되는 관계

① 확장점(extension point) : 확장될 때의 조건

② 화살표 방향은 확장 유스케이스에서 기본 유스케이스 방향

 

[확장 관계]

---

3. 인터넷 쇼핑몰 유스케이스 모델링

 

- 유스케이스 식별은 보통 문제 설명서로부터 시작한다.

 

- 문제 설명서 : 시스템이 수행하는 일을 간략하게 소개한 것

 

[인터넷 쇼핑몰 유스케이스 다이어그램]

 

- 유스케이스 다이어그램 완성 후 유스케이스 시나리오 작성

① 유스케이스 이름 및 개요, 행위자, 선행 및 후행 조건, 이벤트 흐름 등을 포함

② 기본 흐름은 반드시 작성해야 하지만, 예외 흐름 및 대안 흐름은 상황에 따라 작성

 

- 유스케이스 식별자

① UC : Use Case(유스케이스)

② A : Administrator(관리자)

③ C : Customer(고객)

④ M : Member(회원)

 

[식별자 목록 예시]

 

※ 자세한 시나리오 예시는 p.250~

 

- 시나리오를 폼 형태로 작성하면 이벤트 흐름을 파악하는 데 효과적이다.

→ but, 각 절차의 시작은 행위자 및 시스템의 주어를 명시적으로 달아야 상호작용 관계를 보다 쉽게 이해할 수 있다.

 

[폼 형식의 시나리오 예시]

---

4. 클래스 다이어그램

 

- 시스템의 정적인 정보 구조를 나타내는 정보 모델이다.

 

- '문제 기술서' 혹은 '유스케이스 시나리오'가 클래스 도출에 사용된다.

 

- 유스케이스 정적 분석 : 유스케이스 시나리오를 통한 클래스 도출 방법

① 클래스 찾기

② 클래스 간의 관계 찾기

③ 클래스의 속성 및 오퍼레이션 찾기

→ 클래스 속성을 도출할 땐 시나리오에 나타난 '명사'들을 분석

 

- 속성 : 클래스의 특성을 설명해주는 정보이며 그 자체가 값을 가질 수 있음

 

- 클래스 : 값을 갖는 속성들의 집합

 

[주문내역 테이블]

 

[인터넷 쇼핑몰 클래스 다이어그램]

---

5. 시퀀스 다이어그램

 

- 시스템의 동적인 정보 구조를 나타내는 정보 모델이다.

① 객체 간 상호작용을 통해 클래스 오퍼레이션 도출 가능

② 어떠한 데이터들을 주고받는지 밝힐 수 있음

 

- 시퀀스 다이어그램은 각각의 유스케이스에 대해 작성하는 것이 일반적이다.

 

- 데이터의 송·수신은 매개변수(parameter)와 반환값(return value)으로 표현된다.

 

- 행위자는 시스템 외부에 존재하며, 시퀀스 다이어그램에선 주로 맨 왼쪽에 위치한다.

 

- 동기 호출(synchronous call) : 오퍼레이션의 반환값을 나타낼 때 사용되는 메시지 유형

→ 오퍼레이션을 호출하는 객체 쪽으로 점선 모양의 화살표 표시

 

[시퀀스 다이어그램 예시]

---

6. 액티비티 다이어그램

 

- 클래스 내에서 이벤트를 처리하는 논리적 과정을 이해하기 위해 사용되는 다이어그램이다.

 

- 액티비티 다이어그램 작성 경우

① 유스케이스 분석 지원 : 유스케이스 시나리오와 같은 목적으로 사용

② 복잡한 알고리즘 표현

 

- 액티비티 다이어그램에선 활동 하나하나가 개별 오퍼레이션이 될 수 있다.

 

- 전용 함수(private member function) : 클래스 내부에서 호출되는 오퍼레이션

 

- 공용 함수(public member function) : 다른 객체에 의해 호출되는 오퍼레이션

 

[액티비티 다이어그램 예시]

---

7. UML 모델의 분석 프로세스

 

[UML의 V 프로세스]

 

- 객체지향 분석 기법은 혼합식 모델링 기법이다.

---

8. 모델의 통합

 

- 동적 분석의 결과로 도출된 오퍼레이션들(ex : 시퀀스 다이어그램)이 정적 분석의 결과물인 클래스 다이어그램에 반영되면, 완전한 분석 단계의 클래스 다이어그램이 완성된다.

 

 

 

 

 

참고 문헌 : 윤청, 『소프트웨어 공학 에센셜』(생능출판), 2019, p.242~294.