Transcript Software Engineering

소프트웨어 설계

소프트웨어 설계
Functional
model
Behavioral
model
Other
requirements
Informational
model
Design
Architectural
design
Procedural
design
Data
design
Interface design
Code
Program
modules
Test
Integrated
and validated
software
소프트웨어 설계

설계의 중요성
Maintenance
Maintenance
Test
Test
Implementation
Implementation
Design
소프트웨어 설계

설계 과정


요구사항들의 명세로부터 소프트웨어의 표현으로
변환시키는 과정
명세 (Specification)
 소프트웨어 시스템의 문제 영역 중심(problem domain-
oriented )의 기술

설계 (Design)
 software domain-oriented 기술
 그 문제에 대한 제안된 해결책 또는 구현

프로젝트 관리 관점에서의 설계

예비 설계(preliminary design)
 요구사항들을 자료와 소프트웨어 구조로 변환

상세 설계(detail design)
 세부적인 자료구조와 알고리즘 도출

기술적 측면에서의 설계




자료 설계
구조 설계(architectural design)
절차 설계(procedural design)
인터페이스 설계
 인간-기계간의 상호작용 설계
소프트웨어 설계

소프트웨어 설계

외적 설계 (External Design)
 소프트웨어 제품의 외적 특성을 고안하고, 계획하고,
기술한다.
 요구 사항을 세분화하고 시스템에 대한 고수준의
구조적 관점 구축
 user displays, report formats, external data sources
and sink,
 functional characteristics, high-level process
structure,
 성능 요구 사항

내적 설계 (Internal Design)
 내부 구조를 기술하고 상세하게 처리
 구조 설계 (Architectural Design)
 상세 설계 (Detailed Design)
소프트웨어 설계

구조 설계 (Architectural Design)





시스템의 개념적인 관점을 세분화 (Hierarchy of
system views)
building blocks과 그들 간의 인터페이스를 파악
(Decomposition, Abstraction)
파악된 시스템 구성 성분(components)의 구조화
내부 자료 흐름 및 자료 저장소 정의
기능(functions), 자료 흐름 및 자료 저장소 간의 관계
정립
 원칙 :
1. maximize INDEPENDENCE among modules
2. minimize INTERFACE to increase Reliability,
Modifiability, Usability
3. maximize COHESION and minimize COUPLING
소프트웨어 설계
소프트웨어 구조



절차 구성요소(모듈)들의 계층적 구조
자료 구조
p1
p4
S1
p2
S2
S3
p3
S4
p5
S5
구조의 전개
S1
S4
S5
S4
S3
S1
S2
S3
S4
S5
S1
S2
S3
문제에 대한 다양한 구조
S2
S5
소프트웨어 설계

자료 구조


자료의 개별적인 요소들 간에 논리적인 관계를 표현
절차 설계에 많은 영향을 미침.
scalar item
sequential vector
linked list
hierarchical tree
소프트웨어 설계

상세 설계 (Detail Design)




기능을 구현하기 위한 알고리즘 기술
자료 저장소를 구현하기 위한 자료 구조 확립
기능과 자료 구조 간의 사실상의 상호 연결 관계
구축
시스템 꾸리기 : physical realization of a modular
system on an actual computer.
 다음과 같은 문제를 수용하기 위한 설계의 수정 :
timing constraints, hardware limitations, language
characteristics, efficiency
소프트웨어 설계

설계 원리

추상화(Abstraction)
 자세한 사항(How, implementation)보다는 근본적인
본질(What, specification)에 집중하는 것
 문제 환경의 언어 ==> 절차 중심의 기술 ==> 구현
중심의 기술

기능 추상화(Functional abstraction) :
입력 자료를 출력 자료로 변환하는 과정을 추상화
1. Abstraction by Parameterization : subroutine
2. Abstraction by Specification : built-in functions

자료 추상화(Data abstraction) :
자료의 표현 및 자료 구조의 구현에 독립적.
자료를 사용하는 입장에서 자료의 자세한 부분에 대한
지식이 없더라도 사용 가능하다.
1. Built-in Types : integer, float, char, ...
Freedom of storage representations. Detect and prevent
operations among objects of different types.
2. User-defined Types : array, record, ...
Allow mapping of concepts from the problem domain into
the implementation language. Allow specification of often
needed types in terms of existing types
소프트웨어 설계
3. Data Encapsulation
Packaging of a data structure and its access routines in a
single module. A single instance of an abstract data object
4. Abstract Data Types
Declaration of a data type (template) from which numerous
instances of encapsulated data objects can be created

