[정보처리기사] 소프트웨어 설계

1과목 : 소프트웨어 설계

디자인패턴

생성패턴 : 객체를 생성하는 것에 대한 패턴
- 추상 팩토리 패턴(abstract factory)
- 빌더 패턴(builder)
- 팩토리 메소드 패턴(factory method)
- 프로토타입 패턴(prototype)
- 싱글톤 패턴(singleton)
구조패턴 : 구조를 통해 확장성을 꾀하는 패턴
- 어댑터 패턴(adapter)
- 브릿지 패턴(bridge)
- 컴포지트 패턴(composite)
- 데코레이터 패턴(decorator)
- 퍼사드 패턴(facade)
- 플라이웨잇 패턴(flysweight)
- 프록시 패턴(proxy)
행위 패턴 : 행위의 변경, 수정 등을 위한 패턴
- 역할 사슬 패턴(책임 연쇄, chain of reposibility)
- 커맨드 패턴(command)
- 인터프리터 패턴(interpreter)
- 이터레이터 패턴(반복자, iterator)
- 미디에이터 패턴(중재자, mediator)
- 메멘토 패턴(memento)
- 옵저버 패턴(observer)
- 상태 패턴(state)
- 전략 패턴(strategy)
- 템플릿 메소드 패턴(template method)
- 비지터 패턴(방문자, visitor)

사용자 인터페이스(UI)

UI의 구분
- CLI(Command Line Interface) : 텍스트 형태 인터페이스
- GUI(Graphical User Interface) : 마우스로 선택하여 작업하는 그래픽 환경 인터페이스
- NUI(Natural User Interface) : 사용자의 말이나 행동으로 기기 조작하는 인터페이스
- VUI(Voice User Interface) : 사람의 음성으로 기기 조작하는 인터페이스
- OUI(Organic User Interface) : 모든 사물과 사용자 간의 상호작용을 위한 인터페이스
UI 설계도구
- 와이어프레임(Wireframe)
- 와이어프레임은 기획 단계의 기초에 제작하는 것, 페이지에 대한 개략적인 레이아웃이나 UI요소 등에 대한 뼈대를 설계하는 단계
- 와이어프레임을 제작할 때는 각 페이지의 영역 구분 컨텐츠, 텍스트 배치 등을 화면 단위로 설계
- 개발자나 디자이너 등이 레이아웃을 협의하거나 현재 진행 상태 등을 공유하기 위해 와이어프레임 사용
- 와이어프레임 툴 : 손그림, 파워포인트, 키노트, 스케치, 일러스트, 포토샵 등
  - 목업(Mockup)
- 목업은 디자인, 사용 방법 설명, 평가 등을 위해 와이어프레임보다 좀 더 설계 화면과 유사하게 만든 정적인 형태의 모형
- 시각적으로만 구성 요소를 배치하는 것으로 실제로 구현되지 않음
- 목업 툴 : 파워 목업, 발사믹 목업 등

스토리보드(Story Board)
- 스토리보드는 와엉프레임에 콘텐츠에 대한 성명, 페이지 간 이동 흐름 등을 추가한 문서
- 디자이너와 개발자가 최종적으로 참고하는 작업 지침서
- 스토리보드는 상단이나 우측에는 제복, 작성자 등을 입력하고, 좌측에는 UI 화면, 우측에는 디스크립션을 기입
- 디스크립션은 화면에 대한 설명, 전반적인 로직, 분기처리, 예외처리 등을 작성하는 부분으로, 명확하고 세부적으로 작성
- 스토리보드 톨 : 파워포인트, 키노트, 스케치, Axure 등
프로토타입(Prototpye)
- 프로토타입은 와이어프레임이나 스토리보드 등에 인터랙션을 적용함으로써 실제 구현된 것처럼 테스트가 가능한 동적인 형태의 모형
- 프로토타입은 사용성 테스트나 작업자 간 서비스 이해를 위해 작성하는 샘플
- 프로토타입은 작성 방법에 따라 페이지 프로토타입과 디지털 프로토타입으로 나뉨
- 프로토타입 툴 : HTML/CSS, Axure, Flinto, 네이버 프로토나우, 카카오 오븐 등
유스케이스(Use Case)
- 유스케이스는 사용자 측면에서의 요구사항으로, 사용자가 원하는 목표를 달성하기 위해 수행할 내용을 기술
- 사용자의 요구사항을 빠르게 파악함을써 프로젝트의 초기에 시스템의 기능적인 요구를 결정하고 그 결과를 문서화
- 유스케이스는 자연어로 작성된 사용자의 요구사항을 구조적으로 표현한 것
- 액터는 시스템 외부에서 시스템과 상호작용하는 사람 혹은 시스템
  - 사용자 액터: 기능을 요구하는 대상이나 시스템의 수행결과를 통보받는 사용자 혹은 기능을 사용하게 될 대상
  - 시스템 액터: 사용자 액터가 사용한 유스케이스를 처리해주는 외부 시스템, 시스템의 기능 수행을 위해서 연동이 되는 또 다른 시스템 액터
