IT CookBook, 쉽게 배우는 소프트웨어 공학

[강의교안 이용 안내]

• 본 강의교안의 저작권은 김치수와 한빛아카데미㈜에 있습니다.

• 이 자료는 강의 보조자료로 제공되는 것으로, 학생들에게 배포되어서는 안 됩니다. 

Chatpter 

06 하위 설계

01 모듈 설계

02 소프트웨어 개발 방법과 설계

03 객체지향의 주요 개념과 특징

04 클래스간의 관계와 설계 원칙

요약

연습문제

3/70



하위 설계 중 모듈 설계에 대해 살펴본다

.



모듈의 독립성을 측정하는 응집도과 결합도에 대해 알아본다

.



프로세스

, 데이터, 객체지향 방법의 특성을 비교하여 살펴본다.



객체지향의 기본 개념과 원리에 대해 알아본다

.



클래스 간의 관계와 설계 원칙에 대해 알아본다

.

Section 01 모듈 설계

5/70

1. 모듈과 모듈화의 이해(1)

 요구 분석 단계



DFD(구조적 방법), ERD(정보공학 방법), usecase diagram(객체지향 방법)

      요구 분석 명세서

 상위 설계(아키텍처 설계)



전체 구조를 파악하여 표현

 하위 설계(아키텍처 설계)



상세한 내용을 다루는 모듈 설계

6/70

1. 모듈과 모듈화의 이해(2)

 모듈화



소프트웨어 개발에서 큰 문제를 작은 단위로 나누는 것

 모듈



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



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



‘하나 또는 몇 개의 논리적인 기능을 수행하기 위한 명령어들의 집합’



독립 프로그램도 하나의 모듈

, 함수(메서드)들도 하나의 모듈

7/70

1. 모듈과 모듈화의 이해(3)

 모듈화의 특징

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

.

• 유일한 이름이 있어야 한다

.

• 독립적으로 컴파일이 가능하다

.

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

.

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

.

 모듈화의 형태

• 용도가 비슷한 것끼리 묶어놓은 라이브러리 함수

, 그래픽 함수

• 추상화된 자료

, subroutine, procedure, object, method

8/70

1. 모듈과 모듈화의 이해(4)

 좋은 모듈 설계를 위한 원칙

• 모듈 간의 결합coupling은 느슨하게loosely

• 모듈 내 구성 요소들 간의 응집cohesion은 강하게strongly

 모듈화의 장점

• 분할과 정복divide and conquer의 원리가 적용되어 복잡도 감소한다

.

• 문제를 이해하기 쉽게 만든다

.

• 변경하기 쉽고

, 변경으로 인한 영향이 적다.

• 유지보수가 용이하다

.

• 프로그램을 효율적으로 관리할 수 있다

.

• 오류로 인한 파급효과를 최소화할 수 있다

.

• 설계 및 코드를 재사용할 수 있다

.

9/70

1-1 모듈화와 소프트웨어 개발 비용

10/70

2. 응집도

 응집도cohesion



모듈 내부에 존재하는 구성 요소들 사이의 밀접한 정도



하나의 모듈 안에서 구성 요소들 간에 똘똘 뭉쳐 있는 정도로 평가

11/70

2-1 기능적 응집

 기능적 응집functional cohesion



함수적 응집



응집도가 가장 높은 경우이며 단일 기능의 요소로 하나의 모듈을 구성

12/70

2-2 순차적 응집

 순차적 응집sequential cohesion



[그림 6-4]처럼 A 요소의 출력을 B 요소의 입력으로 사용하므로 두 요소가 하나의 모듈을 

구성한 경우



두 요소가 아주 밀접하므로 하나의 모듈로 묶을 만한 충분한 이유가 된다

.

13/70

2-3 교환적 응집

 교환적 응집communication cohesion



정보적 응집



[그림 6-5]처럼 같은 입력을 사용하는 구성 요소들을 하나의 모듈로 구성



구성 요소들이 동일한 출력을 만들어낼 때도 교환적 응집



요소들 간의 순서는 중요하지 않다

.

14/70

2-4 절차적 응집

 절차적 응집procedural cohesion



