軟件復用課件_第1頁
軟件復用課件_第2頁
軟件復用課件_第3頁
軟件復用課件_第4頁
軟件復用課件_第5頁
已閱讀5頁,還剩93頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權,請進行舉報或認領

文檔簡介

軟件復用

?人們開始認識到,要真正實現(xiàn)軟件的工業(yè)化生

產(chǎn)方式,保證軟件生產(chǎn)的高效率和高質(zhì)量,軟

件復用是一條現(xiàn)實可行的途徑

?軟件復用的概念是在1968年NATO軟件工程會

議上由McIlroy第一次提出的

?所謂軟件復用是指在開發(fā)新的應用系統(tǒng)時使用

以前開發(fā)的軟件資源,如設計、代碼、文檔等,

從而提高系統(tǒng)開發(fā)效率及軟件質(zhì)量

?在較長的一段時間內(nèi),軟件復用僅限于程序代

碼段的復用,這僅是一種較低層次的復用

?人們開始認識到,軟件開發(fā)并不僅僅是編程,

而是一個從系統(tǒng)需求獲取、分析、設計到實現(xiàn)、

測試、運行、維護的過程。理論和實踐表明,

在軟件生存期中,需求、設計階段是開發(fā)過程

的關鍵和瓶頸。軟律復用的概念也隨之擴展到

對軟件開發(fā)過程中各階段產(chǎn)品和文檔的復用,

其中更為重要的是對需求規(guī)約和設計的復用。

?面向?qū)ο蠹夹g為軟件復用提供了更強有力的支

持,帶來了更多的復用機會

面向?qū)ο蠹夹g對軟件復用的支持優(yōu)勢

?面向?qū)ο蠹夹g對軟件復用的支持優(yōu)勢在

于:

-OO模型比傳統(tǒng)過程型模型更為穩(wěn)定;

-00分析更適合于領域工程;

-OO構件具有更好的封裝性;

-00方法學支持無縫的工程,可實現(xiàn)分析、

設計、編碼的一致復用。

日常生活中的復用概念

?在人們的日常生活中,復用概念的存在隨處可

見。

?傳統(tǒng)工業(yè)如機械、建筑等行業(yè)中,標準規(guī)格的

零部件、設計模式等無不體現(xiàn)了復用的思想。

計算機產(chǎn)業(yè)雖然是年輕的產(chǎn)業(yè),其成功同樣是

由于實現(xiàn)了將標準的集成電路芯片、插件板、

主板、外設等直接組裝的工業(yè)化生產(chǎn)方式???/p>

以說,符合標準的構件、基于標準構件的產(chǎn)品

生產(chǎn)(組裝)是產(chǎn)業(yè)工程化、工業(yè)化的必由之

路,而其中構件是核心和基礎,復用是必需的

手段。這種成功的模式是軟件產(chǎn)業(yè)發(fā)展的良好

借鑒,有柞多看益的啟示

軟件構件技術

?軟件構件技術已成為研究的熱點,其研究內(nèi)容

包括構件標準和模型、構件的生產(chǎn)和獲取、構

件的規(guī)約和描述、構件的分類和組織、構件的

檢索和組裝、基于構件的價格分析,以及軟件

體系結(jié)構、軟件復用支持工具和管理手段、基

于復用的軟件開發(fā)過程等方面。

?研究工作有很大進展和眾多成果,而且還出現(xiàn)

了一些產(chǎn)W構件標準,如Microsoft的OLE-

COM、OMG的CORBA/OM等。這標志著軟件

復用已進入蓬勃發(fā)展的時期

產(chǎn)品復用

?軟件復用通??煞譃閮深悾寒a(chǎn)品復用和過程復

?產(chǎn)品復用指對軟件開發(fā)過程中生成的各種產(chǎn)品

(需求規(guī)約、設計、程序、測試計劃和數(shù)據(jù)等)

構件的復用,這涉及可復用構件的建造(從現(xiàn)

有系統(tǒng)中獲取及有目的的生產(chǎn))及可復用構件

的使用(對知識性資源的參考和對程序代碼級

資源的復合組裝)兩個方面,通過專業(yè)性的構

件開發(fā)和基于構件復用的系統(tǒng)集成實現(xiàn)軟件的

工業(yè)化生產(chǎn)。

過程復用

?過程復用指通過采用自動化技術,復用關于軟

件系統(tǒng)生成或變換的,從而使得可以從需

求描述出發(fā),通過生成或變換,自動生成最終

所需的系統(tǒng),應用生成器、程序變換器和可執(zhí)

行規(guī)約語言均是過程復用的例子。

?完全通用的過程復用意味著軟件生產(chǎn)的自動化,

這在目前還是不現(xiàn)實的想法,因此過程復用難

度大、投資大、不易實施。

?當前過程復用的實踐大多和領域相關,如特定

領域的應用生成器。過程復用是非常理想的軟

件復用方式,但在目前技術發(fā)展水平下,仍是

難以企及的目標,產(chǎn)品復用成為主要的研究課

題。

產(chǎn)品復用分類

?產(chǎn)品復用可分為直接復用和間接復用兩類

?直接復用是指對那些可表示為某種程序設計語

言代碼的構件的復用,這類構件的復用及其通

過一定機制的復合(組裝)可直接產(chǎn)生可執(zhí)行

的應用程序,這是我們開發(fā)軟件的最終目標。

?間接復用是指對需求規(guī)約、功能規(guī)約、設計思

想、測試計劃等文檔型知識的復用,這類非代

碼構件的復用雖然不能直接得到最終可運行的

系統(tǒng),但可以對系統(tǒng)開發(fā)的效率和質(zhì)量帶來極

大的好處,這類構件的復合(組裝)缺乏形式

