소프트웨어 설계 · 오답노트

2025년 3회

프로토타이핑 모형(Prototyping Model)에 대한 설명으로 옳지 않은 것은?

1최종 결과물이 만들어지기 전에 의뢰자가 최종 결과물의 일부 또는 모형을 볼 수 있다.

2프로토타이핑을 수행하는 과정에서 새로운 요구사항의 반영은 불가능하다.

3프로토타입은 발주자나 개발자 모두에게 공동의 참조 모델을 제공한다.

4프로토타입은 구현 단계의 구현 골격이 될 수 있다.

정답 2번 · 프로토타이핑을 수행하는 과정에서 새로운 요구사항의 반영은 불가능하다.

핵심 해설

프로토타이핑 모형은 사용자의 요구사항이 불명확할 때 최종 제품의 일부 기능이나 화면을 미리 견본(prototype)으로 만들어 보여 주고, 그에 대한 피드백을 받아 요구사항을 구체화해 나가는 개발 모형이다. 견본 제작 → 사용자 평가 → 요구 수정의 과정을 반복하기 때문에 개발 도중에 발견된 새로운 요구사항을 적극적으로 반영하는 것이 이 모형의 존재 이유이자 가장 큰 장점이다. 따라서 '새로운 요구사항의 반영이 불가능하다'는 설명은 오히려 폭포수 모형처럼 단계가 확정된 뒤 되돌아가기 어려운 선형 모형의 특징에 가깝다. 프로토타입은 완제품이 아니라 요구 확인용 견본이므로 폐기형(throwaway)과 진화형(evolutionary)으로 나뉜다.

보기별 해설

1. 최종 결과물 일부나 모형을 미리 볼 수 있다는 점은 프로토타이핑 모형의 핵심 특징이다. 완성 전에 눈으로 확인할 수 있어 개발이 끝난 뒤에야 요구 불일치가 드러나는 위험을 줄인다.

2. 프로토타이핑 과정에서 새로운 요구사항의 반영이 불가능하다는 서술은 이 모형의 취지와 정반대이다. 프로토타이핑은 견본에 대한 사용자 평가를 반복해 요구사항을 계속 수정·추가하는 것을 전제로 하는 모형이므로 옳지 않다.

3. 프로토타입이 발주자와 개발자 모두에게 공동의 참조 모델을 제공한다는 점은 맞는 설명이다. 눈에 보이는 견본이 있으면 문서만으로 생기는 해석 차이를 줄이고 양측이 같은 대상을 놓고 의사소통할 수 있다.

4. 프로토타입이 구현 단계의 구현 골격이 될 수 있다는 것도 옳다. 프로토타입을 버리지 않고 계속 다듬어 실제 제품으로 발전시키는 진화형 프로토타이핑에서는 견본이 그대로 시스템의 뼈대가 된다.

정리

프로토타이핑 = 견본 제작 → 사용자 평가 → 요구 수정의 반복. 요구가 불명확할 때 쓰며 변경 반영이 목적이다. 변경이 어려운 것은 폭포수 모형이다.

#소프트웨어설계#요구사항

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

1Process : 원

2Data Flow : 화살표

3Data Store : 삼각형

4Terminator : 사각형

정답 3번 · Data Store : 삼각형

핵심 해설

자료 흐름도(DFD)는 시스템 안에서 자료가 어떤 경로로 흐르고 어떤 처리를 거쳐 변환되는지를 도형으로 표현한 구조적 분석 도구로, 네 가지 구성 요소를 정해진 기호로 나타낸다. 처리(Process)는 원 또는 둥근 사각형, 자료 흐름(Data Flow)은 화살표, 자료 저장소(Data Store)는 두 줄의 평행선(직선), 단말(Terminator, 외부 엔티티)은 사각형으로 그린다. 따라서 자료 저장소를 삼각형으로 연결한 것이 잘못된 짝이다. 삼각형은 DFD의 표준 기호가 아니다.

보기별 해설

1. Process는 원(또는 둥근 사각형)으로 표기하는 것이 맞다. 입력 자료를 받아 처리해 다른 형태의 출력 자료로 변환하는 기능 단위를 뜻하며, 원 안에 처리 번호와 처리 이름을 적는다.

2. Data Flow는 화살표로 표기하는 것이 맞다. 자료가 이동하는 방향을 나타내며 화살표 위에 흐르는 자료의 이름을 붙인다.

3. Data Store는 삼각형이 아니라 두 개의 평행선(직선)으로 표기한다. 파일이나 데이터베이스처럼 자료가 저장되어 머무는 장소를 뜻하며, 평행선 사이에 저장소 이름을 적는다.

4. Terminator는 사각형으로 표기하는 것이 맞다. 시스템 경계 밖에서 자료를 제공하거나 받아 가는 외부 엔티티(사용자, 다른 조직·시스템)를 의미한다.

정리

DFD 기호 — Process: 원, Data Flow: 화살표, Data Store: 평행선 두 줄, Terminator: 사각형. 삼각형은 DFD 기호가 아니다.

#소프트웨어설계

HIPO(Hierarchy Input Process Output)에 대한 설명으로 거리가 먼 것은?

1상향식 소프트웨어 개발을 위한 문서화 도구이다.

2HIPO 차트 종류에는 가시적 도표총체적, 도표세부적, 도표가 있다.

3기능과 자료의 의존 관계를 동시에 표현할 수 있다.

4보기 쉽고 이해하기 쉽다.

정답 1번 · 상향식 소프트웨어 개발을 위한 문서화 도구이다.

핵심 해설

HIPO(Hierarchy Input Process Output)는 시스템의 기능을 계층 구조로 나누고 각 기능을 입력-처리-출력의 형태로 기술하는 하향식(Top-down) 소프트웨어 개발 및 문서화 도구이다. 전체 기능을 큰 단위에서 작은 단위로 분할해 내려가므로 하향식이며, 상향식 개발 도구가 아니다. 도표는 시스템 전체 기능을 나무 구조로 보인 가시적 도표(도식 목차), 기능별 입력·처리·출력을 개괄한 총체적 도표(총괄 도표), 각 기능을 상세히 기술한 세부적 도표(상세 도표)로 구성된다. 표기가 간단해 이해와 유지보수가 쉽다는 점이 장점이다.

