가이드라인: 아키텍처 발견, 분석 및 제어
이 가이드라인에서는 프로젝트에 맞는 RSA 모델링 환경을 사용하여 아키텍처 발견, 분석 및 제어를 수행하는 방법을 설명합니다.
관계
관련 요소
기본 설명

소개

RUP의 몇몇 타스크에서는 최근 디자인 모델을 점검하고 다양한 품질 측면에 대해 판단하여 필요에 따라 모델을 리팩터해야 합니다. 일단 시스템이 구현 단계로 이동되면 시스템의 아키텍처 무결성을 유지보수 할 수 있고, 구조 및 디자인 제한조건을 위반하지 않게 되며, 시스템이 구현될 때 계속 아키텍처 비전과 맞출 수 있다는 점도 중요합니다. RUP에서, 이와 같은 주요 체크포인트는 타스크: 아키텍처 검토, review_the_design_gui_design코드 검토에서 발생합니다.

아키텍처 및 디자인 통합 중에 서로 다르지만 관련이 있는 문제점이 발생합니다. 타스크 아키텍처 분석(아키텍처 개요 개발사용 가능한 자산 조사 참조)과 기존 디자인 요소 통합에서는 소프트웨어 설계자가 기존 디자인 및 코드 자산을 다시 사용할 기회를 찾아서 필요에 따라 리버스 엔지니어링 이후에 디자인 모델에 통합해야 합니다. 재사용한 자산에 일부 품질 인증 유형이 포함되어 있지 않으면 소프트웨어 설계자는 새로 작성한 디자인 및 코드의 경우와 마찬가지로 자세히 조사합니다.

두 경우 모두 다음 정적 분석을 위해 소프트웨어 설계자가 계속 필요합니다.

  • 코드된 응용프로그램(또는 단편)을 가져오려면 기호 구조를 발견한 후 UML 형식으로 복구하십시오. 디자인 모델로 복구하는 것이 이상적입니다. 또한 찾아볼 수 있는 문서 아티팩트를 복구하는 일은 소프트웨어 설계자로 하여금 코드가 실제로 구조화된 방법, 문서가 존재하지 않는 시기 또는 만료된 시기를 알 수 있도록 하는 데 있어 중요한 가치를 가집니다.
  • 디자인 모델을 분석할 수 있으려면 아티팩트: 측정 계획에서 수집하는 품질 메트릭(예: 용어 정의: 결합)을 수집하고 아티팩트: 소프트웨어 아키텍처 문서디자인 가이드라인을 준수하는지 확인하십시오.
  • 필요한 경우 정정 조치를 취할 수 있도록 중요한 구조 또는 디자인 변경사항을 알고 있어야 합니다. 소프트웨어 설계자가 설정한 기준에 의거하여 중요성을 판단합니다.

이론적으로는 검사를 통해 이러한 요구를 충족시킬 수 있지만 실제로는 보다 복잡한 대형 시스템의 경우 일부 유형의 자동화된 지원이 필요합니다. 다음 섹션에서는 이러한 주제에 대한 몇 가지 구현 및 도구 지원의 예를 제공합니다.

아키텍처 발견 및 복구

배경

그린 필드 개발에서 소프트웨어 구조는 요구사항, 도메인 컨텍스트 및 규칙(패턴 및 메커니즘 포함)으로부터 나타나는데, 추가 스펙 아티팩트는 이 구조를 결정할 때 중요한 역할을 합니다. 요구사항에서 구조로 직접적이고 기계적으로 맵핑되는 경우가 드물기 때문에 소프트웨어 구조를 형성하는 이 프로세스를 발견이라고도 합니다. 그러나 여기서는 소프트웨어 설계자가 기존 응용프로그램 또는 응용프로그램 단편을 코드화된 양식으로 이해하도록 도와주는 프로세스를 설명하기 위해 발견을 다른 의미로 사용합니다. 아키텍처 복구는 보다 야심적입니다. 소프트웨어 설계자는 복구를 통해 응용프로그램을 이해하고자 할 뿐만 아니라 이상적으로 디자인 모델과 호환 가능한 추상 레벨에서 해당 응용프로그램의 모델을 추출하려고 합니다. 이와 같은 모델을 병합하고 용어 정의: 변환을 통해 서로 다른 용어 정의: 플랫폼에 대해 새 응용프로그램을 생성할 가능성이 있습니다.

