Part 3. 애플리케이션 설계 23.01.16(월)

1. 애플리케이션 설계 – 공통 모듈 설계 – 재사용

1) 재사용(Recuse)의 개념

재사용은 목표 시스템의 개발 시간 및 비용 절감을 위하여 검증된 기능을 파악하고 재구성하여 시스템에 응용하기 위한 최적화 작업이다.

기존의 소프트웨어 또는 소프트웨어 지식을 활용하여 새로운 소프트웨어를 구축하는 작업이다.

 

2) 재사용의 유형

(1) 함수와 객체 재사용

클래스(Class)나 함수(Function) 단위로 구현한 소스 코드를 재사용

 

(2) 컴포넌트 재사용

컴포넌트 단위로 재사용

컴포넌트의 인터페이스를 통해 통신

* 컴포넌트란 틀정한 기능을 수행하기 위해 독립적으로 개발되어 보급하고, 다른 부품과 조립되어 응용 시스템을 구축하기 위해 사용되는 소프트웨어 프로그램이다.

 

(3) 애플리케이션 재사용

공통기능을 제공하는 애플리케이션과 기능을 공유하여 재사용

 

2. 애플리케이션 설계 – 공통 모듈 설계 – 공통 모듈

1) 공통 모듈의 개념

(1) 모듈(Module)의 개념

모듈은 크게 독립된 하나의 소프트웨어 또는 하드웨어 단위를 지칭하는 용어이다.

모듈화를 통해 분리된 시스템의 기능들로 서브프로그램, 서브 루틴, 소프트웨어 내의 단위 프로그램, 작업 단위 등과 같은 의미로 사용된다.

 

(2) 모듈의 특징

1-독립성

각각의 모듈은 상대적인 독립성을 가짐

모듈의 독립성은 결합도와 응집도에 의해 측정됨

 

2-다양한 조합

모듈 내부에는 모듈을 하나로 통합하는 수많은 조합이 존재할 수 있음

 

3-재사용

모듈은 단독으로 컴파일할 수 있고 재사용 가능

 

4-영향 최소화

독립성이 높은 모듈일수록 수정 시 다른 모듈에 영향을 거의 미치지 않음

 

(3) 공통 모듈의 개념

전체 프로그램의 기능 중 특정 기능을 처리할 수 있는 실행 코드를 의미한다.

자체적으로 컴파일 가능하고, 다른 프로그램에서 재사용이 가능하다.

* 컴파일이란 프로그래밍 언어로 쓰여 있는 원시 코드(Source Code)를 다른 프로그래밍 언어의 목적 코드(Object Code)로 옮기는 기법이다.

여러 기능 및 프로그램에서 공통으로 사용할 수 있는 모듈을 의미하며 날짜 처리를 위한 유틸리티 모듈 등이 해당된다.

 

2) 공통 모듈의 원칙 – 정명 완일추

(1) 정확성(Correctness)

해당 기능이 실제 시스템 구현 시 필요한지 아닌지를 알 수 있도록 정확하게 작성

 

(2) 명확성(Clarity)

해당 기능에 대해 일관되게 이해되고 한 가지로 해석될 수 있도록 작성

 

(3) 완정성(Completeness)

시스템이 구현될 때 필요하고 요구되는 모든 것을 기술

 

(4) 일관성(Consistency)

공통 기능 간에 상호 충돌이 없도록 작성

 

(5) 추적성(Traceability)

공통 기능에 대한 요구사항 출처와 관련 시스템 등의 유기적 관계에 대한 식별이 가능하도록 작성

 

3) 모듈화

(1) 모듈화(Modularity) 개념

모듈화는 프로그램이 효율적으로 관리될 수 있도록 시스템을 분해하고 추상화함으로써 소프트웨어 제품의 성능을 향상시키거나 시스템의 수정 및 재사용, 유지 관리를 쉽게 하는 기법이다.

소프트웨어의 성능을 향상시키거나 복잡한 시스템의 수정, 재사용, 유지 관리 등이 용이하도록 기능 단위의 모듈로 분해하는 설계 및 구현 기법이다.

 