[그림 6-6]처럼 순서가 정해진 몇 개의 구성 요소를 하나의 모듈로 구성



순차적 응집과 다른 점

: 어떤 구성 요소의 출력이 다음 구성 요소의 입력으로 사용되지 않고, 

순서에 따라 수행만 된다는 것

15/70

2-5 시간적 응집

 시간적 응집temporal cohesion



모듈 내 구성 요소들의 기능도 다르고

, 한 요소의 출력을 입력으로 사용하는 것도 아니고, 요소들 

간에 순서도 정해져 있지 않다

.

  But!



그 구성 요소들이 같은 시간대에 함께 실행된다는 이유로 하나의 모듈로 구성

16/70

2-6 논리적 응집

 논리적 응집logical cohesion



모듈 간 순서와 무관

, 한 모듈의 출력을 다른 모듈의 입력으로 사용하는 것도 아님

  But!



요소들 간에 공통점이 있거나 관련된 임무가 존재하거나 기능이 비슷하다는 이유로 하나의 

모듈로 구성

• 비슷한 기능

(입출력) : scanf( ), printf( )를 결합시킨 입출력 모듈

• 공통점

(덧셈) : 정수의 덧셈과 행렬의 덧셈을 결합시킨 덧셈 모듈

• 공통점

(출력) : 단말기 출력 기능과 파일 출력 기능을 결합시킨 출력 모듈

17/70

2-7 우연적 응집

 우연적 응집coincidental cohesion



구성 요소들이 말 그대로 우연히 모여 구성



특별한 이유 없이

, 크기가 커 몇 개의 모듈로 나누는 과정에서 우연히 같이 묶인 것

18/70

3. 결합도(1)

 좋은 관계와 나쁜 관계

19/70

3. 결합도(2)

 결합도coupling



모듈과 모듈 사이의 관계에서 관련 정도



하나의 모듈 안에서 구성 요소들 간에 똘똘 뭉쳐 있는 정도로 평가



좋은 설계

: loosely coupled

   ∵ 상호 의존성이 줄어 모듈의 독립성이 높아지고

, 모듈 간에 영향이 적기 때문

20/70

3-1 데이터 결합

 데이터 결합data coupling



가장 좋은 모듈 간 결합



모듈들이 매개변수를 통해 데이터만 주고받음으로써 서로 간섭을 최소화하는 관계



모듈 간의 독립성 보장



관계가 단순해 하나의 모듈을 변경했을 때 다른 모듈에 미치는 영향이 아주 적음

21/70

3-2 스탬프 결합

 스탬프 결합stamp coupling



두 모듈 사이에서 정보를 교환할 때 필요한 데이터만 주고받을 수 없고 스탬프처럼 필요 없는 

데이터까지 전체를 주고받아야 하는 경우



레코드나 배열 같은 데이터 구조

, C 언어의 구조체(struct)

22/70

3-3 제어 결합

 제어 결합control coupling



제어 플래그flag를 매개변수로 사용하여 간섭하는 관계



호출하는 모듈이 호출되는 모듈의 내부 구조를 잘 알고 논리적 흐름을 변경하는 관계



정보은닉을 크게 위배하는 결합으로

, 다른 모듈의 내부에 관여하여 관계가 복잡해진다.

23/70

3-4 공통 결합

 공통 결합common coupling



모듈들이 공통 변수

(전역변수)를 같이 사용하여 발생하는 관계



문제점

: 변수 값이 변하면 모든 모듈이 함께 영향을 받는다는 것

24/70

3-5 내용 결합

 내용 결합content coupling



모듈 간에 인터페이스를 사용하지 않고 직접 왔다 갔다 하는 경우의 관계



상대 모듈의 데이터를 직접 변경할 수 있어 서로 간섭을 가장 많이 하는 관계



C 언어의 goto 문

25/70

3-6 모듈 간의 좋은 관계

 바람직한 설계



모듈 간에는 꼭 필요한 데이터만 주고받도록 



적은 인터페이스의 수를 통한 약한 결합 유지



매개변수로 제어 플래그보다 데이터를 사용        유지보수 용이성 향상

낮은 결합도

!

높은 응집도

