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

2025년 1회

소프트웨어 공학에서 워크스루(Walkthrough)에 대한 설명으로 틀린 것은?

1사용사례를 확장하여 명세하거나 설계 다이어그램원시코드, , 테스트 케이스 등에 적용할 수 있다.

2복잡한 알고리즘 또는 반복실시간, 동작병행, 처리와 같은 기능이나 동작을 이해하려고 할 때 유용하다.

3인스펙션(Inspection)과 동일한 의미를 가진다.

4단순한 테스트 케이스를 이용하여 프로덕트를 수작업으로 수 행해 보는 것이다.

정답 3번 · 인스펙션(Inspection)과 동일한 의미를 가진다.

핵심 해설

워크스루(Walkthrough)는 개발자가 작성한 산출물을 동료들과 함께 검토하는 비공식(informal) 검토 기법이다. 검토 자료를 회의 전에 미리 배포해 사전 검토한 뒤 짧은 회의를 열어 오류를 조기에 발견하며, 간단한 테스트 케이스를 가지고 사람이 직접 코드나 설계를 따라가 보는 방식으로 진행한다. 이에 비해 인스펙션(Inspection)은 작성자를 제외한 전문 검토 그룹이 체크리스트와 정해진 역할(중재자, 판독자, 기록자 등)에 따라 산출물을 조사하는 공식적(formal) 검토이며, 결함 기록과 후속 조치까지 절차화되어 있다. 따라서 워크스루와 인스펙션은 형식성과 참여자 구성이 다른 별개의 기법이다.

보기별 해설

1. 사용사례를 확장하여 명세하거나 설계 다이어그램, 원시코드, 테스트 케이스 등에 적용할 수 있다는 것은 워크스루의 적용 범위를 옳게 설명한 것이다. 워크스루는 코드에 국한되지 않고 요구사항·설계·테스트 산출물 전반을 대상으로 삼을 수 있다.

2. 복잡한 알고리즘 또는 반복, 실시간, 병행 동작 처리와 같은 기능이나 동작을 이해하려고 할 때 유용하다는 것도 옳은 설명이다. 사람이 직접 흐름을 따라가며 설명하고 질문하는 방식이므로 로직이 난해한 부분의 이해와 결함 발견에 효과적이다.

3. 인스펙션(Inspection)과 동일한 의미를 가진다는 설명은 틀렸다. 인스펙션은 작성자를 제외한 전문 검토 그룹이 체크리스트와 정해진 역할에 따라 수행하는 공식 검토인 반면, 워크스루는 작성자가 주도하는 비공식 검토이므로 두 기법은 구분된다.

4. 단순한 테스트 케이스를 이용하여 프로덕트를 수작업으로 수행해 보는 것이라는 설명은 워크스루의 전형적인 진행 방식이다. 도구를 돌리지 않고 검토자들이 입력값을 따라가며 결과를 추적하는 정적 검토에 해당한다.

정리

정적 검토 — 워크스루(작성자 주도, 사전 배포 후 짧은 비공식 회의) vs 인스펙션(작성자 제외 전문가 그룹의 역할 분담 공식 검토). 같은 기법이 아니다.

#소프트웨어설계#테스트

애자일 방법론에 해당하지 않는 것은?

1기능 중심 개발

2개발 및 검증

3익스트림 프로그래밍

4칸반

정답 2번 · 개발 및 검증

핵심 해설

애자일(Agile)은 짧은 반복 주기로 동작하는 소프트웨어를 만들며 변화에 대응하는 개발 철학이며, 이를 구체화한 실천 방법론에는 익스트림 프로그래밍(XP), 스크럼(Scrum), 기능 중심 개발(FDD), 칸반(Kanban), 린(Lean), 크리스탈(Crystal), ASD, DSDM 등이 있다. 이들은 모두 반복적 개발, 고객 참여, 자기 조직화된 팀 같은 애자일 가치를 공유한다. 반면 '개발 및 검증'은 특정 방법론의 이름이 아니라 개발 생명주기 안의 활동 단계를 가리키는 일반 표현이므로 애자일 방법론에 해당하지 않는다.

보기별 해설

1. 기능 중심 개발(FDD, Feature Driven Development)은 애자일 방법론의 하나이다. 사용자에게 가치 있는 기능(feature) 단위로 목록을 만들고 2주 이내의 짧은 주기로 설계·구현을 반복한다.

2. 개발 및 검증은 애자일 방법론의 명칭이 아니라 소프트웨어 생명주기에서 구현과 확인(Verification) 활동을 묶어 부르는 일반적인 단계 표현이다. 특정 방법론으로 정의된 실체가 없으므로 애자일 방법론에 속하지 않는다.

3. 익스트림 프로그래밍(XP)은 대표적인 애자일 방법론이다. 짧은 릴리즈, 페어 프로그래밍, 테스트 주도 개발, 지속적 통합 같은 12가지 실천 항목으로 요구 변화에 빠르게 대응한다.

4. 칸반(Kanban)은 애자일 방법론의 하나이다. 작업을 카드로 시각화한 보드에 올리고 진행 중 작업 수(WIP)를 제한해 흐름을 관리하는 린(Lean) 계열 기법이다.

정리

애자일 방법론 — XP, 스크럼, FDD(기능 중심 개발), 칸반, 린, 크리스탈, ASD, DSDM. '개발 및 검증'은 방법론명이 아닌 생명주기 활동 표현이다.

#소프트웨어설계

익스트림 프로그래밍에 대한 설명으로 틀린 것은?

1대표적인 구조적 방법론 중 하나이다.

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

3익스트림 프로그래밍을 구동시키는 원리는 상식적인 원리와 경험을 최대한 끌어 올리는 것이다.

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

정답 1번 · 대표적인 구조적 방법론 중 하나이다.

핵심 해설

익스트림 프로그래밍(XP, eXtreme Programming)은 켄트 벡이 제안한 애자일 방법론으로, 요구 변화가 잦고 불확실한 소규모 프로젝트에 적합하다. 의사소통·단순성·피드백·용기·존중의 5가지 가치를 바탕으로 짧은 릴리즈, 페어 프로그래밍, 테스트 주도 개발, 리팩토링, 지속적 통합, 공동 코드 소유 같은 구체적 실천 항목을 정의하며, 방대한 문서보다 동작하는 소스 코드를 중시한다. 반면 구조적 방법론은 1970~80년대의 절차 지향 개발 방법론으로 DFD·자료 사전 같은 도구를 사용하는 전통적 접근이므로 XP와는 계보가 전혀 다르다.