보기별 해설

1. 상향식 개발을 위한 문서화 도구라는 서술이 틀렸다. HIPO는 전체 기능을 상위에서 하위로 분할해 계층도로 나타내는 하향식(Top-down) 도구이므로 방향이 반대이다.

2. HIPO 차트 종류는 가시적 도표(도식 목차), 총체적 도표(총괄 도표), 세부적 도표(상세 도표) 세 가지가 맞다. 지문은 PDF 추출 과정에서 쉼표 위치가 깨졌을 뿐 내용은 옳다.

3. 기능과 자료의 의존 관계를 동시에 표현할 수 있다는 것은 HIPO의 옳은 특징이다. 각 기능 단위마다 입력(Input)·처리(Process)·출력(Output)을 함께 적으므로 어떤 기능이 어떤 자료를 쓰는지 한눈에 드러난다.

4. 보기 쉽고 이해하기 쉽다는 것도 옳은 설명이다. 기호가 단순한 계층도와 IPO 표로만 구성되어 비전문가도 읽을 수 있어 문서화와 유지보수에 유리하다.

정리

HIPO = 하향식 기능 분해 + 입력·처리·출력 문서화. 도표 3종 — 가시적(도식 목차), 총체적(총괄), 세부적(상세).

#소프트웨어설계#네트워크

그래픽 표기법을 이용하여 소프트웨어 구성 요소를 모델링하는 럼바우 분석 기법에 포함되지 않는 것은?

1객체 모델링

2기능 모델링

3동적 모델링

4분석 모델링

정답 4번 · 분석 모델링

핵심 해설

럼바우(Rumbaugh)의 객체지향 분석 기법인 OMT(Object Modeling Technique)는 시스템을 세 가지 관점의 그래픽 모델로 나누어 분석한다. 객체 모델링은 객체와 클래스, 속성, 연관 관계를 객체 다이어그램으로, 동적 모델링은 시간 흐름에 따른 상태와 사건을 상태 다이어그램으로, 기능 모델링은 자료의 변환 과정을 자료 흐름도(DFD)로 표현한다. 즉 객체·동적·기능 세 가지만이 럼바우 기법의 구성 요소이며, '분석 모델링'은 이 세 모델 어디에도 속하지 않는 명칭이다.

보기별 해설

1. 객체 모델링은 럼바우 기법의 첫 단계로 정보 모델링이라고도 한다. 시스템에 필요한 객체를 찾아 속성과 연산, 객체 사이의 관계를 객체 다이어그램으로 표현한다.

2. 기능 모델링은 럼바우 기법의 마지막 단계이다. 자료 흐름도(DFD)를 이용해 프로세스 사이에서 자료가 어떻게 흘러 어떤 값으로 변환되는지를 표현한다.

3. 동적 모델링은 럼바우 기법의 두 번째 단계이다. 상태 다이어그램(State Diagram)으로 사건(event)에 따른 객체의 상태 변화와 제어 흐름을 시간 순으로 표현한다.

4. 분석 모델링은 럼바우 OMT의 구성 요소 명칭이 아니다. 객체지향 분석 활동 전체를 가리키는 일반적인 표현일 뿐 세 모델(객체·동적·기능) 가운데 어느 것도 아니다.

정리

럼바우 OMT 3모델 = 객체(객체 다이어그램) · 동적(상태 다이어그램) · 기능(자료 흐름도). '객동기'로 암기하며 정적·분석 모델링은 없다.

#소프트웨어설계

다음 내용이 설명하는 객체지향 설계 원칙은? • 클라이언트는 자신이 사용하지 않는 메소드와 의존관계 를 맺으면 안 된다. • 클라이언트가 사용하지 않는 인터페이스 때문에 영향을 받아서는 안 된다.

1인터페이스 분리 원칙

2단일 책임 원칙

3개방 폐쇄의 원칙

4리스코프 교체의 원칙

정답 1번 · 인터페이스 분리 원칙

핵심 해설

객체지향 설계 5원칙(SOLID) 가운데 클라이언트가 자신이 사용하지 않는 메소드에 의존하지 않도록 인터페이스를 사용 목적별로 잘게 쪼개라는 원칙은 인터페이스 분리 원칙(ISP, Interface Segregation Principle)이다. 하나의 거대한 인터페이스를 여러 클라이언트가 공유하면, 자신과 무관한 메소드가 바뀌어도 재컴파일·재배포 등의 영향을 받게 되므로 이를 막자는 취지이다. 지문의 두 문장 모두 '사용하지 않는 것에 의존하지 않는다'는 ISP의 정의를 그대로 서술한 것이다.

보기별 해설

1. 인터페이스 분리 원칙(ISP)은 클라이언트가 사용하지 않는 메소드에 의존하지 않도록 인터페이스를 목적별로 분리하라는 원칙이다. 범용의 큰 인터페이스 하나보다 클라이언트별 작은 인터페이스 여러 개가 낫다고 본다.

2. 단일 책임 원칙(SRP)은 하나의 클래스가 오직 하나의 책임(변경 이유)만 가져야 한다는 원칙이다. 대상이 클래스의 책임 개수이지 클라이언트와 인터페이스의 의존 관계가 아니다.

3. 개방 폐쇄 원칙(OCP)은 소프트웨어 요소가 확장에는 열려 있고 수정에는 닫혀 있어야 한다는 원칙이다. 기능 추가 시 기존 코드를 고치지 않고 상속·구현으로 확장하라는 뜻이다.

4. 리스코프 치환 원칙(LSP)은 상위 타입 객체를 하위 타입 객체로 바꾸어도 프로그램이 정상 동작해야 한다는 원칙이다. 상속 관계에서 자식이 부모의 규약을 지켜야 함을 요구한다.

정리

