基于構件的軟件開(kāi)發(fā)前景分析（基于構件的軟件開(kāi)發(fā)的優勢是什麼(me)?面(miàn)臨哪些挑戰和困難）
今天給各位分享基于構件的軟件開(kāi)發(fā)前景分析的知識，其中也會(huì)對(duì)基于構件的軟件開(kāi)發(fā)的優勢是什麼(me)?面(miàn)臨哪些挑戰和困難進(jìn)行解釋，如果能(néng)碰巧解決你現在面(miàn)臨的問題，别忘了關注本站，現在開(kāi)始吧！
本文目錄一覽：
- 1、基于構件的軟件開(kāi)發(fā)方法
- 2、有關軟件的一些問題！我也知道(dào)問題多 ！盡量解答還(hái)有加分！不差分！屬于保險行業應用軟件
- 3、軟件開(kāi)發(fā)就業前景如何？
- 4、解釋爲什麼(me)基于構件的軟件開(kāi)發(fā)提高了軟件開(kāi)發(fā)的生産效率
- 5、基于構件應用開(kāi)發(fā)的優點有哪些?
- 6、構件化的軟件開(kāi)發(fā)方法是什麼(me)?
基于構件的軟件開(kāi)發(fā)方法
基于構件的軟件開(kāi)發(fā)(cBSD，ComponentBasedsoftwareDevelopment)是以構件爲組裝藍圖，以可複用軟件構件爲組裝模塊，支持組裝式複用，以提高軟件生産效率和軟件産品質量的有效途徑。它包含了系統分析、構造、維護和擴展的各個方面(miàn)，這(zhè)些方面(miàn)都(dōu)是以構件方法爲核心的。
軟件構件技術以及基于構件的軟件開(kāi)發(fā)方法，與傳統軟件工程方法有所不同，它不僅僅針對(duì)某個具體的工程項目，而更多地是針對(duì)某一行業領域的共性需求，利用領域工程方法，將(jiāng)多年積累的行業經(jīng)驗進(jìn)行總結，提煉出業務模型、特定領域的系統架構、構件庫等，這(zhè)樣(yàng)開(kāi)發(fā)出來的架構和構件封裝了業務的個性和變化性，具有此領域的共同特點，在此領域有很高的可複用性。有了這(zhè)樣(yàng)的積累之後(hòu)，整個應用軟件的生産方式將(jiāng)發(fā)生很大的改變，將(jiāng)不再是從頭做起(qǐ)。而是以“構件組裝”的方式生産出軟件應用系統。軟件系統的質量、複用率和開(kāi)發(fā)效率都(dōu)得到大幅提高。
軟件構件技術要想在實際工作得到有效利用，需要有一些平台軟件來支撐，這(zhè)就是我們所說的軟件構件技術的支撐平台四要素，即構件運行支撐環境、構件開(kāi)發(fā)／組裝環境、構件管理環境和基于構件的開(kāi)發(fā)方法和過(guò)程。
有關軟件的一些問題！我也知道(dào)問題多 ！盡量解答還(hái)有加分！不差分！屬于保險行業應用軟件
1.軟件可分爲這(zhè)樣(yàng)三個層次:一是基礎軟件，包括了操作系統軟件、中間件軟件、數據庫以及辦公套間等通用型應用軟件，二是企業應用軟件，三是軟件服務。辦公應用類有金山WPS Office，還(hái)有像瑞星，江民等國(guó)産殺毒軟件。
2.一、軟件生産方式的變革
由于軟件開(kāi)發(fā)的系統越來越大，涉及的領域越來越廣，用戶的需求也在不斷變化，這(zhè)使軟件企業不能(néng)再像原來一樣(yàng)，僅僅依靠一些人從零開(kāi)始，從編碼到設計一杆子做到底。
構件技術的出現是對(duì)傳統軟件開(kāi)發(fā)過(guò)程的一次變革。構築在“構件組裝”模式之上的構件技術，使軟件技術人員擺脫了“一行行寫代碼”的低效編程方式，直接進(jìn)入“組裝構件”的更高階段。
基于構件的軟件開(kāi)發(fā)，不僅使軟件産品在客戶需求吻合度、上線時間、軟件質量上領先于同類産品，提高了項目的成(chéng)功率，而且對(duì)軟件的開(kāi)發(fā)和維護變得十分簡單，客戶可以随時随地應對(duì)商業環境變化和IT技術變化，實現“敏捷定制”。
從最終用戶的角度來看，采用基于構件技術搭建的系統，在遇到業務流程變革或系統升級等問題時，不再需要對(duì)系統進(jìn)行大規模改造或推倒重來，隻需對(duì)構件進(jìn)行“拖、拉、拽”的方式，使之重新排列、組合，就可以組裝成(chéng)新的系統，或者通過(guò)增加新的構件、改造原來的構件來實現。由于不用在代碼層進(jìn)行一個個改編和測試，因此可以很快開(kāi)發(fā)出新的系統。
據有關調查機構統計顯示，構件技術可以使軟件的投放市場時間縮短到原來的1/2到1/5，使軟件的缺陷密度降低到原來的1/5到1/10，使軟件的維護成(chéng)本降低到原來的1/5到1/10，使整體軟件的開(kāi)發(fā)成(chéng)本降低大約15%，甚至長(cháng)期項目可降低高達75%的成(chéng)本。
從我國(guó)整個軟件産業來看，無論是大的軟件企業還(hái)是小的軟件企業，目前很多都(dōu)在做ERP。如果采用構件技術，小企業可以隻做某些模塊的構件，而大企業負責組裝構件。這(zhè)樣(yàng)，小企業就可以把構件賣給大企業，不僅大企業的成(chéng)本降低了，小企業也能(néng)從中賺取利潤。現在，國(guó)際上大的軟件企業就是通過(guò)這(zhè)種(zhǒng)方式把一些軟件工程的一部分外包給小企業，從而提高生産效率，提升規模化生産能(néng)力。
在這(zhè)種(zhǒng)新的軟件開(kāi)發(fā)方式下，軟件公司將(jiāng)以開(kāi)發(fā)構件爲主要業務，提供規格化的軟部件。系統集成(chéng)商則彙總部件，組合成(chéng)能(néng)完成(chéng)不同功能(néng)的軟構件，將(jiāng)自己的核心技術構件化。正是這(zhè)兩(liǎng)者之間分工的泾渭分明，將(jiāng)軟件行業工業化逐漸推向(xiàng)成(chéng)功。可以想像，未來的軟件産業將(jiāng)劃分爲三種(zhǒng)業态：
第一個是構件業，類似傳統産業的零部件，這(zhè)些構件是可以買賣的。國(guó)家工程研究中心的構件庫現在已經(jīng)具備了這(zhè)樣(yàng)的職能(néng)。
第二個是集成(chéng)組裝業，相當于汽車工廠，根據市場的需要先設計汽車的款型，然後(hòu)到市場上采購通用零部件，特别需求還(hái)可以委托專門生産零部件的企業去設計生産，最後(hòu)把這(zhè)些零部件組裝在一起(qǐ)。
第三個是服務業，基于互聯網平台上的軟件服務是當前正在推行的一種(zhǒng)軟件應用模式，未來這(zhè)種(zhǒng)應用將(jiāng)更加普遍。
這(zhè)是一個美好(hǎo)而且不很遙遠的想象，也許幾年之内就可能(néng)實現。
在我國(guó)，構件化軟件的探索也在繼續前行。2004年3月，北京大學(xué)軟件工程國(guó)家工程研究中心啓動了“軟件構件庫系統應用示範”項目，通過(guò)對(duì)四家企業在典型應用領域的項目實施構件化改造，提煉了一批領域、行業或通用的構件。
2004年5月，北京軟件行業協會(huì)、北京軟件産業促進(jìn)中心、北京大學(xué)軟件工程國(guó)家工程研究中心和北京軟件産品質量檢測檢驗中心，共同組織開(kāi)展了“北京第一屆優秀軟件構件評選活動”，進(jìn)一步推行基于構件的軟件開(kāi)發(fā)方法，豐富公共構件庫系統的資源。
二、什麼(me)是軟件構件？
工業化革命的偉大創新在于，功能(néng)再複雜的産品都(dōu)可以由大量标準的零部件組裝而成(chéng)。分工越細、專業生産程度越高，總體生産效率就越高。
構件技術就是一種(zhǒng)類似于“零部件組裝”集成(chéng)組裝式的軟件生産方式。它把零件、生産線和裝配運行的概念運用在軟件産業中，徹底打破了手工作坊式的軟件開(kāi)發(fā)模式。
構件是軟件的構成(chéng)元素，構件具有一定的功能(néng)和結構，并符合一定的标準，可以完成(chéng)一個或多個特定的服務，構件隐藏了具體的實現，通過(guò)接口對(duì)外提供服務。
一般而言，構件是軟件系統中具有相對(duì)獨立功能(néng)，可以明确辨識、接口由契約指定、和語境有明顯依賴關系、可獨立部署、可組裝的軟件實體，并且可以重複使用。廣義上講，構件可以是數據，也可以是被(bèi)封裝的對(duì)象類、軟件構架、文檔、測試用例等。
軟件構件庫作爲一種(zhǒng)支持軟件複用的基礎設施和軟件資産的管理設施，它提供對(duì)軟件構件的描述、分類、存儲和檢索等功能(néng)，它爲基于構件的軟件開(kāi)發(fā)提供了有效的支持，提高了軟件開(kāi)發(fā)效率和軟件産品質量。
建立具有豐富構件資源且統一的軟件構件庫，是當前國(guó)内推行構件技術要解決的關鍵問題，也是北京大學(xué)軟件工程國(guó)家工程研究中心現在正在做的事(shì)情。該中心目前正在建立一個完整的構件庫體系。該體系包含了省市級的構件庫、地區級的構件庫、不同軟件企業的構件庫，并且不同構件庫之間具有統一的标準規範。
3.SOA從字面(miàn)上理解就是面(miàn)向(xiàng)服務的體系架構。實際上我們用很通俗的話就是說怎麼(me)樣(yàng)符合在因特網架構下，怎麼(me)樣(yàng)服務實施者和調用者之間建立很簡易的調用關系。這(zhè)時候用簡單的包裝方式去調用一定的服務，然後(hòu)拿來完成(chéng)一個服務平台，這(zhè)種(zhǒng)模式就是以核心平台向(xiàng)遠端調動服務的體系我們叫(jiào)做SOA。（詳細：）
4.業務模型是分别從業務過(guò)程和客戶對(duì)應的業務狀況和業務參與者的角度來描述系統的業務過(guò)程。業務建模很重要的一點是在分析企業流程的同時，分析出基礎業務對(duì)象，在學(xué)校圖書館裡(lǐ)系統中，基礎業務對(duì)象有三個：對(duì)這(zhè)、圖書、管理人員。圖書管理、借書、還(hái)書等十系統的基礎業務。（業務模型到系統：）
因爲字數的限制，所以剩下的部分答案到我的空間裡(lǐ)去看吧。
軟件開(kāi)發(fā)就業前景如何？
據我所知，前景不錯的哦！就比如基于低代碼平台的軟件開(kāi)發(fā)，
一、實現以下幾點優勢
從企業角度來說，優化流程，提升企業運行效率；節省成(chéng)本，提高企業效益；維護方便，即改即用；一鍵升級，方便實用；
從開(kāi)發(fā)者角度來說，圖形化操作，容易上手；提供成(chéng)熟案例模闆庫，不用從零開(kāi)始；支持主流應用服務器和數據庫，降低開(kāi)發(fā)難度；接口豐富，節省開(kāi)發(fā)時間；強大的代碼調試功能(néng)，提高開(kāi)發(fā)效率；
從使用者角度來說，操作簡單、友好(hǎo)、人性化；消息驅動，合理利用工作時間；即改即用，優化完善軟件功能(néng)；多客戶端入口，随時随地辦公；
二、低代碼核心能(néng)力
基于上述的定義和分析，不難總結出如下這(zhè)3條低代碼開(kāi)發(fā)平台的核心能(néng)力：
01、全棧可視化編程：
可視化包含兩(liǎng)層含義，一個是編輯時支持的點選、拖拽和配置操作，另一個是編輯完成(chéng)後(hòu)所見即所得（WYSIWYG）的預覽效果。傳統代碼IDE也支持部分可視化能(néng)力（如早年Visual Studio的MFC/WPF），但低代碼更強調的是全棧、端到端的可視化編程，覆蓋一個完整應用開(kāi)發(fā)所涉及的各個技術層面(miàn)（界面(miàn)/數據/邏輯）。
通過(guò)可視化的界面(miàn)編輯器，面(miàn)向(xiàng)業務的界面(miàn)設計能(néng)力爲傳統開(kāi)發(fā)者以外的更多應用參與者提供服務。JNPF的可視化設計，不僅僅實現拖拽設計，更重要的是拓寬了使用者範圍，讓更多不同知識背景的公民開(kāi)發(fā)者來完成(chéng)應用構建（包括但不限于用戶界面(miàn)、業務流程、審批過(guò)程、業務邏輯），讓更多角色參與到應用構建過(guò)程中。
02、全生命周期管理：
作爲一站式的應用開(kāi)發(fā)平台，低代碼支持應用的完整生命周期管理，即從設計階段開(kāi)始（有些平台還(hái)支持更前置的項目與需求管理），曆經(jīng)開(kāi)發(fā)、構建、測試和部署，一直到上線後(hòu)的各種(zhǒng)運維（e.g. 監控報警、應用上下線）和運營（e.g. 數據報表、用戶反饋）。
應用構建從需求輸入開(kāi)始，經(jīng)過(guò)分析、設計、開(kāi)發(fā)、測試、發(fā)布上線公有雲 / 專屬化出盤交付私有化項目的開(kāi)發(fā)過(guò)程，到發(fā)布後(hòu)的運維、運營，再到問題反饋和新的需求再次形成(chéng)需求輸入，形成(chéng)了一個基于JNPF閉環的全生命周期管理。
在該閉環中，會(huì)涉及到産品經(jīng)理、需求分析師、架構師、開(kāi)發(fā)人員、測試人員、運維人員、運營人員、技術支持人員等各種(zhǒng)各樣(yàng)的角色本職工作和協作工作，JNPF 開(kāi)發(fā)平台必須要具備全生命周期特性，才能(néng)真正達到從整體把控應用開(kāi)發(fā)全過(guò)程，實現快速交付、降低開(kāi)發(fā)成(chéng)本的目标。
03、低代碼擴展能(néng)力：
使用低代碼開(kāi)發(fā)時，大部分情況下仍離不開(kāi)代碼，因此平台必須能(néng)支持在必要時通過(guò)少量的代碼對(duì)應用各層次進(jìn)行靈活擴展，比如添加自定義組件、修改主題CSS樣(yàng)式、定制邏輯流動作等。
解釋爲什麼(me)基于構件的軟件開(kāi)發(fā)提高了軟件開(kāi)發(fā)的生産效率
摘要
基于構件的軟件複用和開(kāi)發(fā)被(bèi)認爲是提高軟件開(kāi)發(fā)效率和質量的有效途徑,并在分布式系統中得到了廣泛的應用.但是,目前的軟件構件技術主要還(hái)是著(zhe)眼于構件實現模型和運行時互操作,缺乏一套系統的方法以指導整個開(kāi)發(fā)過(guò)程.近年來,以構件爲基本單元的軟件體系結構研究取得了較大的發(fā)展.它通過(guò)對(duì)軟件系統整體結構和特性的描述,爲面(miàn)向(xiàng)構件的軟件開(kāi)發(fā)提供了一個自頂向(xiàng)下的途徑.介紹了一種(zhǒng)以軟件體系結構爲指導,面(miàn)向(xiàng)構件的軟件開(kāi)發(fā)方法,試圖爲基于構件的軟件複用提供一種(zhǒng)有效的解決方案.這(zhè)種(zhǒng)方法主要是將(jiāng)軟件體系結構引入到軟件開(kāi)發(fā)的各個階段,作爲系統開(kāi)發(fā)的藍圖,利用工具支持的自動轉換機制縮小從高層設計到實現的距離,而後(hòu)在構件平台的運行支持下實現自動的系統組裝生成(chéng).
基于構件應用開(kāi)發(fā)的優點有哪些?
構件的最大優點是重用，軟件之所以那麼(me)難做，就是難以重用。這(zhè)方面(miàn)硬件要好(hǎo)得多，硬件容易重用，CPU、存儲器、硬盤、光驅、顯示器等等都(dōu)可以重用，將(jiāng)它們裝配在一起(qǐ)就成(chéng)了一台新計算機。軟件就很難達到這(zhè)樣(yàng)的重用程度，構件的出現是一個進(jìn)步
另外補充一下，通過(guò)一些特殊的處理，如dll動态鏈接庫的應用，提高了程序的執行效率，即：當需要某部分功能(néng)時才載入某個dll庫，使程序具備了比較好(hǎo)的伸縮和可擴展性，當某個功能(néng)發(fā)生變動時，隻需要更新相應的dll文件即可
構件化的軟件開(kāi)發(fā)方法是什麼(me)?
與傳統的軟件開(kāi)發(fā)方式相比，基于構件的軟件開(kāi)發(fā)方法有什麼(me)突破呢？ 一、體系結構 軟件體系結構代表了系統公共的高層次的抽象，它是系統設計成(chéng)敗的關鍵。其設計的核心是能(néng)否使用重複的體系模式。傳 統的應用系統體系結構從基于主機的集中式框架，到在網絡的客戶端上通過(guò)網絡訪問服務器的框架，都(dōu)不能(néng)适應目前企業所處的商業環境，原因是： 企業過(guò)分地依賴于某個供應商的軟件和硬件産品。這(zhè)種(zhǒng)單一供應商使得企業難以利用計算供應商的免費市場，將(jiāng)計算基礎設施的重要決定交給第三方處理，這(zhè)顯然不利于企業在合作夥伴之間共享信息。 不能(néng)适應遠程訪問的分布式、多層次異構系統。 封裝的應用系統在出現某種(zhǒng)組織需要時，難以用定制來維護系統，從而難以滿足多變的需求。 不能(néng)實現分析、設計核心功能(néng)重用，最多隻能(néng)實現代碼重用。 如今，應用系統已經(jīng)發(fā)展成(chéng)爲在Intranet和Internet上的各種(zhǒng)客戶端可遠程訪問的分布式、多層次異構系統。CBSD爲開(kāi)發(fā)這(zhè)樣(yàng)的應用系統提供了新的系統體系結構。它是标準定義的、分布式、模塊化結構，使應用系統可分成(chéng)幾個獨立部分開(kāi)發(fā)，可用增量方式開(kāi)發(fā)。 這(zhè)樣(yàng)的體系結構實現了CBSD的以下幾點目标: 能(néng)夠通過(guò)内部開(kāi)發(fā)的、第三方提供的或市場上購買的現有構件，來集成(chéng)和定制應用軟件系統。 鼓勵在各種(zhǒng)應用系統中重用核心功能(néng),努力實現分析、設計的重用。 系統都(dōu)應具有靈活方便的升級和系統模塊的更新維護能(néng)力。 封裝最好(hǎo)的實踐案例，并使其在商業條件改變的情況下，還(hái)能(néng)夠被(bèi)采用，并能(néng)保留已有資源。 由此看出,CDSD從系統高層次的抽象上解決了複用性與異構互操作性，這(zhè)正是分布式網絡系統所希望解決的難題。 二、開(kāi)發(fā)過(guò)程 傳統的軟件開(kāi)發(fā)過(guò)程在重用元素、開(kāi)發(fā)方法上都(dōu)與CBSD有很大的不同。雖然面(miàn)向(xiàng)對(duì)象技術促進(jìn)了軟件重用，但是，隻實現了類和類繼承的重用。在整個系統和類之間還(hái)存在很大的缺口。爲填補這(zhè)個缺口，人們曾想了許多方法，如系統體系結構、框架、設計模式等。 自從構件出現以來，軟件的重用才得到了根本改變。CBSD實現了分析、設計、類等多層次上的重用。圖1顯示了它的重用元素分層實現。在分析抽象層上，重用元素有子系統、類；在設計層上重用元素有系統體系結構、子系統體系結構、設計模式、框架、容器、構件、類庫、模闆、抽象類等。 在軟件開(kāi)發(fā)方法上，CBSD引導軟件開(kāi)發(fā)從應用系統開(kāi)發(fā)轉變爲應用系統集成(chéng)。建立一個應用系統需要重用很多已有的構件模塊，這(zhè)些構件模塊可能(néng)是在不同的時間、由不同的人員開(kāi)發(fā)的，并有各種(zhǒng)不同的用途。在這(zhè)種(zhǒng)情況下，應用系統的開(kāi)發(fā)過(guò)程就變成(chéng)對(duì)構件接口、構件上下文以及框架環境一緻性的逐漸探索過(guò)程。例如，在J2EE平台上，用EJB框架開(kāi)發(fā)應用系統，主要工作是將(jiāng)應用邏輯,按session Bean、entity Bean設計開(kāi)發(fā),并利用JTS事(shì)務處理的服務實現應用系統。其主要難點是事(shì)務劃分、構件的部署與開(kāi)發(fā)環境配置。概括地說，傳統的軟件開(kāi)發(fā)過(guò)程是串行瀑布式、流水線的過(guò)程;而CBSD是并發(fā)進(jìn)化式，不斷升級完善的過(guò)程。圖2顯示了它們的不同。 三、軟件方法學(xué) 軟件方法學(xué)是從各種(zhǒng)不同角度、不同思路去認識軟件的本質。傳統的軟件方法學(xué)是從面(miàn)向(xiàng)機器、面(miàn)向(xiàng)數據、面(miàn)向(xiàng)過(guò)程、面(miàn)向(xiàng)功能(néng)、面(miàn)向(xiàng)數據流、面(miàn)向(xiàng)對(duì)象等不斷創新的觀點反映問題的本質。整個軟件的發(fā)展曆程使人們越來越認識到應按客觀世界規律去解決軟件方法學(xué)問題。直到面(miàn)向(xiàng)對(duì)象方法的出現，才使軟件方法學(xué)邁進(jìn)了一大步。但是，高層次上的重用、分布式異構互操作的難點還(hái)沒(méi)有解決。CBSD發(fā)展到今天，才在軟件方法學(xué)上爲解決這(zhè)個難題提供了機會(huì)。它把應用業務和實現分離，即邏輯與數據的分離，提供标準接口和框架，使軟件開(kāi)發(fā)方法變成(chéng)構件的組合。因此，軟件方法學(xué)是以接口爲中心，面(miàn)向(xiàng)行爲的設計。圖3是其開(kāi)發(fā)過(guò)程。 歸納起(qǐ)來，CBSD的軟件開(kāi)發(fā)方法學(xué)應包括下面(miàn)幾方面(miàn)： 對(duì)構件有明确的定義。 基于構件的概念需要有構件的描述技術和規範，如UML、JavaBean、EJB、Servlet規範等。 開(kāi)發(fā)應用系統必須按構件裁剪劃分組織，包括分配不同的角色。 有支持檢驗構件特性和生成(chéng)文檔的工具，确保構件規範的實現和質量測試。 總之，傳統的軟件方法學(xué)從草稿自頂向(xiàng)下進(jìn)行，對(duì)重用沒(méi)有提供更多的輔助。CBSD的軟件方法學(xué)要豐富得多，它是即插即用，基于體系結構，以接口爲中心，將(jiāng)構件有機組合，它把自頂向(xiàng)下和自底向(xiàng)上方法結合起(qǐ)來進(jìn)行開(kāi)發(fā)。 四、開(kāi)發(fā)組織機構 傳統軟件的開(kāi)發(fā)組織一般由分析員、設計員、程序員和測試員組成(chéng)。對(duì)一個小的應用系統來說，一個熟練的開(kāi)發(fā)人員，可能(néng)兼顧以上多個角色。但對(duì)CBSD來說,因爲構件開(kāi)發(fā)與應用系統集成(chéng)往往是分開(kāi)進(jìn)行的，因此整個開(kāi)發(fā)過(guò)程由六個角色來完成(chéng)，他們是: 構件開(kāi)發(fā)者 也是構件供貨商，這(zhè)些大多數是中間件構件提供(續緻信網上一頁内容)者。 應用構件集成(chéng)者 針對(duì)某應用領域將(jiāng)已有構件組合成(chéng)更大的構件模塊或容器， 作爲系統部署的基本單元。 應用系統部署者 將(jiāng)系統部署基本單元放入選定的平台環境或基本框架中，完成(chéng)軟件定制的要求。 開(kāi)發(fā)平台服務器供應商 提供服務器、操作系統和數據庫等基本軟件。 應用系統開(kāi)發(fā)工具供應商 提供構件公共設施服務。 系統管理員 配置硬件、網絡和操作系統，監督和維護應用系統者。 這(zhè)六個角色的工作專業性很強，要兼顧成(chéng)爲多面(miàn)手很不容易。目前已形成(chéng)構件開(kāi)放市場，而且還(hái)很火紅。這(zhè)也是當今軟件人才大戰所遇的一個困惑。因此，在CBSD中，如何組織好(hǎo)開(kāi)發(fā)隊伍尤爲重要，必須按本企業所具備人才來組織。特别重要的是:開(kāi)發(fā)初期必須選好(hǎo)标準框架，以及統一的開(kāi)發(fā)指導方針，保證在整個開(kāi)發(fā)過(guò)程中,各角色能(néng)随時互相溝通。一般來說，CBSD的人員素質決定了構件的重用率。 五、構造方法 傳統應用軟件的構造是用白盒子方法，應用系統的實現全在代碼中，應用邏輯和數據粘結在一起(qǐ)。而CBSD 的構造是用白盒子和黑盒子相結合的方法。 基于構件的框架是用兩(liǎng)個概念來支持演變：第一個概念是構件有很強的性能(néng)接口，使構件邏輯功能(néng)和構件模型的實現都(dōu)隐藏起(qǐ)來。這(zhè)樣(yàng)，隻要接口相同，構件就可以被(bèi)替換。 第二個概念是隐式調用，即在基于構件的框架中，從來不直接給構件的接口分配地址，隻在識别構件用戶後(hòu)才分配地址。因此，構件用戶隻要了解接口要求和爲構件接口提供的引用後(hòu)的返回信息 (該引用可能(néng)是一個構件，也可能(néng)是一個構件代理。對(duì)構件用戶來說，構件代理就是構件，不用區分) 。 構件接口的信息并不存入構件内，而是存入構件倉庫或注冊處。這(zhè)樣(yàng)才能(néng)保證構件替換靈活，并很容易利用隐式調用去重新部署構件。由于構件的實現對(duì)用戶透明，因此也使構件能(néng)适應各種(zhǒng)不同的個性化要求。爲此，構件提供自檢和規範化兩(liǎng)個機制。自檢保證在不了解構件的具體實現時，就能(néng)獲得構件接口信息。例如，JavaBean提供的自檢機制是Reflection和BeanInfo， 通過(guò)Reflection 可直接獲得Bean構件的全部方法，通過(guò)BeanInfo可直接獲得構件的許多複雜信息。 規範化允許不訪問構件就可以修改它，如JavaBean提供的規範化是property sheet和customizer(定制器)。 通過(guò)property sheet提供一組簡單參數，修改Bean的屬性。複雜的修改由用戶通過(guò)定制器設置參數完成(chéng)。
基于構件的軟件開(kāi)發(fā)前景分析的介紹就聊到這(zhè)裡(lǐ)吧，感謝你花時間閱讀本站内容，更多關于基于構件的軟件開(kāi)發(fā)的優勢是什麼(me)?面(miàn)臨哪些挑戰和困難、基于構件的軟件開(kāi)發(fā)前景分析的信息别忘了在本站進(jìn)行查找喔。