보기별 해설

1. 대표적인 구조적 방법론 중 하나라는 설명은 틀렸다. 구조적 방법론은 기능 분할과 DFD·자료 사전을 사용하는 절차 지향 전통 방법론이며, XP는 이와 대비되는 애자일 계열 방법론이다.

2. 소규모 개발 조직이 불확실하고 변경이 많은 요구를 접하였을 때 적절한 방법이라는 설명은 옳다. XP는 짧은 반복과 고객의 상시 참여로 요구 변화를 흡수하도록 설계되어 있다.

3. 익스트림 프로그래밍을 구동시키는 원리는 상식적인 원리와 경험을 최대한 끌어 올리는 것이라는 설명도 옳다. XP는 새로운 이론을 만든 것이 아니라 이미 좋다고 알려진 실천법을 '극단(extreme)'까지 밀어붙인 방법론이다.

4. 구체적인 실천 방법을 정의하고 있으며 개발 문서보다는 소스 코드에 중점을 둔다는 설명은 옳다. 페어 프로그래밍, 테스트 주도 개발, 리팩토링 등 실행 지침이 명확하고 산출물의 중심은 동작하는 코드이다.

정리

XP = 애자일 방법론(구조적 방법론 아님). 5가지 가치(의사소통·단순성·피드백·용기·존중) + 페어 프로그래밍·TDD·리팩토링·지속적 통합 등 실천 항목, 문서보다 코드 중심.

#소프트웨어설계

럼바우(Rumbaugh) 분석 기법에서 정보 모델링이라고도 하며시스, 템에서 요구되는 객체를 찾아내어 속성과 연산 식별 및 객체들 간의 관계를 규정하여 다이어그램을 표시하는 모델링은?

1Object

2Dynamic

3Function

4Static

정답 1번 · Object

핵심 해설

럼바우(Rumbaugh)의 OMT(Object Modeling Technique)는 분석을 객체 모델링, 동적 모델링, 기능 모델링의 세 단계로 나눈다. 이 중 객체 모델링(Object Modeling)은 정보 모델링이라고도 하며, 시스템에서 요구되는 객체를 찾아내어 속성과 연산을 식별하고 객체들 사이의 관계를 규정해 객체 다이어그램으로 표현한다. 동적 모델링은 상태 다이어그램으로 시간 흐름에 따른 상태 변화와 제어 흐름을, 기능 모델링은 자료 흐름도(DFD)로 데이터 값의 변환 과정을 표현한다. 따라서 문제의 조건에 해당하는 것은 객체(Object) 모델링이다.

보기별 해설

1. Object 모델링은 럼바우 분석의 첫 단계이자 정보 모델링이라 불리는 단계이다. 객체를 식별해 속성·연산과 객체 간 관계를 정의하고 객체 다이어그램으로 나타내므로 문제 조건과 정확히 일치한다.

2. Dynamic 모델링은 럼바우 분석의 두 번째 단계로, 시간의 흐름에 따른 객체의 상태 변화와 사건(event)에 의한 제어 흐름을 상태 다이어그램으로 표현한다. 객체의 속성과 관계를 규정하는 단계가 아니다.

3. Function 모델링은 럼바우 분석의 세 번째 단계로, 자료 흐름도(DFD)를 이용해 프로세스 간 자료의 흐름과 값의 변환 과정을 표현한다. 정보 모델링이라 불리는 단계는 아니다.

4. Static은 럼바우 OMT 세 모델의 공식 명칭이 아니다. 정적 구조를 다루는 부분은 럼바우 기법에서 객체 모델링이 담당하므로 별도의 'Static 모델링' 단계는 존재하지 않는다.

정리

럼바우 OMT 3단계 — 객체 모델링(=정보 모델링, 객체 다이어그램) → 동적 모델링(상태 다이어그램) → 기능 모델링(자료 흐름도). '객동기'로 암기한다.

#소프트웨어설계

설계 기법 중 하향식 설계 방법과 상향식 설계 방법에 대한 비교 설명으로 가장 옳지 않은 것은?

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

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

3상향식 설계는 최하위 수준에서 각각의 모듈들을 설계하고 이 러한 모듈이 완성되면 이들을 결합하여 검사한다.

4상향식 설계에서는 인터페이스가 이미 성립되어 있지 않더라 도 기능 추가가 쉽다. - 1 기출문제 & 정답 년 1회 정보처리기사 필기

정답 4번 · 상향식 설계에서는 인터페이스가 이미 성립되어 있지 않더라 도 기능 추가가 쉽다. - 1 기출문제 & 정답 년 1회 정보처리기사 필기

핵심 해설

하향식(Top-down) 설계는 시스템의 최상위 기능부터 정의하고 이를 점차 하위 모듈로 분할해 내려가는 방식이고, 상향식(Bottom-up) 설계는 최하위의 구체적인 모듈을 먼저 만들고 이를 결합해 상위 기능을 구성하는 방식이다. 하향식은 상위에서 하위로 내려가며 인터페이스가 먼저 정의되므로 통합이 수월하지만, 낮은 레벨의 데이터 구조 세부 사항은 설계 후반에 결정하므로 초기 단계에서는 필요하지 않다. 반대로 상향식은 상위 인터페이스가 아직 확정되지 않은 상태에서 모듈을 만들기 때문에, 나중에 기능을 추가하거나 통합할 때 인터페이스 불일치가 생겨 오히려 어려워진다.

보기별 해설

1. 하향식 설계에서는 통합 검사 시 인터페이스가 이미 정의되어 있어 통합이 간단하다는 설명은 옳다. 상위 모듈을 먼저 설계하며 하위 모듈과의 호출 관계를 규정해 두므로 결합 시 충돌이 적다.

2. 하향식 설계에서 레벨이 낮은 데이터 구조의 세부 사항은 설계 초기 단계에서 필요하다는 표현은 하향식의 특징을 뒤집은 것으로 보이지만, 실제 시험에서는 하향식의 단점(세부 데이터 구조를 초기에 확정하기 어렵다는 점)을 서술한 항목으로 다루어진다. 하향식은 추상적인 상위 기능부터 정의하므로 세부 자료 구조는 후반에 구체화된다.