化和機械化的機制,通常只能有開發(fā)者在分析

理解后進行手工復合。

黑盒復用和白盒復用

?對已有軟件資源的復用存在兩種情形,一是不

作修改的全部采用,這類構件恰好能滿足使用

者的需求,這種復用稱為黑盒復用;

?另一情形是所復用的構件只能滿足使用者部分

需求,需要對構件進行適應性修改才可采用,

這種復用稱為白盒復用。

?在大多數(shù)情況下,對構件的復用均是白盒復用。

基于復用的軟件開發(fā)方式

?對照傳統(tǒng)的成熟產(chǎn)業(yè),我們可以發(fā)現(xiàn),

專業(yè)性的分工是社會化、工業(yè)化生產(chǎn)的

基本前提,專業(yè)化的零部件生產(chǎn)和使用

零部件的整機生產(chǎn)是主要的生產(chǎn)方式。

?我們有理由認為理想的軟件生產(chǎn)方式是:

專業(yè)化的構件生產(chǎn),基于構件復用的應

用系統(tǒng)集成(組裝)。

?

一種工廠化的軟件生產(chǎn)方式

?Caldieri和Basili提出了一種工廠化的軟件

生產(chǎn)方式

青鳥工程簡介

?青鳥工程是國家重點支持的科技攻關課題,已

有十余年的發(fā)展歷程?!捌呶濉?、“八五”期

間,青鳥工程面向我國軟件產(chǎn)業(yè)基礎建設的需

求,以實用的軟件工程技術為依托,研究開發(fā)

具有自主版權的軟件工程環(huán)境,為軟件產(chǎn)業(yè)提

供基礎設施一軟件工具、平臺和環(huán)境,建立工

業(yè)化生產(chǎn)的基本手段,促進我國軟件開發(fā)由手

工作坊式轉(zhuǎn)向用計算機輔助開發(fā),以提高軟件

開發(fā)效率,改善軟件產(chǎn)品質(zhì)量。大型軟件開發(fā)

環(huán)境青鳥系統(tǒng)便是這一階段攻關工作的成果。

?“九五”期間,青鳥工程的任務是在前

期攻關工作的基礎上,為形成我國軟件

產(chǎn)業(yè)規(guī)模提供技術支持。重點是研究軟

件的工業(yè)化生產(chǎn)技術,開發(fā)軟件工業(yè)化

生產(chǎn)系統(tǒng)——青鳥軟件生產(chǎn)線系統(tǒng),即

基于構件一構架模式的軟件開發(fā)技術及

系統(tǒng),為軟件開發(fā)提供整體解決方案,

推行軟件工業(yè)化生產(chǎn)模式,促進軟件產(chǎn)

業(yè)規(guī)模的形成。

青鳥HI型(JB3)系統(tǒng)

?作為研究成果之一,青鳥工程開發(fā)了基于異構

平臺、具有多信息源接口的應用系統(tǒng)集成(組

裝)環(huán)境青鳥III型(JB3)系統(tǒng)。青鳥III型系統(tǒng)研

制的目標是針對軟件工業(yè)化生產(chǎn)的需求,完善

并初步實現(xiàn)青鳥軟件生產(chǎn)線的思想,制定軟件

工業(yè)化生產(chǎn)標準和規(guī)范,研究基于“構件一構

架”模式的軟件工業(yè)化生產(chǎn)技術,研制支持面

向?qū)ο蠹夹g,支持軟件復用的,基于異構平臺、

具有多信息源接口的應用系統(tǒng)集成(組裝)環(huán)境。

其最終目標是要構造如下圖示意的軟件生產(chǎn)線

系統(tǒng)。

青鳥軟件生產(chǎn)線

構件生產(chǎn)車間

標唯規(guī)范與質(zhì)量保證

-軟件的生產(chǎn)過程劃分為三類不同的生產(chǎn)車間,

即應用構架生產(chǎn)車間、構件生產(chǎn)車間和基于構

件、構架復用的應用集成(組裝)車間,從而形

成軟件產(chǎn)業(yè)內(nèi)部的合理分工,實現(xiàn)軟件的工業(yè)

花圣產(chǎn)。

?軟件開發(fā)人員被劃分成三類:構件生產(chǎn)者、構

件庫管理者和構件復用者。這三種角色所需完

成的任務是不同的,構件生產(chǎn)者負責構件的生

產(chǎn)、描述;構件庫管理者負責構件分類以及構

件庫的管理工作;而構件復用者負責進行基于

構件的軟件開發(fā),包括構件查詢、構件理解、

適應性修改、構件組裝以及系統(tǒng)演化。

復用帶來了軟件開發(fā)過程的變革

?由于復用活動的存在使得傳統(tǒng)的軟件生

存期模型不再適用,軟件開發(fā)過程分為

兩個相互關聯(lián)的過程,即開發(fā)可復用資

源的過程和根據(jù)可復用資源開發(fā)應用系

統(tǒng)的過程,REBOOT計劃中將其稱為

DEVELOPINGFORREUSE和

DEVELOPINGWITHREUSE

青鳥山型系統(tǒng)的體系結(jié)構

基于復用的

胡友工具集

廠■向琳4

激博工具

西?自對八

警總工只

尸面白對蒙、

ttiMM

k而R時拿、

分析工具P

規(guī)范

,規(guī)范包括:

-青鳥可復用構件制作指南

-青鳥領域工程方法指南

-青鳥構件模型

-青鳥構件描述語言

-青鳥構件庫概念模型

-基于復用的軟件開發(fā)過程

青鳥構件模型設計原則

1.表達能力足夠強

2.簡單性

3.支持構件的復合

4.模型和方法學關系的考慮

5.一致性和完備性

