전공과목 정리/소프트웨어분석및설계

[소프트웨어분석및설계🛠️] 9장 SW 아키텍쳐

최연재 2024. 11. 13. 08:57

출처 : 강의 교안, 시스템분석설계 with 애자일 (생능출판사, 최은만)

1. 아키텍쳐 기초

1.1 SW 아키텍쳐 기초

- 소프트웨어 아키텍쳐

  • 시스템을 구성하는 컴포넌트(구성요소)와 컴포넌트 상호작용의 집합

- SW 아키텍쳐는 비기능적 결정(non-functional decisions)을 반영하고, 기능 요구사항을 분할

- SW 아키텍쳐 설계에서 고려해야 할 요구사항

  • 변경
  • 유지보수 용이성
  • 상용 컴포넌트의 사용
  • 시스템 성능
  • 신뢰성
  • 보안
  • 고장 인내성
  • 복구

- SW 아키텍쳐의 역할

  • 시스템의 구조를 확립하는 소프트웨어 개발의 중심축
  • 설계, 구현과 통합, 테스팅까지 통합하는 뼈대
  • 모든 단계에 영향을 줄 만한 초기 의사 결정의 핵심

- SW 아키텍쳐가 중요한 이유 : 시스템이 개발된 후에 구조를 바로잡기 어려움

- SW 아키텍쳐 관점 (view)

  • UML 4+1 View : 시스템 전체에 대한 관점
  • 아키텍쳐 관점은 시스템을 특정 구성요소와 그들 사이의 관계로 표현

 

2. 아키텍쳐 스타일

2.1 SW 아키텍쳐 스타일

- 일반적인 모양과 조화를 위한 스타일을 정하는 작업

  • 시스템 분할, 전체적인 제어 흐름, 오류처리 방침, 서브시스템 간의 통신 프로토콜 포함

- 대표적인 소프트웨어 아키텍쳐 스타일

  • Data-centered architectures (중앙저장소 구조)
  • MVC(Model/View/Controller) 구조
  • 클라이언트-서버(Client-Server) 구조
  • Peer-to-Peer 구조
  • 계층 구조
  • 파이프필터 구조

 

2.2 중앙저장소 구조

- 서브시스템들이 단일 중앙 저장소의 공유 데이터에 접근하고 추가, 수정 및 삭제

  • 서브시스템들은 독립적이고 중앙 자료 저장소를 이용하여 상호 대화
  • 새로운 서브시스템도 저장소를 중심으로 위치함
  • 유형 : 블랙보드, Repository

- 특징 

  • 서비시스템 사이의 병렬 처리와 통합이 용이
  • 저장소는 계속 변경 추가
  • 중앙저장소가 잘 정의되면 새로운 서비스를 서브시스템으로 쉽게 추가할 수 있음
  • 데이터 처리 업무에 적합

- 단점

  • 중앙저장소와 서브시스템의 결합이 매우 강하므로 저장소가 변경되면 모든 서브시스템이 영향을 받음
  • 단일 장애 지점(Single Point Of Failure) 문제

 

2.3 MVC 구조

- MVC (Model-View-Controller)

  • UI로부터 비즈니스 로직과 데이터를 분리
  • 모델 : 애플리케이션의 정보(데이터)를 나타냄
  • 뷰 : 텍스트, 체크박스 항목 등과 같은 사용자 인터페이스 요소를 나타냄
  • 컨트롤러 : 데이터와 비즈니스 로직 사이의 상호동작을 관리

- 모델 서브 시스템은 시스템의 여러 뷰나 컨트롤러와 의존되지 않도록 개발

- 장점

  • 느슨한 결합, 확장성
  • 다수의 뷰를 사용하는 대화형 시스템에 적합

- 단점

  • 복잡도
  • 뷰와 모델이 서로 의존적임 : 뷰가 바뀌면 모델도 바뀌어야 함
  • MVP(Model, View, Presenter)로 개선

 

2.4 클라이언트/서버 구조

- 클라이언트/서버 (Client/Server)

  • 서버는 여러 클라이언트에게 서비스 제공
  • 요청과 결과를 받기 위해서 동기화되는 일을 제외하고는 모두 독립적
  • 대부분의 웹 기반의 애플리케이션과 파일 서버, 전송 프로토콜을 포함

- 장점

  • 데이터 집중화 : 모든 데이터는 서버에서 집중 관리하므로 구성과 관리를 단순화
  • 보안 : 모니터링과 인증을 통한 접근 제어

