Transcript Structured Analysis

Structured Analysis
Modeling(1)
Modeling이란?
 A model is a miniature representation of
something for imitation or emulation
 Modeling: 어떤 것을 만들기 전에 그것을 이해하
기 위한 목적으로 추상화하는 작업
 복잡한 Real World를 이해하는데 필요
 대상 시스템을 용도에 따라 여러 가지 model로 표현
 하나의 모델이 시스템의 모든 관점을 표현할 수 없음
 세부적인 것은 생략하고, 필수적이고 다루기 쉬운 것
만을 표현
 Simple, Understandable, Unambiguous
 과다한 기호 사용 --> 표현력 증가, 이해하기 어려움
Modeling(2)
Model의 활용
 도표를 사용하여 시스템을 논리적으로 분할
 프로젝트의 초기 단계에서 필요한 요구사항을
추출하는데 효과적
 모델링의 결과
 요구분석 명세서의 핵심 부분
 프로젝트의 다음 단계로 옮겨 가는데 필요한 정보
를 제공
 사용자와 개발자 사이의 대화 도구로 사용
 개발 단계에 필요한 시스템의 윤곽 및 골격 제공
소프트웨어 시스템의 세 관점
정보(객체) 모델링
(Information Modeling)
정보(객체) 관점
기능 관점
동적 관점
소프트웨어
시스템
기능 모델링
(Function Modeling)
동적 모델링
(Dynamic Modeling)
Functional Modeling
Functional Model
 기능 관점(Function space)에서 시스템을 표현
 입력을 출력으로 변환시키는 계산과 제약조건을 기술
 계산의 순서, 자료의 생성 및 도착 순서는 생략
구조적 분석 기법
 Functional Modeling에 사용하는 대표적인 분석기법으
로 요구분석 도구로 가장 많이 이용
 자료의 흐름 및 변환을 나타내는 자료흐름도, 자료사전,
소단위명세서로 시스템을 표현
 자료흐름도는 자료에 대한 계산에 근거하여 시스템을
분할
Dynamic Modeling(1)
Dynamic Model
 시간의 변화에 따른 시스템의 동작에 초점
 시스템의 상태(state)와 상태를 변하게 하는 원인
(event)을 묘사
 외부와의 상호작용이 많은 실시간 시스템을 기술하는
데 적합
대표적인 동적 모델링 도구




상태변화도(State Transition Diagram), 사건추적도
State Chart
SDL (Specification and Description Language)
Petri net
Dynamic Modeling(2)
물 추가
물 끓이기
차 추가
설탕 추가
우유 추가
사람
차 준비
차 만드는
시스템
Information Modeling (1)
Information Model
 시스템에서 사용하는 정보 객체 및 시스템의 정적인 정보
구조(객체의 특성, 객체 사이의 관계)를 포착
 객체는 자주 변하지 않아 시스템 개발에 튼튼한 기초제공
 다른 관점보다 실세계를 정확히 묘사할 수 있는 장점
 시스템의 데이터베이스를 설계하는데 효과적
 시스템의 기능보다 정보와 데이터에 초점을 맞추는 추세
에 따라 정보 모델링의 중요성 증가
대표적인 정보 모델링 도구
 ER 모델, EER 모델
 객체지향 모델
Information Modeling (2)
차
설탕
물
찻잎
우유
사람
3가지 관점의 통합
통합의 필요성
 3가지 모델은 시스템의 서로 다른 측면을 표현
--> 시스템 전체를 완벽하게 설명하지 못함
 3가지 관점을 통합(integration)하여야 시스템의 요구
사항을 완벽하게 표현할 수 있음
통합이 불필요한 경우
 하나의 관점으로 시스템을 거의 설명할 수 있을 때
 다른 관점은 간략하게 묘사하거나 생략할 수 있음
 예
 컴파일러 시스템: 기능 모델링
 데이터베이스 시스템: 정보 모델링
 통신 시스템: 동적 관점 + 기능 관점
Structured Analysis(1)
기본 개념
 System = Processes + Data flows between
Processes
 System Model = Data Flow Diagrams + Data
