1과목 : 소프트웨어 설계

dev-note-404 2025. 5. 8. 11:24

728x90

21년 8월 14일 시험

1. 요구사항 검증(Requirements Validation)

Requirements Validation(요구사항 검증)
- 실제로 고객이 원하는 바를 정의했는지를 보이는 것
- 검증이 중요한이유는 시스템을 개발하거나, 시스템이 운영 중일 경우에 발견되면 방대한 재 작업 비용이 발생된다.
- 시스템을 변경하여 요구사항 문제를 수정하는 비용은 설계및 코딩오류에 비하여 비용이 많이 소요된다.
(시스템 설계 및 구현 변경 및 다시 테스트해야하기 때문)

2. 의존 관계(Dependency Relationship) - UML 모델에서 한 사물의 명세가 바뀌면 다른사물에 영향을 주며, 일반적으로 한 클래스가 다른 클래스를 오퍼레이션의 매개변수로 사용하는 경우에 나타나는 관계

3. 익스트림 프로그래밍 (XP)

=> 프로그래밍에서 테스트가 없다는 것은 낙하산 없이 스카이 다이빙 하는 것과 같다.

4. 소프트웨어 설계에서 사용되는 대표적인 추상화(Abstraction) 기법이 아닌 것?

=> 소프트웨어 설계에 사용되는 대표적인 3가지 추상화 기법
-제어 추상화: 제어의 정확한 메커니즘을 정의하지 않고 원하는 효과를 정하는데 이용하는 방법
-기능 추상화: 입력 자료를 출력자료로 변환하는 과정을 추상화하는 방법
-자료 추상화: 자료와 자료에 적용될 수 있는 기능을 함께 정의함으로써 자료 객체를 구성하는 방법

5. 정보 은닉(Information Hiding)

정보은닉(information hiding)
다른 객체에게 자신의 정보를 숨기고 자신의 연산만을 통해 접근을 허용하는 것
클래스 외부에서 특정 정보에 접근을 막는다는 의미
(사용자가 굳이 알 필요가 없는 정보는 사용자로부터 숨겨야 한다는 개념 ex.ip, port)

6. 모델링 (Modeling)

모델링은 초반에 하는 것 이고 유지보수는 마지막 단계에 하는 것

7. 요구 분석(Requirement Analysis)

기능적 요구사항
- 시스템이 수행해야 하는 행위들을 구체화 한 것
- 시스템에서 제공해야 할 기능을 정의한 것
- 입력기능, 출력기능, 데이터베이스 기능, 통신 기능 등

8. Operation : 클래스의 동작을 의미 / 클래스에 속하는 객체에 대하여 적용될 메서드를 정의 / UML에서는 동작에 대한 인터페이스를 지칭한다고 볼 수 있

9. 마스터-슬레이브(Master-Slave) 아키텍처

마스터 - 슬레이브 패턴 (Master-slave pattern)
마스터: 작업을 분리, 배포
슬레이브: 요청 작업 처리

10. 다이어그램(Diagram)

11. 객체지향

12. 사용자 인터페이스(User Interface) - 사용자 인터페이스는 개발자 중심이 아닌 사용자가 바라보는 관점으로 쉽게 알아볼 수 있도록 설계되어야 한다.

13. GoF(Gang of Four) 디자인 패턴

Strategy 패턴 : 행위패턴, 클라이언트에 영향을 받지 않는 독립적인 알고리즘을 선택하는 패턴

14. 애자일 개발 방법론

- 반복적인 개발을 통한 잦은 출시를 목표로 함
- 기존모형(폭포수, 프로토타입, 나선형)의 문제점을 보완한 모형
- 소프트웨어를 점증적으로 개발
- 출시 주기를 짧게 하여 다양한 요구 변화에 대응
- 가볍고 실용적인 소프트웨어 개발 방법론

15. 럼바우 분석기법
객,동,기
객체모델링 = 객체 다이어그램
동적모델링 = 상태 다이어그램
기능 모델링 = 자료흐름도

16. 시퀀스 다이어그램 - 동적 다이어그

17. 객체지향 분석 기법

객체지향 분석 기법
1. 동적 모델링
2. 상향식

18. CLI(Command Line Interface)

19. 미들웨어 (Middleware)

=> 애플리케이션 - 사용자 사이 외에도 프로그램과 환경간에서 서비스를 제공

