모르겠는건 여기 참고

https://1d1cblog.tistory.com/87
https://velog.io/@yuhyeonp

요구사항확인

연습문제

9-5. UML 다이어그램 중 구현 단계에서 사용하기에 가장 적합한 것은?

1. 유즈케이스 다이어그램
2. 컴포넌트 다이어그램 + 배치 다이어그램
3. 활동 다이어그램
4. 클래스 다이어그램

예상문제

20. 다음은 서점 시스템의 요구사항에 대한 내용이다. 비기능 요구사항에 대한 설명은?

1. 사용자는 로그인 또는 비로그인을 통해 책을 구매할 수 있어야 한다.
2. 사용자가 책을 현금으로 구매하였을 경우 현금영수증 처리를 할 수 있어야 한다.
3. 동시에 100명 이상이 주문을 요청해도 처리할 수 있어야 한다. -> 시스템 품질 (비기능)
4. 사용자가 마이페이지에 저장해 놓은 도서 목록은 일정 기간 동안 그대로 저장되어 있어야 한다.

21. 요구사항 협상은 요구사항이 서로 충돌하는 경우 이를 적절히 해결하는 과정이다. 다음 중 요구사항이 서로 충돌되어 적절한 기준점을 찾아 합의해야 하는 경우가 아닌 것은?

1. 두명의 이해관계자가 요구하는 요구사항이 서로 충돌되는 경우
2. 요구사항이 서로 우선순위가 다른경우 -> 이미 우선순위가 부여 됐으므로 충돌x
3. 요구사항과 자원이 서로 충돌되는 경우
4. 기능 요구사항과 비기능 요구사항이 서로 충돌되는 경우

화면설계

연습문제

10-3. 소프트웨어 아키텍처에 관한 설명으로 가장 옳지 않은 것은?

1. 아키텍처의 결정은 비기능적 요구사항과 큰 관련이 있다.
2. 물리적 구성을 바탕으로 정의하는 시스템의 상세 설계도이다.
   -> 시스템의 "논리적" 구성을 정의하는 것으로, "초기 설계" 또는 "개략 설계"라고도 한다
3. 초기 계획 단계에서 작성되어 개발 및 유지 보수 작업 등에 영향을 준다.
4. 작업자들 간의 상호 이해, 타협 및 의사 소통을 위해 사용된다.

14-2. 소프트웨어 품질 체계인 ISO/IEC 9126의 품질 특성 중 신뢰성(Reliability)에 속하지 않는 특성은?

1. 성숙성(Maturity)
2. 결함허용성(Fault Tolerance)
3. 회복성(Recoverability)
4. 정확성(Accuracy) --> 기능성에 속함

18-1. 다음 중 사용자 인터페이스의 시나리오 문서에 포함되는 내용이 아닌 것은?

1. 다양한 상황에서의 예외 처리 방식
2. 대표 화면 간 인터랙션 흐름
3. GUI
   -> UI 시나리오 문서가 완성되면 이것을 토대로 GUI를 설계한다
4. 기능 구조

18-2. 완성된 UI 시나리오 문서를 가지고 다음 작업을 진행하는 담당자가 아닌 것은?

1. 인터랙션 디자이너
   -> UI시나리오 문서를 작성하는 사람
2. 개발자
3. 품질 관리자
4. GUI 디자이너

애플리케이션 설계

연습문제

22-1. 소프트웨어 아키텍처의 패턴중 Pipe-Filter에 대한 설명으로 옳은 것은?

1. 컴포넌트 간의 인터페이스가 복잡한 시스템에 적합하다.
2. 유저가 직접 데이터 흐름에 간섭할 필요가 있는 경우에 사용된다.
3. 모든 컴포넌트가 동시에 처리되어야 하는 병렬처리 시스템에 적합하다.
4. 하나의 컴포넌트에서 처리가 끝나면 다음 컴포넌트가 결과물을 받아 처리하는 과정이 반복된다.
   -> Pipe-Filter Pattern: 각 단계를 필터 컴포넌트로 캡슐화하여 앞의 컴포넌트에서 처리한 결과를 파이프를 통해서 전송하면 뒤의 컴포넌트에서 결과를 받아 다음 작업을 수행하는 구조

23-3. 결합도 강 -> 약 순서

내용(content) > 공통(common) > 외부(external) > 제어(control) > 스탬프(stamp) > 자료(data) 결합도

23-6. 응집도 강 -> 약 순서

기능적(functional) > 순차적(sequential) > 교환적(communication) > 절차적(procedural) > 시간적(temporal) > 논리적(logia) > 우연적(coincidental) 응집도

26-2. Iterator 패턴에 대한 설명으로 옳지 않은 것은?

