Transcript Software Engineering

모델링 (Modeling)
■ 모델링이란 개발대상 시스템의 성능분석이나
동작과정 등을 알아보기 위하여 간단한 물리적
모형, 도해를 만들거나 또는 그 시스템의 특징을
수학적으로 표현하는 과정
■ 실세계를 이해하기 위해 필요
■ 모델링은 어떤 것을 만들기 전에 그것을 이해하기
위한 목적으로 추상화하는 작업
■ 모델링의 결과는 필수적이 아닌 세부적인 것은
생략하기 때문에 다루기가 쉽고 필수적인 것만을
표현
모델의 활용
■ 용도에 따라 실제의 모습을 여러 가지로 나타냄
■ 어느 한 모델이 실세계 또는 시스템의 모든 관점을
다 표현할 수 없다.
■ 모델은 단순하고 이해하기 쉬워야 하며 모호성이
없어야 한다.
■ 너무 많은 기호가 사용되면 많은 내용을 포함할
수는 있으나 이해하기 어렵다.
■ 모델링의 결과는 요구사항 명세서의 핵심 부분이
되며 프로젝트의 다음 단계로 옮겨 가는데 필요한
정보 제공
■ 모델링은 도표를 사용하여 시스템을 논리적으로
분할할 수 있게 하여 준다.
■ 모델링의 결과는 사용자와 개발자 사이의 대화의
도구로 사용
■ 프로젝트의 초기 단계에서 필요한 요구사항을 뽑아
내는 데 많은 도움을 준다.
■ 개발 단계에(설계, 구현, 시험 포함) 필요한
시스템의 윤곽과 골격 제공
소프트웨어 시스템의 세 관점
정보(객체) 모델링
(Information Modeling)
정보(객체) 관점
기능 관점
동적 관점
소프트웨어
시스템
기능 모델링
(Function Modeling)
동적 모델링
(Dynamic Modeling)
기능 관점 (Function Space)
■ 기능 모델은 시스템이 어떠한 기능을 수행하는가의
관점에서 시스템 기술
■ 데이터에 대하여 수행되는 계산에 초점을 맞춘다.
■ 기능 모델은 주어진 입력에 대하여 어떤 결과가
나오는가를 보여 주는 관점이며 연산과
제약조건을 묘사
■ 기능 모델은 시스템의 계산에 관한 논리와 현상을
보여 주는 반면, 계산이 일어나는 순서는 물론
데이터가 생성되거나 도착하는 순서 등에 대하여
기술하지 않는다.
■ 기능모델의 일반적인 표현 방법은 자료 흐름도에
의하여 도식적으로 나타난다.
■ 자료흐름도는 데이터에 수행되는 계산에 근거하여
시스템을 쪼개 나간다.
■ 자료흐름도의 중요 구성요소는 기능을 수행하는
프로세스와 자료흐름 이다.
기능 관점
■ 기능 모델링에 사용되는 대표적인 분석기법을
구조적 분석이라 하며 자료흐름도와 자료사전에
의해 그 결과를 나타낸다.
■ 구조적 분석기법은 정보의 흐름과 정보의 변환을
나타내는 방법으로 요구사항 분석 도구로 가장
많이 사용되고 있다.
사람
물 끓이기
물
차 준비
우유 추가
끓인 물
차 추가
차
설탕을 첨가한
홍차
홍차
설탕 추가
동적 관점 (Dynamic Space)
■ 시간의 변화에 따른 시스템의 동작과 제어에
초점을 맞추어 시스템의 상태(state)와 상태를
변하게 하는 원인들을 묘사
■ 이는 시스템의 시간과 변화에 대한 것을 포함
■ 시스템은 시간의 변화에 따라 한 상태에서 다른
상태로 변화하게 되므로 이러한 변화는 동적인
면을 가지게 되고, 그로 인해 이 모델을 동적
모델이라 부른다.
■ 많이 사용되는 동적 모델링 도구로는 상태변화도와
사건추적도 등
■ 상태와 사건이 동적 모델링의 주요 구성 요소
동적 관점
■ 외부와의 상호작용이 많은 실시간 시스템들은 동적
관점에서 시스템이 기술되어야 한다.
■ 상태변화도(State Transition Diagram), State Chart,
SDL(Specification and Description Language),
페트리네트(Petri net) 등이 대표적 도구
물 추가
물 끓이기
차 추가
설탕 추가
우유 추가
차 준비
사람
차 만드는
시스템
정보 관점 (Information Space)
■ 정보 모델은 시스템에 필요한 정보를 보여
줌으로써 시스템의 정적인 정보구조를 포착
■ 시스템에 사용되는 정보 객체를 찾아내고, 이들
객체의 특성, 객체들 사이의 관계와 연관성을 규명
■ 정보 모델은 다른 두 관점보다 실세계를 정확히
묘사할 수 있는 장점
■ 이 모델에 나타나는 객체들은 다른 모델에서
나타나는 결과와는 달리, 변하지 않고 안정감이
있어 시스템 개발에 있어 튼튼한 기초를 제공
■ 정보 모델은 시스템의 기능이나 동적인 면을
고려하지 않으며 오직 정적인 것에만 초점
■ 정보 모델은 특히 시스템의 데이터베이스를
분석하는 데 많이 사용
■ ER 모델 또는 EER 모델은 그 대표적인 도구
정보 관점
■ 정보의 중요성이 부각됨에 따라 시스템의
기능보다는 정보와 데이터에 초점을 맞추는
추세이며 정보 모델링의 중요성도 증가
■ 객체지향 시스템 개발 방법론도 정보 모델링을
기초로 하여 시스템을 분석하고 개발하는 접근
방법
■ 객체지향 모델은 객체의 정적인 정보에 객체의
동적인 면과 기능 관점을 추가하여 완벽한 객체를
구현하는 게 그 목적
차
설탕
물
찻잎
우유
사람
세 관점의 통합
■ 세 가지 모델은 시스템의 각기 다른 면을 나타내며
어느 하나도 시스템 전체를 완벽하게 설명하지
못한다.
■ 세 가지 관점이 모아지고 통합(integration)되어야
시스템의 요구사항이 완벽하게 표현될 수 있다.
■ 개발하는 응용 분야에 따라서는 한 관점이
시스템의 필요한 모든 모습을 거의 다 설명하여 줄
수도 있을 것이며, 이런 경우 다른 관점은
간략하게 묘사되거나 생략될 수 있다.
예) 컴파일러 시스템: 기능 모델링
데이터베이스 시스템: 정보 모델링
통신 시스템: 동적 관점 + 기능 관점
구조적 분석