(2) 모듈화 기법

1-루틴(Routine)

소프트웨어에서 특정 동작을 수행하는 일련의 코드로 기능을 가진 명령들의 모임

* 루틴은 메인 루틴과 서브 루틴으로 나뉜다.

 

2-메인 루틴(Main Routine)

프로그램의 주요한 부분이며, 전체의 개략적인 동작 절차를 표시하도록 만들어진 루틴

메인 루틴은 서브 루틴을 호출

 

3-서브 루틴(Subroutine)

메인 루틴에 의해 필요할 때마다 호출되는 루틴

 

(3) 모듈화 필요성

모듈의 크기가 너무 작아 모듈 개수가 많아지면 모듈 간 통합 비용이 많이 발생한다.

모듈의 크기가 너무 크면 모듈 간의 통합 비용이 줄어드는 대신 모듈 당 개발 비용이 커진다.

 

(4) 바람직한 모듈 설계 방안

모듈의 독립성과 재사용성을 높이기 위하여 결합도는 낮추고 응집도는 높인다.

모듈의 복잡도와 중복성을 줄이고 일관성을 유지한다.

모듈의 기능은 예측이 가능해야 하며, 지나치게 제한적이어서는 안 된다.

적당한 모듈의 크기를 유지한다.

모듈 간의 효과적인 제어를 위해 설계에서 계층적 자료 조직이 제시되어야 한다.

유지보수가 용이해야 하고, 이식성을 고려해야 한다.

 

4) 모듈화 측정 지표

(1) 응집도(Cohesion)

모듈의 내부 요소들의 서로 관련되어 있는 정도

모듈이 독립적인 기능으로 정의되어 있는 정도

 

(2) 결합도(Coupling)

모듈 간에 상호 의존하는 정도

두 모듈 사이의 연관 관계를 맺고 있는 정도

 

* 좋은 모듈화란 용도에 맞게 잘 구분된 기능을 가진 모듈들로 세분화하는 것이다.

* 개별 모듈은 독립적으로 주어진 역할 만을 수행하며, 타 모듈에 의존성이 높지 않아야 한다.

 

5) 모듈화 유형

(1) 응집도

1-응집도의 개념

응집도는 모듈의 독립성을 나타내는 개념으로, 모듈 내부 구성요소 간 연관 정도이다.

응집도는 정보 은닉 개념의 확장개념으로, 하나의 모듈은 하나의 기능을 수행하는 것을 의미한다.

 

2-응집도의 유형 – 우논시절 통순기 – 영어 체크하기

응집도의 유형은 ‘우연적 < 논리적 < 시간적 < 절차적 < 통신적 < 순차적 < 기능적 응집도’ 순서로 응집도가 높아진다.

 

[1] 우연적 응집도(Coincidental Cohesion)

서로 간에 어떠한 의미 있는 연관 관계도 없는 기능 요소로 구성될 경우의 응집도

서로 다른 상위 모듈에 의해 호출되어 처리상의 연관성이 없는 서로 다른 기능을 수행할 경우의 응집도

 

[2] 논리적 응집도(Logical Cohesion)

유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들이 한 모듈에서 처리되는 경우의 응집도

 

[3] 시간적 응집도(Temporal Cohesion)

연관된 기능이라기보다는 특정 시간에 처리되어야 하는 활동들을 한 모듈에서 처리할 경우의 응집도

 

[4] 절차적 응집도(Procedural Cohesion)

모듈이 다수의 관련 기능을 가질 때 모듈 안의 구성요소들이 그 기능을 순차적으로 수행할 경우의 응집도

 

[5] 통신적 응집도(Communication Cohesion)

동일한 입력과 출력을 사용하여 다른 기능을 수행하는 활동들이 모여있을 경우의 응집도

 

[6] 순차적 응집도(Sequential Cohesion)

모듈 내에서 한 활동으로부터 나온 출력값을 다른 활동이 사용할 경우의 응집도

 

[7] 기능적 응집도(Functional Cohesion)

