[정보처리기사 필기] 기출문제 - 151 ~ 200. 오답노트

153. 객체지향 설계 기법

  • 객체지향 용어
    • 추상화 Abstraction
      • 공통 성질을 추출하여 슈퍼클래스로 구성
      • 객체중심의 안정된 모델을 구축
      • 현실 세계를 자연스럽게 표현
      • 분석의 초점이 명확해짐
    • 다형성 Polymorphism
      • 동일한 이름의 여러 오퍼레이션(메서드)을 다른 사양으로 정의 가능
      • 오버로딩 : 매개변수의 수 또는 타입을 달리하여 구분
      • 오버라이딩 : 부모 클래스의 메서드를 재정의
        구분 오버라이딩 오버로딩
        개념 상속관계에서 상위 클래스의 메소드를 하위 클래스 재정의 하나의 클래스 내에서 같은 이름으로 여러 개의 메소드를 정의(다중정의)
        메소드명 상속관계 내 동일 특정클래스 내 동일
        매개변수
        개수, 타입
        반드시 동일 개수 또는 타입이 다름
        리턴 타입 기본적으로 동일 상관없음
        클래스
        다이어그램
        Fox 클래스는 Animal의 클래스를 상속받아, Bark 메소드의 파라미터 개수, 데이터형, 리턴형이 같게 정의

        같은 Dog 클래스 내에서 동일한 이름의 Bark 메소드를 두 개 만들고 메개변수를 다르게 정의



        구현코드 public class Animal {
        public void Bark() { }
        }
        public class Fox extends Animal {
        public void Bark() { }
        }
        public class Dog extends Animal {
        public void Bark() { }
        public void Bark(int volume) {
        /* 소리조절 */
        }
        }
       
    • 일반화 Generalization
      • 일반화된 사물과 좀 더 특수화된 사물과의 관계 (is - kind - of 관계)
      • 자식 객체가 부모 객체가 사용되는 어느 곳에서나 사용될 수 있다는 것을 의미 (그 반대는 성립하지 않음)
      • 부모 자식 관계를 표현할 때 일반화 사용
      • 주로 클래스와 인터페이스 사이에서 상속 관계를 보여주기 위해 사용

