软件程序的知识点..docVIP

UI层和逻辑层大家的讨论使我明白在设计多层结构的程序时，层与层之间需要多用接口少用继承，但为什么要用接口呢？比如逻辑层直接实例化一个数据访问层的类，然后调用数据访问层中相应的方法返回一个数据源不就可以了吗？这样做也不关接口什么事呀　　在企业级程序开发中，一般出于并发的考虑，可能需要较好的可伸缩性(就是可以把一套程序的不同结构层放在不同的服务器上，我是这样理解的)，这样的话以的最简单的三层结构举例子，UI层和逻辑层应该是放在同一台服务器上(我不知道能不能把它们分到两台服务器中去)，我把它叫做[UI逻辑服务器]，而数据访问层放在另一台服务器中，我把它叫做[数据访问服务器]，还有一台是存放数据库的服务器，这样 UI逻辑服务器 与 数据访问服务器 中的程序可能就是2(或以上)个人开发的，两台服务器间的通讯一般是用WebService，这个我就不说了。按我上面说的，UI逻辑服务器 中的程序应该是可以直接调用 数据访问服务器 中的类，这本身没什么问题，但到具体开发上时可能就会出问题了，比如 UI逻辑服务器 中的程序开发人员甲在开始设计的时候需要调用一个 数据访问服务器 中的GetData()的方法，但这个时候 数据访问服务器 中程序的开发人员乙并不知道需要增加这个方法，那么甲的工作就继续不下去了，因为他的程序编译不了，假如这个时候甲定义了一个接口，然后在接口的定义中定义一个方法GetData()，当然这个方法里什么代码都不用写(具体的实现是由乙来做的)，然后乙写的程序都需要继承甲定义的这个接口，当乙的程序在编译的时候就会被提示哪些方法是必须被实现的，这样一来乙就随时都可以知道甲需要哪些方法来返回数据了，这样做最起码的好处是不用甲总需要告诉乙需要加哪些方法，而且也不会因为乙对数据访问层程序的误修改(比如误删除了GetData()这个方法)导致 UI逻辑层的程序运行不正常，因为如果删除了GetData()的话，乙的程序是编译不了的。　　所以我的结论就是接口在层与层之间的作用主要是上层(比如UI逻辑层)对下层(比如数据访问层)的一些限定，方便了开发，减少了不必要的沟通，也防止了一些出错的可能。不知道这种理解是否正确，还请大虾指教 需求分析的20条法则 2009年08月27日 星期四 下午 11:27 2009-08-11 16:00 需求分析的20条法则 邢学慧 ---对商业用户来说，他们后面是成百上千个供应商，前面是成千上万个消费顾客。怎样利用软件管理错综复杂的供应商和消费顾客，如何做好精细到一个小小调料包的进、销、调、存的商品流通工作，这些都是商业企业需要信息管理系统的理由。软件开发的意义也就在于此。而弄清商业用户如此复杂需求的真面目，正是软件开发成功的关键所在。 ---经理：“我们要建立一套完整的商业管理软件系统，包括商品的进、销、调、存管理，是总部-门店的连锁经营模式。通过通信手段门店自动订货，供应商自动结算，卖场通过扫条码实现销售，管理人员能够随时查询门店商品销售和库存情况。另外，我们也得为政府部门提供关于商品营运的报告。” ---分析员：“我已经明白这个项目的大体结构框架，这非常重要，但在制定计划之前，我们必须收集一些需求。” ---经理觉得奇怪：“我不是刚告诉你我的需求了吗？” ---分析员：“实际上，您只说明了整个项目的概念和目标。这些高层次的业务需求不足以提供开发的内容和时间。我需要与实际将要使用系统的业务人员进行讨论，然后才能真正明白达到业务目标所需功能和用户要求，了解清楚后，才可以发现哪些是现有组件即可实现的，哪些是需要开发的，这样可节省很多时间。” ---经理：“业务人员都在招商。他们非常忙，没有时间与你们详细讨论各种细节。你能不能说明一下你们现有的系统？” ---分析员尽量解释从用户处收集需求的合理性：“如果我们只是凭空猜想用户的要求，结果不会令人满意。我们只是软件开发人员，而不是采购专家、营运专家或是财务专家，我们并不真正明白您这个企业内部运营需要做些什么。我曾经尝试过，未真正明白这些问题就开始编码，结果没有人对产品满意。” ---经理坚持道：“行了，行了，我们没有那么多的时间。让我来告诉您我们的需求。实际上我也很忙。请马上开始开发，并随时将你们的进展情况告诉我。” ---风险躲在需求的迷雾之后 ---以上我们看到的是某客户项目经理与系统开发小组的分析人员讨论业务需求。在项目开发中，所有的项目风险承担者都对需求分析阶段备感兴趣。这里所指的风险承担者包括客户方面的项目负责人和用户，开发方面的需求分析人员和项目管理者。这部分工作做得到位，能开发出很优秀的软件产品，同时也会令客户满意。若处理不好，则会导致误解、挫折、障碍以及潜在的质量和业务价值上的威胁。因此可见——需求分析奠