面向对象分析与设计过程(思路)

weixin_43081541

已于 2024-03-01 16:17:17 修改

阅读量949

点赞数 22

文章标签：需求分析软件工程

于 2024-02-26 09:32:59 首次发布

本文链接：https://blog.csdn.net/weixin_43081541/article/details/135956845

版权

面向对象分析与设计过程

一项目接触
二准备工作
三获取需求
四需求分析
- 1 关键概念分析
- - 1.1建立概念模型
五系统分析
1确定系统用例
欢迎使用Markdown编辑器

整理《大象thinking in uml》思路

一项目接触

项目了解

二准备工作

1 了解问题领域

1.1了解业务概况

项目背景调查
业务前景分析
业务可行性分析
技术可行性分析

1.2 整理业务目标（重要）

业务目标又称为业务前景，是对要建设的系统的展望。客户立项准备开发一个软件系统，一·定会对这个系统有明确的展望，即建设系统的目的是什么、准备用它来做什么。业务目标非常重要在 9.1 定义边界一节中会看到，边界正是基于业务目标来定义的。
一般我们都会根据对业务概况的了解来整理业务目标。业务目标大部分情况下是由客户提出,在招标书里一般都有相关的描述。当然也可以由开发方整理得出。在这个案例里，我们得到了以下一些业务目标:

为用电客户提供业务办理自动化服务，提高办事效率，方便客户，为客户提供更好的服务。
规范供电企业的内部管理，提高工作效率和管理效能。
管理好供电企业的资产，提高资产使用率和设备可靠性规范化财务管理，提高电费发行效率，减少人为差错。
做好用电检查工作，保障用电安全。
采集营销和管理数据，进行商业分析，提供决策支持。

在很多项目里业务目标仅在项目立项的过程中使用,它最多会在分析业务范围时起一点参考作用，很少有人用它来进行分析设计。在作者所介绍的方法里，业务目标是进行分析的第一步，从需求开始，所有的工作都由业务目标开始推导。在 9.1 定义边界一节里，读者将看到作者是如何根据业务目标来开始推导需求和建立业务模型的。

1.3 产出成果

项目立项建议书

2 涉众分析

2.1 发现定义涉众（干系人）

业主（出资方）
业务提出者
业务管理者
业务执行者
第三方
承建方
相关法律法规
用户

2.2 涉众分析报告

涉众概要
涉众简档
用户概要

在这里插入图片描述

用户简档
消费者统计

2.3 产出成果

系统涉众概要（编号+涉众名称+涉众说明+期望）
系统涉众简档（代表+职责）
系统用户概要（用户名称+概况特定）
系统用户简档（代表+职责）

3 规划业务范围

3.1 规划业务目标

取消一个目标、调整一个目标

3.2 规划涉众期望

取消一个涉众、调整一个涉众期望等

4 需求调研计划整理

4.1 划分涉众优先级

涉众优先级从低到高：1 2 3
期望优先级从低到高：1 2 3
从涉众分析报告中，根据优先级别产出
在这里插入图片描述

4.2 规划需求层次

第一层：业务架构
调研内容包括：业务背景、业务目标、业务目标人员、业务参与人员、组织架构、岗位设置等
第二层：业务流程
针对每个业务目标，将参与这个业务目标的业务目标人员、业务参与人员、组织结构和岗位设置组织起来，描述业务流程的运转过程以及每一个参与元素在运转过程中的贡献和期望。
第三层：工作细节
针对每一个参与上述业务流程的参与者展开，描述他的工作细节，做什么、怎么做、有哪些规则、结果是什么。在这一层次，基于前面的工作，已经不用再考虑整个业务是什么，而只需要专心细致地一点点挖挪参与者的工作细节。

4.3 需求调研计划

项目情况千变万化，需求调研计划也应当因地制宜。这里作者给出–个示例，在这个示例中，需求工作分三个迭代完成。
第一个调研迭代周期完成第一优先级期望的第一、第二需求层次的工作。
（根据最高优先级涉众及期望，调研业务目标、业务流程，产出业务用例、流程图等）
第二个调研迭代周期完成第一优先级期望的第三需求层次，第二优先级期望的第一、第二需求层次和第三优先级期望的第一需求层次的工作。
（最高优先级涉众、期望+工作细节调研，中优先级涉众、期望+业务目标+流程调研，低优先级涉众、期望+业务目标调研）
第三个调研迭代周期则完成第二优先级期望的第三需求层次，第三优先级期望的第二、第三需求层次的工作。
（中优先级涉众、期望+工作细节调研，低优先级涉众、期望+目标流程+工作细节调研）
在这里插入图片描述

