CERTIFICATION/IEIP
[1-2] 애플리케이션 설계
써머레인
2024. 5. 17. 01:05
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)
- 각 클래스들의 데이터 구조에서 처리 가능을 분리하여 별도의 클래스로 구성하는 패턴