期中复习

OOAD的定义

OOAD——从对象的角度考虑问题领域和概念上的解决方案
OOA——定义了问题领域中的概念，这些概念的关系和属性，在OOA中，强调的是在问题领域内发现和描述对象（或概念）
OOD——定义了该问题的逻辑上的软件解决方案，这个方案是基于OOA阶段的findings被定义的，包含描述了逻辑软件解决方案的类方法，在这个阶段，会发现新概念，新属性，或者这些概念间的关系，它们可以迭代反射回OOA阶段，在面向对象设计的过程中，强调的是定义软件对象以及他们如何协作以实现需求

OOA阶段制品包括：用例，领域模型，设想，业务规则，补充性说明，词汇表
OOD阶段制品包括：静态：类图，包图；动态：顺序图，通信图

OOA、OOD和OOP之间的关系

OOA需要领域知识和OOA专业知识

• 因此，既需要领域专家，也需要面向对象分析专家
• 领域专家对有关问题领域的决策总是正确的
• 如果你幸运的话，这两位专家是同一个人

OOA标识

• 问题领域的概念
• 这些概念之间的关系
• 这些概念的属性

OOD为问题定义了一个逻辑软件解决方案

• 基于OOA阶段的结果定义解决方案
• 它包括代表逻辑软件解决方案的类方法的定义
• 在设计阶段经常会发现新的概念、属性或概念之间的关系。

它们迭代地反映回分析阶段

统一过程up

不仅仅是一个简单的软件过程，而是一个通用的过程框架，可用于不同类型的应用系统、各种不同的应用领域、各种不同类型的组织、各种不同功能和规模的项目。它是基于构件（Component-based）的，即所构造的软件系统是由软件构件通过明确定义的接口相互链接所建造起来的。并且它使用统一建模语言（Unified Modeling Language，UML）来制定系统的所有蓝图。

统一软件过程的特点：用例驱动、以构架为中心、迭代和增量的软件过程框架。

迭代和敏捷建模

迭代开发是UP和大多数其他现代方法中的实践关键；开发被组织成为一系列固定的短期小项目，称为迭代；每个迭代具有各自的需求分析、设计、实现和测试活动。
敏捷建模即使避开繁琐复杂的过程，用最简单的工具进行产品的设计和建模。应用时间定量的进化式开发，使用自适应计划，提倡增量交付，并包含其他提倡敏捷性的价值和时间；采用敏捷方法并不意味着不进行任何建模，这是错误的理解；建模和模型的目的主要是用于理解和沟通，而不是构建文档；不要对所有或大多数软件设计建模或者应用UML。

区分迭代开发和敏捷开发：https://zhuanlan.zhihu.com/p/142731328

需求

需求就是系统（更广义的说法是项目）必须提供的能力和必须遵从的条件

用例与功能列表

用例是一组相关的成功和失败场景的集合，用来描述参与者如何使用系统来实现其目标。用例是文本故事，更简单，更为我们熟知，更加以用户为中心，是发现和定义功能性需求的中心机制，能够根据需要对复杂程度和形式化程度进行增减调节。

功能列表是一种描述系统功能的传统方法，不适用于面向用户的软件，难以维护，

用例比老式的功能列表更加关注以用户为中心，老式的功能列表难以维护；在文档中加入简洁的高阶特性列表有助于概括系统的功能性，是用例的总结。

需求的类型，FURPS+指：

• 功能性(Functional)：特性、功能、安全性。
• 可用性(Usability)：人性化因素、帮助、文档。
• 可靠性(Reliability)：故障频率、可恢复性、可预测性。
• 性能(Performance):响应时间、吞吐量、准确性、有效性、资源利用率。
• 可支持性(Supportability)：适应性、可维护性、国际化、可配置性。

“FURPS+”中”+”是指一些辅助性的和次要的因素，比如：