구조적 분석 (Structured Analysis)
시스템을 분할하고 이해하는데 유용한 분석 방법
 Top-down Decomposition
 Graphic Language
 Model Building
 Data structuring techniques
System = Processes + Data flows between Processes
System Model = Data Flow Diagrams + Data Dictionary
Specification = System Model + Mini-specs
<장점>
 광범위한 보급
 체계적 방법 제공
- 구조적 설계와 연결
- 자연스러운 도큐먼트 산출 - 분석 작업의 부산물
- 자동화 도구의 지원 가능
 이해하기 쉽다.
- Walkthrough 가능
- 사용자 반응 유도
 관리 자료 제공
- 크기 판단 자료 (개발 비용, 개발 기간, 소요 인력, ....)
구조적 분석

자료 흐름도(Data Flow Diagram : DFD)

구성 요소
Data Flow
source
/ sink
process
Data Store
Inventory
fill
order
scan
order
approved_order
Books
check
credit
Customer
구조적 분석

자료 흐름도

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



더 이상 분해할 수 없는 원자적 process
모듈로 구현 가능한 process
균형 유지
 다른 level에 있는 DFD간의 균형 유지
 Data 보존 법칙 : Process는 data를 변환할 뿐 창출,
소멸시키지 않는다.
구조적 분석

자료 사전 (Data Dictionary)

구성 요소
 = is equivalent to
 + and
 [ ] either or
 { } iterations of
 ( ) optional
 * * comment

예
Resume = Personal data + {Education} + {Experience} +
{Family} + ....
Course = {Course_No + Title + Description + Credit +
({Prerequisite}) + ({Text_title + Text_author})}
구조적 분석

