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

102. SW 아키텍처 4+1 View : 고객 요구사항을 중심으로 4가지 관점으로 소프트웨어 아키텍처를 설계하는 기법

• 사용사례관점 Use Case View : 시스템의 외부 사용자 관점에서 사용 사례들 간의 관계를 정의
• 논리관점 Logical View : 상위 수준에서 시스템의 논리적인 구조/행위를 클래스 인터페이스, 협력관계로 정의
• 구현관점 Implementation View : 독립적으로 실행되는 컴포넌트와 이들 간 관계를 정의
• 프로세스관점 Process View : 시스템의 병렬처리 및 동기화 처리를 위한 스레드와 프로세스를 정의
• 배치관점 Deployment view : 실행되는 시스템 하드웨어와 소프트웨어 관계를 정의

103. SW 아키텍처 4+1 View : 고객 요구사항을 중심으로 4가지 관점으로 소프트웨어 아키텍처를 설계하는 기법

• 사용사례관점 Use Case View : 시스템의 외부 사용자 관점에서 사용 사례들 간의 관계를 정의
• 논리관점 Logical View : 상위 수준에서 시스템의 논리적인 구조/행위를 클래스 인터페이스, 협력관계로 정의
• 구현관점 Implementation View : 독립적으로 실행되는 컴포넌트와 이들 간 관계를 정의
• 프로세스관점 Process View : 시스템의 병렬처리 및 동기화 처리를 위한 스레드와 프로세스를 정의
• 배치관점 Deployment view : 실행되는 시스템 하드웨어와 소프트웨어 관계를 정의

104. 아키텍처 스타일 / 소프트웨어 설계 패턴 / 소프트웨어 아키텍처 프레임워크

• 아키텍처 스타일 
  • 아키텍처 스타일은 아키텍처의 유형
  • 적절한 아키텍처 스타일의 선택은 대상시스템의 개발을 효율적이고 효과적으로 만들 수 있음
• 소프트웨어 설계 패턴
  • 반복적으로 발생하는 문제에 대해 미리 만들어진 솔루션
• 소프트웨어 아키텍처 프레임워크
  • IEEE1471 : 소프트웨어 구조에 대한 기술을 규정한 IEEE 표준 (ISO/IEC/IEEE 42010 표준)
  • IEEE42010 : 시스템 및 SW 엔지니어링 아키텍처 기술과 관련된 용어와 개념을 정의한 국제표준

105. 객체지향의 구성

• 클래스 Class
  • 같은 종류(또는 문제해결을 위한)의 집단에 속하는 속성과 행위를 정의한 것
  • 객체지향 프로그램의 기본적인 사용자 정의 데이터형
• 객체 Object
  • 클래스의 인스턴스
  • 자신 고유의 데이터를 가지며 클래스에서 정의한 행위를 수행
• 속성 Attribute
  • 객체의 데이터
• 메서드 Method
  • 객체의 행위 : 함수, 메서드
  • 클래스로부터 생성된 객체를 사용하는 방법
• 메시지 Message
  • 객체 간의 통신

107. 객체지향의 기법

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

109. 다형성의 기법