6.實用性考慮

7.擴展性考慮

8.對軟件開發(fā)過程的考慮

表達能力足夠強

?模型是對客觀對象的抽象)合適的抽象

層次是十分重要的,必須既能抓住本質(zhì),

又不陷入細節(jié)。從表達能力考慮,青鳥

構件模型首先必須遵循3c模型

?3c模型由構件的三個不同方面的描述組

成,即概念(concept)、內(nèi)容(content)

和語景(context)三個方面

3c模型

?概念:關于“構件做什么”的抽象描述,可以通過概

念去理解構件的功能。概念包括接口規(guī)約和語義描述

兩個部分,語義描述和每個操作相關聯(lián)(至少表示為

前后置謂詞形式)。

?內(nèi)容:概念的具體實現(xiàn),描述構件如何完成概念所刻

劃的功能。

?語景:描述構件和外圍環(huán)境在概念級和內(nèi)容級的關系。

語景刻劃構件的應用環(huán)境,為構件的選用和適應性修

改提供指導。語景進一步可分為:、秩念語景

(ConceptualContext)描述構件間接口和語義方面的

關系;操作語景(OperationalContext)刻劃構件中法

操作數(shù)據(jù)的特征(如類型和操作);、實現(xiàn)將景、、

(ImplementationContext)描述構件間在實現(xiàn)方面的依

賴關系。

簡單性

?簡單性是各種模型必須予以考慮的重要

性質(zhì),簡單意味著易于掌握和理解。簡

單性和強的表達能力是一對矛盾,必須

合理權衡。

?青鳥構件模型應在具有足夠強的表達能

力的前提下盡可能簡單,因為構件被很

好地復用的前提是必須能夠被充分的理

解。

支持構件的復合

?構件模型僅僅作為構件的抽象和描述是不夠的,

必須能夠描述構件間的關系及構件的復合,這

樣才有實用的價值和完整性。

?青鳥構件模型考慮了直接復用構件的復合問題,

在源代碼級上提供了構件復合的機制。同時,

也支持目標碼級構件的復合,當前的考慮是將

青鳥構件轉(zhuǎn)換為符合某種規(guī)范的目標碼構件

(如OLE構件),通過相應的構件互操作機制

來實現(xiàn)復合。

模型和方法學關系的考慮

-構件模型的確立和具體的軟件方法學有

著密切關系,不同范型的方法學必然導

致不同的模型。

?青鳥構件模型遵循00范型,其構件結(jié)構

符合00風范。如此考慮是因為00技術

能對軟件復用提供更有力的支持。對于

基于傳統(tǒng)范型的構件,如模塊類構件,

可考慮將其通過再工程封裝成00類構件。

一致性和完備性

?模型必須具有對內(nèi)的一致性和對外的完

備性。

?所謂一致性是指構件作為一個封裝體必

須具有一致的對外接口、一致的組成結(jié)

構以及一致的交互方式。

?完備性是指不存在模型所不能描述的構

件(在00范型內(nèi))。

實用性考慮

?實用性是青鳥構件模型所考慮的主要因

素之一。

?從實用性角度來看,構件模型應易于理

解、支持復合、方便分類和檢索。

?青鳥構件模型應作為青鳥構件庫概念模

型的核心。

擴展性考慮

?模型的可擴展性是指在保持模型本身的一致性

和完備性的前提下,模型可以隨著應用需求的

增長而演化。為此,在模型設計初期,能適應

擴展的設計考慮是必需的。

?青鳥構件模型目前主要考慮工程實用性,進一

步的考慮是結(jié)合形式化規(guī)約技術,給出構件的

形式化功能規(guī)約,一方面可用于支持基于形式

化功能規(guī)約的構件分類和檢索策略,通過規(guī)約

匹配查找所需的構件;另一方面支持更有效、

更自動地復用非代碼類構件,通過形式規(guī)約變

換技術,實現(xiàn)產(chǎn)品復用和過程復用在一定程度

上的結(jié)合

對軟件開發(fā)過程的考慮

?軟件復用可以發(fā)生在軟件開發(fā)過程的任

意階段,各個階段的產(chǎn)品均是可復用的

目標,越早階段的復用可帶來更好的效

血。

?青鳥構件模型描述的對象是多層次、多

階段的構件,層次刻劃構件的抽象程度。

層次和開發(fā)階段是密切關聯(lián)的,開發(fā)階

段越早,構件抽象層次也就越高

構件的形態(tài)、層次和表示

?青鳥構件模型從三個不同的、相互正交

的視角來看待構件,每個具體的構件都

是形態(tài)、層次和表示構成的三維空間中

的一個點。

構件的形態(tài)

?構件呈現(xiàn)不同的形態(tài)(Form),形態(tài)的差異體

現(xiàn)在構件的結(jié)構組織方式和依賴的方法學范型

上。青鳥構件可分為如下幾種形態(tài):

-類(Class):以類為單位進行封裝而得到的構件,

這是最基本的構件單元

-類樹(ClassTree):以一個抽象類為根,若干繼承

該抽象類的具體子類(也可能有抽象子類)為節(jié)點

的一棵類樹。這樣的一棵類樹被封裝為構件,對外

實現(xiàn)了具體子類的隱蔽,抽象根類提供了該類樹的

對外接口規(guī)約,對具體子類的操作(刪除或增加)

以及子類對象的創(chuàng)建均由抽象類控制,該類樹的客

戶無需知道類樹結(jié)構和具體子類。

一個類樹的例子

?類樹作為構件的優(yōu)點在

于:

a.類樹比類具有更多的獨

立性,對外界依賴少,

更易于復用;

b.類樹封裝使得用戶只需

關心所需功能的抽象和該類樹被封裝為構件,類樹