정보 은닉(Information Hiding) [ D.L. Parnas ]
 각 모듈의 자세한 처리 내용 또는 설계상의 결정
사항(design decision)은 시스템의 다른 부분으로 부터
감추어져야 한다는 것.
 모듈 내에 포함된 정보는 이런 정보를 필요로 하지
않는 다른 모듈들이 접근할 수 없도록 설계되어야 함.
 모듈화의 기준
 장점 :
 모듈 구현의 독립성
 모듈 구현의 병렬성
 모듈의 이해도 증진
 변경의 국부화, 변경으로 인한 영향의 최소화
소프트웨어 설계

설계 원리

단계적 세분화(Stepwise refinement)
 문제를 상위 개념부터 더 구체적인 단계로 하향식으로
분할 및 세분화하는 기법
 상호 종속적이지 않은 설계 요소(design aspects)를 격리
 점진적으로 세분화한다.
 세분화 요소의 표현(representation details)과 관련된
의사 결정은 가능한한 연기한다.
 세분화 과정에서 각각의 연속적인 단계들은 이전
단계로부터 자연스럽게 확장되도록 한다.
 사례 : <Airline Reservations Program>
소프트웨어 설계

설계 원리

모듈화 개념(Modularity)
 module






수행 가능한 문장들의 집합
이름이 있는 서브루틴
잘 정의된 단일의 목적을 가진다.
다른 모듈로부터 호출될 수 있다.
다른 모듈을 호출할 수 있다.
분리되어 컴파일될 수 있고 분리되어
라이브러리에 저장될 수 있다.
 Good modularity criteria





모듈 분해성(modular decomposability) : top-down
design
조합성(composability) : reusable
이해도(understandability) : maintenance가 쉽다.
연속성(continuity) : 변경 영향의 최소화,
소프트웨어 구조에의 영향을 최소화
protection : error 영향 최소화, side effect 줄인다.
소프트웨어 설계

Modular 설계

모듈 형태
 순차 모듈(sequential module)
응용 소프트웨어에 의해 분명한 인터럽트 없이
참조되고 실행되는 모듈
 점진적 모듈(incremental module)
응용 소프트웨어가 완성 전에 인터럽트할 수 있고,
후에는 인터럽트 시점에서 다시 시작할 수 있는 모듈
 coroutine
 interrupt driven system
 병렬 모듈(parallel module)
공동으로 작용하는 다중 프로세서 환경에서 다른
모듈과 동시에 실행될 수 있는 모듈
 Modula의 Module, Ada의 Package

모듈의 기능적 독립성에 대한 품질 평가 기준
 응집도(cohesion)
모듈에 있는 기능적인 응집력의 정도
 결합도(coupling)
모듈 간에 관련되어 있는 상호 의존성의 정도
Cohesion

Levels of Cohesion

coincidental
 No meaningful relationships among elements (multiple,
unrelated functions)
 Closely related to their subordinate and superordinate
modules (large interface)
e.g. Compute the cosign of an angle and the inverse of a
matrix.

logical
 Performs a set of related functions with a single interface.
 Parameters have different interpretations depending on
which function is invoked. Some parameters are ignored
in some cases.
e.g. Add or delete an entry and list all the entries on the
membership directory.

classical
 Performs multiple sequential functions. Weak but nonzero
relationship.
 No parameter or logic to determine which elements to
execute
e.g. INIT. declare i, j, x, y; declare table1(20), table2(20);
read trans-file-1; read trans-file-2;
Cohesion

procedural
 Multiple functions where the sequential relationship
among the functions is implied by the problem statement.
e.g. Extract the outline of an object and determine its shape.

communicational
 Procedural and all the elements communicate with one
another through a common data structure.
e.g. Compute the largest angle of a triangle and the sum of
the length of each side.

functional
 The outside (function) is easier to understand than its
inside (logic).
 Easier to use than to write a functional module.
e.g. Find customer loan balance.