4.4 产出成果

根据涉众及期望，我们在规划业务目标及期望后，根据涉众和期望的优先级，我们整理了需求调研计划表。《需求调研计划表》

接下来就是明确主角，点对点进行调研。

三获取需求

在准备工作中，我们得到了涉众分析报告这个重要的工件，它将为我们获取需求指明方向; 经过规划业务范围、划分优先级和规划需求层次的工作，明确了应当在什么时候对什么涉众的什么期望进行调研:通过学习客户访谈技巧，知道了应当如何做好与客户沟通的准备。一切就绪,可以开始获取需求的进程了。

1 定义边界

从一个业务目标（参照准备工作中的整理业务目标，一个目标为一个边界）中发现边界，发现边界外围的涉众。为下一步发现主角做准备。
在这里插入图片描述

2 发现主角

首先根据涉众分析报告中的涉众概要，我们很容易得到备选的涉众列表: 其次根据所定义的边界，我们可以从中寻找那些站在边界外的涉众。用主角的定义去审查这些备选的涉众在此边界内的行为模式，从中找出符合定义的涉众而形成业务主角。
请注意，不是所有的涉众都会成为业务主角，只有那些直接与系统交互的涉众才能被称为业务主角。另一方面，涉众利益可以被多个不同的业务主角代表，这意味着，一个涉众可以衍生出多个主角。

3 获取业务用例（用例视图）

获取业务用例有很多方法，可以从岗位手册、业务流程指南、职务说明等一些文件中获得，也可以从涉众分析中获得灵感。另外一种很重要的方法，就是业务主角访谈。在 3.3.4 用例的获得一节中我们谈到过，可以通过以下问题引导业务主角代表说出他们的业务需求:

您对系统有什么期望?
（当客户谈及系统期望时，通常都不是业务需求，而更多的会谈及他们希望系统能帮助他们做什么，或者说他们脑子里想象的系统应当是什么样，应当如何操作等。有时，从这些期望当中找出明确的需求并不容易。需求分为两种: 功能性需求和非功能性需求。业务员所提出的这些期望看上去正是非功能性需求。另一方面，读者也可以看出，虽然业务员是代表用电客户这个涉众来提出问题的.但由于业务员是系统的直接使用者，因此他不可避免地一定会谈到对他有利的一些期望。如果发现这些期望有和他所代表的涉众利益有冲突，就应当注意并提出来。）

您打算在这个系统里做些什么事情?
（在初步了解业务时，要防止陷入业务细节，应当引导客户先从独立的业务模块开始讲起，这样才能够建立起对整体业务的初步概念而不至于谨毛失貌。）

您做这件事的目的是什么?
（由于判断用例是否合理是以该用例是否完整地达成了业务主角的一个目的为标准的，因此在访谈中应当引导客户从每一项业务的起因(针对性)和目的(要达成的业务目标)谈起。由此来判断客户所谈及的这些业务是否可以作为一个业务用例。例如，本例中虽然客户谈及了低乐、高压、批量等业务类型，但从针对性和目的看，它们都是针对同样类别的客户达到同样的目的，因此应当作为一个业务用例而不是多个。而低压、高压、批量等则是同样业务的不同实现方式，即该项业务有多个业务用例实现。
另一方面，客户所谈及的针对性也可以作为将来用例规约文档的前置条件来源。）

您做完这件事希望有一个什么样的结果?
（让客户说明每项业务的结果可以帮助我们分析用例，尤其是在概念模型建立时，不同的业务有着相同或相似的结果，这种情况往往是分析的重点。另外，业务结果的说明也是将来用例规约文档中后置条件的重要来源。）

根据上面访谈可以获取以下业务用例。
在这里插入图片描述
如果业务主角是机器设备、传感器、子系统等，尽管这些业务主角不能够开口说话，但是你可以采用拟人化的形式、角色扮演的形式来替代它们做出类似例子中的访谈。

3.1 业务用例可作为项目管理估算依据

