DW R Modsoacase5 PDF

Model service-oriented architecture with IBM
Rational Software Architect: Part 5. Service

Identification
Skill Level: Intermediate
Bertrand Portier
IT Architect
IBM
Gregory Hodgkinson (ghodgkinson@prolifics.com)

SOA Lead
Prolifics
27 May 2008
This tutorial series gives you a detailed look at modeling service-oriented architecture
(SOA) by using IBM Rational Software Architect. This fifth tutorial in this series will
step through how you would identify services and create the initial service model in
Rational Software Architect. It continues using the online DVD rental case study
introduced in the previous four parts, and you will use Rational Software Architect to
create the initial service model based on that case study.
Section 1. Before you start

Learn what to expect from this tutorial and how to get the most out of it.
About this series

This tutorial series gives you a detailed look at modeling service-oriented
architecture (SOA) by using IBM Rational Software Architect. Although this
tutorial is primarily for software architects and covers the activities that they perform,
it is also helpful to people in other roles in the software development process,
Part 5. Service Identification Trademarks

Copyright IBM Corporation 2008. All rights reserved. Page 1 of 25
developerWorks ibm.com/developerWorks
including those who provide input into software architecture, such as business
analysts, and those who use the software architecture as input to perform their own
activities, such as software designers and developers (architecture realization,
design, and implementation). This series also covers several core SOA concepts
that are useful to a wide audience.
You will learn how to do these three things:
Architecture: Describe what SOA comprises and where it fits into the
overall software development process.
Services: Design the services architecture for an SOA solution.
Models: Demonstrate how Rational Software Architect supports a
model-driven development (MDD) approach to thespecification of
service-oriented architectures.
After describing software architecture and positioning services within it, this series
then introduces Rational Software Architect and its SOA- and architecture-related
features. By using a fictitious online DVD rental case study throughout, these
articles:
Describe the work products used as input to the service architecture

activities, including the component business model, business process
model, system use case model, and external systems part of the design
model.
Describe, step-by-step, how the service model representing the
architecture is specified in Rational Software Architect, including service
consumers, service specifications, service partitions, atomic and
composite service providers, services, service collaborations, service
interactions, and service channels.
Explain how the service model is then used in the subsequent phases of
the software development process, such as design and implementation.
About this tutorial

In Part 1, we introduced the video rental case study that is used as the example
throughout this tutorial series. We placed service architecture within the framework
of the IBM Rational Unified Process (RUP) and introduced the IBM SOA
Solution Stack for reference. We noted the various work products that are used as
input to a service architecture, and then used the case study to provide examples for
two of them: the business architecture model (described in Part 1 in the form of a
component business model) and the business process model.

ibm.com/developerWorks developerWorks
In Part 2, we took a detailed look at what a domain model is and how it can be
represented in Rational Software Architect. You started to get hands-on experience
with the tool and created the domain model used in this series.
In Part 3, we explained how to model the external systems that we want to integrate
into our service oriented architecture. We described bottom-up analysis and the
modeling of these external systems in terms of interfaces and components.
In Part 4, we took a detailed look at the use case model. We explained the value of
this model in requirements specification activities. We then used Rational Software
Architect to specify the use case model for the DVD2U Return Video case study.
In this part, we will step through how you would identify services and create the
initial service model in Rational Software Architect.
Objectives
At the end of this part of the tutorial series, you should be able to:
Describe how services can be identified from the different input models
Create a service model in Rational Software Architect
Model and classify the identified services and consumers in Rational
Software Architect
Prerequisites
To get the most value from this tutorial, it is recommended (but not necessary) that
you be familiar with:
Service-oriented architecture (SOA)

Rational Software Architect
Unified Modeling Language (UML)
Rational Unified Process (RUP)
We highly recommend that you read the first four parts in this tutorial series before
reading this part.
System requirements

Rational Software Architect V7 (Fix Pack 005 or later)

IBM WebSphere Business Modeler Version 6.0.2, 6.0.2.1, or 6.1 is
required to download the essential DVD-Rental.zip file
Section 2. Service modeling

Part 1 of this tutorial series mentioned the service model as the core work product
for service architecture activities. In this section, we will focus on the service model
and the paradigms and techniques used to produce it.
The nature of a service model

