구조적 ㅂ분석 및 설계contents.kocw.net/kocw/document/2014/deagucatholic/... · 2016. 9....

Copyright Kim, Haeng Kon 1

구조적 ㅂ분석 및 설계

이런 system을 정의하기 위해서는

user의 요구사항을 체계적으로 명기해야 하고

이해하기 쉬워야 하며

system상의 문제점을 발견할 수 있어야 하고

software 개발을 위한 지침서의 역할을 할 수 있도록 작성

이는 구조화 분석과정을 통해서 작성할 수 있고 그 특징은

매우 간결하다(Concise).

이해하기 쉽다(Understandability).

검증이 가능하다(Verifiable).

체계적이다(Organized).

구조적 명세서(Structured Specification)는 system의 한 model로서

자료 흐름도(Data Flow Diagram:DFD)

자료사전(Data Dictionary:DD)

미니 명세서(Mini-Specification)

로 된 한 개의 set와 같은 tool이나 방법론에 의해서 작성


1. 자료 흐름도

정보의 흐름을 나타내는 graph

자료 흐름 graph = Bubble Chart = DFD(Data Flow Diagram)

처리공정(process)과 이들 간의 자료흐름을 network 형태로 도형화하여 표현한 것

• 업무상의 작업흐름과 처리공정을 표현

• 각 routine들 사이에서 자료흐름과 program의 module을 나타내는데 이용

Process

1

Process

2

Process

3

Data 1

Data 2

Data 4

Data 3

Data 5

Data 6


1) DFD의 요소

자료흐름(Data Flow) : 화살표(→)

• system에서 처리되는 자료의 흐름을 추적

• 처리 공정들 간의 자료의 연관관계

처리공정(Process) : 원(○), 둥근 사각형()

• system에서의 처리요소를 자료변환의 관점에서 표시하여 처리요소 데이터에 대한 연

산을 내용

• 명칭의 사용 시 처리공정의 내용과 일치하는 의미 있는 명칭을 사용

• 한 개 이상의 입력자료와 출력자료가 존재

주문서

수주 확인 수주 확인


자료저장소(Data Store) : 직선(단선, 이중선)( )

• 논리적 data file을 표시

• 자료흐름에 의해 처리공정에 연결

• 자료흐름의 방향은 자료저장에서 자료를 읽어서 처리공정의 입력을 위한 방향과 자료의

작성과 이들이 동시에 행해질 수 있음

종착지(Terminator) : 정사각형, 직사각형(□)

• 자료흐름의 발생지(조직)와 최종 출력의 종착지(조직)를 나타냄

• 자료의 발생지를 "source"라 하고 종착지를 "sink"

• 종착지는 실제로 DFD의 외부에 있으며 하위 level로 갈수록 생략

고객 화일 고객 화일또는

거래처

주문서


2) DFD의 작성방법 : DFD를 작성할 때 발생할 수 있는 여러 가지 상황에 대처하는 안내

내용

수정된 자료흐름의 이름 부여 : bubble 안에 표시된 처리공정은 일종의 변환내용

사소한 거절(Trivial reject)

대화식 자료흐름 : 서로 대응되는 경우에는 양방향 화살표로 표현하고 명창을 반드시 붙여 주

어야 하고 그 내용 설명은 자료사전에 명세

씻는다 깎는다

사과 깨끗한 사과 깎은사과

지불

지불요청 신용처리

영수증 신용요구

신용응답자


자료의 순수흐름 : 처리공정이 자료저장소의 자료를 단순히 갱신할 때와 갱신한 다

음 흐름으로 옮겨갈 때는 구별해서 표현

처리공정과 저장소간의 명칭 부여

Add xto

TOTAL

X

TOTAL

Add xto

TOTALlssue

TOTAL

X

TOTAL

TOTAL


3) DFD의 분할 : 자료 흐름도를 작성하는데 있어서 가장 어려운 점은 어디서부터 시작해

서 그릴것인가 하는 것

자료흐름중심

처리공정은 어떤 자료흐름이 들어와서 어떤 자료흐름으로 나가는가를 결정하고 처리공

정안에서 변환되는 처리를 인식하여 분할하는 기법

처리공정내에서 자료흐름과 처리공정의 관계를 추적해 나가는 방법

절차

