10.소프트웨어 공학 아키텍처 설계

1. 아키텍처 설계

아키텍처 설계

아키텍처

• 건물의 뼈대뿐 아니라 특성을 결정짓는 기본 구조를 일컫는 말
• 아키텍처는 모든 기술 분야에 적용할 수 있고 종류도 다양함

아키텍처의 필요성

복합성의 문제

• 대형 프로젝트는 전체 시스템의 구조를 생각하며 균형과 조화를 이루도록 설계
• 대형 프로젝트가 복합성의 문제를 해결하는 방법
  • 개발할 소프트웨어의 전체 구조를 가장 먼저 생각
  • 소프트웨어의 구조를 이루는 각 구성 요소를 찾음
  • 각 구성 요소 간의 명확한 관계를 설정
  • 일정한 규칙을 따름

아키텍처의 필요성

• 복잡하고 규모가 큰 소프트웨어를 개발하려면 전체적인 구조가 유기적으로 잘 구성되어야 함
• 잘 정의된 구조의 품질 좋은 소프트웨어를 만 들려면 소프트웨어 아키텍처가 필요
• 아키텍처 설계로 소프트웨어가 어떤 구조이고 어떻게 동작할 것인지를 예측할 수 있으며, 변경에 유연하게 대처 가능

아키텍처의 특징과 기능

아키텍처의 특징

• 소프트웨어의 골격을 나타내는 추상화된 전체 구조를 제공
• 소프트웨어를 이루고 있는 여러 구성 요소(서브시스템, 컴포넌트)를 다룸
• 인터페이스를 통해 소프트웨어의 구성 요소가 어떻게 상호작용하는지를 정의
• 세부 내용보다는 중요 내용(설계자가 주관적으로 판단하고 결정)만 다룸
• 설계에 적용되는 원칙과 지침이 있음

아키텍처 설계 시 고려 사항

• 모든 이해관계자 사이의 의사소통 도구로 활용할 수 있어야 함
• 구현에 대한 제약 사항(개발 비용, 기간, 조직의 역량 등)을 정의해야 함
• 모든 이해관계자의 품질 요구사항을 반영해 우선순위에 따라 시스템 품질 속성을 결정해야 함
• 성능, 사용성, 보안성, 안정성, 검증 가능성, 변경 용이성 등
• 특정 문제 영역에 적합한 소프트웨어의 구성 요소를 표준화하고 패턴화해 재사용할 수 있도록 설계해야 함

아키텍처의 기대 효과

• 소프트웨어의 기본 골격이 만들어져 개발에 참여하는 사람들의 이해의 폭이 넓어지며 구현상의 문제점을 도출할 수 있음
• 소프트웨어 아키텍처를 기반으로 분할 방법을 찾고 구조화를 위한 구체적인 방안을 생각할 수 있음
• 설계의 원칙과 가이드를 제공할 수 있고 설계를 재사용할 수 있음
• 소프트웨어 아키텍처를 기준으로 개발 조직을 만들 수 있음
• 전사 조직을 소프트웨어 아키텍처에 맞게 재편할 수 있음
• 품질 특성에 대한 평가 방법을 결정할 수 있음

아키텍처의 품질 속성

품질 속성의 개요

• 사용성, 이식성, 유지보수 용이성과 같이 이해관계자의 요구사항과 관심사를 반영한 것
• 품질 요구사항: 이해관계자들이 아키텍처에 요구하는 수준의 품질 속성, 가능한 정확한 수치로 제시되는 것이 좋음

품질 속성을 반영하는 방법

① 해당 프로젝트에서 중요하게 생각하는 품질 속성을 결정 ② 결정한 품질 속성을 어느 정도 수준으로 설계할 것인지 목표를 설정 ③ 설정한 목표를 달성할 수 있는 방법을 서술 ④ 품질 속성을 평가할 방법을 서술

예시) 중요한 품질 속성으로 보안성을 결정할 경우

• 계층 구조 아키텍처를 선택하고 보호 해야 할 요소를 가장 깊숙한 내부 계층에 둠
• 이 계층의 데이터는 높은 등급의 보안 인증을 통과해야만 사용할 수 있도록 설계

시스템 품질 속성

가용성

• 시스템이 실패 없이 운용될 수 있는 확률로 시스템이 장애 발생 없이 서비스를 제공할 수 있는 능력
• 가용성이 99.99%라면 제대로 동작하지 않을 확률이 0.01%라는 의미
• 하드웨어는 가용성을 높이기 위해 이중화 설계를 함
• 이중화 설계: 하나의 시스템이 중단 되어도 바로 또 다른 시스템이 가동

변경 용이성

