8 분 소요

2020 시나공 정보처리기사 필기책 참고

주의! 중요도가 낮은 항목(C)은 제외

1. 소프트웨어 아키텍처 – APermalink

- 소프트웨어 아키텍처의 설계Permalink

  • 골격이 되는 기본 구조, 시스템의 구조 또는 구조체
  • 원칙과 지침, 의사소통 도구
  • 비기능적 요구사항의 제약 반영, 기능적 요구사항을 구현하는 방법을 찾는 과정
  • 분할 방법, 모듈에 할당될 기능, 모듈 간의 인터페이스 등 결정

- 모듈화(Modularity)Permalink

  • 성능을 향상시키거나 수정 및 재사용, 유지관리 등을 위해 기능들을 모듈 단위로 나누는 것
  • 자주 사용하는 것들을 공통 모듈로 구성하여 재사용성 향상
  • 크기를 작게 나누면 통합 비용이 많이 듦
  • 크기를 크게 나누면 모듈 하나의 개발 비용이 많이 듦

- 추상화(Abstraction)Permalink

  • 전체적이고 포괄적인 개념을 설계한 후 차례로 세분화하여 구체화
  • 유사한 모델을 만들어서 여러 가지 요인들을 테스트
  • 최소의 비용으로 실제 상황에 대처, 구조 및 구성을 대략적으로 파악
  • 과정 추상화
    • 전반적인 흐름만 파악할 수 있게 설계
  • 데이터 추상화
    • 데이터 구조를 대표할 수 있는 표현으로 대체
  • 제어 추상화
    • 이벤트 발생을 대표할 수 있는 표현으로 대체

- 단계적 분해(Stepwise Refinement)Permalink

  • 하향식 설계 전략. 상위의 중요 개념으로부터 하위의 개념으로 구체화
  • 추상화의 반복에 의해 세분화
  • 기능에서부터 시작해 알고리즘, 자료구조 등 상세한 내역을 뒤로 미뤄 진행

- 정보 은닉(Information Hiding)Permalink

  • 정보가 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법
  • 필요한 정보만 인터페이스를 통해 주고 받음
  • 모듈을 독립적으로 수행할 수 있음
  • 모듈이 변경되더라도 다른 모듈에 영향을 주지 않아 수정, 시험, 유지보수 용이

- 소프트웨어 아키텍처의 품질 속성Permalink

  • 시스템 측면
    • 성능, 보안, 가용성, 기능성, 사용성, 변경용이성, 확장성 등
  • 비즈니스 측면
    • 시장 적시성, 비용과 혜택, 예상 시스템 수명 등
  • 아키텍처 측면
    • 개념적 무결성, 정확성, 완결성, 구축 가능성 등

- 소프트웨어 아키텍처 설계 과정Permalink

  • 설계 목표 설정 -> 시스템 타입 결정 -> 아키텍처 패턴 적용 -> 서브시스템 구체화 -> 검토


2. 아키텍처 패턴 – APermalink

- 아키텍처 패턴의 개요Permalink

  • 아키텍처를 설계할 때 참조할 수 있는 전형적인 해결 방식
  • S/W 시스템의 구조를 구성하기 위한 기본적인 윤곽
  • 서브시스템들과 그 역할이 정의, 관계와 여러 규칙, 지침 등이 포함
  • 아키텍처 스타일 또는 표준 아키텍처라고도 함

- 레이어 패턴(Layers pattern)Permalink

  • 시스템을 계층으로 구분
  • 상위 계층은 서비스 제공자, 하위 계층은 클라이언트가 됨
  • 마주보는 두 개의 계층 사이에서만 상호작용
  • 변경 작업 용이
  • 특정 계층만을 교체해 시스템을 개선하는 것이 가능
  • OSI 참조 모델

- 클라이언트-서버 패턴(Client-Server pattern)Permalink

  • 하나의 서버 컴포넌트와 다수의 클라이언트 컴포넌트로 구성
  • 사용자는 클라이언트와만 의사소통
  • 서버는 항상 대기 상태를 유지
  • 클라이언트나 서버는 요청과 응답을 받기 위해 동기화되는 경우를 제외하고 서로 독립적

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

  • 데이터 스트림 절차의 각 단계를 필터 컴포넌트로 캡슐화하여 파이프를 통해 데이터 전송
  • 재사용성이 좋고, 추가가 쉬워 확장이 용이
  • 재배치하여 다양한 파이프라인 구축 가능
  • 데이터 변환, 버퍼링, 동기화 등에 주로 사용
  • Unix의 Shell

