Object-Oriented Analysis and Design Using UML 翻译与学习 （十四）

回顾软件开发步骤

目标

完成这个章节（模块），你可以：

1、解释面向对象开发（OOSD）的最好的实践

2、描述多种通用的方法论的特性

3、选择一个最适合你的软件的方法论

4、开发一个迭代计划

回顾软件方法论

浏览方法论的最佳实践

1、用例驱动

2、系统质量驱动

3、以架构为中心（方法论）

4、迭代模式和增量模式

5、以模型为基础（方法论）

6、设计最佳实践

//2017年3月13日22:57:00 开个好头

用例驱动

“A  software  system  is  brought  into  existence  to  serve  its  users.” (Jacobson USDP page 5)

一个软件系统被带到存在，是为了服务它的用户。                 ----Jacobson USDP 5页

1、所有的软件都有用户（人或机器）

2、用户使用软件用来进行活动或完成目标（用例）

3、一个软件开发方法论支持对用例有利的软件的创建

4、用例驱动系统的设计

系统质量驱动

1、系统质量是对系统的需求，是非功能性的或者与服务质量相关。

2、例子包括;

    2.1性能--如响应性和延迟

    2.2可靠性--组件失败后的平静性

    2.3规模--支持额外的负载（如更多用户）的能力

3、系统品质驱动软件的架构

以架构为中心（的方法论）

“Architecture is all about capturing the strategic aspects of the high-level structure of a system.”

                                                                                                     (Arlow and Neustadt page 18)

架构是一切关于捕获系统的高级别结构的策略方面。

策略方面是：

1、系统质量驱动的架构上的工件和形式

2、用例必须和架构适应

高级别结构是：

1、阶层，如客户端，应用和后端

2、阶层组件和它们的通讯协议

3、层，例如应用，平台和硬件

迭代和增量（模式）

“Iterative development focuses on growing the system in small,incremental, and planned steps.”

                                                                                                               (Knoernschild page 77)

迭代模式开发关注系统在小，增量和计划的步骤上的成长。

                                                                                          ----Knoernschild 77页

1、每一个包括一个完整的OOSD(面向对象)生命周期，包括分析，设计，实现和测试

2、模型和软件在多个迭代上被逐渐建立的

3、维护是另一个简单的迭代（或一系列迭代）

以模型为基础（方法论）

在软件工程中，模型是在所有利益相关者的沟通方式。

类型：

1、文字文档

2、UML图

3、原型

目标：

1、沟通

2、解决问题

3、概念证明

设计最佳实践

理解和应用设计级别最佳实践可以改进软件解决方案的灵活性和延展性。

最佳实践包括以下：

1、设计原则

2、软件模式

3、重构