소단위 명세 (Mini-Specification)
 Functional primitives에 대해서 쓰여진다.
 서술식 문장도 가능
 decision tables, decision trees로도 기술

Structured English
 pseudo code의 형태
 제약적인 어휘, 제약적인 구조
예 : Invoice 처리 정책
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. 제목 및 목차
2. 서론
// 시스템의 목표를 기술
2.1 독자(Audience)
2.2 전체 기술(Overall Description)
2.3 프로젝트 제약조건(Project Constraints)
3. 기능 기술
3.1 자료 흐름도(Data Flow Diagram)
3.2 프로세스 명세서(Process Specification)
3.3 자료 사전(Data Dictionary)
4. 정보 기술
4.1 ERD(Entity-Relationship Diagram)
4.2 Data Dictionary
5. 초보 사용자 매뉴얼
6. 검증 기준
// 검증을 위한 check list를 포함
7. 기능이 아닌 요구사항
// 규제 조항, 제약 조건
8. 요약
9. 부록
구조적 분석 기법

Use Case를 이용한 구조적 분석
1. 문제 기술 준비
2. 시스템을 사용하는 행위자(actor)를 파악
2.1 주 행위자(primary actor) 파악
2.2 부 행위자(secondary actor) 파악
3. 각 행위자에 대하여 use case를 찾아내고 목록을
만든다. <= 정보를 만들거나 사용하는 use case만
고려
4. 각 use case에 대하여 기본적인 활동만 구체적으로
기술
5. 각 use case에 대하여 예외적인 경우와 선택적인
경우를 찾아내어 구체적으로 기술 <= 기본적인
활동과 상당히 다른 경우만을 조사
구조적 분석 기법

문제 기술 (Problem Statement)
요구 사항을 기술
 문제 기술에 포함되어야 하는 내용
1. 해결하려는 문제점에 대한 명확한 기술 (고객의
관점에서 고객이 사용하는 용어로)

 현재의 상황, 배경
 시스템 개발의 필요성
 문제 제약 조건
 달성하려는 목표
2. 추진 전략 및 방법 기술 (구체적으로)
 개발 방법론
 접근 방법
3. 제공되어야 할 기능, 시스템의 제약 조건, 요구되는
H/W, 연관되는 S/W, 일의 범위
4. 시스템 차원의 목표, 개발 과정에서 요구되는 사항,
결과물
5. 추상적인 차원(high-level)에서 합격 판정 검증 기준
6. 시스템 개발 시 예상되는 기대 효과 및 활용 방안
구조적 분석 기법

자판기 문제 기술
우리가 만들고자 하는 시스템은 24시간 내내 고객에게 음료수를 제공 할 수 있는
간단한 음료수 자판기이다. 이 자판기는 여러 종류의 음료수를 제공할 수 있어야 하며
한번에 오직 한 고객에게 한 종류의 음료수만을 제공한다. 음료수는 서로 다른 가격을
가질 수 있으며, 자판기는 음료수 가격을 고객에게 보여준다. 이 자판기는 동전의
무게와 크기를 측정하여 입력된 동전의 금액을 측정한다. 모두 네 가지 종류(10, 50,
100, 500)의 동전이 사용 가능하며 자판기는 삽입된 동전의 총 금액 또는 현재의
잔액을 기억하고 사용자에게 보여줄 수 있어야 한다.
고객이 원하는 음료수를 얻기 위해서는 적어도 그 음료수 값과 동일한 금액만큼의
동전을 삽입해야 한다. 자판기에 충분한 금액의 동전이 입력되었을 때, 고객이 원하는
음료수 버튼을 누름으로써 음료수를 선택 했음이 자판기로 전달되고 선택한 음료수가
제공된다. 음료수가 제공 된 후, 자판기는 고객이 잔돈 회수 버튼을 누르면 거스름돈을
돌려 준다.
선택된 음료수가 제공된 후, 고객은 잔돈 회수 버튼을 누르지 않고 다른 음료수를
선택할 수도 있다. 이것은 자판기에 또 다른 음료수를 선택할 수 있을 만큼 돈이
남았거나 또는 고객이 자판기에 동전을 더 집어넣어 모자라는 금액을 보충한 경우이다.
고객이 선택한 음료수가 남아있지 않은 경우 선택한 음료수는 제공될 수 없다. 이때
고객은 다른 음료수를 선택하거나 잔돈 회수 버튼을 누를 수 있다. 고객이 선택한
음료수의 값이 입력된 금액(또는 잔액)을 초과하면 음료수는 제공되지 않는다. 고객이
동전을 삽입한 뒤에 마음을 바꿔 동전 회수 버튼을 누르면 동전을 다시 환불 받을 수
있다.
자판기에 거스름돈이 없을 경우, 자판기는 고객에게 정확한 금액을 투입할 것을
알린다. 이런 경우 선택할 음료수의 값보다 더 많거나 적은 양의 동전이 삽입되면,
음료수는 제공되지 않는다.
자판기는 관리자에 의해 유지되며 관리자를 위해 두 종류의 기능을 제공한다. 관리자는
음료수의 가격을 바꿀 수 있으며 그날 이루어진 모든 거래는 프린트된 보고서를 통하여
얻을 수 있다.
구조적 분석 기법

