[정보처리기사] 4장 서버 프로그램 구현

모듈: 소프트웨어 설계에서 기능단위로 분해하고 추상화되어 재사용 및 공유가능한 수준으로 만들어진 단위
모듈화: 소프트웨어의 성능 향상, 시스템의 수정 및 재사용, 유지 관리 등이 용이하도록 시스템의 기능들을 모듈 단위로 나누는 것. 모듈화는 모듈 간 결합도(Coupling)의 최소화와 모듈 내 요소들의 응집도(Cohesion)를 최대화 하는 것이 목표

결합도(Coupling): 모듈 간에 상호 의존하는 정도 또는 두 모듈 사이의 연관 관계
<결합도가 약한 것부터 결합도가 높은 순-약할수록 모듈의 독립성이 높아짐>
- 자료결합도(Data Coupling): 모듈 간의 인터페이스가 자료 요소로만 구성될 때
- 스탬프(검인) 결합도(Stamp Coupling): 모듈 간의 인터페이스로 배열이나 레코드 등의 자료 구조가 전달될 때
- 제어 결합도(Control Coupling): 어떤 모듈이 다른 모듈 내부의 논리적인 흐름을 제어하기 위해 제어 신로를 통신하거나 제어 요소(Flag)를 전달
- 외부 결합도(External Coupling): 어떤 모듈에서 선언한 데이터(변수)를 외부의 다른 모듈에서 참조할 때
- 공통(공유) 결합도(Common Coupling): 공유되는 공통 데이터 영역(전역변수)을 여러 모듈이 사용할 때
- 내용 결합도(Content Coupling): 한 모듈이 다른 모듈의 내부 기능 및 그 내부 자료를 직접 참조하거나 수정(public 속성)할 때

응집도(Cohesion): 정보 은닉 개념 확장. 모듈이 독립적인 기능으로 정의되어 있는 정도
<응집도가 강한 것부터 약한 것 순-응집도가 강할수록 품질이 높고, 약할수록 품질이 낮음>
- 기능성 응집도(Functional Cohesion): 모듈 내부의 모든 기능 요소들이 단일 문제와 연관되어 수행될 경우의 응집도
- 순차적 응집도(Sequential Cohesion): 모듈 내 하나의 활동으로부터 나온 출력 데이터를 그다음 활동의 입력데이터로 사용할 경우의 응집도
- 교환(통신)적 응집도(Communication Cohesion): 동일한 입력과 출력을 사용하여 서로 다른 기능을 수행하는 구성 요소들이 모였을 경우의 응집도
- 절차적 응집도(Procedural Cohesion): 모듈이 다수의 관련 기능을 가질 때 모듈 안의 구성 요소들이 그 기능을 순차적으로 수행할 경우의 응집도
- 시간적 응집도(Temporal Cohesion): 특정 시간에 처리되는 몇 개의 기능을 모아 하나의 모듈로 작성할 경우의 응집도
- 논리적 응집도(Logical Cohesion): 유사한 성격을 갖거나 특정 형태로 분류되는 처리요소들로 하나의 모듈이 형성되는 경우의 응집도
- 우연적 응집도(Coincidental Cohesion): 모듈 내부의 각 구성 요소들이 서로 관련 없는 요소로만 구성된 경우의 응집도

객체지향: 현실 세계를 그대로 모형화. 소프트웨어 개발 시 객체들을 조립하여 작성 가능. 소프트웨어 재사용 및 확장 용이. 유지보수 쉬움

객체지향 주요 요소
- 객체: 데이터와 데이터를 처리하는 함수를 캡슐화한 하나의 모듈
- 클래스: 공통된 속성과 연산을 갖는 객체의 집합
- 인스턴스: 클래스에 속한 각 객체

객체지향의 주요 개념
- 캡슐화(Encapsulation): 데이터와 데이터를 처리하는 함수를 하나로 묶은 것. 재사용 용이. 객체 간 결합도 감소
- 상속성(Inheritance): 이미 정의된 상위 클래스의 모든 속성과 연산을 하위 클래스가 물려 받는 것. 클래스 및 소프트웨어 재사용
- 다형성 (Polymorphism): 각 개체가 갖고 있는 고유한 방법대로 응답하는 것. 오버로딩과 오버라이딩 존재
   - 오버로딩(Overloading): 메서드의 이름은 같고 매개변수의 유형과 개수가 다르도록 하는 것
   - 오버라이딩 (Overriding): 상위 클래스가 가지고 있는 메서드를 하위 클래스가 재정의해서 사용하는 것

