2021 #정보처리기사 필기요약 #1-3. 애플리케이션 설계

728x90

2021년 NCS기반 정처기 필기입니다. 이기적2020과 수제비2021 수험서를 함께 보고 공부한 기록입니다.

제 1과목 소프트웨어 설계 > 애플리케이션 설계

(1) 공통 모듈 설계

모듈(Module)의 개념

모듈은 크게 독립된 하나의 소프트웨어 또는 하드웨어 단위를 지칭하는 용어이다.

모듈화를 통해 분리된 시스템의 기능

서브 프로그램
서브 루틴
소프트웨어 내의 단위 프로그램
작업 단위

모듈의 특징

각각의 모듈은 상대적으로 독립성을 가지고 있다.
모듈은 단독으로 컴파일할 수 있으며, 재사용할 수 있다.
독립성이 높은 모율일수록 수정 시 다른 모듈에 영향을 거의 미치지 않고, 오류 발생 시 쉽게 해결할 수 있다.
모듈의 독립성은 결합도와 응집도에 의해 측정된다.
모듈의 독립성을 높이는 방법
- 모듈의 결합도는 약하게(낮게)
- 응집도는 강하게(높게)
- 모듈의 크기는 작게 만든다.

공통 모듈의 개념

전체 프로그램 기능 중 특정 기능을 처리할 수 있는 실행 코드를 의미한다.
자체적으로 컴파일이 가능하다.
다른 프로그램에서 재사용이 가능하다.

공통 모듈 원칙 (정명 완일추)

공통 모듈에 대한 명세를 작성할 때에는 다음의 원칙을 지킨다.

정확성 (Correctness)
명확성 (Clarity)
완전성 (Completeness)
일관성 (Consistency)
추적성 (Traceability)

모듈화(Modularity)

소프트웨어의 성능을 향상시키거나 복잡한 시스템의 수정, 재사용, 유지 관리 등이 용이하도록 기능 단위의 모듈로 분해하는 설계 및 구현 기법이다.

기법	설명
루틴 (Routine)	소프트웨어에서 특정 동작을 수행하는 일련의 코드로 기능을 가진 명령들의 모임
루틴 (Routine)	메인 추틴과 서브 루틴으로 나뉨
메인 루틴 (Main Routine)	프로그램의 주요한 부분이며, 전체의 개략적인 동작 절차를 표시하도록 만들어진 루틴.
메인 루틴 (Main Routine)	메인 루틴은 서브 루틴을 호출
서브 루틴 (Subroutine)	메인 루틴에 의해 필요할 때마다 호출되는 루틴

바람직한 모율 설계 방안

모듈의 독립성과 재사용성을 높이기 위하여 결합도는 낮추고 응집도는 높인다.
모듈의 복잡도와 중복성을 줄이고 일관성을 유지한다.
모듈의 기능은 예측이 가능해야 하며, 지나치게 제한적이어서는 안된다.
적당한 모듈의 크기를 유지한다.
모듈 간의 효과적인 제어를 위해 설계에서 계층적 자료 조직이 제시되어야 한다.
유지보수가 용이해야 한다.

팬인(Fan-In) 및 팬아웃(Fan-Out)

소프트웨어의 구성요소인 모듈을 계층적으로 분석하기 위해서 팬인, 팬아웃을 활용한다.
팬인과 팬아웃 분석을 통하여 시스템의 복잡도를 측정할 수 있다.

구분	팬인(Fan-In)	팬아웃(Fan-Out)
개념	어떤 모듈을 제어(호출)하는 모듈의 수	어떤 모듈에 의해 제어(호출)되는 모듈의 수
모듈 숫자 계산	모듈 자신을 기준으로 모듈에 들어오면 팬인(in)	모듈 자신을 기준으로 모듈에서 나가면 팬아웃(out)
고려 사항	팬인이 높으면 재사용 측면에서 설계가 잘되었지만, 단일 장애점 발생 가능	팬아웃이 높을 경우는 불필요한 모듈 호출 여부 검토 필요
고려 사항	팬인이 높으면 관리 비용 및 테스트 비용 증가	팬아웃이 높을 경우는 단순화 여부 검토 필요

