Transcript 구조적 분석 및 설계

구조적 분석 및 설계





정보공학
분석기초
구조적 분석 1,2,3
설계원리
구조적 설계
1999.8
S/W Engineerin_YE Han
1
교육 목적



소프트웨어 공학과 정보공학의 연관성을 이해한다
분석과 설계의 기초원리를 이해한다
구조적 분석과 설계의 기법을 학습한다
1999.8
S/W Engineerin_YE Han
2
구조적 분석 및 설계

정보공학
분석기초
 구조적 분석 1,2,3
 설계원리
 구조적 설계

1999.8
S/W Engineerin_YE Han
3
정보 공학
과
소프트웨어 공학
분석기법
정보
공학
설계기법
소프트웨어 공학
Re-Engineering
프로그램 작성
테스트
1999.8
S/W Engineerin_YE Han
4
정보 공학




기업의 전략적 목표를 달성하는데 가장 적합한
정보시스템을 찾아내기 위하여
일련의 통합된 절차,기법 및 툴을 사용한다
기업 전체에 먼저 초점을 맞추고,
그 다음 업무분야에 초점을 맞춘다
기업모델, 데이터 모델, 프로세스 모델을 개발한다
정보관리 체제의 분산과 통제를 위한
기본구조를 개발한다
1999.8
S/W Engineerin_YE Han
5
정보공학의 장점(Benefits)
정보시스템이 전략적 차원에서 경쟁력 향상을 위한
도구로 사용될 수 있는 방안을 제공한다
 정보시스템의 초점을 경영목표에 맞추게 한다
 정보시스템의 장기적 발전을 위한 기초를 확립한다
 변경하기 쉬운 정보시스템 구조를 형성한다

1999.8
S/W Engineerin_YE Han
6
정보공학의 단계




정보전략 계획 수립(Information System Planning)
업무분야 분석(Business Area Analysis)
업무시스템 설계(Business System Design)
업무시스템 구축(Business System Construction)
1999.8
S/W Engineerin_YE Han
7
정보전략 계획 수립 - 고려요소


관리적 측면
- 전략적 경영 목표를 정의한다
- 핵심적인 성공요인을 찾아낸다
- 정보기술이 경영에 미치는 영향을 분석한다
- 전략적 기업모델을 개발한다
기술적 측면
- 최상위 데이터 모델을 개발한다
- 업무기능과 조직을 Clustering 한다
- 데이터 모델과 Cluster를 정련한다
1999.8
S/W Engineerin_YE Han
8
제1단계: 기업 모델 개발
업무 모델을 개발 한다
- 조직단위를 정의한다
- 업무기능을 식별한다
. 업무기능을 분해한다
. 업무프로세스를 정의한다
* 업무기능:
- 사업을 영위하는데 필요한 지속적인 활동
- 명사 또는 동명사로 표현
* 업무 프로세스:
- 입력자료를 출력자료로 변환시키는 반복적인 행위
- 동사로 표현
1999.8
S/W Engineerin_YE Han
9
업무기능 분활(Function Decomposition)
- 업무기능(Business Function)
- 업무 하위 기능(Business Subfunction)
- 업무 프로세스(Business Process)
- 하위 프로세스(Subprocess)
- 작업(Task)
1999.8
* 제품 개발 및 엔지니어링(업무기능)
- 영업(업무 하위 기능)
. 시장조사.분석(업무프로세스)
. 고객정의
. 판매예측
. 가격결정
. 제품사양 결정
- 제품 엔지니어링(업무 하위 기능)
. 기술조사
. 신제품 개발(업무프로세스)
. 제품설계(하위 프로세스)
. 하위 시스템 엔지니어링
. 시제품 생산 및 평가
. 기존 제품 지원
S/W Engineerin_YE Han
10
제1차 엔티티(객체) 식별









고객(Customers)
종업원(Employees)
판매자(Vendors)
장비/설비(Equipments)
영업정보(Sales Information)
주문(Orders)
제품(Products)
원자재(Materials)
부품(Components)
1999.8
S/W Engineerin_YE Han
11
엔티티(객체)가 요구하는 서비스 식별
@ 엔티티(객체)
고객(Customers)
종업원(Employees)
판매자(Vendors)
장비(Equipments)
영업정보(Sales Information)
주문(Orders)
제품(Products)
1999.8
@ 서비스
- 구입
- 설치
- 운영
- 유지보수
S/W Engineerin_YE Han
12
엔티티와 업무기능의 연결
- MATRICS 엔티티
업무기능
엔티티1 엔티티2 엔티티3 엔티티4…...
업무기능1
*
업무기능2
*
업무기능3
*
*
*
*
*
*
………….
1999.8
S/W Engineerin_YE Han
13
엔티티와 업무기능의 연결
- ER Diagram 사용된다
엔티티
1999.8
사용한다
S/W Engineerin_YE Han
업무기능
14
ISP: 방향 및 목표 설정
목표2
목적
(방향)
Goal-2
Objective
목표1
Goal-1
1999.8
목적: 제조원가를 절감한다
목표: 재고비를 2% 절감한다
인건비를 3% 절감한다
S/W Engineerin_YE Han
15
목표와 업무기능의 연결
목표
업무기능
업무기능1
업무기능2
업무기능3
목표1 목표2 목표3 …………….
*
*
*
*
………….
1999.8
S/W Engineerin_YE Han
16
ISP: 핵심 성공요인 식별


목적(Objective): 제조원가를 절감한다
핵심 성공요인(CSF):
- 전사적 품질관리를 실시한다
- 작업자를 훈련시키고 동기를 부여한다
- Just-in-Time 재고관리를 실시한다
1999.8
S/W Engineerin_YE Han
17
ISP: 기술 영향도 분석




