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

903. UML의 상호작용 다이어그램

• 구조적 다이어그램 (Structural) 
  • class
    • 시스템 내 클래스들의 정적 구조를 표현
    • 클래스는 객체들의 집합 : 속성 (Attribute), 동작(Behavior)으로 구성
  • object
    • 클래스의 여러 object 인스턴스를 나타내는 대신 실제 클래스 사용
    • 관계 있는 모든 인스턴스 표현
• 행위 다이어그램 (Behavioral)
  • use case
    • 사용자의 입장에서 본 시스템의 행동 표현
    • 시스템의 기능적인 요구 정의
  • state
    • 클래스가 가질 수 있는 모든 가능한 상태와 상태 간의 전이 표현
    • 진입조건, 탈출조건, 상태 전이에 필요한 사건 등 자세한 사항이 기술 설계 단계에서 클래스 객체의 동적인 행동 방식을 표현하는데 사용
  • activity
    • 작업 또는 행위의 순서적 흐름을 표시
    • 순서도나 병렬적인 처리를 필요로 하는 행위를 표현할 때 사용
• 상호작용 다이어그램 (Interaction)
  • sequence
    • 객체와 객체 간 상호작용을 메시지 흐름으로 표시
    • 오브젝트 사이에 메시지를 보내는 시간 또는 순서 표현 위해 사용
  • communication
    • 상호작용에 참여하는 객체 / 컴포넌트 간의 관계를 명시적으로 표현

905. XP의 12가지 실천사항

• Planning game
  • 사용자 스토리를 이용해서 다음 릴리즈의 범위를 빠르게 결정
  • 비즈니스 우선순위와 기술적 평가 결합
• Small / Short releases
  • 필요한 기능들만 갖춘 간단한 시스템을 빠르게 릴리즈
  • 고객이 소프트웨어가 어떻게 돌아가는지 아주 짧은 약 2주 사이클로 볼 수 있도록 자주 새로운 버전 배포 유지
• Metaphor
  • 공통의 name system 의사소통 및 공통 개념 공유
  • 전체 개발 프로세스에 걸쳐서 시스템의 동작에 대한 전체 그림을 표현하는 것
  • 이해하기 쉬운 스토리로 이루어짐
• Simple design
  • 당장 필요하지 않은 디자인 배제
  • 항상 가능한 가장 간결한 디자인 상태 유지
• TDD
  • 개발자 먼저 단위 테스트, 실제 코드를 작성하기 전에 먼저 작성함으로써 자신이 무엇을 해야하는지 스스로 깨우침
  • 고객은 기능 테스트를 작성하여 요구사항이 모두 반영되었는지를 확인
• Refactioring
  • 프로그램 기능은 변경 없이 중복/복잡성 제거, 커뮤니케이션 향상, 단순화, 유연성 추가 등을 통해 시스템 재구성
• Pair programming
  • 두 사람이 함께 프로그램 Driver / Partner
  • 모든 프로그래밍은 하나의 컴퓨터에 2명의 프로그래머가 같이 공동 작업
• Collective Code Ownership
  • 팀의 모든 프로그래머가 소스 코드에 대해서 공동 책임을 지는 것
  • 시스템에 있는 코드는 누구든지 언제라도 수정 가능
• CI
  • 컴포넌트 단위로 혹은 모듈 단위로 나누어서 개발된 소스코드들은 하나의 작업이 끝날 때마다 지속적으로 통합되고 동시에 테스트
• 40-hour-week
  • 일주일에 40시간 이상을 일하지 말도록 규칙으로 정하고 2주를 연속으로 오버타임하지 않도록 함
• Whole Team
  • 개발 효율성을 위해 고객을 프로젝트에 상주시킴
  • 고객은 스토리를 명확하게 해주고, 중요한 비즈니스 결정사항에 대해 명확한 답을 제공해주는 역할
• Coding Standard
  • 팀원들 간 커뮤니케이션을 향상시키기 위해서는 코드가 표준화된 관례에 따라 작성되어야 함

909. 주요 디자인 패턴

• Decorator 패턴 : 새로운 기능이 추가(확장)될 때마다 새로운 객체를 만들고, 이전 객체의 기능은 새로운 객체 내부에서도 그대로 유지, 보장해주는 패턴
• Singleton 패턴 : 지정한 클래스의 인스턴스가 반드시 한 개만 존재하도록 하는 패턴
• Iterator 패턴 : 집합 객체 요소들의 내부 표현 방식을 공개하지 않고, 순차적으로 접근하는 구조를 제공하는 패턴
• State 패턴 : 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들에게 통지되고, 필요 시 자동으로 내용이 갱신되는 패턴

