UML面向对象建模与设计——笔记（二）

最新推荐文章于 2024-06-09 10:56:42 发布

忧愁的awe

最新推荐文章于 2024-06-09 10:56:42 发布

阅读量1.6k

点赞数 1

文章标签： uml 面向对象

本文链接：https://blog.csdn.net/DFSAE/article/details/78916090

版权

UML面向对象建模与设计（第二版）笔记——第二部分：分析与设计

1.开发过程

开发过程由以下几个过程：系统构思，分析，系统设计，类设计，实现，测试，培训，部署，维护。

1.1.系统构思

构思一项应用并系统的猫叔临时性的需求。

1.2.分析

注重模型的建立。通过创建模型来捕获并审视需求。在需求分析阶段，开发者需要考虑如何利用现有的信息资源（文档，业务会谈和相关的应用）并消除歧义。

系统包括了两个子阶段：领域分析和应用分析。领域分析关注的重点是真实世界中传达应用语义的内容。领域分析强调的是概念和关系。应用分析描述的是应用为用户可见的计算机层面，描述应用从外界看来会是什么样子——应用黑盒视图。

1.3.系统设计

需要尽可能详尽的描述架构，并选择全局策略和政策来指导后续更加详细的设计。架构是用于解决应用问题的高层计划或策略。架构应该包含一个可执行的和可测试的基本框架。设计人员必须掌握一套新系统是如何对其他系统进行交互的，也要支持应用程序的未来修改。

1.4.类设计

扩充并优化分析模型，决策算法。

1.5.实现

实际编码过程。

1.6.测试

审视原始业务需求，验证系统是否交付正确的功能。
测试应该在几个层次上：单元测试，系统测试。

1.7.培训

培训是祖苏用户的软件学习过程。

1.8.部署

系统必须能在不同的平台上用不同的配置完成实际的工作。

1.9.开发生命周期

OO软件开发常用的方法：瀑布式开发和迭代开发。

瀑布开发指开发者严格顺序执行软件的开发阶段，不需要回溯。这在需求频繁改变的项目中会出现直到借宿才能交付，在项目出现偏差的时候加大评估进度和纠正项目的难度。

迭代开发需要一个过程的基点（分析，设计，实现和交付），在扩大范围，增加已有对象的属性和行为，以及增加新的对象，这是一个迭代的过程。每次迭代都包括完成的一套阶段（分析，设计，实现和测试），每次迭代都可以有目标的实现，这也有助于评估进度，及时调整计划。

2.系统构思

系统构思的目的是延迟细节实现，并理解完整图景。考虑系统具体的可实现性。
系统构思的过程主要有以下几个方面：

1>.阐释概念

即考虑系统的可行性和原始目的用途和价值。

2>.准备问题陈述

问题陈述可以构建系统的目标和总体方案。问题陈述应该描述要完成那些事，而不是如何实现，应该是需求陈述，避免描述系统内部机制和系统架构。

3.系统分析

3.1.领域分析

领域分析是关注设计一套精准简洁的，可以理解正确的真实世界模型。
创建领域模型，要与业专家交流，检查需求描述和审视相关制品。重新陈述，抽象终于特征，推迟细节。

分析模型描述对象的三个方面：对象的静态结构（类模型），对象间的交互（交互模型）和对象的生存期（状态模型）。我们需要对分析模型进行不断地迭代，细化分析模型。

1>创建领域类模型

分析过程中，类模型的优先级要高于状态和交互模。
创建领域类模型，需要经过以下几个步骤：
1.寻找类
2.准备数据词典
3.寻找关联
4.寻找对象和连接的属性
5.使用继承组织和简化类
6.验证可能查询的访问路径
7.迭代并细化模型
8.重新考虑抽象的层次
9.把类编组成包

2>.分析领域状态模型。

构造领域状态模型的步骤：
1.确定具有状态的了领域类
2.寻找状态
3.寻找事件
4.构造状态图
5.评价状态图

3>.领域交互模型

这个步骤在领域分析过程总并不是特别重要，而在应用建模时会是重点。

3.2.应用分析

应用分析模型包括应用交互模型，应用类模型，应用状态模型。

1>.应用交互模型

完成领域建模之后，我们要考虑应用程序中的细节，考虑进一步的交互。通过系统的整体边界来开始交互建模。

交互建模的具体步骤如下：
1.确定系统边界。
即应用程序的准确范围。
2.寻找参与者
3.寻找用例。
用例将系统功能划分成少数离散单元，所有的系统行为必须在某种用例之下。我们可以写几句小结来详细描述用例。
4.寻找初始和终止事件。
初始事件是触发连串的活动事件。终止事件是用例最后的结果。
5.准备普通场景。
场景是指一组交互对象之间发送的一系列事件，主要描述了主要的交互，外部显示格式，信息互换等。
6.增加变化和异常场景。
包括一下被忽略输入错误，计算错误错误，无效操作及一些异常非法情况。
7.寻找外部事件。
包括所有输入，决策，中断以及用户或者外部设备额往来交互。应该为某一种场景都准备一张顺序图，顺序图显示了交互过程中的参与者和他们之间的消息序列。
8.编制复杂用例的活动图。
用顺序图捕获参与者之间的对话与相互作用。可以用一想描述主导交互流的顺序图，还需要描述每种错误和决策点的其他顺序图。
9.组织参与者和用例。
用关系（包含，扩展，泛化）来组织用例。
10.检查领域类模型

2>.应用类模型

具体步骤如下：
1.确定用户界面。分析阶段的重点在信息流的控制，而不再表现格式。可以通过草拟一份示例界面来帮助我们将应用程序的操作可以可视化。
2.确定边界类。边界类可以理解为一个或多个外部资源的格式，可以让传输信息在外部和内部系统之间传递。
3.确定控制器。控制器是一种管理应用程序内部控制权的主动对象。他接受外界或系统的内部对象信号，并响应并回调操作。
4.检查交互模型。

3>.应用状态模型

应用状态模型专注于应用类，扩展了领域类模型，拥有了重要的时序行为。

应用类状态的构造步骤如下：
1.使用状态来确定应用类。
2.寻找事件。从前面的交互模型的大量场景中,提取事件。
3.构造状态图。用时序行为构造诶一个应用类的状态图。
4.检查其他状态。检车每个类的状态图的完整性和一致性。每次事件都应该有一个发送者和一个接收者。
5.检查类模型。要确保状态图和领域和应用类模型的一致性。
6.检查交互模型。