발견

타스크: 아키텍처 분석(아키텍처 개요 개발사용 가능한 자산 조사 참조)와 기존 디자인 요소 통합에서, 소프트웨어 설계자는 기존 디자인 및 코드 자산을 다시 사용할 기회를 찾습니다. 예를 들어, 조직은 그 자산 기초에 여러 참조 구조를 가질 수 있는데, 이상적으로 이들 구조는 최신 문서 및 모델로 완전히 갖춰져 있습니다. 그러나 소스 코드만 있는 경우가 많으며 아키텍처 문서가 있는 경우 현재 문서가 아닙니다.

많은 경우에 소프트웨어 설계자는 인터페이스가 명확히 정의된 경우에도 이러한 코드를 블랙 박스로 취급할 수 없지만 그 구조는 이해해야 합니다. 이 프로세스는 이 코드의 찾아볼 수 있는 설명을 자동으로 생성할 수 있는 기능에 의해 크게 도움을 받습니다. 그러면 소프트웨어 설계자가 코드에서 패턴과 안티패턴을 시각적으로 '발견'할 수 있습니다. Rational Software Architect 도구에서 이러한 지원 유형의 예를 찾아볼 수 있습니다. 이 도구에서 아키텍처 발견 기능은 Java 응용프로그램에 대한 패키지 구조, 클래스 내부, 상속 트리 및 협업과 같은 토픽 다이어그램을 자동으로 채워줍니다. 자세한 정보는 도움말 서적 아이콘 Rational Software Architect 문서를 참조하십시오.

복구 및 변환

재사용가능한 자산이 모델을 갖추고 있는 경우, 이들 모델을 프로젝트 특정 모델과 결합한 후 변환 기법을 통해 플랫폼 특정 구현으로 계속 수행할 수 있습니다. 코드만 있는 경우에도 변환을 통해 생성된 코드를 레거시 코드와 통합시켜 변환 기반 접근 방식을 통해 코드를 재사용할 수 있습니다.

소프트웨어 설계자는 구조 복구의 사용을 통해 대부분의 능력과 유연성을 가집니다. 복구 성능은 시맨틱적으로 풍부한 응용프로그램 모델을 생성하여 찾아보기에는 물론 코드 생성에도 사용할 수 있습니다. 실제로는, 코드를 다시 직접적인 시각적 표시로 리버스 엔지니어링하는 것은 대체로 쉽습니다. 모델을 용어 정의: 플랫폼 독립 모델 디자인 모델과 같은 레벨로 추상화하는 것은 일반적으로 완전히 자동화하기 어렵습니다.

이는 특히 용어 정의: 플랫폼 특정 모델에서 용어 정의: 플랫폼 독립 모델(PIM)로의 변환(개념: 모델 기반 개발(MDD) 및 모델 기반 아키텍처(MDA ) 참조)입니다. 복구된 PIM(단편)은 모델 병합 변환 유형을 사용하여 디자인 모델(PIM 자체)과 결합합니다([OMG03] 참조).

아키텍처 분석

찾아볼 수 있는 모델이 있으면 소프트웨어 설계자가 검사를 통해 아키텍처 품질을 확인할 수 있습니다. 그러나 이 작업은 지루하고 시간이 많이 소요될 수 있으며, 이 방식으로 메트릭을 수집하고 표준 및 규칙 준수를 확인하면 오류가 발생하기 쉽습니다. 소프트웨어 설계자는 되도록 이 프로세스를 자동화하려고 하므로, 해결책을 찾아서 적용하는 데 많은 시간을 소비합니다. 자동화하면 소프트웨어 설계자가 "만약의 문제(what if)"에 대해 실험하고 신속하게 결과를 확인할 수 있습니다.

무엇을 자동화할 수 있습니까?

자동화된 아키텍처 분석은 다음을 수행할 수 있습니다.

  • 구조에서 패턴 및 안티패턴(병적인 구조)을 찾을 수 있습니다.
  • 다양한 구조에 대해 측정을 수행하고 메트릭을 보고할 수 있습니다.
  • 소프트웨어 설계자의 제한조건을 준수하는지 확인할 수 있습니다(아키텍처 제어 참조).