팬인(Fan-In) 및 팬아웃(Fan-Out) 계산 방법

팬인(Fan-In)	모듈 자신을 기준으로 모듈에 들어오면 팬인(in)
팬아웃(Fan-out)	모듈 자신을 기준으로 모듈에서 나가면 팬아웃(out)

설계 모델링

설계 모델링은 요구사항 분석 단계에서 규명된 필수 기능들의 구체적인 구현 방법을 명시하는 기법이다.
소프트웨어에 요구되는 기능과 성능 조건들을 만족하는 소프트웨어의 내부 기능, 구조 및 동적 행위들을 모델링하여 표현, 분석, 검증하는 과정이다.

설계 모델링 원칙

소프트웨어 설계는 변경이 쉽도록 구조화되어야 한다.
하나의 함수 안에 특정 기능을 수행하는 데 필요한 자료만 사용하도록 규제한다.
독립적이고 기능적인 특성을 지닌 모듈 단위로 분할 설계한다.
계층적 구조를 가져야 한다.

설계모델링 유형

구조 모델링
행위 모델링

소프트웨어 설계 유형

상위 설계 : 자료 구조 설계 / 아키텍처 설계 / 인터페이스 설계 / 프로시저 설계 [2020년 4회]
하위 설계 : 모듈 설계

설계 유형	설명
자료 구조 설계 (Data Structure Design)	요구 분석 단계에서 생성된 정보를 바탕으로 소프트웨어를 구현하는데 필요한 자료 구조로 변환하는 과정
아키텍처 설계 (Architecture Design)	예비 설계 또는 상위 수준 설계
	소프트웨어 시스템의 전체 구조를 기술
	소프트웨어를 구성하는 컴포넌트 간의 관계를 정의
인터페이스 설계 (Interface Design)	소프트웨어와 상호작용하는 컴퓨터 시스템, 사용자 등이 어떻게 통신하는지를 기술
프로시저 설계 (Procedure Design)	프로그램 아키텍처의 컴포넌트를 소프트웨어 컴포넌트의 *프로시저 서술로 변환하는 과정
협약에 의한 설계 (Design by Contract)	클래스에 대한 여러 가정을 공유하도록 명세한 설계
	소프트웨어 컴포넌트에 대한 정확한 인터페이스 명세를 위하여 선행조건, 불변조건을 나타내는 설계 방법
	선행조건(Precondition) : 컴포넌트의 오퍼레이션 사용 전에 참이 되어야 할 조건 결과조건(Postcondition) : 사용 후 만족되어야 할 조건 불면조건(Invariant) : 오퍼레이션이 실행되는 동안 항상 만족되어야 할 조건

*프로시저(Procedure) : 프로그램을 기능에 따라 여러 개의 단위로 분해하여 작성하는 것 (서브/함수 프로시저)

코드 설계

코드 설계는 데이터의 분류나 조합을 쉽게 하기 위하여 사물을 표현하는 코드를 설계하는 기법이다.

코드의 기능

표준화, 분류, 식별, 배열, 간소화, 연상, 암호화, 오류 검출

코드 설계 종류

종류	설명
연상 코드 (Mnemonic)	코드만 보고 대상을 연상할 수 있도록 명칭 일부를 약호(간단하고 알기 쉽게 나타내어 만든 부호) 형태로 넣어 구성된 코드 ex) 나라 이름 (한국: KR, 미국: US, ...)
블록 코드 (Block Code)	공통성이 있는 것끼리 블록으로 구분하고, 각 블록 내에서 일련번호를 부여하는 코드 ex) 전화번호 (지역번호-국번-일련번호 조합에서 지역번호-국번은 같은 지역끼리 공통)
순차 코드 (Sequence Code)	일정한 기준에 따라 순서대로 일련번호를 부여한 코드 [2020년 1회] ex) 가나다순으로 1번, 2번, ...
표의 숫자 코드 (Significant Digit Code)	대상 자료의 물리적인 수치인 길이, 넓이, 용량 등을 표시한 코드 [2020년 4회] ex) 20-10-300 (길이-넓이-용량 조합)
10진 코드 (Decimal Code)	10진수 형태로 표현한 코드 ex) 상품 바코드 (880 ...)
그룹 분류식 코드 (Group Classification Code)	대상을 기준에 따라 대분류, 중분류, 소분류로 구분하여 번호를 부여한 코드 ex) 학번 (입학년도-일련번호 조합)

