基于构件的软件工程

合集下载

基于构件的软件工程

基于构件的软件工程

1
2
3
4
单击此处添加正文,文字是您思想的提炼,为了演示发布的良好效果,请言简意赅地阐述您的观点。
构件分类:
应用构件 横向: 界面构件(控件) 业务构件 数据访问构件
纵向: 系统级构件
除了关于软件构件的这些描述,也可以基于软件构件在CBSE过程中的使用来描述。 除了COTS构件,CBSE过程生产: 已认证的构件——由软件工程师评估,以确保不仅功能而且性能、可靠性、可用性和其它质量因素均符合待构造的系统或产品的需求。 适应的构件——对不想要的或不希望的特征进行适应性修改(也称掩盖或包裹)。 组装的构件——被集成到体系结构风格中,并与能够有效地协同和管理构件的合适的基础设施互联。 更新的构件——当新版本的构件可用时,替换现存的构件。
202X
单击此处添加副标题
第6章 基于构件的软件工程
基本概念 基于构件的开发模型 CBSE过程 基于构件的开发 典型的构件模型 构件分类与检索
汇报日期
6.1 基本概念
基于构件的软件工程(component-based software engineering,CBSE)是强调使用可复用的软件“构件”来设计和构造基于计算机的系统的过程。
在传统软件工程环境中,一个构件就是程序的一个功能要素。传统构件也称为模块。 通常,构件具有以下三个角色之一: 控制构件:协调问题域中所有其他构件的调用; 问题域构件:完成部分或全部用户的需求; 基础设施构件:负责完成问题域中所需相关处理的功能。
6.1 基本概念
Brown和Wallnau给出了如下可能的构件描述:
接口定义语言IDL
体系结构描述语言ADL
ADL是一种描述实际系统体系结构的形式语法; 构成元素: 构件 连接件 体系结构配置 比较有影响的ADL有C2、UniCon、MetaH、Aesop、SADL、Rapide、Wright等。

软件工程复习资料

软件工程复习资料

第一章绪论什么是软件工程?软件=程序+数据+文档什么是软件危机?软件危机是指落后的软件生产方式无法满足迅速增长的计算机软件,从而导致软件开发与维护过程中出现一系列严重问题的现象。

什么是软件工程?采用工程化的原理和方法对软件进行计划开发和维护。

软件工程三范型:1.过程式编程范型2.面向对象编程范型3.基于构件技术的编程范型软件工程的发展时期:(1)传统软件工程或者经典软件工程:开发过程:结构化分析一>结构化设计一>面向过程的编码一>软件测试(2)面向对象软件工程开发过程:OO分析与对象抽取一》对象详细设计一》面向对象编码与测试(3)基于构件的软件工程:以软件复用为目标、领域工程为基础,其开发过程一般包括包括以下阶段:领域分析和测试计划定制一一》领域设计一一》建立可复用构件库一一》按“构件集成模型,,查找与集成构件第二章生存周期什么是软件生存周期?计划阶段:需求分析,软件分析开发阶段:软件设计,编码(测试)软件测试维护阶段:运行维护模型特点和使用场合可行性研究1.经济可行性2.技术可行性3.运行可行性4.法律可行性第三章结构化分析与设计结构化程序设计的特点以及论述(1)整个程序的模块化(2)每个模块只有一个入口和出口(3)每个模块都应能单独执行,且无死循环(4)采用自顶向下,逐步细化的方法SA结构化分析设计(结构化)从内容分:1.系统结构设计2.接口设计3.数据设计4.过程设计按照步骤分:1.概要设计2.详细设计第四章OO与面向对象+UML OO的特征1.抽象2.封装3.继承4.多态为什么用面向对象1.符合人类习惯的思维方式2.提高软件系统的可复用性3.提高软件系统的可扩展性4.提高软件系统的可维护性UML相关知识静态图1.用例图:描述系统功能2.类图:描述系统的静态结构3.对象图:描述系统在某个时期的静态结构4.构件图:描述实现系统的元素的组织5.部署图:描述系统环境元素的配置动态图1.状态图:描述系统元素的状态条件和相应2.时序图:按照时间顺序描述系统元素间的交互3.协作图:按照连接关系描述系统元素间的交互4.活动图:描述系统元素的活动流程第五章需求建模需求分析的步骤1.需求获取2.需求建模3.需求描述4.需求验证面向对象需求建模1.画用例图2.写用例规约3.描述补充规约4.编写术语表第六章需求分析面向对象的需求分析1.边界类:边界类提供了对参与者或外部系统交互协议的接口。

