郑州公交查询系统.docx
- 文档编号:24619893
- 上传时间:2023-05-29
- 格式:DOCX
- 页数:11
- 大小:76.66KB
郑州公交查询系统.docx
《郑州公交查询系统.docx》由会员分享,可在线阅读,更多相关《郑州公交查询系统.docx(11页珍藏版)》请在冰豆网上搜索。
郑州公交查询系统
郑州公交查询系统
作者:
日期:
郑州市公交查询系统
1.度地本系统用到的主要技术
采用java编程语言,初步打算运用EOS开发平台,数据库采用Oracle,会用到百图。
2.系统实现的主要功能
输入起点和终点,能够显示所乘公交车次(主要包括最短路径和换乘次数最少路径),XX地图上会显示路线。
3.本系统的难点
查询最短路径的时候,用到的算法比较难(通过图来实现);在地图上插入站点比较难(通过API插件);
数据量比较大,数据量的搜集比较难(通过网路搜索和实地考察)。
4.本系统的亮点
1.采用XX地图,把站点插入地图中,查询的时候可
以直接在地图上显示路线。
2.能够查找出最短路径。
5.系统简介
页面主要有两个窗口,一个显示地图,一个显示车次。
把站点插入XX地图,输入起点和终点,通过调用数据库查找出最短路径,在地图上显示路线,在车次窗口中显示换乘的车次。
®•全9»
ffn■■tPEuE
S-tr.77?
clmAC
廿■■.
-.±s
w
.■nfrJKPfl
jKmI
•if料蚌小牧适
-
a^-T-
卅I
[-4
ij«5即i:
i#・rT号嶄i IB J* 3KB" •JUMa Publictransportquerysystem EOS开发平台和框架 现在我天天都离不开普元EOS,我的工作就是用它来开发,相信很多朋友都用过或者听说 过这个中间件和开发平台了。 说实话,当初我是极度地不接受这个“东西”的。 但出于工作, 我慢慢接受了这个框架。 比起Struts,Spring,Hibernate等开源框架,EOS做得更彻底,走得更远了。 它有几个特 点是别的框架所没有的。 1、一个开源并且成熟的用户管理系统框架(用户管理系统是大多数应用所必须的); 2、开发环境是eclipse二次开发(我觉得是eclipse的插件)过的,已经封装了许多“构 件”,以构件为单位的编程思想贯穿其中,提高了程序的复用程度;并且能够在开发环 境中 直接拖拽构件,构件以图元的形式显示,调试方便(是不是从.NET学来的? ) 3、采用“数据总线”的思想,应用各部分都共享数据总线上的数据,而不直接传递对象; 4、对工作流开发很好的支持; “面向构件”和“Web服务”和以上几点的确能够使EOS成为一个出色的中间件和开 发平台,使工作流应用(例如OA)快速开发,不过EOS也有它的不足的地方,作为程序 员更应该客观地去看待这个“工具”。 当初开始接触EOS,感觉很不习惯,因为一些新的思想必须去接受,例如“数据总线”, “XPath存取路径”等,而且感觉自己作为程序员在使用框架的时候成就感少了,呵呵。 因为什么都是现成的构件或者是半成品,我只拿过来用,后来想想,前人已经做好了轮子,何 必重复去做呢? 心理有些平衡了。 现在发觉EOS有几个缺点,不知道大家认同否 1、用XPath存取数据,面向对象能力减弱。 因为在数据总线上只保留数据,没有方法, 而众所周知对象是数据和方法的集合。 2、EOS的所谓MVC架构其实并不彻底,架构比较散。 MVC虽然不是死的,也不一 定要完全遵照MVC模式才是好的应用,但我觉得Struts在应用MVC上是成功的。 而EOS 充其量只不过是多个小MVC拼凑在一起。 以JSP做viewer,展现逻辑作controller,业务逻 辑作model,对比在struts中只有一个单一的controllerActionServlet,我觉得后者更好。 3、EOS不是开源框架,如果应用出了什么问题,而调试时发现是框架出了问题,你只 好去找普元了,呵呵 这是我的一些看法,你呢? 不妨说说啊。 如果看了我的blog想了解EOS的话,那真是 我的罪过了,我不是想卖广告的,到google或baidu上搜一下,一大筐,自己慢慢看吧〜 普元EOS开发平台培训总结 (本文是某软件企业的技术负责人在接受普元EOS平台3.0版本的培训之后总结的心得体 会。 目前普元EOS产品的最新版本是5.0,作者提出的“5大缺点”如今是否仍然存在,尚且是一个值得思考的问题。 ) 一EOS开发平台的功能 普元EOS是一个快速开发平台。 在这个平台的基础上,可以通过既有的一些构件的功 能,来订制新的系统。 EOS专业版附带了权限和公共两个构件库,可选构件包括工作流,管理等部分。 通过 默认的构件库,能够轻松的调用并订制新的功能。 EOS提供一个Studio开发环境,订制过程完全图像化,可以用拖拉拽的方式实现。 对于一个全新的业务系统的开发,开发人员可以通过订制表现自动机”,业务自动机 等构建整个系统。 系统会自动生成相应的代码并提交到服务器。 EOS提供一个称为数据字典的数据库映射工具,将数据库表映射成某个命名的实体对 象。 系统中调用命名的对象来访问数据库。 EOS提供一个JSP生成器,自动根据某个实体来生成相应的CRUD模版操作界面。 EOS支持多种应用服务器。 支持部署在分布式系统上。 二EOS开发平台的优势 1能够很快的开发出原形产品 在了解了业务需求的情况下,几个熟悉EOS的开发人员可以很快地开发出产品原形。 这适于对陌生领域的竞投标等采用。 2学习曲线较J2EE低 EOS的一些复杂技术对开发人员透明,开发人员不许要了解过多的EJB,应用服务器 等使用,只要会操作EOS的各种工具,就可以开发和部署。 只需要关注业务。 3对客户的需求更改应变能力强 整个开发都是基于图形化的流程界面,很少涉及程序代码,如果一旦客户的需求变更,只需要更新图形并重新生成代码。 其他修改比较少。 4构件包可以不断积累 EOS提供了一些基本包,大量的功能都已经封装好。 同时,在不同领域的实施中,还会产生该领域特色的构件包,可以积累以供将来使用。 三EOS开发平台的缺点 1EOS构件没有统一标准 EOS的构件还没有一个统一的标准。 这样就对后续开发和扩展产生了很大的影响。 今后所有的产品都牢牢的绑定在EOS平台,移植性很差,完全失去了J2EE的灵活性。 2EOS的一些概念定义含糊 例如动态EJB,数据字典,构件等,并没有给出一个确定的定义。 理解起来可能存在 一定困难或偏差。 而实际上,动态EJB和数据字典都是在炒作概念,并没有新意。 3EOS会导致公司技术积累下降 EOS的高度透明性同样带来了技术水平的降低。 程序员无法掌握核心技术,这样一旦 发生意外,很难靠自己解决。 4EOS无法兼容旧有产品 EOS的移植性很差,旧有的产品完全无法移植到EOS平台上。 5EOS的工具还存在一定的差距 它的工具易用性、成熟性等方面尚存在一定的差距。 例如,各种工具尚未整合到同一个 操作界面下等。 四对EOS的个人看法 通过2天的培训,对EOS有了大致了解。 可以认为,EOS是一个比较稳定的快速开发 平台。 然而,其中的一些概念或方法,都存在着较大的风险。 首先是整个EOS这个软件的思路,它定位于一种图形快速开发平台,通过对业务建模 而生成最终代码。 而国际上的标准是MDA(ModelDrivenArchitecture)。 MDA发展刚起 步,它的核心是MOF或元数据,并且是OMG的标准。 反观EOS,它仅仅是通过订制流程图来定义业务,一没有一个全局的架构或概况设计, 二没有对业务领域的建模。 如果拿过去面向过程和面向对象来比较的话正合适,EOS就是 面向过程的设计。 然而,它的成品是面向对象的语言Java的代码,用面向过程的方式来写 面向对象的Java代码,这就是它移植性差的原因。 其次,所谓构件。 照我的理解,构件,就是能够反复使用的一套业务功能或模型,其重 用范围应该是整套功能而不是某个类,例如订单系统,可能包含多个类,但复用是复用整个 定单系统。 Java中有portlet标准,即为门户定义的标准。 每个portlet可对应一套构件。 只要订单系统实现portlet标准,就可以在WEB上任意的地方重用订单。 Java中被广泛接 受的构件概念,是POJO或JavaBean,即带有业务功能的领域模型。 而EOS中的构件实际上就是一个类中的函数。 根据我的分析,EOS实际上是将业务流 程定义在XML文件中,然后用固定出入口的许多函数来调用和执行流程。 按照它的这种方式,复用竟然具体到函数。 每个函数都是用的类似的参数,一般是XML文档和实体对象等。 EOS并没有给出系统接口或扩展标准,后续开发或扩展很困难,开发一个复杂的系统 风险很高。 标准,关系到EOS的成败。 EOS不适合技术型的开发人员使用。 大量雷同的操作和对核心技术的屏蔽会使热衷于 技术的人失去兴趣。 这平台对技术水平比较低,但对业务比较熟悉的技术支持人员可能会很有效。 软件开发是人而不是机器的工作,因此,人的能动性在开发中起了非常重要的作用。 忽视了对人的培养,只能带来更高的人员流动率。 EOS不能用于对现有OA产品的更新换代和移植。 但可以用来进行新领域的竞标等方面。 然而,不可忽视的是,由于EOS扩展的困难性和核心技术的缺乏,对EOS的依赖将不 可避免。 以上是我对EOS3.0的总结。 经过几天的培训,我认为EOS实际的平台比宣传的差很多, 目前仍不能用于真正的企业级开发。 另一篇关于普元的blog: 普元软件公司是国内专业的中间件提供商,从国家得到了不少投资,做出来的东西也是相当 的庞大。 最近普元EOS的宣传和发展的势头都很盛。 其宣传材料中屡次提到软件的涅磐这一用语,这明显是一种危言耸听之举,当然这在业内也不算什么新鲜的事情。 按照EOS的 宣传,”以图形化的构件组装方式画”出来的软件无论从结构上、形式上还是开发过程上都 堪称简捷而美的软件”。 这一提法倒是别开生面。 图形化与简洁,与美竟然还存在着这样必 然的联系,实在是一种创举。 从普元公开的资料来看,EOS的一个鲜明特征是全面基于xml描述,即所谓的xml数据 总线。 表面上看起来,xml结构内置于系统内核中似乎很时尚,但实际上,EOS产生的xml 描述文件中的大量条目都是EOS自身的结构要求,而与实际业务无关,即EOS描述文件中 的有效信息量密度很低。 这是一个危险的信号。 EOS的xml描述本身可以看作是一种完全 新的编程语言,但这个语言似乎没有什么抽象能力和组合能力,对于关联的表达能力也很弱 (到处都是数字id)。 如果直接手工编写,那是一件要死人的事情。 只有通过集成开发环境 的可视化界面,EOS才呈现出可理解的一面。 EOS的概念与LanguageWorkbench是不同的,其中的结构似乎很难进行有效的扩展。 而 所谓的xml总线技术更加剧了这一点。 xml数据总线其实与面向过程编程类似,只是过程变 成了service,数据变成了xml节点而已。 对象与简单数据结构在结构表达上的本质差异就在于对象通过成员函数可以封装动态结构。 虽然xml节点的表达能力远远超越了普通的数 据类型,但充其量也不过是对现有数据的规整的树形表示,并不具有动态计算能力(甚至是 最简单的lazyevaluation)。 丧失了动态计算能力,就意味着我们很难在系统中动态引入结构,程序中所操纵的结构都需要事前定义出来,这将极大的限制系统的可扩展性。 另一方面,xml 节点受限于自身格式,其描述关联的能力也要弱于java对象结构本身。 对象通过引用访问 相关对象,其隐含意义是对象处于同一地址(状态)空间中,可以非常自然的保证对象的唯 一性并实现同步访问。 在跨越状态空间的边界时,xml表示是有意义的,因为我们需要把所 有的结构都暴露出来并加以描述(外在化)。 而在状态空间内部,我们需要更加紧致有效的表 述方式。 在具体的实现中,EOS暴露给程序员的xml操纵API相当的原始,使用起来很繁琐。 在前台展示页面中,如果不使用EOS的界面组件,提取数据本身就是一种不小的困难。 EOS 的前台展示组件与后台的结合也比较弱,后台改变之后,缺乏有效的手段来检测并保证前后 台结构的同步性。 所谓的前台构件层似乎只是提供了一些帮助函数和功能固化的组件,并没 有提供什么有效的利于结构抽象和结构重组的机制。 整个EOS的构架看起来很象是一个monster,我很难想象它的各个部分如何才能独立的, 深入的发展下去。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 郑州 公交查询 系统