• 출력 단자(Outer Edge)에서 시작하여 모든 순수 작업(Net input)과 출력을 연결

• 자료와 변형되거나 집합되는 곳에 이름을 붙이지 않은 처리를 설정

• 자료흐름의 명칭을 부여

• 프로세스의 이름을 부여

• 자료를 보존할 곳에 자료저장소를 첨가


쇠고시

빵가루

밀가루

우유

계란

요크셔 푸딩

비프웰링톤

간파이

고기굽기

혼합

간파이

쇠고기

우유

밀가루

빵가루

주된 요리 준비물

푸딩요리

빵가루

우유

계란

요크셔 푸딩

기름 비프웰링톤

고기굽기

특징

• 자료흐름관점에 기초

• 자료요구 사항을 기초로 처리순서 파악 가능

• 예산되는 출력을 토대로 입력 자료 파악

• 불명확한 처리를 인지하는데 도움

• 작은 체계일수룩 유용성 증대


처리과정 중심의 접근방법

• 체계에 의해 수정되어질 처리들을 먼저 인식하여 해당처리의 수행을 위해 요구되는 자료

를 확인하고 공통자료에 관련된 처리들을 함께 연결시키는 방법

• 절차

– 체계에 의해 수행되어야 할 처리를 확인

– 각 처리에 대해 원을 그림

– 각 처리가 요구되는 자료흐름 및 자료저장소를 추가

– 자료흐름이나 자료저장소를 공유하는 처리들을 서로 연결


물품재고 파일

재고 명세서

선적 요구서

선적된 출고물품

구매 요구서

재 주문서

1주문서조회

선적 요구서

제외된 요구서

유효한 선적 서류

2물품출하

상품-ID 재고품파일

상품상품-ID별

출하량

3선적물포장

상품

선적물

4주문품발송

선적물

고객명과 주소고객별선적물

5재고조정

상품-ID별출하량

재고 명세서

6재고품보충

재고명세서

재 주문서구매요구서


1

주문서조회

2물픔 출하

6재고품보충

4주문품

발송 3선적물포장

5재고조정

선적요구서

제외된요구서 고객 이름및

조소

재고 명세서

재주문서

재고품

고객별선적물

상품

선적물

상품-ID별출하량

상품-ID출하되지

않은량

품목명 및품목번호

고객명과 주소

구매요구서


4) DFD의 복잡도

한페이지 정도의 크기를 단위로해서 그림.

DFD에 차원을 부여할 수 있는 레벨링(평준화,Leveling)의 개념을 도입

system의 한계영역을 정의하는 정체도(Context diagram)를 그리고 분석과 정의영역의 한

계를 분명히 할 필요가 있음.

DFD의 leveling은 하향식 설계방법으로 여러 가지로 분할해 감으로써 복잡한 최저수준의 기

능을 쉽게 파악할 수 있고, system내의 다른 부분과의 연계 관계도 균형있게 이해가능

A D

B C

B.1

B.2

B.3

z

x y

x

z

y

(a) (b)


5) DFD의 균형유지

처리공정과 그 다음 수준의 자료흐름 다이어그램의 입출력 흐름이 완전히 대응되게 함.

(a) 부모도

1.6지불기록

현금

수표

신용카드

신용화일

신용전표

신용카드 영수증

(b) 자식도 :부모 버블과 같은 자료흐름명을 가져야 한다.

1.6.1현금 계산

현금

수표

신용카드

신용화일

신용전표

신용카드 영수증

1.6.2수표인가

1.6.3불량 거래자

확인

1.6.4신용정리

입금전표

입금전표

입금전표


균형법칙 : 각 상위 단계의 처리는 그보

다 한 단계 아래의 자료흐름도와 같은 입

출력 자료흐름과 자료 저장소를 유지

1.6지불기록

지불신용화일

영수증

지불 =현금수표

신용카드

영수증=신용전표+(신용카드 영수증)

1

2

3

4 5

4.1

4.2

4.3

4.4

4.5

A

B

D

G

E

P

Z

T

D

U

Y

E

R

W P

(a) 다이어그램 0 (b) 다이어그램 4


3.6 자료사전

DFD상의 자료요소를 수학적으로 정의 = DD(Data Dictionary)

a = XXX + XXX

b ={ XXX + ( XX | XX ) }

c = ( XXX )

d = { XXX } + { XX | XX }

