假設(shè)您公司的CEO 要求您對(duì)公司W(wǎng)eb 開(kāi)發(fā)人員最近開(kāi)發(fā)的250 個(gè)內(nèi)部軟件進(jìn)行檢查，以確定用于構(gòu)建可重用組件庫(kù)的候選功能組件，包括設(shè)計(jì)、代碼和測(cè)試用例。你如何完成這個(gè)任務(wù)？以2009年前后的技術(shù)水平為例。這項(xiàng)任務(wù)并不容易完成。在這250個(gè)軟件應(yīng)用中，約有75個(gè)是功能點(diǎn)不足1000個(gè)的小軟件，它們很可能采用敏捷開(kāi)發(fā)方法，以用戶故事為主要設(shè)計(jì)描述方法，也可能混合使用其他描述方法。對(duì)于單個(gè)軟件應(yīng)用，用戶故事非常有用，但是如果你需要在多個(gè)軟件應(yīng)用中找到共同點(diǎn)，用戶故事就沒(méi)那么有效了。

可能還有50個(gè)左右的軟件是5000多個(gè)功能點(diǎn)的大型商業(yè)軟件。這些軟件很可能使用各種形式化的設(shè)計(jì)描述方法，也可能使用UML方法從聯(lián)合應(yīng)用設(shè)計(jì)（JAD）方法來(lái)描述。收集到的要求。雖然UML 方法可以幫助我們?yōu)閱蝹€(gè)軟件應(yīng)用程序構(gòu)建模型，但考慮到這么多具有不同特征的UML 圖，如果我們想嘗試找出哪些是通用的功能，這仍然不是一件容易或快速的工作。

自動(dòng)化工具，例如靜態(tài)分析工具，可能能夠通過(guò)分析基于UML 的元語(yǔ)言的語(yǔ)法結(jié)構(gòu)來(lái)找到共同模式，但截至2009 年左右，這種技術(shù)在實(shí)踐中尚不可用。在這250個(gè)軟件應(yīng)用中，可能有25個(gè)用于科研項(xiàng)目或工程項(xiàng)目的軟件應(yīng)用，可能使用狀態(tài)變化圖、建模語(yǔ)言（如LePus3語(yǔ)言e、Express語(yǔ)言。）或質(zhì)量功能展開(kāi)（QFD）方法建立“質(zhì)量屋”圖和許多其他建筑建模元語(yǔ)言。

其余100 個(gè)軟件應(yīng)用程序可能使用了多種描述方法。包括但不限于用例、UML 方法、N-S 圖、Jackson Design、流程圖、決策表、數(shù)據(jù)流圖、HIPO 圖和各種其他方法。其中一些方法可能會(huì)定義模型，但即使掃描100 個(gè)項(xiàng)目的支票也不是一件容易的事。

綜上所述，這250 個(gè)新開(kāi)發(fā)的軟件應(yīng)用程序使用了50 多種不同的設(shè)計(jì)語(yǔ)言和方法，并且對(duì)于其中的大部分。相互轉(zhuǎn)換是一項(xiàng)非常困難的工作。同時(shí)，這些語(yǔ)言和方法也很難被自動(dòng)化驗(yàn)證工具和自動(dòng)化錯(cuò)誤檢查工具處理。

我們專注高端建站，小程序開(kāi)發(fā)、軟件系統(tǒng)定制開(kāi)發(fā)、BUG修復(fù)、物聯(lián)網(wǎng)開(kāi)發(fā)、各類API接口對(duì)接開(kāi)發(fā)等。十余年開(kāi)發(fā)經(jīng)驗(yàn)，每一個(gè)項(xiàng)目承諾做到滿意為止，多一次對(duì)比，一定讓您多一份收獲！