타스크: 컴포넌트 스펙(SOA)
이 타스크에서는 디자인 서브시스템을 실현하는 서비스 컴포넌트의 세부사항을 지정합니다.
목적

타스크: 서브시스템 디자인(SOA) 중에 설명된 하나 이상의 아티팩트: 디자인 서브시스템을 구체화하고 세부적인 아티팩트: 서비스 컴포넌트 디자인을 제공합니다.

관계
역할기본: 추가: 지원:
입력필수: 선택사항: 외부:
  • 없음
출력
기본 설명

SOA 기반 솔루션에서 사용한 서비스는 아티팩트: 서비스 컴포넌트를 통해 실현되며 이는 특정 비즈니스 기능 연계 서브시스템에 속합니다. 각 서비스 컴포넌트에서는 실현할 서비스의 QoS를 확인해야 합니다. 엔터프라이즈 규모 자산의 경우, 각 서비스 컴포넌트는 자금 지원, 관리 및 유지보수에 대한 권한이 있습니다. 하부 구조 관리는 가용성, 로드 밸런스, 보안, 성능, 버전화 및 서비스 컴포넌트의 전반적인 상태를 확인해야 합니다. 여기서 서비스 컴포넌트는 서비스 세트의 기능성을 구현하고 서비스의 품질을 확인해야 합니다. 기능적 컴포넌트 및 기술적 컴포넌트는 여러 서비스 컴포넌트 전반에서 사용할 수 있습니다.

단계
모델 컴포넌트 인터페이스

컴포넌트, 특히 서비스 컴포넌트에서는 오퍼레이션을 직접 제공할 필요가 없으며 대신 인터페이스를 사용해 오퍼레이션 세트를 설명한 다음 인터페이스를 제공/실현해야 합니다. 이는 일반적으로 RUP에서 설명됩니다(타스크: 서브시스템 디자인(SOA) 및 타스크: 디자인 요소 식별 참조).

예제

렌트카 예제에서는 예약 서비스 컴포넌트의 필요성을 식별합니다(서브시스템 분석을 통해). 재사용가능하고 유연한 디자인을 확인하려면 해당 예약 인터페이스를 작성하거나 서비스 스펙(타스크: 서비스 스펙에서)을 사용하여 서비스 컴포넌트에 대한 인터페이스를 설명합니다. 컴포넌트에서는 제공된 각 인터페이스를 실현하며(UML 용어로) 아래 다이어그램에 표시된 대로 UML 사용 관계를 사용하는 기타 컴포넌트 인터페이스에 대한 종속성이 표시 가능합니다.

명료하게 하기 위해 인터페이스의 세부사항은 생략합니다.

모델 컴포넌트 속성
이 단계에서 속성, 서비스, 정책 및 규칙을 포함한 각 서비스 컴포넌트의 세부사항을 정의합니다. 서비스 컴포넌트 스펙을 문서화하는 템플리트에는 다음 속성이 포함됩니다.
  1. 특성 또는 속성
  2. 규칙
  3. 변형
  4. <기타 컴포넌트>에 따라 다름
  5. 기능적 및 기술적 컴포넌트의 컴포지션
  6. 서비스 제공
  7. 필수 서비스
모델 컴포넌트 이벤트 및 메시지
이 활동 중에 트리거 시 컴포넌트가 인식하고 응답해야 이벤트를 식별합니다. 또한 입력 및 출력 컴포넌트 메시지도 지정됩니다. 서비스가 데이터 변화로 구동되는 경우, 데이터 중심 보기를 사용해야 하고 서비스 기반 솔루션 범위에 없는 비즈니스 프로세스를 식별하고 이벤트 생성 및 서비스 지향 솔루션의 고객 서비스에 대한 데이터 공급을 평가해야 합니다. 예를 들어, ISV 패키지에 있는 다중 비즈니스 프로세스에서 새 클라이언트를 추가할 수 있습니다. 모든 경우에서 비즈니스 프로세스의 특정 컨텍스트에 따라 다른 클라이언트를 위해 동일한 데이터를 캡처할 수 있습니다. 제공자 서비스를 통해 새 클라이언트를 인식하는 데 필요한 이용자 서비스에서는 비즈니스 프로세스의 서비스 생성에 관계없이 새 클라이언트 서비스 호출을 처리해야 합니다.
모델 컴포넌트 내부 구조

이 활동 중에 적어도 하나 이상의 클래스 다이어그램을 작성해야 하며, 이 다이어그램에서는 각 서비스 컴포넌트의 기능적 및 기술적 컴포넌트 간 관계를 표시합니다. 표준 UML 모델링은 이 단계에서 적용됩니다. 확장 가능하고 변경 가능한 방법으로 패턴을 사용해 결과 오브젝트 그래프를 구성할 수 있습니다. 변경 정도가 큰 경우, 이 단계에서 변동 분석을 수행하는 것이 좋습니다.

이전 타스크의 설명대로 변경을 위해 또는 앞으로의 비즈니스 변경 결과로 IT 시스템의 디자인 및 구조에 대해 미치는 영향을 예상하여 디자인하는 경우, 변동 분석 기법을 사용하는 것이 좋습니다. 이 기법은 공통성을 리팩터하고 디자인 패턴을 사용하여 변동을 구체화합니다. 이전에 발견된 공통성 및 변형은 시작점으로 사용 가능하며 공통 디자인 패턴 사용(예: 전략, 상태 [i], 규칙 오브젝트 [ii], 유형 오브젝트 등)을 통해 인수화됩니다.

세부적인 디자인 중에 분석을 수행하면 공통성을 식별하고 플러그형 변형에 초점을 맞추며 여섯 개의 원칙을 포함합니다. 이 원칙으로 소프트웨어 시스템의 변경된 형태에서 변경사항을 분리하여 이 변경사항을 다음과 같이 캡슐화할 수 있습니다.

  1. 도메인의 변경되지 않은 형태에서 변경 내용을 분리 및 모델링합니다. 즉, 식별, 분리, 캡슐화 및 증가하는 변형을 구체화합니다.
  2. 각 변형 지점에서 유형 계층 구조를 작성합니다.
  3. 각 변형 유형에 대한 규칙 유형을 지정합니다.
  4. 3 레벨의 추상화를 구현하고, 상속 메타패턴 집계를 사용합니다.
  5. 각 재사용 레벨의 오브젝트 및 빌드 자산보다 높은 재사용 레벨에서 시작하고, 변형 지점의 작은 프레임워크 빌드합니다. 일반적으로 각 프레임워크에는 7+-2 클래스만이 있어야 합니다.
  6. 각 재사용 요소에는 고유한 동작이 있습니다. 동작을 소프트와이어링할 수 있는 응용프로그램에서 읽기 가능한 구성 데이터로 동작을 구체화할 수 있습니다.

[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 컴포넌트는 공개되고 실현된 서비스만 문서화된 "블랙 박스"로 간주되어야 합니다.

특성
다중 발생
이벤트로 구동됨
진행 중임
선택사항
계획됨
반복 가능함
자세한 정보