3. 상향식 설계는 최하위 수준에서 각각의 모듈들을 설계하고 이러한 모듈이 완성되면 이들을 결합하여 검사한다는 설명은 상향식의 정의 그대로이다. 하위 모듈을 먼저 만들고 상위로 묶어 올라가는 방식이다.

4. 상향식 설계에서는 인터페이스가 이미 성립되어 있지 않더라도 기능 추가가 쉽다는 설명은 틀렸다. 상향식은 상위 인터페이스가 확정되지 않은 채 하위 모듈을 만들기 때문에 통합 시 인터페이스 불일치가 발생하기 쉬워 기능 추가와 결합이 오히려 어렵다.

정리

하향식 = 상위 기능 → 하위 분할, 인터페이스 선정의로 통합 용이. 상향식 = 하위 모듈 먼저 → 결합, 인터페이스 미확정으로 통합·기능 추가가 어렵다.

#소프트웨어설계

Q6검수필요

요구사항 명세에 대한 설명으로 틀린 것은?

1분석된 요구사항을 바탕으로 모델을 작성하고 문서화하는 것 이다.

2기능 요구사항은 빠짐없이 완전하고 명확하게 기술해야 한다.

3잘못된 부분이 확인될 경우 그 내용을 요구사항 정의서에서 추적할 수 있어야 한다.

4구체적인 명세를 위해 자료 사전(DD)가 사용될 수 있다.

정답 4번 · 구체적인 명세를 위해 자료 사전(DD)가 사용될 수 있다.

핵심 해설

요구사항 명세(Specification)는 도출·분석된 요구사항을 체계적인 문서와 모델로 정리하는 활동이다. 명세서는 기능 요구사항을 빠짐없이 완전하고 명확하게 기술해야 하고, 요구사항의 출처와 반영 위치를 되짚을 수 있는 추적성(Traceability)을 갖춰야 하며, 검증 가능성과 일관성도 요구된다. 표기 방식은 자연어로 서술하는 비정형 명세와 수학적 원리·모델을 사용하는 정형 명세(Z, VDM, Petri-net 등)로 나뉜다. 1~3번은 각각 명세의 정의, 완전성·명확성, 추적성을 정확히 기술한 옳은 설명이고, 공식 정답은 4번이다. 다만 자료 사전(DD)은 구조적 분석에서 자료 흐름도의 자료 항목을 정의하는 표기 도구로 요구사항 명세에 실제로 사용될 수 있어, 4번 서술 자체는 사실로서 옳다. 원본 시험지를 대조한 결과 보기 4번은 '사용될 수 있다'로 인쇄되어 있으며 부정어 누락 등 인쇄·추출상의 오류는 없었다. 따라서 이 문항은 출제 의도상 결함이 있는 것으로 보인다.

보기별 해설

1. 분석된 요구사항을 바탕으로 모델을 작성하고 문서화하는 것이라는 설명은 요구사항 명세의 정의 그대로이다. 도출·분석 단계의 결과를 요구사항 명세서(SRS)로 정리하는 활동이다.

2. 기능 요구사항은 빠짐없이 완전하고 명확하게 기술해야 한다는 것은 명세서가 갖춰야 할 완전성·명확성 요건에 해당한다. 애매한 표현은 이후 설계와 테스트에서 해석 차이를 낳는다.

3. 잘못된 부분이 확인될 경우 그 내용을 요구사항 정의서에서 추적할 수 있어야 한다는 것은 명세서의 추적성(Traceability) 요건이다. 요구사항의 출처와 반영 위치를 역으로 따라갈 수 있어야 한다.

4. 구체적인 명세를 위해 자료 사전(DD)가 사용될 수 있다는 서술은 그 자체로는 옳은 내용이다. 자료 사전은 자료 흐름도에 나타난 자료의 구성과 의미를 `=`, `+`, `{ }`, `[ | ]` 등의 기호로 정의하는 구조적 분석 도구로, 요구사항을 구체화하는 명세 작업에 활용된다. 원본 시험지 확인 결과 이 보기의 문장은 위와 같이 긍정문으로 인쇄되어 있고 공식 정답은 4번이지만, 출제자는 자료 사전을 명세 단계가 아닌 분석·모델링 단계의 도구로 한정해 본 것으로 보인다. 내용상으로는 논란의 여지가 있는 보기이다.

정리

요구사항 명세의 요건 — 완전성, 명확성, 검증 가능성, 일관성, 추적성. 표기는 비정형(자연어)과 정형(Z·VDM·Petri-net)으로 나뉘며, 자료 사전(DD)은 구조적 분석에서 자료를 정의하는 도구이다.

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

바람직한 소프트웨어 설계 지침이 아닌 것은?

1결합도를 최소화하고 응집도를 최대화한다.

2복잡도와 중복성을 줄이고 일관성을 유지시킨다.

3하나의 입구와 하나의 출구를 갖도록 해야 한다.

4모듈의 크기를 가능한 작게 구성하여 병행성 수준을 높여야 한다.

정답 4번 · 모듈의 크기를 가능한 작게 구성하여 병행성 수준을 높여야 한다.

핵심 해설

좋은 모듈 설계의 핵심 지침은 결합도(Coupling)를 낮추고 응집도(Cohesion)를 높여 모듈의 독립성을 확보하는 것이다. 또한 복잡도와 중복을 줄이고 일관된 구조를 유지하며, 제어 흐름은 하나의 입구와 하나의 출구를 갖도록 해 이해와 검증을 쉽게 만든다. 모듈의 크기는 무조건 작을수록 좋은 것이 아니라 적당해야 하는데, 지나치게 잘게 나누면 모듈 수와 호출 관계가 늘어 인터페이스 비용과 결합도가 커지고 오히려 복잡해진다. 따라서 크기를 최소화해 병행성 수준을 높이자는 것은 바람직한 설계 지침이 아니다.

보기별 해설

1. 결합도를 최소화하고 응집도를 최대화한다는 것은 모듈 독립성 확보를 위한 가장 기본적인 설계 지침이다. 모듈 간 의존은 줄이고 모듈 내부 구성 요소의 관련성은 높여야 한다.

2. 복잡도와 중복성을 줄이고 일관성을 유지시킨다는 것도 바람직한 설계 지침이다. 중복 코드를 제거하고 명명·구조 규칙을 통일하면 이해도와 유지보수성이 높아진다.