Dictionary
 Specification = System Model + Mini-specs
특징




Top-down Decomposition
Graphic Language
Model Building
Data structuring techniques
Structured Analysis(2)
장점
 광범위한 보급
 체계적인 방법 제공
 구조적 설계와 연계
 자연스러운 문서 산출 - 분석 작업의 부산물
 자동화 도구의 지원 가능
 이해하기 쉬움
 Walkthrough 가능
 사용자 반응 유도
 관리 자료 제공
 크기 판단 자료 (개발 비용, 개발 기간, 소요 인력, ..)
Structured Analysis(3)
구조적 분석의 세부 작업
1. 배경도(Context Diagram) 작성
 시스템의 추상적인 개관을 표현
2. 상위 자료흐름도 (Level 0 Diagram) 작성
 전체시스템을 구성하는 큰 부분을 기술
3. 하위 자료흐름도 (Level 1, Level 2, ,,) 작성
 시스템의 각 부분에 대한 상세한 묘사
 특정 부분을 zoom in 하여 확대하는 방식 적용
 더 이상 자세히 나타낼 필요가 없으면 종료
4. 자료 사전 (Data Dictionary) 작성
5. 소단위 명세서 (Mini-specs) 작성
Data Flow Diagram(1)
자료흐름도(DFD)의 구성 요소
 Process: 원/둥근 사각형으로 표기, 내부에 이름 기재
 Data Flow: 프로세스 연결, 화살표 위에 자료 이름 기재
 Data Store: 한쪽/양쪽이 열린 직사각형으로 표기, 파일
이름 기재
 Data Source/Sink: 시스템 외부에 있는 자료 출처/도착지
Data Flow
source
/ sink
process
Data Store
Data Flow Diagram(2)
자료흐름도의 예
Inventory
fill
order
scan
order
approved_order
Books
check
credit
Customer
Data Flow Diagram(3)
Leveling
 크고 복잡한 문제를 극복하기 위한 방안
 하향식 분해(top-down decomposition)
 high level : 사용자 관점, 시스템의 개념적인 관점
 low level : 개발자 관점, 시스템의 상세한 관점
 Context Diagram
 최상위 수준의 다이어그램으로 시스템의 경계를 표시
 순수한 I/O 부분만 표시, 주변 환경과의 인터페이스




1st level : Diagram 1, Diagram 2, ...
2nd level : D 1.1, 1.2, 1.3, ...., D 2.1, 2.2, 2.3, ....
3rd level
Functional primitives
 더 이상 분해할 수 없는 원자적 프로세스
 모듈로 구현 가능한 크기의 프로세스
Data Flow Diagram(4)
하향식 분할(Top-down Decomposition)
 같은 level의 문제는 같은 수준의 상세도 유지
 각각의 문제는 독립적인 문제로 분리
 분해된 부분 문제의 해를 모으면 원래 문제를
해결할 수 있어야 함
균형 유지 (Balancing)
 다른 level에 있는 DFD간의 균형 유지
 Data 보존 법칙: Process는 data를 변환할 뿐
창출, 소멸시키지 않는다.
 자료흐름이 분할된 경우 자료사전에 명시
 교재 그림 3.8 참조
Data Flow Diagram(5)
자료흐름도 작성 방법
 시스템 경계의 입출력을 식별하는 작업부터
시작 --> Context Diagram
 자료의 흐름에 초점을 두고, 자료가 어떤 과정
을 거쳐 변형되는가를 파악
 자료 흐름과 프로세스의 Naming은 매우 중요
 한 장에 한 level의 자료흐름도만 포함하고, 프
로세스는 7개 전후로 제한
 최하위 단계의 프로세스는 Mini-spec을 한 장
에 기술할 수 있는 정도의 크기로
 프로세스의 분할할 때 균형을 유지
Data Flow Diagram(6)
자료흐름도 검사
 correctness checking
 completeness checking
 consistency checking
자료흐름도 다듬기를 위한 Heuristics