The Rational Unified Process for Service-Oriented Modeling and Architecture (RUP
for SOMA) provides SOA best practices in a RUP format. RUP for SOMA defines
the service model work product in the Analysis and Design domain as follows:
The service model is an abstraction of the IT services implemented

within an enterprise and supporting the development of one or more
service-oriented solutions. It is used to conceive and document the
design of the software services. It is a comprehensive, composite
work product encompassing all services, providers, specifications,
partitions, messages, collaborations, and the relationships between
them.
In Part 3, we talked about the external systems model being a subset of the design
model, and we explained the difference between the service model and the design
model. To recap:
We use the service model to capture aspects of the architecture by using

only service-oriented model elements (service providers, services, service
consumers, and service specifications, for example). It contains the
specification of the design at this higher (architectural) level of
abstraction.
On the other hand, the design model contains detailed design and can
contain designs for both service-oriented parts and non-service-oriented
parts.
In Part 1, we introduced the SOA Solution Stack (Figure 1). In this and the following
parts of the series, our focus will be on the functional layer at the center of this stack:

the services layer.
Figure 1. The SOA Solution Stack
This tutorial will show how we design both the services and the service-oriented
solution that contains them for the DVD2U case study. We will also further specify
and use elements in other functional layers, above and under the services layer.
Using the UML Profile for Software Services

As introduced in Part 1, The UML 2 Profile for Software Services (UPSS) defines the
stereotypes that we use to model our service architecture (examples of these
stereotypes are <<serviceSpecification>>, <<serviceConsumer>>,
<<serviceProvider>>, and <<service>>). Starting with this part of the series,
we will introduce each stereotype as we use it in the service model. We recommend
that you refer to the "Building SOA Solutions Using the Rational SDP" in the IBM
Redbooks series, Chapter 9, the service model section (see Resources) for a
detailed treatment of the UPSS and its stereotypes.
Version 7.0 and later of Rational Software Architect includes UPSS, as well as a
model template that goes with it: the Service Design Model template (Figure 2).
Figure 2. The Service Design Model templat

The Rational Software Architect Service Design Model template provides structuring
guidelines and building blocks for the service model. Using the template, the service
model is structured according to these three views (see Figure 3):
Collaborations: The solutions service interactions

Services: Service providers and service specifications
Messages: Definitions of service inputs and outputs
Figure 3. The Service Design Model template structure

In this series, we do not use this Service Design Model template for two reasons:
Educational goals: We want you to learn all the elements of a service

model by starting from the ground up and building them as you go, rather
than using pre-built building blocks.
Emphasis on service providers: We made an architectural decision that
service providers (not service specifications) were the core building
blocks that we wanted to be able to reuse in future SOA modeling
exercises. For this reason, we want to have a package structure where a
given service provider package contains all of the information necessary
to fully specify its service provider (including service specifications and
their messages). This made the provided template and its package
structure unsuitable for our technique.
OOAD, CBD, and SOA

In previous parts of this series, weve covered some tried-and-tested best practices
that are not new with SOA. For example, in Part 1, we performed business process
modeling, and in Part 4, we performed use case analysis.
In this and the following parts, we will focus on the core elements and parts of the
service architecture, and, in doing so, we will cover some ideas that are more novel
to SOA. However, this does not mean that these are totally new ideas. Rather than
reinventing the wheel and forgetting all of the good things that weve learned about
software system design over the years, we will build on these. For example, we will
model service specifications by using classes and interfaces similar to what is done
in Object-Oriented Analysis and Design (OOAD). Also, we will model service
providers as components, as in Component-Based Development (CBD). That
means we still leverage these accumulated best practices that are fundamental to
successful SOA.
The key difference to these established best practices is that services, not classes or
components, are at the core of our design. This can be seen in the SOA Solution
Stack shown in Figure 1. So although these services (providers, consumers,
specifications) may be specified by using "traditional" modeling elements, such as
classes or components, it is the services that are the key parts of the architecture.
As an example, one of the things that we model are service interactions. We use
traditional UML interactions diagrams to do this, but the lifelines are not objects
based on plain classes or interfaces. Instead, they are service instances based on
service specifications.
Section 3. Service specifications

The starting point for this section is the SOA tutorial project that is the result of Part 4
of this series.
Creating the service model

We add the service model to the SOA Tutorial UML project. Download the file (see
DVD_Rental-Part4.zip in Downloads), and then follow these instructions to import
the project into your workspace.
Note:
If you still have the workspace available from Part 4, skip these steps and proceed to
Step 7.

