정보처리기사 필기 요약 1과목 소프트웨어 설계 - 3장 애플리케이션 설계

SECTION 021 소프트웨어 아키텍처

(1) 소프트웨어 아키텍처의 설계

소프트웨어의 골격이 되는 기본 구조, 관계를 표현하는 시스템의 구조 또는 구조체

소프트웨어 개발 시 적용되는 원칙과 지침, 이해 관계자들의 의사소통 도구

(2) 모듈화(Modularity)

모듈화(한가지 기능)는 시스템의 기능들을 모듈 단위로 나누는 것을 의미한다.

(3) 추상화(Abstraction)

(5) 정보 은닉

캡슐화. 결합도는 약하게, 응집도는 강하게

 

SECTION 022 아키텍처 패턴

(1) 아키텍처 패턴(Patterns)의 개요

아키텍처 패턴의 장점

시행착오를 줄여 개발 시간을 단축, 고품질의 소프트웨어 생산

검증된 구조, 안정적인 개발

이해관계자들이 공통된 아키텍처를 공유, 의사소통이 간편

손쉽게 유지보수 수행

시스템의 특성을 개발 전에 예측

(2) 레이어 패턴(Layers pattern)

계층(Layer)으로 구분하여 구성하는 고전적인 방법

레이어 패턴은 각각의 서브시스템들이 계층 구조를 이루며, 상위 계층은 하위 계층에 대한 서비스 제공자

ex) OSI 7 Layger : 물>데>네>전>세>표>응, 하위 계층 : 1~3, 상위 계층 : 4~7

(3) 클라이언트-서버 패턴(Client-Server Pattern)

클라이언트-서버 패턴은 하나의 서버 컴포넌트와 다수의 클라이언트 컴포넌트로 구성되는 패턴

서버는 클라이언트의 요청에 대비해 대기 상태를 유지

클라이언트나 서버는 요청과 응답을 받기 위해 동기화되는 경우를 제외하고는 서로 독립적

(4) 파이프-필터 패턴(Pipe-Filter Pattern)

데이터 스트림 절차의 각 단계를 필터(Filter) 컴포넌트로 캡슐화 하여 파이프를 통해 데이터를 전송

재사용성이 좋고, 확장이 용이

1. 데이터 변환 2. 버퍼링 3. 동기화 등에 주로 사용

ex) 유튜브

(5) 모델-뷰-컨트롤러 패턴(Model-View-Control Pattern)

뷰(View) : 사용자에게 정보를 표시

여러 개의 뷰를 만들 수 있다.

(6) 기타 패턴

마스터 슬레이브 패턴(Master-Slave Pattern) : 마스터 슬레이브에서 슬레이브 컴포넌트로 작업을 분할, 슬레이브 컴포넌트에서 처리된 결과물을 다시 돌려받는다. 병렬 컴퓨팅 시스템에서 주로 활용된다.

피어-투-피어 패턴(Peer-To-Peer Pattern) : 피어를 하나의 컴포넌트로 간주, 서비스를 호출하는 클라이언트가 될 수도, 서비스를 제공하는 서버가 될 수도 있는 패턴

 

SECTION 023 객체지향(Object-Oriented)

(2) 객체(Object)

속성 + 메소드(행위)

데이터	객체가 가지고 있는 정보 속성이나 상태
함수	객체가 갖는 데이터(속성, 상태)를 처리하는 알고리즘 메소드, 서비스, 동작, 연산이라고 한다.

독립적으로 식별 가능한 이름을 가지고 있다.

객체가 가질 수 있는 조건을 상태(State)라고 하는데 일반적으로 상태는 시간에 따라 변한다.

(3) 클래스(Class)

공통된 속성과 연산(행위)을 갖는 객체의 집합

클래스가 속한 각각의 객체를 인스턴스(Instance)라 하며, 클래스로부터 새로운 객체를 생성하는 것을 인스턴스화(Instantiation)라고 한다.

(4) 캡슐화(Encapsulation)

모듈화

캡슐화된 객체는 인터페이스를 제외한 세부 내용이 은폐(정보 은닉)되어 외부에서의 접근이 제한적 외부 모듈의 변경으로 인한 파급 효과가 적다.

