소프트웨어 설계

💐 스크럼(Scrum)

• 스크럼은 제품 책임자(Product Owner), 스크럼 마스터(Scrum Master), 개발팀(Development Team)으로 구성된다.
• 스프린트 회고를 통해 개선할 점은 없는지 등을 확인하고 기록한다.
  -스프린트는 실제 개발 작업을 진행하는 과정으로 보통 1~4주 정도의 기간 내에서 진행한다.
• 스프린트 진행 상황을 점검하기 위한 스크럼 회의는 월 단위가 아니라 매일 진행하는데, 이를 일일 스크럼 회의(Daily Scrum Meeting)

스크럼의 개요

스크럼이란 럭비에서 반칙으로 경기가 중단된 경우 양 팀의 선수들이 럭비공을 가운데 두고 상대팀을 밀치기 위해 서로 대치해 있는 대형을 말한다. 스크럼은 이처럼 팀이 중심이 되어 개발의 효율성을 높인다는 의미가 내포된 용어이다.

• 스크럼은 팀원 스스로가 스크럼 팀을 구성(self-organizing)해야 하며, 개발 작업에 관한 모든 것을 스스로 해결(cross-functional)할 수 있어야 한다.

<스크럼 팀>

• 제품 책임자(PO : Product Owner)
  -이해관계자들 중 개발될 제품에 대한 이해도가 높고, 요구사항을 책임지고 의사 결정할 사람으로 선정하는데, 주로 개발 의뢰자나 사용자가 담당한다.
  -이해관계자들의 의견을 종합하여 제품에 대한 요구사항을 작성하는 주체다.
  -제품에 대한 테스트를 수행하면서 주기적으로 요구사항의 우선순위를 갱신한다.
• 스크럼 마스터(SM : Scrum Master)
  -스크럼 팀이 스크럼을 잘 수행할 수 있도록 객관적인 시각에서 조언을 해주는 가이드 역할을 수행한다. 팀원들을 통제하는 것이 목표가 아니다.
  -일일 스크럼 회의를 주관하여 진행 사항을 점검하고, 개발 과정에서 발생된 장애 요소를 공론화하여 처리한다.
• 개발팀(DT : Development Team)
  -제품 책임자와 스크럼 마스터를 제외한 모든 팀원으로, 개발자 외에도 디자이너, 테스터 등 제품 개발을 위해 참여하는 모든 사람이 대상이 된다.
  -보통 최대인원은 7~8명이 적당하다.

스크럼 개발 프로세스

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

🌸비기능 요구사항

🔹은행의 조회, 입금, 출금, 이체 등이 어떻게 수행되는지 여부
-> 시스템이 수행해야하는 기능 요구사항

🔹처리 속도 및 시간, 처리량 등의 성능에 대한 요구사항
🔹"차량 대여 시스템에서 제공하는 모든 화면은 3초 안에 사용자에게 보여야 한다"는 것
-> 성능에 관한 비기능 요구사항

🔹보안 및 접근 통제를 위한 요구사항
-> 보안에 관한 비기능 요구사항

💮자료 흐름도(DFD)

• 자료 흐름은 처리(Process)를 거쳐 변환될 때마다 새로운 이름을 부여한다.

• 어떤 처리(Process)가 출력 자료를 산출하기 위해서는 반드시 입력 자료가 발생해야 한다.

• 상위 단계의 처리(Process)와 하위 자료 흐름도의 자료흐름은 서로 일치되어야 한다.

• 자료 저장소의 입력 화살표는 데이터의 입력 및 수정을 의미하는 것으로, 입력 화살표가 있다고 하여 반드시 출력 화살표가 있어야 하는 것은 아니다.

🌹UML의 구성요소

1. 관계(Relation-ships)
관계는 사물과 사물 사이의 연관성을 표현하는 것

• 연관(Association)관계
  연관 관계는 2개 이상의 사물이 서로 관련되어 있음을 표현한다.
• 집합(Aggregation)관계
  집합 관계는 하나의 사물이 다른 사물에 포함되어 있는 관계를 표현한다.
• 포함(Composition)관계
  포함 관계는 집합 관계의 특수한 형태로, 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계를 표현한다.
• 일반화(Generalization)관계
  일반화 관계는 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지를 표현한다.
• 의존(Dependency)관계
  의존 관계는 연관 관계와 같이 사물 사이에 서로 연관은 있으나 필요에 의해 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계를 표현한다.
  -일반적으로 한 클래스가 다른 클래스를 오퍼레이션의 매개 변수로 사용하는 경우에 나타나는 관계이다.