規(guī)約而忽略具體子類細的客戶只知道抽象類Graph,

下;并不關心類樹中有多少子類,

所有操作都是針后Graph類

C.類樹封裝后其結(jié)構變化

和具體子類的增刪對客進行,通過條件限制實現(xiàn)對

戶不會產(chǎn)生影響。子類對象的匿名創(chuàng)建和操作

框架

?框架(Framework):一個框架由一組協(xié)作構

件組成,闡明了整個設計、構件間依賴及成員

構件的責任分布。

?這些成員構件通常是子框架、類樹或類,大多

以抽象的形式出現(xiàn),實現(xiàn)細節(jié)放在具體子類中,

構成了一個抽象設計,不同的具體子類可產(chǎn)生

對設計的不同實現(xiàn)。

?框架作為構件使得用戶可以復用設計,用戶通

過具體子類的嵌入而在框架中加入特殊功能。

一個框架的例子

?GraphResizer稱為圖形變

形器,它既是Graph的子

類,又是Graph對象的操

作者(變形器),每一

種具體圖形對象都宥對

應的具體圖形變形器,

GraphEditor用于屏幕上

?圖中箭頭線表示客戶關畫鹵,每一種具體圖形

系(Clientship),帶△類都有對應的編輯器。

的線表示繼承關系。這用戶復用這個框架,通

是一個由三個抽象類組過加入具體子類,即可

成的框架得到處理不同圖元的應

用程序。

設計模式

?設計模式(DesignPattern):設計模式

是對經(jīng)驗的顯式表示,每個設計模式描

述了一個反復出現(xiàn)的問題以及該問題解

法的核心內(nèi)容,它命名、抽象并標識了

一個通用設計結(jié)構的關鍵部分,使得它

可以用來創(chuàng)建一個可復用的面向?qū)ο蟮?/p>

設計。設計模式作為可復用構件體現(xiàn)了

較高層次的設計思想復用。

模式的四個基本要素

-1)模式名稱:是一個助記名,他用一兩個詞來描述模式

的問題、解決方案和效果。

?2)問題:描述了應該在何時使用模式。它解釋了設計

問題和問題存在的前因后果,它可能描述特定的設計

問題,如怎樣用對象表示算法,也可能描述了導致不

靈活設計的類或?qū)ο蠼Y(jié)構,有時候,問題部分還會包

括使用模式必須滿足的一系列先決條件。

?3)解決方案:描述了一個設計的各個組成成分(結(jié)

構),以及它們之間的相互關系及各自的職責和協(xié)作

方式。

?4)效果:描述了模式使用的效果及使用模式應注意的

問題。

設計模式的分類

■創(chuàng)建型模式

-AbstractFactory(抽象工廠)、Builder(生成器)、

FactoryMethod(工廠方法)、Prototype(原型)、

Singleton(單件)

?結(jié)構型模式

-Adapter(適配器對象)、Bridge(橋接)、

Composite(組合)、Decorator(裝飾)、Facade

(外觀)、Flyweight(享元)、Proxy(代理)

?行為型模式

