Transcript Design - 소공녀의 전공강의노트♡

Software Design
소프트웨어 설계(1)
설계 단계
Functional
model
Behavioral
model
Informational
model
Design
Procedural
design
Other
requirements
Data
design
Interface design
Architectural
design
Code
Program
modules
Test
Integrated
and validated
software
소프트웨어 설계(2)
설계 과정
 요구분석명세서에 기술된 명세를 해결 방안
으로 변환시키는 과정
 명세 (Specification)
 소프트웨어 시스템을 problem domain 관점에서
기술
 설계 (Design)
 software domain 관점에서 기술
 주어진 문제에 대하여 제안된 해결방안(solution)
 분석과 설계의 차이 --> 주택 건설의 예
설계작업의 구분(1)
프로젝트 관리 관점에서의 구분
 예비 설계(preliminary design)
 요구사항들을 자료와 소프트웨어 구조로 변환
 상세 설계(detail design)
 세부적인 자료구조와 알고리즘 도출
기술적 측면에서의 구분




소프트웨어 구조 설계(architectural design)
자료 설계
절차 설계(procedural design)
인터페이스 설계
 인간-기계간의 상호작용 설계
설계작업의 구분(2)
설계대상이 무엇인가에 따른 구분
 외적 설계 (External Design)
 소프트웨어 제품의 외적 특성을 고안/계획/기술
 요구사항을 세분화하여 시스템에 대한 고수준의 구조적
관점 구축
 내적 설계 (Internal Design)
 소프트웨어 제품의 내부 구조와 구성 모듈에 대하여 기술
외적 설계 (External Design)
 user displays, report formats, external data
sources/sinks
 functional characteristics, high-level process
structure
 성능 요구 사항
설계작업의 구분(3)
내적 설계 (Internal Design)
 구조 설계 (Architectural Design)
 building blocks과 그들 사이의 관계를 파악
 Hierarchy of system views
 시스템의 기능, 자료 흐름, 자료 저장소 사이의 관
계 정립
 상세 설계 (Detailed Design)
 기능을 구현하기 위한 알고리즘 기술
 자료 저장소를 구현하기 위한 자료 구조 확립
 기능과 자료 구조 간의 사실상의 상호 연결 관계
구축
설계 원리(Principles of Design)
설계 원리
 추상화(abstraction)
자세한 사항보다는 근본적인 본질에 집중
 정보은닉(information hiding)
모듈의 상세한 처리 내용은 시스템의 다른 부분으로부터
감추어져야 함
 단계적 분해(stepwise refinement)
문제를 상위 개념부터 하위의 구체적인 단계로 분할 및
세분화
 모듈화(modularization)
소프트웨어를 구성하는 기본 단위는 모듈
추상화(1)
추상화란?
 자세한 사항은 접어두고, 근본적인 본질에 집중
 전체적이고 포괄적인 개념 --> 구체적인 개념
 기능 추상화, 자료 추상화, 제어 추상화
기능 추상화(Functional abstraction)
 입력 자료를 출력 자료로 변환하는 과정을 추상화
 Examples
 Abstraction by Parameterization : subroutine
 Abstraction by Specification : built-in functions
추상화(2)
자료 추상화(Data abstraction)
 자료의 표현 및 자료 구조의 구현에 독립적
 자료의 자세한 부분에 대한 지식 없이도 사용 가능
 Examples
 Built-in Types: Freedom of storage representations
 User-defined Types: Allow mapping of concepts
from the problem domain into the implementation
language
 Data Encapsulation: Packaging of a data structure
and its access routines in a single module
 Abstract Data Types: Declaration of a data type
(template) from which numerous instances of
encapsulated data objects can be created
정보 은닉
정보 은닉이란?
 모듈 안에 포함된 정보는 이를 필요로 하지 않는
다른 모듈이 접근할 수 없도록 설계되어야 함
 모듈화의 기준으로 사용되는 개념
장점




모듈 구현의 독립성
모듈 구현의 병렬성
모듈의 이해도 증진
변경의 국부화, 변경으로 인한 영향의 최소화
단계적 세분화
단계적 세분화 기법(N. Wirth)
 상호 독립적인 설계 요소를 격리
 점진적으로 세분화
 세분화 요소의 표현(representation details)과
관련된 의사 결정은 가능한 한 연기
 세분화 과정에서 각각의 연속적인 단계들은
이전 단계로부터 자연스럽게 확장시킴
기법의 적용
 모듈에 대한 상세 설계시 사용
 사례 : “Airline Reservations Program”