• 실체화(Realization)관계
  실체화 관계는 사물이 할 수 있거나 해야 하는 기능(행위, 인터페이스)으로 서로를 그룹화 할 수 있는 관계를 표현한다.

2. 다이어그램(Diagram)

3. 사물(Things)
모델을 구성하는 가장 중요한 기본 요소로, 다이어그램 안에서 관계가 형성될 수 있는 대상들을 말한다.

• 구조 사물(Structural Things)
  시스템의 개념적, 물리적 요소를 표현한다.
  -클래스(class)
  -유스케이스(Use Case)
  -컴포넌트(Component)
  -노드(Node)

• 행동 사물(Behavioral Things)
  시간과 공간에 따른 요소들의 행위를 표현한다.
  -상호작용(Interaction)
  -상태머신(StateMachine)

• 그룹 사물(Grouping Things)
  요소들을 그룹으로 묶어서 표현한다.
  -패키지(Package)

• 주해 사물(Annotation Things)
  부가적인 설명이나 제약조건 등을 표현한다.
  -노트(Note)

🥀다이어그램

<구조적다이어그램 - 정적>

• 클래스 다이어그램 : 클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현한 다이어그램

<행위다이어그램 - 동적>

• 순차(Sequence) 다이어그램 : 상호 작용하는 시스템이나 객체들이 주고받는 메시지를 표현하는 다이어그램
• 상태(State) 다이어그램 : 하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 다른 객체와의 상호 작용에 따라 상태가 어떻게 변하는지를 표현하는 다이어그램
• 활동 다이어그램 : 오퍼레이션이나 처리 과정이 수행되는 동안 일어나는 일들을 단계적으로 표현한 다이어그램

🌺UML 다이어그램

다이어그램은 사물과 관계를 도형으로 표현한 것

• 여러 관점에서 시스템을 가시화한 뷰(View)를 제공함으로써 의사소통에 도움을 준다.
• 정적 모델링에서는 주로 구조적 다이어그램을 사용하고 동적 모델링에서는 주로 행위 다이어그램을 사용한다.

🔹 구조적(Structural) 다이어그램의 종류 -정적

• 클래스 다이어그램(Class Diagram)
  -클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현함
  -시스템의 구조를 파악하고 구조상의 문제점을 도출할 수 있음

• 객체 다이어그램(Object Diagram)
  -클래스에 속한 사물(객체)들, 즉 인스턴스(Instance)를 특정 시점의 객체와 객체사이의 관계로 표현함
  -럼바우(Rumbaugh)객체지향 분석 기법에서 객체 모델링에 활용됨

• 컴포넌트 다이어그램(Component Diagram)
  -실제 구현 모듈인 컴포넌트 간의 관계나 컴포넌트 간의 인터페이스를 표현함
  -구현 단계에서 사용되는 다이어그램

• 배치 다이어그램(Deployment Diagram)
  -결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치를 표현함
  -노드와 의사소통(통신) 경로로 표현함
  -구현 단계에서 사용되는 다이어그램

• 복합체 구조 다이어그램(Composite Structure Diagram)
  클래스나 컴포넌트가 복합 구조를 갖는 경우 그 내부 구조를 표현함

• 패키지 다이어그램(Package Diagram)
  유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계를 표현함

🔹 행위(Behavioral) 다이어그램의 종류 - 동적

• 유스케이스 다이어그램(Use Case Diagram)
  -사용자의 요구를 분석하는 것으로 기능 모델링 작업에 사용함
  -사용자(Actor)와 사용 사례(Use Case)로 구성되며, 사용 사례 간에는 여러 형태의 관계로 이루어짐

• 순차 다이어그램(Sequence Diagram)
  상호 작용하는 시스템이나 객체들이 주고받는 메시지를 표현함

• 커뮤니케이션 다이어그램(Communication Diagram)
  순차 다이어그램과 같이 동작에 참여하는 객체드링 주고받는 메시지를 표현하는데, 메시지뿐만 아니라 객체들 간의 연관까지 표현함

• 상태 다이어그램(State Diagram)
  -하나의 객체가 자신이 속한 클래스의 상태변화 혹은 다른 객체와의 상호 작용에 따라 상태가 어떻게 변화하는지를 표현함
  -럼바우(Rumbaugh) 객체지향 분석 기법에서 동적 모델링에 활용됨