1. Start Rational Software Architect. Use the default workspace, or create a

new one.
2. After Rational Software Architect has launched, close the Welcome

Screen if you are in a new workspace.
3. Select File > Import.
4. In the Import wizard, type project in the Select an import source filter
field, and then select Project Interchange and click Next (Figure 4).
Figure 4. Import Project Interchange
5. Click Browse and point to the location where you saved the

DVD_Rental-Part4.zip file.
6. Select SOA Tutorial, and then click Finish (Figure 5).
Figure 5. Import the SOA tutorial project
7. Select Window > Open Perspective > Modeling to switch to the

Modeling perspective (if you are not already in it).
8. After doing this, if you expand the SOA Tutorial project, you should see
something like Figure 6 in your Project Explorer view.
Figure 6. Initial Project Explorer view

9. To start with, you need to create a new UML model for the service model.
1. Select the SOA Tutorial project, right-click, and then select New >
UML Model.
2. From the New UML Model dialog, select Standard Template and
choose Blank Model as the template. Then deselect Create a
default diagram in the model.
3. Enter Service Model as the file name, and click Finish.
4. Select the Service Model, and then go to Profiles under the

Properties view.
5. Click Add Profile.
6. In the Select Profile dialog, select Software Services under

Deployed Profile, and click OK. (This is necessary to make use of
the SOA stereotypes and would have been done automatically if
the Service Design Model template had been selected).
Identifying subsystems
After analyzing the business process model, use case model, and domain model, we
decide to identify two sub-systems for the SOA solution:
Online Rentals: This subsystem deals with matters related to DVD2U

members
Tracking: This subsystem deals with matters related to DVD stock.

These subsystems are specifically made up of service-oriented parts. As such, we

refer to them as service-oriented systems in Part 3 of our article series (see
Resources). These are different from the external systems that we modeled in Part 3
of this tutorial series, which are not considered to be service-oriented.
For this part of the tutorial, we do not want Rational Software Architect to
automatically create diagrams under new packages. You will now set this
preference.
1. From the Window menu, select Preferences.
2. Under Preferences, type diag in the Filter field, and select Default
Diagrams under Modeling (Figure 7).
3. Deselect Create a default diagram in new packages.
4. Click Apply, and then click OK.
Figure 7. Default diagram preferences
You will now create the package structure in your service model for the two identified
subsystems.
5. Select Service Model, right-click, and then select Add UML > Package.
Name the package Service-Oriented Sub-systems.

6. Select the Service-Oriented Sub-systems package, right-click, and then

select Add UML > Package. Name the package Online-Rentals.
7. Repeat the previous steps for Tracking.
Note:
The system analyst identified two subsystems of use cases in the Use Case model,
which is where we got our two service-oriented subsystems. In this tutorial, we will
go only as far as identifying these service-oriented subsystems and creating a
representation of them. In the next tutorial, we will take the services that we identify
in the remainder of this tutorial, place them on service providers, and then take both
the service provider and service consumer parts and assemble them to build the
internal structure of our service-oriented subsystems.
Identifying services
In Part 1, we created the DVD2U Component Business Model (CBM), and the
Online Rental business process with its business tasks, business items, and
resources.
In Part 2, we modeled the Online Rental Domain model in terms of its domain
types.
We will now use these models to identify services (which we initially represent with
service specifications) and service consumers. More specifically, we will:
Leverage the CBM models business components to classify the identified

services
Use the decomposed business processes to identify the required
functionality to be offered by services
Use the domain models types to name the atomic services, and start to
define their inputs and outputs
A service specification is a service interface that groups together service operations.
It acts as a contract between the service consumers and the service provider.
Service specifications are produced by the software architect and used by
designers, implementers, and testers to respectively realize, implement, and test the
services.
Composite services
From the Online Rental Business Process model, you look at the Return Video
sub-process in WebSphere Business Modeler and change to swim-lane layout by

classifier: automation. Business tasks that are candidates for automation are the one
classified as either Human System (blue) or System-only (gray) in Figure 8.
Figure 8. The Return Video business process
This sub-process is decomposed at a level where identifying functionality that could