• 实现(Implementation):资源限制、语言和工具、硬件等。
• 接口 （Interface）:强加于外部系统接口之上的约束。
• 操作（Operation）：对其操作设置的系统管理。
• 包装（Packaging）：例如物理的包装盒。
• 授权（Legal）：许可证或其他方式。

CURD

增删改查： create, retrieve, update, delete

UML

统一建模语言是描述、构造和文档化系统制品的可视化语言；是面向对象的概念建模系统的标 系统；不是一种方法，不是一个过程。

用例

用例是一组相关的成功和失败场景集合，用来描述参与者如何使用系统实现其目标。

用例的三种形式

• 摘要
  简洁的一段式概要，主要用于主成功场景。
• 非正式
  非正式的段落格式。用几个段落覆盖不同场景。
• 详述
  详细编写所有步骤及各种变化，同时具有补充部分。

如何发现用例

1. 选择系统边界
2. 寻找主要参与者和目标
3. 定义用例

如何判断用例的好坏

• The Boss Test 老板测试
• The EBP Test EBP测试
• The Size Test 规模测试

EBP 基本业务过程

EBP即基本业务过程，是源于业务过程工程领域的术语；一个人于某时刻在一个地点所执行的任务，用以响应业务事件。该任务能够增加可量化的业务价值，并且以持久状态留下数据

领域模型

如何创建领域模型：

1. (可以通过catalog list方式)寻找概念类
2. 绘制UML类图中的类
3. 添加关联和属性

绘制 SSD 的好处

系统顺序图（SSD）是为阐述与所讨论系统相关的输入和输出事件而快速、简单地创建的制品。它们是操作契约和（最重要的）对象设计的输入。SSD

1. 绘制系统时序图的好处：
   SSD 使事件变得更加具体和明确；
2. 绘制的动机
   基本上，软件系统要对以下三种事件进行响应：1）来自于参与者（人或
   计算机）的外部事件，2）时间事件, 3）错误或异常（通常源于外部）。因此，需要准确地知道，什么是外部输入的事件，即系统事件。这些事件是系统行为分析的重要部分。你可能对如何识别进入软件对象的消息非常熟悉。而这种概念同样适用于更高阶的构件， 包括把整个系统（抽象地）视为一个事物或对象。在对软件应用将如何工作进行详细设计之前，最好将其行为作为“黑盒”来调査和定义。 系统行为（system behavior）描述的是系统做什么，而无需解释如何做。这种描述的一部分就是系统顺序图。

SSD与用例之间的关系

SSD展示了用例中一个场景的系统时间，因此他是从对用例的考察中产生的。

操作契约

1. 操作契约使用前置和后置条件的形式，描述领域模型里对象的详细变化，
   并作为系统操作的结果。
2. 操作契约可以视为 UP 用例模型的一部分，因为它对用例指出的系统操作
   的效用提供了更详细的分析。
3. 操作契约有哪些部分
   操作：操作的名称和参数
   交叉引用：会发生此操作的用例
   前置条件：执行操作之前，对系统或领域模型对象状态的重要假设。
   后置条件：最重要的部分。完成操作后，领域模型对象的状态。
4. 系统操作是作为黑盒构件的系统在其公共接口中提供的操作。系统操作
   可以在绘制 SSD 草图时确定。
5. 后置条件描述了领域模型内对象状态变化。领域模型状态变化包括创建
   实例、形成或消除关联以及改变属性。后置条件有三种类型创建或删除实例、形成或消除关联、属性值的变化。
6. 在 UP 中，用例是项目需求的主要知识库。用例可以为设计提供大部分或
   全部所需细节。这中情况下，契约就没什么用处。
7. 如何创建和编写契约
   从 SSD 图中确定系统操作，如果系统操作复杂，其结果可能不明显，或者在用例中不清楚，则可以为其构造契约使用以下几种类表来描述后置条件：
   1. 创建或删除实例
   2. 属性值的变化
   3. 形成或消除关联（UML 连接）