• 활동 다이어그램(Activity Diagram)
  -시스템이 어떤 기능을 수행하는지 객체의 처리 로직이나 조건에 따른 처리의 흐름을 순서에 따라 표현함

• 상호작용 개요 다이어그램(Interaction Overview Diagram)
  상호작용 다이어그램 간의 제어 흐름을 표현함

• 타이밍 다이어그램(Timing Diagram)
  객체 상태 변화와 시간 제약을 명시적으로 표현함

🌻순차 다이어그램(Sequence Diagram)

• 주로 동적인 측면에서 모델링을 설계하기 위해 사용
• 시간의 흐름에 따라 객체들이 주고 받는 메시지의 전달 과정을 강조한다.
• 수직 방향이 시간의 흐름을 나타낸다.
• 구성 요소에는 회귀 메시지, 제어 블록 등이 있다.

🌼UI 설계 도구

• 목업(Mockup)
  -디자인, 사용 방법 설명, 평가 등을 위해 실제 화면과 유사하게 만든 정적인 형태의 모형
  -시각적으로만 구성 요소를 배치하는 것으로 일반적으로 실제로 구현되지는 않음

• 스토리보드
  와이어프레임에 콘텐츠에 대한 설명, 페이지 간 이동 흐름 등을 추가한 문서

• 프로토타입
  와이어프레임이나 스토리보드 등에 인터랙션을 적용함으로써 실제 구현된 것처럼 테스트가 가능한 동적인 형태의 모형

• 유스케이스
  -사용자 측면에서의 요구사항

🌷협약(Contract)에 의한 컴포넌트 설계

1) 컴포넌트의 오퍼레이션 사용 전에 참이 되어야 할 선행조건
2) 사용 후 만족되어야 할 결과조건
3) 오퍼레이션이 실행되는 동안 항상 만족되어야 할 불변조건 등이 포함되어야 한다.

🌱MVC(Model-View-Controller)

모델-뷰-컨트롤러 패턴 (Model-View-Controller Pattern) : 서브시스템을 3개의 부분으로 구조화하는 패턴이며, 각 부분의 역할은 다음과 같다.

• 모델 (Model) : 서브시스템의 핵심 기능과 데이터를 보관함
• 뷰(View) : 사용자에게 정보를 표시함
• 컨트롤러(Controller) : 사용자로부터 받은 입력을 처리하며, 처리 결과에 따라 모델의 상태를 갱신함

서로 영향을 받지 않고 개발 작업을 수행할 수 있으며 여러 개의 뷰를 만들 수 있으므로 한 개의 모델에 대해 여러 개의 뷰를 필요로 하는 대화형 애플리케이션에 적합하다.

🌲명령

• Message : 객체에게 어떤 행위를 하도록 지시하는 명령
• Class : 공통된 속성과 연산(행위)을 갖는 객체의 집합으로, 객체의 일반적인 타입(Type)
• Instance : 클래스에 속한 각각의 객체
• Object : 데이터와 데이터를 처리하는 함수를 묶어 놓은(캡슐화한) 하나의 소프트웨어

🌳객체지향 소프트웨어 특성

• 메소드 오버라이딩 : 상위 클래스에서 정의한 메소드와 이름은 같지만 메소드안의 실행 코드를 달리하여 자식 클래스에서 재정의해서 사용하는 것을 말합니다. 이와 같이 하나의 메시지에 대해 각각의 객체가 가지고 있는 고유한 방법(특성)으로 응답할 수 있는 능력을 다형성(Polymorphism)이라고 합니다.
• 추상화 : 불필요한 부분을 생략하고 객체의 속성 중 가장 중요한 것에만 중점을 두어 개략화하는 것으로, 이와 관련된 객체지향 소프트웨어의 요소는 클래스 입니다.
• 캡슐화 : 데이터와 데이터를 처리하는 함수를 하나로 묶은 것을 캡슐화라고 한다.
• 상속 : 이미 정의된 상위 클래스의 모든 속성과 연산을 하위 클래스가 물려받는 것을 상속이라고 한다.
• 정보은닉 : 한 모듈 내부에 포함된 절차와 자료들의 정보가 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법을 은닉이라고 한다.

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

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

🌵결합도(Coupling)

• 결합도는 모듈 간에 상호 의존하는 정도 또는 두 모듈 사이의 연관 관계를 의미한다.
• 다양한 결합으로 모듈을 구성할 수 있으나 결합도가 약할수록 품질이 높고, 강할수록 품질이 낮다.
• 결합도가 강하면 시스템 구현 및 유지보수 작업이 어렵다.

