2022-1-(1) 소프트웨어 설계 풀이(20문항)

1) User Interface 설계 시 오류 메세지나 경고에 관한 지침

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

 

2)  애자일(Agile) 방법론 특징(애자일 소프트웨어 개발에 대한 설명)

1. 프로젝트 요구사항은 '기능' 중심
2. 공정과 도구보다 '개인'과 소통을 중요시
3. '변화'에 유연하고 신속한 대처
4. '고객'과의 피드백을 중요시

 

3) 요구 사항 개발 프로세스

• 도출 - 분석 - 명세 - 확인

 

4) 객체지향의 주요 개념(원칙)

1. 캡슐화(Encapsulation)
   - 데이터와 데이터를 처리하는 함수를 하나로 묶은 것
   - 캡슐화된 객체의 세부 내용이 은폐되어 변경이 발생해도 오류의 파급효과가 적음
   - 캡슐화된 객체들은 재사용이 용이함
   - 인터페이스가 단순해지고 객체간의 결합도가 낮아짐
2. 상속성(Inheritance)
   - 객체지향 프로그래밍에서 이미 정의된 상위 클래스(부모 클래스)의 모든 속성과 연산을 하위 클래스가 상속(물려)받는 것
   - 하위 클래스는 상위 클래스로부터 받은 속성과 연산 외에도 새로운 것을 첨가 가능
   - 클래스의 재사용, 소프트웨어의 재사용을 높이는 중요한 개념
   + 속성과 연산 등을 물려주는 클래스는 상위 클래스 또는 슈퍼 클래스, 물려받는 클래스를 하위 클래스 또는 서브 클래스라고 한다.
3. 다형성(Polymorphism)
   - 하나의 메시지에 대해 각 객체가 갖고 있는 고유한 방법대로 응답하는 것을 의미
   - 하나의 클래스나 메서드가 다양한 방식으로 동작이 가능한 것을 의미
   - 오버로딩과 오버라이딩이 존재

5) 하향식 통합 테스트 / 상향식 통합 테스트

 

• 하향식 통합 테스트(Top Down Integration Test)
  a. 깊이 우선 통합법, 넓이 우선 통합법 사용
  b. 테스트 초기부터 사용자에게 시스템 구조를 보여줄 수 있다.
  c. 상위 모듈에서는 tc를 사용하기 어렵다.
  d. 상위 모듈에서 하위 모듈 방향으로 통합하면서 테스트하는 기법
  e. 절차
      -주요 제어 모듈은 작성된 프로그램을 사용하고, 주요 제어 모듈의 종속 모듈들은 스텁(stub)으로 대체 한다.
      -깊이 우선 or 넓이 우선 등의 통합방식에 따라, 하위 모듈인 스텁들이 한 번에 하나씩 실제모듈로 교체된다.
      -모듈이 통합될 때마다 테스트 실시
      -새로운 오류가 발생하지 않음을 보증 하기 위해 회귀 테스트 실시
• 상향식 통합 테스트(Boottom Up Integration Test)
  a. 하위 모듈에서 상위 모듈 방향으로 통합하면서 테스트 하는 방법
  b. 가장 하위 단계의 모듈부터 통합 및 테스트가 수행되므로 스텁은 필요하지 않다.
  c. 하나의 주요 제어 모듈과 관련된 종속 모듈의 그룹인 클러스티(cluster)은 필요하다.
  d. 절차
      -하위 모듈을 클러스터로 결합
      -상위 모듈에서 데이터의 입출력을 확인하기 위해, 모듈인 드라이버 작성
      -통합된 클러스터 단위로 테스터
      -테스트가 완료되면 클러스터는 프로그램 구조의 상위로 이동하여 결합하고, 드라이버는 실제 모듈로 대체

 

6) 자료흐름도(DFD)의 4가지 구성요소

1. 처리 Process : 원
2. 자료흐름 Data Flow : 화살표
3. 자료저장소 Data Store : 평행선
4. 단말 Terminal : 사각형

 

7) 소프트웨어 개발에 이용되는 모델(Model)에 대한 설명

1. 모델은 개발 대상을 추상화하고 기호나 그림 등으로 시각적으로 표현한다.
2. 모델을 통해 소프트웨어에 대한 이해도를 향상시킬 수 있다.
3. 모델을 통해 이해 당사자 간의 의사소통이 향상된다.
4. 소프트웨어 개발시 모델은 향후 개발될 시스템을 유추하기 위해서 하는 활동이며, 주로 시스템 개발자가 실행한다.

 

8) UML(Unified Modeling Language)

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

 

9) UI설계 도구

1. 스토리보드(Storyboard) : 디자이너와 개발자가 최종적으로 참고하는 작업지침서
                              상단이나 우측에 제목, 작성자들을 입력하고 좌측에는 UI화면, 우측엔 디스크립션(설명)을 기입한다.
2. 프로토타입(Prototype) : 와이어프레임이나 스토리보드등에 인터랙션(상호작용)을 적용함으로써 실제 구현된 것처럼 테스트가 가능한 동적인 형태의 모형
3. 유스케이스(Usecase) : 사용자 측면에서의 요구사항으로, 사용자가 원하는 목표를 달성하기 위해 수행할 내용을 기술한다.
4. 목업(Mockup) : ?????

 

10) 애자일(Agile) 기법 중 스크럼(Scrum)과 관련된 용어에 대한 설명

1. 스크럼 

 

11) UML 다이어그램 중 정적 다이어그램

