《UML和模式应用》读书笔记(一)

第一部分 绪论

面向对象分析设计

1.2学习目标

在OO开发中,至关重要的能力是熟练地为软件对象分配职责;

1.3什么是分析和设计

分析(analysis)强调的是对问题和需求的调查研究,而不是解决方案;
设计(design)强调的是满足需求的概念上的解决方案(在软件方面和硬件方面),而不是其实现。

有益的分析和设计可以概括为:做正确的事(分析)和正确地做事(设计)。

1.4什么是面向对象分析和设计

面向对象分析,强调的是在问题领域内发现和描述对象(或概念)。
面向对象设计,强调的是定义软件对象以及他们如何协作以实现需求。

1.5简单示例

定义用例

需求分析可能包括人们如何使用应用的情节或场景,这些情节或场景可以被编写成用例(use case)。

分配对象职责和绘制交互图

顺序图是描述协作的常见表示法。他展示出软件对象之间的消息流,和由为消息引起的方法调用

定义领域模型

面向对象分析关注从对象的角度创建领域描述,面向对象分析需要鉴别重要的概念、属性和关联。
面向对象分析的结果可以表示为领域模型,在领域模型中展示重要的领域概念或对象。(也称概念对象模型)。

定义设计类图

设计类图有效的表示类定义的静态视图。这样可以描述类的属性和方法。

与领域模型表示的是真实世界的类,设计类图表示的是软件类。

1.6什么是UML

  • UML作为草图——非正式的、不完整的图
  • UML作为蓝图——相对详细的设计图
  • UML作为编程语言——用UML完成软件系统可执行规格说明。
    敏捷建模强调了UML作为草图的方式。对时间投入具有高回

迭代、进化和敏捷

2.2什么是迭代和进化式开发

迭代开发:

迭代开发(iterative development)是UP和大多数其他现代方法中的关键实践。在这种生命周期方法中,开发被组织成一系列固定的短期(如三个星期)小项目,称为迭代(iteration),每次迭代都产生经过测试、集成并可执行的局部系统。每次迭代都具有各自的需求分析、设计、实现和测试活动。

迭代开发的优点:

  • 减少项目失败可能性,提高生产率,降低缺陷率。
  • 在早期缓解高风险(技术、需求、目标、可用性等等)。
  • 早期可见的进展。
  • 早期反馈、用户参与和调整,会产生更接近涉众真实需求的精化系统。
  • 可控复杂性;团队不会被“分析瘫痪”或长期且复杂的步骤所淹没。
  • 一次迭代中的经验可以被系统地用于改进开发过程本身,并如此反复进行下去。

2.3什么是瀑布生命周期

反馈改写的必要性

在复杂、变更系统中(如大多数软件项目),反馈和调整是成功的关键要素。

2.4如何进行迭代和进化式分析和设计

1)在第1次迭代之前,召开第一个时间定量的需求工作会议,例如确切地定义为两天时间,业务和开发人员(包括首席架构师)需要出席。
  • 在第一天上午,进行高阶需求分析,例如仅仅确定用例和特性的名称,以及关键的非功能性需求。这种分析不可能是完美的。
  • 通过咨询首席架构师和业务人员,从高阶列表中选择10%列表项,这些项目具备以下三种性质:1,具有重要的架构意义;2,具有高业务价值;3,具有高风险。
  • 在剩下的一天半内,对这三个用例的功能和非功能性需求进行详细的分析。完成这一过程后,对10%进行了深入分析,90%进行了高阶分析。
2)在第1次迭代之前,召开迭代计划会议,选择上述三种用例的子集,在特定时间内(例如,四周的时间定量迭代)进行设计、构造和测试。
3)在三到四周内完成第1次迭代(选择时间定量,并严格遵守时间):
  • 在开始的两天内,开发者和其他成员分组进行建模和设计工作,在首席架构师的带领和指导下,于“公共作战室”的众多白板上,画出UML的草图(及其他的模型)。
  • 然后,开发者摘掉其“建模帽子”并戴上“编程帽子”,开始编程、测试和集成工作并且剩余的时间均用于完成这项工作。
  • 进行大量的测试,包括单元测试、验收测试、负载测试和可用性测试等。
  • 在结束前的一周,检查是否能够完成初始的迭代目标;如果不能,则缩小迭代的范围,将次要目标置回任务列表中。
  • 在最后一周的星期二,冻结代码。必须检入、集成和测试所有代码,以建立迭代的基线。
  • 在星期三的上午,向外部涉众演示此局部系统,展示早期可视进展,同时要求反馈。
4)在第1次迭代即将结束时(如最后一周的星期三和星期四),召开第二次需求工作会,对上一次会议的所有材料进行复查和精化,然后选择具有重要架构意义和高业务价值的另外10%到15%的用例,用一到两天对其进行详细分析。
5)于周五上午,举行下一迭代的迭代计划会议。
6)以相同步骤进行第2次迭代。
7)反复进行四次迭代和五次需求工作会,这样在第4次迭代结束时,可能已经详细记录了大约80%-90%的需求。
8)我们大概推进了整个项目过程的20%。此时,可以估计这些精化的、高质量的需求所需工作量和时间。因为具有依据现实得出的调查、反馈结论并进行了早期编程和测试,因此估计能够做什么和需要多长时间的结果会更为可靠。
9)此后,一般不需要再召开需求工作会;需求已经稳定了(尽管需求永远不会被冻结)。接下来是一系列为期三周的迭代,在最后一个周五召开的迭代计划会上选择适宜的下一步工作,每次迭代都要反复询问:“就我们现在所知,下一个三周应该完成的、最关键的技术和业务特性是什么?”
 利用这种方式,经过早期探索式开发的几次迭代之后,团队将能够更准确地回答“什么、多少、何时”。

