주제

소개 페이지 맨 위

RUP의 여러 가지 활동에서 최근 생겨난 설계 모델의 조사에 대한 필요성을 검토하고, 여러 품질 측면에 대한 판단을 한 후, 필요하면 이 모델을 리팩토링합니다. 일단 시스템이 구현 단계로 이동되면 시스템의 구조적 무결성을 유지보수 할 수 있고, 구조 및 설계 제한조건을 위반하지 않게 되며, 시스템이 구현될 때 계속 구조적 시각과 맞출 수 있다는 점도 중요합니다. RUP에서 이러한 주요 체크포인트는 구조 검토, 설계 검토코드 검토 활동에서 발생합니다.

구조 및 설계 통합 중 다르긴 하지만 서로 관련이 있는 문제점이 구조적 분석(구조 개발 개요사용 가능 자산 조사 참조) 및 기존 설계 요소 통합 활동에서 발생하며, 소프트웨어 아키텍트는 기존 설계 및 코드 자산을 재사용할 기회를 모색하고 필요하면 리버스 엔지니어링 후 이를 설계 모델에 통합하는 것이 좋습니다. 재사용한 자산에 일부 품질 인증 유형이 포함되어 있지 않으면 소프트웨어 아키텍트는 새로 작성한 설계 및 코드의 경우와 마찬가지로 자세히 조사합니다.

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

  • 코드된 어플리케이션(또는 단편)을 가져오려면 기호 구조를 발견한 후 UML 형식으로 복구하십시오. 설계 모델로 복구하는 것이 이상적입니다. 또한 찾아볼 수 있는 문서 결과물을 복구하는 일은 소프트웨어 아키텍트로 하여금 코드가 실제로 구조화된 방법, 문서가 존재하지 않는 시기 또는 만료된 시기를 알 수 있도록 하는 데 있어 중요한 가치를 가집니다.
  • 설계 모델을 분석할 수 있으려면 ../artifact/ar_metr.htm -- This hyperlink in not present in this generated website결과물: 평가 계획에서 호출된 품질 메트릭(예: 결합)을 수집하고 결과물: 소프트웨어 구조 문서../artifact/ar_projspecgls.htm -- This hyperlink in not present in this generated website설계 가이드라인을 준수하는지 확인하십시오.
  • 필요한 경우 정정 조치를 취할 수 있도록 중요한 구조 또는 설계 변경사항을 알고 있어야 합니다. 소프트웨어 아키텍트가 설정한 기준에 의거하여 중요성을 판단합니다.

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

구조 발견 및 복구 페이지 맨 위

배경

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

발견

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

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

복구 및 변환

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

소프트웨어 아키텍트는 구조 복구의 사용을 통해 대부분의 능력과 유연성을 가집니다. 복구 성능은 의미론적으로 풍부한 어플리케이션 모델을 생성하여 찾아보기에는 물론 코드 생성에도 사용할 수 있습니다. 실제로 리버스 엔지니어링 코드를 다시 직접적인 시각적 표현으로 되돌리기는 쉽습니다. 하지만 이러한 모델을 플랫폼 독립 설계 모델과 동일한 레벨로 다시 추상화하는 것은 일반적으로 완전 자동화하기 어렵습니다.

이것은 본질적으로 PSMPIM으로 변환하는 것입니다(개념: MDD 및 MDA® 참조). 그런 다음, 복구된 PIM(단편)은 모델 병합([OMG03] 참조) 변환 유형을 사용하여 설계 모델(PIM 자체)과 결합됩니다.

구조 분석 페이지 맨 위

찾아볼 수 있는 모델이 있으면 소프트웨어 아키텍트가 검사를 통해 구조적 품질을 확인할 수 있습니다. 그러나 이 작업은 지루하고 시간이 많이 소요될 수 있으며, 이 방식으로 메트릭을 수집하고 표준 및 규칙 준수를 확인하면 오류가 발생하기 쉽습니다. 소프트웨어 아키텍트는 가능한 이 프로세스를 자동화하고 개선책을 찾아 적용하는 데 보다 많은 시간을 보내야 합니다. 자동화를 통해 소프트웨어 아키텍트는 "만약의 경우"를 실험하고 물어보며 그 결과를 신속히 확인할 수 있습니다.

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

