01. 설계의 이해

p. 1

• 원광대학교 컴퓨터소프트웨어공학과

• 2018학년도 1학기 수요일 4교시 목요일 34교시

• 소프트웨어공학 / 374022-01

A05. 상위 설계 소프트웨어공학

p. 2

• 상위 설계

• 01. 설계의 이해

• 02. 설계의 원리

• 03. 소프트웨어 아키텍처

• 04. 디자인 패턴

목차

그림: 쉽게 배우는 소프트웨어 공학, 김치수, 한빛미디어

2

p. 3

• 1. 건축 설계와 소프트웨어 설계

• 설계• 계획을 종합한 후 설계도를 작성하고 구체적으로 내용을 명시하는 일

01. 설계의 이해

p. 4

• 1. 건축 설계와 소프트웨어 설계

• 분석 단계

• 사용자의 요구 사항을 토대로 요구 분석 명세서를 작성함.

• 개념적/추상적인 성격이 강함.

• 사용자의 요구를 무엇(What) 관점에서 봄.

• 설계 단계

• 개발팀은 작성된 요구 분석 명세서를 참조하여 설계서(건축의 설계 도면) 를 작성한 뒤 이를 기반으로 구현함.

• 분석단계에서 고려하지 않았던 상세내용을 충분히 반영하여 구현할 수 있 는 수준으로 준비해야 함.

• 사용자의 관점을 어떻게(How) 관점에서 봄.

01. 설계의 이해

p. 5

• 1. 건축 설계와 소프트웨어 설계

• 좋은 설계의 조건

• 요구 분석 명세서의 내용을 설계서에 모두 포함하여야 함.

• 유지보수가 용이하도록 추적이 가능해야 함.

• 변화에 쉽게 적응할 수 있어야 함.

• 시스템 변경으로 인한 영향이 최소화되도록 국지적이어야 함.

• 설계서는 읽기 쉽고, 이해하기 쉽게 작성해야 함.

• 모듈이 독립적이어야 함.

• 모듈 내 요소들 간의 응집력은 높아야 함.

• 모듈 간의 결합력은 낮아야 함.

01. 설계의 이해

p. 6

• 2. 설계의 종류

01. 설계의 이해

4

p. 7

• 2. 설계의 종류

• 상위 설계(High-Level Design)

• 예비 설계

• 전체 골조(뼈대)를 세움.

• 내용• 아키텍처(구조) 설계: 시스템의 전체적인 구조

• 데이터 설계: 시스템에 필요한 정보를 자료구조/데이터베이스 설계에 반영• 시스템 분할: 전체 시스템을 여러 개의 서브시스템으로 분리

• 인터페이스 설계: 시스템의 구조와 서브시스템들 사이의 관계

• 사용자 인터페이스 설계: 사용자와 시스템의 관계

01. 설계의 이해

p. 8

• 2. 설계의 종류

• 하위 설계(Low-Level Design)

• 내부 구조를 상세히 나타냄.

• 내용• 각 모듈의 실제적인 내부를 알고리즘(Pseudo-Code) 형태로 표현함.

• 인터페이스에 대한 설명, 자료구조, 변수 등에 대한 상세한 정보를 작 성함.

01. 설계의 이해

p. 9

• 설계의 원리

• 분할과 정복

• 추상화

• 단계적 분해

• 모듈화

• 정보은닉

02. 설계의 원리

p. 10

• 1. 분할과 정복(Divide & Conquer)

• 규모가 큰 소프트웨어를 여러 개의 작은 서브시스템으로 나눔.

• 하나의 일을 수행할 때 작은 단위로 나누고,

• 각 작은 단위를 하나씩 처리하여 전체일을 끝냄.

• 모듈로 나누면 모듈끼리 서로 통신하는 방법이 필요함.

02. 설계의 원리

6

p. 11

• 2. 추상화(Abstraction)

• 2.1. 추상화의 개념

• 특정한 목적과 관련된 필수 정보만 추출하여 강조하고,

• 관련이 없는 세부 사항을 생략함으로써,

• 본질적인 문제에 집중할 수 있도록 하는 작업

02. 설계의 원리

p. 12

• 2. 추상화(Abstraction)

• 2.1. 추상화의 개념

• 객체지향에서의 추상화

• 객체들의 공통점을 뽑아 클래스라는 이름을 붙여 놓은 것

02. 설계의 원리

p. 13

• 2. 추상화(Abstraction)

