我在美国的研发经历分享.ppt

《我在美国的研发经历分享.ppt》由会员分享，可在线阅读，更多相关《我在美国的研发经历分享.ppt（131页珍藏版）》请在三一办公上搜索。

1、我在美国的研发经历分享,甲骨文公司 仲秋MAIL:,背景,本人科大毕业后在软件所特宝科公司做开发软件工作，在亚里桑纳大学取得硕士学位后，前后在爱德华(J.D.Edwards)、仁科(PeopleSoft)、甲骨文(Oracle)三大公司做软件开发工作。主要的工作范围：维护和开发中间件。维护和开发应用软件的构件开发平台，调试平台和运行平台。对运行平台实现代码的分析，优化和二次开发。本报告不代表任何公司见解和立场，不妥之处请指正。所讲内容可从以下提供的线索找到，但本报告是以我亲身经历来谈我的体会。,参考资源,WIKI http:/wiki.org/wiki.cgi?WhatIsWikiSystem

2、s Life Cycle http:/www.house.gov/cao-opp/PDFSolicitations/SDLCPOL.pdfISO9000 http:/www.iso.org/iso/en/iso9000-14000/index.htmlUML http:/www.uml.org/，http:/www.visual-Design Patternhttp:/en.wikipedia.org/wiki/Design_pattern_(computer_science)Borland CaliberRM http:/Together http:/Project Server http:

3、/JDeveloper http:/Test http:/en.wikipedia.org/wiki/Unit_testingIBM WSAD http:/TestDirector http:/QuickTest Professional http:/LoadRunner http:/WinRunner http:/http:/www.junit.org/index.htmJsUnit http:/http:/Ant http:/ant.apache.org/Boland StartTeam http:/SourceSafe http:/Rational ClearCase http:/htt

4、p:/http:/Optimizeit http:/Web Studio http:/Suite http:/,报告安排,目的：学习国外经验，指导国内发展第一部分：公司中的开发过程的各模式概述。多部门合作的、多环境、多级(多平台)、多阶段、多代码视图、和工作流开发模式。第二部分：在软件开发周期或各阶段中各环节的工程技术和工具。每个环节分五个方面讲述挑战问题、解决办法、工作流程、工具介绍和个人体会。,报告目的学习国外经验，指导国内发展,国内策略学习经验正确起步避免弯路快速跟上改进创新,国外发展长期摸索总结经验吸取教训竞争淘汰技术领先,第一部分：软件企业中的各开发模式概述,1.1 多部门合作的模式

5、1.2 多级（平台）的模式1.3 生命周期的多阶段模式 1.4 多种代码视图模式1.5 多环境开发的模式1.6 工作流开发模式,1.1多部门开发模式-软件开发的部门分工,总经理,应用开发部,工具开发部,质量保证部,产品维护及客户关系部,营销决策部,研究部门,后勤人事部,测试员,维护员,文档员,客户方,领域专家,产品主管,构架员程序员部署员,1.2 多级（平台）的开发模式-二级开发,二级用户,应用开发部,工具开发部,最终客户,应用构件开发,管理,调试,测试平台,应用产品,应用运行平台,开发,开发,使用,使用,运行,应用程序的商务逻辑(4GL),3GL(JAVA,C+),使用,应用配置平台,使用,

6、应用开发部,工具开发部,最终客户,应用开发部,工具开发部,所谓二级开发、二级用户,由工具开发部门根据总体框架用第三代语言设计和开发构件库及各种工作平台。由应用开发部门根据用户需求用4GL二次开发、组装构件,制订应用产品的商务逻辑.工具开发部门开发应用配置平台.工具开发部门,应用开发部门和最终用户都可以使用它配置自己的工作环境。(不同的商务逻辑和商务数据)工具开发部门开发提供运行平台,使用用户配置的商务数据和应用开发部门配置的商务逻辑,合并成最终的产品.,多级开发的优点,加强知识和技能的分工细化,降低开发员的素质要求和开发的复杂度,利于人才的招聘和分配,提高开发效率。分离商务逻辑和构件工具实现逻

7、辑(商务引擎),实现体系结构一定程度上的松耦合。多条产品线可以在两极并行发展。给予最终用户和测试员一定的自由度去组合各种工作环境。开发员可利用交叉测试的策略孤立故障到应用层或工具层。,组合出各种工作环境,第N-1代运行平台(商务引擎),第M-1代应用的商务逻辑,应用部门工作环境,工具部门工作环境,第M代应用的商务逻辑,第N代运行平台(商务引擎),测试部门工作环境,多级开发的潜在问题,各级开发部门不了解彼此的领域知识和实现。在调试一个具体的应用产品时难以独立完成。对构件和工具的功能和约束条件存在不同的理解和假设，易在问题责任上纠缠。,避免多级开发问题的策略主要靠统一文档资料和规范,对构件和工具的