🌾결합도의 종류

• 자료 결합도(Data Coupling) : 모듈 간의 인터페이스가 자료 요소로만 구성될 때의 결합도
• 스탬프(검인) 결합도(Stamp Coupling) : 모듈 간의 인터페이스로 배열이나 레코드 등의 자료 구조가 전달될 때의 결합도
• 제어 결합도(Control Coupling) : 어떤 모듈이 다른 모듈 내부의 논리적인 흐름을 제어하기 위해 제어 신호를 이용하여 통신하거나 제어 요소(Function Code, Switch, Tag, Flag)를 전달하는 결합도
• 외부 결합도(External Coupling) : 어떤 모듈에서 외부로 선언한 데어터(변수)를 다른 모듈에서 참조할 때의 결합도
• 공통(공유) 결합도(Common Coupling) : 공유되는 공통 데이터 영역을 여러 모듈이 사용할 때의 결합도
• 내용 결합도(Content Coupling) : 한 모듈이 다른 모듈의 내부 기능 및 그 내부 자료를 직접 참조하거나 수정할 때의 결합도

🌿결합도 단계 (약한 -> 강한)

Data ➡ Stamp ➡ Control ➡ Common ➡ Content
자료 ➡ 스탬프(검인) ➡ 제어 ➡ 공통(공유) ➡ 내용

🍀코드

• 표의 숫자 코드 : 코드화 대상 항목의 중량, 면적, 용량 등의 물리적 수치를 이용하여 만든 코드
• 순차 코드(Sequence) : 자료의 발생순서, 크기순서 등 일정 기준에 따라서 최초의 자료부터 차례로 일련번호를 부여하는 방법
• 10진 코드(Decimal Code) : 코드화 대상 항목을 0~9까지 10진 분할하고, 다시 그 각각에 대하여 10진 분할하는 방법을 필요한 만큼 반복하는 방법
• 블록 코드(Block Code) : 코드화 대상 항목 중에서 공통성이 있는 것끼리 블록으로 구분하고, 각 블록 내에서 일련번호를 부여하는 방법

🍁디자인 패턴(Design Pattern)

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

• 디자인 패턴을 문제 및 배경, 실제 적용된 사례, 재사용이가능한 샘플 코드 등으로 구성되어 있다.
• '바퀴를 다시 발명하지 마라(Don't reinvent the wheel)'라는 말과 같이, 개발 과정 중에 문제가 발생하면 새로 해결책을 구상하는 것보다 문제에 해당하는 디자인 패턴을 참고하여 적용하는 것이 더 효율적이다.
• GoF의 디자인 패턴은
  생성 패턴 5개
  구조 패턴 7개
  행위 패턴 11개
  총 23개의 패턴

🍂디자인 패턴 사용의 장단점

<장점>

• 범용적인 코딩 스타일로 인해 구조 파악이 용이하다.
• 객체지향 설계 및 구현의 생산성을 높이는 데 적합하다.
• 검증된 구조의 재사용을 통해 개발 시간과 비용이 절약된다.
• 개발자 간의 원활한 의사소통이 가능하다.
• 설계 변경 요청에 대한 유연한 대처가 가능하다.

<단점>

• 객체지향을 기반으로 한 설계와 구현을 다루므로 다른 기반의 애플리케이션 개발에는 적합하지 않다.
• 초기 투자 비용이 부담될 수 있다

🍃생성 패턴(Creational Pattern)

생성 패턴은 객체의 생성과 참조 과정을 캡슐화 하여 객체가 생성되거나 변경되어도 프로그램의 구조에 영향을 크게 받지 않도록 하여 프로그램에 유연성을 더해 준다.

1. 추상팩토리(Abstract Factory)

• 구체적인 클래스에 의존하지 않고, 인터페이스를 통해 서로 연관, 의존 하는 객체들의 그룹으로 생성하여 추상적으로 표현함
• 연관된 서브 클래스를 묶어 한 번에 교체하는 것이 가능함

2. 빌더(Builder)

• 작게 분리된 인스턴스를 건축 하듯이 조합하여 객체를 생성함
  -객체의 생성 과정과 표현 방법을 분리하고 있어, 동일한 객체 생성에서도 서로 다른 결과를 만들어 낼 수 있음

3. 팩토리 메소드(Factory Method)

• 객체 생성을 서브 클래스에서 처리하도록 분릭하여 캡슐화한 패턴
• 상위 클래스에서 인터페이스만 정의하고 실제 생성은 서브 클래스가 담당함
• 가상 생성자(Virtual Constructor)패턴이라고도 함

