Transcript Discrete Mathematics

소프트웨어 공학 (Software Engineering)
설계 (Design)
최미정
강원대학교 컴퓨터과학전공
Where we are in waterfall model?
설계 (Design)
계획
요구 분석
설계
구현
시험
인수설치
Page 2
Software Engineering
In this chapter …
설계 (Design)
요구 분석이 끝나면, 소프트웨어의 내부 구조를 설계하여야 한다.
지금까지는 “what”에 주안점이 있었다면, 지금부터는 “how”에 주안점을
두고 작업을 진행한다.
건축으로 치면, 설계 도면을 작성하는 작업이다.
 방을 어디다 두고, 크기는 얼마로 하며, 어떤 모양으로 만들고, …
We will cover …
• 설계의 정의 및 원리
• 구조적 설계
• 소프트웨어 구조
• 프로그램 설계
• 사용자 인터페이스 설계
• 설계서 작성
Page 3
Software Engineering
We are now …
설계 (Design)
설계의 정의 및 원리
구조적 설계
소프트웨어 아키텍처
프로그램 설계
사용자 인터페이스 설계
설계서 작성
Page 4
Software Engineering
설계(Design)? (1/2)
설계 (Design)
설계란 “사용자의 요구를 만족시키기 위하여 제약 조건이 반영된 구현 대
안을 창출하는 일”이다.
설계란 “소프트웨어 시스템의 내부를 설계”하는 일이다.
즉, 1) 모듈의 구조, 2) 자료 구조, 3) 알고리즘을 설계하는 일이다.
분석
설 계
사용자
요구사항
제약 조건
시스템의
본질정의
구현대안
설정
분석모형
구현
구축 시스템
시스템
구축
설계모형
Page 5
Software Engineering
설계(Design)? (2/2)
설계 (Design)
설계를 수행하는 가장 좋은 방법은…
 없다. 많은 방법 중에서 “가장 좋다” 생각하는 대안을 찾아야 한다.
설계자는 사용자와 개발자를 동시에 만족시켜야 한다.
•
사용자는 설계를 보고 시스템이 어떤 기능을 하는지 이해할 수 있어야 한다.
(집 주인이 집 설계도를 보고 집이 어떻게 지어질지 알 수 있어야 한다.)
•
개발자는 시스템이 어떻게 동작하고, 어떻게 구현하는지 이해할 수 있어야 한다.
(집 짓는 사람들이 설계도를 보고 집을 어떻게 지어야 하는지 알 수 있어야 한다.)
설계의 구분
•
구조 설계 ( 전체적 설계, 모듈의 종류, 기능, 인터페이스 등)
•
상세 설계 ( 세부적 설계, 모듈 내의 기능)
Page 6
Software Engineering
구조 설계 – 상위 레벨 설계
설계 (Design)
시스템의 구조 설계
기능을 분해
모듈 구조 (모듈 자체의 기능, I/O 설계)
모듈 간의 관계를 정립(모듈 인터페이스)
자료 설계(데이터베이스 설계)
결과
시스템 구조도(Structure Chart)
외부 파일 및 DB 설계도(레코드 레이아웃, ERD)
Page 7
Software Engineering
상세 설계 – 하위 레벨 설계
설계 (Design)
모듈 내부 설계
•
모듈 안의 알고리즘
•
모듈 안의 지역 변수
사용자 인터페이스
•
메뉴
•
입력 폼
•
출력 레포트
자료구조 설계
•
구조형 및 배열
결과
프로그램 사양서
화면 및 출력물 레이아웃
Page 8
Software Engineering
설계 방법론
설계 (Design)
구조적 설계(structured design)
•
시스템을 기능적 관점에서 다룸
•
하향적 세분화
객체지향 설계(object-oriented design)
•
자료와 자료에 적용될 기능을 함께 추상화
•
객체: 자료+기능
•
시스템은 객체의 모임
자료구조 중심 설계
•
입출력 자료의 구조 파악으로 소프트웨어 구조를 추출
•
Data Structure + Algorithm = Program
Page 9
Software Engineering
설계 원리 (1/2)
설계 (Design)
분할의 기본 원칙:
변경(update)이 있을 경우, 이를 최소화하는 식으로 분할해야 한다.
IPO(Input Process Output) 모형
입력
프로세스
출력
구조도 (Structure Chart)
제어
프로세스
프로세스
프로세스
Page 10
Software Engineering
설계 원리 (2/2)
설계 (Design)
설계 원리
• 추상화(abstraction):
복잡한 문제를 일반화하여, 쉽게 이해할 수 있도록 하는 원리
( 피타고라스 정리?)
• 정보 은닉(information hiding):
함수의 내부 변수 사용이 외부에 알려질 필요가 없다…
( 내정 간섭하지 마요~)
• 단계적 분해(stepwise refinement):
처음엔 간단히, 차츰 세밀하게…
( 사칙연산  더하기  정수 더하기)
• 모듈화(modularization):
모듈은 독립성을 가져야 함…
( 많은 라이브러리 함수를 생각하세요, 삼각함수 등)
Page 11
Software Engineering
추상화 (Abstraction)
설계 (Design)
(현실의) 복잡한 문제  추상화  개념 정립
소프트웨어의 구조를 이루는 계층의 파악
기능 추상화
•
입력자료를 출력자료로 변환하는 과정을 추상화
•
부프로그램(subprogram)의 목적과 기능만 생각
자료 추상화
•
자료와 기능을 묶어서 생각 (data object 구성하는 방법)  OO Concept
제어 추상화
•
외부 이벤트에 대한 반응을 추상화  … 입력되면 …을 처리하고…
Page 12
Software Engineering
정보 은닉(Information Hiding)
설계 (Design)
각 모듈의 자세한 처리 내용이 시스템의 다른 부분으로부터 감추어져 있
어야 ( 내부적으로 어떤 변수를 쓰던…)
각 모듈이 다른 모듈에 구애 받지 않고 설계  I/F만 잘 정의하자.
인터페이스가 모듈 안의 구체적 사항을 최소로 반영
•
전역변수가 없어야
•
모듈의 입력이 1이면 입력, 2이면 출력, …  좋은 모듈 설계가 아님  모듈화와 연관
모듈 단위의 수정, 시험, 유지보수에 큰 장점
•
모듈 설계 평가에 기초
•
모듈을 독립적으로 시험할 수 있으며, 모듈 별로 개선 및 최적화 할 수 있음
Page 13
Software Engineering
단계적 분해(Stepwise Refinement)
설계 (Design)
기능을 최대한으로 떼어내어 생각
점진적으로(incrementally) 구체화
상세한 내역(알고리즘, 자료구조)는 가능한 뒤로 미룸
추상화 I
CAD system
추상화 II
추상화 III
CAD softrware tasks:
procedure: 2-D drawing creation;
user interaction task;
repeat util <drawing creation task terminates>
2-D drawing creation task;
do while <digitizer interaction occurs>
graphics display task;
digitizer interface task;
drawing file management task;
determine drawing request;
end.
line: line drawing task;
circle: circle drawing task;
.
.
.
Page 14
Software Engineering
모듈화(Modularization) (1/6)
1
4
2
5
설계 (Design)
1
4
2
5
3
6
0
3
6
문제영역
시스템 분해
1
2
4
3
5
6
시스템 구조
시스템 분해를 어떻게 해야 할 것인가?  모듈로 분해한다.
한 모듈의 규모는 어떠해야 하는가?
•
30 lines ~ 50 lines ???
•
너무 길면 이해하기 어렵고, 너무 짧으면 성능이 저하됨
Page 15
Software Engineering
모듈화(Modularization) (2/6)
설계 (Design)
모듈의 이식성(portability)
•
특정 환경에서만 동작하는 것이 아니라 일반적 환경에서 동작하면 이식성이 높다고 이
야기한다.
•
이식성이 높은 S/W를 개발하는 것은 모든 S/W Engineer의 공통된 목표이다.
모듈을 어떻게 만들 것인가? 어떻게 모듈을 구성할 것인가?
 모듈(내) 응집력(intra relationship)은 강하게,
 모듈(간) 결합력(inter relationship)은 약하게
