Ⅰ 什么是软件构架
软件架构
软件架构(software architecture)是一系列相关的抽象模式,用于指导大型软件系统各个方面的设计。 软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段,这些抽象组件被细化为实际的组件,比如具体某个类或者对象。在面向对象领域中,组件之间的连接通常用接口_(计算机科学)来实现。
软件体系结构是构建计算机软件实践的基础。与建筑师设定建筑项目的设计原则和目标,作为绘图员画图的基础一样,一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。
软件构架是一个容易理解的概念,多数工程师(尤其是经验不多的工程师)会从直觉上来认识它,但要给出精确的定义很困难。特别是,很难明确地区分设计和构架:构架属于设计的一方面,它集中于某些具体的特征。
在“软件构架简介”中,David GArlan 和 Mary Shaw 认为软件构架是有关如下问题的设计层次:“在计算的算法和数据结构之外,设计并确定系统整体结构成为了新的问题。结构问题包括总体组织结构和全局控制结构;通信、同步和数据访问的协议;设计元素的功能分配;物理分布;设计元素的组成;定标与性能;备选设计的选择。”[GS93]
但构架不仅是结构;IEEE Working Group on Architecture 把其定义为“系统在其环境中的最高层概念”[IEEE98]。构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。它并不仅注重对内部的考虑,而且还在系统的用户环境和开发环境中对系统进行整体考虑,即同时注重对外部的考虑。
在 Rational Unified ProcESs 中,软件系统的构架(在某一给定点)是指系统重要构件的组织或结构,这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互。
从和目的、主题、材料和结构的联系上来说,软件架构可以和建筑物的架构相比拟。一个软件架构师需要有广泛的软件理论知识和相应的经验来事实和管理软件产品的高级设计。软件架构师定义和设计软件的模块化,模块之间的交互,用户界面风格,对外接口方法,创新的设计特性,以及高层事物的对象操作、逻辑和流程。
是一般而言,软件系统的架构(ArchitECture)有两个要素:
·它是一个软件系统从整体到部分的最高层次的划分。
一个系统通常是由元件组成的,而这些元件如何形成、相互之间如何发生作用,则是关于这个系统本身结构的重要信息。
详细地说,就是要包括架构元件(Architecture Component)、联结器(Connector)、任务流(TASk-flow)。所谓架构元素,也就是组成系统的核心"砖瓦",而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果,任务流则描述系统如何使用这些元件和联结器完成某一项需求。
·建造一个系统所作出的最高层次的、以后难以更改的,商业的和技术的决定。
在建造一个系统之前会有很多的重要决定需要事先作出,而一旦系统开始进行详细设计甚至建造,这些决定就很难更改甚至无法更改。显然,这样的决定必定是有关系统设计成败的最重要决定,必须经过非常慎重的研究和考察。
历史
早在1960年代,诸如E·W·戴克斯特拉就已经涉及软件架构这个概念了。自1990年代以来,部分由于在 Rational Software Corporation 和MiCROSoft内部的相关活动,软件架构这个概念开始越来越流行起来。
卡内基梅隆大学和加州大学埃尔文分校在这个领域作了很多研究。卡内基·梅隆大学的Mary Shaw和David Garlan于1996年写了一本叫做 Software Architecture perspective on an emerging DIscipline的书,提出了软件架构中的很多概念,例如软件组件、连接器、风格等等。 加州大学埃尔文分校的软件研究院所做的工作则主要集中于架构风格、架构描述语言以及动态架构。
计算机软件的历史开始于五十年代,历史非常短暂,而相比之下建筑工程则从石器时代就开始了,人类在几千年的建筑设计实践中积累了大量的经验和教训。建筑设计基本上包含两点,一是建筑风格,二是建筑模式。独特的建筑风格和恰当选择的建筑模式,可以使一个独一无二。
下面的照片显示了中美洲古代玛雅建筑,Chichen-Itza大金字塔,九个巨大的石级堆垒而上,九十一级台阶(象征着四季的天数)夺路而出,塔顶的神殿耸入云天。所有的数字都如日历般严谨,风格雄浑。难以想象这是石器时代的建筑物。
图1、位于墨西哥Chichen-Itza(在玛雅语中chi意为嘴chen意为井)的古玛雅建筑。(摄影:作者)
软件与人类的关系是架构师必须面对的核心问题,也是自从软件进入历史舞台之后就出现的问题。与此类似地,自从有了建筑以来,建筑与人类的关系就一直是建筑设计师必须面对的核心问题。英国首相丘吉尔说,我们构造建筑物,然后建筑物构造我们(We shape our buildings, and afterwaRDS our buildings shape us)。英国下议院的会议厅较狭窄,无法使所有的下议院议员面向同一个方向入座,而必须分成两侧入座。丘吉尔认为,议员们入座的时候自然会选择与自己政见相同的人同时入座,而这就是英国政党制的起源。Party这个词的原意就是"方"、"面"。政党起源的关键就是建筑物对人的影响。
在软件设计界曾经有很多人认为功能是最为重要的,形式必须服从功能。与此类似地,在建筑学界,现代主义建筑流派的开创人之一Louis Sullivan也认为形式应当服从于功能(FORMs follows function)。
几乎所有的软件设计理念都可以在浩如烟海的建筑学历史中找到更为遥远的历史回响。最为着名的,当然就是模式理论和XP理论。
架构的目标是什么
正如同软件本身有其要达到的目标一样,架构设计要达到的目标是什么呢?一般而言,软件架构设计要达到如下的目标:
·可靠性(Reliable)。软件系统对于用户的商业经营和管理来说极为重要,因此软件系统必须非常可靠。
·安全行(Secure)。软件系统所承担的交易的商业价值极高,系统的安全性非常重要。
·可扩展性(SCAlable)。软件必须能够在用户的使用率、用户的数目增加很快的情况下,保持合理的性能。只有这样,才能适应用户的市场扩展得可能性。
·可定制化(CuSTomizable)。同样的一套软件,可以根据客户群的不同和市场需求的变化进行调整。
·可扩展性(Extensible)。在新技术出现的时候,一个软件系统应当允许导入新技术,从而对现有系统进行功能和性能的扩展
·可维护性(MAIntainable)。软件系统的维护包括两方面,一是排除现有的错误,二是将新的软件需求反映到现有系统中去。一个易于维护的系统可以有效地降低技术支持的花费
·客户体验(Customer Experience)。软件系统必须易于使用。
·市场时机(Time to Market)。软件用户要面临同业竞争,软件提供商也要面临同业竞争。以最快的速度争夺市场先机非常重要。
架构的种类
根据我们关注的角度不同,可以将架构分成三种:
·逻辑架构、软件系统中元件之间的关系,比如用户界面,数据库,外部系统接口,商业逻辑元件,等等。
比如下面就是笔者亲身经历过的一个软件系统的逻辑架构图
图2、一个逻辑架构的例子
从上面这张图中可以看出,此系统被划分成三个逻辑层次,即表象层次,商业层次和数据持久层次。每一个层次都含有多个逻辑元件。比如WEB服务器层次中有HTML服务元件、Session服务元件、安全服务元件、系统管理元件等。
·物理架构、软件元件是怎样放到硬件上的。
比如下面这张物理架构图描述了一个分布于北京和上海的分布式系统的物理架构,图中所有的元件都是物理设备,包括网络分流器、代理服务器、WEB服务器、应用服务器、报表服务器、整合服务器、存储服务器、主机等等。
图3、一个物理架构的例子
·系统架构、系统的非功能性特征,如可扩展性、可靠性、强壮性、灵活性、性能等。
系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识,这一工作无疑是架构设计工作中最为困难的工作。
此外,从每一个角度上看,都可以看到架构的两要素:元件划分和设计决定。
首先,一个软件系统中的元件首先是逻辑元件。这些逻辑元件如何放到硬件上,以及这些元件如何为整个系统的可扩展性、可靠性、强壮性、灵活性、性能等做出贡献,是非常重要的信息。
其次,进行软件设计需要做出的决定中,必然会包括逻辑结构、物理结构,以及它们如何影响到系统的所有非功能性特征。这些决定中会有很多是一旦作出,就很难更改的。
根据作者的经验,一个基于数据库的系统架构,有多少个数据表,就会有多少页的架构设计文档。比如一个中等的数据库应用系统通常含有一百个左右的数据表,这样的一个系统设计通常需要有一百页左右的架构设计文档。
构架描述
为了讨论和分析软件构架,必须首先定义构架表示方式,即描述构架重要方面的方式。在 Rational Unified Process 中,软件构架文档记录有这种描述。
构架视图
我们决定以多种构架视图来表示软件构架。每种构架视图针对于开发流程中的涉众(例如最终用户、设计人员、管理人员、系统工程师、维护人员等)所关注的特定方面。
构架视图显示了软件构架如何分解为构件,以及构件如何由连接器连接来产生有用的形式 [PW92],由此记录主要的结构设计决策。这些设计决策必须基于需求以及功能、补充和其他方面的约束。而这些决策又会在较低层次上为需求和将来的设计决策施加进一步的约束。
典型的构架视图集
构架由许多不同的构架视图来表示,这些视图本质上是以图形方式来摘要说明“在构架方面具有重要意义”的模型元素。在 Rational Unified Process 中,您将从一个典型的视图集开始,该视图集称为“4+1 视图模型”[KRU95]。它包括:
用例视图:包括用例和场景,这些用例和场景包括在构架方面具有重要意义的行为、类或技术风险。它是用例模型的子集。
逻辑视图:包括最重要的设计类、从这些设计类到包和子系统的组织形式,以及从这些包和子系统到层的组织形式。它还包括一些用例实现。它是设计模型的子集。
实施视图:包括实施模型及其从模块到包和层的组织形式的概览。 同时还描述了将逻辑视图中的包和类向实施视图中的包和模块分配的情况。它是实施模型的子集。
进程视图:包括所涉及任务(进程和线程)的描述,它们的交互和配置,以及将设计对象和类向任务的分配情况。只有在系统具有很高程度的并行时,才需要该视图。在 Rational Unified Process 中,它是设计模型的子集。
配置视图:包括对最典型的平台配置的各种物理节点的描述以及将任务(来自进程视图)向物理节点分配的情况。只有在分布式系统中才需要该视图。它是部署模型的一个子集。
构架视图记录在软件构架文档中。您可以构建其他视图来表达需要特别关注的不同方面:用户界面视图、安全视图、数据视图等等。对于简单系统,可以省略 4+1 视图模型中的一些视图。
构架重点
虽然以上视图可以表示系统的整体设计,但构架只同以下几个具体方面相关:
模型的结构,即组织模式,例如分层。
基本元素,即关键用例、主类、常用机制等,它们与模型中的各元素相对。
几个关键场景,它们表示了整个系统的主要控制流程。
记录模块度、可选特征、产品线状况的服务。
构架视图在本质上是整体设计的抽象或简化,它们通过舍弃具体细节来突出重要的特征。在考虑以下方面时,这些特征非常重要:
系统演进,即进入下一个开发周期。
在产品线环境下复用构架或构架的一部分。
评估补充质量,例如性能、可用性、可移植性和安全性。
向团队或分包商分配开发工作。
决定是否包括市售构件。
插入范围更广的系统。
构架模式
构架模式是解决复发构架问题的现成形式。构架框架或构架基础设施(中间件)是可以在其上构建某种构架的构件集。许多主要的构架困难应在框架或基础设施中进行解决,而且通常针对于特定的领域:命令和控制、MIS、控制系统等等。
构架模式示例
[BUS96] 根据构架模式最适用的系统的特征将其分类,其中一个类别处理更普遍的结构问题。下表显示了 [BUS96] 中所提供的类别和这些类别所包含的模式。
类别 模式
结构 层
管道和过滤器
黑板
分布式系统 代理
交互系统 模型-视图-控制器
表示-抽象-控制
自适应系统 反射
微核
软件构架是一个容易理解的概念,多数工程师(尤其是经验不多的工程师)会从直觉上来认识它,但要给出精确的定义很困难。特别是,很难明确地区分设计和构架:构架属于设计的一方面,它集中于某些具体的特征。
在“软件构架简介”中,David Garlan 和 Mary Shaw 认为软件构架是有关如下问题的设计层次:“在计算的算法和数据结构之外,设计并确定系统整体结构成为了新的问题。结构问题包括总体组织结构和全局控制结构;通信、同步和数据访问的协议;设计元素的功能分配;物理分布;设计元素的组成;定标与性能;备选设计的选择。”[GS93]
但构架不仅是结构;IEEE Working Group on Architecture 把其定义为“系统在其环境中的最高层概念”[IEEE98]。构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。它并不仅注重对内部的考虑,而且还在系统的用户环境和开发环境中对系统进行整体考虑,即同时注重对外部的考虑。
在 Rational Unified Process 中,软件系统的构架(在某一给定点)是指系统重要构件的组织或结构,这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互。
为阐明其含义,下面将详述其中的两个;完整说明请参见 [BUS96]。模式以下列广泛使用的形式来表示:
模式名
环境
问题
影响,描述应考虑的不同问题方面
解决方案
基本原理
结果环境
示例
模式名
层
环境
需要进行结构分解的大系统。
问题
必须处理不同抽象层次的问题的系统。例如:硬件控制问题、常见服务问题和针对于不同领域的问题。最好不要编写垂直构件来处理所有抽象层次的问题。否则要在不同的构件中多次处理相同的问题(可能会不一致)。
影响
系统的某些部分应当是可替换的
构件中的变化不应波动
相似的责任应归为一组
构件大小 -- 复杂构件可能要进行分解
解决办法
将系统分成构件组,并使构件组形成层叠结构。使上层只使用下层(决不使用上层)提供的服务。尽量不使用非紧邻下层提供的服务(不跳层使用服务,除非中间层只添加通过构件)。
示例:
1. 通用层
严格的分层构架规定设计元素(类、构件、包、子系统)只能使用下层提供的服务, 服务可以包括事件处理、错误处理、数据库访问等等。 相对于记录在底层的原始操作系统级调用,它包括更明显的机制。
2. 业务系统层
上图显示了另一个分层示例,其中有垂直特定应用层、水平层和基础设施层。注意:此处的目标是采用非常短的业务“烟囱”并实现各种应用程序间的通用性。 否则,就可能有多个人解决同一问题,从而导致潜在的分歧。
有关该模式的深入讨论,请参见指南:分层。
模式名
黑板
环境
没有解决问题的确定方法(算法)或方法不可行的领域。例如 AI 系统、语音识别和监视系统。
问题
多个问题解决顾问(知识顾问)必须通过协作来解决他们无法单独解决的问题。各顾问的工作结果必须可以供所有其他顾问访问,使他们可以评估自己是否可以参与解决方案的查找并发布其工作结果。
影响
知识顾问参与解决问题的顺序不是确定的,这可能取决于问题解决策略
不同顾问的输入(结果或部分解决方案)可能有不同的表示方式
各顾问并不直接知道对方的存在,但可以评估对方发布的工作
解决办法
多名知识顾问都可访问一个称为“黑板”的共享数据库。黑板提供监测和更新其内容的接口。控制模块/对象激活遵循某种策略的顾问。激活后,顾问查看黑板,以确定它是否能参与解决问题。如果顾问决定它可以参与,控制对象就可以允许顾问将其部分(或最终)解决方案放置于黑板上。
示例:
以上显示了使用 UML 建模的结构或静态视图。 它将成为参数化协作的一部分,然后会绑定到实参上对模式进行实例化。
构架风格
软件构架(或仅是构架视图)可以具有名为构架风格的属性,该属性减少了可选的形式,并使构架具有一定程度的一致性。样式可以通过一组模式或通过选择特定构件或连接器作为基本构件来定义。对给定系统,某些样式可作为构架描述的一部分记录在构架风格指南(Rational Unified Process 中设计指南文档的一部分)中。样式在构架的可理解性与完整性方面起着主要的作用。
构架设计图
构架视图的图形描述称为构架设计图。对于以上描述的各种视图,设计图由以下统一建模语言图组成 [UML99]:
逻辑视图:类图、状态机和对象图。
进程视图:类图与对象图(包括任务 - 进程与线程)。
实施视图:构件图。
部署视图:配置图。
用例视图:用例图描述用例、主角和普通设计类;顺序图描述设计对象及其协作关系。
构架设计流程
在 Rational Unified Process 中,构架主要是分析设计工作流程的结果。当项目再次进行此工作流程时,构架将在一次又一次迭代中不断演化、改进、精炼。由于每次迭代都包括集成和测试,所以在交付产品时,构架就相当强壮了。构架是精化阶段各次迭代的重点,构架的基线通常会在此阶段结束时确定。
架构师
软体设计师中有一些技术水平较高、经验较为丰富的人,他们需要承担软件系统的架构设计,也就是需要设计系统的元件如何划分、元件之间如何发生相互作用,以及系统中逻辑的、物理的、系统的重要决定的作出。
这样的人就是所谓的架构师(Architect)。在很多公司中,架构师不是一个专门的和正式的职务。通常在一个开发小组中,最有经验的程序员会负责一些架构方面的工作。在一个部门中,最有经验的项目经理会负责一些架构方面的工作。
但是,越来越多的公司体认到架构工作的重要性,并且在不同的组织层次上设置专门的架构师位置,由他们负责不同层次上的逻辑架构、物理架构、系统架构的设计、配置、维护等工作。
参考资料:http://www.itise.com/phrase/200602281452595.html
Ⅱ 构件的软件工程中的构件
构件是面向软件体系架构的可复用软件模块。构件(component)是可复用的软件组成成份,可被用来构造其他软件。它可以是被封装的对象类、类树、一些功能模块、软件框架(framework)、软件构架(或体系结构Architectural)、文档、分析件、设计模式(Pattern)等。1995年,Ian.oraham给出的构件定义如下:构件(Component)是指一个对象(接口规范、或二进制代码),它被用于复用,接口被明确定义[8]。构件是作为一个逻辑紧密的程序代码包的形式出现的,有着良好的接口。像Ada的Package、Smalltalk-80和C++的class和数据类型都可属于构件范畴。但是,操作集合、过程、函数即使可以复用也不能成为一个构件。开发者可以通过组装已有的构件来开发新的应用系统,从而达到软件复用的目的。软件构件技术是软件复用的关键因素,也是软件复用技术研究的重点。 (1)有用性(Usefulness):构件必须提供有用的功能;
(2)可用性(Usability):构件必须易于理解和使用;
(3)质量(Quality):构件及其变形必须能正确工作;
(4)适应性(Adaptability):构件应该易于通过参数化等方式在不同语境中进行配置;
(5)可移植性(Portability):构件应能在不同的硬件运行平台和软件环境中工作。
日历、工作流构件、订单构件、用户界面控制等等都可以是构件。 构件具有以下几个特点:
(1)自描述:构件必须能够识别其属性、存取方法和事件,这些信息可以使开发环境将第三方软件构件无缝地结合起来;
(2)可定制:允许提供一个典型的图形方式环境,软件构件的属性只能通过控制面板来设置;
(3)可集成:构件必须可以被编程语言直接控制。构件也可以和脚本语言或者与从代码级访问构件的环境连接,这个特点使得软件构件可以在非可视化开发项目中使用;
(4)连接机制:构件必须能产生事件或者具有让程序员从语义上实现相互连接的其他机制。
采用构件软件不需要重新编译,也不需要源代码并且不局限于某一种编程语言。该过程叫做二进制复用(Binary Reuse),因为它是建立在接口而不是源代码级别的复用之上的。虽然软件构件必须遵守一致的接口,但是它们的内部实现是完全自动的。因此,可以用过程语言和面向对象语言创建构件。
由于构件技术是由基于面向对象技术而发展起来的,与面向对象的设计中的对象相类似,它们都是针对软件复用,都是被封装的代码,但它们之间仍存在很大差异。 (1)在纯面向对象的设计中,对象(类)、封装和继承三者缺一不可,但对构件可以没有继承性,只要实现封装即可;
(2)从构件和对象的生成方式上,对象生成属于实例化的过程,比较单一,而生成构件的方式较多;
(3)构件是设计的概念,与具体编程语言无关,不像对象属于编程中的概念,要依赖于具体的编程语言;
(4)在对构件操作时不允许直接操作构件中的数据,数据真正被封装了。而对象的操作通过公共接口部分,这样数据是可能被访问操作的;
(5)对象对软件复用是通过继承实现的,构件对软件复用不仅可以通过继承还可以通过组装时的引用来实现。
因此,构件不是对象,只是与对象类似。
从力学角度来说,结构是指可以承受一定力的结构形态,它可以抵抗能引起形状和大小改变的力。每种事物都有它的架构形态,这种架构形态体现着它的结构。一个较复杂的结构由许多不同的部分组成,这些组成部分通常成为构件。
Ⅲ software component是什么意思
software component
un.软件成分
软件组件;软件构件化;软构件
例句
1.
Software component is a fundamental unit of software reusability.
软件构件是软件复用的基本单元。
2.
With registration complete, the second software component may then be downloaded.
在注册完毕后,就可以下载第二软件组件。
3.
A managed software component that performs a task in response to an application event.
一种托管软件组件,该组件通过执行任务来响应应用程序事件。
4.
There are many aspects to the concept of a software component.
软件组件的概念涉及很多方面。
5.
Represents a property of a printing system hardware or software component whose value is an array of Byte values.
表示打印系统硬件或软件组件一个属性,其值为Byte值的一个数组。
6.
Describes how to create and install a host adapter, which is a software component that lets you run tests in a specific environment.
介绍如何创建和安装主机适配器,这是一个软件组件,使您可以在特定的环境中运行测试。
Ⅳ 广联达软件中“构件”是什么意思
构件就是一个名称属性的东西,比如一颗柱子,你建立他的属性出来后他就是一个构件了,然后你会展到图上后,这个图形就是一个图元了,相同的图元都是一个构件,构件的名称是不能重复的。
比如,列表所项
希望能帮助得到你
Ⅳ 什么叫系统的构件化开发
软件构件又称软件集成电路;构件的特点可以不断复用,可以显着降低成本,缩减工期。
软件构件化是指应用系统中可以明确辨识的构成成分,包括源代码、需求、系统和软件的需求规约、系统和软件的构架、文档、测试计划、测试案例和数据以及其他开发活动有用的信息。
Ⅵ 构件是什么
构件是系统中实际存在的可更换部分。它实现特定的功能,符合一套接口标准并能实现一组接口。构件代表系统中的一部分物理实施,包括软件代码(源代码、二进制代码或可执行代码)或其等价物(如脚本或命令文件)。在图型中,构件表示为一个带有标签的矩形。
Ⅶ 计算机软件的五大基本构件包括什么
中央处理器、存储器、输入设备、输出设备以及控制器。
最初的计算机就是这五大部件,是分立的五大部件,随着集成电路的发展,体积越来越小,集成度越来越高。后来把运算器和控制器集成到一起,称为微处理器,才诞生了微机(微机一点都不小,是有微处理器的计算机)。
计算机系统是由硬件和软件组成的,系统软件是指能够对计算机硬件资源进行管理,其核心就是操作系统。计算机系统是由三个层次构成的,即硬件、软件和应用软件,下层为上层功能提供支持。
(7)什么是软件构件扩展阅读:
注意事项:
1、将计算机放置在较一般读书距离稍远处,计算机屏幕上端,稍微在眼睛水平面下方,使用计算机时,将觉得较舒适。
2、将要输入的资料文字放置于荧光屏旁,越接近越好,以减少颈部及眼睛转动以及注意力改变。
3、计算机、信息互递及生产应用系统的用户口令是否按要求设置,口令设置须大小写字母、数字及特殊字符混合组成且不少于8位。
Ⅷ hp inc softwarecomponent是什么
software component
un.软件成分
软件组件;软件构件化;软构件
例句
1.
Software component is a fundamental unit of software reusability.
软件构件是软件复用的基本单元。
2.
With registration complete, the second software component may then be downloaded.
在注册完毕后,就可以下载第二软件组件。
3.
A managed software component that performs a task in response to an application event.
一种托管软件组件,该组件通过执行任务来响应应用程序事件。
Ⅸ 什么是软件结构
软件体系结构研究如果仅仅停留在非形式化的框图阶段,已经难以适应进一步发展的需要。为支持基于体系结构的开发,需要有形式化建模符号、体系结构说明的分析与开发工具。从软件体系结构研究的现状来看,在这一领域近来已经有不少进展,其中比较有代表性的是美国卡耐基梅隆大学(Carnegie Mellon University)的Robert J.A11en于l997年提出的Wright系统。Wright是-种结构描述语言,该语言基于一种形式化的、抽象的系统模型,为描述和分析软件体系结构和结构化方法提供了一种实用的工具。Wright主要侧重于描述系统的软件构件和连接的结构、配置和方法。它使用显式的、独立的连接模型来作为交互的方式,这使得该系统可以用逻辑谓词符号系统,而不依赖特定的系统实例来描述系统的抽象行为。该系统还可以通过一组静态检查来判断系统结构规格说明的一致性和完整性。从这些特性的分析来说,Wright系统的确适用于对大型系统的描述和分析。
Ⅹ 什么是部件什么是零件什么是构件
部件(assembly unit)是机械的一部分,由若干装配在一起的零件所组成。
零件,指机械中不可分拆的单个制件,是机器的基本组成要素,也是机械制造过程中的基本单元。其制造过程一般不需要装配工序。如轴套、轴瓦、螺母、曲轴、叶片、齿轮、凸轮、连杆体、连杆头等。
构件是系统中实际存在的可更换部分,它实现特定的功能,符合一套接口标准并实现一组接口。构件代表系统中的一部分物理实施,包括软件代码(源代码、二进制代码或可执行代码)或其等价物(如脚本或命令文件)。在图中,构件表示为一个带有标签的矩形。在工程实际中,各种机械与结构得到广泛应用。组成机械与结构的零、构件,在工程力学中统称为构件。
(10)什么是软件构件扩展阅读:
构件具有以下几个特点:
(1)自描述:构件必须能够识别其属性、存取方法和事件,这些信息可以使开发环境将第三方软件构件无缝地结合起来;
(2)可定制:允许提供一个典型的图形方式环境,软件构件的属性只能通过控制面板来设置;
(3)可集成:构件必须可以被编程语言直接控制。构件也可以和脚本语言或者与从代码级访问构件的环境连接,这个特点使得软件构件可以在非可视化开发项目中使用;
(4)连接机制:构件必须能产生事件或者具有让程序员从语义上实现相互连接的其他机制。
采用构件软件不需要重新编译,也不需要源代码并且不局限于某一种编程语言。该过程叫做二进制复用,因为它是建立在接口而不是源代码级别的复用之上的。虽然软件构件必须遵守一致的接口,但是它们的内部实现是完全自动的。因此,可以用过程语言和面向对象语言创建构件。