Business-Process-to-Service-Model transformations

The Business-Process-to-Service-Model transformation enables you to transform a business analysis model, which you might import from IBM® WebSphere® Business Modeler, into an architected solution UML model, which is also called a service model. The service model fulfills a traceable contract between business analysis and high-level design.

WebSphere Business Modeler model projects and specification projects

To import a WebSphere Business Modeler model project into your workspace, you must have WebSphere Business Modeler integration support installed.

When you import a WebSphere Business Modeler model project into your workspace, a UML representation of the business model is created in your workspace. This UML representation is also called a specification model, or a business process model. The specification model defines how business processes interact and how they are invoked by actors or other services. Each element in the specification model has the same name as the corresponding element in the WebSphere Business Modeler business analysis model, and UML collaborations represent the business processes. To create a view of the contracts that exist between the roles and business processes defined by the business model, you can create a freeform diagram in the UML realization model, and drag the roles, processes, and interfaces to the diagram.

The details and structure of the specification model are contained in a file called resources.xmi, which is located in the top-level folder of the specification model. You can save the resources.xmi file as a UML 2.1 EMX model file; however, if you edit and then save changes to the specification model, you cannot export the changes to the original WebSphere Business Modeler model project.

Valid transformation sources

You can specify a specification model as the transformation source. The WebSphere Business Modeler project that contains the business analysis model must exist in your Eclipse workspace, and the specification model must be open when you create the Business-Process-to-Service-Model transformation configuration and run the transformation.

Attention: To avoid potential data loss, you should not have the same project files open simultaneously in both WebSphere Business Modeler and IBM DevOps Software Architect.

If you select a transformation source from the Project Explorer view instead of using the Transformation Configuration editor, the project that you select overrides the source project that is specified in the transformation configuration. The transformation configuration is not affected and the source that you specify on the Source and Target page of the transformation configuration editor or in the New Transformation Configuration wizard does not change.

Valid transformation targets

You can specify any project or a folder as the target location for the output of the Business-Process-to-Service-Model transformation.

Transformation extensions for generating domain-specific output

By default, the Business-Process-to-Service-Model transformation provides the following extensions for transforming business processes in a specification model:

Default implementation: This extension describes the behavior of a business process by assigning a UML activity as an owned behavior of the business process, which is represented by a UML component. The UML-to-SOA transformation can use this information later to generate Business Process Execution Language (BPEL) artifacts.
Skeleton implementation: This extension creates a generic decomposition for the Services Component Definition Language (SCDL). You might use this implementation to generate a service model that the UML-to-SOA transformation can use to generate output that can be deployed by using WebSphere Integration Developer.

To create UML service models that contain implementation details for other domains, you can create and register custom extensions for the Business-Process-to-Service-Model transformation.

You can apply one transformation extension to all the business processes in the specification model, or you can specify a transformation extension for each business process in the specification model. You can specify transformation extensions in the transformation configuration.

Transformation output

In a Business-Process-to-Service-Model transformation configuration, you can specify a different name for the generated service model. The transformation generates a service model with the same name as the specification model in the project or folder that you specify as the transformation target. You might use the output of the Business-Process-to-Service-Model transformation as the source of another transformation such as the UML-to-SOA transformation, to create software services artifacts for service-oriented architecture (SOA) solutions.

In the transformation configuration, you can also specify that the transformation applies either the Services Modeling (SoaML) profile or the Software Services profile to the model that it generates.

Important: The Software Services profile is deprecated and a profile called the Services Modeling (SoaML) profile is available for modeling services. For information about migrating from the Software Services profile to the Services Modeling (SoaML) profile, see the related link at the end of this topic. For information about how stereotypes in the Software Services profile map to stereotypes in the Services Modeling (SoaML) profile, see the related link at the end of this topic.

For more information about the Software Services profile, also called the UML 2.0 Profile for Software Services, see the article entitled UML 2.0 Profile for Software Services on the IBM® developerWorks® website.

The profile that you select determines the stereotypes that the transformation applies to the elements in the target model. For example, for each business process in the source specification model, the transformation generates a UML component with the following stereotype applied:

If you select the Services Modeling (SoaML) profile, the transformation applies the «Participant» stereotype
If you select the Software Services profile, the transformation applies the «serviceProvider» stereotype

After you run the transformation, you can create visual representations of the generated components by adding them to a composite structure diagram.

The service model, or contract fulfillment model, preserves the contract information that is defined in the specification model, and provides the implementation details that are required to fulfill the contract. Each UML collaboration in the specification model that describes a business process is transformed into a UML component that represents a service in the service model. The transformation populates the generated components with ports that specify the interfaces that are required or provided by the business process.

The transformation generates CollaborationUse elements inside each component. A generated CollaborationUse maintains a link between the original collaboration element in the specification model and the component element in the service model. The transformation also generates bindings between collaboration roles and component ports. The binding of roles and ports represents business contract verification. To specify the implementation details of a service, you can specify or create a transformation extension to generate the implementation details of each service. The type of extension that you specify or create depends on the target domain, and includes considerations such as implementation language and deployment environment. You can specify an appropriate transformation extension in the transformation configuration.

After the transformation generates the service model, system or software architects can further refine the service model, which might include specifying more implementation detail or creating references to legacy libraries.

For more information about how the Business-Process-to-Service-Model transforms the elements in the realization model, see the related reference links at the end of this topic.

Traceability of business requirements by using contract verification information

Traceability enables you to ensure that the architecture that is defined in the generated service model meets the business requirements that are represented in the WebSphere Business Modeler business analysis model.

In the generated service model, the existence of contract verification information enables the traceability of a business process. The following information in specification and service models is necessary for contract verification for each business process:

CollaborationUse element that links the collaboration in the specification model to a component in the service model
Binding relationships between the roles in the specification model and the ports in the service model

Integration with Compare and Merge functionality

The Business-Process-to-Service-Model transformation uses the comparing and merging functionality to determine the differences between the specification model and the service model that the transformation generates. After you save changes to a specification model and rerun the Business-Process-to-Service-Model transformation, the merge editor displays the differences between the two service models. In the merge editor, you can select the changes that the transformation merges into the target model.

Integration with team support

The Business-Process-to-Service-Model transformation provides integration functionality with IBM Rational® Team Concert™, CVS, Rational ClearCase®, and Rational ClearCase LT version control systems, which enables you to automatically check out files or add new files.

You must enable team capabilities to work with configuration management systems.

Feedback