[编辑本段]基本信息
软件工程一直以来都缺乏一个统一的定义,很多学者、组织机构都分别给出了自己的定义: 软件工程(1)、BarryBoehm:运用现代科学技术知识来设计并构造计算机程序及为开发、运行和维护这些程序所必需的相关文件资料。 (2)、IEEE在软件工程术语汇编中的定义:软件工程是:1.将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护,即将工程化应用于软件;2.在1中所述方法的研究 (3)、FritzBauer在NATO会议上给出的定义:建立并使用完善的工程化原则,以较经济的手段获得能在实际机器上有效运行的可靠软件的一系列方法。 目前比较认可的一种定义认为:软件工程是研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件,以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来。 (4)、《计算机科学技术百科全书》中的定义:软件工程是应用计算机科学、数学及管理科学等原理,开发软件的工程。软件工程借鉴传统工程的原则、方法,以提高质量、降低成本。其中,计算机科学、数学用于构建模型与算法,工程科学用于制定规范、设计范型(paradigm)、评估成本及确定权衡,管理科学用于计划、资源、质量、成本等管理。
[编辑本段]目标
软件工程的目标是:在给定成本、进度的前提下,开发出具有可修改性、有效性、可靠性、可理解性、可维护性、可重用软件工程性、可适应性、可移植性、可追踪性和可互操作性并且满足用户需求的软件产品。追求这些目标有助于提高软件产品的质量和开发效率,减少维护的困难。下面分别介绍这些概念。 (1)可修改性(modifiablity)。容许对系统进行修改而不增加原系统的复杂性。它支持软件的调试与维护,是一个难以达到的目标。 (2)有效性(efficiency)。软件系统能最有效地利用计算机的时间资源和空间资源。各种计算机软件无不将系统的时/空开销作为衡量软件质量的一项重要技术指标。很多场合,在追求时间有效性和空间有效性方面会发生矛盾,这时不得不牺牲时间效率换取空间有效性或牺牲空间效率换取时间有效性。时/空折衷是经常出现的。有经验的软件设计人员会巧妙地利用折衷概念,在具体的物理环境中实现用户的需求和自己的设计。 (3)可靠性(reliability)。能防止因概念、设计和结构等方面的不完善造成的软件系统失效,具有挽回因操作不当造成软件系统失效的能力。对于实时嵌入式计算机系统,可靠性是一个非常重要的目标。因为软件要实时地控制一个物理过程,如宇宙飞船的导航、核电站的运行,等等。如果可靠性得不到保证,一旦出现问题可能是灾难性的,后果将不堪设想。因此在软件开发、编码和测试过程中,必须将可靠性放在重要地位。 (4)可理解性(understandability)。系统具有清晰的结构,能直接反映问题的需求。可理解性有助于控制软件系统的复杂性,并支持软件的维护、移植或重用。 (5)可维护性(maintainability)。软件产品交付用户使用后,能够对它进行修改,以便改正潜伏的错误,改进性能和其他属性,使软件产品适应环境的变化,等等。由于软件是逻辑产品,只要用户需要,它可以无限期的使用下去,因此软件维护是不可避免的。软件维护费用在软件开发费用中占有很大的比重。可维护性是软件工程中一项十分重要的目标。软件的可理解性和可修改性有利于软件的可维护性。 (6)可重用性(reusebility)。概念或功能相对独立的一个或一组相关模块定义为一个软部件。软部件可以在多种场合应用的程度称为部件的可重用性。可重用的软部件有的可以不加修改直接使用,有的需要修改后再用。可重用软部件应具有清晰的结构和注解,应具有正确的编码和较低的时/空开销。各种可重用软部件还可以按照某种规则存放在软部件库中,供软件工程师选用。可重用性有助于提高软件产品的质量和开发效率、有助于降低软件的开发和维护费用。从更广泛的意义上理解,软件工程的可重用性还应该包括:应用项目的重用,规格说明(也称为规约)的重用,设计的重用,概念和方法的重用,等等。一般来说,重用的层次越高,带来的效益也就越大。 (7)可适应性(adaptability)。软件在不同的系统约束条件下,使用户需求得到满足的难易程度。适应性强的软件应采用广为流行的程序设计语言编码,在广为流行的操作系统环境中运行,采用标准的术语和格式书写文档。适应性强的软件较容易推广使用。 (8)可移植性(portability)。软件从一个计算机系统或环境搬到另一个计算机系统或环境的难易程度。为了获得比较高的可移植性,在软件设计过程中通常采用通用的程序设计语言和运行环境支撑。对依赖于计算机系统的低级(物理)特征部分,如编译系统的目标代码生成,应相对独立、集中。这样,与处理机无关的部分就可以移植到其他系统上使用。可移植性支持软件的课重用性和课适应性。 (9)可追踪性(tracebility)。根据软件需求对软件设计、程序进行正向追踪,或根据程序、软件设计对软件需求进行逆向追踪的能力。软件可追踪性依赖于软件开发各个阶段文档和程序的完整性、一致性和可理解性。降低系统的复杂性会提高软件的可追踪性。软件在测试或维护过程中或程序在执行期间出现问题时,应记录程序事件或有关模块中的全部或部分指令现场,以便分析、追踪产生问题的因果关系。 (10)可互操作性(interoperability)。多个软件元素相互通信并协同完成任务的能力。为了实现可互操作性,软件开发通常要遵循某种标准,支持折衷标准的环境将为软件元素之间的可互操作提供便利。可互操作性在分布计算环境下尤为重要。 软件工程活动是“生产一个最终满足需求且达到工程目标的软件产品所需要的步骤”。主要包括需求、设计、实现、确认以及支持等活动。需求活动包括问题分析和需求分析。问题分析获取需求定义,又称软件需求规约。需求分析生成功能规约。设计活动一般包括概要设计和详细设计。概要设计建立整个软件体系结构,包括子系统、模块以及相关层次的说明、每一模块接口定义。详细设计产生程序员可用的模块说明,包括每一模块中数据结构说明及加工描述。实现活动把设计结果转换为可执行的程序代码。确认活动贯穿于整个开发过程,实现完成后的确认,保证最终产品满足用户的要求。支持活动包括修改和完善。伴随以上活动,还有管理过程、支持过程、培训过程等。
[编辑本段]过程
生产一个最终能满足需求且达到工程目标的软件产品所需要的步骤。软件工程过程主要包括开发过程、运作过程、维护过程。它们覆盖了需求、设计、实现、确认以及维护等活动。需求活动包括问题分析和需求分析。问题分析获取需求定义,又称软件需求规约。需求分析生成功能规约。设计活动一般包括概要设计和详细设计。概要设计建立整个软件系统结构,包括子系统、模块以及相关层次的说明、每一模块的接口定义。详细设计产生程序员可用的模块说明,包括每一模块中数据结构说明及加工描述。实现活动把设计结果转换为可执行的程序代码。确认活动贯穿于整个开发过程,实现完成后的确认,保证最终产品满足用户的要求。维护活动包括使用过程中的扩充、修改与完善。伴随以上过程,还有管理过程、支持过程、培训过程等。
[编辑本段]原则
软件工程的原则是指围绕工程设计、工程支持以及工程管理在软件开发过程中必须遵循的原则。软件工程的原则有以下四项软件工程师基本原则:
1)选取适宜开发范型
该原则与系统设计有关。在系统设计中,软件需求、硬件需求以及其他因素之间是相互制约、相互影响的,经常需要权衡。因此,必须认识需求定义的易变性,采用适宜的开发范型予以控制,以保证软件产品满足用户的要求。
2)采用合适的设计方法
在软件设计中,通常要考虑软件的模块化、抽象与信息隐蔽、局部化、一致性以及适应性等特征。合适的设计方法有助于这些特征的实现,以达到软件工程的目标。
3)提供高质量的工程支持
“工欲善其事,必先利其器”。 在软件工程中,软件工具与环境对软件过程的支持颇为重要。软件工程项目的质量与开销直接取决于对软件工程所提供的支撑质量和效用。
4)重视开发过程的管理
软件工程的管理,直接影响可用资源的有效利用,生产满足目标的软件产品,提高软件组织的生产能力等问题。因此,仅当软件过程得以有效管理时,才能实现有效的软件工程。 这一软件工程框架告诉我们,软件工程的目标是可用性、正确性和合算性;实施一个软件工程要选取适宜的开发范型,要采用合适的设计方法,要提供高质量的工程支撑,要实行开发过程的有效管理;软件工程活动主要包括需求、设计、实现、确认和支持等活动,每一活动可根据特定的软件工程,采用合适的开发范型、设计方法、支持过程以及过程管理。根据软件工程这一框架,软件工程学科的研究内容主要包括:软件开发范型、软件开发方法、软件过程、软件工具、软件开发环境、计算机辅助软件工程(CASE) 及软件经济学等。
[编辑本段]基本原理
自从1968年提出“软件工程”这一术语以来,研究软件工程的专家学者们陆续提出了100多条关于软件工程的准则或信条。美国著名的软件工程专家巴利·玻姆(Barry Boehm)综合这些专家的意见,并总结了美国天合公司(TRW)多年的开发软件的经验,于1983年提出了软件工程的七条基本原理。 玻姆认为,这七条原理是确保软件产品质量和开发效率的原理的最小集合。它们是相互独立的,是缺一不可的最小集合;同时,它们又是相当完备的。 人们当然不能用数学方法严格证明它们是一个完备的集合,但是可以证明,在此之前已经提出的100多条软件工程准则都可以有这七条原理的任意组合蕴含或派生。下面简要介绍软件工程的七条原理:
1、用分阶段的生命周期计划严格管理
这一条是吸取前人的教训而提出来的。统计表明,50%以上的失败项目是由于计划不周而造成的。在软件开发与维护的漫长生命周期中,需要完成许多性质各异的工作。这条原理意味着,应该把软件生命周期分成若干阶段,并相应制定出切实可行的计划,然后严格按照计划对软件的开发和维护进行管理。 玻姆认为,在整个软件生命周期中应指定并严格执行6类计划:项目概要计划、里程碑计划、项目控制计划、产品控制计划、验证计划、运行维护计划。
2、坚持进行阶段评审
统计结果显示: 大部分错误是在编码之前造成的,大约占63%错误发现的越晚,改正它要付出的代价就越大,要差2到3个数量级。 因此,软件的质量保证工作不能等到编码结束之后再进行,应坚持进行严格的阶段评审,以便尽早发现错误。
3、实行严格的产品控制
开发人员最痛恨的事情之一就是改动需求。但是实践告诉我们,需求的改动往往是不可避免的。这就要求我们要采用科学的产品控制技术来顺应这种要求。也就是要采用变动控制,又叫基准配置管理。当需求变动时,其它各个阶段的文档或代码随之相应变动,以保证软件的一致性。
4、采纳现代程序设计技术
从六、七时年代的结构化软件开发技术,到最近的面向对象技术,从第一、第二代语言,到第四代语言,人们已经充分认识到:方法大似气力。采用先进的技术即可以提高软件开发的效率,又可以减少软件维护的成本。
5、结果应能清楚地审查
软件是一种看不见、摸不着的逻辑产品。软件开发小组的工作进展情况可见性差,难于评价和管理。为更好地进行管理,应根据软件开发的总目标及完成期限, 尽量明确地规定开发小组的责任和产品标准,从而使所得到的标准能清楚地审查。
6、开发小组的人员应少而精
开发人员的素质和数量是影响软件质量和开发效率的重要因素,应该少而精。 这一条基于两点原因:高素质开发人员的效率比低素质开发人员的效率要高几倍到几十倍,开发工作中犯的错误也要少的多; 当开发小组为N人时,可能的通讯信道为N(N-1)/2, 可见随着人数N的增大,通讯开销将急剧增大。
7、承认不断改进软件工程实践的必要性
遵从上述六条基本原理,就能够较好地实现软件的工程化生产。但是,它们只是对现有的经验的总结和归纳,并不能保证赶上技术不断前进发展的步伐。因此,玻姆提出应把承认不断改进软件工程实践的必要性作为软件工程的第七条原理。根据这条原理,不仅要积极采纳新的软件开发技术,还要注意不断总结经验,收集进度和消耗等数据,进行出错类型和问题报告统计。这些数据既可以用来评估新的 软件技术的效果,也可以用来指明必须着重注意的问题和应该优先进行研究的工具和技术。
[编辑本段]方法学
软体工程的方法有很多方面的意义。包括专案管理,分析,设计,程序的编写,测试和质量控制。 软件工程师软体设计方法可以区别为重量级的方法和轻量级的方法。重量级的方法中产生大量的正式文档。 著名的重量级开发方法包括ISO9000,CMM,和统一软体开发过程(RUP)。 轻量级的开发过过程没有对大量正式文档的要求。着名的轻量级开发方法包括极限编程(XP)和敏捷流程(AgileProcesses)。 根据《新方法学》这篇文章的说法,重量级方法呈现的是一种防御型的姿态。在应用重量级方法的软体组织中,由于软体项目经理不参与或者很少参与程序设计,无法从细节上把握项目进度,因而会对项目产生恐惧感,不得不要求程式设计师不断撰写很多“软体开发文档”。而轻量级方法则呈现“进攻型”的姿态,这一点从XP方法特别强调的四个准则—“沟通、简单、反馈和勇气上有所体现。目前有一些人认为,重量级方法合于大型的软体团队(数十人以上)使用,而“轻量级方法”适合小型的软体团队(几人、十几人)使用。当然,关于重量级方法和轻量级方法的优劣存在很多争论,而各种方法也在不断进化中。 一些方法论者认为人们在开发中应当严格遵循并且实施这些方法。但是一些人并不具有实施这些方法的条件。实际上,采用何种方法开发软体取决于很多因素,同时受到环境的制约。
[编辑本段]主要课程
外语、高等数学、线性代数、高等代数、电子技术基础、离散数学、计算机引论(C语言)、数据结构、C++程序设计、JAVA程序设计、Delphi程序设计、汇编语言程序设计、算法设计与分析、计算机组成原理与体系结构、数据库系统、计算机网络、软件工程、软件测试技术、软件需求与项目管理、软件设计实例分析、CMM/ISO9000等。 另外,还包括操作系统、软件体系结构概论、设计模式、多媒体技术基础、UML建模、概率论、大学英语等,部分院校还会包括大学物理,工程制图,数值分析等。
[编辑本段]发展方向
敏捷开发(Agile Development)被认为是软体工程的一个重要的发展。它强调软体开发应当是能够对未来可能出现的变化和不确定性作出全面反应的。 敏捷开发被认为是一种“轻量级”的方法。在轻量级方法中最负盛名的应该是“极限编程”(Extreme Programming,简称为XP)。而与轻量级方法相对应的是“重量级方法”的存在。重量级方法强调以开发过程为中心,而不是以人为中心。重量级方法的例子比如CMM/PSP/TSP。 面向侧面的程序设计(Aspect Oriented Programming,简称AOP)被认为是近年来软体工程的另外一个重要发展。这里的方面指的是完成一个功能的对象和函数的集合。在这一方面相关的内容有泛型编程(Generic Programming)和模板。
[编辑本段]需求分析
软件工程中包含需求、设计、编码和测试四个阶段,其中需求工程是软件工程第一个也是很重要的一个阶段,本文以医院管软件工程需求分析理系统为例详细介绍了需求工程的构成和进行方法。 首先人们必须了解需求工程和其他项目过程的关系: 图1需求与其他项目过程的关系 软件需求包括三个不同的层次-业务需求、用户需求和功能需求-也包括非功能需求:业务需说明了提供给客户和产品开发商的新系统的最初利益,反映了组织机构或客户对系统、产品高层次的目标要求,它们在项目视图与范围文档中予以说明;用户需求文档描述了用户使用产品必须要完成的任务,这在使用实例文档或方案脚本说明中予以说明;功能需求定义了开发人员必须实现的软件功能,使得用户能完成他们的任务,从而满足了业务需求。 需求工程分为了需求开发和需求管理两个阶段:下面就以这两个阶段说明: 一,需求开发 需求开发又分为需求获取、需求分析、编写规格说明书和需求验证。以下列出和讲解分析常规的步骤,当然应按照项目的大小和特点等实际情况我们应该自己确定合适的步骤。 1.需求获取: 1)确定需求开发过程:确定需求开发过程确定如何组织需求的收集、分析、细化并核实的步骤,并将它编写成文档。对重要的步骤要给予一定指导,这将有助于分析人员的工作,而且也使收集需求活动的安排和进度计划更容易进行。 2)编写项目视图和范围文档:项目视图和范围文档应该包括高层的产品业务目标,所有的使用实例和功能需求都必须遵从能达到的业务需求。项目视图说明使所有项目参与者对项目的目标能达成共识。而范围则是作为评估需求或潜在特性的参考。 表1项目视图和范围文档的模板 a、1背景在这一部分,总结新产品的理论基础,并提供关于产品开发的历史背景或形势的一般性描述。 a、2业务机遇描述现存的市场机遇或正在解决的业务问题。描述商品竞争的市场和信息系统将运用的环境。包括对现存产品的一个简要的相对评价和解决方案,并指出所建议的产品为什么具有吸引力和它们所能带来的竞争优势。 a、3业务目标用一个定量和可测量的合理方法总结产品所带来的重要商业利润,把重点放在给业务的价值上。 a、4客户或市场需求描述一些典型客户的需求,包括不满足现有市场上的产品或信息系统的需求。提出客户目前所遇到的问题在新产品中将可能(或不可能)出现的阐述,提供客户怎样使用产品的例子。确定了产品所能运行的软、硬件平台。 a、5提供给客户的价值确定产品给客户带来的价值,并指明产品怎样满足客户的需要。 a、6业务风险总结开发(或不开发)该产品有关的主要业务风险,例如市场竞争、时间问题、用户的接受能力、实现的问题或对业务可能带来的消极影响。预测风险的严重性,指明你所能采取的减轻风险的措施。 b.1项目视图陈述编写一个总结长远目标和有关开发新产品目的的简要项目视图陈述。项目视图陈述将考虑权衡有不同需求客户的看法。它可能有点理想化,但必须以现有的或所期待的客户市场、企业框架、组织的战略方向和资源局限性为基础。 b.2主要特性包括新产品将提供的主要特性和用户性能的列表。强调的是区别于以往产品和竞争产品的特性。可以从用户需求和功能需求中得到这些特性。 b.3假设和依赖环境在构思项目和编写项目视图和范围文档时,要记录所作出的任何假设。通常一方所持的假设应与另一方不同。 c.1首次发行的范围总结首次发行的产品所具有的性能。描述了产品的质量特性,这些特性使产品可以为不同的客户群提供预期的成果。c.2随后发行的范围如果你想象一个周期性的产品演变过程,就要指明哪一个主要特性的开发将被延期,并期待随后版本发行的日期。 c.3局限性和专用性明确定义包括和不包括的特性和功能的界线是处理范围设定和客户期望的一个途径。列出风险承担者们期望的而你却不打算把它包括到产品中的特性和功能。 d.1客户概貌客户概述明确了这一产品的不同类型客户的一些本质的特点,以及目标市场部门和在这些部门中的不同客户的特征。 d.2项目的优先级一旦明确建立项目的优先级,风险承担者和项目的参与者就能把精力集中在一系列共同的目标上。达到这一目的的一个途径是考虑软件项目的五个方面:性能、质量、计划、成本和人员。e.产品成功的因素明确产品的成功是如何定义和测量的,并指明对产品的成功有巨大影响的几个因素。不仅要包括组织直接控制的范围内的事务,还要包括外部因素。如果可能,可建立测量的标准用于评价是否达到业务目标. 3)用户群分类:产品的用户在很多方面存在着差异,例如:用户使用产品的频度、他们的应用领域和计算机系统知识、他们所使用的产品特性、他们所进行的业务过程、他们在地理上的布局以及他们的访问优先级。根据这些差异,你可以把这些不同的用户分成小组。用户类不一定都指人,你可以把其它应用程序或系统接口所用的硬件组件也看成是附加用户类的成员。以这种方式来看待应用程序接口,可以帮助你确定产品中那些与外部应用程序或组件有关的需求。将用户群分类并归纳各自特点为避免出现疏忽某一用户群需求的情况,要将可能使都有所差异。详细描述出它们的个性特点及任务状况,将有助于产品设计。 4)选择产品代表:择每类用户的产品代表为每类用户至少选择一位能真正代表他们需求的人作为那一类用户的代表并能作出决策。这对于内部信息系统的开发是最易实现的,因为此时,用户就是身边的职员。而对于商业开发,就得在主要的客户或测试者中建立起良好的合作关系,并确定合适的产品代表。他们必须一直参与项目的开发而且有权作出决策。每一个产品代表者代表了一个特定的用户类,并在那个用户类和开发者之间充当主要的接口。 5)建立核心队伍:建立起典型用户的核心队伍把同类产品或产品的先前版本用户代表召集起来,从他们那里收集目前产品的功能需求和非功能需求。这样的核心队伍对于商业开发尤为有用,因为你拥有一个庞大且多样的客户基础。与产品代表的区别在于,核心队伍成员通常没有决定权。 6)确定使用实例:让用户代表确定使用实例从用户代表处收集他们使用软件完成所需任务的描述-使用实例,讨论用户与系统间的交互方式和对话要求。在编写使用实例的文档时可采用标准模版,在使用实例基础上可得到功能需求。 一个单一的使用实例可能包括完成某项任务的许多逻辑相关任务和交互顺序。因此,一个使用实例是相关的用法说明的集合,并且一个说明是使用实例的例子。在描述时列出执行者和系统之间相互交互或对话的顺序。当这种对话结束时,执行者也达到了预期的目的。 对于一些复杂的使用实例,画出图形分析模型是有益的,这些模型包括数据流程图、实体关系图、状态转化图、对象类和联系图。 使用实例的描述并不向开发者提供他们所要开发的功能的细节。为了减少这种不确定性,需要把每一个使用实例叙述成详细的功能需求。每一个使用实例可引伸出多个功能需求,这将使执行者可以执行相关的任务;并且多个使用实例可能需要相同的功能需求。使用实例方法给需求获取带来的好处来自于该方法是以任务为中心和以用户为中心的观点。比起使用以功能为中心的方法,使用实例方法可以使用户更清楚地认识到新系统允许他们做什么。 每一个使用实例都描述了一个方法,用户可以利用这个方法与系统进行交互,从而达到特定的目标。使用实例可有效地捕捉大多数所期望的系统行为,但是你可能有一些需求,这些需求与用户任务或其他执行者之间的交互没有特定的关系。这时你就需要一个独立的需求规格说明。 7)召开应用程序开发联系会议:召开应用程序开发联系会议应用程序开发联系会议是范围广的、简便的专题讨论会,也是分析人员与客户代表之间一种很好的合作办法,并能由此拟出需求文档的底稿。该会议通过紧密而集中的讨论得以将客户与开发人员间的合作伙伴关系付诸于实践。 8)分析用户工作流程:分析用户工作流程观察用户执行业务任务的过程。画一张简单的示意图(最好用数据流图)来描绘出用户什么时候获得什么数据,并怎样使用这些数据。编制业务过程流程文档将有助于明确产品的使用实例和功能需求。你甚至可能发现客户并不真地需要一个全新的软件系统就能达到他们的业务目标。 9)确定质量属性:确定质量属性和其它非功能需求在功能需求之外再考虑一下非功能的质量特点,这会使你的产品达到并超过客户的期望。对系统如何能很好地执行某些行为或让用户采取某一措施的陈述就是质量属性,这是一种非功能需求。听取那些描述合理特性的意见:快捷、简易、直觉性、用户友好、健壮性、可靠性、安全性和高效性。你将要和用户一起商讨精确定义他们模糊的和主观言辞的真正含义。 10)检查问题报告:通过检查当前系统的问题报告来进一步完善需求客户的问题报告及补充需求为新产品或新版本提供了大量丰富的改进及增加特性的想法,负责提供用户支持及帮助的人能为收集需求过程提供极有价值的信息。 11)需求重用:跨项目重用需求如果客户要求的功能与已有的产品很相似,则可查看需求是否有足够的灵活性以允许重用一些已有的软件组件。
关于反应过程开发方法实例的论文
LZ好,代写毕业论文QQ:82912600
网址:
Visual C++提供的几种数据库访问技术
(1)ODBC(Open DataBase Connectivity) :作为一个数据库操作接口,ODBC提供了一个允许单一应用程序去访问许多不同数据库管理系统的机制, 应用非常广泛。
(2)MFC ODBC (Microsoft Foundation Classes ODBC) :MFC ODBC是Visual C++对ODBC API封装得到的,可以简化程序设计,但无法对数据源进行底层操作。
(3)DAO(Data Access Objects) :DAO提供了一种通过程序代码创建和操纵数据库的机制。多个DAO构成一个体系结构。在这个结构中,各个DAO对象协同工作。
(4)OLE DB(Object Link and Embedding DataBase) :OLE DB是Visual C++开发数据库应用中提供的基于COM接口的新技术,因此OLE DB对所有的文件系统都提供了统一的接口。直接使用OLE DB来设计数据库应用程序需要大量的代码。在VC中提供了ATM模板,用于设计OLE DB数据应用程序和数据提供程序。它是一种底层接口。
(5)ADO(ActiveX Data Objects) :ADO技术是基于OLE DB的访问接口,对OLE DB的接口作了封装,定义了ADO对象,使得程序开发得到简化,它属于数据库访问的高层接口。
第三章 系统功能详细设计
3. 1 需求分析
需求分析的主要任务是确定系统必须完成哪些工作,也就是对目标系统提出完整的、准确的、具体的、清晰的要求,确定系统必须具有的功能和性能,系统要求的运行环境,并且预测系统发展的前景,并仔细分析系统中的数据,以便完成良好的软件环境。在需求分析阶段系统分析员将仔细研究软件需要完成的具体功能。
需求分析的结果是软件开发的基础,必须仔细验证它的正确性,开发人员必须和用户取得完全一致的意见,需求分析的文档应该被用户所确认。然而这并不意味着分析员应该不假思索的全盘接受用户提出的所有要求,对用户提出的笼统要求应该分解细化,对用户提出的含混的要求需要进一步澄清,对用户提出的不切实际的要求必须做深一步细致的解释说服工作,以便动员用户放弃不合理的要求。
(1) 从用户角度
从人事部门档案管理员的角度出发,应用计算机这样的现代化技术工作,当然比用原来的方法方便、快捷。所以有一个良好的“人事管理信息系统”软件是符合时代发展的。当档案管理员进入本系统后,首先进入“基本信息管理”部分,可以很清晰地看到企业的所有部门,还可以查询员工所属部门及个人简历等。然后依次为考勤考评管理 系统用户管理 数据库操作。只有管理员可以添加用户和修改密码,一般用户无此权限。
(2) 从实现角度
从实现角度来说,用户在操作这个软件时,要求这个软件不但要实现强大的功能,完成用户的全部要求之外,还要求这个软件实现的灵活性,安全性。在灵活性方面,比如可以实现企业员工的调转;在安全性方面,普通用户是无法添加用户和修改密码的。
(3) 从实现功能
本应用系统应达到的目标概述如下:
① 为企业内部各个业务部门提供数据查询功能。
② 实现员工管理、考勤管理、考评管理等功能。
③ 为企业管理层提供直观、及时、方便的信息,提高迅速反应能力、提供有效的决策支持。
总之,从用户角度看,要求程序员设计的软件应尽量完成用户所设想的所有功能,完成用户的全部设想,并没有考虑设计中的难度问题,而在程序员设计中,只能尽可能的完成用户需要的所有信息,但难免出现技术难题,这就要求双方不断研究讨论,相互协调,相互补充。
3. 2 功能设计
根据需求分析得出的结论,本系统要具有对员工进行全方位数字化的管理功能,目的是为了提高工作效率减少操作失误。还要具有数据库还原和备份、用户权限设置、系统日志查看等功能,旨在达到使企业员工的管理更加方便快捷以提高工作效率。本系统主要分为四大模块:基本信息管理、考勤考评管理、系统用户管理、数据库操作。
其结构图如下:
其流程图如下:
3. 3 数据库结构设计
(1) 员工与部门间的关系 (E—R图)
(2) 数据库的创立
建立员工信息表:
Create table employees (
Emp_id [int] (4) ,
Emp_name [varchar] (50) ,
Sex [char] (2) ,
Nationality [varchar] (40) ,
Birth [varchar] (20) ,
Political_party [varchar] (40) ,
Culture_level [varchar] (40) ,
Marital_condition [varchar] (20) ,
Family_place [varchar] (60) ,
Id_card [varchar] (20) ,
Badgeid [varchar] (40) ,
Office_number [varchar] (30) ,
Mobile [varchar] (30) ,
Files_keep_orp [varchar] (100) ,
Hukou [varchar] (100) ,
Hiredate [varchar] (20) ,
Dep_id [int] (4) ,
Position [varchar] (40) ,
Title [varchar] (20) ,
State [tinyint] (1) ,
Upperld [int] (4) ,
Contract_duration [varchar] (20) ,
Memo [varchar] (100) ,
Fillin_person [varchar] (30) ,
Fillin_time [varchar] (20) )
建立考勤表:
Create table checkin (
Checkdate [char] (10) ,
Emp_id [int] (4) ,
Qqpays [demical] (5(4,1)) ,
Ccdays [demical] (5(4,1)) ,
Bjdays [demical] (5(4,1)) ,
Sjdays [demical] (5(4,1)) ,
Kgdays [demical] (5(4,1)) ,
Fdxjdays [demical] (5(4,1)) ,
Nxjdays [demical] (5(4,1)) ,
Dxjdays [demical] (5(4,1)) ,
Cdminutes [tinyint] (1) ,
Ztminutes [tinyint] (1) ,
Otdays1 [demical] (5(4,1)) ,
Otdays2 [demical] (5(4,1)) ,
Otdays3 [demical] (5(4,1)) ,
Memo [varchar] (200)
)
3. 4 系统功能模块设计
1、建立系统登陆窗口
本系统启动时,按F2或连接选项,进入用户登陆的界面。为了维护系统的安全性,防止非法用户登录进行系统设置,需要对系统的登录用户进行验证。用户输入用户名与用户密码,如果用户名与用户密码都正确,点击确定进入系统,否则不能进入本系统,点击取消回到初始界面。
2 建立系统主程序窗口
登陆系统后,首先进入的是主窗体,有五个选项分别为人事系统、基本信息管理、考勤考评信息管理、系统用户管理、数据库操作。
为了使用户的操作简单与方便,以及整个系统的整体性,首界面的设计使用了MDI窗体,并且所有的功能都集中在一个菜单内,并且为一些经常用的功能设计了右键的快捷键。
(1) 人事系统:在该下拉菜单中可以选择“退出”选项退出本系统
(2) 基本信息管理:
① 部门信息:在系统中,点击基本信息管理的下拉菜单中的部门管理,可以很清楚地看到该企业的下属部门,如:人事部、公关部、组织部等。可以根据需要添加、删除部门,点击修改,可以修改部门名称和部门描述。点击关闭,返回主窗体。
② 员工信息:系统自动生成员工自己的工作号。管理员可以添加、删除、修改员工的基本信息,包括:姓名、性别、民族、出生日期、政治面貌、文化程度、婚姻状况、档案所在地、户口所在地、身份证号、电话号、到岗日期、所在部门、工作岗位、职务、合同有效期、备注信息等。
还可以根据输入员工姓名、在职情况进行查询员工信息,可以看到员工的基本信息。选中某一员工的姓名,还可以查看家庭成员的信息及个人经历,包括父母姓名、性别、年龄、和员工关系、工作,员工的入学、毕业时间、毕业学校、在校职位等。选中员工,点击部门调转,选择要调转的部门,按确定调转成功,按取消返回员工信息管理界面。
③ 登陆日志:对登陆该人事管理系统的事件加以记录。
(3)考勤考评信息管理:
① 考勤信息:主要记录员工的出勤情况。包括员工姓名、全勤、出差、病假、事假、旷工、法定休假、年休假、倒休假天数、迟到、早退时间、一类加班天数、二类加班天数、三类加班天数、备注信息等。若选中部门,选择月份,可以查看该月该部门的出勤情况。还可以对考勤信息进行添加、删除、修改。
② 考评信息:主要是对员工的工作表现进行考核的,包括员工姓名、总体评价、奖励事由、奖励金额、处罚事由、处罚金额、备注信息等。选择部门,选中员工姓名,点击设置可以编辑员工考评信息。点击确定,添加成功,若点击取消,返回考评信息界面。
(4) 系统用户管理:
① 用户管理:可以添加、删除登陆用户信息,但只有管理员有权限。系统启动的时候有一个管理员用户,使用这个用户登录后,可以添加其他用户,而且每一个用户都可以更改自己的密码。
② 修改密码:每个用户可根据自己的需要修改密码。输入新密码后,还需要重新输入新密码进行确认。
(5) 数据库操作:是对数据库的一系列操作,包括数据备份和数据还原。
结 论
随着信息产业技术的迅速发展、计算机应用的进一步普及,越来越多的公司企业实行“无纸化办公”,这当然也给了各种管理系统很大的生存空间。选择使用人事管理信息系统,可以节省人力和财力,提高工作效率。经过近一个学期的设计和开发,人事管理信息系统基本开发完毕。该系统能够完成企业人员管理、调转、基本情况的各种操作,并且具有输入修改等相关设置。同时提供系统维护功能,使用户方便进行数据添加、修改、删除,且考虑到了系统的安全性设置了登录密码。
通过对毕业设计的学习,我对Visual C++ 有了深刻的了解和认识,但仍有许多不足:编程能力这一环节还很薄弱。毕业设计是对我们这四年来学习的知识一个检验,让我们把所学知识融会贯通,并且和实际工作想结合,从而使理论知识得到了验证,积累了宝贵的实践经验。
由于毕业设计时间较短,该系统还有许多不完善的地方。比如数据库操作部分还不是很完善,只是对数据备份和数据还原设置了没有权限,另外对话框也不够美观等缺点。我在以后还会继续改进和完善。
致 谢
近一个学期的毕业设计已经结束了,在这短短的设计时间里,我得到了李晖老师的关心和帮助。她给了我们很多的指导,与我们一起探讨问题,询问我们遇到了哪些问题。当我们遇到技术上难以解决的问题时,她就会指导我们解决问题,她把自己多年来积累的经验教授给我们,使我们顺利地完成了毕业设计任务。在这里我特别向在毕业设计过程中给予我极大帮助的李晖老师表示衷心的感谢。
时间过得真快,大学四年的学习生活即将结束,经过四年的大学学习和毕业设计阶段的提高,使我本身的知识得到提高的同时,也增强了我对工作的信心,我相信自己有能力胜任将来的工作。在即将离校之际,我衷心的感谢母校四年来对我的培养,感谢计算机系老师对我的教导,感谢我的毕业设计老师——李晖老师对我的指导,感谢同学们对我无私的帮助。
参考文献:
1 张海藩 著《软件工程导论》 清华大学出版社 1997年
2 萨师煊 王姗 著《数据库系统概述》 高等教育出版社 2000年2月
3 曹军生 著 《SQL SERVER 2000实用教程》 北京理工大学出版社 2001年
4 李小喆 著 《SQL SERVER 2000 管理及应用系统开发》 人民邮电出版社 2001年
5 Marci Frohock Garcia Jamie reding Edward Whalen Steve Adrien Deluca 著;
孙岩 黄波 张宁 译 《SQL Server2000 系统管理员宝典》 清华大学出版社 2002年
6 郑章、程刚、张勇 Visual C++6.0数据库开发技术 机械出版社 1999年
7 李民谚、吴继刚、周学明Visual C++6.0 数据库系统开发实例导航
人民邮电出版社 2002年
8 伍俊良 Visual C++课程设计与系统开发案例 清华大学出版社 2002年
9 陈维兴、林小茶 C++面向对象程序设计教程 清华大学出版社 2000年
10 冯华 Visual C++数据库开发技巧与实例 机械工业出版社 2000年
11 杨小平 Visual C++项目案例导航 科学出版社 2002年
12 同志工作室 Visual C++ 6.0数据库开发实例 人民邮电出版社 2001年
13 谭浩强主编 Visual C++实用教程 电子工业出版社 2000年 26964希望对你有帮助!
参考资料:. chmryiq
软件开发案例讲解(1500字左右),急急急~~~~
那要对着具体的软件项目来讲的啊!而且也有分不同类型的软件。
某中小型企业创业案例分析,论文。有哪些企业算中小型?最好是要资料多的
送你一句话“心急吃不鸟热豆腐”,首先必须跟自己定个目标,自己适合走什么样的路?包括开发语言等等。。学软件开发你也知道这行竞争力很强的,压力也很大,所以之前一定要做好充分的准备,找工作是首要的,大城市机会多,前途也大,当然你付出的就要多很多,比如那边门槛要高,要求也高。个人觉得年轻人就是要趁早出来闯一下(难道等自己老了再去,后悔也来不及了)况且你现在就想自己单干了,有志气!说明你很自信,有能力,这点很欣赏你,那么这样的人找工作相信也不是难事!!
找工作自己不要要求太高,能找到一个适合自己,能锻炼自己的就OK了,况且现在工作不好找(当然你有足够的能力,那就无所谓了),工作的时候遇到的问题,那就太多了,BUG,程序崩溃,报错。。。。。
遇到这样的首先不要去问别人,自己解决,包括上网查资料==,实在是解决不鸟的再问同事,作为一个开发人员一定要虚心谨慎,冷静的处理问题,不要心急(编码测试的时候,大量的代码会让你头疼),和同事和睦相处这一点很重要
单干5年内你就甭想了,经验非常重要。。很多东西都是实践学来的
单干一般自己都有一定规模的办公地,还有其他。。之类的。想想这都是不少的花费。当务之急就是找个好工作,不要急于求成,否则只会事与愿违,祝你成功!!
会计论文哪些题目比较好写?
提供一些会计学年论文的参考题目,供参考。
一、会计方面(含会计理论、财务会计、成本会计、资产评估)
1.金融衍生工具研究
2.财务报表粉饰行为及其防范
3.试论会计造假的防范与治理
4.会计诚信问题的思考
5.关于会计职业道德的探讨
6.论会计国际化与国家化
7.论稳健原则对中国上市公司的适用性及其实际应用
8.关于实质重于形式原则的运用
9.会计信息相关性与可靠性的协调
10.企业破产的若干财务问题
11.财务会计的公允价值计量研究
12.论财务报告的改进
13.论企业分部的信息披露
14.我国证券市场会计信息披露问题研究
15.上市公司治理结构与会计信息质量研究
16.论上市公司内部控制信息披露问题
17.关于企业合并报表会计问题研究
18.我国中小企业会计信息披露制度初探
19.现金流量表及其分析
20.外币报表折算方法的研究
21.合并报表若干理论的探讨
22.增值表在我国的应用初探
23.上市公司中期报告研究
24.现行财务报告模式面临的挑战及改革对策
25.表外筹资会计问题研究
26.现行财务报告的局限性及其改革
27.关于资产减值会计的探讨
28.盈余管理研究
29.企业债务重组问题研究
30.网络会计若干问题探讨
31.论绿色会计
32.环境会计若干问题研究
33.现代企业制度下的责任会计
34.人本主义的管理学思考――人力资源会计若干问题
35.试论知识经济条件下的人力资源会计
36.全面收益模式若干问题研究
37.企业资产重组中的会计问题研究
38.作业成本法在我国企业的应用
39.战略成本管理若干问题研究
40.内部结算价格的制定和应用
41.跨国公司转让定价问题的探讨
42.我国企业集团会计若干问题研究
43.责任成本会计在企业中的运用与发展
44.试论会计监管
45.会计人员管理体制问题研究
46.高新技术企业的价值评估
47.企业资产重组中的价值评估
48.企业整体评估中若干问题的思考
49.新会计制度对企业的影响
50.《企业会计制度》的创新
51.我国加入WTO后会计面临的挑战
52.XX准则的国际比较(例如:中美无形资产准则的比较)
53.新旧债务重组准则比较及对企业的影响
54.无形资产会计问题研究
55.萨宾纳斯――奥克斯莱法案对中国会计的影响
56.对资产概念的回顾与思考
57.规范会计研究与实证会计研究比较分析
58.试论会计政策及其选择
59.对虚拟企业几个财务会计问题的探讨
60.知识经济下无形资产会计问题探讨
61.两方实证会计理论及其在我国的运用
二、财务管理方面(含财务管理、管理会计)
1.管理层收购问题探讨
2.MBO对财务的影响与信息披露
3.论杠杆收购
4.财务风险的分析与防范
5.投资组合理论与财务风险的防范
6.代理人理论与财务监督
7.金融市场与企业筹资
8.市场经济条件下企业筹资渠道
9.中西方企业融资结构比较
10.论我国的融资租赁
11.企业绩效评价指标的研究
12.企业资本结构优化研究
13.上市公司盈利质量研究
14.负债经营的有关问题研究
15.股利分配政策研究
16.企业并购的财务效应分析
17.独立董事的独立性研究
18.知识经济时代下的企业财务管理
19.现代企业财务目标的选择
20.中小企业财务管理存在的问题及对策
21.中小企业融资问题研究
22.中国民营企业融资模式――上市公司并购
23.债转股问题研究
24.公司财务战略研究
25.财务公司营运策略研究
26.资本经营若干思考
27.风险投资运作与管理
28.论风险投资的运作机制
29.企业资产重组中的财务问题研究
30.资产重组的管理会计问题研究
31.企业兼并中的财务决策
32.企业并购的筹资与支付方式选择研究
33.战略(机构)投资者与公司治理
34.股票期权问题的研究
35.我国上市公司治理结构与融资问题研究
36.股权结构与公司治理
37.国际税收筹划研究
38.企业跨国经营的税收筹划问题
39.税收筹划与企业财务管理
40.XXX税(例如企业所得税)的税收筹划
41.高新技术企业税收筹划
42.入世对我国税务会计的影响及展望
43.我国加入WTO后财务管理面临的挑战
44.管理会计在我国企业应用中存在的问题及对策
45.经济价值增加值(EVA)――企业业绩评价新指标
三、审计方面
1.关于CPA信任危机问题的思考
2.注册会计师审计质量管理体系研究
3.论会计师事务所的全面质量管理
4.注册会计师审计风险控制研究
5.企业内部控制制度研究
6.现代企业内部审计发展趋势研究
7.审计质量控制
8.论关联方关系及其交易审计
9.我国内部审计存在的问题及对策
10.论审计重要性与审计风险
11.论审计风险防范
12.论我国的绩效审计
13.萨宾纳斯――奥克斯莱法案对中国审计的影响
14.审计质量与审计责任之间的关系
15.经济效益审计问题
16.内部审计与风险管理
17.我国电算化审计及对策分析
18.浅议我国的民间审计责任
19.试论审计抽样
20.论内部审计的独立性
21.论国有资产保值增值审计
22.论企业集团内部审计制度的构建
四、电算化会计类
1.论电子计算机在审计中的应用
2.电算化系统审计
3.关于会计电算化在企业实施的经验总结
4.计算机在管理会计中的应用
5.试论会计软件的发展思路
6.当前会计电算化存在的问题与对策
7.会计电算化软件和数据库的接口研究
8.我国会计电算化软件实施中的问题及对策
9.中外会计电算化软件比较研究
10.会计电算化系统中的组织控制问题
11.会计电算化系统下的内部控制问题新特点研究
12.商用电算化软件开发与实施中的问题探讨
13.会计软件开发中的标准化问题研究
14.我国会计软件的现状与发展方向问题研究
15.会计电算化实践对会计工作的影响与对策
16.我国会计电算化软件市场中的问题与调查
17.通用帐务处理系统中的会计科目的设计
18.会计软件开发中如何防止科目串户的探讨
19.关于建立管理会计电算化的系统的构想
20.会计电算化系统与手工会计系统的比较研究
21.会计电算化后的会计岗位设计问题研究
22.关于我国会计电算化理论体系的构想
23.会计电算化软件在使用中存在的问题和解决办法的探讨
24.计算机网络系统在管理中的应用
25.会计电算化在我省开展的现状研究
26.关于会计电算化审计中的若干问题的探讨
27.会计电算化软件和数据库的结合应用
28.会计电算化内部控制的若干典型案例
29.会计电算化理论和实际使用的几点看法
30.会计电算化和手工系统并行运用的经验
31.Foxpro在会计工作中的应用和体会
求一篇关于 软件体系结构分析 的论文
软件体系结构论文:一种面向方面软件体系结构模型
摘 要: 为了分离软件系统中的核心关注点和横切关注点,通过引入面向方面软件开发的思想设计了一种面向方面软件体系结构模型,并详细分析了该模型的三个基本构成单元,即构件、连接件和方面构件。最后通过一个网上支付实例验证了该模型具有一定的理论意义和实用价值。
关键词: 面向方面软件体系结构;横切关注点;构件;连接件;方面构件
20世纪60年代的软件危机使得人们开始重视软件工程的研究。起初,人们把软件设计的重点放在数据结构和算法的选择上,然而随着软件系统规模越来越大,对总体的系统结构设计和规格说明变得异常重要。随着软件危机程度的加剧,软件体系结构(software architecture)这一概念应运而生。软件体系结构着眼于软件系统的全局组织形式,在较高层次上把握系统各部分之间的内在联系,将软件开发的焦点从成百上千的代码上转移到粒度较大的体系结构元素及其交互的设计上。与传统软件技术相比,软件体系结构理论的提出不仅有利于解决软件系统日益增加的规模和复杂度的问题,有利于构件的重用,也有利于软件生产率的提高。面向方面软件开发(AOSD)认为系统是由核心关注点(corn concern)和横切关注点(cross-cutting concern)有机地交织在一起而形成的。核心关注点是软件要实现的主要功能和目标,横切关注点是那些与核心关注点之间有横切作用的关注点,如系统日志、事务处理和权限验证等。AOSD通过分离系统的横切关注点和核心关注点,使得系统的设计和维护变得容易很多。
Extremadura大学的Navasa等人[1]在2002年提出了将面向方面软件开发技术引入到软件体系结构的设计中,称之为面向方面软件体系结构(aspect oriented software architecture,AO-SA),这样能够结合两者的优点,但是并没有给出构建面向方面软件体系结构的详细方法。
尽管目前对于面向方面软件体系结构这个概念尚未形成统一的认识,但是一般认为面向方面软件体系结构在传统软件体系结构基础上增加了方面构件(aspect component)这一新的构成单元,通过方面构件来封装系统的横切关注点。目前国内外对于面向方面软件体系模型的研究还相对较少,对它的构成单元模型的研究更少,通常只关注方面构件这一构成单元。方面构件最早是由Lieberherr等人[2]提出的,它是在自适应可插拔构件(adaptive plug and play component,APPC)基础之上通过引入面向方面编程(AOP)思想扩展一个可更改的接口而形成的,但它关于请求接口和服务接口的定义很模糊,未能给出一个清晰的方面构件模型。Pawlak等人[3]提出了一个面向方面的框架,该框架主要包含了一个方面构件模型———Java方面构件(Java aspect component,JAC),但该方面构件模型仅包含了切点(pointcut),并把AOP中装备(advice)集成到了切点的表达式中,它主要从实现的角度进行了阐述,并没有给出详细的方面构件模型。本文没有只关注面向方面软件体系结构中方面构件这一构成单元模型,还详细分析了它的另外两个构成单元,即构件和连接件,因为面向方面软件体系结构各部分之间是相互关联的。
1面向方面软件体系结构相关概念
面向方面软件体系结构涉及诸多概念,以下将分别介绍。软件体系结构在软件工程领域有着广泛的影响,但当前仍未形成一个统一的、标准的定义。目前国内外普遍认可的看法是软件体系结构包含构件、连接件和约束[4]。其中约束描述了体系结构配置和拓扑的要求,确定了体系结构的构件与连接件的连接关系。这样就可以把软件体系结构写成
软件体系结构(software architecture)=构件(components)+
连接件(connectors)+约束(constraints)
构件是软件体系结构的基本元素之一。一般认为,构件是指具有一定功能、可明确辨识的软件单位,并且具备语义完整、语法正确、有可重用价值的特点,然而目前对于构件的具体结构及构成并没有一个统一的标准[5],而且一些主要的构件技术也没有使用相同的构件类型。另外,当前被广泛接受的构件定义并不包含具体的软件构件模型(software component model)。例如,Szyperski等人[6]给出了软件构件一个很有名的定义:软件构件是一个仅带特定契约接口和显式语境依赖的结构单位,它可以独立部署,易于第三方整合。但是关于软件构件模型有一个被普遍接受的观点是:软件构件是一个具有服务提供和服务请求功能的软件单元[7]。
连接件是软件体系结构另一个基本的构成元素,是用来建立构件间交互以及支配这些交互规则的构造模块。连接件最先是由Shaw[8]提出来的,她建议把连接件作为软件体系结构中第一类实体,用来表示普通构件之间的交互关系。目前对于连接件尚未形成统一的认识,尽管在软件体系结构中强调了连接件存在的必要性,但是关于连接件模型的研究还很少,连接件的实际应用还不成熟。
面向方面软件体系结构在传统软件体系结构的基础上增加了方面构件单元。通常认为,方面构件是封装了系统横切关注点的一类特殊的构件。目前关于方面构件模型的研究还处于起步阶段。
2面向方面软件体系结构模型
由于传统软件体系结构模型包含构件、连接件和约束,而面向方面软件体系结构是在传统软件体系结构的基础之上扩展了方面构件,所以面向方面软件体系模型结构包含构件、连接件、方面构件和约束。其中约束描述了面向方面体系结构配置和拓扑的要求,确定了体系结构的构件、连接件和方面构件之间的连接关系,而构件、连接件、方面构件是它的三个基本的构成单元。以下对这三个构成单元的模型进行详细的设计。
2.1构件模型
构件模型由以下几个要素构成(图1):
(a)端口。
构件的服务请求和服务提供功能是通过端口来实现的。端口是构件与外部环境进行交互的惟一通道。一般的构件模型通常采用两种端口,即双向端口和单向端口。在使用双向端口的构件模型中,服务请求和服务提供功能可以在同一个端口中实现。本文中的构件模型使用单向端口,此种端口分为请求端口和服务端口两种类型。
(a)服务端口。构件通过服务端口向其他构件提供服务。构件通过服务端口向其他构件的请求消息进行应答,返回响应消息。每个服务端口对应一个接口。
(b)请求端口。构件通过请求端口向其他构件请求服务。构件为了实现自己的业务功能,需要通过请求端口向其他构件发送请求消息。每个服务端口也对应一个接口。
(b)接口。
它定义了一个到多个业务功能。这些业务功能由服务端口进行提供,并由请求端口进行使用。一个接口限定了一个特定端口可以进行的交互功能,接口是构件间交互的契约。通常的接口类型有:Java Interface、WSDL 1.1 portTypes和WSDL 2.0 Interfaces等,也可以自定义接口类型。
(c)属性。
与类或对象相似,构件也具有属性,属性可以在构件使用前进行配置,它能够反映构件在交互过程中状态的变化。
2.2连接件模型
连接件是用来建立构件间交互以及支配这些交互规则的体系结构构造模块。连接件为构件间信息交互提供传输和路由服务。在最简单的情况下,构件之间可以直接完成交互,这时体系结构中的连接件就退化为直接连接。在更为复杂的情况下,构件间交互的处理和维持都需要连接件来实现。对于构件而言,连接件是构件的粘合剂,是构件交互的实现,也可以看做是一种特殊的构件[8]。与构件相似,连接件也具有端口。连接件的端口可分为两种类型,即源端口(source port)和目标端口(target port)。源端口用于接收构件请求端口中的消息,目标端口用于向构件服务端口中输入消息。连接件通常需要使用一种合适的绑定(binding)机制,构件的请求端口使用这种绑定机制来描述服务请求的方法,构件的服务端口也使用这种机制来描述构件进行请求的方式。常用的绑定机制有:WebService Binding和JMS Binding等,也可以自定义绑定机制。与构件一样,连接件也具有属性,来表示构件间交互的状态变化,如图2所示。
2.3复合构件模型
构件可分为两种,即原子构件和复合构件。前者是不可再分的构件。后者是可再分构件,它封装了若干个子构件。子构件间通过连接件相互连接,且子构件的端口也可以暴露成为复合构件的端口,子构件也可能是复合构件。如图3所示:复合构件A包含两个子构件B和D,子构件B和D通过连接件C进行相连,构件B的服务端口E暴露成为复合构件A的服务端口F,其请求端口G暴露成为A的请求端口H。
2.4方面构件模型
方面构件是面向方面软件体系结构的一个核心的构成单元,它封装了横切关注点,这是与传统软件体系结构最大的不同之处。图4给出了方面构件模型,与普通构件一样,方面构件也有服务端口和请求端口以及属性,但是它还有普通构件所没有的方面端口。当一个构件具有一个方面端口时,即可认为此构件就是方面构件。一个方面端口中包含若干个方面,这与一般面向方面编程(AOP)技术中方面概念有所不同。面向方面编程具有以下四个基本概念:方面(aspect)、连接点(joinpoint)、通知(advice)和切点(pointcut)。连接点是应用程序执行过程一个定义明确的位置,如方法调用是一种典型的连接点。切点是一系列连接点的集合,是方面的作用点。通知表述了在切点所选定的连接点处要执行的动作,常见通知类型有before、around和after等,分表代表在连接点之前、连接点附近和连接点之后执行相应的通知代码。方面是用来描述和实现横切关注点的基本单位,由切点和通知构成。方面端口中的方面横切关注的是构件,这与一般AOP(如AspectJ)横切关注的对象(object)不同,由于构件能够表达对象所不能表达的请求服务的能力[9],这使得方面端口中方面所采用的连接点模型和切点语言具有很大的不同。
2.4.1连接点模型
该连接点模型包含两种不同类型的连接点,即构件服务端口中的服务提供操作和请求端口的服务请求操作。由于构件的内部结构通常被视为黑盒,因此连接点模型应该仅考虑构件的外部可见元素,如构件请求端口和服务端口中的服务操作。如果连接点模型包含构件的属性,那么它将会破坏构件的分装性。
2.4.2切点语言
用来选用连接点的切点语言基于切点表达式,表1给出了切点的五个组成部分,即component、jp_type、port、interface和service,然后分别对其进行了说明。其中,jp_type代表选用的连接点类型,可以是请求端口中的服务、服务端口中的服务或所有端口中的服务,详细如表1。表2给出了切点语言的一些例子,其中正则表达式基于java.util.regexp包。
2.5面向方面软件体系结构模型
面向方面软件体系结构由构件、连接件、方面构件组成,详细请参见图6。
3基于面向方面软件体系结构模型的网上支付实例
近年来,网上购物发展迅速,网上支付是消费者主要的支付手段之一,图7给出了基于面向方面软件体系结构的网上支付模型,它由四个原子构件,即一个复合构件、两个方面构件和三个连接件组成。其中WebClientComponent代表客户端构件,它可以向网上银行构件WebBankComponent请求AccountService()服务,该服务有三个参数,即username、password、cost,分别对应于用户的网上银行账户名、密码及购买商品的消费金额。
〈component name="WebClientComponent"〉〈required.port name="WebClientRequest"〉
〈java.interface interface="AccountServiceInterface"〉〈service name="AccountService()"〉
〈param name="username"type="string"/〉
〈param name="password"type="string"/〉
〈param name="cost"type="float"/〉
〈/service〉〈/java.interface〉
〈/required.port〉
〈/component〉
连接件AccountServiceConnector用于连接客户端构件和网上银行构件,它采用WebServiceBinding绑定机制。
〈connector name="AccountServiceConnector"binding="WebServi-ceBinding"/〉
〈source name="S"/〉〈target name="T"〉
〈/connector〉
〈connect.source from="WebClientComponent.WebClientRequest"to="S"/〉
〈connect.target from="T"to="WebBankComponent.Bank-Re-sponse"/〉
网上银行构件是一个复合构件,由账户服务构件Account-ServiceComponent、账户数据库连接件AccountDBConnector和账户数据库构件AccountDBComponent组装而成。其中该复合构件的服务端口也使用接口AccountServiceInterface,这是为了兼容客户端构件请求端口使用的接口。
身份验证构件AuthenticationComponent用于验证用户的身份信息,它通过UserInfoConnector连接件访问用户信息数据库构件UserInfoDBComponent。
pointcut="WebBankComponent;BankResponse;AccountServiceInterface;AccountService()"
是该方面构件的方面端口中使用切点的表达式。
为了保证数据库构件UserInfoDBComponent和AccountDB-Component的安全性,方面构件SecurityComponent使用方面端口Security监视这两个构件的服务端口,使得在这两个构件服务调用之前增加日志和事务功能,而日志和事务功能在系统中通常表现为横切关注点,面向方面软件体系结构能够对它进行很好的封装,便于设计和维护。
〈aspect.component name="SecurityComponent"〉〈aspect.port name="Security"〉〈aspect〉〈pointcut="UserInfoDBComponent;UserInfoResponse;*;*|Ac-countDBComponent;AccountDBResponse;*;*"/〉〈advice.role="before"action="Log()"/〉〈advice.role="before"action="Transaction()"/〉〈/aspect〉〈/aspect.port〉〈required.port name="UserInfoRequest"/〉〈/aspect.component〉
4结束语
本文给出了一种面向方面软件体系结构模型,详细设计了它的三个基本构成单元模型,即构件、连接件和方面构件;最后通过一个网上支付实例验证了该模型有效性和实用性,为面向方面软件体系结构的实际应用奠定了一定的基础。笔者将继续完善该模型的相关理论,研究面向方面软件体系结构的工程化应用方法。
参考文献:
[1]FABRESSE L,DONY C,HUCHARD M.Foundations of a simpleand unified component-oriented language[J].Journal of ComputerLanguages,Systems&Structures,2008,34(2-3):130-149.
[2]LIEBERHERR K,LORENZ D,MEZINI M.Programming with as-pectual components,T R NU-CSS-99-01[R].[S.l.]:NoutheastamUniversity,1999.
[3]PAWLAK R,SERNTURIER L,DUCHIEN L D,et al.JAC:an as-pect-based distributed dynamic framework[J].Software Practiceand Experiences,2004,34(12):1119-1148.
[4]李千目.软件体系结构设计[M].北京:清华大学出版社,2008.
[5]马亮,孙春艳.软件构件概念的变迁[J].计算机科学,2002,29(4):28-30.
[6]SZYPERSKI C,GRUNTZ D,MURER S.Component software:be-yond object-oriented programming[M].2nd ed.[S.l.]:Addison-Wesley,2002.
[7]LAU K K,WANG Z.Software component models[J].IEEE TransSoft Eng,2007,33(10):709-724.
[8]SHAW M.Procedure calls are the assembly language of software in-terconnection:connectors deserve first-class status[C]//Proc of InICSE Workshop on Studies of Software Design.1993:17-32.
[9]NAVASA A,PREZ M A,MURILLO J M,et al.Aspect orientedsoftware architecture:a structural perspective[C]//Proc of Workshopon Early Aspects.2002.
寻论文《阿里巴巴网站成功案例分析》
1,阿里巴巴本身就是个例子: 阿里巴巴是全球B2B电子商务的著名品牌,是目前全球最大的商务交流社区和网上交易市场。他曾两次被哈佛大学商学院选为MBA案例,在美国学术界掀起研究热潮,两次被美国权威财经杂志《福布斯》选为全球最佳B2B站点之一,多次被相关机构评全球最受欢迎的B2B网站、中国商务类优秀网站、中国百家优秀网站、中国最佳贸易网,被国内外媒体、硅谷和国外风险投资家誉为与Yahoo, Amazon, eBay,AOL比肩的五大互联网商务流派代表之一。其创始人、首席执行官马云也被著名的"世界经济论坛"选为"未来领袖"、被美国亚洲商业协会选为"商业领袖",并曾多次应邀为全球著名高等学府麻省理工学院、沃顿商学院、哈佛大学讲学,是50年来第一位成为《福布斯》封面人物的中国企业家。
也许是取决于“良好的定位,稳固的结构,优秀的服务”,阿里巴巴如今巳成为全球首家拥有210万商人的电子商务网站,成为全球商人网络推广的首选网站,被商人们评为"最受欢迎的B2B网站",杰出的成绩使阿里巴巴受到各界人士的关注。WTO首任总干事萨瑟兰出任阿里巴巴顾问,美国商务部、日本经济产业省、欧洲中小企业联合会等政府和民间机构均向本地企业推荐阿里巴巴。
"倾听客户的声音,满足客户的需求"也许是阿里巴巴生存与发展的根基,根据相关的调查显示:阿里巴巴的网上会员近五成是通过口碑相传得知阿里巴巴并使用阿里巴巴;各行业会员通过阿里巴巴商务平台双方达成合作者占总会员比率近五成。
在产品与服务方面,阿里巴巴公司为中国优秀的出口型生产企业提供在全球市场的"中国供应商"专业推广服务。中国供应商是依托世界级的网上贸易社区,顺应国际采购商网上商务运作的趋势,推荐中国优秀的出口商品供应商,获取更多更有价值的国际订单。截至2003年5月底加盟企业达到近3000家。目前已经有70%的被推荐企业已在网上成交,众多类别市场名额已满。2002年3月开始为全球注册会员提供进入诚信商务社区的通行证-"诚信通"服务。阿里巴巴积极倡导诚信电子商务,与邓白氏、ACP、华夏、新华信等国际国内著名的企业资信调查机构合作推出电子商务信用服务,帮助企业建立网上诚信档案,通过认证、评价、记录、检索、反馈等信用体系,提高网上交易的效率和成功的机会。每月赢收以双位数增长。 阿里巴巴以50万元人民币创业资本起步,吸纳了国际资本2500万美元,经过3年的发展,于2001年底实现当月盈利,2002年实现每月收入双位数的增长,实现全年盈利,从而保证对客户的持久服务能力。
下面是对阿里巴巴公司商业的模式进行分析。
阿里巴巴的营运模式是遵循一个循序渐进的过程。首先抓住基础的,然后在实施过程中不断捕捉新出现的收入机会。从最基础的替企业架设站点,到随之而来的网站推广,以及对在线贸易资信的辅助服务,交易本身的订单管理,不断延伸。出色赢利模式符合:赢利的强有力,可持续,可拓展。
1、架设企业站点
很少有企业把它理解为是一项重要的业务,理由在于这是一个高度离散的行业。你可以很从容的获得一个或者几个制作企业站点的机会,但不等于能够获得很多。这里存在收入收集上的困难。有一些公司主营这项业务,它们往往将业务定格在高端客户。阿里巴巴是一个很大的商业社区站点,这就是说它有与许多潜在顾客频繁接触的机会。更重要的是它能顺利的把潜在机会转化为现实收入。阿里巴巴的目标受众每年都要参加许多类似广交会之类的展销会议,这时候阿里巴巴的工作人员就出现了,有一些低成本的推广活动。线上与线下的营业推广相结合,实践证明能有效的收集商业机会。中小企业存在很大的伸缩性,这是说业务流程和业务规模都在迅速的发生变化。有时候它或许会找邻居帮助设计一个主页,这在当时可能已经足够了,但是很快它就有了更高的需求,这就超过了邻居的能力。阿里巴巴则有能力提供从低端到高端所有的站点解决方案。它能在企业的成长过程中获得全部收益。更大的优势在于制作商品交易市场型的站点。阿里巴巴只是替商品交易市场做一个外观主页,然后将其链接在自己的分类目录下。交易市场有了一个站点,实际上这和阿里巴巴的站点是同一个站点,这就提高了被检索的机会。网页设计毕竟是一项倾向于劳动密集型的业务。网站设计其实和开发应用程序没有什么不同,这是说存在国际转包的内在需求,这和印度班加罗尔的故事相同。这也解释阿里巴巴为什么把它的人手更多集中在劳动力成本相对低廉的杭州。国际转包的实现除了需要品牌,还要有对应的机构设置。无疑,阿里巴巴一直就是往这一方向走。
2、站点推广
对于网站的媒体定为一直十分模糊,它应当是广播式的,还是特定用户检索式的?其他从事于企业站点设计的公司存在一个很大的问题,没有对应的推广能力。而网站设计一旦完成,推广是自然需求。网站实际上是另一种媒体,广告收入对大多数网站都很重要。无论一些针对企业的服务是否被称之为广告。广播式的模式容易让人理解,但是逻辑上我们更倾向于检索式的。原因很简单,网站首页的空间是有限的,换句话说注意力本身是一种稀缺资源。一些站点的合适位置已经充满了形式各异的广告,我们忍不住困惑,增长的潜力在那里?如果我们定义为检索式的,这同时就表明了有几乎无限可供销售的广告位置。这好像就是最初网站在股市受到追捧的原因。跟大多数人的认识相反,中小企业存在很强烈的营销愿望。这一愿望没有更多转化为现实的理由是:首先通常营销的费用超过了中小企业可承受的范围。其次以前并不存在相应很好的方式。在阿里巴巴今天的收入中,站点推广的收入占了一半还多。“中国供应商”和“网上有名”。 “中国供应商”面对的是出口型的企业,“网上有名”则针对内销或工厂的出口主要以买断形式进行的那一种。其中的价格依据是,如果某家企业愿意以3万人民币的价格租赁两周的广交会展销摊位,那么它为似乎也会愿意以同样的价格购置一年的在线展销时段。今年这一价格已经上升到4万。对于一个新生事物,某种意义上阿里巴巴要证明服务的有效性。阿里巴巴有一个系统服务的思维。除了在网站上的页面设置,还可以通过“商情快递”邮件杂志,检索上的优先派序。至少它能证明付费的顾客要比免费的客户有更多的机会。有人愿意以6万人民币的价格,以便获得更多的服务内容。
3、诚信通
网络可能是虚拟的,但贸易本身必须是真实的。信用分析是企业的日常工作。这很好解释,网友们在拍卖网站上的交易并不是每一次都那么如意。易趣的统计表明在同通过身份认证但只有少数交易经历的所谓一星级顾客交易中,有6%最终受到了投诉。都一样,企业间交易存在相似的压力,所不同的是企业对此有更高的敏感性。在线贸易一方面体现了采购行为更充份的竞争性,另一方面企业对网络信息本身充满了质疑。“诚信通”作为一项服务不难理解。可以在“诚信通”上出示第三方对其的评估,企业在阿里巴巴的交易记录也有据可循。问题是这项服务本身是否会非常成功。阿里巴巴显然是希望所有的注册会员都使用这项付费的服务,最起码新注册的用户是如此。这个问题的确非常有趣。如果这一预想符合了现实,大多数的企业都购买了“诚信通”,那么意味剩下少数也会购买,即便不购买也不再重要。每个“诚信通”的价格都很便宜,但对网站而言几乎不存在成本。这就是说阿里巴巴的运营业绩将会非常的成功。另一种可能是只有少数企业购买了,这就存在用户流失的问题。类似于阿里巴巴模式的网站今天多如牛毛。阿里巴巴的认识是,首先他们在前期的努力已经吸纳了国际贸易中最活跃的顾客群。另一方面在线交易本身必须实现其严肃性。“如果某一商人在支付最基本的费用上都存在问题,那么他根本就没有资格从事生意本身。”我想这一逻辑应该被认为是正确的。
4、贸易通
贸易通是阿里巴巴网站新推出的一项服务,它的功能主要有以下几项:和百万商人安全、可靠地进行即时在线沟通、互动;结识、管理自己的商业伙伴,开展一对一的在线营销;强大的商务搜索引擎,搜尽天下商机;"服务热线"为诚信通会员即时解答网络贸易疑问,方便享受高质量的在线客户服务。其界面有点类似于常用的聊天工具QQ,非常友好且使用简单。不过,有关“贸易通”的收费一直没有行动起来,但这却是最初也是最重要的愿望。阿里巴巴的定义是从企业的每一次日常交易中抽取佣金,这在前期被舆论认为是不可能的,原因在于B2B贸易存在重复交易,企业通常不会一次就更换一家供应商。这样企业很容易绕开任何中介。这又是一个没有思维,就迅速下判断的例子。当然并不是这样的。“贸易通”可以理解为是一种订单管理软件。我想很多IT评论人都忽略了阿里巴巴这一项服务,实际上它对阿里巴巴未来的潜在影响最大,绝对不能看成电子邮件的豪华版。这里有一个观念上的不同,产品重要的是需求,而不是技术表述。“贸易通”则解决了这所有的问题。而且操作中存在很强的可行性,可以通过短消息捆绑按次计费。这一服务所面临的价格敏感性很小,而且存在一个很大的数量。“贸易通”则延伸了企业软件托管的思路。2, 阿里巴巴电子商务网站Linux应用案例 解决之道 阿里巴巴在2003年年初开始启动是数据库升迁项目。3月底引进基于Linux平台的Oracle9i集群数据库(Oracle9iRAC),4月初开始安装,到4月底便成功上线。新的数据库集群是以Dell 6650为硬件服务器、存储服务器采用Dell/EMC CX200存储阵列、以Red Hat Linux Advanced Server 2.1为操作系统、数据库采用Oracle9i集群数据库,采用三层架构,部署两个节点的集群系统。 在从原有系统向新系统迁移数据时,按数据的不同特征进行,不仅能够快速迁移数据,并且大大减少了由于系统迁移而可能造成的停机时间。阿里巴巴数据库项目主管鲁国良先生说:“我们原有系统采用的数据库也是Oracle数据库,只不过它是基于Linux的单机数据库,因此,在数据迁移过程中,几乎没有遇到大问题。由于Oracle9iRAC在节点间信息交换的性能有了很大的改进,使得我们在从原来的单机系统升级到集群系统时,几乎不需要更改应用,新系统得到快速部署,一个月之内就能够上线。” 应用效益 鲁先生说:“通过采用2个节点的集群系统,我们能够很好地避免在升级Linux系统时可能出现的停机现象。Linux仍在迅速发展之中,其内核技术更新快,为了及时获得Linux更先进的功能,我们需要及时升级Linux内核技术。由于Exodus中的数据库集群采用的是2个节点的集群系统,我们可以先对集群中的一个节点升级其Linux内核,然后再升级另一个节点,在此过程中,系统完全能够正常运行。借助基于Linux的Oracle9i集群数据库(Oracle9iRAC)的强大功能,系统的管理工作变得简单得多,并且能够有效弥补Linux操作系统的一些不足,在降低应用成本的同时,获得强大的性能。” 在性能与成本之间获得很好的平衡,全面满足网站的应用需求。采用基于Linux的Oracle9i集群数据库(Oracle9iRAC)作为Exodus的数据库平台,阿里巴巴既能够充分利用Linux平台的低成本优势,同时能够获得Oracle9i数据库强大的性能优势,获得对网站发展至关重要的系统性能、安全性、可靠性和可扩展性。 性能提高60%。以基于Linux的Oracle9i集群数据库为动力的“Exodus”投入使用后,成功地把阿里巴巴网站性能提高了60%。系统在投入使用后不久,中国部分地区遭受“非典”袭击,为了尽可能避免相互接触,企业纷纷转向网上交易,作为中国最主要的商业网站之一,阿里巴巴成为广大企业进行交易的平台,日交易从“非典”前的4千~5千笔迅速攀升到6月初的9千~1万2千笔。“Exodus”的及时投入使用,为阿里巴巴从容应对快速增长的交易量提供了强大的动力,帮助阿里巴巴及时把握住新的发展机遇。 系统管理简单化。借助Oracle9iRAC先进的Data Guard技术,阿里巴巴能够简化数据库的管理工作。Oracle9i Data Guard能够维护关键数据的实时拷贝,从而能够防止由于各种原因引起的数据丢失。工作区之间强大的转接和转回能力,使得硬件和操作系统的维护更为容易,同时又降低了宕机时间。比如,在过去,当主数据库和备用数据库的网络出现异常时,往往需要采用手工方式复制Archive Log,并应用到备用系统,工作量相当大,现在,这些工作都能够自动完成。 大大减少宕机时间。借助基于Linux的Oracle9i集群数据库(Oracle9iRAC)的高可用性,阿里巴巴无论是升级Linux内核还是升级应用,都不需要关闭系统,有效减少了计划内停机时间。同时,集群系统中两个节点互为备份,大幅度减少了意外停机的时间。 减少测试环境和实际应用环境的差异,提高系统部署的效率。现在,Linux已成为成长型企业的首选应用开发和测试平台,比如在Linux系统上运行开发数据库,而在其它系统上运行产品数据库,结果是在开发、测试、产品应用平台之间存在着差异。这种差异往往会影响到系统部署时的投入。阿里巴巴通过采用基于Linux的Oracle9i集群数据库(Oracle9iRAC)作为产品数据库,有效地缩小了这些差异,使很多测试工作变得真正有意义,直接用于产品应用平台,从而提高系统的部署效率。 为什么选择ORACLE 在谈及选择基于Linux的Oracle9i集群数据库的原因时,鲁先生说:“Oracle9i集群数据库在性能、安全性、24x7高可用性、稳定性方面都很好地满足了我们的应用需求,特别是它强大的易扩展性,尤其适合阿里巴巴快速发展的特点。另一方面,Oracle公司对Linux的积极态度和支持力度以及在Linux平台上不断实现的性能突破,坚定了我们采用Linux的信心,使我们既能够满足电子商务网站对性能和安全性的高要求,同时也能够很好地解决了成本控制的问题,这对我们成长型企业来说至关重要。基于Linux的Oracle9i集群数据库使我们能够以较低的成本在Linux平台上获得企业级的性能、可靠性和可扩展性,在Linux平台上运行网站的关键应用系统。其强大的集群能力,使我们能够在以后交易量上升到一定程度需要增加系统容量时,只需简单地增加节点,完全不需要更改应用,我们获得了一个真正按需部署的系统。” 未来计划 我们将继续关注Oracle在Linux方面的合作以及技术的发展。随着阿里巴巴业务的不断发展,我们将充分利用“Exodus”系统成功应用基于Linux的Oracle9i集群数据库的经验,改善其它应用系统,逐步把这些系统迁移到Oracle平台上。
管理信息系统案例分析 只要一个案例 多分析一些 字数在4000-6000 左右 能和市场营销方面有关尽量靠拢
我也是学这个的,下面这个以前自己用过,希望对你有帮助。
从宝供储运的成长看信息系统战略规划的作用
宝供储运是广州的一家物流公司,其前身是广州的一个铁路货物转运站。刘武于1992年在承包这个铁路货物转运站时,该转运站的规模还很小。但由于刘武经营灵活,承包的货运任务大多能及时完成,运输的质量比较好,仓库也比较干净,而且还是当时广州惟一一家能够提供24小时货运仓储的服务企业。而当时的国有物流企业,仓储和运输是分开的,服务质量差,仓库又脏又乱,这种截然鲜明的对比,使刘武的货物转运站越来越受到客户的好评。以致于1994年进入中国市场的宝洁公司也将业务交给这家小小的铁路货物转运站去做。
自从宝洁公司成为刘武的客户以后,这家铁路货物转运站的业务环境就发生了巨大的变化,并直接促成1994年广州宝供储运有限公司(简称"宝供",下同)的成立。归纳起来,业务环境的变化表现在三个方面:
(1)业务总量的增加
宝洁交给宝供的第一笔业务是将4个集装箱发运到上海。为了做好这笔业务,刘武运作得非常仔细。刘武将集装箱送上火车以后,又马上乘飞机去了上海,一方面"督战",一方面还可以考察各个环节,拿到第一手资料,这样才能保证以后的发运可以少出现一些问题,满足客户的要求。结果,宝洁对第一批业务感到非常满意,并从此开始陆陆续续地给宝供加大业务量,甚至一度把自己所有的铁路货运业务全部交给了宝供储运。
然而,尽管第一笔业务效果很好,但由于成本很高,宝供并没有赚到什么钱。毫无疑问,如果每一笔业务都这样做,客户自然欢迎,但从经济效益的角度看却是不允许的。实际上,从1994年到1995年,宝供在全国已经有将近30万平方米的仓库,每天的发运量非常大,运营部的人每天都要花很大的力气了解这些货是不是按照客户的要求在规定时间之内发运出去,到达目的地的时间、破损率是不是在控制范围之内、有没有及时把货送到仓库去、签收情况又是怎么样等等。运营部的人拿一个硕大的笔记本,有单子就登记一下,对没有收到货的要及时打电话去询问;对于有破损的,要发个传真调查一下。其烦琐的程度,仅仅靠人工是很难完成的。因此,面对发展迅速的业务量,如何提高运行效率,是摆在宝供面前亟待解决的一个问题。
(2)设立了分公司
分公司也是1994年由于业务发展迅速才成立的,并直接与宝洁有关。因为尽管铁路运输很便宜,但当时的铁路运输也有不少缺点,如环节多,时间不可靠,再加上一些装卸、运输过程中的野蛮作业,所以破损率比较高。而宝洁则一再表示:传统的储运公司让客户觉得很麻烦,货到了以后,还要委托另外一个供应商来提货,或者派自己的人去提货,而且一旦出现短少、破损、或者提货不及时等问题时,往往就会造成互相扯皮的现象。面对这种情形,宝供立即在成都、北京、上海、广州设立了4个分公司,这4个分公司都按同样的操作方法、同样的模式与标准来运作。由宝供承运的货物到达目的地后,仍然由受过专门统一培训的宝供的人来接货、卸货、运货,为宝洁公司提供"一条龙"服务,而且从理论上看,总公司与分公司之间的信息沟通和协调应该比较方便。
然而,分公司建立以后,也面临一个问题--通讯问题,即总公司与4个分公司之间联系很频繁。用什么通讯方式才能保证业务的正常开展而且成本也很低?
宝供当时的做法是:1996年建立了一套基于DOS平台的用电话线连接的内部网络,以便在全国范围内的分公司之间传递一些信息。但在实际运作过程中,这种通讯方式效率低成本高。例如,总公司在与成都分公司通过计算机联系的时候,往往由于电话线路紧张而失败;另外操作复杂,稳定性差,长途电话成本高以及与宝洁没有"接口"等等。因此,这又给宝供的未来发展提出了一个十分严峻的问题。
(3)兼顾客户的业务流程
自从宝洁成为宝供的客户以后,该公司就不断对宝供提出了很多新的要求,如前面提到的要求宝供提供安全、准确、及时、可靠的储运服务等。宝洁不仅要求宝供在业务上满足他们的要求,而且还对所有在物流各个环节产生的信息非常关注。比如货物什么时候发运,用的是哪趟火车,预计何时到货,货物情况如何,有无破损,是否已经签收等。
鉴于宝洁上述方面的要求,宝供努力地按照宝洁的要求来设计业务流程和发展方向。但宝供原有的业务流程是建立在业务量较低的水平基础之上,业务量骤增以后,立即面临着很多问题。对于宝洁所要求了解的发运时间、车次、到货时间、破损情况、签收与否等情况,如果只有一笔业务,刘武自己可以跟踪解决,如坐飞机到上海、成都、北京等地;但如果有好几百笔业务都在同时做,那么每一笔业务都这样跟踪,显然是不可行的。事实上,宝洁与宝供刚刚合作的一年左右时间内,宝洁一直都较满意,但随着业务量的加大,宝供的反应速度都在明显下降,如发现到货时间不准,破损率上升,还有货运信息不能及时反馈等,甚至进一步影响到企业本身的发展,因此宝洁中止了与宝供的铁路运输总代理的合同。所有上述这些情况,又向宝供的业务流程和信息传递提出了挑战。
宝供将如何解决上述问题?如果从信息系统的角度来分析上述问题,我们会发现宝供当时面临的最本质的问题是信息的管理,即如何解决信息瓶颈问题。因为在原来业务量小的情况下,事务处理过程可以由手工来完成,而现在业务量大,事务处理过程变得繁重而复杂,如果仍通过手工的方式(用笔记本记录、打电话、发传真查询催问),即使花很大的气力也难以准确收集诸如发运时间、车次、预计到达时间、实际到达时间、破损率、入库时间、签收情况等有关信息。虽然宝供在成都、北京、上海、广州四处设立了分公司,可以保证按同样的模式和标准来运作业务流程,但对于信息管理而言,这样做实际上增加了中间层次,并随即面临了总公司与各分公司之间的通讯问题。不仅如此,现代客户(如宝洁)与传统客户相比,要求更高,不仅要求提供安全、准确、及时、可靠的储运服务,而且还要求提供及时准确的货运信息。这样看来,宝供当时的"信息瓶颈"既表现为当时的信息管理水平和信息系统(IS)现状已不能实时监控各个储运环节,还表现为不能满足客户的需要。
正当宝供处于无法实时监控各个储运环节和"竞争激烈"这种内外交困的境地时,正当宝供为如何解决"信息瓶颈"问题一筹莫展时,Internet网的应用已被我国的有志之士所认同,而企业信息系统及Internet应用专家唐友三此时对于帮助解决这一"信息瓶颈"问题起了一个非常关键的推动作用。如果我们从内部业务现状、外部业务环境、内部IS现状、外部信息系统环境四个方面来分析宝供,不难发现下面这样一个业务与信息系统矩阵:
应该说,宝供当时的信息系统战略规划也并非完全一帆风顺。作为企业的第一把手,刘武已经意识到宝供的信息瓶颈可以通过Internet网来解决,即通过网站发布货运信息,全国各地的分公司和客户都可以共享这些信息。甚至可以说没有网络,宝供很难再往下发展了。然而,宝供当时的实际情况是,已有一些PC机了,并组建了一个基于DOS平台的网络,而且当时资金有限。唐友三与刘武多次商量以后,一致认为,为了企业的长远发展,信息系统规划必须与企业目标相统一,必须跟上国际潮流,要建立一个高起点高水平的企业信息系统,一个基于Internet网的信息系统。考虑到宝供的信息系统现状和业务现状,在硬件上能省就省,486先用着,386换成586兼容机,买一台新服务器,再将原来的486服务器升级一下,其它布线的活也由企业内部的职员来做,这样硬件总共投入了大约10万元,软件部分也投入10万元,交由北京的英泰奈特公司来做。经过英泰奈特信息系统专家的查询访谈,整理出宝供的基本业务流程。
"客户发过来一个单子,也就是一套托运表,要填好货物品种、目的地、数量/重量等等,然后宝供的分公司根据这张表按照客户要求联系火车或者汽车准备第二天发运。有车皮了,如果这个单子的货少,马上还要准备调配其它客户的货一起发运。第二天要有车拉到火车站去装,根据要求还要加一些包装(如将怕漏水的加塑料布,怕磕碰的加用木架等)。装完以后车皮的门要锁住,封条要封好,封条的号码还要记下来通知接货的分公司。到达目的地后,分公司要到火车站去接收,把货拉到宝供当地的仓库里面去检验有没有损失,然后分类储存好,等待客户签收。客户签收后再把单子马上快递回货物始发的分公司,分公司上报总公司,总公司就凭这个找客户拿钱。"
当然,在实际操作中每笔货物都是不一样的,在这个标准流程中的任何一个环节有变化,都会衍生出一种新的流程。比如食品在仓储过程中有一个批号问题,考虑到保质期要"先进先出",再比如有些货物在运输过程中必须分开,不能同批搭配运输等等。
基于上述业务流程的分析,宝供建立了以Internet网络构架的IS,把货物的运输系统分解为接单、发运、到站、签发等环节进行操作,整个系统由接单模块、发运模块、运输过程控制模块、运输系统管理模块、仓位管理模块、查询模块等构成。系统采用集中数据存储,各个分公司对于数据的保有权是有时效限制的。所有最终数据的维护均由公司的信息中心负责进行。
如果要详细而具体地评述宝供信息系统战略规划的作用与影响,那将是十分困难的,不过我们通过对成本与收益的简要分析就可以得出较有说服力的结论。
在成本方面,虽然宝供信息系统早期的规划与开发上占了不少便宜,如硬件很节约,软件报价低等等,但后来的投入渐渐加大了,超过了200多万元,总部人手一台计算机,经理们有笔记本电脑。从企业财务的角度来看,这正是良性循环的必然结果。因为宝供储运的信息系统应用从基本的Internet构架到报表生成系统的开发,已经历了两个阶段。无论从事务处理的计算机化还从服务于管理决策的角度看,成本的投入都是值得的。这一点已从总经理对唐友三的信任上得到了证明。
在收益方面,信息系统战略规划给企业带来的好处很多。收益包括有形的收益和无形的收益两方面。有形的收益表现为成本的节约。例如,将信息系统建立在Internet/Intranet平台上,比原先的电话、传真方式所需的费用要低。虽然首期一次性投入(服务器、PC机、布线等)可能也不少,但运行时具有的规模效应具有较大的优势。另外,宝供从当初4个分公司发展到了31个城市都有分公司,客户也由原来专门为宝洁服务发展到后来的45个客户。从传统的角度看,业务量的增长,应有较多的人员去应付诸多管理上的事务。而实际上,借助先进的信息系统,宝供总公司业务部仅用12人就可以进行全盘监控了。这在以前简直是无法想象的。用刘武自己的话说:"没有这个信息系统,宝供根本就做不大。现在我们在全国有那么多运营点,要对他们进行管理,我看不到又摸不着,只能依靠这套系统来监控。对提出的要求和标准,有没有达到?如果没有达到,具体是什么原因。我在电脑上一看,就知道这里已经出了什么事,可以赶紧采取补救措施。"
有形的收益不仅表现在成本的节约上,有时甚至能直接体现在业务指标的实现上。例如,以前从广州运到北京要15天,现在只需10天时间就可以了。在可靠性方面,原来能达到90%就不错了,可现在铁路运输已经提高到了95%,公路甚至可以达到99%以上。
信息系统战略规划的作用与影响在很多情况下还表现为一种看不见摸不着的东西。宝供新的信息系统刚开始运行的时候,曾遇到过不少阻力,主要是一些老资格的管理人员,他们不懂计算机,不懂Internet网,更不懂计算机联网后会提高管理效率,因而产生了抵触情绪。通过总经理对规划意图的讲解和参与计算机知识的培训,提高了企业的所有员工的素质,而这实际上无形之中提高了企业的综合素质。
上述两方面的收益可以总结为以下5点:
(1)有效地组织跨地区的业务;
(2)充分利用资源(包括货品的和信息的两方面);
(3)提高客户服务水平;
(4)加快资金周转,采用先进的比原来的结算系统平均提早两天时间;
(5)节约通信费用。
而在上述5个方面中,最为根本的应当是搞好客户服务。从这个角度看,对于物流企业而言,信息系统比车队和仓库更为重要。国外许多著名的物流公司其本身并没有车队和仓库,但它每年的承运量都可以达到惊人的数字。而许多有着强大的承远能力的国内运输公司或拥有大片空余仓位的储运公司,由于没有一套能够让客户满意的信息系统而失去与客户合作的机会,只能沦为那些有信息系统但没有储运能力的物流公司的廉价的运输和仓储工具。因此,建立和开发以客户服务为宗旨的信息系统可以为企业提供长期的具有战略意义的竞争优势。
有没有其他的 这个网上一搜能搜到很多啊 我怕撞上....
我也是从网上找的,应该可以,要是你怕撞上的话,最好改一下里面的内容。例如公司名称,一些人物名字,还有一些语句变幻,如(1)业务总量的增加 可以这样说,公司业务比以往有显著增加。相信你是聪明的,呵呵。
如果你要是真想换个案例,也行。
转载请注明出处51数据库 » 软件开发案例分析论文 软件工程论文