[架构之路-201]-《软考-系统分析师》- 关键技术 - 结构化分析方法与面向对象分析（分析与设计的区别、pre架构设计、架构前设计）

目录

前言：

一、分析与设计的区别

二、结构化分析方法

2.1  实体关系图：E - R 图 （名词）

2.2. 数据流图（数据的流动）

(1) 顶层图。

(2) 逐层分解。

2.3. 状态转换图（动作）

2.4 数据字典

三、面向对象分析方法

3.1 用例模型

3.2 分析模型

3.2.1 定义概念类

3.2.2 确定类之间的关系

3.2.3 为类添加职责

3.2.4 建立交互图

3.2.5 分析模型的详细程度问题

---

前言：

结构化分析和面向对象分析，都是一种需求分析的方法和手段，用于把复杂问题分解成简单的问题，把复杂的需求分解成简单的需求，把高层笼统的需求分解成低层细化后的需求。

所谓：需求，就是“what”，是“是什么”？做成“什么样子”，是“目标”，即未来的软件系统长成什么样子？

系统分析不关系怎么做，也不是解决方案。

当然，有时候，客户的需求也提出解决方案，但这并不意味着“需求”关注的“怎么做”。

一、分析与设计的区别

备注：

系统分析又称为目标系统的概念层面设计，因此，需求分析也包含了设计的成分，因此，有点地方，系统分析又称为pre-架构设计。架构前设计！！！

架构设计又称为目标系统的逻辑层设计。

底层设计有称为目标系统的物理层面设计、代码层面设计

二、结构化分析方法

S A 方法的基本思想是自顶向下，逐层分解，把一个大问题分解成若干个小问题，每个小问题再分解成若干个更小的问题。经过逐层分解，每个最低层的问题都是足够简单、容易解决的，于是复杂的问题也就迎刃而解了。在 S A 方法中导出的分析模型如阁11-5所示。

从 图 11-5可以看出， S A 方法分析模型的核心是数据字典，围绕这个核心，有三个层次的模型，分别是数据模型、功能模型和行为模型（也称为状态模型）。

在实际工作中：

• 一般使用 E - R 图表示数据模型，
• 用 D F D 表示功能模型或数据转换模型
• 用状态转换图 （State TransformDiagram , S T D ) 表示行为模型。

这三个模型有着密切的关系，它们的建立不具有严格的时序性，而是一个迭代的过程。

2.1  实体关系图：E - R 图 （名词）

E-R图，也称为实体关系图，用于显示实体集之间的关系。它提供了一种表示实体类型、属性和连接的方法；用来描述现实世界的概念模型。

2.2. 数据流图（数据的流动）

(1) 顶层图。

顶层图是描述系统最高层结构的 D F D , 它的特点是将整个待开发的系统表示为一个加工，将所有的外部实体和进出系统的数据流都画在一张图屮。

例如，图11-6就是一个顶层图的实例，只不过在绘制时做了一些处理，使得它看上去更加直观
易懂。

顶层图用来描述系统有什么输入和输出数据流，与哪些外部实体直接相关，可以把整个系统的范围勾画出来。

(2) 逐层分解。

当完成了顶层图的建模之后，就可以在此基础上进行进一步的分解。对 图 11-6进行分解，在对原有流程了解的基础上，可以得到图11-7。

 图 11-7是在顶层图11-6的基础上做的第一次分解，而在图】1-7中只有一个加工，那就是系统本身，可以将其编号为0。因此，对顶层图进行的分解，其实就是对这个编号为0 的加工进行更细化的描述，在这里引入了新的加工和数据存储，为了能够区分其位于的级别，在这个层次上的加工将以1, 2, 3 为序列进行编号。正是由于这是对加工0 的分解，因此也称为0 层图。可以根据谣要对0 层图上的加工进行类似的再分解，称之为1层图，在 1层图中引入的新加工，其编号规则就是1.1、
1.2、…，以及2.1、2.2、…，依次类推，直到完成分析工作。

2.3. 状态转换图（动作）

大多数业务系统是数据驱动的，所以适合使用 D F D 。但是，实时控制系统却主要是事件驱动的，因此，行为模型是最有效的描述方式。 S T D 通过描述系统的状态和引起系统状态转换的事件，来表示系统的行为。此外， S T D 还指出了作为特定事件的结果将执行哪些动作（例如，处理数据等）。状态是任何可以被观察到的系统行为模式，每个状态代表系统的-•种行为模式。在
S T D 中，用圆形框或椭圆框表示状态，通常在框内标上状态名。状态规定了系统对事件的响应方式。系统对事件的响应可以是做一个（或一系列）动作，也可以是仅仅改变系统本身的状态。 S T D 描述了系统如何在各种状态之间移动。事件是在某个特定时刻发生的事情，它是对引起系统从一个状态转换到另一个状态的外界事件的抽象。例如，内部时钟指明某个规定的时间段己经过去，鼠标移动或单击等都是事件。简而言之，事件就是引起系统状态转换的控制信息。
在 S T D 中，从一个状态到另一个状态的转换用箭头线表示，箭头表明转换方向，箭头线上标上事件名。必要时可在事件名后面加一个方括号，括号内写上状态转换的条件。也就是说，仅当方括号内所列出的条件为真时，该事件的发生才引起箭头所示的状态转换。图 11-8给出了一个在线课程学习的 S T D 示例。

 

2.4 数据字典

