반응형
✅ 2022년 04월 24일
💡 1. UML, Unified Modeling Language 다이어그램 중 순차 다이어그램(Sequence Diagram)에 대한 설명으로 틀린 것은?
- 객체 간의 동적 상호작용을 시간 개념을 중심으로 모델링하는 것이다.
주로 시스템의 정적 측면을 모델링하기 위해 사용한다.- 일반적으로 다이어그램의 수직 방향이 시간의 흐름을 나타낸다.
- 회귀 메시지(Self-Message), 제어블록(Statement block) 등으로 구성된다.
순차 다이어그램(Sequence Diagram)
- 객체 간 상호작용을 메시지(Message)로 표현한다.
- 시간의 흐름을 나타내는 시간축(Time Axis)을 가진다.
- 객체 간의 상호작용을 표현한다.
💡 2. 메시지 지향 미들웨어(MOM, Message-Oriented Middleware)에 대한 설명으로 틀린 것은?
느리고 안정적인 응답보다는 즉각적인 응답이 필요한 온라인 업무에 적합하다.- 독립적인 애플리케이션을 하나의 통합된 시스템으로 묶기 위한 역할을 한다.
- 송신 측과 수신 측의 연결 시 메시지 큐를 활용하는 방법이 있다.
- 상이한 애플리케이션 간 통신을 비동기 방식으로 지원한다.
메시지 지향 미들웨어(MOM, Message-Oriented Middleware)
- 분산 환경에서의 메시지 전송과 처리를 관리하는 미들웨어이다.
- 비동기적 메시지(Message)를 기반으로 한 통신 방식을 사용한다.
- 메시지 전송에 대한 에러 처리, 재전송 기능, 트랜잭션 처리 등을 지원하여 데이터의 안정적인 전송을 보장한다.
💡 3. 익스트림 프로그래밍(XP, Extreme Programming)에 대한 설명으로 틀린 것은?
대표적인 구조적 방법론 중 하나이다.- 소규모 개발 조직이 불확실하고 변경이 많은 요구를 접하였을 때 적절한 방법이다.
- 익스트림 프로그래밍을 구동시키는 원리는 상식적인 원리와 경험을 최대한 끌어올리는 것이다.
- 구체적인 실천 방법을 정의하고 있으며, 개발 문서보다는 소스코드에 중점을 둔다.
익스트림 프로그래밍(XP, Extreme Programming)
- 빠른 개발과 고객 요구사항 변화에 대응하기 위한 유연한 개발 프로세스를 강조한다.
- 1~4주 정도의 짧은 주기를 반복하면서, 작은 기능 단위로 개발하고 테스트한다.
- 개발을 시작하기 전에 테스트 케이스를 작성하고, 해당 테스트 케이스를 통과하는 코드를 작성한다.
- 일일 스탠드업 미팅을 비롯한 다양한 소통 방법을 도입하여, 프로젝트 전반에 걸쳐 정보를 공유하고, 문제점을 빠르게 파악하고 해결한다.
💡 4. 유스케이스(Use Case)의 구성 요소 간의 관계에 포함되지 않는 것은?
- 연관 관계(Association): 유스케이스와 액터, 액터와 액터, 유스케이스와 유스케이스 등 요소들 간의 관계이다.
- 확장 관계(Extension): 한 유스케이스가 다른 유스케이스의 기능을 확장하는 관계이다.
구체화- 일반화 관계(Generalization): 여러 유스케이스가 공통적인 기능이나 속성을 가지고 있는 경우, 상위 유스케이스로 일반화하여 공통적인 부분을 추상화한다.
- 포함 관계(Inclusion): 한 유스케이스가 다른 유스케이스의 일부 기능을 포함하는 관계이다.
💡 5. 요구사항 분석에서 비기능적 요구에 대한 설명으로 옳은 것은?
- 시스템의 처리량(Throughput), 반응 시간 등의 성능 요구나 품질 요구는 비기능적 요구에 해당하지 않는다.
- '차량 대여 시스템이 제공하는 모든 화면이 3초 이내에 사용자에게 보여야 한다'는 비기능적 요구이다.
- 시스템 구축과 관련된 안전, 보안에 대한 요구사항들은 비기능적 요구에 해당하지 않는다.
- '금융 시스템은 조회, 인출, 입금, 송금의 기능이 있어야 한다'는 비기능적 요구이다.
비기능적 요구
- 시스템의 기능적 요구 이외의 요구사항이다.
- 성능(Performance), 안정성(Reliability), 보안(Security), 사용성(Usability), 유지보수성(Maintainability)
💡 6. 정보공학 방법론에서 데이터베이스 설계의 표현으로 사용하는 모델링 언어는?
- 패키지 다이어그램(Package Diagram): 소프트웨어의 구조를 보여주는 다이어그램이다.
- 상태 전이 다이어그램(State Transition Diagram): 시스템이 객체의 상태 변화에 따라 수행하는 동작을 모델링하기 위해 사용하는 다이어그램이다.
- 배치 다이어그램(Deployment Diagram): 소프트웨어 컴포넌트들이 어떻게 하드웨어에 배치되는지를 보여주는 다이어그램이다.
- 엔티티-관계 모델링 언어(ERD, Entity-Relationship Diagram): 현실 세계에서 개체(Entity)들 간의 관계(Relationship)를 그래픽적으로 표현하는 방식이다.
💡 7. 미들웨어(Middleware)에 대한 설명으로 틀린 것은?
- 여러 운영체제에서 응용 프로그램들 사이에 위치한 소프트웨어이다.
미들웨어의 서비스 이용을 위해 사용자가 정보 교환 방법 등의 내부 동작을 쉽게 확인할 수 있어야 한다.- 소프트웨어 컴포넌트를 연결하기 위한 준비된 인프라 구조를 제공한다.
- 여러 컴포넌트를 1대 1, 1대 다, 다대 다 등 여러 가지 형태로 연결이 가능하다.
미들웨어(Middleware)
- 다양한 컴퓨터 시스템 및 네트워크 간의 통신을 원활하게 하기 위해 사용되는 소프트웨어이다.
- 서로 다른 하드웨어, 운영체제, 프로그래밍 언어, 프로토콜 등 다양한 시스템 간의 통신을 지원한다.
- 분산 컴퓨팅 환경에서 여러 시스템 간의 자원 공유를 지원한다.
- 다양한 프로토콜을 처리하는 데 필요한 복잡한 로직을 담당한다.
- SOA 아키텍처에서 서비스의 발견, 호출, 메시지 교환 등을 처리하여, 서비스 지향 시스템을 구현한다.
- 시스템 간의 보안 및 트랜잭션 처리를 담당한다.
💡 8. UI, User Interface의 설계 지침으로 틀린 것은?
- 이해하기 편하고 쉽게 사용할 수 있는 환경을 제공해야 한다.
- 주요 기능을 메인 화면에 노출하여 조작이 쉽도록 하여야 한다
치명적인 오류에 대한 부정적인 사항은 사용자가 인지할 수 없도록 한다.- 사용자의 직무, 연령, 성별 등 다양한 계층을 수용하여야 한다.
UI, User Interface의 설계 지침
- 사용자 중심적 설계(User-centered design): 사용자들의 요구와 행동 패턴을 분석하여, 사용자 경험(UX)을 최적화한다.
- 일관성 있는 디자인(Consistent design): UI 요소들의 배치, 색상, 글꼴 등을 일관성 있게 유지하여, 사용자가 익숙한 패턴으로 구성한다.
- 직관적인 UI 설계(Intuitive design): 버튼의 위치나 레이아웃 등은 직관적인 방식으로 설계한다.
- 적절한 피드백 제공(Feedback): 사용자가 버튼을 클릭하거나 입력을 완료하면, 적절한 피드백을 제공하여 사용자가 성공적으로 작업을 수행함을 알린다.
- 접근성(Accessibility): 대체 텍스트, 색상 대비, 키보드 제어 등의 기능을 제공한다.
💡 9. 객체지향 개념에서 다형성(Polymorphism)과 관련한 설명으로 틀린 것은?
- 다형성은 현재 코드를 변경하지 않고 새로운 클래스를 쉽게 추가할 수 있게 한다.
- 다형성이란 여러 가지 형태를 가지고 있다는 의미로, 여러 형태를 받아들일 수 있는 특징을 말한다.
- 메서드 오버라이딩(Overriding)은 상위 클래스에서 정의한 일반 메서드의 구현을 하위 클래스에서 무시하고 재정의할 수 있다.
메서드 오버로딩(Overloading)의 경우 매개 변수 타입은 동일하지만 메서드명을 다르게 함으로써 구현, 구분할 수 있다.
- 오버라이딩(Overriding): 상위 클래스에서 정의된 메서드를 하위 클래스에서 재정의하여 사용하는 것으로, 메서드 이름, 매개변수, 반환형이 일치해야 하며, 상위 클래스의 메서드와 동일한 시그니처를 가진다.
- 오버로딩(Overloading): 같은 이름의 메서드를 매개변수의 종류, 개수, 순서 등을 다르게 하여 여러 개 정의한다.
💡 10. 소프트웨어 개발 영역을 결정하는 요소 중 다음 사항과 관계있는 것은?
소프트웨어에 의해 간접적으로 제어되는 장치와 소프트웨어를 실행하는 하드웨어
기존의 소프트웨어와 새로운 소프트웨어를 연결하는 소프트웨어
순서적 연산에 의해 소프트웨어를 실행하는 절차
- 기능(Function): 시스템이 제공해야 하는 기능을 정의하고 명세한다.
- 성능(Performance): 시스템이 수행하는 작업의 속도나 처리량 등을 평가하고 최적화한다.
- 제약 조건(Constraint): 시스템 설계나 구현에 적용되는 제한 조건을 명확하게 정의한다.
- 인터페이스(Interface): 시스템과 시스템, 시스템과 사용자, 시스템과 외부 시스템 등 각 요소들 간의 상호작용을 정의한다.
💡 11. 객체에 대한 설명으로 틀린 것은?
- 객체는 상태, 동작, 고유 식별자를 가진 모든 것이라 할 수 있다.
객체는 공통 속성을 공유하는 클래스들의 집합이다.- 객체는 필요한 자료 구조와 이에 수행되는 함수들을 가진 하나의 독립된 존재이다.
- 객체의 상태는 속성 값에 의해 정의된다.
클래스(Class)
- 객체 지향 프로그래밍에서 데이터와 해당 데이터를 조작하는 함수를 함께 묶어 놓은 사용자 정의 데이터 타입이다.
- 클래스를 사용하여 객체를 생성하면, 해당 객체는 클래스의 속성과 메서드를 상속받아 사용할 수 있다.
- 캡슐화, 상속, 다형성 등의 개념을 제공하여, 복잡한 프로그램의 구조를 단순하고 유연하게 만들어 준다.
💡 12. 속성과 관련된 연산(Operation)을 클래스 안에 묶어서 하나로 취급하는 것을 의미하는 객체지향 개념은?
- 상속(Inheritance): 객체 지향 프로그래밍에서 하위 클래스가 상위 클래스의 속성과 동작을 상속받는 개념이다.
- 클래스(Class): 객체 지향 프로그래밍에서 데이터와 해당 데이터를 처리하는 함수를 하나의 단위로 묶어놓은 사용자 정의 자료형이다.
- 캡슐화(Encapsulation): 객체 지향 프로그래밍에서 객체의 속성과 동작을 하나로 묶고, 외부에서 접근을 제어하는 개념이다.
- 연관관계(Association): 객체 지향 프로그래밍에서 두 개 이상의 객체들 간에 서로 관련이 있다는 개념이다.
💡 13. 애자일(Agile) 프로세스 모델에 대한 설명으로 틀린 것은?
변화에 대한 대응보다는 자세한 계획을 중심으로 소프트웨어를 개발한다.- 프로세스와 도구 중심이 아닌 개개인과의 상호소통을 통해 의견을 수렴한다.
- 협상과 계약보다는 고객과의 협력을 중시한다.
- 문서 중심이 아닌, 실행 가능한 소프트웨어를 중시한다.
애자일(Agile) 프로세스 모델
- 소프트웨어 개발 방법론 중 하나로 빠르고 유연하게 요구사항을 반영하면서 개발을 진행하는 방법이다.
- 고객과의 소통을 중요시하며, 작은 주기로 반복적인 개발을 진행하여 빠르게 피드백을 받고 문제를 수정한다.
- 변화에 대응할 수 있는 유연성을 제공하고, 고객의 요구사항을 빠르게 수용하여 고객 만족도를 향상한다.
💡 14. 명백한 역할을 가지고 독립적으로 존재할 수 있는 시스템의 부분으로 넓은 의미에서는 재사용되는 모든 단위라고 볼 수 있으며, 인터페이스를 통해서만 접근할 수 있는 것은?
- 모델(Model): 데이터를 처리하는 데 사용되는 소프트웨어 요소이며, 데이터의 구조와 규칙을 정의한다.
- 시트(Sheet): 데이터를 저장하고 편집할 수 있는 하나의 표 형식의 문서이다.
- 컴포넌트(Component): 프로그래밍에서 하나의 기능을 수행하는 독립적인 모듈이다.
- 셀(Cell): 하나의 데이터를 저장하는 단위이며, 행과 열의 교차점에 위치한다.
💡 15. GoF, Gang of Four 디자인 패턴을 생성, 구조, 행동 패턴의 세 그룹으로 분류할 때, 구조 패턴이 아닌 것은?
- 어댑터(Adapter): 구조 패턴
- 브리지(Bridge): 구조 패턴
- 빌더(Builder): 생성 패턴
- 프락시(Proxy): 구조 패턴
- 생성 패턴: 기존 코드의 유연성과 재사용을 증가시키는 객체를 생성한다.
- 팩토리 메서드(Factory Method): 부모 클래스에서 객체를 생성할 수 있는 인터페이스를 제공하지만, 자식 클래스들이 생성될 객체의 유형을 변경한다.
- 추상 팩토리(Abstract Factory): 관련 객체들의 구상 클래스들을 지정하지 않고도 그들의 패밀리들을 생성한다.
- 빌더(Builder): 복잡한 객체들을 단계별로 생성한다.
- 프로토타입(Prototype): 코드를 클래스들에 의존시키지 않고 기존 객체들을 복사한다.
- 싱글턴(Singleton): 클래스에 인스턴스가 하나만 있도록 하면서 인스턴스에 대한 전역 접근 지점을 제공한다.
- 구조 패턴: 객체들과 클래스들을 구조를 유연하고 효율적으로 유지하면서 더 큰 구조로 조립한다.
- 어댑터(Adapter): 호환되지 않는 인터페이스를 가진 객체들을 협업한다.
- 브리지(Bridge): 큰 클래스 또는 밀접하게 관련된 클래스들의 집합을 두 개의 개별 계층구조로 나눈 후 각각 독립적으로 개발한다.
- 복합체(Composite): 객체들을 트리 구조들로 구성한 후, 개별 객체들인 것처럼 작업한다.
- 데코레이터(Decorator): 객체들에 새로운 행동들을 포함한 특수 래퍼 객체들 내에 넣어서 해당 객체들에 연결한다.
- 퍼사드(Facade): 라이브러리 및 프레임워크에 대한 단순화된 인터페이스를 제공한다.
- 플라이웨이트(Flyweight): 각 객체에 모든 데이터를 유지하는 대신 여러 객체 간에 상태의 공통부분들을 공유한다.
- 프록시(Proxy): 다른 객체에 대한 대체 또는 자리표시자를 제공한다.
- 행위 패턴: 객체 간의 효과적인 의사소통과 책임 할당을 처리한다.
- 책임 연쇄(Chain of Responsibility): 일련의 핸들러들의 사슬을 따라 요청을 전달한다.
- 커맨드(Command): 요청을 요청에 대한 모든 정보가 포함된 독립 실행형 객체로 변환한다.
- 반복자(Iterator): 컬렉션의 요소들의 기본 표현(리스트, 스택, 트리 등)을 노출하지 않고 하나씩 순회한다.
- 중재자(Mediator): 객체 간의 직접 통신을 제한하고 중재자 객체를 통해서만 협력한다.
- 메멘토(Memento): 객체의 구현 세부 사항을 공개하지 않으면서 해당 객체의 이전 상태를 저장하고 복원한다.
- 옵서버(Observer): 여러 객체에 자신이 관찰 중인 객체에 발생하는 모든 이벤트에 대하여 알리는 구독 메커니즘을 정의한다.
- 상태(State): 객체의 내부 상태가 변경될 때 해당 객체가 그의 행동을 변경한다.
- 전략(Strategy): 알고리즘들의 패밀리를 정의하고, 각 패밀리를 별도의 클래스들에 넣은 후 객체들을 상호교환한다.
- 템플릿 메서드(Template Method): 부모 클래스에서 알고리즘의 골격을 정의하지만, 해당 알고리즘의 구조를 변경하지 않고 자식 클래스들이 알고리즘의 특정 단계들을 오버라이드한다.
- 비지터(Visitor): 알고리즘들을 작동하는 객체들로부터 분리한다.
💡 16. UI와 관련된 기본 개념 중 하나로, 시스템의 상태와 사용자의 지시에 대한 효과를 보여주어 사용자가 명령에 대한 진행 상황과 표시된 내용을 해석할 수 있도록 도와주는 것은?
- 피드백(Feedback): 어떤 결과물에 대한 정보를 제공하거나, 행동의 결과에 대한 정보를 받아들이는 과정이다.
- 자세(Posture): 컴퓨터에서는 자세 추정 기술을 이용하여 사람의 자세를 추정한다.
- 모듈(Module): 로그래밍에서 기능 단위로 묶어서 관리하는 독립적인 코드 블록이다.
- 해시(Hash): 고정된 길이의 데이터를 출력하는 해시 함수를 이용하여 입력 데이터를 변환한 값이다.
💡 17. UI의 종류로 멀티 터치(Multi-touch), 동작 인식(Gesture Recognition) 등 사용자의 자연스러운 움직임을 인식하여 서로 주고받는 정보를 제공하는 사용자 인터페이스를 의미하는 것은?
- GUI, Graphical User Interface: 그래픽으로 구성된 사용자 인터페이스이다.
- OUI, Organic User Interface: 사람의 몸과 자연스러운 인터페이스를 지향하는 사용자 인터페이스이다.
- NUI, Natural User Interface: 자연스러운 사용자 인터페이스를 지향하는 기술로, OUI를 포함한다.
- CLI, Command Line Interface: 명령어를 이용하여 컴퓨터와 상호작용하는 사용자 인터페이스이다.
💡 18. 소프트웨어 모델링(Modeling)과 관련한 설명으로 틀린 것은?
모델링 작업의 결과물은 다른 모델링 작업에 영향을 줄 수 없다.- 구조적 방법론에서는 DFD(Data Flow Diagram), DD(Data Dictionary) 등을 사용하여 요구 사항의 결과를 표현한다.
- 객체지향 방법론에서는 UML 표기법을 사용한다.
- 소프트웨어 모델을 사용할 경우 개발될 소프트웨어에 대한 이해도 및 이해 당사자 간의 의사소통 향상에 도움이 된다.
모델링(Modeling)
- 현실 세계를 추상화하여 컴퓨터로 표현하는 과정이다.
- 모델링을 통하여 시스템의 동작과 상호작용, 구조 등을 이해한다.
- 시뮬레이션, 데이터베이스 설계, 소프트웨어 개발 등에서 활용한다.
💡 19. 유스케이스 다이어그램(Use Case Diagram)에 관련된 내용으로 틀린 것은?
- 시스템과 상호작용하는 외부시스템은 액터로 파악
해서는 안 된다. - 유스케이스는 사용자 측면에서의 요구사항으로, 사용자가 원하는 목표를 달성하기 위해 수행할 내용을 기술한다.
- 시스템 액터는 다른 프로젝트에서 이미 개발되어 사용되고 있으며, 본 시스템과 데이터를 주고받는 등 서로 연동되는 시스템을 말한다.
- 액터가 인식할 수 없는 시스템 내부의 기능을 하나의 유스케이스로 파악해서는 안 된다.
유스케이스 다이어그램(Use Case Diagram)
- 시스템의 기능과 사용자, 외부 시스템 등의 역할을 나타내는 UML 다이어그램이다.
- 액터(Actor)는 시스템과 상호작용하는 외부 개체를 나타내는 요소로 사용자, 다른 시스템, 장치 등이다.
- 시스템의 기능을 사용자 시나리오로 모델링하여 시스템의 요구사항을 파악하고, 사용자와 시스템 간의 상호작용을 명확하게 설명하는 데 활용한다.
💡 20. 소프트웨어 아키텍처 모델 중 MVC, Model-View-Controller와 관련한 설명으로 틀린 것은?
- MVC 모델은 사용자 인터페이스를 담당하는 계층의 응집도를 높일 수 있고, 여러 개의 다른 UI를 만들어 그 사이에 결합도를 낮출 수 있다.
모델(Model)은 뷰(View)와 제어(Controller) 사이에서 전달자 역할을 하며, 뷰마다 모델 서브시스템이 각각 하나씩 연결된다.- 뷰(View)는 모델(Model)에 있는 데이터를 사용자 인터페이스에 보이는 역할을 담당한다.
- 제어(Controller)는 모델(Model)에 명령을 보냄으로써 모델의 상태를 변경할 수 있다.
MVC, Model-View-Controller
- 소프트웨어를 세 가지 역할(Model, View, Controller)로 분리하여 설계한다.
- Model: 데이터를 처리하는 부분을 담당한다.
- View: 사용자 인터페이스를 담당한다.
- Controller: Model과 View를 연결하여 사용자의 요청을 처리한다.
✅ 2022년 03월 05일
💡 1. User Interface 설계 시 오류 메시지나 경고에 관한 지침으로 가장 거리가 먼 것은?
- 메시지는 이해하기 쉬워야 한다. (직관성, Intuitiveness)
- 오류로부터 회복을 위한 구체적인 설명이 제공되어야 한다.
- 오류로 인해 발생될 수 있는 부정적인 내용을 적극적으로 사용자들에게 알려야 한다.
소리나 색의 사용을 줄이고 텍스트로만 전달하도록 한다.
오류 메시지나 경고에 관한 지침
- 사용자에게 발생한 문제에 대해 명확하게 설명한다.
- 발생한 문제의 원인을 정확히 파악하여 제공한다.
- 발생한 문제의 위치를 사용자에게 설명한다.
- 경고와 오류는 서로 다른 수준의 문제이므로, 구분하여 제공한다.
- 사용자가 해결할 수 있는 대처 방안을 제공한다.
💡 2. 다음 중 애자일(Agile) 소프트웨어 개발에 대한 설명으로 틀린 것은?
- 공정과 도구보다 개인과의 상호작용을 더 가치 있게 여긴다.
동작하는 소프트웨어보다는 포괄적인 문서를 가치 있게 여긴다.- 계약 협상보다는 고객과의 협력을 가치 있게 여긴다.
- 계획을 따르기보다 변화에 대응하기를 가치 있게 여긴다.
애자일(Agile) 프로세스 모델
- 소프트웨어 개발 방법론 중 하나로 빠르고 유연하게 요구사항을 반영하면서 개발을 진행한다.
- 고객과의 소통을 중요시하며, 작은 주기로 반복적인 개발을 진행하여 빠르게 피드백을 받고 문제를 수정한다.
- 변화에 대응할 수 있는 유연성을 제공하고, 고객의 요구사항을 빠르게 수용하여 고객 만족도를 높일 수 있다.
💡 3. 소프트웨어 설계에서 요구사항 분석에 대한 설명으로 틀린 것은?
- 소프트웨어가 무엇을 해야 하는가를 추적하여 요구사항 명세를 작성하는 작업이다.
- 사용자의 요구를 추출하여 목표를 정하고 어떤 방식으로 해결할 것인지 결정하는 단계이다.
소프트웨어 시스템이 사용되는 동안 발견되는 오류를 정리하는 단계이다.- 소프트웨어 개발의 출발점이면서 실질적인 첫 번째 단계이다.
- 요구사항 분석: 시스템이 가져야 할 기능, 성능, 제약조건 등을 명확하게 정의한다.
- 요구사항 검증: 시스템이 제대로 동작하는지를 확인하는 과정으로, 요구사항 명세에 부합하는지 여부를 검토하며, 문제가 발생할 가능성을 최소화한다.
💡 4. 객체지향 기법에서 상위 클래스의 메서드와 속성을 하위 클래스가 물려받는 것을 의미하는 것은?
- 추상화(Abstraction): 복잡한 시스템을 단순화하여 핵심적인 요소만 추출한다.
- 다형성(Polymorphism): 같은 이름의 메서드가 서로 다른 동작을 수행한다.
- 캡슐화(Encapsulation): 객체의 상태와 행위를 하나로 묶어 외부로부터의 접근을 제한한다.
- 상속성(Inheritance): 부모 클래스의 특성을 자식 클래스가 물려받아 확장한다.
💡 5. 설계 기법 중 하향식 설계 방법과 상향식 설계 방법에 대한 비교 설명으로 가장 옳지 않은 것은?
- 하향식 설계는 통합 검사 시 인터페이스가 이미 정의되어 있어 통합이 간단하다.
- 하향식 설계에서 레벨이 낮은 데이터 구조의 세부 사항은 설계 초기 단계에서 필요하다.
- 상향식 설계는 최하위 수준에서 각각의 모듈들을 설계하고 이러한 모듈이 완성되면 이들을 결합하여 검사한다.
상향식 설계에서 인터페이스가 이미 성립되어 있지 않더라도 기능 추가가 쉽다.
상향식(Bottom Up) 설계
- 인터페이스를 먼저 정의하고, 이를 기반으로 모듈을 개발한다.
- 시스템이 다양한 변경에 대응할 수 있도록 유연성을 향상한다.
💡 6. 자료흐름도(DFD)의 각 요소별 표기 형태의 연결이 옳지 않은 것은?
- 프로세스(Process): 원형 또는 타원형으로 표기하며, 프로세스 번호와 함께 표시한다.
- 데이터 흐름(Data Flow): 화살표로 표기하며, 데이터의 흐름 방향과 함께 표시한다.
데이터 저장소(Data Store): 삼각형- 외부 개체(External Entity): 직사각형으로 표기하며, 외부 개체의 이름을 함께 표시한다.
- 데이터 저장소(Data Store): 병렬선으로 표기하며, 데이터 저장소 이름을 함께 표시한다.
💡 7. 소프트웨어 개발에 이용되는 모델(Model)에 대한 설명 중 거리가 먼 것은?
- 모델은 개발 대상을 추상화하고 기호나 그림 등으로 시각적으로 표현한다.
- 모델을 통해 소프트웨어에 대한 이해도를 향상할 수 있다.
- 모델을 통해 이해 당사자 간의 의사소통이 향상된다.
모델을 통해 향후 개발될 시스템의 유추는 불가능하다.
모델(Model)
- 폭포수 모델(Waterfall Model): 개발 생명주기를 단계별로 수행하는 모델로, 각 단계가 완료될 때마다 다음 단계로 넘어가는 선형적인 개발 방식이다.
- 프로토타입 모델(Prototype Model): 초기 요구사항 수집 및 분석을 통해 개발하고자 하는 소프트웨어의 프로토타입을 만들어 가며 요구사항을 보완하는 개발 방식이다.
- 애자일 모델(Agile Model): 소규모의 개발 팀이 작업을 진행하면서 지속적으로 피드백을 주고받으며 빠른 속도로 개발을 진행하는 방식이다.
- 나선형 모델(Spiral Model): 개발 생명주기를 나선형으로 표현하며, 매 단계마다 위험 분석을 수행하고, 이를 기반으로 개발 계획을 조정하는 개발 방식이다.
- V자 모델(V-Model): 폭포수 모델을 확장한 개발 방식으로, 각 단계에서 검증 및 검토를 수행하여 소프트웨어 품질을 보증하는 개발 방식이다.
💡 8. 다음의 설명에 해당하는 언어는?
객체 지향 시스템을 개발할 때 산출물을 명세화, 시각화, 문서화하는 데 사용된다.
즉, 개발하는 시스템을 이해하기 쉬운 형태로 표현하여 분석가, 의뢰인, 설계자가 효율적인 의사소통을 할 수 있게 해 준다.
따라서, 개발 방법론이나 개발 프로세스가 아니라 표준화된 모델링 언어이다.
- JAVA: 객체 지향 프로그래밍 언어로 강력한 컴퓨팅 기능과 다양한 플랫폼에서 동작한다.
- C 언어: 절차 지향적인 프로그래밍 언어로 시스템 프로그래밍과 임베디드 시스템에서 사용한다.
- UML, Unified Modeling Language: 객체 지향 소프트웨어 설계를 위한 표준화된 모델링 언어이다.
- Python: 간결하면서도 읽기 쉬운 문법으로 인기 있는 프로그래밍 언어이다.
💡 9. 다음 내용이 설명하는 UI설계 도구는?
디자인, 사용 방법 설명, 평가 등을 위해 실제 화면과 유사하게 만든 정적인 형태의 모형
시작적으로만 구성 요소를 배치하는 것으로 일반적으로 실제로 구현되지는 않음
- 스토리보드(Storyboard): 플로우를 설계하는 데 사용되는 그림이나 스케치를 나열한 문서이다.
- 목업(Mockup): 제품 또는 서비스의 디자인을 구상하기 위해 제작된 저해상도의 시각적인 모형이다.
- 프로토타입(Prototype): 실제 제품 또는 서비스의 일부 또는 전체를 모사한 모형이다.
- 유스케이스(Usecase): 소프트웨어 시스템에서 사용자의 요구사항을 기술한다.
💡 10. 애자일(Agile) 기법 중 스크럼(Scrum)과 관련된 용어에 대한 설명이 틀린 것은?
- 스크럼 마스터(Scrum Master): 스크럼 프로세스를 따르고, 팀이 스크럼을 효과적으로 활용할 수 있도록 보장하는 역할 등을 맡는다.
- 제품 백로그(Product Backlog): 스크럼 팀이 해결해야 하는 목록으로 소프트웨어 요구사항, 아키텍처 정의 등이 포함된다.
스프린트(Sprint): 하나의 완성된 최종 결과물을 만들기 위한 주기로 3달 이상의 장기간으로 결정된다.- 속도(Velocity): 한 번의 스프린트에서 한 팀이 어느 정도의 제품 백로그를 감당할 수 있는지에 대한 추정치로 볼 수 있다.
스프린트(Sprint)
- 소프트웨어 개발 프로젝트를 일정 기간(보통 1주일 ~ 4주)으로 분할하여 개발하는 반복적인 개발 주기이다.
- 미리 정의된 목표를 달성하고, 해당 목표에 대한 결과물을 제공하며, 다음 스프린트를 계획하는 방식으로 개발을 진행한다.
💡 11. UML 다이어그램 중 정적 다이어그램이 아닌 것은?
- 컴포넌트 다이어그램: 정적 다이어그램
- 배치 다이어그램: 정적 다이어그램
순차 다이어그램: 동적 다이어그램- 패키지 다이어그램: 정적 다이어그램
정적 다이어그램 (클객컴배복패)
- 클래스 다이어그램(Class Diagram): 클래스, 인터페이스, 관계 등을 사용하여 시스템의 정적인 구조를 표현하는 다이어그램
- 객체 다이어그램(Object Diagram): 클래스와 인스턴스 간의 관계를 표현하는 다이어그램
- 패키지 다이어그램(Package Diagram): 시스템을 구성하는 여러 클래스와 객체를 그룹화하여 관리하기 위한 패키지를 표현하는 다이어그램
- 컴포넌트 다이어그램(Component Diagram): 시스템을 구성하는 컴포넌트 간의 의존 관계를 표현하는 다이어그램
- 복합구조 다이어그램다이어그램(Composite Structure Diagram): 클래스나 컴포넌트 등의 내부 구조를 표현하는 다이어그램
- 배치 다이어그램(Deployment Diagram): 시스템을 구성하는 하드웨어와 소프트웨어 구성 요소 간의 관계를 표현하는 다이어그램
💡 12. LOC 기법에 의하여 예측된 총 라인수가 36000 라인, 개발에 참여할 프로그래머가 6명, 프로그래머들의 평균 생산성이 월간 300 라인일 때 개발에 소요되는 기간을 계산한 결과로 가장 옳은 것은?
- 5개월
- 10개월
- 15개월
- 20개월
LOC 기법
- 소프트웨어 코드의 크기를 측정하기 위한 방법이다.
- 소프트웨어의 개발 시간, 비용 및 유지보수에 대한 추정을 위해 사용된다.
- 개발 기간 측정 = 예측된 LOC / (투입인원 × 1인당 월평균 LOC) = 36000 라인 / (6명 × 300 라인)
💡 13. 클래스 설계 원칙에 대한 바른 설명은?
- 단일 책임 원칙(SRP, Single Responsibility Principle): 하나의 클래스만 변경 가능 해야 한다.
- 개방-폐쇄 원칙(OCP, Open-Closed Principle): 클래스는 확장에 대해 열려 있어야 하며, 변경에 대해 닫혀 있어야 한다.
- 리스코프 치환 원칙(LSP, Liskov Substitution Principle): 여러 개의 책임을 가진 클래스는 하나의 책임을 가진 클래스로 대체되어야 한다.
- 의존 역전 원칙(DIP, Dependency Inversion Principle): 클라이언트는 자신이 사용하는 메서드와 의존관계를 갖지 않도록 해야 한다.
클래스 설계 원칙
- 단일 책임 원칙(SRP, Single Responsibility Principle): 클래스는 하나의 책임만을 가져야 하며, 해당 책임을 완전히 수행할 수 있도록 설계한다.
- 개방-폐쇄 원칙(OCP, Open-Closed Principle): 확장에는 열려 있고, 수정에는 닫혀 있어야 한다.
- 리스코프 치환 원칙(LSP, Liskov Substitution Principle): 하위 클래스는 상위 클래스를 대체할 수 있어야 한다.
- 의존 역전 원칙(DIP, Dependency Inversion Principle): 추상화에 의존해야 하며, 구체화에 의존하면 안 된다.
- 인터페이스 분리 원칙(ISP, Interface Segregation Principle): 클라이언트는 자신이 사용하지 않는 인터페이스에 의존하지 않아야 한다.
- 데메테르의 법칙(LoD, Law of Demeter): 객체는 자신이 조작하는 객체만 알아야 한다.
💡 14. GoF(Gangs of Four) 디자인 패턴에서 생성 패턴에 해당하는 것은?
- 복합체(Composite): 구조 패턴
- 어댑터(Adapter): 구조 패턴
- 추상 팩토리(Abstract Factory): 생성 패턴
- 옵서버(Observer): 행위 패턴
- 생성 패턴: 기존 코드의 유연성과 재사용을 증가시키는 객체를 생성한다.
- 팩토리 메서드(Factory Method): 부모 클래스에서 객체를 생성할 수 있는 인터페이스를 제공하지만, 자식 클래스들이 생성될 객체의 유형을 변경한다.
- 추상 팩토리(Abstract Factory): 관련 객체들의 구상 클래스들을 지정하지 않고도 그들의 패밀리들을 생성한다.
- 빌더(Builder): 복잡한 객체들을 단계별로 생성한다.
- 프로토타입(Prototype): 코드를 클래스들에 의존시키지 않고 기존 객체들을 복사한다.
- 싱글턴(Singleton): 클래스에 인스턴스가 하나만 있도록 하면서 인스턴스에 대한 전역 접근 지점을 제공한다.
- 구조 패턴: 객체들과 클래스들을 구조를 유연하고 효율적으로 유지하면서 더 큰 구조로 조립한다.
- 어댑터(Adapter): 호환되지 않는 인터페이스를 가진 객체들을 협업한다.
- 브리지(Bridge): 큰 클래스 또는 밀접하게 관련된 클래스들의 집합을 두 개의 개별 계층구조로 나눈 후 각각 독립적으로 개발한다.
- 복합체(Composite): 객체들을 트리 구조들로 구성한 후, 개별 객체들인 것처럼 작업한다.
- 데코레이터(Decorator): 객체들에 새로운 행동들을 포함한 특수 래퍼 객체들 내에 넣어서 해당 객체들에 연결한다.
- 퍼사드(Facade): 라이브러리 및 프레임워크에 대한 단순화된 인터페이스를 제공한다.
- 플라이웨이트(Flyweight): 각 객체에 모든 데이터를 유지하는 대신 여러 객체 간에 상태의 공통부분을 공유한다.
- 프록시(Proxy): 다른 객체에 대한 대체 또는 자리표시자를 제공한다.
- 행위 패턴: 객체 간의 효과적인 의사소통과 책임 할당을 처리한다.
- 책임 연쇄(Chain of Responsibility): 일련의 핸들러들의 사슬을 따라 요청을 전달한다.
- 커맨드(Command): 요청을 요청에 대한 모든 정보가 포함된 독립 실행형 객체로 변환한다.
- 반복자(Iterator): 컬렉션의 요소들의 기본 표현(리스트, 스택, 트리 등)을 노출하지 않고 하나씩 순회한다.
- 중재자(Mediator): 객체 간의 직접 통신을 제한하고 중재자 객체를 통해서만 협력한다.
- 메멘토(Memento): 객체의 구현 세부 사항을 공개하지 않으면서 해당 객체의 이전 상태를 저장하고 복원한다.
- 옵서버(Observer): 여러 객체에 자신이 관찰 중인 객체에 발생하는 모든 이벤트에 대하여 알리는 구독 메커니즘을 정의한다.
- 상태(State): 객체의 내부 상태가 변경될 때 해당 객체가 그의 행동을 변경한다.
- 전략(Strategy): 알고리즘들의 패밀리를 정의하고, 각 패밀리를 별도의 클래스들에 넣은 후 객체들을 상호교환한다.
- 템플릿 메서드(Template Method): 부모 클래스에서 알고리즘의 골격을 정의하지만, 해당 알고리즘의 구조를 변경하지 않고 자식 클래스들이 알고리즘의 특정 단계들을 오버라이드한다.
- 비지터(Visitor): 알고리즘들을 작동하는 객체들로부터 분리한다.
💡 15. 아키텍처 설계 과정이 올바른 순서로 나열된 것은?
㉮ 설계 목표 설정
㉯ 시스템 타입 결정
㉰ 스타일 적용 및 커스터마이즈
㉱ 서브시스템의 기능, 인터페이스 동작 작성
㉲ 아키텍처 설계 검토
- ㉮ → ㉯ → ㉰ → ㉱ → ㉲
- ㉲ → ㉮ → ㉯ → ㉱ → ㉰
- ㉮ → ㉲ → ㉯ → ㉱ → ㉰
- ㉮ → ㉯ → ㉰ → ㉲ → ㉱
💡 16. 사용자 인터페이스(UI)를 설계할 경우 고려해야 할 가이드라인과 가장 거리가 먼 것은?
심미성을 사용성보다 우선하여 설계해야 한다.- 효율성을 높이게 설계해야 한다.
- 발생하는 오류를 쉽게 수정할 수 있어야 한다.
- 사용자에게 피드백을 제공해야 한다.
사용자 인터페이스(UI)를 설계할 때 고려해야 할 가이드라인
- 직관성: 색상, 폰트, 레이아웃 등을 사용한다.
- 일관성: 모든 페이지와 기능에서 일관된 UI를 유지한다.
- 가시성: 사용자가 필요로 하는 모든 기능과 정보를 쉽게 찾을 수 있도록 가시성을 부여한다.
- 효율성: 사용자가 가능한 빠르고 쉽게 작업을 수행할 수 있도록 최적화한다.
- 접근성: 모든 사용자가 UI를 사용할 수 있도록, 특히 장애가 있는 사용자를 고려하여 설계한다.
- 안정성: 사용자가 예상치 못한 결과를 방지하기 위해 경고와 검증 메시지를 제공한다.
- 유연성: 사용자가 원하는 방식으로 UI를 사용할 수 있도록, 설정이나 맞춤 기능을 제공한다.
💡 17. 소프트웨어 설계에서 자주 발생하는 문제에 대한 일반적이고 반복적인 해결 방법을 무엇이라고 하는가?
- 모듈 분해: 복잡한 시스템을 조금 더 작고 관리 가능한 부분으로 나누는 과정이다.
- 디자인 패턴: 소프트웨어 개발에서 발생하는 공통적인 문제를 해결하기 위한 설계 방법이다.
- 연관 관계: 객체 지향 프로그래밍에서 객체들 간의 관계를 표현한다.
- 클래스 도출: 요구사항을 분석하여 필요한 클래스들을 도출한다.
💡 18. 객체지향 분석 기법의 하나로 객체 모형, 동적 모형, 기능 모형의 3개 모형을 생성하는 방법은?
- Wirfs-Block 방법: 요구사항 분석과 설계 단계에서 객체 지향 개념을 적용하여 소프트웨어를 개발하는 방법을 제시한다.
- 럼바우(Object Modeling Technique) 방법: 객체 모델링을 중심으로 요구사항 분석, 설계, 구현, 테스트 등의 단계를 수행한다.
- 부치(Booch) 방법: UML, Unified Modeling Language을 활용하여 시스템 모델링을 수행한다.
- Jacobson 방법: 유스케이스를 중심으로 요구사항을 분석하고 객체 모델을 작성한다.
💡 19. 입력되는 데이터를 컴퓨터의 프로세서가 처리하기 전에 미리 처리하여 프로세서가 처리하는 시간을 줄여주는 프로그램이나 하드웨어를 말하는 것은?
- EAI, Enterprise Application Integration: 기업 내부의 서로 다른 응용 프로그램 및 데이터를 통합하여 효율적인 업무 처리를 위한 솔루션을 제공한다.
- FEP, Front-End Processor: 데이터 송수신을 담당하는 프로그램이나 장치를 가리키며, 사용자와 서버 간의 데이터 통신을 담당한다.
- GPL, General Public License: 자유 소프트웨어 재단에서 만든 오픈 소스 라이선스이다.
- 이중화(Duplexing): 양방향 통신을 위해 동시에 두 개의 통신 링크를 사용하는 방식이다.
💡 20. 객체 지향 개념 중 하나 이상의 유사한 객체들을 묶어 공통된 특성을 표현한 데이터 추상화를 의미하는 것은?
- 메서드(Method): 객체가 수행하는 작업을 정의한 함수이다.
- 클래스(Class): 객체를 생성하기 위한 구조와 기능을 정의한 설계도이다.
- 필드(Field): 객체의 상태를 나타내는 변수이다.
- 메시지(Message): 객체 간의 상호작용을 위한 요청 또는 명령으로, 수신 객체가 처리할 수 있는 작업을 지시한다.
✅ 2021년 08월 14일
💡 1. 요구사항 검증(Requirements Validation)과 관련한 설명으로 틀린 것은?
- 요구사항이 고객이 정말 원하는 시스템을 제대로 정의하고 있는지 점검하는 과정이다.
- 개발완료 이후에 문제점이 발견될 경우 막대한 재작업 비용이 들 수 있기 때문에 요구사항 검증은 매우 중요하다.
- 요구사항이 실제 요구를 반영하는지, 문서상의 요구사항은 서로 상충되지 않는지 등을 점검한다.
요구사항 검증 과정을 통해 모든 요구사항 문제를 발견할 수 있다.
💡 2. UML 모델에서 한 사물의 명세가 바뀌면 다른 사물에 영향을 주며, 일반적으로 한 클래스가 다른 클래스를 오퍼레이션의 매개변수로 사용하는 경우에 나타나는 관계는?
- 연관(Association) 관계: 객체 간의 관계를 표현한다.
- 의존(Dependency) 관계: 하나의 객체가 다른 객체의 기능을 사용한다.
- 실체화(Realization) 관계: 인터페이스를 구현한 클래스와 인터페이스 간의 관계를 표현한다.
- 일반화(Generalization) 관계: 상위 클래스와 하위 클래스 사이의 관계를 표현한다.
💡 3. 익스트림 프로그래밍(XP)에 대한 설명으로 틀린 것은?
빠른 개발을 위해 테스트를 수행하지 않는다.- 사용자의 요구사항은 언제든지 변할 수 있다.
- 고객과 직접 대면하며 요구사항을 이야기하기 위해 사용자 스토리(User Story)를 활용할 수 있다.
- 기존의 방법론에 비해 실용성(Pragmatism)을 강조한 것이라고 볼 수 있다.
익스트림 프로그래밍(XP)
- 고객 요구사항에 집중하여 빠르게 개발하고 테스트하여 고품질의 소프트웨어를 제공한다.
- 짧은 개발 주기를 갖고, 지속적인 테스트와 통합 개발을 수행하며, 고객과의 강한 소통과 협력을 강조한다.
💡 4. 소프트웨어 설계에서 사용되는 대표적인 추상화(Abstraction) 기법이 아닌 것은?
- 자료 추상화: 데이터의 핵심적인 부분만 추려내어 모델링한다.
- 제어 추상화: 프로그램의 흐름을 추상화하여, 프로그램의 제어 구조를 단순화한다.
- 과정 추상화: 작업을 추상화하여, 프로세스를 모델링한다.
강도 추상화
💡 5. 객체지향 설계에서 정보 은닉(Information Hiding)과 관련한 설명으로 틀린 것은?
- 필요하지 않은 정보는 접근할 수 없도록 하여 한 모듈 또는 하부시스템이 다른 모듈의 구현에 영향을 받지 않게 설계되는 것을 의미한다.
- 모듈들 사이의 독립성을 유지시키는 데 도움이 된다.
- 설계에서 은닉되어야 할 기본 정보로는 IP주소와 같은 물리적 코드, 상세 데이터 구조 등이 있다.
모듈 내부의 자료 구조와 접근 동작들에만 수정을 국한하기 때문에 요구사항 등 변화에 따른 수정이 불가능하다.
정보 은닉(Information Hiding)
- 적용한 모듈은 내부 구현을 외부에서 숨기기 때문에, 다른 모듈과의 결합도가 낮아져 독립성을 갖게 된다.
- 요구사항이나 설계 변경 등의 변화에 대응하여 해당 모듈만 수정할 수 있다.
💡 6. 소프트웨어 공학에서 모델링(Modeling)과 관련한 설명으로 틀린 것은?
- 개발팀이 응용문제를 이해하는 데 도움을 줄 수 있다.
유지보수 단계에서만 모델링 기법을 활용한다.- 개발될 시스템에 대하여 여러 분야의 엔지니어들이 공통된 개념을 공유하는 데 도움을 준다.
- 절차적인 프로그램을 위한 자료흐름도는 프로세스 위주의 모델링 방법이다.
💡 7. 요구 분석(Requirement Analysis)에 대한 설명으로 틀린 것은?
- 요구 분석: 소프트웨어 개발의 실제적인 첫 단계로 사용자의 요구에 대해 이해하는 단계라 할 수 있다.
- 요구 추출(Requirement Elicitation): 프로젝트 계획 단계에 정의한 문제의 범위 안에 있는 사용자의 요구를 찾는 단계이다.
- 도메인 분석(Domain Analysis): 요구에 대한 정보를 수집하고 배경을 분석하여 이를 토대로 모델링을 하게 된다.
기능적(Functional) 요구에서 시스템 구축에 대한 성능, 보안, 품질, 안정 등에 대한 요구사항을 도출한다.
- 기능적 요구사항(Functional Requirements): 시스템이 수행해야 하는 기능에 대한 요구사항으로, 시스템이 수행할 수 있는 일의 범위와 기능적인 측면을 나타낸다.
- 비기능적 요구사항(Non-functional Requirements): 시스템이 제공해야 하는 기능 외적인 측면에 대한 요구사항으로, 보안, 안정성, 사용성, 성능 등의 측면을 포함한다.
💡 8. 클래스 다이어그램의 요소로 다음 설명에 해당하는 용어는?
클래스의 동작을 의미한다.
클래스에 속하는 객체에 대하여 적용될 메서드를 정의한 것이다.
UML에서는 동작에 대한 인터페이스를 지칭한다고 볼 수 있다.
- 인스턴스(Instance): 클래스(Class)를 구체화한 객체(Object)이다.
- 연산(Operation): 객체가 수행하는 작업이다.
- 아이템(Item): 프로그램의 구성 요소 중 하나인 데이터(Data)나 코드이다.
- 은닉(Hiding): 객체 내부의 상세한 구현 내용을 외부에서 접근하지 못하도록 숨긴다.
💡 9. 분산 시스템을 위한 마스터-슬레이브(Master-Slave) 아키텍처에 대한 설명으로 틀린 것은?
- 일반적으로 실시간 시스템에서 사용된다.
- 마스터 프로세스는 일반적으로 연산, 통신, 조정을 책임진다.
슬레이브 프로세스는 데이터 수집 기능을 수행할 수 없다.- 마스터 프로세스는 슬레이브 프로세스들을 제어할 수 있다.
- 마스터(네임 노드, Master): 분산 시스템에서 중앙 집중식으로 제어하는 노드이다.
- 슬레이브(데이터 노드, Slave): 분산 시스템에서 마스터 노드의 지시를 받아 동작하는 노드이다.
💡 10. 요구 사항 정의 및 분석·설계의 결과물을 표현하기 위한 모델링 과정에서 사용되는 다이어그램(Diagram)이 아닌 것은?
- 데이터 흐름도(Data Flow Diagram): 시스템 내부의 데이터 흐름을 다이어그램으로 데이터의 원천, 목적지, 흐름 경로 등을 표시한다.
- 통합 모델링 언어 다이어그램(UML Diagram): 표준화된 모델링 언어로 시스템의 구조, 동작, 상호작용 등을 다이어그램으로 표현한다.
- 개체-관계 다이어그램(E-R Diagram): 개체와 개체 간의 관계를 그래픽으로 표현한다.
- AVL 트리 다이어그램(AVL Diagram): AVL 트리의 구조와 작동 방식을 다이어그램으로 표현한다.
💡 11. 객체지향의 주요 개념에 대한 설명으로 틀린 것은?
캡슐화: 상위클래스에서 속성이나 연산을 전달받아 새로운 형태의 클래스로 확장하여 사용하는 것을 의미한다.- 객체: 실세계에 존재하거나 생각할 수 있는 것을 말한다.
- 클래스: 하나 이상의 유사한 객체들을 묶어 공통된 특성을 표현한 것이다.
- 다형성: 상속받은 여러 개의 하위 객체들이 다른 형태의 특성을 갖는 객체로 이용될 수 있는 성질이다.
💡 12. 사용자 인터페이스(User Interface)에 대한 설명으로 틀린 것은?
- 사용자와 시스템이 정보를 주고받는 상호작용이 잘 이루어지도록 하는 장치나 소프트웨어를 의미한다.
편리한 유지보수를 위해 개발자 중심으로 설계되어야 한다.- 배우기가 용이하고 쉽게 사용할 수 있도록 만들어져야 한다.
- 사용자 요구사항이 UI에 반영될 수 있도록 구성해야 한다.
💡 13. GoF, Gang of Four 디자인 패턴과 관련한 설명으로 틀린 것은?
- 디자인 패턴을 목적(Purpose)으로 분류할 때 생성, 구조, 행위로 분류할 수 있다.
전략(Strategy) 패턴은 대표적인 구조 패턴으로 인스턴스를 복제하여 사용하는 구조를 말한다.- 행위 패턴은 클래스나 객체들이 상호작용하는 방법과 책임을 분산하는 방법을 정의한다.
- 싱글턴(Singleton) 패턴은 특정 클래스의 인스턴스가 오직 하나임을 보장하고, 이 인스턴스에 대한 접근 방법을 제공한다.
- 생성 패턴: 기존 코드의 유연성과 재사용을 증가시키는 객체를 생성한다.
- 팩토리 메서드(Factory Method): 부모 클래스에서 객체를 생성할 수 있는 인터페이스를 제공하지만, 자식 클래스들이 생성될 객체의 유형을 변경한다.
- 추상 팩토리(Abstract Factory): 관련 객체들의 구상 클래스들을 지정하지 않고도 그들의 패밀리들을 생성한다.
- 빌더(Builder): 복잡한 객체들을 단계별로 생성한다.
- 프로토타입(Prototype): 코드를 클래스들에 의존시키지 않고 기존 객체들을 복사한다.
- 싱글턴(Singleton): 클래스에 인스턴스가 하나만 있도록 하면서 인스턴스에 대한 전역 접근 지점을 제공한다.
- 구조 패턴: 객체들과 클래스들을 구조를 유연하고 효율적으로 유지하면서 더 큰 구조로 조립한다.
- 어댑터(Adapter): 호환되지 않는 인터페이스를 가진 객체들을 협업한다.
- 브리지(Bridge): 큰 클래스 또는 밀접하게 관련된 클래스들의 집합을 두 개의 개별 계층구조로 나눈 후 각각 독립적으로 개발한다.
- 복합체(Composite): 객체들을 트리 구조들로 구성한 후, 개별 객체들인 것처럼 작업한다.
- 데코레이터(Decorator): 객체들에 새로운 행동들을 포함한 특수 래퍼 객체들 내에 넣어서 해당 객체들에 연결한다.
- 퍼사드(Facade): 라이브러리 및 프레임워크에 대한 단순화된 인터페이스를 제공한다.
- 플라이웨이트(Flyweight): 각 객체에 모든 데이터를 유지하는 대신 여러 객체 간에 상태의 공통부분을 공유한다.
- 프록시(Proxy): 다른 객체에 대한 대체 또는 자리표시자를 제공한다.
- 행위 패턴: 객체 간의 효과적인 의사소통과 책임 할당을 처리한다.
- 책임 연쇄(Chain of Responsibility): 일련의 핸들러들의 사슬을 따라 요청을 전달한다.
- 커맨드(Command): 요청을 요청에 대한 모든 정보가 포함된 독립 실행형 객체로 변환한다.
- 반복자(Iterator): 컬렉션의 요소들의 기본 표현(리스트, 스택, 트리 등)을 노출하지 않고 하나씩 순회한다.
- 중재자(Mediator): 객체 간의 직접 통신을 제한하고 중재자 객체를 통해서만 협력한다.
- 메멘토(Memento): 객체의 구현 세부 사항을 공개하지 않으면서 해당 객체의 이전 상태를 저장하고 복원한다.
- 옵서버(Observer): 여러 객체에 자신이 관찰 중인 객체에 발생하는 모든 이벤트에 대하여 알리는 구독 메커니즘을 정의한다.
- 상태(State): 객체의 내부 상태가 변경될 때 해당 객체가 그의 행동을 변경한다.
- 전략(Strategy): 알고리즘들의 패밀리를 정의하고, 각 패밀리를 별도의 클래스들에 넣은 후 객체들을 상호교환한다.
- 템플릿 메서드(Template Method): 부모 클래스에서 알고리즘의 골격을 정의하지만, 해당 알고리즘의 구조를 변경하지 않고 자식 클래스들이 알고리즘의 특정 단계들을 오버라이드한다.
- 비지터(Visitor): 알고리즘들을 작동하는 객체들로부터 분리한다.
💡 14. 애자일 개발 방법론과 관련한 설명으로 틀린 것은?
- 빠른 릴리즈를 통해 문제점을 빠르게 파악할 수 있다.
정확한 결과 도출을 위해 계획 수립과 문서화에 중점을 둔다.- 고객과의 의사소통을 중요하게 생각한다.
- 진화하는 요구사항을 수용하는데 적합하다.
애자일(Agile) 프로세스 모델
- 소프트웨어 개발 방법론 중 하나로 빠르고 유연하게 요구사항을 반영하면서 개발을 진행하는 방법이다.
- 고객과의 소통을 중요시하며, 작은 주기로 반복적인 개발을 진행하여 빠르게 피드백을 받고 문제를 수정한다.
- 변화에 대응할 수 있는 유연성을 제공하고, 고객의 요구사항을 빠르게 수용하여 고객 만족도를 향상한다.
💡 15. 럼바우(Rumbaugh)의 객체지향 분석 기법 중 자료 흐름도(DFD)를 주로 이용하는 것은?
- 기능 모델링: 시스템이 제공하는 기능을 모델링하고 시스템의 기능 요구사항을 분석한다.
- 동적 모델링: 시간의 흐름에 따른 객체들의 동작과 상호작용을 모델링하고 시스템의 동작 요구사항을 분석한다.
- 객체 모델링: 객체지향 개념을 기반으로 시스템을 모델링하고 설계한다.
- 정적 모델링: 시스템의 데이터나 객체의 상태, 속성, 관계 등을 다이어그램으로 표현한다.
💡 16. 순차 다이어그램(Sequence Diagram)과 관련한 설명으로 틀린 것은?
- 객체들의 상호 작용을 나타내기 위해 사용한다.
- 시간의 흐름에 따라 객체들이 주고받는 메시지의 전달 과정을 강조한다.
동적 다이어그램보다는 정적 다이어그램에 가깝다.- 교류 다이어그램(Interaction Diagram)의 한 종류로 볼 수 있다.
순차 다이어그램(Sequence Diagram)
- 객체 간 상호작용을 메시지(Message)로 표현한다.
- 시간의 흐름을 나타내는 시간축(Time Axis)을 가진다.
- 객체 간의 상호작용을 표현한다.
💡 17. 객체지향 분석 기법(OOA, Object-Oriented Analysis Techniques)과 관련한 설명으로 틀린 것은?
- 동적 모델링 기법이 사용될 수 있다.
기능 중심으로 시스템을 파악하며 순차적인 처리가 중요시되는 하향식(Top-down) 방식으로 볼 수 있다.- 데이터와 행위를 하나로 묶어 객체를 정의 내리고 추상화시키는 작업이라 할 수 있다.
- 코드 재사용에 의한 프로그램 생산성 향상 및 요구에 따른 시스템의 쉬운 변경이 가능하다.
객체지향 분석 기법(OOA, Object-Oriented Analysis Techniques)
- 객체지향 개념을 기반으로 시스템을 분석하는 기법이다.
- 시스템의 요구사항을 파악하는 상향식 방식이다.
- 시스템의 유연성, 재사용성, 확장성 등을 향상한다.
💡 18. 대표적으로 DOS 및 Unix 등의 운영체제에서 조작을 위해 사용하던 것으로, 정해진 명령 문자열을 입력하여 시스템을 조작하는 사용자 인터페이스(User Interface)는?
- GUI(Graphical User Interface): 그래픽과 아이콘 등을 사용해 사용자가 쉽게 인터랙션 할 수 있는 환경을 제공하는 인터페이스이다.
- CLI(Command Line Interface): 명령어를 입력하는 방식으로 사용자와 인터랙션 하는 인터페이스이다.
- CUI(Cell User Interface): 셀 기반의 인터페이스이다.
- MUI(Mobile User Interface): 모바일 기기에서 사용되는 인터페이스이다.
💡 19. 분산 시스템에서의 미들웨어(Middleware)와 관련한 설명으로 틀린 것은?
- 분산 시스템에서 다양한 부분을 관리하고 통신하며 데이터를 교환하게 해주는 소프트웨어로 볼 수 있다.
- 위치 투명성(Location Transparency)을 제공한다.
- 분산 시스템의 여러 컴포넌트가 요구하는 재사용가능한 서비스의 구현을 제공한다.
애플리케이션과 사용자 사이에서만 분산서비스를 제공한다.
미들웨어(Middleware)
- 클라이언트와 서버 사이에서 동작하여, 데이터 통신을 중개하거나 처리하는 소프트웨어이다.
- 서로 다른 시스템 간의 통신을 용이하게 하고, 데이터의 흐름과 처리를 관리하며, 보안과 안정성을 제공한다.
- 웹 서버와 웹 애플리케이션 서버, 메시지 큐, 데이터베이스 연결을 위한 DBMS 클라이언트 라이브러리 등이 있다.
💡 20. 소프트웨어 아키텍처와 관련한 설명으로 틀린 것은?
파이프 필터 아키텍처에서 데이터는 파이프를 통해 양방향으로 흐르며, 필터 이동 시 오버헤드가 발생하지 않는다.- 외부에서 인식할 수 있는 특성이 담긴 소프트웨어의 골격이 되는 기본 구조로 볼 수 있다.
- 데이터 중심 아키텍처는 공유 데이터저장소를 통해 접근자 간의 통신이 이루어지므로 각 접근자의 수정과 확장이 용이하다.
- 이해 관계자들의 품질 요구사항을 반영하여 품질 속성을 결정한다.
소프트웨어 아키텍처
- 소프트웨어 시스템의 구성요소와 이들 간의 상호작용을 설계하는 과정이다.
- 파이프 필터 아키텍처: 입력 데이터를 여러 개의 필터를 통해 변환하고, 최종 출력 데이터를 내보내는 아키텍처이다.
- 파이프를 통한 데이터 흐름이 단방향으로만 이루어져야 하기 때문에 필터 사이의 상호작용이 제한적이고, 필터 이동 시 파이프를 끊고 다시 연결하는 과정에서 오버헤드가 발생할 수 있다.
- 파이프 필터 아키텍처는 비교적 단순한 데이터 처리 시스템에서 적합하다.
반응형
'기타 > 정보처리기사' 카테고리의 다른 글
정보처리기사 정처기 | 실기 4 통합 구현 | 연계 메커니즘 구성, 내외부 연계 모듈 구현 | 단원별 정리 (0) | 2023.03.08 |
---|---|
정보처리기사 정처기 | 실기 3 데이터 입출력 구현 | 논리 데이터 저장소 확인, 물리 데이터 저장소 설계, 데이터베이스 기초 활용하기 | 단원별 정리 (0) | 2023.03.08 |
정보처리기사 정처기 | 실기 2 화면 설계 | UI 요구사항 확인, UI 설계 | 단원별 정리 (0) | 2023.03.08 |
정보처리기사 정처기 | 실기 1 요구사항 확인 | 소프트웨어 개발 방법론, 현행 시스템 분석, 요구사항 확인 | 단원별 정리 (0) | 2023.03.08 |
정보처리기사 정처기 | 필기 5과목 정보시스템 구축 관리 | 기출문제 정리본, 두문자 (0) | 2023.02.27 |
정보처리기사 정처기 | 필기 4과목 프로그래밍 언어 활용 | 기출문제 정리본, 두문자 (0) | 2023.02.27 |
정보처리기사 정처기 | 필기 3과목 데이터베이스 구축 | 기출문제 정리본, 두문자 (0) | 2023.02.27 |
정보처리기사 정처기 | 필기 2과목 소프트웨어 개발 | 기출문제 정리본, 두문자 (0) | 2023.02.27 |