소프트웨어 아키텍처

Software architecture
시리즈의 일부
소프트웨어 개발
핵심 활동
패러다임 및 모델
방법론 및 프레임워크
지원 분야
프랙티스
도구들
지식의 표준과 본문
용어집
개요

소프트웨어 아키텍처는 소프트웨어 시스템의 기본 구조와 이러한 구조와 시스템을 만드는 규율을 말합니다.각 구조는 소프트웨어 요소, 이들 간의 관계 및 요소와 [1]관계 모두의 속성으로 구성됩니다.소프트웨어 시스템의 아키텍처는 [2]건물의 아키텍처와 유사한 비유입니다.시스템 [3]및 개발 프로젝트의 청사진으로 기능하여 설계팀이 수행해야 할 작업을 제시합니다.

소프트웨어 아키텍처는 일단 구현되면 변경 비용이 많이 드는 근본적인 구조 선택을 하는 것입니다.소프트웨어 아키텍처에는 소프트웨어 설계의 가능성에서 특정 구조 옵션이 포함됩니다.예를 들어, 우주왕복선 발사체를 제어하는 시스템은 매우 빠르고 신뢰할 수 있어야 합니다.따라서 적절한 실시간 컴퓨팅 언어를 선택해야 합니다.또한 신뢰성에 대한 요구를 충족시키기 위해 다중으로 독립적으로 생성된 프로그램 복사본을 여러 개 가지고 결과를 상호 확인하면서 독립 하드웨어에서 이러한 복사본을 실행할 수 있습니다.

소프트웨어 아키텍처를 문서화하면 이해관계자 간의 커뮤니케이션이 용이해지고, 설계에 대한 높은 수준의 초기 결정이 도출되며,[4]: 29–35 프로젝트 간에 설계 구성요소를 재사용할 수 있습니다.

소프트웨어_아키텍처_액티비티

범위

소프트웨어 [5]아키텍처의 범위에 대해서는 의견이 다릅니다.

  • 거시적 시스템 구조: 이는 컴퓨팅 컴포넌트의 집합과 이들 [6]컴포넌트 간의 상호작용을 설명하는 커넥터로 구성된 소프트웨어 시스템의 상위 수준의 추상화라고 합니다.
  • 중요한 것은 소프트웨어 설계자가 시스템과 이해관계자에게 [7]큰 영향을 미치는 의사결정에 관심을 가져야 한다는 것입니다.
  • 환경 내 시스템 이해에 필수적인 것[8]
  • 변경하기 어려운 것:아키텍처 설계는 소프트웨어 시스템의 라이프 사이클의 시작 단계에서 이루어지기 때문에 설계자는 처음에 '적절해야 한다'는 결정에 초점을 맞춰야 합니다.이러한 사고방식에 따라 건축설계상의 문제는 돌이킬 수 없는 [7]문제를 극복하면 비건축적인 문제가 될 수 있습니다.
  • 일련의 아키텍처 설계 결정: 소프트웨어 아키텍처는 단순한 모델 또는 구조 집합으로 간주되지 않고 이러한 특정 구조를 이끄는 결정과 그 [9]이면에 있는 근거를 포함해야 합니다.이러한 통찰력은 소프트웨어 아키텍처 [10]지식 관리에 대한 상당한 연구로 이어졌습니다.

소프트웨어 아키텍처와 설계 및 요건 엔지니어링 사이에는 뚜렷한 차이가 없습니다(아래의 관련 필드 참조).이들은 모두 높은 수준의 의도부터 낮은 수준의 [11]: 18 세부 사항까지 '의도 사슬'의 일부입니다.

특성.

소프트웨어 아키텍처는 다음을 나타냅니다.

다수의 이해관계자: 소프트웨어 시스템은 비즈니스 관리자, 소유자, 사용자, 운영자 등 다양한 이해관계자의 요구에 부응해야 합니다.이러한 이해관계자들은 모두 시스템에 대해 그들만의 우려를 가지고 있다.이러한 우려 사항의 균형을 맞추고 해결되었음을 입증하는 것은 시스템 [4]: 29–31 설계의 일부입니다.이는 아키텍처가 다양한 우려사항과 이해관계자를 다루는 것을 의미하며, 다원적 특성을 가지고 있다는 것을 의미합니다.

우려의 분리: 설계자가 복잡성을 줄일 수 있는 확립된 방법은 설계를 추진하는 문제를 분리하는 것입니다.아키텍처 문서에 따르면 모든 이해관계자의 우려사항은 다양한 이해관계자의 [12]우려사항과 관련된 별도의 관점에서 아키텍처를 모델링하고 기술함으로써 해결됩니다.이러한 개별적인 설명을 아키텍처 뷰라고 합니다(예를 들어 4+1 아키텍처 뷰 모델 참조).

:전통적인 소프트웨어 설계 접근법(예를 들어 잭슨 법)필요한 기능성과 데이터의 제도를 통해 흐름을 입었지만 현재 insight[4]:26–28은 소프트웨어 시스템의 구조를 더 밀접함에 따라 무결함, 이전 버전과의 호환성,에 의한 같은 품질 특성도 연관되어 있으러 나와Quality-driven.신장성, 신뢰성, 유지 보수성, 가용성, 보안, 조작성 및 기타 다양한 기능을 제공합니다.이해관계자의 우려는 종종 비기능적 요건, 부가기능적 요건, 행동 요건 또는 품질 속성 요건이라고 불리는 이러한 품질 속성에 대한 요건으로 해석됩니다.

