서비스 모델에서는 다중 반복으로 서비스 세트의 세부사항을 캡처하여 세부사항을 더욱 세부화합니다. 서비스 모델은 다음과 같은 여러 범위 레벨에 사용할 수 있습니다.
-
서비스 범위 개발 프로젝트 범위는 서비스를 가능한 한 다른 서비스에 관계 없이 독립적으로 개발하는 것입니다. 따라서 이 모델링은 유스 케이스, 아키텍처, 디자인 및 구현 모델을
특정 서비스의 수직 단면으로 포함합니다.
-
프로젝트 범위 개발 프로젝트에 여러 서비스의 스펙이 포함되며 응용프로그램 요구사항 세트를 지원합니다. 이러한 경우, 해당 범위는 응용프로그램 레벨에 맞게 확장되어 여러 서비스를
포함할 수 있습니다. 결과적으로 유스 케이스 및 아키텍처에 대한 응용프로그램 레벨 모델 세트와, 서비스 특정 디자인 및 구현 모델 세트가 존재합니다.
-
엔터프라이즈 범위 개발 또는 서비스 포트폴리오 관리에서는 해당 범위가 엔터프라이즈 전체 범위가 아닌 서비스 스펙 및 논리 파티션만 캡처하는 것입니다. 이러한 경우 디자이너 및
설계자는 전체 포트폴리오에 대한 광범위한 결정을 내릴 수 있지만 식별된 서비스(및 클라이언트 응용프로그램)에 대한 디자인 및 구현 모델을 개발하기 위한 별도 프로젝트가 필요합니다.
다음 다이어그램에서는 서비스 모델의 핵심 양상 및 이 양상 간 관계와 식별, 스펙 및 활동 실현(realization)을 추상적으로 보여줍니다.
요소 식별
첫 번째 정제는 분해와 같은 기법을 사용하여 활동: 기존 자산 분석 중에 작성된 서비스 포트폴리오에 있는 후보 서비스의 목록부터 시작합니다(개념: 비즈니스 프로세스 분해 참조). 이 서비스는 기능 영역 및 서비스를 식별하는 데 사용된 기법에 따라 카테고리화됩니다. 여기서 설명한 서비스
포트폴리오는 프로젝트용 포트폴리오이며 활성: 기존 자산 분석에 설명된 여러 분석 기법을 사용하여 식별된 후보 서비스를 포함합니다. 이 단계에서 식별된 서비스는 이름 및 가능한 기능
설명으로만 제공되며 서비스 목록을 포함한 간단한 문서로 충분하지만 UML 접근 방식이 사용되는 경우에는, 포트폴리오가 아티팩트: 서비스 스펙의 콜렉션으로 유지보수되며 보고서: 서비스
포트폴리오를 사용하여 생성 가능합니다.
가능한 한 빨리 목록의 서비스를 기능 분류 구성(일반적으로 도메인 분해 중에 식별된 기능 영역을 기반으로 함)을 사용하여 계층 구조로 구성합니다. 이와 같은 계층 구조에서는 프로세스
호출 종속성에 대한 서비스의 기본 분류 구성을 볼 수 있으며 따라서 분해 활동 중에 식별된 서비스 간의 관계를 이해하는 데 큰 도움이 됩니다. 또한 계층 구조는 문서, 스프레드시트 또는 UML 모델로
표시합니다. 이 경우, 기능 영역을 모델링하는 데 아티팩트: 서비스 파티션을 사용합니다.
또한 서비스 포트폴리오 용어는 프로젝트용 포트폴리오의 라이프사이클 이상인 엔터프라이즈 전체 서비스 포트폴리오를 나타낼 수 있습니다(개념: 서비스
포트폴리오에서 설명). 실제 엔터프라이즈와 프로젝트 포트폴리오 간의 관계는 아래 그림에 표시되어 있습니다.
스펙 요소
활동: 서비스 스펙 수행 의 첫 단계 중 하나는 서비스의 공개를 결정하고 문서화하는 것, 즉 진정한 서비스로서
개발하고 공개할 후보 서비스를 문서화하는 것입니다. 핵심 기법 중 하나는 타스크: 서비스
리트머스 테스트 적용으로서, 공개를 위해 서비스를 평가하는 방법에 대한 특정 안내를 제공합니다. 서비스 모델의 UML 표시에 대해서, 상태 특성을 사용하여 식별 중에 개발된 서비스 스펙을 모델에 표시 및
공개한 후 세부화합니다. 공개를 위한 서비스 분석에서 서비스를 논리 제품으로 그룹화할 수 있으며 아티팩트: 서비스 제공자를 사용하여 UML에 모델링할 수 있습니다.
서비스 스펙 문서화의 경우, 다양한 목적을 위한 서비스 종속성 모두를 캡처하는 것이 중요합니다. 예를 들어, 종속성이 많은 서비스는 여러 환경에서 재사용하기가 더 어려운 반면 많은 종속자를 가진 서비스는 코어
기능을 나타냅니다. 서비스 종속성은 텍스트로, 혹은 종종 테이블 형식으로도 캡처할 수 있으며(보고서:
서비스 종속성 참조) 또는 서비스 모델의 UML 표시로 모델링할 수 있습니다. 일부 종속성의 원인은 내부 서비스 통신 때문이며 UML 모델 및 특히 협업 모델의 아티팩트: 서비스 채널을 사용하여 이 종속성과 연관된 특정 세부사항(관련된 통신 프로토콜, 보안 등)을 문서화할 수
있음을 인식해야 합니다.
서비스 정의 시 일반적으로 컴포지트 서비스가 좀 더 세분화된 서비스 세트를 구성(Choreography)하는 데만 사용됨을 인지하며, 이 컴포지션 및 플로우에서는 컴포지트와 작성된
서비스 간의 관계 및 서비스에 대한 플로우로 표현된 서비스 간 종속성에 대해 설명합니다. UML 표시로 이 컴포지션 및 플로우(활동, 상호작용)를 잘 설명할 수 있으며(컴포지트 클래스), 기법은 개념: 서비스 컴포지션 및 Choreography에서 설명됩니다.
또한 서비스의 비기능적 요구사항을 캡처하고(위의 많은 주제가 기능적 요구사항에 더 초점을 맞춘 경우), 서비스 품질, 정책 등에 대한 가능한 한 많은 세부사항을 캡처해야 합니다. 이
영역에서는 요구사항을 텍스트 문서로 표시할 수 있지만(UML로 직접 표시하기는 더 어려움), 요구사항 관리 제품을 사용하면 더 쉽게 표시할 수 있습니다. 서비스 모델의 UML 표시 사용 시 기존
RUP 아티팩트: 소프트웨어 아키텍처 문서 및 아티팩트: 보충 스펙을 모두 사용하여 비기능적 요구사항을 캡처하는 것이 좋습니다. 비기능적 솔루션의 한 가지
양상은 서비스의 분배 및 가용성과 관계가 있으며 UML 모델과 특히 아티팩트: 서비스 파티션 및 아티팩트: 서비스 게이트웨이를 사용해 이를 문서화할 수 있습니다.
서비스 메시지의 세부화는 사용 가능한 서비스 스펙의 개발에 중요합니다. 이 메시지는 상위 레벨 모델에서 파생 가능하거나 일부 기술용 양식(예: XML 스키마)으로 직접 표시할 수
있습니다. 메시지가 스키마 언어에서든 UML 모델에서든 텍스트로 설명되면 이 메시지 정의에서는 타스크: 메시지
디자인 및 해당 가이드라인: 메시지 첨부에 문서화된 핵심 사항을 고려해야 합니다.
SOA에서 실제로 서비스를 Stateless로 만드는 경우 이를 언제나 고정된 목적으로 만들 수 있는 것은 아닙니다. 상태 관리 결정 주제를 제공하면 디자이너 시간을 절충사항, 비용
및 서비스 상태 관리의 이점에 반영할 수 있습니다. 이러한 결정을 지원하는 경우 가이드라인: 서비스 상태 관리 주제에서 서비스로 자주 유지보수해야 하는 상태 유형의 예제를 제공합니다.
요소 실현(realization)
서비스 실현(realization)은 본래 세 영역과 관계가 있는데, 이 세 영역은 각각 서비스의 실제 실현(realization)에 대한 결정, 서비스 스펙을 실현할 서브시스템 및 컴포넌트 식별, 마지막으로
이러한 컴포넌트의 개발입니다.
실현(realization) 결정 문서화의 경우, 타스크: 서비스
실현(realization) 결정 문서화의 설명대로 소싱 및 개발 접근 방식 선택에 대한 합리적이고 세부적인 이유가 있어야 합니다. 또한 위의 비기능적 요구사항과 유사한 방법에서는 이 결정을 UML로
표시하기(특히 자세하게) 어려우므로 문서화할 서비스를 각각 독립적으로 선택해야 합니다.
|