모듈 내부의 모든 기능이 단일한 목적을 위해 수행되는 경우의 응집도

 

* 낮은 응집도의 경우 하나의 모듈 내부에 다양한 기능을 구현하여 독립성이 낮아진다.

* 높은 응집도의 경우 단 하나의 기능만을 분리 구현하여 독립성이 보장되고, 변경이 쉬워서 유지보수에 편리하다.

 

(2) 결합도

1-결합도의 개념

결합도는 모듈 내부가 아닌 외부의 모듈과의 연관도 또는 모듈 간의 상호 의존성을 나타내는 정도이다.

결합도는 소프트웨어 구조에서 모듈 간의 관련성을 측정하는 척도이다.

 

2-결합도의 유형 – 내공외제 스자 – 영어 체크하기

결합도의 유형은 ‘내용 > 공통 > 외부 > 제어 > 스탬프 > 자료 결합도‘ 순으로 결합도가 낮아진다.

 

[1] 내용 결합도(Content Coupling)

다른 모듈 내부에 있는 변수나 기능을 다른 모듈에서 사용하는 경우의 결합도

하나의 모듈이 직접적으로 다른 모듈의 내용을 참조할 때 두 모듈은 내용적으로 결합되어 있는 경우의 결합도

 

[2] 공통 결합도(Common Coupling)

파라미터가 아닌 모듈 밖에 선언되어 있는 전역 변수를 참조하고 전역 변수를 갱신하는 식으로 상호작용하는

경우의 결합도

공유되는 공통 데이터 영역을 여러 모듈이 사용할 때의 결합도

 

* 전역 변수(Global Variable)

어떤 변수 영역 내에서도 접근할 수 있는 변수를 의미하는 용어로 지역 변수와 대비되는 개념이다.

예를 들어, C언어에서 전역 변수는 최초의 실행 함수인 main 함수가 실행되기 전에 생성되어 초기화되며, 지역 변수와 다르게 데이터 영역에 저장된다.

 

[3] 외부 결합도(External Coupling)

두 개의 모듈이 외부에서 도입된 데이터 포맷, 통신 프로토콜 또는 디바이스 인터페이스를 공유할 경우의 결합도

외부 모듈에서 선언한 데이터(변수)를 외부의 다른 모듈에서 참조할 때의 결합도

 

[4] 제어 결합도 (Control Coupling)

어떤 모듈이 다른 모듈의 내부 논리 조직을 제어하기 위한 목적으로 제어신호를 이용하여 통신하는 경우의 결합도

하위 모듈에서 상위 모듈로 제어 신호가 이동하여 상위 모듈에게 처리 명령을 부여하는 권리 전도 현상이 발생하는 결합도

 

[5] 스탬프 결합도(Stamp Coupling)

모듈 간의 인터페이스로 배열이나 객체, 구조 등이 전달되는 경우의 결합도

두 모듈이 동일한 자료 구조를 조회하는 경우의 결합도이며, 자료 구조의 어떠한 변화는 모든 모듈에 영향을 미치게 됨

 

[6] 자료 결합도(Data Coupling)

모듈 간의 인터페이스로 전달되는 파라미터를 통해서만 모듈 간의 상호 작용이 일어나는 경우의 결합도

한 모듈의 내용을 변경하더라도 다른 모듈에는 영향을 미치지 않는 상태로 가장 바랍직한 결합도

 

6) 효과적인 모듈 설계를 위한 유의사항

모듈 간의 결합도를 약하게 하면 모듈 독립성이 향상된다.

복잡도와 중복성을 줄이고 일관성을 유지시킨다.

모듈의 기능은 예측이 가능해야 하며, 지나치게 제한적이면 안 된다.

유지보수가 용이해야 한다.

모듈의 수가 증가하면 상대적으로 각 모듈의 크기가 작아지고, 모듈 사이의 상호 교류가 증가하여
과부화(Overload) 현상이 나타난다.

 

7) 팬인(Fan-In) 및 팬아웃(Fan-Out)

* 팬인, 팬아웃의 계산은 정확하게 답을 구하는 문제이기 때문에 출제되기 좋음.