- 모델-뷰-컨트롤러 패턴(Model-View-Controller Pattern)Permalink

  • 서브시스템을 3개의 부분으로 구조화
  • 모델(Model) : 핵심 기능과 데이터를 보관
  • 뷰(View) : 정보를 표시
  • 컨트롤러(Controller) : 입력을 처리
  • 별도의 컴포넌트로 분리되어 서로 영향을 받지 않고 개발 작업 수행 가능
  • 여러 개의 뷰를 만들 수 있으므로 대화형 어플리케이션에 적합

- 마스터-슬레이브 패턴(Master-Slave Pattern)Permalink

  • 장애 허용 시스템, 병렬 컴퓨팅 시스템

- 브로커 패턴(Broker Pattern)Permalink

  • 분산 환경 시스템

- 피어-투-피어 패턴(Peer-To-Peer Pattern)Permalink

  • 클라이언트와 서버는 전형적인 멀티스레딩 방식을 사용

- 이벤트-버스 패턴(Event-Bus Pattern)Permalink

  • 소스, 리스너, 채널, 버스

- 블랙보트 패턴(Blackboard Pattern)Permalink

  • 음성 인식, 차량 식별, 신호 해석

- 인터프리터 패턴(Interpreter Pattern)Permalink

  • 프로그램 코드를 해석하는 컴포넌트를 설계할 때 사용


3. 객체지향(Object-Oriented) – APermalink

- 객체지향의 개요Permalink

  • S/W를 개발할 때 객체들을 조립해서 작성할 수 있는 기법
  • 재사용 및 확장 용이, 빠르게 개발할 수 있고 유지보수 쉬움
  • 복잡한 구조를 단계적, 계층적으로 표현하고, 멀티미디어 데이터 및 병렬 처리 지원
  • 사용자와 개발자가 쉽게 이해할 수 있음

- 객체(Object)Permalink

  • 데이터와 데이터를 처리하는 함수를 묶어 놓은 하나의 S/W 모듈
  • 데이터
    • 객체가 가지고 있는 정보. 속성이나 상태, 분류 등
    • 속성, 상태, 변수, 상수, 자료 구조
  • 함수
    • 객체가 수행하는 기능
    • 메소드, 서비스, 동작, 연산
  • 객체의 특성
    • 독립적으로 식별 가능한 이름
    • 상태는 시간에 따라 변함
    • 상호 연관성에 의한 관계 형성
    • 행위의 특징을 나타낼 수 있음
    • 일정한 기억장소를 가지고 있음

- 클래스(Class)Permalink

  • 공통된 속성과 연산을 갖는 객체의 집합
  • 객체들이 갖는 속성과 연산을 정의하고 있는 틀
  • 각각의 객체를 인스턴스, 새로운 객체를 생성하는 것을 인스턴스화
  • 최상위 클래스는 상위 클래스를 갖지 않는 클래스
  • 슈퍼 클래스는 특정 클래스의 부모 클래스
  • 서브 클래스는 특정 클래스의 자식 클래스

- 캡슐화(Encapsulation)Permalink

  • 데이터와 데이터를 처리하는 함수를 하나로 묶는 것
  • 인터페이스를 제외한 세부 내용이 은폐
  • 외부 모듈의 변경으로 인한 파급 효과가 적음
  • 재사용 용이
  • 인터페이스가 단순해지고, 객체 간 결합도 낮아짐

- 상속(Inheritance)Permalink

  • 부모 클래스의 모든 속성과 연산을 자식 클래스가 물려 받는 것
  • 자식 클래스는 속성과 연산을 다시 정의하지 않고 사용 가능
  • 새로운 속성과 연산을 첨가하여 사용 가능
  • 재사용을 높임