3. 하나의 입구와 하나의 출구를 갖도록 해야 한다는 것은 구조적 설계의 원칙으로 옳다. 진입·진출점이 하나면 제어 흐름 추적과 테스트가 단순해진다.

4. 모듈의 크기를 가능한 작게 구성하여 병행성 수준을 높여야 한다는 것은 바람직한 지침이 아니다. 모듈 크기는 지나치게 작지도 크지도 않게 적당해야 하며, 과도하게 분할하면 모듈 간 인터페이스와 호출 비용이 늘어 결합도와 복잡도가 오히려 증가한다.

정리

설계 지침 — 결합도 최소·응집도 최대, 복잡도·중복 감소, 일관성 유지, 단일 입구/단일 출구, 모듈 크기는 '적당히'(무조건 작게가 아님).

#소프트웨어설계

UML(Unified Modeling Language)에 대한 설명 중 틀린 것은?

1기능적 모델은 사용자 측면에서 본 시스템 기능이며, UML에서 는 Use Case Diagram을 사용한다.

2정적 모델은 객체속성연관관계오퍼레이션의, , , 시스템의 구 조를 나타내며, UML에서는 Class Diagram을 사용한다.

3동적 모델은 시스템의 내부 동작을 말하며, UML에서는 Sequence Diagram, State Diagram, Activity Diagram을 사 용한다.

4State Diagram은 객체들 사이의 메시지 교환을 나타내며, Sequence Diagram은 하나의 객체가 가진 상태와 그 상태의 변화에 의한 동작 순서를 나타낸다.

정답 4번 · State Diagram은 객체들 사이의 메시지 교환을 나타내며, Sequence Diagram은 하나의 객체가 가진 상태와 그 상태의 변화에 의한 동작 순서를 나타낸다.

핵심 해설

UML 다이어그램은 사용자 관점의 기능 모델(유스케이스 다이어그램), 시스템 구조를 나타내는 정적 모델(클래스·객체·컴포넌트 다이어그램), 시스템의 동작을 나타내는 동적 모델(시퀀스·상태·활동 다이어그램)로 나눌 수 있다. 이 가운데 시퀀스 다이어그램(Sequence Diagram)은 객체들 사이에 오가는 메시지를 시간 순서에 따라 배열해 상호작용을 표현하고, 상태 다이어그램(State Diagram)은 하나의 객체가 가지는 상태와 사건에 의한 상태 전이를 표현한다. 즉 두 다이어그램의 역할이 서로 뒤바뀌어 서술된 항목이 틀린 설명이다.

보기별 해설

1. 기능적 모델은 사용자 측면에서 본 시스템 기능이며 UML에서는 Use Case Diagram을 사용한다는 설명은 옳다. 액터와 유스케이스, 그들 사이의 관계로 시스템이 제공하는 기능을 나타낸다.

2. 정적 모델은 객체, 속성, 연관관계, 오퍼레이션의 시스템 구조를 나타내며 UML에서는 Class Diagram을 사용한다는 설명은 옳다. 클래스 다이어그램은 시간에 따라 변하지 않는 구조적 측면을 표현한다.

3. 동적 모델은 시스템의 내부 동작을 말하며 UML에서는 Sequence Diagram, State Diagram, Activity Diagram을 사용한다는 설명은 옳다. 세 다이어그램 모두 행위(Behavioral) 다이어그램에 속한다.

4. State Diagram은 객체들 사이의 메시지 교환을 나타내며 Sequence Diagram은 하나의 객체가 가진 상태와 상태 변화에 의한 동작 순서를 나타낸다는 설명은 두 다이어그램의 역할이 뒤바뀐 것이다. 메시지 교환을 시간 순으로 표현하는 것이 시퀀스 다이어그램이고, 객체의 상태와 전이를 표현하는 것이 상태 다이어그램이다.

정리

시퀀스 다이어그램 = 객체 간 메시지의 시간 순서, 상태 다이어그램 = 한 객체의 상태와 사건에 의한 전이. 기능=유스케이스, 정적=클래스, 동적=시퀀스·상태·활동.

#소프트웨어설계#UML

코드 설계에서 일정한 일련번호를 부여하는 방식의 코드는?

1연상 코드

2블록 코드

3순차 코드

4표의 숫자 코드

정답 3번 · 순차 코드

핵심 해설

코드는 자료의 식별·분류·집계를 쉽게 하기 위해 부여하는 기호이며, 부여 방식에 따라 여러 유형으로 나뉜다. 순차 코드(Sequence Code)는 자료의 발생 순서나 정해진 일정 기준에 따라 1, 2, 3…처럼 일련번호를 차례로 붙이는 가장 단순한 코드이다. 이 밖에 일정 기준으로 구간을 나누어 번호를 할당하는 블록 코드, 대상의 명칭을 연상시키는 문자·기호를 쓰는 연상 코드, 대상의 물리적 수치를 그대로 코드에 반영하는 표의 숫자 코드 등이 있다. 문제에서 말하는 '일정한 일련번호를 부여하는 방식'은 순차 코드에 해당한다.

보기별 해설

1. 연상 코드(Mnemonic Code)는 대상 항목의 명칭이나 약칭을 떠올릴 수 있는 문자·숫자를 사용하는 코드이다. 예를 들어 텔레비전 21인치를 'TV-21'로 표기하는 방식으로, 일련번호를 붙이는 방식이 아니다.

2. 블록 코드(Block Code, 구분 코드)는 공통 성질을 가진 것끼리 블록으로 구간을 나누고 각 블록 안에서 일련번호를 부여하는 코드이다. 예를 들어 1~100은 인사부, 101~200은 총무부처럼 배정하며, 단순 일련번호와 달리 분류 기능이 함께 있다.

3. 순차 코드(Sequence Code, 순서 코드)는 자료의 발생 순서나 정해진 기준에 따라 처음부터 차례로 일련번호를 부여하는 가장 단순한 코드이다. 문제에서 말하는 '일정한 일련번호를 부여하는 방식'에 정확히 해당한다.

4. 표의 숫자 코드(Significant Digit Code, 유효 숫자 코드)는 대상의 길이·넓이·용량 같은 물리적 수치를 그대로 코드 값에 반영하는 방식이다. 예를 들어 가로 100, 세로 50, 두께 20인 제품을 '100-50-20'으로 표기하며 일련번호와는 무관하다.

정리