基于构件软件工程的经济学分析

基于构件软件工程的经济学分析

软件 的质 量 由 软 件 的 内在 质 量 和 顾 客 满 意 度 两 方 面 决 提 高获得的荣誉 及 由此带来 的收入等 。二 是消 费者 的质量 定 。 相对 应 引 发 软 件 质 量 缺 陷 也 是 两 部 分 构 成 的 : 是 技 收益 , 一 主要有软件产 品 日常用 费 的节 约带 来的经济 收益 ; 软 术 性 缺 陷 , 由 于 软 件 开 发 人 员 在 开 发 过 程 中 的 技 术 原 因 件 产品 日常维护 费用 的 节约 带来 的经 济 收益 ; 既 软件 产 品可 或 失 误造 成 的 缺 陷 , 要 通 过 B 主 UG 发 生 率 、 行 误 码 率 表 行 性带来的 经济 收 益 ; 品使 用 寿 命 带来 的 经济 收 益等 。 千 产 示 ; 是 由 于软 件 开 发 人 员 与 客 户 的 沟 通 不 良 , 虑 不 周 全 三 是 社 会 的 质 量 收 益 , 件 质 量 直 接 或 间 接 影 响 的 其 它 部 二 考 软 等 原 因 造 成 的 , 功 能 性 缺 陷 。理 想 情 况 下 , 了 复 用 而 开 门 或 企 业 产 生 的 经 济 收 益 和 效 果 , 及 质 量 影 响 传 递 获 得 属 为 以
件 软 件 开 发 各 经 济 因子 间 的 关 系 。
关 键 词 : 件 工 程 ; 济 学 ; 析 软 经 分 中 图 分 类 号 : 0 F8 文献标识码 : A 文 章 编 号 :6 23 9 ( 0 9 0 —0 20 l7 —1 8 20 ) 10 2—2
1 传统 软件 工程与基 于构件 软件工 程
工 作 流 程 。传 统 软 件 工 程 在 实 践 中始 终 难 以 解 决 生 产 效 率
传 统 质 量 成 本 理 论 将 质 量 成 本 分 为 预 防 成 本 、 定 成 鉴

基于构件的软件工程研究

基于构件的软件工程研究
件 开 发 的 目的 。下 面从 软 件 工 程 的 角 度 来 比较
性 的特 点 。 软件 构 架描 述 的 是 系统 整体 设 计 格局 、 协作 构件 之 问 的依 赖 关 系 、 责任 分 配 和控 制 流程 ,
第1 卷 第4 3 期
基 于 构 件 的软 件 工 程 研 究
赵 芳

