개념: 분석 메커니즘
주제
분석 메커니즘은 공통 문제점에 대한 공통 솔루션을 구성하는 패턴을 나타냅니다.
분석 메커니즘은 구조의 패턴, 작동의 패턴 또는 두 가지 모두를 표시할 수 있습니다. 분석 메커니즘은
분석 중에 설계자에게 복잡한 작동의 간단한 표시를 제공하여
분석의 복잡도를 줄이고 일관성을 증대시키기 위해 사용됩니다. 메커니즘을 사용하면
기능을 지원하는 데는 필요하지만 이에 주요하지는 않은 비교적 복잡한
작동의 스펙에 치우치지 않고 기능적 요구사항을 소프트웨어 개념으로 변환하는 데
분석 노력을 집중시킬 수 있습니다. 분석 메커니즘은 종종 하나 이상의
구조적
또는 분석 패턴의
인스턴트화에서 비롯됩니다.
분석 메커니즘은 주로 중간 및 하위 구조 계층에서 복잡한 기술의
'플레이스홀더'를 나타내는 데 사용됩니다. 구조에서 메커니즘을 '플레이스홀더'로 사용하면
메커니즘 작동의 세부사항에 의해 구조화 노력이 흩뜨러지는 것을 줄일 수 있습니다.
예를 들어, 객체 수명 범위 유스 케이스,
프로세스 수명 또는 시스템 종료 및 시작이 있어야 할 요구는 객체 지속성의 요구를 정의합니다.
지속성은 특히 복잡한 메커니즘이므로,
분석 중 지속성을 달성하려는 방법의 세부사항 때문에 주의가 흩뜨러지지 않아야 합니다.
이것은 '지속성' 분석 메커니즘의 근원이 되는데, 이 메커니즘을 사용하여
실제로 지속성 메커니즘이 수행하는 작업 또는
지속성 메커니즘이 작업하는 방법에 대해 염려하지 않고
지속적 객체에 관하여 말하고 지속성 메커니즘에 대한 요구사항을 캡처할 수 있습니다.
분석 메커니즘은 반드시 그런 것은 아니지만
일반적으로 문제점 도메인에 관련되지 않으며, 대신 "컴퓨터 공학" 개념입니다.
그 결과, 분석 매커니즘은 일반적으로 구조의 중간 및 하위 계층을 차지합니다.
분석 메커니즘은 도메인 관련 클래스 또는 서브시스템에 대해 특정 작동을 제공하거나
클래스 및/또는 서브시스템 간 협업의 구현에 부합합니다.
분석 메커니즘은 프레임워크로 구현될 수 있으며,
몇 가지 예로 지속성, 프로세스 상호 통신, 오류 또는 결함 처리, 공고 및 메시징을 처리하는 메커니즘이 포함됩니다.
그러나 더 많은 분석
패턴이 다양한 도메인에 구축됨에 따라,
분석 메커니즘에서 분석 패턴을 부분적 또는 전체적으로 인스턴스화하면
이들 메커니즘은 구조의 상위 계층에 나타나게 됩니다.
- 지속성
인스턴스가 지속될 수 있는 모든 클래스에 대해 다음을 식별해야 합니다.
- 세분성: 지속적으로 유지할 객체 크기의 범위
- 볼륨: 지속적으로 유지할 객체의 수
- 지속 기간: 일반적으로 객체를 보존해야 하는 기간
- 검색 메커니즘: 제공되는 객체가 고유하게 식별되고 검색되는 방법
- 갱신 빈도: 객체가 다소 일정합니까? 영구히 갱신됩니까?
- 신뢰성: 프로세스, 프로세서 또는 전체 시스템이 손상될 때 객체가 생존합니까?
- 프로세스간 통신
다른 프로세스 또는 스레드에서 실행되는
컴포넌트 또는 서비스와 통신해야 하는 모든 모델 요소에 대해
다음을 식별해야 합니다.
- 지연: 프로세스가 다른 프로세스와 얼마나 빠르게 통신해야 합니까?
- 동시성: 비동기 통신
- 메시지 크기: 단일 숫자보다 범위가 더 적절할 수 있습니다.
- 프로토콜, 플로우 제어, 버퍼링 등.
기타 일반 메커니즘에는 다음이 포함됩니다.
- 메시지 라우팅
- 프로세스 제어 및 동기화
- 트랜잭션 관리
- 정보 교환
- 보안
- 중복성
- 오류 보고
- 형식 변환
분석 메커니즘을 설명하는 프로세스는 다음과 같습니다.
- 모든 분석 메커니즘을 목록에 수집
동일한 분석 메커니즘이 다른 유스 케이스 구현이나 다른 설계자에서 여러 다른 이름으로
표시될 수 있습니다. 예를 들어, 저장영역, 지속성, 데이터베이스 및
저장소는 모두 지속성 메커니즘에 관한 것입니다.
또는 프로세스간 통신, 메시지 전달 또는 원격 호출은 모두 프로세스간 통신에 관한 것입니다.
- 분석 메커니즘에 대한 클라이언트 클래스의 맵 그리기

