 |
이 타스크에서는 디자인 서브시스템을 실현하는 서비스 컴포넌트의 세부사항을 지정합니다. |
원칙: 분석 및 디자인 |
|
목적
관계
역할 | 기본 수행자:
| 추가 수행자:
|
입력 | 필수:
| 선택사항:
|
출력 |
|
프로세스 사용법 |
|
기본 설명
SOA 기반 솔루션에서 사용한 서비스는 아티팩트: 서비스 컴포넌트를 통해 실현되며 이는 특정 비즈니스 기능 연계 서브시스템에 속합니다. 각 서비스 컴포넌트에서는
실현할 서비스의 QoS를 확인해야 합니다. 엔터프라이즈 규모 자산의 경우, 각 서비스 컴포넌트는 자금 지원, 관리 및 유지보수에 대한 권한이 있습니다. 하부 구조 관리는 가용성, 로드 밸런스, 보안, 성능, 버전화
및 서비스 컴포넌트의 전반적인 상태를 확인해야 합니다. 여기서 서비스 컴포넌트는 서비스 세트의 기능성을 구현하고 서비스의 품질을 확인해야 합니다. 기능적 컴포넌트 및 기술적 컴포넌트는 여러 서비스 컴포넌트 전반에서
사용할 수 있습니다.
|
단계
모델 컴포넌트 인터페이스
컴포넌트, 특히 서비스 컴포넌트에서는 오퍼레이션을 직접 제공할 필요가 없으며 대신 인터페이스를 사용해 오퍼레이션 세트를 설명한 다음 인터페이스를 제공/실현해야 합니다. 이는 일반적으로 RUP에서
설명됩니다(타스크: 서브시스템 디자인(SOA) 및 타스크: 디자인
요소 식별 참조).
예제
렌트카 예제에서는 예약 서비스 컴포넌트의 필요성을 식별합니다(서브시스템 분석을 통해). 재사용가능하고 유연한 디자인을 확인하려면 해당 예약 인터페이스를 작성하거나 서비스 스펙(타스크: 서비스 스펙에서)을 사용하여 서비스 컴포넌트에 대한 인터페이스를 설명합니다. 컴포넌트에서는 제공된 각 인터페이스를
실현하며(UML 용어로) 아래 다이어그램에 표시된 대로 UML 사용 관계를 사용하는 기타 컴포넌트 인터페이스에 대한 종속성이 표시 가능합니다.
명료하게 하기 위해 인터페이스의 세부사항은 생략합니다.
|
모델 컴포넌트 속성
이 단계에서 속성, 서비스, 정책 및 규칙을 포함한 각 서비스 컴포넌트의 세부사항을 정의합니다. 서비스 컴포넌트 스펙을 문서화하는 템플리트에는 다음 속성이 포함됩니다.
-
특성 또는 속성
-
규칙
-
변형
-
<기타 컴포넌트>에 따라 다름
-
기능적 및 기술적 컴포넌트의 컴포지션
-
서비스 제공
-
필수 서비스
|
모델 컴포넌트 이벤트 및 메시지
이 활동 중에 트리거 시 컴포넌트가 인식하고 응답해야 이벤트를 식별합니다. 또한 입력 및 출력 컴포넌트 메시지도 지정됩니다. 서비스가 데이터 변화로 구동되는 경우, 데이터 중심 보기를 사용해야 하고 서비스 기반 솔루션
범위에 없는 비즈니스 프로세스를 식별하고 이벤트 생성 및 서비스 지향 솔루션의 고객 서비스에 대한 데이터 공급을 평가해야 합니다. 예를 들어, ISV 패키지에 있는 다중 비즈니스 프로세스에서 새 클라이언트를 추가할 수
있습니다. 모든 경우에서 비즈니스 프로세스의 특정 컨텍스트에 따라 다른 클라이언트를 위해 동일한 데이터를 캡처할 수 있습니다. 제공자 서비스를 통해 새 클라이언트를 인식하는 데 필요한 이용자 서비스에서는 비즈니스
프로세스의 서비스 생성에 관계없이 새 클라이언트 서비스 호출을 처리해야 합니다. |
모델 컴포넌트 내부 구조
이 활동 중에 적어도 하나 이상의 클래스 다이어그램을 작성해야 하며, 이 다이어그램에서는 각 서비스 컴포넌트의 기능적 및 기술적 컴포넌트 간 관계를 표시합니다. 표준 UML 모델링은 이
단계에서 적용됩니다. 확장 가능하고 변경 가능한 방법으로 패턴을 사용해 결과 오브젝트 그래프를 구성할 수 있습니다. 변경 정도가 큰 경우, 이 단계에서 변동 분석을 수행하는 것이 좋습니다.
이전 타스크의 설명대로 변경을 위해 또는 앞으로의 비즈니스 변경 결과로 IT 시스템의 디자인 및 구조에 대해 미치는 영향을 예상하여 디자인하는 경우, 변동 분석 기법을 사용하는 것이 좋습니다. 이 기법은 공통성을 리팩터하고 디자인 패턴을 사용하여 변동을 구체화합니다. 이전에 발견된 공통성 및
변형은 시작점으로 사용 가능하며 공통 디자인 패턴 사용(예: 전략, 상태 [i], 규칙 오브젝트 [ii], 유형 오브젝트 등)을 통해 인수화됩니다.
세부적인 디자인 중에 분석을 수행하면 공통성을 식별하고 플러그형 변형에 초점을 맞추며 여섯 개의 원칙을 포함합니다. 이 원칙으로 소프트웨어 시스템의 변경된 형태에서 변경사항을 분리하여 이 변경사항을 다음과 같이
캡슐화할 수 있습니다.
-
도메인의 변경되지 않은 형태에서 변경 내용을 분리 및 모델링합니다. 즉, 식별, 분리, 캡슐화 및 증가하는 변형을 구체화합니다.
-
각 변형 지점에서 유형 계층 구조를 작성합니다.
-
각 변형 유형에 대한 규칙 유형을 지정합니다.
-
3 레벨의 추상화를 구현하고, 상속 메타패턴 집계를 사용합니다.
-
각 재사용 레벨의 오브젝트 및 빌드 자산보다 높은 재사용 레벨에서 시작하고, 변형 지점의 작은 프레임워크 빌드합니다. 일반적으로 각 프레임워크에는 7+-2 클래스만이 있어야 합니다.
-
각 재사용 요소에는 고유한 동작이 있습니다. 동작을 소프트와이어링할 수 있는 응용프로그램에서 읽기 가능한 구성 데이터로 동작을 구체화할 수 있습니다.
[i] Erich
Gamma, Richard
Helm, Ralph
Johnson, John
Vlissides, Design Patterns, Addision-Wesley 1994.
[ii] Arsanjani, A., Rule Object: A Pattern Language for Flexible Modeling and Construction of Business Rules,
Washington University Technical Report number: wucs-00-29, Proceedings of the Pattern Languages of Program
Design, 2000.
|
모델 컴포넌트 플로우
이 활동 중에 서비스 컴포넌트에 있는 제어의 내부 플로우를 식별합니다. 이 내용은 시퀀스 또는 활동 다이어그램으로 표시할 수 있습니다.
ISV 고려사항: ISV 패키지 컴포넌트에 있는 컴포넌트 내부 플로우는 공개 가능 또는 공개 불가능하고/하거나 패키지에 따라 구성 가능합니다. ISV 컴포넌트의 오브젝트가 공개되고 구성 가능할 경우,
해당 플로우를 사용자 조정 및 사용자 정의하여 솔루션을 보다 충족시킬 수 있습니다. 하지만 이와 연관된 잠재적이고 지속적인 유지보수 문제는 알고 있어야 합니다. 많은 경우, ISV 패키지의 컴포넌트 내부 플로우를
식별할 수 없거나 식별이 필요하지 않을 수도 있습니다. 이런 경우, ISV 컴포넌트는 공개되고 실현된 서비스만 문서화된 "블랙 박스"로 간주되어야 합니다.
|
계층에 컴포넌트 할당
계층화는 다음과 같은 이점이 있습니다.
-
계층으로 IT 시스템에 대한 변경성 및 이식성의 품질 속성을 가져올 수 있습니다. 해당 인터페이스에 영향을 주지 않는 하위 계층으로 변경하는 경우 상위 계층으로의 변경이 필요하지 않습니다. 예를 들어,
J2EE™ 표준을 따르는 모든 J2EE™ 규격 응용프로그램 서버는 응용프로그램 레벨의 소프트웨어로 변경하지 않고 자유롭게 대체할 수 있습니다. 하위 계층에서 필요로 하는 설비에 영향을 주지 않는 상위
계층으로 변경하는 것은 하위 계층에 영향을 주지 않습니다. 일반적으로, 인터페이스에 영향을 주지 않는 계층화된 소프트웨어 시스템으로 변경하는 것은 단일 계층에 한정됩니다.
-
계층은 시스템을 구성하는 아키텍처의 청사진 역할의 일부입니다. 소프트웨어가 있는 계층을 인식하는 경우, 개발자는 그들이 코드 환경에서 의존할 수 있는 역할도 인식합니다. 계층은 개발 팀의 작업 지정을 정의할
수 있습니다(항상 그렇지는 않음).
-
계층은 아키텍처에서 수행하는 통신 역할의 일부입니다. 대규모 시스템에서 모듈 간 종속성의 수는 빠르게 증가합니다. 소프트웨어를 인터페이스가 있는 계층으로 조직하는 것은 복잡도를 관리하고 구조를 개발자에게
전달하는 중요한 도구입니다.
-
계층은 아키텍처의 분석 역할 수행에 도움이 됩니다. 이 계층은 디자인 변경의 영향을 분석하는 데 사용 가능합니다.
계층화는 엄격하거나 엄격하지 않을 수 있습니다. 엄격한 계층화 구성표는 컴포넌트가 동일한 계층 또는 바로 그 아래 계층에 있는 컴포넌트를 사용할 수 있음을 의미합니다. 엄격하지 않은 계층화 구성표는 컴포넌트가
동일하거나 모든 하위 계층에 있는 컴포넌트를 사용할 수 있음을 의미합니다. 하지만, 일반적인 규칙에 따르면 컴포넌트가 상위 계층에 있는 컴포넌트를 사용할 수 없습니다. 컴포넌트에 상위 계층 컴포넌트에
대한 종속성이 있는 경우, 하위 계층 컴포넌트를 변경하지 않고 상위 계층 컴포넌트를 바꾸는 것은 어렵습니다. 모델링 계층에 필요한 기법을 포함한 자세한 정보는 개념: 솔루션 파티션을 참조하십시오.
소프트웨어 계층을 기록할 중요한 지점은 계층과 동일하지 않습니다. 분배된 환경의 시스템에 대한 할당, 요소 간의 데이터 플로우 및 통신 채널의 존재 및 사용 모두가 계층 다이어그램에서 식별할 수 없는 계층 그림에
표현됩니다. 계층 다이어그램은 특정 정렬의 양방향 통신을 표시하는 두 방향 화살표를 보여줍니다. 양방향(대칭) 통신은 계층 다이어그램에 좋은 영향을 주지 않습니다. 더구나 오퍼레이션 아키텍처 정의 시 계층에 대한
컴포넌트의 지정이 배치 규칙을 기반으로 하며 시스템의 필수 서비스 레벨 특성에서 정의됩니다. 계층화 다이어그램과 계층 그림 간의 주요 차이점은 전자에는 배치 개념이 없는 반면 후자에는 분명하게 있다는 것입니다.
경험에 의한 규칙 계층화
-
응용프로그램 독립 비즈니스 기능성을 제공하는 모든 컴포넌트는 한 계층에 있습니다. 응용프로그램 독립 비즈니스 기능에는 "고객 관리" 및 "제품 관리" 등이 있어 여러 응용프로그램의 범위에 적용할 수
있습니다.
-
기술적 기능을 제공하는 모든 컴포넌트(예: 오류 처리, 인증, 로깅 및 감사)는 다른(논리) 계층에 있습니다. 이 컴포넌트는 비즈니스와 응용프로그램 모두에 독립적입니다. 경우에 따라, 기능적 컴포넌트에 대한
기술적 컴포넌트의 근접성으로 이 컴포넌트가 공통 계층에 위치할 필요가 있습니다. 이는 아키텍처 결정이며 그대로 문서화해야 합니다.
-
미들웨어 컴포넌트(예: 메시지 큐 및 관련 DBMS 소프트웨어)는 그 이상의 계층에 있습니다. 이것은 "패브릭"이라고 합니다.
예제
다음은 솔루션에 있는 여러 요소에 필요한 일반(권장) 계층을 표시하는 SOA의 계층화된 보기입니다.
이 계층화 구조표에서 컴포넌트가 있게 될 위치를 쉽게 인식하며, 아래에 표시된 대로 렌트카 예제의 관련 컴포넌트를 서비스 컴포넌트 계층에 배치합니다. 모델에 엄격한 계층을 채택하기 위하여 UML
컴포지션으로 서비스 컴포넌트 계층을 포함하며 포트가 서비스 컴포넌트와 같은 인터페이스를 제공하는 대표 포트를 사용하여 서비스 컴포넌트의 기능성만 공개합니다.
|
|
자세한 정보
© Copyright IBM Corp. 1987, 2006. All Rights Reserved.
|
|