Architectural Styles and the Design of Network-based Software Architectures -미완성

해당 논문을 읽으면서 주먹구구식으로 요약을 하였다. 그렇기 때문에 나의 요약이 곧 정답이란 법이 없으므로 원본을 읽어보는 것을 추천한다. 이 글에서 SA는 소프트웨어 아키텍쳐를 의미한다. 

  software연구개발은 오랜 시간동한 설계의 분류와 설계 방법에 집중을 했고 극소수만이 설계 방식이 시스템에 미치는 영향을 객관적으로 평가했다. 인터넷 연구는 그와 반대로 시스템 간의 일반 통신의 세세한 부분과 특수한 통신 기술의 성능 개선에 집중했다. 애플리케이션 커뮤니케이션 스타일을 바꾸는 것이 프로토콜을 바꾸는 것보다 성능에 영향을 더 많이 준다. 저자는 인터넷 애플리케이션의 기반이 되는 아키텍쳐를 이해하고 평가하고 원칙적으로 아키텍쳐를 사용해 원하는 기능과 성능을 얻기 위해 이 논문을 작성했다.

 

 

Chapter 1 Software architecture

  소프트웨어 아키텍쳐는 수많은 연구가 있었지만 그 아키텍쳐 안의 어떠한 것이 포함되어야 하는지에 대해선 공통된 의연을 내놓지 못했다. 이는 과건 연구 중 아키텍쳐의 중요한 설계를 경시하는 현상을 야기했다. 이 장에서는 기존에 존재하는 정의와 저자의 인터넷 애플리케이션아키텍쳐에 대한 통찰력을 기반으로 소프트웨어 아키텍쳐에 대한 self-consist한 용어를 정의한다. 

 1.1 Run-time Abstraction

   소프트웨어 아키텍처는 그 연산의 어떤 단계에서 스프트웨어 시스템의 런타임 요소들을 추상화 한것이다. 한개의 시스템은 수많은 추상계층과 수많은 연산 단계로 구성될 수 있으며 각 추상층과 연산 단계는 각자의 소프트웨어 아키텍처를 가지고 있다.

  소프트웨어 아키텍쳐의 핵심은 추상화 원칙이다. 캡슐화를 통해 시스템의 세부적 부분을 숨기고 그로인해 시스템의 속성을 더 잘 식별하고 지원할 수 있다. 하나의 복잡한 시스템은 수많은 추상 계층을 포함하고 각 추상계층은 각자의 아키텍쳐가 있다. 아키텍쳐는 각 계층에서의 시스템 동작의 추상화를 나타낸다. 아키텍쳐의 원소는 같은 계층의 기타 원소에게 추상 인터페이스를 제공하는 것으로 묘사된다. 각 원소 중에는 다른 아키텍쳐도 존재할 수 있다. 이는 자식 원소의 시스템을 정의하고 이 시스템은 부모 아키텍쳐의 추상 인터페이스에서 발전된 행동을 실현시켰다. 이러한 아키텍쳐는 가장 기초적인 시스템 원소가 나올때 까지 귀속될 수 있다. 

  아키텍쳑의 계층 외에 소프트웨어 시스템은 통상적으로 여러개의 연산 단계를 사용한다. start-up, initialization, normal-processing, re-initilization등.각 연산은 각자의 아키텍쳐를 가지고 있다. 시스템 아키텍쳐의 전반적인 서술은 반드시 가능한 많은 각 계층의 시스템 아키텍쳐의 동작과 동작간의 이동을 서술해야 한다. 

  Software architecture는 소프트웨어 시스템이 런타임 시의 추상화이고 software strucre는 정적 소스코드의 속성이다. 소스코드의 모듈 구조가 실행중인 시스템 내에서 동작의 분해와 일치하게 하는 이점이 있지만, 동일한 코드의 일부를 사용해 독립적인 소프트웨어 요소를 구현하게 하는 장점도 있다. 소프트웨어 아키텍쳐와 소스코드의 구조를 분리시키는 것은 스프트웨어 런타임 시의 특성을 더 잘 파악하기 위함이다. 이러한 특성들은 특정한 원소의 사용에 의존하지 않는다. 따라서 비록 소프트웨어 아키텍쳐와 코드 구조는 긴밀한 관계가 있지만 사실상 그들은 분리되 있다. 불행이도 일부 소프트웨어 아키텍쳐의 서술을 이런 점을 명확히 나타내지 않고있다.