- 다형성(Polymorphism)Permalink

  • 메시지에 의해 객체가 연산을 수행할 때, 고유한 방법으로 응답할 수 있는 능력
  • 객체들은 동일한 메소드명을 사용하며 같은 의미의 응답을 함
  • 같은 클래스에 속한 인스턴스처럼 수행할 수 있도록 함


4. 모듈 – APermalink

- 모듈의 개요Permalink

  • 모듈화를 통해 분리된 시스템의 각 기능. 서브루틴, 서브시스템 등과 같은 의미로 사용
  • 단독으로 컴파일 가능, 재사용 가능
  • 모듈의 기능적 독립성은 하나의 기능만을 수행하고 과도한 상호작용을 배재함으로써 달성
  • 수정하더라도 다른 모듈에 거의 영향을 미치지 않으며, 오류 발생시 쉽게 발견하고 해결 가능
  • 결합도는 약하게, 응집도는 강하게, 모듈의 크기는 작게 만들어야 함

- 결합도(Coupling)Permalink

  • 모듈간 상호 의존하는 정도
  • 결합도가 약할수록 품질이 높고, 강할수록 품질이 낮음
  • 결합도가 강하면 시스템 구현 및 유지보수 작업이 어려움

@ 내용 결합도(Content Coupling)Permalink

  • 한 모듈이 다른 모듈이 내부 기능 및 그 내부 자료를 직접 참조하거나 수정
  • 제어가 이동하는 경우

@ 공통(공유) 결합도(Common Coupling)Permalink

  • 공통 데이터 영역을 여러 모듈이 사용할 때의 결합도
  • 조금의 변경이 모든 모듈에 영향을 미치므로 모듈의 독립성을 약하게 함

@ 외부 결합도(External Coupling)Permalink

  • 선언한 데이터를 외부의 다른 모듈에서 참조할 때의 결합도
  • 데이터의 범위를 각 모듈에서 제한할 수 있음

@ 제어 결합도(Control Coupling)Permalink

  • 다른 모듈 내부의 논리적 흐름을 제어하기 위해 제어신호를 이용하여 통신
  • 다른 모듈의 상세한 처리 절차를 알고 있어 이를 통제하는 경우
  • 처리 기능이 두 모듈에 분리되어 설계된 경우
  • 하위 모듈이 상위 모듈에게 처리 명령을 내리는 권리 전도현상 발생

@ 스탬프 결합도(Stamp Coupling)Permalink

  • 배열이나 레코드 등의 자료 구조가 전달될 때의 결합도
  • 동일한 자료 구조를 조회하는 경우

@ 자료 결합도(Data Coupling)Permalink

  • 자료 요소로만 구성될 때의 결합도
  • 가장 바람직한 결합도

- 응집도(Cohesion)Permalink

  • 정보 은닉 개념을 확장한 것
  • 모듈이 독립적인 기능으로 정의되어 있는 정도
  • 응집도가 강할수록 품질이 높고, 약할수록 품질이 낮음

@ 기능적 응집도(Functional Cohesion)Permalink

  • 모든 기능 요소들이 단일 문제와 연관되어 수행될 경우

@ 순차적 응집도(Sequential Cohesion)Permalink

  • 출력 데이터를 그 다음 활동의 입력 데이터로 사용할 경우

@ 교환적 응집도(Communication Cohesion)Permalink

  • 동일한 입출력을 사용하여 서로 다른 기능을 수행하는 구성요소들이 모였을 경우

@ 절차적 응집도(Procedural Cohesion)Permalink

  • 다수의 관련 기능을 가질 때 모듈 안의 구성 요소들이 그 기능을 순차적으로 수행할 경우

@ 시간적 응집도(Temporal Cohesion)Permalink

  • 특정 시간에 처리되는 몇 개의 기능을 모아 하나의 모듈로 작성할 경우

@ 논리적 응집도(Logical Cohesion)Permalink

  • 유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들로 하나의 모듈이 형성되는 경우