SOLID — SRP(단일 책임), OCP(개방 폐쇄), LSP(리스코프 치환), ISP(인터페이스 분리), DIP(의존 역전). '사용하지 않는 메소드에 의존 금지' = ISP.

#소프트웨어설계#객체지향

N-S(Nassi-Schneiderman) Chart에 대한 설명으로 거리가 먼 것은?

1논리의 기술에 중점을 둔 도형식 표현 방법이다.

2연속선택, 및 다중 선택반복, 등의 제어 논리 구조로 표현한다.

3주로 화살표를 사용하여 논리적인 제어 구조로 흐름을 표현한다. - 1 기출문제 & 정답 년 3회 정보처리기사 필기

4조건이 복합되어 있는 곳의 처리를 시각적으로 명확히 식별하 는데 적합하다.

정답 3번 · 주로 화살표를 사용하여 논리적인 제어 구조로 흐름을 표현한다. - 1 기출문제 & 정답 년 3회 정보처리기사 필기

핵심 해설

N-S 차트(Nassi-Schneiderman Chart)는 순서도(Flowchart)의 단점을 보완하기 위해 고안된 도형식 표현 방법으로, 논리 기술에 중점을 두고 상자를 겹겹이 채워 넣는 방식으로 알고리즘을 표현한다. 순차, 선택 및 다중 선택, 반복이라는 구조적 프로그래밍의 세 가지 제어 구조만 사용하며, GOTO 같은 임의 분기를 표현할 수 없다는 것이 특징이다. 결정적으로 N-S 차트에는 화살표와 흐름선이 없고 상자의 중첩만으로 흐름을 나타내며, 화살표로 제어 흐름을 표현하는 것은 순서도(Flowchart)의 특징이다.

보기별 해설

1. 논리의 기술에 중점을 둔 도형식 표현 방법이라는 서술은 N-S 차트의 정의 그대로이다. 상자(box) 안에 처리 내용을 적고 이를 중첩시켜 프로그램 논리를 나타낸다.

2. 연속(순차), 선택 및 다중 선택, 반복의 제어 논리 구조로 표현한다는 것도 옳다. 구조적 프로그래밍의 세 가지 기본 구조만 사용하므로 논리 흐름이 명확해진다.

3. 주로 화살표를 사용해 논리적인 제어 구조의 흐름을 표현한다는 서술이 틀렸다. N-S 차트는 화살표나 흐름선을 전혀 쓰지 않고 상자의 중첩으로만 흐름을 나타내며, 화살표로 흐름을 그리는 것은 순서도(Flowchart)이다.

4. 조건이 복합된 곳의 처리를 시각적으로 명확히 식별하는 데 적합하다는 것은 N-S 차트의 장점으로 옳다. 중첩된 조건을 상자를 나눠 표현하므로 분기 조건이 겹쳐도 구조가 한눈에 드러난다.

정리

N-S 차트 = 화살표 없는 상자 중첩식 논리 표현, 순차·선택·반복 세 구조만 사용, GOTO 표현 불가. 화살표로 흐름을 그리는 것은 순서도이다.

#소프트웨어설계

럼바우(Rumbaugh)의 객체지향 분석 절차를 가장 바르게 나열한 것은?

1객체 모형 → 동적 모형 → 기능 모형

2객체 모형 → 기능 모형 → 동적 모형

3기능 모형 → 동적 모형 → 객체 모형

4기능 모형 → 객체 모형 → 동적 모형

정답 1번 · 객체 모형 → 동적 모형 → 기능 모형

핵심 해설

럼바우(Rumbaugh)의 OMT 분석 절차는 객체 모형 → 동적 모형 → 기능 모형 순서로 진행되며, 앞 글자를 따 '객동기'로 암기한다. 먼저 객체 모형에서 시스템에 존재하는 객체와 클래스, 속성, 관계를 파악해 정적 구조를 확정하고, 다음으로 동적 모형에서 그 객체들이 사건에 따라 어떤 상태로 변하는지 시간 흐름을 분석하며, 마지막으로 기능 모형에서 자료가 어떤 처리를 거쳐 변환되는지를 자료 흐름도로 정리한다. 즉 구조를 먼저 세우고 그 위에 동작과 기능을 얹는 순서이다.

보기별 해설

1. 객체 모형 → 동적 모형 → 기능 모형이 럼바우 OMT의 올바른 분석 순서이다. 정적 구조(객체 다이어그램) → 상태 변화(상태 다이어그램) → 자료 변환(자료 흐름도)의 순으로 진행하며 '객동기'로 외운다.

2. 객체 모형 → 기능 모형 → 동적 모형은 두 번째와 세 번째 단계가 뒤바뀐 순서이다. 기능 모형(DFD)은 동적 모형(상태 다이어그램) 다음에 오는 마지막 단계이다.

3. 기능 모형 → 동적 모형 → 객체 모형은 순서를 완전히 거꾸로 뒤집은 배열이다. 객체 모형이 가장 먼저 수행되어야 나머지 두 모형의 분석 대상이 정해진다.

4. 기능 모형 → 객체 모형 → 동적 모형도 시작 단계가 잘못된 배열이다. 기능 모형은 첫 단계가 아니라 객체·동적 모형을 거친 뒤 수행하는 마지막 단계이다.

정리

럼바우 분석 절차 = 객체 모형 → 동적 모형 → 기능 모형('객동기'). 객체 다이어그램 → 상태 다이어그램 → 자료 흐름도 순이다.

#소프트웨어설계#객체지향

한 모듈 내의 각 구성 요소들이 공통의 목적을 달성하기 위하여 서로 얼마나 관련이 있는지의 기능적 연관의 정도를 나타내는 것은?

1Cohesion

2Coupling

3Structure

4Unity

정답 1번 · Cohesion

핵심 해설

