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

51. 객체지향기법의 접근 제한자

• JAVA 접근 제한자(접근 지정자)
  • private : 클래스를 선언하고, 그 클래스를 구성하는 객체에 대해 외부에서는 사용이 불가, 해당 클래스에서만 접근이 가능
  • public : 클래스를 선언하고, 그 클래스를 구성하는 객체에 대해 외부에서는 사용이 가능
  • protected : 클래스를 선언하고, 그 클래스를 구성하는 객체에 대해 동일 패키지 내에서만 접근이 가능
• 접근 제한자 사용 효과 
  • JAVA : 정보은닉을 위해 다른 객체에게 자신의 정보를 숨기고 자신의 연산만을 통해 접근하도록 함
  • 캡슐화된 클래스를 선언 시, 그 클래스를 구성하는 속성, 메소드에 대하여 private, public, protected 접근 제한자를 선언하여 정보 은닉을 실현
  • 이를 통해 유지보수와 소프트웨어 확장 시 오류를 최소화할 수 있음

52. 유즈케이스 구현에 필요한 분석클래스

• 하나의 유즈케이스를 실현하기 위하여 3개 이상의 클래스가 역할 기준으로 도출되어야 함
• 유즈케이스 별로 실현에 필요한 클래스가 추적 가능해야 클래스 누락 여부를 확인할 수 있음
• 유즈케이스 별로 도출된 분석클래스들이 역할 기준으로 경계, 엔터티, 제어 클래스가 도출되어 스테레오 타입으로 표시되었는지 확인
• 분석 클래스의 종류
  • 경계클래스와 엔터티 클래스 사이에 중간 역할
  • 사용 사례의 초기에 생성되고 끝까지 존재하며 경계클래스로부터 정보를 받아 엔터티클래스에 전달1. 객체지향기법의 접근 제한자
• 엔터티 클래스

  • 

  • 시스템에서 계속 추적해야 할 자료가 들어 있는 클래스
  • 책 주문 정보는 데이터베이스에 계속 저장하고 취소하더라도 주문내역으로 저장할만한 자료이므로 엔터티클래스에 해당
  • 고객, 주문 아이템에 관한 데이터 등도 영구적으로 시스템에서 기록되어야 할 자료이므로 엔터티클래스로 분류
• 경계 클래스

  • 

  • 주로 시스템 외부의 액터와 상호작용하는 클래스로 사용자 인터페이스를 제어하는 역할
  • 액터와 연결된 시스템 인터페이스를 나타내며 각 사용 사례에서 액터는 적어도 하나의 경계 클래스와 인터페이스
  • 액터로부터 정보를 수집하여 엔터티 객체나 제어 객체가 사용할 수 있는 형태로 변경
• 제어 클래스

  • 

  • 경계클래스와 엔터티 클래스 사이에 중간 역할
  • 사용 차례의 초기에 생성되고 끝까지 존재하며 경계클래스로부터 정보를 받아 엔터티 클래스에 전달

53. 유즈케이스 구현에 필요한 분석클래스-경계 클래스

• 경계 클래스

  • 

  • 주로 시스템 외부의 액터와 상호작용하는 클래스로 사용자 인터페이스를 제어하는 역할
  • 액터와 연결된 시스템 인터페이스를 나타내며 각 사용 사례에서 액터는 적어도 하나의 경계 클래스와 인터페이스
  • 액터로부터 정보를 수집하여 엔터티 객체나 제어 객체가 사용할 수 있는 형태로 변경

54. 유즈케이스 구현에 필요한 분석클래스-앤터티클래스

• 엔터티 클래스

  • 

  • 시스템에서 계속 추적해야 할 자료가 들어 있는 클래스
  • 책 주문 정보는 데이터베이스에 계속 저장하고 취소하더라도 주문내역으로 저장할만한 자료이므로 엔터티클래스에 해당
  • 고객, 주문 아이템에 관한 데이터 등도 영구적으로 시스템에서 기록되어야 할 자료이므로 엔터티클래스로 분류

55. 애자일 방법론

• 어느 특정 개발 방법론은 가리키는 말은 아님
• 애자일 개발을 가능하게 해주는 다양한 방법론 전체
• 지속적인 요구사항의 분석, 반영을 통해 변화에 신속하게 대응하는 개발방법론
• 소프트웨어 개발 방법에 있어서 아무런 계획이 없는 개발 방법과 계획이 지나치게 많은 개발 방법들 사이에서 타협점을 찾고자 등장하게 된 방법론
• 애자일 방법론의 테스트는 잦은 개발-테스트 주기를 통해 많은 시간과 비용이 들어가기 전에 기능을 검증하게 됨
• 애자일 선언문 : 가치 있게 여기는 사항
  • 공정과 도구보다 개인과 상호작용
  • 포괄적인 문서보다 작동하는 소프트웨어
  • 계약 협상보다 고객과의 협력
  • 계획을 따르기보다 변화에 대응하는 가치