1. 내부 표현 방법의 노출 없이 접급이 가능하다.
2. 클라이언트는 독립적으로 원하는 알고리즘을 선택하여 사용할 수 있다.
   -> 행위패턴의 '전략'
3. 배열이나 리스트 같은 자료 구조를 처리하는 데 사용된다.
4. 집합 객체의 각 요소들에 대해 순차 접근하는 방식이다.

예상문제

2. 추상화의 유형 중 이벤트 발생의 구체적인 절차 또는 방법을 정의하지 않고 대표할 수 있는 표현으로 대체하는 것

1. 과정 추상화
   -> 자세한 수행 과정을 정의하지 않고, 전반적인 흐름만 파악할 수 있게 설계하는 방법
2. 데이터 추상화
   -> 데이터의 세부적인 속성이나 용도를 정의하지 않고, 데이터 구조를 대표할 수 있는 표현으로 대체하는 방법
3. 제어 추상화
4. 이벤트 추상화
   -> 없음

3. 소프트웨어 아키텍처 설계에 대한 설명으로 옳지 않은 것

1. 이해 관계자들의 의사소통 도구로 활용된다.
2. 설계된 모듈을 프로그래밍 언어를 통해 구현한다. -> 아키텍처 '구현'에 관한 설명
3. 애플리케이션을 모듈로 분할하고, 모듈 간 인터페이스를 결정하는 과정이다.
4. 기본 원리에는 모듈화, 추상화, 단계적 분해, 정보은닉이 있다.

4. 소프트웨어 아키텍처의 품질 속성 중 다음 설명이 의미하는 것은?

• 개발 비용을 더 투자하여 유연성이 높은 아키텍처를 만들것인지를 결정하는 것이다.
• 유연성이 떨어지는 경우 이후 유지보수에 많은 비용이 소모될 수 있다는 것을 고려해야 한다.

1. 비용과 혜택
2. 시장 적시성
   -> 정해진 시간에 맞춰 프로그램을 출시하는 것
3. 가용성
   -> 장애 없이 정상적으로 서비스를 제공하는 것
4. 구축 가능성
   -> 모듈 단위로 구분된 시스템을 적절하게 분배하여 유연하게 일정을 변경할 수 있도록 하는 것

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

1. 요구사항을 분석하여 전체 시스템의 설계 목표를 설정한다.
2. 시스템과 서브시스템의 타입을 결정한다.
3. 표준 아키텍처를 설계한다.
4. 서브시스템의 기능과 서브시스템 간의 인터페이스를 정의(=구체화)한다.
5. 검토

8. 아키텍처 스타일과 이를 기반으로 하는 시스템의 관계를 짝지은 것

1. Layer Pattern - OSI 참조 모델
2. Master-Slave Pattern - 장애 허용 시스템, 병렬 컴퓨팅 시스템
3. Blackboard Pattern - 차량 식별 시스템
4. MVC Pattern - 대화영 애플리케이션

14. 객체지향 개념에서 연관된 데이터와 함수를 함께 묶어 외부와 경계를 만들고 필요한 인터페이스만을 밖으로 드러내는 과정

1. 정보 은닉(Information Hiding)
   -> 한 모듈 내부에 포함된 절차와 자료들의 정보가 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법
2. 클래스(Class)
   -> 공통된 속성과 연산(행위)을 갖는 객체의 집합. 객체의 일반적인 타입(Type)
3. 캡슐화(Encapsulation)
4. 통합(Intergration)

18. 두 모듈이 동일한 자료 구조를 조회하는 경우의 결합성이며 자료 구조의 어떠한 변화, 즉 포맷이나 구조의 변화는 그것을 조회하는 모든 모듈 및 변화되는 필드를 실제로 조회하지 않는 모듈에까지도 영향을 미치게 되는 결합성은?

1. Data Coupling 자료
   -> 어떤 모듈이 다른 모듈을 호출하면서 매개 변수나 인수로 데이터를 넘겨주고, 호출 받은 모듈은 받은 데이터에 대한 처리 결과를 다시 돌려주는 방식
2. Stamp Coupling 스탬프
3. Control Coupling 제어
   -> 어떤 모듈이 다른 모듈 내부의 논리적인 흐름을 제어하기 위해 제어 신호를 이용하여 통신하거나 제어요소를 전달하는 결합도
4. Content Coupling 내용
   -> 하나의 모듈이 직접적으로 다른 모듈의 내용을 참조할 때 두 모듈은 내용적으로 결합되어 있다고 한다.
5. Common Coupling 공통
   -> 두 모듈이 동일한 전역 데이터를 접근할 때

24. 효과적인 모듈 설계 방법

