| 网站首页 | 下载中心 | 技术文章 | 图片中心 | 站内搜索 | 
最新公告：

  没有公告
您现在的位置： 源码仓库 >> 技术文章 >> 综合文章 >> 项目管理 >> 正文
[推荐]软件项目经验谈 DelphiUN.com
[推荐]软件项目经验谈
作者：hhytsoft 文章来源：论坛 点击数： 更新时间：2006-6-11 19:21:49
声明一点以下仅是本人的一些想法与公司的一些实际状况，有精华也有谬误，问 题多多，错误难免，仅希望对软件开发人员能有所帮助，欢迎大家指正与讨论。 写完后感觉没有把握好粒度，粗细不均。望见谅。 内容目录: (1)需求分析 (2)软件设计 (3)软件编码 (4)软件测试 (5)软件分发 (6)ER/Win (7)Datawindow (8)软件维护 (9)数据库 (10)类库与PFC (11)展望 当前位置：PowerBuilder天堂 --> PB编程 --> PowerScript --> 软件工程与PB十日谈之需求分析 需求分析 需求分析定义了软件产品的各种用户需求如功能、性能等，需求分析是否透彻、 完整、正确是软件项目成败的关键。通常供方派专业的系统分析员与需方合作， 共同定义需求。不过现在国内的软件公司似乎分析、设计、编码、测试都是几个 人从头做到尾。在需求分析过程中，时刻要坚持的一个原则就是“客户就是上帝 ”，不管客户提出了什么要求，能够实现的一定要实现而且要更好，不能实现的 也要约定好是将来实现还是放弃，尽最大能力满足用户要求。 在分析过程中，首先软件人员需要学习领域词典、用户词汇，特别是某些专业领 域如冶金、邮电等，可以找一些专业词典或入门书籍学习，通常学习程度不要求 很深，只要能同用户交谈、理解用户目的即可；另外还需要了解需方的一些情况 如行业特征等。与用户面对面交流前，通常需要制定一个计划，包括讨论的问题 、步骤等，否则具体交流时很容易忘记一些事项。可能的话，可事先将计划交与 用户，让用户做必要的准备。需求的讨论定义需要用户的实际参与，因此人际交 流也成为一个成败因素，分析人员要时刻为用户着想。讨论过程中，用户由于工 作忙、不懂计算机经常不愿意配合分析人员开展工作，分析人员应该能心平气和 的帮助与指导，诱导用户交流，可以从谈天开始，慢慢来，不要急噪，计算机对 某些用户是一种恐惧、毕竟还是陌生事物。交流过程中，刚开始，用户提出的任 何建议、想法都必须如实记录，分析人员要多听少说，了解用户想干什么而不是 不让用户干什么及软件如何实现，让用户充当主要发言人。随着工作的开展，分 析人员的知识的积累，分析人员就可以“多说”了。交流工作除了诱导，还需要 激发，总之为了透彻深入了解用户需求，必须创造一个能让用户随意表达思想的 环境。讨论过程中经常有术语不懂或体会不了某些用户要求，这些需要耐心的向 用户询问，了解清楚，千万不可放弃，这很有可能是关键的问题。 某些用户要求是不切实际、错误的，分析人员应该诚恳的倾听用户，提出解决方 案，帮助用户。最后，让用户该说的都说了，那么项目组里的各分析人员该碰碰 头，大家交流一下体会，对业务逻辑的交叉、接口部分更应该讨论清楚，并对后 继分析工作做规划。此时用户提出的要求包括自己认为是错误的、不现实的都要 列出来，大家讨论。分析人员形成了共同的决议后，再与用户交流讨论，如此反 复，直到用户、分析人员都对需求表示满意，本阶段的工作也就完成了。当然了 问题肯定还存在，今后的工作中还需要交流，故不要把用户扔在一边啊！。 本阶段提交的需求说明书通常包括如下内容:功能要求，接口要求（用户接口、硬 件接口、软件接口、逻辑接口），性能要求，设计约束，其他等。 回忆一下我参加的第一个项目分析。那天下午，项目经理突然提出要带我去见见 用户，我才想起来前几天曾向经理要求去用户那里了解一些问题。现在突然要去 了，我还没准备，怎么办？不管了，笔纸一带，路上边走边想，列举了一下想提 出的问题。到了用户那里，好紧张啊，第一次面对用户。经理介绍了一下就走了 ，剩下我一人，话不多说，解决了问题再说，马上步入正题。可惜经验不足，准 备不充分，想了解的问题忘记问了，问了的问题回到公司又给忘记了（本人自凭 记忆力好，故当时没有仔细记录），不过那天帮用户解决了很多实际应用中的问 题，软件、打印机啊，对俺的印象还可以，以后工作方便多了。直到现在，我们 还保持合作愉快。 以上是我的一点体会，希望能对广大的分析人员特别是刚涉足该领域的分析人员 有所帮助。谨记“用户就是上帝”！ 当前位置：PowerBuilder天堂 --> PB编程 --> PowerScript --> 软件工程与PB十日谈之软件设计 软件设计 通常软件设计分为概要设计和详细设计。概要设计的输出是模块层次图（模块划 分），IPO图（功能划分），数据流程图。详细设计的输出是数据库设计说明书， 界面设计和程序伪码。概要设计中模块的划分根据软件工程的原则要符合高内聚 低偶合。模块粒度可以小到函数、事件大到窗口、程序模块，模块划分完后，就 需要确定接口，可以用IPO图指出输入、处理、输出将接口明确下来。本人认为概 要设计与详细设计好比树枝与数叶的关系，树枝是脉络，数叶则是外观（界面、 操作）。详细设计对于PB类数据库开发工具而言，还需要提交数据库详细设计， 这是非常重要的文档之一。数据是基础吗！ 数据流程图通常可以通过需求分析过程中的业务流程图推导出来，一般只要变换 一下符号即可。DF图完成后，需要将其量化为数据字典，数据字典包括各种加工 、数据流、存储等，都需要将组成、频度、大小、功能用文字描述出来。现在很 多CASE工具可以自动根据DF图生成数据字典如PowerDesigner，我们可以借助这些 工具完成数据字典的书写、同步工作。 数据库详细设计包括表、触发器、存储过程、视图、ER图等，这些可以参考前面 的数据字典，进行必要的优化冗余处理。表即存储，要详细描述出表的功能、涉 及模块、特殊要求、数据来源，所有的表都要描述出各列的属性包括类型、名称 、约束、缺省值、索引等，对于代码/参数表还需要详细列出参数/代码；视图则 需要标明视图形成的机理包括基本表、计算字段，此外还有视图的功能、引用模 块；触发器、存储过程则需要将出入口参数、调用者、处理过程伪码描述出来， 对于触发器还需要将其宿主表、激活时间、处理级别描述出来。设计存储过程和 触发器时，按照C/S原则我们应该把计算部分、逻辑处理部分、安全部分交给后台 来做，既加快了速度又提高了安全性，总之不要让前台把工作全部包了。最后需 要描述出实体关系图，ER图可以用专门的CASE工具来完成，如ER/Win，PowerDes igner，ErStudio，它们灵活方便、支持群体协同开发，效率很高。此时实体分解 粒度问题又拉上案头，基本原则是按照几个数据库范式建立实体关系，最终的目 的就是不要发生数据异?吞岣叽硭俣龋实钡娜哂嘁彩侨峡傻摹Ｊ菘庀晗干杓 仆瓿珊螅筇ú糠忠膊畈欢嗔耍衷诳梢钥记疤ㄉ杓乒ぷ髁耍ń缑嫔杓坪 臀甭搿＝缑嫔杓瓶梢杂酶髦諶 AD工具本身的快速原型功能，也可以用专门的界面CASE工具如Visio，界面设计完 成后，可以参照界面设计写出处理逻辑的伪码，模块的伪码，函数事件的伪码， 详细程度达到程序员看到设计方案马上可以编码为止。当然我们还可以在PB中划 分出很多用户对象盛装业务逻辑/程序逻辑，在设计过程中也可以将其描绘出来， 这也是对设计人的OO能力的考验。 国内的公司对软件设计很不重视，项目来了就是开个会，划分一下模块，就开始 编码，编码成了关键的部分，可以说这是本末倒置，其实编码只占了开发工作很 小一部分，软件设计需要大量的时间定义、讨论、评审，形成大量文档。俺认为 如果软件设计做好了，程序也就不那么重要了，多加些人手，多花些时间是可以 很快就完成的，而且对于程序员的要求相应也降低了，他们只需按照文档编码， 只要将文字转换为代码即可。故软件设计好比建筑物的蓝图，没有它再好的建筑 工人（程序员）也是白费力气。 当前位置：PowerBuilder天堂 --> PB编程 --> PowerScript --> 软件工程与PB十日谈之软件编码 软件编码 软件编码工作主要由程序员完成，程序是按照设计方案的要求按照一定规则与步 骤完成的文档到代码的转换工作。 PB的PowerScript代码应该是比较简洁、直观的，代码编辑环境也不错，特别是P B7的改进吸收了很多RAD工具的优点，但工具只是设施、基础，还需要优秀的方法 指导。各公司一般都有代码书写规范如注释规范、代码格式规范、命名规范，界 面规范如GUI规范等，这些规范小到定义了变量名称大到模块名称，外观上有界面 规范内部有代码格式规范，按照这些预先定义好的规范可以写出可读性、可维护 性较好的代码。下面谈谈各种规范的制定与实施。 注释规范：PB中包含有事件、函数、对象等可注释对象，对于具体对象如窗口、 数据窗口、菜单我们都需要在Comment中标明名称；而事件、函数的概要性注释则 需要按照规定格式书写，一般包括如下项目：名称、功能、参数、返回值、作者 、修改记录等，它定义了函数事件的概要信息，这对于他人阅读代码是最为重要 的信息。我们可以在PB中使用一些代码公开的注释工具如PBComment等来完成这一 部分注释的书写。此外在事件/函数内部还有各种处理代码，故还需要就近书写功 能注释，这部分注释往往与具体代码段相结合而不是与代码行结合，即注释要说 明代码段的功能而不是一行行代码的文字描述，否则没有任何意义，费力费时。 代码格式规范包括代码对齐，代码布局等，一般都包含在代码命名规范中。好的 代码格式规范对于提高可读性、可维护性。一样是很重要的，现在的RAD工具一般 都支持一些简单的格式处理，但比较复杂的代码往往需要开发人员手工处理。 命名规范主要针对变量、对象。变量的命名规范有很多如匈牙利命名法等，一般 随具体语言的差异而稍有变化，可以参考PB的特点建立规范。PB本身对于对象名 称约定还是有默认设置的，但不完整，我们需要对各种对象（窗口、数据窗口、 用户对象等）加以命名约定，可以参考PFC、Pb example建立。 软件的界面美观、方便易用往往决定了软件的成败特别是商品化的小软件，故GU I规范更应该仔细制定实施。现在的界面一般都基于微软的Windows风格，它包括 各种界面元素如按纽、树、页面等，对这些可视元素（控件）应该制定一套涉及 大小、颜色、字体的一般规则及功能作用的约定。要严格区分使用各种容易被混 淆的元素如RadioButton与CheckBox,要确定一些控件的合理使用限度如Listbox与 DropdownListbox的列表数目，要严格要求在开发过程使用统一的、持续的一套界 面风格，在多人开发时更应该注意。现在的软件界面设计中往往出现很多稀奇古 怪的界面，无非是开发人员挖空心思展示自己的技术水平，不知道高手们有没有 认真研究过，殊不知用户才是真正的使用者、评价者。其实微软的界面是很不错 的，Bill有专门的界面实验室，各种Windows元素都是经过严格考虑实验才采用的 。界面优秀也是Windows系列产品成功的因素吧！我们可以学学MS的OFFICE系列产 品从元素布局到控件搭配，多看看GUI比较好的软件，提高自己的GUI设计水平。 此外不要忘了，中文与英文的GUI是有差别的，中文是方块字，方方正正，故应该 针对中文特点制定相应的规范，不可盲目照抄。 如何编码上面已经讲的很清楚了，剩下的就是对程序员编码效率的考验了。程序 员如何提高自己的水平，提高工作效率，我想就自己的体会谈谈。俺是学习了三 天PB就开始干活的，当然了不好意思刚开始是练习基本功：做报表。俺认为要想 提高水平一方面需要不断的学习，从书本上、从工作中，可以多看看别人的程序 ，多看看PB的例子，PB的例子是一套非常好的教材，从编码到界面设计到程序技 巧；此外就是多动脑多动手，敢想敢干。网络上各种Tip很多，多收集学习，也是 一个好方法。其它我就不多说了，诸位大侠，俺班门弄斧献丑了。 当前位置：PowerBuilder天堂 --> PB编程 --> PowerScript --> 软件工程与PB十日谈之软件测试 软件测试 软件测试在现代的软件开发中日益显示出其重要性，所花费的费用也越来越高。 测试按照典型的软件工程理论划分，分为单元测试、集成测试、系统测试等，此 外从其他角度还可以分成白盒测试、黑盒测试。软件测试工作往往分布于整个开 发周期中，测试的级别从函数事件测试到对象测试到系统测试。 编码过程中，编写一个函数、事件，一个对象的时候，需要开发驱动模块及桩模 块，测试方法一般采用白盒测试方法即分析程序路径（事件、函数、分支）、条 件（判断），尽可能的遍历程序，引发错误。采用的方法有等价量划分、边界值 等，将代码中的所有路径包括合理合法的与非法的都走一遍，测试的过程中会发 现某些路径无法到达，此时可能是代码位置错误或代码本身有错误，修改完毕后 ，回归再测；可能还会发生很多的意外，如用户突然点击某个按纽或用户未按照 程序员设想的路径回答“YES/NO”，这些例外情况我们也应该考虑入内加以处理 ，使程序更健壮。编码工作完成，单元测试也已经完成。现在可以开始集成测试 了，将开发小组内的各个模块联合运行，检查整体能否正常运转，但前提是单元 测试一定要通过，千万不能在单元测试未通过的情况下联调，否则不仅工作效率 不高，而且可能引发其它问题。联调的过程中往往发现的问题是接口、约定、惯 例没协调好，各个开发人员应商量清楚，如何处理，加以纠正，再联调，如此反 复，直到联调通过。 为了在给用户交付安装过程中不致发生意外情况，一般还会模拟用户环境，进行 系统测试，如需要远程通信，远程数据处理等。经过系统测试会发现很多想不到 的问题，如线路速度、网络带宽、用户环境等。因此该测试还是十分有必要的特 别是需要大规模分发出去的软件及用户环境复杂的系统。 集成测试与系统测试都需要制定测试计划，书写测试用例，测试工作完成后还应 该有测试报告。测试计划规定了进度、资源安排，而测试用例则定义了测试数据 等，测试用例一般包括用例名称、用例目的，测试方法，期待输入、期待输出、 实际输出等，实际输出可以在具体测试工作进行的时候填写，其他项目可预先完 成。测试完成后，针对错误类型、数量写出总结报告——测试报告，要分析出错 误规律、原因、解决方法，并反馈给开发部门以提高代码质量。测试用例都需要 留存，供回归测试等使用。为了方便测试，可以制定一些CheckList，对照它检查 问题，项目可多可少，但需要注意可操作性及确定性。 下面谈谈测试过程中CASE工具的使用。PB本身的Debuger功能是非常强大的，可以 完成断点、单行跟踪、变量观察等功能，用Debuger观察路径，观察变量变化，程 序员在单元测试过程中使用的最多的恐怕是它了。在测试数据库的过程中，我们 可以使用Trace功能，即在事物对象如SQLCA的DbName属性中的实际名称前加“Tr ace”即可，系统会生成一个SQL语句记录文件，对于我们分析数据处理过程有很 大好处。测试数据的生成使用手工方法往往效率不高，在需要大量数据的情况下 更不可行，比如强度测试，可以使用一些测试数据生成工具，这些工具可以快速 灵活的生成数据。另外测试过程中的测试结果可以用专门的BugReport工具管理， 记录跟踪错误，防止遗漏问题。 软件测试对于提高开发人员水平特别是刚入门的开发人员水平有很大作用，通过 测试工作可以学习他人的代码风格、界面风格、软件风格，通过测试可以学习他 人的技巧，可以锻炼耐心。 当前位置：PowerBuilder天堂 --> PB编程 --> PowerScript --> 软件工程与PB十日谈之软件分发 软件分发 软件测试完成后，产品质量通过了确认，就可以提交给用户使用了，这其中有一 个编译、发行的过程。 PB应用的编译方式有二种：P-Code方式，DLL方式。P-Code方式即PBD方式，程序 体积小打包速度快而DLL方式执行速度快但打包速度慢，有时可能无法想象需要数 个小时。DLL方式的编译过程是先将PowerScript语言翻译成C代码，然后用SYBAS E的Watcom C编译器编译成二进制代码，可以想象速度的确比较慢了！一般而言，发行的各种 应用都是PBD方式，特别是大型的项目，PBD方式稳定性强。如果程序中使用了某 些特殊功能如动态切换数据窗口对象，则应该打成PBD文件。如果程序中使用了P B的COM组件功能，则该COM组件必须打成DLL，PBD两种格式，否则该COM组件无法 正常运转。PB生成的COM组件的DLL只是一个COM函数头，实际处理代码在PBD中。 程序打包过程中各种资源文件如.Ico，.Bmp等需要一并打包。方法有两种，一是 将资源文件形成PBR文件打到PBD里面二是不打进PBD，直接作为应用程序的文件存 在。 打包完成后，形成了EXE文件，DLL文件，PBD文件等，此时可以制作安装程序了， 但不要忘记了PB的相关系统DLL（PBVMxx.dll、....）及与具体数据库相关的DLL （PBORAxx.dll,PBSYBxx.dll）、特殊功能的DLL（PBRTFxx.dll、....），这些文 件都需要完好无缺。如何知道自己的应用需要那些DLL支持文件呢？可以使用DLL 调用监视工具，查一些文档，配齐所有的文件后可以到其他“干净”的机器上试 一试，不要有遗漏的。 制作安装程序的工具很多，如Installshild，SetupFactory等，Installshild功 能强大，SetupFactory制作速度比较快，但功能简单，但一般的也够用了。制作 安装程序时，需要配置安装交互界面，系统文件修改，注册表的修改等，此外可 以将数据库的客户端与自己的应用作在一个安装程序里，这样安装时自动安装、 配置好了数据库，省时省力。 安装程序制作完成后，可以到其他机器上实验一下，在各种环境下是否有问题， 千万不可掉以轻心。现在的机器用过一段时间后已经非常不“干净”了，还需要 重装几台机器作些测试。 上述一切都可以了就可以刻盘了，一般要制作光盘的AutoRun文件，使界面更友好 ，还有Readme文件。 在编译过程中可能会遇到很多古怪的问题，比如无论如何编译，却总是半道中非 法操作，或者生成出来的文件一执行就非法，此时可以检查一下机器是否有?荆 梢园汛朐僦匦律伞⒂呕钡矫挥幸凰烤婧痛砦筇崾尽５惺被故遣恍校 馐亲詈貌灰俅虬耍菹⒁幌掳桑≡谡馓ɑ鞴兰撇豢赡芰耍惶ɑ鳎 梢粤税桑飧龇椒ū冉狭楣獍。?BR> 还强调一点比较幼稚可笑的问题，在编译、 制作安装程序、刻盘的过程中软件一定要保持“干净”，不要感染?荆裨?.... ... 俺用过很多软件，其中有很大一部分可能是自己动手编的安装程序，安装界面不 友好（特别是国内的小软件）；还有一些安装程序可能做了不该做的事，或该做 的事情没作完导致安装完后机器启动不了了，一查原因或者是把Windows的几个重 要的DLL搞成了0字节或把批处理文件整没了，这样的软件俺再也不敢碰了。因此 各位制作安装程序时，一定不要做不该干的事情，一点多余的事情也不要做，也 不要对用户的系统做任何假设，时刻保持仔细严谨的作风。 安装程序是用户第一次接触你的系统，千万不要破坏了“第一印象”啊！ 当前位置：PowerBuilder天堂 --> PB编程 --> PowerScript --> 软件工程与PB十日谈之ER/Win ER/Win ER/Win是CA公司的建模产品的主力，多次获得大奖，感觉方便易用、功能强大， 现在最高的正式版本是3.5。下面是本人的一些体会，如有错误还望笑纳。 ER/Win主要用来建立数据库的概念模型与物理模型，能用图形化的方式描述出实 体联系及实体的属性，它支持两种建模方法（IDEF1x和IE），一般使用IDEF1x方 法，两种方法的具体建模规则请查阅有关资料。ER/Win建立的物理模型可以针对 各种数据库自动转换为适当的类型，并生成进数据库中，它支持各种主流数据库 如SQLServer，SYBASE ASE，Oracle等，同时ER/Win还可自动建立索引、触发器等，这些工作的自动完成 极大提高了开发人员的工作效率。ER/Win支持逆向工程即将物理数据库中的模型 反向生成ＥＲ图，将物理模型以图形化的方式表达出来，它支持双向比较、同步 ，这对于开发人员检查核对模型的一致性非常重要。ER/Win支持的前台工具PB， VB等，对于PB，它可以设置生成各种PB的一些属性放在PB的系统表里，该功能大 大提高开发人员的效率，它可以生成PB的数据窗口，虽然不是很美观。此外ER/W in非常易于使用，简单的鼠标拖动即可完成大部分工作。它有一个报表工具类似 与Datawindow Builder，可以设计出非常美观的报表。ER/Win对中文支持也比较 好，但不是很稳定。 下面谈谈如何使用：由于手头上暂时没有该软件，只能按我的记忆来，介绍一下 步骤。首先NEW一个文件，选种菜单项目中的ToolBox，显示出工具箱。工具箱大 概分为如下部分：实体（方框），关系（线），操作工具（手）。点击一下“实 体”，然后在文件中用鼠标左键点击一下，会出现一个实体，各实体有默认的名 称，每点击一次出现一个实体，点击工具箱中的“光标”将暂停实体建立功能。 选中一个实体，点击右键出现一个菜单，包括编辑实体的逻辑属性、物理属性、 触发器、索引等功能项目。选中实体逻辑属性编辑功能，出现一窗口，可以输入 实体名称、实体的键属性与非键属性，编辑完成后可以编辑实体的物理属性，需 要设置实体的物理名称，字段的物理属性包括名称、类型等。全部完成后，可以 建立实体之间的联系，先在工具框中选择选中一种“关系”，再分别点击一下源 实体、目标实体，它们之间的联系就建立起来了。通过菜单上的逻辑模型、物理 模型切换功能可以看到不同的模型表示。最后选择Forward Engineer即可生成物理模型。其它功能我不多写了，大家自己摸索吧！ 在建模过程中ER/Win对每个字段都建立了默认的属性如长度等，当实体比较多、 修改又比较频繁的时候，往往忘记了将字段的默认属性改为实际属性，特别是有 些字段实际属性与默认属性相同，特别容易遗漏，我们可以修改ER/Win的字段默 认属性为一个不常用的属性，这样就比较容易发现问题了。在一个文件中如果有 多个实体的某些属性相同，如金额等，手工一个个改就比较罗嗦了，而且同步也 是问题，特别是字段比较多的时候，这时可以采用Domain，一个Domain代表一类 共同的属性（包括物理类型、约束等），我们可以建立金额型的Domain，以后修 改金额Domain的时候所有使用该Domain作为类型的字段都会自动随着修改，不用 一个一个修改，可以看出Domain类似于数据库中的自定义类型。ER/Win默认对于 在一个文件中的实体及属性的同名是不允许的，如果出现同名系统自动在其后加 上数字，我们可以修改系统设置，使得不同实体间的字段同名是允许的。 最后谈谈ER/Win的文件交换。对于面向对象的建模工具如Rational Rose ，ER/Win提供了附件可以在ER/Win模型与Rose模型之间单向转换，现在仅限于 3.5的版本；对于其他的结构建模工具如Sybase Power Designer，ER/Win可以使 用ERX文件与其交换数据。 最后补充一点，Sybase 的 Power Designer建模功能不错，可惜本人没有好好用 过它，它对于PB应该支持的更好，现在已经有7.0的版本了，支持OO，界面改动也 较大，类似VC。 当前位置：PowerBuilder天堂 --> PB编程 --> PowerScript --> 软件工程与PB十日谈之Datawindow / Datastore Datawindow / Datastore Datawindow，数据窗口，作为PB的精华，可以说PB的大部分价值就体现在它身上 了。下面从原理、功能上谈谈我的体会。 Datawindow控件实质是一个窗口，而Datastore则是一个隐藏的窗口，即Visible ,Redraw属性都为假，这也是为何Datastore操作数据比Datawindow更快的一个原 因，它占用的系统资源更少，消耗的系统时间也更少。既然Datawindow与Datast ore 是一个窗口，那么窗口所具有的属性、消息如打开、关闭、重画它们也有。了解 这些对于深入应用数据窗口是非常也好处的。Datawindow与Datastore从某种程度 上讲是一个中间件，在用户界面与物理数据库之间加了一层功能，将它们隔离开 来，给用户界面提供更友好的数据操作，给数据库提供更稳定的数据显示。Data window作为一项专利，是Powersoft（原来的PB开发商，后被SYBASE收购）向美国 国家专利与商标局注册的。 Datawindow/Datastore控件其基本原理就是Datawindow提供了数据显示界面的格 式位置定义，而Datawindow控件提供了数据操作方法与数据容器。为此PB为Data window控件提供了操作数据库的函数与几个缓冲区（Primary！，Filter!等）， 为Datawindow提供了几个显示层次（Foreground、Background等）。用户使用Da tawindow控件的数据库操作函数，系统自动转换为特定数据库的SQL语言，提交给 数据库，待后台完成后 ，将数据返回给Datawindow控件，Datawindow控件再根据Datawindow的格式定义 将数据显示出来；另外Datawindow控件还要根据 Datawindow 的属性控制事物完整性等，还要处理一些自己特有的数据处理功能如Filter等。 Datawindow控件除具有Windows的窗口的属性与事件还有自己独特的函数与事件， 如Retrievestart、Retrieveend、SqlPreview、Printpage等事件与Update，Reset 等函数。这些事件有些是系统自动触发的如Dberror,SqlPreview等，这些事件一 般都有参数或有相关函数可以获得事件信息，因此我们可以在这些事件中获得、 修改数据处理信息。Datawindow函数需要手工调用，包括有关于后台数据处理的 Datawindow控件函数，与SQL语言类似，是SQL语言在Datawindow中的表示；有前 台数据处理的Datawindow控件函数如Getitem,Setitem等；还有前后台协调的函数 Retrieve等。Datawindow定义了数据的显示界面属性及与该Datawindow相关的数 据库对象的数据操作属性。界面显示风格一般分为FreeForm,Grid,Composite等， 每一类风格还可以定义内部的显示属性如数据字段显示风格、颜色、字体等，还 可以在内部添加控制如按纽、OLE、计算域等，而数据操作属性包括后台数据操作 属性如UpdateProperty，前台数据操作属性包括Retrieve Property、Filter Property，这些属性在Datawindow处理前后台数据时都要用到，因此如果修改了 这些属性，Datawindow控件处理数据的属性也就自然修改了。 下面谈谈Datawindow的数据交互过程。用户通过Datawindow控件的函数如Retrie ve检索数据，Datawindow控件把自己的DataObject属性对象的SQL语句提交给后台 数据库，后台数据库检索数据将结果返回给Datawindow控件，Datawindow控件根 据Datawindow的格式定义显示数据设置那些字段显示、显示在那个位置、字体及 Head、Foot、Sumary等，同时计算计算域，相关事件也会触发，直到后台检索数 据完成。完成后Datawindow控件的几个缓冲区也被赋了值，修改数据时，Datawi ndow对象的字段状态（ItemStatus）在更改，删除、过滤数据(Delete，filter) 时，数据在前台的几个缓冲区移动，并没有实际提交给后台，直到用户一旦提交 ，修改就转化为SQL语句提交给后台数据库了。 Datawindow的技巧很多，我也不重复了，谈谈几个方面。常见到很多的数据窗口 对象布满了计算域，殊不知这既影响速度也不符合C/S原则，数据窗口中计算域能 作的事情大部分用视图都可以完成，而且在后台计算速度将更快，数据一致性更 高，同时也符合将业务逻辑分离的原则；数据窗口对象的大部分属性都能够用函 数表示，这样数据属性将能随数据变化而变化，可以作出很多特殊效果，但不能 太多，否则性能效率将急剧下降；很多程序员图快图省，作的数据窗口对象字段 位置不仅乱，TabOrder也没有按照“从上到下、从左到右”的原则设置，另用户 找不着北，此外字段的编辑显示格式也前后不一致，这些对于用户方便快捷的数 据处理非常不利。我们应该注意这些问题。 当前位置：PowerBuilder天堂 --> PB编程 --> PowerScript --> 软件工程与PB十日谈之软件维护 软件维护 软件维护工作一般发生在客户使用软件产品的过程中，通常分为如下几类：适应 性维护、完善性维护、纠错性维护。适应性维护指系统环境的变更导致系统的修 改，如OS平台的改变，数据库平台的改变；完善性维护包括增加新的功能或改变 已有的功能，使其更符合用户的需求，比如：用户要求增加新的报表，增强统计 功能等；纠错性维护使指排除在用户使用过程中发现的错误。 整个维护过程需要建立一套体系，即维护管理体系。对于产品的维护不能随便进 行，要求建立申请——判断——实施——检查的过程，也就是任何维护工作都要 向有关部门申请，相关部门判断决定是否实施及实施优先级，维护完成后还需要 检查确认，上述维护工作都要有记录。 软件维护费用在软件产品的开发费用中占了很大一部分，应该说是最难的工作， 开发人员最不愿意作的工作，特别是在没有文档的情况下。如何提高维护效率呢 ？首先开发过程中各种文档一定要齐备、同时要保持与代码的同步，此外代码书 写过程中遵循一定的规则（命名、注释等）。有了这两部分，维护工作就不会无 处下手了。 维护工作中最常见的问题是错误扩散，主要包括纠错性维护错误扩散与完善性错 误扩散。在纠错过程中，往往纠正了这里的错误又引发了其它地方发生错误，特 别是全局性的函数、变量、过程、结构体的修改一定要慎重，此外各种接口的修 改也要慎重，千万不要引发其他的错误。完善性维护增加了新的功能，也增加了 出错的可能，对此一定要反复测试，最基本的要求就是不要破坏已有的正常功能 。 维护活动完成后，一般要进行回归测试，可以利用测试阶段使用的测试用例完成 回归测试，回归测试完成后才可交付用户使用。到底是直接取代用户现在使用的 老系统呢还是新旧两套一起并行运行呢？如果系统不是很重要，则可以马上取代 旧系统，应用修改过的新版本；如果对用户利益重大则最好新旧一起用，互相参 照监督，防止新版本出现了老版本没有的问题，直到用户确认了新系统。维护版 本交付前，涉及软件的数据库等相关资源都要备份，保证安全。 下面谈谈维护技巧。在执行状态下，如果出现错误可以用命令行加上 “/Pbdebug”来执行程序，当然了打包的时候要求Trace信息要包含，系统在执行 PB应用时会产生一个文件，大家自己看看吧！另外如果维护过程中需要修改一些 变量、结构体、接口等，如何发现那些代码涉及了这些待修改的对象呢，可以用 PB的FIND功能，将所有引用全查出来。 维护工作是辛苦需要耐心的，希望大家都能作好它！ 当前位置：PowerBuilder天堂 --> PB编程 --> PowerScript --> 软件工程与PB十日谈之数据库 数据库 PB的强项是纯数据库开发，下面就谈谈如何更好的结合使用PB与数据库，发挥出 两者的最大功能。 数据库本质上讲上一个容器，一个盛装数据与规则的容器。各种桌面、企业级数 据库很多，但原理功能都差不多。存储管理数据的功能依靠数据库中的表实现， 表定义了各个数据项目的类型、大小，为数据存储提供了一个格式定义；而管理 规则 则包括视图、存储过程、触发器等，这里将视图作为一种规则，而不是管理数据 的方式，因其实质是表的抽象，具体数据仍然来源于基本表。存储过程、数据库 函数类似于一般程序中的函数，是用PL/SQL、T/SQL等数据库结构化语言书写的存 储于数据库内的逻辑；触发器是一种特殊的自动调用的逻辑代码，同样用数据库 结构化语言书写，它依附于表上，当对表进行插入、修改、删除时自动被激活， 完成适当的逻辑处理。触发器很多情况下是作为系统自动调用的强制执行的逻辑 来完成诸如数据复制、更新、日志等功能，它由系统保证与激发它的事物（Tran saction）成为一体，一同提交、回退。 PB中没有数据存储功能，只有逻辑管理功能，它有类似与视图的Query、Datawin dow，有类似存储过程、数据库函数的各类函数，类似约束的界面校验规则，类似 触发器的事件处理。 Query、Datawindow封装了表或视图，为操作数据库提供了一层隔离机制；而函数 则是用PowerScript书写的独立与具体数据库的逻辑；界面数据校验规则是数据库 约束的界面表示，它将更及时、有效地反映约束。以上规则定义的管理功能是不 能共享的，但是如果将函数等定义为COM/CORBA组件就另当别论了。 既然在很多功能上数据库与PB有功能重复，我们如何处理好他们之间的功能分配 与协调呢？下面针对C/S模式说说自己的看法。业务逻辑如果是处理数据的或负责 大量计算或需要经常改动的则可以放在后台实现。对于数据处理、逻辑计算前台 只需请求结果，后台返回结果，减轻了网络负担与客户机负担；对与需要经常改 动的逻辑放在后台，那么后台的修改对于前台是透明的，只要接口不变，那么前 台应用程序无须做任何修改；同时需要各个模块共享的逻辑也可以放在后台。对 于那些与界面相关的、与用户交互相关的、与外设相关的我们可以用PB实现。比 如打印、窗口布局等。约束规则在数据库的后台定义将更加安全，但仅有这些是 不够的，用户需要的是即时的反馈机制，特别是对于系统使用生疏的用户。我们 可以为Datawindow各个字段建立校验、可以在Datawindow控件的相关事件中写检 查代码， 但同时不要忘了在数据库中也要写约束，防止漏网之鱼！ PB的Datawindow有一些属性如Retrieve，即Retrieve as Needed,Retrieve to Disk,这些能加快系统响应速度，但根本的加快处理速度的办法在于后台，因为前 台是多种多样的，我们不可能考虑的了全部前台环境，但在后台我们可以使用索 引、分区、条块等方式加快速度。Datawindow有一个Filter属性，类似于SQL的W HERE子句，但是除非与具体客户环境相关，最好用SQL的WHERE实现，这样可以大 大加快速度。很多开发人员写出类似于触发器的东西，自己用PB编码完成一致性 处理，如主子表等，但这是系统不安全、数据不完整的一个漏洞，后台做的事情 没有必要拿到前台来做。最后讲下数据库透明，即程序应该隔离开数据库，提供 给用户一个更友好的操作数据的界面，这也是程序的最终目的吧！ 当前位置：PowerBuilder天堂 --> PB编程 --> PowerScript --> 软件工程与PB十日谈之面向对象与类库 面向对象与类库 面向对象是现在的RAD工具都支持的特性，PB也不例外。下面就OO在PB中的应用及 PB的类库谈一点体会。 OO的几个特征如对象、继承、封装、消息等在PB中称谓不大一致，PB中有用户对 象、窗口、菜单等对象，这些对象都支持继承、封装等，但不支持多继承；消息 表现为函数和事件。为了提供封装，PB定义了一些属性修饰符，如Pbulic,Priva te等。虽然PB没有类似于DELPHI的VCL，VB的VBX（OCX），但它的用户对象是非常 有特色的，用户对象作为OO的最直观体现，应用也最多。 PB中面向对象环境的另一个体现就是PFC类库，这个PB附带的类库完全尊从OO，虽 然推出没有很久时间，但是应用已经非常广泛了。PFC的核心是消息循环与服务机 制。各种程序消息被自动路由到合适的对象，而用户无须关心具体的对象，只需 简单的发送消息即可。PFC将各种功能定义为服务，开发人员使用时只需要声明那 些服务需要使用，系统将自动调用相应的服务例程处理，使用起来简洁高效。PF C中的各种服务包括安全、调试等，此外PFC还预先封装了系统的各种控件，提供 一些有用的用户对象，最大的好处是提供源代码。 类库的益处是几个方面的：首先提高了系统的开发效率，各种预先定义的可视、 不可视控件、对象使得开发人员无须重复编码，只要使用即可，随着开发工作的 进展，开发人员会不断增加新的构件，类库功能也越来越强大，这也是类库自我 完善的过程；类库也增强了程序的稳定性，代码、功能的复用意味着同一功能的 实现只有一个，大家共同使用，这样测试的的人更多、测试的时间将更长，因此 类库将更加稳定；此外类库还增强了程序的一致性，封装好的GUI对象，各种统一 的反馈信息，将以一致的方式出现在用户面前，不用担心不同开发人员的界面风 格问题，界面将更加友好。 PFC类库是一个庞大的体系，实际应用中很多功能往往使用不到，而且又是英文版 ，用起来不是很方便，实际上虽然类库比较复杂，但我们自己完全有可能做一套 类似的东西，将更加简洁，对中文应用支持也更好。国内已经有公司从事这方面 的工作了，如深圳的齐谱类库。还有一些开发团体自己有一些类库，但基本上未 成体系，停留在简单的用户对象的管理。在国外这方面开发很广泛，很多公司从 事PB类库的开发，有针对各个行业的类库如金融类库，有针对不同国别语言的类 库，他们出售源代码及良好的技术支持，对于新特性他们支持的也更快，大都拥 有自己特色的功能，完全可以与PFC一比高低。 以上说明了类库的应用，大家有兴趣可以应用、开发出更好，更完善的类库。 当前位置：PowerBuilder天堂 --> PB编程 --> PowerScript --> 软件工程与PB十日谈之展望 展望 面向对象是现在与将来都热门的技术，通过将面向对象方法贯穿软件过程，形成 了面向对象分析、设计、编码、测试等。尽管现在还不是很成熟，但国外的应用 已经很广泛了。UML语言，统一建模语言，一种标记方法，将取代SA/SD建模语言 。Rational Rose是对UML支持比较好的工具，并支持PowerBuilder。组件技术包括COM和CORB A两大类。COM组件由微软主要支持主要应用与桌面领域；CORBA由OMG团体定义， 主要应用与高端领域。PB支持COM/CORBA组件的开发、调试。N tier 技术现在异 常流行，从C/S 、B/S到 其它开发，PB完全支持，当然了要借助 EA Studio中的 其它工具。...... 看来只有不停的学习才能不落伍啊！这也是程序员的.....
  • 上一篇文章：

  • 下一篇文章：
    • 【字体：小 大】【发表评论】【加入收藏】【告诉好友】【打印此文】【关闭窗口】
    　　网友评论：（只显示最新10条。评论内容只代表网友观点，与本站立场无关！）

    | 设为首页 | 加入收藏 | 友情链接 | 关于我们 |

    源码仓库 http://www.delphiun.com
    豫ICP备05002841号 Copyright(C)2005 源码仓库 Delphiun.COM. All Rights Reserved.