소프트웨어 공학 Chapter06

9 minute to read

Architectural design

아키텍처 설계는 소프트웨어 시스템이 어떻게 구성되어야 하는지를 이해하고 그 시스템의 전체 구조를 설계하는 것과 관련이 있습니다. 아키텍처 설계는 시스템의 주요 구조적 요소들과 그것들 사이의 관계를 식별하기 때문에 설계와 요건 공학 사이의 중요한 연결고리 입니다. 아키텍처 설계 과정의 산출물은 시스템이 통신요소로 어떻게 구성되어 있는지를 기술하는 구조모델입니다.

Architectural abstraction

소규모 아키텍처는 개별 프로그램의 아키텍처와 관련이 있습니다. 이 수준에서 우리는 개별 프로그램이 구성 요소로 분해되는 방식에 관심이 있습니다.

아키텍처는 다른 시스템, 프로그램 및 프로그램 구성 요소를 포함하는 복잡한 엔터프라이즈 시스템의 아키텍처와 관련이 있습니다. 이러한 엔터프라이즈 시스템은 다른 회사에서 소유하고 관리 할 수 있는 여러 컴퓨터에 배포됩니다.

명시적 아키텍처의 장점

이해 관계자와 커뮤니케이션

아키텍처는 시스템 이해 관계자가 토론의 초점으로 사용할 수 있습니다.

시스템 분석

시스템이 비 기능적 요구사항을 충족할 수 있는지 여부를 분석 할 수 있음을 의미합니다.

대규모 재사용

아키텍처는 다양한 시스템에서 재사용 가능합니다.

Architectural representation

엔티티와 관계를 보여주는 단순하고 비공식적인 블록 다이어그램은 소프트웨어 아키텍처를 문서화하는 데 가장 자주 사용되는 방법입니다.

그러나 이들은 의미론이 부족하고 엔티티 간의 관계 유형이나 아키텍처에서 엔티티의 가시적 속성을 표시하지 않기 때문에 비판을 받았습니다.

Box and line diagram

  • 매우 추상적
    • 구성 요소 관계의 특성이나 하위 시싀템의 외부에서 볼 수 있는 속성을 표시하지 않습니다.
  • 이해 관계자와의 의사 소통 및 프로젝트 계획에 유용함

User of Architectural models

시스템 설계에 대한 토론을 촉진하는 방법

높은 수준의 아키텍쳐 뷰는 세부 사항으로 복잡하지 않기 때문에 시스템 이해 관계자와의 커뮤니케이션 및 프로젝트 계획에 유용합니다. 이해 관계자들은 그것에 관련되어 시스템의 추상적인 관점을 이해할 수 있습니다. 그런 다음 세부 사항에 혼동하지 않고 시스템 전체를 논의 할 수 있습니다.

설계된 아키텍처를 문서화 하는 방법

여기서 목표는 시스템의 다양한 구성 요소, 해당 인터페이스 및 연결을 보여주는 완전한 시스템 모델을 생성하는 것입니다.

Architectural design decision

Architectural design decisions

아키텍처 설계는 창의적인 과정이므로 개발중인 시스템 유형에 따라 과정이 다릅니다. 그러나 모든 설계 프로세스에 공통된 여러 가지 결정이 적용되며 이러한 결정은 시스템의 비 기능적 특성에 영향을 미칩니다.

시스템 구조에 영향을 줄 수 있는 디자연 결정 중 기본적인 질문들

  • 설계중인 시스템의 템플릿 역할을 할 수 있는 일반적인 애플리케이션 아키텍처가 있습니까?
  • 시스템이 하드웨어 코어 또는 프로세서에 어떻게 분산됩니까?
  • 어떤 아키텍처 패턴이나 스타일을 사용할 수 있습니까?
  • 시스템 구성 요소의 작동을 제어하기 위해 어떤 전략이 사용됩니까?
  • 시스템 아키텍처를 어떻게 문서화해야 합니까?
  • 시스템의 비 기능적 요구사항을 제공하는데 가장 적합한 아키텍처 조직은 무엇입니까?
  • 시스템의 구조적 구성 요소는 어떻게 하위 구성 요소로 분해됩니까?
  • 시스템을 구성하는데 사용되는 기본 접근 방식은 무엇입니까?