• 사용자가 새로운 요구사항을 요청했을 때 얼마나 쉽게 변경할 수 있는지를 말함
• 변경 용이성을 위해서는 추적이 가능하도록 아키텍처를 설계해 변경 발생 시 영향이 미치는 곳을 쉽게 찾을 수 있어야 함
• 변경이 자주 발생하는 소프트웨어는 아키텍처를 설계할 때 변경 용이성을 다른 품질 속성보다 우선으로 고려

성능

• 사용자 요청과 같은 이벤트가 발생했을 때 얼마나 빠르고 효율적으로 기능을 수행 할 수 있는가를 말함
• 성능이 좋고 나쁨은 사용자 요청에 관한 결과를 제공하는 대기시간이나 초당 처리할 수 있는 트랜잭션의 수로 표현
• 성능이 중요한 소프트웨어 라면 공유 자원을 어떻게 사용해서 설계하는지와 어떤 알고리즘을 선택하는지가 중요

보안성

• 허용되지 않은 접근에 대응할 수 있는 능력
• 시스템 접근의 적법성을 가려서 승인되지 않은 사용을 차단하고 올바른 사용자에게 서비스가 제공될 수 있게 설계
• 네트워크를 통해 데이터를 주고받을 때는 보안유지를 위해 DoS 공격을 실시간으로 탐지해야 하고 회피 전략을 설립
• 보안성 속성이 중요하다면 인증받은 일부만 접근할 수 있도록 계층 구조 아키텍처를 사용해 가장 안쪽 계층에 자료를 저장

사용성

• 시스템을 사용할 때 발생할 수 있는 여러 가지 상황을 극복할 수 있도록 이를 반영해 아키텍처 설계 작업을 해야함
• 시스템의 도움말 기능은 사용자에게 실제 도움을 줄 수 있어야 함
• 사용자가 원치 않는 상황에 놓인 경우에도 친숙한 사용자 인터페이스를 제공해 당황하지 않도록 설계해야 함
• 사용자의 실수에도 오류의 영향을 최소화하도록 되돌리기나 취소 기능을 제공해야 함

테스트 용이성

• 테스트 비용을 줄이기 위해서는 아키텍처 설계부터 테스트를 고려해야 함
• 테스트가 얼마나 효과적으로 수행되는지, 소요되는 시간을 얼마나 단축할 수 있는지 와 같은 요소를 아키텍처 설계에 반영

비즈니스 품질 속성

시장 적시성

• 적정한 시기에 소프트웨어를 출시해 경쟁력을 높이는 것
• 아키텍처 설계를 할 때 구매한 컴포넌트들이 잘 맞을 수 있도록 범용성 높은 설계가 필요

비용과 이익

• 아키텍처를 설계할 때 비용을 많이 들여 유연한 설계를 할 것인지, 비용을 절감해 이익을 높일 것인지 판단
• 개발 시점에서 비용을 더 들여 유연한 시스템을 만들면 나중에 수정 및 유지보수가 쉬운 시스템
• 비용 절감에 초점을 두면 우선 개발 비용이 적게 드는 효과는 있지만, 유지보수를 할 때 비용 증가

예상 시스템 수명

• 시스템을 구축할 때는 시스템 사용 기간을 예측해 아키텍처 설계에 반영
• 예상 시스템 수명을 위해서는 확장성, 이식성과 같은 아키텍처 품질 속성을 고려해야 함

목표 시장

• 목표 시장이 있는 소프트웨어는 경쟁 제품과 비교했을 때 기능성이 매우 중요
• 다양한 플랫폼에서 잘 작동해야 하므로 시스템 품질 속성 중 이식성을 충분히 고려해야 함

신규 발매(공개) 일정

• 공지한 일정에 개발을 못 맞출 경우에는 현재  전에서는 기본 기능만 제공하고 차기 버전에서 기능을 추가해 완성도를 올림
• 아키텍처 설계 시 유연성과 확장성을 중요하게 고려해야 함

기존 시스템과의 통합

• 개발할 시스템을 기존 시스템과 통합해야 한다면 기존 시스템의 특성을 잘 파악해야 함
• 기존에 사용하던 DBMS나 개발 시 제약 사항을 충분히 고려한 아키텍처 설계가 필요

아키텍처 품질 속성

개념적 무결성

• 시스템 설계는 전체 시스템을 나타내는 설계와 세부 구성 요소 설계로 나뉨
• 세부 구성 요소를 전체 시스템으로 통합하더라도 일관성이 유지되어야 하기 때문
• 전체 시스템과 시스템 구성 요소가 일관되도록 아키텍처를 결정해야 함

정확성과 완전성

• 정확성과 완전성은 사용자가 요구하는 기능을 충족시키는 정도를 말하며 요구분석명세 와 일치하는 정도를 나타냄

개발 용이성(구축 가능성)

