2015-01-09 44 views
0

我想在編寫一些代碼之前知道我的應用程序。我已經創建了要使用的所有類的類圖,然後使用Astah從它們生成代碼。保持類圖和代碼同步

當我想要更改某個類的方法或添加一個新類時,會發生此問題。我應該這樣做兩次:一次在類圖中,一次在源代碼中。這種進展正在進行,我的班級圖很容易過時。

有沒有辦法避免這種情況?我可以更新活動圖中已有的代碼嗎?

預先感謝您

+0

「我太懶了」對其他人不太有幫助。爲什麼你有人會/應該幫助_lazy_人?提示:在[uml]標記的舊問題中搜索「逆向工程」,使用您使用的編程語言過濾 – xmojmr 2015-01-10 06:23:51

+0

實際上,這是編程中兩次做同樣事情的非常糟糕的做法,所以我希望人們能理解。儘管如此,謝謝你的提示。我會檢查的。 – 2015-01-10 08:53:08

+0

我沒有在編程中提出代碼重用的問題。我質疑你自己顯示的研究成果(如http://stackoverflow.com/help/how-to-ask)。優化和重視你的資源(生活,時間),但不要懶惰,不要要求別人做你的工作。如果沒有指定語言並顯示您正在討論的代碼和圖表的某些部分,則此問題太廣泛且太抽象。另見http://agilemodeling.com/essays/bestPractices.htm – xmojmr 2015-01-10 09:10:57

回答

0

爲了回答你的問題,在我看來,有關考慮使用UML的方式。

UML distilled,Martin Fowler的考慮使用UML的方法有三種:

  1. 素描
  2. 藍圖
  3. 可執行UML

1素描

草圖使用UML方便refactoring節目,練習福勒是seriously interested in。一般來說,對現有程序有一個綜合的看法是適當的。

2.藍圖

藍圖是在某種程度上學術界使用的語言。主要問題在於軟件的演變:模型必須重新編碼,不要成爲遺留問題。

3.可執行UML

可執行UML是一種在其成爲表達的用於節目的主要途徑的語言的極端實踐的。在這種情況下,程序通常由包含所有軟件信息的初始UML模型生成。源代碼只是軟件的轉換形式。該軟件隨模型演變,再次生成代碼。這隻有通過完整的軟件UML建模才能實現。簡而言之,這是對UML的徹底使用。

我認爲這三種使用UML的方式之間的區別是對UML一般用法的一個相關考慮。

UML作爲源代碼修改

的界面不過我明白你在找什麼:應該有使用UML,作爲修改源代碼的接口的另一個(第四)的方式。存在一些解決方案,但都不是很方便,這裏是我所確定的舉措:

  • Green UML是一個Eclipse插件,由布法羅大學使用它自己的類圖編輯器
  • Code Canvas是研究課題由微軟,不是UML但有趣的,一篇文章是the ACM communications
  • BlueJ可以是一個很輕的IDE包括類圖編輯器修改源代碼
  • Coffea UML是一個個人項目

這裏有幾個關於Coffea的文字。其目的是將Eclipse JDT重構功能鏈接到Eclipse UML2Tools圖編輯器。它在類圖編輯器中正常工作。我的目標是將其擴展到活動圖。不幸的是,從那以後,UML2Tools已經成爲傳統。 Coffea並沒有死,而是差不多。我已經從UML2Tools編輯器中分離了核心UML2函數。我的意圖在項目現場詳細說明。然而,我在業餘時間上工作,我還有其他職業。

當且僅當修改僅在一個方面(例如行爲或結構)時,UML纔可用作源代碼修改的接口。在Executable UML範圍之外的軟件的全面版本是不可能的。爲這樣的目的而設想的編輯將是多個圖的組合,這將是非常複雜的。這樣的編輯器應該接近福勒描述的草圖模式。

結論

不幸的是,我認爲,UML作爲修改源代碼的接口是目前一些理論。主要的挑戰是將修改與初始UML模型(您的案例)相集成。鑑於各種UML工具,我認爲Fowler對UML的使用是唯一嚴肅的解決方案。看來你只能使用Astah作爲Executable UML。我甚至不確定該工具是否提供了所有這些功能。

+0

謝謝您的回覆,可能是我需要改變我的做法。 – 2015-01-13 15:11:58

+0

這取決於你,UML和代碼之間的關係並不明顯。在我看來,UML工具應該更傾向於使用更適合於日復一日的繪圖。很少有組織接受藍圖模式,很少有狂熱者會關注可執行的UML。結果是UML在企業發展中的使用很差。請讓我知道你將如何管理你的建模... – bdulac 2015-01-13 15:25:41