자동화된 구조적 분석은 다음을 수행할 수 있습니다.

  • 구조에서 패턴 및 안티패턴(병적인 구조)을 찾을 수 있습니다.
  • 다양한 구조에 대한 평가를 수행하고 md_metri.htm -- This hyperlink in not present in this generated website메트릭을 보고할 수 있습니다.
  • 소프트웨어 아키텍트가 설정한 제한조건을 준수하는지 확인할 수 있습니다(구조적 제어 참조).

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

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

분석 대상은 무엇입니까?

분석 대상은 선택한 개발 접근방식에 따라 라이프사이클 전체에서 다양할 수 있습니다. 프로젝트가 변환적(일반적) 접근방식을 사용할 경우, 생성된 어플리케이션이 항상 설계와 동기화된다는 가정 하에 일반적으로 설계 모델이 대상이 됩니다. 결과물: 구현 모델을 작성하여 별도로 유지보수하는 경우 또는 코드를 재사용하는 경우, 소프트웨어 구조 문서 및 설계 가이드라인에 의거하여 평가할 때 구조적 무결성을 보유할 수 있도록 포커스가 코드로 이동됩니다.

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

이들 개념 및 성능 예

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

  • Butterfly
  • Breakable
  • Hub
  • Tangle
Butterfly

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

이 다이어그램은 4개의 종속사항(사용 종속성을 갖는 2개의 종속사항과 일반화 관계를 갖는 1개의 종속사항, 구현 관계를 갖는 1개의 종속사항)을 갖는 클래스를 표시합니다.

로컬 Butterfly

Breakable

Breakable은 종속성이 많은 요소입니다. 즉, 다른 요소에 종속되는 많은 관계를 갖고 있습니다. 이들 다른 요소를 변경하면 Breakable에 영향을 주게 됩니다. Butterfly의 경우와 마찬가지로 관계가 직접적일 경우 이러한 요소를 로컬 breakable이라고 하고 요소에 영향을 주는 간접 관계가 많을 경우에는 글로벌 breakable이라고 합니다. 글로벌 breakable은 어플리케이션의 많은 부분에서 변경되기 쉬우며, 모듈성의 부족을 나타냅니다. 아래의 그림은 로컬 breakable에 대한 일러스트레이션입니다.

이 다이어그램은 4개의 다른 클래스(사용 종속성 관계에 의해 2개의 클래스, 일반화 관계에 의해 1개의 클래스, 구현 관계에 의해 1개의 클래스)에 종속되는 하나의 클래스를 표시합니다.

로컬 Breakable

Hub

Hub는 butterfly와 breakable의 특성을 결합한 요소입니다. 여기에도 로컬글로벌 형식이 있습니다. 글로벌 hub가 있으면 파티셔닝이 잘못되어 있음을 나타내며, 소프트웨어가 변경(전체 어플리케이션에 영향을 주는 변경)에 극도로 민감해집니다.

Tangle

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

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

타이밍

이러한 분석의 결과는 모든 검토 이정표에서 구조 및 설계 품질의 객관적이고 양적인 증거로서 또는 활동: 기존 설계 요소 통합의 설계 모델의 구성 갱신에서처럼 중요한 구조적 변경사항이 있을 때 가치가 있습니다.

구조적 제어 페이지 맨 위

소프트웨어 아키텍트의 비전은 소프트웨어 아키텍트 문서에 캡처되어 있으며, 설계자용 실제 가이드는 설계 가이드라인을 참조하십시오. 모든 직원들이 이 비전을 공유하는 경우에도 프로젝트 작업의 일상적 긴급성으로 인해 비전이 모호해질 수가 있습니다. 최종 기한을 맞춰야 하기 때문에 안이한 방법을 택할 수 있으며, 일반적으로 소프트웨어 아키텍트가 모든 결정에 참여할 수는 없습니다. 따라서 제어 문제가 발생합니다. 프로젝트 관리자가 임계값과 한계를 설정하고 이를 모니터해야 하듯이(../activity/ac_monpr.htm -- This hyperlink in not present in this generated website활동: 프로젝트 상태 모니터 참조) 소프트웨어 아키텍트는 최근 생겨난 소프트웨어 설계 및 구현에 대해 유사한 타스크를 가집니다.

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

Rational Software Architect 툴은 Java 어플리케이션에 대해 이러한 성능을 포함하고 있으며, 소프트웨어 아키텍트는 규칙을 설정한 후 분석을 실행하여 준수하는지 확인할 수 있습니다. 자세한 정보는 Rational Software Architect 문서를 참조하십시오.

Rational Unified Process   2003.06.15