UML于模式应用 摘抄(1)

------------------=======================================------------------
    说明: 您所看到下面这些文字是我在看<< UML和模式应用>> 第二版 (<<Applying
 UML and Patterns >> ) 时摘抄的一些内容. 称不上是学习笔记........
------------------=======================================------------------
用面向对象的思想看待问题,用面向对象的思想解决问题.

模式是已命名的问题--解决方案公式, 是已经经过系统整理的经典设计原则.

OOA/D 中的最关键,最基本的能力是熟练地为软件组件分配职责.

分析 强调的是对问题和需求的调查研究, 而不是解决方案.
设计 强调的是满足学期的概念上的解决方案, 而不是其实现.
分析和设计可以被概括为: 做正确的事(分析)和正确的做事(设计).
在面向对象分析过程中, 强调的事在问题领域内发现和描述对象或概念.
在面向对象设计过程中, 强调的事定义软件对象和这些软件对象如何协作来满足需
        求.

用例不是面向对象的工件, 而只是情节的简单文字记录.

软件开发过程描述了软件构造, 部署或者还有维护的一种方法.
统一过程是已经成为一种流行的构造面向对象系统的软件开发过程.
Rational统一过程或简称RUP是对统一过程的详细精化.并且已经被广泛采纳.
最重要的UP思想:迭代开发, 开发被组织成一系列固定的短期小项目,称为迭代;每次
        迭代都产生经过测试的,经过集成的和可执行的系统. 每次迭代都有自己的需求
       分析, 设计, 实现和测试活动.
一个UP项目跨越4歌主要的阶段, 对其工作和迭代进行组织:
       1. 初始阶段 ---- 大体上的构想, 业务案例, 范围, 模糊评估.
       2. 细化阶段 ---- 已精化的构想, 核心构架的迭代实现, 高风险的解决, 大多数需求
                  和范围的识别, 更为现实的评估.
       3. 构造阶段 ---- 迭代实现遗留下来的风险较低和比较容易的元素, 准备部署.
       4. 移交阶段 ---- beta测试, 部署.

P₂₅
初始阶段:
       预见项目的范围.构想和业务案例.
初始阶段要解决的问题:
       项目相关人员是否就项目的构想达成基本的一致. 项目是否值得继续进行和认真
                的研究.
初始阶段的意图:
       为项目的目标简历一些初始的一般的构想,确定项目是否可行. 并决定是否值得进
                入细化阶段的认真研究.

P₂₈
需求就是项目必须提供的能力和必须遵从的条件.
需求的最根本的挑战在于: 寻找. 交流并记住(通常是指记录)什么是真正的需要的, 并
       能够清楚地向用户和开发团队的成员讲解.

需求类型            FURPS+
       功能性(Functional): 特性, 能力, 安全性.
       可用性(Usability): 人性化因素, 帮助文档.
       可靠性(Reliability): 故障周期, 可恢复性, 可预测性.
       性能(Perforance): 响应时间, 吞吐量, 准确性, 有效性, 资源利用率.
       可支持性(Supportability): 适用性, 可维护性, 国际化, 可配置性.
       + 是指一些辅助性的和次要的因素.比如: 实现, 接口, 操作, 包装, 授权

P₃₁
本质上, 用例模型是所有用例的集合. 是系统功能和环境的模型.
用例可以为项目人员体构一种简单而易懂的机制了解目标和系统需求.
用例在本质上是通过写出多种使用系统的情节来发现和记录功能性需求.
用例机制的优越性在于: 能够根据需要增减复杂的程度和形式化的程度.

参与者(actor) 是具有行为能力的事物, 可以是一个人, 计算机系统或组织.
场景(scenario) 是参与者和被讨论系统之间的一系列特定的活动和交互. 通常被称为
       "用例的实例", 场景是使用系统的一个特定情节或用例的一条执行路径.
一个用例就是描述参与者使用系统来达成目标的时候一组相关的成功或失败场景的
        集合.
用例分析的关键是专注于"怎样才能使系统为用户提供可观察的数值, 或帮助用户实
        现他们的目标". 而不是仅仅将系统需求用特性和功能的细目清单罗列出来.

Jacobson 在用例的概念用想要表达的主要思想是: 在需求缝隙中专注于考虑系统怎
        样才能增加价值和实现目标.

P₃₃
用例就是需求
用例的主要思想是: 为功能性需求写出用例, 从而降低老式的详尽的特性列表的重要
        性或减少这种列表的使用.
用例是文本文档而不是图表. 用例建模的主要工作是写文本而不是画图.

黑箱用例是描述系统具有哪些职责. What to do ?

简洁用例: 简明扼要的一段概括. 通常用在主要成功场景.
临时用例: 非正式的段落格式. 用几段话来说明几个不同的场景.
详述用例: 最详细的描述格式. 所有步骤和其中的变化都被详细写出,这种格式还包含
        辅助部分.
书写详细用例的格式模版(单列)   (略)

关于格式:
       双列格式: 这种格式强调参与者和系统之间进行交互.
       双列格式的好处能使对话过程更加清晰和形象
       单列格式则更紧凑, 更易用.
       建议使用单列格式.

用例应该包含什么 ?
       用例应该包含满足了所有的项目相关人员兴趣的内容.

要将最重要的元素放在一开始(主要成功场景之前)来读.而将一些不重要的仅有"标题"
        的材料放在用例的末尾.