반복 스타일: 아키텍처 구축과 마찬가지로 소프트웨어 아키텍처 분야에서는 반복적인 문제를 해결하기 위한 표준 방법을 개발했습니다.이러한 "표준적인 방법"은 추상화의 다양한 수준에서 다양한 이름으로 불립니다.반복 솔루션의 일반적인 용어는 아키텍처 스타일,[11]: 273–277 전술,[4]: 70–72 레퍼런스 아키텍처[13][14] 및 [4]: 203–205 아키텍처 패턴입니다.

개념적 완전성: Fred Brooks가 1975년 저서 The Mythic Man-Month에서 소개한 용어는 소프트웨어 시스템의 아키텍처가 무엇을 해야 하는지, 어떻게 해야 하는지에 대한 전체적인 비전을 나타낸다는 것을 나타냅니다.이 비전은 구현에서 분리되어야 한다.설계자는 "비전의 유지자" 역할을 수행하며, 시스템에 대한 추가가 아키텍처와 일치하도록 보장하고, 따라서 개념적 [15]: 41–50 무결성을 유지합니다.

인지적 제약: 컴퓨터 프로그래머 멜빈 콘웨이의 1967년 논문에서 최초로 관찰한 내용입니다.설계 시스템을 설계하는 조직은 이러한 조직의 통신 구조를 복사한 설계를 생산하도록 제약됩니다.개념적 완전성과 마찬가지로, 프레드 브룩스가 그의 우아한 고전인 "신화적 인간-월"에서 이 논문과 아이디어를 인용하면서 "컨웨이의 법칙"이라고 불렀을 때 더 많은 청중들에게 그것을 소개했습니다.

동기

소프트웨어 아키텍처는 복잡한 시스템의 [4]: 5–6 "지적으로 파악할 수 있는" 추상화입니다.이 추상화에는 다음과 같은 이점이 있습니다.

  • 시스템이 [2]구축되기 전에 소프트웨어 시스템의 동작을 분석할 수 있는 기반을 제공합니다.미래의 소프트웨어 시스템이 실제로 구축하지 않고도 이해관계자의 요구를 충족하는지 검증할 수 있다는 것은 상당한 비용 절감과 리스크 [16]경감을 의미합니다.이러한 분석을 수행하기 위해 ATAM 또는 소프트웨어 시스템을 시각적으로 표현하여 많은 기법이 개발되었습니다.
  • 요소와 의사결정을 [2][4]: 35 재사용할 수 있는 기반을 제공합니다.개별 아키텍처 전략 및 의사결정과 마찬가지로 완전한 소프트웨어 아키텍처 또는 그 일부를 여러 시스템에서 재사용할 수 있으며, 이해관계자는 유사한 품질 속성 또는 기능을 필요로 하므로 설계 비용을 절감하고 설계 오류의 위험을 줄일 수 있습니다.
  • 시스템의 개발, 도입 및 유지 보수 [4]: 31 수명에 영향을 미치는 초기 설계 결정을 지원합니다.일정과 예산 초과를 방지하기 위해서는 영향력이 큰 결정을 조기에 올바르게 내리는 것이 중요합니다.
  • 이해관계자와의 커뮤니케이션을 촉진하여 그들의 요구를 [4]: 29–31 보다 잘 충족시키는 시스템에 기여합니다.이해관계자의 관점에서 복잡한 시스템에 대해 소통하는 것은 이해관계자가 명시된 요건의 결과와 그에 기초한 설계 결정을 이해하는 데 도움이 됩니다.아키텍처는 시스템이 구현되기 전에 설계 결정을 비교적 쉽게 적용할 수 있는 기능을 제공합니다.
  • 리스크 관리에 도움이 됩니다.소프트웨어 아키텍처는 리스크와 [11]: 18 장애 가능성을 줄이는 데 도움이 됩니다.
  • 비용 절감이 가능합니다.소프트웨어 아키텍처는 복잡한 IT [17]프로젝트에서 리스크와 비용을 관리하기 위한 수단입니다.

역사

소프트웨어 설계와 (토목) 아키텍처의 비교는 1960년대 [18][19]후반에 처음 이루어졌지만, "소프트웨어 아키텍처"라는 용어는 1990년대까지 널리 사용되지 않았다.컴퓨터 과학 분야는 형성 [20]이후 복잡성과 관련된 문제에 직면했다.이전의 복잡성 문제는 개발자가 올바른 데이터 구조를 선택하고 알고리즘을 개발하며 관심사 분리 개념을 적용하여 해결했습니다.소프트웨어 아키텍처(Software Architecture)라는 용어는 업계에서 비교적 생소한 용어이지만 1980년대 중반부터 소프트웨어 엔지니어링 선구자들에 의해 이 분야의 기본 원칙이 산발적으로 적용되어 왔다.시스템의 소프트웨어 아키텍처를 캡처하고 설명하려는 초기 시도는 부정확하고 체계적이지 않았으며, 종종 박스 앤 라인 [21]다이어그램으로 특징지어졌습니다.

