概要设计说明书 - TRUSTIE

概要设计 说明书 房屋状态说明书下载罗氏说明书下载焊机说明书下载罗氏说明书下载GGD说明书下载 - TRUSTIE 国家863 计划 项目进度计划表范例计划下载计划下载计划下载课程教学计划下载 课题技术验收附件材料 可信的国家软件资源共享与协同生产环境 课题编号:2007AA010301 OODIA双向工程工具 软件概要设计说明 TRUSTIE课题组 二〇一〇年十二月 文档修改 记录 混凝土 养护记录下载土方回填监理旁站记录免费下载集备记录下载集备记录下载集备记录下载 修订版本号 修订人 修改内容 日期 备注 V1.0 李合 创建文档 2008-3-9 V2.0 李合 更新设计内容 2009-10-8 V3.0 赵旭、李合 审阅并定稿 2010-1-22 目录 1 引言 ............................................................................................................................................ 4 1.1 编写目的 ........................................................................................................................... 4 1.2 背景 ................................................................................................................................... 4 2 总体设计 .................................................................................................................................... 4 2.1 需求规定 ........................................................................................................................... 4 2.2 运行环境 ........................................................................................................................... 5 2.3 基本设计概念和处理流程 ............................................................................................... 5 2.4 结构 ................................................................................................................................... 6 3 接口设计 .................................................................................................................................... 6 3.1 用户接口 ........................................................................................................................... 6 3.2 外部接口 ........................................................................................................................... 7 4 运行设计 .................................................................................................................................... 8 4.1 运行模块组合 ................................................................................................................... 8 4.2 运行控制 ......................................................................................................................... 10 概要设计说明书 1 引言 1.1 编写目的 本文档为OODIA(一种以代码为中心的增量同步的双向工具)编写的概要设计说明书。本文所针对的读者包括: , 用户:帮助用户了解工具的意义，使用和一些基本功能 , 开发人员:指导开发人员完成对用户需求的实现 , 测试人员:指导测试人员完成测试任务，尤其是进行集成系统测试时，根据 此文档来测试工具是否完成了在特定软硬件环境下的正常运行 1.2 背景 说明: , 名称:以代码为中心的增量同步双向工具 , 提出者:707国家重点工程项目组 , 开发者:李合、刘石、王晓吟、白鹏 , 用户: 1、中创软件商用中间件股份有限公司 2、神州数码公司 3、万达信息股份有限公司 2 总体设计 2.1 需求规定 从功能上可以把面向对象双向工程工具划分为三个部分:正向工程部分，逆向工程部分，以及保证模型与代码之间同步部分。细化之后的主要功能点如下: , 支持从Java源代码文件到类图的逆向，对Java源代码文件进行解析，逆向生 成包图/类图，并显示在编辑视图中 , 提供简单的类图编辑功能，支持对主要的UML类图模型元素的添加，删除 和修改等操作，这里支持的元素主要为包、类、类的 方法 快递客服问题件处理详细方法山木方法pdf计算方法pdf华与华方法下载八字理论方法下载 、类的属性，以及 类与类之间的各种关系。支持类图文件的保存、载入等操作。 , 支持从类图生成源代码，将类图中的各种模型元素生成Java语言中对应的代 码段，并保证代码的正确性，这是实现正向工程的关键。 , 提供对Java代码文件的编辑功能，包括代码浏览，添加，删除以及修改的操 作。支持Java代码文件的保存，载入等操作。 , 保证类图与代码的同步，即当在类图中对类图的元素进行的各种操作，包括 添加，删除，修改等都可以即时反映到代码上，反之，对代码的各种修改也 同步反映到类图模型上。 2.2 运行环境 CPU:Inter Pentium 4以上 硬盘:大于500M的可用空间 内存:512M 以上RAM 运行平台:JDK 6以上、Eclipse 3.4 2.3 基本设计概念和处理流程 下图展示了系统的整体框架图 图:系统整体框架图 整个工具搭建在Eclipse平台之上，Eclipse为Graphical Editing Framework(GEF)和Java Development Tools(JDT)提供底层的基础功能支持。在Eclipse平台之上主要包含两大部分，分别基于GEF的类图编辑器，以及利用JDT内部支持的代码编辑器。用户可以分别同类图编辑器和代码编辑器进行交互。其中类图编辑器提供的基本功能包括UML类图的创建，修改和删除等功能。而JDT所支持的代码编辑器可以支持代码的添加，修改等。类图编辑器可以将模型文件保存起来，该模型文件可在今后需要使用时再被打开。。当用户分别对类图编辑器和类图编辑器进行操纵时，工具提供了同步机制保证模型与代码之间的同步。 2.4 结构 用一览表及框图的形式说明本系统的系统元素(各层模块、子程序、公用程序等)的划分，扼要说明每个系统元素的标识符和功能，分层次地给出各元素之间的控制与被控制关系. 3 接口设计 3.1 用户接口 类图编辑器是利用GEF提供的基础功能实现的。GEF的优势是提供了标准的MVC(Model-View-Control)结构，开发人员可以利用GEF来完成许多图形编辑器的功能，而不需要自己重新设计。大部分GEF应用程序都实现为Eclipse的Editor，也就是说整个编辑区域是放置在一个Editor里的。所以典型的GEF应用程序具有一个图形编辑区域包含在一个Editor里，可能有一个大纲视图和一个属性页，一个用于创建EditPart实例的EditPartFactory，一些表示业务的模型对象，与模型对象对应的一些EditPart，每个EditPart对应一个IFigure的子类对象显示给用户，一些EditPolicy对象，以及一些Command对象。 GEF应用程序的工作方式如下: EditPartViewer接受用户的操作，例如节点的选择、新增或删除等等，每个节点都对应一个EditPart对象，这个对象有一组按操作Role分开的EditPolicy，每个EditPolicy会对应一些Command对象，Command最终对模型进行直接修改。用户的操作转换为Request分配给适当的EditPolicy，由后者创建适当的Command来修改模型，这些Command会保留在EditDomain(专门用于维护EditPartViewer、Command等信息的对象，一般每个 Editor对应唯一一个该对象)的命令堆栈里，用于实现撤消/重做功能。图3-4展示了GEF应用程序的工作流程以及其所涉及到的各个部分。 利用GEF进行图形化开发，软件开发人员需要自己实现模型，控制器、视图以及命令和编辑策略。其它部分GEF已经实现，其相应的功能也可以直接使用。 下图展示了GEF应用程序的工作流程以及其所涉及到的各个部分。 图: GEF应用程序流程 3.2 外部接口 根据需求，我们讲本工具设计为Eclipse的插件，有些功能是软件工程工具的基本功能，例如代码的编辑，对Java源文件的解析等这些功能在以往的工具中已经被实现，但由于以往的工具往往只关注某个功能点，且开发的环境与语言都不尽相同，所以想要复用以前的功能模块不太现实。但从头开发这些功能导致工作量太大。开发平台Eclipse提供了丰富的基础工具支持及框架用来支持软件开发过程的各个部分，利用Eclipse平台，开发人员可以节省大量开发工作，并可提供更丰富的功能。鉴于此，OODIA开发小组决定在Eclipse平台上进行该工具的开发，并将工具设计为Eclipse插件，最终产品将以插件的形式依赖于Eclipse平台运行，为在Eclipse上进行开发的用户提供双向工程功能。 4 运行设计 4.1 运行模块组合 任何东西都可以被当作模型，模型是唯一可以持久保存和被恢复的。一个应用程序应该将需要保存的数据定义为模型。GEF的模型只与控制器打交道，而不知道任何与视图有关的东西。为了能让控制器知道模型的变化，应该把控制器作为事件监听者注册在模型中，当模型发生变化时，就触发相应的事件给控制器，后者负责通知各个视图进行更新。 典型的模型对象会包含PropertyChangeSupport类型的成员变量，用来维护监听器成员即控制器;对于与其他对象具有连接关系的模型，要维护连入/连出的连接列表;如果模型对应的节点具有大小和位置信息，还要维护它们。这些变量并不是模型本身必须的信息，维护它们使模型变得不够清晰，但你可以通过构造一些抽象模型类(例如让所有具有连接的模型对象继承Node类)来维持它们的可读性。 由于我们需要实现一个类图编辑器，所以需要保存UML类图的模型元素的信息。本文所实现的工具并不支持UML类图中所有的类元，而只支持使用较多的类和接口这两种，且对这两种类元也只支持其使用较广泛的简单特征:属性和方法。该工具支持类元之间的三种关系:关联、泛化以及实现。下图为模型的主要结构图。 图 :模型部分的主要结构图 , AbstractModel类为所有类的父类，因为所有的模型需要支持三项基本功能: 模型更改消息通知机制，序列化以及其属性显示，所以我们把这部分公用的 功能放在AbstractModel类里面实现。 , RootModel类表示JAVA工程 , PackageModel类表示包。 , PackageFieldModel类表示类中的类或接口(和包图中的类条目一一对应，每 PackageFieldModel对应于一个TypeModel) , 类TypeModel为接口和类提供了公用的功能。由于用户使用类图编辑器时， 的位置信息，以便下次打开时可以恢复为上次的位置，所希望保存其中图形 以在Type中添加了保存位置信息的变量。另外接口与类还具有一些公共属 性，包括:名称、以该类型为源的关系集合，以该类型为目标的关系集合， 方法集合。任何一个关系都有关系源和关系目标两端，处在源和目标两端的 类的属性往往不一样，所以需要分别保留以该类为关系源的关系及以该类为 目标的关系集合。从Type类派生出了接口和类。该工具所支持的接口与UML 里的标准接口有些不同。在UML里，接口是一组用于描述类或构件的一个 服务的操作。在图形上，它可以画为一个圆，其扩展形式是将接口表示成一 个构造型化类。在工具中，对接口进行了简化，由于在Java语言中，可以将 接口看成是与类类似的结构体，所以我们在工具中对接口的表示也与类的表 示类似。 , CompartmentModel表示模型的组合，是FieldCompartmentModel和 MethodCompartmentModel的父类，其中，前者表示属性的组合，后者表示 方法的组合，每个TypeModel中均包含类型为FieldCompartmentMode和 MethodCompartmentModel的属性，表示类/接口中的所有属性和方法。 , MethodModel用来表示类的操作，包含名字、 参数 转速和进给参数表a氧化沟运行参数高温蒸汽处理医疗废物pid参数自整定算法口腔医院集中消毒供应 、返回类型以及可见性属 性。 , FieldModel用来表示类的属性，包含名字、类型以及可见性属性。 , RelationshipModel用来表示所有支持的关系。其中该类包含一个类型 , ModelType的属性来表示该类的实例到底是哪种关系。另外对一个关系实例， 还需要保存其关系源端的Type实例，以及关系目标端的Type实例。 4.2 运行控制 在MVC结构里控制器是模型与视图之间的桥梁，也是整个GEF的核心。它不仅要监听模型的变化即当用户编辑视图时，将编辑结果反映到模型上。举个例子来说，用户在数据库结构图上删除一个表时，控制器应该从模型中删除这个表对象、表中的字段对象、以及与这些对象有关的所有连接。当然在GEF中这些操作不是由直接控制器完成的，GEF提供了对这些操作更好的操作。 GEF中的控制器是所谓的EditPart对象，更确切的说应该是一组EditPart对象共同组成了GEF的控制器这部分，每一个模型对象都对应一个EditPart对象。你的应用程序中需要有一个EditPartFactory对象负责根据给定模型对象创建对应的EditPart对象，这个工厂类将被视图利用。 RootEditPart是一种特殊的EditPart，它和模型没有任何关系，它的作用是把EditPartViewer和contents(应用程序的最上层EditPart，一般代表一块画布)联 系起来，可以把它想成是contents的容器。EditPartViewer有一个方法setRootEditPart()专门用来指定视图对应的RooEditPart。 当我们在设计系统时，一般会为模型里面的每一个类设计一个对应的控制器类，这样可以方便以后的控制器类对模型类的修改。下图为控制器的结构图(省略了类之间的关联关系)。 图:与editor相关的控制器的主要结构图 图:与outLine相关的控制器结构图 以上给出了两幅图，一幅是与编辑视图相关的控制器的结构图，第二幅是与大纲视 图相关的控制器的结构图。由于控制器只是模型的对应部分，负责将模型与视图连接起来，所以基本上都没有属性。在GEF中，预先实现了三类控制器，分别为AbstractGraphicalEditPart 、AbstractConnectionEditPart和AbstractTreeEditPart。当用户需要自己实现控制器时，一般都是从这三者去派生。类一用于生成图元为图形的控制器，类二为生成图元之间连接的控制器，类三为生成大纲视图树图元的控制器。另外，控制器需要实现PropertyChangeListener 接口。每一个模型被生成的同时会将相应的控制器加为自己属性变化的侦听器，这样，一旦模型的属性发生更改，相应的控制器就可以得到通知。AbstractEditPartWithListener实现了上述接口，其它的控制器只要继承该抽像类即可。