• 전체 시스템을 적절한 모듈로 분할한 후 알맞게 분배해 개발함으로써 정해진 기간 내에 개발을 완성할 수 있고 개발 과정 중에도 쉽게 변경 할 수 있는 능력을 말함

아키텍처의 4+1 관점

4+1 관점

• 관점: 시스템을 이루는 요소의 집합과 그들의 연관 관계를 추상적으로 표현한 것
• 4+1 관점은 크루첸이 1995년에 쓴 논문에 처음 등장
• 문제 영역의 1개 관점(시나리오 관점)과 해법 영역의 4개 관점(논리적 관점, 프로세스 관점, 개발 관점, 물리적 관점)으로 이루어짐

시나리오(유스케이스) 관점

• 최종 사용자가 인식하는 시스템의 기능을 의미
• 시스템이 사용자에게 제공하는 기능에 주목하는 관점
• 기능 하나하나가 유스케이스로 표현되기 때문에 유스케이스 관점이라 할 수 있음
• 사용 다이어그램
  • 정적 표현: 유스케이스 다이어그램
  • 동적 표현: 상태 다이어그램, 순차 다이어그램, 통신 다이어그램, 활동 다이어그램

논리적(디자인) 관점

• 시스템의 기능에 관심이 있는 유스케이스 관점과 달리 시스템 내부를 들여다봄
• 시스템의 기능을 제공하기 위해 필요한 클래스나 컴포넌트 및 이들의 관계에 초점
• 사용 다이어그램
  • 정적 표현: 클래스 다이어그램, 객체 다이어그램
  • 동적 표현: 상태 다이어그램(클래스 내의 동작 표현), 순차·통신 다이어그램(클래스 간 상호 작용 표현), 활동 다이어그램(클래스의 연산 동작 표현)

개발(구현) 관점

• 물리적 시스템에서 사용하는 소프트웨어 서브시스템의 모듈(원시 코드, 데이터 파일, 컴포넌트, 실행 파일 등으로 구성)이 서로 어떤 연관 관계가 있고 또 설계와 어떻게 연결 관계를 나타내는지에 관심
• 사용 다이어그램
  • 정적 표현: 컴포넌트 다이어그램
  • 동적 표현: 상태 다이어그램, 순차·통신 다이어그램, 활동 다이어그램

물리적(배치) 관점

• 시스템에서 필요한 하드웨어 환 경을 포함해 시스템을 구성하는 처리 장치 간의 물리적인 배치에 초점

사용 다이어그램

• 정적 표현: 배치 다이어그램
• 동적 표현: 상태 다이어그램, 순차 다이어그램, 통신 다이어그램, 활동 다이어그램

아키텍처 스타일

• 아키텍처 스타일은 각각의 특징이 있고 해당 스타일만의 구성과 모양을 가지고 있음

데이터 중심형 스타일

• 가장 큰 특징은 주요 데이터가 리포지토리에서 중앙 관리된다는 점
• 리포지토리와 여기에 접근하는 서브시스템으로 구성
• 시스템에서 공동으로 활용하는 데이터는 리포지토리에 보관
• 대량의 데이터를 공유하는 은행 업무 시스템에 매우 유용
• 서브시스템과 리포지토리의 결합도가 높아 리포지토리를 변경하면 서브시스템에 영향을 줄 수 있다는 단점

클라이언트-서버 스타일

• 네트워크를 이용하는 분산 시스템 형태로 데이터와 처리 기능을 클라이언트와 서버에 분할해 사용
• 서버, 서비스, 클라이언트로 구성되며 서브시스템(컴포넌트)이 서비스를 서로 요청하면서 상호작용

서버 특성

• 클라이언트(서브시스템)에 서비스를 제공하는 역할을 하므로 클라이언트의 요청을 처리하기 위해 대기
• 요청을 처리한 후에는 결과를 클라이언트에 회신
• 프린트 서버, 파일 및 FTP 서버, 메일 서버, DNS 서버 등이 이에 해당

클라이언트 특성

• 사용자와 대화하기 위해 서버가 제공하는 서비스를 요청(호출)하는 서브시스템
• 메시지나 원격 프로시저 호출을 통해 서비스를 요청하고 서버가 이 요청을 받아 수행하면 그 결과를 클라이언트에게 전송
• 클라이언트가 서버에 서비스를 요청할 때는 서버의 이름과 제공서비스를 알아야 함
• 인터넷을 통해 웹서버와 통신해 웹 페이지를 다운로드하고 사용자에게 보여주는 웹브라우저가 해당

클라이언트-서버 스타일(비중의 분산)

씬 클라이언트 스타일

• 데이터 관리가 서버에서 수행되며 클라이언트는 프레젠테이션 계층만 구현
• 데이터 관리가 거의 필요 없는 애플리케이션이나 응용 처리가 거의 필요 없는 데이터 중심의 애플리케이션의 경우에 적합
• 서버와 네트워크에 걸리는 부하가 큰 것이 단점