@ 우연적 응집도(Coincidental Cohesion)Permalink

  • 각 구성 요소들이 서로 관련 없는 요소로만 구성된 경우

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

  • 팬인은 모듈을 제어하는 모듈의 수. 팬아웃은 모듈에 의해 제어되는 모듈의 수
  • 시스템의 복잡도를 알 수 있음
  • 팬인이 높다는 것은 재사용 측면에서 설계가 잘 되어있으나, 단일 장애점 발생 가능
  • 팬아웃이 높은 경우 불필요하게 다른 모듈을 호출하고 있는지 검토하고 단순화할 수 있는지 검토
  • 시스템 복잡도를 최적화하기 위해 팬인을 높게, 팬아웃은 낮게 설계


5. 코드 – BPermalink

- 코드의 개요Permalink

  • 자료의 추출을 쉽게 하기 위해 사용하는 기호
  • 신속, 정확, 명료하게 정보 전달
  • 일정한 규칙에 따라 작성
  • 식별기능, 분류기능, 배열기능

- 코드의 종류Permalink

  • 순차 코드
    • 1, 2, 3 ..
  • 블록 코드
    • 1001~1100 : 총무부
  • 10진 코드
    • 1000 : 공학, 1100 : S/W 공학
  • 그룹 분류 코드
    • 1-01-001 : 본사-총무부-인사계
  • 연상 코드
    • TV-40 : 40인치 TV
  • 표의 숫자 코드
    • 120-720-1500 : 두께x폭x길이가 120x720x1500인 강판
  • 합성 코드
    • KE-711 : 대한항공 711기

- 코드 부여 체계Permalink

  • 이름만으로 개체의 용도와 적용 범위를 알 수 있도록 코드를 부여하는 방식
  • 유일한 코드 부여하여 식별 및 추출을 용이하게 함
  • 각 단위 시스템의 고유한 코드와 개체를 나타내는 코드 등이 정의되어야 함
  • 코드의 자릿수와 구분자, 구조 등을 상세하게 명시


6. 디자인 패턴 – BPermalink

- 디자인 패턴의 개요Permalink

  • 세부적인 구현 방안을 설계할 때 참조할 수 있는 전형적인 해결 방식
  • 재사용할 수 있는 기본형 코드들이 포함
  • 디자인 패턴을 참고하여 적용하는 것이 더 효율적
  • Don’t reinvent the wheel
  • 유사한 형태의 다른 패턴으로 변화되는 특징

- 아키텍처 패턴 vs 디자인 패턴Permalink

아키택처 디자인
상위수준 설계 하위수준 설계
전체 시스템 구조 설계 서브시스템에 속하는 컴포넌트들과 그 관계 설계

- 생성 패턴(Creational Pattern)Permalink

  • 객체의 생성과 관련된 패턴
  • 객체의 생성과 참조 과정을 캡슐화하여 프로그램에 유연성을 더해줌

@ 추상 팩토리(Abstract Factory)Permalink

  • 인터페이스를 통해 서료 연관, 의존하는 객체들의 그룹으로 생성하여 추상적으로 표현
  • 연관된 서브 클래스를 묶어 한 번에 교체하는 것이 가능

@ 빌더(Builder)Permalink

  • 작게 분리된 인스턴스를 건축 하듯이 조합하여 객체 생성
  • 동일한 객체 생성에서도 서로 다른 결과를 만들어 낼 수 있음

@ 팩토리 메소드(Factory Method)Permalink

  • 객체 생성을 서브클래스에서 처리하도록 분리하여 캡슐화
  • 상위클래스에서는 인터페이스 정의하고 실제 생성은 서브 클래스가 담당

@ 프로토타입(Prototype)Permalink

  • 원본 객체를 복제하는 방법으로 객체를 생성
  • 비용이 큰 경우 이용

@ 싱글톤(Singleton)Permalink

  • 객체를 생성하면 어디서든 참조할 수 있지만, 여러 프로세스가 동시 참조 불가
  • 클래스 내에서 인스턴스가 하나뿐임을 보장, 불필요한 메모리 낭비 최소화

- 구조 패턴(Structural Pattern)Permalink

  • 클래스나 객체들을 조합하여 더 큰 구조로 만들 수 있게 해주는 패턴
  • 구조가 복잡한 시스템을 개발하기 쉽게 도와줌

@ 어댑터(Adapter)Permalink

  • 인터페이스를 다른 클래스가 이용할 수 있도록 변환
  • 인터페이스가 일치하지 않을 때 이용