e = XXX + { XXX }

p = { XXX + XXX + XXX }

DFD DD

p

a b

c

e

d


1) 자료 사전에 사용되는 기호

① 자료흐름이나 자료저장소의 구성관계

② 반복의 형태

③ 기타


2) 자료 사전의 형태

① 자료저장소에 대한 DD

고객화일

청구서 발송 청구서

고객화일 = {계정번호 + 고객명세 + 고객 특성 + 입금상황} 고객명세 = 고객명 + 고객 주소 + 거래 시작일 고객특성 = 신용 현황 + 현잔고 현금 입금방법 = 수표 신용카드 입금 상황 = {입금일 + 입금방법}


② 자료흐름에 대한 DD

입금

청구서

입금증

영수증

·청구서 = 청구서 번호 + 청구일 +고객 주소 + {청구명세} + 청구액 ·청구명세 = 물품명 + 수량 + 단가세액 + 물품소계 + 물품합계 ·입금증 = 청구서 번호 + [현금|수표번호|신용카드 번호] ·영수증 = 고객명 + 고객 주소 + 영수일 + 입금액 + 임금방법 + (신용카드 전표 사본)


③ 명열(참고사항)

• 종업원 = *종업원 카드의 하위 구성요소*

• {종업원명 + 종업원 주소}

④ 별칭(Aliases)의 사용 : user의 혼돈을 피하기 위해 사용하지만 될 수 있는 대로

사용하지 않도록...

• 청구서 : *의뢰서의 별칭*

• 고객명 + 고객주소 × 청구일 + ...

• 의뢰서 : *청구서의 별칭*


3) 자료 사전의 단순화

항공탑승표 = 발행관련자료 + 탑승자명 + 1{항공기 관련자료}4 + 여행목적 + 요금관련 자료 +탑승표 구분자료

발행관련자료 = 항공사명 + (배서사항) + 출발지 + 도착지 + 발행자 + (교환증)

항공기관련자료 = 항공사명 + 항공기 코드 + 항공기 번호 + 등급 + 출발일 + 출발시간 + 기

본요금 + (유효일) + (실효일) + (보충사항)

요금관련자료 = 요금 + (할인요금) + (세액1) + (세액2) + 요금합계 + 요금계산 근거 + 요

금지불 방법

탑승표 구분자료 = (여행사 코드) + 여행사명 + 일련번호 +탑승표 번호 + 항공사 코드

• 계층적(나무구조)으로 표현함으로 단순화를 추구

항공탑승표 = 항공사명+ (배서사항) + 출발지 + 도착지 + 발행자 + (교환증) + 탑승자명 +

1{항공사명 + 항공기 코드 + 항공기 번호 + 등급 + 출발일 + 출발시간 + 기본요금 + (유효일)

+ (실효일) + 보충사항}4 + 여행 목적 + 요금 + (할인 요금) + (세액 1) + (세액 2) + 요금합계

+ 요금계산 근거 + 요금 지불 방법 + (여행사 코드) + 여행사명 + 일련번호 + 탑승표 변호

+ 항공사코드


4) DFD와 DD의 관계

① DFD의 보기 : 티켓발행

② 자료사전

수락된 주문 = 이름 + 주소 + 지불 + 실제날짜 + 실제 수량 + 1{티켓}

티켓 = 1{날짜 + 가격 + 가능 수량 + {티켓}}

티켓 요청 = 이름 + 주소 + 지불 + 1{우선 티켓}

미수락 주문 = 이름 + 주소 + 지불 + 미수락 편지

티켓할당

고객

지불기록

은행

티켓대장

영수증

티켓요청

미수락 주문

수락된 주문

예금

티켓판매


3.7 Mini 명세서

반페이지나 한페이지 정도의 크기로 세분화된 모듈을 작성할 때 사용

미니 명세서를 작성하는 툴

1. Graph와 table

user의 지침서로 구축

나쁨

- 서술문장- 구조적 언어- 의사결정 나무- 의사결정표- 표- 그래프

좋음


2. 의사결정표

3. 의사결정 나무

회계처리금액

솔정 > $ 500Acc에 60일 이상 - 1.송장 유보한다.미불된 송장있음.Acc 상태 좋은. -2.확인서와 송정 발행

