没有合适的资源?快使用搜索试试~ 我知道了~
资源详情
资源评论
资源推荐
Effective Business Modeling with UML:
Describing Business Use Cases and Realizations
by Pan-Wei Ng
Software Engineering Specialist
Rational Software Singapore
As most software development practitioners
know, the Unified Modeling Language (UML)
excels at representing "real world"
phenomena. This capability led to
development of the UML Business Modeling
Profile, which provides extensions and
stereotypes to facilitate communication
between users and analysts.
Organizations that are thinking about
applying the UML Business Modeling Profile
often have practical questions, such as:
● When do I really need a business model? When are use-case
models alone sufficient?
● Which UML diagrams should I use for particular business modeling
situations? How do I know whether to use a sequence diagram or a
collaboration diagram, for example?
● How does the UML business model relate to other UML models
(domain model, use-case model, etc.)? How should I organize these
models?
Unfortunately, the literature that addresses
these questions, as well as best practices for
applying the UML Business Modeling Profile, is
relatively sparse compared to that for system
modeling. This frustrates users and analysts
who recognize the benefits of using the UML
for business modeling but are forced to
struggle with the notation.
This article addresses their concerns by
walking through an example case that models
http://www.therationaledge.com/content/nov_02/t_businessModelingUML_pn.jsp
Copyright Rational Software 2002
the acquisition process within an IT
department responsible for managing
outsourced development. Comprised of legal
advisors, enterprise architects, and project
managers, the department is responsible for
contractual, system architecture, and project
management issues. Its mission is to free
end-user departments from IT-related issues
so they can concentrate on business
operations. When these departments need to
acquire new systems or enhance existing
ones, they get the IT department to prepare
tender specifications, and IT then selects
suitable vendors to deliver the required
system.
The discussion assumes a basic
knowledge of the Business Modeling Profile
described in the Rational Unified Process
®
(RUP
®
). If you're not familiar with this
Profile, see the Appendix below.
Doing a Business Use-Case
Model Survey
The first step in our simple example is to
complete a business use-case model survey.
As Figure 1 shows, there are two actors and
two business use cases. The End User
Manager wants a vendor to automate some
processes, so the IT department assists by
preparing tender documents and short-listing
vendor candidates. Once a contract has been
awarded, the procurement department
assists the End User Manager by managing
delivery of the systems in accordance with
the contract's milestones.
Figure 1: Business Use-Case Model
We can summarize the business use cases as
follows:
● Prepare Tender: Describes the
process for preparing the system
Identifying Business
Actors
It is easy to identify
Actors for system
modeling -- anything
outside the system is
an Actor, and the
boundaries are very
clear, so people are
always Actors. For
business modeling it is
not so simple,
however, because a
person could be either
a Business Actor (i.e.,
someone external to
the business who
interacts with it) or a
Business Worker (i.e.,
someone internal to
the business). A way
around this issue is to
identify all people
involved with the
business case before
classifying them as
either Business Actors
or Workers. This
means you have to
define Business Actors
and Workers at the
same level of
abstraction: They are
all either people, or
groups of people.
Try not to define any
system as a Business
Actor, although some
systems will become
Actors when you
derive the system use
cases. In business
modeling, you want to
focus on business
processes, so postpone
dealing with system
issues to avoid
cluttering up the
business use-case
model.
specifications.
● Select Vendor: Describes the
selection process, from approval of
tender to award of contract award to a
vendor that can meet the specifications
at a reasonable cost and deliver on a
reasonable schedule.
We can summarize the Business Actors as
follows:
● End User Manager: The contact
person in the end user department
that requested the automation.
● Vendor Manager: The vendor's
representative who bids for the
contract and oversees system
implementation from the vendor end.
In our business use-
case model survey, the
Business Actors are
people as opposed to
groups of people; that
is, we have an End-
User Manager as
opposed to an End-
User Department, and
a Vendor Manager as
opposed to a Vendor.
This is so that the
Actors will be at the
same level of
abstraction as the
Business Workers
when we later realize
the business use
cases.
Scoping Business
Use Cases
To determine scope of
a business use case, I
usually trace a core
business goal in a
single workflow like
the one in Table 1. If
the use case gets too
long, I refine the core
business goals into
subgoals, segment the
workflow accordingly,
and divide the long
workflow horizontally
into several business
use cases.
Table 1: Very Long Workflow
The business use case begins when an End User Department requires
additional automation to improve operations. The goal of this use case
is to select a vendor that can deliver the desired system.
1. Designation of End-User Manager. The procurement
department designates an End-User Manager for the entire
acquisition process.
2. Prepare System Specifications. The End User Manager
prepares and submits specifications to the IT department.
3. Prepare Tender Document. The IT department reviews
submitted specifications and prepares a tender document,
augmenting the specifications with contractual requirements.
4. Approval of Tender Document. The End User Manager
reviews and approves the tender document.
5. Open Tender. Once the tender document is approved, the IT
department sends it to a list of vendors for the system category
specified.
6. Prepare Bid. Each vendor prepares a bid indicating estimated
cost and projected delivery plan, and submits it to the IT
department.
7. Short-list Bids. At the end of the tender period, the IT
department short-lists candidate bids (vendors) according to the
estimated cost and feasibility of the delivery plan.
8. Select Vendor. From the short-list of vendors, the End-User
Manager selects the most suitable one.
9. Prepare Contract. The IT department prepares a contract with
the selected vendor.
10. Award Contract. Both the End-User Manager and the selected
Vendor sign the contract, and more detailed system planning
and design begin.
In our example, the core business goal of acquiring a new system is
refined into two subgoals
● Specifying the system to be acquired.
● Selecting and evaluating a candidate vendor.
Consequently, the Prepare Tender business use case covers Steps 1 to 4
in Table 1, and the Select Vendor business use case covers Steps 5 to 10
in Table 1. There are many ways to segment the workflow, and it is
important to discuss options with the customer. Nevertheless, it is
important to recognize that the true value in business modeling lies in
understanding how seemingly piecemeal workflows relate to each other.
Doing a Business Use-Case Specification
In this section, we look at how to describe business use cases. The
business use-case template in the RUP has a number of sections, but we
will focus only on the basic and alternate flows. I will discuss the other
sections -- which include goals, risks, possibilities, and so on -- in a future
article. Table 2 shows basic and alternate flows for the Prepare Tender
business use case.
Table 2: Business Use-Case Specification
Basic Flow for Prepare Tender
This business use case begins when the End User Department requires
additional automation to improve operations. The goal is to finalize a
tender document that can be issued to candidate vendors.
1. Designation of End User Manager. The procurement
department designates an End-User Manager for the entire
acquisition process.
2. Prepare System Specifications. The End-User Manager
prepares and submits specifications to the IT department.
3. Prepare Tender Document. The IT department reviews
submitted specifications and prepares a tender document,
augmenting the submitted specifications with contractual
requirements.
4. Approval of Tender Document. The End-User Manager
reviews and approves the tender document. The use case then
terminates.
Alternate Flows
1. System Specifications Invalid. In Step 3, if the IT department
finds the system specifications are too vague or unfeasible, the
End-User Manager needs to rework the specifications. The
business use case then either resumes at Step 2 or terminates if
the End-User Manager does not wish to continue.
2. System Already Exists. In Step 3, if the IT department finds
that the desired system is very similar to an existing system in
another department, then the IT department refers the End-User
Manager to that department. If the End-User Manager wishes to
proceed with acquiring the "new" system, he or she must put the
differentiating features in the system specifications, resubmit the
specifications, and continue at Step 2. The business use case
terminates if the End-User Manager does not wish to continue.
3. Tender Document Discrepancies. In Step 4, if the End-User
Manager notices discrepancies in the Tender Document, it is
rejected, and the IT department must rework it. The business
use case continues at Step 3.
剩余23页未读,继续阅读
sun_bolin
- 粉丝: 0
- 资源: 9
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
最新资源
- 论文(最终)_20240430235101.pdf
- 基于python编写的Keras深度学习框架开发,利用卷积神经网络CNN,快速识别图片并进行分类
- 最全空间计量实证方法(空间杜宾模型和检验以及结果解释文档).txt
- 5uonly.apk
- 蓝桥杯Python组的历年真题
- 2023-04-06-项目笔记 - 第一百十九阶段 - 4.4.2.117全局变量的作用域-117 -2024.04.30
- 2023-04-06-项目笔记 - 第一百十九阶段 - 4.4.2.117全局变量的作用域-117 -2024.04.30
- 前端开发技术实验报告:内含4四实验&实验报告
- Highlight Plus v20.0.1
- 林周瑜-论文.docx
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功
评论0