[1-2] 애플리케이션 설계

017 소프트웨어 생명 주기

---

폭포수 모델(Waterfall Model)

• 이전 단계로 돌아갈 수 없다는 전제하에 각 단계를 확실히 매듭짓고 그 결과를 철저하게 검토하여 승인 과정을 거친 후에 다음 단계를 진행하는 개발 방법론
• 보헴(Boehm)이 제시한 고전적 생명 주기 모형
• 가장 오래되고 가장 폭넓게 사용된 전통적인 소프트웨어 생명 주기 모형
• 개발 과정에서 발생하는 요구사항을 반영하기 어려움

나선형 모형(Spiral Model, 점진적 모형)

• 보헴(Boehm)이 제안한 것으로, 폭포수 모형과 프로토타입 모형의 장점에 위험 분석 기능을 추가한 모형
• 나선을 따라 돌듯이 여러 번의 소프트웨어 개발 과정을 거쳐 점진적으로 완벽한 최종 소프트웨어 개발
• '계획 수립 → 위험 분석 → 개발 및 검증 → 고객 평가' 과정의 반복

애자일의 개발 4가지 핵심 가치

• 프로세스와 도구보다는 개인과 상호작용에 더 가치를 둠
• 방대한 문서보다는 실행되는 SW에 더 가치를 둠
• 계약 협상보다는 고객과 협업에 더 가치를 둠
• 계획을 따르기보다는 변화에 반응하는 것에 더 가치를 둠

018 소프트웨어 개발 방법론

---

객체지향 방법론

• 소프트웨어를 개발할 때 기계의 부품을 조립하듯이 객체들을 조립해서 필요한 소프트웨어를 구현하는 방법론
• 절차 : 요구 분석 → 설계 → 구현 → 테스트 및 검증 → 인도

019 스크럼(Scrum) 기법

---

스크럼(Scrum) 팀

• 제품 책임자(PO; Product Owner)
  • 이해관계자들 중 개발될 제품에 대한 이해도가 높고, 요구사항을 책임지고 의사 결정할 사람
  • 주로 개발 의뢰자나 사용자가 담당
  • 이해관계자들의 의견을 종합하여 제품에 대한 요구 사항을 작성하는 주체
  • 요구사항이 담긴 백로그(Backlog) 작성 및 우선순위 지정
• 스크럼 마스터(SM; Scrum Master)
  • 스크럼 팀이 스크럼을 잘 수행할 수 있도록 객관적인 시각에서 조언을 해주는 가이드 역할
• 개발팀(DT; Development Team)
  • 제품 책임자와 스크럼 마스터를 제외한 모든 팀원
  • 개발자 외에도 디자이너, 테스터 등 제품 개발을 위해 참여하는 모든 사람이 대상

스크럼 개발 프로세스

• 제품 백로그(Product Backlog)
  • 제품 개발에 필요한 모든 요구사항(User Story)을 우선순위에 따라 나열한 목록
• 스프린트 계획 회의(Sprint Planning Meeting)
  • 제품 백로그 중 이번 스프린트에서 수행할 작업을 대상으로 단기 일정을 수립하는 것
• 스프린트(Sprint)
  • 실제 개발 작업을 진행하는 과정
  • 보통 2~4주 정도의 기간 내에서 진행
• 일일 스크럼 회의(Daily Scrum Meeting)
  • 모든 팀원이 매일 약속된 시간에 약 15분 정도의 짧은 시간동안 진행 상황을 점검
• 스프린트 검토 회의(Sprint Review)
  • 부분 또는 전체 완성 제품이 요구사항에 잘 부합되는지 사용자가 포함된 참석자 앞에서 테스팅
• 스프린트 회고(Sprint Retrospective)
  • 스프린트 주기를 되돌아보며 정해놓은 규칙을 잘 준수했는지, 개선할 점은 없는지 등을 확인하고 기록