4. 프로토타입(Prototype)

• 원본 객체를 복제하는 방법으로 객체를 생성하는 패턴
• 일반적인 방법으로 객체를 생성하며, 비용이 큰 경우 주로 이용함

5. 싱글톤(Singleton)

• 하나의 객체를 생성하면 생성된 객체를 어디서든 참조할 수 있지만, 여러 프로세스가 동시에 참조할 수는 없음
• 클래스 내에서 인스턴스가 하나뿐임을 보장하며, 불필요한 메모리 낭비를 최소화 할 수 있음

💐구조 패턴(Structural Pattern)

구조패턴은 클래스나 객체들을 조합하여 더 큰 구조로 만들 수 있게 해주는 패턴으로 구조가 복잡한 시스템을 개발하기 쉽게 도와준다

1. 어댑터(Adapter)

• 호환성이 없는 클래스들의 인터페이스를 다른 클래스가 이용할 수 있도록 변환해주는 패턴
• 기존의 클래스를 이용하고 싶지만 인터페이스가 일치하지 않을 때 이용함

2. 브리지(Bridge)

• 구현부에서 추상층을 분리하여, 서로가 독립적으로 확장할 수 있도록 구성한 패턴
• 기능과 구현을 두 개의 별도 클래스로 구현함

3. 컴포지트(Composite)

• 여러 객체를 가진 복합 객체와 단일 객체를 구분없이 다루고자 할 때 사용하는 패턴
• 객체들을 트리 구조로 구성하여 디렉터리 안에 디렉터리가 있듯이 복합 객체 안에 복합 객체가 포함되는 구조를 구현할 수 있음

4. 데코레이터(Decorator)

• 객체 간의 결합을 통해 능동적으로 기능들을 확장할 수 있는 패턴
• 임의의 객체에 부가적인 기능을 추가하기 위해 다른 객체들을 덧붙이는 방식으로 구현함

5. 퍼싸드(Facade)

• 복잡한 서브 클래스들을 피해 더 상위에 인터페이스를 구성함으로써 서브 클래스들의 기능을 간편하게 사용할 수 있도록 하는 패턴
• 서브 클래스들 사이의 통합 인터페이스를 제공하는 Wrapper 객체가 필요함

6. 플라이웨이트(Flyweight)

• 인스턴스가 필요할 때마다 매번 생성하는 것이 아니고 가능한 한 공유해서 사용함으로써 메모리를 절약하는 패턴
• 다수의 유사 객체를 생성하거나 조작할 때 유용하게 사용할 수 있음

7. 프록시(Proxy)

• 접근이 어려운 객체와 여기에 연결하려는 객체사이에서 인터페이스 역할을 수행하는 패턴
• 네트워크 연결, 메모리의 대용량 객체로의 접근 등에 주로 이용함

🌸행위 패턴(Behavioral Pattern)

행위 패턴은 클래스나 객체들이 서로 상호작용하는 방법이나 책임 분배 방법을 정의하는 패턴으로 총 11개의 패턴이있다. 하나의 객체로 수행할 수 없는 작업을 여러 객체로 분배하면서 결합도를 최소화 할 수 있도록 도와준다.

1. 책임 연쇄(Chain of Responsi-bility)

• 요청을 처리할 수 있는 객체가 둘 이상 존재하여 한 객체가 처리하지 못하면 다음 객체로 넘어가는 형태의 패턴
• 요청을 처리할 수 있는 각 객체들이 고리(Chain)로 묶여 있어 요청이 해결될 때까지 고리를 따라 책임이 넘어감

2. 커맨드(Command)

• 요청을 객체의 형태로 캡슐화하여 재이용하거나 취소할 수 있도록 요청에 필요한 정보를 저장하거나 로그에 남기는 패턴
• 요청에 사용되는 각종 명령어들을 추상 클래스와 구체 클래스로 분리하여 단순화함

3. 인터프리터(Interpreter)

• 언어에 문법 표현을 정의하는 패턴
• SQL이나 통신 프로토콜과 같은 것을 개발할 때 사용함

4. 반복자(Iterator)

• 자료 구조와 같이 접근이 잦은 객체에 대해 동일한 인터페이스를 사용하도록 하는 패턴
• 내부 표현 방법의 노출 없이 순차적인 접근이 가능함

5. 중재자(Mediator)