한 모듈 내부의 구성 요소들이 공통의 목적을 위해 얼마나 밀접하게 관련되어 있는지를 나타내는 척도는 응집도(Cohesion)이다. 응집도는 모듈 '내부'의 결속력을 재는 개념으로 높을수록 좋은 설계이며, 기능적 > 순차적 > 교환(통신)적 > 절차적 > 시간적 > 논리적 > 우연적 순으로 강하다. 이에 대비되는 개념이 모듈 '사이'의 상호 의존 정도를 재는 결합도(Coupling)로, 결합도는 낮을수록 좋다. 좋은 모듈 설계의 원칙은 '응집도는 높게, 결합도는 낮게'이다.

보기별 해설

1. Cohesion(응집도)은 한 모듈 안의 구성 요소들이 하나의 목적을 위해 얼마나 관련되어 있는지를 나타내는 기능적 연관의 정도이다. 높을수록 모듈이 단일 기능에 집중되어 좋은 설계로 평가된다.

2. Coupling(결합도)은 모듈과 모듈 사이의 상호 의존 정도를 나타내는 척도이다. 모듈 내부가 아니라 모듈 간의 관계를 재는 개념이며 낮을수록 좋은 설계이므로 문제의 정의와 다르다.

3. Structure(구조)는 시스템을 구성하는 모듈들의 배치와 계층 관계를 가리키는 일반적인 용어이다. 구조도(Structure Chart)처럼 전체 구성을 나타낼 뿐 연관의 정도를 재는 척도가 아니다.

4. Unity는 소프트웨어 모듈 평가 척도로 쓰이는 표준 용어가 아니다. 모듈의 결속 정도를 나타내는 정식 용어는 응집도(Cohesion)이다.

정리

모듈 평가 = 응집도(Cohesion, 모듈 내부 결속, 높을수록 좋음) + 결합도(Coupling, 모듈 간 의존, 낮을수록 좋음).

#소프트웨어설계

결합도(Coupling) 단계를 약한 순서에서 강한 순서로 가장 옳게 표시한 것은?

1Stamp → Data → Control → Common → Content

2Control → Data → Stamp → Common → Content

3Content → Stamp → Control → Common → Data

4Data → Stamp → Control → Common → Content

정답 4번 · Data → Stamp → Control → Common → Content

핵심 해설

결합도(Coupling)는 모듈 사이의 상호 의존 정도로, 약한 것부터 강한 것 순으로 자료(Data) → 스탬프(Stamp) → 제어(Control) → 외부(External) → 공통(Common) → 내용(Content) 결합도의 여섯 단계로 나뉜다. 필요한 값만 매개변수로 주고받는 자료 결합도가 가장 약하고, 자료구조 전체를 넘기는 스탬프, 제어 플래그를 넘겨 상대의 논리를 좌우하는 제어, 전역 변수를 공유하는 공통, 다른 모듈의 내부를 직접 참조·수정하는 내용 결합도로 갈수록 강해진다. 보기 중 이 순서를 만족하는 배열은 Data → Stamp → Control → Common → Content이다.

보기별 해설

1. Stamp → Data → Control → Common → Content는 앞의 두 단계가 뒤바뀐 배열이다. 자료구조 전체를 넘기는 스탬프 결합도보다 필요한 값만 넘기는 자료 결합도가 더 약하다.

2. Control → Data → Stamp → Common → Content는 가장 약한 것이 제어 결합도로 시작하는 잘못된 배열이다. 제어 결합도는 제어 플래그를 넘겨 상대 모듈의 흐름을 결정하므로 자료·스탬프보다 강하다.

3. Content → Stamp → Control → Common → Data는 가장 강한 내용 결합도를 맨 앞에 두고 가장 약한 자료 결합도를 맨 뒤에 둔, 사실상 순서가 뒤집힌 배열이다.

4. Data → Stamp → Control → Common → Content가 약한 순서에서 강한 순서로 올바르게 나열한 배열이다. 자료(값 전달) → 스탬프(자료구조 전달) → 제어(제어 신호 전달) → 공통(전역 변수 공유) → 내용(내부 직접 참조) 순이다.

정리

결합도 약 → 강 : 자료(Data) → 스탬프(Stamp) → 제어(Control) → 외부(External) → 공통(Common) → 내용(Content). '자스제외공내'로 암기한다.

#소프트웨어설계

Q10

UML에서 시퀀스 다이어그램의 구성 항목에 해당하지 않는 것은?

1생명선

2실행

3확장

4메시지

정답 3번 · 확장

핵심 해설

시퀀스 다이어그램(Sequence Diagram)은 객체들이 시간 순서에 따라 주고받는 메시지를 표현하는 UML 동적(행위) 다이어그램이다. 구성 요소로는 상호작용에 참여하는 객체(Actor 포함), 객체의 존재 기간을 나타내는 점선인 생명선(Lifeline), 객체가 실제로 동작 중임을 나타내는 가는 직사각형인 실행(Activation, 활성 상자), 객체 사이의 요청·응답인 메시지(Message)가 있다. '확장(extend)'은 유스케이스 다이어그램에서 유스케이스 사이의 확장 관계를 나타내는 표기이므로 시퀀스 다이어그램의 구성 항목이 아니다.

보기별 해설

1. 생명선(Lifeline)은 시퀀스 다이어그램의 구성 요소이다. 객체 아래로 뻗은 세로 점선으로 그 객체가 존재하는 기간을 나타내며, 아래로 내려갈수록 시간이 흐른다.

2. 실행(Activation)은 시퀀스 다이어그램의 구성 요소이다. 생명선 위에 겹쳐 그린 가는 직사각형으로, 객체가 메시지를 받아 실제로 작업을 수행하는 구간을 나타낸다.

3. 확장(extend)은 유스케이스 다이어그램에서 쓰이는 관계 표기이다. 특정 조건에서만 기본 유스케이스에 추가되는 선택적 기능을 나타내며, 시퀀스 다이어그램의 구성 항목이 아니다.

4. 메시지(Message)는 시퀀스 다이어그램의 핵심 구성 요소이다. 객체와 객체 사이에 오가는 요청과 응답을 가로 화살표로 표현하며, 위에서 아래로의 배치가 시간 순서를 뜻한다.

정리

