Задача: Identify Service Component

This task extends the traditional RUP subsystem design with details specific to a SOA solution, especially where subsystems were identified from business analysis models. Once we make the transition from the business domain to the IT domain, we map identified functional areas defined by the former to subsystems, their IT counterparts.

Назначение

To link the business models to their IT counterparts we perform the following:

Identify the relationship between Functional Areas (Concept: Functional Area Analysis) in the Artifact: Business Analysis Model to corresponding Artifact: Design Subsystem.
To define the behaviors specified in the subsystem's interfaces in terms of collaborations of contained design elements and external subsystems/interfaces.
To document the internal structure of the subsystem, in terms of Artifact: Service Components that realize the Subsystem.
To define realizations between the subsystem's interfaces and contained components and classes.
To determine the dependencies upon other subsystems.

Взаимосвязи

Роли	Основной: Designer	Дополнительно:	Помощь:
Входы	Обязательный: Business Analysis Model Design Subsystem Interface	Необязательный: Data Migration Specification Design Model Project-Specific Guidelines Service Model	Внешний: Нет
Выходы	Design Model

Основное описание

We begin with the determination and documentation of the dependencies between subsystems that correspond to the functional areas that have been identified during Task: Functional Area Analysis. Usually a functional area will correspond to a single subsystem; that is, the simplifying assumption that has been found to be accurate in many, if not most cases. If we decide to map a functional area to several subsystems, that can also be feasible and valid; but usually means the domain decomposition did not go deep enough and the functional areas are not granular enough.

Шаги

Identify Service Component

Subsystems, in and of themselves, are not IT assets and not deployable into the IT infrastructure; they provide a bridge between the business and IT perspectives. Each subsystem is realized by one or more Service Components where a Service Component is an enterprise-scale asset (a managed software element with guaranteed availability, load balancing, security, performance, and versioning). The Service Component is in turn realized by multiple Functional and Technical Components according to the diagram below.

Generally each service assigned to a Subsystem will result in a Service Component; Functional and Technical Components may be shared between Service Components within the same subsystem.

Свойства

Несколько вхождений
Управляется событиями
Выполняющийся
Необязательный
Запланированный
Повторяющийся

Дополнительные сведения

Справочные таблицы	Капсула
Концепции	Functional Area Analysis
Рекомендации	Designing Data Migration Subsystems Диаграмма конечных состояний Капсула Проектирование подсистем для приложений J2EE Проектирование приложений-клиентов J2EE
Руководства по инструментам	Designing Subsystems Using Rational Software Architect Designing Subsystems Using Rational Systems Developer Проектирование подсистем с помощью Rational XDE Developer Управление моделью разработки с помощью Rational Rose Управление подсистемами с помощью Rational Rose