2021년 NCS기반 정처기 필기입니다. 이기적2020과 수제비2021 수험서를 함께 보고 공부한 기록입니다.
제 1과목 소프트웨어 설계 > 애플리케이션 설계
(1) 공통 모듈 설계
모듈(Module)의 개념
모듈은 크게 독립된 하나의 소프트웨어 또는 하드웨어 단위를 지칭하는 용어이다.
모듈화를 통해 분리된 시스템의 기능
- 서브 프로그램
- 서브 루틴
- 소프트웨어 내의 단위 프로그램
- 작업 단위
모듈의 특징
- 각각의 모듈은 상대적으로 독립성을 가지고 있다.
- 모듈은 단독으로 컴파일할 수 있으며, 재사용할 수 있다.
- 독립성이 높은 모율일수록 수정 시 다른 모듈에 영향을 거의 미치지 않고, 오류 발생 시 쉽게 해결할 수 있다.
- 모듈의 독립성은 결합도와 응집도에 의해 측정된다.
- 모듈의 독립성을 높이는 방법
- 모듈의 결합도는 약하게(낮게)
- 응집도는 강하게(높게)
- 모듈의 크기는 작게 만든다.
공통 모듈의 개념
- 전체 프로그램 기능 중 특정 기능을 처리할 수 있는 실행 코드를 의미한다.
- 자체적으로 컴파일이 가능하다.
- 다른 프로그램에서 재사용이 가능하다.
공통 모듈 원칙 (정명 완일추)
공통 모듈에 대한 명세를 작성할 때에는 다음의 원칙을 지킨다.
- 정확성 (Correctness)
- 명확성 (Clarity)
- 완전성 (Completeness)
- 일관성 (Consistency)
- 추적성 (Traceability)
모듈화(Modularity)
소프트웨어의 성능을 향상시키거나 복잡한 시스템의 수정, 재사용, 유지 관리 등이 용이하도록 기능 단위의 모듈로 분해하는 설계 및 구현 기법이다.
기법 | 설명 |
루틴 (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) |
입력, 처리, 출력에 대한 정보를 제공하는 도표 |
프로그램을 구성하는 기능을 기술 | |
세부적 도표 (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
제 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) 개발 프로세스를 모두 사용하는 분석 방법 |
분석과 설계 분리 불가능 분석하는 데 이용된 객체 모델의 설계시 적용 |
Wirfs-Brock 방법론 |
고객 명세서를 평가해서 설계 작업까지 연속적으로 수행하는 분석방법 | 분석과 설계 간의 구분이 없다 | |
OOA (Object Oriented Analysis) |
Coad와 Yourdon 방법론 |
객체 식별, 구조 식별, 주체 정의, 속성 및 관계 정의, 서비스 정의 등의 과정으로 구성되는 객체 지향 분석방법 | E-R 다이어그램을 사용하여 객체의 행위를 모델링 |
※ 객체/동적/기능 모델링에 활용되는 다이어그램 상세 바로가기
https://simuing.tistory.com/entry/2021-정보처리기사-필기요약-UML
디자인 패턴
디자인 패턴 구성요소 (패문솔 사결샘)
패턴 이름 / 문제 및 배경 / 솔루션 / 사례 / 결과 / 샘플 코드
디자인 패턴 유형 (생구행)
목적: 생성 / 구조 / 행위
범위: 클래스 / 객체
디자인 패턴 종류
생성 패턴 (생빌 프로 팩앱싱)
빌더 / 프로토타입 / 팩토리 메서드 / 앱스트랙 팩토리 / 싱글톤
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회]
장점
- 요구사항 변경에 따른 소스 코드 변경 최소화
- 설계 변경 요청에 대한 유연한 대처 가능
- 범용적인 코딩 스타일 적용 가능
- 개발자 간의 원활한 의사소통 가능
- 재사용을 통한 개발 시간 단축 가능
- 소프트웨어 구조 파악 용이
- 객체지향 설계 및 구현의 생산성을 높임
단점
- 객체지향 설계/구현 위주로 사용
- 초기 투자 비용의 부담
'IT License > 정처기-1과목' 카테고리의 다른 글
2021 #정보처리기사 필기요약 #1-4. 인터페이스 설계 (0) | 2021.02.25 |
---|---|
2021 #정보처리기사 필기요약 #1-2. 화면 설계 (0) | 2021.02.24 |
2021 #정보처리기사 필기요약 #1-1. 애자일(Agile), 분석모델확인 (4) | 2021.02.24 |
2021 #정보처리기사 필기요약 #1-1. UML (1) | 2021.02.19 |
2021 #정보처리기사 필기요약 #1-1. 요구사항 확인 (0) | 2021.02.18 |
댓글