개념으로서의 소프트웨어 아키텍처는 1968년 Edsger Dijkstra와 1970년대 초 David Parnas의 연구에서 비롯되었습니다.이 과학자들은 소프트웨어 시스템의 구조가 중요하며 구조를 바로 잡는 것이 중요하다고 강조했다.1990년대 동안 이 분야의 근본적인 측면을 정의하고 체계화하기 위한 공동 노력이 이루어졌으며, 건축 양식(패턴), 건축 기술 언어, 건축 문서 및 형식적 [22]방법에 초점을 맞춘 연구 작업이 이루어졌다.

연구기관들은 소프트웨어 아키텍처를 하나의 분야로 발전시키는데 중요한 역할을 해왔습니다.Carnegie Mellon의 Mary Shaw와 David Garlan은 Software Architecture라는 제목의 책을 썼습니다. 컴포넌트, 커넥터, 스타일 등의 소프트웨어 아키텍처 개념을 촉진한 1996년의 신흥 분야 전망.어바인의 소프트웨어 아키텍처 연구 기관인 캘리포니아 대학(University of California)은 주로 건축 스타일, 아키텍처 기술 언어 및 동적 아키텍처에 중점을 두고 있습니다.

IEEE 1471-2000, 「소프트웨어 집약적인 시스템의 아키텍쳐의 설명에 관한 권장 프랙티스」는, 소프트웨어 아키텍처 분야의 최초의 정식 규격이었습니다.ISO는 2007년에 ISO/IEC 42010:2007로 채택했습니다.2011년 11월, IEEE 1471–2000은 ISO/IEC/IEE 42010:2011, "시스템 및 소프트웨어 엔지니어링 – 아키텍처 설명"(IEEE와 [12]ISO의 공동 출판)으로 대체되었습니다.

IEEE 1471에서는 소프트웨어 아키텍처가 "소프트웨어 집약적 시스템" 아키텍처에 관한 것이었지만, 2011년판은 ISO/IEC 15288 및 ISO/IEC 12207의 정의를 포함함으로써 한 걸음 더 나아갑니다.하드웨어와 소프트웨어뿐만 아니라 "하드웨어, 프로세스, 절차, 설비, 재료 및 자연적으로 발생하는 실체"를 수용하는 시스템의 ns.이는 소프트웨어 아키텍처, 엔터프라이즈 아키텍처 및 솔루션 아키텍처 간의 관계를 반영합니다.

아키텍처 활동

소프트웨어 설계자가 수행하는 많은 작업이 있습니다.일반적으로 소프트웨어 설계자는 프로젝트 매니저와 협력하여 아키텍처에 관한 중요한 요건에 대해 논의하거나 소프트웨어 아키텍처를 설계하거나 설계를 평가하거나 설계자 및 이해관계자와 커뮤니케이션하거나 아키텍처 설계를 문서화합니다.[23]소프트웨어 아키텍처 [24]설계에는 4가지 핵심 활동이 있습니다.이러한 핵심 아키텍처 활동은 시스템의 진화뿐만 아니라 초기 소프트웨어 개발 라이프사이클의 다양한 단계에서 반복적으로 수행됩니다.

아키텍처 분석은 제안된 시스템이 작동하는 환경을 이해하고 시스템의 요건을 결정하는 프로세스입니다.분석 활동에 대한 입력 또는 요구사항은 이해관계자 수에 관계없이 발생할 수 있으며 다음과 같은 항목을 포함할 수 있다.

  • 작동 시 시스템이 수행하는 작업(기능 요건)
  • ISO/IEC 25010:2011[25] 표준에 정의된 신뢰성, 조작성, 퍼포먼스 효율성, 보안, 호환성 등의 런타임 비기능 요건을 얼마나 잘 수행할 것인가
  • ISO 25010:2011[25] 표준에 정의된 유지관리성 및 이동성 등 비기능적 요구사항의 개발 시간
  • 법률, 사회, 재무, 경쟁, 기술[26] 등과 같이 시간이 지남에 따라 변경될 수 있는 시스템의 비즈니스 요건 및 환경 컨텍스트

분석 활동의 결과물은 소프트웨어 시스템의 아키텍처에 측정 가능한 영향을 미치는 요구사항으로, 이를 아키텍처상 [27]중요한 요구사항이라고 합니다.

아키텍처 합성 또는 설계는 아키텍처를 만드는 과정입니다.분석에 의해 결정되는 구조적으로 중요한 요건, 설계의 현재 상태 및 평가 활동의 결과에 따라 설계가 생성되고 [24][4]: 311–326 개선된다.

아키텍처 평가는 현재 설계 또는 그 일부가 분석 중에 도출된 요구사항을 얼마나 잘 충족하는지 결정하는 과정입니다.평가는 설계자가 설계 결정을 고려할 때마다 수행될 수 있으며, 설계의 일부분이 완료된 후에 수행될 수도 있고, 최종 설계가 완료된 후에 수행될 수도 있고, 시스템 구축 후에 수행될 수도 있습니다.사용 가능한 소프트웨어 아키텍처 평가 기법에는 아키텍처 트레이드오프 분석 방법(ATAM)과 [28]TARA가 있습니다.기술을 비교하기 위한 프레임워크는[16] SARA 보고서 및 아키텍처 리뷰: 프랙티스와 [29]익스피리언스 등의 프레임워크에서 논의됩니다.