!

Section 02 소프트웨어 개발 방법과 

설계

27/70

1. 방법론이 만들어지는 과정

28/70

2. 프로세스 지향 방법(1)

 procedural approachprocess oriented approach



처리순서를 구조화하는 방법 



대표적인 모델 기법

: DFD(Data Flow Diagram)              

29/70

2. 프로세스 지향 방법(2)

 프로세스 지향 방법의 구성



기능이 중심

(우선)이 되고 그 기능을 수행하는 데 필요한 데이터가 참조되는 형태로 구성

30/70

2. 프로세스 지향 방법(3)

 프로세스 지향 방법의 특징



프로세스와 데이터의 분리



실세계를 컴퓨터 처리 방식으로 표현



함수 중심

(우선)으로 모듈 구성

31/70

3. 데이터 지향 방법

 데이터 지향 방법data oriented approach



시스템이 취급하는 데이터에 관심

, 즉 데이터가 중심(우선)이 되어 데이터를 구조화



대표적 소프트웨어 개발 방법론

: 정보공학 방법론



DB 설계를 위한 대표적 모델 표기법: E-REntity-Relationship 다이어그램

32/70

4. 프로세스 지향 방법과 데이터 지향 방법의 문제점

 변경이 미치는 영향이 큼



프로세스와 데이터를 각각 별개의 것으로 파악하기 때문

 프로그램의 복잡도 증가



함수와 데이터가 분리되어 있기 때문

 프로그램 변경 시 프로그램 구조 파악 필요



프로그래머는 프로그램의 구조와 영향을 미치는 곳도 파악해야 함

 재사용의 어려움



프로세스와 데이터가 분리된 구조 때문

33/70

5. 객체 지향 방법(1)

 객체지향 방법object-oriented approach



프로세스 지향 방법과 데이터 지향 방법의 문제점을 해결하기 위해 고안



기능이나 데이터 대신 객체가 중심이 되어 개발



데이터

(속성)를 가장 먼저 찾고 그 데이터를 조작하는 메서드(함수)를 찾아 그 둘을 객체라는 

이름으로 묶어 그 객체를 중심으로 모듈을 구성

34/70

5. 객체 지향 방법(2)

 객체지향 방법의 특징

• 실세계를 사람이 생각하는 방식으로 표현한다

. 

• 임의로 데이터에 접근할 수 없다

. 

• 시스템은 객체들의 모임이다 

• 요구 사항 변경에 유연하게 대처할 수 있다 

• 확장성과 재사용성이 높아진다

. 

• 추상화를 통해 생산성과 품질이 높아진다

Section 03 객체지향의 

주요 개념과 특징

36/70

1. 객체(1)

37/70

1. 객체(2)

 객체(object)



실세계에 존재하거나 생각할 수 있는 것들



사전에 나와 있는 명사뿐 아니라 동사의 명사형까지도 모두 객체



인간이 생각하고 표현할 수 있는 모든 것

38/70

1. 객체(3)

 관점에 따른 객체의 이해



모델링 관점 

: 객체는 명확한 의미를 담고 있는 대상 또는 개념



프로그래머 관점 

: 객체는 클래스에서 생성된 변수



소프트웨어 개발 관점 

: 객체는 ‘데이터+메서드’ 형태의 소프트웨어 모듈



객체지향 프로그래밍 관점 

: 객체는 속성attribute과 메서드method 용어로 구현

 개발 관점에서의 객체의 특성



식별자identity

 존재 : 객체를 구별하는 유일한 식별자를 갖는다.



상태state

 존재 : 자료구조에 해당하는 상태를 갖는다.



메서드 존재 

: 연산을 수행할 수 있는 행위에 해당하는, 잘 정의된 메서드를 갖는다.



클래스로 선언 및 사용 

: 객체는 비슷한 객체의 구조와 행위가 클래스로 선언되어 사용

39/70

2. 클래스(1)

 클래스



클래스class는 공통되는 것들을 묶어서 대표적인 이름을 붙인 것



클래스가 개념적이라면

, 객체는 구체적



데이터뿐 아니라 이 데이터에서 수행되는 메서드까지 포함해서 묶어놓은 것

