소프트웨어 설계 · 오답노트
2025년 2회
럼바우(Rumbaugh)의 객체지향 분석 절차를 가장 바르게 나열한 것은?
핵심 해설
럼바우(Rumbaugh)의 객체지향 분석 기법인 OMT(Object Modeling Technique)는 시스템을 세 가지 관점으로 나누어 순차적으로 분석한다. 먼저 객체 모형(Object Model)에서 시스템에 필요한 객체와 클래스, 속성, 객체 간 관계를 객체 다이어그램으로 표현한다. 다음 동적 모형(Dynamic Model)에서 상태 다이어그램을 이용해 시간 흐름에 따른 객체의 상태 변화와 사건(event)에 의한 제어 흐름을 표현한다. 마지막 기능 모형(Functional Model)에서 자료 흐름도(DFD)로 프로세스 간 자료의 흐름과 값의 변환 과정을 표현한다. 따라서 순서는 객체 → 동적 → 기능이며 '객동기'로 암기한다.
보기별 해설
정리
UI의 종류로 멀티 터치(Multi-touch), 동작 인식(Gesture Recognition) 등 사용자의 자연스러운 움직임을 인식하여 서로 주고받는 정보를 제공하는 사용자 인터페이스를 의미하는 것은?
핵심 해설
사용자 인터페이스(UI)는 사용자가 시스템과 상호작용하는 방식에 따라 분류된다. 멀티 터치, 동작 인식, 음성 인식처럼 사람이 본래 가진 자연스러운 움직임과 감각을 그대로 입력으로 사용하는 인터페이스를 NUI(Natural User Interface)라 한다. 별도의 장치 조작법을 배우지 않아도 되도록 사람의 신체 동작 자체를 명령으로 삼는 것이 특징이다. 스마트폰의 핀치 줌이나 키넥트 방식의 제스처 제어가 대표적인 사례이다.
보기별 해설
정리
소프트웨어 설계에서 사용되는 대표적인 추상화(Abstraction) 기법 이 아닌 것은?
핵심 해설
추상화(Abstraction)는 복잡한 문제에서 세부 사항을 감추고 본질적인 특성만 추려내어 표현하는 설계 기법이다. 소프트웨어 설계에서 사용하는 대표적인 추상화는 과정 추상화, 자료 추상화, 제어 추상화의 세 가지이다. 과정 추상화는 알고리즘의 세부 절차를 생략하고 수행 흐름만 표현하며, 자료 추상화는 데이터의 내부 표현을 감추고 연산 중심으로 자료 구조를 정의한다. 제어 추상화는 이벤트나 인터럽트 같은 제어 사건의 정확한 처리 메커니즘을 숨기고 개념적으로만 표현한다. '강도 추상화'는 존재하지 않는 용어이다.
보기별 해설
정리
다음 설명에 해당하는 도표는? 시스템의 기능을 여러 개의 고유 모듈들로 분할하여 이들 간의 인터페이스를 계층 구조로 표현한 것으로, 가시적 도표(Visual Table of Contents), 총체적 도표(Overview Diagram), 세부적 도표(Detail Diagram)가 있다.
핵심 해설
HIPO(Hierarchy Input Process Output)는 시스템의 기능을 여러 모듈로 분할하고 각 모듈의 입력·처리·출력 관계와 모듈 간 계층 구조를 도표로 표현하는 기법이다. HIPO Chart는 세 종류로 구성되는데, 가시적 도표(Visual Table of Contents)는 전체 기능의 계층 구조를 트리 형태로 보여주는 목차 역할을 하고, 총체적 도표(Overview Diagram)는 각 기능의 입력·처리·출력을 개괄적으로 나타내며, 세부적 도표(Detail Diagram)는 총체적 도표의 내용을 상세히 기술한다. 문제의 세 도표 명칭이 그대로 HIPO의 구성 요소이다.
보기별 해설
정리
요구사항 분석이 어려운 이유가 아닌 것은?
핵심 해설
요구사항 분석이 어려운 근본 원인은 요구사항 자체가 불완전하고 유동적이며, 이를 전달하는 사람과 받는 사람의 배경 지식이 다르다는 데 있다. 사용자는 자신이 원하는 바를 정확한 용어로 표현하지 못해 요구가 모호하거나 상충하고, 개발자와 사용자의 도메인 지식·표현 방식 차이 때문에 같은 말을 다르게 이해하기 쉽다. 또한 요구사항은 개발이 진행되는 도중에도 시장·업무 환경 변화로 계속 바뀐다. 여기에 사용자의 요구는 예외 상황과 특수 규칙이 매우 많아 빠짐없이 열거하고 구조화하기가 오히려 어렵다.
보기별 해설
정리
자료 흐름도(DFD)의 각 요소별 표기 형태의 연결이 옳지 않은 것은?
핵심 해설
자료 흐름도(DFD, Data Flow Diagram)는 시스템 내 자료의 흐름과 변환 과정을 네 가지 기본 기호로 표현하는 구조적 분석 도구이다. 처리(Process)는 원 또는 둥근 사각형, 자료 흐름(Data Flow)은 화살표, 자료 저장소(Data Store)는 평행선(두 줄 또는 한쪽이 열린 직사각형), 단말(Terminator, 외부 엔티티)은 사각형으로 표기한다. 따라서 자료 저장소를 삼각형으로 연결한 것이 옳지 않다. 삼각형은 DFD의 기본 기호가 아니다.
보기별 해설
정리
익스트림 프로그래밍(XP)의 5가지 가치로 거리가 먼 것은?
핵심 해설
익스트림 프로그래밍(XP, eXtreme Programming)은 짧은 반복 주기와 고객 참여를 강조하는 애자일 방법론이며, 실천 방법의 바탕이 되는 다섯 가지 가치를 제시한다. 그 다섯은 의사소통(Communication), 단순성(Simplicity), 피드백(Feedback), 용기(Courage), 존중(Respect)이다. Pair Programming, Test-Driven Development, Continuous Integration 같은 실천 항목은 이 가치들을 실현하기 위한 구체적 기법이다. '정형 분석'은 수학적 표기로 명세를 기술하는 정형 기법 계열의 용어로 XP의 가치가 아니다.
보기별 해설
정리
UI의 설계 지침으로 틀린 것은?
핵심 해설
UI 설계 지침은 사용자가 시스템을 쉽고 정확하게 사용할 수 있게 하는 원칙들로, 직관성·유효성·학습성·유연성을 바탕으로 한다. 특히 오류 처리에서는 오류가 발생했을 때 그 사실과 원인, 대처 방법을 사용자가 즉시 알 수 있도록 명확한 메시지로 알려야 한다는 것이 핵심 원칙이다. 오류를 감추면 사용자는 잘못된 상태를 인지하지 못한 채 작업을 계속해 더 큰 피해를 입는다. 따라서 치명적 오류를 사용자가 인지할 수 없게 한다는 지침은 틀렸다.
보기별 해설
정리
UI를 설계할 때 사용자 측면에서의 요구사항으로사용자가, 원하는 목표를 달성하기 위해 수행할 내용을 기술하는 것은?
핵심 해설
유스케이스(Use Case)는 사용자(액터)가 시스템을 통해 달성하려는 목표와 그 목표를 이루기 위해 수행하는 상호작용 절차를 기술한 것이다. 시스템이 내부적으로 어떻게 구현되는지가 아니라 '사용자가 무엇을 하려 하고 시스템이 무엇을 해 주는가'를 사용자 관점에서 서술하므로, UI 설계 시 사용자 측면의 요구사항을 도출하는 데 쓰인다. 유스케이스 다이어그램과 유스케이스 명세서(기본 흐름, 대안 흐름, 사전·사후 조건)로 표현한다.
보기별 해설
정리
다음 중 SOLID 원칙이라고 불리는 객체지향 설계 원칙에 속하지 않는 것은?
핵심 해설
SOLID는 로버트 마틴이 정리한 객체지향 설계 5원칙의 머리글자이다. SRP(Single Responsibility Principle, 단일 책임), OCP(Open-Closed Principle, 개방-폐쇄), LSP(Liskov Substitution Principle, 리스코프 치환), ISP(Interface Segregation Principle, 인터페이스 분리), DIP(Dependency Inversion Principle, 의존 역전)로 구성된다. SSO(Single Sign On)는 한 번의 인증으로 여러 시스템을 이용하는 통합 인증 기술로, 설계 원칙이 아니라 보안·인증 분야의 용어이다.
보기별 해설
정리
객체지향 분석 방법론 중 Jacobson 방법에 해당하는 것은?
핵심 해설
객체지향 분석 방법론은 제안자마다 강조점이 다르다. 야콥슨(Jacobson)의 OOSE(Object-Oriented Software Engineering)는 사용자와 시스템의 상호작용을 Use-Case로 도출하고, 이 Use-Case를 분석·설계·테스트 전 과정의 중심 축으로 삼는 것이 가장 큰 특징이다. 이에 비해 코드-요든은 E-R 다이어그램 기반, 럼바우는 객체·동적·기능 세 모형, 부치(Booch)는 미시적·거시적 개발 프로세스를 사용한다. 따라서 Use-Case를 강조하는 방법이 야콥슨에 해당한다.
보기별 해설
정리
한 모듈 내의 각 구성 요소들이 공통의 목적을 달성하기 위하여 서로 얼마나 관련이 있는지의 기능적 연관의 정도를 나타내는 것은?
핵심 해설
모듈의 품질은 응집도와 결합도라는 두 축으로 평가한다. 응집도(Cohesion)는 한 모듈 내부의 구성 요소들이 하나의 공통 목적을 위해 얼마나 밀접하게 관련되어 있는지를 나타내는 기능적 연관의 정도로, 모듈 '내부'를 보는 척도이다. 결합도(Coupling)는 서로 다른 모듈 '사이'의 상호 의존 정도를 나타낸다. 좋은 설계는 응집도는 높고 결합도는 낮아야 하므로, 문제에서 묻는 모듈 내부의 기능적 연관 정도는 Cohesion이다.
보기별 해설
정리
소프트웨어 공학에서 모델링(Modeling)과 관련한 설명으로 틀린 것은?
핵심 해설
모델링(Modeling)은 복잡한 시스템을 추상화해 그림·기호·문서로 표현하는 활동으로, 개발 전 과정에서 활용된다. 요구사항 분석 단계에서는 문제 영역을 이해하는 수단이 되고, 설계 단계에서는 구조와 동작을 표현하며, 구현·유지보수 단계에서는 시스템 이해와 변경 영향 파악을 돕는다. 또 개발자·기획자·현업 담당자 등 서로 다른 분야의 사람들이 같은 개념을 공유하는 의사소통 도구가 된다. 따라서 유지보수 단계에서만 모델링을 활용한다는 진술은 틀렸다.
보기별 해설
정리
GoF(Gangs of Four) 디자인 패턴 중 생성 패턴으로 옳은 것은?
핵심 해설
GoF 디자인 패턴은 목적에 따라 생성(Creational), 구조(Structural), 행위(Behavioral) 세 그룹으로 나뉜다. 생성 패턴은 객체를 만드는 과정을 캡슐화해 시스템이 어떤 구체 클래스를 사용하는지 감추는 패턴으로 Factory Method, Abstract Factory, Builder, Prototype, Singleton이 속한다. 그중 Singleton은 특정 클래스의 인스턴스가 오직 하나만 생성되도록 보장하고 전역 접근점을 제공하는 생성 패턴이다. Adapter와 Decorator는 구조 패턴, State는 행위 패턴이다.
보기별 해설
정리
요구사항 명세 기법에 대한 설명으로 틀린 것은?
핵심 해설
요구사항 명세 기법은 표현 방식에 따라 비정형(Informal) 명세와 정형(Formal) 명세로 나뉜다. 비정형 명세는 자연어나 그림, 도표를 사용해 서술하므로 작성과 이해가 쉬운 대신 의미가 모호해질 수 있다. 정형 명세는 Z, VDM, Petri-net처럼 수학적 원리와 표기법을 사용해 요구사항을 기술하므로 표현이 간결하고 명세의 일관성·완전성을 검증할 수 있으나 작성자와 독자 모두 전문 지식이 필요하다. 따라서 Z는 정형 명세 기법이며, 이를 비정형 명세 기법이라고 한 진술이 틀렸다.
보기별 해설
정리
GoF(Gang of Four) 디자인 패턴을 생성구조행동, , 패턴의 세 그룹으로 분류할 때구조, 패턴이 아닌 것은?
핵심 해설
GoF 디자인 패턴의 구조(Structural) 패턴은 클래스와 객체를 조합해 더 큰 구조를 만드는 방법을 다루며 Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy 일곱 가지가 속한다. 반면 Builder는 복잡한 객체의 생성 과정과 표현 방법을 분리해 동일한 생성 절차로 서로 다른 표현의 객체를 만들 수 있게 하는 생성(Creational) 패턴이다. 객체를 '어떻게 만드는가'를 다루므로 구조 패턴에 해당하지 않는다.
보기별 해설
정리
UML에서 활용되는 다이어그램 중시스템의, 동작을 표현하는 행위 (Behavioral) 다이어그램에 해당하지 않는 것은?
핵심 해설
UML 다이어그램은 시스템의 정적 구조를 표현하는 구조(Structural) 다이어그램과 동작·흐름을 표현하는 행위(Behavioral) 다이어그램으로 나뉜다. 구조 다이어그램에는 클래스, 객체, 컴포넌트, 배치(Deployment), 복합체 구조, 패키지 다이어그램이 속한다. 행위 다이어그램에는 유스케이스, 시퀀스, 커뮤니케이션, 상태, 활동, 타이밍 다이어그램이 속한다. 배치 다이어그램은 소프트웨어 산출물이 어느 하드웨어 노드에 배포되는지 물리적 구성을 나타내는 구조 다이어그램이므로 행위 다이어그램이 아니다.
보기별 해설
정리
분산 시스템에서의 미들웨어(Middleware)와 관련한 설명으로 틀린 것은?
핵심 해설
미들웨어(Middleware)는 운영체제와 응용 프로그램 사이, 또는 서로 다른 시스템 사이에 위치해 통신과 데이터 교환, 트랜잭션 관리 등을 중계하는 소프트웨어이다. 분산 시스템에서 미들웨어는 클라이언트와 서버, 응용 프로그램과 데이터베이스, 서로 다른 플랫폼의 컴포넌트 등 다양한 구성 요소 사이를 연결하며, 자원의 실제 위치를 몰라도 사용할 수 있게 하는 위치 투명성을 제공한다. 따라서 '애플리케이션과 사용자 사이에서만' 분산 서비스를 제공한다는 설명은 미들웨어의 역할 범위를 지나치게 좁힌 틀린 진술이다.
보기별 해설
정리
결합도(Coupling)에 대한 설명으로 틀린 것은?
핵심 해설
결합도(Coupling)는 두 모듈 사이의 상호 의존 정도를 나타내며, 약한 순서로 자료(Data) → 스탬프(Stamp) → 제어(Control) → 외부(External) → 공통(Common) → 내용(Content) 결합도로 구분한다. 이 중 자료 결합도는 모듈 간에 꼭 필요한 개별 데이터 항목만을 매개변수로 주고받는 가장 바람직한 결합이다. 반면 배열이나 레코드 같은 자료 구조 전체를 매개변수로 전달하고 일부만 사용하는 경우는 스탬프 결합도(Stamp Coupling)에 해당한다. 따라서 자료 결합도를 자료 구조 형태의 전달로 설명한 1번이 틀렸다.
보기별 해설
정리
소프트웨어 개발 방법 중 요구사항 분석(Requirements Analysis)과 거리가 먼 것은?
핵심 해설
요구사항 분석(Requirements Analysis)은 사용자의 요구를 도출하고 그 타당성을 조사해 무엇을 만들 것인지 정의한 뒤 요구사항 명세서로 문서화하는 활동이다. 여기에는 타당성 조사(경제적·기술적·법적 검토), 요구사항 도출과 분류, 비용과 일정 등 제약 조건 설정, 요구사항 정의 문서화와 검토가 포함된다. 반면 설계 명세서 작성은 확정된 요구사항을 어떻게 구현할지 구조와 모듈을 정하는 설계(Design) 단계의 산출물이다. 즉 분석은 'What', 설계는 'How'를 다루므로 설계 명세서 작성이 가장 거리가 멀다.