be provided by services is possible. For this example, assume that you decide to
identify services for two of these business tasks:
Notify of return (when the DVD2U member notifies DVD2U that they have
returned one or more videos)
Add copy back to stock (when the DVD copy received at the DVD2U
warehouse is added back to the list of available copies)
These two tasks support the return of a video. One is in the area of Member, the
other one is in Stock.
1. Based on the two identified service-oriented sub-systems, name the two

services ReturnVideoMembershipMgt and ReturnVideoStockMgt,
respectively.
We know that these two services are coarse-grained. For example,

ReturnVideoMembershipMgt includes members accessing their video rentals lists
and then selecting one or more videos to return. This is not fine-grained functionality

like, for example, merely accessing the video rentals list. As such, these two
services will probably require other services in order to provide their functionality.
We call this type of service Composite.
2. Under the Service Model, create a UML package named Composite.
3. Under the Composite package, create a package named

MembershipMgt.
4. Repeat the previous step for StockMgt.
From the Project Explorer, your Service model should now look something like
Figure 9.
Figure 9. The initial structure of the Service model
5. Select the MembershipMgt package, right-click, and then select Add

UML > Interface.
6. Name the interface ReturnVideoMembershipMgt.
7. Repeat the previous steps for ReturnVideoStockMgt (under the StockMgt

package).
8. From the Project Explorer, select the two interfaces (CTRL + click), and
then select the Stereotypes tab under the Properties view.
9. Click Apply Stereotypes, and select serviceSpecification.
10. Click OK.
Figure 10.
Figure 10. The two initial service specifications

Tip:
A successful alternative technique to deriving your composite services directly from
the business processes is to derive them from the use cases in the Use Case model.
In this case, you would create a composite service for each use case to support the
behavior required of that use case.
Service Consumers
The <<serviceConsumer>> stereotype is used to type model elements that are

consumers of services: the top functional layer in the SOA Solution Stack (Figure 1).
In terms of this Service model, any architectural part that is stereotyped as a
<<serviceConsumer>> is one that only consumes services, meaning that they do
no provide services.
You know that the Return Video business process is a consumer of the two
identified composite services. You will now capture this in the Service model.
1. In the Service Model, create a package called Consumers.
2. Under the Consumers package, create a component named

ReturnVideoProcess, stereotyped as <<serviceConsumer>>.
3. Save the Service Model (CTRL + s).
Figure 11.
Figure 11. The ReturnVideoProcess consumer

You will specify later which service operations are used by this consumer. You need
to specify these operations first.
You know that the service providers offering the service specifications that you've
identified will, themselves, consume (use) services, because they are composite
services. You will model these service providers later.
Atomic services
Now, you analyze the Domain model to see what services you can identify from it.
Figure 12 shows the Rental part of the DVD2U Domain model.
Figure 12. DVD2U Domain model for Rental

The services identified from the Domain model are typically fine-grained, because
they deal with specific business entities, such as a Member or an Account. These
data services, which provide Create-Read-Update-Delete (CRUD) access to data,
are considered atomic services. However, it is important to note that not all of the
operations assigned to these domain entity-oriented services will be CRUD-style
operations. Any atomic business logic that can be aligned with a single domain type
should appear at this level. Some of these may be more computational, meaning
that given a set of inputs, they compute outputs.
Note:
Although we won't cover it in detail here, typically, you would also analyze the

External Systems model from Part 3 of this series (this is called bottom-up existing
asset analysis) to see if the functionality that they provide could help fulfill the Video
Return requirements.
For DVD2U Return Video, these are the identified atomic services:
Member: Information about a DVD2U member (name, address, and so

forth)
MemberRental: Information about a member's video rental (dates,
shipment notices, and such)
VideoList: Information about a member's video list (titles, dates)
VideoCopy: Information about a video copy (rental status and such)
VideoTitle: Information about a video title (basically the name)
Location: Information about the location of a video copy (in stock and
such)
Note:
A service specification's name should be meaningful for the business; and the
organization-level SOA governance should have set the standards for service
naming. In our case, we make sure we derive the service specification names from
the Domain model (atomic) and Business Process model (composite).
1. In the Service Model, create a package named Atomic.
2. Under the Atomic package, create a UML interface stereotyped as

<<serviceSpecification>> for each of the six identified services
listed previously.
Figure 13.
Figure 13. The Service model with the atomic service specifications

For composite services, you created two sub-packages: MembershipMgt and