기업의 목적(방향), 목표 및 성공요인에
어떤 기술이 직간접적으로 영향을 미치는가 ?
영향의 심각성은 어느 정도인가 ?
기술의 발전 주기는 얼마인가 ? 1년, 2년, 3년, 5년…..
다가오는 변화를 수용하기 위해서 기업의 목적(방향)
과 목표를 어떻게 확대시켜나가야 하는가 ?
1999.8
S/W Engineerin_YE Han
18
ISP: 업무기능의 계층구조 분석
업무기능
업무 하위 기능
업무기능을 하향식
계층구조로 분석한다
1999.8
S/W Engineerin_YE Han
19
ISP: 엔티티 관계 모델링(ERM)
엔티티1
엔티티5
엔티티2
엔티티3
엔티티4
1999.8
엔티티6
개별 응용소프트웨어를
개발할 때 더 자세히 정련한다
S/W Engineerin_YE Han
20
업무분야 분석(BAA)
업무기능과 엔티티가 상호 연관성이 많은 것끼리
그룹으로 묶어서 업무분야를 구성한다
 업무분야별로 새로운 모델을 개발한다
 기존의 정보시스템을 파악하여 새로운 모델과
비교한다

1999.8
S/W Engineerin_YE Han
21
업무분야 분석(BAA) -
그룹화
엔티티
업무기능
업무분야
1999.8
S/W Engineerin_YE Han
22
업무분야 분석(BAA) 프로세스
영업
업무분야
엔지니어링 품질관리
일반
관리
재무관리
업무기능/데이터
관련도
유통관리
프로세스
모델
1999.8
S/W Engineerin_YE Han
데이터
모델
업무기능
분해도
23
구조적 분석 및 설계

정보공학

분석기초
구조적 분석 1,2,3
 설계원리
 구조적 설계

1999.8
S/W Engineerin_YE Han
24
소프트웨어 요구분석 개요





고객과 함께 소프트웨어의 요구사항을 협의한다
분석 모델을 개발한다
불확실한 분야에 대해서 시제품(Prototype)을 만든다
설계의 지침이 될 사양서를 작성한다
공식적 기술검토를 실시한다
1999.8
S/W Engineerin_YE Han
25
소프트웨어 요구분석 프로세스
시제품
구축
문제
1999.8
요구사항
수집
사양서
작성
S/W Engineerin_YE Han
공식적
기술검토
26
소프트웨어 요구분석시의 문제점-면담방식




고객의 요구사항이 막연한 아이디어 수준이다
개발자는 막연한 아이디어로 개발을 진행하려고 한다
고객은 계속해서 요구사항을 변경한다
개발자는 계속되는 변경으로 인해서 혼란에 빠지고,
실수하고, 오류를 범하고, 부작용을 일어킨다
1999.8
S/W Engineerin_YE Han
27
소프트웨어 요구분석시의 문제점-문서방식




소프트웨어 요구명세서에 중요한 요구사항이
빠질 수 있다
기능과 성능에 대한 요구사항이 서로 상반될 수 있다
문제점의 경계가 명확하게 설정되지 못하고
막연하게 기록될 수 있다
설계상의 제약사항 또는 시스템 인터페이스에
부정확한 정보 및 부적절한 정보가 포함될 수 있다
1999.8
S/W Engineerin_YE Han
28
요구분석 기법 - FAST
Facilitation Application Specification Technics
소프트웨어
요구사항
개발자
고객
- 요구사항을 상세하게 정의한다
- 팀웍(Team Work)을 개발한다
JAD - Joint Application Development
1999.8
S/W Engineerin_YE Han
29
FAST 역할 분담





후 원 자: 경영자 중의 한 사람으로서
팀 요원의 참여를 독려한다
팀 리 드: 공정한 성격을 가진 사람으로서
FAST 회의를 리드하고 조정한다
서 기: 회의의 진행사항과 결과를 기록한다
참 가 자: 고객과 개발자로서 요구사항을 정의한다
전 문 가: 정보기술 분야와 업무 분야의 전문가로서
참가자의 질문에 자문한다
1999.8
S/W Engineerin_YE Han
30
FAST의 단계





정의 단계
조사 단계
준비 단계
회의 단계
문서화 단계
1999.8
S/W Engineerin_YE Han
31
FAST - 정의 단계




목적 및 범위
요구되는 기능 및 성능
제약사항 및 가정사항
미해결 현안
* 업무상의 기본 요구를 정의한다
1999.8
S/W Engineerin_YE Han
32
FAST - 조사 단계



현재의 업무처리 방식
기존의 업무기능, 데이터, 프로세스
새로운 요구사항
1999.8
S/W Engineerin_YE Han
33
FAST - 준비 단계



회의 의제 작성
정의 단계와 조사 단계의 내용을 문서화
미해결 현안 정리
1999.8
S/W Engineerin_YE Han
34
FAST - 회의 단계




회의 의제 설명
참석자 소개
그룹별로 문제해결
전체 팀이 모여서 최종 결정
* 사무실에서 멀리 떨어지고,
문서화 작업을 쉽게 할 수 있는 장소에서 실시한다
1999.8
S/W Engineerin_YE Han
35
FAST - 회의의 초점




기존의 데이터
변경된 데이터
새로운 데이터
입출력 - 화면, 보고서, 사건
1999.8
S/W Engineerin_YE Han
36
FAST - 회의 지침






사전 준비를 철저히 한다
회의장소는 사무실에서 멀리 떨어진 한적한 곳이 좋다
모든 참석자는 직급에 관계없이 동등한 자격을 갖는다
회의 참가자는 회의의 시작부터 끝까지 참석한다
회의의 의제를 정의하고 끝까지 유지한다
기술적으로 너무 깊이 빠져들지 않는다
1999.8
S/W Engineerin_YE Han
37
FAST - 이로운점






단순화(Simplify)
식별화(Identify)
계량화(Quantify)
명확화(Clarify)
통일화(Unify)
만족화(Satisfy)
1999.8
S/W Engineerin_YE Han
38
전형적인 FAST-예비회의