2.6什么是敏捷方法及其观点?

敏捷开发方法通常应时间定量的迭代和进化式开发,使用自适应计划,提倡增量交付并包含其他提倡敏捷性的价值和实践。并没有精确定义。

2.7什么是敏捷建模?

建模(构建UML草图……)的目的主要是为理解,而非文档。

2.10什么是UP阶段?

  • 初始:大体上的构想、业务案例、范围和模糊评估
  • 细化:已精华的构想、核心构架的迭代实现、高风险的解决、确定大多数需求和范围以及进行更为实际评估
  • 构造:对遗留下来的风险较低和比较简单的元素进行迭代实现,准备部署。
  • 移交:进行beta测试和部署。

2.11什么是UP科目?

UP描述了科目中的活动,例如编写用例。
科目:是在一个主题域中的一组活动(及相关制品),eg.需求分析中的活动
制品:是对所有工作产品的统称(eg.代码,文档,图,模型等)

相关推荐
本书论述运用UML(统一建模语言)和模式进行对象建模的方法和技巧,重点讨论了如何使用面向对象的分析和设计技术来建造一个健壮的和易于维护的系统。 全书叙述清晰、图文并茂、实例丰富,是一部来自于大量经验的总结性论著,适合在学习和工作中需要运用面向对象技术的高校师生或工程技术人员使用,特别适用于对面向对象技术有一定了解但希望进一步提高开发水平的应用开发人员。 目录 第一部分结论 第1章 面向对象的分析与设计 1.1 运用UML模式面向对象的分析与设计技术 1.2 分配职责 1.3 什么是分析和设计 1.4 什么是面向对象的分析和设计 1.5 类比--组织MicroChaos公司的业务 1.5.1 MicroChaos公司正迅速发展壮大 1.5.2 什么是业务过程 1.5.3 组织中的角色是什么 1.5.4 谁该干什么?他们之间如何协作 1.6 面向对象的分析与设计的例子 1.6.l 定义用况 1.6.2 定义概念模型 1.6.3 定义协作图 1.6.4 定义设计类图 1.6.5 掷骰子游戏例子的总结 1.7 面向对象的与面向功能的分析与设计 1.8 警告:"分析"和"设计"可能引起术语上的"冲突" 1.9 统一建模语言 .第2章 开发过程导论 2.l 导言 2. 1.l 推荐的过程和模型--RPM 2.1.2 讨论范围 2.2 UML和开发过程 2.3 高层步骤 2.4 迭代开发 2.4.1 确定开发周期的时间企 2.4.2 用况和迭代开发周期 2.4.3 划分用况的层次 2.5 计划和细化阶段 2.6 构造阶段--开发周期 2.7 选择制品创建的时机 2.7.1 何时创建概念模型 2.7.2 何时创建扩展用况 第3章 定义模型和制品 3.l 导言 3.2 建模系统 3.3 样例模型 3. 4 制品之间的关系 第二部分 计划和细化阶段 第4章 学习案例:销售点终端 4.1 销售点终端系统 4.2 系统体系结构的层次和学习案例的重点 4. 3 我们的策略:反复学习和反复开发 第5章 理解需求 5.1 导言 5.2 需求 5.3 总体问题陈述 5.4 顾客 5.5 目标 5.6 系统功能 5.6.1 功能的分类 5.6.2 基本功能 5.6.3 处理支付的功能 5.7 系统属性 5.8 需求阶段的其他制品 第6章 用况:对过程的描述 6.1 导言 6.2 活动及其相互间的依赖关系 6.3 用况 6.3.1 高层用况举例:购买商品 6.3.2 扩展用况举例:用现金购买商品 6.3.3 扩展格式的说明 6.4 参与者 6.5 使用用况时的常见错误 6.6 用况的识别 6.7 用况和领域过程 6.8 用况、系统功能和可跟踪性 6.9 用况图 6.10 用况的格式 6.10.1 高层格式 6.10.2 扩展格式 6.11 系统及其边界 6.12 主要、次要和可任选的用况 6.13 基本用况和真实用况 6.13.1 基本用况 6.13.2 真实用况 6.13.3 购买商品的基本用况 6.13.4 购买商品的真实用况 6.14 表示法要点 6.14.l 用况的命名 6.14.2 扩展用况的开始部分 6.14.3 判定点和分支的表示法 6.15 一个开发过程中的用况 6.15. l 计划和细化阶段的步骤 6.15.2 迭代开发周期阶段中的步骤 6.16 销售点终端系统的处理步骤 6.16.l 识别参与者和用况 6.16.2 用高层格式书写用况 6.16.3 绘制系统的用况图 6.16.4 为用况增加关联 6.16.5 书写一部分扩展的基本用况 6.16.6 在必要情况下书写一些真实用况 6.16.7 划分用况的层次 6.17 样例模型 第7章 用况的分类和时间调度 7.1 导言 7.2 将用况调度分配到开发周期中实现 7.2.1 用况和开发周期 7.2.2 用况的分类 7.3 销售点终端应用系统中的用况分类 7.4 "系统启动"用况 7.5 销售点终端应用系统中用况的时间调度 7.5.1 创建复杂用况的多个版本 7.5.2 用况分配 7.6 "购买商品"用况的版本 7.6.1 购买商品一版本1 7.6.2 购买商品一版本2 7.7 小结 第8章 开始进入一个开发周期 第三部分 分析阶段(1) 第9章 建立一个概念模型 9.1 导言 9.2 活动及其相互之间的依赖关系 9.3 概念模型 9.3.1 理解领域词汇 9.3.2 概念模型不是软件设计模型 9.3.3 概念 9.3.4 概念模型和问题分解 9.
©️2020 CSDN 皮肤主题: 编程工作室 设计师:CSDN官方博客 返回首页