-ChainofReponsibility(職責鏈)、Command(命

令)、INTERPRETER(解釋器)、Iterator(迭代

器)、Mediator(中介者5、Memento(備忘錄)、

Observer(觀察者)、state(狀態(tài))、strategy(策

略)、TEMPLATEMETHOD(模板方法)、visitor

(訪問者).........................

構架

?構架(Architecture):應用系統(tǒng)體系結(jié)

構的顯式表示。構架具有領域相關性,

構件根據(jù)構架進行復合而生成可運行的

系統(tǒng)。構架是一類特殊的構件,可視為

框架用于描述一個應用系統(tǒng)時的極限狀

態(tài)。

各類形態(tài)構件間的關系

?通常,一個構架由若干框架所構成,框架又可

包含子框架、類樹、抽象類和具體類,類樹由

抽象類和具體子類構成,類是最基本的構件單

元。在這個意義上,構件的形態(tài)體現(xiàn)了構件粒

度上的差異。一個框架通常含有多個設計模式

的采用,每個設計模式都有若干個框架作為它

在不同領域的具體實現(xiàn)。

?這里討論的構件形態(tài)均和00方法范型相依賴,

對于傳統(tǒng)范型的構件可以通過再工程替其轉(zhuǎn)換

為00構件,如傳統(tǒng)的模塊、模塊簇可以轉(zhuǎn)換

封裝為00的類、類樹和框架,并按照00的方

式進行復合組裝。

構件的層次

?可復用構件根據(jù)其產(chǎn)生于開發(fā)過程的不

同階段而處于不同的抽象層次。青鳥構

件模型考慮將構件分為四個層次。

?分析件:指系統(tǒng)需求規(guī)約和功能規(guī)約。

?設計件:指系統(tǒng)體系結(jié)構和設計方案。

?編碼件:由具體程序設計語言編制的源

代雞構件。

?測試件:測試計劃和測試案例。

構件的表示

?不同層次的構件具有不同的表示媒介和

手段,如:

-圖形

-復合文檔

—正文

-偽碼

-編程語言

—目標

青鳥構件模型

?青鳥構件模型從九個方面來描述構件,

更多地關心構件的易理解性、封裝性及

構件間關系,通過給構件提供明確的對

外接口實現(xiàn)服務提供者和其服務請求者

的分離,模型更多地關心構件及其使用

者間的交互,特別是對構件使用者有意

義的部分。

(1)概念

?這是對構件功能的抽象描述,多采用名

詞來表示。如堆棧(Stack)、銀行帳號

(Account)等,這類名詞術語應盡可能

采用同領域內(nèi)的公認詞匯,以便于直觀

的理解和相互交流。

(2)操作規(guī)約

?用來指稱構件對外提供的、可被請求的服務。

?Operation=Name+Signature+Axiom+Exception

+Context

?Signature給出了操作的類型聲明,由參數(shù)類

型和結(jié)果類型構成,操作參數(shù)有in、out.

in&out三種模式(Modei;Axiom以前后置斷

言的形式給出操作的功能規(guī)約;Exception描述

操作的例外處理;Context描述操作使用的語景。

?對收到的服務請求,操作的執(zhí)行有兩種方式:

-at-most-once如執(zhí)行成功,則恰好執(zhí)行一次;如出

現(xiàn)例外,則執(zhí)行一次或0次

-best-effort:不需返回結(jié)果,不等待執(zhí)行

(3)接口

?接口給出了構件的對外行為描述,分入接口(in-

interface)和出接口(out-interface)。

?入接口:每個人接口刻劃一個操作集合,接口可以具

有用一對訪問函數(shù)(獲取或設置屬性值)表示的屬性。

一個構件可擁有多個人接口,客戶(Client)可通過一

個或多個人接口請求構件服務。

-出接口:描述構件對外界的請求。當構件完成某一功

能時,可能需要其他構件的協(xié)作,出接口指明了這種

對外關泵。

?構件間存在入接口繼承關系(子類型關系),這種關

系指明:凡是父構件能響應的請求,其繼承者同樣可

以響應。子類型關系是造成多人接口的原因。

(4)類型

-類型用于定義“什么值可用作為操作參數(shù)”。

在00程序也操作參數(shù)可分為三類:

?基本類型值:這是一般程序語言中都提供的基

本類型,如整數(shù)、字符、字符串等。

?對象索引:指對象的名或地址,憑此將對象作

為參數(shù)傳遞。

?構造值:由對象和基本值混合構造成的結(jié)構。

(5)實現(xiàn)體

?這是構件的具體實現(xiàn)部分,是實際完成

被請求服務的系統(tǒng)。不同層次的構件有

不同的實現(xiàn)(表示)方式,具有不同實

現(xiàn)體的構件可能擁有相同的接口和功能

規(guī)約。

(6)構件復合

-構件通過復合組成系統(tǒng)。模型中的復合

關系僅限于可表示為程序代碼的構件,

復合的方式是服務請求(消息傳遞)。

構件間出、入接口的關聯(lián)建立起構件的

復合關系。

?服務請求=請求的操作+目標對象+參

數(shù)表+語景選項

構件性質(zhì)、注釋和語景

?(7)構件性質(zhì)

指明構件的形態(tài)、層次和表示。

?(8)構件注釋

描述和構件庫相關的其他性質(zhì),這些性質(zhì)

是構件庫管理所必需的信息,如構件作者、制

作時間、修改限制、修改影響等等。

?(9)構件語景

描述構件的軟、硬件使用環(huán)境和實現(xiàn)依賴。

其他關于構件的模型

OMG的CORBA/OM

MICROFOFT的OLE/COM

DEC的COM

REBOOT模型

RESOLVE模型

青鳥構件模型和構件描述語言

?青鳥構件模型是以對象計算模型為基礎進行設計的,

它支持多種不同構件形態(tài):類、抽象類、類簇、類樹、

框架(framework)和構架(architecture)。

?類構件、類簇構件和類樹構件的引入為代碼復用提供

了三種不同粒度的支持。

■抽象類構件的引入為設計復用提供了一定的支持。

?框架構件的引入則對面向?qū)ο笤O計的復用提供了充分

的支持。

-而構架作為一種系統(tǒng)級的框架,為系統(tǒng)級構件組裝提

供了支持。

?青鳥構件模型具有自包含性,即要求構件組裝而成的

構件子系統(tǒng)仍是一個可以繼續(xù)進行復合的構件。這使

得原有的構件一構架兩層結(jié)構擴展為構件一構件子系

統(tǒng)一構架多層結(jié)構,從而拓展了該模型的表達能力。

???????

軟件復用的優(yōu)勢

?軟件工程界普遍認為軟件復用具有以下優(yōu)勢:

1.提高軟件生產(chǎn)率

2.提高軟件產(chǎn)品質(zhì)量

3.縮短開發(fā)周期

4.降低維護費用

5.便于軟件移植和實現(xiàn)互操作性

6.支持快速原型開發(fā)

7.降低程序員和端用戶(EndUser)培訓費用

■在工業(yè)界推行復用取得成功的范例有HP、IBM、Unisys、

NEC、BNR、富士通、Raytheon導彈系統(tǒng)、GTE數(shù)據(jù)服務、

SofTech公司、Universal防務系統(tǒng)(UDS)、Bofors電

氣公司等等。許多著名的企業(yè)內(nèi)部也建立了復用機制,

但是尚未對外公開。從管理上和技術上采納軟件復用

已經(jīng)是大勢所趨。

軟件復用的困難

1.系統(tǒng)開發(fā)者缺乏軟件復用的觀念。

2.制作和整理可復用構件需要增加額外的投資。

3.構件不易理解和學習。

4.缺乏有效的構件庫。

5.缺乏足夠選用的構件或者構件的質(zhì)量不佳。

6.構件不完全符合需求時,不容易修改。

7.構件緊密依賴其原有開發(fā)平臺,難以在其他平臺上使用。

8.構件依賴于某一程序語言,無法與其他語言的構件集成。

9.復用別人制作的構件有心理上的障礙(NotInventedHere和Not

InventedThere綜合癥)。

10.與軟件復用有關的版權問題、合同問題和成本分配問題。

11.缺乏理解、修改和組裝構件的支持工具。

12.復用的收益難于估計和度量。

?其中的2.5.6.7.8幾點表明對高質(zhì)量的可復用構件存在著很大

的需求,而4.io.n等幾點表明在構件開發(fā)者與復用者之間缺

乏有效的交流,限制了構件制作者的創(chuàng)作積極性。

構件一般性制作指南

?分析、設計和測試階段的成果本身都有被復用

的潛力,應被當作RSC;

?在新系統(tǒng)中復用前期的軟件工程成果往往帶來

對相應后期產(chǎn)品的復用。

?可復用RSC應該以方便復用的方式被表示,易

于識別,易于獨立提取,與系統(tǒng)特定的和易變

的成分分隔;在組織內(nèi)部采用一致的機器可讀

的記號表示分析和設計RSC,以便進行自動的

信息提取和轉(zhuǎn)換。從分析到設計到編碼的轉(zhuǎn)換

應該遵循上一階段的復用考慮、保持相鄰階段

RSC之間的良好映射和可跟蹤性質(zhì)。

建立一個鼓勵復用現(xiàn)有軟件的需求

?需求規(guī)約必須認識到復用的必要性并鼓勵軟件復用。好的

需求規(guī)約應該只規(guī)定所需的功能和性能指標,允許開發(fā)者

決定操作上和實現(xiàn)上的細節(jié)。一個極端明細的規(guī)約是很難

與任何現(xiàn)有軟件相匹配的,不必要的系統(tǒng)需求將限制軟件

復用。將軟件復用作為需求之一,在規(guī)約中規(guī)定所有必須

的(Required)和期望的(Expected)復用活動。

?建議:要逐條檢查每一需求的必要性,確信其中不包括進

一步的設計選擇。

?建議:給承包商以復審需求規(guī)約的機會。改變以往將需求

規(guī)約在招標之前定住不變的做法,向潛在的承包商提供需

求規(guī)約的草稿,讓開發(fā)者參與進來,標識出他們認為可以

修改并將促進復用的地方,由客戶和承包商共同完成項目

的規(guī)約文檔。

?建議:復用需求必須解釋什么是復用和如何評估復用。為

開發(fā)者指定一個復用目標,比如復用的代碼、函數(shù)的數(shù)量

等,在合同中為復用制定獎勵措施以鼓勵復用。

將可復用軟件的開發(fā)列入需求

?如果希望所開發(fā)的系統(tǒng)是可復用的,就應該在

需求中顯式聲明出來,并且應該使這種項月需

求在客觀上是可測試的。

?建議:這種需求必須定義什么是可復用性和如

何評估RSC的可復用性,應該規(guī)定對RSC所期

望的復用范圍(在項目內(nèi)部或者跨項目的復用,

在不同的OS上復用等等),規(guī)定與某一復用標

準的符合程度,規(guī)定RSC所必須具備的文檔,

要求對軟件的可復用性進行測試,以及要求開

發(fā)者對RSC進行維護等。

領域

?領域(Domain)被定義為“一類相關或相似的軟

件應用系統(tǒng)"O從復用的角度看來,面向領

域的構件具有較高的可復用性。如果組織所關

注的領域足夠成熟,能夠建立起領域構件庫,

那么即使構件庫的規(guī)模不大也照樣會有相當大

的作用。領域分析(DomainAnalysis)的成果

不僅在復用者生成應用系統(tǒng)時有用,而且可以

用來組織軟件產(chǎn)品線(ProductLine),管理用

戶需求和輔助構件庫進行構件的分類等。

制作面向領域的可復用構件

?領域分析和領域工程是應用系統(tǒng)開發(fā)過

程中最需要經(jīng)驗也最缺乏方法和工具支

持的階段之一,領域知識在分析和設計

階段有十分重要的作用。如果能夠?qū)㈩I

