1과목 소프트웨어 설계
1. 오류를 조기에 검출하는데 목적을 두는 요구사항 검토방법
->워크스루
빌드 검증: 빌드가 성공했는지 확인하는 기본 테스트.
동료 검토: 팀원이 작업을 검토하는 피드백 과정.
개발자 검토: 개발자가 자신의 작업을 다른 개발자에게 검토받는 과정.
2. 코드 설계에서 일정한 일련번호를 부여하는 방식
->순차 코드
연상 코드: 이미지나 의미를 통해 정보를 표현. 예: 번호 대신 특정한 문구 사용.
블록 코드: 고유한 의미를 가진 짧은 숫자/문자 조합으로 구성됨.
표의 숫자 코드: 체계적으로 정리된 숫자 형태로 정보를 표현. 주로 매핑된 데이터에 사용됨.
3. 객체 지향 프로그램에서 데이터를 추상화하는 단위
-> 클래스
객체지향 프로그래밍 (OOP) 간단 설명
객체지향 프로그래밍(OOP)은 프로그램을 객체(Object)라는 단위로 나누어 개발하는 방법론이다. 객체는 데이터와 그 데이터를 처리하는 메소드를 함께 포함하는 캡슐화된 구조다. 이 방식은 코드의 재사용성과 유지보수성을 높인다.
메소드: 특정 작업을 수행하는 기능으로, 클래스 내부에서 정의됨.
상속성: 기존 클래스를 기반으로 새로운 클래스를 생성하는 개념.
메시지: 객체 간의 상호작용을 나타내는 방법.
4.DFD구성요소가 아닌것
->data dictionary
데이터 흐름도는 process, data flow, 그리고 data store로 구성된다. 데이터 딕셔너리는 별도의 관리 도구로, 데이터에 대한 메타 정보를 담고 있다.
5. SW설계시 성능특성 분석에 사용되는 항목이 아닌것
->서버 튜닝
응답시간, 가용성, 사용률은 성능 분석에 필수적인 요소이며, 서버 튜닝은 성능 최적화를 위한 방법이지 측정 항목이 아니다.
6.UML확장모델에서 스테레오 타입객체를 표현할떄 사용되는 기호
-> << >>
UML(통합 모델링 언어)은 소프트웨어 시스템의 구조와 동작을 시각적으로 표현하기 위해 표준화된 언어
다양한 다이어그램을 사용하여 시스템의 아키텍처, 동작, 프로세스 등을 설명하며, 특히 소프트웨어 개발과정에서 요구사항 분석, 설계 및 문서화에 널리 사용
(( )): 일반적으로 다른 특정 기능에 사용되는 표현.
{{ }}: 수학적 집합 또는 기타 특수한 표현에 사용될 수 있음.
[[ ]]: 표현의 범위를 묘사하는데 자주 사용됨.
UML의 다이어그램 종류
UML은 여러 종류의 다이어그램을 제공한다.
클래스 다이어그램 (Class Diagram): 클래스와 그들 간의 관계를 표시.
시퀀스 다이어그램 (Sequence Diagram): 객체 간의 상호작용을 시간 순서에 따라 나타냄.
상태 다이어그램 (State Diagram): 객체의 상태 변화 및 이벤트에 따른 반응을 문서화.
유즈케이스 다이어그램 (Use Case Diagram): 시스템의 기능과 외부 사용자(액터) 간의 관계를 나타냄.
7. GOF의 디자인 패턴에서 행위패턴에 속하는 것
->Visitor
Builder: 객체 생성을 단순화하기 위한 패턴, 주로 생성 패턴에 속함.
Visitor: 다양한 객체 구조에 대해 동작을 추가하기 위한 행위 패턴.
Prototype: 기존 객체를 복제하여 새로운 객체를 만드는 방법을 정의하는 패턴으로 생성 패턴.
Bridge: 추상화와 구현 부분을 분리하여 독립적으로 변화할 수 있도록 하는 구조 패턴.
GoF 디자인 패턴은 크게 세 가지 카테고리로 나눌 수 있다.
생성 패턴 (Creational Patterns):
객체 생성을 중심으로 다양한 상황에 맞게 객체를 생성하는 메커니즘을 제공.
예시: Singleton, Factory Method, Abstract Factory, Builder, Prototype.
구조 패턴 (Structural Patterns):
클래스와 객체를 조합하여 더 큰 구조를 형성하는 방법을 정의.
예시: Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy.
행위 패턴 (Behavioral Patterns):
객체 간의 상호작용과 책임 분담에 대한 패턴을 정의.
예시: Observer, Strategy, Command, State, Visitor, Mediator, Iterator, Chain of Responsibility.
8. 자료사전에서 자료의 생략을 의미하는 기호
->**
{ }: 일반적으로 블록 구조나 집합을 나타내는 기호로 사용.
**: 보통 생략 기호로 쓰이는 경우가 많으며, 자료의 생략을 나타내는데 적합한 기호.
=: 주로 할당 또는 동등성을 나타내는 기호.
( ): 종종 그룹화나 우선 순위를 나타내는 괄호.
9. 트래잭션이 올바르게 처리되고있는지 데이터를 감시하고 제어하는 미들웨어
->TP monitor
트랜잭션은 데이터베이스 관리 시스템에서 일련의 작업이 완전히 수행되거나 전혀 수행되지 않도록 보장하는 단위. 즉, 트랜잭션 내의 모든 명령어는 완벽하게 실행되거나, 오류 발생 시 원래 상태로 되돌려져야 하는 특성을 가진다. 이 특성을 ACID라 부르며, ACID는 Atomicity(원자성), Consistency(일관성), Isolation(격리성), Durability(지속성)의 약자이다.
RPC: 원격 프로시저 호출로, 원격 서버에서 프로시저를 호출하지만 트랜잭션 관리를 위한 미들웨어는 아님.
ORB: 객체 요청 브로커로, 객체 지향 시스템에서의 통신을 돕는 기술로, 트랜잭션 감시와는 관련이 없음.
HUB: 네트워크 장치로 데이터 흐름을 중앙에서 관리하지만 트랜잭션 감시와 관련 없음.
10. UI 설계원칙에서 누구나 쉽게 이해할 수 있음을 나타내는 것
->직관성
유효성: 잘못된 선택 (기능 구현과 관련)
무결성: 잘못된 선택 (데이터 관리 관련)
유연성: 잘못된 선택 (시스템 적응력)
11. XP의 5가지 가치가 아닌것
->정형 분석
XP는 애자일 소프트웨어 개발 방법론의 하나로, 고객의 요구를 빠르게 반영하고 품질 있는 소프트웨어를 짧은 주기로 개발하는 데 중점을 둔다.
협업, 지속적 피드백, 반복적인 개발 과정을 강조하며 변화에 민첩하게 대응할 수 있는 프레임워크이다.
용기: 변화를 두려워하지 않고, 새로운 아이디어를 시도하는 자세.
의사소통: 팀원 간의 원활한 소통을 통해 정보 공유와 협력 향상.
피드백: 고객과의 지속적인 피드백을 통해 개발 방향성을 조정.
단순성: 필요한 기능만을 먼저 구현하고, 복잡성을 최소화하여 유지보수를 용이하게 함.
12. UML모델에서 사용하는 Structural Diagram에 속하지 않는것
->Activity Diagram
Activity Diagram은 행위 다이어그램(Behavioral Diagram)에 속한다.
행위 다이어그램은 시스템이 어떻게 동작하는지를 모델링하는 데 중점을 둔다.
이 카테고리에는 다음과 같은 다이어그램도 포함된다.
상태 다이어그램(State Diagram)
시퀀스 다이어그램(Sequence Diagram)
커뮤니케이션 다이어그램(Communication Diagram)
13. SW개발 방법 중 요구사항 분석과 거리가 먼 것
-> 설계 명세서 작성
비용과 일정에 대한 제약설정 :요구사항 분석 시 고려해야 할 사항이다. 사업비 및 수행 일정을 설정하는 단계.
타당성 조사 : 요구사항 분석의 중요한 부분으로, 프로젝트의 실현 가능성을 평가하는 과정이다.요구사항 정의 문서화 : 요구사항을 명확히 정리하고 기록하는 과정으로 요구사항 분석에 직접적으로 해당된다.
14. 럼바우의 객체지향 분석 절차
-> 객체 모형 → 기능 모형 → 동적 모형
객체 모형 (Object Model) : 시스템의 데이터 구조를 정의한다. 객체들 간의 관계 및 속성을 모델링하며, 클래스 다이어그램을 통해 객체를 시각화.
기능 모형 (Functional Model) : 시스템의 기능을 기술하며, 기능들이 어떻게 상호작용하는지를 보여줍니다. 이는 주로 동작 및 처리 흐름에 초점을 맞춘다.
동적 모형 (Dynamic Model) : 시스템의 상태 변화와 객체 간의 메시지를 다룬다. 상태 다이어그램을 통해 객체의 생명주기와 동작을 설명.
15. 공통 모듈에 대한 명세기법 중 해당 기능에 대해 일관되게 이해하고 한가지로 해설 될 수 있도록 작성하는 원칙
->명확성
상호작용성: 모듈이 서로 어떻게 상호작용하는지를 규명하는 원칙.
명확성: 기능과 목적이 잘 이해될 수 있도록 명확하게 작성하는 원칙.
독립성: 모듈이 독립적으로 동작할 수 있도록 하는 원칙.
내용성: 모듈의 내용이 충실하게 반영되어야 한다는 원칙.
16. 객체지향 기법에서 클래스들 사이의 부분-전체 입합 관계 또는 부분의 관계로 설명되는 연관성을 나타내는 용어
->집단화
일반화: 특정 클래스가 더 일반적인 클래스와의 관계를 형성할 때, 즉 '부분-전체' 관계를 나타내는 용어이다. 예를 들어, 자동차는 차량의 부분일 수 있다.
추상화: 복잡한 현실 세계의 개념을 단순화하여 표현하는 과정이다. 일반화와는 다름.
캡슐화: 데이터와 기능을 함께 묶고 외부로부터 숨기는 과정이다. 다른 클래스와의 관계가 아닌, 내부 보호에 관한 것이다.
집단화: 관련성 있는 클래스들을 모아서 하나의 그룹으로 만드는 과정으로, '부분-전체' 관계와 직접적이지 않다.
17. CASE가 갖고 있는 주요 기능이 아닌것
-> 언어번역
그래픽 지원: CASE 도구는 그래픽적으로 모델링과 다이어그램 작성이 가능. 이는 사용자가 구조와 프로세스를 시각적으로 이해하는 데 도움을 줌.
소프트웨어 생명주기 전 단계의 연결: CASE 도구는 소프트웨어 개발의 전 과정(요구사항 분석, 설계, 구현, 테스트, 유지보수 등)을 지원.
언어번역: CASE 도구의 주요 기능이 아니며, 언어번역 기능은 특정 개발 도구의 기능에 해당되고, CASE 도구의 범주에는 포함되지 않는다.
다양한 소프트웨어 개발 모형 지원: 다양한 소프트웨어 개발 방법론(예: 폭포수 모델, 애자일 등)을 지원.
CASE(Computer-Aided Software Engineering) 도구는 소프트웨어 개발이 효율적이고 효과적으로 이루어지도록 도와주는 도구
18. DBMS분석시고려 사항이 아닌
->네트워크 구성도
가용성: 데이터베이스의 가용성은 시스템이 언제든지 사용할 수 있도록 보장하는 것이고, 이는 DBMS의 중요한 고려 사항이다.
성능: DBMS의 성능은 데이터 조회와 처리 속도와 관련이 있으며, 사용자 경험에 큰 영향을 미친다.
상호 호환성: 서로 다른 시스템 간의 통신이 가능하도록 하는 부분도 DBMS에서 신경 써야 할 요소이다.
19.HIPO에 대한 설명으로 거리가 먼것
->상향식 소프트웨어 개발을 위한 문서화 도구이다.
HIPO는 하향식 접근 방식을 기반으로 한 문서화 도구.
20. 객체지향 분석 방법론 중 E-R다이어그램을 사용하여 객체 행위를 모델링 하며, 객체싯ㄱ별, 구조식별, 주체정의, 속성 및 관계 정의, 서비스 정의 등의 과정으로 구성되는 것
->Coad와 Yourdon 방법
Coad와 Yourdon 방법: 이 방법은 객체지향 분석의 기법 중 하나로, 객체를 식별하고 주된 정의를 제공
Booch 방법: 이 방법도 객체지향 모델링을 위한 기법으로, E-R 다이어그램 대신 다른 다이어그램을 사용하는 경향이 있다.
Jacobson 방법: 유스케이스 다이어그램과 객체 다이어그램을 포함하여, 객체의 행위를 모델링하는 데 중점을 두는 방법이다.
Wirfs-Brocks 방법: 이 방법은 협력(협업) 중심의 접근을 사용.
'정보처리기사' 카테고리의 다른 글
| 2020년도 6월 정보처리기사 기출 분석 3과목 : 데이터베이스 구축 (0) | 2025.01.23 |
|---|---|
| 2020년도 9월 정보처리기사 기출 분석 2과목 : 소프트웨어설계 (1) | 2025.01.22 |
| 2020년도 6월 정보처리기사 기출 분석 2과목 : 소프트웨어설계 (2) | 2025.01.22 |
| 2020년도 9월 정보처리기사 기출 분석 1과목 : 소프트웨어설계 (0) | 2025.01.21 |
| 2020년도 8월 정보처리기사 기출 분석 1과목 : 소프트웨어설계 (0) | 2025.01.21 |