4、Sun 蓝图(Sun Blueprints,http://www.sun.com/blueprints/)

//2017年3月14日22:40:15 尽快搞完

调查多种方法论

这个章节描述一下方法论

1、瀑布（模型）

2、统一软件开发过程（USDP或者UP）

3、Rational统一过程（RUP）

4、并列争夺

5、极限编程（XP；敏捷开发）

瀑布

1、瀑布使用单一片段，在这其中工作流运行线性模式

2、这个方法论不支持迭代开发

3、这个方法论最适合一开始需求都明确并且不太可能会变的工程

4、一些政府合同可能要求（使用）这个方法论

5、一些咨询公司使用这个方法论，这个方法的每一个工作流签一个固定价格的投标价的合同

统一软件开发过程

统一软件开发过程（USDP）是被 Booch,Jacobson和Rumbaugh创建的Rational方法论的“开源”版本。

它也被叫做统一过程。

四个阶段

1、成立--创建一个软件版本

2、精心设计--多数用例被定义，以用来增加系统架构

3、创建--软件被建立

4、变迁--软件从测试版升级成产品

每个阶段可能有多个迭代

Rational统一开发

RUP是被 Booch,Jacobson和Rumbaugh创建的Rational方法论的商业版本。

1、RUP是具有Rational工具集合的UP

2、这些工具贯穿工程的生命周期，并且管理阶段，工作流和工件

//2017年3月15日21:37:40 每天攒一点

并列争夺

并列争夺是一个迭代和增量开发框架，经常被用来连接机敏软件开发。

主要特点是：

1、每个冲刺（Sprint）产生一个软件的可交付的增量

2、每个冲刺典型的是15到30天

3、一个特点的子集是每次冲刺的开始将产品的积压的事（backlog）作为冲刺的积压的事（backlog）

4、冲刺的积压的事（backlog）中的需求是随着冲刺开发的

5、在日并列争夺（Scrum）中冲刺是每24小时重新查看一次

6、并列争夺（Scrum）框架需要以团队为核心的责任感

极限编程

“XP nominates coding as the key activity throughout a software project.”

                                                                     (Erich Gamma, forward to Beck’s XP book, page xiii)

极限编程将代码在整个软件工程中任命为重要活动。

                                                                 ----（Rich Gamma, forward to Beck’s XP book, 第8页）

有一些重要观点：

1、成对编程--如果代码查看是好的，那么代码查看应该一直进行

2、测试--如果测试是好的，那么测试应该一直进行

3、重构--如果设计是好的，那么让它成为每个人的日常事情

4、简单--如果简单是好的，那么总是让系统保持简单

选择一个方法论

有许多重要因素可以作为选择方法论的引导。

1、公司文化--过程为中心和产品为中心

2、组建团队--经验少的开发者也许需要更多的结构，团队需要明显的工作角色

3、工程大小--一个大的工程需要更多的文档（利益相关者之间的交流）

4、需求的稳定性--需求有多频繁变化

选择瀑布（模型）

什么时候去用：

1、有明确的角色的大团队

2、当工程风险不是很大，选择瀑布模型

问题：

1、对需求变化没有弹性

2、文档会很多

选择统一开发

什么时候去用：

1、公司文化是以过程为中心

2、团队中的成员有灵活的工作角色

3、中到大规模的工程

4、需求被允许变化

问题：

1、过程和文档太多

2、对小工程来说是牛刀

选择Rational统一开发

什么时候去用：

1、和统一开发愿意一样

2、你的公司拥有Rational的工具集

问题：

1、和统一开发愿意一样

2、工具集学习曲线（困难）

3、工具将团队限制于过程

选择并列争夺（Scrum）

什么时候去用：

1、具有需求频繁变化的属性

2、当你选择每隔30天发布软件的工作增量

问题：

1、需要一个坚定的团队

2、每个冲刺（Sprint）的主要焦点在功能性需求。非功能性需求有可能不被充分考虑。

选择极限编程

什么时候去用：

1、公司文化允许实验

2、拥有灵活的工作空间小团队

3、需要同没有经验的一样多的有经验的开发者

4、需求频繁变化

问题：

1、文档少

工程风险和限制

工程风险和限制是经常被工程架构管理。

工程风险和限制应该在开发过程的初始阶段被评估。

工程限制

工程开发限制经常与系统运行时的限制的非功能性需求发生困扰。

典型的工程限制是：

1、工程根据一个明确的平台开发

2、工程需要明确的技术

3、工程需要一个明确截止日期

4、系统明确的与内部系统交互

//2017年3月18日23:57:26 早睡早起

工程风险

每个工程都会有风险等级。

对一个工程来说，任何一个情形和因素可以导致不成功的结果都是风险。

每个限制通常都会影响几个风险因素，一些产生积极影响，一些产生消极影响。

5个主要的风险是：

1、政治

2、技术

3、资源

4、技巧

5、需求

产生一个迭代计划

1、迭代计划主要应用于迭代和增量开发过程

2、这些计划决定软件组件被开发的顺序

3、如果你使用一个用例驱动的方法论或者相似的方法论，基于优先级，风险，以来来考虑每个用例

4、迭代计划可以在工程的前期详细的被形成档案并且被僵硬的执行，或者松散的计划，随着工程进度对修改开放

给用例划分优先级

用例，用户故事，高等级功能需求和特性通常按优先级分类。

一个常用的优化模型是MuSCoW优化技术，这些优先级有：

1、必须有（Must）

2、应该有（should），如果都有可能

3、可以有（could），不影响其他事情

4、这次不会用（won't），但想未来包含

评定用例风险

在风险的基础上考虑用例。这些风险因素应该包含：

1、用例的复杂性

2、对外部设备和系统的接口

架构的重要性

用例是架构上重要的，如果它们有工程级重要非功能性需求。

这些需求要求架构师选择一个能满足非功能性需求的架构。

架构基线

一个架构基线是系统基线的子集：

1、在工程的前期用代码实现

2、做测试以便证明选择的架构满足非功能性需求

基线代码应该包括架构上重要的用例。

测试架构上重要的用例的过程叫做“架构上概念证明”。

在统一开发过程中，架构基线必须在最后精心装饰阶段完成。

时间箱

每一个迭代在迭代和增量开发过程中都有一个迭代固定时间的期限。

主要特性：

1、迭代按计划完成

2、未完成的用例重新计划到下一迭代

你应该避免连续不停重新计划一个明确的用例。

80/20Rule

在一个迭代和增量开发过程中，在进入下一步前，你不用完全理解。

80/20可以被应用，例如：

1、使用20%的努力，你可以理解80%细节

2、使用20%的努力，你的说明可以完成80%精确

缺失的细节和精确会在接下来的迭代中发现，作为一小部分努力。

这个原则起效，仅当你建的软件有灵活性。

产生一个迭代计划

迭代计划包含你准备在每个迭代中开发的用例。

这个重要的评判标准包括以下条目：

1、用例优先级

2、用例风险

3、架构上的重要性

4、开发一个用例的预估时间

5、对其它用例的依赖

用例表单和补充说明文档包含这信息

重要评估的例子

迭代计划例子

这是一个迭代计划的演示

总结

回归这章：

1、迭代和增量开发

2、架构为中心开发

3、工程风险和限制性

4、基于用例开发迭代计划

    4.1优先级

    4.2风险

    4.3架构上的重要性

5、没有一个方法论完全适合每一个组织和工程。你通过改编已存在的方法论去适应你的需求和跟随最佳实践

可以创建你自己的方法论。

//2017年3月19日16:22:05 又完成了一个章节，good

//另外，鄙人从事软件开发，英语过6级，求兼职
//联系我，邮箱：[e-mail]

交个朋友吧