第3章 系统健壮性分析

.,第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年，IvarJacobson把鲁棒分析引进了面向对象领域。为了适合我们的理解习惯，以下一律叫健壮性分析。,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.1MVC模型结构,模型层负责表达和访问商业数据，执行商业逻辑和操作。也就是说，这一层就是现实生活中功能的软件模拟；在模型层变化的时候，它将通知视图层并提供后者访问自身状态的能力，同时控制层也可以访问其功能函数以完成相关的任务。,第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中的类，就是系统中的实体类。当然，并不是概念模型中所有的类都是我们要找的实体类，而是在用例描述中涉及到概念模型中的类才是我们要找的实体类。因此，结合概念模型和用例描述，我们就能够很容易地找到四个实体类：书籍、计算机书籍、非计算机书籍以及书籍列表。,第3章系统健壮性分析,22,.,第3章系统健壮性分析,3.2.3绘制健壮性分析图,当我们找出了边界类和实体类之后，就可以从边界类出发，根据用例描述逐步找到控制类。一般对于每个用例而言，合适的控制类的数量大约是25个之间。同时，在绘制健壮性分析图时要注意：,1)图中的箭头与顺序图不一样，并不代表信息传递，而是代表逻辑流。因此，你所要做的事情是理清楚对象之间的逻辑关系，而不是产生一个定义严密的设计方案。,2)图中出现的控制类并不一定就是一个未来的设计类，也许仅仅是类中的一个方法。因此没有必要花太多时间去考虑它是否是一个类。,23,.,第3章系统健壮性分析,1绘制边界类,我们可以先绘制参与者与边界类，如图3.5所示。,图3.5健壮性分析图之一,24,.,第3章系统健壮性分析,在前面关于健壮性分析图的绘制规则中，我们曾规定边界类与边界类之间是不能进行交互的，而图3.5中连接“新增图书信息”按钮和“新书录入”窗口两个边界类之间的虚箭头，表示的是“新书录入”窗口是按下“新增图书信息”按钮时才显示出来的，并不是表示两个边界类之间的交互。也就是说，这样画并没有违反规则。,2引入控制类及实体类,根据表3.1中事件流步骤5以及扩展路径的描述，我们就可以在图3.5中添加相应的控制类，得到包括控制类在内的进一步的健壮性分析图如图3.6所示。,再考虑表3.1中事件流步骤2、步骤3的内容，即根据所选的书籍类别，自动按规则生成书号，并把书号作为创建书籍的相关信息，把这些信息添加进图3.6中，就得到了最后的健壮性分析图如图3.7所示。,25,.,第3章系统健壮性分析,图3.6加入控制类和实体类的初步健壮性分析图,在图3.6中，我们所表达的是：当按下“提交”按钮后，就将进行书名的重复性检查，检查的依据是书籍列表，如果重名则回到“新书录入”窗口重新输入，如果不重名就创建新的书籍，并加入书籍列表。,26,.,第3章系统健壮性分析,图3.7最后的健壮性分析图,27,.,第3章系统健壮性分析,通过仔细分析，并把分析结果绘制成健壮性分析图，将有助于开发人员更加深入的了解系统细节。与此同时找到了边界类（系统的各种界面信息）和控制类（系统的关键业务逻辑）。健壮性分析也不一定是一个独立的分析阶段，我们可以在编写用例描述的同时，结合健壮性分析来启发思路，完善细节。,3.3完善概念模型,健壮性分析图的绘制过程，是对用例描述的正确性和完整性进行检查的过程，也是不断发现新的类或修正先前发现的类的过程。因此，它在细化用例描述的同时，也包含了对我们在前面的工作中已经完成的静态模型（问题域概