자판기 문제 기술

자판기의 외형
À½·á¼ö A
À½·á¼ö B
À½·á¼ö C
Ãѱݾ×
µ¿Àü¹Ýȯ¹öÆ°
Àܵ·¾øÀ½
·¥ÇÁ
µ¿Àü»ðÀÔ±¸
À½·á¼ö
³ª¿À´Â°÷
µ¿Àü¹Ýȯ±¸

À½·á¼ö D
자판기 행위자 규명
 주 행위자 : 음료수를 뽑기 원하는 고객
 부 행위자 : 자판기 관리자

행위자 입장에서의 자판기 기능
 고객 : 음료수를 뽑는다.
 관리자 : 거래량을 출력한다.
음료수 가격을 바꾼다.
구조적 분석 기법

시스템과 행위자의 상호작용 기술 (기능별로)

음료수를 뽑는다
 고객이 자판기에 첫 번째 동전을 넣었을 때 시작된다.
자판기는 금액 표시란에 입력된 금액을 보여준다.
 동전을 더 넣으면 자판기는 금액을 증가시키고 금액
표시란에 총액을 보여준다.
 표시된 총 금액이 고객이 원하는 음료수 가격과
같거나 더 많을 때, 고객은 음료수 버튼을 누르고
음료수를 선택할 수 있다.
 고객이 원하는 음료수에 대한 버튼을 누를 때,
자판기는 음료수를 제공한다.
 음료수가 제공된 후, 자판기는 현재 총액에서
음료수의 가격을 뺀 나머지 수정된 총액을 보여준다.
 고객은 잔돈 회수 버튼을 누르고 자판기는 금액
표시란에 보여진 총액과 같은 금액을 되돌려준다.
 자판기는 거래를 기록한다. 즉, 고객에게 제공된
음료수의 총 양을 증가시키고, 고객에게 지출된
거스름돈의 양 만큼 거스름돈의 총액을 감소시킨다.
구조적 분석 기법

시스템과 행위자의 상호작용 기술 (기능별로)

하루 동안의 음료수 거래량을 출력한다
 관리자가 자판기를 열 때 시작된다. 관리자는 암호
입력 후 시스템 모드 스위치를 ‘관리’로 설정한다.
 관리자는 그날 거래의 보고서를 얻기 위해 변환 설정
버튼을 ‘거래량 출력’으로 놓는다. 그 날 거래된
음료수의 종류별 숫자, 각 음료수에 대한 매출액, 그
날 팔린 음료수의 총 금액을 포함한 정보가 출력된다.
 관리자는 음료수의 숫자와 총 양을 초기화시킨다.
 관리자는 시스템 모드 스위치를 ‘운영’으로 설정하고
자판기를 잠근다.
구조적 분석 기법

시스템과 행위자의 상호작용 기술 (기능별로)

음료수 가격을 바꾼다
 관리자가 자판기를 열어놓았을 때 시작된다.
관리자는 암호 입력 후 시스템 모드 스위치를 ‘관리’로
설정한다.
 관리자는 음료수의 가격을 바꾸기 위해 변환 설정
버튼을 ‘음료수 가격 변환’으로 놓는다.
 관리자는 음료수의 종류와 새로운 가격을 입력한다.
 관리자는 시스템 모드 스위치를 ‘운영’으로 설정하고
