오래된 SW 엔지니어의 평생 공부

아키텍처 드라이버는 시스템의 아키텍처에 영향을 미치는 주요 요인(Driver)이다. 이러한 드라이버는 아키텍처 결정을 내리는 데 중요한 역할을 하며, 요구사항(Requirement), 제약사항(Constraint), 원칙(Principle) 등을 포함할 수 있다. 소프트웨어 아키텍처 분야의 다양한 전문가와 저자들은 아키텍처 드라이버에 대해 논의하였는데 주요한 내용들을 정리해 보자.

아키텍처 드라이버를 언급하는 주요 인물들

1. 그래디 부치 (Grady Booch)
   • 공통점:
     • 요구사항(Requirement)과 제약사항(Constraint)을 이해하는 것이 중요하다고 강조한다.
     • 성능, 확장성, 보안과 같은 품질 속성(Quality Attribute)의 역할을 강조한다.
   • 차이점:
     • 아키텍처 결정 과정과 UML과 같은 모델링 언어 사용에 더 중점을 둔다.
2. 메리 쇼와 데이비드 갈란 (Mary Shaw and David Garlan)
   • 공통점:
     • 아키텍처 스타일(Architectural Style)과 패턴(Pattern)이 아키텍처 드라이버의 일부임을 강조합니다.
     • 기능적 요구사항(Functional Requirement)과 비기능적 요구사항(Non-functional Requirement 혹은 Quality Attribute) 모두를 다룰 필요성을 강조한다.
   • 차이점:
     • 아키텍처 스타일을 분류하고 이해하는 데 중점을 두는 더 학문적이고 이론적인 관점을 제공한다.
3. 바스, 클레멘츠, 카즈먼 (Bass, Clements, and Kazman) - "Software Architecture in Practice" 저자들
   • 공통점:
     • 품질 속성(Qaulity Attribute)이 아키텍처 결정에 중요한 역할을 한다고 강조한다.
     • 이해관계자의 우려가 아키텍처를 형성하는 데 중요한 역할을 한다고 강조한다.
   • 차이점:
     • Attribute-Driven Design (ADD) 방법 등 아키텍처 결정을 평가하고 문서화하는 자세한 프레임워크를 제공한s다.
4. 마틴 파울러 (Martin Fowler)
   • 공통점:
     • 요구사항과 제약사항이 아키텍처 결정에 중요한 역할을 한다고 인정한다.
     • 아키텍처의 유연성을 유지하여 변화하는 드라이버에 적응하는 것이 중요하다고 강조한다.
   • 차이점:
     • 실무 경험과 애자일 방법론을 통해 아키텍처 드라이버를 다루는 데 더 중점을 둔다.

공통점

• 품질 속성(Quality Attribute): 모든 저자는 품질 속성(예: 성능, 보안, 유지보수성)이 중요한 아키텍처 드라이버임을 강조한다.
• 이해관계자의 우려: 다양한 이해관계자의 우려를 이해하고 해결하는 것이 중요하다고 일관되게 강조한다.
• 기능적 및 비기능적 요구사항: 두 가지 요구사항 모두 아키텍처 결정을 내리는 데 기본적이라고 인식한다.

차이점

• 방법론 및 프레임워크:
  • 그래디 부치는 모델링 언어와 프로세스에 중점을 둔다.
  • 바스, 클레멘츠, 카즈먼은 ADD와 같은 특정 프레임워크를 제공한다.
  • 마틴 파울러는 애자일 실천과 현실 세계의 적응성을 강조한다.
• 관점:
  • 카네기 멜론대 소프트웨어 엔지니어링 인스티튜트(Carnegie Mellon University Software Engineering Institue, CMU SEI)의 메리 쇼와 데이비드 갈란은 더 이론적이고 학문적인 접근을 취한다.
  • 마틴 파울러는 실무자 지향적 관점을 제공한다.
• 프로세스 vs. 패턴에 대한 강조:
  • 그라디 부치와 마틴 파울러는 프로세스와 적응성에 중점을 둔다.
  • 메리 쇼와 데이비드 갈란, 바스 등은 아키텍처 스타일과 패턴을 이해하고 활용하는 데 중점을 둔다.

요약

요약하자면, 품질 속성, 이해관계자의 우려, 기능적 및 비기능적 요구사항의 중요성에 대한 공통점이 있지만, 방법론, 관점, 특정 강조점에서 차이가 있다. 그라디 부치는 프로세스와 모델링에 중점을 두고, 메리 쇼와 데이비드 갈란은 이론적 이해를, 바스 등은 프레임워크를, 마틴 파울러는 실무와 애자일 방법론을 강조한다.

개요

여기서는 SEI의 Architecture 설계 [1]에서 설명하는 품질 속성(Quality Attribute)에 대해서 설명한다. 4.4절에서 설명하는 바와 같이 품질 속성(Quality Attribute)이 품질 속성 시나리오(Quality Attribute Scenario)로 구체화 된다. 이를 그림으로 표현하면 아래와 같다. ISO 25010의 경우는 이름이나 분류가 다른 경우도 있으니, 참고 바란다.

이 후에는 [1]에서 설명하는 Quality Attribute들 중요서 주요한 몇가지를 Quality Scenario 형태로 설명한다.

성능(Performance)

성능은 Software System이 가지는 중요한 Quality 중의 하나이다. 이는 [1]의 8장에서 설명한다. 아래는 설명하는 Quality Attribute의 상세히 설명하는 Quality Scenario가 가져야 하는 내용의 일반적인 셜명이다.

변경 용이성 (Modifiability)

변경 용이성은 개발 측면에서 추가적인 요구 사항에 대해서 변경하기 효율성을 의미한다. 

가용성(Availability)

기타 Quality Attributes

상호 운영성(Interoperability), 보안성(Security), 시험 용이성(Testability), 사용성(Usability) 뿐만 아니라, 다른 속성도 많다. 이는 설계하려는 Software System의 Domain에 따라 달라지기도 한다. 이야기 한데로, System을 분석하다 보면, 위의 품질 뿐 아니라, 다른 품질 속성이 도입되기도 한다. 여기서는 상세히 다루지 않는다. 필요하면, [1] 혹은 [2]를 참조하기 바란다.

마무리 하며

여기서는 SEI에서 이야기하는 주요 Quality Attribute[1]들에대해서 살펴 보았다. 성능(Performance), 변경 용이성(Modifiability) 그리고 가용성(Availability)를 살펴 보았다. 이외에도 Software System에 따라 다른 Quality Attribute들이 있을 수 있다. 각 Quality Attribute는 Quality Scenario로 표시 될 수 있다. 또한 Quality Attribute들은 때에 따라 Functional Requirement가 될 수 있다.

Quality Attribute를 만족하기 위한 Tactics나 Architecture Style들은 따로 논의 한다. Tactics는 Quality Attribute별로 접근하는 방식을 정리해놓은 것으로 [1]에도 설명이 되어 있다. Architecture Style은 Architecture Pattern이라고도 불리는데, 이는 POSA[3]의 책 시리즈에 잘 설명이 되어 있고, Design Pattern 처럼 종류가 다양하다.

Reference

[1] Len Bass, et. al., "Software Architecture in Practice, Third Edition," Addison Wisely, 2012

[2] ISO/IEC 25010, https://iso25000.com/index.php/en/iso-25000-standards/iso-25010

[3] Frank Buschmann, et. al., "Pattern-Oriented Software Architecture Volume 1: A System of Patterns Volume 1 Edition", Wiley