아키텍처의 진화는 요건과 환경의 변화에 대응하기 위해 기존 소프트웨어 아키텍처를 유지 보수하고 조정하는 프로세스입니다.소프트웨어 아키텍처는 소프트웨어 시스템의 기본 구조를 제공하므로, 그 진화와 유지보수는 그 기본 구조에 영향을 미칠 수밖에 없습니다.이와 같이 아키텍처의 진화는 기존 기능과 시스템 동작을 유지할 뿐만 아니라 새로운 기능을 추가하는 것과 관련이 있습니다.

아키텍처에는 중요한 지원 활동이 필요합니다.이러한 지원 활동은 핵심 소프트웨어 아키텍처 프로세스 전체에서 수행됩니다.여기에는 지식 관리 및 커뮤니케이션, 설계 추론 및 의사결정, 문서화가 포함됩니다.

아키텍처 지원 활동

소프트웨어 아키텍처 지원 활동은 핵심 소프트웨어 아키텍처 활동 중에 수행됩니다.이러한 지원 활동은 소프트웨어 설계자가 분석, 합성, 평가 및 진화를 수행하는 데 도움이 됩니다.예를 들어, 건축가는 분석 단계에서 지식을 수집하고, 결정을 내리고, 문서를 작성해야 합니다.

  • 지식관리와 커뮤니케이션은 소프트웨어 아키텍처 설계에 필수적인 지식을 탐색하고 관리하는 행위입니다.소프트웨어 설계자는 단독으로 작업하지 않습니다.이들은 다양한 이해관계자로부터 입력, 기능 및 비기능 요건 및 설계 컨텍스트를 얻고 이해관계자에게 결과를 제공합니다.소프트웨어 아키텍처에 대한 지식은 암묵적인 경우가 많아 이해관계자의 머릿속에 남아 있습니다.소프트웨어 아키텍처 지식 관리 활동은 지식을 검색, 전달 및 유지하는 것입니다.소프트웨어 아키텍처 설계 문제는 복잡하고 상호 의존적이기 때문에 설계 추론의 지식 격차로 인해 소프트웨어 아키텍처 [23][30]설계가 잘못될 수 있습니다.지식 관리 및 커뮤니케이션 활동의 예로는 설계 패턴 검색, 프로토타이핑, 숙련된 개발자 및 설계자에게 문의, 유사한 시스템의 설계 평가, 다른 설계자 및 이해관계자와의 지식 공유, 위키 페이지에서의 경험 문서화가 있습니다.
  • 설계 추론과 의사결정은 설계 결정을 평가하는 활동입니다.이 액티비티는 3가지 핵심 소프트웨어 아키텍처 [9][31]액티비티 모두에 기본입니다.의사결정 컨텍스트를 수집하고 관련짓고, 설계 의사결정 문제를 공식화하고, 솔루션 옵션을 찾고, 의사결정을 하기 전에 트레이드오프를 평가해야 합니다.이 프로세스는 중요한 아키텍처 요건과 소프트웨어 아키텍처 결정 및 소프트웨어 아키텍처 분석, 통합 및 평가를 평가하면서 다양한 수준의 의사 결정 단계에서 발생합니다.추론 활동의 예로는 요건 또는 설계가 품질 속성에 미치는 영향 이해, 설계로 인해 야기될 수 있는 문제에 대한 질문, 가능한 솔루션 옵션 평가, 솔루션 간의 트레이드오프 평가가 포함된다.
  • 문서화는 소프트웨어 아키텍처 프로세스 중에 생성된 설계를 기록하는 작업입니다.시스템 설계는 시스템의 코드 구조를 나타내는 정적 뷰, 실행 중 시스템의 동작을 나타내는 동적 뷰 및 시스템을 실행하기 위해 하드웨어에 배치하는 방법을 나타내는 전개 뷰를 자주 포함하는 여러 뷰를 사용하여 기술됩니다.Kruchten의 4+1 뷰는 소프트웨어 [32]아키텍처 문서화에서 일반적으로 사용되는 뷰에 대한 설명을 제시합니다. 소프트웨어 아키텍처 문서화: Views and Beyond에는 뷰 설명 내에서 사용할 수 있는 [1]표기의 종류에 대한 설명이 있습니다.문서화 활동의 예로는 사양서 작성, 시스템 설계 모델 기록, 설계 근거 문서화, 관점 개발, 뷰 문서화 등이 있습니다.

소프트웨어 아키텍처 항목

소프트웨어 아키텍처 설명

주요 기사:소프트웨어 아키텍처 설명

소프트웨어 아키텍처 기술에는 아키텍처 기술 언어, 아키텍처 시점 및 아키텍처 프레임워크와 같은 메커니즘을 사용하여 아키텍처를 모델링하고 표현하는 원칙과 실천이 포함됩니다.

아키텍처 설명 언어

주요 기사:아키텍처 설명 언어

