[정보처리기사 실기] 1. 요구사항 확인

요구사항 확인

(1) 소프트웨어 생명주기 모델

1. 소프트웨어 생명주기 모델 개념

• 소프트웨어 생명주기는 시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차
• 시스템이 개발될 때부터 운용과 유지보수를 거쳐 생애를 마칠 때까지의 작업 프로세스를 모델화한 것

2. 소프트웨어 생명주기 모델 프로세스

1. 요구사항 분석
   • 다양한 요구사항을 종합하여 요구와 조건을 결정하는 단계
   • SW기능과 제약 조건, 목표 등을 사용자와 함께 정의
   • 기능 요구사항, 비기능 요구사항
2. 설계
   • 시스템 명세 단계에서 정의한 기능을 실제 수행하도록 방법을 논리적으로 결정하는 단계
   • 시스템 구조 설계, 프로그램 설계, 사용자 인터페이스 설계
3. 구현
   • 논리적으로 결정한 문제 해결 방법을 실제 프로그램으로 작성하는 단계
   • 언어 선택, 기법, 스타일, 순서 등을 결정
   • 인터페이스 개발, 자료 구조 개발, 오류 처리
4. 테스트
   • 예상과 실제 결과가 어떤 차이를 보이는지 검사하고 평가하는 단계
   • 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트
5. 유지보수
   • 시스템이 인수되고 설치된 후 일어나는 모든 활동
   • 예방, 완전, 교정, 적응 유지보수

3. 소프트웨어 생명주기 모델 종류

• 소프트웨어 생명주기 모델 종류
  • 폭포수 모델
    • 각 단계를 확실히 마무리 지은 후 다음 단계로 넘어가는 모델
    • 가장 오래된 모델
    • 선형 순차적 모형으로 고전적 생명주기 모형으로도 불림
    • 적용 경험과 성공 사례多
    • 단계별 정의와 산출물이 명확
    • 요구사항 변경 어려움
    • 타당상 검토 => 계획 => 요구사항 분석 => 설계 => 구현 => 테스트 => 유지보수
  • 프로토타이핑 모델
    • 고객이 요구한 주요 기능을 프로토타입으로 구현, 피드백을 반영하며 소프트웨어를 만들어가는 모델
    • 발주자, 개발자 모두에게 공동의 참조 모델 제공
    • 프로토타입은 구현 단계의 구현 골격
  • 나선형 모델
    • 시스템 개발 시 위험을 최소화하기 위해 점진적으로 완벽한 시스템으로 개발해 나가는 모델
    • 계획 및 정의 => 위험 분석 => 개발 => 고객 평가
  • 반복적 모델
    • 구축대상을 나누어 병렬적으로개발 후 통합 혹은 반복적으로 개발하여 점증 완성시키는 모델
    • 요구사항 일부분 혹은 제품 일부분을 반복적으로 개발하여 최종 시스템으로 완성
• 소프트웨어 생명주기 모델 간 비교

구분	폭포수 모델	프로토타이핑 모델	나선형 모델	반복형 모델
절차도	요구사항 분석 => 설계 => 구현 => 테스트	1. 요구사항 분석 => 프로토타입 개발 => 프로토타입 평가 => 구현 => 테스트 2. 요구사항 분석 => 프로토타입 개발 => 프로토타입 평가 => 요구사항 분석	계획 및 정의 => 위험분석 => 개발 => 고객평가 => 계획 및 정의 (반복)	개발대상 => 분석 => 설계 => 구현 (병렬)
특징	순차적 접근	프로토타입	- 위험분석 - 반복 개발	증분방식으로 병행 개발
장점	- 이해 용이 - 관리 편리	- 요구분석 용이 - 타당성 검증 가능	- 위험성 감소 - 변경에 유연한 대처	병행 개발로 인한 일정 단축 가능
단점	요구사항 변경 어려움	프로토타입 폐기 비용	단계 반복 관리 어려움

 

(2) 소프트웨어 개발 방법론

1. 소프트웨어 개발 방법론 개념

• 소프트웨어 개발 방법론은 소프트웨어 개발 전 과정에 지속적으로 적용가능한 방법, 절차, 기법
• 소프트웨어를 하나의 생명체로 간주하고 소프트웨어 개발의 시작 부터 시스템을 사용하지 않는 과정까지 전 과정을 형상화한 방법론