Architecture reuse

  • 동일한 도메인의 시스템은 종종 도메인 개념을 반영하는 유사한 아키텍처를 갖습니다.
  • 애플리케이션 제품 라인은 특정 고객 요구 사항을 충족하는 변형이 있는 핵심 아키텍처를 중심으로 구축됩니다.
  • 시스템의 아키텍처는 하나 이상의 아키텍처 패턴 또는 ‘스타일’ 중 하나를 중심으로 설계될 수 있습니다.
  • 이들은 아키텍처의 본질을 포착하고 다양한 방식으로 인스턴스화 할 수 있습니다.

Architecture and system characteristic

  • 성능
    • 중요한 작업을 현지화하고 통신을 최소화합니다. 작은 단위 보다는 큰 단위의 구성 요소를 사용하십시오
  • 보안
    • 내부 계층에 중요한 자산이 있는 계층화 된 아키텍처를 사용합니다.
  • 안전
    • 소수의 하위 시스템에서 안전에 중요한 기능을 현지화합니다.
  • 가용성
    • 내결함성을 위한 중복 구성 요소 및 메커니즘을 포함합니다.
  • 유지 관리
    • 세밀하고 교체 가능한 구성 요소를 사용합니다.

Architectural view

Architectural views

  • 시스템 아키텍처를 설계하고 문서화 할 때 유용한 보기 또는 관점은 무엇입니까?
  • 아키텍처 모델을 섦여하는 데 어떤 표기법을 사용해야 합니까?
  • 각 아키텍처 모델은 시스템에 대한 하나의 보기 또는 관점만 표시합니다.
    • 시스템이 모듈로 분해되는 방식, 런타임 프로세스가 상호 작용하는 방식 또는 시스템 구성 요소가 네트워크를 통해 배포되는 다양한 방식을 보여줄 수 있습니다. 설계 및 문서화의 경우 일반적으로 소프트웨어 아키텍처에 대한 여러 관점을 제시해야 합니다.

4 + 1 View Model

  • Logical View
    • 시스템의 주요 추상화를 개체 또는 개체 클래스로 표시
    • 정적 모델
      • 클래스 다이어그램
    • 동적 모델
      • 시퀀스 다이어그램
      • 상태 다이어그
      • 액티비티 다이어그램
  • Process View
    • 런타임시 시스템이 상호 작용하는 프로세스로 구성되는 방식을 보여줌
    • 동적 모델
      • 시퀀스 다이어그램
      • 상태 다이어그램
      • 액티비티 다이어그램
  • Development View
    • 개발을 위해 소프트웨어가 분해되는 방식을 보여줌
    • 동적 모델
      • 시퀀스 다이어그램
      • 상태 다이어그램
      • 액티비티 다이어그램
  • Physical View
    • 시스템 하드웨어와 소프트웨어 구성 요소가 시스템의 프로세서에 분산되는 방식을 보여줌
  • 사용 사례 또는 시나리오를 사용(+1)
    • 다른 교재에는 “use case view”로 소개될 수 있음
    • 4-view 모델은 use case view를 기본으로 사용함

아키텍처의 뷰 표현

일부 사람들은 UML이 시스템 아키텍처를 설명하고 문서화하는 데 적합한 표기법이라고 주장합니다. UML에 상위 수준 시스템 설명에 적합한 추상화가 포함되어 있지 않다고 생각되므로 이에 동의하지 않습니다. 아키텍처 설명 언어(ADL)이 개발되었지만 널리 사용되지는 않습니다.

Architectural patterns

Architectural patterns

  • 패턴은 지식을 표현, 공유 및 재사용하는 수단입니다.
  • 아키텍처 패턴은 다양한 환경에서 시도되고 테스트 된 우수한 설계 사례에 대한 양식화 된 설명입니다.
  • 패턴에는 유용성과 유용하지 않은 시기에 대한 정보가 포함되어야 합니다.
  • 패턴은 표 및 그래픽 설명을 사용하여 표현할 수 있어야 합니다.