시퀀스 다이어그램 구성 = 객체(Actor) + 생명선 + 실행(활성 상자) + 메시지. 확장(extend)·포함(include)은 유스케이스 다이어그램의 관계이다.

#소프트웨어설계#UML

Q11

UI의 종류로 멀티 터치(Multi-touch), 동작 인식(Gesture Recog nition) 등 사용자의 자연스러운 움직임을 인식하여 서로 주고받는 정보를 제공하는 사용자 인터페이스를 의미하는 것은?

1GUKGraphical User Interface)

2OUI(Organic User Interface)

3NUI(Natural User Interface)

4CLK(Command Line Interface)

정답 3번 · NUI(Natural User Interface)

핵심 해설

멀티 터치, 동작(제스처) 인식, 음성 인식처럼 사람의 자연스러운 신체 움직임을 그대로 입력으로 받아들이는 사용자 인터페이스를 NUI(Natural User Interface)라고 한다. 별도의 입력 장치 조작법을 배울 필요 없이 만지고 움직이는 일상적 행동만으로 조작한다는 점이 특징이다. UI 유형은 명령어를 직접 입력하는 CLI, 아이콘·창을 마우스로 조작하는 GUI, 신체 동작을 인식하는 NUI, 사물 자체가 인터페이스가 되는 OUI 순으로 발전해 왔다.

보기별 해설

1. GUI(Graphical User Interface)는 아이콘, 창, 메뉴 같은 그래픽 요소를 마우스나 키보드로 조작하는 인터페이스이다. 보기의 'GUKGraphical...'은 PDF 추출로 깨진 표기이며 올바른 표기는 GUI(Graphical User Interface)이다.

2. OUI(Organic User Interface)는 컵, 책상, 옷 같은 사물이나 자연물 자체가 입출력 장치가 되는 유기적 인터페이스이다. 모든 사물이 인터페이스가 되는 개념으로, 신체 동작 인식만을 가리키지는 않는다.

3. NUI(Natural User Interface)는 멀티 터치, 제스처, 음성처럼 사용자의 자연스러운 움직임을 인식해 상호작용하는 인터페이스이다. 별도의 조작법 학습 없이 직관적으로 사용할 수 있다는 것이 특징이다.

4. CLI(Command Line Interface)는 키보드로 명령어 문자열을 입력해 조작하는 문자 기반 인터페이스이다. 보기의 'CLK'는 PDF 추출로 깨진 표기이며 올바른 표기는 CLI이고, 동작 인식과는 정반대의 방식이다.

정리

UI 유형 — CLI(명령어 입력), GUI(아이콘·마우스), NUI(터치·제스처·음성), OUI(사물 자체가 인터페이스). 멀티 터치·동작 인식 = NUI.

#소프트웨어설계

Q12

LOC 기법에 의하여 예측된 총 라인수가 36000라인개발에, 참여할 프로그래머가 6명프로그래머들의, 평균 생산성이 월간 300라인일 때 개발에 소요되는 기간을 계산한 결과로 가장 옳은 것은?

15개월

210개월

315개월

420개월

정답 4번 · 20개월

핵심 해설

LOC(원시 코드 라인 수) 기법에서 개발 기간은 '총 라인 수 ÷ (투입 인원 × 1인당 월 생산성)'으로 구한다. 여기서 총 라인 수는 36,000라인, 참여 인원은 6명, 1인당 월 생산성은 300라인이다. 전체 팀의 월 생산량은 6명 × 300라인 = 1,800라인이므로, 개발 기간은 36,000 ÷ 1,800 = 20개월이 된다. 참고로 노력(인월, M/M)은 36,000 ÷ 300 = 120인월이며, 이를 인원 6명으로 나누어도 같은 20개월이 나온다.

보기별 해설

1. 5개월은 36,000을 7,200으로 나눈 값으로, 인원이나 생산성을 실제보다 크게 잡아야 나오는 값이다. 팀의 월 생산량 1,800라인으로는 5개월에 9,000라인밖에 만들지 못한다.

2. 10개월이 되려면 팀의 월 생산량이 3,600라인이어야 하므로 인원이 12명이거나 1인 생산성이 600라인이어야 한다. 주어진 조건(6명 × 300라인 = 1,800라인)과 맞지 않는다.

3. 15개월은 36,000 ÷ 1,800 = 20이라는 계산 결과와 어긋나는 값이다. 15개월 동안의 생산량은 1,800 × 15 = 27,000라인에 그쳐 목표 36,000라인에 미치지 못한다.

4. 20개월이 올바른 계산 결과이다. 6명 × 300라인 = 월 1,800라인이고, 36,000 ÷ 1,800 = 20이므로 개발 기간은 20개월이다.

정리

LOC 기법 — 노력(인월) = 총 라인 ÷ 1인 월 생산성, 개발 기간 = 노력 ÷ 투입 인원. 36,000 ÷ 300 = 120인월, 120 ÷ 6 = 20개월.

#소프트웨어설계#LOC

Q13

분산 시스템에서의 미들웨어(Middleware)와 관련한 설명으로 틀린 것은?

1분산 시스템에서 다양한 부분을 관리하고 통신하며 데이터를 교환하게 해주는 소프트웨어로 볼 수 있다.

2위치 투명성(Location Transparency)을 제공한다.

3분산 시스템의 여러 컴포넌트가 요구하는 재사용 가능한 서비 스의 구현을 제공한다.

4애플리케이션과 사용자 사이에서만 분산 서비스를 제공한다. 1

정답 4번 · 애플리케이션과 사용자 사이에서만 분산 서비스를 제공한다. 1

핵심 해설

미들웨어(Middleware)는 운영체제와 응용 프로그램 사이, 또는 서로 다른 이기종 시스템 사이에 위치해 통신과 데이터 교환을 중계하는 소프트웨어이다. 분산 환경에서 클라이언트와 서버, 응용 프로그램과 데이터베이스, 서로 다른 플랫폼의 컴포넌트 등 여러 구성 요소 사이를 폭넓게 연결하며, 서버의 물리적 위치를 몰라도 서비스를 이용할 수 있게 하는 위치 투명성을 제공한다. 따라서 연결 대상을 '애플리케이션과 사용자 사이'로만 한정한 설명은 미들웨어의 역할을 지나치게 좁게 서술한 것이라 틀렸다.