2. 소프트웨어 개발 방법론 종류

종류	구분
구조적 방법론	- 전체 시스템을 기능에 따라 나누어 개발하고, 통합하는 분할과 정복 접근 방식 - 프로세스 중심의 하향식 방법론 - 나씨-슈나이더만 차트 사용
정보공학 방법론	- 정보시스템 개발에 필요한 관리 절차와 작업 기법을 체계화 - 개발주기를 이용해 대형 프로젝트를 수행하는 체계적인 방법론
객체 지향 방법론	- '객체'라는 기본 단위로 시스템을 분석 및 설계하는 방법론 - 현실 세계를 사람이 이해하는 방식으로 시스템에 적용 - 객체, 클래스, 메시지 사용
컴포넌트 기반 방법론	- 소프트웨어를 구성하는 컴포넌트를 조립, 하나의 새로운 응용프로그램 작성 - 개발 기간 단축으로 생산성 향상 - 확장성 - 소프트웨어 재사용
애자일 방법론	- 절차보다 사람이 중심이 되어 변화에 유연하고, 신속 적응적 경량 개발 방법론
제품 계열 방법론	- 특정 제품에 적용하고 싶은 공통 기능을 정의하여 개발 - 임베디드 소프트웨어에 유용

3. 애자일

1. 애자일 방법론의 개념
   • 절차보다는 사람이 중심, 변화에 유연하고 신속하게 적응하며 효율적으로 시스템을 개발
   • 개발 기간이 짧고 신속, 폭포수 모형에 대비되는 방법론
   • 기존 개발 방법론의 한계를 극복하기 위해 등장
2. 애자일 방법론의 유형
   • 대표적인 애자일 방법론(XP, 린, 스크럼)
   • XP
     • 의사소통 개선, 즉각적 피드백으로 소프트웨어 품질 향상
     • 1~3주의 반복 개발 주기
     • XP의 5가지 가치
       • 용기
       • 단순성
       • 의사소통
       • 피드백
       • 존중
     • XP의 12가지 기본원리
       • 짝 프로그래밍
       • 공동 코드 소유
       • 지속적인 통합
       • 계획 세우기
       • 작은 릴리즈
       • 메타포어
       • 간단한 디자인
       • 테스트 기반 개발
       • 리팩토링
       • 40시간 작업
       • 고객 상주
       • 코드 표준
   • 스크럼
     • 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론
     • 주요개념
       • 백로그: 제품과 프로젝트에 대한 요구사항
       • 스프린트: 2~4주의 짧은 개발 기간으로 반복적 수행
       • 스크럼 미팅: 매일 15분 정도 미팅 TO-DO리스트 수립(데일리 미팅)
       • 스크럼 마스터: 프로젝트 리더
       • 스프린트 회고: 스프린트 주기를 되돌아보며 규칙 준수 여부, 개선점 등 확인, 스프린트 후 일정 주기로 시행
       • 번 다운 차트: 남아있는 백로그 대비 시간을 그래픽적으로 표현
   • 린
     • 도요타의 린 시스템 품질기법으로 소프트웨어에 적용
     • JIT, 칸반 보드 사용
     • 7가지 원칙(낭비제거, 품질 내재화, 지식 창출, 늦은 확정, 빠른 인도, 사람 존중, 전체 최적화)

(3) 객체 지향 분석 방법론

1. 객체 지향 개념

객체 지향은 현실의 개체를 속성과 메서드가 결합한 형태의 객체로 표현

2. 객체 지향 구성요소

구성요소	설명
클래스	- 특정 객체 내에 있는 변수와 메서드를 정의하는 틀 - 데이터를 추상화하는 단위 - 유사한 객체들을 묶어서 공통된 특성 표현 - 속성 = 변수, 행위 = 메서드
객체	- 물리적 추상적으로 자신과 다른 것을 식별 가능한 대상 - 클래스에서 정의한 것을 토대로 메모리에 할당 - 객체마다 고유의 식별성
메서드	- 클래스로부터 생성된 객체를 사용하는 방법 - 객체가 메시지를 받아 실행해야 할 객체의 연산 - 함수 또는 프로시저에 해당하는 연산 기능
메시지	- 객체 간 상호 작용을 하기 위한 수단 - 객체에게 행위를 지시 - 객체 간 상호작용 유발 - 메시지는 객체에서 객체로 전달
인스턴스	- 클래스에 의해 만들어진 실제의 객체 - 실제로 메모리상에 할당
속성	- 객체의 데이터 값을 단위별로 정의(현재 상태의 표현 값)