MVC 패턴

프레젠테이션과 상호 작용을 시스템 데이터와 분리합니다. 시스템은 서로 상호 작용하는 세 가지 논리적 구성 요소로 구성됩니다

  • Model
    • 시스템 데이터 및 해당 데이터에 대한 관련 작업을 관리합니다.
  • View
    • 데이터가 사용자에게 표시되는 방식을 정의하고 관리합니다.
  • Controller
    • 사용자 상호 작용을 관리하고 이러한 상호 작용을 View 및 Model에 전달합니다.

사용

데이터를 보고 상호 작용하는 여러 방법이 있을 때 사용됩니다. 데이터의 상호 작용 및 표시에 대한 향후 요구 사항을 알 수 없는 경우에도 사용됩니다.

장점

데이터가 표현과 독립적으로 변경될 수 있으며 그 반대도 가능합니다. 모든 데이터에 표시되는 하나의 표현에서 변경된 내용을 사용하여 동일한 데이터를 다른 방식으로 표현할 수 있도록 지원합니다.

단점

데이터 모델과 상호 작용이 간단한 경우 추가 코드 및 코드 복잡성이 포함될 수 있습니다.

Layered architecture

  • 하위 시스템의 인터페이스를 모델링하는 데 사용됩니다.
  • 시스템을 각각 일련의 서비스를 제공하는 일련의 계층으로 구성합니다.
  • 여러 계층에서 하위 시스템의 점진적인 개발을 지원합니다. 레이어 인터페이스가 변경되면 인접한 레이어만 영향을 받습니다.

각 계층과 관련된 관련 기능을 사용하여 시스템을 계층으로 구성합니다. 계층은 그 위에 있는 계층에 서비스를 제공하므로 최하위 계층은 시스템 전체에서 사용될 가능성이 높은 핵심 서비스를 나타냅니다.

사용

기존 시스템 위에 새로운 시설을 구축 할 때 사용됩니다. 개발이 여러 팀에 분산되어 각 팀이 기능 계층을 담당하는 경우 다단계 보안에 대한 요구사항이 있을 때 사용됩니다.

장점

인터페이스가 유지되는 한 전체 레이어를 교체할 수 있습니다. 시스템의 신뢰성을 높이기 위해 각 계층에 중복 기능을 제공 할 수 있습니다.

단점

실제로 레이어간에 깨끗한 분리를 제공하는 것은 종종 어렵고 높은 수준의 레이어는 바로 아래의 레이어를 통하지 않고 하위 수준의 레이어와 직접 상호 작용해야 할 수 있습니다. 서비스 요청이 각 계층에서 처리 될 때 여러 수준의 해석으로 인해 성능이 문제가 될 수 있습니다.

Repository Architecture

  • 하위 시스템은 데이터를 교환해야 합니다. 두 가지 방법으로 수행할 수 있습니다.
    • 공유 데이터는 중앙 데이터베이스 또는 리포지토리에 보관되며 모든 하위 시스템에서 액세스 할 수 있습니다.
    • 각 하위 시스템은 자체 데이터베이스를 유지하고 데이터를 다른 하위 시스템으로 명시적으로 전달합니다.
  • 많은 양의 데이터를 공유해야 하는 경우 공유 저장소 모델이 가장 일반적으로 사용되며 이는 효율적인 데이터 공유 메커니즘입니다.

시스템의 모든 데이터는 모든 시스템 구성 요소에 액세스 할 수 있는 중앙 저장소에서 관리됩니다. 구성 요소는 저장소를 통해서만 직접 상호작용하지 않습니다.

사용

장기간 저장해야 하는 많은 양의 정보가 생성되는 시스템이 있는 경우 이 패턴을 사용해야 합니다. 리포지토리에 데이터를 포함하면 작업이나 도구가 트리거되는 데이터 기반 시스템에서도 사용할 수 있습니다.

장점