韦 群
( 备指挥 技术学院 电子工程系 , 京 111) 装 北 0 4 6
要 :介 绍 了构 件 的基本 概 念 ; 软 件 工程 包 括 的 方 法 、 从 工具 和 过 程 3个
方 面 分 别 阐 述 了基 于 构 件 的 软 件 工 程 的 特 点 及 与 传 统 的 软 件 开 发 方 法 的 区 别 ; 出 提
了从 传 统 软 件 系统 向基 于构 件 的 软件 系统 转 变 的 2个 问题 。
关 键 词 : 件 ;软 件 构 架 ;软 件 工 程 ;软 件 重 用 ;基 于 构 件 的 软 件 工 程 构 中 图 分 类 号 : P 3 1 5 T l.2
文献 标 识码 :A
文 章 编 号 : Nl ¨g 7 G3 2 O ) 40 5 — 3 C 1: 8 / ( O 2 0 — 0 60  ̄ 表现 为 一 组 抽 象 类 以及 实 例 之 问 协 作 的 方 法 , 它 是 构 件组 装 的基 础 。 架具 有 以下特 征 : 构架 主 构 ① 要 侧 重 于设 计 重 用 , 与 模 板 (e lts 重 用 或 这 tmpae ) 设 计 计 划 ( ein sh ma ) 重 用 等 高 层 设 计 重 d s c e s 1 g
现 在 的 软 件 产 业 仍 保 留着 1 9世 纪 手 工 作 坊

软件工程案例分析

软件工程案例分析

软件项目常见错误(续)
技术相关的错误
–银弹综合症: 过于相信以前没有采用过的技术 的宣传
–过高估计了新技术或方法带来的节省量 –项目中间切换工具 –缺少自动的源代码控制手段
软件项目常见错误(续)
人员相关的错误
– 挫伤积极性 – 人员素质低 – 对有问题的员工失控 – 英雄主义 – 项目后期加入人员:“火上加油” – 办公环境差 – 开发人员与客户之间发生摩擦 – 不现实的预期
软件危机
一种看法
– “两难境地(Crunch Mode)”:处于两难境地的项目 面临无法达到最初目标的威胁(费用、进度表、功能 性等),而项目团队努力想跨越困境。
• “我们正处于两难境地,在半夜之前是不会回家”
– “死亡行军(Death March)”:用来描述其进度表几 乎不可能完成的项目。
3000多个工程师,几百个小团队。
Exchange2000和 Windows2000开发人员结构
项目经理
Exchange2000 25人
Windows2000 约250人
开发人员
140人
约1700人
测试人员
350人
约3200人
“软件工程案例分析”课程与其它 软件专业课的区别
(1) 立足于系统的整体。
软件项目常见错误
选自《快速软件开发》 产品相关的错误
–需求镀金:项目具有比实际需求多得多的性能 –功能蔓延:项目平均会有25%的需求变更
(Jones 1994) –开发人员的镀金:开发人员着迷于新技术 –又推又拉的交易:经理在批准项目进度顺延时
又加入了新的功能 –研究导向的开发
软件项目常见错误(续)
软件危机的主要特征
软件开发周期大大超过规定日期; 软件开发成本严重超标; 软件质量难于保证

软件工程讲义_第九章 构件级设计

软件工程讲义_第九章 构件级设计

传统观点
考虑ComputePageCost模块。该模块的目的在 于根据用户提供的规格说明来计算每页的印刷费用。 为了实现该功能需要以下数据:文档的页数,文档 的印刷份数,单面或者双面印刷,颜色,纸张大小。 这些数据通过该模块的接口传递给 ComputePageCost。ComputePageCost根据任 务量和复杂度,使用这些数据来决定一页的费用— —这是一个通过接口将所有数据传递给模块的功能。 每一页的费用与任务的大小成反比,与任务的复杂 度成正比。
什么是构件
通常来讲,构件是计算机软件中的一个模 块化的构造块。OMG UML规范将构件定 义为“系统中模块化的、可部署的和可替 换的部件,该部件封装了实现并暴露一系 列接口”。 构件存在于软件体系结构中,因而构件在 完成所建系统的需求和目标中起重要作用。 由于构件驻留于软件体系结构的内部,它 们必须与其他的构件和存在于软件边界以 外的实体进行通信和合作。

传统观点

在传统软件工程环境中,一个构件就是程序的 一个功能要素,程序由处理逻辑及实现处理逻辑 所需的内部数据结构以及能够保证构件被调用和 实现数据传递的接口构成。传统构件也被称为模 块,作为软件体系结构的一部分,它承担如下三 个重要角色之一:(1)控制构件,协调问题域中 所有其他构件的调用;(2)问题域构件,完成部分 或全部用户的需求;(3)基础设施构件,负责完成 问题域中所需相关处理的功能。

传统观点

图9-3给出了使用UML建模符号描述的构件级 设计。其中ComputePageCost模块通过调用 getJobData模块和数据库接口accessCostDB 来访问数据。接着,对ComputePageCost模 块进一步细化,给出算法和接口的细节描述。其 中算法的细节可以由图中显示的伪代码或者 UML活动图来表示。接口被表示为一组输入和 输出的数据对象或者数据项的集合。设计细化的 过程需要一直进行下去,直到能够提供指导构件 构造的足够细节为止。

基于构件行为聚类的软件工程知识分类

基于构件行为聚类的软件工程知识分类
关蝴 :软 件 工 程 知 识 体 系 ;接 口 自动机 ;构 件 行 为 聚 类 ;聚 类 构 造 器
S fwa eEng ne rng Kno e eCl s i c to ot r i ei wldg a sf a i n i
Ba e n Co p n n h v o u t r n s d0 m o e t Be a i rCl se i g
I ywod ]S f re nier gB d n wl g (WE OK)Itr c uo t( ;o o et ea i ut n ;ls r g os utr ge rs ot gne n oyOf o e eS B wa E i K d ;nef e tmaaI cmp nn h v r ls r gcut n nt c a A A) b oc e i e c r o i DoI 03 60i n10 -4 82 1.90 7 :1.9 9 .s . 03 2 . 0 3 s 0 01
a i r v d s fwa e e g n e n k wld e c a sfc to me h d Re a di t e a c ie t r o S fwa e En i e r g Bo y Of n mp o e o t r n i e r g no e g ls i ai n i i to g r ng h r h tc u e f o t r gn e统软件工程知识分类方法效率低下 的问题 , 出一种改进的软件工程知识分 类方法 。依据软件工程知识体 系(WE O ) 提 S B K 对
构件行为进行聚类 ,确定关联系数、最佳聚类数和模糊 关联矩阵 ,基于 K— NN算法和结构建模方法生成软件知识 分类系统 ,并根据训练先
验知识将新知识 归入到 S B K的对应类别 下。实验结果表明 ,该方法具有较好的分类效果 。 WE O