단계
고객과 개발자가 합동으로 실시
제품 요구서(Product Request) 작성
회의 장소, 날짜, 시간 결정
회의 리드(Facilitator) 선정
회의 참석자 선정 및 초청장 발송
참석자에게 제품요구서 배포
1999.8
S/W Engineerin_YE Han
39
전형적인 FAST-준비단계




데이터 목록(Object List) 작성
업무기능 목록 작성
프로세스 목록 작성
제약사항(예산,기간..) 및 성능기준(속도, 정확성..) 작성
1999.8
S/W Engineerin_YE Han
40
전형적인 FAST-회의단계1


신제품의 필요성 및 타당성 토의
참석자가 준비한 목록 설명
참석자가 설명하는 동안 비판과 토론을 금한다
주제별로 결합 목록 작성(데이터, 업무기능,제약사항..)
 주제별 결합 목록에 대해서 토론
 결합 목록이 개발될 제품을 적절하게 표현하도록
목록의 내용을 줄이거나, 늘이거나, 표현방법을 변경한다
 주제별로 합의 목록 작성

1999.8
S/W Engineerin_YE Han
41
전형적인 FAST-회의단계2





팀을 몇 개의 서브 팀으로 나눈다
서브 팀별로 Mini-Spec 작성
서브 팀별로 작성된 Mini-Spec 설명 및 전체 토의
해결되지 않은 사항에 대해서 문제점 목록 작성
제품 검증기준 토의 및 목록 작성
1999.8
S/W Engineerin_YE Han
42
분석 원칙 1 - 데이터의 모델화




데이터(Data Object)를 정의한다
데이터간의 관계를 설정한다
데이터의 흐름을 표현한다
데이터의 내용을 명기한다
** Data Object: Paycheck
1999.8
S/W Engineerin_YE Han
43
분석 원칙 2 - 업무기능의 모델화


데이터를 변환시키는 기능을 식별한다
식별된 기능을 분해한다
1999.8
S/W Engineerin_YE Han
44
분석 원칙 3 - 사건.반응의 모델화


시스템의 상태를 변화 시키는 사건을 명기한다
사건에 반응하는 시스템의 서로 다른 상태를 나타낸다
1999.8
S/W Engineerin_YE Han
45
분석 원칙 4 - 모델의 분활
각 모델이 하위 수준의 추상화를 나타내도록 정련핟다



데이터의 정련(Refine)
업무기능의 분해(Decomposition)
상세 수준의 사건.반응 모델 작성
1999.8
S/W Engineerin_YE Han
46
분석 원리 5 - 논리적 vs 물리적

논리적: 고위 수준의 추상화
“ 가격을 읽는다 ”
What should be done ?

물리적: 하위 수준의 추상화
“ 바코드를 통해서 가격을 읽는다 “
How could be done ?
1999.8
S/W Engineerin_YE Han
47
구조적 분석 및 설계





정보공학
분석기초
구조적 분석 1,2,3
설계원리
구조적 설계
1999.8
S/W Engineerin_YE Han
48
구조적 분석 모델
ERD
DFD
PSPEC
엔티티
관계도
자료
흐름도
처리
명세서
자료
사전
상태
변화도
STD
DD
1999.8
S/W Engineerin_YE Han
49
구조적 분석 모델 - ERD
ERD
DFD
PSPEC
엔티티
관계도
자료
흐름도
처리
명세서
자료
사전
상태
변화도
STD
DD
1999.8
S/W Engineerin_YE Han
50
분석 모델링 -
어디서부터 시작하는가 ?
FAST의 작업문서가 소프트웨어의
범위 내역(Statement of Scope)을 제공한다
 FAST의 작업문서를 문법적으로 해부해서
데이터와 처리기능을 추출한다

1999.8
S/W Engineerin_YE Han
51
소프트웨어 범위 내역서

구축하려고 하는 시스템에 대해서
간략하게 기술해 놓은 것



1999.8
시스템의 입출력 데이터 및 기본 처리기능
고위 수준의 조건별 프로세스
강요사항 및 제약사항
S/W Engineerin_YE Han
52
데이터 및 처리기능의 식별

소프트웨어 범위 내역서의 모든 명사에 밑줄을 그어서
데이터(엔티티)를 정의한다
데이터의 생산자 및 소비자
 데이터가 저장되는 장소
 데이터 아이템의 합성체


소프트웨어 범위 내역서의 모든 동사에 밑줄을 그어서
처리기능을 정의한다
데이터의 변환
 업무 프로세스


그외에 데이터(엔티티)가 필요로 하는 “서비스”를
고려한다
1999.8
S/W Engineerin_YE Han
53
데이터 모델링 이란 ?

데이터 모델링 이란
데이터 (엔티티) 와
데이터간의 관계를
도형으로 표현한 것
1999.8
S/W Engineerin_YE Han
54
왜 데이터 모델링을 하는가 ?
프로세스와는 별도로 데이터(엔티티)를 조사한다
 데이터(엔티티)의 영역에 초점을 맞춘다
 고객수준의 추상화 모델을 만든다
 어떤 데이터(엔티티)가 있으며,
그들이 어떻게 서로 관련되고 있는가를 나타낸다

1999.8
S/W Engineerin_YE Han
55
데이터(엔티티)란 ?

데이터 엔티티란
일련의 속성(데이터 아이템)에 의해서 묘사되는
어떤 것으로서 시스템 내에서 조작된다
데이터 엔티티의 실례(Instance)는 유일하게 식별된다
( 학생:학생번호)
 데이터 엔티티의 실례는 속성(데이터 아이템)에 의해서 묘사된다
 데이터 엔티티의 실례는 시스템에서 필요한 역할을 수행한다