155. 디자인 패턴

  • GoF의 생성 패턴
    • Factroy method
      • 객체를 생성하기 위해 인터페이스를 정의하지만, 어떤 클래스의 인스턴스를 생성할지에 대한 결정은 서브 클래스가 내리도록 함
      • 다른 이름 : Virtual constructor
    • Singleton
      • 오직 한 개의 클래스 인스턴스만을 갖도록 보장, 이에 대한 전역적인 접근점을 제공
    • Abstract factory
      • 상세화된 서브 클래스를 정의하지 않고도 서로 관련성이 있거나 독립적인 여러 객체의 군을 생성하기 위한 인터페이스를 제공
      • 다른 이름 : 키트
    • Builder
      • 인스턴스를 생성자를 통해 직접 생성하지 않고, 빌더라는 내부 클래스를 통해 간접적으로 생성
    • Prototype
      • 원본을 만들어놓고 원본 객체를 복사하여 사용
  • GoF의 구조 패턴
    • Adapter
      • 클래스의 인터페이스를 사용자가 기대하는 인터페이스 형태로 적응(변환)
      • 서로 일치하지 않는 인터페이스를 갖는 클래스들을 함께 동작
      • 다른 이름 : 래퍼
    • Bridge
      • 구현에서 추상을 분리하여 각자 독립적으로 다양성을 가질 수 있도록 함
      • 다른 이름 : 핸들 / 구현부
    • Composite
      • 부분과 전체의 계층을 표현하기 위해 객체들을 모아 트리 구조로 구성
      • 사용자가 개별 객체와 복합 객체를 모두 동일하게 다룰 수 있도록 하는 패턴
    • Decorator
      • 객체에 동적으로 새로운 책임을 추가할 수 있게 함
      • 기능을 추가하려면, 서브 클래스를 생성하는 것보다 융통성 있는 방법을 제공
    • Facade
      • 서브시스템에 있는 인터페이스 집합에 통합된 하나의 인터페이스를 제공 (의사소통 및 종속성 최소화 목표)
      • 서브시스템을 좀 더 쉽게 사용하기 위해 상위수준 인터페이스 정의
    • Flyweight
      • 객체의 내부에서 참조하는 객체를 직접 만드는 것이 아니라, 없다면 만들고, 만들어져 있다면 객체를 공유하는 식으로 객체를 구성하는 방법
    • Proxy
      • 실제 기능을 수행하는 객체 대신 가상의 객체를 사용해 로직의 흐름을 제어
      • 다른 이름 : 대리자 Surrogate
  • GoF의 행위 패턴
    • Template method
      • 어떤 작업을 처리하는 일부분을 서브 클래스로 캡슈리화해 전체 일을 수행하는 구조는 바꾸지 않으면서 특정 단계에서 수행하는 명세를 변경
    • Interpreter
      • 주어진 언어에 대해서 문법을 위한 표현수단을 정의
      • 해당 언어로 된 문장을 해석하는 해석기를 사용하는 패턴
    • Interator
      • 내부 표현부를 노출하지 않고 어떤 객체집합의 원소들을 순차적으로 접근하는 방법을 제공하는 패턴
      • 다른 이름 : 커서
    • Command
      • 실행될 기능을 캡슐화함으로써 주어진 여러 기능을 실행할 수 있는 재사용성이 높은 클래스 설계 패턴
      • 다른 이름 : 작동, 트랜잭션
    • Chain of Responsibility
      • 요청을 처리하는 기회를 하나 이상의 객체에 부여하여 요청을 보내는 쪽과 받는 쪽의 결합을 피하는 패턴
      • 요청을 받는 객체를 연쇄적으로 묶고 객체를 처리할 수 있을 때까지 요청을 전달
    • State
      • 객체의 내부 상태에 따라 객체의 행위 내용을 변경
      • 다른 이름 : 상태 표현 객체
    • Strategy
      • 행위를 클래스로 캡슐화해 동적으로 행위를 자유롭게 바꿀 수 있게 해줌
      • 다른 이름 : 정책
    • Mediator
      • 한 집합에 속해 있는 객체들의 상호작용을 캡슐화하는 객체를 정의하는 패턴
      • 중재자는 객체들이 직접 서로 참조하지 않도록 함으로써 객체 간의 느슨한 연결을 촉진하며 객체들의 상호작용을 독립적으로 다양화시킬 수 있도록 해 줌
    • Memento
      • 객체의 상태 정보를 저장하고 사용자의 필요에 따라원하는 시점의 데이터를 복원할 수 있는 패턴
      • 다른 이름 : 토큰
    • Visitor
      • 객체구조를 이루는 원소에 대해 수행할 연산을 표현
      • 방문자는 연산에 적용할 원소의 클래스를 변경하지 않고 새로운 연산을 재정의할 수 있음
    • Observer
      • 한 객체의 상태 변화에 따라 다른 객체의 상태도 연동되도록 일대다 객체 의존 관계를 구성
      • 다른 이름 : 종속자, 게시-구독

156. 클래스 간의 관계

  • 일반화 관계 Generalization (IS-A)
    • 객체지향 개념에서 상속관계
    • UML에서는 일반화 관계로 모델링
    • 한 클래스가 다른 클래스를 포함하는 상위 개념
    • 상하 관계를 의미
    • 하위는 상위의 공통점을 상속
    • 클래스를 상속받아 자식 클래스에서 사용
    • 예시 : 지우개, 노트, 연필 → 학용품
  • 연관관계 Association (HAS-A)
    • 클래스들이 상호 메시지를 주고 받는 관계를 표현
    • 한 클래스가 다른 클래스와 영속적인 관계일 때 사용
    • 예시 : 부서  부서원
  • 의존관계 Dependency (use)
    • 연관관계의 특수한 형태로 한 클래스가 다른 클래스에 의존적인 연관관계를 나타낼 때 사용
    • 예시 : 주문  제품
  • 집합연관(집약관계) Aggregation
    • 연관관계의 특수한 형태로 클래스들 사이의 전체와 부분의 관계(part of)를 나타냄
    • 하나의 클래스가 다른 클래스를 포함하는 관계
    • 전체 객체의 라이프 타임과 부분 객체의 라이프타임은 독립적
    • 전체객체가 사라져도 Destroy 부분 객체는 계속 생존할 수 있음
    • 예시 : 컴퓨터 - 마우스, 모니터, 키보드, 본체
  • 복합연관(합성관계) Composition
    • 연관관계의 특수한 형태로 클래스들 사이의 전체와 부분의 관계를 나타냄
    • 전체 객체의 라이프타임과 부분 객체의 라이프타임이 동일하여, 전체 객체가 없어지면 부분 객체도 없어짐
    • 예시 : 본체 - CPU, RAM, 메인보드
  • 실체화 관계 Realization (implement)
    • 하나의 클래스가 다른 클래스를 보다 구체적으로 실체화하는 관계
    • 인터페이스 클래스를 다른 클래스가 구현해주는 관계가 좋은 관계
    • 예시 : 빌딩 컨셉 설계도