3. 객체 지향 기법

기법	설명
캡슐화	- 연관된 데이터와 함수를 묶어 필요한 인터페이스만을 드러내는 기법 - 결합도↓, 재사용 용이 - 인터페이스 단순화 - 정보 은닉 - 변경에 용이
상속성	- 하위클래스에서 상위 클래스의 속성과 메서드를 사용
다형성	- 하나의 메시지에 대해 객체가 가지고 있는 고유한 방법으로 응답할 수 있는 능력 - 상속받은 하위 객체들이 다른 형태의 특성을 갖는 객체로 이용 가능한 성질 - 오버로딩: 매개변수의 유형과 개수를 다르게 하여 같은 이름의 메서드를 여러 개 사용 - 오버라이딩: 상위 클래스에서 정의한 메서드의 구현을 하위 클래스에서 재정의 할 수 있는 기법
추상화	- 공통 성질을 추출하여 추상 클래스를 설정 - 과정 추상화, 자료 추상화, 제어 추상화
정보 은닉	- 코드 내부 데이터와 메서드를 숨기고 공개 인터페이스만으로 접근 가능케 함 - 하부 시스템이 다른 모듈의 구현에 영향을 받지 않게 설계 - 모듈 사이의 독립성
관계성	- 두 개 이상의 엔터티 형에서 데이터를 참조하는 관계를 나타냄 - 연관화, 집단화, 분류화, 일반화, 특수화

 

4. 객체 지향 설계 원칙(SOLID)

원칙	설명
단일 책임의 원칙 (SRP)	- 하나의 클래스는 하나의 목적을 위해 생성, 클래스가 제공하는 모든 서비스는 하나의 책임을 수행 - 객체 지향 프로그래밍 5원칙 중 나머지 4원칙의 기초
개방 폐쇄 원칙 (OCP)	- 소프트웨어 구성요소는 확장에는 오픈, 변경에는 닫혀있어야 함
리스코프 치환의 원칙 (LSP)	- 서브 타입(상속받은 하위 클래스)은 어디서나 자신의 기반 타입(상위 클래스)로 교체될 수 있음
인터페이스 분리의 원칙 (ISP)	- 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 않아야 함 - 객체 설계 시 특정 기능에 대한 인터페이스는 그 기능과 상관없는 부분이 변해도 영향이 없어야 함
의존성 역전의 원칙 (DIP)	- 추상을 매개로 메시지를 주고받아 관계를 최대한 느슨하게 함

 

5. 객체 지향 분석 방법론 종류

종류	만든 이	설명
OOSE (Object Oriented Software Engineering)	야콥슨 (Jacobson)	- 유스케이스를 모든 모델의 근간으로 활용 - 분석, 설계, 구현 단계로 구성
OMT (Object Modeling Technology)	럼바우 (Rumbaugh)	- 그래픽 표기법을 이용하여 소프트웨어 구성요소를 모델링 - 분석 절차는 객체 모델링 => 동적 모델링 => 기능 모델링 순서로 진행
OOD (Object Oriented Design)	부치 (Booch)	- 설계 문서화를 강조, 다이어그램 중심 개발 방법론 - 분석과 설계의 분리가 불가능 - 분석시 이용된 객체 모델의 설계 시 적용
코드-요든 (Coad-Yourdon)		- ER 다이어그램 사용하여 객체의 행위 모델

• 객체 모델링
  • 정보 모델링
  • 객체를 찾고, 객체들 간의 관계를 정의하여 ER 다이어그램을 만드는 과정까지의 모델링
  • 객체 다이어그램 활용
• 동적 모델링
  • 시간의 흐름에 따라 객체들 사이의 제어 흐름, 동작 순서 등 동적인 행위를 표현
  • 상태 다이어그램을 활용
• 기능 모델링
  • 프로세스들의 자료 흐름을 중심으로 처리 과정 표현 모델링
  • 자료 흐름도(DFD)를 활용