- 단점

  • 병목현상 : 서버의 부하로 인한 네트워크 속도 저하
  • 비용 : 설치 및 관리 비용
  • 비강인성 : 서버의 고장으로 인한 서비스 불가

 

2.5 Peer-to-Peer

- 클라이언트 서버 유형을 일반화시켜 놓은 것

  • 각 서비시스템이 클라이언트 또는 서버로 동작할 수 있음
  • 각 서버시스템이 서비스를 요청/제공할 수 잇음

- 클라이언트 서버 시스템보다 설계가 어려움

  • 데드락(deadlock)의 가능성과 제어구조의 복잡성 때문

 

2.6 계층(layered) 구조

- SW 기능을 상호작용하는 여러 수직층으로 분할

  • 인접한 층 사이에서만 메시지 교환
  • 장점 : 추상화, 캡슐화, 재사용이 용이
  • 단점 : 이웃 계층과의 통신이 매우 제한적

 

2.7 파이프필터 구조

- 필터 사이에 데이터를 이동시키면서 단계적으로 처리

  • 서브시스템 = 필터
  • 서브시스템 사이의 관계 = 파이프
  • 서브시스템이 입력 데이터를 받아 처리하고 결과를 다른 시스템에 보내는 작업이 반복
  • 사용자 개입 없이 데이터 스트림 변형시키기에 적합

- 복잡한 상호작용이 필요한 정보관리시스템이나 인터랙티브 시스템에는 적합하지 않음

- 장점 : 단순성, 재사용, 병렬성

- 단점 : 자원의 낭비 (데이터가 여러 곳에 저장되고, 각 필터는 입/출력 형식으로 변환해야 함.)

 

 

3. Clean Architecture

3.1 클린 아키텍쳐

-  마이크로서비스 아키텍쳐나 서버리스 등 현대의 아키텍쳐들의 주요 이슈

  • 관심의 분리 (Separation of Concerns)
  • 테스트 가능성 (Testability)

- 이런 요구를 만족하는, 추상화 개념으로 관심사를 분리시키고 의존도를 낮추는 것에 목적을 둔 아키텍쳐

- 의존도를 낮추고 서로에게 주는 영향이 감소되면 유지보수성이 향상됨 ➡️ 비용 절감 효과

- 클린 아키텍쳐 (Clean Architecture)

  • Robert C.Martin가 Clean code와 함꼐 제안한 시스템 아키텍쳐
  • 기존의 계층형 아키텍쳐가 가지던 의존성을 벗어나도록 설계를 제공
  • 기본적인 원리는 종속성 규칙 (Dependency rule)
    • 각 코드의 종속성은 외부에서 내부로 안쪽으로만 가리킬 수 있고, 고수준 정책이 저수준 정책의 변경에 영향을 받지 않도록 해야 한다는 것
    • 의존관계 역전의 원칙 (DIP)을 달성

 

3.2 클린 아키텍쳐의 레이어

- 레이어 구조

- 클린 아키텍쳐의 경계(boundary)

  • 소프트웨어 요소를 서로 분리
  • 경계의 바깥으로 갈수록 덜 중요하고 세부적인 사항, 안으로 갈수록 좀 더 추상화된 고수준으로 표현

 

3.3 주요 원칙

- Dependency rule (종속성 규칙)

  • 종속성의 흐름을 제어하기 위한 것
  • 캡슐화를 통해 내부 계층을 외부 계층과 분리시킴
  • 내부는 외부를 모르게 하며 영향을 받지 않도록 종속성의 흐름을 제어

- Abstraction principle (추상화 원리)

  • 가장 안쪽에 있는 계층이 제일 추상회된 영역
  • 바깥으로 향할수록 내부 계층을 활용하여 세부사항 구현

- SOLID

- 클린 아키텍쳐의 원칙 (요약)

  • 안으로 갈수록 변경 가능성이 낮아야 한다.
  • 외부 영역은 내부 영역에 의존할 수 있지만, 내부 영역은 외부 영역에 의존할 수 없다.
  • 프레임워크에 의존하지 않는다. (프레임워크 때문에 내부의 로직이 좌우되면 안 된다.)
  • 유스케이스는 아키텍쳐에서 최우선이다 ➡️ 클린 아키텍쳐의 핵심이 되는 요소는 유스케이스