•
모듈의 응집력: 모듈 내 기능/요소들이 갖는 관계
•
모듈의 결합력: 모듈 간의 관계
Page 16
Software Engineering
모듈화(Modularization) (3/6)
설계 (Design)
모듈의 응집력(Cohesion)
•
하나의 모듈은 전체 시스템이 갖는 여러 기능 중에 하나의 기능을 갖도록 설계해야…
•
모듈 내의 모든 요소는 하나의 목적을 가지고 있는 것이 바람직하다.
•
Theme sentence: 한 문단의 주제를 담고 있는 문장 (vs. support sentence)
모듈의 응집력 구분
•
•
•
기능적 응집(functional cohesion):
잘 정의된 하나의 기능이 하나의 모듈을 이룬 경우
예) “판매 세금 계산”  (동사, 목적어) 한 쌍으로 구성
순차적 응집(sequential cohesion):
모듈 내 한 작업의 출력이 다른 작업의 입력이 되는 경우
예) “다음 거래를 읽고, 그 결과를 마스터 파일에 반영함”
응집력이 강함
응집력이 약함
교환적 응집(communication cohesion):
동일한 입력과 출력을 사용하는 여러 작업들이 모인 경우
예) “인사 기록 파일에 근무 성적을 기재하고, 급여를 갱신함”
Page 17
Software Engineering
모듈화(Modularization) (4/6)
설계 (Design)
모듈의 응집력 구분 (계속)
•
응집력이 강함
절차적 응집(procedural cohesion):
공유하는 것은 없으나, 큰 테두리 안에서 같은 작업에 속하는 경우
예) “총계를 출력하고, 화면을 지우고, 메뉴를 뿌리고, 메뉴 선택 코드를 받음”
•
시간적 응집(temporal cohesion):
특정 시간에만 수행되는 기능을 묶어놓은 모듈
예) 초기화 루틴(변수 할당, 초기값 설정, …)
•
논리적 응집(logical cohesion):
유사 성격을 갖거나 특정 형태로 분류되는 처리 요소들을 하나의 모듈로 형성
예) “사칙연산에서 주어진 매개변수에 따라 다른 계산을 함”  연산간 관계가 없음
•
우연적 응집(coincidental cohesion):
아무 관련 없는 처리 요소들로 모듈이 형성된 경우
 모듈 개념이 상실되어 이해 및 유지보수가 힘든 단점이 있음