40/70

2. 클래스(2)

 구조체



서로 연관된 자료들만 모아놓은 것

[구조체의 구성]
• struct : 구조체를 나타내는 예약어 

• student : 구조체 태그명 

• 구조체 멤버 

: name, korean, english, math, aver-

age

41/70

3. 인스턴스

 인스턴스instance



같은 클래스에 속하는 개개의 객체로

, 하나의 클래스에서 생성된 객체



클래스가 구체화되어

, 클래스에서 정의된 속성과 성질을 가진 실제적인 객체로 표현된 것



인스턴스화instantiation 

: 추상적인 개념인 클래스에서 실제 객체를 생성하는 것

42/70

4. 캡슐화(1)

 캡슐화encapsulation



사용자들에게 해당 객체의 기능

(서비스)과 사용법만 제공하고 내부는 감추어(변경할 수 없게 함) 

쉽게 사용할 수 있게 하는 개념



객체 내부에 서로 관련된 데이터와 그 데이터를 조작할 수 있는 메서드를 같이 포장하는 

방식으로 그 안에 포함된 메서드만 사용하여 데이터 값을 변경할 수 있는 구조

43/70

4. 캡슐화(2)

 캡슐화의 장점



데이터 보호



추상화 용이



제공자와 이용자를 명확히 분리



이용자에게 편리성 제공



사용법이 쉬움



변화에 대한 국지적 영향



객체 간의 독립성 보장



변경 용이성과 재사용성 증대

44/70

5. 정보은닉(1)

45/70

5. 정보은닉(2)

 정보은닉information hiding



외부

(다른 객체)에서 객체의 내부(데이터)를 들여다볼 수 없다는 개념



다른 객체가 한 객체 내의 데이터 값을 직접 참조하거나 접근할 수 없는 구조



인터페이스와 구현의 명확한 분리



각 모듈의 내부 항목에 관한 정보는 감추고

, 인터페이스를 통해서만 메시지를 전달



다른 모듈을 변경하지 못함



모듈 안의 자료구조와 메서드에 사용된 알고리즘은 외부에서 그 값을 직접 변경 못함



공개 인터페이스로 정의 된 메서드를 통해서만 접근 가능

46/70

5. 정보은닉(3)

 정보은닉의 표기 방법

47/70

5. 정보은닉(4)

 정보은닉의 특징



블랙박스 역할



인터페이스를 통한 접근



자료구조 변경이 용이

 정보은닉 개념 사용의 장점



독립성 향상



수정 용이



이해도 증진



확장성 증가

48/70

6. 상속(1)

 상속inheritance



뭔가를 물려받는다는 의미



상위 클래스super class의 모든 것을 하위 클래스sub class가 물려받아 내 것처럼 사용

49/70

6. 상속(2)

 상속의 장점



이해 용이



재사용성 증대



확장 용이



유지보수 용이



추상화 가능

50/70

7. 다형성(1)

 다형성polymorphism



‘여러 개의 형태를 갖는다’라는 의미의 그리스어에서 유래



poly(하나 이상), morph(형태)가 합성된 단어로 ‘하나 이상의 형태’를 뜻함

 다형성 예 1



다음 그림에서 공통점

: ‘타다’

51/70

7. 다형성(2)

 다형성 예 2



C 언어에서 + 기호는 다음 두 가지 용도로 사용된다.

• 연산자operator 

: 두 수를 더하는 연산자로, ‘3+5’ 형태로 사용

• 연결자concatenation 

: 문자열을 연결하는 역할을 하며 ‘go+stop’ 형태로 사용

 다형성 예 3



‘삼각형 면적을 계산한다’

, ‘사각형 면적을 계산한다’, ‘원 면적을 계산한다’의 공통점? 

         ‘면적을 계산한다’

 다형성 예 4



‘창문을 열다’

, ‘지갑을 열다’, ‘파일을 열다’, ‘은행 계좌를 열다’의 공통점: ‘열다’ 

52/70

7. 다형성(3)

 다형성



같은 이름의 메서드가 객체에 따라 다르게 동작하고

, 서로 다른 구현(코드)을 제공

 다형성 사용의 장점