910. 아키텍처 패턴의 종류

• 레이어 패턴 : 시스템을 계층으로 구분하여 구성하는 방법, 서로 마주보는 두 개의 계층 사이에서만 상호작용이 이루어져 변경 작업이 용이
• 클라이언트-서버 패턴 : 하나의 서버 컴포넌트와 다수의 클라이언트 컴포넌트로 구성하는 패턴
• 파이프-필터 패턴 : 데이터 스트림 절차의 각 단계를 필터 컴포넌트로 캡슐화하여 파이프를 통해 데이터를 전송하는 패턴
• 모델-뷰-컨트롤러 패턴 : 서브 시스템을 3개의 부분으로 구조화하는 패턴, 한개의 모델에 대해 여러 개의 뷰를 필요로 하는 대화형 애플리케이션에 적합
• 마스터-슬레이브 패턴 : 동일한 구조의 슬레이브 컴포넌트로 작업을 분할한 후 슬레이브 컴포넌트에서 처리된 결과물을 다시 돌려받는 방식으로 작업을 수행하는 패턴
• 브로커 패턴 : 사용자가 원하는 서비스와 특성을 브로커 컴포넌트에 요청하면 브로커 컴포넌트가 요청에 맞는 컴포넌트와 사용자를 연결, 원격 서비스 호출에 응답하는 컴포넌트들이 여러 개 있을 때 적합한 패턴
• 피어-투-피어 패턴 : 피어를 하나의 컴포넌트로 간주하는 패턴
• 이벤트-버스 패턴 : 소스가 특정 채널에 이벤트 메시지를 발행하면 해당 채널을 구독한 리스너들이 메시지를 받아 이벤트를 처리하는 방식
• 블랙보드 패턴 : 모든 컴포넌트들이 공유 데이터 저장소와 블랙보드 컴포넌트에 접근이 가능한 형태, 해결책이 명확하지 않은 문제들을 처리하는데 유용한 패턴
• 인터프리터 패턴 : 프로그램 코드와 각 라인을 수행하는 방법을 지정하고 기호마다 클래스를 갖도록 구성하는 패턴, 특정 언어로 작성된 프로그램 코드를 해석하는 컴포넌트를 설계할 때 사용

911. 소프트웨어 개발 방법

• 구조적 방법 : 구조적 분석 방법론은 도형화된 도구를 이용해 정형화된 분석 절차에 따라 사용자 요구사항을 파악하고 문서화하는 체계적 분석 방법
• 정보공학 방법 : 기업 정보 시스템에 공학적 기법을 적용하여 시스템의 계획, 분석, 설계 및 구축을 하는 데이터 (자료) 중심의 방법
• 객체지향 기법 : 분석과 설계 및 개발에 있어서 객체지향기법을 활용하여 시스템을 구축하고자 하는 방법
• CDB 방법 : 재사용이 가능한 컴포넌트의 개발 또는 상용 컴포넌트들을 조합하여 애플리케이션 개발하는 Bottom-Up 방법

913. 데이터 흐름도 (DFD) 구성 요소

• 처리 (Process) : 입력된 자료를 출력으로 변환하는 것, 프로세스, 원 안에 처리 명칭 기술
• 자료 흐름 (Data flow) : 발생시, 종착지, 처리 및 저장소 사이에서의 자료의 흐름, 화살표 위에 자료의 명칭 기술
• 자료 저장소 (Data store) : 시스템 상의 자료 저장소를 나타내며 평행선 안에 자료 저장소 명칭 기술
• 단말기 (Terminator) : 시스템에 필요한 자료가 입력되는 발생지와 시스템에서 처리된 자료가 출력되는 종착지 또는 외부에 존재하는 사람이나 조직을 나타냄, 사각형 안에 발생지나 종착지 명칭 기술

915. 요구공학 절차

• 요구사항 개발 : 요구사항 도출 → 요구사항 분석 → 요구사항 명세 → 요구사항 확인
• 요구사항 관리 : 요구사항 협상, 요구사항 기준선, 요구사항 변경 관리 등을 수행

918. CASE (Computer Aided Software Enginnering)

• 표준화 적용 (범용성, 이식성+), 문서화를 통한 품질 개선 가능
• 변경사항, 변경으로 인한 영향에 대한 추적 용이
• 명세에 대한 유지보수 비용의 축소 가능
• CASE의 분류
  • Upper CASE (상위 CASE)
    • 계획수립, 요구분석, 기본 설계 단계 : 다이어그램으로 표현
    • 모델들 사이의 모순 검사, 모델의 오류 검증, 일관성 검증 지원
    • 자료 흐름도 프로토 타이핑 작성 지원, UI 설계 지원
  • Lower CASE (하위 CASE)
    • 코드의 작성과 테스트, 문서화 과정 지원
    • 구문 중심 편집 및 정적 / 동적 테스트
    • 시스템 명세서 생성 및 소스 코드 생성 지원