Page 18
응집력이 약함
Software Engineering
모듈화(Modularization) (5/6)
설계 (Design)
모듈의 결합도(Coupling)
•
모듈간의 상호 의존하는 정도를 의미한다.
•
모듈은 하나의 블랙 박스로 다른 모듈과의 독립성이 높아야 한다.
•
독립적인 모듈이 되기 위해서는 다른 모듈과의 결합도가 약해야 한다(loosely coupled).
모듈의 결합도 구분
•
•
자료 결합(data coupling):
모듈 간의 인터페이스가 자료 요소(파라메터)로만 구성된 경우
예) add(3, 5), sort(a)
스탬프 결합(stamp coupling):
모듈 간의 인터페이스를 통해 배열, 레코드가 전달되는 경우
(단, 배열, 레코드 전체가 사용되면 “자료 결합”으로 볼 수 있음)
예) print_salary(인사 기록 레코드)
Page 19
결합도가 약함
결합도가 강함
Software Engineering
모듈화(Modularization) (6/6)
설계 (Design)
모듈의 결합도 구분 (계속)
•
제어 결합(control coupling):
한 모듈이 다른 모듈에게 제어 요소(function code, switch, flag 등)를 전달하는 경우
예) integer_operation(‘+’, 3, 5)
•
공통 결합(common coupling):
공통된 자료 영역을 사용하는 경우
 자료 영역의 보호가 어렵고, 자료 구조 변경 시 파급 효과가 큼
예) C/C++ 등에서 global 변수를 사용하는 예제, Shared Memory 사용
•
내용 결합(content coupling):
한 모듈이 다른 모듈의 일부분을 직접 참조 또는 수정하는 경우
 공유 부분을 변경할 필요가 생기면 그 파급 효과가 가장 큼
예 1) 에셈블리어에서 한 모듈이 다른 모듈의 데이터를 참조하는 경우
예 2) 한 모듈에서 다른 모듈로 분기(goto)하는 경우
Page 20
결합도가 약함
결합도가 강함
Software Engineering
We are now …
설계 (Design)
설계의 정의 및 원리
구조적 설계
소프트웨어 아키텍처
프로그램 설계
사용자 인터페이스 설계
설계서 작성
Page 21
Software Engineering
구조적 설계 개요 (1/2)
설계 (Design)
시스템을 이루는 모듈의 구조를 파악하는 방법
 궁극적으로 S/W 모듈의 종류, 모듈 간의 관계를 파악하고자 함
모듈 분해의 계층적, 인터페이스 지향적 접근
데이터 흐름 형식에 중점
•
Source-transaction-sink: 변환 분석(transform analysis)
 자료가 어디서 나와서 어떤 처리를 거쳐서 어디로 전달되는가?
•
Transaction pattern: 처리 분석(transaction analysis)
 처리하고자 하는 트랜잭션의 기능이 무엇인가?
Page 22
Software Engineering
구조적 설계 개요 (2/2)
설계 (Design)
시스템 구조도(structure)의 도출
 (관리자를 비롯한 높은) 사람들은 한 눈에 들어오는 구조를 원한다.
 결국, 간단하게 흐름을 파악할 수 있는 구조를 그려주어야 한다.