(시스템은 데이터 엔티티의 실례를 Access하지 않고는 처리기능을
수행할 수 없다)

1999.8
S/W Engineerin_YE Han
56
전형적인 데이터 엔티티(객체)







외형적 엔티티: PC, OHP, BLACK BOARD….
사물(실체): 시험지, 성적표, 출석부….
사건: 개강, 시험….
역활: 학생, 교수, 조교….
조직: 전산학과, 교무처, 사무국….
장소: 강의실, 실습실, 사무실….
구조(구성): 학생기록부….
1999.8
S/W Engineerin_YE Han
57
데이터 엔티티 및 속성
데이터 엔티티: 자동차
속성: 제작회사
모델
가격
선택 옵션
속성:엔티티의 외관, 특성,품질
1999.8
S/W Engineerin_YE Han
58
관계(Relationship)란 ?

관계란 엔티티들이 서로 연결되어 있는 방식
하나의 관계에 여러 개의 실체(Instance)가 연결될 수 있다
 엔티티들은 여러 가지 다른 방식으로 연결될 수 있다

1999.8
S/W Engineerin_YE Han
59
엔티티 관계도(ERD) 표기법
엔티티1
(0,m)
관계
엔티티2
(1,1)
속성
관계
엔티티1
1999.8
엔티티2
(0,m)
(1,1)
S/W Engineerin_YE Han
60
엔티티 관계도(ERD) - 예제
(0,m) 제작된다
자동차
제작한다 (1,1)
- 모델명
-색 상
-가 격
1999.8
제작회사
- 제작회사명
-공장 번호
S/W Engineerin_YE Han
61
엔티티 관계도(ERD) 작성단계



제 1 단계: 모든 엔티티와 그들의 관련사항을 모델화
제 2 단계: 모든 엔티티와 엔티티간의 관계를 모델화
제 3 단계: 모든 엔티티,엔티티간의 관계 및
엔티티의 속성을 모델화
1999.8
S/W Engineerin_YE Han
62
제1단계 ERD 작성
책
서점
출판사
구매자
저자
- 엔티티를 식별해서 이름을 부여한다
- 엔티티 간의 관련여부를 정의한다
1999.8
S/W Engineerin_YE Han
63
제2단계 ERD 작성
(0,m)
책
(0,K)
팔린다
판 다
(1,1)
서점
(1,1)
(0,n)
(1,1)
진열된다
진열한다
주문된다
주문한다
- 엔티티와 엔티티 사이의 관계에 이름을 부여한다
- Cardinality를 정의한다
1999.8
S/W Engineerin_YE Han
64
제3단계 ERD 작성
책
도서번호
책명
출판사
출판일자
가격
- 엔티티의 속성을 정의한다
- 관계의 속성을 정의한다
1999.8
S/W Engineerin_YE Han
65
엔티티 관계도(ERD): SUB 엔티티
책
교과서
참고서
엔티티 타입
소설
SUB 엔티티
1999.8
S/W Engineerin_YE Han
66
엔티티 관계도(ERD): Cardinality




1:1
1:n
n:1
m:n
1999.8
일 대 일(One to One)
일 대 다(One to many)
다 대 일(Many to One)
다 대 다(Many to Many)
S/W Engineerin_YE Han
67
앤티티 관계도(ERD): 예제
1999.8
S/W Engineerin_YE Han
68
엔티티 관계도(ERD)에 대한 주석

ERD에서 관계는 양방향이다
- 어느 방향으로 든지 읽을 수 있다



Cardinality는 항상 나타난다
ERD는 계층적으로 도출된다
ERD는 검토되고 필요에 따라서 편집된다
1999.8
S/W Engineerin_YE Han
69
엔티티 연합형 관계(AOT)
AOT(Associative Object Type):
정보를 포함하고 있는 관계
엔티티 연합형 관계에 포함되는 정보는
사후에 도출될 수 없다
 엔티티 연합형 관계는 이 관계가 연결하는 엔티티에
의존되어 있다 즉 엔티티가 없이는 존재하지 못한다

1999.8
S/W Engineerin_YE Han
70
엔티티 연합형 관계(AOT) 표기법
고객
책
구매
구매일자
1999.8
등록번호
구매 엔티티의 속성
점원ID
S/W Engineerin_YE Han
71
엔티티 관계도(ERD) 검토




하나의 엔티티에 특별한 실체(Instance)들이 있다면
이 엔티티는 Subtype 구조로 확장한다
엔티티간의 관계를 데이터로 부터 도출할 수 있다면
이 관계는 ERD상에 나타낼 필요가 없다
관계에 대한 정보가 포함되어 있다면
이 관계는 AOT로 표현한다
새로운 엔티티로 정의할 수 있는
“속성 부분집합(Attribute Subset)”을 찾는다
1999.8
S/W Engineerin_YE Han
72
구조적 분석 모델 - DFD
ERD
DFD
PSPEC
엔티티
관계도
자료
흐름도
처리
명세서
자료
사전
상태
변화도
STD
DD
1999.8
S/W Engineerin_YE Han
73
자료흐름 모델(Flow Model)
입력자료
컴퓨터
시스템
출력정보
모든 컴퓨터 시스템은 자료를 변환한다
1999.8
S/W Engineerin_YE Han
74
자료흐름 모델 표기법
외부 엔티티
처리
자료흐름
자료저장소
1999.8
S/W Engineerin_YE Han
75
외부 엔티티(External Entity)
외부
엔티티
컴퓨터
시스템
외부
엔티티
- 자료의 생산자 또는 소비자
(예: 사람, 장치,컴퓨터 시스템….)
- 자료는 항상 어떤 곳에서 부터 발생되어서
어떤 곳으로 보내져야 한다
1999.8
S/W Engineerin_YE Han
76
처리(Process)
밑변
높이
삼각형의
면적을
계산한다
면적
- 자료 변환기 - 입력자료를 출력자료로 변경한다
(예: 세금을 계산한다, 보고서를 작성한다, 그라프를 보여 준다…)
- 자료는 시스템의 기능을 달성하기 위해서 항상 어떤 방식으로
처리되어야 한다
1999.8
S/W Engineerin_YE Han
77
자료흐름(Data Flow)
밑변
높이
1999.8
삼각형의
면적을
계산한다
S/W Engineerin_YE Han
면적
78
자료저장소(Data Store)
학생번호
학생정보
조회
학생의 학과, 성적...
학생 기록부
1999.8
S/W Engineerin_YE Han
79
자료흐름도의 관례(Conventions)