157. 스크럼의 구성 요소

  • 조직
    • Product Owner : Product backlog 정의, 우선순위 부여
    • Scrum Master : 팀원 멘토링, 기술 전파, 장애 제거
    • Scrum Team : 스프린트 기간 동안 구현할 기능 도출 및 구현 (Product Backlog 구현)
  • 산출물
    • Product backlog : 제품 요구사항 및 우선순위
    • Sprint backlog : Sprint 기간에 수행할 Task
  • Meeting
    • Sprint meeting : Sprint 목표 세우기, Product backlog로부터 Sprint 진행 항목 선택
    • Daily meeting : 매일 15분 진행 검토, 장애 확인, 문제해결
    • Sprint review : Sprint 목표 달성 검토 (작업진행과 결과물 확인)
  • Iteration
    • Sprint : 통상 4~6주 (30일) 주기 동안 개발 가능한 기능 목록, 개발과 테스트

158. 결합도의 종류

  • 자료 결합도 Data Coupling : 모듈 간의 인터페이스로 전달되는 파라미터를 통해서만 모듈 간의 상호 작용이 일어나는 경우
  • 스탬프 결합도 Stamp Coupling : 모듈 간의 인터페이스로 배열이나 오브젝트, 스트럭쳐 등이 전달되는 경우
  • 제어 결합도 Control Coupling : 단순 처리할 대상인 값만 전달되는 게 아니라 어떻게 처리를 해야 한다는 제어 요소가 전달되는 경우
  • 외부 결합도 External Coupling : 모듈에서 외부로 선언한 데이터(변수)를 다른 모듈에서 참조할 때의 경우로 외부에서 도입된 데이터 포맷, 통신 프로토콜, 또는 디바이스 인터페이스를 공유할 때 주로 발생
  • 공통 결합도 Common Coupling : 파라미터가 아닌 모듈 밖에 선언되어 있는 전역 변수를 참조하고 전역 변수를 갱신하는 식으로 상호 작용하는 경우
  • 내용 결합도 Content Coupling : 다른 모듈 내부에 있는 변수나 기능을 다른 모듈에서 사용하는 경우

168. 형상관리의 baseline

169. 형상관리의 기준선

  • 제품 베이스라인 : 테스트가 끝나고 생산된 산출물 (통합테스트 보고서, 운영전환 계획서) 통제

173. 형상관리의 기준선

  • 기능 기준선 : 사용자 요구사항이 정의되는 시점의 기준선 - 개발계획서, 형상관리 계획서 관리의 기준이 되는 기준

178. 협업 도구

구분 도구 설명
문서공유 구글 드라이브 팀원 간 또는 고객과 문서를 공유하거나 공동 작업을 할 수 있는 온라인 도구
슬라이드 온라인에서 PPT를 만들 수 있는 서비스
소스 공유 깃허브 • 많은 프로그래머들이 애용하는 공동 작업 공간
• 수많은 오픈 소스 프로젝트가 여기서 진행중
아이디어 공유 에버노트 팀원들과 중요한 아이디어 공유, 업무와 관련 있는 기사를 스크랩해서 공유하기도 함
인비전 프로그래머나 웹 디자인 전문가들이 많이 사용하는 온라인 프로토타이핑 도구
디자인 공유 레드펜 • 웹 디자인 전문가들이 사용하는 협업도구
• 자신의 디자인을 업로드하고 동료간 공동 작업
마인드 맵핑 마인드 마이스터 • 온라인 공동 마인드 맵핑 도구
• 공동으로 브레인스토밍을 하거나 정보 간 관계망 그리기를 공동으로 수행
프로젝트 관리 트렐로 • 온라인 공동 프로젝트 관리 도구
• 프로젝트의 각 과제들을 분류하고 구성원들을 배정
레드마인 다수의 프로젝트 관리 도구
지라(JIRA) 프로젝트 이슈 트래킹 기반 협업 도구
태스크월드 사용자가 자유롭게 프로젝트 일정, 팀원 설정 가능
일정관리 구글캘린더 구글의 일정 관리 서비스, 모바일과 PC 연동 가능
컨플루언스 개발자간 일정 공유 및 문서 공유 기능

