소프트웨어공학 실무 이론

---

아키텍처 패턴/스타일 적용

과제로 두 챕터를 정리하는 내용입니다.
소공이 여러개 있어서 해깔린건데 저도 잘 모르겠어요 ㅠ

NCS 국가직무능력표준, NCS 블라인드채용

해당 자료는 위에 링크에서 찾으시면 됩니다.(LM2001020103_14v2)

---

주요 아키텍처 패턴별 적용방법

Layer pattern

가장 일반적인 방식으로 사용하는 아키텍처 패턴으로
subtask들의 그룹으로 묶어 사용 허가 관계를 표시하는 패턴

모듈의 재사용성을 높여 유지보수성이나 이식성이 좋은 패턴

Layered archiecture pattern

이러한 유형의 구성 요소 분류를 통해 아키텍처에 효과적인 역할 및 책임 모델을 쉽게 구축할 수 있으며
잘 정의된 구성 요소 인터페이스와 제한된 구성 요소 범위로 인해 이 아키텍처 패턴을 사용하여
애플리케이션을 쉽게 개발, 테스트, 관리 및 유지 관리할 수 있습니다.

 

장단점

• 높은 응집도(High Cohesion)

 각 계층은 특정한 역할을 수행하므로, 관련된 기능이 하나의 계층에 집중되어 높은 응집도를 가질 수 있습니다. 이는 코드의 가독성과 유지보수성을 향상시킵니다.

• 낮은 결합도(Low Coupling)

 각 계층은 서로에게 의존성이 있는 관계로 구성되어 있지만, 계층 간의 결합도는 낮게 유지됩니다. 따라서 한 계층의 변경이 다른 계층에 미치는 영향이 최소화되어, 시스템의 확장성과 유연성이 향상됩니다.

• 재사용성(Reusability)

 각 계층은 독립적으로 사용될 수 있어, 재사용성이 높아집니다. 특정 계층의 변경이 다른 부분에 영향을 미치지 않기 때문에, 계층을 재사용하여 다양한 소프트웨어에서 활용할 수 있습니다.

---

• 불필요한 계층 추가 가능성

 계층을 더 세분화하여 구현할 경우, 불필요한 계층이 추가될 수 있습니다. 이는 코드의 복잡성 ↑

• 오버헤드

 계층이 추가될수록 각 계층 간의 데이터 교환과 함수 호출 등의 오버헤드가 발생할 수 있습니다. 따라서 성능에 영향을 미칠 수 있습니다.

• 복잡성

 계층 간의 의존성과 인터페이스 관리 등, 계층 패턴 자체가 복잡성을 증가시킬 수 있습니다. 따라서 적절한 계층 구조를 설계하고 관리가 필요합니다.

 

대략적인 간단 명료 정리를 여기까지이며, 더욱 자세한 내용은 아래 링크에 있습니다.

Software Architecture Patterns

 

The Layered Architecture Pattern in Software Architecture

---

Broker pattern

외부 컴포넌트 호출할 때 → 클라 요청 → 서버 컴포에 전달
해당 결과를 전달하는 역할(일종의 브로커 패턴)

보안이나, 안정성을 높일 수 있는 패턴

broker architecture pattern

다양한 컴포넌트 간의 상호작용을 조정하는 중앙 집중형의 중개자 역할로써,
브로커는 다양한 컴포넌트 간의 통신을 관리하며, 클라이언트와 서버, 혹은 서비스 제공자와
사용자와 같은 다양한 컴포넌트 간의 통신을 중재하여 서로간의 결합도를 낮추고 유연성 ↑

---

broker arch pattern에 대하여 알아둘 것 

브로커(Broker):
- 다양한 컴포넌트 간의 상호작용을 중재하고 관리하는 중앙 집중형의 컴포넌트
- 클라이언트와 서버 간의 통신이나 서비스 제공자와 사용자 간의 통신을 조정


클라이언트(Client):
- 브로커와 상호작용하며 서비스나 기능을 요청하는 컴포넌트


서버(Server):
- 브로커와 상호작용해 클라의 요청을 처리하고 서비스/기능을 제공하는 컴포넌트


서비스 제공자(Service Provider):
- 브로커에 등록되어 서비스나 기능을 제공하는 컴포넌트