1.2 Elements

  하나의 소프트웨어 아키텍쳐는 원소구조의 배치로 정의되며 이 원소들 간의 관계는 제한되있으며 이는 원하는 아키텍처 속성을 얻기 위함이다.

  perry와 Wolf는 SA의 범위와 기초 지식에 대한 전면적인 조사를 했다. 그들은 하나의 모델을 제안했고 이 모델은 한 세트의 원소 아키텍쳐로 SA를 정의하고 , 이 원소는 한 세트의 기본원리(rationale)로 묘사되는 특수한 형식을 띄고있다. 원소 아키텍쳐는 처리, 데이터, 연결원를 포함하고있다. 형식은 원소의 속성과 원소간의 관계로 정의된다. 이러한 기본 원리는 아키텍쳐의 스타일, 원소와 형식의 동기 선택을 통해 아키텍쳐에게 기본 지식을 제공했다. 

  나의 SA정의는 Perry와 Wolf의 모델에 기초해 더 상세한 부분을 다루었다. 하지만 기본 원리에 대한 부분을 다루지는 않는다. 비록 기본원리는 SA연구 중 아주 중요한 부분이지만(특히 아키텍쳐 묘사 측면에서) 이를 SA정의에 포함한다면 디자인 도큐멘테이션이 런타임 시스템의 일부분이라는 것을 암시하게 된다. 기본원리의 포함 여부는 아키텍쳐의 개발에 영향을 주지만 아키텍쳐가 한번 만들어 지면 이는 기본원리에서 벗어나 독자적으로 존재하게된다. 반영형 시스템은 과거의 성능을 기반으로 이후의 행위를 개선할 수 있다. 하지만 이는 낮은 계층의 아키텍쳐로 더 낮은 단예의 아키텍쳐를 대체하는 것이고 이들의 아키텍쳐에서 기본원리를 포함시키는게 아니다. 

(반영: 컴퓨터 프로그램에서 런타임 시점에 사용되는 자신의 구조와 행위를 관리(type introspection)하고 수정할 수 있는 프로세스를 의미한다)

  예를 하나 들어보자. 건물의 청사진과 설계도가 소각됬다면 어떠한 일들이 발생하겠나? 그 건물이 순식간에 무너질까? 아니다, 건물을 지탱하는 벽이 여전히 온전하기 때문이다. 설계에 따르면 하나의 아카텍쳐는 한 세트의 속석을 가지고 있고 이 속성은 해당 아키텍쳐의 요구를 만족시키거나 더 많은 것들을 만족시킨다. 이런 속성들을 생략하면 추후의 유지보수 중에 아키텍쳐의 레퍼런스를 위반하게 된다. 벽 하나를 아주 큰 창문 하나로 대체하는거 처럼. 따라서 우리의 SA정의 중에는 기본원리를 포함하고 있지 않고 아키텍쳐의 속성을 포함하고 있다. 기본원리는 이런 속성을 설명하고 있다. 기본원리의 부재는 시간에 따른 아키텍쳐의 변화를 퇴화시킬 수 있지만 기본원리 자체는 아키텍쳐의 한 부분이 아니다.

  Perry와 Wolf의 모델의 핵심적인 특징 중 하나는 서로 다른 유형의 원소간의 구별에 있다. processing elements는 데이터의 전환을 실행하는 원소이다. data element는 사용되는, 전환되는 정보의 원소이다. connection elements는 아키텍쳐의 서로 다른 부분을 결합신키는 접착제이다. 이 논문에서는 components와 connectors를 사용해 각각 processing elemetns와 connecting elements를 대체했다.

  Garlan과 Shaw는 시스템의 아키텍쳐를 일부 연산 컴포넌트와 이러한 컴포넌트간의 커뮤니케이션으로 묘사한다(커넥터). 이 모델은 Shaw등 인물의 모델에 대한 확장이다. 하나의 소프트웨터 시스템의 아키텍쳐는 일부 컴포넌트와 이러한 컴포넌트 간의 커뮤니케이션으로 정의한다. 시스템의 구조와 토플로지에 대한 지적외에 아키텍쳐는 원하는 시스템의 니즈와 시스템을 이루는 원소 간의 대을 관계를 나타낸다. 더 자세한 정의는 Shaw와 Garlan의 글에서 볼 수 있다( M. Shaw and D. Garlan. Software Architecture: Perspectives on an Emerging Discipline. Prentice-Hall, 1996.).

  Shaw등 일부 사람들의 모델은 SA를 소프트웨어 중에 존재하는 것이 아니라 SA에 대한 묘사를 아키텍쳐 그 자체 처럼 대했다는 점에서 놀라움이 있다. 이과정에선 SA는 대다수의 비형식화된 도표에서 볼 수 있는 것으로 간략화 되있다. 사각형->컴포넌트, 직선->커넥터. 데이터 원소와 다른 실제 SA의 동작은 모두 생략되 있다. 이러한 모델은 네트워크 기반의 SA를 설명하기는 부족하다. 왜냐하면 네트워크 기반의 애플리케이션에서의 데이터 원소의 시스템에의 위치와 이동은 종종 가장 중요한 요인이 되기 때문이다. 