域知識和模型與本領域的構件結(jié)合,將

大大提高應用系統(tǒng)的開發(fā)效率

領域分析的作用

?領域分析活動不同于通常對特定系統(tǒng)進行的需

求分析,它是對特定應用領域中已有的系統(tǒng)、

預期的需求變化和技術演化進行分析,目的是

標識出整個領域中通用的構架和相同的功能與

接口。領域分析的結(jié)果將影響到系統(tǒng)需求的取

舍,由此構造出的系統(tǒng)由于更適應變化的需求,

日后被復用的可能性也更大。

?建議:要評估領域分析的必要性和可行性。在

適當?shù)臅r機進行領域分析或者采用現(xiàn)有的分析

成果。在利用現(xiàn)有領域分析成果時應該評價其

適用性,即使整個構架未必可用,仍有可能復

用某些標準的構件和接口。

領域分析的建議

■建議:在評估領域分析的必要性時有以下評價準則,

對這些問題的回答應該大多數(shù)為“是”:

-本組織還會在同一領域建造其他系統(tǒng)并由此從一個標準

的構架和適合該構架的構件集合中獲益嗎?

-在本領域中建造系統(tǒng)的技術已經(jīng)足夠成熟并能夠產(chǎn)生一

個令人滿意的標準構架了嗎?

-開發(fā)者是否建造過類似系統(tǒng),是否獲得了足夠的經(jīng)驗以

保證所得的領域分析結(jié)果是可用的呢?

-是否有一種要求和確保領域分析的結(jié)果被實際應用了的

機制呢?比如,一個小組受命開發(fā)標準的構架后,是否

有一種方式讓其它開發(fā)小組獲知并采用領域分析的成果

呢?

-有否一種方式在受益于領域分析結(jié)果的小組之間分攤領

域分析的成本?

領域分析的建議

建議:在評估領域分析的必要性時有以下評價

準則,對這些問題的回答應該大多數(shù)為“是”

-要建造的系統(tǒng)是該領域的一個代表嗎?領域構架會