- 정보은닉(Information Hiding): 다른 객체에 자신의 정보를 숨기는 것. 연산만을 통해 접근. 각 개체의 수정이 다른 객체에 주는 Side Effect를 최소화하는 기술
- 추상화(Abstaction): 불필요한 부분 생략. 객체 속성 중 가장 중요한 것에 중점을 두어 모델화하는 것

아키텍처 패턴(Architecture Pattern): 소프트웨어 구조에서 발생하는 문제점을 해결하기 위한 일반화된 재사용 가능한 솔루션
- 계층화 패턴(Layer Pattern): 하위층이 제공하는 서비스를 상위층의 서브 시스템이 이용 가능
- 클라이언트-서버 패턴(Client-Server Pattern): 서버는 클라이언트에 서비스를 제공하며 데이터를 관리
- 마스터-슬레이브 패턴(Master-Slave Pattern): 마스터 컴포넌트가 동등한 구조의 슬레이브 컴포넌트로 작업을 분산하고, 슬레이브가 결과값을 반환하면 최종 결과값을 계산하는 구조
- 파이프-필터 패턴(Pipe-Filter Pattern): 필터 컴포넌트에서 각 처리과정을 실행하며, 처리된 데이터는 파이프를 통해 전송
- 브로커 패턴(Broker Pattern): 분리된 컴포넌트로 구성된 분산 시스템에서 사용. 
- 피어 투 피어 패턴(Peer to Peer Pattern): 각 컴포넌트 간에 서비스를 주고 받는 패턴. 서로 서비스 요청 및 제공 가능
- 이벤트-버스 패턴(Event-Bus Pattern): 리스너가 구독한 채널에 소스가 서비스를 제공하면 채널이 리스너에게 서비스를 제공해 주는 구조
- 모델-뷰-컨트롤러 패턴(Model-View-Controller Pattern) - MVC Pattern: 각자의 역할을 갖고 사용자에게 서비스를 제공
- 블랙보드 패턴(Blackboard Pattern): 명확히 정의된 해결 전략이 알려지지 않은 문제에 대해서 유용
- 인터프리터 패턴(Interpreter Pattern): 특정 언어로 작성된 프로그램을 해석하는 컴포넌트를 설계할 때 사용

객체지향 분석(OOA. Object Oriented Analysis): 사용자의 요구사항을 분석하여 요구된 문제와 관련된 모든 클래스, 객체, 속성, 연산, 관계 등을 정의하여 모델링하는 작업
- Rumbaugh(럼바우): 소프트웨어 구성 요소를 그래픽 표기법을 이용하여 모델링. 객체모델링(객체 다이어그램(Object Diagram): 객체들 간의 관계 정의) → 동적 모델링(상태 다이어그램(State Diagram): 시간 흐름에 따른 동적인 행위) → 기능 모델링(자료 흐름도(Data Flow Diagram): 자료 흐름을 중심으로 처리 과정 표현)
- 부치(Booch): 미시적(Micro) 개발 프로세스와 거시적(Macro) 개발 프로세스 모두 포함. Use-Case를 강조
- 코드(Code)와 요든(Yourdon): E-R 다이어그램을 사용하여 객체의 행위를 모델링
- 워프스(Wirfs)-브록(Brock): 분석과 설계 간 구분이 없으며, 고객 명세서를 평가하여 설계 작업까지 연속적 수행

객체지향 설계 원칙(SOLID 원칙)
단일 책임 원칙(SRP) : 객체는 단 하나의 책임만 가져야 한다.
개방-폐쇄 원칙(OCP) : 기존의 코드를 변경하지 않고 기능을 추가할 수 있도록 설계해야한다.
리스코프 치환 원칙(LCP) : 자식 클래스는 최소한 부모 클래스의 기능은 수행할 수 있어야 한다는 원칙
인터페이스 분리 원칙(ISP) : 자신이 사용하지 않는 인터페이스와 의존 관계를 맺거나 영향을 받지 않아야 한다는 원칙
의존 역전 원칙(DIP) : 의존 관계 성립 시 추상성이 높은 클래스와 의존관계를 맺어야 한다는 원칙

- 팬 인(Fan-in)Permalink: 어떤 모듈을 제어(호출)하는 모듈의 수. 상위 모듈
- 팬 아웃(Fan-out)Permalink: 어떤 모듈어 의해 제어(호출)되는 모듈의 수. 하위 모듈