모듈화(1)
module이란?




수행 가능한 문장들의 집합으로 이름이 있는 서브루틴
잘 정의된 단일의 목적을 가짐
다른 모듈을 호출하거나 호출될 수 있음
컴파일하거나 라이브러리에 저장되는 단위
모듈 형태
 sequential module
 incremental module
 수행 중에 인터럽트가 가능한 모듈
 Examples: coroutine, interrupt driven system
 parallel module
 다중 프로세서 환경에서 다른 모듈과 동시에 실행될 수 있는 모듈
 Examples: Modula의 Module, Ada의 Package
모듈화(2)
좋은 모듈이 되기 위한 조건




modular decomposability: top-down design
조합 용이성: reusable
understandability: ease of maintenance
continuity: 변경으로 인한 소프트웨어 구조에의 영향
을 최소화
 protection: error의 영향 및 side effect 최소화
모듈의 기능적 독립성에 대한 품질 평가 기준
 응집도: 모듈 내부의 기능적 응집력의 정도
 결합도: 모듈 상호간에 의존하는 정도
모듈의 응집도 (Cohesion) (1)
 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) (2)
 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).
 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) (3)
 Module Strength의 판별
IF 단일 기능 THEN functional
ELSE
IF Data에 의한 결합 informational or communicational
ELSE IF Control에 의한 결합 procedural or classical
ELSE logical or coincidental
 Exercises
 Print and punch the output file
 Update, add, or delete a record on the master file.
 Format screen for part display and read part record from
database
 Read the next transaction, edit it, and display it to the tape
operator.
 Read or write an inventory record (two entry points).
모듈의 결합도 (Coupling) (1)
 결합도에 영향을 주는 요소
 모듈 간의 연결 형태: 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) (2)
 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..
구조 설계(1)
Architectural Design?
 Establishing the overall structure of a software
system
 identify major system components and their
communications
 produces a description of the software architecture
 An early stage of the system design process
 Represents the link between specification and design
processes
 Often carried out in parallel with some specification
activities
구조 설계(2)
Advantages of explicit architecture
 Stakeholder communication
 Architecture may be used as a focus of
discussion by system stakeholders
 System analysis
 Means that analysis of whether the system can
meet its non-functional requirements is
possible
 Large-scale reuse
 The architecture may be reusable across a
range of systems
구조 설계(3)
Architectural design process
 System structuring
 identify several principal sub-systems
 identify communications between these subsystems
 Control modelling
 establish a model of the control relationships
between the different parts of the system
 Modular decomposition
 decompose the identified sub-systems into
modules
구조 설계(4)
Sub-systems and modules
 A sub-system is a system in its own right whose
operation is independent of the services provided
by other sub-systems.
 A module is a system component that provides
services to other components but would not
normally be considered as a separate system
System structuring
 Concerned with decomposing the system into
interacting sub-systems
 The architectural design is normally expressed as
a block diagram presenting an overview of the
system structure
 May develop more specific models showing how
sub-systems share data, are distributed, and
interface with each other
구조 설계(5)
Control models
 Are concerned with the control flow
between sub-systems. Distinct from the
system decomposition model
 Centralized control
 One sub-system has overall responsibility for
control and starts and stops other sub-systems
 Event-based control
 Each sub-system can respond to externally
generated events from other sub-systems or
the system’s environment
구조 설계(6)
Modular decomposition
 Another structural level where sub-systems
are decomposed into modules
 Two modular decomposition models covered
 An object model where the system is decomposed
into interacting objects
 A data-flow model where the system is
decomposed into functional modules which
transform inputs to outputs. Also known as the
pipeline model
 If possible, decisions about concurrency
should be delayed until modules are
implemented
자료 설계(1)
자료 설계란?
 요구 단계에서 식별된 자료 객체들의 논리적인 표현
을 선택
 논리적 자료 구조에 직접 작동해야 하는 프로그램 모
듈을 식별
자료 설계를 위한 원칙
 기능과 행위에 적용된 체계적인 분석 원칙을 자료에
적용
 모든 자료 구조와 이에 대한 모든 연산을 식별
 자료 사전을 자료와 프로그램을 정의하는데 이용
 하위 수준의 자료 설계에 관한 결정은 가능한 한 연기
 정보 은닉 개념 적용
 유용한 자료 구조의 라이브러리와 이에 적용되는 연