코드 유형 — 순차 코드(일련번호), 블록 코드(구간별 분류 후 번호), 연상 코드(명칭 연상 기호), 표의 숫자 코드(물리적 수치 반영), 10진 코드, 그룹 분류 코드.

#소프트웨어설계

Q10

시스템의 구성 요소로 볼 수 없는 것은?

1Process

2Feedback

3Maintenance

4Control

정답 3번 · Maintenance

핵심 해설

시스템(System)은 공동의 목표를 위해 여러 요소가 유기적으로 결합된 집합체이며, 기본 구성 요소는 입력(Input), 처리(Process), 출력(Output), 제어(Control), 피드백(Feedback) 다섯 가지이다. 입력은 자료를 받아들이고, 처리는 이를 목적에 맞게 변환하며, 출력은 결과를 내보낸다. 제어는 각 단계가 올바르게 수행되는지 감시·조정하고, 피드백은 출력 결과를 다시 입력 쪽으로 되돌려 시스템을 개선하게 한다. 유지보수(Maintenance)는 소프트웨어 생명주기의 한 단계일 뿐 시스템의 구성 요소가 아니다.

보기별 해설

1. Process(처리)는 시스템의 구성 요소이다. 입력받은 자료를 시스템의 목적에 맞게 가공·변환해 출력으로 만드는 핵심 기능을 담당한다.

2. Feedback(피드백)은 시스템의 구성 요소이다. 출력된 결과를 검토해 다시 입력이나 처리 단계에 반영함으로써 목표와의 차이를 줄이고 시스템을 개선한다.

3. Maintenance(유지보수)는 시스템의 구성 요소가 아니라 소프트웨어 생명주기의 마지막 단계이다. 이미 인도된 소프트웨어의 오류를 수정하고 변경 요구를 반영하는 활동으로, 입력·처리·출력·제어·피드백 어디에도 해당하지 않는다.

4. Control(제어)은 시스템의 구성 요소이다. 처리 과정이 정해진 기준대로 수행되는지 감시하고 이상이 있으면 조정하는 역할을 한다.

정리

시스템의 5대 구성 요소 — 입력(Input), 처리(Process), 출력(Output), 제어(Control), 피드백(Feedback). 유지보수는 생명주기 단계이지 구성 요소가 아니다.

#소프트웨어설계

Q11

파이프 필터 형태의 소프트웨어 아키텍처에 대한 설명으로 옳은 것은?

1노드와 간선으로 구성된다.

2서브시스템이 입력 데이터를 받아 처리하고 결과를 다음 서브 시스템으로 넘겨주는 과정을 반복한다.

3계층 모델이라고도 한다.

43개의 서브시스템모델뷰제어으로( , , ) 구성되어 있다.

정답 2번 · 서브시스템이 입력 데이터를 받아 처리하고 결과를 다음 서브 시스템으로 넘겨주는 과정을 반복한다.

핵심 해설

파이프-필터(Pipe-Filter) 아키텍처는 데이터를 변환하는 처리 단위인 필터(Filter)와, 필터 사이에서 데이터를 전달하는 통로인 파이프(Pipe)로 구성된다. 각 필터는 앞 단계에서 넘어온 데이터를 받아 처리한 뒤 결과를 다음 필터로 넘기며, 이 과정이 순차적으로 반복되어 최종 결과가 만들어진다. 필터끼리 상태를 공유하지 않으므로 필터의 재사용과 교체·추가가 쉽고 병렬 처리에도 유리하며, UNIX의 셸 파이프라인이나 컴파일러 처리 단계가 대표적인 예이다.

보기별 해설

1. 노드와 간선으로 구성된다는 것은 그래프 자료구조나 일반적인 다이어그램의 구성 설명으로, 특정 아키텍처 스타일을 규정하는 서술이 아니다. 파이프-필터의 고유 특징이 아니다.

2. 서브시스템이 입력 데이터를 받아 처리하고 결과를 다음 서브시스템으로 넘겨주는 과정을 반복한다는 것은 파이프-필터 아키텍처의 정의 그대로이다. 필터가 데이터를 변환하고 파이프가 그 결과를 다음 필터로 전달한다.

3. 계층 모델이라고도 한다는 것은 계층화(Layered) 아키텍처에 대한 설명이다. 시스템을 기능별 계층으로 나누고 상위 계층이 하위 계층의 서비스만 사용하도록 하는 구조로, OSI 7계층이 대표적이다.

4. 3개의 서브시스템(모델, 뷰, 제어)으로 구성되어 있다는 것은 MVC(Model-View-Controller) 아키텍처에 대한 설명이다. 데이터와 로직(Model), 화면 표현(View), 입력 처리와 흐름 제어(Controller)를 분리하는 구조이다.

정리

아키텍처 스타일 — 파이프-필터(필터가 변환, 파이프가 전달, 순차 반복), 계층화(상위가 하위 서비스 이용), MVC(모델·뷰·제어 3분할), 클라이언트-서버, 마스터-슬레이브.

#소프트웨어설계

Q12

데이터 흐름도(DFD)의 구성 요소에 포함되지 않는 것은?

1Data Flow

2Data Dictionary

3Process

4Data Store 1

정답 2번 · Data Dictionary

핵심 해설

자료 흐름도(DFD, Data Flow Diagram)는 자료가 어떤 처리를 거쳐 어디로 흐르는지를 도형으로 표현한 구조적 분석 도구이다. 구성 요소는 자료를 변환하는 처리(Process, 원 또는 둥근 사각형), 자료의 이동 경로인 자료 흐름(Data Flow, 화살표), 자료가 보관되는 자료 저장소(Data Store, 두 줄의 평행선), 그리고 시스템 외부의 자료 발생·소멸 지점인 단말(Terminator, 사각형) 네 가지이다. 자료 사전(Data Dictionary)은 DFD에 나타난 자료 항목의 구성과 의미를 별도로 정의하는 보조 명세 도구이므로 DFD 자체의 구성 요소가 아니다.

보기별 해설

1. Data Flow(자료 흐름)는 DFD의 구성 요소이다. 자료가 이동하거나 전달되는 경로를 화살표로 표시하며 화살표 위에 자료의 이름을 적는다.

2. Data Dictionary(자료 사전)는 DFD의 구성 요소가 아니라 DFD를 보완하는 별도의 명세 도구이다. `=`(정의), `+`(연결), `{ }`(반복), `[ | ]`(선택), `( )`(생략) 같은 기호로 자료 항목의 구성을 정의한다.

