[정보처리기사: 필기] 1. 소프트웨어 설계 문제 풀이

익스트림 프로그래밍에 대해 틀린 것

1) 구체적인 실천 방법을 정의하고 있으며 개발 문서보다 소스코드에 중점을 둔다.

2) 구동 원리는 상식적인 원리와 경험을 최대한 끌어 올리는 것이다.

3) 대표적인 구조적 방법론 중 하나다.  

=> 애자일 관련

4) 소규모 개발 조직이 불확실하고 변경이 많은 요구를 접할 때 적절한 방법이다.

---

소프트웨어 설계에서 자주 발생하는 문제에 대한 일반적이고 반복적인 해결 방법

=> 디자인 패턴

---

설계 기법 중 하향식 설계 / 상향식 설계 비교로 옳지 않은 것 (X)

1) 하향식 설계: 통합 검사 시 인터페이스가 이미 정의되어 통합이 간단하다.

2) 하향식 설계: 레벨이 낮은 데이터 구조의 세부 사항은 설계초기 단게에서 필요하다.

3) 상향식 설계: 최하위 수준에서 각 모듈을 설계, 모듈 완성 후 결합해 검사한다. (맞음. 아래에서 위로 올라감)

4) 상향식 설계: 인터페이스가 성립되어 있지 않더라도 기능 추가가 쉽다.

---

UI의 종류로 멀티 터치, 동작 인식 등 유저의 자연스러운 움직임을 인식, 서로 주고받는 정보를 제공하는 UI는?

=> NUI(Natural User Interface)

---

속성과 관련된 연산을 클래스 안에 묶어 하나로 취급하는 것을 의미하는 객체지향 개념

=> Encapsulation

---

UML 다이어그램 중 정적 다이어그램이 아닌 것

1) 순차 다이어그램  => 동적 다이어그램(행위 다이어그램에 해당됨)

2) 배치 다이어그램

3) 컴포넌트 다이어그램

4) 패키지 다이어그램

---

유스케이스 다이어그램에 대해 틀린 것 (X)

1) 시스템 액터는 다른 프로젝트에서 이미 개발되어 사용되고 있으며 본 시스템과 데이터를 주고받는 등 서로 연동되는 시스템을 말한다.

2) 유스케이스는 사용자 측면에서의 요구사항으로 유저가 원하는 목표를 달성하기 위해 수행할 내용을 기술한다.

3) 시스템과 상호작용하는 외부시스템은 액터로 파악해서는 안된다.

4) 액터가 인식할 수 없는 시스템 내부 기능을 하나의 유스케이스로 파악해서는 안된다.

---

객체지향 개념에서 다형성에 대해 틀린 것 (X)

1) 메소드 오버로딩: 매개 변수 타입은 동일하지만 메소드명을 다르게 해 구현, 구분한다.

=> 동일한 메소드명이지만 매개 변수의 유형과 갯수를 다르게 해 구현, 구분한다.

2) 메소드 오버라이딩: 상위 클래스에서 정의한 일반 메소드의 구현을 하위 클래스에서 무시하고 재정의한다.

3) 다형성: 현재 코드를 변경하지 않고 새로운 클래스를 쉽게 추가한다.

4) 다형성: 여러 형태를 가진다는 의미로 여러 형태를 받아들일 수 있는 특징을 말한다.

---

유스케이스의 구성 요소 간의 관계에 포함되지 않은 것 (X)

1) 확장

2) 연관

3) 일반화

4) 구체화

---

자료흐름도의 각 요소별 표기 형태의 연결이 옳지 않은 것 (X)

1) Terminator: 사각형

2) Process: 원

3) Data Store: 삼각형 => 평행선

4) Data Flow: 화살표

---

MVC와 관련된 설명으로 틀린 것 (X)

1) MVC 모델: UI를 담당하는 계층의 응집도를 높이고 여러 개의 다른 UI를 만들어 결합도를 낮출 수 있다.

2) 제어는 모델에 명령을 보내 모델의 상태를 변경할 수 있다.

3) 모델은 뷰와 제어 사이에서 전달자 역할을 하며, 뷰마다 모델 서브 시스템이 각각 하나씩 연결된다.

=> 전달자 역할은 '제어'가 한다. 

4) 뷰는 모델에 있는 데이터를 UI에 보이는 역할을 담당한다.

---

클래스 설계 원칙에 대해 바른 설명

1) 의존관계 역전의 원칙: 클라이언트는 자신이 사용하는 메서드와 의존관계를 갖지 않도록 해야한다.

=> 상위 모듈은 하위 모듈에 종속되지 않고 추상화에 의존해야 하며, 추상화는 세부사항에 의존하지 않는다.

2) 개방-폐쇄의 원칙: 클래스는 확장에 열려 있고 변경에 닫혀 있어야 한다.

3) 단일 책임원칙: 하나의 클래스만 변경 가능해야 한다.

=> 하나의 클래스는 하나의 책임을 가져야 한다. 클래스가 변경될 이유는 하나여야 한다.

4) 리스코프 교체의 원칙: 여러 개의 책임을 가진 클래스는 하나의 책임을 가진 클래스로 대체되어야 한다.

=> 다형성과 상속의 이유를 지켜라. 서브 타입은 언제나 기반 타입으로 교체할 수 있다.

---

GoF(Gang of Four) 디자인 패턴을 생성, 구조, 행동 패턴의 3그룹으로 분류할 때 구조 패턴이 아닌 것 (X)

1) Bridge 패턴 (구조)

2) Adapter 패턴 (구조)

3) Builder 패턴 => (생성)

4) Proxy 패턴 (구조)