项目管理的底层逻辑(6篇)
项目管理的底层逻辑篇1
论文摘要：本文通过介绍框架技术特点，提出了基于五层web应用的框架整合结构。并在此结构上实现了城市公共信息服务平台的应用，为类似的电子政务应用提供了参考。
随着网络技术、信息技术的发展，各类信息充斥我们生活、工作及学习周围，但这些信息之间重复严重，数据准确度不高，社会公众很难准确获取与个人生活、工作、学习密切相关的本地数据和信息，进而影响人们的网络生活，因而各类专业的本地信息服务已成为当前互联网应用的一种趋势。由政府牵头整合政府、市场、企业等多方面资源，共同构建一个统一、开放、跨平台、系统结构层次清晰的城市公共信息服务平台，并以灵活多样的形式为本地公众提供准确、权威的信息服务已经成为当地互联网应用的一种重要需求。
基于j2ee技术标准体系的框架技术能够快速、有效地支持大中型web应用项目的开发，但是在大中型web应用中，可能存在几个层次，需要使用几个不同的框架。那么如何整合各层框架以让每个层在一种松耦合的方式互相协作，这是一个在软件工程领域实践性很强的课题。本文介绍了一个以spring框架为核心，结合struts、hibernate框架的一种快速有效构建web应用的框架整合策略，并在此整合策略基础上阐述了城市公共信息服务平台应用的设计思想和实现技术。
1j2ee框架技术特点
目前随着软件开发技术的发展，可重用、易扩展，而且是经过良好测试的软件组件，越来越为人们所青睐。这意味着人们可有充裕的时间用来分析、构建业务逻辑，而不是繁杂的代码工程。于是人们将相同类型问题的解决途径进行抽象，抽取成一个应用框架。
1．1spring框架
spirng框架是一个以控制反转(ioc)模式和面向方面编程(aop)思想为核心的轻量级框架，主要用于对中间层业务组件的管理。常用的中间件解决方案ejb是一种重量级的容器，主要有以下缺点：必须实现ejb的接口，对业务逻辑组件侵人性很大；应用依赖于ejb容器，不能单独运行，另外启动时间长，测试复杂、配置很困难。
首先，spring是一种轻量级的框架，是基于组件化、模块化的结构。它有分层的体系结构，因而针对spirng开发的组件不需要任何外部库，也可以选择某个模块独立使用，从而避免了ejb复杂、启动时间长的缺点。
其次，spring也是一个ioc容器。ioc模式是spring的核心，它的本质是由容器控制业务对象的协作关系，而非传统的用程序编码在业务对象直接控制，控制权由程序代码转移到外部容器。通过ioc模式可以很容易地管理和替换业务对象。
另外，spring又是比较全面的框架，它并没有象ejb一样从底层开始全面实现j2ee的功能模块。spring提供了大多数的层次功能模块，但它并不是从头开始实现的，它通过对其它框架技术的支持来实现各层功能。它包括springcore核心层、mvc模块、springdao、springorm、上下文控制、web表示层、面向方面编程7个功能模块。
1．2hibernate框架
hibernate是一种专业的对象关系映射(o／r)工具，通过hibernate的o／r映射，可以以对象化的方式处理数据库表中的记录。hibernate通过properties文件建立数据库连接，通过映射文件(．hbm．xm1)将数据库表映射为java类，表中的每条记录对应为类的实例，而数据列值映射为实例的属性。hiber—nate将这些实例以持久对象(persistentobject)形式向中间业务层提供服务。
1．3struts框架
sturts框架很好地实现了mvc设计模式的概念。它通过actionservlet对象实现集中控制，并利用struts—conifg．xml文件，很好地实现了视图、控制、模型层次之间的分离，使得页面设计与改变真正做到与代码无关。
2整合框架的web应用架构
如果以上述任何一个框架技术来实现大中型的web应用，会存在效率不高，解决问题不彻底等问题，通过以轻量级框架spring为核心，充分利用spring框架的开放性、模块化以及对业务对象、事务管理等强大的功能，整合sturts、hibernate框架，可以构造出五层web应用架构，分别为：客户层、web层、业务层、持久层、企业资源层5个层次。整合框架的web应用架构如图1所示：
在客户层，通过jsp页面实现交互，负责传送请求(request)和接受响应(response)。在web层，sturts根据actionservlet接受到的请求，委派相应的action。action对象中的execute方法调用模型中的业务组件，决定“做什么”。在业务层，管理业务组件的springioc容器负责向action提供业务模型(mode1)组件，决定“怎么做”和该组件的协作对象数据处理(dao)组件完成业务逻辑，并提供事务处理、缓冲池等容器组件提升系统性能和保证数据完整性。业务层通过dao数据访问对象，向持久层请求数据处理。在持久层，依赖于hibernate的对象关系映射和对象化的查询语言操作，通过hibernate的会话，处理dao组件请求的数据，并返回处理结果。
对照基于ejb的一般web应用结构，整合框架的web应用架构中通过spring提供的轻量级业务组件的管理和ioc容器，实现了对ejb技术的替代和更好的组件重用性，使业务组件间的协作更加松耦合。同时利用spirng的开放性、模块化以及对hibernate良好支持的特点，通过引入专门的o／r映射框架hibernate实现了对关系数据库的对象化，隐藏了数据库的底层细节，便于开发者以统一的面向对象思想来开发应用。另外通过sturts的mvc模式，开发清晰明确的业务流程和用户交互，实现表现逻辑和业务逻辑的解耦，摆脱了原有的开发模式带来的高耦合性。通过框架的整合不仅集成了各种框架的优势，同时也构造了层次清晰，结构合理的5层web应用架构。
3应用实例
3．1项目概述
“宁波市城市公共信息服务平台”是由宁波市信息产业局牵头，以政府投资形式建设的一个公益性地信息服务平台。平台整合本地各类专业的信息服务企业和机构的信息资源，以合作的方式共同打一个宁波市本地的信息资源集聚中心和本地的信息门户，进而既增值开发利用了政府信息资源，也提了信息服务业的核心竞争能力，同时也为社会公众提供了一个权威的、统一的信息渠道，达到了政府、业、公众共赢的局面。
本平台整合了与社会公众有关的衣、食、住、行等政府、企业信息。信息分基本信息和市场商业信息两类。对于基本信息，平台的管理员及加盟企业所有成员都能进行信息的维护和更新，并有专门的信息员进行审核和管理，保持平台基本信息的准确与及时性。对于商业信息，基本上由者负责为原则，平台提供一种免费的平台，同时对这些的信息给予地图定位以及与其它频道信息等关联的增值服务，进一步提升第三方网站的信息价值。根据本平台的用户角色区分，主要有：前端普通用户和后台管理用户。后台管理用户有4种，分别是系统管理员、频道运作单位、加盟企业、信息员，主要负责对信息的采集与。前端用户是指一般的网站浏览用户，前端普通用户可以按分类信息查询，也可以按搜索引擎方式查询，在查到文本信息的同时给出对应的gis信息，进而可以获得行车路线等有关地图位置信息。另外，如用户根据本平台查到的信息，想进一步进行电子商务操作，如网上购物、电子订票等，本平台可以负责直接转向，起了一个信息门户的作用。
3．3主要实现技术
本平台采用tomcat5．0作为web服务器，struts框架为1．2版本，spring框架为1．2．5版，hiber—nate框架为3．0版，根据上述整合框架的web应用架构来实现平台的结构。
3．3．1视图层页面设计：根据前端用户灵活的信息浏览需求，同时又要适应频道运作单位自己管理频道模块的需求，因此，页面设计改动不能影响到其它业务逻辑。在实现中通过sturts的自定义标签，结合mvc模式，实现页面与业务逻辑分离，做到jsp页面不包含java代码。另外，利用jsp技术在显示页面嵌入地图内容，实现图文并茂的显示方式。
3．3．2web层请求响应控制：通过struts—conifg．xml配置文件把后台用户管理页面或前台用户浏览页面都对应到每个action，当页面发出请求后，根据struts—config．xml的配置文件中对应的action部署，由action对象调用本平台内的业务层组件。如果此时请求的是地图信息那么action对象中以ap／方式向市规划局的gis平俞调用地图位置信息，并把结果返回给客户端。如果此时请求是进一步需要第方电子商务服务，那么直接重定向到第方电子商务服务网站。
3．3．3业务对象的ioc方式管理：web层的action只是决定“做什么”，并没有实现“怎么做”，具体的业务逻辑由业务层的业务组件来完成。平龠中包括信息查询、会员注册、积分管理等功能模块都需要有一个业务组件来实现该功能。在项目实现中，把每一个业务组件包按接口类和实现类分开编码，当需要互相协作时，在代码层只要直接引用协作对象的接口类就可以了。协作对象的实现类统一南spring容器根据配置文件的说明进行注入。如：在本项目中，普通会员信息的业务需要信息员审核，审核通过后要把该信息的状态记录到某个频道运作单位下。那就可以分为i个服务组件：信息组件、信息审核组件、信息状态记录组件，在spring的ioc机制下，利用配置文件和基于接口与实现分离的编码方式可以很好地实现这个组件之间的松耦合协作，减轻了应用对容器的依赖。
3．3．4利用spring框架实现事务管理及与持久层会话：在本项目中对于会员注册，积分管理等操作需要进行事务管理，同时所有的操作数据保存需要与持久层进行连接，这些都可利用spring框架本身的功能来实现。如：通过spring配置文件可以直接实现数据源、会话工厂、事务管理和数据访问对象的配置，数据访问对象根据上述spring配置可以直接和持久层连接．这样在实现有中不用考虑这些功能的具体实现。hibernate通过转换工具把各类信息保存表转换成相应的对象文件和．xml映射文件，spring中的数据访问对象，直接对对象文件进行操作，由hibernate完成数据的持久化。
项目管理的底层逻辑篇2
引进咨询公司把关不严是后续项目问题的根源
咨询市场是一个严重信息不对称的市场，人力资源部很难判断咨询公司是否适合自己的公司。而所有的人力资源项目都必须是带实施的项目，最后所有人力资源咨询项目的效果都不是体现在人力资源部门，而是体现在业务部门。
帮助客户界定初始需求本身就是咨询顾问该做的工作，也应该是必备的能力。如果需求界定不清楚，真给客户做了个薪酬咨询，结果可能给客户的人力资源部带来很大的包袱。但由于咨询公司内部各个模块过于细分，使得大多数顾问难以从更高的层面上看待客户的问题。发展顾问综合能力是有效界定客户需求问题的关键。
所以，人力资源部在选择咨询顾问的时候，要注意以下几点：
1、
驻场项目经理是否有足够的实施经验，项目经理的水平就是项目本身的水平。考核对方很简单：一是看洞察力，我方没有提到的问题是否看到了；二是看其有没有变革实施的措施，对实施阻力分析是否到位。
2、
当咨询公司提到按人头付费的时候就要小心一点，因为请顾问公司是来解决问题。应该尽量描述清楚项目结束后要达到的效果，而不是关注来几个顾问。
3、
不用太关注前期沟通时的项目建议书漂亮与否，试想一个从来没有深入企业的顾问仅仅靠漂亮的项目建议书就打动了你，他们进场后还有足够的动力深入企业吗？
4、
看看合约中提到的成果是什么，如果是一大堆文档，而不是自己起初想要的效果，恐怕在未来项目结束时，除了一堆漂亮的垃圾，什么也没有得到。
合同偏文案而不是效果将带来落地的麻烦
正如上面第四条所分析的，大多数咨询公司都把提供文案作为项目的最终成果，每到项目要结款的时候，顾问们提供的是厚厚的文档，公司付出的是厚厚的钞票。项目经理常教导顾问：没有结果，有过程，看不到过程，有文档。一般咨询公司所谓的显性成果就是厚厚的文档。其中逻辑性是说服客户的关键，但逻辑的前提是信息对称。经常看到管理咨询主管们在骂下属顾问的文案缺乏逻辑。想起冯友兰先生的一句话：“有人以为凡是依逻辑讲的彻底的学问，都是科学。”问题是，科学真的对管理咨询那么重要吗？实际上，只在一种情况下答案是肯定的，就是管理的对象——人不再有自主的思考，并且所有人对同样的刺激表现出同样的反应。在管理咨询项目中，要想在没有主观设定目标的情况下找出合乎逻辑的方案几乎是不可能的。而主观设定目标的荒谬之处就在于管理中人的主观因素的复杂性及人的多目标特征。大多数管理咨询顾问不敢把决定着个人行为的主观观念作为起点，他们系统地以支配个人行为的观念，而不是他们对自己行为的理论结论作为起点。即他们自己的行为本身很可能就是方案的起点和结论。所以某著名管理咨询公司在描述其管理咨询奥秘的著作中，提出了预期性假设的做法，并奉为法宝。只要有了假设，就不愁没有逻辑，因为自此一切资料的收集都是按照这个假设的方向进行的。虽然表面上说的原因是为了避免“不必要”的资料干扰精力。至于基于行业分析的战略，是否是先有了战略导向，再收集相关行业资料就很难说了。
所以说，对项目成果的检验，仅仅看文档是否合逻辑是不够的，还要看顾问能否真正给客户带来变化，哪怕这种变化是不好衡量的，如：员工行为习惯，心理架构等发生的变化。管理咨询卖的是服务，产品是通过“人”来体现的，产品的效果也是通过“人”来体现的。虽然管理咨询公司极力将产品标准化、可衡量化，客户付款拿到的是量化的方案。但是客户得到的价值是多少，却不是由方案的多少来决定的。而是咨询内在的东西：对问题的看法是否正确？解决问题的思路是否正确？实施是否简便到位？企业家观念是否已经跟上变革内容？等等。
另一方面，咨询的价值因顾问与客户的关系不同而不同：对方案的认可，对方法论的认可以及充分信任基础上的关于认识论的交流。高层次咨询的价值正如老子所说：少即是多。或者应俗语所说：假传传万卷，真传一句话。
对老板的咨询不可或缺
当我们发现企业的问题全都是人的问题，当我们知道人的问题主要在老板的问题，而老板本人是最难改变的时候。于是对于企业最有效的企业家咨询“死了”。
这种咨询只能走向“秀肌肉”：“科学”的大部头文案。“秀肌肉”对中国的老板很有效，因为他们大部分出身营养缺乏的年代，科学学得不够。而中国有十分迷信教育的传统。于是打着科学的牌子，拎着比教科书还漂亮还厚的文案。再加上神秘的服务器和电脑中吐出的眼花缭乱的报表。足以让哪些只受过中等以下教育的老板臣服，并献上自认误打误撞赚来的银子。
咨询顾问“肌肉男”来到企业，与老板（大脑）们打个招呼，就和部门经理们开始练摊。老板羞于对科学的无知，不愿与“肌肉男”多谈。“肌肉男”正好落得自在。“肌肉男”们熟练而毫不羞耻地运用去掉“大脑”的“系统思维”，搭起没有大脑的机械怪兽。机械怪兽举起远轻于自己的杠铃。“肌肉男”收钱，走人。项目的结果如果不是把老板原有的思想理论化，科学化，就是事后被老板一手插到底，彻底毁掉，原因就是大家都理解了，只有老板还没有完全理解，因为项目中他很少见到顾问。
项目管理的底层逻辑篇3
关键词：三层结构；Web应用；Java/Jsp技术
中图分类号：TP311文献标识码：A文章编号：1009-3044（2013）07-1567-03
一般企业级Web应用软件的开发都会涉及较多且较复杂的业务逻辑，而且客户的业务需求也会经常发生变化，这就对此类软件的开发提出了更高的要求。为适应这种要求，一般软件开发企业会采用一定的软件设计模式来提高开发效率，而分层模式是最常见的一种架构模式，而且分层模式是很多更为复杂的架构模式的基础。分层模式的特点是：将解决方案的组件分隔到不同的层中；在同一个层中组件之间保持内聚性；层与层之间保持松耦合。
三层模式可以说既是Web应用软件开发中最简单地一种分层模式，也是较为实用的一种分层模式。它是将整个系统自上而下分为表示层、业务逻辑层、数据库访问层。表示层用于将信息展示给用户或接受用户输入信息，一般是由Web页面组成；业务逻辑层负责实现系统主要涉及到的业务逻辑功能，一般封装了业务逻辑的类组成；数据库访问层主要实现对数据库的增、删改查操作，不涉及业务逻辑，一般由数据操作对象（DAO）类组成。三层之间的关系是：表示层依赖于业务逻辑层，业务逻辑层依赖，即高层依赖于底层，底层不依赖于高层，一般不能跨层调用方法。同时，对于系统封装好的实体类，三层都可以访问。
1三层结构的具体应用
1.1“新闻系统”的总体设计
“新闻系统”是许多企业级Web应用系统的子模块，这里就以此为例来说明三层结构的具体应用。“新闻系统”分为前台用户模块和后台管理模块两大部分。
前台用户模块包括以下功能：1）用户登录、注册；2）新闻列表展示；3）新闻详细内容展示；4）按关键词查询新闻。
后台管理模块包括以下功能：1）用户管理（普通用户的增、删、改、查）；2）新闻管理（新闻信息的增、删、改、查）。
1.2数据库设计
1.3三层结构设计
2三层结构Web应用的编程思路
2.1编写实体类
编写Web应用程序一般都会对数据库表进行增、删、改、查操作，所以一般对数据库表的设计是第一步，也可以称为定义数据字典。这一步做的主要工作是创建表、定义表字段名、类型、约束条件，确定表之间的关系，另外为了方便后期开发还要输入少量的测试数据。
数据表定义好以后我们就可以编写实体类了，不涉及到业务逻辑的实体类一般一个实体类对应一个数据表，业务逻辑实体类到需要编写业务逻辑时再定义。
在编写实体类过程中总结了一下经验：
1）将实体类字段名定义成和表字段名一致的名称可以减少错误，另外借助工具（如PLSQLDeveloper、Hibernate）可以加快编码速度。
2）尽可能地使用字符串类型作为所定义的属性的类型，这样可以比较方便后期对数据库的操作；
3）给所有的属性都添加上getter/setter方法，便于后期对属性的操作；
2.2三层结构的编写步骤
一般教科书或参考书上讲的编写三层结构代码的顺序都是按照业务功能模块先编写此模块的数据访问层，再编写业务逻辑层，最后编写表示层。但我们在教学实践过程中发现使用这样的编码顺序做项目教学效果并不理想，学生往往在编写的过程中没有一个清晰的思路，或者是写某一功能时无从下手，或者是写着写着就不知道下一步该做什么了。
这里我们根据教学实践采用一种“需求驱动”的方式编码，取得了较好的教学效果。这一编程思路就是首先从表示层，也就是页面开始编码，由于页面上很多内容都是静态显示的，所以我们先把静态部分写好，然后再写逻辑脚本部分，根据客户具体需求要显示哪些内容，我们就在页面上合适的地方添加相应的jsp脚本或el/jstl表达式。其次，还是根据需求看是否需要去调用业务逻辑层的功能代码，如果这时业务逻辑层还没有需要的方法，我们就到业务逻辑对应的类去添加相应的方法，并在页面上传递相应的参数进行调用。最后，如果在编写业务逻辑层方法的过程中需要访问数据库，则再去调用数据访问层的相应方法，如果没有需要的方法同样到数据访问层对应的类中添加方法。这样有上层开始，逐步向下的编码顺序可以使我们有很清晰的编码思路，最后再由低层将结果逐步返回上层，最后再回到页面上验证我们编写代码的输出结果是否正确，这样每一层的功能十分清晰，有利于程序调试。
下面以“新闻系统”中显示新闻标题列表的功能模块为例说明这种编码步骤在实践中的具体应用。
1）创建newsTitleList.jsp页面，页面将静态部分设计编写好，包括页面头部，尾部，导航等固定部分，还有显示标题列表部分，我们这里采用简单地table显示。
2）编写jsp脚本部分，这里我们做了简化，显示包括所有主题的新闻标题和创建时间（实际项目中需要按主题显示列表并进行列表分页），具体代码如下：
3）编写业务逻辑层方法，在以上的页面上要调用findAllNews_item（）方法，这个方法现在还没有，所以需要在业务逻辑层NewsItemBiz类中编写如下具体代码：
4）编写数据访问层方法，在以上的业务逻辑方法中要调用getAllNews_item（）方法，这个方法现在还没有，所以需要在数据访问层News_itemDao类中编写如下具体代码：
5）最后再回到页面层调试程序，显示出正确的新闻列表标题数据。
2.3程序代码优化
掌握了以上编码思路，其他逻辑功能模块的编写完全按照这一步骤和顺序来实现。在平时教学过程中我们还积累了一些对程序代码优化非常有用的方法，现总结如下。
1）对数据库操作表基本的连接、关闭、增、删、改、查操作应该作为公共方法提取出来，放到一个工具类中，并尽量写成静态方法，以方便其他类调用。
2）对用户经常要反复访问的页面（如首页index.jsp），如果其中有对数据库操作的代码，则应该对其进行优化，可以放到Servlet的init（）方法中只执行一次，然后放到session或application中，这样可以避免频繁查询数据库。
3）为了便于程序的后期维护和扩展，页面应主要使用el/jstl标签来代替jsp脚本，使表示层只用于展示内容，将业务逻辑与页面显示尽量分开，降低层与层之间的耦合度。
4）将程序中编写的js脚本和css样式放到单独的文件中，这样有利于代码的复用和程序的修改维护。
5）在使用jndi方式配置数据库连接信息时，最好不要在tomcat下的context.xml文件中进行配置，而更好的办法是在项目的META-INF目录下单独建立一个context.xml文件并写入配置信息，这样在项目进行迁移时不需要重新配置数据库连接信息。
3结束语
本文主要结合在教学过程中使用的“新闻系统”这一项目案例说明三层结构在Web应用程序开发过程中的具体运用，重点论述了编程思路和方法对提高项目开发效率的重要性，其中对使用三层结构编写Web应用程序过程中的编程思路提出了自己的观点，并在教学实践中取得了较好得教学效果，另外文中还总结了几条程序代码优化的技巧。
参考文献：
[1]林信良.JSP&Servlet学习笔记[M].2版.北京：清华大学出版社，2012.
项目管理的底层逻辑篇4
关键词商业银行数据仓库数据模型
中图分类号：TP311.13文献标识码：A
1实施策略
2003年中国建设银行制定了《中国建设银行科技应用总体规划》，确定了项目群实施规划、数据仓库和管理信息系统实施规划。规划中明确了建设银行的目标应用体系架构、技术架构以及项目实施路径等，规划出未来5-10年建设银行信息化发展战略。规划旨在为建设银行业务新一轮改革发展提供有力支撑，不断提高建设银行的盈利能力。
为实现这一战略目标，建设银行以数据集中为前提，通过数据仓库为基础，通过信息管理平台持续开发客户分析管理、资产负债管理等应用，使建设银行信息化水平和内部管理水平走上新台阶。其中数据集中和数据仓库的建设是关键步骤。
2TeradataFSLDM客户化
2.1FSLDM简介
TeradataFSLDM是预先构建的逻辑数据模型，利用它可以直接开始数据仓库模型设计。它是一个纯粹的逻辑数据模型，可以运行在任何数据库和平台上，与Teradata数据库无关。
2.2客户化策略
客户化方法论可以概括为自底向上、从顶至下以及自底向上和从顶至下的联合使用。下面我们简要对这几种方法进行一下对比和分析，主要从策略、过程等方面的特点来决定到底采用何种方法进行开发。
首先，自底向上法是指先从较下层设计开始，也就是说去解决问题的各个不同的小部分，然后把这些部分组合成为完整的应用。这种设计方法主要是要根据系统功能要求，从具体的逻辑部件或者相似系统开始，凭借设计者熟练的技巧和丰富的经验，通过对其进行相互连接、修改和扩大，构成所要求的系统并保证系统功能的实现。从设计成本和开发周期来讲，自底向上法一般优于自顶向下法，但是由于其设计是从最底层开始的，所以也存在难以保证总体设计的最佳性的问题，一般适用于探索性的开发项目。在银行建设数据仓库，自底向上策略一般是从某个数据仓库原型开始，选择一些特定的为企业管理人员所熟知的管理问题作为数据仓库建设目标。该策略的主要优点在于能够以较小的投入在短时间内取得局部成果。
结合银行业务特点，一般来讲，按照数据仓库的思路建设信息决策系统已经有一定的先例和成功经验可以借鉴，不应该算作探索性尝试，而是目标明确、长期规划的建设过程，所以应该采用从顶至下的方法进行。也就是说，在开发前就已经具备数据仓库的系统定位、实现目标、应用范围等内容，这种策略对开发人员的开发经验要求和管理层、建设者的预期目标明确程度都有非常高的要求。
实际上，在许多数据仓库设计过程中，是混合使用从顶至下法和自底向上法的，因为这样可能会取得更好的效果。从银行来讲，主体策略采用从顶至下法，在一些局部的、不熟悉的领域，采用自底向上的方法进行一些探索性的尝试，以积累经验、规避风险，这样的组合应该是理想而明智的选择。
2.3FS-LDM主体结构
TeradataFS-LDM在某银行客户化改造覆盖了11大主题区域，包括团队、资产、财务、营销活动、协议、渠道、事件、内部结构、产品和地域等。
3具体实施策略
在某银行TeradataFS-LDM客户化的具体实施过程中，采取的是分重点设计主题、自主设计主题、简化设计主题等不同类别，根据每种类别的特点和目标来分别制定有针对性实施策略的原则。
4在某银行的BANK-LDM管理界面
某银行建立了专门的平台管理LDM，在这个平台界面上可以对LDM进行词法分析、关联实体分析、父子实体分析等操作，LDM的开发和维护人员可以通过IE浏览器改元数据管理平台，对自己负责的相关模型进行查询和分析。
数据仓库在初期建设时还没有到考虑模式优化问题的时候，因为此时不仅数据量少，而且加载的应用也少。但是，随着应用的推广，数据量不断加大，应用不断增多，不断会爆出空间效率等问题，必须后期进行调整优化，可以优化逻辑模型，也可以针对物理模型优化。在实践中，我们发现充分事前的设计和实施中的不断改进，逻辑模型在项目完成时可优化的范围小，通常集中于协议、事件等主体。后期我们已物理模型优化为主。
物理模型优化的原则主要是一要结构层次一致性、二要结合具体运行环境、三要针对Teradata的特点。
逻辑模型设计是基于三范式的分层结构，这样可以保证模型的灵活性和稳定性，但与此同时可能产生大量关联表，优化时需要考虑精简。另外通过脚本相关算法的优化以及调度机制的优化，提高运行效率，从整体上缩短仓库运行的时间窗口。
据上述目标原则，物理模型优化主要通过数据冗余和数据清理、拆分以及针对Teradata性能优化来实现。在进行脚本优化时要先优化关键脚本，脚本优化要注意与物理表结合。优化完成后需要进行测试工作，保证优化不改变应用正常应用，也可以验证优化效果。优化尽量选择在仓库的非主要运行日进行，避免资源紧张对正常运行造成干扰。
参考文献
[1]郑承满.数据仓库技术在商业银行中的应用与发展趋势[J].中国金融电脑，2012（07）.
[2]冯健文，林璇.基于ODS的数据仓库模型研究[J].微计算机应用，2012（04）.
项目管理的底层逻辑篇5
关键词:Web3.0;网站;应用开发
中图分类号:TP393文献标识码:A文章编号:1009-3044(2009)24-6695-02
Web3.0ApplicationDevelopmentWebSite
CHENWei-feng
(Chien-shiunginstituteofTechnology,Taicang215411,China)
Abstract:ThearticlefirstdescribedthedevelopmenttrendofWeb3.0,Web3.0andthenbyanalyzingtheinternalWebsite,describesthetechnicalfeaturesofWeb3.0,theendusersiteintheweb3.0waytobuildpersonalwebsites.
Keywords:web3.0;websites;applicationdevelopment
1Web3.0的发展趋势
1.1什么是web3.0
GoogleCEO埃里克施密特定义:Web3.0是一系列组合在一起的应用,对于个人用户来讲互联网将更具有可管理性,也意味着,互联网将由一系列的标准化Web组件拼装起来。
谷歌中国的总裁李开复定义:Web3.0将以网络化和个性化为特征。谷歌正越来越热衷于把微软的桌面软件移植到网上,例如,谷歌已开始做Web3.0概念,已推出了在线办公软件,还正在计划推在线操作系统。
1.2Web3.0与Web1.0、Web2.0的区别
从互联网的发展进程来看,Web1.0的特点是联合,出现了网站与网站之间的广泛链接。Web2.0的特点是互动,出现了社区、论坛、博客等等,用户在网站系统内拥有自己的数据。Web3.0的特点是能通过第三方信息平台同时对多家网站的信息进行整合使用。相对于Web1.0时期信息通过超级连接跳转互通。Web2.0时期信息通过程序中的标识代码在页面内容里互通.Web3.0所实现的是信息可以直接从底层数据库之间进行通讯.底层数据库具备完整的信息交换机制。
现有的Web2.0只能通过PC终端应用在互联网这一单一的平台上,面临现在层出不穷的新的移动终端的开发与应用都需要新的技术层面和理念层面的支持。而Web3.0将打破这一僵局,使得各种终端的用户群体都可以享受到在互联网上冲浪的便捷。
1.3典型的国内Web3.0网站
2007年创建阔地网络()和雅蛙网(http//:),都是目前国内基于Web3.0概念的个人门户网站。用户可以根据自己的喜好和使用习惯来聚合网络信息、创造个人门户,展示了“RSS聚合+搜索定制聚合+个性化平台”的模式,在自己的个人门户就可以浏览网页和下载软件,体现高度的个性化。这两家网站为Web3.0在我国的发展提供了一个风向标和示范。
2Web3.0的技术特点
Web2.0以Blog、BBS,TAG、SNS、RSS、WiKi等应用为核心,改变了传统的互联网阅读模式,向主动创造信息迈进,把内容制作开放给用户,实现人与人交互,共同创造内容。Web3.0则引智能搜索、智能网络、和虚拟现实技术等,将对现有互联网应用模式带来新的挑战。继承Web2.0,广泛采用Ajax技术,广泛采用RSS内容聚合,表现为博客大行其道,互联网上涌现大量的个人原创日志。
2.1源数据的分析
是Web3.0的源数据分析应用于大规模关键词的搜索技术及衍生服务。新一代的标记语言如ODW、RDF、SPARQL等会在原始数据内容之上注解,使之具备“生命力”,不但可以搜索,还可以向每个用户提供个性化的服务。这个实现的技术难点在于一个通用的数据标准,不过随着开放源代码计划的逐步实施和多层协议的完善,在可预见的将来,所有的网络数据都可以被不同的应用和服务所理解和执行。举个简单例子,当你在网上搜索商品时,网站会自动弹出相关性极高的相关商品,购买、评价、推介和其他很多你可能想不到的信息,这个过程包括了服务程序对商品的DNA分析(源数据的提炼、产生、归类、注释),调用客户行为信息数据库,发出搜索指令,高效率抓取数据,用友好界面呈现等等,这个过程在用户界面上和Web2.0没什么区别,但依靠后台的大规模运算,可提供非常舒服的用户经验,这就是网络DNA。
2.2智能网络
这是一个以整个互联网为基础,聚合了所有知识的平台,开发人员甚至普通用户可以透过Web3.0的技术非常高效地抓取所需要的知识(注意是“知识”而不是简单的“信息”),拼凑出自己所需要的信息和电子商务服务平台,比如说你要计划一个大型的时装表演活动而你又几乎是个门外汉,在Web1.0时代是在网络广告里找公关公司、设计公司承包这个项目,在Web2.0时代是可以通过搜索引擎自我学习一番,而在Web3.0时代可以通过很多可以彼此智能化相通的网络服务器,发出一系列的外包指令,以最低的成本得到最好的服务,同时还可以用非常多的可视化工具帮助你理解业务逻辑,跟踪项目进度。所以智能化的核心是虚拟化和可视化。
2.3虚拟现实技术
首先是继承Web2.0中应用的核心技术,如XML、SOA、AJAX等,实现了信息的推送、订阅、主动筛选。Web3.0所要使用的技术就是一些带有解析功能的数据交换协议和注解语言,使得知识共享真正成为可能。企业可以根据自己的需要搭建商用软件,传统媒体重振雄风,有专长的人可以做个完全的自由职业者。Web3.0的核心软件技术是人工智能,模仿补充人类思维行为的软件技术,具备学习能力、界面友好、视觉化,包含了本地端的视觉化工具和远程的高性能分析工具。以后的应用不但是模块化的,而且是多线程、高度图像化、可自我治愈的,例如,网络虚拟人的出现就是虚拟现实技术的综合运用。
3Web3.0网站的开发
3.1Web3.0框架
相对传统软件及Web开发来讲,Web3.0引入了全新的软件开发架构及四层语义软件开发架构:数据层、语义逻辑层、业务逻辑层、业务视图层。相对传统软件开发框架做大的变化为语义逻辑层:传统软件的开发是从对业务需求开始的。而Web3.0框架下的软件开发时,从底层构建并不针对需求,而是针对语义。把传统三层框架中的业务逻辑划分了两层,一层是语义逻辑,即支撑业务逻辑的代码层。所以在传统开发思想和模式下无法实现Web3.0。Web3.0技术开发原理:针对应用分析业务涉及的语义元素、然后根据语义元素建立支撑业务的类表、然后根据类表对应数据表并开发基于数据表的语义逻辑层代码。同时还可以根据业务需求开发业务逻辑层和视图层代码。并实现缝合。Web3.0会推动计算机语言从面向对象开发,升级到面向对象的语义开发。任何一个人遵循此标准开发程序,都可以彼此替换和互联。并最终会推动产业出现新的下一代计算机开发语言。
3.2用户在Web3.0网站的搭建个人网站的方法
Web3.0网站既是平台又是工具,给用户节约了大量的时间,而且它所提供的各种个性化工具组件将大大的提高用户的工作和学习效率;在Web3.0时代,一切操作都将在网页上完成,这将很大程度的便利了用户的使用;在个人门户上用户可以合理的统筹安排自己的学习、工作和娱乐休闲生活。
4结束语
Web3.0跟Web2.0一样,不仅仅是技术的创新,更是思想的创新,Web3.0是基于互联网应用层面的理念。在技术上是在原来Web2.0电子公告的技术原理上推进了更多的应用。Web3.0将建立可信的SNS(社会网络服务系统),可管理的VoIP与IM,可控的Blog/Vlog/Wiki,Web3.0是通过更加个性化的技术革新丰富着互联网的表现形式,实现数字通信与信息处理、网络与计算、媒体内容与业务智能的有效结合。
参考文献:
项目管理的底层逻辑篇6
J2EE技术提供了一个基于组件的、多层分布式计算平台。在J2EE的应用系统的开发过程中，由于使用了中间件，开发人员可以把工作重点放在系统功能的建模、设计与实现上。此外，J2EE技术结合了软件设计中的最佳实践(bestpractices)，如以架构为中心的软件体系结构、基于组件的架构等等。这一切都对现有的软件工程过程提出了新的挑战。所以，裁剪RUP并且使其在J2EE项目中起更大的作用是非常有意义的。
本文讲述了如何把RUP应用到小型项目团队开发J2EE应用系统的过程中，并且结合J2EE技术的特点从项目管理、架构设计、开发和测试等方面重点阐明了对RUP的裁剪。
图1一个复杂的BUS的实现方法
项目管理
在RUP中，角色定义了个人或团队的行为和职责，包括分析设计人员、编程人员、测试人员、项目管理人员和辅助人员，一个人可以同时担当几个角色．一个角色也可以由几个人来共同承担。针对J2EE系统的开发和维护，J2EE规范中也定义不同的角色，包括J2EE产品供应商、应用组件供应商、人员、系统管理员等等。
在实际的项目运行中．要根据软件开发组织的实际情况来确定角色的定义和分配。项目经理是必不可少的一个角色，通常是一个人来担任。项目经理代表整个项目与软件客户进行沟通和协商，并且制定软件开发计划等等。架构师也是一个必须的角色，通常由一名经验丰富的软件开发人员来担任。
在项目运行的前期，架构师负责设计软件架构和原型系统。在项目运行后期，架构师可以参与到具体的软件开发中。SQA同样是必不可少的，通常是一名经验丰富的软件开发人员来担任。SQA在整个项目的运行过程中负责监督和改进软件质量，包括制定系统测试方案、用户接受测试方案等等。开发人员是组成团队的主要力量，负责系统的设计、开发和测试。如果可能的话，团队中必须设立业务分析员的角色，负责商业建模等，通常由有特定行业经验的人来担任。
迭代开发计划
RUP的精髓之一迭代式的开发，它是基于Spiral模型翻的。整个软件开发周期由很多个迭代组成，其中初始迭代最为重要。其它每个迭代都为了实现软件的部分功能。在完成所有迭代后，软件的所有功能都已实现并且通过测试。
图2基于Tier层的J2EE应用系统架构
初始迭代又叫作0迭代，它开始于项目的启动。结束于RUP初始阶段(inceptionphase)的完成。初始迭代在整个软件项目中起着十分重要的作用，这是因为在这个迭代中，项目团队和客户必须对软件项目的范围、成本、进度和应用系统的边界以及功能等达成一致的理解。
在初始迭代中，最重要的活动有明确项目的范围、商业需求和提出至少一个可用的软件架构方案。在明确项目范围的过程中，项目经理就项目的边界、产品、限制条件等与软件客户进行协商，从而达成一致认识。同时，在理解客户需求的基础上，项目经理或者业务分析员以需求说明书和功能说明书的形式把客户的需求记录下来。并且和客户达成一致理解。在此基础上，架构师提供至少一个合适的软件架构方案，并且完成原型系统。原型系统的目的不但是为了验证技术上的可行性，而且是为了给客户一个感性的认识，更好地完善对需求的理解。
需求说明书从客户的角度简要地描述了系统要具备的功能，它包含了很多商业用例。通常情况下，需求说明书还不能够全面地描述整个应用系统,所以软件开发组织还要从不同角度来描述系统的功能和特征，这就是功能说明书。功能说明书中包含了很多系统用例。功能说明书和需求说明书必须征求客户的意见，直到客户满意为止。
图3基于Layer的J2EE应用系统架构
迭代计划是项目计划的一部分，指如何把要实现的系统分解成更小的子系统和如何在不同迭代中(除初始迭代之外)划分子系统，从而使每个迭代的目标明确，不同迭代之间的依赖关系达到最低。通常情况下，从逻辑上看，应用系统可以划分成多个BUC，而每个BUC又可以进一步划分成SUC;因此，可以从BUC的角度出发，根据相互之间的依赖程度来进行划分，把依赖程度低的BUC划分到不同的迭代中，从而确定每一个迭代的范围。一个复杂的BUC可以把它分解成独立的几个小BUC在几个迭代中来实现。（如图1所示）
一个应用系统也是由很多组件组成的。一个或者几个组件组合起来可以实现一个SUC或者一个BUC的要求。在设计迭代计划的时候，要考虑到组件之间可能存在的约束关系。基于J2EE的应用系统是基于组件架构的，因此，最小化迭代之间的依赖是一个最重要的衡量标准。
采用这种迭代办法后，每个迭代的范围限制在一个或者几个相互独立的BUC中。这样做的好处在于降低需求变化带来的风险。
图4BUS的组成结构
风险管理
采用迭代式开发的一个很重要的原因是，项目的风险能够在早期的几个迭代中暴露出来。风险有两个基本的属性，一个是它发生的概率，还有一个是风险发生后对项目的影响。风险管理的目的是为了尽量降低风险发生时对项目的影响。
在风险管理中，首先要识别项目中存在的风险。其次根据风险发生的概率和风险发生后对项目的影响来分析存在的风险。通常采用量化风险的办法。给概率和影响分别赋予一定的数值，经过分析，把概率的数值和影响的数值相乘后的结果风险量化后的值。接着，对于量化后值比较高的风险制定相应的风险规避计划。在项目运行过程中，要不断地监督风险的变化。
架构设计
RUP采用基于组件的软件架构和以架构为中心的开发方式。J2EE技术强调基于组件的软件架构,能够很好地体现RUP的架构思想。根据3D方法可以把一个J2EE应用系统的架构从三维进行分析，分别是Tier、Layer和SystematicQuality。在设计系统架构的时候，可以从这三个角度考虑。
Tier
从Tier层的角度进行考虑,一个J2EE应用系统的架构可以分为以下几个部分:客户端层、表示层、业务逻辑层、集成层、资源层，如图2所示。每层都是按系统中业务逻辑而划分的，它具有唯一的职责。每层与相邻层都是松散耦合的。
图5应用实例
在实现的时候，需要结合项目的具体情况而定。基于MVC设计模式的J2EEWeb应用系统中，客户一般访问JSP。然后由Control层进行处理:如果需要进行复杂的业务逻辑处理并且已经有后台实现，业务逻辑使用Facade模式进行封装，形成统一的接口，业务逻辑层实现复杂的事务处理;如果需要访问资源层，再经过DAO层访问资源。
Layer
从Layer的角度进行考虑，一个J2EE应用系统的架构可以分为几个部分:最下层为操作系统、Java虚拟机和网络，它们负责系统的底层操作和网络数据的传输;之上是J2EE服务层，一般由J2EE服务器(如WebSphere，WebLogic等)提供各种基础服务，如事务的管理(JTS)、命名目录服务(JNDI)、负载均衡(LoadBalancing)、容错(failover)、安全(security)等;其次是通用业务层，它一般完成与具体业务无关的基本操作，由通用的组件来实现，如数据库处理组件、系统错误处理组件、字符处理和数值处理组件、日志(10g)处理、数据转化和编码维护等;最上层才是具体业务逻辑模块，它完成具体的业务逻辑。（如图3所示）
在实现的时候．底层一般是不需开发人员关心的操作系统和网络环境，并且不同J2EE服务器厂商都提供了相应J2EE服务层，开发人员需要关心上面两层的实现。如果是J2EEWeb应用体系，应用服务层一般会使用Struts框架。log服务一般选择log4j等。最上层才是具体业务模块。
SystematicQuality
这是指在软件架构中通过一定的办法或者使用一定的工具来达到系统要求的QoS，一般指可扩展性、可移植性、可维护性、安全等等,而这些恰恰是J2EE架构本身所带来的好处。
实现和测试
实现是软件开发人员编写代码来完成每一个组件。测试是用来保证软件质量的重要手段。采用RUP的软件工程过程后，整个项目被划分成不同的迭代。每个迭代(除了初始迭代)的范围是一个或者多个独立的BUC，目标是编写代码实现BUC并且保证软件的质量。
在实现和测试的时候，集成(integration)是很重要的。这是因为整个软件开发过程分成多个迭代来完成，每个迭代(除初始迭代外)都是为了实现应用系统的一个部分。对于相邻的两个迭代。后者是在前者的基础上进行开发的，是实现功能上的一个增量。因此，相邻迭代之间需要功能上的集成。此外，每一个迭代都是由BUC组成的。从逻辑上来看，一个BUC是由一个或者多个SUC组成的。从实现上来看，每个SUC是由一个或者多个组件(component)组成的。因此，每一个迭代中都需要组件之间的集成，如图4所示。
根据集成程度的不同，可以划分几个不同的开发集成和测试:
首先是SUC集成和单元测试。这个是粒度最小的集成，它把几个不同的组件集成起来，实现同一个SUC。例如，SUC1是通过集成C1和C2来实现的。同时，在集成完成后，进行相应的单元测试。
其次是BUC集成和集成测试。BUC集成是把几个相关的组件集成起来,来实现它的功能。图4中BUC的实现需要集成4个组件。同时，在集成完成后进行相应的集成测试。
再次是迭代内集成和系统测试。迭代内集成从功能上来看，就是把这个迭代包含的所有BUC集成起来;从代码上看，是把所有和BUC相关的组件集成起来。同时，在集成完成后进行系统测试。系统测试分两步，首先是从功能上来测试每个BUC，其次是测试不同BUC之间的依赖和约束。
最后是迭代间集成和回归测试。对于相邻的两个迭代，从功能上来看，后者是前者基础上的一个增量。迭代间集成把这个增量准确地集成到应用系统上。同时，在集成完成后进行衰减测试。回归测试不但要测试功能增量的正确性．而且要测试增量发生后系统原来功能的正确性。
实例研究
笔者在TradeManager项目中运用了上述的方法。TradeManager是一个关于金融软件研究的项目，开发基于J2EE技术的金融订单管理系统。项目由12个人的团队来进行开发。团队成员分工明确，有项目经理、架构师、测试员和SQA等等。项目采用迭代式的开发方式。在初始迭代中，项目双方对项目范围、功能需求及架构达成一致，并签字同意。整个开发分为三个迭代阶段,根据功能点来划分，每个迭代分别实现交易前、交易中和交易后的功能。每个迭代的开发时间在六个星期。
这个软件采用J2EE的架构，如图5所示。其中UI和Delegate层在客户端，采用Swing技术来实现。是一个典型的肥客户端。Facade、BusinessLogic和DAO在J2EE服务器端，采用EJB技术来实现，它与客户端的通讯是典型的RMI／IIOp协议，采用的服务器是WebSphere。后台采用Oracle数据库来存放各种系统数据。同时，采用SiteMinder来实现系统的认证和授权。用log4j来实现logging／auditing功能。由于采用WebSphere集群技术，系统的可扩展性和高可用性得到了保证。