57. XP 방법론

• 의사소통 개선과 즉각적인 피드백에 의한 단순한 코딩으로 S/W 품질을 높이기 위한 방법
• 1~3주 반복주기 iteration
• 5가지 가치 : 용기, 단순성, 의사소통, 피드백, 존경
• 12개 실천항목

60. 애자일 방법론

• XP (eXtreme Programming)
  • 의사소통 개선과 즉각적인 피드백에 의한 단순한 코딩으로 S/W 품질을 높이기 위한 방법
  • 1~3주 반복주기 iteration
  • 5가지 가치 : 용기, 단순성, 의사소통, 피드백, 존경
  • 12개 실천항목

• SCRUM
  • 매일 정해진 시간에 정해진 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심의 방법론
  • 30일마다 동작 가능한 제품을 제공하는 스프린트
  • 백로그 : 제품과 프로젝트에 대한 요구사항
  • 스프린트 : 30일 단위의 짧은 개발기간으로 분리하여 반복적 수행
  • 스크럼미팅 : 매일 스크럼(15분 정도) 미팅으로 오늘과 내일 해야 할 일의 계획 수립
  • 스크럼마스터 : 프로젝트 리더, 스크럼 수행 시 문제 인지 및 이를 해결하고 노력하는 사람
• Lean
  • 린 시스템의 품질 기법을 소프트웨어 개발 프로세스에 적용하여 프로세스의 낭비 요소를 제거 후 결과를 측정, 성과를 분석하여 소프트웨어의 품질을 향상시키는 개발방법론
  • 7가지 원칙 : 낭비 제거, 품질 내재화, 지식 창출, 늦은 확정, 빠른 인도, 사람 존중, 전체 최적화
• FDD (Feature Driven Development)
  • 개발을 상품이나 서비스 단위가 아니라 신규 기능 단위로 하는 개발 방법론
  • 기능별 개별적으로 수행해야 하는 구체적이고 짧은 단계의 작업
  • 하나의 기능 개발을 위해 전체 팀에서 필요한 내용을 중재하고 전체 시스템의 흐름을 정의할 수 있는 아키텍트의 역할 필요
  • 각 개발 컴포넌트별 코디네이션이 중요
  • feature마다 2주정도의 반복개발 실시
  • Peter Coad가 제창한 방법론
  • UML을 이용한 설계 기법과도 밀접한 관련을 가짐

65. 요구사항

• 요구사항 추출 : 사용자들로부터 제시되는 추상적 요구에 대해 관련 정보를 식별하고 수집하여 구체적 요구사항으로 표현하는 활동
• 요구사항 분석 : 추출된 불완전하고 추상적인 요구사항들에 대해 충돌, 중복, 누락 등에 대한 분석을 통하여 완전성과 일관성을 가지고 참여자들 사이에 동의된 요구사항을 구성하는 활동
• 요구사항 검증 : 요구사항 명세서에 사용자의 요구가 올바르게 기술되었는지에 대해 검토하고 베이스라인으로 설정하는 활동
• 요구사항 변경 관리 : 요구사항의 베이스라인을 정하고 베이스라인과 다르게 될 경우 영향분석, 수용여부 의사 결정 수행

66. UML-액티비티 다이어그램의 노드 종류

• Action / Activity : 어떤 Action이나 Action의 집합으로 동사, 명사로 명명
• Object Node : 한 Activity 에서 다른 Activity로 이어지는 정보의 흐름을 나타냄
• Control Flow : 실행 순서를 나타내는 화살표
• Object Flow : Flow of Object
• Initial Node : Activity Diagram의 시작점, Action들의 시작점
• Final Node : Activity Diagram의 종료지점, Activity Flow들이 모두 끝나는 시점
• Decision Node : 분기점
• Merge Node : Decision Path들을 하나로 모으는 노드, Decision Node로 나눠진 Control flow를 다시 합침
• Fork Node : 평행적으로 수행되는 Flow를 나누는 노드
• Join Node : Fork Node로 나눠진 Control Flow를 다시 하나로 합치는 노드

67. UML의 종류