팻 클라이언트 스타일

• 서버에서 데이터 관리만 관여하고 애플리케이션로직 과 프레젠테이션의 많은 부분이 클라이언트 쪽에서 구현
• 클라이언트에 더 많은 부하가 걸릴 수밖에 없으므로 클라이언트 컴퓨터의 사양이 충분할 경우에 사용
• 씬 클라이언트 스타일보다 관리하기가 복잡하고 새로운 버전이 출시되면 모든 클라이언트에 배포 및 설치해야 함

계층 스타일

• 기능을 몇 개의 계층으로 나누어 배치
• 데이터베이스를 많이 이용하는 소프트웨어는 3-계층으로 구성
• 각 계층의 응집도는 높고 계층 간 결합도는 낮아 재사용 및 유지보수가 용이한 것이 장점
• 계층 간 역할 분담이 명확해 각 계층을 쉽게 변경할 수 있음
• 대부분의 운영체제와 통신 시스템이 계층 스타일을 이용

프레젠테이션

• 클라이언트 계층으로서 사용자와 직접 만나는 화면에 해당
• 사용자 인터페이스를 지원하며 front-end 라고도 함

비즈니스 로직 계층

• 기능 요구사항을 구현하는 곳으로 미들웨어 라고도 함
• 애플리케이션 로직을 실행하고 또 어떤 형태의 데이터가 필요하고 반환될 것인지를 결정

데이터 계층

• 데이터베이스에 접근해 데이터 처리와 관리를 하며 필요한 데이터를 제공
• back-end 라고도 함

MVC 스타일 (Model-View Controller)

• 구성요소를 기능별 또는 특성별로 명확하게 분리해 유지보수를 쉽게 하고 프로그램의 확장성과 유연성을 높임
• 모델, 뷰, 제어의 세 부분으로 이루어짐
• 뷰와 모델을 독립적으로 분리해 변경에 대한 영향이 덜 미치도록 한 것이 장점
• 약한 결합으로 설계하여 서로 영향을 덜 미치기 때문에 구조 변경을 요청할 때 수정하기가 쉬움

① 사용자는 제어에게 자료를 요청하거나 처리할 데이터를 전송

② 제어는 이를 처리하기 위해 모델을 호출

③ 모델은 DBMS를 이용해 데이터베이스의 자료를 수정하고 그 결과를 제어에게 반환

④ 제어는 사용자가 요청한 결과를 모델로부터 가져와 뷰를 호출하고 결과를 전달

⑤ 뷰는 처리 결과를 여러 형태(테이블, 그래프, 액셀 등)로 사용자에게 공개

데이터 흐름 스타일

• 서브시스템이 하나의 데이터를 입력으로 받아서 처리한 후 그 결과를 다음 서브시스템으로 넘겨주는 과정을 반복함
• 일반적으로 데이터를 변환하는 시스템에서 주로 사용하며, 전체 변환 작업은 독립적인 단계로 나뉠 수 있음
• 파이프와 필터를 조합해 만드는 아키텍처에 적합하고 사용자의 개입 없이 데이터 흐름이 전환되는 경우에 사용

• 필터 또는 파이프 단위로 나누어 개발할 수 있기 때문에 동시에 개발이 가능하다는 것이 장점

• 필터: 데이터 스트림을 하나 이상 입력받아 처리(변환)한 후 데이터 스트림 하나를 출력, 하나의 필터는 여러 포트로 데이터를 보낼 수 있음
• 파이프: 필터를 거쳐 생성된 데이터 스트림 하나를 다른 필터의 입력에 연결

아키텍처 스타일의 장점

1. 개발 기간 단축 및 고품질의 소프트웨어 생산
   • 시행착오를 줄임으로써 개발 기간을 많이 단축 할 수 있고 고품질의 소프트웨어를 만들 수 있음
2. .수월한 의사소통
   • 아키텍처에 익숙한 개발자끼리 공통된 아키텍처를 공유함으로써 의사소통이 수월해짐
3. 용이한 유지보수
   • 개발에 참여하지 않은 사람이라도 비즈니스 로직만 잘 이해하고 있으면 유지 보수의 어려움을 많이 줄일 수 있음
4. 검증된 아키텍처
   • 사용을 통해 이미 검증된 아키텍처 스타일이므로 안정적으로 개발할 수 있음
5. 구축 전 시뮬레이션 가능
   • 이미 알려진 아키텍처 스타일을 이용하면 시스템을 개발하기 전에 시스템 특성을 시뮬레이션해볼 수 있음
6. 기존 시스템에 대한 빠른 이해
   • 기존 시스템이 어떤 아키텍처 스타일로 개발되었는지 알면 그 시스템을 더 빨리 이해할 수 있음