코드 설계 절차

코드화 항목 선정 → 코드화 목적 설정 → 코드화 대상 확인 →코드화 범위 설정 → 코드 사용 기간 설정 → 코드화 항목의 특성 분석 →코드화방식결정 → 문서화

코드 오류 종류

사본 오류, 전위 오류, 생략 오류, 첨가 오류, 이중 전위 오류

HIPO (Hierarchy Input Process Output)

시스템의 분석 및 설계, 문서화할 때 사용된다.
하향식 소프트웨어 개발을 위한 문서화 도구이다.

HIPO 특징

체계적인 문서 관리가 가능하다.
기호, 도표 등을 사용해서 보기 쉽고 이해하기 쉽다.
기능과 자료의 의존 관계를 동시에 표현할 수 있다.
변경, 유지보수가 용이하다.
시스템의 기능을 고유 모듈들로 분할하여 이들 간의 인터페이스를 계층구조로 표현한 것을 HIPO 차트(Chart)라고 한다.

HIPO 차트 종류 (가총세)

종류	설명
가시적 도표 (Visual Table of Contents)	시스템의 전체적인 기능과 흐름을 보여주는 계층구조도
총체적 도표 (Overview Diagram)	입력, 처리, 출력에 대한 정보를 제공하는 도표
총체적 도표 (Overview Diagram)	프로그램을 구성하는 기능을 기술
세부적 도표 (Detail Diagram)	총체적 도표에 표시된 기능을 구성하는 기본 요소들을 상세히 기술하는 도표

소프트웨어 아키텍처 (Software Architecture)

소프트웨어를 설계하고 전개하기 위한 지침과 원칙이다.

소프트웨어 아키텍처 프레임워크 (Software Architecture Framework)

소프트웨어 집약적인 시스템에서 아키텍처가 표현해야 하는 내용 및 관계를 제공하는 아키텍처 기술 표준이다.
소프트웨어 아키텍처 프레임워크의 국제표준은 IEEE1471이다.
- 1...* : 1개이거나 더 많음(*)
- 0..1 : 0개이거나 1개

소프트웨어 아키텍처 프레임워크 구성요소

아키텍처 명세서 (Architectural Description)	이해관계자 (Stakeholder)	관심사 (Concerns)
관점 (Viewpoint)	뷰 (View)	근거 (Rationale)
목표 (Mission)	환경 (Environment)	시스템 (System)

소프트웨어 아키텍처 4+1 뷰 (유논프구배)

1: 유스케이스 뷰
- 사용자, 설계자, 개발자, 테스트 관점
4: 논리 뷰 / 구현 뷰 / 프로세스 뷰 / 배포 뷰
- 논리 뷰(Logical View): 설계자, 개발자 관점
- 프로세스 뷰(Process View): 개발자, 시스템 통합자 관점

소프트웨어 아키텍처 비용 평가 모델 (SACAA(사카))

평가 모델 종류	설명
SAAM (Software Architecture Analysis Method)	변경 용이성, 기능 집중, 평가 용이
ATAM (Architecture Trade-off Analysis Method)	아키텍처 품질 속성 만족 여부 판단, 이해 관계 평가
CBAM (Cost Benefit Analysis Method)	ATAM바탕 분석, 경제적 의사결정 요구 충족
ADR (Active Design Review)	아키텍처 구성요소 간 응집도 평가
ARID (Active Reviews for Intermediate Designs)	특정 부분에 대한 품질요소 집중

소프트웨어 아키텍처 패턴(Software Architecture Pattern)

아키텍처 패턴이란 주어진 상황에서의 소프트웨어 아키텍쳐에서 일반적으로 발생하는 문제점들에 대한 일반화되고 재사용 가능한 솔루션이다.

소프트웨어 아키텍처 패턴의 필요성