• 구조적 다이어그램
  • class
    • 시스템 내 클래스들의 정적 구조를 표현
    • 클래스는 객체들의 집합으로 속성과 동작으로 구성
  • object
    • 클래스의 여러 객체 인스턴스를 나타내는 대신 실제 클래스를 사용
    • 관계 있는 모든 인스턴스를 표현
  • component
    • 코드 컴포넌트에 바탕을 둔 코드의 물리적 구조 표현
    • 컴포넌트는 논리적 클래스 혹은 클래스 자신의 구현에 대한 정보를 포함하고 실질적인 프로그램 작업에 사용
  • depolyment
    • 시스템 하드웨어와 소프트웨어 간의 물리적 구조를 표현
    • 실질적인 컴퓨터와 디바이스 간의 관계를 표현하는데 이용
    • 컴포넌트 사이의 종속성을 표현
  • package UML 2.0
    • 시스템 계층적인 구조 표현
    • 클래스들로 이루어진 패키지와 그들 간의 의존 관계를 보여줌
  • composite Structure UML 2.0
    • 전체 클래스 안에 각 컴포넌트 클래스 표현
    • 클래스 내부 구조 파악에 용이
• 행위 다이어그램
  • use case
    • 사용자의 입장에서 본 시스템의 행동 표현
    • 유즈케이스는 시스템의 기능적인 요구를 정의
  • state
    • 클래스의 객체가 가질 수 있는 모든 가능한 상태와 상태 간의 전이를 표현
    • 진입조건, 탈출조건, 상태전이에 필요한 사건 등 자세한 사항이 기술
    • 설계단계에서 클래스 객체의 동적인 행동 방식을 표현하는데 사용
  • activity
    • 행위의 순서적 흐름을 표시
    • 순서도나 병렬적인 처리를 요하는 행위를 표현할 때 사용
• 상호작용 다이어그램
  • sequence
    • 객체와 객체 간의 상호작용을 메시지 흐름으로 표시
    • 오브젝트 사이에 메시지를 보내는 시간, 순서를 보여주기 위해 사용
  • communication
    • 상호작용에 참여하는 객체, 컴포넌트 간의 관계를 명시적으로 표현
  • interaction overview UML 2.0
    • 활동 다이어그램과 시퀀스 다이어그램 혼합
    • 상호작용에 대한 제어흐름을 표현
  • timing UML 2.0
    • 시간적 제약과 객체상태의 변화를 표현
    • 인스턴스 간의 상태 전이와 상호작용을 시간 제약으로 표현

68. 유즈케이스 다이어그램의 구성

• 시스템 System
  • 만들고자 하는 프로그램을 나타냄
  • 유즈케이스들을 둘러싼 사각형 틀로 시스템 명칭을 안쪽 상단에 자것ㅇ
• 액터 Actor
  • 시스템의 외부에 있고 시스템과 상호작용을 하는 사람 (시스템의 기능을 사용하는 사람), 시스템 (시스템에 정보를 제공하는 또 다른 시스템)을 의미
  • 원과 선을 조합하여 사람 모양으로 표현
  • 액터명은 위나 아래에 표시하고 액터의 역할을 작성 
• 유즈케이스 Use case
  • 사용자 입장에서 바라본 시스템의 기능으로 시스템이 액터에게 제공해야 하는 기능
  • 시스템의 요구사항을 나타냄
  • 타원으로 표시하고 안쪽에 유즈케이스 명을 작성
• 관계 Relation
  • 액터와 유즈케이스 사이의 의미 있는 관계를 나타냄
  • 연관 관계, 포함 관계, 확장 관계, 일반화 관계

69. 유즈케이스 다이어그램의 관계표현 방법

• 연관 관계
  • 유즈케이스와 액터 간의 상호작용이 있음을 표현
  • 표기 : 액터와 유즈케이스 간 실선으로 연결하여 표기
• 포함 관계 
  • 하나의 유즈케이스가 다른 유즈케이스의 실행을 전제로 할 때 형성되는 관계
  • 포함되는 유즈케이스는 포함하는 유즈케이스를 실행하기 위해 반드시 실행되어야 하는 경웨 적용
  • 포함하는 유즈케이스에서 포함되는 유즈케이스 방향으로 화살표를 점선으로 연결하고 <<include>>라고 표기
• 확장 관계 
  • 확장 기능 유즈케이스와 확장 대상 유즈케이스 사이에 형성되는 관계로 확장 대상 유즈케이스를 수행 할 때 특정 조건에 따라 확장 기능 유즈케이스를 수행하는 경우에 적용
  • 확장 기능 유즈케이스에서 확장 대상 유즈케이스 반대 방향으로 화살표를 점선으로 연결하고 <<extend>>라고 표기