보기별 해설

1. 분산 시스템의 여러 부분을 관리하고 통신·데이터 교환을 해 주는 소프트웨어라는 설명은 미들웨어의 정의 그대로이다. 이기종 시스템을 이어 주는 중계 계층이 미들웨어의 본질이다.

2. 위치 투명성(Location Transparency) 제공은 미들웨어의 대표적 기능이다. 사용자나 응용 프로그램이 서비스가 어느 서버에 있는지 몰라도 이름만으로 호출할 수 있게 해 준다.

3. 분산 시스템의 여러 컴포넌트가 요구하는 재사용 가능한 서비스의 구현을 제공한다는 것도 옳다. 인증, 트랜잭션 관리, 메시지 큐잉 같은 공통 기능을 미들웨어가 대신 제공해 개발자가 매번 만들 필요가 없다.

4. 애플리케이션과 사용자 사이에서만 분산 서비스를 제공한다는 서술이 틀렸다. 미들웨어는 응용 프로그램과 응용 프로그램, 응용 프로그램과 DB, 서로 다른 플랫폼의 컴포넌트 사이 등 다양한 구간을 중계하므로 대상이 그렇게 한정되지 않는다.

정리

미들웨어 = OS와 응용 사이·이기종 시스템 사이를 중계하는 소프트웨어. 위치 투명성과 재사용 가능한 공통 서비스를 제공하며 연결 대상은 사용자-응용에 한정되지 않는다.

#소프트웨어설계

Q14

객체에게 어떤 행위를 하도록 지시하는 명령은?

1Class

2Package

3Object

4Message

정답 4번 · Message

핵심 해설

객체지향에서 객체에게 어떤 행위(연산)를 수행하라고 지시하는 명령은 메시지(Message)이다. 객체는 자신의 데이터를 캡슐화해 감추고 있으므로 다른 객체가 직접 속성을 건드릴 수 없고, 오직 메시지를 보내 해당 객체의 메소드를 호출하는 방식으로만 상호작용한다. 메시지는 수신 객체의 이름, 실행할 메소드 이름, 필요한 인자로 구성된다. 클래스는 객체의 틀, 객체는 그 틀로 만들어진 실체이며, 메시지는 그 실체들 사이를 오가는 요청이다.

보기별 해설

1. Class(클래스)는 공통 속성과 연산을 갖는 객체들을 묶어 정의한 틀이자 객체의 설계도이다. 객체를 만들어 내는 형판일 뿐 행위를 지시하는 명령이 아니다.

2. Package(패키지)는 관련 있는 클래스나 요소들을 묶어 이름 공간을 나누는 논리적 그룹 단위이다. UML에서는 패키지 다이어그램으로 표현하며 객체 간 명령과는 무관하다.

3. Object(객체)는 클래스로부터 생성된 실체로, 속성(데이터)과 메소드(연산)를 함께 갖는 독립적 단위이다. 명령을 주고받는 주체이지 명령 자체는 아니다.

4. Message(메시지)는 한 객체가 다른 객체에게 특정 연산을 수행하라고 요청하는 명령이다. 수신 객체명, 메소드명, 인자로 구성되며 객체 간 상호작용은 오직 메시지로 이루어진다.

정리

객체지향 기본 요소 — 클래스(틀), 객체(실체), 속성/메소드(구성), 메시지(객체에게 연산 수행을 지시하는 명령).

#소프트웨어설계

Q15

애자일 소프트웨어 개발 기법의 가치가 아닌 것은?

1프로세스의 도구보다는 개인과 상호작용에 더 가치를 둔다.

2계약 협상보다는 고객과의 협업에 더 가치를 둔다.

3실제 작동하는 소프트웨어보다는 이해하기 좋은 문서에 더 가 치를 둔다.

4계획을 따르기보다는 변화에 대응하는 것에 더 가치를 둔다.

정답 3번 · 실제 작동하는 소프트웨어보다는 이해하기 좋은 문서에 더 가 치를 둔다.

핵심 해설

애자일 선언문(Agile Manifesto)이 밝힌 네 가지 가치는 프로세스와 도구보다 개인과 상호작용을, 포괄적인 문서보다 작동하는 소프트웨어를, 계약 협상보다 고객과의 협력을, 계획을 따르기보다 변화에 대응하기를 더 중시한다는 것이다. 각 문장은 '오른쪽 것도 가치가 있지만 왼쪽 것에 더 가치를 둔다'는 형식이다. 따라서 '작동하는 소프트웨어보다 문서에 더 가치를 둔다'는 서술은 애자일 가치의 방향을 정확히 뒤집은 것으로, 오히려 문서 중심의 전통적 개발 방식에 해당한다.

보기별 해설

1. 프로세스의 도구보다 개인과 상호작용에 더 가치를 둔다는 것은 애자일 선언문의 첫 번째 가치이다. 정형화된 절차보다 팀원 간 대화와 협업이 문제 해결에 더 효과적이라고 본다.

2. 계약 협상보다 고객과의 협업에 가치를 둔다는 것은 애자일 선언문의 세 번째 가치이다. 계약서 문구를 다투기보다 고객을 개발 과정에 참여시켜 피드백을 받는 것을 중시한다.

3. 실제 작동하는 소프트웨어보다 이해하기 좋은 문서에 더 가치를 둔다는 서술은 애자일 가치를 거꾸로 뒤집은 것이다. 애자일 선언문은 '포괄적인 문서보다 작동하는 소프트웨어'에 더 가치를 둔다고 명시한다.

4. 계획을 따르기보다 변화에 대응하는 것에 가치를 둔다는 것은 애자일 선언문의 네 번째 가치이다. 요구 변경을 비용이 아니라 자연스러운 것으로 받아들여 짧은 반복으로 대응한다.