고객 요구사항을 만족시키고, 소프트웨어 개발 생산성과 품질 확보 가능
개발에 대한 시행착오를 줄여 개발 시간을 단축하고, 높은 품질의 소프트웨어 생산 가능
검증된 구조로 개발하기 때문에 안정적인 수행 가능
시스템의 특성을 개발 전에 예측 가능

소프트웨어 아키텍처 패턴 유형

유형	설명	개념도
계층화 패턴 (Layered Pattern)	- 시스템을 계층(Layer)으로 구분하여 구성 - 각 하위 모듈들은 특정한 수준의 추상화를 제공 - 각 계층은 다음 상위 계층에 서비스를 제공 - 서로 마주 보는 두 개의 계층 사이에서만 상호 작용
클라이언트-서버 패턴 (Client-Server Pattern)	- 하나의 서버와 다수의 클라이언트로 구성
파이프-필터 패턴 (Pipe-Filter Pattern)	- 데이터 스트림 생성하고 처리하는 시스템에서 사용 가능 - 서브 시스템이 입력 데이터를 받아 처리하고, 결과를 다음 서브 시스템으로 넘겨주는 과정 반복
브로커 패턴 (Broker Pattern)	- 분리된 컴포넌트들로 이루어진 분산 시스템에서 사용됨, 컴포넌트들은 원격 서비스 실행을 통해 상호작용 - 컴포넌트 간의 통신을 조정하는 역할 수행 - 서버는 자신의 기능들(서비스 및 특성)을 브로커에 넘겨주며(Publish), 클라이언트가 브로커에 서비스를 요청하면 브로커는 클라이언트를 자신의 레지스트리에 있는 적합한 서비스로 리다이렉션(Redirection)함 ex) Apache Kaf-ka, JBoss Messaging
모델-뷰-컨트롤러 패턴 (MVC; Model View Controller Pattern)	모델(Model): 핵심 기능과 데이터 보관 뷰(View): 사용자에게 정보 표시(하나 이상의 뷰가 정의될 수 있음) 컨트롤러(Controller): 사용자로부터 요청을 입력받아 처리

*소프트웨어 아키텍처 패턴 참고자료

towardsdatascience.com/10-common-software-architectural-patterns-in-a-nutshell-a0b47a1e9013

10 Common Software Architectural Patterns in a nutshell

Ever wondered how large enterprise scale systems are designed? Before major software development starts, we have to choose a suitable…

towardsdatascience.com

제 1과목 소프트웨어 설계 > 객체지향 설계

객체지향(Object Oriented)

객체지향은 실세계의 개체를 속성과 메서드가 결합한 형태의 객체로 표현하는 기법이다.

객체지향 구성요소 (클객메 메인속)

클래스(Class) / 객체(Object)/ 메서드(Method) / 메시지(Message) / 인스턴스(Instance) / 속성(Property)

구성요소	설명
클래스(Class)	하나 이상의 유사한 객체들을 묶어 공통된 특성을 표현한 데이터 추상화 [2020년 1회, 3회]
객체(Object)	자신 고유의 데이터를 가지며 클래스에서 정의한 행위를 수행
메서드(Method)	클래스로부터 생성된 객체를 사용하는 방법, 객체에 명령을 내리는 메시지
메시지(Message)	객체에게 어떤 행위를 하도록 지시하기 위한 방법
인스턴스(Instance)	클래스에 속한 각각의 객체
속성(Property)	한 클래스 내에 속한 객체들이 가지고 있는 데이터 값들을 단위별로 정의

객체지향 기법 (캡상다추정관)