모든 심볼에는 명확한 이름을 부여한다
Level 0 도면에는 항상 외부 엔티티를 나타낸다
Level 0 도면에는 자료저장소를 나타내지 않는다
시스템으로 들어가는 자료흐름은 반드시
처리를 통과해야 한다
통제흐름은 나타내지 않는다
1999.8
S/W Engineerin_YE Han
80
자료흐름도의 관레
자료 저장소
자료흐름 1
처리 1
자료흐름 2
처리 2
자료흐름 3
자료흐름이 자료 저장소에 의해서 연결된다
외부
엔티티
자료 저장소
외부
엔티티
처리
자료 저장소
허락되지 않는다
1999.8
S/W Engineerin_YE Han
81
자료흐름도(DFD) 작성 - 1




시스템의 범위를 결정한다
외부 엔티티를 결정한다
외부 엔티티에서 시스템으로 입력되는 자료흐름과
시스템에서 외부 엔티티로 출력되는 자료흐름을
찾아낸다
Level 0 자료흐름도(배경도)를 작성한다
1999.8
S/W Engineerin_YE Han
82
Level 0 자료흐름도 - 예제
User
Video
Source
1999.8
Processing
Request
Digital
Video
Processor
Requested
Video
Signal
Monitor
NTSC
Video
Signal
S/W Engineerin_YE Han
83
자료흐름도(DFD) 작성 - 2




자료흐름을 변환시키는 처리기능을 찾아낸다
자료흐름의 연속성이 유지되도록
자료흐름과 처리기능을 연결시킨다
Level 1 자료흐름도를 작성한다
처리기능의 확장비율은 1:5를 유지한다
1999.8
S/W Engineerin_YE Han
84
자료흐름도(DFD)의 계층 구조
a
x
c
a
b
p
p2
p4
p3
Level 0
f
p1
d
y
Level 1
g
e
b
p5
d
P3.1
d1
e
P3.3
Level 2
d2 P3.2 d3
1999.8
S/W Engineerin_YE Han
85
자료흐름도 작성 노트
각 처리기는 하나의 기능을 수행하게 될 때까지
단계적으로 세분된다
 자료흐름도의 Level의 숫자가 증가함에 따라서
확장비율은 감소한다
 대부분의 시스템은 3 - 7 Level의 자료흐름도로
표현된다
 자료흐름도의 Level의 숫자가 증가함에 따라서
하나의 자료흐름은 확장될 수도 있다

1999.8
S/W Engineerin_YE Han
86
자료흐름도 예제
Manufacturing cell software controls a robot by generating
position coordinates that are transmitted to the robot.
An operator inputs commands that cause the
manufacturing cell software to read positioning and
control commands from an NC command file.
Components to be assembled are held in parts fixtures…
a part ID is input for each component… an operator
display is output to a monitor...
1999.8
S/W Engineerin_YE Han
87
Level 0 자료흐름도 작성
Part
fixture
Position
coordinator
Part ID
Robot
Manufacturing
cell
software
operator
1999.8
Operator
commands
Operator
display
S/W Engineerin_YE Han
Monitor
88
Level1 자료흐름도로 세분화
Part ID
Monitor
fixture
status
Part
priority
Construct
robot
command
Raw
position
data
Compute
position
data
Position
coordinator
Computed
block
PGM ID
NC record
Operator
commands
Read
operator
input
PGM ID
Read
command
blocks
Format
monitor
display
Control
status
display
NC command file
1999.8
S/W Engineerin_YE Han
89
Level 2 자료흐름도로 세분화
Raw
position
data
Raw
position
data
1999.8
Compute
position
Compute
position
data
x,y,z
Position
coordinator
Format
position
g,x,y,z,t,s,
eof
S/W Engineerin_YE Han
Transmit
position
Position
coordinator
90
구조적 분석 모델 - STD
ERD
DFD
PSPEC
엔티티
관계도
자료
흐름도
처리
명세서
자료
사전
상태
변화도
STD
DD
1999.8
S/W Engineerin_YE Han
91
행동 모델(Behavioral Modeling)
사건(Event)
1999.8
시스템
S/W Engineerin_YE Han
행동(Behavior)
92
시스템의 상태(States




of System)
상태(State): 일정 시간동안 시스템 행동의 특성을
밝히는 일련의 환경
상태변화(State Transition): 하나의 상태로부터
다른 상태로 옮겨 가는 것
사건(Event): 시스템으로 하여금 어떤 예측할 수 있는
행동을 일으키게 하는 것
행동(Action): 변화가 일어남으로 인해서 발생하는
처리기능
1999.8
S/W Engineerin_YE Han
93
행동 모델 작성



시스템의 상태 목록을 만든다
시스템이 어떤 상태에서 다른 상태로 변화되는
사건과 행동을 찾는다
상태변화도(State Transition Diagram)을 그린다
1999.8
S/W Engineerin_YE Han
94
상태변화도(STD) 표기법
상태
변화를 유발하는 사건
발생되는 행동
새로운 상태
1999.8
S/W Engineerin_YE Han
95
상태변화도(STD) 예제
Full and start
Invoke manage-copying
Reading
operator
commands
Copies done
Invoke read op input
Full
Invoke read op input
Making copies
Reloading paper
Empty
Jammed
Invoke reload paper
Invoke problem diagnosis
Problem state
1999.8
Not jammed
Invoke read op input
S/W Engineerin_YE Han
96
상태변화도(STD)의 분활
S1
S2
S2.1
S2.2
S2.5
S2.3
S2.6
S3
S4
S2.4
Level 1 STD
1999.8
Level 2 STD
S/W Engineerin_YE Han
97
상태변화도 검토