아키텍처 기술 언어(ADL)는 소프트웨어 아키텍처(ISO/IEC/IEEE 42010)를 기술하기 위해 사용되는 표현 수단입니다.AADL(SAE 표준), 라이트(카네기 멜론 개발), 아크메(카네기 멜론 개발), xADL(UCI 개발), 다윈(임페리얼 칼리지 런던 개발), DAOP-ADL(말라가 대학 개발) 등 많은 특수 목적 ADL이 1990년대부터 개발되어 왔다.yADL(이탈리아 라퀼라 대학교).

아키텍처의 시점

주요 기사:모델 표시
4+1 아키텍처 뷰 모델.

소프트웨어 아키텍처 설명은 일반적으로 뷰로 구성되며, 이는 아키텍처 구축 시 작성된 다양한 유형의 청사진과 유사합니다.각 뷰는 관점의 관례에 따라 일련의 시스템 우려에 대처합니다.여기서 뷰는 특정 이해관계자의 관점에서 해당 아키텍처를 표현하는 뷰에서 사용하는 표기, 모델링 및 분석 기술을 기술하는 사양입니다(ISO/IEC/IEE 42010).관점은 다른 관점과 일관성을 유지하기 위해 제시된 우려사항(즉, 다루어야 할 우려사항)뿐만 아니라 프레젠테이션, 사용된 모델 종류, 사용된 관례 및 일관성(대응) 규칙을 명시한다.

아키텍처 프레임워크

주요 기사:아키텍처 프레임워크

아키텍처 프레임워크는 "어플리케이션 및/또는 이해관계자 커뮤니티 내에서 확립된 아키텍처의 기술 규약, 원칙 및 관행"을 캡처한다(ISO/IEC/IEE 42010).프레임워크는 보통 1개 이상의 시점(ADL)으로 구현됩니다.

건축 스타일과 패턴

아키텍처 패턴은 특정 컨텍스트 내에서 소프트웨어 아키텍처에서 일반적으로 발생하는 문제에 대한 일반적인 재사용 가능한 솔루션입니다.아키텍처 패턴은 소프트웨어 설계 패턴으로 문서화되는 경우가 많습니다.

전통적인 건축양식에 이어 '소프트웨어 건축양식'은 특정 건축방식으로, 이를 두드러지게 하는 특징이 있습니다.(건축양식)

아키텍처 스타일은 구조조직 패턴에 관한 시스템 패밀리, 컴포넌트 및 커넥터의 어휘, 결합 방법에 대한 제약이 있는 시스템을 정의합니다.[33]

아키텍처 스타일은 설계 결정과 제약의 재사용 가능한 '패키지'로, 선택된 바람직한 품질을 유도하기 위해 아키텍처에 적용됩니다.[34]

그 중에서도 많은 아키텍처 패턴과 스타일이 인정되고 있습니다.

건축 패턴과 건축 스타일을 동일하게 [35]취급하는 사람도 있고, 스타일을 패턴의 전문화로 취급하는 사람도 있습니다.이들의 공통점은 패턴과 스타일 모두 건축가가 사용하는 관용어이며, 시스템 클래스를 기술하기 위한 "공통 언어"[35] 또는 "어휘"[33]를 제공한다는 것입니다.

소프트웨어 아키텍처 및 신속한 개발

주요 기사:신속한 개발

또한 소프트웨어 아키텍처가 특히 신속한 변화를 위한 소프트웨어 개발 지지자들 사이에서 너무 많은 빅 디자인 프런트(Big Design Up Front)를 초래한다는 우려도 있습니다.「충분한」아키텍쳐의 기반이 구축되는 「기초」의 단계를 필요로 하는 민첩한 방법 DSDM을 포함해, 선행 설계와 [36]민첩성의 밸런스를 맞추기 위해서 많은 방법이 개발되고 있습니다.IEEE Software는 민첩성과 아키텍처 간의 상호 작용에 특별한 호를 할애했습니다.

소프트웨어 아키텍처의 잠식

소프트웨어 아키텍처의 침식(또는 "쇠락")은 소프트웨어 시스템의 [37]구현에서 실현된 계획된 아키텍처와 실제 아키텍처 간의 차이를 말합니다.소프트웨어 아키텍처 잠식은 구현 결정이 계획한 대로 아키텍처를 완전히 달성하지 못하거나 아키텍처의 제약 [2]또는 원칙을 위반할 때 발생합니다.

예를 들어, 각 계층은 바로 아래의 계층에서 제공하는 서비스만 사용할 수 있는 엄격하게 계층화된 시스템을 고려하십시오.이 제약 조건을 준수하지 않는 모든 소스 코드 구성 요소는 아키텍처 위반을 나타냅니다.이러한 위반을 수정하지 않으면 아키텍처를 단일 블록으로 전환하여 이해성, 유지보수성 및 진화 가능성에 악영향을 미칠 수 있습니다.

침식을 다루기 위해 다양한 접근법이 제안되었다.툴, 기술, 프로세스를 포함한 이러한 접근법은 주로 아키텍처 침식을 최소화, 방지 및 복구하는 세 가지 일반적인 범주로 분류됩니다.이러한 광범위한 범주 내에서 각 접근방식은 침식 문제를 해결하기 위해 채택된 높은 수준의 전략을 반영하여 더욱 세분화됩니다.프로세스 지향 아키텍처 컴플라이언스, 아키텍처 진화 관리, 아키텍처 설계 적용, 아키텍처에서 구현 링크, 자가 적응 및 아키텍처 복원 기술로, 복구, 검색 및 [38]조정으로 구성됩니다."