구분	오버로딩 Overloading	오버라이딩 Overriding
개념	하나의 클래스 내에서 같은 이름으로 여러 개의 메서드를 정의	상속관계인 상위 클래스의 메서드를 하위클래스에서 재정의
메서드명	특정 클래스 내 동일	상속관계 내 동일
매개변수개수, 타입	개수 또는 타입이 다름	반드시 동일
리턴 타입	상관없음	기본적으로 동일
접근제한	상관없음	범위가 같거나 넓어야 함
Code	public class Employee{    public String name;    public int age;    //print() aptjem    public void print() {       System.out.println("이름:" + this.name + "나이는" + this.age);    } } //Employee 상속 public class Manager extends Employee {    String jobOfManage;    //print() 메서드 오버라이딩    public void print(){       System.out.printIn("이름:" + this.name + "나이:" + this.age);       System.out.printIn("관리자" +  this.name + this.jobOfManage + "담당");    } }	public class Overloadingtest {    //test() 호출    void test(){       System.out.printIn("매개변수 없음");    }    //test에 매개변수로 int형 2개 호출    void test(int a, int b) {       System.out.printIn("매개변수" + a + "와" + b);    }    //test에 매개변수 double형 1개 호출    void test(double d){       System.out.printIn("매개변수" + d);    } }
Test Code	public class test {    public static void main(String[] args) {       //Manager 객체 생성       Manager lee = new Manager();       //변수 설정       lee.name = "홍길동";       lee.age = 30;       lee.jobOfManage="프로젝트 매니저";       //Overring된 Manager객체 print() 호출       lee.print();    } }	public class test {    public static void main(String[] args) {       //Overloadingtest 객체 생성       Overloadingtestob = new Overloadingtest();       //test() 호출       ob.test();       //test(int a, int b) 호출       ob.test(10, 20);       //test(double d) 호출       ob.test(50);       //test(double d) 호출       ob.test(123.4);    } }

111. 디자인패턴

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

115. GoF의 디자인 패턴

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

116. MVC 패턴의 구성

• 모델 Model
  • 모델의 상태에 변화가 있을 때 컨트롤러와 뷰에 이를 통보
  • 통보를 통해서 뷰는 최신의 결과를 보여줄 수 있고, 컨트롤러는 모델의 변화에 따른 적용 가능한 명령을 추가, 제거, 수정할 수 있음
  • 어떤 MVC 구현에서는 통보 대신 뷰나 컨트롤러가 직접 모델의 상태를 읽어 오기도 함
• 뷰 View
  • 사용자가 볼 결과물을 생성하기 위해 모델로부터 정보를 얻어옴
• 컨트롤러 Controller
  • 모델에 명령을 보냄으로써 모델의 상태를 변경할 수 있음
  • 컨트롤러가 관련된 뷰에 명령을 보냄으로써 모델의 표시 방법을 바꿀 수 있음

117. 인터페이스

• 내외부 인터페이스
  • 조직 내/외부에 존재하는 시스템이 연동을 통해 상호 작용하기 위한 접속 방법이나 규칙을 의미
  • 네트워크를 통해 조직 내/외부에 존재하는 시스템 간의 요구 기능을 수행하기 위해서 내외부 인터페이스 설계와 개발은 필수적
• 인터페이스 설계 능력
  • 응용 소프트웨어 개발을 위해 정의된 시스템 인터페이스 요구사항을 확인
  • 인터페이스 대상을 식별하여 인터페이스 설계서를 작성하는 능력
• 내외부 인터페이스
  • 조직 내외부에 존재화는 시스템이 연동을 통해 상호 작용하기 위한 접속 방법이나 규칙을 의미
• 내외부 인터페이스 요구 사항 분석
  • 요구 사항 정의 단계에서 정의한 기능 및 비기능 내외부 인터페이스 요구 사항을 식별하고 분류, 조직화하여 명세를 구체화하는 작업
• 내외부 인터페이스 설계
  • 네트워크를 통해 조직 내외부에 존재하는 시스템 간의 요구 기능을 구현하기 위한 설계를 의미

119. 요구공학

• 요구사항 분석
  • 요구사항들 간 상충되는 것을 해결
  • 소프트웨어 범위를 파악하며 소프트웨어가 환경과 어떻게 상호작용하는지를 이해
  • 요구사항을 정제하여 소프트웨어 요구사항을 정리하는 업무
• 요구사항 명세
  • 요구사항을 체계적으로 검토, 평가, 승인될 수 있도록 문서를 작성하는 것을 의미
  • 시스템의 정의 및 시스템 요구사항, 소프트웨어 요구사항을 작성하는 업무
• 요구사항 확인
  • 분석가가 요구사항을 이해했는지 확인이 필요
  • 요구사항 문서가 조직의 표준에 적합하고 이해 가능하며, 일관성이 있고, 완전한지 검증하는 것이 중요, 이러한 활동을 수행하는 업무

120. 요구공학의 프로세스

• 요구사항 개발의 절차 : 도출 → 분석 → 명세 → 확인
  • 도출 Elicitation
    • 소프트웨어가 해결해야 할 문제를 이해하고 요구사항이 어디에 있고, 어떻게 수집할 것인가와 관련
    • 활용기법 : 인터뷰, 시나리오, 작업분석, BPR, 프로토타이핑, RFP, 워크샵, 벤치마킹
  • 분석 Analysis
    • 요구사항들 간의 상충을 해결하고 소프트웨어의 범위를 파악하며 소프트웨어가 환경과 어떻게 상호작용하는지 이해
    • 활용기법
      • 구조적 분석 : DFD, Data Dictionary, mini Spec, ERD
      • Use Case 기반 분석 : UML, 모델링
  • 명세 Specification
    • 체계적으로 검토, 평가, 승인될 수 있는 문서를 작성하는 것
    • 활용기법 : ER 모델링, FSM, SADT (구조적 분석과 디자인 기술)
  • 확인 / 검증 Validation / Verification
    • 분석가가 요구사항을 이해했는지에 대한 확인이 필요
    • 요구사항 문서가 조직의 표준에 부합하고 이해 가능하며 일관성 있고 완전한지에 대한 검증이 중요
    • 활용기법
      • Verifiaction 검증 : 소프트웨어 개발 라이프사이클의 각 단계의 산출물이 이전 단계에서 설정된 개발규격과 요구들을 충족시키는지의 여부를 판단하기 위한 활동
      • Validation 확인 : 소프트웨어 개발 라이프사이클의 각 단계의 산출물이 최초 사용자 요구 또는 소프트웨어 요구에 적합한지를 입증하기 위한 활동
• 요구사항 관리
  • 요구사항 협상 : 가용한 자원과 수용 가능한 위험 수준에서 구현 가능한 기능을 협상하기 위한 기법
  • 요구사항 기준선 : 공식적으로 검토되고 합의된 요구사항 명세서
  • 요구사항 변경 관리 : 요구사항 기준선을 기반으로 모든 변경을 공식적으로 통제하기 위한 기법
  • 요구사항 확인 : 구축된 시스템이 이해관계자가 기대한 요구사항에 부합되는지 확인하기 위한 방법

121. 비기능적 요구사항

• 시스템 장비 구성 요구사항 : 하드웨어, 소프트웨어, 네트워크 등의 도입 장비 내역 등
• 성능 요구사항 : 처리속도 및 시간, 처리량, 동적정적 용량, 가용성 등
• 인터페이스 요구사항 : 시스템 인터페이스와 사용자 인터페이스에 대한 요구사항
• 데이터 요구사항 : 초기자료 구축 및 데이터 변환을 위한 대상, 방법, 보안이 필요한 데이터 등
• 테스트 요구사항 
• 보안 요구사항 : 정보 자산의 기밀성과 무결성을 확보하기 위해 필요한 사항
• 품질 요구사항 : 품질 항목, 품질 평가 대상 및 목표 (신뢰성, 사용성, 유지관리성 등)
• 제약사항 : 기술, 표준, 업무, 법제도 등 제약조건 등을 파악하여 기술
• 프로젝트 관리 요구사항 : 관리 방법 및 추진 단계별 수행방안에 대한 요구사항을 기술
• 프로젝트 지원 요구사항 : 지원사항 및 방안에 대한 요구사항을 기술

125. 시스템 아키텍처의 기본 요구사항

• 시스템 구성 및 동작 원리를 나타내고 있음
• 시스템 구성 요소에 대해 설계 및 구현을 지원하는 수준으로 자세히 기술 : IEEE 1471, TOGAF 등
• 구성 요소 간의 관계 및 시스템 외부 환경과의 관계가 묘사
• 요구 사양 및 시스템의 전체 수명주기를 고려
• 하드웨어와 소프트웨어를 포함하는 시스템 전체에 대한 논리적인 기능 체계와 그것을 실현하기 위한 구성 방식, 시스템의 전체적인 최적화를 목표로 함

127. 소프트웨어 아키텍처

• 소프트웨어 시스템의 구조를 비롯한 시스템 개발에 중요한 영향을 미치는 결정들
• 소프트웨어 시스템 개발에서 특정 시스템에 대하여 요구되는 기능과 품질을 확보하고 또한 소프트웨어 시스템의 구축 및 지속적인 개선이 용이하도록 하는 역할
• 소프트웨어 시스템의 컴포넌트들을 식별하고 그 속성을 정의
• 컴포넌트들 사이의 커뮤니케이션 방법 및 물리적 배치 등을 포함하는 시스템의 구조
• 이해관계자들 간의 원활한 의사소통 수단
• 소프트웨어의 복잡성 증가에 따른 해결 대안
• 시스템의 추상적인 표현을 사용하여 복잡도를 관리

129. 모듈을 제어 관련 용어

• 공유도 Fan-in : 어떤 모듈을 제어(호출)하는 상위 모듈의 개수
• 제어도 Fan-out : 어떤 모듈에 의해 제어(호출)되는 하위 모듈의 개

131. 개체정의서

• 데이터베이스 개념 모델링 단계에서 도출한 개체의 타입과 관련 속성, 식별자 등의 정보를 개괄적으로 명세화한 정의서
  • 개체 타입명 : 데이터베이스에 저장할 개체를 대표할 수 있는 이름
  • 속성 : 개체의 특징 또는 설명 정보
  • 식별자 : 해당 개체를 유일하게 식별할 수 있는 속성 (주식별자, 대체 식별자)

133. 데이터베이스 기술

• DB Link : 데이터베이스에서 제공하는 DB Link 객체를 활용한 연계 기술
• DB Connection : 송신 시스템 DB로 연결하는 DB Connection Pool을 생성하고 연계 프로그램에서 해당 DB Connection Pool을 이용하는 기술, API/OpenAPI, JDBC, Hyper Link 등
• Socket 소켓 : 통신을 위한 프로그램으로 포트를 할당하고 클라이언트의 통신 요청 시 클라이언트와 연결하는 연계 기술
• Web Service 웹 서비스 : WSDL, UDDI, SOAP 프로토콜을 이용하여 연계하는 연계 기술

135. 인터페이스 연계 서버의 기능과 관련된 장애, 오류

• 시스템 연계 과정에서 발생할 수 있는 장애나 오류의 유형
  • 연계 시스템의 장애
  • 송신 시스템의 연계 프로그램 오류 : 연계 데이터를 생성하거나 추출하는 과정, 코드 및 데이터를 변환하는 과정에서 발생할 수 있음
  • 연계 데이터 자체 오류
  • 수신 시스템의 연계 프로그램 오류 : 운영 DB에 데이터를 반영하거나 코드 및 데이터를 변환하는 과정에서 발생

136. 인터페이스 보안 코딩

• 인터페이스 보안 기능 : 아마호화 알고리즘은 DES보다는 AES 알고리즘을 적용
  • 민감정보가상화 : 인터페이스 데이터 중 민간정보(주민번호, 전화번호 등)는 비식별화 조치
  • 인증 보안 수행 : 인터페이스 수행에 필요한 인증 수행 (보안 토큰 소유 확인)
  • 이상 거래 감지 : 외부 불법 접근 시도, 무작위 공격행위 탐지 기능
  • 필드 암/복호화 : 정의된 보안 필드를 인터페이스하기 전 암/복호화
  • 필드 필터링 : 필드 필터링을 통해 필수 정보만을 제공
  • 암호화 키 전송 : UI에 Field 암호화, Hash를 위한 암호화 Key를 반환하는 기능
  • 파일 암/복호화 : 파일서버에 저장된 파일을 암/복호화하는 기능
  • 체크성 : 송/수신 시스템 간 체크성 검증하여 메시지 위변조를 확인
• 중요 인터페이스 데이터 암호화 저장
  • 개인정보, 금융정보, 패스워드 등 중요 인터페이스 정보는 암호화하여 저장
• 중요 인터페이스 데이터 암호화 전송
  • 민감한 정보를 통신 채널을 통하여 내보낼 때에는 반드시 암호화 과정을 거쳐야 하며, 필요할 경우 SSL 또는 HTTPS 등과 같은 보안 채널을 사용

137. 인터페이스 처리 유형

• 동기 거래 Sync : 요청서비스에서 응답메시지를 즉시 받아 처리하는 거래
• 비동기 거래 Async : 요청결과 수신서비스에서 응답 메시지를 대신 받아 처리
• 지연 거래 Deferred : 메시지를 수신 시스템에 일정시간을 간격을 두고 반영하는 거래
• 파일 거래 File : 송수 파일을 수신 시스템에서 Batch 처리로 반영하는 거래

138. 미들웨어 솔루션의 유형

• RPC : 응용 프로그램의 프로시저를 사용하여 원격 프로시저를 로컬 프로시저처럼 호출하는 방식의 미들웨어
• MOM : 메시지 기반의 비동기형 메시지 전달 방식 미들웨어로 서로 다른 이기종 분산 데이터 시스템의 데이터 동기를 위하여 주로 사용
• ORB : 코바 CORBA 표준 스펙을 구현한 객체지향 미들웨어
• WAS : 웹환경을 구현하기 위한 미들웨어, 기능은 자바, EJB 컴포넌트 기반으로 구현 가능
• TP-모니터 : 온라인 업무에서 트랜잭션을 처리, 감시하는 미들웨어로 사용자 수가 증가하여도 빠른 응답 속도를 유지해야 하는 업무에 적합

144. 자료 사전의 기호

• = : 자료의 정의, A는 ~로 구성
• + : 자료의 연결, A와 B를 연결
• ( ) : 자료의 생략, 없어도 되는 자료
• [ | ] : 자료의 선택, A이거나 B
• { } : 자료의 반복
• ** : 자료의 설명

145. 미들웨어 아키텍처

• DB 접속 미들웨어 : 데이터베이스 제품 제작업체에서 제공하는 어플리케이션과 데이터베이스를 연결해주는 미들웨어
• RPC : 응용 프로그램의 프로시저를 사용하여 원격 프로시저를 로컬 프로시저처럼 호출하는 방식의 미들웨어
• MOM : 메시지 기반의 비동기형 메시지 전달 방식 미들웨어로 서로 다른 이기종 분산 데이터 시스템의 데이터 동기를 위하여 주로 사용
• ORB : 코바 CORBA 표준 스펙을 구현한 객체지향 미들웨어
• WAS : 웹환경을 구현하기 위한 미들웨어, 기능은 자바, EJB 컴포넌트 기반으로 구현 가능
• TP-모니터 : 온라인 업무에서 트랜잭션을 처리, 감시하는 미들웨어로 사용자 수가 증가하여도 빠른 응답 속도를 유지해야 하는 업무에 적합

148. 동료검토 / XP의 12가지 실천사항

• 동료 검토
  • 동료 검토의 절차
    • 계획 : 관련 자료 수집, 구성원 역할 배정
    • 사전준비 : 검토 항목, 범위 설정, 검토 설명
    • 개별 검토 : 개별적 산출물 검토 진행
    • 검토 회의 : 산출물 오류, 결함, 조치 사항 회의
    • 재작업 : 오류, 결함 사항 분석, 조치
    • 후속조치 : 저자가 작성 내용 반영 여부 판별
  • 동료 검토의 구성 요소 
    • 관찰 대상 범위 : SDLC 단계별 산출물 범위 확인
    • 참여자 구성원 : 중재자, 검토자, 저자, 기록자 등
    • 체크리스트 : 산출물의 추적도, 설계 구현 내용
• XP의 12가지 실천사항 Practice
  • 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
    • 팀원들 간 커뮤니케이션을 향상시키기 위해서는 코드가 표준화된 관례에 따라 작성되어야 함