在前面的文章中，我们从Rational Rose开始，启动并建立了一个类图。下面我们的任务就是要通过BankAPP实例来了解如何用Rose构造业务模型。
业务企业模型
业务前景，目标，组织－分别提供
业务事件[UML信号事件-指定的激励表格或文档]和过程(UML 用例)
| 过程名 |
参与者 |
事件/输入 |
转换 |
事件/输出 |
约束 |
描述 |
引用 |
联系点 |
| WithdrawFromAccount |
Customer,Teller,BankDB |
WithdrawRequest |
UpdateAccount |
WithdrawRecord |
|
|
|
|
[译注：Customer：客户；Teller：出纳员 ；withdraw：取款；account：账户；BankDB：银行数据库]
Business Actors, Business Workers,业务实体（问题域实体）
| 业务参与者(UML 参与者) |
业务员（UML 参与者） |
业务实体（UML 类） |
| Customer |
Teller |
Account,SavingsAccount,CheckingAccount |
[译注：saving：储蓄；checking：支票]
业务规则目录
| 规则标识符 |
参与者，实体，过程 |
描述：IF条件..then 动作 |
区域 |
引用 |
联系点（Point of Contact） |
| ValidAccount |
Account |
If AccountNum 有效,then Acccount 有效 |
|
|
|
业务接口（指定操作集）－由架构师提供
业务模式目录－参见《Business Modeling with UML》（Eriksson 和Penker 著）。
业务术语－待完备
业务系统体系结构－由架构师提供
需求模型
需求：BankApp应该管理支票和存款账户的存款和取款。将来（还要提供）查询，转账，透支，等等从TellerGUI 到BankApp的输入/输出： sAcctNum, nDeposit, nWithdraw,sText。从BankApp 到BankDB的输入/输出： sAcctNum, nDeposit, nWithdraw.
需求可追踪性表：需求号，名称，引用，用例名，UML元素，测试用例，描述，职责。
需求可追踪性表（部分）
| 需求编号 |
需求名 |
引用 |
用例名 |
UML元素 |
测试实例 |
描述 |
职责 |
| 1.1 |
DepositToSavingsAccount |
|
DepositToSavingsAccount |
BankPkg |
|
|
|
| 1.2 |
DepositToCheckingAccount |
|
DepositToCheckingAccount |
BankPkg |
|
|
|
| 1.3 |
WithdrawFromSavingAccount |
|
WithdrawFromSavingAccount |
BankPkg |
|
|
|
| 1.4 |
WithdrawFromCheckingAccount |
|
WithdrawFromCheckingAccount |
BankPkg |
|
|
|
需求－用例图－所有用例
Rose用例图：在浏览器窗口，选择Use Case View；Main Use CaseDiagram；在图上放置参与者，用例，关系[Rose单向关联（Unidirectional Association）]，泛化；选择每一个参与者－单击鼠标右键键入参与者的操作；选择Tools-Check Model；选择File-Save.
需求－高级别协作图[环境图（Context Diagram）]
Rose高级别协作图：在浏览器窗口，选择Use Case View；选择Browse-Interaction Diagram（交互图）-Use Case View-；选择Collaboration Diagram；键入图名；在图上放置对象表示参与者；双击每个对象，然后从下拉列表中选择参与者名；在图的中央放置一个对象以表示系统；双击对象，键入系统名；选择Rose Object Link (对象连接符)并且在参与者和系统之间拖曳；选择Rose 文本框TextBox”ABC” ,键入传递的对象/数据；选择Tools-Check Model；选择File-Save。
需求－用例增量
增量1：支票和储蓄账户的存款和取款
增量2：查询和转账
增量3：透支
每个增量内进行迭代：乐观的，正常的，悲观的
需求用例规约：名称，触发器，输入参数，输出返回值，出现的前置条件/异常，出现的（raised）后置条件/异常，基本的/乐观场景，替代性可选的/悲观的场景，业务规则，测试实例。
WithdrawFromCheckingAccount用例的用例规约
用例名：WithdrawFromCheckingAccount
触发器： WithdrawFromCheckingAccount
输入参数： sAcctNum, nWithdraw
输出返回值： sText
前置条件： ValidAccount = true and nWithdraw <= nCurrentBalance
出现的前置条件异常： 待定的
描述/转换： nCurrentBalance = nCurrentBalance - nWithdraw
后置条件： nCurrentBalance < nOldBalance
后置条件异常：无
相关用例： Generalization, Includes, Extends/Extension Point： 无
基本场景/乐观场景： Text(文本) - 待定；Diagram（图） -见 WithdrawFromCheckingAccount乐观场景顺序图
替代性可选场景/被动场景：Text -待定；Diagram -见WithdrawFromCheckingAccount 活动图
业务规则： ValidAccountRule, AdequateBalanceRule
测试实例：1 - 乐观的：输入： sAcctNum - BGates001, nWithdraw - 100, nCurrentBalance - 1000 Conditions： None, 输出：”BGates001 withdraw $100 OK and recorded”；2 …待定
输入/输出表单：
WithdrawFromCheckingAccount用例的输入/输出表单
Withdraw Request Form（取款需求表单）
Customer Account Number（客户账号）__________
Withdraw Amount（取款数量） ________
Button-Submit（提交按钮） Button-Clear（清除按钮）
Withdraw Response Form（取款响应窗体）
Customer Account Number __________
Withdraw Amount __________
Status （状态） ________________________
Button-OK（OK 按钮）
需求－顺序图WithdrawFromCheckingAccount - 乐观场景
注：getApp的第一笔事务需要达到应用程序的最高级别
Rose 顺序图：在浏览器窗口，选择Use Case View；选择 Use Case Diagram；选择一个用例；选择Browse-Interaction Diagram-Use Case View-；选择Sequence Diagram；键入图名,例如WithdrawFromCheckingAccount－OptiminticScenario；在图上放置对象以表示参与者；双击每个对象，然后从下拉列表中选择参与者名；
在图的中央放置一个对象以表示系统；双击对象，从下拉列表中键入系统名；选择Rose Object Link (对象连接符)，在参与者和系统之间拖曳；选择Tools-Check Model；选择File-Save .
4-WithdrawFromCheckingAccount用例－所有场景的需求活动图
注：getApp的第一笔事务需要达到应用程序的最高级别
Rose状态－活动图： 在浏览器窗口，选择Use Case View；
选择Use Case Diagram 显示图；
选择一个用例；选择Browse - State Diagram；
如果”State Diagram” 是灰色，则返回到用例图并重新选择一个用例；
在图上放置活动状态（activity states）；通过在两个状态之间拖曳，放置转移；
选择Tools-Check Model；
选择File-Save 。
需求－产品性能：高可靠性，10个并发的用户，2秒响应时间。
需求/分析－高阶概念模型（HOCM–High Order Concept Model）
外部参与者：TellerGUI,BankDB.内部实体（Internal Entities）： BankApp, Account, CheckingAccount, SavingsAccount
Rose高级别概念模型图： 推荐使用铅笔和纸做HOCM。作为替代，创建不含属性和操作的Rose类图。
分析模型－草图
分析类图 - 最简结构
Rose类图： 见〈使用Rational Rose〉
分析包图
Rose包图：在浏览器窗口选择Logical View；选择Browse－Class Diagram－Logical View－。输入包图名；在图上放置包；从工具条中选择依赖箭头然后从源包到目的包拖曳，放置依赖关系。在浏览器中，拖动每个类到适当的包；选择Tools-Check Model；选择File-Save。
分析 WithdrawFromCheckingAccount顺序图－乐观场景
注：getApp的第一笔事务需要达到应用程序的最高级别
Rose顺序图：见〈使用Rational Rose〉
8- 分析Account类的状态图
Rose 状态－活动图：在浏览器窗口，选择Use Case View；选择Use Case Diagram 显示；选择一个用例；选择Browse - State Diagram；如果 “State Diagram” 是灰色，则返回到用例图并重新选择一个用例；在图上放置活动状态（activity states）；通过在两个状态之间拖曳，放置转移；选择Tools-Check Model；选择File-Save .
分析－复杂操作：待定的－每一个操作的活动图 和/或操作规约：名称，输入，前置条件/异常，转换，后置条件/异常，业务规则，描述。
Rose规约： 显示类图；选择一个类；按鼠标右键显示Specification Dialog Box；选择一个标签，例如Operations；双击一个操作；填写操作信息；选择 Tools - Check Model；选择File - Save.
设计模型 - 编码的基础
设计过程环境：Linux 6.2版, GNU C++ 6.2版, C++ 标准库,CORBA 3。
设计潜在模式
企业级：基于分布式CORBA，具有公共接口的组件
系统（组件到组件）：分层，会话－实体（Session - Entity），回调（Callbacks），发行者-订阅者（Publisher - Subscriber）
组件：应用－文档，控制器－实体－边界，虚包（Facade）
类设计：UML, Factory（工厂），事务
JAVA 语言：Java Bean, Enterprise Java Bean, Servlet, RMI
设计包图
设计类图 说明类型和参数-目标是完成编码
注：CheckingAccount和SavingsAccount 提供多态操作的实现。
设计顺序图WithdrawFromCheckingAccount - 乐观场景
注：getApp的第一笔事务需要达到应用程序的最高级别
设计协作图WithdrawFromCheckingAccount - 乐观场景
在Rational Rose中打开顺序图，按F5 自动创建协作图。
设计CheckingAccount类withdraw()操作的操作规约
用例名： withdraw
触发：withdraw
输入参数： nWithdraw ： int
输出返回值： boolean
前置条件： nWithdraw <= nCurrentBalance
出现