回顾

什么是分析和设计? 分析强调的是对问题的理解，而不是如何解决问题。 设计强调的是给出一个有效的软件实现方案以实现用户的需求。 作正确的事情(Do the right thing) 设计强调的是给出一个有效的软件实现方案以实现用户的需求。 把事情作正确(Do the thing right) 为什么要先分析，然后设计? 为什么软件开发人员经常会将设计和分析混在一起？ 分析和设计在软件工程的领域中成了鸡和蛋的问题。 从比较学究的角度考虑，软件开发是一个从需求分析到程序代码的变换过程。 原因： 急于展示自己的技术水准 不知道如何使用分析语言 没有掌握在适当的抽象层次上思考的技巧 “你讲的很好，但是我一点都没有听懂。”客气而刻薄的用户。

面向对象和面向功能(结构化)分析/设计 图书馆信息系统 O-O A&D Structured A&D 系统 书目 管理员 书 图书馆 从对象和概念的角度来分解系统 Structured A&D 从功能和过程的角度来分解系统 系统 软件工程将软件开发分解为各个不同的阶段，每个阶段就像是一座大桥的桥墩。 部分的开发方法就是建造桥墩的不同的方法。 面向对象和面向功能（结构化）分析设计经常会被拿来对比，似乎他们是一对反义词。实际上，在所有的软件开发方法中，他们可能是最接近的，一不小心就会搞混的。 书目 管理员 书 图书馆 借还图书 购置图书 报表

需要演化的系统 软件演化的巨大代价

迭代式开发 瀑布生命周期 迭代式的生命周期 在瀑布生命周期过程中，试图在编程之前定义几乎所有的需求，以及明确详尽的时间表。 通过多次的迭代获得周期性的反馈，以这些反馈为驱动力，对系统进行不断的扩展和精化。 迭代式开发将软件开发过程分解为一系列小的，固定周期的(比如，4个星期)的小项目，每个小项目称为一个迭代。 传统的瀑布模型究竟遇到什么问题了？我们为什么需要迭代式的开发 软件的变更率可达50% 瀑布式声明周期：试图引进一种简单有序的开发过程，建立一种可以依赖的次序，事实证明这不可行。 瀑布模型在现在看来几乎已经成为了一个贬义词，但是，实际上在理论上这个一个简单漂亮，容易理解和管理的模型，这也是为什么现在还有这么多的组织在实际上使用瀑布模型。 迭代式是一种相对复杂的生命周期

敏捷宣言 个体和交流(Individuals and interactions) 工作的软件(Working software) 与客户协作(Customer collaboration) 积极响应变更(Responding to change) 过程和工具(processes and tools) 完善的文档(comprehensive documentation ) 合同谈判(contract negotiation) 严格履行计划(following a plan)

什么是用例 Two people see a motorcycle in two ways: as the subsystems that make up the bike and as the things a person can do with the bike.

什么是用例 用例是文本形式的情节描述，广泛应用于需求的发现和记录工作中。 示例：处理销售 顾客携带所购商品到达收银台。收银员使用POS系统记录每件商品。系统连续显示累计信息，并逐行显示细目。顾客确认支付方式，并实施支付。系统对支付信息进行验证和记录。系统更新库存信息。顾客从系统得到购物小票，然后携带商品离开。

编写用例的准则 以无用户界面约束的风格编写用例 编写简洁的用例 采用参与者的视角 保持黑盒风格

定义：什么是领域模型 领域模型(Domain Model)是对领域内概念类的可视化表示。 为什么要创建领域模型 提高模型的抽象层次，减少我们的思维和软件模型之间的表示差距。同时促进对领域问题的理解 领域模型也称为概念模型、领域对象模型、分析对象模型、可视化字典。 通过UML表示法，领域模型被描述为一组没有定义操作的类图，提供了概念透视图。他可以展示： 领域对象或概念类 概念类之间的关联 概念类的属性

创建领域模型的准则 领域模型不是软件对象的模型 领域模型不是数据模型 恰当的属性 在领域模型中，不会有窗口或数据表之类的对象，也不会有职责或方法 领域模型不是数据模型 数据模型是针对信息系统的模型，用于表示存储于某处的持久性数据。 恰当的属性 领域模型中的属性应该是基本数据类型(Data Type),比如Boolean,String等（值对象）。

基于职责设计对象 系统事件： 对于用例的一个特定的场景，系统顺序图用于表示外部参与者产生的事件，及其发生的顺序。 外部输入的，驱动系统的事件称为系统事件。 外界通过系统事件对系统进行交互，在这个意义上，系统顺序图是以一个黑盒方式来描述系统。 对于用例的一个特定的场景，系统顺序图用于表示外部参与者产生的事件，及其发生的顺序。

系统顺序图的组成

系统事件

用例实现

三个主要的层次 表示层 数据/技术服务层 业务逻辑层 用于处理用户和软件系统之间的交互。 处理那些需要持久化的数据和操作这些数据的事务。 随着对分层理解的深入，一些诸如日志、审计和安全的处理也归入了这一层。 业务逻辑层 表示领域中的基本概念和他们之间的关系 领域逻辑相对而言是最重要的，也是比较稳定的。 不要将领域逻辑和表示层、数据/技术服务层混淆。

准则：模型-视图分离原则 不要将非UI对象直接与UI对象连接或耦合。 不要在UI对象方法中加入应用逻辑。

UML交互图 顺序图 通信图

顺序图的示例 public class A{ private B myB = new B(); public void doOne(){ myB.doTwo(); myB.doThree(); }

通信图的示例 public class A{ private B myB = new B(); public void doOne(){ myB.doTwo(); myB.doThree(); }

类图

GRASP:基于职责设计对象 高内聚 低耦合 信息专家 控制器 创建者 多态 纯虚构 间接性 防止变异

测试驱动的开发与重构 测试驱动的开发 重构 什么是测试驱动的开发 为什么要进行测试驱动的开发 如何进行测试驱动的开发 如何设计易于测试的程序 软件的演化 什么是重构 为什么要重构

其他内容 插件结构的应用程序框架 Persistence的基本概念

考试题型 按内容分类 课本：70% 论述：10% 拓展：20% 按题型分类 选择题 是非题 问答题 论述题

课程目标 程序的乐趣