uml05(第五章)

从在构架方面具有重要意义的用例中确定分析类 通过分析类交互来更新用例实现
-34-
经典的三层构架-1
表示层
应用逻辑层
记录销售信息
支付授权
存储层
数据库
-35-
多层体系结构的动机



将应用逻辑作为单独的构件从系统中分离出来， 以便这些构件在其他系统中能得到重用 将各个层次分配到各个不同的物理计算节点， 或者分配给不同的进程。这样可以改善系统性 能、更好地支持客户和服务器系统中的信息共 享和协调 将不同层的开发任务在开发者之间适当地分配， 这可以有效地利用开发人员的专长和开发技巧， 并且能够提高并行开发能力

完备的


-19-
从用例开始-2

根据风险、重要性以及项目组的能力确定用例的优先 级：用例分级


风险 重要性 团队能力以及团队建设

在迭代开发中，通过一次全面的需求收集来获得所有 的用例；之后找出一个用例集，开发一个符合这些需 求的最小系统，完成一次迭代过程；在此基础上，进 行后续的增量开发过程


清晰地区分问题域（业务需求）和解域（详细 的设计考虑）

总是关注存在于问题域的抽象
-29-
经验法则-2

总是尽力最小化耦合

类之间的每个关联都是在它们之间建立耦合

继承关系


继承是类间耦合的最强形式 如果看起来存在自然的、强迫的抽象层次，则可探 索继承关系 分析中，永远不要仅为了复用代码而使用继承
-3-
下构化 分析设计
其它方法
自己的 土方法
系统
-4-
内容安排


面向对象分析设计过程 面向对象分析基础 面向对象分析原则 开始分析之前 用例分析技术
-5-
面向对象分析、设计

基于面向对象的分析和设计理论，产生 了许多开发过程实践

RUP：Ration Unified Process MSF：Microsoft Solution Framework ALM：Application Lifecycle Manage
第 5 章用例分析技术
Use-Case Analysis
Review: Use-Case Modeling

基于用例的需求获取过程

1. 获取原始需求 2. 开发一个可以理解的需求

2.1 识别参与者 2.2 识别用例 2.3 构建用例图
进行用例阐述 4.1 识别用例间的关系 4.2 对用例进行组织和分包
Login Login
Employee Employee
Record Time Record Time Create Charge Code Create Employee
-26-
内容安排


面向对象分析设计过程 面向对象分析基础 面向对象分析原则 开始分析之前 用例分析技术
-27-
分析的基本原则
-16-
分析模型与用例模型
用例：外观
类图：内部机理
-17-
如何开始？
从 用 例 开 始！
-18-
从用例开始-1

根据高层用例图和文档来确认需求定义是可靠 的、一致的

可靠的

每个用例都包含对正常事件流和异常事件流的描述 存在备选事件流、异常事件流的描述
如果在分析过程中发现一些新的用例，说明需求是不完备 的，此时应对用例进行重构 在分析过程中，还有可能精化对每一个用例的理解
-31-
分析模式-2



分析模式更接近系统的概念模型，如果系统概 念模型经过抽象，可以应用在多个相似的环境 中，那么，它就变成了模式 在代码实现层面，我们很容易看到和理解重用 的概念，从最开始的函数库，到类库，到设计 模式，到应用框架，我们的对代码的重用程度 越来越高 在业务领域的分析层面，重用的可能性依然存 在，分析模式，就是这种重用的一部分，如果 我们都可以利用以往的经验，得到业务领域的 通用解决方案，它们将直接影响到应用系统的 设计，因而这种重用的价值将更加显著
-13-
OOA目标

开发一系列模型，以描述计算机软件， 从而满足客户定义的需求：分析模型


包括两种图，描述对象及其交互 这些图按照用例模型来组织，每个用例图都 会产生数张图


类图（class diagram）：描述了构成一类对象 特征的状态和行为（描述软件架构） 交互图（interaction diagram）：描述对象之 间的交互行为（演示用例实现）（描述系统行为）
------------------------------------------------------------------------------Glossary
Analysis workflow
: :
Analysis Class
-15-
OOA与用例模型

分析是建立在需求收集的基础上

Vision/Scope Approved
Release Readiness Approved
Product Management
Development
MSF
User Experience
Scope Complete Project Plans Approved
Communication
Test Release Management
-2-

3 详细、完整地描述需求


4 重构用例模型


References



[Arri02]CT Arrington, Enterprise Java with UML（马波，李雄锋译，Enterprise Java with UML中文版，机械工业出版社，2003年） [Larm01], Craig Larman, Applying UML and Patterns, 2e（姚淑珍、李虎等译，UML和模式应用 -面向对象分析与设计导论，机械工业出版社，2002 年） [DEV475], IBM Rational, Mastering ObjectOriented Analysis and Design with UML, 2003 [Kruc00], Philippe Kruchten, The Rational Unified Process: An Introduction (Second Edition)（周伯生等译，Rational统一过程引论，机 械工业出版社，2002.5）


1-用户几乎不注意用例的存在，在没有它的情况下系统不 会有什么影响 2-用户注意用例的存在，但稍加想象，系统仍然可以很好 的使用 3-系统的大部分可以独立于这个用例 4-系统的一部分可以独立于这个用例 5-没有它，就不可能使用这个系统
-24-
从用例开始-其它问题

合适性（suitability）：这个用例是否适合你 的团队
Employee
Record Time
Create Charge Code Create Employee
-21-
从用例开始-风险分析-1

项目本身风险（risk）：项目的风险清 单

无法接受的系统性能 无法应付新的需求 不确定的进度以及开发周期 无法接受的用户界面 ……
-22-
从用例开始-风险分析-2

分析模型建立在用例模型的基础上 用例模型确定了分析模型的结构（通过用例来组织 分析模型） 用户视角理解用户问题过渡到开发团队视角分析用 户问题

与需求一样，它还是在问题域中 用例分析也是分析的一个阶段，而OOA是分析的后期阶段， 从这个阶段开始，我们从用户域跨入开发团队域

分析与需求捕获在很大程度上重叠，这两个活动常 常相辅相成，为了澄清和找出任何遗漏或歪曲的需 求，常常需要在需求之上作一些分析
-6-
IBM RUP
-7-
RUP中的分析和设计工作流
软件构架文档 用例实现规约
分析 Analysis
设计 Design
-8-
分析阶段主要工件
用例视图：
用例模型 用例实现(分析)
逻辑视图：
分析(概念)模型 体系结构包图
:
:
-9-
MSF
Deployment Complete
Program Management
相对来说，策划一系列的小胜利和接受一些小的 失误总要好一点。策划一个巨大的胜利经常会导 致灾难性的失败！
-20-
用例图：考勤卡系统
Export Time Entries Billing System Change Password <<include>>
Administrativ e User
Login

“该模型对所有项目干系人有用吗？”
保持模型简单！
-30-
题外话：分析模式-1

分析模式（analysis pattern）：描述通用业 务/分析问题解决方案的一种模式



例：“游戏者击中白球，它以一定的速度前进，并 以特定的角度碰到红球，于是红球在某个特定的方 向上前进一段距离 ” 除了这些表面现象，还必须了解背后的本质，那就 是和质量有关的运动定律，速度，动量，等等。了 解这些规律将更容易看到软件可以怎样建立 我们建造应用系统的时候，需要大量的了解和研究， 才能接触到问题的本质
把分析限制在问题域词汇的那部分类 保持分析模型是一个对系统结构和行为 的精确和简单陈述
-28-
经验法则-1