구성 요소는 독립적일 수 있으며 다른 구성 요소의 존재를 알 필요가 없습니다. 한 구성 요소에서 변경한 내용을 모든 구성 요소에 전파할 수 있습니다. 모든 데이터가 한 곳에 있으므로 모든 데이터를 일관되게 관리할 수 있습니다.

단점

저장소는 단일 실패 지점이므로 저장소의 문제가 전체 시스템에 영향을 줍니다. 저장소를 통한 모든 통신을 구성하는데 비효율적일 수 있습니다. 여러 컴퓨터에 저장소를 배포하는 것은 어려울 수 있습니다.

Client-server Architecture

  • 데이터 및 처리가 다양한 구성 요소에 분산되는 방식을 보여주는 분산 시스템 모델
    • 단일 컴퓨터에서 구현할 수 있습니다.
  • 인쇄, 데이터 관리 등과 같은 특정 서비스를 제공하는 독립 실행형 서버 집합
  • 이러한 서비스를 호출하는 클라이언트 집합
  • 클라이언트가 서버에 액세스 할 수 있는 네트워크

클라이언트-서버 아키텍처에서 시스템의 기능은 서비스로 구성되며 각 서비스는 별도의 서버에서 제공됩니다. 클라이언트는 이러한 서비스의 사용자이며 이를 사용하기 위해 서버에 액세스합니다.

사용

공유 데이터베이스의 데이터를 다양한 위치에서 액세스해야 할 때 사용됩니다. 서버를 복제 할 수 있기 때문에 시스템 부하가 가변적일 때도 사용할 수 있습니다.

장점

이 모델의 주요 장점은 서버가 네트워크를 통해 분산 될 수 있다는 것입니다. 일반 기능은 모든 클라이언트에서 사용할 수 있으며 모든 서비스에서 구현할 필요는 없습니다.

단점

각 서비스는 단일 장애 지점이므로 서비스 거부 공격이나 서버 장애에 취약합니다. 성능은 시스템뿐만 아니라 네트워크에 따라 다르기 때문에 예측할 수 없습니다. 다른 조직에서 서버를 소유하는 경우 관리 문제가 될 수 있습니다.

Pipe and filter Architecutre

  • 기능적 변환은 입력을 처리하여 출력을 생성합니다.
  • 파이프 및 필터 모델이라고도 합니다(UNIX 셸에서와 같이)
  • 이 접근 방식의 변형은 매우 일반적입니다. 변형이 순차적인 경우 이는 데이터 처리 시스템에서 광범위하게 사용되는 일괄 순차 모델입니다.
  • 대화형 시스템에는 적합하지 않습니다.
    • 사용자 상호 작용이 제한되어 있는 일괄처리 시스템과 임베디드 시스템에 적합함

시스템에서 데이터 처리는 각 처리 구성 요소가 개별적이며 한가지 유형의 데이터 변환을 수행하도록 구성됩니다. 데이터는 처리를 위해 한 구성 요소에서 다른 구성 요소로 파이프처럼 흐릅니다.

사용

입력이 별도의 단계에서 처리되어 관련 출력을 생성하는 데이터 처리 애플리케이션(배치 기반 및 트랜잭션 기반 모두)에서 일반적으로 사용됩니다.

장점

이해하기 쉽고 변환 재사용을 지원합니다. work-flow 스타일은 많은 비즈니스 프로세스의 구조와 일치합니다. 변형을 추가하여 진화하는 것은 간단합니다. 순차 또는 동시 시스템으로 구현할 수 있습니다.

단점

데이터 전송 형식은 통신 변환간에 합의되어야 합니다. 각 변환은 입력을 구문 분석하고 합의 된 형식으로 출력을 구문 분석 해제해야 합니다. 이는 시스템 오버 헤드를 증가시키고 호환되지 않는 데이터 구조를 사용하는 기능적 변환을 재사용하는 것이 불가능함을 의미할 수 있습니다.

Application architectures