• 2.1. 추상화의 개념

• 추상화의 방법

• 과정(Procedure) 추상화: 프로그램 전체를 알고리즘 형태로 작성

• 데이터(Data) 추상화: 데이터를 모아 데이터 구조 형태로 표현

• 제어(Control) 추상화: 여러 줄의 내용을 간략히 줄여서 표현

02. 설계의 원리

p. 14

• 2. 추상화(Abstraction)

• 2.2. 과정 추상화(Procedure Abstraction)

02. 설계의 원리

8

p. 15

• 2. 추상화(Abstraction)

• 2.3. 데이터 추상화(Data Abstraction)

02. 설계의 원리

p. 16

• 2. 추상화(Abstraction)

• 2.4. 제어 추상화(Control Abstraction)

02. 설계의 원리

p. 17

• 3. 단계적 분해(Gradual Decomposition)

• 하향식 설계에서 사용됨.

• 기능을 점점 작은 단위로 나누어 점차적으로 구체화하는 방법

02. 설계의 원리

p. 18

• 4. 모듈화(Modulization)

• 실제로 개발할 수 있는 작은 단위로 나눔.

• 모듈(Module)

• 규모가 큰 것을 여러 개로 나눈 조각

• 소프트웨어 구조를 이루는 기본적인 단위

• 하나 이상의 논리적인 기능을 수행하기 위한 명령어들의 집합

• 모듈의 특징

• 다른 것들과 구별될 수 있는 독립적인 기능을 갖는 단위

• 유일한 이름을 가짐.

• 독립적으로 컴파일이 가능함.

• 모듈에서 또 다른 모듈을 호출할 수 있음.

• 다른 프로그램에서도 모듈을 호출할 수 있음.

• 모듈의 형태

• 라이브러리 함수

• 그래픽 함수

• 추상화된 자료

• 서브루틴(Subroutine)

• 프로시저(Procedure)

• 객체• 메서드(Method)

02. 설계의 원리

10

p. 19

• 1. 아키텍처와 소프트웨어 아키텍처의 이해

• 아키텍처

• 건축물의 뼈대 뿐 아니라 특성을 결정짓는 기본 구조

03. 소프트웨어 아키텍처

p. 20

• 1. 아키텍처와 소프트웨어 아키텍처의 이해

• 소프트웨어 아키텍처 복잡성

• 전체 시스템의 구조를 생각하며, 균형과 조화를 이루도록 설계함.

• 복잡성 문제 해결 방법

• 개발할 소프트웨어의 전체 구조를 생각함.

• 구조를 이루는 구성 요소를 찾음.

• 구성 요소들 간의 명확한 관계를 설정함.

• 일정한 규칙을 따름.

03. 소프트웨어 아키텍처

p. 21

• 2. 아키텍처의 특징과 기능

• 소프트웨어 아키텍처의 정의

• 외부에서 인식 가능한 특성이 담긴 소프트웨어의 골격이 되는 기본 구조

• 개발할 소프트웨어의 구조, 구성요소, 구성 요소의 속성, 구성 요소 간의 관계와 상호작용을 판단하고 결정하는 것

• 다루는 내용

• 구성 요소

• 구성 요소들 사이의 관계

• 구성 요소들이 외부에 드러내는 속성

• 구성 요소들과 주변 환경 사이의 관계

• 구성 요소들이 제공하는 인터페이스

• 구성 요소들의 협력 및 조립 방법

03. 소프트웨어 아키텍처

p. 22

• 2. 아키텍처의 특징과 기능

• 소프트웨어 아키텍처의 특징

• 개발할 소프트웨어에 대한 전체적인 구조를 다룸.

• 소프트웨어를 이루고 있는 여러 구성 요소(서브시스템, 컴포넌트)를 다룸.

• 구성 요소들이 인터페이스를 통해서 어떻게 상호작용하는지를 정의해야 함.• 세부 내용보다는 중요한 부분만을 다룸.

• 시스템 설계와 개발 시 적용되는 원칙과 지침이 있어야 함.

03. 소프트웨어 아키텍처

12

p. 23

• 2. 아키텍처의 특징과 기능

• 소프트웨어 아키텍처의 기능

• 의사소통 도구로 활용할 수 있어야 함.

• 구현에 대한 제약 사항을 정의해야 함.

• 품질 속성을 결정해야 함.

• 재사용할 수 있게 설계해야 함.

• 소프트웨어 아키텍처 설계 시 기술하는 방법

