本篇文章给大家谈谈简述基于构件的软件开发过程，以及简述基于构件技术的特点对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。
本文目录一览：
- 1、基于构件的软件开发过程由什么和什么两个并行的活动组成
- 2、基于构件的软件开发方法
- 3、软件开发的一般流程是什么?
- 4、构件化的软件开发方法是什么
- 5、简述基于构件的软件开发的核心是什么急急急！！！
基于构件的软件开发过程由什么和什么两个并行的活动组成
软件体系结构是具有一定形式的结构化元素，即构件的集合，包括处理构件、数据构件和连接构件。处理构件负责对数据进行加工，数据构件是被加工的信息，连接构件把体系结构的不同部分组组合连接起来。这一定义注重区分处理构件、数据构件和连接构件，这一方法在其他的定义和方法中基本上得到保持。（1）结构模型这是一个最直观、最普遍的建模方法。这种方法以体系结构的构件、连接件和其他概念来刻画结构，并力图通过结构来反映系统的重要语义内容，包括系统的配置、约束、隐含的假设条件、风格、性质。研究结构模型的核心是体系结构描述语言。管道/过滤器风格的体系结构（2）框架模型框架模型与结构模型类似，但它不太侧重描述结构的细节而更侧重于整体的结构。框架模型主要以一些特殊的问题为目标建立只针对和适应该问题的结构。（3）动态模型动态模型是对结构或框架模型的补充，研究系统的”大颗粒”的行为性质。例如，描述系统的重新配置或演化。动态可能指系统总体结构的配置、建立或拆除通信通道或计算的过程。这类系统常是激励型的。（4）过程模型过程模型研究构造系统的步骤和过程。因而结构是遵循某些过程脚本的结果。（5）功能模型该模型认为体系结构是由一组功能构件按层次组成，下层向上层提供服务。它可以看作是一种特殊的框架模型。这5种模型各有所长，也许将5种模型有机地统一在一起，形成一个完整的模型来刻画软件体系结构更合适。例如，Kruchten在1995年提出了一个”4+1″的视角模型。”4+1″模型从5个不同的视角包括逻辑视角、过程视角、物理视角、开发视角和场景视角来描述软件体系结构。每一个视角只关心系统的一个侧面，5个视角结合在一起才能够反映系统的软件体系结构的全部内容。
基于构件的软件开发方法
基于构件的软件开发(cBSD，ComponentBasedsoftwareDevelopment)是以构件为组装蓝图，以可复用软件构件为组装模块，支持组装式复用，以提高软件生产效率和软件产品质量的有效途径。它包含了系统分析、构造、维护和扩展的各个方面，这些方面都是以构件方法为核心的。
软件构件技术以及基于构件的软件开发方法，与传统软件工程方法有所不同，它不仅仅针对某个具体的工程项目，而更多地是针对某一行业领域的共性需求，利用领域工程方法，将多年积累的行业经验进行总结，提炼出业务模型、特定领域的系统架构、构件库等，这样开发出来的架构和构件封装了业务的个性和变化性，具有此领域的共同特点，在此领域有很高的可复用性。有了这样的积累之后，整个应用软件的生产方式将发生很大的改变，将不再是从头做起。而是以“构件组装”的方式生产出软件应用系统。软件系统的质量、复用率和开发效率都得到大幅提高。
软件构件技术要想在实际工作得到有效利用，需要有一些平台软件来支撑，这就是我们所说的软件构件技术的支撑平台四要素，即构件运行支撑环境、构件开发／组装环境、构件管理环境和基于构件的开发方法和过程。
软件开发的一般流程是什么?
您好，非常荣幸能在此回答您的问题。以下是我对此问题的部分见解，若有错误，欢迎指出。展开全部
软件开发流程分为: 需求确认——概要设计——详细设计——编码——单元测试——集成测试——系统测试——维护
软件开发是一项包括需求捕捉、需求分析、设计、实现和测试的系统工程。软件一般是用某种程序设计语言来实现的。通常采用软件开发工具可以进行开发。软件分为系统软件和应用软件，并不只是包括可以在计算机上运行的程序，与这些程序相关的文件一般也被认为是软件的一部分。
软件设计思路和方法的一般过程，包括设计软件的功能和实现的算法和方法、软件的总体结构设计和模块设计、编程和调试、程序联调和测试以及编写、提交程序。
扩展资料
软件开发方面的工作。具体可分为以下方面：
1 可视化编程掌握程序设计方法及可视化技术，精通一种可视化平台及其软件开发技术。获取Delphi程序员系列、Java初级或VB开发能手认证。 就业方向：企业、政府、社区、各类学校等可视化编程程序员。非常感谢您的耐心观看，如有帮助请采纳，祝生活愉快！谢谢！
构件化的软件开发方法是什么
基于构件的软件开发（Component-Based Software Development, CBSD，有时也称为基于构件的软件工程CBSE）是一种基于分布对象技术、强调通过可复用构件设计与构造软件系统的软件复用途径。基于构件的软件系统中的构件可以是COTS（Commercial-Off-the-Shelf）构件，也可以是通过其它途径获得的构件（如自行开发）。CBSD体现了“购买而不是重新构造”的哲学，将软件开发的重点从程序编写转移到了基于已有构件的组装，以更快地构造系统，减轻用来支持和升级大型系统所需要的维护负担 ，从而降低软件开发的费用。
开发基于构件的软件系统受到以下几方面因素的影响：1）COTS构件质量的提高和种类的增加；2）要求降低系统开发和维护成本的经济压力；3）构件集成技术的出现；4）软件开发组织内可以用于新系统开发的已有软件制品的数量增加。
CBSD整个过程从需求开始，由开发团队使用传统的需求获取技术建立系统的需求规约。在完成体系结构设计后，并不立即开始详细设计，而是确定哪些部分可由构件组装而成。此时开发人员面临的设计决策包括“是否存在满足某种需求的COTS 构件”，“是否存在满足某种需求的内部开发的可复用构件”，“这些可用构件的接口与体系结构的设计是否匹配”等。对于那些无法通过已有构件满足的需求，就只能采用传统的或面向对象的软件工程方法开发新构件。对于那些满足需求的可用构件，开发人员通常需要进行如下活动：
构件鉴定（qualification）：通过接口以及其它约束判断COTS 构件是否可在新系统中复用。构件鉴定分为发现和评估两个阶段。发现阶段需要确定COTS 构件的各种属性，如构件接口的功能性（构件能够提供什么服务）及其附加属性（如，是否遵循某种标准）、构件的质量属性（如，可靠性）等。构件发现难度较大，因为构件的属性往往难以获取、无法量化。评估阶段根据COTS 构件属性以及新系统的需求判断构件是否可在系统中复用。评估方法常常涉及分析构件文档、与构件已有用户交流经验、甚至开发系统原型。构件鉴定有时还需要考虑非技术因素，如构件提供商的市场占有率、构件开发商的过程成熟度等级等。
构件适配（adaptation）：独立开发的可复用构件满足不同的应用需求，并对运行上下文做出了某些假设。系统的软件体系结构定义了系统中所有构件的设计规则、连接模式和交互模式。如果被复用的构件不符合目标系统的软件体系结构就可能导致该构件无法正常工作，甚至影响整个系统的运行，这种情形称为失配（mismatch）。调整构件使之满足体系结构要求的行为就是构件适配。构件适配可通过白盒、灰盒或黑盒的方式对构件进行修改或配置。白盒方式允许直接修改构件源代码；灰盒方式不允许直接修改构件源代码，但提供了可修改构件行为的扩展语言或编程接口；黑盒方式是指调整那些只有可执行代码且没有任何扩展机制的构件。如果构件无法适配，就不得不寻找其它适合的构件。
构件组装（composition）：构件必须通过某些良好定义的基础设施才能组装成目标系统。体系风格决定了构件之间连接或协调的机制，是构件组装成功与否的关键因素之一。典型的体系风格包括黑板、消息总线、对象请求代理等。
构件更新（update）：基于构件的系统演化往往表现为构件的替换或增加，其关键在于如何充分测试新构件以保证其正确工作且不对其它构件的运行产生副面影响，对于由COTS 构件组装而成的系统，其更新的工作往往由提供COTS 构件的第三方完成。
简述基于构件的软件开发的核心是什么急急急！！！
与传统的软件开发方式相比，基于构件的 软件开发方法 有什么突破呢？ 一、体系结构 软件体系结构 代表了系统公共的高层次的抽象，它是系统设计成败的关键。其设计的核心是能否使用重复的体系模式。传 统的应用 系统体系结构 从基于主机的集中式框架，到在网络的客户端上通过网络访问服务器的框架，都不能适应目前企业所处的商业环境，原因是： 企业过分地依赖于某个供应商的软件和硬件产品。这种单一供应商使得企业难以利用计算供应商的免费市场，将计算基础设施的重要决定交给第三方处理，这显然不利于企业在合作伙伴之间共享信息。 不能适应远程访问的分布式、多层次异构系统。 封装的应用系统在出现某种组织需要时，难以用定制来维护系统，从而难以满足多变的需求。 不能实现分析、设计核心功能重用，最多只能实现代码重用。 如今，应用系统已经发展成为在Intranet和Internet上的各种客户端可远程访问的分布式、多层次异构系统。CBSD为开发这样的应用系统提供了新的 系统体系结构 。它是标准定义的、分布式、模块化结构，使应用系统可分成几个独立部分开发，可用增量方式开发。 这样的体系结构实现了CBSD的以下几点目标: 能够通过内部开发的、第三方提供的或市场上购买的现有构件，来集成和定制应用软件系统。 鼓励在各种应用系统中重用核心功能,努力实现分析、设计的重用。 系统都应具有灵活方便的升级和系统模块的更新维护能力。 封装最好的实践案例，并使其在商业条件改变的情况下，还能够被采用，并能保留已有资源。 由此看出,CDSD从系统高层次的抽象上解决了复用性与异构互操作性，这正是分布式网络系统所希望解决的难题。 二、开发过程 传统的软件开发过程在重用元素、开发方法上都与CBSD有很大的不同。虽然面向对象技术促进了软件重用，但是，只实现了类和类继承的重用。在整个系统和类之间还存在很大的缺口。为填补这个缺口，人们曾想了许多方法，如 系统体系结构 、框架、设计模式等。 自从构件出现以来，软件的重用才得到了根本改变。CBSD实现了分析、设计、类等多层次上的重用。图1显示了它的重用元素分层实现。在分析抽象层上，重用元素有子系统、类；在设计层上重用元素有 系统体系结构 、子 系统体系结构 、设计模式、框架、容器、构件、类库、模板、抽象类等。 在 软件开发方法 上，CBSD引导软件开发从应用系统开发转变为应用系统集成。建立一个应用系统需要重用很多已有的构件模块，这些构件模块可能是在不同的时间、由不同的人员开发的，并有各种不同的用途。在这种情况下，应用系统的开发过程就变成对构件接口、构件上下文以及框架环境一致性的逐渐探索过程。例如，在J2EE平台上，用EJB框架开发应用系统，主要工作是将应用逻辑,按session Bean、entity Bean设计开发,并利用JTS事务处理的服务实现应用系统。其主要难点是事务划分、构件的部署与开发环境配置。概括地说，传统的软件开发过程是串行瀑布式、流水线的过程;而CBSD是并发进化式，不断升级完善的过程。图2显示了它们的不同。 三、软件方法学 软件方法学是从各种不同角度、不同思路去认识软件的本质。传统的软件方法学是从面向机器、面向数据、面向过程、面向功能、面向数据流、面向对象等不断创新的观点反映问题的本质。整个软件的发展历程使人们越来越认识到应按客观世界规律去解决软件方法学问题。直到 面向对象方法 的出现，才使软件方法学迈进了一大步。但是，高层次上的重用、分布式异构互操作的难点还没有解决。CBSD发展到今天，才在软件方法学上为解决这个难题提供了机会。它把应用业务和实现分离，即逻辑与数据的分离，提供标准接口和框架，使 软件开发方法 变成构件的组合。因此，软件方法学是以接口为中心，面向行为的设计。图3是其开发过程。 归纳起来，CBSD的 软件开发方法 学应包括下面几方面： 对构件有明确的定义。 基于构件的概念需要有构件的描述技术和规范，如UML、JavaBean、EJB、Servlet规范等。 开发应用系统必须按构件裁剪划分组织，包括分配不同的角色。 有支持检验构件特性和生成文档的工具，确保构件规范的实现和质量测试。 总之，传统的软件方法学从草稿自顶向下进行，对重用没有提供更多的辅助。CBSD的软件方法学要丰富得多，它是即插即用，基于体系结构，以接口为中心，将构件有机组合，它把自顶向下和自底向上方法结合起来进行开发。 四、开发组织机构 传统软件的开发组织一般由分析员、设计员、程序员和测试员组成。对一个小的应用系统来说，一个熟练的开发人员，可能兼顾以上多个角色。但对CBSD来说,因为构件开发与应用系统集成往往是分开进行的，因此整个开发过程由六个角色来完成，他们是: 构件开发者 也是构件供货商，这些大多数是中间件构件提供(续致信网上一页内容)者。 应用构件集成者 针对某应用领域将已有构件组合成更大的构件模块或容器， 作为系统部署的基本单元。 应用系统部署者 将系统部署基本单元放入选定的平台环境或基本框架中，完成软件定制的要求。 开发平台服务器供应商 提供服务器、 操作系统 和数据库等基本软件。 应用系统开发工具供应商 提供构件公共设施服务。 系统管理员 配置硬件、网络和 操作系统 ，监督和维护应用系统者。 这六个角色的工作专业性很强，要兼顾成为多面手很不容易。目前已形成构件开放市场，而且还很火红。这也是当今软件人才大战所遇的一个困惑。因此，在CBSD中，如何组织好开发队伍尤为重要，必须按本企业所具备人才来组织。特别重要的是:开发初期必须选好标准框架，以及统一的开发指导方针，保证在整个开发过程中,各角色能随时互相沟通。一般来说，CBSD的人员素质决定了构件的重用率。 五、构造方法 传统应用软件的构造是用白盒子方法，应用系统的实现全在代码中，应用逻辑和数据粘结在一起。而CBSD 的构造是用白盒子和黑盒子相结合的方法。 基于构件的框架是用两个概念来支持演变：第一个概念是构件有很强的性能接口，使构件逻辑功能和构件模型的实现都隐藏起来。这样，只要接口相同，构件就可以被替换。 第二个概念是隐式调用，即在基于构件的框架中，从来不直接给构件的接口分配地址，只在识别构件用户后才分配地址。因此，构件用户只要了解接口要求和为构件接口提供的引用后的返回信息 (该引用可能是一个构件，也可能是一个构件代理。对构件用户来说，构件代理就是构件，不用区分) 。 构件接口的信息并不存入构件内，而是存入构件仓库或注册处。这样才能保证构件替换灵活，并很容易利用隐式调用去重新部署构件。由于构件的实现对用户透明，因此也使构件能适应各种不同的个性化要求。为此，构件提供自检和规范化两个机制。自检保证在不了解构件的具体实现时，就能获得构件接口信息。例如，JavaBean提供的自检机制是Reflection和BeanInfo， 通过Reflection 可直接获得Bean构件的全部方法，通过BeanInfo可直接获得构件的许多复杂信息。 规范化允许不访问构件就可以修改它，如JavaBean提供的规范化是property sheet和customizer(定制器)。 通过property sheet提供一组简单参数，修改Bean的属性。
简述基于构件的软件开发过程的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于简述基于构件技术的特点、简述基于构件的软件开发过程的信息别忘了在本站进行查找喔。