1. Coupling은 약하게, Cohesion는 강하게 설계.
2. Complexity와 Redundancy(중복성)은 줄인다
3. Matintenance가 용이하도록
4. Module 크기는 시스템의 전반적인 기능과 구조를 이해하기 쉬운 크기로 설계

26. 공통 모듈을 설계할 때 공통 부분을 명세하기 위한 기법

1. 명확성
2. 일관성
3. 정확성
4. 완전성
5. 추적성

28. 다음과 같이 주로 도서 분류 코드에 사용되는 코드

• 도서 목록 : 부여 코드
• ..국문학.. : ....100....
• ..철..학.. : ....200....
• ..정보학.. : ....300....

1. 10진코드
2. 순서코드
   -> 1,2,3,4...
3. 문자코드
   -> ??
4. 분류코드
   -> 1-01-001 : 본사-총무부-인사계, 2-01-001 : 지사-총무부-인사계

33. 디자인 패턴에 대한 설명

1. Singleton: 하나의 객체를 생성하여 해당 객체를 어디서든 참조할 수 있도록 한다.
2. Bridge: 구현에서 추상을 분리하여, 독립적으로 다양성을 가질 수 있다.
3. Chain of Responsibility: 한 객체가 처리하지 못한 요청을 다음 객체가 처리하는 형태
4. Strategy: 알고리즘들을 개별적으로 캡슐화하여 필요할 때 마다 원하는 알고리즘을 선택하여 사용할 수 있는 패턴

인터페이스 설계

연습문제

27-3. 시스템 인터페이스 요구사항 분석 절차

1. 요구사항 선별
2. 요구사항 관련 자료 준비
3. 요구사항 분류
4. 요구사항 분석 및 명세서 구체화
5. 요구사항 명세서 공유

27-4. 시스템 인터페이스 관련 요구사항 중 비기능적 요구사항에 해당하지 않는 것은?

1. 인사 및 조직 정보 등록 -> 기능적 요구사항
2. 운영 접근 통제
3. 처리 속도 및 시간
4. 시스템 장애 대응

29-1. 다음 중 인터페이스 시스템 식별에 대한 설명으로 틀린 것은?

1. 인터페이스 별로 인터페이스에 참여하는 시스템들을 송신 시스템과 수신 시스템으로 구분하여 작성하는 것 -> 인터페이스 시스템 식별
   -> 인터페이스 요구사항 명세서와 인터페이스 요구사항 목록 기반 -> 내 외부 시스템 사이의 인터페이스를 식별
2. 식별된 내,외부 시스템 간 인터페이스에 참여하는 시스템들을 송신 측과 수신 측으로 구분한다.
3. 인터페이스가 내부 시스템 간 또는 내,외부 시스템 간에 발생하는지를 파악하여 대내외 여부를 기재한다.
4. 개발하고자 하는 시스템과 타 시스템 사이의 인터페이스를 유일하게 식별할 수 있도록 인터페이스명을 부여한다.

30-1. 송,수신 시스템 사이에서 교환되는 데이터에 대한 설명

1. 송,수신 데이터 항목은 인터페이스별로 전송되는 데이터 항목과 순서가 다르다.
2. 인터페이스 표준 항목 중 시스템 공통부는 시스템 간 연동 시 필요한 공통 정보를 의미한다.
3. 인터페이스 표준 항목 중 거래 공통부는 연동 처리 시 필요한 직원, 승인자, 기기, 매체 등으로 구성된다.
4. 대,내외 연계 시 사용하는 공통 코드와 연계 시스템 등에서 사용하는 상태 또는 오류 코드와 같은 공통 코드 항목에 대해 코드값과 코드명, 코드 설명 정보 등을 공통 코드로 관리해야 한다.

30-2. 송,수신 데이터 식별에 대한 설명

1. 개발하고자 하는 시스템과 연계할 내,외부 시스템 사이의 정보 흐름과 데이터베이스 산출물들을 기반으로 송,수신 데이터를 식별하고 정의한다.
2. 송,수신 데이터를 식별하는데 필요한 데이터베이스 산출물에는 테이블 정의서, 코드 정의서, ERD 등이 있다.
3. 데이터베이스 산출물들을 기반으로 송,수신 시스템 사이에서 교환되는 범위를 파악하고 데이터 항목을 식별한다.
4. 코드성 데이터 항목에 대해 연계 시스템에서 사용하는 코드명과 코드값이 다를 경우 코드 매핑 대상으로 식별하고 양쪽 시스템에서 사용하는 코드 정보를 확보한다.

31-1. 인터페이스 송,수신 방법을 명세화 하는데 포함되는 항목

1. 인터페이스 발생 주기
2. 인터페이스 통신 유형
3. 인터페이스 처리 유형
4. 인터페이스 연계 방식

31-3. 인터페이스 통신 유형