• 이해하기 쉽게 작성

• 명확하게 기술

• 표준화된 형식 사용

• 문서 버전 명시

03. 소프트웨어 아키텍처

p. 24

• 3. 소프트웨어 아키텍처의 품질 속성

• 이해 관계자들이 요구하는 수준만큼 달성해야 할 품질 요구사항

• 내용

• 중요하게 생각하는 품질 속성을 결정함.

• 어느 정도 수준으로 설계할 것인지 목표를 설정함.

• 목표를 달성할 수 있는 방법을 서술함.

• 품질 속성 평가 방법을 서술함.

03. 소프트웨어 아키텍처

p. 25

• 3. 소프트웨어 아키텍처의 품질 속성

• 종류• 시스템 품질 속성: 가용성, 변경 용이성, 성능, 보안성, 사용성, 테스트 용 이성• 비즈니스 품질 속성: 시장 적시성, 비용과 이익, 예상 시스템 수명, 목표 시장, 신규 발매 일정 또는 공개 일정, 기존 시스템과의 통합

• 아키텍처 품질 속성: 개념적 무결성, 정확성과 완전성, 개발 용이성 또는 구축 가능성

• 이해 관계자별 품질 속성: 발주자 관점, 사용자 관점, 개발자 관점

03. 소프트웨어 아키텍처

p. 26

• 3. 소프트웨어 아키텍처의 품질 속성

• 3.1. 시스템 품질 속성

• 가용성(Availability)

• 시스템이 운용될 수 있는 확률

• 하드웨어의 가용성을 높이기 위해 이중화 설계함.

• 아키텍처 설계 시 여분의 구성요소를 포함하여 설계함.

• 변경 용이성(Modifiability)

• 쉽게 변경할 수 있는 능력

• 성능(Performance)

• 이벤트가 발생했을 때, 빠르고 적절하게 반응할 수 있는 능력

• 보안성(Security)

• 허용하지 않은 접근에 대응할 수 있는 능력

• 사용성(Usability)

• 편의성

• 테스트 용이성(Testability)

03. 소프트웨어 아키텍처

14

p. 27

• 3. 소프트웨어 아키텍처의 품질 속성

• 3.2. 비즈니스 품질 속성

• 시장 적시성(Time to Market)

• 정해진 날짜에 소프트웨어를 출시해 경쟁력을 높일 수 있는 정도

• 비용과 이익(Cost & Benefit)

• 비용을 더 들여 사용하고 효과를 볼 것인지, 아니면 비용을 절약하는 데 중심을 둘 것인지를 판단

• 예상 시스템 수명(Predicted Lifetime of the System)

• 변경 용이성(Modifiability), 확장성(Scalability), 이식성(Portability) 을 중요하게 고려

• 목표 시장(Targeted Market)

• 신규 발매 일정 또는 공개 일정(Rollout Schedule)

• 기존 시스템과의 통합(Integration with Legacy System)

03. 소프트웨어 아키텍처

p. 28

• 3. 소프트웨어 아키텍처의 품질 속성

• 3.2. 아키텍처 품질 속성

• 개념적 무결성(Conceptual Integrity)

• 일관성

• 전체 시스템과 시스템 구성 요소가 일관

• 정확성과 완전성(Correctness & Completeness)

• 사용자가 요구하는 기능을 충족시키는 정도

• 요구 분석 명세서와 일치하는 정도

• 개발 용이성 또는 구축 가능성(Buildability)

03. 소프트웨어 아키텍처

p. 29

• 3. 소프트웨어 아키텍처의 품질 속성

• 3.4. 이해 관계자별 품질 속성

• 발주자 관점

• 저렴한 비용이 우선

• 사용자 관점

• 편리하고 이해하기 쉬운 시스템이 우선

• 개발자 관점

• 새로운 플랫폼에 쉽게 적용할 수 있는 속성이 우선

03. 소프트웨어 아키텍처

p. 30

• 4. 아키텍처 구축 절차

• 4.1. 요구 사항 분석

• 4.2. 아키텍처 분석

• 4.3. 아키텍처 설계

• 관점 정의

• 아키텍처 스타일 선택

• 후보 아키텍처 선택

• 4.4. 검증 및 승인

• 아키텍처 평가

• 아키텍처 상세화(반복)

• 아키텍처 승인

03. 소프트웨어 아키텍처

16

p. 31

• 5. 아키텍처 4+1 관점