informational => Information Hiding
 Multiple functions dealing with a single data structure.
 Physical packaging together of modules having functional
strength
e.g. STACK, QUEUE
Cohesion

Module Strength의 판별
IF 단일 기능 THEN functional
ELSE
Data에 의한 결합 informational,
communicational
Control에 의한 결합 procedural, classical
ELSE
logical, coincidental

Exercises
1. Print and punch the output file
2. Update, add, or delete a record on the master file.
3. Format screen for part display and read part record from
database
4. Read the next transaction, edit it, and display it to the tape
operator.
5. Read or write an inventory record (two entry points).
Coupling

결합도에 영향을 주는 요소

모듈 간의 연결 형태
 transfer/return, multiple entry

인터페이스의 복잡도
 공유되는 정보의 양

정보 흐름의 형태
 자료 흐름, 제어 흐름

Levels of Coupling

Content coupling
 One module makes a direct reference to the contents of
the other module
 Does not occur in high-level languages. (assembly lang.)

Common coupling
 A modification impacts every module that is common
coupled to this module.
 difficult to use in other context.
 difficult to control data access.
 difficult to know what data are used by a particular
module.
e.g. FORTRAN : common blocks
Coupling

Control coupling
 One module passes elements of control as parameters to
the other module.
e.g. function code, flags, switches, error code, return code
 One module knows something about the logic of the other
module.
* inversion of control (hierarchy breakdown)

Stamp coupling
 Modules reference the same nonglobal data structure.
 The name or location of the data structure is passed
through the program as a parameter.
 Pass needed field as parameters

Data coupling
 Is a necessary minimum form of the module
interconnection..
소프트웨어 설계

자료 설계

자료 설계 과정 [Wasserman]
 요구사항 정의와 명세화 단계시에 식별된 자료
객체들의 논리적인 표현을 선택
 논리적 자료 구조에 직접 작동해야 하는 프로그램
모듈들을 식별

자료 설계를 위한 일련의 원칙
 기능과 행위에 적용된 체계적인 분석 원칙들을
자료에 적용
 자료 흐름의 내용과 표현
 자료 객체들의 식별
 모든 자료 구조와 각 자료 구조에 수행될 모든
연산들의 식별
 자료 사전을 자료와 프로그램을 정의하는데 이용
자료 사전 : 자료 구조의 관계, 자료 요소들 간의
제약 기술
 하위 수준의 자료 설계 결정들은 가능한한 연기
 단계적 세분화를 자료 설계에 적용

 정보 은닉 개념 적용
 유용한 자료 구조의 라이브러리와 그들에 적용되는
연산들의 개발
소프트웨어 설계

자료 설계

자료 구조 설계
 자료를 단순한 화일로 처리할 경우
 시스템의 외부 화일에 대한 설계
 구조도에 나타난 자료들에 대한 자료 사전 작성
 절차
1. DFD에서 자료저장소 => 외부 화일
2. 분석 단계에서의 자료 사전을 기초 => 레코드의
항목과 길이 결정
 사례 : 인사관리 시스템의 인사 기본 화일

데이타베이스 설계
 자료를 데이타베이스로 구축할 경우
 자료의 논리적 설계
 데이타 모델링에 의한 자료 분석 (E-R Diagram)
구조적 설계

구조적/복합 설계
 TR 분할 방법 (Transactional Decomposition)
 STS 분할 방법 (Source-Transform-Sink Decomposition)
 FD 분할 방법 (Functional Decomposition)

TR 분할 방법
 입력 데이타의 종류에 의해 처리가 선택되어 지는
경우
 각각의 처리 단위로 모듈 분할
 예 : 상품 관리 시스템의 경우