020 XP(eXtreme Programming) 기법

---

XP(eXtreme Programming)의 개요

• 수시로 발생하는 고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상시키는 방법
• 대표적인 애자일 개발 방법론 중 하나
• 짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적인 참여를 통해 소프트웨어를 빠르게 개발하는 것이 목적
• 자동화된 테스팅 도구를 사용하여 테스트를 지속적으로 수행

XP의 핵심 가치

• 의사소통(Communication)
• 단순성(Simplicity)
• 용기(Courage)
• 존중(Respect)
• 피드백(Feedback)

XP 개발 프로세스

• 사용자 스토리(User Story)
  • 고객의 요구사항을 간단한 시나리오로 표현한 것
• 릴리즈 계획 수립(Release Planning)
  • 릴리즈 : 몇 개의 스토리가 적용되어 부분적으로 기능이 완료된 제품을 제공하는 것
• 스파이크(Spike)
  • 요구사항의 신뢰성을 높이고 기술 문제에 대한 위험을 감소시키기 위해 별도로 만드는 간단한 프로그램
• 이터레이션(Iteration)
  • 하나의 릴리즈를 더 세분화 한 단위
• 승인 검사(Acceptance Test, 인수 테스트)
  • 하나의 이터레이션 안에서 계획된 릴리즈 단위의 부분 완료 제품이 구현되면 수행하는 테스트
• 소규모 릴리즈(Small Release)
  • 릴리즈를 소규모로 하게되면, 고객의 반응을 기능별로 확인할 수 있어, 고객의 요구사항에 좀 더 유연하게 대응 가능

XP의 주요 실천 방법

• Pair Programming(짝 프로그래밍)
  • 다른 사람과 함꼐 프로그래밍을 수행함으로써 개발에 대한 책임을 공동으로 나눠 갖는 환경 조성
• Collective Ownership(공동 코드 소유)
  • 개발 코드에 대한 권한과 책임을 공동으로 소유
• Continuous Intergration(계속적인 통합)
  • 모듈 단위로 나눠서 개발된 코드들은 하나의 작업이 마무리될 때마다 지속적으로 통합됨
• Refactoring(리팩토링)
  • 프로그램 기능의 변경 없이, 단순화, 유연성 강화 등을 통해 시스템의 내부 구조를 재구성

021 요구사항 정의

---

기능 요구사항

• 시스템이 무엇을 하는지, 어떤 기능을 하는지에 대한 사항
• 시스템의 입력이나 출력으로 무엇이 포함되어야 하는지, 시스템이 어떤 데이터를 저장하거나 연산을 수행해야 하는지에 대한 사항
• 시스템이 반드시 수행해야 하는 기능
• 사용자가 시스템을 통해 제공받기를 원하는 기능

비기능 요구사항

• 성능 요구사항
  • 처리 속도 및 시간, 처리량 등의 요구 사항
• 보안 요구사항
  • 시스템의 데이터 및 기능, 운영 접근을 통제하기 위한 요구 사항
• 품질 요구사항
  • 품질 평가 대상에 대한 요구사항

요구사항 개발 프로세스

• 도출(Elicitation) → 분석(Analysis) → 명세(Specification) → 확인(Validation)

요구사항 도출(Requirement Elicitation, 요구사항 수집)

• 시스템, 사용자, 시스템 개발에 관련된 사람들이 서로 의견을 교환하여 요구사항이 어디에 있는지, 어떻게 수집할 것인지 식별하고 이해하는 과정
• 요구사항 도출 기법
  • 청취, 인터뷰, 설문, 브레인스토밍, 워크샵, 프로토타이핑, 유스케이스 등

022 요구사항 분석

---

요구사항 분석의 개요

• 소프트웨어 개발의 실제적인 첫 단계
  • 개발 대상에 대한 사용자의 요구사항을 이해하고 문서화(명세화)하는 활동