- 유스케이스 다이어그램이 완성되면, 각각의 유스케이스에 대해 유스케이스 명세서를 작성
- 구성요소
  - 연관 : use case 와 actor의 관계
  - 확장 : 기본 use case 수행 시 특별한 조건을 만족할 때 수행할 usecase
  - 포함 : 시스템의 기능이 별도의 기능을 포함
  - 일반화 : 하위 use case/action이 상위 use case/actor에게 기능/역할을 상속받음
  - 그룹화 : 여러개의 usecase를 단순화하는 방법

자료흐름도(DFD)

21513842570C3F6339

설계기법 : 상향 vs 하향

하향식 통합 테스트 ( Top Down Integration Test )
- 깊이 우선 통합법, 넓이 우선 통합법 사용
- 테스트 초기 부터 사용자에게 시스템 구조 보여줄 수 있다.
- 상위 모듈에서는 tc를 사용하기 어렵다.
- 상위 모듈에서 하위 모듈 방향으로 통합하면서 테스트하는 기법
- 계층 구조상에서 시스템의 주요 컴포넌트들을 찾고 그것을 낮은 수준의 컴포넌트들로 분해하는 것으로 단계적 정제라 하며 메인 모듈의 설계에서 시작하여 단계적으로 구체화시키는 것
- 하향식 설계에서는 통합 검사 시 인터페이스가 이미 정의되어 있어 통합이 간단하다.
- 하향식 설계에서 레벨이 낮은 데이터 구조의 세부 사항은 설계초기 단계에서 필요하다.
- 절차
- 주요 제어 모듈은 작성된 프로그램을 사용하고, 주요 제어 모듈의 종속 모듈들은 스텁 ( stub )로 대체 한다.
- 깊이우선 or 넓이 우선 등의 통합방식에 따라, 하위 모듈인 스텁들이 한 번에 하나씩 실제모듈로 교체된다.
- 모듈이 통합될 때마다 테스트 실시
- 새로운 오류가 발생하지 않음을 보증 하기 위해 회귀 테스트 실시
상향식 통합 테스트 ( Bottom Up Integration Test )
- 하위 모듈에서 상위 모듈 방향으로 통합하면서 테스트 하는 방법
- 가장 하위 단계의 모듈부터 통합 및 테스트가 수행되므로 스텁은 필요하지 않다.
- 하나의 주요 제어 모듈과 관련된 종속 모듈의 그룹인 클러스터( cluster )는 필요하다.
- 가장 기본적인 컴포넌트를 먼저 설계한 다음 이것을 사용하는 상위 수준의 컴포넌트를 설계하는 것
- 상향식 설계는 최하위 수준에서 각각의 모듈들을 설계하고 이러한 모듈이 완성되면 이들을 결합하여 검사한다.
- 기존 컴포넌트들을 조합하여 시스템을 개발하는 경우에는 상향식이 적합
  - 절차
- 하위 모듈을 클러스터로 결합
- 상위 모듈에서 데이터의 입출력을 확인하기 위해, 모듈인 드라이버 작성
- 통합된 클러스터 단위로 테스터
- 테스트가 완료되면 클러스터는 프로그램 구조의 상위로 이동 하여 결합하고, 드라이버는 실제 모듈로 대체

애자일의 스크럼 기법

스크럼은 프로젝트 관리를 위해 상호, 점진적인 개발 방법론이며 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심의 개발 방법론
스크럼 주요 진행 과정
- 제품 백로그 -> 스프린트 -> 스프린트 계획회의 -> 스프린트 백로그 -> 일일 스크럼 회의 -> 실행 가능한 제품 개발
용어
- 제품 백로그 : 개발한 제품에 대한 요구 사항 목록이다.
- 스프린트 : 반복적인 개발 주기, 2~4주 정도의 짧은 개발기간으로 개발 품질을 향상한다.
- 일일 스크럼 회의 : 매일 15분 정도 진행되는 스크럼 회의
- 스크럼 마스터 : 스크럼 프로젝트의 리더, 스크럼 진행 중 문제들을 인지하고 해결하는 역할
- 스프린트 회고 : 스프린트 주기를 되돌아보며 정해 놓은 규칙을 잘 지켰는지 확인하고 개선점을 확인 및 기록하는 것을 말한다. 스프린트가 끝난 시점이나 일정 주기로 시행한다.
- 번 다운 차트 : 남아 있는 백로그 대비 시간을 그래픽적으로 표현한 차트이다.

UML 다이어그램

정적구조(구조적 다이어그램) : 클래스, 객체, 패키지, 컴포넌트, 복합구조, 배치
동적구조(행위 다이어그램) : 유스케이스, 상태, 활동, 시퀀스, 통신, 상호작용, 타이밍

1) 클래스 다이어그램 : 객체를 생성하기 위한 도구. 클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현. 시스템의 구조를 파악하고 구조상의 문제점을 도출할 수 있음
2) 객체 다이어그램 : 객체 간의 연결관계를 표현
3) 패키지 다이어그램 : 객체들의 그룹화된 표현
4) 컴포넌트 다이어그램 : 시스템을 구성하는 컴포넌트 사이에 의존관계를 표현
* 컴포넌트는 1개이상의 클래스로 구현됨.
5) 복합구조 다이어그램 : 컴포넌트나 클래스의 내부 구조를 보여주기 위해 사용  내부 연결 형태를 표현
6) 배치 다이어그램 : H/W자원에 연결된 S/W컴포넌트 배치를 표현
7) 유스케이스 다이어그램 : 사용자의 시각에서 소프트웨어의 범위와 기능을 표현
8) 상태 다이어그램 : 시간에 따라 객체가 변하는 상태를 표현
9) 활동 다이어그램 : 객체의 동적행위를 활동으로 표현
10) 시퀀스 다이어그램 : 객체간 상호작용을 시간 순서에 따른 메시지로 표현
- 구성항목 : 액터, 활성객체(object), 라이프라인(생명선), 메세지, 제어삼각형
11) 통신 다이어그램 : 객체간 상호작용을 관계형태의 메세지로 표현
12) 상호작용 다이어그램 : 객체들의 상호작용 관계를 표현
13) 타이밍 다이어그램 : 객체간 상태변화를 구체적인 시간으로 표현

소프트웨어 비용 산정

비용 결정 요소
- 프로젝트 요소
  - 제품 복잡도 - 소프트웨어의 종류에 따라 발생할 수 있는 문제점들의 난이도
  - 시스템 크기 - 소프트웨어의 규모에 따라 개발해야 할 시스템의 크기
  - 요구되는 신뢰도 - 일정 기간 내 주어진 조건하에서 프로그램이 필요한 기능을 수행하는 정도
- 자원 요소
  - 인적 자원 - 소프트웨어 개발 관련자들이 갖춘 능력 혹은 자질
  - 하드웨어 자원 - 소프트웨어 개발 시 필요한 장비와 워드프로세서, 프린터 등의 보조 장비
  - 소프트웨어 자원 - 소프트웨어 개발 시 필요한 언어 분석기, 문서화 도구 등의 개발 지원 도구
- 생산성 요소
  - 개발자 능력 - 개발자들이 갖춘 전문지식, 경험, 이해도, 책임감, 창의력 등
  - 개발 기간 - 소프트웨어를 개발하는 기간
비용 산정 기법
- 하향식 비용 산정 기법
  - 과거의 유사한 경험을 바탕으로 전문 지식이 많은 개발자들이 참여한 회의를 통해 비용을 산정하는 방법
- 상향식 비용 산정 기법
  - 세부적인 작업 단위별로 비용을 산정한 후 집계하여 전체 비용을 산정하는 방법
- 전문가 감정 기법
  - 경험이 많은 두 명 이상의 전문가에게 비용 산정을 의뢰하는 기법
- 델파이 기법
  - 전문가 감정 기법의 주관적인 편견을 보완하기 위해 많은 전문가의 의견을 종합하여 산정하는 기법
- LOC 기법
  - 각 기능의 원시 코드 라인 수의 비관치, 낙관치, 기대치를 측정하여 예측치를 구하고 이를 이용하여 비용을 산정하는 기법
  - 예측치 = ( 낙관치 + 4 * 기대치 + 비관치 ) / 6
  - 비관치 : 가장 많이 측정된 코드 라인 수 (최댓값)
  - 낙관치 : 가장 적게 측정된 코드 라인 수 (최솟값)
  - 기대치 : 측정된 모든 코드 라인 수의 평균
  - 노력 = 개발 기간 x 투입 인원 = LOC / 1인당 월평균 생산 코드 라인 수
  - 개발 비용 = 노력 x 단위 비용(1인당 월평균 인건비)
  - 개발 기간 = 노력(인월) / 투입 인원
  - 생산성 = LOC / 노력(인월)
- 개발 단계별 인월수 기법
  - 기능을 구현시키는 데 필요한 노력을 생명 주기의 각 단계별로 산정
  - LOC 기법보다 더 정확
- 수학적 산정 기법
  - COCOMO 모형
  - Putnam 모형
  - 기능점수(FP) 모형

클래스 설계 원칙

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

객체지향 분석기법

Rumbaugh(럼바우) 방법
- 모든 소프트웨어 구성 요소를 그래픽 표기법을 이용하여 모델링하는 기법으로, 객체 모델링 기법(Object Modeling Technique) 라고도 한다. 분석활동은 객체모델링 -> 동적 모델링 -> 기능 모델링 순으로 통해 이루어진다
- (다음 설명에 이 “단어”가 있으면 해당 “모델링”이 정답)
  - 객체 모델링 : 정보 모델링, 시스템에서 요구
  - 동적 모델링 : 제어, 흐름, 동작
  - 기능 모델링 : DFD
Booch(부치) 방법
- 미시적(Micro) 개발 프로세스와 거시적(Macro) 개발 프로세스를 모두 사용하는 분석 방법으로, 클래스와 객체들을 분석 및 식별하고 클래스의 속성과 연산을 정의한다.
Jacobson 방법
- Use Case를 강조하여 사용하는 분석 방법이다.
Coad와 Yourdon 방법
- E-R 다이어그램을 사용하여 객체의 행위를 모델링하며, 객체 식별, 구조 식별, 주제 정의, 속성과 인스턴스 연결 정의, 연산과 메시지 연결 정의 등의 과정으로 구성하는 기법
Wirfs-Brock 방법
- 분석과 설계 간의 구분이 없고, 고객 명세서를 평가해서 설계 작업까지 연속적으로 수행하는 기법

아키텍쳐 설계과정

설계 목표 설정
시스템 타입 결정
스타일 적용 및 커스터마이즈
서브시스템의 기능, 인터페이스 동작 작성
아키텍처 설계 검토

아키텍쳐 스타일

클라이언트 서버 구조 : 컴포넌트가 다른 컴포넌트에게 서비스를 요청. 데이터가 여러 컴포넌트를 거치며 처리.
계층구조 : 모듈들로 응집된 계층 단위로 SW를 구성. 계층간에 사용 가능의 관계로 표현
MVC 구조 : 모델-뷰-컨트롤러, 기능을 분리한 아키텍처
파이프 필터 : 파이프를 통해 받은 데이터를 변경시키고 그 결과를 파이프로 전송

소프트웨어 설계 추상화 기법

추상화(Abstraction) : 문제의 전체적이고 포괄적인 개념을 설계한 후 차례로 세분화하여 구체화시켜 나가는 것
- 제어 추상화: 제어의 정확한 메커니즘을 정의하지 않고 원하는 효과를 정하는데 이용하는 방법
- 기능 추상화: 입력 자료를 출력자료로 변환하는 과정을 추상화하는 방법
- 자료 추상화: 자료와 자료에 적용될 수 있는 기능을 함께 정의함으로써 자료 객체를 구성하는 방법

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

일반적으로 실시간 시스템에서 사용
슬레이브는 마스터의 작업 요청을 처리하고, 처리된 결과를 되돌려줌
네임노드(마스터)는 데이터 노드(슬레이브)에 대한 메타 데이터를 가지고 있음
마스터: 작업을 분리, 배포
슬레이브: 요청 작업 처리

요구분석

기능적 요구사항
- 시스템이 수행해야 하는 행위들을 구체화 한 것
- 시스템에서 제공해야 할 기능을 정의한 것
- 입력기능, 출력기능, 데이터베이스 기능, 통신 기능 등
비기능적 요구사항
- 시스템이 가져야 하는 기능 이외의 요구사항
- 시스템의 전체적인 품질이나 고려해야 하는 제약사항 등
- 사용 용이성, 효율성, 신뢰성, 이식성, 유연성, 확장성 등
- 성능적인 면: 응답 속도, 자원 사용량 등
- 보안 측면: 침입 대응, 침입 탐지, 사용자 인증, 권한 부여 등

시스템 구성 요소

입력 (Input) : 처리 방법, 처리할 데이터, 조건을 시스템에 투입하는 것
처리 (Process) : 입력된 데이터를 처리 방법과 조건에 따라 처리하는 것
출력 (Output) : 처리된 결과를 시스템에서 산출하는 것
제어 (Control) : 자료를 입력하여 출력될 때까지의 처리 과정이 올바르게 진행되는지 감독하는 것
피드백 (Feedback) : 출력된 결과가 예정된 목표를 만족시키지 못할 경우 목표 달성을 위해 반복 처리하는 것

Maintenance는 유지보수로서, 시스템 구성요소에는 포함되지 않음.

요구사항 개발 프로세스 순서

도출
분석
명세
확인

시스템 품질 속성

가용성
변경용이성
성능
보안성
사용편의성
시험용의성

연계 시스템 구성

송신 시스템
연계할 데이터를 DB와 어플리케이션으로부터 연계테이블 또는 파일 형태로 생성하여 송신
수신 시스템
수신한 연계테이블, 파일데이터를 수신시스템에서 관리하는 데이터 형식에 맞게 변환하여 DB에 저장하거나 애플리케이션에서 활용할 수 있도록 제공
중계 서버
송/수신 시스템 사이에서 데이터를 송수신하고, 연계데이터의 송수신 현황을 모니터링함, 연계데이터의 보안강화 및 다중플랫폼 지원 등이 가능

CASE(Computer-Aided Software Engineering)

CASE: 시스템 개발과정의 일부 또는 전체를 자동화시킨 것
- 소프트웨어 생명주기의 전체 단계를 연결해 주고 자동화해주는 통합된 도구를 제공
- 소프트웨어, 하드웨어, 데이터베이스, 테스트 등을 통합하여 소프트웨어를 개발하는 환경을 제공
상위 CASE: 요구 분석과 설계 단계를 지원
- 모델들 사이의 모순검사 기능
- 모델의 오류 검증 기능
- 자료흐름도 작성 기능
하위 CASE: 코드를 작성하고 테스트하며 문서화하는 과정 지원
- 원시코드 생성 기능
통합 CASE: 소프트웨어 개발 주기 전체과정을 지원
원천기술
- 구조적 기법 / 프로토타이핑 기술 / 자동프로그래밍 기술 / 정보 저장소 기술 / 분산 처리 기술

미들웨어 종류

WAS : 애플리케이션 수행 미들웨어
MOM : 메세지 지향 미들웨어
RPC : 원격 프로시저 호출
ORB : 네트워크 호출 미들웨어

시스템 연계 기술

DB링크
- 데이터베이스에서 제공하는 DB 링크 객체를 이용한다.
- 수신측에서 DB 링크를 생성하고 송신측에서 해당 DB링크를 직접 참조하는 방식이다.
DB 커넥션 : 수신측의 WAS에서 송신측 데이터 베이스로 연결하는 DB Connection Pool을 생성한다.
API/OpenAPI : 송신측의 데이터베이스에서 데이터를 가져와 제공하는 응용 프로그래밍 인터페이스 프로그램이다.
JDBC
- 수신측의 프로그램에서 JDBC 드라이버를 이용하여 송신 시스템 데이터베이스와 연결한다.
- DBMS 유형, DBMS 서버 IP와 Port, DB Instance 정보가 필요하다
하이퍼링크 : 웹 응용에서 하이퍼링크(Hyper Link)를 이용한다.
소켓 :
- 서버는 통신을 위한 Socket을 생성하여 Port를 할당한다.
- 클라이언트의 통신 요청 시 클라이언트와 연결하고 통신하는 네트워크 기술이다.

현행 시스템 분석

플랫폼 기능 분석
플랫폼 성능 분석
운영체제 분석
네트워크 분석
DBMS 분석
비즈니스 융합 분석

소프트웨어의 설계

상위 설계 : 아키텍처 설계, 데이터 설계, 시스템 분할, 인터페이스 정의, 사용자 인터페이스 설계(UI 설계)
하위 설계 : 모듈 설계, 인터페이스 작성

자료사전 표기 방법

= : 자료의 정의(~로 구성되어 있다)
+ : 자료의 연결(그리고)
() : 자료의 생략(생략 가능한 자료)
[] : 자료의 선택(또는) ex) [ A B C ]
{} : 자료의 반복
* * : 자료의 설명(주석)

객체지향 설계 원칙

단일 책임 원칙(SRP, Single Responsibility Principle)
객체는 단 하나의 책임만 가져야 한다.
개방-폐쇄의 원칙(OCP, Open Closed Principle)
기존의 코드를 변경하지 않으면서 기능을 추가할 수 있도록 설계가 되어야 한다.
리스코프 치환 원칙(LSP, Liskov Substitution Principle)
일반화 관계에 대한 이야기며, 자식 클래스는 최소한 자신의 부모 클래스에서 가능한 행위는 수행할 수 있어야 한다.
인터페이스 분리 원칙(ISP, Interface Segregation Principle)
인터페이스를 클라이언트에 특화되도록 분리시키라는 설계 원칙이다.
의존 역전 원칙(DIP, Dependency Inversion Principle)
의존 관계를 맺을 때 변화하기 쉬운 것 또는 자주 변화하는 것보다는 변화하기 어려운 것, 거의 변화가 없는 것에 의존하라는 것.

인터페이스 요구 사항 검토

동료 검토(Peer Review)
- 요구사항 명세서 작성자가 요구사항 명세서를 설명하고 이해관계자들이 설명을 들으면서 결함을 발견
워크스루(Walk Through)
- 검토 회의 전, 명세서를 미리 배포하여 사전검토 후에 짧은 검토 회의를 통해 결함 발견
인스펙션(Inspection)
- 요구사항 명세서 작성자를 제외한 다른 검토 전문가들이 명세서를 확인하면서 결함을 발견

IM