용어 정의: 패턴은 프로젝트와 조직 표준의 지시에 따르며, 사용에 대한 근거는 소프트웨어 아키텍처 문서(아키텍처 측면에서 중요한 경우)나 디자인 가이드라인에서 캡처됩니다. 자동화된 분석을 통해 소프트웨어 설계자는 패턴 사용을 신속히 확인하여 소프트웨어 구조 문서 및 디자인 가이드라인의 취지에 맞는지 확인할 수 있습니다. 안티패턴은 구조를 좀더 유지보수하기 어렵게 만들거나 좀더 복잡하게 또는 덜 강력하게 만들어 다소간 구조를 약화시키는 병적인 구조 및 디자인 구조입니다.

수행할 측정은 중간 산출물: 측정 계획에서 수집됩니다(일부 제시된 메트릭은 가이드라인: 메트릭에서 볼 수 있음). 평가 계획은 메트릭 사용 방법(예: 높은 값이 적합한지 낮은 값이 적합한지 여부 또는 중요한 경향인지 여부)도 설명하므로, 메트릭 분석을 통해 핫 스팟(구조에서 변경하면 수집된 메트릭을 크게 향상시킬 수 있는 위치)을 식별하는 것도 유용합니다. 이들 메트릭은 구조의 병리와 연관된 경우가 많습니다. 그런 다음, 소프트웨어 설계자는 개선을 위한 목표 기반을 갖게 되고, 변경사항을 작성하거나 완료되면 테스트될 수 있는 후속 조치를 위임할 수 있습니다.

분석 대상은 무엇입니까?

분석 대상은 선택한 개발 접근 방식에 따라 라이프사이클 전체에서 다양할 수 있습니다. 프로젝트가 변환적(일반적) 접근 방식을 사용할 경우, 생성된 응용프로그램이 항상 디자인과 동기화된다는 가정 하에 일반적으로 디자인 모델이 대상이 됩니다. 아티팩트: 구현 모델을 작성하여 별도로 유지보수하거나 코드를 다시 사용하는 경우, 초점을 코드에 맞춰서, 소프트웨어 아키텍처 문서와 디자인 가이드라인에 대해 측정될 때 아키텍처 무결성이 유지되는지 확인합니다.

구현 모델에 대한 이러한 유형의 분석은 실제로 분석 목적으로 코드에서 명시적 디자인 모델을 복구할 수 없습니다. 그렇지만 코드에 명백히 문제가 있기 때문에 코딩 표준이 아니라 구조 및 디자인 문제와 관련되어 있습니다.

이들 개념 및 성능 예

Rational Software Architect 도구는 아키텍처 발견을 통해 Java 응용프로그램용 문서를 복구하는 기능 외에도 구조에서 잠재적으로 문제를 일으킬 수 있는 위치를 표시할 수 있는 사전정의된 패턴 세트를 식별하고 보고할 수 있습니다. 이러한 패턴은 다음과 같습니다.

  • 버터플라이
  • 분리 가능
  • 허브
  • 탱글(tangle)
버터플라이

버터플라이는 버터플라이가 변경될 경우 영향을 받게 되는 다른 종속 요소와 많은 관련을 갖고 있는 요소(예: 클래스)입니다. 관계가 직접적일 경우, 이런 요소를 로컬 버터플라이라고 합니다. Rational Software Architect는 응용프로그램을 계단식으로 수행할 때 관계를 추적하고, 요소 변경사항이 직접 종속사항 뿐 아니라 그 하위 종속사항에도 차례로 영향을 미쳐 전체 응용프로그램으로 전이되는지 여부를 판별할 수도 있습니다. 간접 종속성이 많은 요소를 글로벌 버터플라이라고 합니다. 아래의 그림은 로컬 버터플라이의 예시입니다. 이 다이어그램은 관계가 UML 종속성이 아닌 다른 종속성이 될 수 있음도 보여줍니다. 예를 들어, 한 요소가 다른 요소를 구현할 때 이 요소는 다른 요소에 종속되고 지정하는 요소가 변경되면 이 요소를 구현하는 다른 요소도 영향을 받게 됩니다.

네 개의 종속자(사용 종속성을 갖는 두 개와 일반화 관계를 갖는 한 개, 실현 관계를 갖는 한 개)를 가지고 있는 클래스

로컬 버터플라이

분리 가능