• 사용자의 요구를 정확하게 추출하여 목표 선정 → 어떤 방식으로 해결할 것인지 결정
• 사용자 요구의 타당성을 조사하고 비용과 일정에 대한 제약 설정
• 개발 대상에 대한 사용자의 요구사항 중 명확하지 않거나 모호하여 이해되지 않는 부분을 발견하고 이를 걸러내기 위한 과정
• 사용자의 요구사항은 예외가 많고 지속적으로 변함 → 열거와 구조화가 어려움
• 내용이 중복되거나 하나로 통합되어야 하는 등 서로 상충되는 요구사항이 있으면 이를 중재하는 과정
• 요구사항 분석을 위해 UML(Unified Modeling Language), 자료흐름도(DFD), 자료 사전(DD), 소단위 명세서(Mini-Spec.), 개체 관계도(ERD), 상태 전이도(STD), 제어 명세서 등의 도구 이용

자료 흐름도의 구성 요소

자료 사전의 표기 기호

기호	의미
=	자료의 정의 : ~로 구성되어 있음(is composed of)
+	자료의 연결 : 그리고(and)
( )	자료의 생략 : 생략 가능한 자료(Optional)
[ | ]	자료의 선택 : 또는(or)
{ }	자료의 반복 : Iteration of
* *	자료의 설명 : 주석(Comment)

023 요구사항 분석 CASE와 HIPO

---

자동화 도구 사용의 이점

• 표준화와 보고를 통한 문서화 품질 개선
• 데이터베이스가 모두에게 이용 가능하다는 점에서 분석자들 간의 적절한 조정
• 교차 참조도와 보고서를 통한 결함, 생략, 불일치 등의 발견 용이성
• 변경이 주는 영향 추적의 용이성
• 명세에 대한 유지보수 비용 축소

SADT

• SoftTech 사에서 개발한 구조적 분석 및 설계 도구
• 블록 다이어그램을 채택한 자동화 도구

HIPO

• 시스템의 분석 및 설계나 문서화할 때 사용되는 기법
  • 시스템 실행 과정인 입력, 처리, 출력의 기능
• 하향식 소프트웨어 개발을 위한 문서화 도구
• 기호, 도표 등을 사용하므로 보기 쉽고 이해하기도 쉬움
• 기능과 자료의 의존 관계를 동시에 표현 가능
• HIPO Chart : 시스템의 기능을 여러 개의 고유 모듈들로 분할하여 이들 간의 인터페이스를 계층 구조로 표현
• HIPO Chart 종류
  • 가시적 도표(Visual Table of Contents)
  • 총체적 도표(Overview Diagram)
  • 세부적 도표(Detail Diagram)

024 UML(Unified Modeling Language)

---

UML

• 시스템 분석, 설계, 구현 등 시스템 개발 과정에서 시스템 개발자와 고객 또는 개발자 상호간의 의사소통이 원활하게 이루어지도록 표준화한 대표적인 객체지향 모델링 언어
• 구성요소
  • 사물(Things)
  • 관계(Relationships)
  • 다이어그램(Diagram)

사물(Things)

• 모델을 구성하는 가장 중요한 기본 요소
• 다이어그램 안에서 관계가 형성될 수 있는 대상들
• 종류
  • 구조 사물
  • 행동 사물
  • 그룹 사물
  • 주해 사물

실체화(Realization) 관계

• 사물이 할 수 있거나 해야하는 기능(오퍼레이션, 인터페이스)으로 서로를 그룹화 할 수 있는 관계 표현
• 한 사물이 다른 사물에게 오퍼레이션을 수행하도록 지정하는 의미적 관계

일반화(Generalization) 관계

• 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지 표현
• ex) 차는 버스, 트럭, 택시보다 일반적인 개념이고 버스, 트럭, 택시는 차보다 구체적인 개념

구조적(정적) 다이어그램 종류