•
시스템을 모듈 단위로 분할
•
모듈의 계층적(hierarchical) 구성
•
모듈 사이의 입출력 인터페이스
•
모듈의 이름과 기능
S1
S2
S3
S4
S5
S1
S4
S3
Structure #1
S4
S5
S1
S2
S5
Structure #2
S2
S3
Page 23
Structure #3
Software Engineering
시스템 구조도 기호 (1/3)
설계 (Design)
표준 기호
한 모듈이 다른 모듈을 호출하는 관계를 나타냄
자료(변수 및 자료 구조)의 흐름을 나타냄
제어(플래그, 태그)의 흐름을 나타냄
모듈을 나타냄
반복(iteration)
선택(option)
주석달기
comment
Module
Page 24
Software Engineering
시스템 구조도 기호 (2/3)
설계 (Design)
예제
•
Main은 모듈 A, B, C를 호출하고, A는 W, X를 호출하며, C는 Y, Z를 호출한다.
•
C는 Y와 Z를 반복적으로 호출할 수 있고, A는 W 혹은 X 중 하나를 호출한다.
•
자료(데이터) f는 W에서 A로 전달되고, 제어 플래그 a는 A에서 Main으로 전달된다.
•
…
Main
c
a
b
B
A
a
f
W
C
f
X
f
Y
Page 25
Z
Software Engineering
시스템 구조도 기호 (3/3)
설계 (Design)
기타 기호
미리 정의된 모듈(라이브러리)
입출력 모듈
Page 26
Software Engineering
시스템 구조도의 요건 (1/4)
설계 (Design)
전체적으로 균형을 이뤄야 함 ( Skew는 별로 좋지 않음)
과다한 깊이를 가지면  하위 모듈까지 통신 오버헤드가 커짐
Page 27
Software Engineering
시스템 구조도의 요건 (2/4)
설계 (Design)
과다한 너비를 가지면  병목현상이 나타날 수 있음
(Parallel Processing이 어려움)
입력
처리
Page 28
출력
Software Engineering
시스템 구조도의 요건 (3/4)
설계 (Design)
편중의 종류: 입력 편중, 처리(process) 편중, 출력 편중
입력 편중의 예
입력
처리
Page 29
출력
Software Engineering
시스템 구조도의 요건 (4/4)
설계 (Design)
처리 편중의 예
입력
처리
출력 편중의 예
출력
입력
처리
Page 30
출력
Software Engineering
설계 요령 (Design Heuristics)
설계 (Design)
양파 모양의 구조가 일반적
•
복잡한 모듈의 연결은 피함
•
과다한 깊이를 가진 구조도 피함
모듈의 영향권을 그 모듈의 하위에 둔다.
<잘못된 예>
<잘된 예>
변경된 모듈
변경된 모듈
영향받는 모듈
Page 31
Software Engineering
변환 분석(Transform Analysis)
설계 (Design)
자료의 변환 흐름(transformation flow)
입력 흐름
출력 흐름
변환 센터
변환 분석은 자료 흐름도를 입력 흐름, 변환 센터, 출력 흐름으로 분할하
는 과정이다.
•
입력 흐름: 입력을 준비하는 단계(입력, 검증...)
•
출력 흐름: 출력을 위하여 준비되는 단계(포매팅, 출력)
•
변환 센터: 실제 자료가 변환
Page 32
Software Engineering
변환 분석 방법 (1/2)
설계 (Design)
① 자료 흐름도에서 입력 자료 흐름과 출력 자료 흐름을 파악
② 중앙 변환 부분을 식별
③ 변환 중심부를 축으로 최상위 구조(first-cut) 작성
④ 각 모듈의 하위 구조도 같은 방법으로 분석
⑤ 설계 기준을 적용하여 수정, 최적화
예제: 파일 안에 포함된 단어의 개수를 계산
파일 이름
읽음
단어개수
출력
파일 이름
단어개수
편집
화일 이름
검증
입력 흐름
검증된
파일이름
단어개수
계산
단어개수
출력 흐름
변환 센터
Page 33
Software Engineering
변환 분석 방법 (2/2)
예제: 최상위 시스템 구조도
단어 계산
검증된
파일 이름
단어개수
파일 이름
상태
파일이름
입력,검증
단어개수
단어개수
계산
단어 개수
편집,출력
설계 (Design)
예제: 프로그램의 구조
main()
{
...
read_file(file_name, status);
count_word(file_name, &word_count);
display(word_count);
}
read_file(char* file_name, boolean status)
{
...
}
count_word(char* file_name, boolean status)
{
...
}
display(int word_count)
{
...
}
Page 34
Software Engineering
변환 분석의 원칙
설계 (Design)
최상위 모듈을 위한 변환 분석
① 입력 자료 흐름과 출력 자료 흐름을 파악하여 경계를 표시한다.
즉, 입력 흐름 및 출력 흐름을 경계로 변환 센터를 식별하는 것이다.
② 최상위 모듈에 의해 직접 호출되고 제어될 다음 단계의 세 개 모듈, 즉 입력 처리
모듈, 변환 제어 모듈, 출력 처리 모듈을 만든다.
하위 모듈을 위한 변환 분석
① 입력 처리 모듈을 분해한다.  마찬가지로, 다시 입력/변환/출력으로 분해한다.
② 출력 처리 모듈을 분해한다.  마찬가지로, 다시 입력/변환/출력으로 분해한다.
③ 변환 제어 모듈을 분해한다.  마찬가지로, 다시 입력/변환/출력으로 분해한다.
Page 35
Software Engineering
구독자 관리 시스템 (1/3)
설계 (Design)
1) 자료 흐름의 요소를 분해
•
입력 자료 흐름, 출력 자료 흐름, 변환 센터
•
두 개의 입력 자료, 하나의 최종 출력 자료
구독자
레코드
준비
출력 흐름
구독자 레코드
만료일
추출
입력 흐름
만료일
새
만료일
계산
새 만료일
구독자
레코드
변경
변경 레코드
갱신기간
구독
갱신기간
입력
변환 센터
Page 36
레코드를
파일에
출력
Software Engineering
구독자 관리 시스템 (2/3)
설계 (Design)
2) 구조도의 최상위층 작성
•
입력, 변환, 출력 흐름을 바탕으로 최상위 구조도를 그린다.
구독 갱신
시스템
갱신 정보
추출
구독 갱신
갱신 레코드
저장
Page 37
Software Engineering
구독자 관리 시스템 (3/3)
설계 (Design)
3) 구조도의 상세화
•
구조도의 각 모듈을 지속적으로 분할하여 상세 구조도를 완성한다.
•
계속적으로 분할하는 것을 요소 분해(factoring)한다고 한다.
구독 갱신
시스템
갱신 정보
추출
새 구독
기간 입력
구독 갱신
구독 만료일
준비
구독 레코드
추출
갱신 레코드
저장
구독자
레코드 변경
레코드
파일로 출력
구독 만료일
추출
Page 38
Software Engineering
마스터 파일 변경 시스템 구조도 (1/2)
설계 (Design)
자료 처리 흐름도 (DFD)
Page 39
Software Engineering
마스터 파일 변경 시스템 구조도 (2/2)
설계 (Design)
시스템 구조도
Page 40
Software Engineering
변환 분석 예제: 비디오 대여점 (1/3)
설계 (Design)
Level 0 변환 분석 (최상위)
Page 41
Software Engineering
변환 분석 예제: 비디오 대여점 (2/3)
설계 (Design)
Level 1 변환 분석
Page 42
Software Engineering
변환 분석 예제: 비디오 대여점 (3/3)
설계 (Design)
시스템 구조도
Page 43
Software Engineering
처리 분석(Transaction Analysis)
설계 (Design)
처리(transaction)?
자료 흐름도의 한 프로세스에서 여러 개의 자료 흐름이 유출되는 것
 현금 자동 지급기의 경우 “선택”에서 여러 분기가 일어난다.
