(요구사항 분석) Data Flow Diagram & Use Case Diagram

훈수/저작권 관련 지적 환영합니다 - 댓글 또는 audgnssweet@naver.com

오늘은 소프트웨어 요구사항 분석 & 명세 기술 방법에 대해 알아보겠습니다.

 

DFD (Data Flow Diagram)

---

 

DFD (데이터 흐름도)

데이터 흐름도(data flow diagram, DFD)는 시스템 구성요소인 프로세스와 프로세스 간 데이터 흐름을 표현하는 주요도구이다.  -위키백과-

 

한눈에 소프트웨어의 맥락 (Context)을 알 수 있습니다.

보통 inital understanding을 위해 사용합니다.

---

 

DFD의 구성요소

 

출처: 위키백과

DFD는 크게 4가지로 이루어집니다.

 

Terminal (사각형)	정보제공자, 정보 사용자 (유저 or 센서 엑츄에이터(하드웨어) or DB or E-commerce system or AWS 등) 여러 군데서 동시에 사용될 수 있음(중복 가능)
Process (원)	정보를 받고, 처리하고, 결과를 내놓는 것 데이터를 manipulate 하는 특징 (함수 등) 원 안에 프로세스 이름 넣어야 함. 이름이 동사로 시작한다는 특징이 있음.
Data Flow (화살표)	데이터 흐름의 방향 어떤 프로세스에서 어떤 프로세스로 가는지 표현 어떤 데이터인지를 표현하는 이름을 갖는다 명사
Data Store (위아래 평행선)	DB 등 데이터 저장소

---

 

레벨링

소프트웨어의 복잡도가 증가하면 하나의 DFD로 표현할 경우, 매우 커지고 한눈에 보기 어렵다는 점이 있습니다.

그래서 DFD 레벨링 + Balancing 방법을 사용합니다.

 

0부터 시작해서 높은 레벨로 올라간다.

레벨이 올라갈 수록 디테일함이 증가한다. (balancing 이라 표현)

레벨 0은 1. 전체 소프트웨어를 단일 process로 표현한다. (여러 개의 소프트웨어가 있을 경우 여러개) 2. Terminal과의 관계, Data source와의 관계를 표현한다. 3. Data Flow의 이름을 생략한다.

balancing을 할 때 단일 프로세스로 표현되었던 것이 작게 쪼개진다. balancing은 이해가 쉬워질 때까지 계속된다.

---

 

예시

출처: https://cjmyun.tripod.com/Knowledgebase/DFD.htm

---

---

 

 

UCD (Use Case Diagram)

---

Use Case Diagram

유스 케이스 다이어그램(use case diagram)은 사용자, 그리고 사용자가 수반한 다른 유스 케이스 간의 관계를 보여주는 사용자-시스템 간 상호작용의 표현이다 - 위키백과 -

 

1. 전체적인 system function을 이해할 수 있음

2. 시스템이 상호작용하는 요소에 대해 알 수 있음.

---

UCD의 구성요소

 

1. Actor	DFD의 Terminal과 비슷하다. 고객, 하드웨어(센서 등). 통신하는 다른 시스템(신용카드사) 등  그 이름에 ROLE 자체가 들어있음 (ex. customer, staff)
	종류 1. active actor 직접 use case를 호출할 수 있는 존재 ex) 고객(사람) 2. passive actor 우리 시스템이 불러서 요구하는 쪽 - 우리 시스템에 직접 요청하지 않음 ex) 신용카드사 인증시스템, 정부의 운전면허 조회 시스템 등
2. Use case	DFD의 Process와 비슷하다. 1. 동그라미로 표현 2. 이름은 동사로 시작 3. 각각의 Flow를 가진다 (아래에서 설명) 함수긴 한데 더 큰 단위를 의미함. (ex 자동차 렌트) 1. 한 수행 단위(한 트랜잭션)  2. 여러 개의 함수로 쪼개질 수 있는 정도의 크기. (ex 운전면허 조회 - 결제 - 렌트)
	use case를 만드는 방법 SRS - software requirement specification (요구사항 기술 문서) functional 한 것과 non-functional 한 것이 섞여있음.   1. SRS에서 functional item을 추출한다. (ex 자동차 렌트해주기) 2. 해당 functional item이 어떤 data를 다루는지 추출한다. (ex 자동차) 3. 추출한 데이터에 맞게 CRUD를 만들어준다. (ex DB에 렌트 기록 생성 등)
	complex system (large scale)에서는 작은 시스템으로 나눈다. 나눈 시스템은 numbering system으로 이름을 붙여준다. ex 뱅킹 시스템 - 결제, 대출 등으로 나눈다. 위에서 같은 경우는 Banking management라고 했을 때 BM01 - payment BM02 - loan
3. 선	기능 1. 유저가 호출 가능한 use case 표현. 2. use case 간 관계 파악 가능
	선으로 관계 표현하기 1. generalization   A. Actor가 Actor 가리킬 때 -> 상속 ex 하위 Actor는 상위 Actor의 use case까지 사용 가능 B. Use case가 Use case 가리킬 때 -> 인터페이스와 같음(기능만 추상화). 런타임 시에 결정. ex 사용자는 결제 사용 -> 내부적으로 카드결제, 현금결제 나뉨   2. include 점선으로 표현한다. <<include>> 이름 고정 use case가 반드시 동반되는 use case를 가진 경우 ex Base use case = 차량 렌트 include use case = 면허 체크 면허 체크 - -> 차량 렌트 와 같이 차량 렌트에는 반드시 면허 체크가 동반되어야 한다.   3. extend 점선으로 표현한다. <<exclude>> 이름 고정 use case가 조건부 실행되는 use case를 가진 경우 ex 차를 반환해야 하는데 (기간이 지나면) 추가 비용을 내야 하는 것 과 같은 행위. 추가 비용 지불 - -> 반환

---

UCD의 특징

 

OOD(Object Oriendted Design)을 할 때 표준적으로 사용.

시스템에서 외부적으로 노출되는 행위를 기술 (사용자와 직접 연관된 것)

Actor들과 System 간 Interaction을 중심으로 기술.

---

 

Use Case의 Flow

 

위에서 각 Use case는 Flow를 갖는다고 말씀드렸었습니다.

이에 대해 알아보겠습니다.

 

main	기본 로직
alternative	경우에 따라 분기되는 로직. main과 같은 결과를 만들어냄 (ex. 분기)
error	제대로 된 결과를 만들 수 없을 때

 

 

각각의 Use case의 Flow는 반드시 description으로 만들어야 한다. (글로 작성해야 한다)

그리고 description에는 반드시 main flow, alternative flow, error flow를 포함해야 한다.

 

description은 Table Form으로 다음과 같은 형태를 가집니다.

Actor	System
요청
	응답
요청

---

 

예시

1. UCD

 

출처: https://ko.wikipedia.org/wiki/%EC%9C%A0%EC%8A%A4_%EC%BC%80%EC%9D%B4%EC%8A%A4_%EB%8B%A4%EC%9D%B4%EC%96%B4%EA%B7%B8%EB%9E%A8

 

2. Use case flow Description

 

 

출처: 학부 수업

여기서 E-1과 A-1등은

Error flow와 Alternative flow로 넘어가는 것을 의미합니다.

---

 

결론

UCDiagram 그리고 UCDescription도 써야 한다.

---

 

오늘은 소프트웨어 공학의

요구사항 분석과 명세 기술의 방법에 대해 알아보았습니다.