@ 브리지(Bridge)Permalink

  • 서로가 독립적으로 확장할 수 있도록 구성한 패턴
  • 기능과 구현을 두 개의 별도 클래스로 구현

@ 컴포지트(Composite)Permalink

  • 복합 객체와 단일 객체를 구분 없이 다루고자 할 때 사용
  • 객체를 트리구조로 구성

@ 데코레이터(Decorator)Permalink

  • 객체 간의 결합을 통해 능동적으로 기능들을 확장
  • 부가적인 기능을 추가하기 위해 다른 객체들을 덧붙이는 방식

@ 퍼싸드(Facade)Permalink

  • 상위에 인터페이스를 구성함으로써 서브 클래스의 기능을 간편하게 사용할 수 있도록 함
  • 통합 인터페이스를 제공하는 Wrapper 객체가 필요

@ 플라이웨이트(Flyweight)Permalink

  • 매번 생성하는 것이 아니고 가능한 한 공유해서 사용해 메모리 절약
  • 다수의 유사 객체를 생성하거나 조작할 때 유용

@ 프록시(Proxy)Permalink

  • 접근이 어려운 객체와 여기에 연결하려는 객체 사이에서 인터페이스 역할
  • 네트워크 연결, 메모리의 대용량 객체로의 접근 등에 이용

- 행위 패턴(Behavioral Pattern)Permalink

  • 클래스나 객체들이 서로 상호작용하는 방법이나 책임 분배 방법을 정의
  • 하나의 객체로 수행할 수 없는 작업을 여러 객체로 분배하면서 결합도를 최소화하도록 도움

@ 책임 연쇄(Chain of Responsibility)Permalink

  • 객체가 둘 이상 존재하여 한 객체가 처리하지 못하면 다음 객체로 넘어가는 형태

@ 커맨드(Command)Permalink

  • 요청을 객체의 형태로 캡슐화하여 재이용하거나 취소할 수 있도록 요청에 필요한 정보를 저장
  • 추상 클래스와 구체 클래스로 분리하여 단순화

@ 인터프리터(Interpreter)Permalink

  • 언어에 문법 표현을 정의하는 패턴
  • SQL이나 통신 프로토콜과 같은 것을 개발할 때 사용

@ 반복자(Iterator)Permalink

  • 접근이 잦은 객체에 대해 동일한 인터페이스를 사용하도록 하는 패턴
  • 내부 표현 방법의 노출 없이 순차적인 접근이 가능

@ 중재자(Mediator)Permalink

  • 복잡한 상호작용을 캡슐화하여 객체로 정의
  • 객체 사이의 의존성을 줄여 결합도 감소시킴

@ 메멘토(Memento)Permalink

  • 객체 내부 상태를 객체화함으로써 객체를 해당 시점의 상태로 돌릴 수 있는 기능 제공
  • Ctrl + Z 같은 기능 개발할 때 이용

@ 옵서저(Observer)Permalink

  • 객체의 상태가 변화하면 상속되어 있는 다른 객체들에게 변화된 상태를 전달하는 패턴
  • 분산 시스템 간에 이벤트를 생성, 발행하고, 이를 수신해야 할 때 이용

@ 상태(State)Permalink

  • 동일한 동작을 다르게 처리해야 할 때 사용하는 패턴
  • 객체 상태를 캡슐화하고 이를 참조하는 방식으로 처리

@ 전략(Strategy)Permalink

  • 동일한 계열의 알고리즘들을 개별적으로 캡슐화하여 상호 교환할 수 있게 정의하는 패턴
  • 원하는 알고리즘을 선택하여 사용할 수 있으며, 클라이언트에 영향 없이 알고리즘 변경 가능

@ 템플릿 메소드(Template Method)Permalink

  • 상위 클래스에서 골격을 정의하고, 하위 클래스에서 세부 처리를 구체화하는 패턴
  • 코드의 양을 줄이고 유지보수를 용이하게 해줌

@ 방문자(Visitor)Permalink

  • 데이터 구조에서 처리 기능을 분리하여 별도의 클래스로 구성하는 패턴
  • 분리된 처리 기능은 각 클래스를 방문하여 수행

태그:

카테고리:

업데이트:

댓글남기기