• 단방향
• 동기
• 비동기

31-4. 인터페이스 처리 유형과 발생 주기에 대한 설명

1. 인터페이스 처리 유형은 업무의 성격 및 전송량을 고려하여 정의한다.
2. 인터페이스 발생 주기는 업무 성격과 송,수신 데이터 양을 고려하여 매일, 수시 등으로 정의한다
3. 인터페이스 처리 유형
   -- 실시간 방식: 사용자가 요청한 내용을 바로 처리해야할 때
   -- 지연 처리 방식: 데이터를 매 건 단위로 처리할 경우 비용이 많이 발생할 때
   -- 배치 방식: 대량의 데이터를 처리할 경우

32-2. 시스템 인터페이스 정의서

1. 데이터 송.수신 시스템 간의 데이터 저장소와 속성등을 작성한다.
2. 최대 처리 횟수: 단위 시간당 처리될 수 있는 해당 인터페이스 최대 수행 건수
3. 데이터 크기: 해당 인터페이스 1회 처리 시 소요되는 데이터의 평균 및 최대크기

• 인터페이스 ID, 인터페이스명, 처리 유형, 통신 유형 -> 시스템 인터페이스 목록에 기록

33-1. 미들웨어 솔루션의 유형

1. ORB: 객체 지향 미들 웨어, 코바(CORBA) 표준 스펙을 구현한 미들웨어
2. DB: 데이터베이스 벤더에서 제공하는 클라이언트에서 데이터베이스와 연결하기 위한 미들웨어
3. WAS: 웹환경을 구현하기 위한 미들웨어
4. MOM: 메시지 기반의 비동기형 메시지를 전달하는 방식의 미들웨어

33-2. 개발 및 운영 환경에서 사용될 미들웨어 솔루션을 확인하는 방법

1. 아키텍처 구성 정보를 검토
2. 프로젝트의 구매 SW를 검토
3. 프로젝트에서 사용될 미들웨어 솔루션에 대해 정리

• 솔루션의 제약사항에 대해 검토 -> 명세서 작성 시 수행

예상문제

2. 시스템 인터페이스 요구사항 명세서의 항목

1. 인터페이스 이름
2. 연계 대상 시스템
3. 연계 범위 및 내용
4. 연계 방식
5. 송신 데이터 (수신 데이터는 아님)
6. 인터페이스 주기
7. 기타 고려사항

6. 요구사항 명세서 검토 방법

1. 워크스루: 검토 회의 전에 요구사항 명세서를 미리 배포하여 사전 검토한 후에 짧은 검토 회의를 통해 결함을 발견하는 형태
2. 인스펙션: 요구사항 명세서 작성자를 제외한 다른 검토 전문가들이 요구사항 명세서를 확인하면서 결함을 발견하는 형태
3. 동료 검토: 요구사항 명세서 작성자가 명세서의 내용을 직접 설명하고 이해관계자들이 이를 들으면서 결함을 발견하는 형태

10. 시스템 연계 기술

1. DB Link: 수신 시스템에서 DB Link를 생성하고 송신 시스템에서 해당 DB Link를 직접 참조하는 방식
2. 연계 솔루션: EAI 서버와 송, 수신 시스템에 설치되는 클라이언트를 이용하는 방식
3. Socket: 서버가 통신을 위한 소켓을 생성하여 포트를 할당하고 크랄이언트의 통신 요청 시 클라이언트와 연결하여 통신하는 네트워크 기술
4. Web Service: 웹 서비스에서 WSDL과 UDDI, SOAP 프로토콜을 이용하여 연계하는 방식

12. 인터페이스 오류 식별 및 처리 방안 명세화

1. 오류가 발생하는 영역을 구분할 수 있는 발생 영역 구분자를 정의한다.
2. 오류 발생 시 오류 코드, 오류 메시지, 오류 설명 및 해결 방법 등을 정의한다.
3. 오류를 식별하는 오류 코드는 오류 발생 영역 구부낮와 오류 그룹 번호 등을 참조하여 정의한다.
4. 오류 처리에 참고할 수 있도록 오류 발생 원인 등 상세한 설명을 포함해서 정의한다.

13. 시스템 인터페이스 설계서

1. 설계서: 시스템의 내, 외부 인터페이스를 식별하고 인터페이스의 명세를 기술하기 위해 작성한다.
2. 설계서: 시스템 인터페이스 목록과 시스템 인터페이스 정의서로 구성
   --목록: 연계 업무와 연계에 참여하는 송,수신 시스템의 정보, 연계 방식과 통신 유형 등에 대한 정보를 포함
   --정의서: 데이터 송신 시스템과 수신 시스템 간의 데이터 저장소와 속성 등의 상세 내역을 포함