20. 소프트웨어 아키텍처

=> 파이프 필터 아키텍처에서 데이터는 파이프를 통해 단방향으로 흐르고, 필터 이동시 오버헤드가 발생될 수 있음

22년 3월 5일 시험

1. User Interface 설계 시 오류 메시지나 경고에 관한 지침으로 가장 거리가 먼 것?

=> 직관성, 유효성, 학습성, 유연성

1) 직관성(Intuitiveness) : 누구나 쉽게 이해하고, 쉽게 사용할 수 있어야 함.
2) 유효성(Effectiveness) : 정확하고 완벽하게 사용자의 목표가 달성될 수 있도록 제작해야 함.
3) 학습성(Learnablilty) : 초보와 숙련자 모두가 쉽게 배우고 사용할 수 있게 제작해야 함.
4) 유연성(Flexibility) : 사용자의 인터랙션을 최대한 포용하고, 실수를 방지할 수 있도록 제작해야 함.

2. 애자일(Agile) 소프트웨어 개발

=> 애자일 방법론 특징
1) 프로젝트 요구사항은 '기능' 중심
2) 공정과 도구보다 '개인'과 소통을 중요시
3) '변화'에 유연하고 신속한 대처
4) '고객'과의 피드백을 중요시

3. 요구사항 분석

=> 요구 사항 개발 프로세스
도출 - 분석 - 명세 - 확인

4. 상속 ( Inheritance )
=> 객체지향 기법에서 상위 클래스의 메소드와 속성을 하위 클래스가 물려받는 것을 의미하는 것

5. 하향식 설계 방법과 상향식 설계 방법

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

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

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

6. 자료흐름도(DFD)

=> 자료흐름도 4가지 구성요소

- 처리 Process : 원

- 자료흐름 Data Flow : 화살표

- 자료저장소 Data Store : 평행선

- 단말 Terminal : 사각형

7. 모델 (Model)

=> 소프트웨어 개발시 모델은 향후 개발될 시스템을 유추하기 위해서 하는 활동이며, 주로 시스템 개발자가 실행합니다.

8. UML

=> 객체 지향 시스템을 개발할 때 산출물을 명세화, 시각화, 문서화하는데 사용된다. 즉, 개발하는 시스템을 이해하기 쉬운 형태로 표현하여 분석가, 의뢰인, 설계자가 효율적인 의사소통을 할 수 있게 해준다. 따라서, 개발 방법론이나 개발 프로세스가 아니라 표준화된 모델링 언어이다.

9. 목업 (Mockup)

=> 디자인, 사용방법설명, 평가 등을 위해 실제 화면과 유사하게 만든 정적인 형태의 모형

=> 시각적으로만 구서 요소를 배치하는 것으로 일반적으로 실제로 구현되지는 않음

10. 애자일 기법 중 스크럽과 관련된 용어

스프린트

- 실제 개발을 2~4주간 진행하는 과정

- 스프린트 백로그에 작성된 Task를 대상으로 작업 시간을 측정한 후 담당 개발자에게 할당

- Task는 할 일, 진행 중, 완료의 상태로 구성

11. UML 다이어그램의 분류

정적구조 : 클객컴배복패 ( 클래스, 객체, 컴포넌트, 배치, 복합구조, 패키지)

동적구조 : 유시통상활타상 ( 유스케이스, 시퀀스, 통신, 상호작용, 활동, 타이밍, 상호작용)

12. LOC 계산

13. 클래스 설계 원칙 (SOLID)

1. 단일 책임원칙(Single Responsibility Principle) : 하나의 클래스는 하나의 목적을 위해서 생성, 클래스가 제공하는 모든 서비스는 하나의 책임을 수행하는데 집중
2. 개방-폐쇄 원칙(Open Close principle) : 소프트웨어 구성요소(컴포넌트, 클래스, 모듈, 함수)는 확장에 열려 있고, 변경에는 닫혀 있다.
3. 리스코프 치환의 원칙(Liskov Substitution Principle) : 서브타입(상속받은 하위 클래스)은 어디서나 자신의 기반 타입(상위 클래스)으로 교체할 수 있어야 한다
4. 인터페이스 분리의 원칙(Interface Segregation Principle) : 한 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 말아야한다.
- 클라이언트가 사용하지 않는 인터페이스 때문에 영향을 받아서는 안된다.
5. 의존성 역전의 원칙 (Dependency Inversion Principle) : 실제 사용 관계가 바뀌지 않으면 추상을 매개로 메시지를 주고받음으로써 관게를 최대한 느슨하게 만드는 원칙