Application Architecture

  • 응용 프로그램 시스템은 조직의 요구를 충족하도록 설계되었습니다.
  • 기업은 공통점이 많으므로 애플리케이션 시스템도 애플리케이션 요구 사항을 반영하는 공통 아키텍처를 갖는 경향이 있습니다.
  • 일반 애플리케이션 아키텍처는 특정 요구 사항을 충족하는 시스템을 만들기 위해 구성 및 조정할 수 있는 소프트웨어 시스템 유형에 대한 아키텍처입니다.
    • 특정 요구사항을 충족시키는 시스템을 제작할 때 일반 어플리케이션 구조가 적용될 수 있음

Use of Application architecture

  • 아키텍처의 시작점
  • 디자인 체크리스트
    • 설계가 일반적인 아키텍처와 일치하는지 점검
  • 개발 팀의 작업을 구성하는 방법
  • 재사용을 위해 구성 요소를 평가하는 수단
  • 응용 프로그램 유형에 대해 말하기 위한 어휘

애플리케이션 유형의 예

  • 데이터 처리 애플리케이션
    • 처리 중에 명시적인 사용자 개입 없이 데이터를 일괄 처리하는 데이터 기반 응용 프로그램
  • 트랜잭션 처리 애플리케이션
    • 사용자 요청을 처리하고 시스템 데이터베이스에서 정보를 업데이트하는 데이터 중심 응용 프로그램
  • 이벤트 처리 시스템
    • 시스템 작업이 시스템 환경의 이벤트 해석에 의존하는 응용 프로그램
  • 언어 처리 시스템
    • 사용자의 의도가 시스템에서 처리되고 해석되는 공식 언어로 지정된 응용 프로그램

매우 널리 사용되는 두 가지 일반 애플리케이션 아키텍처는 트랜잭션 처리 시스템과 언어 처리 시스템입니다.

  • 트랜잭션 처리 시스템
    • 전자상거래 시스템
    • 예약 시스템
  • 언어 처리 시스템
    • 컴파일러
    • 명령 인터프리터

트랜잭션 처리 시스템

  • 데이터베이스의 정보에 대한 사용자 요청 또는 데이터베이스 업데이트 요청을 처리합니다.
  • 사용자 관점에서 트랜잭션은 다음과 같습니다
    • 목표를 충족하는 일관된 작업 순서
    • 예를 들어 런던에서 파리까지의 항공편 시간을 찾는 것
  • 사용자는 서비스에 댛나 비동기 요청을 한 다음 트랜잭션 관리자가 처리합니다.

정보 시스템 아키텍쳐

정보 시스템에는 계층 구조로 구성할 수 있는 일반 아키텍처가 있습니다. 이러한 시스템과의 상호 작용에는 일반적으로 데이터베이스 트랜잭션이 포함되므로 트랜잭션 기반 시스템입니다.

레이어에는 다음이 포함됩니다

  • 사용자 인터페이스
  • 사용자 커뮤니케이션
  • 정보 검색
  • 시스템 데이터베이스

웹 기반 정보 시스템

정보 및 리소스 관리 시스템은 이제 일반적으로 웹 브라우저를 사용하여 사용자 인터페이스를 구현하는 웹 기반 시스템입니다.

  • 예를 들어 전자 상거래 시스템은 상품 또는 서비스에 대한 전자 주문을 수락한 다음 이러한 상품 또는 서비스를 고객에게 제공하는 인터넷 기반 리소스 관리 시스템입니다.
  • 전자 상거래 시스템에서 응용 프로그램 별 계층에는 사용자가 여러 항목을 별도의 트랜잭션에 배치 한 다음 단일 트랜잭션으로 모두 함께 지불 할 수 있는 ‘장바구니’를 지원하는 추가 기능이 포함되어 있습니다.

서버 구현

이러한 시스템에는 종종 다층 클라이언트 서버/아키텍처로 구현됩니다.

  • 웹 서버는 웹 브라우저를 사용하여 구현 된 사용자 인터페이스와 함께 모든 사용자 통신을 담당합니다.
  • 응용 프로그램 서버는 정보 저장 및 검색 요청뿐만 아니라 응용 프로그램 별 논리를 구현합니다.
  • 데이터베이스 서버는 데이터베이스간에 정보를 이동하고 트랜잭션 관리를 처리합니다.

Updated: