作業: Data Model Analysis
This task identifies the design elements of a service-oriented solution in terms of services and partitions and documents the initial specification of those services.
目的
  • To identify the design elements of a service-oriented solution in terms of services and partitions.
  • To document the initial specification of services.
  • To determine the initial dependencies and the communication between services.
關係
角色主要: 其他的: 協助:
輸入強制: 選用: 外部:
輸出
主要說明

This task uses Business Process Models as input and identifies a set of candidate services which are included in the project service portfolio. These candidate services may yet require additional refinement, however the steps included here provide an effective manner in which to produce an initial set of Service Specifications.

步驟
Identify Candidate Services from Data Models

For most business-driven IT organizations, understanding and managing data in the form of complex 構件: Business Entity(s) is key to the analysis and design of solutions. As such, many solutions will include services that act as data-management services and the identification of services will tend to focus more on the 構件: 資料模型 or 構件: Business Analysis Model. In terms of application reengineering to service-oriented solutions, data models have to be developed from the existing applications that can be used to identify coherent subsets that can be treated as autonomous services.

Where possible the creation of an enterprise-wide domain model is an activity that has great value, the domain model is a higher level of abstraction in general to a more complete logical data model (see 構件: 資料模型) and so may be maintained more regularly. This domain model expresses the key concepts, in terms of 構件: Business Entity, and can be considered to represent the key artifact types managed by either a business component or business service (see 概念: Component Business Modeling). As such the logical grouping of a domain model into a coherent set of dependent entities can be a starting point for service identification -- treating the service as the owner of the entities. For example, consider the following domain model fragment.

We see that the domain model identifies a set of business entities that fall into two main business competencies: account and customer management. It is true that there is a significant relationship between an account and an organization; however, these two artifact types are most often dealt with separately and operations tend to be carried out at either the account or organization level. We may then assign the relevant portions of the domain model to a RUP 構件: Business System (Business Component in CBM) as shown below.

While this gives us a clear picture in terms of the ownership of the relevant artifact types we need to go one step further and identify the services that the business system provides to the organization, and in this case specifically the service provided to manage the identified artifact types. So, given the example we have we would identify the entity "Account" as the primary artifact owned by the "Account Management" Business System, and "Customer" as the primary artifact owned by the "Customer Management" system. Thus, we would provide a service that enables the access to, and update of, these entities as shown in the figure below.

Again, these service specifications only represent candidate services (see the status property of the 構件: Service Specification) and as such would need to be refined with details of the operations they provide, specifically operations that allow for the update of entities.

內容
多次出現的項目
事件驅動
持續進行中
選用
規劃
可重複的
詳細資訊