솔정 <= 500Acc에 60일 이상 - 3.확인서와 송장발행미불된 송장있음. 신용처리 보고서 기입Acc 상태 좋은. -2.확인서와 송정 발행


4. 구조적 언어

구조적 언어의 구성요소

제한된 구조

제한된 문장형태

블럭구조

사용상의 주의점

비공식적으로 융통성있게 사용

공식적으로 표준화하려고 하지 않음

user가 편리하도록 그 형태를 수정

user에게 그 사용을 강요하지 않음

미니명세서 작성용 도구는 하나만 사용하는 것이 아니라, 경우에 따라서는 복합적으로 사용.

구조적 언어에 의한 블럭 구성

순차, 판단, 반복형태의 구조를 가지고 블럭을 구성

서술문장과 구조적 프로그래밍언어의 장단점을 취사선택하여 작성

서술문장은 업무 중심이기 때문에 익숙하여 신속하게 작성할 수 있고 융통성이 있음

구조적 프로그래밍 언어는 간결하고 명확하며 구조적인 특성을 구비한 장점을 갖음


구조적 언어로 표현한 미니명세서

근무자 화일

총금여 계산고용인보고서

금여 레코드

PAYMENT-TYPE = ["WEEKLY"|"SEMI-MONTHLY"|"MONTHLY"] EMPLOYEE-RECORD = EMPLOYEE-NAME + EMPLOYEE-ADDRESS + EMPLOYEE-NUMBER +PAYMENT-TYPE + [ANNUAL-SALARY|WEEKLYPAY-DATA] PAY-RECORD = EMPLOYEE-NAME + EMPLOYEE-ADDRESS + EMPLOYEE-NUMBER + GROSS-PAY WEEKLY-PAY-DATA = HOUSE-WORKED + REGULAR-WAGE + OVERTIME-WAGE


For each Employee Record Select the case based on Payment Type Case 1("Weekly") If the Hours Worked > 40 Reg Hours = 40 Reg Pay = Reg Hours × Reg Wage OT Hours = Hours Worked-40 OT Pay = OT Hours × OT Wage Gross Pay = Reg Pay + OT Pay Otherwise Reg Hours = Hours Worked Reg Pay = Reg Hours × Reg Wage Gross Pay = Reg Pay Case 2("Semi Monthly") Gross Pay = Annual Salary/24 Case 3("Monthly") Gross Pay = Annual Salary/12 Case 4("Anything else") Issue an error message Issue Pay Recoded


Mini명세서의 역할

지금까지는 하나의 system을 서브system별로 분할하였고, 서브system과 그들간의 인터페

이스를 DFD로 표현하였으며, 각 인터페이스를 DD로 정의

미니 명세서는 DFD상에서 설명되지 않은 처리과정 자세를 설명

DFD상 최하위 버블 각각에 대하여 하나의 미니 명세서가 작성

미니 명세서는 입력 자료를 출력 자료를 변화시키기 위한 업무 내용을 기술

Mini명세서의 작성기준

반 페이지내지 한 페이지 정도의 분량

따라서 미니 명세서의 분량을 염두해 두고 DFD를 분할

다음과 같은 조건일 때는 상기기준에 얽매지 않고 DFD를 분할

• 시간적으로 동일하지 않은 두개의 기능을 수행할 때

• 명명이 용이하지 않을 때

• 분량이 적어짐으로써 user의 system에 대한 이해가 용이할 때

Copyright Kim, Haeng Kon

등록자료

경고메세지

보고서증상신호

보고를 위한요구

환자 간호원

간호원

환자등록

0환자감시시스템

환자감시 시스템(PMS)

Context Diagram

DFD 00


Level 01

기록자료 기록자료

환자자료

환자한계치 화일

보고서

경고메세지

환자자료

증상신호환자

간호원

간호원

1국부지 감시

4보고서

3 기록 갱신

2중앙통제

보고를 위한 요구

환자기록

중앙신호자료


Level 02

환자자료

증상신호자료

경고메세지

위반

체온

맥박

환자자료

시계

2.1 신호

2.4 환자자료

처리

2.2 환자상태

한계치 상태

2.3 경고 메세지

발생

혈압

날짜, 시간

혈압, 체온, 맥박

환자한계치 화일

구조적 ㅂ분석 및 설계contents.kocw.net/kocw/document/2014/deagucatholic/... · 2016. 9....

Documents