系统健壮性分析课件

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,第,3,章 系统健壮性分析,3.1,什么是健壮性分析,3.1.1,健壮性分析的作用,3.1.2,健壮性分析的对象,3.2,开始健壮性分析,3.2.1,通过事件流寻找边界对象,3.2.2,从概念模型及用例描述中寻找实体对象,3.3,完善概念模型,1,第,3,章 系统健壮性分析,通过前面两章的工作，我们已经建立起一静（概念模型）一动（用例模型）两个模型，从静态和动态两个方面描述了系统的概貌。接下来，我们该做哪些事情呢？,绝大多数软件工程教科书都告诉我们，面向对象方法比结构化方法先进，前者用直接的手段反映现实世界，而后者是用间接的手段来反映现实世界。后者的致命弱点就是在分析阶段以数据流图作为表达工具，而在设计阶段用系统结构图等作为表达手段，从而使得分析和设计两个阶段存在着难以跨越的鸿沟，导致了设计和分析的脱节。而在面向对象方法中，由于表达工具的一致性，加上通常采用的是迭代的软件过程，使分析和设计没有明显的界限，从而不会导致分析结果在设计中的变形。,2,那么，面向对象方法分析和设计中的各步骤工作是否就真的能无缝的集成在一起，是否不存在任何障碍和鸿沟。实际上，当我们对问题域完成了用例建模之后，接下来的工作就是绘制系统顺序图或时序图，并进而把它们演化成设计类图，在这个过程中，我们依然会感到无从下手。也就是说，当我们完成了传统意义上的分析工作,建立概念模型和用例模型,之后，从分析阶段向设计阶段转换中，依然存在着一定程度的鸿沟，只不过没有结构化方法那么明显而已。,第,3,章 系统健壮性分析,3,第,3,章 系统健壮性分析,3.1,什么是健壮性分析,健壮性分析通常也叫鲁棒分析。鲁棒是,Robust,的音译，也就是健壮和强壮的意思。鲁棒性（,robustness,）就是系统的健壮性。它是在异常和危险情况下系统生存的关键。比如说，计算机软件在输入错误、磁盘故障、网络过载或恶意攻击情况下，能否不死机、不崩溃，就是该软件的鲁棒性。所谓,“,鲁棒性,”,，是指控制系统在一定（结构，大小）的参数摄动下，维持某些性能的特性。根据对性能的不同定义，可分为稳定鲁棒性和性能鲁棒性。以闭环系统的鲁棒性作为目标设计得到的固定控制器称为鲁棒控制器。,1991,年，,Ivar Jacobson,把鲁棒分析引进了面向对象领域。为了适合我们的理解习惯，以下一律叫健壮性分析。,4,健壮性分析尽管也有分析两字，但它的工作有很多与设计类似，而从严格的意义上来说，它又不是真正的设计，即是一种介乎于分析与设计中间地带的东西。因此，用它来填补上面所提到的鸿沟，却是非常合适的。现在大多数面向对象的书籍中，都没有提到健壮性分析，我们在这里对它进行介绍，也算是一家之言吧。,第,3,章 系统健壮性分析,5,第,3,章 系统健壮性分析,在面向对象的分析与设计中，健壮性分析可以完成以下的任务：,1),正确性检查：健壮性分析将通过比顺序图更简单、更有效的图形来描述用例中的传递过程，从而确保用例是正确的，同时没有指定对于特定对象来说不合理、不可能的系统行为。如果熟练掌握了健壮性分析，还可以在编写用例描述时，多了一种有效的对比和检验方法。,2),完整性检查：通过健壮性分析，你可以很容易的找到用例描述中所有必须的扩展路径。,3.1.1,健壮性分析的作用,6,4),初步设计：健壮性分析将类分成了实体类、控制类、边界类三种，组装观点正好与,MVC,体系结构不谋而合，这可以保证设计出更加稳健的应用系统。,3),持续发现及确认类：在做健壮性分析时，你将会关注具体的细节问题，从而很容易发现在问题域建模时漏掉的类。这些漏掉的类让你在绘制顺序图时感觉到好像缺少了一些什么，但又不容易被重新找到。同时，你也可以通过健壮性分析来确认先前所确定的类中哪些是不正确的，从而修改或删除不正确的类。,第,3,章 系统健壮性分析,7,第,3,章 系统健壮性分析,附：,MVC,简介,MVC,是,Model-View-Controller,的缩写，,是一种常用的设计模式。,模型,-,视图,-,控制结构是交互式应用程序广泛使用的一种体系结构。它有效地在存储和展示数据的对象中区分功能模块以降低它们之间的连接度，这种体系结构将传统的输入、处理和输出模型转化为图形显示的用户交互模型，或者换一种说法，是多层次的,Web,商业应用；,MVC,体系结构具有三个层面：模型（,Model,）、视图,(View),和控制,(Controller),，每个层面有其各自的功能作用，,MVC,体系结构如下：,8,图,3.1 MVC,模型结构,模型层负责表达和访问商业数据，执行商业逻辑和操作。也就是说，这一层就是现实生活中功能的软件模拟；在模型层变化的时候，它将通知视图层并提供后者访问自身状态的能力，同时控制层也可以访问其功能函数以完成相关的任务。,第,3,章 系统健壮性分析,9,第,3,章 系统健壮性分析,视图层负责显示模型层的内容。它从模型层取得数据并指定这些数据如何被显示出来。在模型层变化的时候，它将自动更新。另外视图层也会将用户的输入传送给控制层。,控制层负责定义应用程序的行为。它可以分派用户的请求并选择恰当的视图以用于显示，同时它也可以解释用户的输入并将它们映射为模型层可执行的操作；在一个图形界面中，常见的用户输入包括点击按钮和菜单选择。控制层可以基于用户的交互和模型层的操作结果来选择下一个可以显示的视图，一个应用程序通常会基于一组相关功能设定一个控制层的模块，甚至一些应用程序会根据不同的用户类型具有不同的控制层设定，这主要是由于不同用户的视图交互和选择也是不同的。,10,第,3,章 系统健壮性分析,在模型层、视图层和控制层之间划分责任可以减少代码的重复度，并使应用程序维护起来更简单。同时由于数据和商务逻辑的分开，在新的数据源加入和数据显示变化的时候，数据处理也会变得更简单。,MVC,是现有的编程语言中制作图形用户界面的一种通用的思想，它把数据的内容本身和显示方式分离开，这样就使得数据的显示更加灵活。比如，某年级各个班级的学生人数是数据，则显示方式是多种多样的，可以采用柱状图显示，也可以采用饼图显示，也可以采用直接的数据输出。因此在设计的时候，就考虑把数据和显示方式分开，对于实现多种多样的显示是非常有帮助的。,11,第,3,章 系统健壮性分析,3.1.2,健壮性分析的对象,健壮性分析的,图形表示法如图,3.2,所示：,实体类,控制类,边界类,图,3.2,健壮性分析图形表示法,1),边界类,：用于建立系统与其参与者（即用户和外部系统）之间交互的模型。这种交互通常包括接收来自用户和外部系统的信息与请求以及将信息与请求提交到用户和外部系统。,边界类对系统中依赖于参与者的部分建模，也就是说，边界类用于阐明和收集系统的边界需求。这样，通常就把用户界面或通信接口的变化隔离在一个或多个边界类中，从而不会影响系统的数据和系统的控制逻辑。,12,边界类通常代表对对话框、菜单、接口等的抽象。在我们工作的这个阶段，只要边界类能够说明通过交互（即在系统与参与者之间来回传递的信息与请求）所实现的目标就足够了，而不必描述如何具体实现这种交互，因为这是在后续的设计与实现活动中所要考虑的问题。,每个边界类至少应该与一个参与者有关，反之亦然。,2),实体类,：实体类通常用于对持久的信息建模，即主要,对诸如个体、实际对象或实际事件的某些现象或概念的,信息及相关行为建模。大多数情况下，实体类来自现实,世界，也就是来自先前所建立的问题域模型，用来描述,具体的实体，并经常表示为一种逻辑数据结构，一般映,射到数据库表格与文件中。,第,3,章 系统健壮性分析,13,第,3,章 系统健壮性分析,3),控制类,：代表协调、排序、事务处理以及对其他对象的控制，经常用于封装与某个具体用例有关的控制。控制类还可用来表示复杂的派生与演算，如业务逻辑，它们与系统存储的任何具体的持久信息（即某个具体的实体类）都没有关系。,系统的动态特征通过控制类来建模，因为控制类处理和协调主要的动作和控制流，并将任务委派给其他对象（即边界对象和实体对象）。,控制类并不封装与参与者交互有关的问题，也不封装与系统处理的持久信息有关的问题，这些问题分别是由边界类和实体类封装的。而控制类对控制、协调、排序、事务处理、复杂业务逻辑（涉及其他多个对象）进行封装，因而能将它们与变化隔离开来，即可以使得应用系统的变化不影响用户界面和数据库中的表。,14,第,3,章 系统健壮性分析,除了以上的图形表示之外，健壮性分析也制定了一些绘制分析图的规则。通过这些规则，使我们能够更好地理解健壮性分析的本质特征。这些规则为：,参与者只能通过边界类与系统交互；,边界类只能与控制类或参与者交互；,实体类也只能与控制类交互；,控制类可以与边界类、控制类、实体类交互，但不能与参,与者交互。,这些规则如图,3.3,所示。,15,第,3,章 系统健壮性分析,允许,不允许,图,3.3,健壮性分析图规则,16,第,3,章 系统健壮性分析,3.2,开始健壮性分析,通过上面的介绍，我们已经了解了什么是健壮性分析，也了解了健壮性分析在面向对象分析和设计中所起的桥梁作用，以及绘制健壮性分析图所应遵循的一些简单规则。,3.2.1,通过事件流寻找边界类,健壮性分析是针对某个具体用例的，其分析的基础是具体用例描述中关于事件流的部分，同时综合考虑基本路径和扩展路径两方面。在第,2,章中，我们曾以“新增书籍信息”（用例,UC01,）为例说明了如何编写用例描述，并得到了如表,3.1,的事件流描述。,17,第,3,章 系统健壮性分析,3.,事件流,3.1,基本事件流,1),图书管理员向系统发出,”,新增书籍信息,“,请求；,2),系统要求图书管理员选择要新增的书籍是计算机类还是非计算机类；,3),图书管理员做出选择后，显示相应界面，让图书管理员输入信息，并自动根据书号规则生成书号；,4),图书管理员输入书籍的相关信息，包括：书名、作者、出版社、,ISBN,号、开本、页数、定价、是否有光盘等；,5),系统确认输入的信息中书名没有重名；,6),系统将所输入的信息存储建档；,表,3.1”,新增书籍信息“用例事件流,18,3.2,扩展事件流,5a),如果输入的书名有重名现象，则显示出重名的书籍，并要求图书管理员选择修改书名或取消输入；,5a1),图书管理员选择取消输入，则结束用例，不做存储建档工作；,5a2),图书管理员选择修改书名后，转到,5),；,在我们讨论的这个用例中，不存在外部系统，而且参与者也只有一个“图书管理员”，因此寻找边界类比较简单，即从“图书管理员”这个参与者出发，认真分析用例描述的每一句话，从中进行选择：,第,3,章 系统健壮性分析,19,第,3,章 系统健壮性分析,1),图书管理员向系统发出“新增书籍信息”请求,图书管理员在什么地方向系统发出“新增书籍信息”的请求呢？一般情况下我们会设计一个主窗口，并在上面摆放一些按钮来实现，所以我们通过该描述可以发现两个边界类：主窗口、“新增书籍信息”按钮。,2),系统要求图书管理员选择要新增的书籍是计算机类还是非计算机类，从该描述中我们可以发现一个新的边界类：书籍类别列表框。,3),图书管理员做出选择后，显示相应界面，让图书管理员输入信息，并根据书号生成规则自动生成书号，从该描述中，我们可以发现很关键的一个边界类：“新书录入信息”窗口以及辅助的“提交”按钮。,除此之外，我们还应该发现新增书籍信息按钮是主窗口的一个组成部分，而书籍类别列表框、提交按钮则是新书信息录入窗口的必要组成部分。,20,第,3,章 系统健壮性分析,3.2.2,从概念模型及用例描述中寻找实体类,在第,1,章中，我们已经找到了与问题域相关的各个类，并建立了问题域概念模型如图,3.4,所示。,书籍列表,借阅记录列表,书籍,借阅记录,非计算机类书籍,计算机类书籍,图,3.4,最初的概念模型,21,图,3.4,中的类，就是系统中的实体类。当然，并不是概念模型中所有的类都是我们要找的实体类