2009-11-23 43 views
4

隨着歲月的流逝,我們獲得越來越多的應用。弄清楚一個應用程序是否正在使用來自其他應用程序的功能可能很難。如果我們改變應用程序A中的某些內容,應用程序B中的某些內容會中斷嗎如何記錄應用程序以及它們如何與其他應用程序集成?

我們一直在使用MediaWiki作爲文檔,但很難保持數據是最新的。

我想我們需要的是某種視覺地圖的一切。並有可能創造某種參考完整性?有任何想法嗎?

回答

3

我在同一條船上,仍然試圖在CASE工具Enterprise Architect上銷售我的同事。這是一個往返工具 - 圖示代碼的代碼是可能的。它也是以UML爲中心的 - 儘管它也支持我不熟悉的其他記法方法...

以下是選擇用於記錄設計的工具時需要考慮的一些事項(不管它們是系統間通信還是隻是設計單個應用程序的內部):

  1. 該工具的可用性。也就是說,它不僅容易創建,而且還能維護您感興趣的數據。

  2. 熟悉符號。

    A.符號(如UML)必須是您的員工理解的符號。如果您嘗試使用UML工具與少數人瞭解如何正確使用UML工具,那麼您會遇到一些混淆,因爲有些人錯誤地記錄了事情,而瞭解UML實施內容的人要麼發現錯誤,要麼繼續前進並實施錯誤記錄的項目。相反,專業人員使用的更復雜的符號會混淆不熟悉的人。 B.文件不是/不應僅爲文件專用人員創建。因此,那些將閱讀文檔的人必須瞭解他們正在閱讀的內容。因此,獲得具有靈活輸出選項的工具總是一個不錯的選擇。

  3. 成本。有比Enterprise Architect更先進的工具。我之所以推薦使用這一工具,是因爲缺乏UML熟悉度和高壓時間表,使用基本結構圖來留給自己或同齡人的教育空間不大。這個工具很容易實現這種用途,比StarUML更穩定。 (我嘗試了兩種方式,StarUML在大量代碼的逆向工程中死亡 - 數百萬行)對於小型項目,我發現StarUML足夠用於家庭使用,直到我安裝了Vista。作爲開源,它也是免費的。

綜上所述,您將永遠需要記錄什麼使用什麼,這意味着維護文檔!這項任務是少數公司認識到其價值,儘管對於那些願意這樣做的人具有明顯的價值。 。 。

+0

+1:很棒的小費!但我不確定這個程序是我在找什麼。也許是因爲它看起來像一個非常詳細的應用程序 – Tommy

+1

CASE工具是冗長的,但您不需要使用所有方面。 許多公司經常忽略維護文檔。最後,這是一個平衡的行動,涉及付出的努力。 有一個問題要問自己:如果** Feature X **沒有「完整的」設計文檔,那麼任何人都能夠理解它,並且不會在三年內破壞它? 如果答案是肯定的,那麼吝嗇它是「相對安全」的,而不是忽略它。 *含義**你是對的**,你可以在需要維護時免除額外的加速。* –

+0

我希望有更多的選擇,但這是唯一的一個 – Tommy

相關問題