文档库 最新最全的文档下载
当前位置:文档库 › 面向构件的软件开发方法学分析研究

面向构件的软件开发方法学分析研究

面向构件的软件开发方法学分析研究
面向构件的软件开发方法学分析研究

面向构件的软件开发方法学研究

陈良山 200305018009

从软件建模方法论的角度看, 信息系统的开发方法已历经两代技术跨越: 面向过程, 包括面向功能和面向数据流。面向对象, 体现功能与数据抽象方法的统一.20 世纪90 年代中期以来, 由于分布对象技术与软件重构工程的有机结合, 促使面向构件的软件开发方法应运而生.面向构件方法(COM >与面向对象方法(OOM > 的本质差异在于: 对象化建模过程一般针对单一应用系统, 对象抽象一般针对问题域, 对象模型的生成过程是静态的, 软件重用粒度是原子级的。而构件化建模过程一般针对领域应用系统, 构件抽象则针对解域, 构件化模型即构架的生成过程是动态的, 软件重用粒度是组合级的. 领域应用是多个单一应用通用化和重用化的应用集群, 解域是问题域的过程与层次深化, 构件则是对象的软件实现与集成。因此,COM 法与OOM 法在研究范畴、研究对象及其研究方法上都是有区别的. 不言而喻, 面向构件方法是21 世纪软件方法学的主流研究方向. 下面用过程与方法的组合理念来展开研究内容.

面向构件软件开发的一般过程

构件化软件开发的过程模型

所谓构件化, 是指软件体系结构可重组以及软件成份可重用的系统开发方法. 这种方法的基本内涵是: 应用需求领域化, 软件结构框架化, 软件元素构件化, 应用原型实例化. 这一思想可以概括为四个阶段、三个层次和两大过程, 如图 1 所示

从工程化与过程管理的角度讲, 整个软件系统的开发过程可定义为四个阶段: 分析, 设计,

实现, 评价. 但这并不是单纯的串行式瀑布模型, 而是过程并行与增量迭代等多种方法相结合的工作流模型. 多年来, 人们往往把系统阶段控制方法与软件建模抽象方法混为一谈。

最典型的是把生命周期法和原型法与面向过程和面向对象的方法混为一谈.

信息系统是一种具有生命周期的开放系统, 这是毋庸置疑的. 因此, 从工程管理及大的阶段控制过程看, 构件化方法与结构化方法和对象化方法一样, 仍然应该遵循软件生命周期规律。差别在于, 前者的阶段论观点是弱化的历递归和过程重构特征. 换句话说, 在构件化方法中, 可以引入并行工程思想和能力成熟度模型(CMM > 来进行局部过程改造, 以提高系统开发效率和持续优化效果。

可以引入领域工程思想和面向对象方法来改善建模机制, 以提高系统实施过程

的可操作性. 这就是面向构件方法论的主要过程特征. 从模型化与内容抽象的角度讲, 构件化软件开发过程可按三个层次展开: 概念层, 逻辑层, 物理层. 这与UML 描述、数据库设计模式和元建模技术等多种方法是一致的, 差别只在术语不同. 例如, 在基于UML 形式描述的面向对象建模中, 上述三个层次称概念层、说明层和实现层。而在元建模中, 则称元知识层、结构知识层和算法知识层.整个建模层次展开过程是: 首先从特定应用需求出发,

通过领域分析进行共性需求识别、领域对象抽象和领域知识获取, 以建立概念级的领域模型. 进而通过领域设计为领域需求寻求软件解决方案, 包括构架级和构件级的设计模型。这种模型体现了初步设计和详细设计成果, 体现了框架结构和部件结构的组成原理可行性, 因而是一种逻辑模型. 由问题域的领域模型转化为解域的构架模型和构件模型, 是一个知识提取(正向> 和分析精化(逆向> 的迭代式增量开发过程. 第三, 根据领域应用开发或直接重用需要, 进行领域实现。包括领域构件的识别、设计、编码和测试等局部过程集成,

系统构件的分类、检索、引用和构件库维护,

领域构件与系统构件的演化、例化、组合和应用原型的动态生成等领域框架整体集成,

从而建立符合领域应用的各种物理模型. 第四, 通过运行模拟(正向>和设计优化(逆向>等措施,

对领域化软件原型进行可用性评价和可重构验证,

并对符合确认测试条件的应用系统进行全局封装和使用规范生成。

最终获得一个真正构件化的目标系统,

这是一个经过版本逐次寻优的实用软件系统.整个过程模型充分体现重构工程思想,

并把面向构件的软件开发分离为正向工程和逆向工程两大过程.

正向工程侧重体现自顶向下与过程并行特征, 解决软件构架和构件的可用性问题。逆向工程侧重体现自底向上与增量迭代特征, 解决构架及构件的可重构性问题. 过程重构的基本内涵是, 概念重定义, 结构重说明, 算法重用, 系统重生成.

面向构件的建模支持机制

常用的构件化建模方法如, 面向对象方法及UML 描述,框架、实例及其规则描述, 巴科斯范式、谓词逻辑和体系结构描述语言(ADL >等形式化描述, Petri 网和导航图等可视化描述. 支持上述建模方法的典型机制如, 抽象类型, 元模式, 模板, 分布对象, 协作代理, 参数化框架, 导航图标, 软件总线, 以及设计词汇表. UML 描述提供了静态和动态两种建模机制. 在静态建模过程中, 可通过用例图来描述反映功能需求的领域模型,

通过类图、对象图和包图来描述面向对象的结构模型,

通过构件图和配置图来描述软件系统的实现模型. 在动态建模过程中, 可通过交互图、状态图和活动图来描述软件系统的行为模型。包括对象间的交互与协作,

对象的生命周期及状态转换, 事务处理及过程同步控制等.框架—规则—实例(称FR I>描述是智能建模方法的推广应用. 框架(Framework>是描述结构性问题的基本骨架, 是一组实体、关联和约束的集合.

规则(Rule>可用于定义实体与实例之间的结构组装或集成方法,

是结构中各类元素交互与连接映射的集合. 实例(Instance>是描述问题解决方案的例化模板, 是一组特定的结构类型和元素类型即表示值的集合. FR I描述特别适用于软件构架设计及动态生成. 其它建模机制的作用如, 巴科斯范式可用于概念模型的规范化描述,

谓词逻辑可用于说明构架和构件的约束条件,ADL 语言可定义软件体系结构的风格, Petri 网可描述工作流和事务处理的动态特性, 导航图可用于构件库的组织与管理. 设计词汇表可用于定义构件和连接件的类型。使得领域概念元素化, 功能分解原子化, 构件聚合结构化.

领域工程及分析方法

领域工程的基本思想

在信息系统中, 领域(Domain>是具有相似应用范畴与共性需求抽象的问题域, 或者是与共性目标关联的应用域. 对于一个信息化企业来说, 领域概念通常涉及该企业所具有的行业特征和经营活动特征。

如机械、电子、化工或商贸领域, 管理、设计或制造领域. 可见, 领域给定了一个信息系统的工程实施背景和研究对象. 领域工程则是面向构件的理念工程, 其核心思想是: 应用模式领域化, 问题抽象通用化, 软件元素重用化, 开发过程工程化.应用模式领域化是一种从特殊到一般的总体归类方法,它根据特定应用系统的概念特征作出相似目标定位和领域划分, 寻求规范的需求描述和一致的概念设计, 从而使单一应用系统按照概念趋同模式向领域概念框架演化.问题抽象通用化是一种具体的需求识别方法, 是实现领域归类的关键技术. 需求通用化是需求领域化的技术延伸, 并从概念层扩展到说明层. 通用化抽象需要严格区分需求的共性、相似性和变异性, 以形成类化的需求分割。把基本不变的问题抽象为共性模型, 把部分变化的问题抽象为相似模型,把频繁多变的问题抽象为变异模型.

共性模型和相似模型可用分类结构、继承机制及演化规则来统一描述。

变异模型可用代理结构、重载机制及例化规则来描述, 并提供用户自定义的工具支持. 通用化需要有抽象思维与分析高度, 没有抽象高度就没有问题通用性。这正是领域分析的特点和难点所在.软件元素重用化使通用化的问题域模型进一步向解域深化. 通用是重用的基础, 重用是通用的目的. 软件重用同样可体现在三个层次: 概念级重用, 如领域知识、开发经验、建模方法和文档资源的重用。逻辑级重用, 关键是软件体系结构重组和规则重用。物理级重用的实质是构件重用, 包括模板共享、类库共享、子程序和函数调用等. 重用方法的引用包括组合式和生成式, 前者针对已有构件库,

后者针对形式描述工具和元生成器.开发过程工程化是一种行为方法论,

它不仅考虑信息系统的技术行为, 而且考虑与技术实施相适应的组织行为. 工程化的典型模式是,

把并行工程、重构工程、协同方法和系统集成技术与现代软件工程相结合, 形成“工程—

工程—产品—产业”一体化发展的工程研究环境和开发环境.

领域分析方法及形式描述

领域分析的基本出发点是,

寻求研究对象领域内共性需求、共性特征和共性结构的一致性描述,

寻求具有可变特征或相似功能覆盖的事务处理和对象抽象, 以获得概念化的领域模型. 在领域建模过程中, 理顺领域知识的分类关系极为重要, 它是规范概念和实现概念级元素重用的基础. 分类是面向对象方法的结构抽象策略, 它使领域知识可按不同层次和不同关系来组织, 以利将概念结构转化为静态的逻辑结构. 下面以集成供应链管理(ISCM >软件的研究开发为例, 说明领域模型的建立问题. ISCM 系统是企业信息系统的一个子集, 它把电子商务与供应链管理功能集成在一起. 与这种应用模式相适应, 任何一个企业的领域需求首先可以抽象为 5 大类: 目标, 组织, 流程, 资源, 环境. 进一步的抽象处理是, 把目标及其任务分解到组织和流程中。再把组织中的职责与角色归入流程, 人员归入资源, 并通过工作流模式进行事务与数据融合. 经过二次抽象, 单个信息系统的领域需求可以归结为三要素, 即流程、资源和环境。它也是ISCM 软件的共性需求. 换句话说, 在IS2 CM 软件开发过程中, 可以用事务流模型及事务对象来描述流程结构, 用类树模型及数据来描述资源结构, 用角色模型及实体来描述环境关联. 按照领域知识获取与组织方法, 三要素模型均可用概念元和概念结构来表示, 两者共同组成领域模型. 概念元可用巴科斯范式(或设计词汇表>来定义, 概念结构可用UML 用例图(图 2>来定义.

现给出 ISCM 领域模型的一些关键描述. ISCM 系统∷= 领域需求目标模型

领域需求∷= (流程, 资源, 环境>

流程∷= {活动集, 关系集}

资源∷= {人员, 资金, 物料, 信息, 时间}

环境∷= {顾客, 供应商, 竞争者, 变因}

目标模型∷= (概念模型, 逻辑模型, 物理模型>

概念模型∷= {元知识集, 结构知识集}

逻辑模型∷= {软构架, 关联集, 规则集}

物理模型∷= {构件集, 实例集, 说明文档}

软件构架与构件设计方法

构架设计及形式化描述

在软件系统中, 构架(A rchitecture> 即软件体系结构。它是可预制和可重构的软件骨架, 是问题域模型转化为解域模型的框架式系统. 这里区分构架与框架, 即构架一般指解决问题的软件结构本身, 而框架则是用于描述各种系统结构的一种方法. 构架的典型实例如: 基于层次抽象程序解释执行与状态模拟的虚拟机结构. 根据实际应用需要, 上述单一软件结构可进一步组成多体系结构风格的分布计算系统, 如B S 与C S 集成体系结构. 框架则是可用于描述构架等总体结构的方法论体系. 框架的典型实例如, 采用巴科斯范式描述的概念结构, 采用类图描述的对象系统逻辑结构, 采用ADL 形式化描述的文本结构, 采用树型和网状拓扑描述的图形结构. 所以, 框架是研究构架的建模机制,

而构架可以是软件结构的框架描述.按照分布计算体系结构的思想,

任何一个应用软件的构架均可划分为三种构造逻辑:

一、界面表示逻辑, 用于覆盖与用户直接关联的前端应用。

二、事务处理逻辑, 体现软件的核心处理功能。

三、数据管理逻辑, 用于解决用户事务的数据交换和后端服务问题.

依据领域应用的复杂程度和系统平台的多线程能力, 事务逻辑可进一步细分, 形成多层应用体系结构。但它本质上仍是三层构架. 三层构架划分思想既有利于保证用户、应用程序和数据三者之间的相互独立性,

以提高软件的整体执行效率和构架重组性能。又与领域需求的三要素模型保持一致, 即用界面逻辑来覆盖环境需求, 用事务逻辑覆盖流程需求, 用数据逻辑覆盖资源需求.按照软件构架的逻辑构造思想,

每一种逻辑部件都可用特定功能的物理构件来实现。

而构件之间的相互连接及其组合规则与约束条件则构成一个完整的构架设计内容. 所以, 一个规范的软构架应由三要素组成: 构件(component>, 连接(connection> , 约束(constraint>。称3C 构架模型. 所对应的实现模式是, 基于对象的基本构件, 基于角色关联的连接及接口件, 基于规则和参数配置的约束集合, 基于实例与连接约束的构架集成. 这种构架设计模式可归纳为:软构架= 软芯片(构件>+ 软总线(连接> + 控制使能(约束>若采用网状结构来定义构架及其要素之间的事务关联,采用树型结构来定义构架生成过程中所引用的资源,

则一个通用的构架模型可用网状结构与树型结构的组合模式来描述, 并采用树网分层机制进行管理, 如图 3 所示.

图 3 中, 基本构件的定义可分为两类: 一是已存在的系统构件, 由系统平台及开发工具自身携带的构件库所提供, 主要完成较低层功能。二是新开发的领域构件, 主要提供应用领域的共性事务或特定事务处理功能, 提供高层次和大粒度的重用支持. 系统构件与领域构件之间可以相互演化, 并用构件库进行分类管理.

连接是构件间角色关联、交互协议、接口类型以及智能特性的逻辑描述,

其功能构造体便是连接件(connector>. 连接件亦可定义为两类: 一是数据通信接插件, 实例如消息、管道和事件广播。二是进程控制接插件, 实例如过程调用、事件触发和数据缓存.

约束用于定义构件或实例之间的组合方式、交互规则和集成方法,

是概念层、说明层和实现层所有语义转换与描述规范的集合.

规范、规则与约束条件的完备集称规约. 在进行构架生成时, 需要对构件和连接件进行实例化, 以便规约的引用. 实例化可分成直接例化和增量例化,前者按初始条件将相关构件直接例化为可通用的固定部件。后者按层次渐近例化思想, 把上层构件逐步例化为新的重用部件, 直至满足领域需求. 框架集成则把已实例化的构件按规约组装成可用构架.按图 3 框架展开, 一个完整的软件构架可形式化描述为:

构架∷= 构架模式构架模型

构架模式∷= (构架名, 类型说明>

构架类型∷= {指定风格的构件类型集}

构架模型∷= (构件, 连接。约束>

构件∷= (构件名, 对象集, 行为代理。接口>

对象集∷= {对象名(属性集, 行为集, 消息接口>}

行为代理∷= {角色名(责任, 权限, 交互方式>}

连接∷= (角色名, 关联集。映射方法>

关联集定义了连接类型

关联集∷= {泛化, 聚集, 依赖。串行, 并行, 回环}

约束∷= (结构规则, 行为规则, 语义说明>

结构规则∷= {满足条件的静态结构规则集}

行为规则∷= {满足条件的动态行为规则集}

构件模型设计及模板划分

构件是可预制和可重用的软件部件, 是组成构架的基本计算单元或数据储存单元, 是实现领域应用的功能封装体. 依据对领域知识的抽象程度和构造逻辑的划分需要, 可生成不同粒度级的构件元素。如对象, 二进制对象, 函数, 例程, 类库,数据包, 过滤器, 触发器等. 这些构件可以设计成模型和模板的形式, 并以源文件、二进制文件和可执行文件的形式存放.一个规范的构件设计也可引入三要素:

概念(Concept>,内容(Content>, 语境(Context>。称 3C 构件模型. 概念刻画了构件的概貌特征, 包括功能需求和数据存取的语义描述和接口说明. 内容是概念实现的软件体, 包括程序代码、脚本、设计文档和技术标准等. 语境即上下文, 用于刻画领域应用环境历定义的交互构件, 二是用作I O 信息交换的接口构件. 界面构件可覆盖领域应用的环境需求. 事务构件是领域构件设计的关键, 主要用于实现事务流程及处理活动。并可分解为通用事务和专用事务两个子类. 通用事务构件可解决泛化问题, 即完成基本不变或相似的事务处理任务。其中, 关键策略是实体或过程的参数化. 专用事务构件可解决特化问题, 即实现多变事务的实例化和用户自定义功能, 包括特定实体或过程的例化与重载. 按照可泛化或可特化事务抽象的程度, 一个构件功能可以对应一个原子事务, 也可覆盖一个事务流. 数据构件的提取与领域资源共享及数据存取服务模式有关, 可分为数据文件DF (含HTML 等文档>、数据库DB 和知识库 KB (含黑板系统>三个子类级. 以上是从静态的对象抽象的角度来识别构件. 若引入协同建模方法与多代理机制, 则可为构件模型增加动态交互能力。如设置热点和移动对象, 设置限次限时等条件触发响应, 嵌入隐式调用结构. 此外, 构件模型中必须引入接口定义机制, 主要包括IDL 和AP I两大接口描述支持.综上所述, 一个完整的领域应用构件集可以划分为三个大类七个子类。

每个大类或子类构件均可用一个模板来实现,构件模板是可规范化、可参数化和可实例化的模块语义结构或程序源代码. 体现上述构件设计思想的模板结构定义为:构件模板= (构件类型, 参数, 处理功能, 引用接口>这种基于功能类化和模板粒度划分的构件模型如图 4 所示.

图 4 的关键内涵在于:①通过设计与实现的分离, 把构件定义为模型和模板。模型描述构件结构, 模板描述构件算法.②通过实体与规约的分离, 例如交互构件与通信代理机制的分离, 大大提高了构件化建模效果与实现效果.③通过粒度分解, 把构件定义为原子级和组合级两大类。这样既降低了构件的设计难度和实现代价, 又提高了构件的重用性能和管理水准.

构架与构件的基本实现

领域构架生成方法

前已指出, 一个规范的软件构架可从模式(Pattern> 和模型 (M odel> 两个不同侧面展开, 并可用面向构件的关联网及资源树结构来实现. 按照这一设计原理, 与图 3 相吻合的领域构架动态生成过程可用图 5 表示.

在图 5 中, 领域构架的实现过程综合运用了六种软件系结构风格: 在静态结构表示方面, 采用类树来组织对象和中央资源, 包括类化的对象库、数据库和例程库, 这些分类库统一用构件库模式来管理。在动态结构生成方面, 采用关联网来组织构件或对象之间的组合(隐式显式> 调用过程和虚拟解释执行过程, 这种关联网是基于规则引用和构架重组的. 整个领域构架生成过程可按三段式递增过程展开:

①为系统平台或外部系统的公共对象提供直接的对象调用渠道, 包括IDL 引用定义或AP I包装定义, 以生成系统构件。这些系统构件是一组与具体领域无关的标准服务构件,可用于演化或组装领域构件.

这一过程可在一组给定的构架组合条件和构件选择条件下进行.

②根据给定的构件组合条件或领域需求说明, 调用相关的系统构件和领域对象, 并按照角色关联进行规则引用及方法映射, 以生成领域构件. 这一过程需要进行模型的一致性检验, 以消除语义冲突.

③根据领域框架的集成要求和具体应用的实例化要求, 调用相关的领域构件和应用例程, 或者对领域构件进行基于实例的演化。并根据框架、实例及其规则的完整性检验〔2〕, 最

终生成可用的领域构架.这一过程是最关键的, 需要进行静态检测和动态验证, 以消除语义冲突和结构冲突. 其中, 实例是应用例程模板化的结果。实例化则为构件演化和构架生成过程提供了相关支持机制, 如参数选择, 例程修改, 处理变换, 规则匹配, 约束检验, 以及实体或过程自定义等.

领域构件实现方法

如前所述, 一个规范的领域构件可从模型和模板(Tem2p late> 两个不同侧面展开。模型是逻辑设计的关键, 模板则是物理实现的关键. 从功能实现的角度讲, 模板是结构稳定、语义规范和具有派生能力的算法单元. 下面采用ADL 形式描述来定义一个典型事务构件模板

Component general_ transac

TransacTypeID ∷= GT

ObjectModel < object_ model_ description >

BehaviorAgents < behavior_ agent_ description >

Interfaces < interface_ declaration >

Constraints < constraint_ declaration >

object_ model_ descrip tion {

ObjectName∷= object_ name_ list ( n , object_ name >

A ttributes∷= < object_ name ( data_ solt_ interface > >

Behaviors∷= object_ name ( method_ solt >

method_ solt∷= solt_ name ( inheritance_ name , method_

nam e , p rocessing >

maps∷= role_ name ( role_ type , computation_ list >

M essageO rdering∷= "{" m sg_ name ( parameter_ list > "}" }

behavior_ agent_ descrip tion {

RoleName∷= role_ name_ list ( n , role_ name, role_ type >

role_ type∷= "{" m sg_ sender, m sg_ receiver "}"

Resposibilities∷= respons_ name ( action_ states , secure_

conditions >

Authorities∷= authority_ list ( authority_ level , resource_

list >

Interactives ∷= interactive_ list ( interactive_ fashion, role_

type > }

interface_ declaration {

in_ port ∷ = 2 role_ type w ith ( require_ list " &"

notification_

list >

out_ port ∷= + role_ type w ith ( require_ list "&" notifica

tion_ list > }

constraint_ declaration {

StructureConstraints structure_ constraint_ declaration

SemanticConstraints emantic_ constraint_ declaration

} End component general_ transac

结束语

文章引用典型的软件体系结构类型来描述面向构件方法的研究模型本身,

以展示构架与构件的建模思想和设计风范.所提出的概念、原理和方法,

在集成化电子商务与供应链管理软件开发过程中得到了深入应用, 并收到良好效果. 进一步的研究是, 给出面向构件方法学的理论框架和常用构架与构件实现的关键技术, 以从不同层次逐步完善面向构件的软件方法学体系.

基于构件组装的应用软件开发过程研究_叶俊民

收稿日期:2007-06-25;修回日期:2007-09-04 基金项目:湖北省自然科学基金资助项目(2007ABA034);华中师范大学科学技术研究基金资助项目(2006AA22) 作者简介:叶俊民(1965-),男,教授,博士,主要研究方向为高可信软件工程(j m yee @m ai.l https://www.wendangku.net/doc/8a9165806.html, .cn);陈卓(1986-),男,学士,主要研究方向为软件工程;雷志翔(1982-),男,硕士研究生,主要研究方向为软件工程;叶焰锋(1983-),男,硕士研究生,主要研究方向为软件工程;詹泽梅(1979-),女,硕士研究生,主要研究方向为软件工程. 基于构件组装的应用软件开发过程研究 * 叶俊民,陈 卓,雷志翔,叶焰锋,詹泽梅 (华中师范大学计算机科学系,武汉430079) 摘 要:基于构件的软件开发方法是目前一种流行的软件生产技术,其核心围绕着构件的开发与组装技术。但如何结合实际应用要求实施基于构件组装的软件开发过程是一个值得进一步研究的课题。为此,根据基于构件的软件组装技术的概念和原理,提出一种应用系统组装框架,从软件体系结构的角度研究了构件的开发与组装方法,并将这一技术应用到软件工程网络课堂教学系统的开发上。相关实践活动表明,提出的方法可有效地获得一个适应性强的应用系统。 关键词:构件;软件体系结构;构件组装;网络课堂教学系统 中图分类号:TP311 文献标志码:A 文章编号:1001-3695(2008)06-1736-03 R esearch on applicati on deve l opm ent process based on com ponen t compositi on Y E Jun -m i n ,CHEN Zhuo ,LE I Zh-i x iang ,Y E Y an -feng ,Z HAN Ze -m ei (D e pt .of C o mpu t er Sc i ence ,H uazhong N or ma l Un i v e rsit y,W uhan 430079,C hina ) Abstract :Soft ware devel op m en tm ethod based on co m ponents is a popular technol ogy on soft ware producti on ,the key i ssue i s development and co mposite technol ogy ,but how to comb i ne the practical app licati on calls for t he i n troduction of componen-t based compositi on i n the soft w are devel op m ent process is a s ubject of a f u rt her study This paper refered to the soft w are co m po -nent compositi on technol ogy concep ts and pri nci ples ,presented a fra m ework f or asse mb li ng appli cations ,and research devel op -m ent and co m pos i tion met hod for m soft ware arch i tect ure ,and t h i s technol ogy appli ed t o devel op i ng t he soft w are engineeri ng net work teachi ng cl assroo m syste m The resu lts show that thism ethod can be an effecti vem eans to obtai n a strong adaptab ilit y app licati on Key words :co m ponen;t soft ware architecture ;co m ponent composite ;net work teach i ng syste m 在当前信息化社会中,各行各业对应用软件的需求量越来越大,所需软件的规模和复杂度也不断增加。传统的 数据结构+算法=程序 设计模式已经无法满足不断增长、日趋复杂应用的需求,而庞大的软件系统在维护上也困难重重,人们不断地探索着这一危机的解决方法,基于构件的软件开发方法就是这一探索中的方法之一。基于构件的软件开发能有效地缩短开发周期,降低应用系统的开发成本,提高系统的可维护性。 目前国内外对构件组装技术的研究已取得一定成果。美国OM G 的CORBA 、M icroso ft 的COM 、S UN 的JavaBeans/EJB ;国内北京大学软件工程研究所的青鸟工程也已取得了很好成果。我国自主研发的 和欣 操作系统(英文名E l astos)就是使用构件技术开发的典型,创新性地实现了C AR (co m ponent assemb l y runti m e)构件技术,即一种完全面向下一代的网络服务。 在基于构件的软件开发中,构件的开发、构件组装及其开发过程是关键技术。目前,对于构件组装技术的应用基本上还停留在手工组装的阶段,半自动化甚至自动化的构件组装的实现还有待时日。 1 研究基础 构件是指是指可方便地插入到语言、工具、操作系统、网络软件系统中的一种接口定义良好的、独立可重用的二进制形式的代码和数据;而可复用构件是指具有相对独立的功能和可复用价值的构件[1]。1 1 构件的开发[2] 构件包括构件接口和构件规约两部分。构件接口是构件间的契约(图1)。一个接口提供一种服务,完成某种逻辑行为。构件接口包括名称部分和行为(图2)。前者是构件本身提供服务的描述;后者是构件行为的描述。一个构件可以有一个或多个接口,而构件接口可以由多个构件实现。构件接口是外部访问构件的访问点。构件规约是构件开发商向构件使用者提供的、用于进行构件组装的文档。 从上述构件的定义可以看出,构件的开发涉及两个方面:设计构件接口和实现构件的行为。众所周知,接口是构件描述其行为的机制,并且提供了对其所提供服务的访问。由于实现是完全隐蔽的,接口描述就成为构件的潜在客户所能依赖的所有信息。这使得接口描述的表达力和完整性在任何基于构件 第25卷第6期2008年6月 计算机应用研究Application R esearc h of C o m puters Vo.l 25,N o .6 Jun .2008

基于组件的嵌入式软件开发方法

基于组件的嵌入式软件开发方法研究 郑久寿 夏德天 何小亚 (中国航空计算技术研究所 十室 陕西 西安 710068) 摘 要: 为提高嵌入式系统软件的通用性和重用性,缩短同类软件的开发周期,从嵌入式系统的特点出发,提出一种基于可重用组件的嵌入式软件开发方法。首先介绍组件的基本概念,然后着重阐述嵌入式系统组件划分方法及设计具体组件接口的一般原则。最后通过对比传统嵌入式系统和基于组件的嵌入式系统软件开发方法的异同,提炼出基于组件的嵌入式软件开发方法的特点。具体项目实践证明该方法的可行性,具有良好的应用前景。 关键词: 嵌入式系统;软件重用;组件;接口设计 中图分类号:TP311 文献标识码:A 文章编号:1671-7597(2012)1120094-02 EJB,COM/DCOM,ActiveX,Web Services等形式存在的可运行 0 引言 二进制程序,也包括经过封装的源代码程序。从广义上来说,目前嵌入式电子产品发展日新月异,更新换代很快,软件 随着对软件重用理解的不断深入,软件组件概念的外延在不断代码量和复杂度随着功能的复杂性呈几何级的增加。在这种情 扩展,从组件实体到规格需求、系统架构、设计文档、测试用况下,传统的基于先前基础代码进行二次开发变的愈发困难。 例等各种具有重用价值的软件资源都是组件的组成部分。 倘若原来程序员离去,其他人员或新手修改源程序则变的愈加 2 嵌入式系统组件架构 困难和不可控。另外由于绝大多数程序内部结构之间相互耦 合,即使只对源代码的很小一部分进行修改,为了保证产品的根据IEEE的定义,嵌入式系统是“控制、监视或者辅助装质量,也应该对整个产品的源代码进行回归测试。在这种开发置、机器和设备运行的装置”,从中可以看出嵌入式系统是软模式下,程序的可重用性低,整个产品的软件开发和测试周期件和硬件的综合体。另外由于嵌入式系统涉及的领域很广,各长,软件成本高。因此寻求一种新的可重用可扩展的软件开发个不同领域的应用往往差别很大。因此不同领域应该针对本领 方法是解决这些问题的根本途径。域特定应针对这些问题,本文从嵌入式软件开发的特点和需求出 发,提出了一种新的基于可重用组件的软件开发方法,并在实 践中取得了较好的效果。 1 组件概述 软件组件(Component)的概念共生于软件重用。早在 1968年,在北大西洋公约组织(NATO)会议上就提出了软件重 用的概念,后来还为此制定了一整套软件重用的指导性标准, 其中包含了利用标准组件实现软件重用的基本思路。也是在这 次会议上,Mcllroy提出了软件组件、组件工厂等概念[1]。 基于组件的软件重用是产品重用的主要形式,软件组件技 术是当前重用研究的焦点。组件技术的基本思想在于,创建和 利用可重用的软件组件来解决应用软件的开发问题。与面向对 象编程语言不同,组件技术是一种更高层次的对象技术。它独 立于语言,只面向应用程序,只规定组件的外在表现,而不关 心其实现方法。 目前关于组件还没有一个统一的定义,以下是关于组件的 一些有代表性的观点[2]: 1)组件是一个独立的可传递的操作的集合; 2)组件是由对象类组合起来的物理意义上的包; 3)组件是软件开发过程中一个可替换的软件单元,它封 装了设计决策,并作为一个大单元的一部分和其他组件组合起 来; 4)组件是具有特定功能,能够跨越进程的边界实现网 络、语言、应用程序、开发工具和操作系统的“即插即用”的 独立对象; 5)组件是指应用系统中可以明确辨识的构成成分。而可 重用组件是指具有相对独立的功能和可重用价值的组件。 关于组件的定义可以从狭义和广义两方面来理解。从狭义 上来说,软件组件是指软件系统中具有相对独立功能、可以明 确辨识、接口由契约指定、和语境有明显依赖关系、可独立部 署、且多由第三方提供的可组装的软件实体。它既包括以用来开发组件,应用组件构建自己的应用系统。开发 出来的组件可以在本领域的不同型号产品间广泛重用。本文选取温度控制器作为应用对象来进行说明基于组件的嵌入式软件开发方法。所谓的温度控制器简单来说就是在暖通系统中通过控制压缩机的开关来达到精确控制温度的装置。具体来说,温度控制器定期测量环境温度,通过其温度算法将环境温度和该时间段的设定温度进行对比决定何时应开启或关闭压缩机使环境温度能迅速而平缓的达到设定温度而又不会产生温度的过冲,始终给用户舒适的感受。用户在任何时候也可对实时时钟和各个不同的时间段的温度设置点进行编辑或设定,并使其应用到温度算法中。另外点式或段式显示屏可以给用户显示环境温度、设定温度、时钟信息、电源状态等信息。 组件是软件系统中具有相对独立功能的软件实体,合理的划分组件,有利于组件的复用和实现,以及系统的配置管理。组件粒度越大,其复用程度就越高,但实现和理解组件就相对困难,重用难度加大;粒度越小,组件越易于复用,但管理组件等代价将增大,甚至大于复用带来的好处。划分组件时应从功能模块的完整性、高内聚和低耦合性等方面出发。依据重用原则、闭包原则、单人组件原则、消息传递原则[3],将通用温控器组件划分如图1所示(虚线框内为可重用组件)。 图1 组件架构 3 嵌入式组件接口设计 组件划分后需要进行接口设计,它是组件设计的重要部分。一个组件接口是一组逻辑上相互关联的操作,这些操作定 义了某类公共行为。接口是一组操作的规范,而非任何特定的

面向构件的软件设计

面向构件的软件设计 9.1 术语、概念 1、构件 构件的特征如下: 独立部署单元。 作为第三方的组装单元。 没有(外部的)可见状态。 独立可部署,意味着必须能跟他所在的环境及其他构件完全分离。 原子性,构件不但必须具备足够好的内聚性,还必须将自己的依赖条件和所提供的服务说明清楚。 缓存具有这样的特征:当它被清空时,除了可能会降低性能以外,没有其它后果。 构建本质上没有状态,同一操作系统进程中装载多个构件的拷贝是毫无意义的,至多会存在一个特定构件的拷贝。 许多系统中,构建被实现为大粒度的单元,工资管理服务程序就是一个构件,工资数据只是实例(对象),将不易变的“模型”和易变的“实例”分离的做法避免了大量的维护问题。 2、对象 对象的特征如下: 一个实例单元,具有唯一的标志。 可能具有状态,此状态外部可见。 封装了自己的状态和行为。 显式存在的实例化方案称为类,也有隐式的实例化方案,既通过克隆一个已存在的对象来实现,即原型对象。 新生的对象都必须被设置一个初始状态,创建与初始化对象的代码可以是一个静态过程——类的一部分,称为构造函数。 如果这个对象是专门用来创建与初始化对象的,称为工厂。

对象中专门用来返回其他新创建的对象的方法称为工厂方法。 3、构件与对象 构件通常包含了若干类或不可更改的原型对象。还包括一系列对象。 但构件并非一定要包含类元素,它甚至可以不包含类,可以拥有传统过程体,甚至全局变量。 构件创建的对象——更确切地说是对这些对象的引用——可以与该构件分离开来,并对构件的客户可见。构件的客户通常是指其他构件。 一个构件可以包含多个类元素,但是一个类元素只能属于一个构建。将一个类拆分进行部署通常没有什么意义。 4、模块 模块化方法成熟的标志是其对分离编译技术的支持,包括跨模块的正确的类型检查能力。 模块没有实例化的概念,在任何情况下,模块都可以包含多个类。类之间的继承关系并不受模块界限的限制。 模块本身就可以作为一个最简单的构件,这些库是功能性的,而不是面向对象的。 资源可以参数化一个构件,重新配置该构件而无需更改构件代码,例如,本地化设置可以通过资源配置实现。 某些情况下,模块并不适合作为构件,构件没有外部可见的状态,但是模块却可以显式地用全局变量来使其状态可见。 5、白盒抽象、黑盒抽象与重用白盒抽象中,可以通过继承对构件的实现细节进行修改,白盒方式中实现细节对外界是完全可见的。 绝大多数系统中,(Application Programming Interface,API)相当于黑盒重用这些接口的实现。白盒重用不可以轻易地被另外的软件替换,因为依赖于细节。 软件构件是一种组装单元,它具有规范的接口规约和显式的语境依赖,软件构件可以被独立地部署并由第三方任意地组装。 6、接口 接口是一个已命名的一组操作集合。

面向对象软件开发教程

软件是在代码之外发生的一切事情。 如何继续学习过程 你将从本章学到什么? 两千年后(P2K)的软件环境是什么样的? P2K软件环境中的技术和技能是什么?有关P2K技能和技术有哪些概述性的资源?软件专家在面向对象项目中充当什么角色/职位? 如何继续面向对象的学习过程? 为什么需要阅读本章? 你的技能,以及如何使用它们,是能否成为成功的软件专家的重要决定性因素。通过阅读本书,你会获得学习对象技术和技巧所需的基本知识,本章也给你提供了继续进一步学习过程的建议。 至此,你已经了解了面向对象的全部内容,现在你已经是一名准备开发大型、关键性任务软件的对象专家。好吧,现在你还不全是。实际上,你已经掌握了一些有用的概念和技能,也明白了它们如何一起使用,在浏览复习题以及案例学习的过程中,你已经使用了它们。目前你正处在有利地位,可以继续你的学习过程,这个过程将很可能贯穿你的整个职业生涯。本章给出了对软件业目前的状况以及将来的发展方向的见解,在接下来的几年中将会需要什么样的技能,要如何才能获得这些技能。 11.1 P2K 环境 在你的整个职业生涯中一直要学习新的技能。 软件业在20世纪90年代后半期被Y2K危机严重影响了,新的开发被耽搁下来或者干脆取消,以转移资源解决Y2K危机,结果,许多企业都推迟了对采用新的技术和技能的投资。现在 Y2K危机已经过去了,我们正面对着两千年后(P2K)的软件环境,一个使用本书中描述的技术支配的环境。 在P2K环境中,你将会应用新的方法,例如面向对象的和基于组件的方法,采用迭代和增 量方法的新的开发过程,像Java和CORBA这样新的技术,以及像用况建模这样新的技术。本 书概述了对象开发技术,本节也总结了用于P2K环境的关键技术和技能。要理解P2K环境, 必需考虑下面几项内容:

软件开发方法与过程

(1)软件开发过程是什么? 软件开发过程是按照软件工业化的标准定义的心之所向,所向披靡 ?在软件开发中必须具有的一系列过程规范; ?软件开发过程是定义在软件中的软件需求、软件设计、软件编码、软件测试、软件部署的实现目标和规范化的管理方法论; ?软件开发过程是保证软件工业化生产的法典;?软件开发过程做的是:定义标准和为了达到标准的路; ?软件开发过程要改善的是:软件开发的效率和质量; ?软件开发过程的实现最重要的是:人。 (2)大多数软件项目失败的原因: a)不完整、不现实的项目需求 b)对需求的变更束手无策 c)脆弱的架构 d)采用不成熟的技术 e)测试的不充分性 f)拙劣的进度计划和评估 g)缺乏资源 h)不具备项目管理方法 i)缺少管理层的支持 (3)软件工程的三个要素:方法、工具和过程(4)A software project failed if It is delivered late It is runs over the budget It does not satisfy the customer’s need It is of poor quality Classical software development methods have not solved software crisis.传统的软件开发方法没有能够解决软件危机。 (5)A software engineer’s job: a)Make a working plan.制定工作计划 b)Carry out it.(Do their work according to this plan)按照此计划工作 c)Try his/her best to produce high-quality products.尽最大努力生产 出高质量产品 (6)3 Key aspects a)Quality products 高质量产品 b)Expected costs c)On agreed schedule (7)Summary of PSP PSP is a framework designed to teach software engineers to do better work Estimate and plan →track →improve quality Quality methods take time to learn and practice,but it will help you in you engineering career Establish goals →measure quality → understand the process → change and reure process → measure & analyze the results → recycle improving Identify the tasks you do (8)敏捷软件开发宣言 个体和交互胜过过程和工具 可以做到工具的软件胜过面面俱到的文档 客户合作胜过合同谈判 响应变化胜过遵循计划 敏捷开发的原则: 1、我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。 尽早交付具有部分功能的系统和质量系统之间具有很强的相关性 2、即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。 关于态度的声明,敏捷过程的参与者不惧怕变化,努力保持软件结构的灵活性。 3、经常性地交付可以工作的软件,交付的间隔可以从几周到几个月,交付的时间越短越好。 关注的目标是交付满足客户需要的东西。它们是敏捷实践区别其他过程的特征所在。 4、在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。 有意义的、频繁的交互,必须对软件项目进行持续不断地引导。 5、围绕被激励起来的个人来构建项目。给他们提供所需要的环境和支持,并且信任他们能够完成工作。 人被认为是项目取得成功的最重要的因素。 6、在团队内部,最具有效果并且富有效率的传递信息的方法就是面对面的交谈。首要的、默认的沟通方式。 7、工作的软件是首要的进度度量标准。 敏捷项目通过度量当前软件满足客户需求的数量来度量开发速度。 8、敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期、恒定的开发速度。不是 50米短跑,而是马拉松。以快速但是可持续的速度行进。 9、不断关注优秀的技能和好的设计会增强敏捷能力。

软件体系结构作业完整版

第一章: 1.根据自己的经验,谈谈对软件危机的看法。 软件危机是指软件生产方式无法满足迅速增长的计算机需求,开发和维护过程出现的一系列问题。 以下几个原因导致:(1)软件自身特点 (2)开发人员的弱点 (3)用户需求不明 (4)缺乏正确理论指导 (5)开发规模越来越大 (6)开发复杂度越来越高 可以通过软件生命周期的模型和软件工具的使用来缓解危机,通过程序自动化和软件工业化生产的方法实现软件标准化的目标,进一步缓解软件危机带来的影响。 软件危机有利有弊,除了带来许多麻烦,也给我们带来许多挑战,克服危机的过程,我们在技术上和创新上都有了一个提升,也算是间接为软件产业的发展做了贡献。 2.什么是软件重用,软件重用的层次可以分为哪几个级别? 软件重用:是指在两次或多次不同的软件开发过程中重复使用相同或相似软件元素的过程。可以分为三个层次: (1)代码重用(2)设计结果重用(3)分析结果重用 3.什么是可重用构件?相对于普通的软件产品,对可重用构件有何特殊要求? 可充用构件表示软件重用过程中,可重用的软件构件元素。 可重用构件的特殊要求: (1)可重用构件应该具有功能上的独立性与完整性; (2)可重用构件应该具有较高的通用性; (3)可重用构件应该具有较高的灵活; (4)可重用构件应该具有严格的质量保证; (5)可重用构件应该具有较高的标准化程。 4.基于构件的软件开发的优势是什么?基于构件的软件开发面临哪些挑战和困难? 优势:基于构件的软件将软件开发的重点从程序编写转移到了基于已有构件的组装,更快地构造系统,减轻用来支持和升级大型系统所需要的维护负担,从而降低了软件开发的费用困难和挑战:没有可依据的参考,可用资源和环境缺乏,开发难度高,而各方面需求增长速度与日剧增,更新和升级的跟进是一个不小的挑战.此外,在同一系统采用多个开发商提供的构件,它 们之间的兼容性可能是开发过程中所要面对的一个严峻的问题 挑战和困难: (1)在同一系统采用多个开发商提供的构件,它们之间的兼容性可能是开发过程中所要面对的一个严峻的问题; (2)采用随处可以购买到的构件可能会使开发出来的软件产品丧失技术上的独创性和市场上的竞争力; (3)第三方的构件开发商可能歇业,这会使购买的构件失去维护服务。这些都是在购买第三方构件进行软件开发时无法回避的问题,因此需要对这些风险进行充分的估计。 5.简述3种应用最为广泛的构件技术规范COM、CORBA和EJB的各自特点。 CORBA的特点: (1)实现客户与服务对象的完全分开,客户不需要了解服务对象的实现过程以及具体位置。 (2)应用程序间的统一接口。

基于构件的软件复用技术研究与应用实践

基于构件的软件复用技术研究与应用实践 基于构件的软件复用技术研究 谷今杰莫继红 ((湖南大学软件学院,长沙410082) 通常情况下.应用软件系统的开发过程包含以下几个阶段:需求分析、设计、编码、测试、维护等。当每个应用系统的开发都是从头开始时,在系统开发过程中就必然存在大量的重复劳动,如:用户需求获取的重复、需求分析、编码、测试的重复和文档等。探讨应用系统的本质,发现其中通常包含:①通用基本构件:是特定于计算机系统的构成成分,如基本的数据结构、用户界面元素等,它们可以存在于各种应用系统中;②领域共性构件:是应用系统所属领域的共性构成成分,它们存在于该领域的各个应用系统中;③应用专用构件:是每个应用系统的特有构成成分。应用系统开发中重复劳动主要在于前两类构成成分的重复开发。 软件复用是在软件开发中避免重复劳动的解决方案。其出发点是应用系统的开发不再采用一切“从零开始”的模式,而是以已有的工作为基础,充分利用过去应用系统开发中积累的知识和经验,如:需求分析结果、设计方案、源代码、测试计划及测试案例等.从而将开发的重点集中于应用的特有构成成分。 通过软件复用,在应用系统开发中可以充分利用已有的开发成果.消除了包括分析、设计、编码、测试等在内的许多重复劳动,从而提高了软件开发的效率:同时,通过复用高质量的已有开发成果时,避免了重新开发可能引入的错误,从而提高软件的质量。 软件复用指重复使用“为了复用目的而设计的软件”的过程。相应地,可复用软件是指为了复用目的而设计的软件。与软件复用的概念相关,重复使用软件的行为还可能是重复使用“并非为了复用目的而设计的软件”的过程,或在一个应用系统中的不同版本间重复使用代码的过程,这两类行为都不属于严格意义上的软件复用。真正的复用是为了支持软件,使用“为复用而开发的软件(构件)”来更快、更好地开发新的应用系统。 复用技术在整体上对软件产业的影响却并不尽如意。这是由于技术方面和非技术方面的种种因素造成的,其中技术上的不成熟是一个主要原因。近十几年来,面向对象技术出现并逐步成为主流技术,为软件复用提供了基本的技术支持。软件复用研究重新成为热点。被视为解决软件危机。提高软件生产效率和质量的现实可行途径。 (复用分类)软件复用可以从多个角度进行考察。依据复用的对象,可以将软件复用分为产品复用和过程复用。产品复用指复用已有的软件构件.通过构件集成(组装)得到新系统。过程复用指复用已有的软件开发过程.使用可复用的应用生成器来自动或半自动地生成所需系统。过程复用依赖于软件自动化技术的发展,目前只适应于一些特殊的应用领域。产品复用是目前现实的、主流的途径。 依据对可复用信息进行复用的方式。可以将软件复用区分为黑盒(Black—box)复用和白盒(White—box)复用。黑盒复用指对已有构件不需作任何修改,直接进行复用。这是理想的复用方式。白盒复用指已有构件并不能完全符合用户的需求。需要根据用户需求进行适应性修改后才使用。而在大多数应用的组装过程中,构件适应性修改是必需的。 软件复用按抽象程度的高低, 可以划分为如下的复用级别: (1) 代码的复用, 包括目标代码和源代码的复用。当前大部分编程语言的运行支持系统都提供了连接(L ink) 、绑定(Binding) 等功能来支持这种复用; ( 2) 设计的复用, 设计结果比源程序的抽象级别更高, 因此它的复用受到实现环境的影响较少, 从而使可复用构件被复用的机会更多, 并且所需的修改更少; (3) 分析的 复用, 可复用的分析成分是针对问题域的某些事物(问题) 的抽象程度更高的解法。

软件开发方法述评

软件开发方法述评 发信人:Joaquin(maverick),信区:SoftEng 标题:软件开发方法评述 发信站:BBS水木清华站(TueNov1821:18:341997) 60年代中期开始爆发了众所周知的软件危机。为了克服这一危机,在1968、1969年连续召开的两次著名的NATO会议上提出了软件工程这一术语,并在以后不断发展、完善。与此同时,软件研究人员也在不断探索新的软件开发方法。至今已形成八类软件开发方法。 一、Parnas方法 最早的软件开发方法是由D.Parnas在1972年提出的。由于当时软件在可维护性和可靠性方面存在着严重问题,因此Parnas提出的方法是针对这两个问题的。首先,Parnas提出了信息隐蔽原则:在概要设计时列出将来可能发生变化的因素,并在模块划分时将这些因素放到个别模块的内部。这样,在将来由于这些因素变化而需修改软件时,只需修改这些个别的模块,其它模块不受影响。信息隐蔽技术不仅提高了软件的可维护性,而且也避免了错误的蔓延,改善了软件的可靠性。现在信息隐蔽原则已成为软件工程学中的一条重要原则。 Parnas提出的第二条原则是在软件设计时应对可能发生的种种意外故障采取措施。软件是很脆弱的,很可能因为一个微小的错误而引发严重的事故,所以必须加强防范。如在分配使用设备前,应该取设备状态字,检查设备是否正常。此外,模块之间也要加强检查,防止错误蔓延。 Parnas对软件开发提出了深刻的见解。遗憾的是,他没有给出明确的工作流程。所以这一方法不能独立使用,只能作为其它方法的补充。 二、 SASA方法 1978年,E.Yourdon和L.L.Constantine提出了结构化方法,即SASD方法,也可称为面向功能的软件开发方法或面向数据流的软件开发方法。1979年TomDeMarco对此方法作了进一步的完善。 Yourdon方法是80年代使用最广泛的软件开发方法。它首先用结构化分析(SA)对软件进行需求分析,然后用结构化设计(SD)方法进行总体设计,最后是结构化编程(SP)。这一方法不仅开发步骤明确,SA、SD、SP相辅相成,一气呵成,而且给出了两类典型的软件结构(变换型和事务型),便于参照,使软件开发的成功率大大提高,从而深受软件开发人员的青睐。 三、面向数据结构的软件开发方法 Jackson方法

快速原型方法与软件开发中的风险管理

快速原型方法与软件开发中的风险管理 软件系统往往体现一定的功能,这些功能要符合一定的使用目的。现实世界是在不断变化的,而且变化的速度是越来越快,唯一不变的就是“变化”的主题。这一现实也就直接影响到了实现实际功能的软件系统,体现在需求、技术实现手段、应用环境等多个方面,这些都直接影响到了软件系统自身的稳定性。同时,由于快速变化这一事实,人们对于以后的预测能力也越来越有限,有时根本难以明确未来的需求,只能是根据环境的变化而随时调整,因此直接导致了软件生命周期越来越短这一现实,特别是应用软件,直接与这种变化紧密相连。 但是,软件开发往往需要一定的时间,一个软件系统从需求、设计、开发到投入使用,这一周期都不会很短,即从需求产生到实际能够投入使用这段时间,其本身就已经成为应用软件自身的风险,很可能当一个软件开发完成的时候,市场需求已经发生了变化,开发出来的软件已经不适用了。软件生命周期已经缩短,特别是应用软件,随着新业务的市场窗口变窄的趋势,其自身的寿命周期也在缩短。快速投放市场已经成为软件系统的首要因素。另一方面,由于快速变化的外部环境给软件产品带来的风险,成本控制也成为软件工程管理的一个重要方面,通过对需求变化的风险的评估来重新认识软件寿命周期,以合理的成本完成软件开发,也已经成为对软件产品管理者的一个挑战。 在传统的软件工程方法中,主要使用瀑布式顺序开发方法,包括需求分析和定义、系统设计、实现和单元测试、系统集成测试、运行维护等多个阶段,这一方法的优点是全面、严谨,但最大的缺陷,就是过程一旦启动就难以适

应变化。这一方法是基于一个重要的假设前提——能够提出明确的需求。当面对快速变化、甚至是根本不明确的需求时,这种假设根本上就不成立,因此这种传统的开发方法的缺点就越来越突出,特别是应用软件的开发,由于它与市场的联系更加紧密,使用这种传统的开发方法,已经难以为继。我们需要寻找一种更加快速、成本合理的软件开发方法。 快速原型方法就是这样一种开发更加迅速、更加成本合理的开发方法。在软件开发过程中,最关键的步骤就是确切定义出需求,明确软件要实现的功能是什么,而这恰恰也是最困难的过程,因为现在许多用户在初期只有一个隐约的、大致的考虑,根本不可能提出具体明确的需求。这种情况下,使用快速原型进行反复交流、细化需求,就成为一种更加有效的方法。一个软件的原型,主要是模拟重要的功能和界面,但是一般不考虑运行效率,也不考虑系统的健壮性,出错处理也考虑不多,它的目的只是为了实际描述概念中的结构,使用户能够检测与其概念的一致性和概念的可用性。 目前主要有两种快速原型方法: ·丢弃原型(Throw-away prototyping)。其目标只是为了明确需求,使用最简单的开发方法,以最低的成本实现一个可工作的系统,该系统只关注功能,不考虑开发工具、性能、容错、未来实际运行环境等。通过反复与客户交流和修改原型,使原型的功能能够充分体现客户需求。在明确了需求之后,原型就会被丢弃。以后软件的开发将根据明确了的需求按照传统的工程化方法来开发。 ·进化原型(Evolutionary prototyping)。其目标就是与客户一起工作,从一个原始的需求的轮廓开始,逐步改进,最终发展成为符合实际需要的系

面向对象的软件开发方法简介

1面向对象的软件开发方法简介 面向对象的开发方法把软件系统看成各种对象的集合,对象就是最小的子系统,一组相关的对象能够组合成更复杂的子系统。面向对象的开发方法具有以下优点。 ●把软件系统看成是各种对象的集合,这更接近人类的思维方式。 ●软件需求的变动往往是功能的变动,而功能的执行者——对象一般不会有大的变 换。这使得按照对象设计出来的系统结构比较稳定。 ●对象包括属性(数据)和行为(方法),对象把数据和方法的具体实现方式一起封 装起来,这使得方法和与之相关的数据不再分离,提高了每个子系统的相对独立性, 从而提高了软件的可维护性。 ●支持封装,抽象,继承和多态,提高了软件的可重用性,可维护性和可扩展性。 1.1 对象模型 在面向对象的分析和设计阶段,致力于建立模拟问题领域的对象模型。建立对象模型既包括自底向上的抽象过程,也包括自顶向下的分解过程。 1.自底向上的抽象 建立对象模型的第一步是从问题领域的陈述入手。分析需求的过程与对象模型的形成过程一致,开发人员与用户交谈是从用户熟悉的问题领域中的事物(具体实例)开始的,这就使用户和开发人员之间有了共同语言,使得开发人员能够彻底搞清用户需求,然后再建立正确的对象模型。开发人员需要进行以下自底向上的抽象思维。 ●把问题领域中的事物抽象为具有特定属性和行为的对象。 ●把具有相同属性和行为的对象抽象为类。 ●若多个类之间存在一些共性(具有相同属性和行为),把这些共性抽象到父类中。 再自底向上的抽象过程中,为了使子类能更好的继承父类的属性和行为,可能需要自顶向下的修改,从而使整个类体系更加合理。由于这类体系的构造是从具体到抽象,再从抽象到具体,符合人们的思维规律,因此能够更快,更方便的完成任务。 2.自顶向下的分解 再建立对象模型的过程中,也包括自顶向下的分解。例如对于计算机系统,首先识别出主机对象,显示器对象,键盘对象和打印机对象等。接着对这些对象再进一步分解,例如主机对象有处理器对象,内存对象,硬盘对象和主板对象组成。系统的进一步分解因有具体的对象为依据,所以分解过程比较明确,而且也相对容易。因此面向对象建模也具有自顶向下开发方法的优点,既能有效的控制系统的复杂性,又能同时避免结构化开发方法中功能分解的困难和不确定性。 1.1.2UML:可视化建模语言 面向对象的分析与设计方法,在20世纪80年代末至90年代中发展到一个高潮。但是,诸多流派在思想和术语上有很多不同的提法,对术语和概念的运用也各不相同,统一是继续发展的必然趋势。需要有一种统一的符号来描述在软件分析和设计阶段勾画出来的对象模型,UML(Unified Modeling Language,统一建模语言)应运而生。UML是一种定义良好,易于表达,功能强大且普遍适用的可视化建模语言。而采用UML语言的可视化建模工具是Rational 公司开发的Rational Rose。 1.2 面向对象开发中的核心思想和概念 在面向对象的软件开发过程中,开发者的主要任务就是先建立模拟问题领域的对象模型,然后通过程序代码来实现对象模型,如何用程序代码来实现对象模型,并且保证软件系统的可重用性,可扩展性和可维护性呢?本节节主要阐述面向对象开发的核心思想和概念,这些核心思想为从事面向对象的软件开发实践提供理论武器。

软件开发中的快速原型法

快速原型法(rapid prototyping) 快速原型法是近年来提出的一种以计算机为基础的系统开发方法,它首先构造一个功能简单的原型系统,然后通过对原型系统逐步求精,不断扩充完善得到最终的软件系统。原型就是模型,而原型系统就是应用系统的模型。它是待构筑的实际系统的缩小比例模型,但是保留了实际系统的大部分性能。这个模型可在运行中被检查、测试、修改,直到它的性能达到用户需求为止。因而这个工作模型很快就能转换成原样的目标系统。 原型法有三个层次 第一层包括联机的屏幕活动,这一层的目的是确定屏幕及报表的版式和内容、屏幕活动的顺序及屏幕排版的方法; 第二层是第一层的扩展,引用了数据库的交互作用及数据操作,这一层的主要目的是论证系统关键区域的操作,用户可以输入成组的事务数据,执行这些数据的模拟过程,包括出错处理; 第三层是系统的工作模型,它是系统的一个子集,其中应用的逻辑事务及数据库的交互作用可以用实际数据来操作,这一层的目的是开发一个模型,使其发展成为最终的系统规模。 原型法的主要优点在于它是一种支持用户的方法,使得用户在系统生存周期的设计阶段起到积极的作用;它能减少系统开发的风险,特别是在大型项目的开发中,由于对项目需求的分析难以一次完成,应用原型法效果更为明显。原型法的概念既适用于系统的重新开发,也适用于对系统的修改;原型法不局限于仅对开发项目中的计算机方面进行设计,第三层原型法是用于制作系统的工作模型的。快速原型法要取得成功,要求有象第四代语言(4GL)这样的良好开发环境/工具的支持。原型法可以与传统的生命周期方法相结合使用,这样会扩大用户参与需求分析、初步设计及详细设计等阶段的活动,加深对系统的理解。近年来,快速原型法的思想也被应用于产品的开发活动中。 快速原型方法与开发的风险管理 软件系统往往体现一定的功能,这些功能要符合一定的使用目的。现实世界是在不断变化的,而且变化的速度是越来越快,唯一不变的就是“变化”的主题。这一现实也就直接影响到了实现实际功能的软件系统,体现在需求、技术实现手段、应用环境等多个方面,这些都直接影响到了软件系统自身的稳定性。同时,由于快速变化这一事实,人们对于以后的预测能力也越来越有限,有时根本难以明确未来的需求,只能是根据环境的变化而随时调整,因此直接导致了软件生命周期越来越短这一现实,特别是应用软件,直接与这种变化紧密相

软件工程习题1传统方法

一.选择和判断 软件工程概述 1、软件的主要特性是() A、无形性 B、高成本 C、包括程序和文档 D、可独立构成计算机系统 2、软件工程三要素是() A、技术、方法和工具 B、方法、工具和过程 C、方法、对象和类 D、过程、模型、方法 3、包含风险分析的软件工程模型是() A、螺旋模型 B、瀑布模型 C、增量模型 D、喷泉模型 4、软件的生命周期的阶段包括() A、软件需求 B、软件设计 C、风险分析 D、软件实现 5、下列属于面向对象开发方法的是() A、Booch B、UML C、Coad D、OMT 6、软件危机的主要表现是() A、软件成本太高 B、软件产品的质量低劣 C、软件开发人员明显不足 D、软件生产率低下 7、软件开发方法的主要工作模型有() A、螺旋模型 B、喷泉模型 C、瀑布模型 D、专家模型 8、软件工程的目标有() A、易于维护 B、低的开发成本 C、高性能 D、短的开发期 9、软件工程学的目的和意义是() A、应用科学的方法和工程化的规范管理来指导软件开发。 B、克服软件危机。 C、作好软件开发的培训工作。 D、以较低的成本开发出高质量的软件。 10、软件就是程序,编写软件就是编写程序。() 11、瀑布模型的最大优点是将软件开发的各个阶段划分得十分清晰。() 12、结构化方法的工作模型是使用螺旋模型进行开发的。() 13、结构化方法和JSP方法都不适合于大型软件的开发。()

14、原型化开发方法包括生成原型和实现原型两个步骤。() 15、面向对象的开发方法包括面向对象的分析、面向对象的设计和面向对象的程序设计。 () 16、软件危机的主要表现是软件的需求量迅速增加,软件价格上升。() 17、软件工具的作用是为了延长软件产品的寿命。() 18、软件工程过程应该以软件设计为中心,关键是编写程序。() 19、RCP法与RSP法的主要区别是前者采用循环渐进的开发方式,原型将成为最终的产品, 而后者将被废弃。() 需求分析 1、需求分析的主要目的是() A、系统开发的具体方案 B、进一步确定用户的需求 C、解决系统是“做什么的问题” D、解决系统是“如何做的问题” 2、需求分析的主要方法有() A、形式化分析方法 B、PAD图描述 C、结构化分析(SA)方法 D、OOA法 3、面向对象的分析方法主要是建立三类模型,即()。 A、系统模型、ER模型、应用模型B、对象模型、动态模型、应用模型 C、ER模型、对象模型、功能模型D、对象模型、动态模型、功能模型 4、SA法的主要描述手段有() A、系统流程图和模块图 B、DFD图、数据词典、加工说明 C、软件结构图、加工说明 D、功能结构图、加工说明 5、画分层DFD图的基本原则有()。 A、数据守恒原则 B、分解的可靠性原则 C、子、父图平衡的原则 D、数据流封闭的原则 6、在E-R模型中,包含以下基本成分()。 A、数据、对象、实体 B、控制、联系、对象 C、实体、联系、属性 D、实体、属性、联系 7、用例驱动的需求方法的主要优点是() A、作为需求分析阶段用户与开发者之间交流信息的工具。 B、对系统的数据结构进行描述。

面向构件的软件开发方法学分析研究

面向构件的软件开发方法学研究 陈良山 200305018009 从软件建模方法论的角度看, 信息系统的开发方法已历经两代技术跨越: 面向过程, 包括面向功能和面向数据流。面向对象, 体现功能与数据抽象方法的统一.20 世纪90 年代中期以来, 由于分布对象技术与软件重构工程的有机结合, 促使面向构件的软件开发方法应运而生.面向构件方法(COM >与面向对象方法(OOM > 的本质差异在于: 对象化建模过程一般针对单一应用系统, 对象抽象一般针对问题域, 对象模型的生成过程是静态的, 软件重用粒度是原子级的。而构件化建模过程一般针对领域应用系统, 构件抽象则针对解域, 构件化模型即构架的生成过程是动态的, 软件重用粒度是组合级的. 领域应用是多个单一应用通用化和重用化的应用集群, 解域是问题域的过程与层次深化, 构件则是对象的软件实现与集成。因此,COM 法与OOM 法在研究范畴、研究对象及其研究方法上都是有区别的. 不言而喻, 面向构件方法是21 世纪软件方法学的主流研究方向. 下面用过程与方法的组合理念来展开研究内容. 面向构件软件开发的一般过程 构件化软件开发的过程模型 所谓构件化, 是指软件体系结构可重组以及软件成份可重用的系统开发方法. 这种方法的基本内涵是: 应用需求领域化, 软件结构框架化, 软件元素构件化, 应用原型实例化. 这一思想可以概括为四个阶段、三个层次和两大过程, 如图 1 所示 从工程化与过程管理的角度讲, 整个软件系统的开发过程可定义为四个阶段: 分析, 设计,

实现, 评价. 但这并不是单纯的串行式瀑布模型, 而是过程并行与增量迭代等多种方法相结合的工作流模型. 多年来, 人们往往把系统阶段控制方法与软件建模抽象方法混为一谈。 最典型的是把生命周期法和原型法与面向过程和面向对象的方法混为一谈. 信息系统是一种具有生命周期的开放系统, 这是毋庸置疑的. 因此, 从工程管理及大的阶段控制过程看, 构件化方法与结构化方法和对象化方法一样, 仍然应该遵循软件生命周期规律。差别在于, 前者的阶段论观点是弱化的历递归和过程重构特征. 换句话说, 在构件化方法中, 可以引入并行工程思想和能力成熟度模型(CMM > 来进行局部过程改造, 以提高系统开发效率和持续优化效果。 可以引入领域工程思想和面向对象方法来改善建模机制, 以提高系统实施过程 的可操作性. 这就是面向构件方法论的主要过程特征. 从模型化与内容抽象的角度讲, 构件化软件开发过程可按三个层次展开: 概念层, 逻辑层, 物理层. 这与UML 描述、数据库设计模式和元建模技术等多种方法是一致的, 差别只在术语不同. 例如, 在基于UML 形式描述的面向对象建模中, 上述三个层次称概念层、说明层和实现层。而在元建模中, 则称元知识层、结构知识层和算法知识层.整个建模层次展开过程是: 首先从特定应用需求出发, 通过领域分析进行共性需求识别、领域对象抽象和领域知识获取, 以建立概念级的领域模型. 进而通过领域设计为领域需求寻求软件解决方案, 包括构架级和构件级的设计模型。这种模型体现了初步设计和详细设计成果, 体现了框架结构和部件结构的组成原理可行性, 因而是一种逻辑模型. 由问题域的领域模型转化为解域的构架模型和构件模型, 是一个知识提取(正向> 和分析精化(逆向> 的迭代式增量开发过程. 第三, 根据领域应用开发或直接重用需要, 进行领域实现。包括领域构件的识别、设计、编码和测试等局部过程集成, 系统构件的分类、检索、引用和构件库维护, 领域构件与系统构件的演化、例化、组合和应用原型的动态生成等领域框架整体集成, 从而建立符合领域应用的各种物理模型. 第四, 通过运行模拟(正向>和设计优化(逆向>等措施, 对领域化软件原型进行可用性评价和可重构验证, 并对符合确认测试条件的应用系统进行全局封装和使用规范生成。 最终获得一个真正构件化的目标系统, 这是一个经过版本逐次寻优的实用软件系统.整个过程模型充分体现重构工程思想, 并把面向构件的软件开发分离为正向工程和逆向工程两大过程. 正向工程侧重体现自顶向下与过程并行特征, 解决软件构架和构件的可用性问题。逆向工程侧重体现自底向上与增量迭代特征, 解决构架及构件的可重构性问题. 过程重构的基本内涵是, 概念重定义, 结构重说明, 算法重用, 系统重生成. 面向构件的建模支持机制 常用的构件化建模方法如, 面向对象方法及UML 描述,框架、实例及其规则描述, 巴科斯范式、谓词逻辑和体系结构描述语言(ADL >等形式化描述, Petri 网和导航图等可视化描述. 支持上述建模方法的典型机制如, 抽象类型, 元模式, 模板, 分布对象, 协作代理, 参数化框架, 导航图标, 软件总线, 以及设计词汇表. UML 描述提供了静态和动态两种建模机制. 在静态建模过程中, 可通过用例图来描述反映功能需求的领域模型,

相关文档