• 일반화 관계 
  • 유사한 유즈케이스 또는 액터를 모아 추상화한 유즈케이스 또는 액터와 연결시켜 그룹을 만들어 이해도를 높이기 위한 관계
  • 구체적인 유즈케이스에서 추상적인 유즈케이스 방향으로 끝부분이 삼각형으로 표현된 화살표를 실선으로 연결하여 표현

70. 유즈케이스 개발 범위

• 유즈케이스의 개발 범위 : 시스템을 표현하는 네모 박스 안의 유즈케이스에 해당
• 개발 범위가 아닌 것 : 액터 등

71. 유즈케이스 확장과 포함

• 포함 관계 
  • 하나의 유즈케이스가 다른 유즈케이스의 실행을 전제로 할 때 형성되는 관계
  • 포함되는 유즈케이스는 포함하는 유즈케이스를 실행하기 위해 반드시 실행되어야 하는 경웨 적용
  • 포함하는 유즈케이스에서 포함되는 유즈케이스 방향으로 화살표를 점선으로 연결하고 <<include>>라고 표기
• 확장 관계 
  • 확장 기능 유즈케이스와 확장 대상 유즈케이스 사이에 형성되는 관계로 확장 대상 유즈케이스를 수행 할 때 특정 조건에 따라 확장 기능 유즈케이스를 수행하는 경우에 적용
  • 확장 기능 유즈케이스에서 확장 대상 유즈케이스 반대 방향으로 화살표를 점선으로 연결하고 <<extend>>라고 표기

72. 유즈케이스 확장과 포함

• 포함 관계 
  • 하나의 유즈케이스가 다른 유즈케이스의 실행을 전제로 할 때 형성되는 관계
  • 포함되는 유즈케이스는 포함하는 유즈케이스를 실행하기 위해 반드시 실행되어야 하는 경웨 적용
  • 포함하는 유즈케이스에서 포함되는 유즈케이스 방향으로 화살표를 점선으로 연결하고 <<include>>라고 표기
• 확장 관계 
  • 확장 기능 유즈케이스와 확장 대상 유즈케이스 사이에 형성되는 관계로 확장 대상 유즈케이스를 수행 할 때 특정 조건에 따라 확장 기능 유즈케이스를 수행하는 경우에 적용
  • 확장 기능 유즈케이스에서 확장 대상 유즈케이스 반대 방향으로 화살표를 점선으로 연결하고 <<extend>>라고 표기

83. UI-설계 단계의 작업의 순서

• 문제 정의
  • 시스템의 목적을 기술하고 해결해야 할 문제를 정의
• 사용자 모델 정의
  • 사용자의 특성을 명확히 하지 않고는 시스템의 사용성을 확보할 수 없으므로 사용자의 특성을 결정
  • 사용자의 컴퓨터 소프트웨어와 작업에 대한 지식 정도에 따라 초보자, 중급자, 숙련자로 분류할 수 있음
• 작업 분석
  • 항상 해결해야 할 문제를 정제하고 사용자의 특징들을 상세화하여 시스템을 통해 수행해야 할 작업들을 정의
• 컴퓨터 오브젝트 및 기능 정의
  • 분석한 작업을 컴퓨터의 어떤 사용자 인터페이스를 통해 표현할 것인지를 정의
  • 실제 사용자는 시스템을 이용해 작업할 경우, 컴퓨터 오브젝트를 통해 수행
• 사용자 인터페이스 정의
  • 컴퓨터나 작업 수행 방법에 대하여 상호작용하는 오브젝트를 선택하고 시스템의 상태를 명확히 정의
  • 상호작용 오브젝트란 작업을 위한 마우스나 키보드, 스크린 등의 물리적인 입력이나 출력 디바이스를 의미
• 디자인 평가
  • 설계한 인터페이스가 분석한 작업에 맞게 잘 설계가 되었는지, 사용자의 능력이나 지식에 대해 적당한지, 사용자가 쓰기 쉽고 편리한지 등을 평가
  • 사용성 평가 실험을 통해 설계한 인터페이스에 대한 사용성 평가를 할 수 있음
  • 평가방법론 : GOMS나 휴리스틱 등 사용성 공학 방법론이 활용됨

86. UI-설계 단계의 사용자 인터페이스 정의