确定业务范围更多的是对项目管理有用。在项目管理中，成本估算依据于工作量估算。业务用例获取是在系统建设的早期进行的，甚至应当早于大部分的项目计划，或者与项目计划并行进行我们知道，要制定项目计划，必须要有明确的项目范围。业务用例可以作为业务范围，也就是项目的范围来使用。在目前比较流行的项目估算方法是工作分解结构 WBS(Work BreakDown Structure)而业务用例就可以作为工作分解结构的起点。这里提到对业务用例的分解,并不是分解成系统用例而是从项目估算的要求出发，来分解完成一个业务用例需要做的工作。图 9.10 展示了根据业务用例的工作分解结构，项目经理可以根据这个结构来估算工作量。
在这里插入图片描述

4 业务建模

完整的业务模型包括以下内容：

业务用例视图
业务主角+简单用例组合的描述业务uml图，上面获取业务用例已完成该步骤。
业务用例场景
用活动图、时序图描述用例场景
业务用例规约
业务规则
业务对象模型
概念类。（具体在领域建模时创建）
业务用例实现视图
业务用例实现场景
业务用例实现场景的建模方法与业务用例场景有着微妙的差别。业务用例场景用于说明业务怎样执行，但缺少表达如何“实现”的机制。例如，一项业务中需要对文件进行保存，但文件保存是可以有多种实现方式的，可以扫描成图片保存，可以做成 PDF 文件保存，甚至干脆采用人工档案室保存的方式。这种实现机制就是在业务用例实现场景中去描述的。虽然它们描述的都是同样的业务要求，但着力点不同。通常情况下，建立计算机系统的目的就是让用户通过人机交互来完成业务，因此，在业务用例实现时应当着重描述如何通过人机交互来完成业务。
包图

5 领域建模

概念类+关联关系+时序图

6 提炼业务规则

全局规则
交互规则
用例规约、用例规则
内禀规则
业务对象描述文档

7 获取非功能性需求

必要时建立调研表调研

可靠性
安全性、事务性、稳定性
可用性
有效性
性能可伸缩性、可扩展性
可移植性

四需求分析

上一章，我们做了许多工作，捕获了需求，然而这些需求还处在“原料”阶段。在很多项目中，需求人员将需求捕获以后，就向后扔给了设计人员。不可否认，信息在传递过程中会发生失真，当需求简单地向后传递给设计人员后，设计人员很有可能误解甚至丢失需求中的重要信息。不论需求文档写得如何详细，设计人员仍然有可能不能理解需求当中的重点和难点是什么，因而导致设计重心的偏差。
信息的失真或许是不可能完全避免的，但我们应当尽量减低这种可能性。在实践过程中，一种好的方法是在将需求向后传递之前进行一些需求分析的工作。这些工作将由需求人员和负责系统设计或架构设计的人员一起来完成。需求分析工作将使得需求人员和系统分析设计人员之间有机会进行沟通和交流，共同就需求文档当中的概念、问题和关键点达成共识，最大限度地降低信息失真的可能性。我们进行需求分析，可能需要完成的工作包括建立概念模型、建立业务架构和开发系统原型。

1 关键概念分析

在这里插入图片描述

1.1建立概念模型

概念模型始于业务用例，从业务模型中抽象出一些概念用例，针对概念用例进行分析，得到一些分析类和分析场景。从业务用例到分析类是分析过程，在分析过程中可以向上追溯，则是改进过程。
在开始建立概念模型之前有必要强调两点:
概念模型是针对需求中的关键业务,或者说业务核心来建立的,所以前提是需求人员已经把握了需求，并能够从复杂的需求当中找出支撑起整个业务的那条主线来。并且，概念模型费于精准而非全面。

五系统分析

1确定系统用例

在这里插入图片描述

欢迎使用Markdown编辑器

你好！这是你第一次使用 Markdown编辑器 所展示的欢迎页。如果你想学习如何使用Markdown编辑器, 可以仔细阅读这篇文章，了解一下Markdown的基本语法知识。

新的改变

我们对Markdown编辑器进行了一些功能拓展与语法支持，除了标准的Markdown编辑器功能，我们增加了如下几点新功能，帮助你用它写博客：

全新的界面设计 ，将会带来全新的写作体验；
在创作中心设置你喜爱的代码高亮样式，Markdown 将代码片显示选择的高亮样式 进行展示；
增加了 图片拖拽 功能，你可以将本地的图片直接拖拽到编辑区域直接展示；
全新的 KaTeX数学公式 语法；
增加了支持甘特图的mermaid语法¹ 功能；
增加了 多屏幕编辑 Markdown文章功能；
增加了 焦点写作模式、预览模式、简洁写作模式、左右区域同步滚轮设置 等功能，功能按钮位于编辑区域与预览区域中间；
增加了 检查列表 功能。