8、界面,功能和约束条件制订公开,详细,与产品同步和易查阅的界面文档资料.双方以此为依据,作为责任仲裁依据.(建议使用版本控制的超文本或WIKI)如在实际应用开发和使用中发现文档资料中的含糊不清和缺陷的地方,双方开发代表要及时统一规范,落实到界面文档中.对新构件和工具功能的开发,要双方开发代表(stakeholder)共同协商需求,权衡代价和利益,设计测试,补充界面文档,并以签字标志通过.在运行平台上,在商务逻辑调用构件界面的地方,实现详细的日志(包括构件,功能名,参数和返回值).一半的责任问题可单纯的审查日志来决定.在升级测试阶段,工具开发部先通过自己的测试,在交给应用开发部测试,以防止工具层的

9、问题困扰应用开发层.,1.3 多阶段/周期的开发模式,一步到位式开发big bang delivery(小项目),渐进式迭代开发evolutionary delivery(大项目),举例,每个阶段/周期又细分为若干环节（分别适用于工具和应用层）,需求计划设计编程测试,部署维护产品补丁及升级体系结构重构评估和优化,1.4 多视图(代码视图)的开发模式,主产品视图(开发员和维护员工作交接点）子项目开发视图（开发员工作视图）对应已部署在客户方正在使用的视图（维护员工作视图）,主产品视图,子项目开发视图,子项目开发视图,客户方正在使用的视图,分支,归并,上线,分支,归并,上线,1.5多工作环境的开发模

10、式-是通过配置平台控制的,开发环境(Development Environment)是应用或工具开发员自己的工作环境(sandbox)，没有特定的商务数据。测试环境(Test or Staging Environment)是测试员自己的工作环境包含测试员的对客户环境模拟商务数据,用于回归测试,一般不允许开发员过多的直接操作。商务数据被定期初始化。客户产品环境(Production Environment)客户端的实际使用的商业环境,不允许开发员和测试员直接操作商务数据。,1.6 工作流开发模式-控制软件开发流程及其管理系统,横向由分工很细的团队组成部门(who)，这是为了更快地开发出优质的产品

11、，在市场竞争中生存下去。纵向按生命周期(when)中需求、计划、设计、编程、测试、部署（编译和集成打包）、维护、再开发和产品补丁升级的几个环节。每个环节中，各团队分别完成整个开发过程中的某些职能，并合作组成一些工作流，由此组成了职能流程图(what)。通过软件开发工作流程的管理系统(how)来协调和组织各团队的开发工作。(它与国内目前采用的项目管理系统略有不同)。,以工作流方式用文档和规范来管理的管理系统,管理系统是用于管理工作流程的软件。各工作流之间是通过工作单来连接，项目和维护的开始创建工作单。流程表现为工作单按内部状态机规则在状态间流动。工作单属性包括：问题描述，重要度，从属分支，讨论，

12、解决方案等各种文档。系统根据工作单当前状态通知下一个接受者，并还优先权加入接受者的工作单队列。接受者（程序员，测试员，客户，经理等）的对工作单的不同状态有不同的控制职责，权限和规定。工作单的终点是项目的解决或推翻。三大公司都有自己的独立开发的管理系统，融合了自己公司的管理特性。由于工作单的细节属于公司内部的知识产权，不易公布。,举例：简化的维护过程中的工作单状态图,答疑：可提问,？,第二部分：软件开发生命周期中各环节简述,我将按如下统一的格式介绍开发生命周期中的几个环节.每环节分以下五方面讲述：挑战问题解决办法工作流程工具介绍个人体会,趣味案例想一想问题的本质是什么,问题案例一:安装盘失败案例

13、问题案例二:汽车车窗失败案例问题案例三:键盘的低效格式,2.1 形成需求报告,2.1.1 挑战问题形成”需求报告”的重要性和复杂性,重要性维护中发现的问题多数根源于需求。需求错误:设计错误:编程错误=-100$:-10$:-1$:复杂性不稳定，常修改。(需求管理问题)难完整，多漏洞。(用例不足和完整性问题)太含糊，难测试。(精确度问题)多矛盾，难理解。(逻辑正确性问题)太复杂，难实现。(过分追求可用性)太简单，不实用。(过分追求低成本)太混乱，没条理。(规范化组织化问题),2.1.2 解决办法,由构架师与领域专家、编程员、产品主管等人员共同完成、并达到可用性和可行性的平衡。标记认同签名和需求锁

14、定。修改方案要重标签再通过。遵循填写格式和保证各主要抽象层间的互相追溯关系和优先权。避免使用含糊词汇（如也许，多，界面友好等）和定义有特别含义词汇。,2.1.3 需求文档形成的抽象结构图,主要抽象层的定义和追溯关系,商业需求：客户的高层需求（市场需要，商业目标，主要特性，客户简历等）,界面需求：系统与外部交互的要求（硬件，软件和通讯需求）,功能需求：系统的行为描述和执行功能,非功能需求：系统约束条件，环境平台，特殊规范的支持度,技术需求：程序员制定的技术实现细节,用户需求：描述用户要使用系统完成的任务，表达方式是用例,测试设计：测试员制定的测试方案,领域专家最少责任线,商业决策点,2.1.3.

15、1抽象层的文档定义是需求工作的目标,具体讨论每个抽象层追溯关系特点表达方式举例,商业需求,最原始的需求,一切的根源表达要用简单扼要的自然语言特点:突出商业价值和目标例子(以自动取款机为例)本银行要开发一直接该银行客户使用的自动取款机系统以减轻银行职员在简单的取款,存款,查询业务上负担.,用户需求,特点追溯到商业需求,但更具体焦点是讨论用户和系统的业务交互过程又用例集表达每用例可有一些属性:代号,重要等级从用户角度看,每用例可有树型的类别和层次关系每用例可由不同低粒度的子用例组合每用例可被其他高粒度用例重用每用例分一个常规和多个非常规路线每用路线有入口条件和出口断言(用来衔接用例)每路线分多步骤

16、步骤可以有条件分支,循环和跳跃.每步骤由应答格式表达:用户操作-系统反馈,用户需求(以自动取款机用例为例),取款过程(U1)注册(U1A)常规路线-正常注册(入口:用户未注册,出口:用户可接触主服务项目)1用户插卡-系统校验卡,接受,提示密码输入2用户输入密码-系统验证密码并显示主服务项目非常规路线-插错卡(入口:用户未注册,出口:用户不可接触主服务项目,退卡)1a用户插错卡-系统校验卡,不接受,退卡.非常规路线-没收卡(入口:用户未注册,出口:用户不可接触主服务项目,丢卡)1(不变)2b用户输入密码-系统验证密码2b.1 错2b.1.1 错三次以上,到32b.1.1 错二次以下,并要求密码重

17、新输入,到2.2b.2 对,新出口:用户可接触主服务项目3b系统没收卡取款(U1B略)(入口:用户可接触主服务项目,出口:用户得到钱和收据,用户可接触主服务项目)略注销(U1C略)存款过程(U2)注册(U1B略),功能需求,特点:追溯到用户用例,但比用户用例的粒度更小,更面向设计焦点是讨论系统的行为和能力,而不直接讨论用户的行为表达上的格式是以”系统”为主语-”系统可以做”从构架师角度看,系统分解成要开发的可评估开发代价的重用模块功能有一些属性:代号,重要等级从功能分化上看,可有树型的类别和层次关系可由不同低粒度的子功能组合可被其他高粒度功能重用,功能需求(以自动取款机为例),安全功能(F1)

18、系统可以校验卡(F1A)系统可以验证用户密码(F1B)系统可以提示密码输入(F1C)系统可以提示密码错误(F1D)系统可以没收卡(F1E)系统可以注册用户(F1F)系统可以注削用户(F1G)业务功能(F2)系统可以显示主服务项目(F2A)取款(F2B)系统可以允许用户选择出款帐号(F2B1)系统可以允许用户选择金额(F2B2)系统可以允许用户选择是否要收据(F2B3)系统可以更新用户帐号金额(F2B4)略存款(略),追溯到用户用例焦点是要定义被开发的软件子系统和所有周围接触的外部实体的信息交流规范和到功能的映射表达形式界面元素允许外部实体触发控制系统的功能界面元素允许系统触发控制外部实体的功能

19、.,界面需求,被开发的软件子系统,用户,网络,卫星,其他软件子系统,硬件,用户界面,硬件界面,软件界面,通讯界面,界面需求(以自动取款机为例),用户界面(I1)触摸屏(I1A)密码输入框允许用户向系统提供密码(I1A1)服务菜单允许用户选择系统的服务功能(I1A2)选择”取款”(I1A2A)选择”存款”(I1A2B)选择”查询”(I1A2C)硬件界面(I2)读卡机(I2A)出纳机(I2B)存钱接受机(I2C)打印机(I2D)软件界面(I3)与中央银行服务器的软件接口(I3A),非功能需求,特点:焦点是讨论系统在扩展性和约束条件,例如软件兼容(底层数据库类型流览器)种类和版本硬件的最低标准支持语

20、言(中文,英文)对残疾人帮助功能表达上的格式是”系统支持某规范或产品或版本”非功能表示非商务相关功能,但不代表没有开发和测试的代价正相反,控制非功能需求对控制开发和测试的工作量极其重要,非功能需求(以自动取款机为例),语言:系统支持英文,中文对视觉障碍者:系统提供语音提示货币货币类型:系统只接受和出纳美元货币单位:系统只出纳$20 面值的货币出纳上限:$300触摸屏支持厂家和型号是:XX出纳机支持厂家和型号是:XX,技术需求,特点:追溯到功能需求,甚至界面和非功能需求.焦点是解决从功能模块到软件设计的过度.设计软件子模块的接口规范和之间的关系定义软件子模块的职责和内部逻辑表达上的格式是灵活多样

21、的.(UML,表格,流程图)多数情况可在设计阶段进行例子(略),测试设计,特点:追溯到功能,界面和非功能需求多数情况可在设计阶段进行焦点是解决从底层需求到测试步骤和验证的映射,确保所有的需求是可测试的.要在资源允许下覆盖尽可能多的非功能需求表达上类似用户用例的应答格式.要覆盖常规路线和非常规路线测试,但是单线过程,没有条件分支和跳跃.,测试设计,例子测试11用户插卡-系统校验卡,接受,提示密码输入2用户输入密码-系统验证密码错,并要求密码重新输入3用户输入密码-系统验证密码对,并显示主服务项目4用户选择”取钱”-系统询问选择哪个出款帐户,2.1.3.2 角色定义需各种技术人员共同协同完成,领域

22、专家架构师程序员测试员主管部门,领域专家,领域专家维护用户方的目标和利益得到最终的贯彻和保证，注重需求的市场价值，制定完备的用例而不被构架师曲解和忽略，审查各阶段成果。领域专家起草高层需求（商业需求）和把它细化为以用例为单位的用户需求。,程序构架师,构架师是开发员的领队和代言人，但不同于国内，他的权力是有限的。构架师的责任是严谨周详的理解和归纳原始的用户事例，发现和提出逻辑漏洞和未定义的潜在用例。验证需求的技术可行性，评估实现代价。构架师的任务是他和领域专家合作制定细节的界面，功能，非功能需求，并最终和其他程序员完成技术需求和实现。,测试员,不同于国内，测试员有责任参与需求分析。测试员的责任是

23、审视所有需求的描述是否有含糊不清和无法度量的地方。能把需求描述转化成可执行的步骤和可以验证的信息反馈，最终书面表达为测试计划和执行。,产品主管,产品主管的责任是通过比较开发成本和市场价值来保证项目开发向使公司赢利的方向发展。对不赢利和低赢利的项目应该考虑放弃或减低他的优先权，或寻求工效比最优的折衷方案。,2.1.4需求阶段的工具介绍（CaliberRM）,界面保证格式。树形视图保证需求从属关系。维护起源追溯关系以防出现无中生有和半途而废的需求。对人力资源核算汇总。生成word和HTML文档资料。多基线版本控制，比较，锁定和电子签名。,2.1.5 体会,美国大公司当前都认识到对需求下的代价都很大

24、，以确保今后工作顺利。以前犯下的忽视需求的错误，十年后仍然后患无穷。有时后，由于公司人力资源有限，程序员身兼数职（领域专家和测试），但要认识到这样作的潜在的危机-破坏了权利制约和监督，开发畸形发展。因此尽量不兼职。为降低开发风险和尽可能提高效益，需求也可以有优先权，并指导在计划，设计，编程和测试中实现优先权化。,2.1.6获取需求的工作流程,2.2 制订计划阶段的任务,如何有效快速地布局资源和人力。如何监视项目的进度。如何按实际情况及时调整。如何考虑未知的技术障碍。,2.2.1 计划(项目管理),解决方案合理安排Capacity（80%留用余地）让多个程序员作独立的成本估算每个子功能需求，综合

25、信息。对潜在的技术难关，要先做原型来证明可行性(可在需求阶段作)。排序任务时先看主从和依赖(追溯)关系，再看优先级。对松耦合的功能集划分多个开发周期。测试员要作类似的成本估算。并行某些任务以提高效力。（例如周期1的测试和周期2的开发,多个程序员的独立开发）定期了解程序员和测试员的进度，调整计划。,B:P3,T1,C:P2,T1,D:P3,T2,F:P2,T2,G:P1,T1,A:P3,T2,I:P1,T5,开发和计划例子-阶段分化,H:P2,T4,E:P3,T3,K:P2,T4,L:P1,T3,P:P2,T1,O:P2,T2,N:P3,T1,Q:P1,T2,M:P3,T4,J:P3,T2,R:

26、P3,T3,注解圆:功能需求方:测试项目P:优先权T:工时,进一步安排每个测试员和开发员的工作日程,2.2.2 制订计划所用的工具Microsoft Project Server,自动生成进程表。可调整工作容量百分比。可用实际时间矫正进度。可保证主从和依赖关系在时序的体现。监视项目的进度。（不同的颜色代号和%度）,2.2.3 体会,软件产业是创造性的企业，区别于可预测的重复性的制造企业。所以精确预测每一个新开发项目人工量是不现实的。因此要灵活认识到计划的可靠性不高，误差大。针对技术攻关的快速原型会减小计划误差。计划往往受公司早以公布的升级部署日期和现有的人力资源约束。过于紧缩的计划可能导致开发

27、员为期限而牺牲产品质量。,2.2.4 计划制定的工作流程,2.3 设计阶段,2.3.1.体系结构设计2.3.2.子系统设计,2.3.1 体系结构设计,运行平台体系结构(本次简单介绍J2EE)构件开发平台体系结构(略)构件管理平台体系结构(略)配置映射平台体系结构(略)构件调试平台体系结构(略),体系结构,面临的问题如何设计和评价一个新的体系结构如何对待老的体系结构后患:工程上和理论上的差距逐渐增大,设计体系结构,要收集以下资料并权衡各种制约条件所有可以使用的技术规范的熟悉程度，应用价值和发展趋势。参考和分析同类产品和自己老一代产品的体系结构的优缺点。宏观上理解客户群和项目群的整体共性和长远目标

28、，作长远打算。,J2EE体系结构的评价标准,支撑力(scalable)易维护易扩展易重构易测试简洁性可靠性重用性,最有效的策略:子系统间松耦合,许多体系结构的革新和成就是基于解决子系统间松耦合上的技术性突破.,J2EE运行体系结构中的子系统,功能层分类,部署分离,客户层UI Tier(client Tier),中间层(可以是再分布多级的)Middle Tier,数据库层Database Tier,网络服务层Web Service Tier,客户端表达逻辑client presentation logic,客户端表达引擎client presentation engine,服务器端表达逻辑 se

29、rver presentation logic,商务逻辑business logic,商务引擎business engine,商务数据business data,设计的核心技术是要解决是对这些功能子系统进行部署和实现松耦合的交互技术.,早期的J2EE运行体系结构的一个范例,客户层,中间层,数据库层,客户端表达逻辑,客户端表达引擎,服务器端表达逻辑,商务逻辑,商务引擎,商务数据,商务逻辑,商务逻辑,从现在角度看,早期的软件和硬件的技术局限性造成不优化的紧耦合体系结构,新的J2EE运行体系结构的一个范例,客户层,中间层,数据库层,12网络服务层,2客户端表达逻辑,1客户端表达引擎,4服务器端表达逻

30、辑,10商务逻辑,6商务引擎,8商务数据,门户,其他分布系统,3,5,7,9,11,13,部署实现技术相邻功能层的交互技术和促进松偶合的革新,(1)客户端表达引擎,部署客户层实现技术的发展IBM 绿屏幕Fat Window Client(胖终端)Thin Web Client(瘦终端)Rich Internet Application(Flex,SiverLight)移动硬件(PDA,iPhone),(2)客户端表达逻辑,部署中间层(早期表达单一)-客户层(当前表达多样)层实现技术的发展(对应于表达引擎的发展)VC,appletHTMLJavascript,SiverLight,Flash,F

31、lex,Mobile Device SDK特点最难自动测试的层是表达层,所以要减少它的商务逻辑复杂(最好不含商务逻辑),(3)客户端表达引擎与客户端表达逻辑交互技术的发展和革新,早期使用WINDOW(受OS约束)HTML 规范提供了在通用流览器与J2EE服务器的松偶合,使多流览器同时支持成为可能.随着不同类的可移动小硬件(PDA和iPhone)的出现和推广,需要一种新的抽象界面表达规范能够进一步使界面开发有重用性.,(4)服务器端表达逻辑,部署中间层实现技术的发展WindowJSP,servlet,JSTL,Tag,XSLT+XML,(5)客户端表达逻辑与服务器端表达逻辑交互技术的发展和革新,

32、早期使用WINDOW RMIHTML 规范提供了在通用流览器与J2EE服务器的松偶合,使多流览器同时支持成为可能.但是,这只能满足是低频交互(low interactivity)的需要.随着不同厂商(IE,NetScape,Firefox)从 JAVASCRIPT原始标准上分化,和新的表达丰富的流览器插件的出现(SVG,Flash,Flex,SiverLight),出现了对高频交互(high interactivity)的需要.AJAX技术出现提供上述所有技术通用的更灵活的交互策略(XML request,局部更新).利用JavaScript语言的灵活性,强大的DOM操作能力和与其他插件的交互

33、能力,可以配合AJAX技术,实现Adapter,用于彻底的屏蔽客户端表达引擎特征和服务器端表达逻辑.这要求客户端表达逻辑只阐述要客户端表达抽象的模型特征,而不解释如何表达和交该Adapter处理.,(6)商务引擎,部署中间层(独立出现是个较为新的概念)实现技术的发展与商务逻辑一体化3GL硬代码 又工具开发员用3GL开发的运行平台,(7)服务器端表达逻辑与商务引擎交互技术的发展和革新,Window 许多以MVC(Strut,JSF,Maverick,WebWork)模式设计的编成框架提供了类似context bean,用来屏蔽网路特征(request,session)和商务引擎,有利于设计无表达

34、特征的单元测试,和扩展商务引擎的实用范畴(例如,通过SOA,EJB技术与门户或其他分布系统接口),(8)商务数据,部署(最成熟和稳定的功能层)数据库层实现技术RDMS(Oracle,UDB,DB2,SQL server),(9)商务引擎与商务数据交互技术的发展和革新,数据库中间件技术(ODBC,JDBC,Entity Bean,Java Data Object,TopLink,CocoBase,SQLJ)都是致力与屏蔽数据特征与商务引擎的,使得在通过商务逻辑对商务数据处理时(创建,插入,更新,删除)不用知道数据库的类型和具体的处理实现和物理部署.EnterpriseOne OCM 近一步扩展这

35、种松偶合的思想到商务逻辑和商务引擎.通过应用管理平台,商务数据,商务逻辑,商务数据都可以做到从逻辑名到物理名映射.这使开发员,调试员和客户可以灵活的的配置自己的工作环境中使用的商务逻辑,商务数据和商务引擎.而且映射粒度是可控制的(小到某个表,某个用户,某个商务逻辑函数),(10)商务逻辑,部署早期多在中间层,表达层,数据库层(trigger,store procedure)当前往数据库层移动(XML数据)实现技术的发展早期与商务引擎一体化3GL硬代码,嵌入到表达层(JSP scriptlet),嵌入到数据库发展到应用开发员用4GL编写(多级开发概念的出现),但4GL 的内部存储形式仍然是又3G

36、L决定的 进一步松偶合,4GL 的内部表达形式转化为通用格式(XML),并物理上脱离引擎,存入数据库中.,(11)商务引擎与商务逻辑交互技术的发展和革新,随着商务逻辑由硬代码逻辑变成软代码,使商务逻辑更易更新(不需重新编译商务引擎)并从3GL完全脱离出来为4GL,变成一种数据库可存取的XML同用格式,使用不同的3GL重构和进化应用开发平台和运行平台(fat widnow client-thin web client)成为可能.,(12)网络服务层,实现技术的发展JSR168(全嵌入门户)Oracle JPDK(半嵌入门户)WSRP(based on Web Service不嵌入门户),或其他基

37、于SOA分布系统,(13)网络服务层和中间层交互技术的发展和革新,EJB JMSWSRP(Web Service Remote Portal)是基于SOAP 技术的远程门户规范.它的出现允许门户服务器(service consumer)和J2EE服务器(service producer)不再需要互相嵌入.一旦在producer实现两个必备和两个可选的Web Service,在consumer处,可以只要花两分钟时间,实时的注册producer,便可开始使用producer提供的门户.在这之前,producer甚至都不知道consumer的存在.总之,SOA技术为更高级的分布技术提供基础,便利了

38、分布子系统的松偶合体系结构.,老的体系结构的后患:工程上和理论上的差距逐渐增大,对一个多年从事开发某一老产品线的部门,不敢按好的体系结构重构系统.进一步发展到工程化的体系结构越来越偏离当前技术可行的理想体系结构.渐渐失去竞争力,增加维护和开发成本如再开发基于不好的体系结构,恶性循环,象癌症扩散.,有2000年历史的London城市交通规划,有150年历史的Denver城市城市交通规划,为什么体系结构工程上和理论上的差距逐渐增大,新需求和技术的出现往往预示老的原始设计的体系结构与当前综合需求的偏离.软件企业的规则:体系结构(architecture)工程化=解决方案(solution),理论上的

39、体系结构主要基于当前的软硬件可用的公开技术和规范,有较少的约束条件,代表理想化的方向-结构简单明朗,没有杂质.而工程上的体系结构还要包括其他方面的约束条件:软硬件价格版权费,适用平台,发展前途客户的新的特殊需求老客户的向后兼容遗留系统(legacy system)保证开发部的人力物力资源如何重用已经有的构件和平台来减少开发成本.,体系结构工程化,J2EE运行体系结构工程化后,客户层,中间层,数据库层,客户端表达逻辑,客户端表达引擎,服务器端表达逻辑,商务逻辑,商务引擎,商务数据,遗留系统层Enterprise Information system Tier(legacy system),商务逻

40、辑,商务引擎,网络服务层,门户,其他分布系统,不敢按好的体系结构重构的原因,表面原因:包袱太重(不能放弃老客户的向后兼容),为了降低成本不愿放弃老的开发工具和平台.本质原因:需求丢失 没有长期维护需求文档,多年后开发员不能回忆和预测产品的某些行为.设计丢失 设计思想随设计者走而不是随产品留,没有知识转移(knowledge transfer)测试恐惧症 积累太多的不确定的未记载的人工测试案例,而且使得重新全面测试新系统代价变的太高,和不可行.客户恐惧症 客户可能已经过于依赖软件未文档成需求的行为(甚至是缺陷).重构有可能改变这些行为.,缩短体系结构的理想化和工程化的策略.,要敢于重构,但是要在

41、一开始为将来的重构打好基础.制订公开,详细,与产品同步和易查阅的界面文档资料-定义产品行为规则,对新的用例的结果可预测.内部开发员经常作设计的知识转移和归纳文档实现高覆盖率的自动单元和和回归测试(auto unit test and regression test),有利于加强重构自信心.当用户汇报新故障后,吸收用户的新的用例到内部测试案例.产品升级太多而体系结构很差,就要整体的更新换代.松偶合的工具层和应用层允许低冲击的局部重构,体会,对历史悠久的大公司,虽然拥有众多的长期老用户和老产品,但如果起步时失误,这个特性反会成为自身技术和体系结构革新的致命累赘.新起步的公司也可因为没有这种累赘的原

42、因,并正确和扎实的起步,得到快速成长和领先的时机.学习和采用其他公司的体系结构时要认识到历史发展约束造成工程结构缺陷,要取精华去糟粕,不要东施效颦,2.3.3 子系统设计阶段,面临的挑战难以有效的记录和转达设计思想。（依赖含糊多意的语言表达）经常重新发明轮子。（忽视现有开发模型重用）由于缺乏交流,其他开发员不了解设计师的最初意图。容易忽视测试也要设计阶段。,2.3.2.1 子系统设计,解决方案程序员必修UML统一建模语言(Unified Modeling Language)设计模式(Design Pattern)程序设计要其他的开发员和维护员早参与审查。测试设计要开发员参与审查，但基础是需求和

43、而不是开发员理解。如有歧义，应找领域专家讨论。,2.3.2.2 UML的特点,是程序员之间的标准高效的软件蓝图的设计语言。有比传统数据流图更丰富的表达能力。可表达继承，从属，界面，实现，实例，过程，逻辑。体系结构图包括时序图，静态结构图，状态图，活动图，组件图，协作图，部署图，用例图等。,设计模式的特点,包括多种创建模式，结构模式和行为模式，并在各种系统设计中广泛使用。利用模式为基本设计构件可提高程序员的交流效率。不仅局限于OO语言C+,java。,2.3.2.3 设计阶段工具,工具介绍（Borland Together Control Center,JDeveloper,visual-par

44、adigm）支持各种UML设计图。可以直接在设计图上直接引入一套参考设计模式，再修改参数。可以有限的实现图和代码的双向转换。自动调整和美化设计图布局。可转化为其它存储格式。（图像文件，HTML等）,2.3.2.4 体会,每个领域的开发都有其独特的设计模式，不要闭门造车，要从网上和书籍中广泛搜索思想。（例如，J2EE设计模型，javaScript OO 设计）许多研究机构已经制订了各种设计规范，而等你去使用这个标准，而不要自己创造。（例如，门户规范WSRP，SOA WS规范）,2.3.2.5 设计阶段的工作流程,2.4 编程,面临的困境初期编码轻率，后期编码拘谨。个人独特的编成习惯互相干扰。子系

45、统分工后，但接口不清，责任不明，调试复杂，难以早测试。编码有可能逐渐偏离需求。,解决办法,以认同设计方案为起点。以统一编程规范（工具，格式，命名）为准则。以阶段性向领域专家演示为需求保证。XP(extreme program)提前自写或互写自动单元测试。多子系统责任分工，要严格制订认同接口协定。使用虚拟子系统取代真子系统作为测试另一子系统的虚拟环境。（举例）在每个子系统接口处建立日志系统以便于孤立和调试问题。,一般的编程注意事项,避免重复剪贴式编码(code duplication)-造成多重维护避免字面常数(literal constant and magic number)-需要分离逻辑和

46、常数避免变量的作用域太宽(visibility and scope)-造成模块的紧耦合.避免缩进不整齐，命名不规范避免过长的子过程使用注解(JAVA DOC)避免效率低下和内存泄露,单元测试的意义,有利于鼓励围绕需求的测试(black box test),减少围绕实现的测试(white box test)逐步加强开发员开发自信心 从100%失败到100%成功减少将来子系统重构和关键修改的顾虑固化系统的行为即使功能简单到1+1=2,也值得有个单元测试,因为开发中的不可预见的改变和失误难以很快觉察强迫如开发员系统行为变化作出反应代码改动造成BUG-改代码是期望的行为改变-改测试,单元测试的特点,可

47、以由程序员自写或互写自动单元测试并嵌入到测试驱动框架工具(unit test framework)。“单元”表示“独立”：各个测试可独立运行，不互相依赖。测试单元可按测试集(Test Suite)分组。测试驱动(test runner)自动为每个测试单元，在启动前作准备(set up)和在结束或失败后作清理(tear down)工作。测试驱动汇报所有测试中成功和失败记录。虽然初期要用较多时间，但在后期面临大改动时，它是有效的快速测试方法。,日志系统的特点,提供日志配置方式（配置文件或平台）可关闭和启动（客户产品环境要求高效）可按严重程度过滤可按子模块过滤可显示程序堆栈最好可实时配置（不需重启系

48、统）有容量控制（不会用光硬盘）,编程工具,开发工具（Control Center Together,JDeveloper，WSAD,VC.NET,JBuilder）直接与代码管理工具集成，调入，调出，加锁 文件。支持从设计试图到代码的转化。自带各种测试服务器。（J2EE container）自动标准代码模版。自动测试框架工具（Junit,JSUnit,Cunit）要程序员维护。易于更改，快速执行。,体会,良好和不好的编程习惯无法直接从产品的质量测试上看出，只有到别人维护时才会暴露出来，造成维护困难和后患。个人经验，在一个大公司里，一个好的程序员领队对其他的队员的监督指导和代码审查(Peer R

49、eview)，对整个队伍的素质提高有很大的影响力。,编程阶段的工作流程,2.5 测试种类和不同阶段的重点,Pre-Alpha单元测试(Unit Test)Alpha程序员的测试(White Box Testing)内部测试员的回归测试(Regression Test and Black Box Testing)负载压力测试(Load Test and Stress Test)Beta外部测试员或选择客户的验收测试和功能测试(Acceptance Test and Functional Test)内部测试员的关键路经测试(Critical Path Test)GA-Gold or General

50、 Availability Release客户上线后的实际使用,测试,面临的困境太多重复乏味的机器操作。随机的测试案例。不稳定测试环境（数据）。测试员和程序员对同一个需求理解不同。非功能需求的变体组合爆炸，无穷无尽。以前测试通过的案例会因为新项目的开发和出现新问题。,解决办法,需求决定测试方案，而不是程序员，但程序员要参与测试方案审查。用测试文档资料工具起草手工测试的文档好让其他的测试员和程序员能够重复。准备稳定的数据是测试的前提工作。测试也按重要性分级别，资源有限制时，宁可牺牲不重要的测试,而只做关键路径测试。分散组合各种非功能需求，求广不求细。不断提升自动测试的覆盖率。（无人测试）每个阶段