14. 디자인패턴 - 생성패턴

15. 아키텍쳐 설계과정

[설계 목표 설정 - 시스템 타입 결정 - 스타일 적용 및 커스터마이즈

- 서브시스템의 기능, 인터페이스 동작 작성 - 아키텍쳐 설계 검토]

16. 사용자 인터페이스를 설계할 경우 고려해야 할 가이드라인과 가장 거리가 먼 것

=> 사용자 친화적이게 설계되어야 하기에 사용성이 최우선으로 고려되어야 함

17. 디자인 패턴 - 소프트웨어 설계에서 자주 발생하는 문제에 대한 일반적이고 반복적인 해결 방법

18. 럼바우 - 객체지향 분석기법의 하나로 객체 모형, 동적 모형, 기능 모형의 3개 모형을 생성하는 방법

19. FEP(Front-End Processor) - 입력되는 데이터를 컴퓨터의 프로세서가 처리하기 전에 미리 처리하여 프로세서가 처리하는 시간을 줄여주는 프로그램이나 하드웨어

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

22년 4월 24일 시험

1. UML 다이어그램 중 순차 다이어그램

: 순차 다이어그램은 행위 다이어그램이므로 동적이고, 순차적인 표현을 위한 다이어그램이다. // 시간 개념을 중심으로 모델링 / 다이어그램의 수직 방향이 시간의 흐름을 나타냄 / 회귀 메세지, 제어블록으로 구성

2. 메시지 지향 미들웨어(Message-Oriented Middleware, MOM)

- 메시지 기반의 비동기형 메시지를 전달하는 방식의 미들웨어이다.
- 온라인 업무보다는 이기종 분산 데이터 시스템의 데이터 동기를 위해 많이 사용한다.

- 즉각적인 응답을 원하는 경우가 아니라 다소 느리고 안정적인 응답을 필요로 하는 경우에 많이 사용됩니다.

3. 익스트림 프로그래밍

- 구조적 방법론이 아니라 애자일 방법론 중 하나

- 구조적 방법론은 계획 중심의 접근 방식을 따르는 반면, 익스트림 프로그래밍은 반복적이고 점진적인 개발을 강조하여 변화에 유연하게 대응할 수 있도록 설계된 방법론으로 차이가 있다.

4. 유스케이스(Use Case)의 구성 요소 간의 관계에 포함되지 않는 것

유스케이스(Use Case)의 구성 요소 간의 관계
- 연관관계(Association) : 유스케이스와 액터간의 상호작용이 있음을 표현한다.
- 포함 관계(Include): 하나의 유스케이스가 다른 유스케이스의 실행을 전제로 할 때 형성되는 관계이다.
- 확장 관계(Extend): 확장 기능 유스케이스와 확장 대상 유스케이스 사이에 형성 되는 관계이다.
- 일반화 관계(Generalization) : 유사한 유스케이스 또는 액터를 모아 추상화한 유스케이스 또는 액터와 연결시켜 그룹을 만들어 이해도를 높이기 위한 관계이다.

5. 요구사항 분석에서 비기능적(Nonfunctional) 요구

기능적 요구사항 Vs 비기능적 요구사항
- 기능적 요구사항 : 시스템이 실제로 어떻게 동작하는지에 관점을 둔 요구사항
- 비기능적 요구사항 : 시스템 구축에 대한 성능, 보안, 품질, 안정 등에 대한 성능, 보안, 품질, 안정성등으로 실제 수행에 보조적인 요구사항

6. 정보공학 방법론에서 데이터베이스 설계의 표현으로 사용하는 모델링 언어

Entity-Relationship Diagram

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

- 클라이언트와 서버 간의 통신을 담당하는 시스템 소프트웨어이다.
- 이기종 하드웨어, 소프트웨어, 네트워크, 프로토콜, PC 환경, 운영체제 환경 등에서 시스템 간의 표준화된 연결을 도와주는 소프트웨어이다.
- 표준화된 인터페이스를 통하여 시스템 간의 데이터 교환에 있어 일관성을 제공한다.
- 운영체제와 애플리케이션 사이에서 중간 매개 역할을 하는 다목적 소프트웨어이다.

8. UI의 설계 지침으로 틀린 것