StockMgt.
Based on the list of identified atomic services, assume that you decide to create
these three sub-packages for them:
MemberMgr: Services related to a DVD2U member, such as Member,

MemberRental, and VideoList
VideoCopyMgr: Services related to copies of DVDs, such as Location
and Video Copy
VideoTitleMgr: Services related to video titles
Note:
We appended Mgr (Manager) to these packages' names, because these packages
will be holding the full specifications of service providers in your Service model (not
just service specifications). We refer to the service providers at this level as
Managers, because they typically manage a set of information.
3. From the Project Explorer, in the Service Model, create three

sub-packages under the Atomic package for MemberMgr,
VideoCopyMgr, and VideoTitleMgr.
4. Move each service specification to its appropriate sub-package, as shown

in Figure 14.
5. Save the Service model (CTRL + s).
Figure 14.
Figure 14. The classified atomic service specifications

6. For each service specification, we recommend that you provide a textual

description: one or two sentences that describe in plain English what the
service is. In Rational Software Architect, you should use the
Documentation tab of the service specification (under the Properties
view) to document this.
7. In addition, start to think about the following for each service specification:
Consumers: Who would use a service that would implement this
service specification? What drove you to identify this service
specification? It should be obvious at this stage who would use the
service (a business process or another service, for example). If you
cannot find a consumer for the service, then maybe you should not
have it in your model.
Inputs and Outputs: What would be the inputs and outputs for the
operations under that service specification? If the service was

identified from the Business Process model, then that information

may lie in the Business Process model (the business item that flows
through the business process). If not, the inputs and outputs would
typically be derived from the Domain model.
As a final word: Because it is beyond the scope of this tutorial to fully describe the
techniques used to identify services, we recommend the following resources (listed
under Resources) for more detailed materials:
The Architecting Services with IBM Rational Software Architect course

From the IBM Redbooks series, "Building SOA Solutions using the
Rational SDP," Chapter 10 and Chapter 11, Task 1, Step 3: Model atomic
service providers
Rational Unified Process for Service Oriented Modeling and Architecture
(RUP SOMA), Identification phase
Section 4. Wrap-up
In this part of this tutorial series, you learned about the creation of the initial Service
model -- the model that is at the core of service modeling.
1. You identified services from the Business Process model and the Domain
model.
2. You used Rational Software Architect and the UML Profile for Software
Services to represent each identified service with a service specification.
3. You used UML packages to classify the identified services, and you also
identified service consumers.
As you now know, the output of the service identification work is more or less an
initial list of service specifications. These service specifications describe, at a high
level of abstraction, what the services are.
In the parts of this series that follow, you will fully detail these service specifications
(operations, and so forth) and also model service interactions and service providers.

Downloads
Description Name Size Download
method
Initial Project Interchange (RSA DVD_Rental-Part4.zip 10KB HTTP
required)
Final Project Interchange (RSA DVD_Rental-Part5.zip 10KB HTTP
required)
Information about download methods

Resources
Learn
Read Part 1 of this series, Model Service-Oriented Architectures with Rational
Software Architect: Part 1. Case study, tools, and the business view .
Software Architect: Part 2. Modeling the business domain .
Software Architect: Part 3. External system modeling .
Software Architect: Part 4. Use Case models .
Take the course called Architecting Services with IBM Rational Software
Architect V7.
Read Exploring the fundamentals of architecture and services in an SOA: Part
3. Service-oriented solutions and enterprise architecture by Gregory
Hodgkinson and Bertrand Portier (IBM developerWorks, January 2008).
Read the developerWorks introductory article titled The Rational UML profile for
business modeling by Simon Johnston (developerWorks, April 2004). The
Rational UML profile for Business Modeling is a component of the Rational
Unified Process (RUP). It presents a UML language for capturing business
models and is supported by the Business Modeling Discipline in the RUP.
Read the developerWorks intermediate-level article, Business services
modeling, Integrating WebSphere Business Modeler and Rational Software
Modeler, by Jim Amsden (developerWorks, December 2005). Business
Services Modeling forms the foundation for the integration between IBM
WebSphere Business Modeler, Rational Software Architect (and UML), and the
Rational Unified Process business modeling guidelines to better support
model-driven development (MDD).
Visit the Rational software area on developerWorks for technical resources and
best practices for Rational Software Delivery Platform products.
Subscribe to the developerWorks Rational zone newsletter. Keep up with
developerWorks Rational content. Every other week, you'll receive updates on
the latest technical resources and best practices for the Rational Software
Delivery Platform.
Browse the technology bookstore for books on these and other technical topics.
Get products and technologies
Download trial versions of IBM Rational software.