一种基于构件的软件工程模型

一种基于构件的软件工程模型
c s no fv tg s o cu e o es it e sa e ,c n ls ss ,wae d ma d a ay i n h e nt n,te c mp n n i r e n n lssa d t e d f ii i o h o o e t

代 计 算 机
软件 的整个开发 过程具有可 生长性 。
/ /
的修 改或添加 。软件开发 过程也可 以随着动 态生长 ,
补充其他任何 开发 阶段 中的遗漏 。 喷泉模 型如 图 3所 示 。常用 的开发模 型还有原 型模 型 、 迭代模 型等 。
2 基 于 构 件 的 软 件 工 程 模 型
构 件 是 近 乎 独 立 的 、 替 换 的 、 足 一 定 功 能 的 可 满 模 块 . 件 之 间 通 过 接 口进 行 通 机 器 码 , 至 是 可 执 行 的 。 它 具 甚 备 以 下 特 点 : 件 是 封 装 了 数 据 和 实 现 方 法 的软 件 模 构





r lto sd sg te c mp n n e in t ec mpo e tc mbiain t s 8 dpu ih lbo eain e in,h o o e td sg , h o n n o n to , e t n bl ,ea - s
定 义 、 件关 系设 计 、 构 构件 设计 、 构件组 合 , 试 和发 测
布 五 个 阶 段 组 成 。就 是 利 用 模 块 化 方 法 , 整 个 系 统 将
有可 生长 性 , 高了构 件 的复用 性 , 提高 软件设 计 提 并 的效率 。
参 考 文 献
模块 化 , 复用 构件 库 中的一个 或 多个 构件 , 过组 合 通 手段高效 率 、 高质 量地构造 应用 软件系统 的过程 。软
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

二、基于软件重用的软件开发过程的角度分 1.生产者重用(product reuse) 指建立、获取或者重新设计可重用构件的活动。涉 及到的活动包括:重用的规划、领域分析、构件的开发、 构件库的组织和管理。 2.消费者重用(consumer reuse) 指使用可重用的构件建立新的系统的活动。涉及到 的活动包括:应用系统的规划、构件的检索和选择、应 用系统中非重用部分的开发、应用系统的组装。
10.1.1 软件重用的级别 三种方式重用:

测试信息的重用 抽
从现有系统的分析结果中提取可重 用构件用于新系统的分析; 主要包括测试用例( test case ) 用一份完整的分析文档作为输入, 的重用和测试过程信息的重用。 成生针对不通软硬件平台和其它实现条 件的多项设计; 独立于具体应用,专门开发一些 可被重用的分析结果是针对问题域 可重用的分析构件。
10.2 软件构件与构件工程
基于软件构件的软件工程也称为构件工程,是 以面向对象的方法为基础,实现软件重用,构造新 系统的过程。 为了实现软件重用,基于软件构件的软件工程 强调领域工程与软件工程同时进行。 领域工程创建应用领域的模型,标识、构造、 分类和传播一组可重用的软件。
图2
典型的重用的过程模型,描述了领域工程与软件工程的关系。
10.2.1 可重用构件 一个软件只有在多个系统中被使用才可称为“可重 用构件”,必须具备的条件: (4)通用性 构件解决的问题,应在同类应用中具有一般性; (5)适应性 应用场合有某些变化时,构件仍是可用的,使构 件的某些数据参数化和数据类型参数化; (6)可靠性 要求构件对预计将要使用它的系统时可靠的; (7)标准化 可重用构件的标准化对于软件重用是至关重要的。
领域分析的输入和输出
领域分析不是针对某个特定的软件系统,而是针 对一类软件系统的共同的特征、知识和需求。比需求 分析更一般、更抽象、更广泛的特征。 领域分析(Domain Analysis)是对一类应用系统的 共同应用领域进行系统化分析,以发现该领域的共同知 识、需求及其应用系统的共同特征。 领域分析又称领域工程(Domain Engineering), 是软件工程的发展与延伸。 领域分析是一项比系统分析更难的工作。领域分 析方法可采用结构化方法和面向对象方法,而后者将 成为主流。
软件重用的优点: (1)提高软件生产率,降低软件生产代价; (2)提高软件质量; (3)互操作性好; (4)推动标准化; (5)支持原型开发。
10.1.2软件重用的形式 一、按照重用活动所跨越的应用领域的类型分 1. 横向重用( horizontal reuse ) 也称为水平 重用,是指重用活动的范围跨越了几个不同的应 用领域,重用的软件产品主要包括数据结构、通 用算法、人机界面等软件元素。 2. 纵向重用( vertical reuse ) 也称为垂直重 用,是指重用活动的范围限制在同一个应用领域 或者是一类具有较多共性的应用领域内。
领域工程
领域分析 设计软件 体系结构 开发可重用 的软件成分ห้องสมุดไป่ตู้
领域 模型
结构 模型
中心库
可重用软件 成分/构件
软件工程
系统分析 用户 需求
规格说明 与设计
建造
系统规 格说明
分析与 设计模型
应用 软件
重用的过程模型
6.2.1 可重用构件 一个软件只有在多个系统中被使用才可称为“可重 用构件”,必须具备的条件: (1)独立性 解决一个相对独立的问题,或大问题中某个相对 独立的部分; (2)完整性 提供较完整的解决,不要遗留很多缺口,让重用 者做大量补充; (3)可标识性 构件所解决的问题应该是可标识的,可命名,有 简要介绍,便于理解和使用。
(2)人的因素 喜欢自己创造而不喜欢使用别人的东西。
10.1.3 软件重用的困难 重用具有许多明显的优点,目前应用不广泛的主要 原因是:
(3)管理因素 把重用构件和一般软件构件同等看待,把重用看 作可有可无的事。
(4)教育因素 软件科学技术的教育与培训中,缺乏关于软件重用 的内容,缺少专门教材和课程。
生产者重用 (为重用开发构件)
建立构件
消费者重用 (使用构件开发应用)
组装应用
生产者重用与消费者重用
10.1.3 软件重用的困难 重用具有许多明显的优点,目前应用不广泛的主 要原因是:
(1)技术因素
构件与应用系统之间的差异;
构件要达到一定的规模,才能支持有效的重用;
发现合用构件的困难; 基于重用的软件开发方法和软件过程需要一些新 的理论、技术及支持环境。

程 度
分析结果的重用
的某些事物或某些问题的抽象程度 更高的解法。 受实际环境影响小,可重用机会多, 所需修改少。 包括目标代码,也包括文本形式的 源代码。
设计结果的重用

代码的重用
软件生产过程主要是正向过程 ,即软件产品从抽象 级别较高的形态向抽象级别较低的形态演化 ,所以较高 级别的重用容易带动较低级别的重用,反之则不然。 重用级别越高,可得到的回报也越大,因此分析 软件(Analysis Ware)和设计软件(Design Ware)的重用 备受重视。
10.2.3 领域分析 领域分析是对特定应用领域中共同的特征、知 识、需求的标识、分析和规约。领域分析是特定领 域内软件重用的基础,它的目标就是:发现和挖掘 在特定领域内可以被重用的构件。领域分析活动中 输入和输出如图所示:
输入信息
技术文献 已有应用 专家经验/建议 当前与未来的需求
输出信息
领域分析 领域语言 重用标准 分类方法 功能/行为模型
6.2.2 基于构件的软件工程
基于构件的软件工程与传统的或面向对象的软 件工程相比,有显著的差异。 它不是针对某个特定的软件系统,而是针对一 类软件系统的共同的特征、知识和需求。 基于构件的软件的开发过程包括两个并发的子 过程,一个是领域工程,另一个是基于构件的开 发。领域工程完成一组可重用构件的标示、构造、 分类和传播;基于构件的开发完成使用可重用构件 构造新的软件系统。
第十章软件重用和构件技术
10
第十章
软件重用技术
10.1 软件重用概述
软件重用就是将已有的软件成分用于构造新的软 件系统,以达到提高软件系统的开发质量与效率,降 低开发成本的目的。 可重用的软件成分,也称为可重用构件(Reusable Component) 可从旧软件中提取,也可以专门为重用 而开发。 软件重用不仅是对程序的重用,它包括对软件生 产过程中任何活动所产生的制成品的重用。如:项目 计划、可行性报告、需求定义、分析模型、详细说明、 源程序和测试用例等等。
相关文档
最新文档