식별된 클래스 및 서브시스템은
식별된 분석 메커니즘으로 맵핑되어야 합니다.
화살표는 클래스가 메커니즘을 이용하고 있음을 표시합니다. 클라이언트 클래스가
여러 메커니즘의 서비스를 필요로 하는 것은 드문 일이 아닙니다.
- 분석 메커니즘의 특성 식별
가능한 설계의 범위를 구별하려면
각 분석 메커니즘을 규정하는 데 사용된 주요 특성을 식별하십시오.
이러한 특성은 파트 기능, 파트 크기 및 성능입니다.
- 협업을 사용하는 모델
분석 메커니즘을 식별하고 이름을 지정한 경우,
궁극적으로 '클래스 모음'의 협업([BOO98] 참조)을
통해 이를 모델링해야 합니다. 이들 중 일부는 직접 어플리케이션 기능을 전달하지는 않지만
단지 이를 지원하기 위해 존재합니다. 대부분 이들 '지원 클래스'는 계층화된 구조의 중간 또는 하위 계층에 위치하여
모든 어플리케이션 레벨 클래스에 공통 지원 서비스를 제공합니다.
식별된 메커니즘이 다분히 공통적인 경우,
해당 패턴에 필요한 대로 기존 클래스를 바인드하고
새 클래스를 구현하여 메커니즘을 인스턴스화할 수 있는
패턴이 존재할 수 있습니다.
이렇게 생성된 분석 메커니즘은 추상적이며
설계 및 구현을 통해 더 자세히 정제해야 합니다.
분석 메커니즘은 결과물:
소프트웨어 구조 문서에 문서화되어 있습니다. 소프트웨어 구조가 완성됨에 따라
결과물: 소프트웨어 구조 문서에는
분석 메커니즘 대 설계 메커니즘 대 구현 메커니즘의 관계(또는 맵핑) 및
이러한 선택에 대해 연관된 합리성이 포함됩니다.
패턴 및 변환 
배경 
"주어진 컨텍스트에서 유용성이 입증된 반복
문제점에 대한 솔루션 템플리트"(용어집 정의에서 발췌)로서
패턴의 개념은 상당히 일반적입니다. 이렇게 정의된 패턴을 적용(인스턴스화)하려면
해결된 문제점의 규모와 특이성에 따라 많은 모델의 변경사항이 필요합니다.
패턴 적용 및 이런 식으로 보여지는 메커니즘 인스턴스화는 모델
변환
을 통해 이루어집니다. 예를 들어, 위에 정의된 메커니즘 중 하나에서 보안 메커니즘의 기초가 되는
모든 패턴인 보안은 보편적이므로 모델 요소 유형에서 요소 유형으로 바뀌어져야 합니다. 보안 패턴의 정의는
특정 기술, 규칙, 도메인 또는 기타 모델링 관련 영역을 정의하고 제한하는
스테레오타입, 태그 표시된 값, 제한조건을 캡처하기 위한 표준화된 방법인
UML 프로파일에서 찾을 수 있습니다.
이는 본질적으로
플랫폼(개념:
MDD 및 MDA® 참조)과 동일하므로
"일반적 패턴"을 구현하는 하나 이상의 변환 개념을 여기에 적용할 수 있습니다.
이 보기에서 패턴(일반적)과 변환 간의 관계는 다음과 같이
설명할 수 있습니다.

그러나 패턴이 보다 한정되어 있다는 것이 다수의 공통적인 경험입니다. 이 보기에서는
일종의 변환(소스 모델에 적용되고 적용 결과 모델이 변경됨)이지만
변경이 구현되어 로컬로 적용되고(여러 단계 중 하나에) 소스 및 대상 모델은
거의 동일한 추상화 레벨에 남아 있습니다. 심지어는 소스 및 대상 모델을 동일 모델로 간주할 수도
있습니다. 예를 들어, 매개변수화된 협업 형식의 패턴을 설계 모델에
적용할 수 있으며, 이 패턴이 기술에 특정되지 않는다면
그 결과가 설계 모델이라고 주장할 수 있습니다. 이것은 분석 패턴, 설계 패턴 및 구현 패턴(관용구)에 관해
말할 때 RUP에 미러링됩니다. 이 보기에서 패턴과 변환(이제 추상 클래스로 표시됨) 간의 관계는 다음과 같이
가시화됩니다.