3. Process(처리)는 DFD의 구성 요소이다. 입력된 자료를 변환해 출력 자료를 만들어 내는 기능 단위로 원이나 둥근 사각형으로 표기한다.

4. Data Store(자료 저장소)는 DFD의 구성 요소이다. 자료가 저장되어 있는 파일이나 데이터베이스를 나타내며 두 줄의 평행선으로 표기한다(보기 끝의 '1'은 PDF 추출 잡음이다).

정리

DFD 구성 요소 4가지 — Process(원), Data Flow(화살표), Data Store(평행선), Terminator(사각형). 자료 사전(DD)과 소단위 명세서(mini-spec)는 DFD를 보완하는 별도 도구이다.

#소프트웨어설계

Q13

사용자 인터페이스의 설계 지침에 대한 설명으로 옳지 않은 것은?

1조작 방법을 가능한 다양화하여 많은 기능이 들어갈 수 있도록 구성해야 한다.

2버튼이나 조작 방법 등을 일관성 있게 제공해야 한다.

3작동시킬 기능만 보고도 결과를 미리 예측할 수 있게 설계해야 한다.

4사용자가 쉽게 이해하고 편리하게 사용할 수 있는 환경을 제공 해야 한다.

정답 1번 · 조작 방법을 가능한 다양화하여 많은 기능이 들어갈 수 있도록 구성해야 한다.

핵심 해설

사용자 인터페이스(UI) 설계는 사용자가 쉽고 정확하게 목적을 달성하도록 돕는 것이 목표이며, 직관성·유효성·학습성·유연성이라는 원칙 위에서 일관성, 예측 가능성, 단순성, 오류 최소화 같은 지침을 따른다. 특히 화면에 지나치게 많은 기능을 담고 조작 방법을 여러 갈래로 늘리면 사용자가 혼란을 겪고 학습 부담과 조작 오류가 커진다. 따라서 UI는 기능을 최대한 넣는 방향이 아니라, 꼭 필요한 기능을 단순하고 일관된 방식으로 제공하는 방향으로 설계해야 한다.

보기별 해설

1. 조작 방법을 가능한 다양화하여 많은 기능이 들어갈 수 있도록 구성해야 한다는 것은 옳지 않은 지침이다. 조작 방식이 여러 갈래로 늘어나면 일관성이 깨지고 학습 부담과 조작 실수가 커지므로, UI는 단순하고 일관된 방식을 유지해야 한다.

2. 버튼이나 조작 방법 등을 일관성 있게 제공해야 한다는 것은 UI 설계의 일관성(Consistency) 지침으로 옳다. 같은 기능은 어느 화면에서나 같은 위치와 같은 방식으로 동작해야 한다.

3. 작동시킬 기능만 보고도 결과를 미리 예측할 수 있게 설계해야 한다는 것은 예측 가능성(Predictability) 지침으로 옳다. 아이콘과 레이블만으로 동작 결과를 짐작할 수 있어야 사용자가 안심하고 조작한다.

4. 사용자가 쉽게 이해하고 편리하게 사용할 수 있는 환경을 제공해야 한다는 것은 UI 설계의 근본 목표이자 직관성 원칙에 해당하는 옳은 지침이다.

정리

UI 설계 지침 — 일관성, 예측 가능성, 단순성(꼭 필요한 기능만), 오류 최소화, 쉬운 이해. 기능과 조작 방법을 많이 넣는 것은 좋은 UI가 아니다.

#소프트웨어설계

Q14

UI 설계 원칙에서 누구나 쉽게 이해하고 사용할 수 있어야 한다는 것은?

1유효성

2직관성

3학습성

4유연성

정답 2번 · 직관성

핵심 해설

UI 설계 원칙은 직관성, 유효성, 학습성, 유연성 네 가지이다. 직관성(Intuitiveness)은 누구나 별도의 설명이나 학습 없이 화면을 보고 바로 이해하고 쉽게 사용할 수 있어야 한다는 원칙으로, 쉬운 사용성과 일관된 화면 구성이 세부 지침이다. 유효성은 사용자의 목적을 정확하고 완전하게 달성하게 하는 것, 학습성은 초보자도 쉽게 배우고 익힐 수 있게 하는 것, 유연성은 사용자의 다양한 요구를 수용하고 오류를 최소화·복구하게 하는 것을 뜻한다.

보기별 해설

1. 유효성(Effectiveness)은 사용자의 목적을 정확하고 완전하게 달성할 수 있게 해야 한다는 UI 설계 원칙이다. 이해의 쉬움이 아니라 목표 달성의 정확성과 효율에 초점이 있다.

2. 직관성(Intuitiveness)은 누구나 별도 설명 없이 쉽게 이해하고 사용할 수 있어야 한다는 UI 설계 원칙이다. 쉬운 사용성과 일관된 화면 구성으로 학습 부담 없이 조작하게 하므로 문제 조건에 정확히 부합한다.

3. 학습성(Learnability)은 초보자도 쉽게 배우고 익힐 수 있어야 한다는 UI 설계 원칙이다. 사용법을 습득하는 과정의 용이함을 다루므로, 설명 없이 즉시 이해된다는 직관성과는 초점이 다르다.

4. 유연성(Flexibility)은 사용자의 다양한 요구를 최대한 수용하고 실수나 오류를 줄이거나 쉽게 복구할 수 있게 해야 한다는 UI 설계 원칙이다. 오류 방지와 복구, 융통성에 관한 원칙이다.

정리

UI 설계 원칙 4가지 — 직관성(설명 없이 쉽게 이해·사용), 유효성(목적의 정확·완전한 달성), 학습성(누구나 쉽게 배움), 유연성(요구 수용·오류 최소화).

#소프트웨어설계

Q15

디자인 패턴 사용의 장단점에 대한 설명으로 거리가 먼 것은?

1소프트웨어 구조 파악이 용이하다.

2초기 투자 비용 및 개발 시간이 절약된다.

3재사용을 위한 개발 시간이 단축된다.

4객체지향 설계 및 구현의 생산성을 높이는데 적합하다.

정답 2번 · 초기 투자 비용 및 개발 시간이 절약된다.

핵심 해설