쉬운 변경

(추가, 삭제), 확장 및 유지보수의 용이

53/70

7-1 메서드 오버로딩(1)

 메서드 오버로딩overloading



한 클래스에 이름이 동일한 메서드가 중복 정의되어 있는 경우



메서드명이 같은데 어떻게 구별할까

?          

          매개변수 타입이나 개수signature로 구별

54/70

7-1 메서드 오버로딩(2)

 연산자 오버로딩



연산자 하나를 다른 용도로 다시 중복 정의하여 사용하는 것

   (예) ‘3+5’, ‘go+stop’

 상속 구조에서의 메서드 오버로딩



상속 구조에서는 메서드명뿐아니라 매개변수의 타입과 개수까지 같다

. 구별 방법?

           상위 클래스

: 추상 클래스, 추상 클래스내의 메서드: 추상 메서드 

55/70

7-2 메서드 오버라이딩

 메서드 오버라이딩overriding



메서드 오버로딩

: 추상 클래스와 추상 메서드만 사용



메서드 오버라이딩

: 추상 클래스와 일반 클래스를 모두 다 사용



상위 클래스에서 정의한 일반 메서드의 구현을 하위 클래스에서 모두 무시하고 다시 재정의해서 

사용 가능         상위 클래스의 메서드는 은닉

(무시)되고, 하위 클래스의 메서드가 사용

Section 04 클래스 간의 관계와 

  설계 원칙

57/70

1. 연관 관계

 연관 관계association relationship



서로 알고 지내는 관계로

, 하나의 클래스가 또 다른 클래스를 인지하고 있음을 의미



두 클래스는 서로 메시지를 주고받으며 이용하는 관계



연관 관계

: 클래스 사이에서 발생, 링크(link): 객체 사이에서의 이용 관계

58/70

2. 일반화-특수화 관계

 일반화-특수화 관계(IS-A, generalization-specialization relationship)



두 클래스 간의 상속 관계



하위 클래스는 상위 클래스의 각 속성과 메서드를 모두 상속받아 사용 가능



하위 클래스

: 원래 가지고 있던 속성과 연산+물려받은 속성과 연산까지 모두 사용

59/70

3. 집합 관계

 집합 관계aggregation relationship



연관 관계를 더 구체적으로 나타낸 것



거대한 객체 하나를 소규모 객체 여러 개로 구성할 때 발생



전체와 부분 관계 성립



집합 관계에 속한 부분 객체는 다른 곳에서도 공유 가능

60/70

4. 포함 관계

 포함 관계composition relationship



전체 객체에 완전히 전속되어 독립된 객체로 존재할 수 없는 부분 객체가 존재하는 관계



포함 관계의 부분 객체들은 전체 객체가 없어지면 같이 없어짐

   (예) 잉크가 떨어진 볼펜의 볼펜심만 따로 갈지 못해 통째로 버려야 하는 경우

61/70

5. 클래스 설계 원칙

① 단일 책임 원칙

(SRP: Single-Responsibility Principle)

클래스를 변경해야 하는 이유는 오직 하나여야 한다

. 

② 개방 폐쇄의 원칙

(OCP: Open-Closed Principle)

확장

(상속)에는 열려 있어야 하고 변경에는 닫혀 있어야 한다. 

③ 리스코프 교체의 원칙

(LSP: Liskov Substitution Principle)

기반 클래스는 파생 클래스로 대체할 수 있어야 한다

. 

④ 의존 관계 역전의 원칙

(DIP: Dependency Inversion Principle)

클라이언트는 구체 클래스가 아닌 추상 클래스

(인터페이스)에 의존해야 한다. 

⑤ 인터페이스 분리의 원칙

(ISP: Interface Segregation Principle)

하나의 일반적인 인터페이스보다는 구 체적인 여러 개의 인터페이스가 낫다

. 

62/70

5-1 단일 책임 원칙

 클래스를 변경해야 하는 이유는 단 하나여야 한다



좋은 설계

: 모듈의 응집도를 높이고, 결합도를 낮추는 설계



단일 책임 원칙

: ‘클래스는 한 가지 책임(기능)만 갖도록 설계하자’



