云南博弈机电集团合同管理系统调研方案
-Java软件开发的调研报告
云南博弈机电集团在20##年7月机构改革，是以市场和用户为中心，由各销售公司和产品线直接签订合同，按市场规律从合同签订之初，直到合同的预付款、合同机床交货、尾款付款交付到用户的全过程等，都是围绕合同而产生的经济活动，因此，建立有效的合同管理是很重要的，用合同管理来对产品交付给用户的全过程实施有效监督和管理。
销售公司和产品线合同签订后，销售公司随即将合同向市场管理部报备，报备之始，市场管理部就围绕合进到交付到用户的整个过程进行监督与管理，目前合同管理、合同统计增考评分析、入库、出库、回款等是使用EXCEL来进行，因EXCEL对数据管理的局限性不仅是造成大量的信息孤岛、人力的重复劳动，还造成数据在重复录入过程中不易查出的错误等，因此，急需要针对此项工作开发一套针对性的小软件，以便于更有效的组织现有数据、避免输入及统计错误、节省人力，高效快捷的组织工作,经考虑并结合当下实际情况，此小软件由市场管理部负责开发、调式、安装、后期维护及培训使用，总体构架情况如下：
一、市场管理部合同管理现状、流程：
1、 管理现状：
●合同录入、开单、开票、分款，由合同管理员。
●商品机床入库录入、出库开单、录入由李冬负责。
●合同管理的考评分析由段芹负责。
●开票审核由杨立负责。
2、现有流程：
3、 流程图解释：
（1） 合同基本信息录入：由合同管理员按照不同销售公司负责录入；
（2） （1）里的审核：由合同管理员之间相互审核，审核完毕确认审核后可进行下一步操作，审核不通过返回（1）里修改；
（3） 合同考核录入1：由合同考核员（段芹）负责录入；
（4） 销售公司开票/回款：经销售公司开票回款数据回来后，由相关人员负责录入，同时此处的回款信息由下一步分款用；
（5） 分款：由合同管理员录入，并且分款分为多次录入；
（6） 入库/出库录入：由入库/出库录入员（李冬）负责录入；
（7） （6）里的考核有合同审核员（段芹）负责审核，审核完毕确认审核后可进行下一步操作，审核不通过返回（6）里修改；
（8） 合同考核录入2：由合同考核员（段芹）负责录入；
（9） 开审批单：由合同管理员开单；
（10） （9）里的审核由：李冬、杨立、室主任审核，审核完毕确认审核后可进行下一步操作，审核不通过返回（9）里修改；
（11） 财务换发票：由杨立志拿审批单去财务换回发票；
（12） 录入发票编号：由合同管理员负责录入；
（13） （12）里审核由杨立负责，审核完毕确认审核后可进行下一步操作，审核不通过返回（12）里修改。
二、软件需求分析：
（一）输入信息管理：
通过实际使用需求调研，将需求信息进行整理、分析，暂定软件由六个模块组成，即：合同录入登记模块，机床入库/出库模块，合同录入后开单/开票模块，分款模块，审核模块，考评及统计分析模块。具体如下：
1、合同录入模块：
2、机床入库/出库模块包括：
3、合同录入后开单/开票模块：
备注：
开单/开票流程细分：
①.【制单日期】（出库）—【发货公司】（出库）—看【型号】（出库）—找合同基本信息对应型号（合同基本信息录入）—复制【机号】/【制单日期】到合同基本信息里的【开单日期】和【机床编号】里。
②.合同管理员 — 执行①后 — 做开票审批单 — 由李冬、杨立、室主任审核（看机床是否入库） — 由杨立志把审批单拿财务换回发票 — 合同管理员根据发票上的【机号】、【型号】录入发票编号 — 杨立审核。
4、分款模块：
备注：分款为销售公司回款后进行分款，分款在合同基本信息录入后就可以进行，贯穿全过程。分款之前，要根据【机号】、【型号】、【合同号】把对应的开票日期和开票价格录入系统。
5、 审核模块：
合同基本信息录入审核；
入库出库录入审核；
录入发票编号审核。
6、考评及统计分析模块：
备注：
确认产出流程细分：
筛选【入库时间】（入库）—找到【合同号】、【型号】、【机号】—把【机号】、【入库时间】粘入考评及统计分析模块。
（二）输出信息管理：
筛选汇总后导出能根据需要得到相应的各种报表。
（三）功能设置管理：
1、信息录入模块中均加入【保存信息功能】、【修改信息功能】、【删除信息功能】
2、在审核模块中药加入【信息筛选功能】、【信息汇总功能】、【信息导出功能】。
3、使用人员的权限设置：不同的负责人有不同的权限查看和筛选、导出不同的信息等。
4、【软件设置功能】、【操作员管理功能】、【帮助功能】、【信息备份功能】、【信息导入功能】。
5、【合同变更功能】、【合同查询功能】
（四）功能解释：
1. 【录入功能】：录入功能中包含修改、删除、保存等功能，保证信息录入正确、有效；
2. 【筛选功能】：根据合同签订时间做一次大的筛选，然后列出合同的各项信息，供不同阶段筛选不同信息，把需要的项目选定到目标框内，然后汇总即可根据相应的顺序筛选出需要的结果并导出文件，以备调用。
3. 【操作员管理功能】：包括操作员的添加、删除、密码设置等。
4. 【软件设置功能】：可以设置不同操作员的使用权限。
5. 【帮助功能】：整个软件的使用手册。
6. 【信息备份功能】：随着时间的推移，合同会越来越多，庞大的数据需要把不同时段的合同信息备份起来，释放系统的空间，以方便合同的录入，以及整个软件的稳定、安全、快捷性。
7. 【信息导入功能】：在此软件之前所做的一些合同信息可以导入系统中直接使用，不需要把以前的信息重新录入一遍。
8. 【合同变更功能】：能够及时更改有变更的合同内容。即在不同时间内的合同变更情况，有变更时间记录。
9. 【合同查询功能】：方便系统管理员和相关合同负责人查询合同的各项执行情况。
在以上各项流程中，尤其是涉及到后期的合同变更和删除各项信息的时候，要根据合同管理人员之间的先后顺序来做一步一步的删除、变更操作。即顺序为：
【考核2】—【开票开票、分款】—【入库、出库】—【考核1】—【合同基本信息录入】
第二篇：Java在软件开发中可能出现的几个错误观点
Java在软件开发中可能出现的几个错误观点
机构名称：北大青鸟APTECH（广州广力）授权培训中心 日期：2008 - 05 - 29 查看次数： 21 次
【赛迪网技术社区整理】越来越多人开始使用Java，但是他们大多数人没有做好足够的思想准备(没有接受OO思想体系相关培训)，以致不能很好驾驭Java项目，甚至 导致开发后的Java系统性能缓慢甚至经常当机。很多人觉得这是Java复杂导致，其实根本原因在于：我们原先掌握的关于软件知识(OO方面)不是太贫乏就是不恰当，存在认识上和方法上的误区。
软件的生命性
软件是有生命的，这可能是老调重弹了，但是因为它事关分层架构的原由，反复强调都不过分。
一个有生命的软件首先必须有一个灵活可扩展的基础架构，其次才是完整的功能。
目前很多人对软件的思想还是焦点落在后者：完整的功能，觉得一个软件功能越完整越好，其实关键还是架构的灵活性，就是前者，基础架构好，功能添加只是时间和工作量问题，但是如果架构不好，功能再完整，也不可能包括未来所有功能，软件是有生命的，在未来成长时，更多功能需要加入，但是因为基础架构不灵活不能方便加入，死路一条。
正因为普通人对软件存在短视误区，对功能追求高于基础架构，很多吃了亏的老程序员就此离开软件行业，带走宝贵的失败经验，新的盲目的年轻程序员还是使用老的思维往前冲。其实很多国外免费开源框架如ofbiz compiere和slide也存在这方面陷阱，貌似非常符合胃口，其实类似国内那些几百元的盗版软件，扩展性以及持续发展性严重不足。
那么选择现在一些流行的框架如Hibernate、Spring/Jdonframework是否就表示基础架构打好了呢？其实还不尽然，关键还是取决于你如何使用这些框架来搭建你的业务系统。
存储过程和复杂SQL语句的陷阱
首先谈谈存储过程使用的误区，使用存储过程架构的人以为可以解决性能问题，其实它正是导致性能问题的罪魁祸首之一，打个比喻：如果一个人频临死亡，打一针可以让其延长半年，但是打了这针，其他所有医疗方案就全部失效，请问你会使用这种短视方案吗？
为什么这样说呢？如果存储过程都封装了业务过程，那么运行负载都集中在数据库端，要中间J2EE应用服务器干什么？要中间服务器的分布式计算和集群能力做什么？只能回到过去集中式数据库主机时代。现在软件都是面向互联网的，不象过去那样局限在一个小局域网，多用户并发访问量都是无法确定和衡量，依靠一台数据库主机显然是不能够承受这样恶劣的用户访问环境的。（当然搞数据库集群也只是五十步和百步的区别）。
从分层角度来看，现在三层架构：表现层、业务层和持久层，三个层次应该分割明显，职责分明：持久层职责持久化保存业务模型对象，业务层对持久层的调用只是帮助我们激活曾经委托其保管的对象，所以，不能因为持久层是保管者，我们就以其为核心围绕其编程，除了要求其归还模型对象外，还要求其做其做复杂的业务组合。打个比喻：你在火车站将水果和
盘子两个对象委托保管处保管，过了两天来取时，你还要求保管处将水果去皮切成块，放在盘子里，做成水果盘给你，合理吗？
上面是谈过分依赖持久层的一个现象，还有一个正好相反现象，持久层散发出来，开始挤占业务层，腐蚀业务层，整个业务层到处看见的是数据表的影子（包括数据表的字段），而不是业务对象。这样程序员应该多看看OO经典PoEAA。PoEAA 认为除了持久层，不应该在其他地方看到数据表或表字段名。
当然适量使用存储过程，使用数据库优点也是允许的。按照Evans DDD理论，可以将SQL语句和存储过程作为规则Specification一部分。
Hibernate等ORM问题
现在使用Hibernate人也不少，但是他们发现Hibernate性能缓慢，所以寻求解决方案，其实并不是 Hibernate性能缓慢，而是我们使用方式发生错误：
“最近本人正搞一个项目，项目中我们用到了#+hibernate3, 由于关系复杂表和表之间的关系很多，在很多地方把lazy都设置false，所以导致数据一加载很慢，而且查询一条数据更是非常的慢。”
Hibernate是一个基于对象模型持久化的技术，因此，关键是我们需要设计出高质量的对象模型，遵循DDD领域建模原则，减少降低关联，通过分层等有效办法处理关联。如果采取围
绕数据表进行设计编程，加上表之间关系复杂（没有科学方法处理、侦察或减少这些关系），必然导致 系统运行缓慢，其实同样问题也适用于当初对EJB的实体Bean的CMP抱怨上，实体Bean是Domain Model持久化，如果不首先设计Domain Model，而是设计数据表，和持久化工具设计目标背道而驰，能不出问题吗？关于这个问题N多年就在Jdon争论过。
这里同样延伸出另外一个问题：数据库设计问题，数据库是否需要在项目开始设计？
如果我们进行数据库设计，那么就产生了一系列问题：当我们使用Hibernate实现持久保存时，必须考虑事先设计好的数据库表结构以及他们的关系如何和业务对象实现映射，这实际上是非常难实现的，这也是很多人觉得使用ORM框架棘手根本原因所在。
当然，也有脑力相当发达的人可以 实现，但是这种围绕数据库实现映射的结果必然扭曲业务对象，这类似于两个板块（数据表和业务对象）相撞，必然产生地震，地震的结果是两败俱伤， 软的一方吃亏，业务对象是代码，相当于数据表结构，属于软的一方，最后导致业务对象变成数据传输对象DTO, DTO满天飞，性能和维护问题随之而来。
领域建模解决了上述众多不协调问题，特别是ORM痛苦使用问题，关于ORM/Hibernate使用还是那句老话：如果你不掌握领域建模方法，那么就不要用Hibernate，对于这个层次的你：也许No ORM 更是一个简单之道： No ORM: The simplest solution
#
Spring分层矛盾问题
Spring是以挑战EJB面貌出现，其本身拥有的强大组件定制功能是优点，但是存在实战的一些问题，Spring作为业务层框架，不支持业务层Session 功能。
具体举例如下：当我们实现购物车之类业务功能时，需要将购物场合保存到Session中，由于业务层没有方便的Session支持，我们只得将购物车保存到 HttpSession，而HttpSession只有通过HttpRequest才能获得，再因为在Spring业务层容器中是无法访问到HttpRequest这个对象的，所以， 最后我们只能将“购物车保存到HttpSession”这个功能放在表现层中实现，而这个功能明显应该属于业务层功能，这就导致我们的Java项目层次混乱，维护性差。 违背了使用Spring和分层架构最初目的。
领域驱动设计DDD
现在回到我们讨论的重点上来，分层架构是我们使用Java的根本原因之一，域建模专家Eric Evans在他的“Domain Model Design”一书中开篇首先强调的是分层架构，整个DDD理论实际是告诉我们如何使用模型对象oo技术和分层架构来设计实现一个Java项目。
我们现在很多人知道Java项目基本有三层：表现层 业务层和持久层，当我们执著于讨论各层框架如何选择之时，实际上我们真正的项目开发工作还没有开始， 就是我们选定了某种框架的组合（如Struts+Spring+Hibernate或Struts+EJB或Struts+JdonFramework），我们还没有意识到业务层工作还需要大量工作，DDD提供了在业务层中再划分新的层次思想，如领域层和服务层，甚至再细分为作业层、能力层、策略层等等。通过层次细化方式达到复杂软件的松耦合。DDD提供了如何细分层次的方式
当我们将精力花费在架构技术层面的讨论和研究上时，我们可能忘记以何种依据选择这些架
构技术？选择标准是什么？领域驱动设计DDD 回答了这样的问题，DDD会告诉你如果一个框架不能协助你实现分层架构，那就抛弃它，同时，DDD也指出选择框架的考虑目的，使得你不会 人云亦云，陷入复杂的技术细节迷雾中，迷失了架构选择的根本方向。
现在也有些人误以为DDD是一种新的理论，其实DDD和设计模式一样，不是一种新的理论，而是实战经验的总结，它将前人 使用面向模型设计的方法经验提炼出来，供后来者学习，以便迅速找到驾驭我们软件项目的根本之道。
北大青鸟APTECH(广州广力)授权培训中心
电话:020-2227 6688
地址:广州市越秀区连新路171号广东国际科技中心首层 北大青鸟 (东风中路纪念堂西 地铁纪念堂站D2出口直达)