halo~我是bay_Tong桐小白
本文内容是桐小白个人对所学知识进行的总结和分享，知识点会不定期进行编辑更新和完善，了解最近更新内容可参看更新日志，欢迎各位大神留言、指点

【更新日志】

最近更新：

• 暂无编辑记录，持续更新中……

面向对象分析概述

问题域与系统责任

• 问题域：在软件工程中，问题域是指被开发系统的应用领域，即在客观世界中由该系统处理的业务范围
• 系统责任：所开发的软件系统应该具备的职能

面向对象分析（OOA）

强调运用面向对象方法，对问题域和系统责任进行分析和理解，找出描述问题和系统责任所需要的对象，定义对象的属性、操作以及对象之间的关系，建立一个符合问题域、满足用户功能需求的OOA模型

面向对象分析主要活动

• 与客户进行沟通、了解用户需求、建立需求模型
• 表示问题域中的对象，分析对象承担的职责
• 分析对象与对象间的关系
• 定义对象间的交互

这些活动需要反复迭代，直至模型完成

面向对象分析的模型

• 功能模型（用例模型）：由用例和场景表示，从用户的角度描述系统的功能，是整个后续工作的基础，也是测试与验收的依据
• 静态模型（对象模型）：由类和对象表示，主要包含面向对象系统中的类、接口及对象等软件的基本组成单元以及它们间的联系
• 动态模型（交互模型）：由活动图、顺序图等表示，描述问题涉及的交互作用和时序

系统范围

建立需求模型时首先要确定系统的范围（即一个系统与系统以外各种事物的分界线），找出系统外与系统交互的事物，然后从这些事物与系统交互的角度，通过用例来描述这些事物怎样使用系统，以及系统向他们提供什么服务

进行面向对象系统分析时，需要建立这样的环境图（也可看成是顶层用例图）来确定系统的边界

建立用例模型

用例：简单说即为对系统的功能描述，用例模型奠定了整个系统软件开发的基础

建立用例模型的目的是提取和分析足够的需求信息，用例模型应能表述用户需要什么，而不涉及系统将如何构造和实现特定细节。

创建用例模型的过程：

• 确定参与者——标识系统将支持的不同类型的用户，可以是人、事件或其它系统
• 确定需求用例——参与者需要系统提供的完整功能
• 创建用例图——标识参与者与用例间、用例与用例间的关系

确定参与者

重点放在如何使用系统而不是如何构造系统上，也即进一步明确系统的范围和边界（环境图）。可以从几个方面来识别参与者：

• 人员或组织，即直接使用系统的人员或组织
• 外部系统，所有与本系统交互的外部系统都是参与者。两种常见的情况：
  如果正在开发的系统中使用一个已有系统，则这个已有系统被看成是一个外部系统；
  如果一个大系统在任务分解时被划分成几个子系统，则每个子系统的开发者都把其他子系统看成是外部系统
• 设备，即与系统交互的设备

确定需求用例

从用户的视角看，一个用例是参与者与系统之间的一次典型的交互作用；从系统内部的视角出发，一个用例代表系统执行的一系列动作，动作的执行结果能够被外部的参与者察觉。可以从以下几个方面获取用例：

• 从参与者角度获取。识别参与者的责任是尊者参与者与系统交互理由的良好基础
• 从系统功能的角度获取。完成一项功能的一组动作序列要描述在一个用例中，通常，以用例中的动作为线索能发现其他用例
• 利用场景获取用例。即仅关注具体的业务活动，确定谁是扮演者，具体做了哪些事情，做这些事情的目的是什么，将本质上相同的场景抽象为一个用例

用例规约描述（规格说明）：对用例的完整描述包括用例名称、参与者、前置条件、后置条件、一个主事件流、零到多个备选事件流

• 前置条件：规定在用例中场景开始之前必须为“真”的条件
• 后置条件：规定在用例结束后必须为“真”的条件
• 主事件流：表示正常情况下参与者与系统之间的信息交互及动作序列
• 备选事件流：表示特殊情况或异常情况下的信息交互及动作序列

每个用例均应给出用例的规格说明

以银行ATM转账用例为例，规约描述如下：

创建用例图

用例图是若干个参与者和用例以及它们间的关系构成的图形表示

每个系统通常都有一个总体用例图，若总体用例图过于复杂，则可以创建多个用例图，每个用例图关注系统的某一方面，事实上用例建模是围绕参与者创建，且往往不是一次就能完成的，需要多次迭代、逐步完善

需要注意的是：

• 参与者和用例之间的连线并不表示信息流，仅代表用例同用例及参与者之间的相互联系
• 参与者和用例间的箭头表示在这一关系中哪一方是交互的主动发起者，箭头所指方式交互的被动接受者

用例图建好后，下一步应建立初步的类图，之后对于关键的用例需要建立顺序图、活动图等

建立对象模型（更新中……）

在系统分析阶段，对象建模的主要任务是建立问题域的概念模型，即描述现实世界中问题域类与对象以及他们之间的关系

复杂问题（大型系统）的对象模型应由5个层次组成：主题层（也称范畴层）、类-对象层、结构层、属性层、服务层，与此对应的5项主要活动：划分主题、确定类与对象、确定结构、确定属性、确定服务

这5项活动的抽象层次不同，在实际面向对象分析时，总体上是按照自顶向下的顺序进行的，但不需要严格遵守这种原则，也无需彻底完成一项工作后再开始另外一项工作

建立动态模型（更新中……）

动态模型描述与操作时间和顺序有关的系统特征、影响更改的事件、事件的序列、事件的环境以及事件的组织

在UML中动态模型的描述工具有顺序图、协作图、活动图、状态图等

建立数据模型（更新中……）

数据模型是数据特征的抽象，从抽象层次上描述了系统的静态特征、动态行为和约束条件，为数据库系统的信息表示与操作提供一个抽象的框架

数据模型所描述的内容有三部分，分别是数据结构、数据操作和数据约束

• 数据结构：数据模型中的数据结构主要描述数据的类型、内容、性质以及数据间的联系等。数据结构是数据模型的基础，数据操作和约束都建立在数据结构上。不同的数据结构具有不同的操作和约束
• 数据操作：数据模型中数据操作主要描述在相应的数据结构上的操作类型和操作方式
• 数据模型中的数据约束主要描述数据结构内数据间的语法、词义联系、它们之间的制约和依存关系，以及数据动态变化的规则，以保证数据的正确、有效和相容

由类图可自动生成数据库表

持续更新中……
我是桐小白，一个摸爬滚打的计算机小白