• 자료 흐름도(DFD)
  • 데이터가 각 프로세스를 따라 흐르면서 변환되는 모습을 나타낸 그림

프로젝트 관리

(1) 프로젝트 관리

1. 프로젝트 관리의 개념

• 주어진 기간 내에 최소의 비용으로 사용자를 만족시키는 시스템을 개발하는 활동
• 개발 계획을 세우고 분석, 설계 구현 등의 작업을 통제하는 것
• 작업의 범위, 필요 자원, 수행 업무, 비용 추진 일정 관리

2. 프로젝트 관리 대상

• 계획 관리: 프로젝트 계획, 비용 산정, 일정 계획, 조직 계획에 대한 관리
• 품질 관리: 품질 통제 및 품질 보증
• 범위 관리: 요구사항이 프로젝트에 포함되었는지를 보장, 필요 작업만 수행되도록 관리

3. 프로젝트 관리 3대 요소

• 사람: 인적 자원
• 문제: 사용자 입장에서 문제를 분석하여 인식
• 프로세스: SW개발에 필요한 전체적인 작업 계획 및 구조

(2) 비용산정 모형

1. 비용산정 모형 분류

• 하향식 산정방법: 경험이 많은 전문가에게 비용 산정 의뢰 혹은 여러 전문가와 조정자를 통해 산정
  • 전문가 판단
  • 델파이 기법
• 상향식 산정방법: 세부적인 요구사항과 기능에 따라 필요한 비용을 계산
  • 코드 라인 수(LOC)
  • Man Month
  • COCOMO 모형
  • 푸트남 모형
  • 기능점수(FP) 모형

2. 비용산정 모형 종류

• LOC 모형
  • 원시 코드 라인 수의 낙관치, 중간치, 비용관치를 측정하여 비용 산정
• Man Month 모형
  • 한 사람이 1개월 동안 할 수 있는 일의 양을 기준으로 프로젝트 비용 산정 (Man Month = LOC / 월간 생산성)
• COCOMO 모형
  • 보헴이 제안한 모형으로 규모에 따라 비용 산정
  • 규모에 따라 유형이 조직형, 반분리형, 임베디드형으로 분류
    • 조직형: 5만 라인 이하의 소프트웨어를 개발
    • 반 분리형: 단순형과 임베디드형의 중간형, 30만 라인 이하의 소프트웨어를개발
    • 임베디드형: 30만 라인 이상의 소프트웨어를 개발
• 푸트남 모형
  • 소프트웨어 개발주기의 단계별로 요구할 인력의 분포를 가정
  • 생명주기 예측 모형
• 기능점수 모형
  • 요구 기능을 증가시키는 인자별로 가중치를 부여, 가중치를 합산하여 총 기능의 점수를 계산하여 비용을 산정

(3) 일정관리 모델

1. 일정관리 모델 종류

• 주 공정법(CPM)
  • 여러 작업의 수행 순서가 얽혀 있는 프로젝트의 일정을 계산하는 기법
  • 프로젝트 시작과 끝을 나타내는 노드와 노드 간을 연결을 통해 공정을 계산하기 위한 표기법(제약사항 배제)
• PERT
  • 일의 순서를 계획적으로 정리하기 위한 수렴 기법. 비관치, 중간치, 낙관치의 3점 추정방식을 통해 일정관리
• 중요 연쇄 프로젝트 관리(CCPM)
  • 주 공정 연쇄법으로 자원제약사항을 고려하여 일정 작성

(4) 위험 관리

1. 위험 대응 전략

회피, 전가, 완화, 수용

현행 시스템 파악

(1) 현행 시스템 파악 개념

현행 시스템 파악이란 현행 시스템의 하위 구성, 제공 기능 및 연계 정보 등 기술 요소 사용을 파악하는 활동

(2) 현행 시스템 파악 절차

1. 구성/기능/인터페이스 파악
   • 시스템 구성 현황 파악
   • 시스템 기능 파악
   • 시스템 인터페이스 현황 파악
2. 아키텍처 및 소프트웨어 구성 파악
   • 아키텍처 파악
   • 소프트웨어 구성 파악
3. 하드웨어 및 네트워크 구성 파악
   • 시스템 하드웨어 현황 파악
   • 네트워크 구성 파악

(3) 소프트웨어 아키텍처

• 소프트웨어 아키텍처 개념: 아키텍처는 여러 가지 소프트웨어 구성요소와 그 구성요소가 가진 특성 중 외부에 드러나는 특성, 그리고 구성요소 간의 관계를 표현하는 시스템의 구조나 구조체
• 소프트웨어 아키텍처 프레임워크 개념: 아키텍처가 표현해야 하는 내용 및 이들 간의 관계를 제공하는 기술 표준
  • 구성요소: 아키텍처 명세서, 이해관계자, 관심사, 관점, 뷰, 근거, 목표, 환경, 시스템
• 소프트웨어 아키텍처 4+1 뷰
  • 고객의 요구사항을 정리해 놓은 시나리오를 4개의 관점에서 바라보는 접근 방법
  • 4개의 분리 구조로 구성되는 아키텍처 개념을 제시, 이 구조들이 서로 충돌하지 않는지, 요구사항을 충족시키는지 증명하기 위해 유스케이스 사용
  • 뷰 구성요소
    • 유스케이스 뷰: 유스케이스 혹은 아키텍처를 도출하고 설계, 다른 뷰를 검증(사용자, 설계자, 개발자, 테스트 관점)
    • 논리 뷰: 시스템의 기능적인 요구사항이 어떻게 제공되는지 설명(설계자, 개발자 관점)
    • 프로세스 뷰: 시스템의 비기능적인 속성으로서 자원의 효율적 사용, 병행 실행, 비동기, 이벤트 처리 등을 표현한 뷰(개발자, 시스템 통합자 관점)
    • 구현 뷰: 개발 환경 내 정적인 소프트웨어 모듈의 구성을 보여주는 뷰
    • 배포 뷰: 컴포넌트가 물리적인 아키텍처에 어떻게 배치되는지를 매핑해서 보여주는 뷰
• 소프트웨어 아키텍처 패턴
  • 개념: 소프트웨어를 설계할 때, 참조할 수 있는 전형적인 해결 방식
  • 필요성: 고객과 의사소통을 통해 고객의 요구사항 만족, 소프트웨어 개발 생산성과 품질 확보
• 소프트웨어 아키텍처 패턴 유형

유형	설명
계층화 패턴	- 시스템을 계층으로 구분하여 구성하는 패턴 - 각 하위 모듈들은 특정 수준의 추상화를 제공, 각 계층은 다음 상위 계층에 서비스를 제공
클라이언트-서버 패턴	- 하나의 서버와 다수의 클라이언트로 구성된 패턴 - 사용자가 클라이언트를 통해 서버에 서비스요청, 서버는 클라이언트에 서비스 제공
파이프-필터 패턴	- 데이터 스트림을 생성하고 처리하는 시스템에서 사용 - 서브 시스템이 입력 데이터를 받아 처리, 결과를 다음 서브 시스템으로 넘겨주는 것을 반복
브로커 패턴	- 분리된 컴포넌트들로 이루어진 분산 시스템에서 사용 - 브로커 컴포넌트는 컴포넌트 간의 통신을 조정 - 서버가 기능을 브로커에게 전달, 클라이언트의 요청을 브로커가 레지스트리에 있는 서비스로 리다이렉션
모델-뷰-컨트롤러 패턴	- 모델, 뷰, 컨트롤러 3개의 서브 시스템으로 구조화하는 패턴 - 모델: 핵심 기능과 데이터 보관 - 뷰: 사용자에게 정보 표시 - 컨트롤러: 사용자로부터 요청을 입력받아 처리 - 컴포넌트를 분리하며, 코드의 효율적인 재사용을 가능하게 함.

• 소프트웨어 아키텍처 비용 평가 모델
  아키텍처 접근법이 품질 속성에 미치는 영향을 판단, 적합성을 평가하는 모델
• 소프트웨어 아키텍처 비용 평가 모델 종류

종류	설명
SAAM	변경 용이성과 기능성에 집중. 평가가 용이해 경험이 없는 조직에서도 활용 가능한 비용 평가 모델
ATAM	아키텍처 품질 속성을 만족시키는지 판단. 품질 속성들의 이해 상충관계까지 평가
CBAM	ATAM 기반의 시스템 아키텍처 분석 중심. 경제적 의사결에 대한 요구를 충족
ADR	아키텍처 구성요소 간 응집도를 평가
ARID	전체가 아닌 특정 부분에 대한 품질요소에 집중

(4) 디자인 패턴

소프트웨어 공학의 소프트웨어 설계에서 공통으로 발생하는 문제에 대해 자주 쓰이는 설계 방법을 정리한 패턴(효율성, 유지보수성, 운용성, 최적화)

1. 구성요소

패턴의 이름, 문제 및 배경, 솔루션, 사례, 결과, 샘플 코드

2. 디자인 패턴 유형

• 목적
  • 생성: 객체 인스턴스 생성에 관여, 클래스 정의와 객체 생성 방식을 구조화, 캡슐화
  • 구조: 더큰 구조 형성 목적, 클래스나 객체의 조합을 다루는 패턴
  • 행위: 클래스나 객체들이 상호 작용하는 방법과 역할 분담을 다루는 패턴
• 범위
  • 클래스: 클래스간 관련성(컴파일 타임에 정적으로 결정)
  • 객체: 객체 간 관련성(런타임에 동적으로 결정)

3. 디자인 패턴 종류

• 생성

패턴	설명
Builder	- 복합 객체 생성 시 객체를 생성하는 방법과 객체를 구현하는 방법을 분리 (생성과 표기를 분리)
Prototype	- 원형을 만들어 복사 후, 필요한 부분만 수정하여 사용하는 패턴. - 기존 객체를 복제하여 객체를 생성
Factory Method	- 상위 클래스에서 객체를 생성하는 인터페이스를 정의하고, 하위 클래스에서 인스턴스를 생성
Abstract Factory	- 서로 연관되거나 의존적인 객체들의 조합을 만드는 인터페이스를 제공하는 패턴 - 동일한 주제의 다른 팩토리를 묶음
Singleton	- 객체를 하나만 생성하여 어디서든 참조할 수 있도록 하는 패턴 - 한 클래스에 한 객체만 존재하도록 제

• 구조

패턴	설명
Bridge	- 기능의 클래스 계층과 구현의 클래스 계층을 연결하고, 구현부에서 추상계층을 분리하여 추상화된 부분과 실제 구현부를 독립적으로 확장 가능 - 구현뿐만 아니라 추상화된 부분도 변경해야 하는 경우 활용
Decorator	- 기존에 구현되어는 클래스에 필요한 기능을 추가해 나가는 설계 패턴 - 객체의 결합을 통해 기능을 동적으로 유연하게 확장
Facade	- 복잡한 시스템에 대해 단순한 인터페이스를 제공, 결합도를 낮추어 시스템 구조에 대한 파악을 쉽게 하는 패턴 - 통합된 인터페이스 제공
Flyweight	- 다수의 객체로 생성될 경우 모두가 갖는 본질적인 요소를 클래스 화하여 공유함으로써 메모리 절약, '경량화'를 목적 - 여러 개의 '가상 인스턴스' 제공하여 메모리 절감
Proxy	- '실체 객체에 대한 대리 객체'로 실제 객체를 드러나지 않게 하여 정보은닉의 역할도 가능 - 특정 객체로의 접근을 제어하기 위한 용도
Composite	- 객체들의 관계를 트리 구조로 구성하여 부분 - 전체 계층을 표현하는 패턴 - 복합 객체와 단일 객체를 동일하게 취급
Adapter	- 기존에 생성된 클래스를 재사용할 수 있도록 중간에서 맞춰주는 역할을 하는 인터페이스를 제공 - 인터페이스가 호환되지 않는 클래스들을 함께 이용할 수 있도록 타 클래스의 인터페이스를 기존 인터페이스에 덧씌움

• 행위