사용자(User):
- 브로커를 통해 서비스나 기능을 사용하는 컴포넌트

컴포넌트 - 해시넷

 

 

장단점

• 중재(Mediation)

브로커는 클라이언트와 서버 간의 통신을 중재하여, 클라이언트와 서버 간의 직접적인 의존성을 줄일 수 있습니다. 이로써 시스템의 유연성과 확장성을 향상시킬 수 있습니다.

• 인터페이스 추상화

 브로커는 클라이언트와 서버 간의 인터페이스를 추상화하고, 서로 다른 시스템 간의 통신을 가능하게 합니다. 이는 시스템의 호환성과 상호운용성을 높여줍니다.

• 중복 제거

 브로커는 공통적인 기능을 중복으로 구현하는 것을 방지하여 코드의 중복을 제거할 수 있습니다. 이는 코드의 유지보수성을 향상시킵니다.

---

• 단일 장애 지점(Single Point of Failure)

 브로커가 시스템의 중심적인 역할을 수행하므로, 브로커의 장애가 시스템 전체에 영향을 줄 수 있습니다. 따라서 브로커의 안정성과 가용성을 고려해야 합니다.

• 성능 저하

 브로커는 클라이언트와 서버 간의 중재를 수행하므로, 추가적인 오버헤드가 발생할 수 있습니다. 이는 시스템의 성능에 영향을 미칠 수 있습니다.

• 복잡성

 브로커 패턴은 클라이언트와 서버 간의 중재를 수행하기 위해 별도의 브로커 컴포넌트를 도입하므로, 시스템의 복잡성을 증가시킬 수 있습니다. 따라서 적절한 설계와 구현이 필요합니다.

 

 

 즉, 중재와 인터페이스 추상화를 통해 시스템의 유연성과 확장성을 향상시키지만, 단일 장애 지점과 성능 저하, 복잡성 등의 단점이 있음

 

대략적인 간단 명료 정리를 여기까지이며, 더욱 자세한 내용은 아래 링크에 있습니다.

Architectural Patterns: Broker

---

MVC pattern

모델, 뷰, 컨트롤 세 개의 컴포넌트로 App을 구분한 패턴으로,

• Model : 기능 데이터
• View : UI/UX
• Control : 관계 → 이벤트

각 관계의 일관성을 갖게 하여 변경용이성, 기능 확장성 지원함

MVC 패턴은 각각의 역할이 분리되어 있기 때문에, 코드의 재사용성, 유지보수성, 확장성이 높으며
또한, 사용자 인터페이스(UI)와 비즈니스 로직이 분리되어 개발을 더 구조화할 수 있습니다.

장단점

• 코드의 분리

 MVC 패턴은 모델, 뷰, 컨트롤러를 각각의 역할로 분리하여 코드를 구성하므로, 코드의 분리가 잘 이루어져서 유지보수성 ↑

• 확장성

 각각의 역할이 명확하게 정의되어 있기 때문에, 새로운 기능을 추가하거나 변경할 때 해당 역할만 수정하면 되므로 확장성 good

• 유연한 사용자 인터페이스 

뷰와 컨트롤러가 분리되어 있기 때문에, 다양한 종류의 사용자 인터페이스(UI)를 구현하는데 유연성이 있습니다.

---

• 복잡성 

MVC 패턴은 세 가지 역할이 분리되어 있기 때문에, 애플리케이션의 구조가 복잡해질 수 있습니다.

• 학습 곡선

 개념적으로 복잡하고, 각각의 역할이 서로 상호작용하는 구조를 가지고 있어 처음 접하는 개발자들에게는 학습 곡선이 높음

• 코드 중복

 모델, 뷰, 컨트롤러 간의 상호작용을 위한 인터페이스나 코드를 작성해야 할 수 있어 코드 중복이 발생할 수 있습니다.

 

대략적인 간단 명료 정리를 여기까지이며, 더욱 자세한 내용은 아래 링크에 있습니다.

 

10 Common Software Architectural Patterns in a nutshell

---

State-Logic-Display pattern

통상 3-tier락 불리며, 비지니스 App에서 주로 사용합니다.
UI/비즈니스 로직/데이터를 구분에 변경 용이성이 높습니다