D F D 描述了系统的分解，即系统由哪几部分组成，各部分之间的联系等，但是，对于数据的详细内容却无法在 D F D 中得到反映。例如，图 11-7中的数据存储“课程”包括哪些内容，在 D F D 中就无法具体、准确地描述。数据字典是在 D F D 的基础上，对 D F D中出现的所有命名元素都加以定义，使得每个图形元素的名字都有一个确切的解释。D F D 和数据字典等工具相配合，就可以从图形和文字两个方面对系统的逻辑模型进行完整的描述。

三、面向对象分析方法

0 0 A 的基本任务是运用 O O 方法，对问题域进行分析和理解，正确认识其中的事物及它们之间的关系，找出描述问题域和系统功能所需的类和对象，定义它们的属性和职责，以及它们之间所形成的各种联系。最终产生一个符合用户需求，并能直接反映问题域和系统功能的 O O A 模型及其详细说明。

0 0 A 模型独立于具体编程语言的实现（怎么做)，即不考虑与系统具体实现有关的因素，这也是0 0 A 和0 0 D 的区别之所在。

O O A 的任务是“做什么”，0 0 D 的任务是“怎么做”。

3.1 用例模型

S A 方 法 采 用 功 能 分 解 的 方 式 来 描 述 系 统 功 能 ， 在 这 种 表 达 方 式 中 ， 系 统 功 能 被 分解 到 各 个 功 能 模 块 中 ，通 过 描 述 细 分 的 系 统 模 块 的 功 能 来 达 到 描 述 整 个 系 统 功 能 的 目 的 。
采 用 SA 方 法 来 描 述 系 统 需 求 ， 很 容 易 混 淆 需 求 和 设 计 的 界 限 ， 这 样 的 描 述 实 际 上 已 经包含了部分的设计在内。因此，系统分析师常常感到迷惑，不知道系统需求应该详细到
何种程度。一个极端的做法就是将需求详细到概要设计，因为这样的需求描述既包含了外部需求也包含了内部设计。 S A 方法的另一个缺点是分割了各项系统功能的应用环境,从各项功能项入手,很难了解到这些功能项如何相互关联来实现一个完整的系统服务的。
从用户的角度来看，他们并不想了解系统的内部结构和设计，他们所关心的是系统所能提供的服务，这就是用例方法的基本思想。用例方法是一种需求合成技术，采用10.2.3节 和 11.2节介绍的技术（方法）获取需求，记录下来，然后从这些零散的要求和期望中进行整理与提炼，从而建立用例模型。

在 O O A 方法中，构建用例模型一•般需要经历4 个阶段，分别是识别参与者、合并需求获得用例、细化用例描述和调整用例模型，其中前三个阶段是必需的。

3.2 分析模型

11.5.2节从用户的观点对系统进行了用例建模，但捕获了用例并不意味着分析的结束，还要对需求进行深入分析，获取关于问题域本质内容的分析模型。

分析模型描述系统的基本逻辑结构，展示对象和类如何组成系统（静态模型），以及它们如何保持通信，实现系统行为（动态模型）。

为了使模型独立于具体的幵发语言，系统分析师需要把注意力集中在概念性问题上而不是软件技术问题上，这些技术的起点就是领域模型。领域模型又称为概念模型或简称为域模型，也就是找到那些代表事物与概念的对象，即概念类。概念类可以从用例模型中获得灵感，经过完善将形成分析模型中的分析类。

每一个用例对应一个类图，描述参与这个用例实现的所有概念类，而用例的实现主要通过交互图来表示。例如，用例的事件流会对应产生一个顺序图，描述相关对象如何通过合作来完成整个事件流，复杂的备选事件流也吋以产生-个或多个顺序图。所有这些图的集合就构成了系统的分析模型。

建立分析模型的过程大致包括定义：概念类、确定类之间的关系、为类添加职责、建立交互图等，

其中有学者将前三个步骤统称为 C R C C C l a s s - Responsibity - Collaborator , 类-责任-协作者）建模。

3.2.1 定义概念类

 

3.2.2 确定类之间的关系

 

 

3.2.3 为类添加职责

 

3.2.4 建立交互图

多个对象的行为通常釆用对象交互来表示 ，U M L 2.0提供的交互图有：

• 顺序图
• 交互概览图
• 通信图
• 定时图。

每种图出于不同视点对行为有不同的表现能力，其中最常用的是顺序图，几乎可以用在任何系统的场合。顺序图的基本元素有对象、参与者、生命线、激活框、消息和消息路线，其中消息是顺序图的灵魂。当对象行为复杂并存在多种不同状态转换时，还要用到反映对象状态变化的状态图。

3.2.5 分析模型的详细程度问题

对于分析模型的详细程度，各种文献说法不一，在实践中的做法也不一样。

有些文献建议只列出类以及类之间的主要关系，不要对关系进行描述，更不要体现类的职责；

而有些文献则认为应该将这些东西都列出來。其实，干巴巴地讨论这个问题是没有任何意义的。

在整个系统开发的过程中，分析模型是不断演变的，应随着幵发的深入加入新的内容，或修改己有内容，逐渐完善，演变完整。最初的分析模型主要是围绕着领域知识进行的，对现实的事物进行建模。而后，则不断地加入设计的元素，最终演变成为运行于计算机上的系统。
总之，模型不是要开发的目标产物，而是开发过程中的一个辅助工作，只要能够利用其帮助团队更好地开发，详细也罢，简约也罢，都是好模型。