분리 가능은 종속성이 많은 요소입니다. 즉, 다른 요소에 종속되는 많은 관계를 갖고 있습니다. 이들 다른 요소를 변경하면 분리 가능에 영향을 주게 됩니다. 버터플라이처럼, 관계가 직접적이면 이 요소를 로컬 분리 가능이라고 하고 요소에 영향을 주는 많은 간접적 관계가 있는 경우에는 글로벌 분리 가능이라고 합니다. 글로벌 분리 가능은 응용프로그램의 많은 부분에서 변경되기 쉬우며, 모듈성의 부족을 나타냅니다. 아래의 그림은 로컬 분리 가능에 대한 예시입니다.

네 개의 종속자(사용 종속성 관계에 의해 두 개, 일반화 관계에 의해 한 개, 실현 관계에 의해 한 개)를 가지고 있는 클래스.

로컬 분리 가능

허브

허브는 버터플라이와 분리 가능의 특성을 결합한 요소입니다. 또한 로컬글로벌 양식도 있습니다. 글로벌 허브가 있으면 파티셔닝이 잘못되어 있음을 나타내며, 소프트웨어가 변경(전체 응용프로그램에 영향을 주는 변경)에 극도로 민감해집니다.

탱글(tangle)

탱글(tangle)은 관계가 매우 복잡해서 관계 중 하나를 변경하면 다른 모든 관계에 영향을 줄 수 있는 대형 요소 그룹입니다. 이러한 구조는 주요 불안정성의 원인입니다.

소프트웨어 설계자는 Rational Software Architect 도구와 공동으로 이러한 핫 스팟을 신속히 발견하고 디자이너와 함께 이를 수정할 수 있습니다. 자세한 정보는 도움말 서적 아이콘 Rational Software Architect 문서를 참조하십시오.

타이밍

분석 결과는 어떤 검토 이정표에서나 아키텍처 및 디자인 품질의 목적 및 정량적 증거로서, 또는 디자인 모델의 조직 갱신(타스크: 기존 디자인 요소 통합)에서와 같이 중요한 아키텍처 변경이 있을 때 가치가 있습니다.

아키텍처 제어

소프트웨어 설계자의 비전은 소프트웨어 설계자 문서에 캡처되어 있으며, 디자이너용 실제 가이드는 디자인 가이드라인을 참조하십시오. 모든 직원들이 이 비전을 공유하는 경우에도 프로젝트 작업의 일상적 긴급성으로 인해 비전이 모호해질 수가 있습니다. 최종 기한을 맞춰야 하기 때문에 안이한 방법을 택할 수 있으며, 일반적으로 소프트웨어 설계자가 모든 결정에 참여할 수는 없습니다. 따라서 제어 문제점이 발생합니다. 프로젝트 관리자가 임계값 및 한계를 설정하고 모니터해야 하는 것처럼(타스크: 프로젝트 상태 모니터 참조), 소프트웨어 설계자는 최근 소프트웨어 디자인 및 구현에 대해 유사한 타스크를 갖고 있습니다.

소프트웨어 설계자는 아키텍처 제어를 통해 아키텍처 제한조건을 강제 수행하는 규칙을 작성할 수 있습니다. 예를 들어, 소프트웨어 설계자는 특정 인터페이스를 구현할 때마다 경고를 발생시키는 규칙을 정의할 수 있습니다. 도구 지원을 사용하지 않고 이 규칙을 간단히 표현하려면 위반을 포착하기 위한 상시 검토가 다소 필요합니다. 자동화를 통해 구조 분석 중 규칙 세트의 위반을 포착할 수 있도록 규칙을 인코딩할 수 있습니다. 자동화는 사후에도 계속 발생하므로, 고급 제어 환경은 이들 규칙을 디자인 및 코드 생산 프로세스에 인코딩하여 첫째로 규칙 위반이 발생하지 않도록 하며, 발생하더라도 수동 검토 프로세스를 크게 향상시켜줍니다.

Rational Software Architect 도구는 Java 응용프로그램에 대해 이러한 성능을 포함하고 있으며, 소프트웨어 설계자는 규칙을 설정한 후 분석을 실행하여 준수하는지 확인할 수 있습니다. 자세한 정보는 도움말 서적 아이콘 Rational Software Architect 문서를 참조하십시오.