• UML(Unified Modeling Language) 4+1 관점

• 유스케이스 관점

• 논리적 관점

• 구현 관점

• 프로세스 관점

• 배치 관점

03. 소프트웨어 아키텍처

p. 32

• 5. 아키텍처 4+1 관점

• 5.1. 유스케이스 관점

• 시스템 기능에 관심

• 시스템이 사용자에게 제공하는 기능에 초점

• 정적 표현

• 유스케이스 다이어그램

• 다른 4가지 관점에 사용되는 다이어그램의 근간

• 분석 및 설계의 전과정에 걸쳐 사용

• 동적 표현

• 상태 다이어그램

• 순차 다이어그램

• 통신 다이어그램

• 활동 다이어그램

03. 소프트웨어 아키텍처

p. 33

• 5. 아키텍처 4+1 관점

• 5.2. 논리적 관점

• 시스템의 내부에 관심

• 시스템의 기능을 제공하기 위한 클래스/컴포넌트의 종류/관계에 초점

• 정적 표현

• 클래스 다이어그램

• 객체 다이어그램

• 동적 표현

• 상태 다이어그램

• 순차/통신 다이어그램

• 활동 다이어그램

03. 소프트웨어 아키텍처

p. 34

• 5. 아키텍처 4+1 관점

• 5.3. 구현 관점

• 소프트웨어 서브시스템의 모듈의 구조화에 관심

• 모듈: 원시코드, 데이터 파일, 컴포넌트, 실행 파일 등

• 정적 표현

• 컴포넌트 다이어그램

• 동적 표현

• 상태 다이어그램

• 순차 다이어그램

• 통신 다이어그램

• 활동 다이어그램

03. 소프트웨어 아키텍처

18

p. 35

• 5. 아키텍처 4+1 관점

• 5.4. 프로세스 관점

• 실제 구동 환경에 관심

• 시스템 내부의 구조에 관심

• 클래스 간의 관계, 클래스의 동작, 클래스 간 상호작용

• 개발자와 시스템 통합자를 위함.

• 동적 표현

• 상태 다이어그램

• 순차 다이어그램

• 협동 다이어그램

• 활동 다이어그램

• 시스템 구성 표현

• 컴포넌트 다이어그램

• 배치 다이어그램

03. 소프트웨어 아키텍처

p. 36

• 5. 아키텍처 4+1 관점

• 5.5. 배치 관점

• 시스템을 구성하는 처리 장치 간의 물리적인 배치에 관심

• 서브시스템들의 연관성과 실행을 노드 간의 관계로 표현

• 정적 표현

• 배치 다이어그램

• 동적 표현

• 상태 다이어그램

• 순차 다이어그램

• 통신 다이어그램

• 활동 다이어그램

03. 소프트웨어 아키텍처

p. 37

• 6. 아키텍처 스타일

• 검증된 보편적인 아키텍처 형태

• 예전엔 개발자들이 각자의 방식대로 스타일을 개발/유지/보수

• 스타일에 따라 구조, 규칙, 요소, 기법 등이 결정됨

• 아키텍처 스타일을 활용한 아키텍처 설계의 장점

• 개발 기간 단축

• 고품질의 소프트웨어 생산

• 수월한 의사소통

• 용이한 유지보수

• 검증된 아키텍처

• 구축 전 시스템 특성에 대한 시뮬레이션 가능

• 기존 시스템에 대한 빠른 이해

03. 소프트웨어 아키텍처

p. 38

• 6. 아키텍처 스타일

• 기능• 소프트웨어 시스템의 구조의 체계적 구성을 위해 기본 스키마를 제시

• 미리 정의된 서브시스템을 제공

• 각 아키텍처 패턴 간의 책임을 명시

• 패턴 간의 관계를 조직화 하는 규칙/가이드라인 제시

• 문제를 소프트웨어 모듈 단위로 분해하는 방법을 제시

• 분해한 소프트웨어 모듈 단위가 상호작용하는 방법을 제시

03. 소프트웨어 아키텍처

20

p. 39

• 7. 아키텍처 모델

03. 소프트웨어 아키텍처

p. 40

• 7. 아키텍처 모델

• 7.1. 데이터 중심형 모델

• 리포지토리 모델(Repository Model)

• 주요 데이터가 리포지토리(Repository)에서 중앙 관리됨.

• 장점• 데이터가 리포지토리에 모여 있어서 데이터의 일관성있는 관리 가능