만일 클래스에 두 개의 책임

(기능)이 존재한다면: 두 개의 클래스로 분리하여 변경

63/70

 확장(상속)에는 열려 있어야 하고 변경에는 닫혀 있어야 한다



개방 폐쇄의 원칙을 지키지 않고 설계하면 어떻게 될까

? 

         이는 하위 클래스의 특정 기능을 상위 클래스에서 미리 구현하는 것과 같다

.

         이 기능이 필요 없는 다른 하위 클래스에서 강제로 상속받아야 하는 경우가 발생



‘변경에는 닫혀 있어야 한다’

? 

         특정 하위 클래스가 상위 클래스에 있는 공통의 기본 기능을 변경 및 간섭 금지

         ‘자유로운 상속을 통한 확장과 재사용성’을 추구하기 위한 원칙

자유롭게 상속하려면

5-2 개방 폐쇄의 원칙(1)

추상 클래스와 구체 클래스를 분리

추상 클래스와 구체 클래스를 분

64/70

5-2 개방 폐쇄의 원칙(2)

 확장(상속)에는 열려 있어야 하고 변경에는 닫혀 있어야 한다



개방 폐쇄의 원칙

: ‘클래스를 확장은 쉽게, 변경은 어렵게 설계하자’는 것

   (예) ‘개방-확장은 쉽게’: 휴대폰, ‘폐쇄-변경은 어렵게’: 휴대폰 충전기

                 휴대폰 기종은 바뀌어도 충전기 인테페이스만 같으면 충전기 계속 사용 가능

인터페이스는 자주 바뀌면 안 되고

(폐쇄), 그 안은 얼마든지 확장할 수 있는 구조

가능한 방법

?

상속

상

65/70

5-2 개방 폐쇄의 원칙(3)

 개방 폐쇄의 원칙 



변경이 필요한 경우 기존 코드 변경 없이 상속과 확장을 통해 변경 



변경 시 영향 축소를 위해 중간에 추상 클래스

-인터페이스 같은 완충 장치를 두는 것  

66/70

5-3 리스코프 교체의 원칙

 기반 클래스는 파생 클래스로 대체할 수 있어야 한다



기반 클래스가 들어갈 자리에 파생 클래스를 넣어도 문제없이 잘 작동함을 의미

   (예) 문서편집기: 구버전에서 작업한 내용을 신버전에서도 계속 사용할 수 있도록 설계



 서브 타입

(상속받은 하위 클래스-신버전)은 어디에서나 자신의 기반타입(상위 클래스-구버전)

으로 교체할 수 있어야 함을 의미

 클래스 설계에서 이 원칙이 중요한 이유?



파생 클래스

(신버전)에서 기반 클래스의 모든 메서드(구버전)를 지원하지 않으면 상속의 기본인 

IS-A 관계가 성립이 안 되기 때문   

67/70

5-4 의존 관계 역전의 원칙

 클라이언트는 구체 클래스가 아닌 추상 클래스(인터페이스)에 의존해야 한다



상속개념을 적용할 때 구체 클래스에서 상속을 받는 구조로 설계하지 말라는 것

이유

?

구체 클래스는 추상 클래스

(인터페이스)보다 변하기 쉽기 때문

구체 클래스는 추상 클래스

(인터페이스)보다 변하기 쉽기 때

68/70

5-5 인터페이스 분리의 원칙(1)

 하나의 일반적인 인터페이스보다는 구체적인 여러 개의 인터페이스가 낫다



‘클라이언트는 자신이 사용하지 않는 메서드와 의존 관계를 맺으면 안 된다’

 인터페이스를 분리하면?

          시스템 확장 시 변화의 폭을 필요한 기능에 대한 변경이나 확장으로 제한 가능

          많은 메서드로 인한 가독성 및 높은 결합도의 문제 해결

각 클라이언트에 맞는 인터페이스만 분리

각 클라이언트에 맞는 인터페이스만 분

※ 클래스 분리 아님

69/70

5-5 인터페이스 분리의 원칙(2)

 하나의 일반적인 인터페이스보다는 구체적인 여러 개의 인터페이스가 낫다

Thank You