아키텍처 위반을 검출하는 주요 기술은 리플렉션모델과 도메인 고유의 언어 두 가지가 있습니다.리플렉션 모델(RM) 기법은 시스템 설계자가 제공하는 개략적인 모델과 소스 코드 구현을 비교합니다.또, 아키텍처의 제약 조건을 지정 및 확인하는 것에 초점을 맞춘 도메인 고유의 언어도 있습니다.

소프트웨어 아키텍처 복구

주요 기사:소프트웨어 아키텍처 복구

소프트웨어 아키텍처 복구(또는 재구축 또는 리버스 엔지니어링)에는 소프트웨어 시스템의 아키텍처를 구현 및 문서 등 사용 가능한 정보에서 발견하는 방법, 기술 및 프로세스가 포함됩니다.구식 또는 구식 문서 및 아키텍처 잠식(예상 [39]아키텍처에서 구현 및 유지보수에 관한 의사결정)에 직면하여 정보에 근거한 의사결정을 하기 위해 아키텍처 복구가 필요한 경우가 많습니다.소프트웨어 아키텍처를 정적 프로그램 분석으로 복구하는 방법이 있습니다.이것은 소프트웨어 인텔리전스 연습의 대상이 되는 과목의 일부입니다.

관련 필드

설계.

주요 기사:소프트웨어 설계

건축은 디자인이지만 모든 디자인이 [1]건축인 것은 아닙니다.실제로 설계자는 소프트웨어 아키텍처(아키텍처 설계)와 상세 설계(비아키텍처 설계)를 구분하는 사람입니다.이 구별을 공식화하려는 시도는 있었지만 모든 경우에 맞는 규칙이나 지침은 없습니다.Intension/[40]Lociality 가설에 따르면 건축설계와 상세설계의 구별은 Locality [40]Criterion에 의해 정의됩니다.Locial Criterion에 따르면 소프트웨어 설계에 대한 설명은 이를 충족하는 프로그램이 그렇지 않은 프로그램으로 확장될 수 있는 경우에만 로컬(아키텍처)이 아닙니다.예를 들어 클라이언트-서버 스타일은 아키텍처(전략적)입니다.이는 이 원칙을 기반으로 구축된 프로그램이 피어 투 피어 노드를 추가하는 등 클라이언트-서버 이외의 프로그램으로 확장될 수 있기 때문입니다.

요건 엔지니어링

주요 기사: 요건 엔지니어링

요건 엔지니어링과 소프트웨어 아키텍처는 상호 보완적인 접근법으로 볼 수 있습니다.소프트웨어 아키텍처는 '솔루션 공간' 또는 '방법'을 대상으로 하고 요건 엔지니어링은 '문제 공간' 또는 '무엇'[41]을 대상으로 합니다.요건 엔지니어링은 요건의 도출, 협상, 사양, 검증, 문서화 및 관리를 수반합니다.요건 엔지니어링과 소프트웨어 아키텍처는 모두 이해관계자의 우려, 요구 및 희망에 중점을 두고 있습니다.

요건 엔지니어링과 소프트웨어 아키텍처 사이에는 상당한 중복이 있습니다.예를 들어 5가지 산업용 소프트웨어 아키텍처 방법에 대한 연구에서는 "입력(목표, 제약 등)이 일반적으로 잘못 정의되어 아키텍처가 출현하기 시작할 때에만 발견되거나 더 잘 이해됩니다."라고 결론을 내렸습니다."대부분의 아키텍처상의 우려는 시스템에 대한 요구사항으로 표현되지만, 여기에는 의무적인 설계 [24]결정도 포함될 수 있다."즉, 필요한 동작은 솔루션 아키텍처에 영향을 미쳐 새로운 [42]요건이 도입될 수 있습니다.Twin Peaks[43] 모델과 같은 접근방식은 요구사항과 아키텍처 간의 시너지 관계를 활용하는 것을 목표로 합니다.

기타 유형의 '아키텍처'