• 새로운 서브시스템을 추가하기 용이

• 단점

• 리포지토리의 병목현상(리포지토리 변경이 서브시스템에 큰 영향)

03. 소프트웨어 아키텍처

p. 41

• 7. 아키텍처 모델

• 7.2. 클라이언트-서버 모델(Client-Server Model)

• 데이터와 처리 기능을 클라이언트와 서버에 분할하여 사용

• 분산 아키텍처 유형에 적합

• 구성• 서버: 서비스 제공

• 클라이언트: 서비스 요청

• 서비스

03. 소프트웨어 아키텍처

p. 42

• 7. 아키텍처 모델

• 7.3. 계층 모델(Layering Model)

• 기능을 몇 개의 계층으로 나누어 배치

• 상위 계층은 클라이언트, 하위 계층은 서버 역할

• 구성• 프레젠테이션(사용자 인터페이스) 계층

• 비즈니스 로직(애플리케이션) 계층

• 데이터(데이터베이스) 계층

03. 소프트웨어 아키텍처

22

p. 43

• 7. 아키텍처 모델

• 7.4. MVC 모델(Model, View, Controller Model)

• 중앙 데이터 구조

• 여러 개의 뷰 서브시스템을 필요로 하는 상호작용 시스템에 적합

• 구성• 모델(Model) 서브시스템

• 모든 데이터 상태와 로직을 처리하고, 호출에만 응답

• 뷰(View) 서브시스템

• 모델 서브시스템이 제공한 데이터를 사용자에게 보여줌

• 제어(Controller) 서브시스템

• 뷰와 모델 사이에 전달자 역할

03. 소프트웨어 아키텍처

p. 44

• 7. 아키텍처 모델

• 7.5. 데이터 흐름 모델

• 파이프 필터(Pipe & Filter) 구조

• 사용자의 개입 없이 데이터의 흐름이 전환되는 경우에 사용

• 구성• 필터(Filter)

• 데이터 스트림을 입력 받아 처리하는 서브시스템

• 파이프(Pipe)

• 필터에서 처리된 데이터 스트림을 다른 필터에 전달

03. 소프트웨어 아키텍처

p. 45

• 1. 디자인 패턴의 이해

• 디자인 패턴의 정의

• 자주 사용하는 설계 형태를 정형화 하여 유형별로 만든 설계 템플릿

• 장점• 효율성과 재사용성 제고

• 개발자(설계자) 간의 원활한 의사소통

• 소프트웨어 구조 파악 용이

• 재사용을 통한 개발시간 단축

• 설계 변경 요청에 대한 유연한 대처

• 단점• 객체지향 설계/구현 위주

• 초기 투자 비용 부담

04. 디자인 패턴

p. 46

• 2. GoF(Gang of Four) 디자인 패턴

04. 디자인 패턴

24

p. 47

• 3. factory method 패턴

04. 디자인 패턴

p. 48

• 4. singleton 패턴

04. 디자인 패턴

p. 49

• 5. prototype 패턴

04. 디자인 패턴

p. 50

• 6. builder 패턴

04. 디자인 패턴

26

p. 51

• 7. abstract factory 패턴

04. 디자인 패턴

p. 52

• 8. composite 패턴

04. 디자인 패턴

p. 53

• 9. adaptor 패턴

04. 디자인 패턴

p. 54

• 10. bridge 패턴

04. 디자인 패턴

28

p. 55

• 11. decorator 패턴

04. 디자인 패턴

p. 56

• 12. facade 패턴

04. 디자인 패턴

p. 57

• 13. flyweight 패턴

04. 디자인 패턴

p. 58

• 14. proxy 패턴

04. 디자인 패턴

30

p. 59

• 15. iterator 패턴

04. 디자인 패턴

p. 60

• 16. observer 패턴

04. 디자인 패턴

p. 61

• 17. strategy 패턴

04. 디자인 패턴

p. 62

• 18. template method 패턴

04. 디자인 패턴

32

p. 63

• 19. visitor 패턴

04. 디자인 패턴

p. 64

• 20. chaine of responsibility 패턴

04. 디자인 패턴

p. 65

• 21. command 패턴

04. 디자인 패턴

p. 66

• 22. mediator 패턴

04. 디자인 패턴

34

p. 67

• 23. state 패턴

04. 디자인 패턴

p. 68

• 24. memento 패턴

04. 디자인 패턴

p. 69

• 25. interpreter 패턴

04. 디자인 패턴