188. 애플리케이션 모니터링 도구

모니터링 기능 도구(예) 설명
애플리케이션 변경관리 ChangeMiner • 애플리케이션간 종속관계를 모니터링
• 애플리케이션 변경이 있을 경우 변경의 영향도 파악에 활용
애플리케이션 성능관리 Jeniffer 애플리케이션 서버로 유입되는 트랜잭션 수량, 처리시간, 응답시간 등을 모니터링
Nmon (GPL v3) • 리눅스 서버 자원에 대한 모니터링 도구
• nmonanalyser를 이용하여 자원 사용량을 그래프로 표현할 수 있음
애플리케이션 정적분석 PMD (BSD, LGPL) • Java로 작성된 소스의 코드 잠재적인 문제 발견
• Java 코딩 규칙 오류 발견
Cppcheck (GPL v3) C / C++ 소스코드에 대한 잠재적 문제 발견
애플리케이션 동적분석 Avalcnche (GPL v2) valgrind 프레임워크와 STP를 기반으로 구현되었으며, 심각한 소프트웨어 에러 및 취약점 발견
Valgrind (GPL v2) C / C++ 기반 프로그램에 대한 메모리 및 쓰레드 문제 발견

193. 결합도 / 응집도

  • 응집도 Cohesion
    • 모듈의 독립성을 나타내는 개념
    • 하나의 모듈 내부 처리 요소들 간의 기능적 연고나도를 측정하는 척도
    • 높을수록 기능이 집적
  • 결합도 Coupling
    • 소프트웨어 구조에서 모듈 간 연관성을 측정
    • 상호의존도를 측정
    • 낮을수록 모듈 간 낮은 의존성

194. 응집도의 유형 

  • 우연적 Coincidental
    • 모듈 내부의 각 구성 요소들이 연관이 없을 경우
    • 모듈화 장점이 없음
  • 논리적 Logical
    • 유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들이 한 모듈에서 처리되는 경우
    • 모든 오류 처리를 하나의 클래스에서 수행
  • 시간적 Temporal
    • 연관된 기능이 아니고, 특정시간에 처리되어야 하는 활동들을 한 모듈에서 처리하는 경우
    • 앱 초기화 시점에 필요한 사용자 정보, 메인 페이지 구성 정보 등의 요청을 하나의 클래스에서 구현
  • 절차적 Procedural
    • 모듈이 다수의 관련 기능을 가질 때 모듈 안의 구성 요소들이 그 기능을 순차적으로 수행할 경우
    • 웹페이지 reload 시 화면 삭제 → 메뉴 표시 → 정보요청 → 페이지표시 기능을 하나의 클래스에서 수행
  • 통신적 Communication 
    • 동일한 입력과 출력을 사용하여 다른 기능을 수행하는 활동들이 모여 있을 경우
    • 시급을 사용하여 월급과 연봉을 계산하는 기능을 하나의 클래스에 구현
  • 순차적 Sequential
    • 모듈 내에서 한 활동으로부터 나온 출력값을 다른 활동의 입력값으로 사용하는 경우
    • 연봉 계산 출력 값을 세금 계산의 입력 값으로 사용하는 경우, 연봉계산, 세금계산 기능을 하나의 클래스에 구현
  • 기능적 Functional
    • 모듈 내부의 모든 기능이 단일한 목적을 위해 수행되는 경우

195. 결합도의 특징

  • 서로 다른 상위 모듈에 의해 호출되어 처리 상 연관성이 없는 서로 다른 기능수행
  • 자료전달이 인터페이스를 통과하므로 인터페이스 복잡성에 의존적
  • 가능한 낮은 결합도가 복잡성을 감소시킴 (loosely coupled)
  • 에러 발생 시 오류가 전파되어 다른 오류의 원인이 되는 리플 효과 최소화

197. 결합도의 단계

  • 결합도는 낮을수록 모듈 간 의존성이 적어져 추가, 수정, 삭제 시 오류 파급이 적고 유지보수성이 높아짐

198. 응집도의 단계

  • 응집도는 높을수록 단 하나의 기능만을 분리 구현하여 독립성이 보장, 수정 시 오류 파급이 적어 유지보수성이 높아짐

199. 결합도 / 응집도

  • 결합도는 낮을수록 응집도는 높을수록 좋음
  • 하나의 모듈은 하나의 기능만 구현되고, 모듈 간 의존도는 없는 것이 좋음