1.2.1 component

  컴포넌트는 명령어와 내부 상태에 대한 추상 단위이다. 그에대한 인터페이스를 통해 데이터의 전환을 제공한다.

  컴포넌트는 SA에서 가장 쉽에 판별할 수 있다. Perry와 Wolf의 정의(D. E. Perry and A. L. Wolf. Foundations for the study of software architecture. ACM SIGSOFT Software Engineering Notes, 17(4), Oct. 1992, pp. 40-52.) 에서는 processing element가 데이터 원소의 전환을 하는 컴포넌트로 정의되 있다. Garlan과 Shaw(D. Garlan and M. Shaw. An introduction to software architecture. Ambriola & Tortola (eds.), Advances in Software Engineering & Knowledge Engineering, vol. II, World Scientific Pub Co., Singapore, 1993, pp. 1-39.)는 컴포넌트를 연산을 수행하는 원소로 간단히 정의했다. 이 논문의 정의 도표는 더 정확하게 컴포넌트와 커넥터 사이의 소프트웨어(software within connectors)를 구별지었다.

  컴포넌트는 소프트웨어 지령과 내부 상태에 대한 추상적 단위이고 이 인터페이스를 통해 데이터의 전환(transformation)을 제공한다. 전환의 예시로는 secondary storage(비휘발성 메모리)에서 ROM으로 데이터를 로딩하는것, 일부 연산, 다른 포맷으로 컨버팅 등이 있다. 모든 컴포넌트의 연산은 아키텍쳐의 일부분이다. 컴포넌트의 연산은 다른 컴포넌트에 의해 관찰(observed)되거나 보여질(discerned) 수 있다. 즉, 컴포넌트는 자기자신이 다른 컴포넌트를 위해 제공한 인터페이스와 서비스로서 정의되야한다. Param은 이를 기타 컴포넌트들이 이 컴포넌트에게 한 가정으로 정의를 했다(D. L. Parnas. Information distribution aspects of design methodology. In Proceedings of IFIP Congress 71, Ljubljana, Aug. 1971, pp. 339-344.).