취급
업무
데이타
{
주문접수 데이타
발주 데이타
주문접수 즉시발주 데이타
구입 데이타
매상 데이타
구입 즉시매상 데이타
취소 데이타
취급업무
데이타의처리
주문접수
데이타의처리
주문접수
즉시발주
데이타의처리
발주
데이타의처리
매상
데이타의처리
구입
데이타의처리
취소
데이타의처리
구입즉시매상
데이타의처리
구조적 설계

STS 분할 방법
 데이타 요소를 변환하여 가는 기능 => S(source),
T(transform), S(sink)의 형태로 모듈 구조를 분할
 source : 입력 모듈, T : 처리 모듈, sink : 출력 모듈
 절차
1. 문제의 구조를 몇 개의 기능 요소의 집합체로 파악
2. 개개의 기능 요소를 표현
3. 기능 요소 간의 관련성을 표시 : 데이타 흐름 표시
4. 주요 데이타의 흐름을 이해하여
최대추상점(입,출력)의 위치 결정
입
력
데
이
타
데이타A
기능1
데이타B
기능2
데이타C
최대추상입력점
기능3
데이타D
최대추상출력점
출
력
데
이
타
5. 최대추상입력점과 최대추상출력점을 기준하여
문제의 구조를 3부분으로 분할(S, T, S)후 계층적으로
구조화
입
력
데
이
타
중요한 데이타의 흐름
최대추상입력점
Source
최대추상출력점
Transform
Sink
주모듈
입력처리
모듈
변환처리
모듈
출력처리
모듈
출
력
데
이
타
구조적 설계

FD 분할
 STS 분할, TR 분할 과정 중에 정의한 몇 개의 모듈에
공통적인 종속 기능을 파악
 공통적인 종속 기능 => 모듈화
 공통 기능 분할의 예
인사화일을 검색
타당한 입력
트랜잭션 얻는다
해당 인사
레코드를 얻는다
레코드를 화면에
표시한다
에러 메시지 표시
급여화일 편집
급여화일에
레코드를 추가
급여화일로부터
레코드를 삭제
급여화일 편집
입구
입구
입구
화일에
레코드를 추가
화일로부터
레코드를 삭제
화일의
레코드를 갱신
급여화일의
레코드를 갱신
구조적 설계

구조도(structure charts)
 시스템의 모듈로의 분할을 보여준다.
 모듈 간의 계층 구조와 조직을 보여준다.
 모듈 간의 입력 및 출력 인터페이스를 보여준다.
 모듈의 이름(기능)을 보여준다.
 구조도의 표기법
모듈 이름
모듈
모듈 호출
자료흐름
모듈 이름
정의된 모듈
(라이브러리)
입출력 모듈
모듈 A
모듈 A
모듈 B
반복
모듈 B
모듈 C
선택
제어흐름
구조적 설계
<예약 구독 시스템>
예약구독을
처리한다
타당한 예약
항목을 얻는다
예약 항목을
읽어 들인다
타당한 항목을
처리한다
예약 항목을
검증한다
신규 구독을
처리한다
구독 계속을
처리한다
구독 취소를
처리한다
신규레코드를
추가한다
청구서를
발행한다
대조레코드를
작성한다
구조적 설계

설계 사례
<Patient Monitoring System>
read
factors
patient
find
unsafe
factors
save
factors
factors
safe ranges
notify
nurse
nurse
monitor
patient
obtain
factors
find unsafe
factors
notify
nurse
구조적 설계
<Patient Monitoring System>
find unsafe
factors
obtain
factors
read next
patient's factors
find
next patient
to monitor
store factors
in database
convert
patient no. to
bed address
obtain
patient's
safe ranges
notify
nurse
write line
to station
Determine
if factor
is unsafe
구조적 설계
<Patient Monitoring System>
monitor
patient
obtain
factors
read next
patient's factors
find
next patient
to monitor
find unsafe
factors
store factors
in database
convert
patient no. to
bed address
obtain
patient's
safe ranges
Determine
if factor
is unsafe
notify
nurse
write line
to station
구조적 설계


복합/구조적 설계시 주의점

모듈 분할의 다양화 <= 개개인의 경험이나 기량
차이
=> 해결 : 설계 결과 체크, 표준화를 위한 설계
패턴 확립

모듈 분할시 한 모듈의 스텝수와 전체 모듈의
갯수와의 관계 최적화 필요 <= 모듈 갯수의 증가는
인터페이스가 복잡해질 가능성 유발

한 모듈의 크기는 가능하다면 50 스텝 정도로 유지

모듈 단위의 정보 은닉 시도

설계 과정은 도큐먼트화 하라. => HIPO diagram
이용
복합 설계 향상위해 함께 적용 가능한 기법
 HIPO diagram을 이용한 도큐먼트
 Top-down 프로그래밍
 Chief programmer team 방식에 의한 프로젝트 관리
 Walk through / inspection을 통한 검사
구조적 설계

HIPO diagram


도식목차
IPO 다이어그램
구조적 설계

HIPO diagram의 사용 예

도식목차
구조적 설계

HIPO diagram의 사용 예 (계속)

IPO 다이어그램
구조적 설계

Chief programmer team 방식에 의한 프로젝트 관리
Librarian
Chief
programmer
Back-up
programmer
Programmer
Programmer
Programmer
classical structure
Team
manager
Programmer
Team
leader
Programmer
Technical management
Nontechnical management
modern structure
Programmer
소프트웨어 설계

설계 heuristics

Fan-in
 여러 개의 fan-in은 코드의 중복을 줄여줌.
 여러 개의 fan-in을 갖는 모듈은 높은 응집도를 가져야
한다.

Fan-out (Span of Control)
 어떤 모듈의 직접적인 하위 모듈의 수
 매우 높거나 혹은 매우 낮은 fan-out은 좋지 않은 설계

영향의 범위(scope of effect)
 어떤 결정으로부터 영향받는 모든 모듈들의 집합
 결정(decision)으로부터 영향받는 모듈은 결정을
내리는 모듈의 하위 모듈이 되어야 한다.

기능이 예측될 수 있는 모듈
 모듈을 기능 추상화를 통해 블랙 박스 모듈로 구성
 동일한 입력 자료에 대해 매번 호출될 때마다
동일하게 동작하는 모듈
 “state memory”를 갖지않아야 한다.

초기화
 initialization(또한 clean up)이 작업이 이루어지는 모듈
내부에서 이루어지도록 설계
소프트웨어 설계

구조와 관련된 용어
M
Fan-out
a
b
Depth
j
d
f
e
g
h
c
k
m
l
n
o
Fan-in
i
q
Width
p
소프트웨어 설계

영향과 제어의 영역
Effect of
decision
Decision
Decision
Effect of
decision
소프트웨어 설계

제어 영역과 영향 영역
제어를
실시한다
(주모듈)
입력 메시지를
얻는다
입력 메시지로 부터
해당 레코드 확보
해당 레코드
(에러도 포함) 출력
(입력모듈)
(처리모듈)
(출력모듈)
제어영역
에러조건에 의한 영향영역
제어를
실시한다
입력 메시지를
얻는다
(입력
모듈)
(주모듈)
입력 메시지로 부터
해당 레코드 확보
해당 레코드
출력
(처리모듈)
(출력모듈)
에러를 편집
출력한다
제어영역(실선)
(에러모듈)
영향영역
설계의 도큐먼트

도큐먼트의 역할

개발의 수단
 개발 요원 간의 통신 수단
 설계 작업의 상세화 수단
 설계 품질의 확보

표준화의 추진
 대상이되는 소프트웨어 구조의 표준화
 소프트웨어 설계 제조 순서의 표준화

프로젝트 관리의 수단
 각 공정의 진행 상황의 확인
 소프트웨어 규모, 품질 등의 정량적 파악

공유 자산화와 기술의 전수
 소프트웨어를 조직의 공유자산으로 한다.
 신인, 후배에 대한 교육과 기술의 전수
소프트웨어 설계

시스템 구조 설계서
1. 개요
1.1
1.2
1.3
1.4
1.5
시스템의 목표
하드웨어와 소프트웨어
소프트웨어의 주요 기능
설계 상 제약 사항
참조된 개발 문서
2. 시스템 구조
2.1 시스템 구조 개요
2.2 시스템 구조도
2.3 자료 사전
3. 모듈 설계(각 모듈에 대한)
3.1
3.2
3.3
3.4
3.5
3.6
3.7
모듈 이름
모듈 형
인터페이스
오류 메시지
사용하는 화일
호출하는 모듈
기능 설명
소프트웨어 설계

시스템 구조 설계서 (계속)
4. 화일 구조 또는 데이타베이스 설계
4.1 외부 화일(데이타베이스)의 논리적 구조
4.2 공유 자료
4.3 화일 접근 방법(데이타베이스 관리 체제)
5. 요구 분석 참조표
6. 제약 사항
7. 참고 사항
참고 문헌
부록