본문 바로가기

정보처리기사/I. 소프트웨어 설계

I. 소프트웨어 설계 - 어플리케이션 설계 (2)

(1) 객체지향

 1. 객체지향(Object Oriented) 개념

 - 개체를 속성과 메서드가 결합된 형태의 객체로 표현하는 개념

 

 2. 객체지향 구성요소

구성요소 설명
클래스 (Class) - 같은 종류의 집단에 속하는 속성과 행위를 정의
- 속성은 변수의 형태로, 행위는 메소드의 형태로 선언
- 객체지향 프로그램의 기본적인 사용자 정의 데이터형
객체 (Object) - 객체의 행위는 클래스에 정의된 행위에 대한 정의를 공유함으로서 메모리를 경제적으로 사용
- 객체마다 각각의 상태와 식별성을 가짐
메서드 (Method) - 클래스로부터 생성된 객체를 사용하는 방법
- 전통적 시스템의 함수 (Function) 또는 프로시저 (Procedure)에 해당하는 연산 기능
메시지 (Message) - 객체에 어떤 행위를 하도록 지시하기 위한 방법
인스턴스 (Instance) - 객체지향 기법에서 클래스에 속한 각각의 객체
- 실제로 메모리상에 할당
속성 (Property) - 한 클래스 내에 속한 객체들이 가지고 있는 데이터 값들을 단위별로 정의
- 성질, 분류, 식별, 수량, 현재 상태 등에 대한 표현 값

 

 3. 객체지향 기법

기법 설명
캡슐화 (Encapsulation) - 관련성이 많은 데이터와 함수들을 한 묶음으로 처리하는 기법
- 결합도가 낮아지고 재사용이 용이
- 변경 발생 시 오류의 파급효과가 적다
- 인터페이스가 단순화 됨
상속성 (Inheritance) - 상위 클래스의 속성과 메소드를 하위클래스에서 물려받아 사용하는 기법
다형성 (Polymorphism) - 하나의 메시지에 대해 각 객체가 가지고 있는 방법으로 응답할 수 있는 능력
- 오버로딩, 오버라이딩
추상화 (abstraction) - 공통 성질을 추출하여 추상 클래스를 설정하는 기법
- 기능 추상화, 자료 추상화, 제어 추상화
정보은닉 (Information Hiding) - 코드 내부 데이터와 메소드를 숨시고 공개 인터페이스를 통해서만 접근이 가능하도록 하는 코드 보안 기술
- 고려되지 않은 영향들을 최소화 하기 위하여 사용

 4. 객체지향 설계 원칙(SOLID)

원칙 설명
단일 책임의 원칙 - Single Responsibility Principle
- 하나의 클래스는 하나의 목적을 위해서 생성되며 클래스가 제공하는 모든 서비스는 하나의 책임을 수행하는데 집중 되어야 한다
- 나머지 4개의 원칙의 기초 원칙
개방 폐쇄 원칙 - Open Close Principle
- 소프트웨어의 구성요소 (컴포넌트, 클래스, 모듈, 함수)는 확장에는 열려있고, 변경에는 닫혀있어야한다
리스코프 치환의 원칙 - Liskov Substitution
- 자식 클래스는 언제나 부모클래스를 대체한다
인터페이스 분리의 원칙 - Interface Segregation Principle
- 한 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다
의존성 역전의 원칙 - Dependency Inversion principle
- 실제 사용 관계는 바뀌지 않으며, 추상을 매개로 메시지를 주고 받음으로써 관계를 최대한 느슨하게 만드는 원칙

* 오버로딩 (Overloading) vs 오버라이딩 (Overriding)

오버로딩 오버라이딩
void fn(int a);
void fn(char a);
void fn(int a, int b);

class A{
   void fn(int a);
}
class B : public A{
   void fn(int a);
}
매개 변수의 유형과 개수가 다르게 하여 같은 이름의 메소드를
여러개 가지는 기법
B 클래스는 A클래스를 상속 상위 클래스가 가지고 있는 메소드를
하위클래스가 재정의해서 사용하는 기법

 

 5. 객체지향 방법론 종류

종류 설명 특징
OOSE - Object Oriented Software Engineering
- 유스케이스에 의한 접근 방법으로 유스케이스를 모든 모델의 근간으로 활용
- 분석, 설계, 구현 단계로 구성
- 기능적 요구사항 중심의 시스템
OMT - Object Modeling Technology
- 객체지향 분석, 시스템 설계, 오브젝트 설계 및 구현의 4단계로 구성
 객체 모델링 : 정적 구조 표현
 동적 모델링 : 제어 흐름/상호 반응 표현
 기능 모델링 : 데이터 값의 변화 과정 표현
- 복잡한 대형 프로젝트에 유용
- 기업 업무의 모델링 편리 및 사용자와 의사소통 편리
Booch - OOD(Object Oriented Design)로 설계부분만 존재
- 설계 문서화를 강조하여 다이어그램 중심으로 개발하는 방법론
- 분석과 설계 분리 불가능
- 분석하는 데 이용된 객체 모델의 설계시 적용

 

(2) 디자인 패턴

 1. 디자인 패턴 (Design Pattern) 개념

  - 반복적으로 나타나는 문제점들에 대해 전문가들의 경험을 정리하여 해결 방안을 제시한 패턴

  - 디자인 패턴을 참고할경우 개발의 효율성, 유지보수성, 운용성, 프로그램 최적화에 도움이 됨

 

 2. 디자인 패턴 구성요소

구성요소 설명
패턴 이름 설계 의도 표현할 수 있도록 문제와 해법을 설명
문제 해결하고자 하는 문제와 배경, 패턴 사용 시점을 서술
해법 패턴을 구성하는 요소, 요소 간의 관계, 책임, 상호관계를 서술
결과 패턴을 적용해서 얻은 결과와 장단점을 서술 

 

  3. 디자인 패턴 유형

구분 유형 설명
목적 생성 객체 인스턴스 생성에 관여, 클래스 정의와 객체 생성 방식을 구조화, 캡슐화를 수행하는 패턴
구조 더 큰 구조 형성 목적으로 클래스나 객체의 조합을 다루는 패턴
행위 클래스나 객체들이 상호작용하는 방법과 역할 분담을 다루는 패턴
범위 클래스 클래스 간 관련성 즉, 상속 관계를 다루는 패턴
*컴파일 타임에 정적으로 결정
객체 객체 간 관련성을 다루는 패턴
*런타임에 동적으로 결정

*컴파일 타임 (Compile Time) : 컴파일 과정을 통해 기계어로 변환되어 실행 가능한 프로그램이 되는 과정 (정적 메모리 할당)

*런타임 (Run Time) : 컴파일 과정을 마친 프로그램은 사용자에 의해 실행되며 이러한 프로그램이 실행되는 과정 (동적 메모리 할당)

 

 4. 디자인 패턴 종류

 

유형 패턴 설명
생성 패턴 Factory Method 서브 클래스가 인스턴스를 결정하도록 하고 책임을 위임하는 패턴
Singleton 유일한 하나의 인스턴스를 보장하도록 하는 패턴
구조 패턴 Facade 하나의 인터페이스를 통해 느슨한 결합을 제공하는 패턴
Proxy 하나의 인터페이스를 통해 느슨한 결합을 제공하는 패턴
행위 패턴 Template 알고리즘 골격의 구조를 정의한 패턴
Command 요청 자체를 캡슐화하여 파라미터로 넘기는 패턴
Observer 상태가 변할 때 의존자들에게 알리고, 자동 업데이트하는 패턴