재사용이 용이하다.

인터페이스가 단순해지고 객체 간의 결합도가 낮아진다(느슨한 결합).

(5) 상속(Inheritance)

이미 정의된 상위 클래스의 모든 속성과 연산을 하위 클래스가 물려받는 것.

하위 클래스는 상위 클래스로부터 상속받은 속성과 연산 외에 새로운 속성과 연산을 첨가하여 사용할 수 있다.

 

SECTION 024 객체지향 분석 및 설계

(1) 객체지향 분석의 개념

(2) 객체지향 분석의 방법론

Rumbaugh(럼바우) 방법 : 가장 일반적으로 사용되는 방법으로 분석 활동을 객체 모델, 동적 모델, 기능 모델로 나누어 수행하는 방법이다.

Coad와 Yourdon 방법 : E-R 다이어그램을 사용하여 객체의 행위를 모델링하며, 연산과 메시지 연결 정의 등의 과정으로 구성

(3) 럼바우(Rumbaugha)의 분석 기법

럼바우의 분석 기법

객체 모델링 -> 동적 모델링 -> 기능 모델링

객체 모델링	정보 모델링이라고도 하며, 객체 다이어그램으로 표시
동적 모델링	상태 다이어그램
기능 모델링	자료 흐름도(DFD)

(4) 객체지향 설계 원칙

리스코프 치환 원칙 (LSP, Liskov Substitution Principle)	하위 클래스는 최소한 자신의 상위 클래스에서 가능한 행위는 수행할 수 있어야 한다는 설계 원칙.
인터페이스 분리 원칙(ISP, Interface Segregation Principle)	자신이 사용하지 않는 인터페이스와 의존 관계를 맺거나 영향을 받지 않아야 한다는 원칙.

 

SECTION 025 모듈

(2) 결합도(Coupling)

연관 관계를 의미한다.

약할수록 품질이 높고, 강할수록 품질이 낮다.

종류

내용 결합도 > 공통 결합도 > 외부 결합도 > 제어 결합도 > 스탬프 결합도 > 자료 결합도

내공외제스자

내용 결합도 : 한 모듈이 다른 모듈의 내부 기능 및 그 내부 자료를 직접 참조하거나 수정

공통(공유) 결합도 : 공통 데이터 영역을 여러 모듈이 사용할 때 결합도

외부 결합도 : 어떤 모듈에서 선언한 데이터(변수)를 외부의 다른 모듈에서 참조할 때의 결합도

제어 결합도 : 어떤 모듈이 다른 모듈 내부의 논리적인 흐름을 제어

스탬프(검인) 결합도 : 모듈 간의 인터페이스로 배열이나 레코드 등의 자료 구조가 전달될 때의 결합도

자료 결합도 : 자료 요소로만 구성될 때의 결합도이다.

(3) 응집도(Cohesion)

정보 응집 개념을 확장, 내부 요소들의 서로 관련되어 있는 정도

응집도가 강할수록 품질이 높고, 약할 수록 품질이 낮다.

우논시절통순기

우연적 응집도(Coincidental Cohesion)	서로 관련 없는 요소로만 구성
논리적 응집도(Logical Cohesion)	유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소
시간적 응집도(Temporal Cohesion)	특정 시간에 처림되는 몇 개의 기능을 모아 하나의 모듈로 작성할 경우의 응집도
절차적 응집도(Procedural Cohesion)	순차적으로 수행할 경우의 응집도
교환(통신)적 응집도(Communication Cohesion)	동일한 입력과 출력을 사용
순차적 응집도(Sequential Cohesion)	모듈 내 하나의 활동으로부터 나온 출력 데이터를 그 다음 활동의 입력 데이터로 사용할 경우의 응집도
기능적 응집도(Fuctional Cohesion)	모듈 내부의 모든 기능 요소들이 단일 문제와 연관되어 수행될 경우의 응집도

(4) 팬인(Fan-In)/팬아웃(Fan-Out)

팬인 :  어떤 모듈을 제어(호출)하는 모듈의 수를 나타낸다.