919. 디자인 패턴의 분류

		생성 패턴	구조 패턴	행위 패턴
의미		객체의 생성방식을 결정하는 패턴	객체를 조직화하는데 유용한 패턴	객체의 행위를 조직, 관리, 연합하는데 사용하는 패턴
범위	클래스	Factory method	Adapter	Template method, Interpreter
	객체	Singleton	Bridge	Iterator
		Abstract Factory	Composite	Command
		Buider	Decorator	Chain of Responsibility
		Prototype	Façade	State
			Fly weight	Strategy
			Proxy	Mediator
				Memento
				Visitor
				Observer

920. 객체지향 기법

• 캡슐화 (Encapsulation)
  • 속성과 메서드를 하나로 묶어서 객체로 구성
  • Readbility 향상 : 유지보수가 용이
  • 재사용성이 높은 S/W 개발이 가능
  • 객체 간 인터페이스 이용, 종속성 최소화
• 추상화 (Abstraction)
  • 공통 성질을 추출하여 슈퍼클래스로 구성
  • 객체 중심의 안정된 모델 구축
  • 현실 세계를 자연스럽게 표현
  • 분석의 초점이 명확해짐
• 다형성 (Polymorphism)
  • 동일한 이름의 여러 오퍼레이션 (메서드)을 다른 사양으로 정의 가능
  • 오버로딩 : 매개변수의 수 또는 타입을 달리하여 구분
  • 오버라이딩 : 부모클래스의 메서드를 재정
• 정보은닉 (Information Hiding)
  • 캡슐화된 항목을 다른 객체로부터 숨김
  • 메시지 전달에 의해 다른 클래스 내의 메서드 호출
• 상속성 (Inheritance)
  • 부모 클래스의 속성과 메서드를 상속받아 사용
  • 부모와 자식 클래스 간의 관계가 슈퍼클래스와 서브클래스로 유지
  • 부모 클래스는 추상적, 자식 클래스는 구체적 성질을 가짐

921. 소프트웨어 개발 - 단위 모듈의 구현원리

• 독립성 보장
  • 낮은 결합도
  • 높은 응집도

926. 소프트웨어 형상 관리

• 형상 관리를 위하여 구성된 팀 : CCB (Configuration Control Board)

928. 해싱 함수의 오버 플로우 해결 방법

• 선형 개방 주소법
  • 충돌이 발생한 다음 위치에서 차례로 검색하여 첫번째 빈 공간에 저장
  • 레코드 전체 개수를 미리 예측 가능할 경우 적용 가능한 방법
• 체인법
  • 오버플로가 발생한 레코드를 별도의 버킷으로 연결하여 저장
  • 링크를 위한 오버 헤드 발생, 레코드 개수 예측하기 어려울 경우 적용
• 다중 해싱법 (확장 해싱)
  • 키의 처음 비트를 이용하여 디렉토리를 통해 버킷에 접근할 수 있음
  • 버킷에 오버플로가 발생할 경우 새로운 버킷을 생성하고 디렉토리의 포인터를 변경하거나 디렉토리를 확장

933. 단위 모듈 테스트 방법

• 화이트 박스 테스트
  • 단위 모듈 테스트의 가장 기본적인 방법은 모듈 내부의 소스를 보면서 수행하는 화이트 박스 테스트
  • 소스 코드를 보면서 테스트 케이스를 다양하게 만들어서 테스트할 수 있음
• 메소드 기반 테스트
  • 단위 모듈의 외부에 공개된 메소드 기반 테스트
  • 메소드에 파라미터 값을 다르게 호출하면서 다양한 테스트를 수행
• 화면 기반 테스트
  • 사용자용 화면이 있는 경우 각각의 화면 단위 모듈 개발 후 화면에 직접 데이터를 입력하여 테스트를 수행
  • 화면 기반 테스트는 화면과 연계된 서비스 컴포넌트, 비즈니스 컴포넌트 및 공통 컴포넌트를 한꺼번에 단위 테스트에 참여시킬 수 있음
  • 사용자 시나리오에 기반한 단위 모듈 테스트를 할 수 있음
• 스텁과 드라이버 활용
  • 사용자용 화면, 화면 모듈 (서비스 컴포넌트, 비즈니스 컴포넌트) 등과 같이 테스트 수행에 필요한 다른 모듈 개발이 안 된 경우 스텁과 드라이버를 활용하여 단위 테스트

