每周必写

Posted 2020-07-19

这周学习了用Rational Rose 2003建模工具画，用例图、类图、序列图和状态图。

用例图定义：由参与者（Actor）、用例（Use Case）以及它们之间的关系构成的用于描述系统功能的静态视图称为用例图。

用例图（User Case）是被称为参与者的外部用户所能观察到的系统功能的模型图，呈现了一些参与者和一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。

用例图展示了用例之间以及同用例参与者之间是怎样相互联系的。用例图用于对系统、子系统或类的行为进行可视化，使用户能够理解如何使用这些元素，并使开发者能够实现这些元素。

用例之间的关系：

包含关系：基本用例的行为包含了另一个用例的行为。基本用例描述在多个用例中都有的公共行为。包含关系本质上是比较特殊的依赖关系。它比一般的依赖关系多了一些语义。在包含关系中用例的方向是从基本用例到包含用例。在UML1.1中用例之间是使用和扩展这两种关系，这两种关系都是泛化关系的版型。在UML1.3以后的版本中用例之间是包含和扩展这两种关系。

泛化关系：代表一般与特殊的关系。它的意思和面向对象程序设计中的继承的概念是类似的。不同的是继承使用在实施阶段，泛化使用在分析、设计阶段。在泛化关系中子用例继承了父用例的行为和含义，子用例也可以增加新的行为和含义或者覆盖父用例中的行为和含义。

扩展关系的基本含义和泛化关系类似，但在扩展关系中，对于扩展用例有更多的规则限制，基本用例必须声明扩展点，而扩展用例只能在扩展点上增加新的行为和含义。与包含关系一样，扩展关系也是依赖关系的版型。在扩展关系中，箭头的方向是从扩展用例到基本用例，这与包含关系是不同的。

类图(Class diagram)由许多（静态）说明性的模型 元素（例如类、包和它们之间的关系，这些元素和它们的内容互相连接）组成。类图可以组织在（并且属于）包中，仅显示特定包中的相关内容。

类图(Class diagram)是最常用的 UML图，显示出类、接口以及它们之间的静态结构和关系；它用于描述系统的结构化设计。

  序列图是一个模型，用于描述对象组如何随着时间在某些行为方面进行协作。序列图捕获单一用例的行为，同时显示在特定用例的时间框架中的对象以及这些对象之间传递的消息。序列图并不显示对象之间的关系。
　序列图是按时间顺序描述了对象间的交互模式；它利用对象的“生命线”和它们之间传递的消息来显示对象如何参与交互。 

状态图（Statechart Diagram）是描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的事件做出反应的。通常创建一个UML状态图是为了以下的研究目的：研究类、角色、子系统、或组件的复杂行为。

这周阅读了《代码大全》第五章 软件构建中的设计

这一章共有4节，是从总体上对设计进行了讨论。

启发式设计方法：

1、  抽象：是一种能让你在关注某一概念的同时可以放心的忽略其中的一些细节的能力，在不同的层次上处理不同的细节。

2、  封装：抽象是“从更高层次的细节来看待一个对象”，封装是“除此之外，你不能看到对象的任何其他层次的细节”。封装帮助你管理复杂度的方法是不让你看到那些复杂度。

3、  信息隐藏：信息隐藏的好处是，对减少“改动影响的代码量”至关重要。

     我觉得软件的首要技术使命就是管理复杂度。以简单性作为努力目标的设计方案对此最有帮助。

简单性可以通过两种方式来获取：一是减少在同一时间所关注的本质性复杂度的量，二是避免生成不必要的偶然的复杂度。

设计是一种启发式的过程。固执于某一种单一方法会损害创新能力，从而损害你的程序。

好的设计都是迭代的。你尝试设计的可能性越多，你的最终设计方案就是变得越好。

信息隐藏是个非常有价值的概念。通过询问“我应该隐藏什么，能够解决很大困难的设计问题”

  经过这么时间学习这门课程，从开始不理解这们课程是干什么的，到现在慢慢的也学了很多东西，学到了一些建模需要的工具，还有一些图，在这之前，做设计写报告没有画过这些图，现在知道一个程序不只是单单画个功能图，流程图就可以的。这们课让我学到很多在设计上没有注意过的问题，以后也会更注意的。