모든 상태가 정의되고 표현되었는가 ?
각 상태에는 어떤 경로를 통해서든지 도달할 수 있는가
각 상태로부터 빠져 나오는 것은 가능한가 ?
각 상태에서 시스템은 모든 발생 가능한 사건에 대하여
정확하게 반응하는가 ?
1999.8
S/W Engineerin_YE Han
98
구조적 분석 모델 - PSPEC
ERD
DFD
PSPEC
엔티티
관계도
자료
흐름도
처리
명세서
자료
사전
상태
변화도
STD
DD
1999.8
S/W Engineerin_YE Han
99
처리 명세서(Process
입력 자료흐름
처리
Specification)
출력 자료흐름
처리 명세서(PSPECS)
- 서술형
- 구조적 언어
- 방정식
- 의사 결정도
- 의사 결정표
1999.8
S/W Engineerin_YE Han
100
처리명세서 - 예제
급여총액
세금을
계산한다
세금
PSPECS: 세금을 계산한다
- IF 급여총액 > 1,000,000
THEN 세금 = 급여총액 * 0.1
ELSE 세금 = 급여총액 * 0.05
1999.8
S/W Engineerin_YE Han
101
처리명세서
와
시스템 구조도
처리명세서
입력 자료흐름
처리
출력 자료흐름
처리 명세서(PSPECS)
시스템 구조도
- 서술형
- 구조적 언어
- 방정식
- 의사 결정도
- 의사 결정표
모듈
모듈
모듈
1999.8
모듈
모듈
S/W Engineerin_YE Han
모듈
모듈
모듈
102
처리명세서 와 시스템 명세서
처리명세서
처리명세서
처리명세서
시스템 명세서
1999.8
S/W Engineerin_YE Han
103
구조적 분석 모델 - DD
ERD
DFD
PSPEC
엔티티
관계도
자료
흐름도
처리
명세서
자료
사전
상태
변화도
STD
DD
1999.8
S/W Engineerin_YE Han
104
자료사전(Data Dictionary)



모든 자료흐름과 자료저장소의 내용이
상세하게 정의되는 곳
모든 엔티티(Data Object)가 정의되는 곳
데이터 항목(Data Item)이
어디에서 어떻게
사용되는 가를 알 수 있는 곳
1999.8
S/W Engineerin_YE Han
105
자료사전의 표기법





=
+
[a l b ]
{
}n
*…Text…*
1999.8
is composed of
and
a 와 b 중에서 선택
반복(n회)
Comment
S/W Engineerin_YE Han
106
자료사전의 구조




데이터 항목명(Data Item Name)
동의어(Alias)
사용되는 곳/사용되는 방법
데이터 항목 설명(Formal Description)
1999.8
S/W Engineerin_YE Han
107
자료사전 - 예제

데이터 항목명:
전화번호

동의어:
전화

사용되는 곳/사용되는 방법:

Read.phone.number(input)
 Display.charge(input)
 Analyze.lg.dist.calls(input)

데이터 항목 설명:
교환기의 회선에 부여되는 고유한 번호
1999.8
S/W Engineerin_YE Han
108
자료사전과





자료흐름도/자료저장소와의 관계
모든 자료흐름과 자료저장소는 자료사전에 정의되어야 한다
자료사전에 정의된 모든 데이터 항목은
자료흐름도에 나타나야 한다
자료사전의 사용되는 곳 에 기록된 모든 Entry는
각각이 하나의 처리이므로 자료흐름도에 나타나야 한다
엔티티 관계도(ERD)에 기록된 모든 엔티티는
자료사전에 나타나야 한다
자료사전에 기록된 모든 Entry는 자료흐름도,
다른 자료사전 Entry 혹은 처리명세서에 의해서 참조되어야 한다
1999.8
S/W Engineerin_YE Han
109
구조적 분석 및 설계





정보공학
분석기초
구조적 분석 1,2,3
설계원리
구조적 설계
1999.8
S/W Engineerin_YE Han
110
설계의 단계(Design Pyramid)
데이터 설계
구조 설계
절차 설계
인터페이스 설계
인터페이스 설계
절차 설계
구조 설계
데이터 설계
잘 못된 접근법
1999.8
S/W Engineerin_YE Han
111
시스템 설계
시스템의 품질은 설계단계에서 결정된다
시스템의 설계 과정을 서둘러서 끝내면
시스템의 테스트 과정은 그만큼 더 길어진다
1999.8
S/W Engineerin_YE Han
112
시스템 설계의 현실적 문제




설계에 투입하는 시간이 너무 적다
: 너무 빨리 코딩을 시작하고 싶어한다
분석에 투입하는 시간이 너무 적다
: 분석은 좋은 설계를 위한 기초이다
설계할 때 가끔 초점을 잘 못 맞춘다
: 구조적 프로그램
대부분의 개발자들이 높은 수준의 품질을 달성하는데
도움을 주는 설계의 규범(Criteria)을 인식하지 못한다
1999.8
S/W Engineerin_YE Han
113
시스템 설계
“What” 을” How”로 변경시키는 것
데이터 모델
기능 모델
행동 모델
1999.8
설계서
설계
방법론
- 데이터 설계
- 구조 설계
- 인터페이스 설계
- 절차 설계
S/W Engineerin_YE Han
114
시스템 설계의 목적