정리

애자일 4대 가치 — 개인·상호작용 > 프로세스·도구, 작동하는 소프트웨어 > 문서, 고객 협력 > 계약 협상, 변화 대응 > 계획 준수.

#소프트웨어설계#프로세스

Q16

GoF(Gangs of Four) 디자인 패턴의 구조 패턴에 속하지 않는 것은?

1Composite

2Observer

3Adapter

4Decorator

정답 2번 · Observer

핵심 해설

GoF 디자인 패턴은 목적에 따라 생성(Creational) 5개, 구조(Structural) 7개, 행위(Behavioral) 11개로 총 23개가 분류된다. 구조 패턴은 클래스나 객체를 조합해 더 큰 구조를 만드는 방법을 다루며 Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy가 여기 속한다. 보기 중 Observer는 한 객체의 상태 변화를 의존 객체들에게 자동으로 통지하는 행위 패턴이므로 구조 패턴에 속하지 않는다.

보기별 해설

1. Composite는 구조 패턴이다. 단일 객체와 복합 객체를 동일한 인터페이스로 다루어 트리 구조의 부분-전체 계층을 클라이언트가 구분 없이 사용할 수 있게 한다.

2. Observer는 행위(Behavioral) 패턴이다. 한 객체의 상태가 변하면 그에 의존하는 객체들에게 자동으로 통지되어 갱신되는 일대다 의존 관계를 정의하므로 구조 패턴이 아니다.

3. Adapter는 구조 패턴이다. 서로 호환되지 않는 인터페이스를 클라이언트가 기대하는 형태로 변환해 기존 클래스를 수정 없이 재사용할 수 있게 한다.

4. Decorator는 구조 패턴이다. 객체를 감싸는 방식으로 기존 코드를 변경하지 않고 실행 중에 기능을 동적으로 덧붙일 수 있게 한다.

정리

GoF 구조 패턴 7종 — Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy. Observer는 Strategy·Command 등과 함께 행위 패턴이다.

#소프트웨어설계#디자인패턴#GoF

Q17

UML에 대한 설명으로 옳지 않은 것은?

1OMG에서 만든 통합 모델링 언어로서 객체 지향적 분석설계, 방법론의 표준 지정을 목표로 한다.

2애플리케이션을 개발할 때 쉽게 이해할 수 있도록 도와 주는 여러 가지 유형의 다이어그램을 제공한다.

3실시간 시스템 및 분산 시스템과 같은 시스템의 분석과 설계에 는 사용될 수 없다.

4개발자와 고객 또는 개발자 상호 간의 의사 소통을 원활하게 할 수 있다.

정답 3번 · 실시간 시스템 및 분산 시스템과 같은 시스템의 분석과 설계에 는 사용될 수 없다.

핵심 해설

UML(Unified Modeling Language)은 OMG(Object Management Group)가 표준으로 채택한 통합 모델링 언어로, 객체지향 분석·설계 방법론의 표기법을 통일하는 것을 목표로 만들어졌다. 사물(Things), 관계(Relationships), 다이어그램(Diagrams)으로 구성되며 구조 다이어그램 7종과 행위 다이어그램 7종을 제공한다. UML은 특정 도메인에 한정되지 않는 범용 모델링 언어이므로 실시간 시스템이나 분산 시스템의 분석·설계에도 얼마든지 사용할 수 있다. 따라서 '사용될 수 없다'는 서술이 옳지 않다.

보기별 해설

1. OMG에서 만든 통합 모델링 언어로 객체지향 분석·설계 방법론의 표준 지정을 목표로 한다는 설명은 옳다. Booch, Rumbaugh, Jacobson의 방법론을 통합해 표기법을 표준화한 것이 UML이다.

2. 애플리케이션 개발 시 쉽게 이해할 수 있도록 여러 유형의 다이어그램을 제공한다는 설명도 옳다. 클래스·객체·컴포넌트·배치 등 구조 다이어그램과 유스케이스·시퀀스·상태·활동 등 행위 다이어그램을 함께 제공한다.

3. 실시간 시스템 및 분산 시스템의 분석·설계에 사용될 수 없다는 서술이 틀렸다. UML은 도메인에 구애받지 않는 범용 모델링 언어이며, 실시간·분산 시스템 모델링에도 표준적으로 사용된다.

4. 개발자와 고객, 개발자 상호 간의 의사소통을 원활하게 한다는 설명은 옳다. 표준화된 시각적 표기법을 공유함으로써 문서 해석의 차이를 줄이는 것이 UML의 주요 목적 중 하나이다.

정리

UML = OMG 표준 통합 모델링 언어. 구성은 사물·관계·다이어그램이며 도메인 제약이 없어 실시간·분산 시스템 모델링에도 사용된다.

#소프트웨어설계#UML

Q18

미들웨어(Middleware)에 대한 설명으로 틀린 것은?

1여러 운영체제에서 응용 프로그램들 사이에 위치한 소프트웨 어이다.

2미들웨어의 서비스 이용을 위해 사용자가 정보 교환 방법 등의 내부 동작을 쉽게 확인할 수 있어야 한다.

3소프트웨어 컴포넌트를 연결하기 위한 준비된 인프라 구조를 제공한다.

4여러 컴포넌트를 1 대 1, 1 대 다다, 대 다 등 여러 가지 형태로 연결이 가능하다.

정답 2번 · 미들웨어의 서비스 이용을 위해 사용자가 정보 교환 방법 등의 내부 동작을 쉽게 확인할 수 있어야 한다.

핵심 해설

미들웨어(Middleware)는 여러 운영체제 환경에서 응용 프로그램들 사이에 위치해 통신과 연계를 담당하는 소프트웨어로, 이기종 시스템을 이어 주는 인프라 역할을 한다. 미들웨어의 중요한 설계 목표는 투명성(Transparency)으로, 사용자와 응용 프로그램이 내부의 통신 방식이나 데이터 교환 절차를 몰라도 서비스를 이용할 수 있게 감추는 것이다. 따라서 '사용자가 내부 동작을 쉽게 확인할 수 있어야 한다'는 서술은 투명성 원칙과 정면으로 어긋나므로 틀렸다. 오히려 내부 동작은 드러나지 않아야 한다.