기법	설명
캡슐화 (Encapsulation)	서로 관련성이 많은 데이터와 이와 관련된 함수들을 한 묶음으로 처리하는 기법. 정보은닉과 밀접한 관계가 있다. [2020년 3회] 인터페이스가 단순화된다, 소프트웨어 재사용성이 높아진다, 변경 발생 시 오류의 파급효과가 적다. [2020년 4회]
상속성 (Inheritance)	상위 클래스의 속성과 메소드를 하위 클래스에서 재정의 없이 물려받아 사용하는 기법
다형성 (Polymorphism)	하나의 메시지에 대해 각 객체가 가지고 있는 고유한 방법으로 응답할 수 있는 능력
추상화 (Abstraction)	공통 성질을 추출하여 클래스를 설정하는 기법
정보은닉 (Information Hiding)	코드 내부 데이터와 메소드를 숨기고 공개 인터페이스르 통해서만 접근이 가능하도록 하는 코드 보안 기술
관계성 (Relationship)	두 개 이상의 엔티티 형에서 데이터를 참조하는 관계를 나타내는 기법

객체지향 설계 원칙(SOLID)

원칙	설명
단일 책임의 원칙 (SRP) (Single Responsibility Principle)	하나의 클래스는 하나의 목적을 위해 생성
개방 폐쇄 원칙 (OCP) (Open Close Principle)	소프트웨어의 구성요소는 확장에는 여려있고, 변경에는 닫혀있어야 한다는 원칙
리스코프 치환의 원칙 (LSP) (Liskov Subsitution)	서브 타입(상속받은 하위 클래스)은 어디서나 자신의 기반 타입(상위 클래스)으로 교체할 수 있어야 한다는 원칙
인터페이스 분리의 원칙 (ISP) (Interface Segregation Principle)	클라이언트는 자신이 사용하지 않는 메서드와 의존관계를 맺으면 안된다. 클라이언트가 사용하지 않는 인터페이스 때문에 영향을 받아서는 안된다. [2020년 4회]
의존성 역전의 원칙 (DIP) (Dependency Inversion Principle)	실제 사용 관계는 바뀌지 않으며, 추상을 매개로 메시지를 주고받음으로써 관계를 최대한 느슨하게 만드는 원칙

객체지향 방법론 종류

종류	만든이(방법론)	설명	특징
OOSE (Object Oriented Software Engineering)	Jacobson (야콥슨)방법론	유스케이스에 의한 접근방법으로 유스케이스를 모든 모델의 근간으로 활용	분석, 설계, 구현 단계로 구성 기능적 요구사항 중심의 시스템
OMT (Object Modeling Technology)	Rumbaugh (럼바우)방법론	객체지향 분석, 시스템 설계, 오브젝트 설계 및 구현의 4단계로 구성 럼바우의 객체지향 분석 절차 (객동기) 객체 모델링 → 동적 모델링 → 기능 모델링 [2020년 1회, 3회, 4회]	복잡한 대형 프로젝트에 유용, 기업 업무의 모델링 편리 및 사용자와 의사소통 편리
OOD (Object Oriented Design)	Booch (부치)방법론	설계 부분만 존재 설계 문서화를 강조하여 다이어그램 중심으로 개발하는 방법론 미시적(Micro) 개발 프로세스와 거시적(Macro) 개발 프로세스를 모두 사용하는 분석 방법	분석과 설계 분리 불가능 분석하는 데 이용된 객체 모델의 설계시 적용
OOD (Object Oriented Design)	Wirfs-Brock 방법론	고객 명세서를 평가해서 설계 작업까지 연속적으로 수행하는 분석방법	분석과 설계 간의 구분이 없다
OOA (Object Oriented Analysis)	Coad와 Yourdon 방법론	객체 식별, 구조 식별, 주체 정의, 속성 및 관계 정의, 서비스 정의 등의 과정으로 구성되는 객체 지향 분석방법	E-R 다이어그램을 사용하여 객체의 행위를 모델링

※ 객체/동적/기능 모델링에 활용되는 다이어그램 상세 바로가기

https://simuing.tistory.com/entry/2021-정보처리기사-필기요약-UML

2021 #정보처리기사 필기요약 #1-1. UML

2021년 NCS기반 정처기 필기입니다. 이기적2020과 수제비2021 수험서를 함께 보고 공부한 기록입니다. 제 1과목 소프트웨어 설계 > 요구사항 확인 > UML UML(Unified Modeling Language)의 개념 UML은 객체지향

simuing.tistory.com

디자인 패턴

디자인 패턴 구성요소 (패문솔 사결샘)

