도서 내용 중 중요하다 여겨지는 것만 작성합니다
영리목적이 아닌 공유목적입니다
출처 : 2023 시나공 정보처리기사 실기 (저자: 김정준, 강윤석, 김용갑, 김우경 | 출판사: 길벗)
'기출문제는 시나공 저자(알앤디)가 복원한 것임'
제가 이미 잘 알고 있는 것은 적지 않습니다
해당 포스팅을 참고하여 학습하셔도 좋지만
교재를 구매하여 문제를 풀며 학습하시는 것을 추천드립니다
소프트웨어 아키텍처
소프트웨어를 구성하는 요소들 간의 관계를 표현하는 시스템의 구조 또는 구조체
- 모듈화
- 추상화 : 제어 추상화, 과정 추상화, 데이터(자료) 추상화
- 단계적 분해 : 상위의 중요 개념으로부터 하위의 개념으로 구체화시키는 분할 기법
- 정보 은닉
상위 설계와 하위 설계
| 상위 설계 | 하위 설계 |
| ex) 아키텍처, 인터페이스, DB | ex) 모듈, 컴포넌트, 자료구조, 알고리즘 |
소프트웨어 아키텍처의 품질 속성
- 시스템 측면 : 성능, 변경 용이성, 사용성, 기능성, 가용성, 확장성, 보안 등
- 비즈니스 측면 : 시장 적시정, 비용과 혜택, 예상 시스템 수명, 목표 시장, 공개 일정 등
- 아키텍처 측면 : 개념적 무결성, 정확성, 완결성, 구축 가능성, 변경성, 시험성 등
소프트웨어 아키텍처의 설계 과정
- 설계 목표 설정
- 시스템 타입 결정
- 아키텍처 패턴 적용
- 서브시스템 구체화
- 검토
아키텍처 패턴
| 레이어 패턴 | ex) OSI 참조 모델 |
| 클라이언트-서버 패턴 | |
| 파이프-필터 패턴 | ex) shell |
| 모델-뷰-컨트롤러 패턴 |  ex) 대화형 애플리케이션 |
| 마스터-슬레이브 패턴 | 슬레이브가 처리한 결과물을 다시 돌려받는 방식 ex) 장애 허용 시스템, 병렬 컴퓨팅 시스템 |
| 브로커 패턴 | 사용자 요청에 맞는 컴포넌트를 연결 ex) 분산 환경 시스템 |
| 피어-투-피어 패턴 | 용도에 따라 피어가 컴포넌트, 서버, 클라이언트가 된다 ex) 파일 공유 네트워크 |
| 이벤트-버스 패턴 | 이벤트 메시지발생, 채널 구독, 리스너 ex) 알림 서비스 |
| 블랙보드 패턴 | 모든 컴포넌트가 공유 데이터 저장소와 블랙보드 컴포넌트 접근 가능 ex) 음성 인식, 차량 식별, 신호 해석 |
| 인터프리터 패턴 | 코드 각 라인별 수행 방법 지정, 기호마다 클래스 보유 ex) 번역기, 컴파일러, 인터프리터 |
객체지향
객체지향의 구성 요소
- 객체 = 데이터 + 함수
- 클래스 = 객체의 집합
- 메시지 = 객체들 간 상호작용을 하는데 사용되는 수단
객체지향의 특징
- 캡슐화 : 외부에서의 접근을 제한하기 위해 인터페이스를 제외한 세부 내용 은닉
- 상속 : 상위 클래스의 모든 속성과 연산을 하위 클래스가 물려받는 것
- 다형성 : 하나의 메시지에 대해 각각의 객체가 고유한 방법으로 응답할 수 있는 능력
- 연관성
| is member of | 연관화 |
| is instance of | 분류화 |
| is part of | 집단화 |
| is a | 일반화 |
| 특수화/상세화 |
객체지향 분석 및 설계
객체지향 분석의 방법론
| Rumbaugh(럼바우) 방법 | 객체 모델, 동적 모델, 기능 모델로 나뉨 |
| Booch(부치) 방법 | 미시적 개발 프로세스와 거시적 개발 프로세스를 모두 사용 |
| Jacobson 방법 | 유스케이스(use case) 사용 |
| Coad와 Yourdon 방법 | E-R 다이어그램 사용 |
| Wirfs-Brock 방법 |
럼바우의 분석 기법
- 객체 모델링 (information) : E-R 다이어그램
- 동적 모델링 (dynamic) : 상태 다이어그램
- 기능 모델링 (functional) : 자료 흐름도(DFD)
객체지향 설계 원칙 (SOLID 원칙)
| SRP (단일 책임 원칙) | 객체는 단 하나의 책임 |
| OCP (개방-폐쇄 원칙) | 기존 코드를 변경하지 않고 기능을 추가 |
| LSP (리스코프 치환 원칙) | 자식 클래스는 최소한 부모 클래스의 기능 수행 가능 |
| ISP (인터페이스 분리 원칙) | 자신이 사용하지 않는 인터페이스와 의존 관계를 맺거나 영향을 받지 않아야 한다 |
| DIP (의존 역전 원칙) | 추상성이 높은 클래스와 의존 관계를 맺어야 한다 |
모듈
결합도
모듈 간에 상호 의존하는 정도
| 내용 결합도 (Content Coupling) | 한 모듈이 다른 모듈의 내부 기능 및 그 내부 자료를 직접 참조하거나 수정할 때의 결합도 |
| 공통(공유) 결합도 (Common) | 파라미터가 아닌 모듈 밖에 선언된 전역 변수를 사용하여 전역 변수를 갱신하는 방식으로 상호작용하는 때의 결합도 |
| 외부 결합도 (External) | 어떤 모듈에서 선언한 데이터(변수)를 외부의 다른 모듈에서 참조할 때의 결합도 |
| 제어 결합도 (Control) | 어떤 모듈이 다른 모듈 내부의 논리적인 흐름을 제어하기 위해 제어 신호나 제어 요소를 전달하는 결합도 |
| 스탬프(검인) 결합도 (Stamp) | 모듈 간의 인터페이스로 배열이나 레코드 등의 자료 구조가 전달될 때의 결합도 |
| 자료 결합도 (Data) | 모듈 간의 인터페이스가 자료 요소로만 구성될 때의 결합도 |
응집도
모듈의 내부 요소들이 서로 관련되어 있는 정도
| 기능적 응집도 (Functional Cohesion) | 모듈 내부의 모든 기능 요소들이 단일 문제와 연관되어 수행될 경우의 응집도 |
| 순차적 응집도 (Sequential) | 모듈 내 하나의 활동으로부터 나온 출력 데이터를 그 다음 활동의 입력 데이터로 사용할 경우의 응집도 |
| 교환(통신)적 응집도 (Communication) | 동일한 입력과 출력을 사용하여 서로 다른 기능을 수행하는 구성 요소들이 모였을 경우의 응집도 |
| 절차적 응집도 (Procedural) | 모듈이 다수의 관련 기능을 가질 때 모듈 안의 구성 요소들이 그 기능을 순차적으로 수행할 경우의 응집도 |
| 시간적 응집도 (Temporal) | 특정 시간에 처리되는 몇 개의 기능을 모아 하나의 모듈로 작성할 경우의 응집도 |
| 논리적 응집도 (Logical) | 유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들로 하나의 모듈이 형성되는 경우의 응집도 |
| 우연적 응집도 (Coincidential) | 모듈 내부의 각 구성 요소들이 서로 관련 없는 요소로만 구성된 경우의 응집도 |
N-S 차트
논리의 기술에 중점을 두고 도형을 이용해 표현하는 방법
단위 모듈
한 가지 동작을 수행하는 기능을 모듈로 구현한 것
IPC
모듈 간 통신 방식을 구현하기 위해 사용되는 대표적인 프로그래밍 인터페이스 집합
| Shared Memory | 공유 가능한 메모리를 구성하여 다수의 프로세스가 통신하는 방식 |
| Socket | 네트워크 소켓을 이용하여 네트워크를 경유하는 프로세스 간에 통신하는 방식 |
| Semaphores | 공유 자원에 대한 접근 제어를 통해 통신하는 방식 |
| Pipes&named Pipes | 선입선출 형태로 통신하는 방식 |
| Message Queueing | 메시지가 발생하면 이를 전달하는 방식 |
재사용
이미 개발된 기능들을 새로운 시스템이나 기능 개발에 사용하기 적합하도록 최적화하는 작업
규모에 따른 분류
| 함수와 객체 | 클래스나 메소드 단위의 소스 코드 |
| 컴포넌트 | 독립적인 업무 또는 기능을 수행하는 실행 코드 기반으로 작성된 모듈 |
| 애플리케이션 | 공통된 기능들을 제공하는 애플리케이션을 공유하는 방식으로 재사용 |
코드의 종류
| 순차 코드 | 일련번호 |
| 블록 코드 | 블록으로 구분하고 각 블록 내 일련번호 |
| 10진 코드 | 10진 분할 |
| 그룹 분류 코드 | 대분류 중분류 소분류 |
| 연상 코드 | 명칭, 약호 등 관련있는 문자 및 기호 |
| 표의 숫자 코드 | 물리적 수치 |
| 합성 코드 | 2개 이상의 코드를 조합 |
디자인 패턴
생성 패턴
클래스나 객체의 생성과 참조 과정을 정의하는 패턴
문제 및 배경, 실제 적용된 사례, 재사용이 가능한 샘플 코드 등으로 구성
| 추상 팩토리 (Abstract Factory) | 인터페이스를 통해 연관 객체들의 그룹으로 생성하여 추상적으로 표현 |
| 빌더 (Builder) | 인스턴스를 조합하여 객체 생성 |
| 팩토리 메소드 (Factory Method) | 상위 클래스 : 인터페이스 정의 서브 클래스 : 실제 객체 생성 |
| 프로토타입 (Prototype) | 원본 객체 복제 |
| 싱글톤 (Singeton) | 클래스 내 인스턴스 하나 |
구조 패턴
클래스나 객체들을 조합하여 더 큰 구조로 만드는 패턴
| 어댑터 (Adaoter) | 기존 클래스의 인터페이스를 호환성을 위해 변환 |
| 브리지 (Bridge) | 구현부에서 추상층을 분리한 독립적 패턴 |
| 컴포지트 (Composite) | 여러 객체를 구분 없이 다루는 패턴 |
| 데코레이터 (Decorator) | 부가적 기능 추가를 위해 다른 객체들을 덧붙이는 패턴 |
| 퍼싸드 (Facade) | 상위 인터페이스를 구성하여 서브 클래스들의 기능을 편리하게 사용 |
| 플라이웨이트 (Flyweight) | 인스턴스를 공유하여 메모리 절약 |
| 프록시 (Proxy) | 접근이 어려운 객체 접근을 돕는 인터페이스 |
행위 패턴
클래스나 객체들이 서로 상호작용하는 방법이나 책임 분배 방법 정의
| 책임 연쇄 (Chain of Responsibility) | 요청 미처리 시 다음 객체에게 책임 전가 |
| 커맨드 (Command) | 요청 캡슐화 |
| 인터프리터 (Interpreter) | 언어에 문법 표현 정의 |
| 반복자 (Iterator) | 접근이 잦은 객체는 동일한 인터페이스를 사용 |
| 중재자 (Mediator) | 상호작용 캡슐화 |
| 메멘토 (Memento) | 특정 시점에서의 객체 내부 상태 객체화, ctrl+z |
| 옵서버 (Observer) | 한 객체의 상태 변화가 상속되어 있는 다른 객체들에게 상태 전달 |
| 상태 (State) | 객체 상태에 따라 동일 동작을 다르게 처리 |
| 전략 (Strategy) | 동일 계열 알고리즘을 개별적으로 캡슐화 |
| 템플릿 메소드 (Template Method) | 상위 클래스 : 골격 정의 하위 클래스 : 구체화 |
| 방문자 (Visitor) | 각 클래스들의 데이터 구조에서 처리 기능 분리 |
오답 노트
Q1.
소프트웨어 개발에서 개발 언어 선정 시 언어가 다른 개발 사례가 충분히 존재하고, 이미 여러 곳에서 사용하고 있는지를 판단하는 기준을 가리키는 용어를 쓰시오.
A1. 범용성
* 적정성, 효율성, 이식성, 친밀성, 범용성
Q2.
소프트웨어 아키텍처에 대해 간략히 서술하시오.
A2. 소프트웨어를 구성하는 요소들 간의 관계를 표현하는 시스템의 구조 또는 구조체
Q3.
공통 모듈의 명세 기법 중 일관성에 대해 간략히 서술하시오.
A3. 공통 기능들 간 상호 충돌이 발생하지 않도록 작성하는 기법
* 정확성, 명확성, 완전성, 일관성, 추적성
Q4.
공통 모듈 구현 시 다른 개발자들이 해당 기능을 명확히 이해할 수 있도록 5가지의 명세 기법을 준수해야 한다. 이 중 기능에 대한 요구사항의 출처, 관련 시스템 등의 관계를 파악할 수 있도록 작성해야 한다는 것을 의미하는 원칙을 쓰시오.
A4. 추적성
'Computer Science (CS) > 정보처리기사' 카테고리의 다른 글
| [정보처리기사 실기] 9. 소프트웨어 개발 보안 구축 (0) | 2023.03.19 |
|---|---|
| [정보처리기사 실기] 8. SQL 응용 (0) | 2023.03.18 |
| [정보처리기사 실기] 5. 인터페이스 구현 (0) | 2023.03.16 |
| [정보처리기사 실기] 2. 데이터 입출력 구현 (0) | 2023.03.11 |
| [정보처리기사 실기] 1. 요구사항 확인 (0) | 2023.03.09 |
