假設您公司的CEO 要求您對公司Web 開發人員最近開發的250 個內部軟件進行檢查,以確定用于構建可重用組件庫的候選功能組件,包括設計、代碼和測試用例。你如何完成這個任務?以2009年前后的技術水平為例。這項任務并不容易完成。在這250個軟件應用中,約有75個是功能點不足1000個的小軟件,它們很可能采用敏捷開發方法,以用戶故事為主要設計描述方法,也可能混合使用其他描述方法。對于單個軟件應用,用戶故事非常有用,但是如果你需要在多個軟件應用中找到共同點,用戶故事就沒那么有效了。
可能還有50個左右的軟件是5000多個功能點的大型商業軟件。這些軟件很可能使用各種形式化的設計描述方法,也可能使用UML方法從聯合應用設計(JAD)方法來描述。收集到的要求。雖然UML 方法可以幫助我們為單個軟件應用程序構建模型,但考慮到這么多具有不同特征的UML 圖,如果我們想嘗試找出哪些是通用的功能,這仍然不是一件容易或快速的工作。
自動化工具,例如靜態分析工具,可能能夠通過分析基于UML 的元語言的語法結構來找到共同模式,但截至2009 年左右,這種技術在實踐中尚不可用。在這250個軟件應用中,可能有25個用于科研項目或工程項目的軟件應用,可能使用狀態變化圖、建模語言(如LePus3語言e、Express語言。)或質量功能展開(QFD)方法建立“質量屋”圖和許多其他建筑建模元語言。
其余100 個軟件應用程序可能使用了多種描述方法。包括但不限于用例、UML 方法、N-S 圖、Jackson Design、流程圖、決策表、數據流圖、HIPO 圖和各種其他方法。其中一些方法可能會定義模型,但即使掃描100 個項目的支票也不是一件容易的事。
綜上所述,這250 個新開發的軟件應用程序使用了50 多種不同的設計語言和方法,并且對于其中的大部分。相互轉換是一項非常困難的工作。同時,這些語言和方法也很難被自動化驗證工具和自動化錯誤檢查工具處理。
我們專注高端建站,小程序開發、軟件系統定制開發、BUG修復、物聯網開發、各類API接口對接開發等。十余年開發經驗,每一個項目承諾做到滿意為止,多一次對比,一定讓您多一份收獲!