• 사용자 인터페이스 정의
  • 컴퓨터나 작업 수행 방법에 대하여 상호작용하는 오브젝트를 선택하고 시스템의 상태를 명확히 정의
  • 상호작용 오브젝트란 작업을 위한 마우스나 키보드, 스크린 등의 물리적인 입력이나 출력 디바이스를 의미

87. 감성공학기술

• 인간공학, 인지공학 등 인간의 특성을 파악하려는 연구에 기본을 둔 생체 측정 기술
• 인간 특성에 적합하도록 사용자 인터페이스를 실현하기 위한 기술
• 센서 공학, 퍼지 뉴럴 네트워크 기술, 신경망 기술 등 인간의 오감 센서 및 감성 처리 기술
• 산업 디자인 등의 감성 디자인 기술
• 마이크로 기구 설계, 극소 기계 으이용 등 마이크로 가공 기술
• 사용성 평가 기술, 가상현실 기술 등으로서 인간에 대한 적합성을 판단하고 새로운 감성을 창출하기 위한 기술
• 감성공학의 종류
  • 감성공학 1류
    • 인간의 감성을 형용사로 표현할 수 있다고 보고 인간의 감성 이미지를 측정하는 방법
    • 제품에 대한 이미지를 조사, 분석하여 제품의 다지인 요소와 연계시킴
  • 감성공학 2류
    • 개인의 연령, 성별 등의 개별적 특성과 생활 방식으로부터 개인이 갖고 있는 이미지를 구체화하는 방법
    • 감성의 심리적 특성을 강조한 접근 방법
    • 감성의 개인성에 중점을 둔 문화적 감성의 일부를 반영하기도 함
  • 감성공학 3류
    • 기존의 감성적 어휘 대신 공학적인 방법으로 접근하여 인간의 감각을 측정
    • 이를 바탕으로 수학적 모델을 구축하여 활용
    • 대상이 되는 제품의 물리적 특성과 인간의 감각이 객관화된 지표 사이의 연관성을 분석하여 제품 설계에 응용할 수 있으며, 측정 시 감성의 생리적 특성을 중시

96. 소프트웨어 관련 개념

• 캡슐화 Encapsulation
  • 속성(데이터)과 메서드(연산)을 하나로 묶어서 객체로 구성
  • Readability 향상 : 유지보수가 용이
  • 재사용성이 높은 S/W 개발이 가능
  • 정보은닉으로 내부 자료의 알관성이 유지됨
  • 객체 간 인터페이스를 이용, 종속성을 최소화
• 다형성 Polymorphism
  • 동일한 이름의 여러 오퍼레이션(메서드)을 다른 사양으로 정의 가능
  • 오버로딩 : 매개변수의 수 또는 타입을 달리하여 구분
  • 오버라이딩 : 부모 클래스의 메서드를 재정의
• 상속성 Inheritance
  • 부모 클래스의 속성과 메서드를 상속받아 사용
  • 부모와 자식 클래스 간의 관계가 슈퍼클래스와 서브클래스로 유지됨
  • 부모 클래스는 추상적, 자식 클래스는 구체적인 성지를 가짐

99. 소프트웨어 설계모델의 분류와 구성요소

• 구조 모델
  • 소프트웨어를 구성하는 컴포넌트들의 유형, 인터페이스, 내부 설계 구조 및 이들의 상호 연결 구조를 모델링
  • 구성요소 : 프로시저, 데이터구조, 모듈, 파일구조
  • 시스템 구조 : 구성 요소들의 연결 구조, 포함 관계
  • 정적 요소
    • 구성 요소의 유형 및 유형 계통
    • 구성 요소들의 배열, 결합 관계
    • 구성 요소들의 인터페이스
    • 구성 요소들의 상호 작용 채널
  • 동적 요소
    • 동적 생성 및 소멸
    • 동적 결합 / 연결
    • 위치 이동, 복제
• 행위 모델
  • 소프트웨어 구성요소들의 기능과 이들이 언제, 어떠한 순서로 기능을 수행하고 상호작용하는지를 모델링
  • 입출력 데이터, 데이터 흐름, 데이터 변환, 데이터 저장, 상태전이, 데이터 흐름 경로, 사건 발생 순서, 실행 경로등
  • 정적 요소
    • 입력 / 출력 데이터
    • 입출력 맵핑
    • 데이터 흐름 채널
  • 동적 요소
    • 제어
    • 상호작용 프로토콜
    • 상호 작용 실행 경로
    • 상태전이
    • 처리순서, 입출력 순서, 알고리즘