산을 개발
자료 설계(2)
자료 구조 설계
 자료를 단순파일에 저장하는 경우에 수행
 시스템의 외부 파일에 대한 설계 및 시스템구조도에 나타
난 자료에 대한 자료 사전 작성
 절차
1. DFD의 자료저장소 => 외부 파일
2. 요구 단계의 자료 사전 => 레코드의 항목 및 길이 결정
 사례 : 인사관리 시스템의 인사 기본 파일
데이터베이스 설계
 자료를 데이터베이스로 구축할 경우에 수행
 자료의 논리적 설계
 데이터 모델링에 의한 자료 분석 (E-R Diagram)
절차 설계
절차 설계란?
 절차 설계/알고리즘 설계/상세설계
 구조적 설계 기법은 소프트웨어의 구조 설계에
초점 ==> 모듈 내부에 대한 설계가 필요
 상세 설계(detailed design)
 구조 설계에서 식별한 모듈 또는 오퍼레이션에 대한
알고리즘 설계
 특정 프로그래밍 언어의 사용은 절제
 표기법
 그래픽 표기 방법: flowchart, N-S 도표
 가상 코드 표기 방법: 프로그램 설계 언어(PDL)
Flow Chart (1)
기본개념
 알고리즘의 제어 흐름을 표현하는 그래픽 도구
 기본 요소: 직사각형, 다이아몬드, 화살표
 직사각형 --> 처리를 표시
 다이아몬드 --> 조건 분기를 표시
 화살표 --> 제어 흐름을 표시
장단점
 간단하고 표현력이 높으며 배우기 쉽다
 구조적으로 작성하면 읽기 쉽고 이해도가 높은 프
로그램 구조 생성 가능
 비구조적이고 복잡한 프로그램 구조 생성 가능
 goto 문의 무절제한 사용
 간단한 모듈의 내부 구조를 나타내는데 적합하나,
복잡한 시스템 구조 설명에는 부적합
Flow Chart (2)
처리 1
Yes
조건
처리 1
처리 2
No
처리 2
¼ø¼-Àû ±¸Á¶
if then else ±¸Á¶
상황1
Yes
처리 1
조건
No
Yes
순환
처리
No
상황2
Yes
처리 2
WhileÇü ¼øȯ ±¸Á¶
순환
처리
No
상황n
Yes
처리 n
No
조건
Yes
Case Á¶°Ç ±¸Á¶
No
RepeatÇü ¼øȯ ±¸Á¶
NS Chart(1)
기본 개념
 flowchart의 단점을 극복하고자 Nassi & Schneiderman
이 제안, Chapin이 발전시킨 그래픽 표기법
 순서적 구조, 조건 분기 구조, 순환 구조 등 기본적인 요
소에 대한 표시 방법 제공
장단점
 프로그램의 기본 제어 구조를 서로 다른 도표로 표시하
여 쉽게 읽고 이해할 수 있음
 임의로 goto 문을 작성할 수 없고, N-S 도표가 제공하는
요소들만 사용 --> 프로그램의 구조적 표현 가능
 순환(recursion) 제어 구조를 쉽게 표시할 수 있음
NS Chart(2)
처리 1
조건
True
순서적
구조
처리 2
then 부분
False
else 부분
조건 분
기 구조
처리 3
case 조건
순환 조건
while형
순환 구조
repeat형
순환 구조
순환 조건
1
2
3
4
case 조
건 구조
프로그램 설계언어
Program Design Language의 기본 개념




가상 코드(pseudocode)라고도 부름
고급 프로그램 언어의 제어 구조와 자연 언어를 통합
PDL "프로그램"은 순서도 혹은 N-S 도표로 변환 가능
Examples: PDL/Ada, PDL/C
자체적인 PDL 설계 시 구비 요건





키워드 및 제어 구조는 미리 정의
처리에 대한 설명은 자연어 사용
데이터 타입에 대한 정의를 내릴 수 있는 기능
사용할 고급 언어로 정의할 수 있는 모든 타입을 설명
모듈 정의 기능을 제공하여야 하며, 모듈간에 서로 호출
할 수 있어야 함
사용자 인터페이스 설계(1)
사용자 인터페이스 설계의 필요성
 컴퓨터 보급의 확대에 따라 사용자 인터페이
스에 대한 중요성이 증가
 컴퓨터와의 대화가 직관적이고 쉬워야 함
 많은 사람들이 컴퓨터를 사용하는데 어려움을
느끼고 있음
 인터페이스가 배우기 어렵고, 쓰기 어렵고, 사용자