(1) 팬인(Fan-In) 및 팬아웃(Fan-Out) 개념

팬인은 어떤 모듈을 제어하는 모듈의 수이다.

팬아웃은 어떤 모듈에 의해 제어되는 모듈의 수이다.

 

(2) 팬인 및 팬아웃 특징

소프트웨어의 구성요소인 모듈을 계층적으로 분석하기 위해서 팬인, 팬아웃을 활용한다.

시스템 복잡도를 최적화하기 위해서는 팬인은 높게, 팬아웃은 낮게 설계해야 한다.

 

(3) 팬인 및 팬아웃 계산 방법

팬인 : 모듈 자신을 기준으로 모듈에 들어오면 팬인(in)

팬아웃 : 모듈 자신을 기준으로 모듈에서 나가면 팬아웃(out)

팬인 및 팬아웃 계산

 

3. 애플리케이션 설계 – 공통 모듈 설계 – 설계 모델링

1) 설계 모델링

(1) 설계 모델링의 개념

설계 모델링은 요구사항 분석 단계에서 규명된 필수 기능들의 구체적인 구현 방법을 명시하는 기법이다.

소프트웨어에 요구되는 기능과 성능 조건들을 만족하는 소프트웨어의 내부 기능, 구조 및 동적 행위들을 모델링하여 표현, 분석, 검증하는 과정이다.

 

(2) 설계 모델링 원칙

소프트웨어 설계는 변경이 쉽도록 구조화되어야 한다.

하나의 함수 안에 특정 기능을 수행하는 데 필요한 자료만 사용하도록 규제한다.

독립적이고 기능적인 특성을 지닌 모듈 단위로 분할 설계한다.

계층적 구조를 가져야 한다.

 

(3) 설계 모델링 유형

1-구조 모델링

소프트웨어를 구성하는 컴포넌트들의 유형, 인터페이스, 내부 설계 구조 및 이들의 상호 연결 구조를 모델링

시스템의 구성요소들과 이들 사이의 구조적인 관계와 특성들을 모델링

 

구성요소 : 프로시저, 데이터 구조, 모듈, 파일 구조

* 프로시저(Procedure)

프로그램을 기능에 따라 여러 개의 단위로 분해하여 작성하는 것으로 크게 서브 프로시저와 함수 프로시저로 구분한다.

 

*모듈(Module)

프로그램을 구성하는 구성요소의 일부로 관련된 함수나 변수 또는 클래스를 모아 놓은 파일이다. 모듈은 다른 프로그램에서 불러와서 사용할 수 있다.

 

2-행위 모델링

소프트웨어의 구성 요소들의 기능들과 이들이 언제, 어떠한 순서로 기능을 수행하고 상호 작용하는지를 모델링

시스템의 구성요소들이 언제 어떠한 순서로 수행되는가와 같은 동적인 특성들을 모델링

 

구성요소 : 입력 데이터, 출력 데이터, 데이터 흐름, 데이터 변환, 데이터 저장

 

2) 소프트웨어 설계 유형 – 가볍게 보고 넘어가기

(1) 자료 구조 설계(Data Structure Design)

요구분석 단계에서 생성된 정보를 바탕으로 소프트웨어를 구현하는데 필요한 자료 구조로 변환하는 과정을 설계

 

(2) 아키텍처 설계(Architecture Design)

예비 설계 도는 상위 수준 설계

소프트웨어 시스템의 전체 구조를 기술

소프트웨어를 구성하는 컴포넌트 간의 관계를 정의

 

(3) 인터페이스 설계(Interface Design)

소프트웨어와 상호 작용하는 컴퓨터 시스템, 사용자 등이 어떻게 통신하는지를 설계

 

(4) 프로시저 설계(Procedure Design)

모듈이 수행할 기능을 절차적 기술로 바꾸는 설계

 

(5) 협약에 의한 설계(Design by Contract)

클래스에 대한 여러 가정을 공유하도록 명세한 설계

