分析rip软件输入和输出部分的实现过程

分析rip软件输入和输出部分的实现过程

用例分析法

用例分析法，是来自面向对象的分析方法。用例描述系统的用户和系统本身之间的交互过程，从而对如何使用系统提供了一种详细的陈述，获得对系统需求的了解。用例分析，是获取系统功能需求的一个重要技术。

用例中，用户术语叫actor。用户不必是真的人，如果要开发的系统系统对另外一个计算机系统提供服务，那么，另一个系统就是这个系统的用户。

一个用例有多个场景组成，一个用例中，所有的场景有着相同的用户目标。一般包括一个主成功场景和几个附加的扩展场景，例如在一个网上超市系统，“购物过程”是一个用例，这个用例中，共同的用户目标就是完成购物。但这个目标可能成功完成，也可能因为什么原因而失败。这样，就有成功实现购物的主场景，还有多个购物失败的场景：如信用卡失败，货物售空等等。

用例中的一个复杂的步骤可能是另一个用例。这就是用例之间的包含关系。

UML用例图重点说明两种关系：

用户和用例的关系。就是那个用户启动了哪个用例。

多个用例之间的关系。比如，一个用例包含了其他的用例

用例的几乎全部的价值在于内容。用例图本身的价值不大。你在使用用例进行分析的时候，不必过多的致力与用例图，应该关注与用例的正文内容。这才是这种技术的真正价值所在。

除了简单的包含关系，UML中还定义了其他的许多关系。但我认为，除了包含关系，以外的其他关系都可以忽略。其他关系除了导致混乱和复杂，几乎没有什么价值。

千万不要把用例做的太复杂，通常做的过少比做的过多危害要小。如果做的太少，一个短小易读的文档，构成发问的起点。如果做的更多，任何人对它将难以阅读，难以理解。

用例可以按照等级划分，分为系统用例和业务用例。系统用例重点说明软件系统的交互，业务用例讨论的是一种业务如何响应来自客户的事件。

还有一种更详细的分级方法：海级用例，鱼级用例和风筝级用例。海级用例描述主参与者和系统之间的一次完整交互，不是任何其他交互过程中的一个步骤。包含在海级内的用例是鱼级用例。更高级别的风筝级用例，风筝级用例就是上面的业务用例。如果适应更广泛的业务交互。

数据流分析法

这个方法来自传统的结构化分析方法。使用数据流图描述系统的数据处理模型。

注意：数据流图描绘的是系统的逻辑模型，图中没有具体的物理元素，只是描述信息在系统中流动和处理的情况。

数据流图在分析和设计的前期使用，数据流图中的处理，是逻辑上存在的一个过程，开始时不要考虑对应任何具体的软件实体（不要把处理当成了模块）。在输入数据和输出数据确定的情况下，需要什么样的处理，才能由输入产生输出？--通过这种思路获得对系统功能需求的理解。最终究竟由哪个软件实体来承担一个处理，是设计阶段的事情。最终，有可能一个处理最终由多个软件实体承担，也由可能，多个处理由一个软件实体承担。甚至可能，某些处理是人工的过程，最终不对应任何的软件实体---哪部分处理通过用户手工完成，也是设计的内容。

数据流图中的数据存储也不是实际存在的物理实体。

数据流图的基本要点是描述“做什么”而不是“如何做”。数据流图的意义在于分析，而不在于设计。避免数据流图中的设计的味道。

许多人画不好数据流图，是因为在画数据流图的过程中。因为他们把数据处理想象成模块或者对象，把数据存储看成了具体的数据文件或者数据库。

另外不要在数据流图中，表现分支和循环，这样会造成混乱，画不出正确的数据流图。数据流图中，描绘所有可能的数据流向，而不应该描绘出现某个数据流的条件。--有时候你可把判断条件当成是输入的数据。

面向对象与数据流分析

是否可以在面向对象设计中使用数据流分析法，是一个有争议的话题。大部分讲面向对象设计方法的书，都反对在面向对象的方法中使用传统的结构化的方法。我个人认为，可以使用，但要小心使用。有下面的理由：

数据流图，涉及了系统内部的分析。而用例分析方法不涉及系统的内部。只通过用例分析系统，总是觉得分析的不够彻底。

有些系统，本身就是一数据处理为主要任务的，应用的逻辑集中在数据的处理上而不是交互的过程上，不适合使用用例分析法。

数据流图流传很久，容易被人看懂，容易在交流中使用。而用例图使用的人少，许多人对它不熟悉。

在面向对象的设计方法中，使用数据流图分析后，就要在数据流图的基础上抽象对象，数据流图上的每种元素：数据流，数据存储;外部实体和数据处理，都可能用来抽象对象。

一般的意义下，在面向对象的程序中，对象或类构成了系统的逻辑结构。而模块反应了系统的物理结构。模块的概念往往和具体的编程语言相关，比如在C++中，模块对应独立的编译单元。一个编译单元中，包含一个或多个紧密相关的类实现。

模块是一个很不精确的概念。在实际的交流中，甚至在一些正式的文档上，模块可能代表任何的软件实体。特别是在结构化设计方法里面，模块可以是单独命名的，可以通过名字来访问的任何程序对象的集合，过程，函数，子程序，宏都可以作为模块。对这种不准确的概念，应该怎样办，应该从狭隘的概念中解放出来，应该“求其意而忘其形”。

但要注意：在面向对象的设计过程中，使用数据流图确实是危险的。注意下面的两点：

在面向对象的设计过程中使用数据流图，注意不要回到结构化设计的路子上。

数据流图，最主要的功能是分析，是帮助程序员理解需求，千万不要在让数据流图有了设计的味道。

JACKSON分析方法

JACKSON方法是一套完成的分析和设计方法。Jackson认为有三种形式的数据结构。、顺序、选择和重复。三种数据结构可以进行任意嵌套，组合。形成复杂的结构体系。JACKSON方法的从目标系统的输入、输出数据结构入手，导出程序框架结构，再补充其它细节，就可得到完整的描述程序结构的JACKSON图。

我在实际中，我没有完整的使用过JACKSON方法（实际上，我也没有系统的学习过这种方法）。我只在分析阶段，经常使用JACKSON图描述复杂的要处理的数据的逻辑结构。我把这种只把JACKSON方法用来做分析的方法，称为JACKSON方法。

JACKSON方法的主要思路，就是：通过对要处理的复杂数据，绘制JACKSON图进行分析，了解需求。

另外，除了使用JACKSON图来完成分析，我还使用过JACKSON图，来描述过复杂配置文件的文件结构。因为JACKSON图关注与数据的逻辑结构，而不比关心数据的具体存在形式。用来设计配置文件的格式，挺合适的。

在中国移动数据网管系统中。我就使用了这种图来设计数据转换配置文件的数据结构。最终，配置文件使用了XML文件。

根据实际情况选择分析方法

交互型的系统：系统和外部有复杂的交互过程，适合使用用例分析法。有图形界面的软件或者服务端常是这种情况。

对数据处理性的系统，可能存在复杂的数据处理流程，系统要求有复杂的数据处理过程，对这样的，适合使用数据流的分析。

如果被处理数据，有复杂的结构，就适合使用面向数据结构的分析方法。在同一个项目中，可能使用到多种分析方法。