디자인 패턴은 반복적으로 나타나는 설계 문제에 대한 검증된 해결책을 정형화한 것으로, 설계 재사용을 통해 개발자 간 의사소통과 구조 파악을 쉽게 하고 객체지향 설계·구현의 생산성과 유지보수성을 높인다. 그러나 패턴을 익히고 상황에 맞게 적용하려면 학습 시간과 설계 검토가 필요하고, 단순한 문제에 패턴을 적용하면 클래스 수가 늘어 구조가 오히려 복잡해진다. 즉 디자인 패턴은 장기적인 재사용 효과가 크지만 초기 투자 비용과 개발 시간은 오히려 늘어나는 것이 일반적이므로, 이를 절약된다고 본 설명은 옳지 않다.

보기별 해설

1. 소프트웨어 구조 파악이 용이하다는 것은 디자인 패턴의 장점이다. 널리 알려진 패턴 이름만으로 설계 의도가 전달되므로 다른 개발자가 구조를 빠르게 이해할 수 있다.

2. 초기 투자 비용 및 개발 시간이 절약된다는 것은 디자인 패턴의 장점으로 볼 수 없다. 패턴 학습과 적용 설계에 시간이 들고 클래스·인터페이스가 늘어나므로 초기 비용은 오히려 증가하며, 이익은 이후 재사용과 유지보수 단계에서 나타난다.

3. 재사용을 위한 개발 시간이 단축된다는 것은 디자인 패턴의 장점이다. 검증된 해결 구조를 그대로 가져다 쓰므로 유사한 설계 문제를 매번 새로 고민할 필요가 없다.

4. 객체지향 설계 및 구현의 생산성을 높이는 데 적합하다는 것은 디자인 패턴의 장점이다. GoF 패턴은 클래스·객체의 상속과 위임을 전제로 정리되어 객체지향 개발에 특히 잘 맞는다.

정리

디자인 패턴 — 장점: 구조 파악 용이, 재사용으로 개발 시간 단축, 객체지향 생산성 향상. 단점: 초기 학습·설계 비용 증가, 남용 시 구조 복잡화, 객체지향 외 설계에는 부적합.

#소프트웨어설계#디자인패턴#객체지향

Q16

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

1생명선

2실행

3확장

4메시지

정답 3번 · 확장

핵심 해설

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

보기별 해설

1. 생명선(Lifeline)은 시퀀스 다이어그램의 구성 항목이다. 각 객체 아래로 뻗은 수직 점선으로 객체의 존속 기간과 시간의 흐름을 나타낸다.

2. 실행(Activation, 활성 구간)은 시퀀스 다이어그램의 구성 항목이다. 생명선 위에 겹쳐 그린 가는 직사각형으로, 객체가 메시지를 받아 처리를 수행 중인 구간을 표시한다.

3. 확장(extend)은 유스케이스 다이어그램에서 기본 유스케이스에 선택적으로 기능을 덧붙이는 관계를 나타내는 개념이다. 시간 순서에 따른 메시지 교환을 표현하는 시퀀스 다이어그램의 구성 항목이 아니다.

4. 메시지(Message)는 시퀀스 다이어그램의 핵심 구성 항목이다. 한 객체가 다른 객체에 보내는 요청이나 응답을 화살표로 나타내며, 아래로 갈수록 나중에 발생한 상호작용이다.

정리

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

#소프트웨어설계#UML

Q17

소프트웨어 설계에서 각 모듈의 세분화된 역할이나 모듈들 간의 인터페이스와 같은 코드를 작성하는 수준의 세부적인 구현 방안을 설계할 때 참조할 수 있는 전형적인 해결 방식 또는 예제를 의미하는 것은?

1모듈 분해

2클래스 도출

3연관 관계

4디자인 패턴

정답 4번 · 디자인 패턴

핵심 해설

설계 단계는 시스템 전체 구조를 정하는 상위 설계(아키텍처 설계)와 코드 작성 수준까지 구체화하는 하위 설계(상세 설계)로 나뉜다. 하위 설계에서 각 모듈의 세부 역할과 모듈 간 인터페이스를 구현 수준으로 정할 때 참조할 수 있는 전형적인 해결 방식이나 예제를 디자인 패턴(Design Pattern)이라 한다. 디자인 패턴은 반복해서 등장하는 설계 문제에 대해 검증된 구조를 이름과 함께 정형화한 것으로, GoF는 이를 생성·구조·행위 세 가지 목적으로 분류했다.

보기별 해설

1. 모듈 분해는 시스템을 기능 단위의 모듈로 나누는 설계 활동 자체를 가리킨다. 분할 방법에 해당할 뿐 참조할 수 있는 전형적 해결 방식이나 예제를 뜻하는 용어가 아니다.

2. 클래스 도출은 요구사항이나 유스케이스 명세에서 시스템에 필요한 클래스를 찾아내는 객체지향 분석 활동이다. 설계 해결책의 템플릿을 의미하지 않는다.

3. 연관 관계(Association)는 클래스 다이어그램에서 두 클래스가 서로 참조하며 관계를 맺고 있음을 나타내는 UML 관계로, 실선으로 표기한다. 모델 간 연결을 표현하는 표기 개념이지 해결 방식의 예제가 아니다.

4. 디자인 패턴(Design Pattern)은 반복적으로 나타나는 설계 문제에 대한 검증된 해결 구조를 이름과 함께 정형화한 것이다. 모듈의 세부 역할과 인터페이스를 구현 수준으로 설계할 때 그대로 참조할 수 있는 전형적 해결 방식이므로 문제 조건에 부합한다.

정리

상위 설계 = 아키텍처·시스템 구조, 하위 설계 = 모듈 내부와 인터페이스 상세. 하위 설계 시 참조하는 검증된 전형적 해결책이 디자인 패턴(GoF: 생성·구조·행위)이다.

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

Q18

소프트웨어 모델링과 관련한 설명으로 틀린 것은?

1모델링 작업의 결과물은 다른 모델링 작업에 영향을 줄 수 없다.

2구조적 방법론에서는 DFD(Data Flow Diagram), DD(Data Dictionary) 등을 사용하여 요구사항의 결과를 표현한다.

3객체지향 방법론에서는 UML 표기법을 사용한다.

4소프트웨어 모델을 사용할 경우 개발될 소프트웨어에 대한 이 해도 및 이해 당사자 간의 의사소통 향상에 도움이 된다.

정답 1번 · 모델링 작업의 결과물은 다른 모델링 작업에 영향을 줄 수 없다.

핵심 해설