팬아웃 : 어떤 모듈에 의해 제어(호출)되는 모듈의 수를 나타낸다.

 

SECTION 026 공통 모듈

(1) 공통 모듈의 개요

공통 모듈은 여러 프로그램에서 공통적으로 사용할 수 있는 모듈을 의미한다.

정확성, 명확성, 완전성, 일관성, 추적성

clean code <-----> alien code

(2) 재사용(Reuse)

함수와 객체	클래스나 메소드 단위의 소스 코드를 재사용한다.
컴포넌트	컴포넌트 자체에 대한 수정 없이 인터페이스를 통해 통신하는 방식으로 재사용
애플리케이션	공통된 기능들을 제공하는 애플리케이션을 공유하는 방식으로 재사용

(3) 효과적인 모듈 설계 방안

모듈의 독립성(종속성X, 의존성X)과 재사용성을 높인다.

중복성을 줄이고 일관성을 유지

지나치게 제한적이어는 안 된다.

모듈 크기는 이해하기 쉬운 크기로 분해한다.

 

SECTION 027 코드

(2) 코드의 종류

순차 코드(Sequence Code)	순서 코드 또는 일련번호 코드 ex) 1, 2, 3, 4......
블록 코드(Block Code)	구분 코드 ex) 1001~1100 : 총무부, 1101~1200 : 영업부
10진 코드(Decimal Code)	도서 분류식 코드 1000 : 공학, 1100 : 소프트웨어 고학, 1110 : 소프트웨어 설계
표의 숫자 코드(Significant Digit Code)	넓이, 부피, 지름 ex) 120-720-1500 : 두께x폭x길이가 120x720x1500인 강판

 

SECTION 028 디자인 패턴

(1) 디자인 패턴(Design Pattern)의 개요

모듈의 세분화된 역활이나 모듈들 간의 인터페이스와 같은 코드를 작성하는 수준의 세부적인 구현 방안을 설계할때 참조할 수 있는 전형적인 해결 방식 또는 예제.

디자인 패턴은 문제 및 배경, 실제 적용된 사례, 재사용이 가능한 샘플 코드
'바퀴를 다시 발명하지 마라'

GoF의 디자인 패턴은 수많은 디자인 패턴들 주 가장 일반적인 사례에 적용될 수 있는 패턴들을 분류하여 정리

생성 패턴 구조 패턴 행위 패턴

(2) 디자인 패턴 사용의 장*단점

객체지향 설계에 적합하다. <-----> 구조적/절차적 프로그램(c언어)

투자 비용이 부담될 수 있다.

개발자 간의 원할한 의사소통이 가능하다.

요청에 대한 유연한 대처가 가능하다.

설계와 구현을 다루므로 다른 기반의 애플리케이션 개발에는 적합하지 않다.

(3) 생성 패턴(Creational Pattern)

생성과 참조 과정을 캡슐화 하여 객체가 생성되거나 변경되어 프로그램의 구조에 영향을 크게 받지 않도록 하여 프로그램에 유연성을 더해준다.

추상 팩토리, 빌더, 팩토리 메소드, 프로토타입, 싱글톤

(4) 구조 패턴(Structural Pattern)

클래스나 객체들을 조합하여 큰 구조로 만든다.

어댑터(Adapter) : 호환성이 없는 클래스들의 인터페이스를 다른 클래스가 이용할 수 있도록 변환 해주는 패턴이다.

(5) 행위 패턴(Behavioral Pattern)

상호작용하는 방법이안 책임 분배 방법을 정의하는 패턴으로 총 11개의 패턴이 있다.

책임 연쇄(Chain of Responsibility), 커맨드(Command), 인터프리터(Interreter) : SQL이나 통신 프로토콜과 같은 것을 개발할 때 사용한다., 반복자(Iterator), 중재자(Mediator), 메멘토(Memento), 옵서버(Observer) : 한 객체의 상태가 변화하면 객체들에게 변화된 상태를 전달, 상태(State), 전략(Strategy), 템플릿 메소드(Template Method), 방문자(Visitor)