처리흐름
처리센터
T
처리 경로(action path)
방법
① 자료 흐름도에서 처리 센터를 식별
② 처리 모듈을 중심으로 구조도 작성
③ 구조도를 상세화 - 하위 구조도를 작성
Page 44
Software Engineering
처리 분석 예제: 현금 자동 지급기 (1/2)
설계 (Design)
자료 흐름도(DFD)
Page 45
Software Engineering
처리 분석 예제: 현금 자동 지급기 (2/2)
설계 (Design)
시스템 구조도 (상위 구조)
Page 46
Software Engineering
We are now …
설계 (Design)
설계의 정의 및 원리
구조적 설계
소프트웨어 아키텍처
프로그램 설계
사용자 인터페이스 설계
설계서 작성
Page 47
Software Engineering
소프트웨어 아키텍처
설계 (Design)
건축 설계로 본다면…
•
설계와 시공에 대한 가이드가 될 큰 밑그림
•
일관적인 모양과 조화를 위한 스타일을 정하는 작업
스타일이라는 개념을 소프트웨어 구조에도 적용
 어떻게 동작해야 할 지의 동작 메커니즘의 큰 그림을 결정
 중앙 DB를 두고? C/S 모델로?
일단 시스템이 개발된 뒤에는 잘못된 구조를 바로잡기가 쉽지 않음
소프트웨어 구조는 시스템 분할, 전체 제어 흐름, 오류 처리 방침, 서브시
스템 간의 통신 프로토콜을 포함
Page 48
Software Engineering
저장소 구조
설계 (Design)
서브시스템들이 단일 중앙 저장소의 자료를 접근하고 변경
서브시스템들은 독립적이고 중앙 자료 저장소를 이용하여 상호 대화
새로운 서브시스템도 저장소를 중심으로 위치함
사례 (주로 DB를 사용하는 경우)
•
급여 시스템
•
은행 시스템과 같은 데이터베이스 관리 시스템
Page 49
Software Engineering
MVC 구조
설계 (Design)
MVC(Model, View, Control)
•
모델 서브시스템: 도메인의 지식을 저장 및 보관
•
뷰 서브시스템: 사용자에게 보여줌
•
제어 서브시스템: 사용자와의 상호 작용을 관리
분리하는 이유
•
사용자 인터페이스, 즉 뷰와 제어가 도메인 지식을 나타내는 모델보다는 더 자주 변경될
수 있기 때문임
Excel에서
• 사용자는 표, 그래프, 차트 등으로 볼
수 있으나(뷰),
• 실제 저장은 한 군데 있으며(모델),
• 다른 뷰에서 각기 수정하여도(제어)
한 군데 반영됨
Page 50
Software Engineering
클라이언트 서버 구조
설계 (Design)
서버는 클라이언트라 불리는 서브시스템에게 서비스를 제공
클라이언트: 사용자로부터 입력을 받아 범위를 체크하고 데이터베이스
트랜잭션을 구동하여 필요한 모든 데이터를 수집
서버: 트랜잭션을 수행하고 데이터의 일관성을 보장한다
우리가 매일 사용하고 있는 웹 환경이 대표적인 C/S 구조에 해당함
Page 51
Software Engineering
계층 구조 (Hierarchical Structure)
설계 (Design)
각 서브 시스템이 하나의 계층이 되어 하위 층이 제공하는 서비스를 상위
층의 서브시스템이 사용
추상화의 성질을 잘 이용한 구조
대표적인 예: 네트워크의 OSI 7 Layer 구조
장점: 각 층을 필요에 따라 쉽게 변경할 수 있음
단점: 성능 저하를 가져올 수 있음
Page 52
Software Engineering
파이프 필터 구조 (Pipe Filter Structure)
설계 (Design)
서브시스템이 입력 데이터를 받아 처리하고 결과를 다른 시스템에 보내
는 작업이 반복
서브시스템을 필터라고 하고 서브시스템 사이의 관계를 파이프라 함
대표적인 예는 UNIX/Linux 쉘
Page 53
Software Engineering
파이프 사용 예제 (in Linux)
Page 54
설계 (Design)
Software Engineering
We are now …
설계 (Design)
설계의 정의 및 원리
구조적 설계
소프트웨어 아키텍처
프로그램 설계
사용자 인터페이스 설계
설계서 작성
Page 55
Software Engineering
알고리즘(프로그램) 설계 (1/2)
설계 (Design)
프로그램을 작성하기 이전에 알고리즘 작성은 필수 요건이다.
알고리즘은 모듈의 명세서에 해당한다.
•
모듈의 세부처리 기능을 기술한 내역
•
시스템 구조도의 박스에 표현되지 않은 자세한 알고리즘을 기술
•
모듈의 내부 자료에 대한 설명을 포함
•
프로그램 구조도와 함께 시스템의 동작 상태를 예측할 수 있는 근거 제공
숫자
결과
소수확인
Module 소수 확인(숫자, 결과)
내부자료: ....
처리기능: 숫자보다 작은 이미 구한
모든 소수로 나누어 나머지가
0이 아니면 결과는 소수이다.
Page 56
Software Engineering
알고리즘(프로그램) 설계 (2/2)
설계 (Design)
상세 설계의 표현
•
설계의 표현과 코딩이 용이해야 할 것
•
수행이 가능해야 할 것
•
유지보수가 용이해야 할 것
상세 설계의 표현
•
흐름도(flow chart)
•
N-S 도표(Nassi-Schneiderman Chart) // 나씨-슈나이더 도표
•
의사 코드(pseudo code)
•
의사 결정표(decision table)
•
의사 결정도(decision diagram)
•
PDL(Program Design Language)
•
상태천이도(state transition diagram)
•
행위도(action diagram)
Page 57
Software Engineering
알고리즘의 선택 기준 (1/4)
설계 (Design)
정확성
•
모듈이 정확하게 수행되지 않는 조건을 점검
•
예: 음수, 0, 경계 값 입력  예외 조건에 대해서 잘 처리해야 함
•
재사용  증명된 알고리즘을 활용하고, 이미 있는 모듈은 그냥 가져다 쓴다.
효율성
•
기억 공간 최소화  최근 들어서는 일반적으로 큰 문제가 되지는 않는다.
•
처리 소요 시간 최소화
•
예: 1에서 N까지의 합
n
i
i 1
<방법 1>
SeriesSum = 0
for Counter = 1 to N do
SeriesSum = SeriesSum + Counter
write "The sum is", SeriesSum
<방법 2>
SeriesSum = (1.0 + N)*(N/2.0)
write "The sum is", SeriesSum
O (1)
O( N )
Page 58
Software Engineering
알고리즘의 선택 기준 (2/4)
설계 (Design)
효율성 (계속)
입력 개수
분석 방법
이름
1
1
10
100
1,000
10,000
Constant
1
1
1
1
1
log N
Logarithmic
1
4
7
10
14
N
Linear
1
10
100
1,000
10,000
N log N
N log N
1
40
700
10,000
140,000
N2
Quadratic
1
100
10,000
1,000,000
100,000,000
N3
Cubic
1
1,000
1,000,000
1,000,000,000
1012
2n
Exponential
2
1,024
1.27 x 1030
1.07 x 10301
1.99 x 103010
복잡도가 높은 경우(N3 이상, 특히 exponential인 경우)
 휴리스틱을 많이 사용함
 대표적 휴리스틱 방법: Greedy Algorithm