소프트웨어 모델링은 개발할 시스템을 추상화한 모델로 표현해 이해와 의사소통을 돕는 활동이다. 구조적 방법론에서는 DFD, 자료 사전(DD), 소단위 명세서 등으로 요구사항을 표현하고, 객체지향 방법론에서는 UML 표기법을 사용한다. 모델링 작업들은 서로 독립적으로 진행되는 것이 아니라 긴밀히 연결되어, 앞선 모델의 결과가 뒤따르는 모델의 입력이 되고 서로 일관성을 유지해야 한다. 예를 들어 유스케이스 모델에서 도출된 개념이 클래스 다이어그램과 시퀀스 다이어그램에 그대로 반영되므로, 결과물이 다른 모델링에 영향을 줄 수 없다는 설명은 틀렸다.

보기별 해설

1. 모델링 작업의 결과물은 다른 모델링 작업에 영향을 줄 수 없다는 설명은 틀렸다. 유스케이스 모델의 결과가 클래스·시퀀스 모델의 입력이 되는 것처럼 모델들은 서로 참조하며 일관성을 유지해야 한다.

2. 구조적 방법론에서는 DFD(Data Flow Diagram), DD(Data Dictionary) 등을 사용하여 요구사항의 결과를 표현한다는 설명은 옳다. 여기에 소단위 명세서(mini-spec), 개체 관계도(ERD) 등이 함께 쓰인다.

3. 객체지향 방법론에서는 UML 표기법을 사용한다는 설명은 옳다. UML은 부치·럼바우·야콥슨의 방법을 통합해 만든 객체지향 표준 모델링 언어이다.

4. 소프트웨어 모델을 사용할 경우 개발될 소프트웨어에 대한 이해도 및 이해 당사자 간의 의사소통 향상에 도움이 된다는 설명은 옳다. 추상화된 그림과 표기로 복잡한 시스템을 공유 가능한 형태로 만드는 것이 모델링의 목적이다.

정리

모델링 — 구조적 방법론은 DFD·DD·mini-spec, 객체지향 방법론은 UML. 여러 모델은 서로 입력·검증 관계로 연결되어 일관성을 유지해야 한다.

#소프트웨어설계#UML#객체지향#요구사항

Q19

UML 모델에서 사용하는 구조적 다이어그램에 속하지 않은 것은?

1State Diagram

2Object Diagram

3Component Diagram

4Class Diagram

정답 1번 · State Diagram

핵심 해설

UML 다이어그램은 시스템의 정적 구성을 나타내는 구조(Structural) 다이어그램과 동적 동작을 나타내는 행위(Behavioral) 다이어그램으로 나뉜다. 구조 다이어그램에는 클래스, 객체, 컴포넌트, 배치(Deployment), 복합체 구조, 패키지 다이어그램 여섯 가지가 속하고, 행위 다이어그램에는 유스케이스, 시퀀스, 커뮤니케이션, 상태, 활동, 타이밍 다이어그램이 속한다. 상태 다이어그램(State Diagram)은 하나의 객체가 사건에 따라 상태를 어떻게 바꾸는지를 표현하므로 행위 다이어그램이며, 따라서 구조 다이어그램에 속하지 않는다.

보기별 해설

1. State Diagram(상태 다이어그램)은 행위(Behavioral) 다이어그램이다. 하나의 객체가 사건(event)에 의해 어떤 상태로 전이되는지를 표현하므로 시스템의 정적 구조를 나타내는 구조 다이어그램이 아니다.

2. Object Diagram(객체 다이어그램)은 구조 다이어그램이다. 클래스에 속한 인스턴스와 그 속성 값, 인스턴스 간 링크를 특정 시점의 스냅숏으로 표현한다.

3. Component Diagram(컴포넌트 다이어그램)은 구조 다이어그램이다. 실제 구현 단위인 컴포넌트들의 구성과 그들이 제공·요구하는 인터페이스 및 의존 관계를 표현한다.

4. Class Diagram(클래스 다이어그램)은 구조 다이어그램의 대표 격이다. 클래스의 속성과 연산, 클래스 간 연관·일반화·의존 관계로 시스템의 정적 구조를 표현한다.

정리

UML 구조 다이어그램 — 클래스·객체·컴포넌트·배치·복합체 구조·패키지. 행위 다이어그램 — 유스케이스·시퀀스·커뮤니케이션·상태·활동·타이밍.

#소프트웨어설계#UML

Q20

객체 지향 개념 중 하나 이상의 유사한 객체들을 묶어 공통된 특성을 표현한 데이터 추상화를 의미하는 것은?

1Method

2Class

3Field

4Message

정답 2번 · Class

핵심 해설

객체지향에서 클래스(Class)는 공통된 속성과 연산을 가진 하나 이상의 유사한 객체들을 묶어 하나의 공통 특성으로 정의한 데이터 추상화 단위이다. 즉 클래스는 객체를 만들어 내기 위한 틀이자 객체의 타입이며, 클래스를 실체화해 메모리에 생성한 개별 객체를 인스턴스(Instance)라 한다. 유사한 객체들의 공통점을 추출해 표현한다는 문제의 조건에 해당하는 것은 클래스이다.

보기별 해설

1. Method(메서드)는 클래스 안에 정의되어 객체가 수행하는 연산이나 동작을 기술한 함수이다. 객체의 행위를 담당하는 구성 요소일 뿐 유사 객체를 묶어 추상화한 단위가 아니다.

2. Class(클래스)는 유사한 객체들이 공통으로 가지는 속성과 연산을 묶어 정의한 데이터 추상화 단위이다. 객체를 생성하는 틀이자 타입 역할을 하므로 문제 조건에 정확히 부합한다.

3. Field(필드)는 클래스에 선언된 데이터 항목, 즉 객체의 상태를 저장하는 속성(Attribute)을 가리킨다. 클래스를 구성하는 요소일 뿐 객체 집합을 추상화한 개념 자체는 아니다.

4. Message(메시지)는 한 객체가 다른 객체에게 특정 연산의 수행을 요청하는 통신 수단이다. 객체 간 상호작용을 나타낼 뿐 객체들의 공통 특성을 정의하지 않는다.

정리

클래스 = 유사 객체들의 공통 속성·연산을 묶은 데이터 추상화(틀·타입), 인스턴스 = 클래스를 실체화한 객체, 메서드 = 연산, 메시지 = 객체 간 요청.

#소프트웨어설계