多平台统一管理软件接口,如何实现多平台统一管理软件接口
559
2022-12-25
本文目录一览:
系统详细设计包括以下内容子系统接口设计过程:
1、 系统结构设计及子系统划分
划分系统功能模块或子系统(如果有或者有必要子系统接口设计过程,特别是大型的软件系统)。
2、系统功能模块详细设计
按结构化设计方法,在系统功能逐层分解的基础上,对系统各功能模块或子系统进行设计。此为详细设计的主要部分之一。
3、系统界面详细设计
系统界面说明应用系统软件的各种接口。整个系统的其子系统接口设计过程他接口(如系统硬件接口、通讯接口等)在相应的部分说明。
4、外部界面设计
根据系统界面划分进行系统外部界面设计,对系统的所有外部接口(包括功能和数据接口)进行设计。
5、内部界面设计
设计系统内部各功能模块间的调用关系和数据接口。
6、用户界面设计
规定人机界面的内容、界面风格、调用方式等,包括所谓的表单设计、报表设计和用户需要的打印输出等设计。
扩展资料子系统接口设计过程:
系统详细设计内容:
用层次图描述系统的总体结构、功能分解及各个模块之间的相互调用关系和信息交互,用IPO图或其他方法描述各模块完成的功能。
以上建议采用HIPO图进行功能分解与模块描述,更高的要求建议采用IDEF0方法进行功能模型设计。
详细设计应用系统的各个构成模块完成的功能及其相互之间的关系。
用IPO或结构图描述各模块的组成结构、算法、模块间的接口关系,以及需求、功能和模块三者之间的交叉参照关系。
每个模块的描述说明可参照以下格式:
模块编号:
模块名称:
输入:
处理:
算法描述:
输出:
其中处理和算法描述部分主要采用伪码或具体的程序语言完成。
对详细设计更高的要求建议用IDEF0图进行各功能模块的设计。
如果对软件需进行二次开发(包括功能扩展、功能改造、用户界面改造等),则相应的设计工作应该设立子课题完成。
参考资料:百度百科 ------ 系统设计
系统在运行中将用到大量的数据资料,必须在设计初始就明确各类数据标准以及各子系统的数据接口。根据各子系统设计的数据项需求及产生的成果数据项,确定各项数据的数据表,定义表结构,进行代码设计,然后由数据库系统实施,同时形成文档,作为系统的数据标准,统一执行。
数据的分类、编码设计、数据库的设计、地图制图、数据录入和质量检验,均遵循国家和行业主管部门的标准、规范、规程;如没有统一的规范规程,则参照相关的规程进行规范化设计。系统有关的数据定义全部形成文档,作为技术规范,统一使用。
各子系统在设计时应当明确与相关子系统的数据关系,提出相关子系统必须提交的数据表要求和系统运行过程中的提交时间,对应子系统按照该提交数据要求在系统中进行相应设计和开发,保证数据流动的通畅,这是基于数据的系统集成方案的关键,是数据平台接口设计的重要依据。系统间数据关系须形成文档,作为系统间数据接口标准规范,统一执行。
数据关系与数据标准相辅相成,共同定义子系统接口设计过程了数据平台与各个子系统之间的输入、输出接口。在数据接口设计中应重点考虑以下几个方面:
(1)遥感数据与图形数据的接口:利用图形配准技术,予以解决。遥感数据是动态监测专题图件产生的基础,必须经过坐标配准,才能产生专题图件。配准过程由遥感动态监测子系统执行,需要应用综合数据库中的地形图数据。在配准后遥感数据与图形数据的套合依据空间坐标进行。
(2)空间数据与属性数据的接口:利用关键字建立联系。在数据建库过程中依据数据标准有关文档规定建立图形库和属性库结构,确定关键字段,同时定义关键字段编码方案,保证关键字段唯一性。在数据采集过程中对关键字段赋予代码。系统维护过程中的数据采集也必须依据编码方案对关键字段赋值。在应用系统中使用时只需建立图形库与属性库间的关联即可。
( 3) 子系统之间数据的接口: 各子系统之间数据的交换通过数据库进行,所以子系统间数据接口本质上是子系统与后台数据库的接口; 在建立数据库时,已经由数据库管理系统依据系统间数据关系建立子系统接口设计过程了接口。
系统内数据关系包括:
数据管理与数据库子系统接受业务处理与信息服务子系统录入的有关基础信息、遥感动态监测子系统输入的遥感数据及各子系统产生的成果数据,为各子系统提供综合基础数据、专题数据和成果数据。
遥感动态监测子系统需要数据库系统管理的遥感数据、地形图数据和历史专题数据。
生态专业分析子系统需要遥感动态监测子系统产生的专题图件和综合数据库中的历史专题图件以及属性资料。
业务处理与信息服务子系统需要数据库子系统管理的综合基础数据和各专业应用子系统产生的成果数据。
如果某个协作中的各个类只是在相互之间进行交互,并且可生成一组定义明确的结果,就应将该协作和它的类封装在一个子系统中。
这一规则同样适用于协作的子集。可以对协作的任何部分或全部进行封装和简化,这将会使设计更易于理解。 构件属于实施范畴;为了在设计中表示构件,可以将子系统用作构件的代理。
系统的每个部分都应尽可能独立于系统的其他部分。 从理论上说,应该可以用新的部分替换系统的任何部分,但前提是新部分必须支持相同的接口。 应该可以使系统的不同部分独立地演进,而不受系统其他部分的影响。 为此,设计子系统提供了一种在设计模型中表示构件的理想方法:它们是用来封装许多类的行为的设计元素(就象构件封装许多类实例的行为一样),并且只能通过它们所实现的接口访问它们的行为(构件就是这样)。 如果现有产品是用来导出接口(即操作,也许会导出接收)的产品,但却隐藏了实施的所有细节,就可以在逻辑视图中将该产品建模为子系统。您可以用子系统表示系统所使用的产品,例如:
通信软件(中间件)。 数据库访问支持(RDBMS 映射支持)。 应用程序专用产品。 某些现有的产品,如类型集合和数据结构(例如,栈、列表、队列)最好用包来表示,因为它们所展示的不仅仅是行为。既重要又有用的是包中的特定内容,而不是包本身,包不过是一个容器而已。
对于常用的实用程序(如数学库),如果它们只导出接口,就可以将其表示成子系统,但这是否有必要或有意义,还要取决于设计人员对建模对象性质的判断。子系统是面向对象的构造,它们不仅是分类器,还是包:子系统可以具有实例(如果设计人员作出这样的指定)。通过 UML,也可以在作为构造型类的实用程序(该实用程序没有实例)中建立多组全局变量和过程的模型。
当定义子系统来代表产品时,还要定义一个或多个接口来表示产品接口。 子系统与包在语义上具有差异:子系统是一种通过一个或多个它所实现的接口来提供行为的包。包并不提供行为;它们只不过是用来容纳提供行为的对象的容器。
之所以要使用子系统而不使用包,是因为子系统完全封装自己的内容,只通过自己的接口提供行为。其好处在于,与包不同,只要子系统的接口保持不变,就可以完全自由地更改子系统的内容和内部行为。另外,子系统还提供了一种“可替换的设计”元素:任何两个实现相同接口的子系统(或类,就此而论)都可以互换。 为确保子系统在模型中是可互换的元素,需要执行以下几条规则:
子系统不应暴露自己的任何内容(即,子系统所包含的元素都不应有“公有”的可见性);子系统外部的元素都不应依赖于子系统内部特定元素的存在。 子系统只应依赖于其他模型元素的接口,因此它不直接依赖于子系统外部的任何特定模型元素。例外情况是,许多子系统共享一组类定义。在这种情况下,这些子系统将“导入”包含公共类的包中的内容。这一操作只应对位于构架低层的包执行,并且只能是为了确保必须在子系统之间传递的公共类定义保持一致。
以下显示了子系统和包的依赖关系的示例:
设计模型中子系统和包的依赖关系
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。
发表评论
暂时没有评论,来抢沙发吧~