주요 기사:컴퓨터 아키텍처, 시스템 아키텍처 및 엔터프라이즈 아키텍처
컴퓨터 아키텍처
컴퓨터 아키텍처는 CPU(또는 프로세서)와 같은 하드웨어 컴포넌트와 버스와 메모리를 협업하는 측면에서 컴퓨터 시스템의 내부 구조를 대상으로 합니다.
시스템 아키텍처
시스템 아키텍처라는 용어는 원래 하드웨어와 소프트웨어 모두로 구성된 시스템 아키텍처에 적용되었습니다.시스템 아키텍처에서 가장 중요한 문제는 소프트웨어와 하드웨어를 완전히 올바르게 작동하는 장치에 통합하는 것입니다.또 다른 공통적인 의미, 훨씬 더 넓은 의미에서는 이 용어는 기술적, 사회적 성질의 복잡한 시스템의 아키텍처에 적용된다.
엔터프라이즈 아키텍처
엔터프라이즈 아키텍처의 목표는 "비즈니스 비전과 전략을 효과적인 엔터프라이즈로 변환"하는 것입니다.TOGAF 및 Zachman Framework와 같은 엔터프라이즈 아키텍처 프레임워크는 일반적으로 서로 다른 엔터프라이즈 아키텍처 계층을 구분합니다.용어는 프레임워크마다 다르지만 비즈니스 계층, 애플리케이션(또는 정보) 계층 및 기술 계층 간의 구별이 대부분 포함되어 있습니다.엔터프라이즈 아키텍처는 이러한 계층 간의 정렬을 주로 하향식 접근 방식으로 해결합니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ a b c Clements, Paul; Felix Bachmann; Len Bass; David Garlan; James Ivers; Reed Little; Paulo Merson; Robert Nord; Judith Stafford (2010). Documenting Software Architectures: Views and Beyond, Second Edition. Boston: Addison-Wesley. ISBN 978-0-321-55268-6.
  2. ^ a b c d Perry, D. E.; Wolf, A. L. (1992). "Foundations for the study of software architecture" (PDF). ACM SIGSOFT Software Engineering Notes. 17 (4): 40. CiteSeerX 10.1.1.40.5174. doi:10.1145/141874.141884. S2CID 628695.
  3. ^ "Software Architecture". www.sei.cmu.edu. Retrieved 2018-07-23.
  4. ^ a b c d e f g h i j Bass, Len; Paul Clements; Rick Kazman (2012). Software Architecture in Practice, Third Edition. Boston: Addison-Wesley. ISBN 978-0-321-81573-6.
  5. ^ SEI (2006). "How do you define Software Architecture?". Retrieved 2012-09-12.
  6. ^ Garlan & Shaw (1994). "An Introduction to Software Architecture" (PDF). Retrieved 2012-09-13.
  7. ^ a b Fowler, Martin (2003). "Design – Who needs an architect?". IEEE Software. 20 (5): 11–44. doi:10.1109/MS.2003.1231144. S2CID 356506.
  8. ^ ISO/IEC/IEE 42010: 「아키텍처」의 정의.Iso-architecture.org 를 참조해 주세요.2013-07-21에 회수.
  9. ^ a b Jansen, A.; Bosch, J. (2005). "Software Architecture as a Set of Architectural Design Decisions". 5th Working IEEE/IFIP Conference on Software Architecture (WICSA'05). p. 109. CiteSeerX 10.1.1.60.8680. doi:10.1109/WICSA.2005.61. ISBN 978-0-7695-2548-8. S2CID 13492610.
  10. ^ Ali Babar, Muhammad; Dingsoyr, Torgeir; Lago, Patricia; van Vliet, Hans (2009). Software Architecture Knowledge Management. Dordrecht Heidelberg London New York: Springer. ISBN 978-3-642-02373-6.
  11. ^ a b c George Fairbanks (2010). Just Enough Software Architecture. Marshall & Brainerd.
  12. ^ a b ISO/IEC/IEEE (2011). "ISO/IEC/IEEE 42010:2011 Systems and software engineering – Architecture description". Retrieved 2012-09-12.
  13. ^ Muller, Gerrit (August 20, 2007). "A Reference Architecture Primer" (PDF). Gaudi site. Retrieved November 13, 2015.
  14. ^ Angelov, Samuil; Grefen, Paul; Greefhorst, Danny (2009). "A Classification of Software Reference Architectures: Analyzing Their Success and Effectiveness". Proc. Of WICSA/ECSA 2009: 141–150. CiteSeerX 10.1.1.525.7208. doi:10.1109/WICSA.2009.5290800. ISBN 978-1-4244-4984-2. S2CID 10417628.
  15. ^ Brooks, Jr., Frederick P. (1975). The Mythical Man-Month – Essays on Software Engineering. Addison-Wesley. ISBN 978-0-201-00650-6.
  16. ^ a b Obbink, H.; Kruchten, P.; Kozaczynski, W.; Postema, H.; Ran, A.; Dominick, L.; Kazman, R.; Hilliard, R.; Tracz, W.; Kahane, E. (Feb 6, 2002). "Software Architecture Review and Assessment (SARA) Report" (PDF). Retrieved November 1, 2015.
  17. ^ Poort, Eltjo; van Vliet, Hans (September 2012). "RCDA: Architecting as a risk- and cost management discipline". Journal of Systems and Software. 85 (9): 1995–2013. doi:10.1016/j.jss.2012.03.071.
  18. ^ P. Naur; B. Randell, eds. (1969). "Software Engineering: Report of a conference sponsored by the NATO Science Committee, Garmisch, Germany, 7–11 Oct. 1968" (PDF). Brussels: NATO, Scientific Affairs Division. Retrieved 2012-11-16.
  19. ^ P. Kruchten; H. Obbink; J. Stafford (2006). "The past, present and future of software architecture". IEEE Software. 23 (2): 22. doi:10.1109/MS.2006.59. S2CID 2082927.
  20. ^ University of Waterloo (2006). "A Very Brief History of Computer Science". Retrieved 2006-09-23.
  21. ^ IEEE Transactions on Software Engineering (2006). "Introduction to the Special Issue on Software Architecture". doi:10.1109/TSE.1995.10003. {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  22. ^ Garlan & Shaw (1994). "An Introduction to Software Architecture" (PDF). Retrieved 2006-09-25.
  23. ^ a b Kruchten, P. (2008). "What do software architects really do?". Journal of Systems and Software. 81 (12): 2413–2416. doi:10.1016/j.jss.2008.08.025.
  24. ^ a b c Christine Hofmeister; Philippe Kruchten; Robert L. Nord; Henk Obbink; Alexander Ran; Pierre America (2007). "A general model of software architecture design derived from five industrial approaches". Journal of Systems and Software. 80 (1): 106–126. doi:10.1016/j.jss.2006.05.024.
  25. ^ a b ISO/IEC (2011). "ISO/IEC 25010:2011 Systems and software engineering – Systems and software Quality Requirements and Evaluation (SQuaRE) – System and software quality models". Retrieved 2012-10-08.
  26. ^ Osterwalder and Pigneur (2004). "An Ontology for e-Business Models" (PDF). Value Creation from E-Business Models. pp. 65–97. CiteSeerX 10.1.1.9.6922. doi:10.1016/B978-075066140-9/50006-0. ISBN 9780750661409. S2CID 14177438. Archived from the original (PDF) on 2018-11-17.
  27. ^ Chen, Lianping; Ali Babar, Muhammad; Nuseibeh, Bashar (2013). "Characterizing Architecturally Significant Requirements". IEEE Software. 30 (2): 38–45. doi:10.1109/MS.2012.174. hdl:10344/3061. S2CID 17399565.
  28. ^ Woods, E. (2012). "Industrial architectural assessment using TARA". Journal of Systems and Software. 85 (9): 2034–2047. doi:10.1016/j.jss.2012.04.055. S2CID 179244.
  29. ^ Maranzano, J. F.; Rozsypal, S. A.; Zimmerman, G. H.; Warnken, G. W.; Wirth, P. E.; Weiss, D. M. (2005). "Architecture Reviews: Practice and Experience". IEEE Software. 22 (2): 34. doi:10.1109/MS.2005.28. S2CID 11697335.
  30. ^ Babar, M.A.; Dingsøyr, T.; Lago, P.; Vliet, H. van (2009). Software Architecture Knowledge Management:Theory and Practice (eds.), First Edition. Springer. ISBN 978-3-642-02373-6.
  31. ^ Tang, A.; Han, J.; Vasa, R. (2009). "Software Architecture Design Reasoning: A Case for Improved Methodology Support". IEEE Software. 26 (2): 43. doi:10.1109/MS.2009.46. hdl:1959.3/51601. S2CID 12230032.
  32. ^ Kruchten, Philippe (1995). "Architectural Blueprints – The '4+1' View Model of Software Architecture" (PDF). IEEE Software. 12 (6): 42–50. arXiv:2006.04975. doi:10.1109/52.469759. S2CID 219558624.
  33. ^ a b Shaw, Mary; Garlan, David (1996). Software architecture: perspectives on an emerging discipline. Prentice Hall. ISBN 978-0-13-182957-2.
  34. ^ UCI 소프트웨어 아키텍처 조사– UCI 소프트웨어 아키텍처 조사: 아키텍처 스타일.Isr.uci.edu 를 참조해 주세요.2013-07-21에 회수.
  35. ^ a b 3장: 건축 패턴과 스타일Msdn.microsoft.com 를 참조해 주세요.2013-07-21에 회수.
  36. ^ Boehm, Barry; Turner, Richard (2004). Balancing Agility and Discipline. Addison-Wesley. ISBN 978-0-321-18612-6.
  37. ^ Terra, R., M.T. Valente, K. Chzarnecki 및 R.S. Bigonha, "Refactorings to Reverse Software Architecture Avilation", 2012년 제16회 유럽 소프트웨어 유지보수 및 리엔지니어링 컨퍼런스http://gsd.uwaterloo.ca/sites/default/files/Full%20Text.pdf
  38. ^ de Silva, L.; Balasubramaniam, D. (2012). "Controlling software architecture erosion: A survey". Journal of Systems and Software. 85 (1): 132–151. doi:10.1016/j.jss.2011.07.036.
  39. ^ Lungu, M. "소프트웨어 아키텍처 리커버리", 루가노 대학, 2008.http://www.slideshare.net/mircea.lungu/software-architecture-recovery-in-five-questions-presentation
  40. ^ a b Amnon H. Eden; Rick Kazman (2003). "Architecture Design Implementation" (PDF). Archived from the original (PDF) on 2007-09-28.
  41. ^ C. Shekaran; D. Garlan; M. Jackson; N.R. Mead; C. Potts; H.B. Reubenstein (1994). "The role of software architecture in requirements engineering". Proceedings of IEEE International Conference on Requirements Engineering: 239–245. doi:10.1109/ICRE.1994.292379. ISBN 978-0-8186-5480-0. S2CID 3129363.
  42. ^ Remco C. de Boer, Hans van Vliet (2009). "On the similarity between requirements and architecture". Journal of Systems and Software. 82 (3): 544–550. CiteSeerX 10.1.1.415.6023. doi:10.1016/j.jss.2008.11.185.
  43. ^ Bashar Nuseibeh (2001). "Weaving together requirements and architectures" (PDF). Computer. 34 (3): 115–119. doi:10.1109/2.910904.

추가 정보

외부 링크

Wikimedia Commons에는 소프트웨어 아키텍처와 관련된 미디어가 있습니다.
Wikiquote에는 소프트웨어 아키텍처에 관한 인용문이 있습니다.