Background
- 소프트웨어 아키텍처 연구의 일환으로 연구자들은 아키텍처에 들어가야 할 용어들을 정의 해야 했음
- 해당 챕터에서는 소프트웨어 아키텍처에서 사용되는 일관성있는 용어들을 정리함
1-1. Run-time Abstraction
A software architecture is an abstraction of the run-time elements of a software system during some phase of its operation
- 소프트웨어 아키텍처의 핵심은 추상화임. 시스템의 각 프로퍼티들을 좀 더 잘 인식하고 유지하기 위해 디테일한 부분을 숨기는 것이 중요함
- 아키텍처의 수준 외에도 소프트웨어 시스템은 주로 다양한 실행 단계를 가지고 있음, 예를 들어서 설정 파일들은 start-up 단계동안 데이터 요소가 될 수 있지만 프로세싱 시간 동안은 데이터 요소로 취급되지 않음
- 시작
- 초기화
- 일반적인 프로세싱
- 재초기화
- 시스템 아키텍처에 대한 전반적인 묘사는 반드시 각 단계의 operation 행동을 묘사할 뿐만 아니라 각 단계 사이의 아키텍처 전환도 묘사해야 함
Software Architecture vs Software structure
- 소프트웨어 아키텍처는 런타임중에 소트프웨어 시스템에서 발생하는 행동을 추상화 한것, 소프트웨어 구조는 static 한 소스 코드를 의미하는 것임
1-2. Elements
A software architecture is defined by a configuration of architectural elements—components, connectors, and data—constrained in their relationships in order to achieve a desired set of architectural properties.
- https://users.ece.utexas.edu/~perry/work/papers/swa-sen.pdf 논문의 저자들은 소프트웨어 아키텍처를 elements 의 집합으로 보았음
- 아키텍처 요소들에는 processing, data, connecting elements 들이 있음
- 이들은 아키텍처를 일련의 이론적 근거에 의해 설명되는 특정 형태를 가진 요소들의 집합으로 정의하는 모델을 제시함
- 저자는 이 논문에서 더 발전된 개념을 제시하지만 이론적 근거를 배제하고 설명함
- 이론적 근거는 소프트웨어 아키텍처 연구에서 중요한 측면이지만 소프트웨어 아키텍처에 포함 시키는 것은 디자인 문서가 런타임 시스템의 일부라는 것을 암시하는 것임
- 이론적 이유들 대신에 소프트웨어 아키텍처를 구성하는 요소에 집중해야함
1.2.1 Components
A component is an abstract unit of software instructions and internal state that provides a transformation of data via its interface
- 연산 혹은 데이터 처리를 담당하는 아키텍처 요소로 정의할 수 있음
- secondary storage 부터의 메모리 적재
- 어떠한 연산
- 다른 타입으로의 데이터 변환
1.2.2 Connectors
A connector is an abstract mechanism that mediates communication, coordination, or cooperation among components.
- Connector 는 Component 들 끼리의 통신을 중재하는 매커니즘이라고 정의할 수 있음
- 예를들어 공유된 표현 계층, 원격 프로시저 콜, 메세지 교환 프로토콜, 데이터 스트림 등이 있을 수 있음
1.2.3 Data
A datum is an element of information that is transferred from a component, or received by a component, via a connector
- 네트워크 기반 애플리케이션 아키텍처 내의 데이터 요소들의 특성은 종종 주어진 아키텍처 스타일이 적절한지 여부를 결정할 것이다
1.3 Configurations
A configuration is the structure of architectural relationships among components, connectors, and data during a period of system run-time.
- Component: 연산, Connector: 컴포넌트간의 상호작용에 관한 것, Configuration: 상호작용하는 Connector 와 Component의 모음
1.4 Properties
- 아키텍처의 특성은 그 아키텍처를 구성하고 있는 컴포넌트, 커넥터, 데이터로 결정됨
- 컴포넌트의 재사용성, 확장성 등
- 아키텍처의 제약사항에 의해 구성됨
- 아키텍처 디자인의 목표는 시스템 요구사항을 충족시키는 아키텍처 특성을 만드는 것
1.5 Styles
An architectural style is a coordinated set of architectural constraints that restricts the roles/features of architectural elements and the allowed relationships among those elements within any architecture that conforms to that style.
- 아키텍처는 기능적 특성과 비기능적 특성을 모두 구현하기 때문에, 서로 다른 유형의 시스템 또는 서로 다른 환경에 설정된 동일한 유형의 시스템에 대한 아키텍처를 직접 비교하기 어려움
- 스타일은 아키텍처를 분류하고 공통 특성을 정의하기 위한 메커니즘임
- 구성 요소의 상호작용에 대한 추상화를 제공하여 나머지 아키텍처의 부수적인 세부 사항을 무시하고 상호 작용 패턴의 본질을 포착함
- 아키텍처 스타일은 소프트웨어 아키텍처의 다양한 측면을 다룰 수 있으므로 특정 아키텍처는 여러 스타일로 구성 될 수 있음
- 설계자는 특정 요구 사항에 맞는 스타일을 선택 해야 함
- 문제 도메인
- 애플리케이션의 통신 요구 사항
- 다양한 아키텍처 스타일과 해당 스타일이 해결하는 특정 문제에 대한 인식
- 각 상호 작용 스타일의 민감도 예측
1.6 Patterns and Pattern Languages
- 디자인 패턴은 중요하고 반복적인 시스템 구성으로 정의됨, 패턴언어는 패턴의 적용을 안내하는 구조로 구성된 패턴의 시스템임
- 패턴의 설계 공간에는 객체 지향 프로그래밍 기술과 관련된 구현 문제뿐만 아니라 아키텍처 스타일에서 다루는 더 높은 수준의 설계문제도 포함됨
- 설계 및 구현 선택 경로를 따라 문제를 해결하기 위한 프로세스를 정의함
1.7 Views
An architectural viewpoint is often application-specific and varies widely based on the application domain. ... we have seen architectural viewpoints that address a variety of issues, including: temporal issues, state and control approaches, data representation, transaction life cycle, security safeguards, and peak demand and graceful degradation. No doubt there are many more possible viewpoints.
- 아키텍처 관점은 애플리케이션에 도메인에 따라 크게 달라짐
- 시간적 문제
- 상태 및 제어 접근 방식
- 데이터 표현
- 트랜잭션 수명 주기
- 보안 안전 장치
- 최대 수요 및 점진적 성능 저하
- 시스템 내의 아키텍처 관점은 크게 3가지로 나눌 수 있음
- 처리 관점
- 구성 요소를 통한 데이터의 흐름과 데이터와 관련된 구성 요소 간 연결의 일부 측면
- 데이터 관점
- 처리 흐름, 커넥터에 대한 강조는 덜함
- 연결 관점
- 구성 요소 간의 관계와 통신 상태
- 처리 관점
'System Design' 카테고리의 다른 글
| [좋은 API 디자인이란 무엇일까] - REST API 의 6가지 제약사항 (0) | 2023.08.01 |
|---|