• 클래스 다이어그램
• 객체(Object) 다이어그램
• 컴포넌트 다이어그램
• 배치(Deployment) 다이어그램
• 복합체 구조(Composite Structure) 다이어그램
• 패키지 다이어그램

행위(동적) 다이어그램 종류

• 유스케이스 다이어그램
• 순차(Sequence) 다이어그램
• 커뮤니케이션 다이어그램
• 상태(State) 다이어그램
• 활동(Activity) 다이어그램
• 상호작용 개요(Interaction Overview) 다이어그램
• 타이밍 다이어그램

스테레오 타입(Stereotype)

• UML에서 표현하는 기본 기능 외에 추가적인 기능을 표현하기 위해 사용
• 길러멧(Guilemet)이라고 부르는 겹화살괄호(<< >>) 사이에 표현할 형태 기술

025 주요 UML 다이어그램

---

유스케이스 다이어그램의 구성 요소

• 시스템/시스템 범위
  • 시스템 내부에서 수행되는 기능들을 외부 시스템과 구분하기 위해 시스템 내부의 유스케이스들을 사각형으로 묶어 시스템의 범위 표현
• 액터
  • 시스템과 상호작용을 하는 모든 외부요소
  • 사람이나 외부 시스템을 의미
  • 주액터 : 시스템을 사용함으로써 이득을 얻는 대상(주로 사람)
  • 부액터(시스템 액터) : 주액터의 목적 달성을 위해 시스템에 서비스를 제공하는 외부 시스템(조직 or 기관)
• 유스케이스
  • 사용자가 보는 관점에서 시스템이 액터에게 제공하는 서비스 또는 기능을 표현한 것
• 관계(Relationship)
  • 유스케이스 다이어그램에서 관계는 액터와 유스케이스, 유스케이스와 유스케이스 사이에서 나타날 수 있음
  • 연관 관계, 포함 관계, 확장 관계, 일반화 관계 표현 가능

유스케이스 확장 관계

• 유스케이스가 특정 조건에 부합되어 유스케이스의 기능이 확장될 때 원래의 유스케이스와 확장된 유스케이스와의 관계

클래스 다이어그램 - 오퍼레이션(Operation)

• 클래스가 수행할 수 있는 동작
• 함수(Method, 메서드)라고도 함

순차 다이어그램의 개요

• 시스템이나 객체들이 메시지를 주고받으며 시간의 흐름에 따라 상호작용하는 과정을 액터, 객체, 메시지 등의 요소를 사용하여 그림으로 표현
• 시스템이나 객체들의 상호 작용 과정에서 주고받는 메시지 표현
• 수직방향 = 시간의 흐름

026 소프트 아키텍처

---

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

• 소프트웨어 아키텍처 : 소프트웨어 개발시 적용되는 원칙, 지침
  • 이해 관계자들의 의사소통 도구로 활용
• 이해하기 쉽고, 명확하게 작성
• 설계는 기본적으로 좋은 품질을 유지하면서 사용자의 비기능적 요구사항으로 나타난 제약 반영 및 기능적 요구사항을 구현하는 방법을 찾는 해결 과정
• 애플리케이션의 분할 방법과 분할된 모듈에 할당될 기능, 모듈 간의 인터페이스 등을 결정

소프트웨어 아키텍처 뷰(View)

• 유스케이스(Use Case) 뷰
  • 시스템 외부 사용자의 관점에서 사용 사례와 이들 간의 관계를 정의
  • 다른 뷰를 검증한느 용도로 사용
• 논리적(Losical) 뷰
  • 설계자의 관점에서 시스템의 기능적인 요구사항이 제공되는 방법을 설명해주는 뷰
• 구현(Implementation) 뷰
  • 개발자의 관점에서 서브 시스템 모듈이 어떻게 구조화되어 있는지를 확인하기 위해 소프트웨어 구성을 보여주는 뷰
• 프로세스(Process) 뷰
  • 시스템 통합자의 관점에서 자원의 효율적인 사용, 이벤트 처리 등을 표현한 뷰
• 배포(Deployment) 뷰
  • 테스터의 관점에서 컴포넌트가 어떻게 배치되고 연결되는지를 보여주는 뷰

모듈화

• 소프트웨어의 성능을 향상시키거나 시스템의 수정 및 재사용, 유지 관리 등이 용이하도록 시스템의 기능들을 모듈 단위로 나누는 것

추상화 유형

• 과정 추상화
• 데이터(자료) 추상화
• 제어 추상화

정보 은닉

• 한 모듈 내부에 포함된 절차와 자료들의 정보가 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법

사용성(Usability)

• 사용자가 소프트웨어를 사용하는데 헤매지 않도록 명확하고 편리하게 구현하는 것

027 아키텍처 패턴

---

아키텍처 패턴의 장점

• 시행착오를 줄여 개발 시간 단축, 고품질의 소프트웨어 생산 가능
• 검증된 구조로 개발 → 안정적인 개발 가능
• 이해관계자들이 공통된 아키텍처를 공유 → 의사소통 간편
• 시스템 구조를 이해하는 것이 쉬어 개발에 참여하지 않은 사람도 손쉽게 유지 보수 수행 가능
• 시스템의 특성을 개발 전에 에측하는 것이 가능

파이프-필터 패턴

• 데이터 스트림 절차의 각 단계를 필터(Filter) 컴포넌트로 캡슐화하여 파이프(Pipe)를 통해 데이터를 전송하는 패턴
• 필터 간 데이터 이동 시 데이터 변환으로 인한 오버헤드 발생

MVC(Modle-View-Controller) 패턴

• 모델(Model)
  • 서브시스템의 핵심 기능과 데이터를 보관함
• 뷰(View)
  • 사용자에게 정보를 표시함
• 컨트롤러(Controller)
  • 사용자로부터 입력된 변경 요청 을 처리하기 위해 모델에게 명령을 보냄

마스터-슬레이브 패턴

• 동일한 구조의 슬레이브 컴포넌트로 작업을 분할한 후, 슬레이브 컴포넌트에서 처리된 결과물을 다시 돌려받는 방식으로 작업 수행
• 마스터 컴포넌트는 모든 작업의 주체, 슬레이브 컴포넌트는 마스터 컴포넌트의 지시에 따라 작업을 수행하여 결과 반환
• 장애 허용 시스템과 병렬 컴퓨팅 시스템에서 주로 활동

028 객체지향(Object-Oriented)

---

객체(Object)

• 데이터와 데이터를 처리하는 함수를 묶어놓어 놓은(캡슐화환) 하나의 소프트웨어 모듈

메시지(Message)

• 객체들 간에 상호작용을 하는 데 사용되는 수단
• 객체에게 어떤 행위를 하도록 지시하는 명령 또는 요구사항

클래스(Class)

• 공통된 속성과 연산(행위)을 갖는 객체의 집합
• 객체의 일반적인 타입(Type) 의미
• 클래스에 속한 각각의 객체를 인스턴스(Instance)라고 함

캡슐화(Encapsulation)

• 데이터(속성)와 데이터를 처리하는 함수를 하나로 묶은 것
• 캡슐화된 객체는 외부 모듈의 변경으로 인한 파급 효과가 적음
• 인터페이스 단순화
• 객체 간의 결합도 낮아짐

상속(Inheritance)

• 이미 정의된 상위 클래스(부모 클래스)의 모든 속성과 연산을 하위 클래스(자식 클래스)가 물려받는 것

다형성(Polymorphism)

• 메시지에 의해 객체(클래스)가 연산을 수행하게 될 때 하나의 메시지에 대해 각각의 객체(클래스)가 가지고 있는 고유한 방법(특성)으로 응답할 수 있는 능력 의미
• 오버로딩(Overloading)
  • 메서드(Method)의 이름은 같지만 인수를 받는 자료형과 개수를 달리하여 여러 기능 정의 가능
• 오버라이딩(Overriding, 메서드 재정의)
  • 상위 클래스에서 정의한 메소드(Method)와 이름은 같지만 메소드 안의 실행 코드를 달리하여 자식 클래스에서 재정의해서 사용 가능

#029 객체지향 분석 및 설계

객체지향 분석 방법론 - Coad와 Yourdon 방법

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

럼바우(Rumbaugj) 분석 기법

• 객체(Object) 모델링
  • 정보 모델링
  • 시스템에서 요구되는 객체를 찾아내어 속성과 연산 식별 및 객체들 간의 관계를 규정하여 객체 다이어그램으로 표시하는 것
• 동적(Dynamic) 모델링
  • 상태 다이어그램(상태도)을 이용하여 시간의 흐름에 따른 객체들 간의 제어 흐름, 상호 작용, 동작 순서 등의 동적인 행위를 표현하는 모델링
• 기능(Functional) 모델링
  • 자료 흐름도(DFD)를 이용하여 다수의 프로세스들 간의 자료 흐름을 중심으로 처리 과정을 표현

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

• 단일 책임 원칙(SRP; Single Responsibility Principla)
  • 객체는 단 하나의 책임만 가져야 한다
  • 응집도는 높고, 결합도는 낮게 설계하는 것
• 개방-폐쇄 원칙(OCP; Open-Closed Principle)
  • 기존의 코드를 변경하지 않고 기능을 추가할 수 있도록 설계해야 한다는 원칙
  • 공통 인터페이스를 하나의 인터페이스로 묶어 캡슐화 하는 방법이 대표적
• 리스코프 치환 원칙(LSP; Liskov Substitution Principle)
  • 자식 클래스는 최소한 자신의 부모 클래스에서 가능한 행위는 수행할 수 있어야 한다는 설계 원칙
  • 자식 클래스는 부모 클래스의 책임을 무시하거나 재정의하지 않고 확장만 수행
• 인터페이스 분리 원칙(ISP; Interface Segregation Principle)
  • 자신이 사용하지 않는 인터페이스와 의존 관계를 맺거나 영향을 받지 않아야 한다는 원칙
  • 단일 책임 원칙이 객체가 갖는 하나의 책임이라면, 인터페이느 분리 원칙은 인터페이스가 갖는 하나의 책임임
• 의존 역전 원칙(DIP; Dependecy Inversion Principle)
  • 각 객체들 간의 의존 관계가 성립될 때, 추상성이 낲은 클래스보다 추상성이 높은 그래드와 의존 관계를 맺어야 함
  • 일반적으로 인터페이스를 활용하면 이 원칙은 준수됨

030 디자인 패턴

---

디자인 패턴

• 각 모듈의 세분화된 역할이나 모듈들 간의 인터페이스와 같은 코드를 작성하는 수준의 세부적인 구현 방안을 설계할 때 참조할 수 있는 전형적인 해결 방식 또는 예제
• 디자인 패턴 유형
  • 생성 패턴, 구조 패턴, 행위 패턴

디자인 패턴 사용의 장단점

• 범용적인 코딩 스타일 → 구조 파악 용이함
• 객체지향 설계 및 구현의 생산성 높이는 데 적합
• 검증된 구조의 재사용 → 개발 시간 및 비용 절약
• 초기 투자 비용 부담
• 개발자 간의 원활한 의사소통 가능

생성 패턴(Creational Pattern)

• 추상 팩토리(Abstract Factory)
  • 구체적인 클래스에 의존하지 않고, 인터페이스를 통해 서로 연관/의존하는 객체들의 그룹으로 생성하여 추상적으로 표현
• 빌더(Builder)
  • 작게 분리된 인스턴스를 건축하듯이 조합하여 객체 생성
• 팩토리 메서드(Factory Method)
  • 객체 생성을 서브 클래스에서 처리하도록 분리하여 캡슐화한 패턴
  • 상위 클래스에서 인터페이스만 정의하고 실제 생성은 서브 클래스가 담당함
  • 가상 생성자(Virtual Constructor) 패턴
• 프로토타입(Prototype)
  • 원본 객체를 복제하는 방법 → 객체를 생성하는 패턴
• 싱글톤(Singleton)
  • 하나의 객체를 생성하면 생성된 객체를 어디서든 참조 가능
  • 단, 여러 프로세스가 동시에 참조할 수 X

구조 패턴(Structural Pattern)

• 어댑터(Adapter)
  • 호환성이 없는 클래스들의 인터페이스가 다른 클래스가 이용할 수 있도록 변환해주는 패턴
• 브리지(Bridge)
  • 구현부에서 추상층을 분리 → 서로가 독립적으로 확장할 수 있도록 구성한 패턴
• 컴포지트(Composite)
  • 여러 객체를 가진 복합 객체와 단일 객체를 구분 없이 다루고자 할 대 사용하는 패턴
• 데코레이터(Decorator)
  • 객체 간의 결합을 통해 능동적으로 기능들을 확장할 수 있는 패턴
  • 임의의 객체에 부가적인 기능을 추가하기 위해 다른 객체들을 덧붙이는 방식으로 구현
• 퍼싸드(Facasde)
  • 복잡한 서브 클래스들을 피해 더 상위에 인터페이스를 구성 → 서브 클래스들의 기능을 간편하게 사용
• 플라이웨이트(Flyweight)
  • 인스턴스가 필요할 때마다 매번 생성하는 것이 아니고 가능한 한 공유해서 사용함으로서 메모리를 절약하는 패턴
• 프록시(Proxy)
  • 접근이 어려운 객체와 여기에 연결하려는 객체 사이에서 인터페이스 역할을 수행하는 패턴

행위 패턴(Behavioral Pattern)

• 책임 연쇄(Chain of Responsibility)
  • 요청을 처리할 수 있는 객체가 둘 이상 존재하여 한 객체가 처리하지 못하면 다음 객체로 넘어가는 형태의 패턴
• 커맨드(Command)
  • 요청을 객체의 형태로 캡슐화하여 재이용하거나 취소할 수 있도록 요청에 필요한 정보를 저장하거나 로그에 남기는 패턴
• 인터프리터(Interpreter)
  • 언어에 문법 표현을 정의하는 패턴
  • SQL or 통신 프로토콜과 같은 것을 개발할 때 사용
• 반복자(Iterator)
  • 자료 구조와 같이 접근이 잦은 객체에대해 동일한 인터페이스를 사용하도록 하는 패턴
• 중재자(Memento)
  • 특정 시점에서의 객체 내부 상태를 객체화함으로써 이후 요청에 따라 객체를 해당 시점의 상태로 돌릴 수 있는 기능 제공
  • Ctrl + z 같은 되돌리기 기능 개발시 주로 이용
• 옵서버(Observer)
  • 한 객체의 상태가 변화하면 객체에 상속되어 있는 다른 객체들에게 변화된 상태를 전달하는 패턴
• 상태(State)
  • 객체의 상태에 따라 동일한 동작을 다르게 처리해야 할 때 사용하는 패턴
• 전략(Strategy)
  • 동일한 계열의 알고리즘들을 개별적으로 캡슐화 → 상호 교환 할 수 있게 정의하는 패턴
• 템플릿 메소드(Template Method)
  • 상위 클래스에서 골격을 정리하고, 하위 클래스에서 세부처리를 구체화하는 구조의 패턴
• 방문자(Visitor)
  • 각 클래스들의 데이터 구조에서 처리 가능을 분리하여 별도의 클래스로 구성하는 패턴