• 정적(구조적)다이어그램 : 클객컴배복패
  - 클래스(Class) 다이어그램 : 클래스와 클래스가 가지는 속성, 관계를 표현하고 시스템의 구조 파악, 구조상의 문제점 도출
  - 객체(Object) 다이어그램 
  - 컴포넌트(Component) 다이어그램 : 구현 단계에서 사용
  - 배치(Deployment) 다이어그램 : 물리적 요소들의 위치를 표현, 구현 단계에서 사용
  - 복합체 구조(Composite Structure) 다이어그램 : 클래스나 컴포넌트가 복합 구조를 갖는 경우 그 내부 구조 표현
  - 패키지(Package) 다이어그램 : 패키지들의 관계 표현

 

12) LOC기법에 의거해 개발 소요기간 계산방법

노력(M/M) = 원시 코드 라인 수(LOC) / (1인당 월 평균 생산 코드 라인 수)

=36,000라인 / 300라인 = 120M/M

 

개발 기간 = (M/M)/참여 인원 = 120(M/M) / 6명 = 20개월

 

13) 클래스 설계원칙

1. 단일 책임원칙 : 하나의 객체는 하나의 동작만의 책임을 가진다.
2. 개방-폐쇄의 원칙 : 클래스는 확장에 대해 열려 있어야 하며 변경에 대해 닫혀 있어야 한다
3. 리스코프 교체의 원칙 : 특정 메소드가 상위 타입을 인자로 사용할 때, 그 타입의 하위 타입도 문제 없이 작동해야 한다.
4. 의존관계 역전의 원칙 : 상위 계층이 하위 계층에 의존하는 전통적인 의존관계를 반전(역전)시킴으로써 상위 계층이 하위 계층의 구현으로부터 독립되게 할 수 있음

 

14) GOF(Gangs of Four) 디자인 패턴

1. 생성패턴
   - 추상팩토리(Abstract Factory)
   - 빌더(Builder)
   - 팩토리메서드(FactoryMethod)
   - 프로토타입(Prototype)
   - 싱글톤(Sington)
2. 구조패턴
   - 어댑터(Adapter)
   - 브리지(Bridge)
   - 컴포지트(Composite)
   - 데코레이터(Decorator)
   - 파사드(Facade)
   - 플라이웨이트(Flyweight)
   - 프록시(Proxy)
3. 행위패턴
   - 책임 연쇄(Chain of Responsibility)
   - 커맨드(Command)
   - 인터프리터(InterPreter)
   - 이터레이터(Iterator)
   - 중재자(Mediator)
   - 메멘토(Memento)
   - 옵서버(Observer)
   - 상태(State)
   - 전략(Strategy)
   - 템플릿메서드(Template Method)
   - 방문자(Visitor)

 

15) 아키텍처(컴퓨터 시스템의 하드웨어 구조) 설계과정

소프트웨어 아키텍처의 설계과정

설계 목표 설정 -> 시스템 타입 결정 -> 아키텍처 패턴 적용 -> 서브시스템 구체화 -> 검토

 

16) 사용자 인터페이스 설계 시 고려해야 할 가이드 라인

사용자 친화적이게 설계되어야 하기에 사용성이 최우선으로 고려되어야 한다. <-> 심미성(미적인 부분)

효율성을 높이게 설계해야 한다.

발생하는 오류를 쉽게 수정할 수 있어야 한다.

사용자에게 피드백을 제공해야 한다.

 

17) 소프트웨어 설계에서 자주 발생하는 문제들을 피하기 위해 사용되는 패턴을 "디자인 패턴"이라 한다.

일반적이고 반복적인 해결 방법이기도 하다.

 

18) Rumbaugh(럼바우) 방법

모든 소프트웨어 구성 요소를 그래픽 표기법을 이용하여 모델링하는 기법으로, 객체 모델링 기법(Object Modeling Technique)라고도 한다.

분석활동은 객체모델링 -> 동적 모델링 -> 기능 모델링 순으로 통해 이루어진다.

 

Booch(부치) 방법

미시적(Micro) 개발 프로세스와 거시적(Macro) 개발 프로세스를 모두 사용하는 분석 방법으로, 클래스와 객체들을 분석 및 식별하고 클래스의 속성과 연산을 정의한다.

 

Jacobson 방법

Use case를 강조하여 사용하는 분석 방법이다.

 

Coad와 Yourdon 방법

E-R 다이어그램을 사용하여 객체의 행위를 모델링하며, 객체 식별, 구조 식별, 주제 정의, 속성과 인스턴스 연결 정의, 연산과 메시지 연결 정의 등의 과정으로 구성하는 기법

 

Wirfs-Brock 방법

분석과 설계 간의 구분이 없고, 고객 명세서를 평가해서 설계 작업까지 연속적으로 수행하는 기법

 

19)

• FEP(Front-End Processor)
  입력되는 데이터를 컴퓨터의 프로세서가 처리하기 전에 미리 처리하여 프로세서가 차지하는 시간을 줄여주는 프로그램이나 하드웨어
• EAI(Enterprise Application Integration)
  기업 응용 프로그램 통합으로 기업용 응용 프로그램의 구조적 통합 방안을 가르킨다
• GPL(General Public License)
  자유 소프트웨어 재단(OSF)에서 만든 자유 소프트웨어 라이센스
• Duplexing
  이중화(데이터베이스의 회복 기법 중 가장 간단한 것)

 

20) 

• Method(메서드) : 클래스로부터 생성된 객체를 사용하는 방법, 객체가 메시지를 받아 실행해야 할 객체의 구체적인 연산
• Class(클래스) : 특정 객체 내에 있는 변수와 메서드를 정의하는 일종의 틀, 객체 지향 프로그래밍에서 데이터를 추상화하는 단위
• Message(메시지) : 객체 간 상호 작용을 하기 위한 수단, 객체에게 어떤 행위를 하도록 지시하는 방법
• Field(필드) : Sql에서 열 또는 속성이라고 불리는 것