자판기를 잠근다.
구조적 분석 기법

각 기능의 예외적인 상황에 대한 기술

음료수를 뽑는다
 정상적인 경우 :
음료수가 제공된다.
 예외적인 경우 :
금액 부족
취소
음료수 없음
거스름 돈 없음
구조적 분석 기법

구조적 분석 기법에 의한 모델 개발
1. Context diagram을 만드는 순서
1) 시스템에 대한 프로세스, 이름 작성
2) 각 행위자에 대한 외부 객체를 작성
3) 행위자와 시스템의 인터페이스 규명 (정보, 사건)
4) use case를 통해 파악된 정보들을 외부 객체와
프로세스 사이의 자료 흐름, 제어 흐름으로 표시
5) 연관된 자료 흐름과 제어 흐름들을 통합 <= 같은
유형, 같은 외부 객체에 연관되어 있는 흐름 통합
2. 레벨 1 자료흐름도 개발 순서
1) 각 use case => 하나의 프로세스, 여러 use case에
존재하는 공통 기능 => 프로세스
2) 각 use case를 분석 => 자료 흐름, 정보 흐름 추가
3) 각 use case를 분석, 서로 다른 use case를
수행하는 동안 기억되어야 할 데이터 => 자료 저장소
4) 필요한 정보에 따라 프로세스들을 자료저장소에
연결 <= 각 행위자에 대한 처리가 동시적으로
일어나지 않으면 프로세스 사이에 직접적인 교류가
일어나지 않고 자료저장소를 통하여 정보 교류
5) Context diagram과 비교하여 모순이 없도록 검사
구조적 분석 기법

구조적 분석 기법에 의한 모델 개발
3. 자료흐름도의 각 프로세스에 대하여
1) 레벨 1 자료흐름도 개발 순서와 동일한 방법으로
아래 단계의 자료흐름도를 개발
2) 각 use case의 기본적인 활동, 예외적인 경우,
선택적인 경우에 대하여 프로세스 생성 가능 <=
필요한 자료 흐름, 자료저장소에 대해서는 2.2, 2.3,
2.4와 같이 진행
3) 프로세스가 복잡하면 계속 더 낮은 단계로 확장
4) 모든 원시 프로세스(Functional primitives)에
대하여 mini-spec 작성
구조적 분석 기법

자판기의 정보 흐름






고객 메시지 = 금액 부족 메시지 + 음료수 없음
메시지 + 잔돈 없음 메시지
가격 변경(newprice_info) = 음료수 종류 + 새 가격
음료수 요구 = 총액 + 음료수 선택
음료수 요구 결과 = (음료수) + (반환 동전) + 잔액
자격 = 암호 + 시스템 모드
자판기 상태 = {음료수 가격 + 음료수 상태} + 잔돈
상태
DFD Mini-exercise #1
The computer which is sending the message gives to
the IMP(Intermediate Message Processor) the text of
the message, along with the sender ID and the ID of
the computer which is to receive the message. The
IMP computes the message charge (based on length)
and returns it to the sender. It then uses the receiving
computer’s ID to retrieve the required message format
from storage. It uses this information to break the
message into the appropriate packets, and sends them
to the receiving computer.
DFD Mini-exercise #2
The researcher gives her name and either the
compound name or the desired sequence of bases to
the Gene Machine. It synthesizes the DNA sample
from its store of nucleotides. The Gene Machine
obtains the researcher’s charge number, and note it on
the upper right hand corner of the printout for the
sample, and place the printout in the sample log. And
then it gives the logged sample to the researcher.
DFD Mini-exercise #3
From the Hospital background:
At the beginning of my shift, I take the pile of doctor’s
notes, make sure they are consistent (writing a note to
the physician where I need him to correct problems)
and update the patient charts with the new treatment
and test information. After updating the charts, I
produce two schedules for my nurse’s activities during
the shift. These are the test schedules and treatment
schedules.
Toward the end of my shift, I go around to all the
patients and check their charts. I note any missed or
incorrect treatments of patients. Then I berate the
nurse(s) responsible and add to the notes to the
physician any errors we made.