1.2.2 Connector

  커넥터는 컴포넌트간의 통신, 조정, 협력을 중재하는 추상화 매커니즘이다.

  Perry와 Wolf는 connection elements를 컴포넌트의 서로 다른 부분을 결합해 놓은 접착제로 대략적으로 묘사했다(D. E. Perry and A. L. Wolf. Foundations for the study of software architecture. ACM SIGSOFT Software Engineering Notes, 17(4), Oct. 1992, pp. 40-52.). Shaw와 Clements는 더 상세한 정의를 제공했다. 커넥터는 컴포넌트간의 통신, 협력 또는 조정을 중재하는 추상 매커니즘이다.(M. Shaw and P. Clements. A field guide to boxology: Preliminary classification of architectural styles for software systems. In Proceedings of the Twenty-First Annual International Computer Software and Applications Conference (COMPSAC`97), Washington, D.C., Aug. 1997, pp. 6-13.) 커넥터의 예시로는 message-passing protocol, 데이터 스트림 등이 있다. 

  커넥터와 컴포넌트를 비굑하는 것은 커넥터를 이해하는 가장 좋은 방법일 수 도 있다. 커넥터는 데이터 원소를 그의 한 인터페이스에서 다른 인터페이스로 전이(transferring)하면서 데이터를 바꾸지 않음으로써 컴포넌트 간의 통신을 지원한다. 이 내부에서는 하나의 커넥터는 하나의 컴포넌트로 구성된 자식 시스템을 가질 수 있다. 전이의 목적이 데이터에 대해 모종의 전환을 하기 위해서는 전이를 실행하고 상반된 전환을 하고 원시 데이터와 같은 결과를 돌려줘야 한다. 하지만 아키텍쳐가 포착한 외부 행위에 대한 추상은 이 과정을 생략할 수 있다. 그와는 반대로, 외부의 시각에서 관찰을 해보면 컴포넌트는 종종 데이터에 대한 전환을 한다.

1.2.3 dada

  데이터는 컴포넌트가 터넥터를 통해 송수신하는 메시지 원소이다.

  데이터 원소의 유무는 Perry와 Wolf가 주장한 모델[105]과 다른 SA연구에서 주장한 모델[1,,5,9,53,56,117-122,128]과의 가장 큰 차이라는 것을 위에서 이미 설명했다. Boasson[24]은 기존의 SA연구가 컴포넌트의 구조와 아키텍쳐 개발 도구를 과도하게 강조했다고 비판했다. 그는 응당 데이터 중심의 아키텍쳐 모델에 집중해야한다고 주장했다. Jackson[67]역시 이과 같은 관점을 가지고 있다.

  데이터는 컴포넌트가 하나의 커넥터를 통해 송수신 되는 정보 원소이다. 데이터의 예시로는 byte-sequence, 메시지, 인코딩된 파라미터, 서열화된 객체 등이 있다. 하지만 오랫동안 있었던 또는 숨겨져있던 컴포넌트 내의 정보는 포함하지 않는다. 아키텍쳐의 입장에선 문서는 사실상 일종의 전환이다. 문서 시스템은 그의 인터페이스에서 문서명에 대한 정보를 받고 이 정보를 내부 저장 시스템에 기록된 byte sequence로 전환한다. 컴포넌트 역시 데이터를 생성할 수 있다. 예를 들어 시계 또는 센서의 소프트웨어 캡슐화.

  네트워크 기반 애플리케이션의 아키텍쳐의 데이터 원소들의 특성은 종종 아키텍쳐 스타일의 적합 여부를 결정한다. Mobile code design paradigms의 비교[50]에서는 반드시 두개의 스타일 중 하나를 선택해야 된다고 명시되 있다. 1. 컴포넌트와 직접적인 커뮤니케이션, 2. 컴포넌트를 하나의 데이터 원소로 전환. 네트워크 전이를한 후 로컬과 커뮤니케이션이 가능하나 컴포넌트로 전환한다. 아키텍쳐 계층의 입장에서 데이터 원소를 고려하지 않으면 이러한 아키텍쳐를 전혀 평가할 수 없다.

1.3 Configuration

  Configuration은 시스템의 런타임 시의 컴포넌트, 커넥터 그리고 데이터 간의 아키텍쳐 관계에 대한 구조이다.

  Abows등 일부 사람들은[1] 아키텍쳐의 묘사를 3개의 기본적인 syntatic objects를 통해 시스템에 대한 묘사를 진행하는 것이라고 정의했다. 컴포넌트-연산의 소재지, 커넥터-정의 컴포넌트 간의 커뮤니테이션, configuration-상호 커뮤니케이션하는 컴포넌트와 커넥터의 집합. 여러종류의 특정한 스타일과 관련된 형상화 부로로 이 개념을 시각화 할 수 있다. 합법적인 계산과 커뮤니케이션, 바람직한 시스템을 편리하게 묘사하기 위해.

  엄격히 말하자면, 하나의 configuration은 한 세트의 컴포넌트의 커뮤니테이선 상의 특정한 약속으로 이해할 수 있다. 예를 들어 Perry와 Wolf[105]는 그들의 아키텍쳐 형식 관계(architectural form relationships)의 정의 중에 토플로지를 포함하고 있다. 그러나 주동적 토플로지화 더 많이 통용되는 약속(constraint)을 분리 함으로 써 아키텍쳐 설계자는 더 간편하게 주동적 configuration과 다른 합법적 configuration이 영향 받을 수 있는 영역을 분리할 수 있다. Medvidovic과 Taylor[86]는 아키텍쳐 묘사에서 별도로 configuration에 대해 구별을 짓는 기본원리를 제안했다.

1.4 Properties

  SA의 아키텍쳐 속성 딥합은 컴포넌트, 커넥터와 데이터의 선택, 이로인해 야기된 모든 속성을 나열하는 것을 포함한다. 아키텍쳐 속성의 예시는 시스템으로 인해 얻은 기능 속성과 비 기능속성을 포함하고 있다. 예를 들어: 컴포넌트의 재활용성, 효율, 동적확장능력 등이 있다. 이들은 주로 품질 속성(quality attributes)[9]라 불린다.

  속성은 아키텍쳐의 약속 한 세트로인해 야기된다. 약속은 종종 아키텍쳐 원소의 일부 소프트웨어 공정 원칙[58]으로 구동된다. 예를 들어, uniform pipe-and-filter 스타일은 이 컴포넌트 인터페이스 상의 애플리케이션 통용성(generality)원칙으로 컴포넌트가 단일 인터페이스 유형을 실현하는 것을 강제한다. 이로인해 애플리케이션에서 컴포넌트의 재활용성과 구성가능 속성(configurability)의 품질을 얻었다. 따라서 아키텍쳐 약속(constraint)은 통용성 원칙으로 구동되는 한 세트의 인터페이스이다. 원하는 두개의 품질을 얻는 것이 목표이다. 아키텍쳐에서 이런 스타일을 사용하면 이 두개의 품질은 재활용성과 configurability한 아키텍쳐 속성이 된다.

  아키텍쳐 디자인의 목적은 아키텍쳐 속성을 포함하는 한 세트의 아키텍쳐를 만드는 것이다. 이런 아키텍쳐 속성은 시스템이 요구하는 superset이 되었다. 서로 다른 아키텍쳐 속성의 상대적 중요성은 원하는 시스템 자체의 특성에 따라 달라진다. 2.3절은 인터넷 기반 애플리케이션의 아키텍쳐에게 특히 중요한 속성을 다룬다.

1.5 Styles

  한 종류의 아키텍쳐는 기능 속성과 비 기능 속석을 포함한다. 직접적으로 서로다른 유형의 아키텍쳐 비교 또는 서로 다른 환경에 에서의 돌이 유형 아키텍쳐 비교는 꽤 어렵다. 스타일은 아키텍쳐에 대해 분류를 진행하고 그들의 공통 특징[38]을 정의하는 매커니즘이다. 각 종류의 스타일은 모두 컴포넌트를 위한 추상을 제공한다. 또한 아키텍쳐의 나머지 부분의 우연성을 생략함으로써 pattern of interation의 본질 특성을 얻는다[117].

  Perry와 Wolf[105]는 스타일을 element types에 대한 일종의 추상과 서로 다른 특정 아키텍쳐에서 온 formal aspect(아키텍쳐의 특정 방면일 수 도 있다)으로 정의했다. 한 종류의 아키텍쳐는 아키텍쳐 원소에 대한 중요한 전략을 캡슐화했다, 이로인해 원소와 그들 간의 관계에 중요한 약속을 강조한다. 이 정의는 스타일이 아키텍쳐의 커넥터, 또는 컴포넌트의 특정 방면에만 초점을 맞추는 것을 허용한다.

  이와는 반대로 Garlan과 Shaw[53], Garlen 등 일부[56], Shaw와 Clements[122]는 모두 각종 유형의 컴포넌트 간의 커뮤니케이션 모델로 스타일을 정의했다. 즉, 하나의 아키텍쳐 스타일이 이 스타일의 실제 사용 사례에서 사용 가능한 컴포넌트와 커넥터의 단어(vocabulary)를 정의했다[53]. 아키텍쳐 스타일의 이런 제한적 시각은 그들의 SA정의의 직접적인 결과이다. 아키텍쳐를 런타임 시스템이 아니라 형식화이 묘사로 보았고 이는 단지 사각형과 직선만 포함된 도표에서 도출한 공통 모형으로 추상화를 진행하는 것을 야기했다. Abowd등 일부 사람들은[1] 한발 더 나아가 이를 하나의 collection of conventions로 명확히 정의했다. 이 집합은 한 세트의 아키텍쳐 묘사를 한 종류의 아키텍쳐 스타일의 정의로 해석한다.

  새로운 아키텍쳐는 특정 스타일의 인스턴스로 정의될 수 있다.[38]. 아키텍쳐 스타일이  SA의 여러 방면을 강조할 수 도 있기 때문이다. 특정 아키텍쳐는 여러 종류의 아키텍쳐 스타일로 만들어 진거 일수도 있다. 동일하게, 여러 종류의 기본 스타일을 하나의 합성 스타일로 만들어 하나의 혼합 스타일을 만들 수 있다. 

  일부 아키텍쳐 스타일은 종종 모든형식의 소프트워어에 적합한 "silver bullet"식 해결방안으로 묘사된다. 그러나, 실력있는 설계사라면 현재 해결중인 특정 문제와 가장 알맞은 스타일을 골라야한다[119]. 네트워크 기반의 애플리케이션을 위해 알맞은 스타일의 아키텍쳐를 선택하기 위해서는 반드시 해당 문제의 영역을 이해해야한다. 따라서 통신 요구 사항을 이해하고 다른 여러 스타일을 알고 그들이 각기 가지고있는 문제점을 알아야 하며 인터넷 기반의 통신의 특성을 통해 각종 커뮤니케이션 스타일의 민감도를 예측해야한다[133].

  불행이도, "스타일"이라는 용어로 한 세트의 협력 약속을 표현하는 것은 종종 사람들을 혼란스럽게 한다. 여기서 사용하는 "스타일"의 의미와 사전상의 의미는 아주 큰 차이가 있다. 후자는 설계과정상의 개성화를 나타낸다. Loerke[76]은 별도의 한 챕터로 전문 건축사가 작업 중 개성화 스타일을 위해 자리를 남겨야 된다는 의견을 깍아내렸다. 반대로, 그는 스타일을 비평가가의 과거 아키텍쳐로 묘사했다. 이는 선택 가능한 원료, 사회의 문화, 본토 통치자의 자존심 등의 요인으로 아키텍쳐의 스타일을 책임져야 된다, 설계자가 책임지는게 아니라. 즉, Loerke는 전통적인 아키텍쳐 건국 중에서 스타일의 진정한 유래는 한 세트의 애플리케이션의 설계상의 약속이고 특정 스타일의 도달 또는 복제는 설계자의 가장 낮은 목표여야 된다고 주장한다. 이미 이름이 붙여진 약속을 한 종류의 스타일이라 부르기 때문에 공통된 약속에 대한 특징에 대한 커뮤니케이션은 더욱 쉬워졌다. 이 논문에선 아키텍쳐 스타일을 한 종류의 개성화의 설계를 대표하는 것이 아닌 추상화하는 방법으로서 사용할 것이다.

1.6 Patterns and Pattern Languages

  아키텍쳐 스타일의 소프트웨어 공정 연구를 진행함과 동시에 객체지향 프로그래밍 커뮤니티는 디자인 패턴의 사용과 패턴 언어(pattern languages)를 내놓아 객체 기반의 소프웨어 개발의 반복적 추상화를 서술했다. 한 종류의 설계 모델은 한 종류의 중요하고 반복적으로 출현하는 시스템 구조로 정의되있다. 하나의 패턴 언어는 하나의 패턴 시스템이다, 패턴 언어는 하나의 구조로 조직된 패턴들의 시스템이고 이는 패턴 애플리케이션을 가이드한다[70]. 패턴 설계와 패턴 언어의 개념은 모두 Alexander등 사람들이 논문[3, 4]중에 아키텍쳐 건축과 관련한 내용을 기반으로 한다.

  패턴의 디자인 공간(design space)는 객체 지향 프로그래밍에 특정한 기술 관련 사항을 포함하고 있다. 예를 들어 클래스 상속과 인터페이스 조합과 아키텍쳐 스타일이 야기한 high-level의 설계문제[51]가 있다. 일부 상황에서는 아키텍쳐 스타일의 묘사가 아키텍쳐 패턴(architectural patterns)로 불리기도 한다[120]. 그러나, 패턴의 주요한 하나의 장점은 객체간의 상당히 복잡한 커뮤니케이션 수칙을 하나의 추상으로 나타낼 수 있다는 것이다[91], 그중에는 행위의 약속과 세세한 사용밥을 포함한다. 종합적으로, 한 종류의 패턴 또는 여러 종류의 패턴이 모여 만들어진 패턴 언어는 객체간의 훌륭한 상호작용을 사용하기 위한 레시피로 볼 수 있다. 즉, 하나의 패텀이 고정된 설계와 implementatino choices를 통해 문제 해결를 해결하는 과정을 정의했다[34].

  SA의 스타일 처럼, 소프트웨어 패턴의 연구 역시 그의 건축 아키텍처의 기원에서 벗어났다. 사실상, Alexander의 모델 개념의 핵심은 반복적으로 나타나는 아키텍쳐 원소의 나열이 아니라 하나의 공간 내에서 반복적으로 발생하는 사건에 대한 모델이다. Alexander는 또한 사건의 모델은 이 사건이 발생한 공간을 벗어나면 안된다는 것도 깨달았다[3]. Alexander의 설계 철학은 목표 문화(target culture) 중 공통된 생활목적(pattern of life)를 식별해 어떤 아키텍쳐적 제약조건에서 그것이 원하는 패턴이 자연스럽게 발생할 수 있도록 그것이 주어진 공간을 수별하는 것이 필요하다 이다. 이런 패턴은 여러개의 계층의 추상과 모든 모델에서 존재한다.

  이 세상의 하나의 원소로서, 각 패턴은 모두 특정 환경 속의 하나의 관계이며 그 환경에서 반복적으로 출현하는 하나의 특정 역학 시스템이다. 또한 일종의 특정한 공간 configuration이 존재해서 시스템에 있는 이 힘(forces)들이 자신을 위해 답을 얻게 하고, 서로를 지탱하며 온건한 상태로 도달하게 한다.

  언어의 한 원소로서, 한 종류의 모델은 하나의 지도(guide)이다, 이런 공간 configuration은 어떠게 반복적으로 사용되게 할지를 나타냄으로써 특적 역학 시스템을 위해 답을 구한다. 맥락이 적절하다고 판단되는 곳 어디든지.

  패턴, 간단히 말하면 패턴은 세상에 존재하는 하나의 사물이자 이런 사물을 만드는 방법이며 언제 우리가 반드시 그를 창조하는지에 대한 규칙이다. 패턴은 하나의 과정이자 사하닁 사물이다. 패턴은 하나의 살아있는 사물에 대한 서술이며 이 사물이 만들어 지는 과정에 대한 묘사이다.

  여러 방면에서 객체 지향 프로그래밍 연구중의 디자인패턴과 비교하면 Alexander의 패턴은 사실상 SA 스타일과 더 많은 공통점이 있다. 한 종류의 아키텍쳐 스타일은 한 세트의 협동 제약 조건으로서 하나의 설계 공간에 사용되서 하나의 시스템에서 희망하는 아키텍쳐 속성이 나오기를 재촉한다. 하나의 스타일을 사용함으로써 아키텍쳐 설계사가 서로다른 소프트웨어 설계 공간을 구분해 결과가 애플리케이션이 고유한, 반드시 만족해야 하는 선제 조건에 더 알맞기를 희망한다. 이는 시스템의 행동이 서로 출돌하는 것이 아닌 자연 패턴(natural pattern)을 강화하는 결과를 도출한다.

  1.7 views

  하나의 아키텍쳐 뷰는 종종 애플리케이션에 특정되 있다, 또한 애플리케이션의 영역에 따라 변화한다. 우리는 이미 아키텍쳐 뷰가 수 많은 문제를 결하는 것을 봐왔다. temporal issues, 상태와 조작 방법, graceful degradation 등. 말할 필요도 없이, 위에서 말한 뷰 외에도 더 많은 뷰가 존재한다[70].

  하나의 시스템의 수많은 아키텍쳐 외에, 아키텍쳐를 이루는 수많은 아키텍쳐 스타일의 입장에서의 관찰 외에 다른 수많을 각도에서 하나의 아키텍쳐를 관찰 할 수 있다. Perry와 Wolf[105]는 3 종류의 중요한 SA 뷰를 묘사했다. 프로세싱, 데이터, 커넥션. 프로세싱 뷰는 컴포넌트를 거쳐간 데이터 스트림과 컴포넌트 간의 커넥션에 대한 데이터와 관련된 방면 보다 중요하다. 데이터 뷰는 커넥터가 아닌 프로세스의 흐름보다 중요하다. 커넥션의 뷰는 컴포넌트 간의 관계와 통신 상태보다 중요하다.

  수 많은 종류의 아키텍쳐 뷰는 특정한 컴포넌트 사례 연구에선 흔한 일이다[9]. 하나의 아키텍쳐 설계학은, 4+1 그림 모델은[74] 5종류의 협력한 뷰로 SA의 묘사를 더 조직화 시켰다. 각 뷰는 한 세트의 특정 관점을 해결하기 위해 애쓴다. 

1.8 Related work

  이 논문에선 여기에서만 그런 SA를 정의한 또는 SA 스타일을 묘사한  연구 영역을 포함시켰다. 기타 SA연구 영역은 기술분석, 아키텍쳐의 recovery와 re-engineering, 아키텍쳐 설계를 위한 도구와 환경, 표준 부터 실현의 세분화, 부속 SA의 사례연구[55]를 포함하고있다. 스타일의 분류, 프로세스 패러다임의 분류, 미들웨어 같은 영역에 대한 것들은 3장에서 다루겠다.

1.8.1 Design Methodologies

  대부분의 초기 SA연구는 모두 설계 방법학(Design Methodologies)에 집중되 있었다. 예를 들어, 객체 지향 설계[25]은 규격화된 방식으로 문제를 해결하는 것을 재창해서 자연스레 기반이 되는 객체의 아키텍쳐를 도출했다(또는, 더 정확히 말하자면 다른 어떠한 형식의 아키텍처도 도출되지 않는다). 극초기에 아키텍처 계층상 강조된 설계 방법학의 설계는 Jackson시스템 개발방법이다 (JSD)[30]. JSD는 문제 분석을 규격했다. 이러게 하면 pipe-and-filter(data flow) 스타일과 process control constraints 스타일을 조합한 아키텍쳐 스타일을 도출할 수 있다. 이러한 설계 방식은 주로 하나의 아키텍쳐 스타일 만을 생산한다.

  사람들은 아키텍쳐 분석돠 개발의 방법학에 대한 일부 기초적인 연구를 진행했다. Kazman등 일부는 SAAM[68]과 ATAM[69]의 아키텍쳐 trade-off 분석을 사용했다. 장면의 분석을 통해 architectural aspects를 식별하는 방식에 대해 묘사했다. Shaw[119]는 자동차의 GPS시스템의 다양한 box-and-arrow 설계를 비교했다. 각 설계는 모두 서로 다른 설계 방법학을 사용했고 여러종류의 아키텍쳐 스타일을 포함한다.

1.8.2 Handbooks for Design, Design Patterns and Pattern Languages

  전통적인 공학학과와 일치함을 유지함과 동시에 Shaw[117]는 아키텍쳐 핸드북에 대한 개발을 재창했다. 객체 지향 프로그래밍에 대해 우선적으로 디자인 패턴에 대한 목록을 개발했다. 예를 들어 "Gang of Four" 서적[51]과 Coplien과 Schmidt[33]의 글이 있다.