패턴	설명
Iterator	- 컬렉션 구현 방법을 노출시키지 않으면서 반복자를 사용하여 접근 가능 - 내부구조를 노출하지 않고, 복잡 객체의 원소를 순차적으로 접근 가능하게 해주는 패턴
Template Method	- 캡슐화를 통해 구조는 바꾸지 않으면서 특정 단계에서 수행하는 내역을 바꾸는 패턴 - 상위 작업의 구조를 바꾸지 않으면서 서브 클래스로 작업의 일부분을 수행
Observer	- 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들에 연락이 가고 자동으로 내용이 갱신 - 객체의 상태 변화에 따라 다른 객체의 상태도 연동
State	- 객체의 상태에 따라 행위 내용을 변경
Visitor	- 각 클래스 데이터 구조로부터 처리 기능을 분리하여 별도의 클래스를 만들고, 해당 클래스의 메서드가 각 클래스를 돌아다니며 특정 작업을 수행하도록 만듦 - 객체의 구조는 변경하지 않으면서 기능만 따로 추가하거나 확장할 때 사용
Command	- 여러 기능을 실행할 수 있는 재사용성 높은 클래스를 설계하는 패턴. 하나의 추상 클래스에 메서드를 만들어 각 명령이 들어오면 그에 맞는 서브 클래스가 선택되어 실행 - 요구사항을 객체로 캡슐화
Strategy	- 알고리즘 군을 정의하고 같은 알고리즘을 각각 하나의 클래스로 캡슐화한 다음, 필요할 때 서료 고환하여 사용 - 행위 객체를 클래스로 캡슐화해 동적으로 행위를 자유롭게 반환
Memento	- 클래스를 설계 관점에서 객체의 정보를 저장할 필요가 있을 때 적용 - Undo기능 개발
Chain of Responsibility	- 정적으로 어떤 기능에 대한 처리의 연결이 하드코딩 되어 있을 때 - 한 요청을 2개 이상의 객체에서 처

개발 기술 환경 정의

(1) 개발 기술 환경 현행 시스템 분석

• 운영체제의 개념
  • 컴퓨터 사용자와 컴퓨터 하드웨어 간의 인터페이스를 담당
• 운영체제 현행 시스템 분석
  • 품질 측면: 신뢰도, 성능
  • 지원 측면: 기술 지원, 주변 기기, 구축 비용
• 운영체제 종류 및 특징
  • PC: Windows, UNIX, Linux
  • Mobile: Android, IOS

(2) 네트워크 현행 시스템 분석

• 네트워크의 개념
  • 네트워크는 컴퓨터 장치들의 노드 간 연결을 사용하여 서로에게 데이터르 ㄹ교환할 수 있도록 하는 기술
• OSI 7계층

계층	설명	프로토콜	전송단위
응용 계층(Application)	사용자와 네트워크 간 응용서비스 연결, 데이터 생성	HTTP, FTP	데이터
표현 계층(Presentation)	데이터 형식 설정과 부호교환, 암/복호화	JPEG, MPEG
세션 계층(Session)	연결 접속 및 동기제어	SSH, TLS
전송 계층(Transport)	- 신뢰성 있는 통신 보장 - 데이터 분할과 재조립, 흐름 제어, 오류 제어, 혼잡제어 담당	TCP, UDP	세그먼트
네트워크 계층(Network)	단말기 간 데이터 전송을 위한 최적화된 경로 제공	IP, ICMP	패킷
데이터 링크(Data Link)	- 인접 시스템 간 데이터 전송, 전송오류 제어 - 동기화, 흐름제어 등의 전송 기능	이더넷	프레임
물리 계층(Physical)	0과 1의 비트 정보를 회선에 보내기 위한 전기적 신호 변환		비트

(3) DBMS 현행 시스템 분석

• DBMS의 개념
  • DBMS는 데이터베이스라는 데이터 집합을 만들고, 저장 및 관리하는 기능을 제공하는 응용프로그램
• DBMS의 기능
  • 중복제어, 접근 통제, 인터페이스 제공, 관계 표현, 샤딩/파티셔닝, 무결성 제약 조건, 백업 및 회복
• DBMS 분석 시 고려 사항
  • 가용성, 성능, 상호 호환성, 기술지원, 구축 비용

(4) 미들웨어 현행 시스템 분석

• 미들웨어 의 개념
  • 분산 컴퓨팅 환경에서 응용 프로그램과 프로그램이 운영되는 환경 간에 원만한 통신이 이루어질 수 있도록 제어해주는 소프트웨어
  • 운영체제와 소프트웨어 애플리케이션 사이에 위치
• 웹 어플리케이션 서버(WAS)의 개념
  WAS는 서버 계층에서 애플리케이션이 동작할 수 있는 환경을 제공하고 안정적인 트랜잭션 처리와 관리, 다른 이기종 시스템 애플리케이션 연동을 지원하는 서버
• 미들웨어의 현행 시스템 분석
  가용성, 성능, 기술 지원, 구축 비용