사용자가 UI를 통해서 프로그램을 사용할 때 발견할 수 있는 치명적 오류에 대한 부정적인 사항들을 인지할 수 있어야 프로그램의 개선이 가능하고 또 오류를 피할 수 있다

9. 다형성(Polymorphism)

다형성이란 여러 가지 형태를 가지고 있다는 의미로, 여러 형태를 받아들일 수 있는 특징

오버로딩 - 한 클래스 내에서 메서드의 이름은 동일하지만 매개변수의 수나 타입을 다르게 하여 재정의 하는 것
오버라이딩 - 상속관계에서만 발생. 슈퍼클래스의 메서드를 서브클래스에서도 동일한 메서드를 재정의 하는 것

10. 소프트웨어 개발 영역을 결정하는 요소

인터페이스: 서로 다른 두 시스템이나 소프트웨어 등을 서로 이어주는 부분 또는 접속 장치를 의미

11. 객체에 대한 설명으로 틀린 것

cf) 클래스: 공통 속성을 공유하는 객체들의 집합

12. 속성과 관련된 연산(Operation)을 클래스 안에 묶어서 하나로 취급하는 것을 의미하는 객체지향 개념

클래스: 하나 이상의 유사한 객체들을 묶는다.
캡슐화: 서로 관련성이 많은 데이터들과 연산들을 묶는다.

13. 애자일(Agile) 프로세스 모델에 대한 설명으로 틀린 것

[애자일 선언문]
" 프로세스, 도구 보다는 (사람과 상호작용)을
광범위한 문서 보다는 (실제 작동하는 제품)을
계약 협상보다는 (고객 협력)을
계획을 따르기 보다는 (변화 대응)을"

14. 명백한 역할을 가지고 독립적으로 존재할 수 있는 시스템의 부분으로 넓은 의미에서는 재사용되는 모든 단위라고 볼 수 있으며, 인터페이스를 통해서만 접근할 수 있는 것

- 컴포넌트

- 프로그래밍에 있어 재사용이 가능한 각각의 독립된 모듈
- 특정 기능 수행을 위해 독립적으로 분리

15. GoF(Gang of Four) 디자인 패턴을 생성, 구조, 행동 패턴의 세 그룹으로 분류할 때, 구조 패턴이 아닌 것

구성 - 브릿지 / 데코레이터 / 퍼사이드 / 플라이웨이트 / 프록시 / 컴포지트 / 어댑터

16. UI와 관련된 기본 개념 중 하나로, 시스템의 상태와 사용자의 지시에 대한 효과를 보여주어 사용자가 명령에 대한 진행 상황과 표시된 내용을 해석할 수 있도록 도와주는 것

피드백(feedback): 처리된 결과를 측정하고 목표에 도달되었는가를 검사하며 불충분할 경우 다시 입력하는 요소로 사용.

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

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

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

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

- 객체지향 방법론에서는 UML 표기법을 사용

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

19. 유스케이스 다이어그램(Use Case Diagram)에 관련된 내용으로 틀린 것?

- 유스케이스는 사용자 측면에서의 요구사항으로, 사용자가 원하는 목표를 달성하기 위해 수행할 내용을 기술한다.

- 시스템 액터는 다른 프로젝트에서 이미 개발되어 사용되고 있으며, 본 시스템과 데이터를 주고받는 등 서로 연동되는 시스템을 말한다.

- 액터가 인식할 수 없는 시스템 내부의 기능을 하나의 유스케이스로 파악해서는 안된다.

20. 소프트웨어 아키텍처 모델 중 MVC(Model-View-Controller)와 관련한 설명으로 틀린 것?

- MVC 모델은 사용자 인터페이스를 담당하는 계층의 응집도를 높일 수 있고, 여러 개의 다른 UI를 만들어 그 사이에 결합도를 낮출 수 있다.

- 모델(Model)은 뷰(View)와 제어(Controller) 사이에서 전달자 역할을 하며, 뷰마다 모델 서브시스템이 각각 하나씩 연결된다. => 한 개의 모델에 대해 여러 개의 뷰를 만들 수 있음

- 뷰(View)는 모델(Model)에 있는 데이터를 사용자 인터페이스에 보이는 역할을 담당한다.

- 제어(Controller)는 모델(Model)에 명령을 보냄으로써 모델의 상태를 변경할 수 있다.

728x90