소프트웨어 컴포넌트에 대한 정확한 인터페이스 명세를 위하여 선행조건, 결과조건, 불변조건을 나타내는 설계 방법

* 선행조건 : 컴포넌트의 오퍼레이션 사용 전에 참이 되어야할 조건

* 결과조건 : 사용 후 만족되어야 할 조건

* 불변조건 : 오퍼레이션이 실행되는 동안 항상 만족되어야할 조건

 

* 자료 구조 설계, 아키텍처 설계, 인터페이스 설계, 프로시저 설계, 협약에 의한 설계는 상위 설계에 속하고, 모듈 설계는 하위 설계에 속한다.

 

* 상위설계는 시스템 수준에서의 소프트웨어 구성 컴포넌트들 간의 관계로 구성된 시스템의 전체적인 설계이다.

* 하위 설계는 시스템의 각 구성요소들의 내부 구조, 동적 행위 등을 결정하는 설계이다.

 

3) 소프트웨어 설계 원리

(1) 상향식 설계

하위 기능들로부터 시작하여 제일 상위에 있는 기능에 접근해가는 방식

인터페이스가 성립되어 있어야 기능 추가가 쉬움

 

(2) 하향식 설계

소프트웨어 설계시 제일 상위에 있는 기능에서 시작하여 기능을 하위 기능들로 분할해 가면서 설계하는 방식

레벨이 낮은 데이터 구조의 세부 사항은 설계 초기 단계에서 필요

통합 검사 시 인터페이스가 이미 정의되어 있어서 통합이 간단함

 

4) 코드 설계 – 중요도 높음

(1) 코드 설계 개념

코드 설계는 데이터의 분류나 조합을 쉽게 하기 위하여 사물을 표현하는 코드를 설계하는 기법이다.

 

(2) 코드의 기능

1-표준화

정보들 종류, 모양, 크기 등의 일정한 기준에 따라 통일적으로 표현하는 기능

 

2-분류

정보들을 동일한 특성을 가진 데이터로 그룹화하여 나누는 기능

 

3-식별

다른 것과 구별될 수 있는 기능

 

4-배열

일련의 순서로 나열할 수 있는 기능

 

5-간소화

정보의 표현을 간소화해서 나타낼 수 있는 기능

 

6-연상

정보를 표현하고자 하는 대상체 뜻과 의미가 코드에 내포되게 하는 기능

 

7-암호화

정보의 외부 표현을 감추고자 하는 기능

 

8-오류 검출

정보 입력이나 관리 시 잘못된 정보를 찾아내는 기능

 

(3) 코드 설계 종류

1-연상 코드(Mnemonic Code)

코드만 보고 대상을 연상할 수 있도록 명칭 일부를 약호(간단하고 알기 쉽게 나타내어 만든 부호) 형태로 넣어 구성된 코드

예) 나라 이름(한국 : KR, 미국 : US ...)

 

2-블록 코드(Block Code)

공통성이 있는 것끼리 블록으로 구분하고, 각 블록 내에서 일련번호를 부여하는 코드

구분 코드라고도 불림

예) 전화번호(지역 번호 – 국번 – 일련번호 조합에서 지역번호 – 국번은 같은 지역끼로 공통)

 

3-순차 코드(Sequence Code)

일정한 기준에 따라 순서대로 일련번호를 부여하는 코드

예) 중고등 학생들의 반에서 번호(가나다순으로 1번, 2번, ...)

 

4-표의 숫자 코드(Significant Digit Code)

대상 자료의 물리적인 수치인 길이, 넓이, 용량 등을 표시한 코드

예) 20-10-300(길이 – 넓이 – 용량 조합)

 

5-십진 코드(Decimal Code)

10진수 형태로 표현한 코드

예) 상품 바코드(880)

 

6-그룹 분류식 코드(Group Classfication Code)

대상을 기준에 따라 대분류, 중분류, 소분류로 구분하여 번호를 부여한 코드

예) 학번(입학 연도 – 일련번호 조합)

 

(4) 코드 오류 종류 – 영어 체크하기

1-사본 오류(Transcription Error) : 한 자리를 잘못 표기한 오류