보다 구체적인 패턴 사용법은 아래에서 자세히 알아봅니다.
소프트웨어 아키텍트로서 상위 추상화 레벨에서 계속 작업하고,
필요한 분석 메커니즘 및 이들 메커니즘이 지원하는 패턴(대형 및 소형)을 식별하고 특성을 나타내며,
자동화된 변환을 사용하여 이를 구현하고자 합니다. 궁극적으로 분석 및 설계를 진행하면서
단순히 코드를 직접 반영하는 것이 아니라 상위 추상화 레벨에서
UML 모델을 사용하여 최종적으로 코드화하기 전에 가능한 많은 모델 변환을 자동화하고자 합니다.
변환 접근방식 
개념: MDD 및 MDA®에 많은 변환 접근방식이 개괄적으로 설명되어
있습니다(어떻게 변환이
수행됩니까? 참조). 구체적인 예를 제공하기 위해 Rational Software Architect는
유형 맵핑(예: 소스 모델의 클래스, 속성,
조작 및 관계가 대상 요소에 어떻게 영향을 주는지 판별)과 소스 모델 표시(둘 다 프로파일에서 사용할 수 있음)의 조합을 토대로 한 접근방식을
지원합니다.
이 접근방식은 소스 모델이 일반적으로 유형 맵핑을 통해 변환을 완전히 안내할 수 있는 충분한
정보를 포함하고 있지 않다는 것을 인정합니다. 소프트웨어 아키텍트는
프로파일에 정의된 스테레오타입과 같은 표시를 소스 모델에 추가하여
변환을 완전히 지정할 수 있습니다. 대상 플랫폼 개념을 표시하는 이런 표시는 소스 모델의 일부는
아니지만 소스 모델을 오버레이합니다. 변환을 구동하는 규칙은 대상 플랫폼 정의에서 파생되는데
예를 들면, 연관된 프로파일에서 파생되고 소스에 사용된 유형에서 대상에 사용된 유형으로의 맵핑에서 파생됩니다.
변환 규칙을 설정하고 소스를 표시했으면 변환을 진행할 수 있습니다.
Rational Software Architect는 더 나아가 변환에 매개변수를 제공할 수 있도록 합니다.
예를 들면, 프로파일 또는 연관된 표시에서 파생될 수 없는 정보를 지정할 수 있습니다. 이러한 체계적 방법으로
모델을 변경할 때 추가적인 장점은 변환 레코드가 생성되어 저장된다는 점입니다.
따라서 소스 모델에서 대상 모델로의 강력한 추적성 정보가 보존됩니다.
몇 가지 구체적인 예를 제공하기 위해 Rational Software Architect는
변환 및
패턴에서
일반적인 변환 개념을 구체화합니다. 제공된 정의는 Rational Software Architect에서 사용되는 정의입니다.
변형 
변형은 "일괄처리에 대해 주로 메타모델, 모델 및 추상화 레벨 간에
최적화된 변환입니다". 변형을 적용하면 일반적으로 명백한 별개의
모델(예: UML 모델로부터 텍스트 코드 모델)이 생성됩니다. 이것은 표기법상의 변경과 더불어 중요한 변화입니다.
패턴 
패턴은 "주로 단일 메타모델에서 동일 레벨의 추상화 내에서 그리고 간혹
동일 모델 내에서 대화식의 구분적 구현화에 최적화된 변환입니다". 이 정의에 따라
UML 모델에서 패턴을 적용하면 여전히 UML 모델이 되며, 다소 더 정교하지만 동일 레벨의 추상화에서 인식할 수 있는
모델입니다.
변환, 패턴 및 변형 간의 관계는 이전 다이어그램을 다음과 같이 정제합니다.

보다 엄격한 이 접근방식을 적용한 또 다른 결과는 프로파일과 여기서 파생된 변환이 당연히 중요한 엔티티가
된다는 점입니다. 소프트웨어 아키텍트는 변환 준비시 수행된 작업을 재사용을 통해
활용하려고 합니다. 변환 라이브러리가 작성되어 1회성 변환은 예외가 될 것으로 예상됩니다.
이러한 라이브러리는 예를 들어
소프트웨어 아키텍트가 필요한 분석 메커니즘의 식별된 특성과 쉽게 일치시킬 수 있도록
변환 특성을 사용하여 검색하거나 찾아볼 수 있어야 합니다.
Rational Software Architect를 사용한 변환 성능에 대한 자세한 정보는 다음을 포함한
다양한 Rational Software Architect 학습서 및 샘플을 참조하십시오.
학습: XYZ 패턴 적용
학습: 패턴 확장
샘플: 패턴 적용을 위한 모델
샘플: 패턴
샘플: 확장할 패턴
학습: 설계: 모델에서 코드로 변환
학습: 설계: 모델에서 모델로 변환
샘플: 변형 적용
샘플: 첫 번째 변형 빌드
샘플: 모델에서 모델로 변형 빌도
샘플: 텍스트를 생성하는 변형 작성
샘플: 변형을
기타 Rational Software Architect 사용자에게 전개
|