패턴 이름 / 문제 및 배경 / 솔루션 / 사례 / 결과 / 샘플 코드

디자인 패턴 유형 (생구행)

목적: 생성 / 구조 / 행위

범위: 클래스 / 객체

디자인 패턴 종류

생성 패턴 (생빌 프로 팩앱싱)

빌더 / 프로토타입 / 팩토리 메서드 / 앱스트랙 팩토리 / 싱글톤
Builder / Prototype / Factory Method / Abstract Factory / Singleton
→ 생더블 날빌을 프로브 안뽑고 하길래 팩토리 애(앱)드온해서 싱나게 두들겼다.

구조 패턴 (구 브데 퍼플 프록 컴 어)

브리지 / 데코레이터 / 퍼지사이드 / 플라이 웨이트 / 프록시 / 컴포지트 / 어댑터
Bridge / Decorator / Facade / Flyweight / Proxy / Composite / Adapter
→ 9(구) 부대(브데) 퍼플(보라색) 프로(록)토스 컴퓨터 병력이 어디있지?

행위 패턴 [2020년 3회]

Interpreter, Template Method, Chain of Responsibility, Command, Iterator, Mediator, Memento, Observer, State, Strategy, Visitor

디자인 패턴 설명 더보기를 클릭하면 보입니다.

구분	패턴	설명
생성 패턴	Builder	생산 단계를 캡슐화하여 구축 공정을 동일하게 이용하도록 하는 패턴
	Prototype	복사하여 새 개체를 생성할 수 있도록 하는 패턴
	Factory Method	객체를 생성하기 위한 인터페이스를 정의하여 어떤 클래스가 인스턴스화 될 것인지는 서브 클래스가 결정하도록 하는 패턴, Virtual-Constructor 패턴이라고도 함 [2020년 3회]
	Abstract Factory	생성군들을 하나에 모아놓고 팩토리 중에서 선택하게 하는 패턴
	Singleton	유일한 하나의 인스턴스를 보장하도록 하는 패턴
구조 패턴	Bridge	추상과 구현을 분리하여 결합도를 낮춘 패턴
	Decorator	소스를 변경하지 않고 기능을 확장하도록 하는 패턴
	Facade	하나의 인터페이스를 통해 느슨한 결합을 제공하는 패턴
	Flyweight	대량의 작은 객체들을 공유하는 패턴
	Proxy	대리인이 대신 그 일을 처리하는 패턴
	Composite	개별 객체와 복합 객체를 클라이언트에서 동일하게 사용하도록 하는 패턴
	Adapter	인터페이스로 인해 함께 사용하지 못하는 클래스를 함께 사용하도록 하는 패턴
행위 패턴	Interpreter	언어 규칙 클래스를 이용하는 패턴
	Template Method	알고리즘 골격의 구조를 정의한 패턴
	Chain of Responsibility	객체들끼리 연결 고리를 만들어 내부적으로 전달하는 패턴
	Command	요청 자체를 캡슐화하여 파라미터로 넘기는 패턴
	Iterator	내부 표현은 보여주지 않고 순회하는 패턴
	Mediator	객체 간 상호작용을 캡슐화한 패턴
	Memento	상태 값을 미리 저장해 두었다가 복구하는 패턴
	Observer	상태가 변할 때 의존자들에게 알리고, 자동 업데이트하는 패턴
	State	객체 내부 상태에 따라서 행위를 변경하는 패턴
	Strategy	다양한 알고리즘을 캡슐화하여 알고리즘 대체가 가능하도록 한 패턴
	Visitor [2020년 1회]	오퍼레이션을 별도의 클래스에 새롭게 정의한 패턴

디자인 패턴의 장단점 [2020년 4회]

장점

요구사항 변경에 따른 소스 코드 변경 최소화
설계 변경 요청에 대한 유연한 대처 가능
범용적인 코딩 스타일 적용 가능
개발자 간의 원활한 의사소통 가능
재사용을 통한 개발 시간 단축 가능
소프트웨어 구조 파악 용이
객체지향 설계 및 구현의 생산성을 높임

단점

객체지향 설계/구현 위주로 사용
초기 투자 비용의 부담