소프트웨어의 요구사항을 만족시키는 모델을 만든다
소프트웨어의 성능을 만족시키는 모델을 만든다
설치하려고 하는 시스템에 순응하는 모델을 만든다
개발일정, 비용등과 같은 프로젝트의 제약사항을
만족시키는 모델을 만든다
1999.8
S/W Engineerin_YE Han
115
시스템 설계: 품질과의 연관성




소프트웨어를 단계적으로 추상화 한다
: 철저한 검토를 할 수 있다
검토 절차와 방법 (Review Mechanism)을 마련해서
구현할 때의 불일치, 모호함, 생략된 것을 찾아내게 한다
: 코드의 변경과 변경에 따르는 부작용을 최소화 한다
더 좋은 유지보수성에 도달하게 한다
: 변경하기 쉽고 부작용을 최소화 한다
테스트 케이스 설계를 위한 지침을 제공한다
: 철저하게 테스트 할 수 있고 많은 결함을 찾아낸다
1999.8
S/W Engineerin_YE Han
116
시스템 설계를 위한 기초 개념







추상화(Abstraction)
단계적 정련(Stepwise Refinement)
정보은익(Information Hiding)
모듈화(Modularity)
응집도(Cohesion)
결합도(Coupling)
설계척도(Design Metrics)
1999.8
S/W Engineerin_YE Han
117
추상화
1999.8
출입문
들어간다
- 제조회사
- 모델번호
- 형태
- 열리는 방향
- 무게
- ……
- …...
- 문 앞으로 간다
- 손잡이를 잡는다
- 문을 연다
- 안으로 걸어간다
- 문을 닫는다
자료
절차
S/W Engineerin_YE Han
118
단계적 정련
들어간다
- 문 앞으로 걸어간다
- 손잡이를 잡는다
- 문을 연다
- 문이 열릴 때까지 반복한다
- 안으로 걸어 간다
- 손잡이를 시계방향으로 돌린다
- 문을 닫는다
- if 손잡이가 돌아가지 않으면
- 키를 찾는다
- 구멍에 끼운다
- 시계방향으로 돌린다
- End if
- 문을 당긴다
- 옆으로 제친다
-End Repeat
1999.8
S/W Engineerin_YE Han
119
정보 은익
프로그램1
인터페이스
프로그램2
프로그램3
비밀
1999.8
S/W Engineerin_YE Han
- 알고리즘
- 자료구조
- 인터페이스 방식
- 자원활당
120
정보은익의 이유





부작용이 발생할 가능성을 감소시킨다
설계단계의 결정이 전체 소프트웨어에 영향을 미치지
않게 한다
통제되는 인터페이스를 통해서만 컴뮤니케이션 하도
록 강조한다
설계의 품질을 높여 주는 켑슐화를 가능하게 한다
고품질의 소프트웨어를 개발할 수 있게한다
1999.8
S/W Engineerin_YE Han
121
모듈이란 ?
Subroutine
- Subprogram
Procedure
Function
- Cluster of Subprogram
- Classes and Objects
1999.8
S/W Engineerin_YE Han
122
모듈화의 이유



이해하기 쉽다
변경하기 쉽다
재사용이 쉽다
1999.8
S/W Engineerin_YE Han
123
모둘화: Trade-off
소프트웨어
비용
모듈 개발 비용
모듈 통합 비용
최적 모듈 수
1999.8
S/W Engineerin_YE Han
모듈의 수
124
모듈의 크기
얼마나 큰가 ?
무엇이 있는가 ?
모듈
1999.8
S/W Engineerin_YE Han
125
모듈의 응집도

하나의 모듈이 잘 정의된 단일 기능을 수행하는 정도
모듈의 응집도는 높을 수록 좋다
 모듈안에 있는 모든 행위(Activity)들은 기능적으로 서로
연관되어 있다
 응집도가 높은 모듈은 절차적 추상화를 이루고 있다
 모듈은 하나의 자료 추상화에만 작용한다
 모듈의 응집성은 그 모듈의 인터페이스를 조사해 봄으로서
알 수 있다

1999.8
S/W Engineerin_YE Han
126
모듈의 결합도

하나의 모듈이 다른 모듈 및 외부 환경과 연결된 정도





1999.8
모듈의 결합도는 낮을 수록 좋다
상호 연결성의 정도는 최소화 되어야 한다
정보은익의 개념이 가장 좋은 특성이다
단순한 인터페이스들이 사용되고 있다
환경과의 인터페이스는 고립된다(제외된다)
S/W Engineerin_YE Han
127
설계 척도

기술적 특성을 활용하여 설계의 품질을 측정할 수 있다
구조적 척도: IEEE의 설계구조 척도
 모듈의 척도: Cyclomatic complexity(Mc Cabe)
 모듈간의 척도: Fan-out & Fan-in(Henry/Kafura)


이 척도들은 설계하고 있는 동안에 결정되고
공식적 기술 검토(FTR)에서 검토된다
1999.8
S/W Engineerin_YE Han
128
구조적 분석 및 설계





정보공학
분석기초
구조적 분석 1,2,3
설계원리
구조적 설계
1999.8
S/W Engineerin_YE Han
129
설계의 단계(Design Pyramid)
데이터 설계
구조 설계
절차 설계
인터페이스 설계
인터페이스 설계
절차 설계
구조 설계
데이터 설계
잘 못된 접근법
1999.8
S/W Engineerin_YE Han
130
데이터 설계