게임, App 등 많은 분야에 사용되는 모델

각 계층이 독립적으로 동작하도록 설계된 디자인 패턴, 코드의 분리와 확장성 ↑

 

장단점

 3-Tier 모델은 코드의 분리와 개발 프로세스의 효율성을 강조하는 장점이 있지만, 복잡성과 오버헤드, 성능에 대한 고려가 필요한 단점이 있습니다. 따라서, 프로젝트의 요구사항과 상황에 따라 장단점을 고려하여 적절하게 선택 및 적용합니다.

 

대략적인 간단 명료 정리를 여기까지이며, 더욱 자세한 내용은 아래 링크에 있습니다.

 

---

Sense-Compute-Control pattern

센서의 값을 계산하여 해야할 행위를 정의한 기능이나
행위를 전달하는 컨트롤러로 모듈을 구분하는 패턴입니

임베디드 App을 개발할 때 주로 사용하는 패턴임

센서와 데이터 처리, 시스템 제어를 분리해 각 계층이 독립적으로 동작, 높은 확장성과 유연성 ↑,
제공 센서와 데이터 처리, 시스템 제어의 각각의 계층이 확장, 수정, 교체가 가능하며,
서로 독립적으로 개발, 테스트, 배포가 가능하다는 장점이 있습니다.

센서와 데이터 처리, 시스템 제어의 분리로 인해 시스템 전체의 복잡성이 감소하고, 재사용성이 향상됩니다.

---

맡은 주제 - 아키텍처 준거성 확보 및 합의

• 아키텍처의 견고성(Resilience)
  시스템이 예상치 못한 상황에서도 정상적으로 동작하고, 중단을 최소화하며, 장애를 복구할 수 있는 능력
• 아키텍처의 합의(Consensus)
  시스템의 다양한 구성 요소가 동일한 상태나 결정을 공유하고, 동기화하여 일관성을 유지하는 것을 의미

아키텍처의 견고성 확보와 합의는 분산 시스템에서 중요한 요소로, 
안정성과 가용성을 높이고, 시스템의 신뢰성을 확보하는 데 도움이 됩니다.

 아키텍처의 견고성 확보와 합의는 시스템의 안정성과 신뢰성을 높이는 데 기여하며, 장애나 이상 상황에서의 복구와 일관성 유지를 보장하여 시스템의 정상적인 동작을 지원합니다. 하지만, 이를 위한 추가적인 구현 비용과 복잡성을 고려하여 프로젝트의 요구사항과 상황에 맞게 적절하게 사용해야합니다.

더 자세히 하고 싶은데 하고 싶은 것도 많아서 넘어가서 바로 질문

---

면접 예상 질문

Q: 아키텍처의 견고성 확보와 합의에 대해 설명해주세요.

A: 아키텍처의 견고성 확보는 시스템이 예상치 못한 상황에서도 정상적으로 동작하고, 장애를 복구할 수 있는 능력을 갖추는 것을 말합니다. 이를 위해 장애 예측과 대응을 위한 복구 메커니즘, 데이터의 백업과 복제, 고가용성을 위한 분산 데이터 센터와 로드 밸런싱 등의 방법을 사용할 수 있습니다. 또한, 모니터링과 경고 시스템을 통해 장애를 신속하게 감지하고 대응하는 것이 중요합니다.

Q: 아키텍처의 견고성 확보와 합의가 중요한 이유는 무엇인가요?

A: 아키텍처의 견고성 확보와 합의는 시스템의 안정성과 신뢰성을 높이는 데 기여합니다. 예상치 못한 장애나 이상 상황에서도 시스템이 정상적으로 동작하여 서비스의 가용성을 유지할 수 있고, 장애를 복구하여 서비스의 중단을 최소화할 수 있습니다. 또한, 다양한 구성 요소 간의 일관성을 유지하고, 결정을 공유함으로써 시스템의 일관성을 보장하고, 데이터 일관성 문제를 방지할 수 있습니다.

---

참고 자료

O'Reilly Media - Technology and Business Training

 

https://www.oreilly.com/library/view/software-architecture-patterns/9781491971437/ch01.html

 

 

 

참고 이미지

 

 

https://www.researchgate.net/figure/BDF-access-broker-architecture-pattern_fig8_338228937