Download IBM product evaluation versions and get your hands on application
development tools and middleware products from DB2, Lotus, Rational,
Tivoli, and WebSphere.
Discuss
Check out developerWorks blogs and get involved in the developerWorks
community.
About the authors

Bertrand Portier
Bertrand Portier works for IBM SWAG SOA Advanced Technologies
(formerly EIS). He is heavily involved in Service-Oriented Architecture,
model-driven, and asset-based development. A regular speaker at
conferences and the author of several technical articles, he has also
co-authored an IBM Redbook about SOA solutions.
Gregory Hodgkinson
Gregory Hodgkinson is a lead consultant at Prolifics
(www.prolifics.com). Previous to that he was a founder, director, and
the SOA lead at the company 7irene. He has 10 years of experience in
software architecture, initially specializing in the field of
component-based development (CBD), then moving seamlessly into
service-oriented architecture (SOA). His extended area of expertise is
the software development process, and he assists Prolifics and IBM
customers in adopting RUP framework-based agile development
processes and SOA methods. He is still very much a practitioner, and
has been responsible for service architectures for a number of FTSE
100 companies. He presents on agile SOA process and methods at
both IBM (Rational and WebSphere) and other events and has also
co-authored a Redbook on SOA solutions.


DW R Modsoacase5 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DW R Modsoacase5 PDF

Uploaded by

Copyright:

Available Formats

Model service-oriented architecture with IBM

Rational Software Architect: Part 5. Service

Gregory Hodgkinson (ghodgkinson@prolifics.com)

Section 1. Before you start

About this series

Part 5. Service Identification Trademarks

You will learn how to do these three things:

Describe the work products used as input to the service architecture

About this tutorial

Part 5. Service Identification Trademarks

Service-oriented architecture (SOA)

Part 5. Service Identification Trademarks

Rational Software Architect V7 (Fix Pack 005 or later)

Section 2. Service modeling

The nature of a service model

The service model is an abstraction of the IT services implemented

We use the service model to capture aspects of the architecture by using

Part 5. Service Identification Trademarks

the services layer.

Figure 1. The SOA Solution Stack

Using the UML Profile for Software Services

Figure 2. The Service Design Model templat

Part 5. Service Identification Trademarks

Collaborations: The solutions service interactions

Part 5. Service Identification Trademarks

Educational goals: We want you to learn all the elements of a service

OOAD, CBD, and SOA

Part 5. Service Identification Trademarks

Section 3. Service specifications

Creating the service model

Part 5. Service Identification Trademarks

1. Start Rational Software Architect. Use the default workspace, or create a

2. After Rational Software Architect has launched, close the Welcome

3. Select File > Import.

Figure 4. Import Project Interchange

Part 5. Service Identification Trademarks

6. Select SOA Tutorial, and then click Finish (Figure 5).

Figure 5. Import the SOA tutorial project

7. Select Window > Open Perspective > Modeling to switch to the

Figure 6. Initial Project Explorer view

Part 5. Service Identification Trademarks

3. Enter Service Model as the file name, and click Finish.

4. Select the Service Model, and then go to Profiles under the

5. Click Add Profile.

6. In the Select Profile dialog, select Software Services under

Online Rentals: This subsystem deals with matters related to DVD2U

Part 5. Service Identification Trademarks

These subsystems are specifically made up of service-oriented parts. As such, we

1. From the Window menu, select Preferences.

3. Deselect Create a default diagram in new packages.

4. Click Apply, and then click OK.

Figure 7. Default diagram preferences

Part 5. Service Identification Trademarks

6. Select the Service-Oriented Sub-systems package, right-click, and then

7. Repeat the previous steps for Tracking.

Leverage the CBM models business components to classify the identified

Part 5. Service Identification Trademarks

Figure 8. The Return Video business process

This sub-process is decomposed at a level where identifying functionality that could

1. Based on the two identified service-oriented sub-systems, name the two

We know that these two services are coarse-grained. For example,

Part 5. Service Identification Trademarks

2. Under the Service Model, create a UML package named Composite.