보기별 해설

1. 여러 운영체제에서 응용 프로그램들 사이에 위치한 소프트웨어라는 설명은 미들웨어의 정의로 옳다. '중간(middle)'에 놓여 서로 다른 시스템을 연결한다는 이름 그대로의 역할이다.

2. 미들웨어의 서비스 이용을 위해 사용자가 정보 교환 방법 등 내부 동작을 쉽게 확인할 수 있어야 한다는 서술이 틀렸다. 미들웨어는 통신·연계의 세부 절차를 감추는 투명성을 제공해야 하며, 사용자는 내부 동작을 몰라도 서비스를 이용할 수 있어야 한다.

3. 소프트웨어 컴포넌트를 연결하기 위한 준비된 인프라 구조를 제공한다는 설명은 옳다. 인증·트랜잭션·메시지 전달 같은 연계 기능을 미리 갖춰 두어 개발자가 직접 구현할 필요를 줄인다.

4. 여러 컴포넌트를 1대1, 1대다, 다대다 등 다양한 형태로 연결할 수 있다는 설명도 옳다. 메시지 큐나 브로커 방식을 통해 복수의 송신자와 수신자를 유연하게 연결한다.

정리

미들웨어의 핵심 성질은 투명성 — 위치·통신 방식 등 내부 동작을 감춰 사용자가 몰라도 쓸 수 있게 한다. '내부 동작을 쉽게 확인'은 오답 단골 문구이다.

#소프트웨어설계

Q19

럼바우(Rumbaugh)의 객체지향 분석 기법 중 자료 흐름도(DFD)를 주로 이용하는 것은?

1기능 모델링

2동적 모델링

3객체 모델링

4정적 모델링

정답 1번 · 기능 모델링

핵심 해설

럼바우(Rumbaugh) 객체지향 분석의 세 모델은 각각 사용하는 표기 도구가 다르다. 객체 모델링은 객체 다이어그램(클래스 다이어그램), 동적 모델링은 상태 다이어그램(State Diagram), 기능 모델링은 자료 흐름도(DFD)를 사용한다. 기능 모델링은 프로세스 사이에서 자료가 어떻게 흘러 어떤 값으로 변환되는지를 다루므로 자료의 이동과 처리를 그리는 DFD가 가장 적합하다. 따라서 자료 흐름도를 주로 이용하는 것은 기능 모델링이다.

보기별 해설

1. 기능 모델링은 자료 흐름도(DFD)를 이용해 프로세스 간 자료의 흐름과 값의 변환 과정을 표현하는 단계이다. 럼바우 분석의 마지막 단계에 해당한다.

2. 동적 모델링은 상태 다이어그램(State Diagram)을 이용해 사건에 따른 객체의 상태 변화와 시간 흐름상의 제어 흐름을 표현한다. 사용하는 도구가 자료 흐름도가 아니다.

3. 객체 모델링은 객체 다이어그램을 이용해 객체와 클래스, 속성, 연관 관계 등 시스템의 정적 구조를 표현한다. 자료의 흐름이 아니라 구조를 다루는 단계이다.

4. 정적 모델링은 럼바우 OMT의 구성 요소 명칭이 아니다. 정적 측면은 객체 모델링이 담당하므로 세 모델 어디에도 이 이름은 쓰이지 않는다.

정리

럼바우 모델별 표기 도구 — 객체 모델링: 객체(클래스) 다이어그램, 동적 모델링: 상태 다이어그램, 기능 모델링: 자료 흐름도(DFD).

#소프트웨어설계#객체지향

Q20

모듈화를 통해 분리된 시스템의 각 기능들로서브루틴서브시스템, , , 소프트웨어 내의 프로그램작업, 단위 등과 같은 의미로 사용되는 것은?

1Module

2Component

3Things

4Prototype

정답 1번 · Module

핵심 해설

모듈화(Modularization)를 통해 분리된 시스템의 각 기능 단위를 모듈(Module)이라고 하며, 서브루틴·서브시스템·프로그램·작업 단위 등이 모두 같은 의미로 쓰인다. 모듈은 독립적으로 컴파일·수정·재사용이 가능한 최소 단위로, 하나의 모듈은 하나의 기능을 수행하도록 설계하는 것이 바람직하다. 좋은 모듈은 응집도가 높고 결합도가 낮으며, 이렇게 나누면 개발과 유지보수, 오류 추적이 쉬워진다.

보기별 해설

1. Module(모듈)은 모듈화로 분리된 시스템의 기능 단위이다. 서브루틴, 서브시스템, 프로그램, 작업 단위 등과 같은 의미로 쓰이며 독립적으로 컴파일·재사용할 수 있는 최소 단위이다.

2. Component(컴포넌트)는 명세와 인터페이스만 공개하고 내부 구현은 감춘 채 독립적으로 배포·교체할 수 있는 재사용 소프트웨어 단위이다. 모듈보다 상위의 배포 가능한 부품 개념으로, 모듈화로 나뉜 기능 단위 자체를 가리키는 용어는 아니다.

3. Things(사물)는 UML의 구성 요소 중 하나로 구조 사물, 행동 사물, 그룹 사물, 주해 사물로 나뉘는 모델링 요소를 뜻한다. 모듈화의 결과 단위를 가리키는 용어가 아니다.

4. Prototype은 요구사항 확인을 위해 미리 만들어 보는 견본을 뜻하며, GoF에서는 원본을 복제해 객체를 생성하는 생성 패턴의 이름이기도 하다. 어느 쪽도 모듈화된 기능 단위와는 무관하다.

정리

모듈(Module) = 모듈화로 분리된 기능 단위(서브루틴·서브시스템·작업 단위와 동의). 좋은 모듈은 응집도 높고 결합도 낮다.

#소프트웨어설계