適用嗎?

-到底什么是可用的?如果只有一個構架模型和部件

列表而沒有可復用的詳細設計或者代碼構件,也許

就不會節(jié)省很多成本了。

-如果詳細設計和代碼構件是可用的,它們提供了多

少要求的功能呢?

-構架達到了哪個層次的標準?為了組織內(nèi)部有更多

共同之處而使用這個構架和(或)接口會獲益嗎?

-分析結(jié)果在實踐中被證明了嗎?有多少可信度?

領域分析的建議

?建議:即使沒有時間或能力進行完整的

領域分析,仍然可以快速標識出本領域

中可復用的子系統(tǒng)和接口(比如標準設

備、通信協(xié)議、用戶接口、應用算法

等),為今后的開發(fā)儲備“零部件”。

?建議:在應用領域分析成果時,應該及

時提供反饋,補充或改進其成分,促進

領域模型隨實際領域的演化而演化。

構件庫的管理流程

圖1.構件庫的韶淵g

構件的登記表格

?構件的登記表格中有下列屬性:

1.名稱:每個構件都必須有一人確定的名稱,該名稱

必須完整地標識了該構件的本質(zhì)。如stack,resource

manager等。

2.作者:即制作或提供該構件的單位或個人的名稱,

以及聯(lián)絡地址等相關信息。

3.制作日期:即構件制作的完成日期。

4.入庫日期:即構件進入構件庫的日期。

5.版本號:即該構件在一組構件演化系列中相應的版

一號。

6.使用環(huán)境:即使用(包括理解/組裝/修改)該構件時

必須提供的硬件和軟件平臺。如所需的特定的硬件

環(huán)境、操作系統(tǒng)、數(shù)據(jù)庫平臺和網(wǎng)絡環(huán)境等。

7.應用領域:即該構件原來或可能被使用到的應用領域

(及其子領域)的名稱。如MIS,CAI等。

8.用途:即該構件在被應用的領域中所發(fā)揮的作用。

9.功能:即該構件在原有或可能的軟件系統(tǒng)中所提供的

軟件功能集。

10.表示方法:即用來描述該構件內(nèi)容的語言形式或媒體。

如源代碼構件所用的編程語言等。

11.形態(tài):即該構件的組成成分及其相互關系。如類、類

樹、框架、模塊等。

12.層次:即該構件相對于軟件開發(fā)過程階段的抽象層次。

如分析、設計、編碼等。

13.上下文環(huán)境:即該構件在組裝時系統(tǒng)所必須提供的程

序級上下文環(huán)境。

14.尺寸(size):即該構件的大小。

15.創(chuàng)作工具:即構件的制作者在制作該構件時所使用的

軟件工具。

構件庫的分類策略

?一個刻面分類模式由一組描述構件本質(zhì)特征的

刻面所組成,每個刻面從不同的側(cè)面對構彳牛庫

中的構件進行分類。

?例如,這組刻面可以是構件的應用領域、功能、

操作對象、使用環(huán)境等。

?每個刻面是由一組基本的術語(即關鍵詞)所構

成的(稱為術語空間termspace)。一個構件可以

被每個刻面中的一個或多個術語所刻劃(刻面術

語是一個確定的集合),而每個刻面則反映了對

庫中構件的一種劃分,因此用戶可以直觀地從

不同的角度指明待檢索的構件,也有利于用戶

對構件的理解。

刻面分類策略的特性

1.刻面必須充分并明確地描述構件庫中全體構件,即每一

個構件都可以用該刻面來分類。

2.每一個刻面與一個術語空間相關聯(lián)。任意兩個刻面的術

語空間是正交的,即一個刻面的術語發(fā)生變化不會影響

到另一個刻面的術語空間。

3.一個刻面的術語空間為有限的不定空間(finite&indefinite

space),即可以隨時間的演進而動態(tài)地增加和刪除術語。

4.每一個構件的所有刻面必須予以定義,不允許在對構件

分類時有未定義的刻面;但查詢時,用戶可以利用任意

數(shù)目的刻面來查詢。

5.構件庫管理者對構件進行分類時,應該針對每一個刻面,

從術語空間中選擇適當?shù)模ǘ鄠€)術語,以完成構件的封裝

工作。

6.在一個術語空間中的術語按一般/特殊關系形成樹狀的層

次結(jié)構,每一個術語附帶有不定數(shù)目的同義詞(術語間可

以具有同義詞關系)。...........................

刻面分類策略的好處

?構件庫管理者通過將刻面與對應的術語

相聯(lián)結(jié),可以在構件間建立復雜的聯(lián)系。

與一般的層次分類策略相比,刻面分類

策略更易于修改,更富有彈性,因為對

一個刻面的修改不會影響到其它的刻面。

同時,每個刻面對應一個結(jié)構化佰術語

空間,避免了一般的關鍵詞分類策略的

雜亂無章,使得對關鍵詞的管理更為方

彳更和有序。

屬性與刻面的區(qū)別

刻面是構件屬性的一個子集。屬性絕大部分是

由構件的制作者或提供者提供的,而刻面則完

全是由構件庫的管理者規(guī)定的,構件的制作者

或提供者完全不需要了解它們。

刻面是構件的復用者在查詢構件時最感興趣的

構件屬性。在查詢時復用者通過選擇刻面的術

語,可以明確地限定構件的范疇,不會有遺漏

的構件。

術語空間

?在刻面分類策略中,每個刻面關聯(lián)了一

個合法術語的結(jié)構化集合-術語空間,在

構件的分類和查找中用到的術語均來自

于這些術語空間。

?術語空間的結(jié)構反映了術語間的語義關

系,因此術語空間可以看做是一種語義