• 수많은 객체들 간의 복잡한 상호작용(Interface)을 캡슐화하여 객체로 정의하는 패턴
• 객체 사이의 의존성을 줄여 결합도를 감소시킬 수 있음

6. 메멘토(Memento)

• 특정 시점에서의 객체 내부 상태를 객체화함으로써 이후 요청에 따라 객체를 해당 시점의 상태로 돌릴 수 있는 기능을 제공하는 패턴
• Ctrl + Z 와 같은 되돌리기 기능을 개발할 때 주로 이용함

7. 옵서버(Observer)

• 한 객체의 상태가 변화하면 객체에 상속되어 있는 다른 객체들에게 변화된 상태를 전달하는 패턴
• 주로 분산된 시스템 간에 이벤트를 생성, 발행(Publich)하고, 이를 수신(Subscribe)해야 할 때 이용함

8. 상태(State)

• 객체의 상태에 따라 동일한 동작을 다르게 처리해야 할 때 사용하는 패턴
• 객체 상태를 캡슐화하고 이를 참조하는 방식으로 처리함

9. 전략(Strategy)

• 동일한 계열의 알고리즘들을 개별적으로 캡슐화하여 상호 교환할 수 있게 정의하는 패턴
• 클라이언트는 독립적으로 원하는 알고리즘을 선택하여 사용할 수 있으며, 클라이언트에 영향 없이 알고리즘의 변경이 가능함

10. 템플릿 메소드(Template Method)

• 상위 클래스에서 골격을 정의하고, 하위 클래스에서 세부 처리를 구체화하는 구조의 패턴
• 유사한 서브 클래스를 묶어 공통된 내용을 상위 클래스에서 정의함으로써 코드의 양을 줄이고 유지보수를 용이하게 해줌

11. 방문자(Visitor)

• 각 클래스들의 데이터 구조에서 처리 기능을 분리하여 별도의 클래스로 구성하는 패턴
• 분리된 처리 기능은 각 클래스를 방몬(Visit)하여 수행함

💮미들웨어(Middleware)

미들웨어는 미들(Middle)과 소프트웨어(Software)의 합성어로, 운영체제와 응용 프로그램, 또는 서버와 클라이언트 사이에서 다양한 서비스를 제공하는 소프트웨어이다.

1. DB(DataBase)

• DB는 데이터베이스 벤더에서 제공하는 클라이언트에서 원격의 데이터베이스와 연결하기 위한 미들웨어
• DB를 사용하여 시스템을 구축하는 경우 보통 2-Tier 아키텍처라고 함

2. RPC(Remote Procedure Call)
   PRC(원격 프로시저 호출)는 응용 프로그램의 프로시저를 사용하여 원격 프로시저를 마치 로컬 프로시저처럼 호출하는 방식의 미들웨어

3. MOM(Message Oriented Middleware)

• MOM(메시지 지향 미들웨어)은 메시지 기반의 비동기형 메시지를 전달하는 방식의 미들웨어
• 온라인 업무보다는 이기종 분산 데이터 시스템의 데이터 동기를 위해 많이 사용됨

4. TP-Monitor(Transaction Processing Monitor)

• TP-Monitor(트랜잭션 처리 모니터)는 항공기나 철도 예약 업무 등과 같은 온라인 트랜잭션 업무에서 트랜잭션을 처리 및 감시하는 미들웨어
• 사용자 수가 증가해도 빠른 응답 속도를 유지해야 하는 업무에 주로 사용됨

5. ORB(Object Request Broker)

• ORB(객체 요청 브로커)는 객체 지향 미들웨어로 코바(CORBA) 표준 스펙을 구현한 미들웨어
• 최근에는 TP-Monitor의 장점인 트랜잭션 처리와 모니터링 등을 추가로 구현한 제품도 이음

6. WAS(Web Application Server)

• WAS(웹 애플리케이션 서버)는 정적인 콘텐츠를 처리하는 웹 서버와 달리 사용자의 요구에 따라 변하는 동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어
• 클라이언트/서버 환경보다는 웹 환경을 구현하기 위한 미들웨어

🌹소프트웨어 설계시 구축된 플랫폼의 성능 특성 분석 측정

• 응답시간(Response Time) : 요청을 전달한 시간부터 응답이 도착할 때까지 걸린시간
• 가용성(Availability) : 시스템을 사용할 필요가 있을 때 즉시 사용 가능한 정도
• 사용률(Utilization) : 의뢰한 작업을 처리하는 동안의 CPU 사용량, 메모리 사용량, 네트워크 사용량 등 자원 사용률