의 실수를 허용하지 아니함
 인터페이스가 쉽다면, 사용자는 시스템 내부
의 기능을 보다 효과적으로 활용할 수 있음
사용자 인터페이스 설계(2)
요구단계에서의 사용자 인터페이스 설계
 요구분석 과정에서 파악된 자료의 반영
 사용자가 관심을 가지는 데이터
 사용자 입력 정보 및 시스템 출력 정보
 사용자가 보아야 할 데이터, 상태의 변화, 기능 수행 등
 요구명세서의 일부인 Preliminary User Manual에
사용자 인터페이스를 기술
 매뉴얼의 사용자를 명확히 규정
 사람과 시스템 사이의 인터페이스에 대한 정보 기술
 입출력 데이터를 중심으로 하여 예상되는 메뉴 구조, 스
크린, 보고서 형식 등을 포함하여 기술
사용자 인터페이스 설계(3)
설계 단계에서의 사용자 인터페이스 설계
 구체적인 사용자 인터페이스는 설계의 초기단계에
서 정의
 메뉴 구조, 스크린의 모양과 데이터, 필요한 버튼 등을
포함
 사용자와 상호 작용이 많은 시스템의 경우에는 사용자
인터페이스가 소프트웨어 구조보다 먼저 고려되어야 할
중요한 문제
 User Guide에 사용자 인터페이스 설계 결과를 기
록
 사용자 안내서에는 시스템의 목적, 주요 기능, 구조, 다
른 소프트웨어 및 하드웨어와의 인터페이스 등을 기술
 스크린에 대한 설명으로는 메뉴, 스크린 종류, 스크린 형
식, 데이터를 선택하거나 입력하는 방식 등을 포함
사용자 인터페이스와 인적 요소(1)
사용자 인터페이스의 인적 요소
 사용자 인터페이스의 사용자 = 인간
 고려해야 할 인적 요소 (human factor)
 심리학적인 요소
 사용자의 인터페이스에 대한 요구
 나이, 성, 직업, 교육, 문화, 피부 색깔 등에 따른 특성
 인간의 사물에 대한 인식 방법
 시각적인 지각 능력
 연역 또는 귀납적인 추론 능력
 인간 사회와 조직 등
사용자 인터페이스와 인적 요소(2)
인식 모델 (cognition model)
 인간이 정보를 처리하는 방법을 규명
 인간은 인식 과정을 통하여 사물을 이해하고
지식을 얻으며, 기억, 추리, 기능의 파악, 새로
운 아이디어의 창출 등을 수행
 HCI는 인간과 컴퓨터간의 지식 교환 방법을
제시하고, 이를 개선할 방안을 연구
입력 정보
해석
비교
응답 선택
응답 수행
State 1
Stage 2
Stage 3
Stage 4
출력 또는
응답
사용자 인터페이스와 인적 요소(3)
확장 모델
 인식 모델에 기억 장치와 관심부분을 추가
 perceptual processor가 어떤 방법으로 정보를 지
각하는가?
 정보가 어떻게 관심의 대상이 되는가?
 정보가 어떻게 처리되고 저장되는가?
주목
입력 정보
해석
비교
응답 선택
기억 장치
응답 수행
출력 또는
응답
사용자 인터페이스와 사회적 요소
정보에 대한 이해는 사회적 환경이 바탕
 사회 환경에서 보고, 듣고, 배운 정보가 저장되며, 이를
바탕으로 인식을 수행
 문화의 차이는 사용자 인터페이스에 대한 요구에 영향
 문화에 따라 붉은 색깔에 대한 이해와 반응은 서로 다름
 사용자 인터페이스 설계에 사회적 환경 및 습관에 대한 요소를 고
려
같은 사회적 환경이라도, 조직에서 수행하는 임무
에 따라 컴퓨터에 대한 이해는 상이
 조직이 업무를 능률적으로 수행하도록 지원
 사용자 인터페이스 설계시 사용자의 역할 및 기술 수준을
고려
 사용자의 역할에 따라 정보를 다양하게 표시하고, 다양한 상호 대
화 방식을 지원
 사용자의 기술 수준에 따라 사용자 인터페이스를 구분
사용자 인터페이스 방식
사용자 인터페이스의 평가 기준





사용법을 배우는데 소요되는 시간
특정 기능을 수행시키는데 필요한 시간
원하는 작업을 수행하기까지 범한 오류의 빈도
시스템에 대한 사용자의 만족도
시스템의 사용법을 기억하고 있는 기간
사용자 인터페이스 방식