934. 깊이 우선 탐색 (DFS) 기법, 너비 우선 탐색 (BFS) 기법

• 깊이 우선 탐색 (DFS) : 한 루트로 탐색하다가 특정 상황에서 최대한 깊숙이 들어가서 확인한 뒤 다시 돌아가 다른 루트로 탐색하는 방
• 너비 우선 탐색 (BFS) : Queue를 이용하는 방법, 루트 또는 임의의 노드에서 인접한 노드를 모두 탐색하는 방법

935. 해싱 함수의 종류

• 계수 분석 : 키 값을 구성하는 숫자의 분포를 파악하여 분포가 비교적 고른 자리부터 필요한 자리만큼 선택하여 레코드 주소를 결정하는 방법
• 제산법 : 키를 임의의 양의 정수로 나눈 나머지를 그 키의 레코드를 저장하는 주소로 결정하는 방법
• 중간 제곱법 : 키 값을 제곱한 값의 중간 부분 값을 선택하여 레코드 주소로 결정하는 방법
• 폴딩법 (중첩법) : 키를 여러 부분으로 나누고 나누어진 각 부분의 값을 모두 더하거나 보수를 취해 더하여 레코드 주소를 결정하는 방법
• 기수변환 : 주어진 키 값을 어떤 특정한 진법의 수로 간주하여 다른 진법으로 변환한 후 레코드 주소를 구하는 방법
• 숫자분석 : 각 숫자의 분포를 이용해서 균등한 분포의 숫자를 선택하여 사용
• 무작위 방법 : 난수를 발생, 탐색을 위한 해시의 경우 충돌이 발생하면 다음 난수를 이용하는 방법

937. 소프트웨어 테스트의 기본 7원칙

• 테스팅은 결함이 존재함을 밝히는 활동 : 테스팅은 소프트웨어의 잠재적인 결함을 줄일 수 있지만 결함이 발견되지 않아도 결함이 없다고 증명할 수 없음
• 완벽한 테스팅은 불가능 : 무한 경로, 무한 입력 값, 무한 시간이 소요되어 완벽하게 테스트할 수 없으므로 리스크 분석과 우선순위를 토대로 테스트에 집중
• 테스팅은 개발 초기에 시작 : 애플리케이션 개발 단계에 테스트를 계획하고 SDLC의 각 단계에 맞춰 전략적 접근
• 결함 집중 (파레토 법칙) : 결함의 대부분이 소수의 특정한 모듈에 집중되어 존재, 80대 20의 법칙
• 살충제 패러독스 : 동일한 테스트 케이스로 반복 실행하면 결함을 발견할 수 없으므로 주기적으로 테스트 케이스를 리뷰하고 개선
• 테스팅은 정황에 의존 : 정황과 비즈니스 도메인에 따라 테스트를 다르게 수행
• 오류 - 부재의 궤변 : 어떤 소프트웨어도 오류가 완벽하게 해소된 제품을 만들어낼 수 없음

943. 그룹 함수

• SELECT 절에 그룹함수가 사용되면 그룹 함수를 제외한 컬럼은 GROUP BY 절에 기술되어야 함

944. HAVING

• 그룹 제한 조건 명령어

946. 절차형 SQL의 기본 구성 요소

• DECLARE : 대상이 되는 프로시저, 사용자 정의함수 등을 정
• BEGIN : 프로시저, 사용자 정의함수가 실행되는 시작점  
• END : 프로시저, 사용자 정의함수가 실행되는 종료점

948. 데이터베이스 키

• 키의 특징 : 유일성, 최소성
• 기본 키 : 후보키 중에서 특별히 선정된 주키. 중복된 값을 가질 수 있음
• 대체 키 : 후보키가 둘 이상일 때 기본 키를 제외한 나머지 후보키를 의미, 보조키
• 슈퍼 키 : 한 릴레이션 내에 있는 속성들의 집합으로 구성된 키로서 릴레이션을 구성하는 모든 튜플 중 슈퍼키로 구성된 속성의집합과 동일한 값을 나타나지 않음
• 외래 키 : 다른 릴레이션 기본 키를 참조하는 속성 또는 속성들의 집합을 의미

949. 데이터 모델의 속성

• 하나의 개체는 연관된 속성들의 집합
• 독립적인 의미를 갖지 않음
• 데이터의 가장 작은 논리적 단위
• 파일 구조상의 데이터 항목 또는 데이터 필드에 해당
• 다른 속성 값으로부터 획득한 속성
• 관계 데이터베이스에서 릴레이션의 속성으로 포함시키지 않는 것을 권장
• E-R 다이어그램에서 표시 : 점선 타원으로 표현