자료흐름의 변형이 없는 프로세스
Control flow를 외부로 표현하는 것은 회피
과도하게 세분된 프로세스는 하나로 통합
같은 외부 개체/파일과 상호 작용하는 프로세스
는 가능한 한 하나로 통합
Data Dictionary (1)
자료사전?
 자료흐름도의 자료 항목에 대한 정의들의 집합
 자료 정의 형태: 자료 요소의 이름 = 수식
 수식: 자료 요소와 연산자로 구성
연산자의 종류 및 의미






+ and
| or
‘string’ string constant
[ ] optional
{ } iterations of
* * comment
Data Dictionary (2)
예
 Resume = Personal data + {Education} +
{Experience} + {Family} + ....
 Course = {Course_No + Title + Description
+ Credit + {Prerequisite} + [{Text_title +
Text_author}]}
Mini-specs (1)
소단위명세서?
 Functional primitives의 기능에 대하여 기술
 기술 방법
 Structured English
 Decision tables
 Decision trees
 Nassi-Shneiderman chart
Structured English
 pseudo code의 형태로 제한된 어휘 사용
 제한적인 구조: 순차, 선택, 반복
Mini-specs (2)
의사결정표(Decision Tables)
 프로세스가 여러 가지의 조건에 따라 각각 다른
처리를 하는 경우에 적합
 가능한 cases에 대한 조건(conditions) 및 처리
내용(processes)을 기술
의사결정도(Decision Trees)
 자료 항목의 값에 따른 처리 내용을 트리 구조
로 표현
 의사결정표와 동일한 표현력
Mini-specs (3)
예: Invoice 처리 (Structured English)
If the amount of the invoice exceeds $500
If the amount has an invoice more than 60 days overdue
hold the confirmation pending resolution of the debt
Else (account is in good standing)
issue confirmation and invoice
Else (invoice $500 or less)
If the account has any invoice more than 60 days overdue
issue the confirmation, invoice and write message on the credit
action report
Else (account is in good standing)
issue confirmation and invoice
구조적 분석기법을 적용한 모델링 (1)
1. Context diagram을 작성
1.1 시스템의 이름을 제작
1.2 시스템과 관련된 외부 객체를 정의
1.3 시스템과 외부 객체 사이의 인터페이스
(정보, 사건)를 파악
1.4 파악한 인터페이스를 시스템과 외부 객체
사이의 자료 흐름으로 표현
1.5 자료흐름을 자료사전에 등록
구조적 분석기법을 적용한 모델링 (2)
2. 레벨 1 자료흐름도 작성
2.1 시스템의 use cases를 파악하여 프로세스로
설정
2.2 각각의 use case를 분석하여 자료 흐름을 추
가
2.3 다른 use case를 수행하는 동안 기억해야 할
데이터는 자료저장소로 표현
2.4 필요한 정보에 따라 프로세스와 자료저장소
를 연결
2.5 Context diagram과 비교하여 모순이 없는지
확인
구조적 분석기법을 적용한 모델링 (3)
3. 자료흐름도의 각 프로세스에 대하여
3.1 레벨 1 자료흐름도 작성 방법과 동일한 방
법으로 아래 단계의 자료흐름도를 개발
3.2 각각의 use case의 기본적인 활동, 예외적
인 경우, 선택적인 경우에 대하여 프로세스
생성 가능
3.3 프로세스가 복잡하면 계속 더 낮은 단계로
확장
3.4 모든 Functional primitives에 대하여
mini-spec 작성
4. 요구분석명세서 작성
구조적 분석기법을 적용한 모델링 (4)
요구분석명세서 양식 (예시)
1. 개요
1.1 시스템의 개요
1.2 목표
2. 기능적 요구
2.1 자료흐름도
2.2 자료 사전
2.3 소단위명세서
2.4 기능 면에서의 시스템의 특징
3. 기타 요구 및 제약 사항 (비기능적 요구)
3.1 성능 요구 (반응시간, 처리소요시간, 처리율)
3.2 H/W 요구 (기억장치 규모, 통신 수용도)
3.3 예외 조건 및 처리
3.4 사용자 인터페이스
3.5 자원, 인력에 대한 제약 조건
4. 인수 조건
4.1 기능 시험 및 성능 시험
5. 참고 자료 및 용어 해설