2-전위 오류(Transposition Error) : 연속된 두 글자가 서로 바뀌어 표기된 경우

3-생략 오류(Omission Error) : 한 글자를 빼먹고 기술한 경우

4-첨가 오류(Addition Error) : 한 글자를 추가되어 기술한 경우

5-이중 전위 오류(Douvle Trannspostion Error) : 전위 오류가 중복 발생한 경우

 

5) HIPO

(1) HIPO(Hierarchy Input Process Outpu) 개념

HIPO는 시스템의 분석 및 설계, 문서화할 때 사용되며, 하향식 소프트웨어 개발을 위한 문서화 도구이다.

 

(2) HIPO 특징

체계적인 문서 관리가 가능하다.

기호, 도표 등을 사용해서 보기가 쉽고 이해가 쉽다.

기능과 자료의 의존 관계를 동시에 표현할 수 있다.

변경, 유지보수가 용이하다.

시스템의 기능을 고유 모듈들로 분할하여 이들 간의 인터페이스를 계층구조로 표현한 것을 HIPO
차트라고 한다.

 

(3) HIPO 차트 종류 - 가총세

1-가시적 도표

시스템의 전체적인 기능과 흐름을 보여주는 계층구조도

 

2-총체적도표

입력, 처리, 출력에 대한 정보를 제공하는 도표

프로그램을 구성하는 기능을 기술

 

3-세부적 도표

총체적 도표에 표시된 기능을 구성하는 기본 요소들을 상세히 기술하는 도표

 

4. 애플리케이션 설계 – 공통 모듈 설계 – 소프트웨어 아키텍처

1) 소프트웨어 아키텍처(Software Architecture) 개념

소프트웨어 아키텍처는 여러 가지 소프트웨어 구성요소와 그 구성요소가 가진 특성 중에서 외부에 드러나는 특성, 그리고 구성요소 간의 관계를 표현하는 시스템 구조이다.

소프트웨어를 설계하고 전개하기 위한 지침과 원칙이다.

 

2) 소프트웨어 아키텍처의 필요성

소프트웨어 아키텍처를 활용하여 주요 이해관계자들 간의 관점 조율을 통해 시스템을 최적화한다.

소프트웨어 아키텍처는 시스템의 비기능적인 요소에 집중해서 만들어지지만 기능적인 요소도 고려한다.

 

3) 소프트웨어 아키텍처 4+1 뷰 – 중요한 개념 중 하나

(1) 소프트웨어 아키텍처 4+1 뷰 개념

소프트웨어 아키텍처 4+1 뷰는 고객의 요구사항을 정리해 놓은 시나리오를 4개의 관점에서 바라보는 소프트웨어적인 접근 방법이다.

4개의 분리된 구조로 구성되는 아키텍처 개념을 제시하고, 이들 4개 구조가 서로 충돌되지 않는지, 시스템의 요구사항을 충족시키는지를 증명하기 위해 체크 방법으로 유스케이스를 사용한 것이다.

 

(2) 소프트웨어 아키텍처 4+1 뷰 구성요소 – 유논프구배

1-유스케이스 뷰(Usecase View)

유스케이스 또는 아키텍처를 도출하고 설계하며 다른 뷰를 검증하는 데 사용되는 뷰

외부 행위자에 의해 인식되는 시스템의 기능 요구사항을 보여주는 데 초점

사용자, 설계자, 개발자, 테스트 관점

 

2-논리 뷰(Logical View)

시스템의 기능적인 요구사항이 어떻게 제공되는지 설명해주는 뷰

설계자, 개발자 관점

 

3-프로세스 뷰(Process View)

시스템의 비기능적인 속성으로 자원의 효율적인 사용, 병행 실행, 비동기, 이벤트 처리 등을 표현한 뷰

개발자, 시스템 통합자 관점

 

4-구현 뷰(Implementation View) - 유논프구배

개발 환경 안에서 정적인 소프트웨어 모듈의 구성을 보여주는 뷰