網(wǎng),而構件從外部來看,都是一組刻面

術語的集合。

術語的兩種關系

?即一般/特殊關系和同義詞關系,這是基于以下

兩個目的:

-簡化術語的定位。用戶可以沿著術語間的關系迅速對術

語進行定位。同時,用戶要查找的術語可能不夠精確,

由于習慣不同,使用的術語也不盡相同,因而查找時容

易出現(xiàn)術語的不匹配(mismatch)。利用這兩種關系,既

可以統(tǒng)一用戶間術語使用上的差異,又可以幫助用戶將

自己的檢索需求進一步修正和細化,這也是一個逐步求

精的過程

-檢索到所需改動最少的構件。若沒有發(fā)現(xiàn)刻面術語與用

戶要查找的術語正好匹配的構件,那么構件庫管理系統(tǒng)

就會讓用戶檢查那些刻面術語與用戶要查找的術語相接

近的構件。這種找到相似構件的機制稱為“松馳查

找”(relaxationofsearch)。這樣用戶可以在構件庫現(xiàn)有

的構件中找到所需改動最少的構件,提高復用的效率。

青鳥構件庫的刻面

?刻面的定義

-1.使用環(huán)境(ApplicationEnvironment)

-2.應用領域(ApplicationDomain)

-3.功能(Functionality)

-4.層次(LevelofAbstraction)

-5.表示方法(Representation)

構件庫的實體-關系圖

構件間的關系

(1)被實現(xiàn)關系(Refinement)

(2)版本關系

(3)包含關系

(4)相關關系

⑸協(xié)作關系

(6)繼承關系

構件庫的查詢策略

?使用者可以按刻面進行查詢。即通過選擇任意刻面的一個

或多個術語,就可以迅速限定構件的范疇。

-除了刻面查詢外,使用者可根據(jù)構件的任意屬性進行輔助

查詢。

?使用者在查詢構件過程中,可隨時通過超文本(hypertext)瀏

覽器對庫中構件進行有層次地瀏覽。

?構件庫提供了類似“服務臺”的機制。使用者在查詢構件

過程中,可以向“服務臺”求助,也可以向它提出自己的

意見和建議。

?使用者找到一個構件時,構件庫可以顯示出與該構件有某

種關系的所有構件。

-較為熟練的使用者可以用類似SQL查詢語句的形式,以構件

的屬性和刻面作為條件變量,并允許查詢條件的與、或、

非的任意組合。

?上面提到的查詢方法可以任意組合,逐步求精,并允許查

詢過程的回溯...........................

構件庫的管理過程

?項目中每個開發(fā)者都應在構件庫中建立帳戶

?盡量避免復用還沒有進入構件庫的構件

?為構件庫提供對構件和構件庫支持工具的使用

經(jīng)驗和反饋

?將復用構件時遇到的所有問題通知構件庫

?將構件的更新版本和增強版本提交給構件庫

對構件的選擇和提取

?使用構件庫提供的材料決定構件的選取

-在選取構件前檢查構件的相關信息

-檢查構件的質(zhì)量和可復用性等級,以及構件的推薦

意見

?提取完整的構件

-提取一個代碼構件時應盡量提取出它的分析構件和

設計構件等

-構件間可能存在繼承、協(xié)作和包含關系

-提取每個構件時,構件庫會將構件的構件描述語言、

摘要、使用樣例、分類信息等作為構件的一部分一

起提取出來

?提供反饋日期等信息

-反饋日期通常在提取后的三個月內(nèi)

需求分析

?需求分析時,應首先查詢構件庫,根據(jù)用戶需求確定

構件庫中是否有相似的構架和子系統(tǒng),或在該領域中

是否有對應的領域分析構件

需求分析

建立復用需求并盡早發(fā)現(xiàn)復用的機會

?在提交具體需求前,要檢查構件庫中是

否有可以復用的構件

?避免在需求分析階段將需求過分細化

?要參照構件庫的分類模式指定系統(tǒng)需求

?盡量選擇支持復用程度更高的開發(fā)方法

和工具

對領域分析構件的復用

領域分析過程采取的主要步驟

1.知識獲取(KnowledgeAcquisition)---收集和分析

與問題域相關的信息,并將這種信息用該領域內(nèi)部

和外部的對象來描述。

2.領域定義(DomainDefinition)---對知識獲取階段

標識出的對象進行分析,以便定義出領域的范圍和

具體邊界。

3.模型建立(ModelFormulation)---對領域定義階段

標識為領域內(nèi)部的對象進行建模,以便進一步地理

解它們在領域中扮演的角色。

4.模型演化(ModelEvolution)——將模型進行進一步

地分析和精化,以開發(fā)出該領域的分類(taxonomic)

模型,用于表示出該模型的組織結(jié)構和語義

領域分析過程的產(chǎn)品

?功能層次(FunctionalHierarchy)---一個功能需求的層

次性模型。

,實體一關系模型(Entity-RelationshipModel)----顯示領

域內(nèi)各對象間關系和接口的模型。

?類屬的軟件構架(GenericSoftwareArchitecture)---以

軟件構件的形式表示出的E-R模型中的對象。

?分類(Taxonomy)——提供了一個用于定義領域內(nèi)對象的分

類模式。

?標準需求(StandardRequirements)---涉及該問題域的系

統(tǒng)都必須滿足的一套類屬性的需求。

,領域特定的語言(Domain-SpecificLanguage)----用于描

述和分類領域特定構件的詞匯。

?設計和開發(fā)準則(DesignandDevelopment

Guidelines)——基于組成該領域的構架和構件的一個類屬

性的開發(fā)框架。

復用已有的構架和子系統(tǒng)

?檢查構件庫中可復用的構架和子系

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論