명령어(Command) 방식
메뉴(Menu) 방식
양식 채움(Form fill-in) 방식
직접 조작(Direct manipulation) 방식
명령어 방식
Overview




컴퓨터 시스템이 도입된 초기에 널리 이용
키보드로 명령어를 컴퓨터에 입력하여 컴퓨터와 대화
컴퓨터 시스템의 동작마다 특정한 명령어를 제공
같은 종류의 동작을 세분화하기 위하여 다양한 선택 사
항을 제공
Example: UNIX 시스템 명령어
 cd, chdir : 작업 디렉토리를 변경
 chmod : 파일 또는 디렉토리의 access permission를
변경
 options: r 읽기 접근, w 쓰기 접근, x 수행 접근,
u 사용자(소유자), g 그룹, o 이외, a 전부
메뉴 방식 (1)
Overview
 다양한 메뉴 항목을 구성하여 제시하고, 사용자는 항목을
선택하여 필요한 기능을 수행
 현재 널리 사용되고 있는 인터페이스 방식
 사용자는 메뉴의 각 항목을 기억할 필요가 없으며, 각 항
목이 어떤 기능을 수행하는가를 판정할 수만 있으면 시스
템 사용 가능
 키보드 입력이 불필요하여, 입력 오류가 없음
full screen menu
 메뉴가 스크린 전부를 차지하고 사용자는 메뉴 항목을 반
드시 선택하여야만 다음 기능을 수행할 수 있는 방식
 예: touch screen을 통한 기능 선택 화면
메뉴 방식 (2)
Drop-down 메뉴
메뉴 방식 (3)
Pop-up 메뉴
메뉴 방식 (4)
Push-Button 메뉴
메뉴 방식 (5)
기타 메뉴
 Radio-Button 메뉴
 기능과 연관된 선택 사항을 메뉴 형식으로 설계할
수 있음
 선택 사항은 배타적(exclusive)인 경우도 있고, 배
타적이 아닌 경우도 있음
 Check-Box 메뉴
 Check-box 메뉴를 이용하여 선택 사항에서 비배
타적으로 선택할 수 있는 사항을 설계할 수 있음
 비배타적 선택에서는 사용자가 동시에 여러 가지
사항을 선택할 수 있음
양식기입 방식 (1)
Overview
 대량의 데이터를 입력하는 경우에 사용
 입력 항목에 따라 다양한 field를 제공하며, 해당
정보를 필드에 직접 입력 가능
 필드마다 이름을 갖고 있어 직관적이며, 일상 업
무에서 사용하는 서식과 유사하여 편함
 초보자도 쉽게 사용할 수 있음
 데이터베이스 시스템 또는 MIS 시스템에서 많이
사용
양식기입 방식 (2)
Example
사용자 인터페이스 설계시 유의사항




인터페이스는 일관성 있게 설계
의미 있는 피드백을 제공
파괴적인 행동을 하고자 할 때 이를 확인
사용자가 취한 행동에 대하여 원 상태로 복귀할 수 있도록
허용
 행동 사이에 기억해야 할 정보의 양을 극소화
 대화, 움직임, 생각의 효율성을 추구
 키 입력을 최소화 및 마우스 이동 거리 최소화
 사용자의 실수에 관대
 명령어와 활동들을 분류하여 화면에 배치하여 응집력을 강
화
 문맥-의존적(context sensitive) 도움말 기능을 제공
 간단한 동사와 명령어를 사용하고, 불필요한 입력은 제외
설계서 작성(1)
도큐먼트의 역할
 개발의 수단
 개발 요원 간의 통신 수단
 설계 작업의 상세화 수단
 설계 품질의 확보
 표준화의 추진
 개발대상 소프트웨어의 구조를 표준화
 소프트웨어 설계 제조 순서의 표준화
 프로젝트 관리의 수단
 각 공정의 진행 상황의 확인
 소프트웨어 규모, 품질 등의 정량적 파악
 공유 자산화와 기술의 전수
 소프트웨어를 조직의 공유자산으로 한다.
 신인, 후배에 대한 교육과 기술의 전수
설계서 작성(2)
 시스템 구조 설계서
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. 파일 구조 또는 DB설계
4.1 외부 파일(DB)의 논리적 구
조
4.2 공유 자료
4.3 파일 접근 방법((DBMS)
5. 요구 분석 참조표
6. 제약 사항
7. 참고 사항
참고 문헌
부록