컴포넌트 구조와 의존성을 보여주고 컴포넌트에 관한 부가적인 정보 정의

 

5-배포 뷰(Deployment View)

컴포넌트가 물리적인 아키텍처에 어ᄄᅠᇂ게 배치되는가를 매핑해서 보여주는 뷰

물리적 시스템을 구성하고 있는 각 부분들의 분산 형태와 설치에 초점

 

4) 소프트웨어 아키텍처 패턴

(1) 소프트웨어 아키텍처 패턴(Software Architecture Pattern) 개념

소프트웨어 아키텍처 패턴은 외부에서 인식할 수 있는 특성이 담긴 소프트웨어의 골격이 되는 기본 구조이다.

소프트웨어 아키텍처 패턴은 소프트웨어를 설계할 때 참조할 수 있는 전형적인 해결 방식이다.

주어진 상황에서의 소프트웨어 아키텍처에서 일반적으로 발생하는 문제점들에 대한 일반화되고 재사용 가능한

솔루션이다.

 

(2) 소프트웨어 아키텍처 패턴 유형 – 책 이미지 확인하기

1-계층화 패턴(Layered Pattern)

시스템을 계층(Layer)로 구분하여 구성하는 패턴

각 하위 모듈들은 특정한 수준의 추상화를 제공하고, 각 계층은 다음 상위 계층에 서비스를 제공

계층화 패턴은 서로 마주 보는 두 개의 계층 사이에서만 상호 작용이 이루어짐

 

2-클라이언트 – 서버 패턴(Client-Server Pattern)

하나의 서버와 다수의 클라이언트로 구성된 패턴

사용자가 클라이언트를 통해서 서버에 서비스를 요청하면 서버는 클라이언트에게 서비스 제공

서버는 계속 클라이언트로부터 요청을 대기

 

3-파이프 – 필터 패턴(Pipe-Filter Pattern)

데이터 스트림을 생성하고 처리하는 시스템에서 사용 가능한 단방향 패턴

서브 시스템이 입력 데이터를 받아 처리하고, 결과를 다음 서브 시스템으로 넘겨주는 과정을 반복

필터 컴포넌트는 재사용성이 좋고, 추가가 쉽기 때문에 확장이 용이하나, 필터 간 데이터 이동에서 데이터 변환 오버헤드가 발생

 

4-브로커 패턴(Broker Pattern) - Apache Kafka

분리된 컴포넌트들로 이루어진 분산 시스템에서 사용되고, 이 컴포넌트들은 원격 서비스 실행을 통해 상호 작용이 가능한 패턴

컴포넌트 간의 통신을 조정하는 역할 수행

서버는 자신의 기능들(서비스 및 특성)을 브로커에 넘겨주며(Publish), 클라이언트가 브로커에게 서비스를 요청하면 브로커는 클라이언트를 자신의 레지스트리에 있는 적합한 서비스로 리다이렉션 함

 

5-모델 – 뷰 – 컨트롤러 패턴(MVC; Model View Controller Pattern)

대화형 애플리케이션을 모델, 뷰, 컨트롤 뷰 3개의 서브 시스템으로 구조화하는 패턴

MVC 패턴은 각 부분이 별도의 컴포넌트로 분리되어 있어서 서로 영향을 받지 않고 개발 작업 수행 가능

MVC 패턴은 컴포넌트를 분리하며 코드의 효율적인 재사용을 가능하게 하고, 여러 개의 뷰가 있어야 하는 대화형 애플리케이션 구축에 적합

[1] 모델(Model) : 핵심 기능과 데이터 보관

[2] 뷰(View) : 사용자에게 정보 표시(하나 이상의 뷰가 정의될 수 있음

[3] 컨트롤러(Controller) : 사용자로부터 요청을 입력받아 처리, 모델과 뷰 사이에서 전달자 역할을 수행

 

6-마스터 – 슬레이브 패턴(Master-Slave Patter)

연산 통신, 조정을 책임지는 마스터와 제어되고 동기화되는 대상인 슬레이브로 구성되는 패턴

일반적으로 실시간 시스템에서 사용