Page 59
Software Engineering
알고리즘의 선택 기준 (3/4)
설계 (Design)
외판원 문제(TSP: Traveling Salesman Problem)
문제 정의
• N개의 도시(C1, C2, … CN)와 두 도시 i와 j 사이의 거리 dij가 주어졌을 때, 모든 도시를 한
번씩 방문해야 하는 외판원이 다리 품을 가장 적게 파는 경로(shortest tour)는?
경로의 가짓수 계산
• 첫 번째 도시를 선택할 수 있는 가짓수: N가지
56
• 두 번째 도시를 선택할 수 있는 가짓수: (N-1)가지
73
89
94
115
• …
 경로의 가짓수 = N(N-1)(N-2)…(2)(1) = N!
32
62
108
49
51
TSP를 풀기 위해 얼마나 걸리는가?
• 하나의 경로 계산을 위해 1 ns가 걸린다고 가정 (1 GHz  1 flop/1 ns)
• N=10: 3,628,800 ns = 0.0036288 sec.
• N=50: 3.02 x 1064 ns = 3.02 x 1055 seconds = 3.50 x 1050 days = 9.59 x 1047 years
 해결할 수 있는 방법은? (Refer to http://www.tsp.gatech.edu//index.html)
Page 60
Software Engineering
알고리즘의 선택 기준 (4/4)
설계 (Design)
적합성
•
알고리즘이 주어진 문제를 정확히 기술하였는가?
•
입력은 sequential file인데, 알고리즘은 random access file을 가정하면 되겠나요?
Page 61
Software Engineering
알고리즘 표현 – 흐름도(or 순서도)
설계 (Design)
표현하기 쉽다.
BUT, 제어 흐름이 구조적이 되지 못해서
 코드가 엉키는, 이른바 스파게티 코드가 되기 쉽다.
현재는 거의 사용하지 않는다.
Page 62
Software Engineering
알고리즘 표현 – 의사 코드 (1/4)
설계 (Design)
일반적으로 가장 많이 사용하는 방법이다.
“자바로 쓴 알고리즘”, “C로 쓴 알고리즘”, “Pascal로 쓴 알고리즘” 등이
이 범주에 해당한다고 볼 수 있다.
모듈의 입출력 자료, 내부 자료, 수행 절차 등을 알고리즘의 형태로 기술
실제 프로그램과 유사하나 특정 프로그래밍 언어에는 독립적임
전문적 용어의 사용은 가능하지만 프로그래머의 고유한 스타일이나 특성
이 무시될 수 있음
의사 코드를 쓰는 방식이 다를 수 있으므로 한 프로젝트 안에서 표준을 만
들 필요가 있음
Page 63
Software Engineering
알고리즘 표현 – 의사 코드 (2/4)
설계 (Design)
요구 분석에서의 구조적 언어 vs. 의사 코드
특성
구조적 언어
의사 코드
동일한 논리 구조 사용
논리 구조
 순차 (sequence)
 선택 (selection)
 반복 (iteration)
사용 단계
요구분석 단계
설계 단계
명세 대상
자료 흐름도 상의 최소 단위로 사용
설계 구조도 상의 모든 모듈
명세 방법
사용자 중심
상세 정도
처리의 기본적인 기능 수행 절차
프로그래머 중심
모듈의 기본적인 기능 수행 절차 및 세부적
방법
Page 64
Software Engineering
알고리즘 표현 – 의사 코드 (3/4)
설계 (Design)
의사 코드 사례
고용자레코드
주급총액
주급계산
고용자 레코드 = 급여형태 + 성명 + 주간근무시간
급여형태 = [1|2|3]
Module 주급계산(고용자 레코드; 주급총액)
Assume
1<급여형태<3
0<주간 근무 시간<100
End Assume
Define
Rate: Real /* 시간 당 급료 */
End Define
If (급여형태=1) Then Rate=4.2
Elseif (급여 형태=2) Then Rate=6.0
Else Rate=9.0
Endif
Select Using (주간근무시간) From
Case (1-40): 주급총액=주간근무시간*Rate
Case (41-50): 주급총액=(주간근무시간*Rate)*0.5
Case (51-99): 주급총액=(주간근무시간*Rate)*1.0
Endselect
End Module
Page 65
Software Engineering
알고리즘 표현 – 의사 코드 (4/4)
설계 (Design)
A Real Example (extracted from Numerical Analysis course)
procedure gauss-jordan(aij, bi: real numbers, n: integer)
{ aij are coefficients. (1  i,j  n)}
{ bi are results. (1  i  n)}
{ n is # of variables. (we assume that # of variables = # of equations.}
k := 1;
while (k  n) begin
i := 1;
while (i  n) begin
j := k+1;
c := aik/akk;
while (j  n) begin
if i = k then aij := aij, bi := bi; {actually, this line is not required.}
else if (i  k) and (j = k) then aij := 0;
else if (i  k) and (j > k) then aij := aij – cakj;
j := j + 1;
end
if i  k then bi := bi – cbk;
i := i + 1;
end
k := k + 1;
end
Page 66
Software Engineering
알고리즘 표현 – NS 도표 (1/4)
설계 (Design)
논리 기술의 기본 형태인 순차, 선택, 반복을 박스로 표현
a. 순차
b. 선택(if-then-else)
action A
action B
Decision
action A
e. 반복(while)
F
action B
action A
c. 선택(if-then)
T
Decision
T
d. 다중선택(case)
Selector
F
Value 1
Value 2
action A
action B action C action D
Value 3 Value 4
Value 5
action E
f. 반복(repeat-until)
Condition
action A
action A
Condition
Page 67
Software Engineering
알고리즘 표현 – NS 도표 (2/4)
설계 (Design)
NS 도표의 표현 규칙
• 도표는 항상 사각형
• 도표의 제어 흐름은 위에서 아래로
• 수평으로 그어진 줄은 항상 평행
• 빈 박스 – null statement
• 모든 사각형은 다시 하나의 NS 도표
Page 68
Software Engineering
알고리즘 표현 – NS 도표 (3/4)
설계 (Design)
NS 도표의 예 (잡지 구독 시스템의 구독 레코드 처리)
While there are records in the correspondence file
Read next correspondence
Check general format
T
F
Errors
Write error message
Transaction type
Cancellation
New subscription
Renewal
Call Handle
New Subscription
Pull sibactiber’s
record
Update expire
date
Pull sibactiber’s
record
Calculate amount
of refund
Call update
Account
Call update
Account
Page 69
Other
Print error
message
Software Engineering
알고리즘 표현 – NS 도표 (4/4)
설계 (Design)
NS 도표의 장점
• 구조적 프로그램
• 배우기 쉽고, 읽기 쉬우며 원시 코드로 전환이 쉬움
• 프로그램의 구조를 쉽게 파악할 수 있다
• 프로그램의 복잡도, 제어구조를 한 눈에 볼 수 있다.
NS 도표의 단점
• 도표를 그려야 하는 불편함
• 수정이 용이하지 않음
Page 70
Software Engineering
We are now …
설계 (Design)
설계의 정의 및 원리
구조적 설계
소프트웨어 아키텍처
프로그램 설계
사용자 인터페이스 설계
설계서 작성
Page 71
Software Engineering
사용자 인터페이스 (User Interface)
설계 (Design)
사용자 인터페이스의 중요성
• 초기의 컴퓨터: 알고리즘이 중요 (계산 자체가 중요)
• 최근의 컴퓨터: 사용자의 입장이 중요 (이쁘게 보여야~)
사용자 인터페이스의 평가 기준
• 배우기 쉬워야
• 반응 속도가 빨라야
• 사용 중 오류가 발생하지 않아야
• 다수의 사용자가 만족할 수 있어야
• 사용법이 유지되어야 (한번 써보면, 다음에 더 쉽고, 그 다음에 더 쉽고…)
Page 72
Software Engineering
사용자 인터페이스 예제 (1/5)
Page 73
설계 (Design)
Software Engineering
사용자 인터페이스 예제 (2/5)
설계 (Design)
MMC Category 선택 Combo Box
MMC Command List
MMC Command Result Output Window
MMC Command Parameter Table
Command
실행
Output
Window
결과 삭제
Command
도움말
MMC Command Input Text Field
Page 74
Window
닫기
Software Engineering
사용자 인터페이스 예제 (3/5)
Page 75
설계 (Design)
Software Engineering
사용자 인터페이스 예제 (4/5)
Page 76
설계 (Design)
Software Engineering
사용자 인터페이스 예제 (5/5)
Page 77
설계 (Design)
Software Engineering
사용자 분석
설계 (Design)
시스템의 최종 사용자에 대한 지식
• 나이, 인원, 성별?
• 컴퓨터에 대한 기본 지식, 동기
• 사용자의 부류(초보자, 능숙하지 못한 사용자, 전문가)
• 다양한 사용자 부류  일반적인 소프트웨어 (게임, 워드 프로세서, …)
Page 78
Software Engineering
대화설계 원리 (1/2)
설계 (Design)
사용자와 시스템 간의 대화 설계에서 따라야 하는 원칙…
일관성이 유지되어야 한다
•
용어, 문법, 화면설계
•
메뉴, 시스템 메시지, 설명서에 같은 의미와 용어
•
오류 메시지
익숙한 사용자에게는 지름길을 (Hot Key 제공)
사용자에게 유익한 정보는 피드백(feedback)시킨다
•
잘못했으면 겸손한 정정을, 잘했으면 칭찬을…
대화의 종결을 표시하도록 설계한다
 진행 중인 단계인지, 종료 단계인지…
Page 79
Software Engineering
대화설계 원리 (2/2)
설계 (Design)
단순한 오류를 처리하는 기능
 Undo/Redo 기능 제공
시스템에 지시한 것을 바꾸기 쉽도록
 브라우저에서 다른 사이트로 갔다가 “뒤로” …
사용자 중심의 상호작용이 되도록 설계
 사용자는 자신이 중심이 되어 도구를 사용하고 있다는 느낌을 가져야
화면의 내용을 너무 복잡하지 않게
 무엇이든 복잡하면 일반인의 외면을 받는다(매니아 빼고…)
 Niche market을 형성한 실버폰이 좋은 예임
Page 80
Software Engineering
메뉴 선택 (1/2)
설계 (Design)
초급이나 중급 사용자에게 적합
메뉴의 구조, 동작, 배치를 고려
•
계층구조 (hierarchical structure)
•
선형구조 (linear structure)
•
네트워크 구조 (network structure)
메뉴 항목의 분류가 중요
•
논리적으로 같은 항목은 같은 범주에
•
모든 경우를 포함하여 분류
•
중복된 항목은 피한다
•
익숙하지 않은 항목은 피한다
메뉴의 종류
•
단일화면 메뉴
•
풀 다운 메뉴
•
고정 메뉴
Page 81
Software Engineering
메뉴 선택 (2/2)
설계 (Design)
풀 다운 메뉴의 예제
Page 82
Software Engineering
양식 채움 (Form Fill) 인터페이스 (1/2)
설계 (Design)
자료 입력에 많이 쓰임
자료 항목, 위치, 길이
어느 정도의 교육이 필요(중급, 고급 사용자에게 적합)
화면 설계
•
관련 항목을 모음
•
화면 이름 작성
•
화면의 배치(항목의 순서)
•
입력 자료 항목의 길이
•
정렬
•
선택적 항목
•
항목 간의 이동
•
오류의 정정
Page 83
Software Engineering
양식 채움 (Form Fill) 인터페이스 (2/2)
설계 (Design)
화면 예제 (네이버 가입)
Page 84
Software Engineering
명령어 방식
설계 (Design)
정형적 언어(formal language)
운영체제, 텍스트 편집기, 모험 게임 등에 자주 사용
고급 사용자에 적합
화면 설계
•
어휘, 문법규칙, 명령어의 의미를 익혀야 함
융통성 있게 창의적으로 시스템에 지시
<예> vi의 명령어
^F 앞으로 한 화면 전진
^B 뒤로 한 화면 후퇴
^D 반 화면 내림
^U 반 화면 올림
G 정해 준 줄로 커서를 옮김
/pattern pattern과 같은 다음 줄로 커서를 옮김
?pattern pattern과 같은 바로 전 줄로 커서를 옮김
Page 85
Software Engineering
명령어 설계 시 주의사항
설계 (Design)
1. 명령어의 개수를 가능하면 적게 한다.
2. 의미 있고 구별되는 이름을 사용한다.
3. 약어는 일관성 있게 사용한다.
4. 약어가 사용되더라도 명령어가 제대로 작동해야 한다.
5. 문법 구조는 일관성이 있어야 한다.
6. 초보자를 위하여 문법규칙을 프롬프트로 안내한다.
7. 명령어 메뉴는 중급 사용자에게 도움이 된다.
Page 86
Software Engineering
직접 조작 (Direct Manipulation)
설계 (Design)
간략화 된 작업환경을 보여주고 그 속의 객체를 직접 조작
아이콘으로 객체가 표현
편집기, 비디오 게임, 터치 스크린, 윈도우 시스템
마우스나 조이스틱을 사용
WYSIWYG  What you see is what you get
설계 시 고려사항
•
아이콘은 이해하기 쉬워야
•
잘못된 유추는 피해야
•
사용자 계층의 관습에 따라 설계
•
아이콘은 알맞은 목적에 사용되어야
•
조화 및 일관성, 배치가 중요
 우리가 현재 쓰고 있는 Windows 환경이 이에 해당한다.
Page 87
Software Engineering
화면 설계 시 주의 사항
설계 (Design)
1. 사용자의 특성을 염두에 둔다
2. 논리적으로 관련 있는 항목은 반전, 글자꼴, 색상으로 구별
하기 쉽게 한다.
3. 정보를 조직적으로 표현하기 위하여 다양한 정렬 방식 사용
한다.
4. 다중화면의 경우 화면 사이의 일관성이 중요하다.
Page 88
Software Engineering
We are now …
설계 (Design)
설계의 정의 및 원리
구조적 설계
소프트웨어 아키텍처
프로그램 설계
사용자 인터페이스 설계
설계서 작성
Page 89
Software Engineering
시스템 설계서 작성
설계 (Design)
1. 개요
1.1
1.2
1.3
1.4
1.5
시스템의 목표
하드웨어, 소프트웨어
소프트웨어의 주요 기능
설계상 제약사항
참조된 개발문서
2. 시스템 구조
4. 화일 구조 또는 데이타베이스 설계
2.1 시스템 구조 개요
2.2 시스템 구조도
2.3 자료사전
4.1 외부 화일(데이타베이스)의
논리적 구조
4.2 공유 자료
4.3 파일 접근 방법(데이타베이스
관리체제)
3. 모듈 설계(각 모듈에 대한)
3.1
3.2
3.3
3.4
3.5
3.6
3.7
모듈이름
모듈형
인터페이스
오류메시지
사용하는 파일
호출하는 모듈
기능설명
5. 요구분석 참조표
6. 제약사항
7. 참고사항
참고문헌
부록
Page 90
Software Engineering
Homework #2
Homework
Page 91
Software Engineering