功能快捷键

撤销：Ctrl/Command + Z
重做：Ctrl/Command + Y
加粗：Ctrl/Command + B
斜体：Ctrl/Command + I
标题：Ctrl/Command + Shift + H
无序列表：Ctrl/Command + Shift + U
有序列表：Ctrl/Command + Shift + O
检查列表：Ctrl/Command + Shift + C
插入代码：Ctrl/Command + Shift + K
插入链接：Ctrl/Command + Shift + L
插入图片：Ctrl/Command + Shift + G
查找：Ctrl/Command + F
替换：Ctrl/Command + G

合理的创建标题，有助于目录的生成

直接输入1次#，并按下space后，将生成1级标题。
输入2次#，并按下space后，将生成2级标题。
以此类推，我们支持6级标题。有助于使用TOC语法后生成一个完美的目录。

如何改变文本的样式

强调文本 强调文本

加粗文本 加粗文本

标记文本

~~删除文本~~

引用文本

H₂O is是液体。

2¹⁰ 运算结果是 1024.

插入链接与图片

链接: link.

图片: Alt

带尺寸的图片:

居中的图片: Alt

居中并且带尺寸的图片:

当然，我们为了让用户更加便捷，我们增加了图片拖拽功能。

如何插入一段漂亮的代码片

去博客设置页面，选择一款你喜欢的代码片高亮样式，下面展示同样高亮的 代码片.

// An highlighted block
var foo = 'bar';

生成一个适合你的列表

项目
- 项目
  - 项目

项目1
项目2
项目3

计划任务
完成任务

创建一个表格

一个简单的表格是这么创建的：

项目	Value
电脑	$1600
手机	$12
导管	$1

设定内容居中、居左、居右

使用:---------:居中
使用:----------居左
使用----------:居右

第一列	第二列	第三列
第一列文本居中	第二列文本居右	第三列文本居左

SmartyPants

SmartyPants将ASCII标点字符转换为“智能”印刷标点HTML实体。例如：

TYPE	ASCII	HTML
Single backticks	`'Isn't this fun?'`	‘Isn’t this fun?’
Quotes	`"Isn't this fun?"`	“Isn’t this fun?”
Dashes	`-- is en-dash, --- is em-dash`	– is en-dash, — is em-dash

创建一个自定义列表

Markdown

Text-to- HTML conversion tool

Authors

John

Luke

如何创建一个注脚

一个具有注脚的文本。²

注释也是必不可少的

Markdown将文本转换为 HTML。

KaTeX数学公式

您可以使用渲染LaTeX数学表达式 KaTeX:

Gamma公式展示 $\Gamma(n) = (n-1)!\quad\forall n\in\mathbb N$ 是通过欧拉积分

$\Gamma(z) = \int_0^\infty t^{z-1}e^{-t}dt\,.$

你可以找到更多关于的信息 LaTeX 数学表达式here.

新的甘特图功能，丰富你的文章

关于 甘特图 语法，参考这儿,

UML 图表

可以使用UML图表进行渲染。 Mermaid. 例如下面产生的一个序列图：

这将产生一个流程图。:

关于 Mermaid 语法，参考这儿,

FLowchart流程图

我们依旧会支持flowchart的流程图：

关于 Flowchart流程图 语法，参考这儿.

导出与导入

导出

如果你想尝试使用此编辑器, 你可以在此篇文章任意编辑。当你完成了一篇文章的写作, 在上方工具栏找到 文章导出 ，生成一个.md文件或者.html文件进行本地保存。

导入

如果你想加载一篇你写过的.md文件，在上方工具栏可以选择导入功能进行对应扩展名的文件导入，
继续你的创作。

mermaid语法说明 ↩︎
注脚的解释 ↩︎

weixin_43081541

关注

22
点赞
踩
21

收藏

觉得还不错? 一键收藏
1
评论
面向对象分析与设计过程(思路)

业主（出资方）业务提出者业务管理者业务执行者第三方承建方相关法律法规用户从一个业务目标（参照准备工作中的整理业务目标，一个目标为一个边界）中发现边界，发现边界外围的涉众。为下一步发现主角做准备。
复制链接

扫一扫