[Software Engineering] 아키텍처 설계(구조 설계)

아키텍처 설계(구조 설계)와 디자인 패턴

시스템 아키텍처(큰 틀, 큰 덩어리, 큰 그림, 숲) ~ 클래스의 묶음

 - 소프트웨어를 그룹(서브시스템) 수준에서 덩어리화 하는 작업

 - 즉, 구성 요소와 구성 요소 간의 통신에 관한 것이며 클래스 수준 이상의
   그루핑과 역할, 인터페이스를 정의하는 작업

   (컴포넌트와 인터페이스를 정의 및 시각화)

 - 예를 들어, 웹 기반 시스템의 아키텍처는 클라이언트 서버

 - 아키텍처는 프로젝트 초기의 설계 결정으로 시스템 개발 및 유지보수
   전반에 걸쳐 지속적인 영향력을 가짐

 - 이해당사자(고객, 개발자 등)들과의 상호 이해, 협상, 동의 및 의사 교환을 위한 도구

 - 따라서 시스템에 관련 있는 이해당사자들의 요구사항을 고려하여 정의해야 함

 - 아키텍처를 표현하는 가장 강력한 방법: 계층적 분할

 - 기본 원리: 모듈화, 추상화, 단계적 분해, 정보 은닉

 - 필수적인 요소: 클래스 다이어그램, 소프트웨어 컴포넌트

 - 비기능적 요구사항을 만족하는데 좋은 아키텍처가 필수

 

소프트웨어 아키텍처의 4+1 관점(view)

 

유스케이스 관점	다른 뷰를 검증하는데 사용 ,외부 행위자, 설계자, 개발자, 테스트 관점	유스케이스 다이어그램
논리적 관점 (설계자 관점)	시스템 기능 적인 요구사항이 어떻게 제공되는지 클래스나 컴포넌트의 종류와 관계를 설명하고 설계가 실제로 구현 되는지 설명 (순서도나 UML 그리는 시점)	클래스/시퀀스 다이어그램
프로세스 관점 (시스템 통합자 관점)	시스템의 비기능적인 속성으로 자원의 효율적인 사용, 병행 실행, 비동기, 이벤트 처리 등을 표현한 관점 성능, 확장성, 효율성 관련	시퀀스/협력 다이어그램
구현 관점 (개발자 관점)	개발 환경 안에서 정적인 소프트웨어 모듈의 구성을 보여주는 관점 컴포넌트 구조와 의존성을 보여주고 컴포넌트에 관한 부가적인 정보 정의 실제 구현할 수 있는지 여부를 확인	컴포넌트 다이어그램
배치(배포) 관점	컴포넌트가 물리적 환경에서 배치 연결 작업이 어떻게 실행 되는지를 매핑해서 보여주는 관점	배치(배포) 다이어그램

 

아키텍처 스타일

• 비기능적 요구사항을 만족하는데 좋은 아키텍처가 필수
• 아키텍처 설계 스타일 중에서 검증된 스타일을 정하는 작업
• 클라이언트 서버 아키텍처
  • 서버, 서비스, 클라이언트로 구성되며, 서브시스템들이 서버에게 서비스를 요청하면서 상호작용한다.
  • 장점
    • 모든 데이터는 서버에 모아서 데이터의 구성과 관리를 단순화하여 데이터의 백업과 변경이 쉽다.
    • 인증을 마친 클라이언트만 특정 서비스에 접근할 수 있도록 하여 보안성이 높다.
  • 단점
    • 서버와 통신하려는 클라이언트가 증가하면 병목이 발생한다.
    • 설치 및 관리 비용이 일반적으로 높다.
    • 서버가 고장나면 클라이언트는 서버가 복구될 때까지 작동할 수 없다.

• 계층형 스타일
  • 기능을 수직으로 상호 작용하는 여러 층으로 분할 (인접한 계층만 접근 가능)
    
  • 장점
    • 시스템에 대하여 좋은 추상적인 관점을 제공한다.
    • 자세한 데이터나 메소드, 자원, 구현 등이 캡슐화 되어 층 사이에 가정하거나 이해하여야 할 사항이 적다.
      • 각 층의 응집이 높고 층 사이에 결합이 적다.
  • 단점
    • 이웃 층과의 커뮤니케이션이 제한적
• 이벤트 기반 아키텍처
  • 이벤트 생산자, 이벤트 처리기, 이벤트 소비자
    • 장점
      • 이벤트의 생산자와 소비자가 분리되어 캡슐화된다.
      • 시스템에 새 소비자를 쉽게 추가할 수 있다.
    • 단점
      • 상태에 따라 복잡하고 정교한 제어가 필요하다.
      • 테스팅이 복잡하다.
• MVC
  • MVC는 모델, 뷰, 컨트롤러라는 세 가지 구성 요소로 나누어 관리하는 아키텍처 스타일로 대화형 모델에 적합하다. 모델은 데이터를 담당하고 뷰는 사용자에게 정보를 보여주는 부분이며 컨트롤러는 사용자의 입력을 받아 처리하고, 그에 따라 모델을 업데이트하거나 뷰를 갱신하는 역할을 한다.
  • 모델: 데이터베이스
  • 뷰: UI
  • 컨트롤러: 제어, 비즈니스 로직

• 장점
  • 각 컴포넌트의 결합이 약해 확장성이 좋다.
  • 데이터와 비즈니스 로직이 분리되어 있어 코드 중복이 적다.
• 단점
  • 복잡도가 올라갈 수 있으며 뷰에서 데이터를 접근해야 하는 비효율적인 부분이 있다.

사용자가 화면에서 버튼을 누르면, 컨트롤러가 그 입력을 받아 모델을 업데이트하고, 그 결과를 뷰에 표시하는 대화형 상호작용

 

• 파이프 필터(데이터 흐름 모델)
  • 필터에 해당되는 서브시스템이 하나의 데이터를 입력으로 받아 처리한 후 그 결과를 다음 서브시스템으로 넘겨주는 과정을 반복하는 모델
  • 장점: 단순하다, 재사용성이 높다, 병렬 처리로 구현하기 쉽다.
  • 단점: 시간과 공간을 낭비할 수 있다.

 

• 데이터 중심 아키텍처

• 공유된 자료가 중요한 시스템에서 채택하는 스타일
• 공유 데이터 저장소
• 장점: 접근자 간의 통신은 공유 데이터 저장소를 통해서만 이루어지므로 느슨한 결합을 유지할수 있으며 확장성이 높다.
• 단점: 공유 데이터 저장소의 장애로 인해 전체 시스템에 장애가 발생할 수 있다.

 

• Peer-to-Peer 스타일(P2P): uTorrent, 블록체인 기술

• 클라이언트 동시에 서비스를 제공하는 서버 역할
• 동일한 수신, 전송 데이터 양을 가지므로 대칭적인 시스템
• 장점: 전담하는 어플리케이션이나 서버가 없음, 컴포넌트에 고장이 있더라도 전체 시스템은 가동됨
• 단점: 보안 취약, 중앙 제어 불가, 성능 저하