ERD와 DD를 이용하여 자료관리 시스템을 선정한다
각 엔티티(Data Object)에 대하여 자료구조를 정의한다
프로그램언어의 선택에 의해서 야기될 수 있는
제약사항을 고려한다
자료구조를 조작할 알고리즘을 선정한다
1999.8
S/W Engineerin_YE Han
131
설계수준에서의 엔티티
자료사전
엔티티
- Naming attributes
- Descriptive “
- Referential “
자료구조
1999.8
S/W Engineerin_YE Han
132
자료구조와 설계
Contiguous Data Structure
data element
data vectors
table
arrays
files
Non-Contiguous Data Structure
linked lists
Algorithms
stack
sorting
queues
searching
doubly linked list
look-ups
binary trees
re-ordering
comparision
building
1999.8
S/W Engineerin_YE Han
133
구조설계
고객의 요구사항:
침실 4개, 욕실 3개, 창문을 많이…..
구조설계
1999.8
S/W Engineerin_YE Han
134
프로그램 구조



프로그램 모듈과 모듈간의 관계를 나타내는 모델
기능 분활 모델
m
모듈 계층 모델
a
d
b
e
g
c
f
h
시스템 내에 있는 모듈들이 서로 연결되는 통제계층을 정의한다
1999.8
S/W Engineerin_YE Han
135
수직적 분활
m
a
d
b
e
g
c
f
h
기능 1
1999.8
기능 2
기능 3
S/W Engineerin_YE Han
기능간의 컴뮤니케이션을
조정하기 위하여
통제모듈을 사용한다
136
수평적 분활
의사결정자
m
a
d
b
e
g
c
f
작업자
h
- 의사결정자와 작업자가 모두 만족하도록 설계한다
- 의사결정자는 구조의 최상위에 위치해야 한다
1999.8
S/W Engineerin_YE Han
137
분활구조의 장점




테스트하기 쉬운 소프트웨어를 만들게 한다
유지보수하기 쉬운 소프트웨어를 만들게 한다
부작용의 발생을 적게 한다
확장이 쉬운 소프트웨어를 만들게 한다
1999.8
S/W Engineerin_YE Han
138
분활구조의 범위
m
a
d
b
e
g
* 영향범위는 통제범위 내에서
유지되어야 한다
c
f
h
r
영향범위: e,g,,h,r
통제범위: e,g,h
1999.8
S/W Engineerin_YE Han
139
구조적 설계

목적:


분활된 프로그램 구조를 도출한다
접근법:
DFD는 프로그램 구조로 Mapping 된다
 PSPEC과 STD는 모듈의 내용으로 사용된다


표기법:

1999.8
구조도
S/W Engineerin_YE Han
140
구조적 Mapping




DFD의 흐름유형(Flow Type)을 결정한다
흐름유형에 적합한 흐름경계(Flow Boundary)를
설정한다
흐름경계를 지침으로 사용하여 구조도로 Mapping한다
설계 품질지침을 사용하여 Mapping한 구조도를
정련한다
1999.8
S/W Engineerin_YE Han
141
DFD의 흐름유형 - 변환흐름
입력흐름
1999.8
변환흐름
S/W Engineerin_YE Han
출력흐름
142
DFD의 흐름유형 - 거래흐름
거래입력
행동경로
Action Path
1999.8
S/W Engineerin_YE Han
143
변환흐름 Mapping
입력흐름
변환흐름
출력흐름
ctl
ctl
1999.8
ctl
S/W Engineerin_YE Han
ctl
144
변환 구조도에서 자료흐름
ctl
ctl
ctl
입력
1999.8
ctl
출력
S/W Engineerin_YE Han
145
거래 Mapping
거래입력
행동경로
Action Path
거래 통제 구조
1999.8
S/W Engineerin_YE Han
146
거래 구조도에서 자료흐름
발송자(Dispatcher)
1999.8
S/W Engineerin_YE Han
147
거래 Mapping 단계





입력흐름 경로를 분리한다
차바퀴 쐐기(Spokes of the Wheel)를 찾음으로서 행동경
로를 정의한다
각 행동경로상의 흐름을 조사한다
발송(Dispatch)과 통제(Control)의 구조를 정의한다
각 행동경로 흐름을 개별적으로 Mapping한다
1999.8
S/W Engineerin_YE Han
148
프로그램 구조가 Mapping 되면..






설계원칙을 적용해서 설계의 품질을 평가한다
구조도를 검토한다
각 모듈의 처리기술서를 작성한다
각 모듈의 인터페이스를 정의한다
모듈 내부의 자료구조를 설계한다
설계 검토회(Walkthroughs)를 실시한다
1999.8
S/W Engineerin_YE Han
149
절차 설계(Procedural Design)
s
구조 설계
침실의 배선도
s
절차 설계
1999.8
S/W Engineerin_YE Han
150
절차 설계(Procedural Design)


코딩에 가까운 설계 작업
접근법:





1999.8
모듈 설계 기술서를 검토한다
단계적 정련 기법을 사용한다
구조적 프로그램 기법을 사용한다
공식 기법을 사용한다
품질 평가를 위해서 Walkthrough를 수행한다
S/W Engineerin_YE Han
151
단계적 정련(Refinement)
들어간다
- 문 앞으로 걸어간다
- 손잡이를 잡는다
- 문을 연다
- 문이 열릴 때까지 반복한다
- 안으로 걸어 간다
- 손잡이를 시계방향으로 돌린다
- 문을 닫는다
- if 손잡이가 돌아가지 않으면
- 키를 찾는다
- 구멍에 끼운다
- 시계방향으로 돌린다
- End if
- 문을 당긴다
- 옆으로 제친다
-End Repeat
1999.8
S/W Engineerin_YE Han
152
절차 설계를 위한

구조적 프로그래밍
한정된 논리구문(Logical Constructs)을 사용한다
순서구문:
 조건구문: If-then-else, Select-case
 반복구문: Do-while, Repeat-until



읽기 쉽고, 테스트하기 쉬운 코드를 작성하게 한다
고품질의 소프트웨어를 개발하는데 중요한
역할을 한다
1999.8
S/W Engineerin_YE Han
153
절차 설계를 위한 모델





Flowchart
Box diagram
Pseudo code(e.g PDL)
Programming language
Decision table
1999.8
S/W Engineerin_YE Han
154