IPC(Inter-Process Communication): 모듈 간 통신 방식을 구현하기 위해 사용되는 대표적인 프로그래밍 인터페이스 집합. 메시지 큐 / 공유메모리 / 소켓 / 세마포어

디자인 패턴: 모듈간의 관계 및 인터페이스를 설계할 때 참조할 수 있는 전형적인 해결방식 또는 예제

생성 패턴(Creational Pattern): 클래스나 객체의 생성과 참조 과정을 정의하는 패턴
추상팩토리(Abstract Factory): 구체적인 클래스에 의존하지 않고, 인터페이스를 통해 서로 연관-의존하는 객체들의 그룹으로 생성하여 추상적으로 표현하는 패턴
빌더(Builder): 작게 분리된 인스턴스를 건축하듯이 조합하여 객체를 생성하는 패턴 객체의 생성 과정과 표현 방법을 분리하고 있어, 동일한 객체 생성에서도 서로 다른 결과를 만들어 낼 수 있다.
팩토리 메소드(Factory Method): 객체 생성을 서브 클래스에서 처리하도록 분리하여 캡슐화한 패턴이다. 상위클래스에서 인터페이스만 정의하고, 실제 생성은 서브 클래스가 담당한다.
프로토타입(Prototype): 원본 객체를 복제하는 방법으로 객체를 생성하는 패턴이다.
싱글톤(Singleton): 하나의 객체를 생성하면 생성된 객체를 어디서든 참조할 수 있지만, 여러 프로세스가 동시에 참조할 수는 없는 패턴클래스 내에서 인스턴스가 하나뿐임을 보장하며, 불필요한 메모리 낭비를 최소화

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

행위 패턴(Behavioral pattern): 클래스나 객체들이 서로 상호작용하는 방법이나 책임 분배 방법을 정의하는 패턴이다.
책임연쇄(Chain of Responsibility): 요청을 처리할 수 있는 객체가 둘 이상 존재하여 한 객체가 처리하지 못하면 다음 객체로 넘어가는 형태의 패턴
커맨드(Command): 요청을 객체의 형태로 캡슐화하여 재이용하거나 취소할 수 있도록 요청에 필요한 정보를 저장하거나 로그에 남기는 패턴
인터프리터(Interpreter): 언어에 문법 표현을 정의하는 패턴 SQL이나 통신 프로토콜과 같은 것을 개발할 때 사용한다.
반복자(Iterator): 자료구조와 같이 접근이 잦은 객체에 대해 동일한 인터페이스를 사용하도록 하는 패턴이다. 내부 표현의 방법과 노출 없이 순차적인 접근이 가능하다.
중개자(Mediator): 수많은 객체들 간의 복잡한 상호작용(Interface)을 캡슐화하여 객체로 정의하는 패턴 객체들 사이의 의존성을 줄여 결합도를 감소시킬 수 있다.
메멘토(Memento): 특정 시점에서의 객체 내부 상태를 객체화 함으로써 이후 요청에 따라 객체를 해당 시점의 상태로 돌릴 수 있는 기능을 제공하는 패턴
옵저버(Observer): 한 객체의 상태가 변화하면 객체에 상속되어있는 다른 객체들에게 변화된 상태를 전달하는 패턴 주로 분산된 시스템 간에 이벤트를 생성-발행(publish)하고, 이를 수신(subscribe)해야할 때 사용한다.
상태(State): 객체의 상태에 따라 동일한 동작을 다르게 처리해야할 때 사용하는 패턴 객체의 상태를 캡슐화하고, 이를 참조하는 방식으로 처리한다.
전략(Strategy): 동일한 계열의 알고리즘들을 개별적으로 캡슐화하여 상호 교환할 수 있게 정의하는 패턴 클라이언트는 독립적으로 원하는 알고리즘을 선택하여 사용할 수 있으며, 클라이언트에 영향없이 알고리즘의 변경이 가능하다.
템플릿 메서드(Template Method): 상위 클래스에서 골격을 정의하고, 하위 클래스에서 세부 처리를 구체화하는 구조의 패턴. 유사한 서브클래스를 묶어 공통된 내용을 상위 클래스에서 정의함으로써 코드의 양을 줄이고, 유지보수 용이.
방문자(Visitor): 각 클래스들의 데이터 구조에서 처리 기능을 분리하여 별도의 클래스로 구성하는 패턴 분리된 처리 기능은 각 클래스를 방문하여 수행