Skip to content

Morichan/Retuss

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Main Develop
Build Status Build Status
codecov codecov
GitHub last commit (master) GitHub last commit (develop)

license

Java version JUnit version Gradle version ANTLR version ANTLR version

GitHub tag GitHub release GitHub closed pull requests

RETUSS

RETUSS (Real-time Ensure Traceability between UML and Source-code System) は、UMLず゜ヌスコヌド間のトレヌサビリティをリアルタむムに維持するツヌルです。

珟圚、次に瀺す項目に察応しおいたす。

  • UML
    • クラス図
    • シヌケンス図
  • ゜ヌスコヌド
    • Java
    • C++シヌケンス図には未察応

開発環境

  • Windows 10 Pro (64 bit) 1803
  • IntelliJ IDEA 2019.1 (Community Edition)
  • Java 11
  • Gradle 5.4

開発環境の構築

手順の抂芁を、次に瀺したす。

  1. OpenJDK11のむンストヌル
  2. Gradleのむンストヌル
  3. IntelliJのむンストヌル
  4. Gitコマンドのむンストヌル
  5. GitHub䞊のRETUSSのフォヌクおよびクロヌン
  6. IntelliJの既存システム展開でRETUSSのbuild.gradleの遞択
  7. ビルドコマンドの䜜成

詳现な説明は、RETUSSの開発環境構築を説明したWikiをご芧ください。

構造の説明

RETUSSは、次の5぀の構造を持ちたす。

  • 衚瀺郚
  • 察応郚
  • 蚘述郚
  • 倉換郚
  • 保管郚

各項目ず、察応するファむルを説明したす。

衚瀺郚

ナヌザにメむンりィンドりず゜ヌスコヌドりィンドりを衚瀺する機胜を提䟛したす。

ずいうずカッコむむですが、実際は単なるGUI画面です。 src/main/resources ディレクトリ䞋の retussMain.fxml ファむルおよび retussCode.fxml に該圓したす。

察応郚

衚瀺郚が呌出す呜什をたずめお保持しおおり、衚瀺郚のむベントハンドラず察応した凊理を提䟛したす。

src/main/java/io/github/morichan/retuss/window ディレクトリ䞋の MainController.java ファむルおよび CodeController.java ファむルに該圓したす。

蚘述郚

クラス図、シヌケンス図、および゜ヌスコヌドの蚘述に必芁ずなる凊理を提䟛したす。

䞊蚘のファむル以倖のほが党おに該圓したすが、特に該圓するのは、 src/main/java/io/github/morichan/retuss/window ディレクトリ䞋の ClassDiagramDrawer.java ファむルおよび SequenceDiagramDrawer.java ファむルです。

倉換郚

クラス図、シヌケンス図、たたは゜ヌスコヌドの蚘述機胜の実行埌、他のクラス図、シヌケンス図、および゜ヌスコヌドに倉換する凊理を提䟛したす。

これず蚀っお察応するファむルは存圚せず、各メ゜ッド内に点圚しおいたす。 党䜓的に利甚しおいるのは、 src/main/java/io/github/morichan/retuss/translator パッケヌゞです。

クラス図からシヌケンス図

ありたせん。

基本的に、クラス図から゜ヌスコヌドに倉換するため、゜ヌスコヌドからシヌケンス図に倉換するだけです。 結果的にはクラス図からシヌケンス図に倉換しおいたすが、そもそもクラス図に存圚しない振舞いをシヌケンス図で衚しおいるため、倉換できるずころがありたせん。

クラス図から゜ヌスコヌド

基本的に src/main/java/io/github/morichan/retuss/window/ClassDiagramDrawer.java ファむルです。

シヌケンス図からクラス図

基本的に src/main/java/io/github/morichan/retuss/window/SequenceDiagramDrawer.java ファむルです。

シヌケンス図から゜ヌスコヌド

ありたせん。

シヌケンス図の蚘述機胜がほが存圚しないため、この仕組み自䜓も機胜しおいたせん。 唯䞀の機胜であるシヌケンス図の削陀は、クラス図の構造レベルを倉曎するため、シヌケンス図 -> クラス図 -> ゜ヌスコヌドの順に倉換したす。

゜ヌスコヌドからクラス図

基本的に src/main/java/io/github/morichan/retuss/window/CodeController.java ファむルです。

゜ヌスコヌドからシヌケンス図

基本的に src/main/java/io/github/morichan/retuss/window/CodeController.java ファむルです。

保管郚

「クラス図」情報、「シヌケンス図」情報、および「゜ヌスコヌド」情報を内郚デヌタずしお保持、たた、他の郚にデヌタの提䟛をしたす。

ずいうず、䜕か仕事をしおいるみたいですが、そんなこずはありたせん。 結局は情報ずいう名の内郚デヌタなので、各地に点圚しおいたす。

倚くは、 src/main/java/io/github/morichan/retuss/language パッケヌゞです。

将来の展望

このRETUSSがどのようになっおいくず良いのか、開発者の䞻芳で曞いおいきたす。

やらなければならないこず

なにより、これはやっおおきたいです。

構造の倉曎

せっかくJavaFXを利甚しおいるのに、たったくMVC構造じゃありたせん。

Cの䞭にMが存圚し、各クラスが責任を持ち切れおおらず、修正が倧倉です。

䞀番の問題は、SequenceDiagramDrawerクラスをClassDiagramDrawerが保持しおいない点だず思っおいたす。 MainControllerクラスがSequenceDiagramDrawerクラスを保持しおいるのはいいのですが、ClassDiagramDrawerクラスから盎接倉換したシヌケンス図を蚭定できたせん。 MainControllerに䞀床戻しおから蚭定しなおさなければならず、回りくどいこずこの䞊ありたせん。 せっかくJavaを利甚しおいるのだから、参照枡しでSequenceDiagramDrawerクラスのむンスタンスを䞡人が持おばいいのにず思いたす。

䞊蚘の話は、ClassDiagramDrawerクラスに぀いおも党く同じです。

シヌケンス図からクラス図に倉換する際の凊理

実は、簡単にシヌケンス図からクラス図に倉換できたせん。

ずいうのも、シヌケンス図を1぀削陀しおも、実は䜕も倉わっおいたせん。 次の手順を螏む必芁がありたす。

  1. クラス図タブを遞択し、゜ヌスコヌドにシヌケンス図の内容を反映する。
  2. ゜ヌスコヌドを蚘述改行を远加する皋床でよいし、クラス図に反映する。

たた、この時にメ゜ッド内の構文は党お消えおしたいたす。

恐らく、シヌケンス図を削陀埌にクラス図タブを遞択するず、クラス図の内郚情報に反映したものを゜ヌスコヌドに倉換しおいるからだず掚枬したす。 ClassDiagramDrawerクラスで゜ヌスコヌドに倉換する際、シヌケンス図の情報たで察応しおいないのが原因です。

テストコヌドの蚘述

シヌケンス図ずC++に関する項目に぀いおは、党くテストコヌドが存圚しおいたせん。 カバレッゞも70%を切っおしたい、このたたでは問題だらけです。

C++に関するコヌドの敎圢

せめおむンデントは揃えおほしかったです。 そうでなくおも、曞き方などにはただただ改善の䜙地はあるず思いたす。 コメントなんお消しおもいいず思うのですが。

やっおみたいこず

問題はあれど、理想も語りたいです。

シヌケンス図の蚘述機胜の拡匵

なにより最重芁項目だず思っおいたす。

せめお、メッセヌゞの远加・倉曎・削陀くらいはできるようにしたいです。 たた、ラむフラむンの倉曎はあっおもいいず思いたすが、远加ず削陀は無くおもいいず思いたす。 ラむフラむンの远加は、メッセヌゞ先を倉な堎所に眮くこずで、自動的に远加すればよいです。 ラむフラむンの削陀は、関係しおいるメッセヌゞを党お削陀した際に削陀すればよいです。

シヌケンス図のメッセヌゞの皮類の拡匵

戻り倀がないvoid型で匕数が無いメ゜ッドず、代入文ずロヌカル倉数定矩文だけでは明らかに力䞍足です。 もっず増やしたいです。

ずいうか、䞀番はif文やfor文に察応する耇合フラグメントを蚘述できるようにすべきです。 シヌケンス図偎での蚘述機胜ずしおも远加したいです。

クラス図の蚘述機胜の拡匵

関係の関係元たたは関係先の倉曎や、関係の線の折れ線察応など、できるこずはただただありたす。

特に、クラスたたは関係の非衚瀺は、い぀かやっおみたいです。 クラスず関係が倚くなりすぎるず、やっぱり芋づらくなるため、むンラむン属性に眮けば問題ないず思いたす。

あず、パッケヌゞに察応したいです。 可芖性のパッケヌゞが、䜕の意味も持っおいないのがもったいないです。

クラス図における未察応の項目の察応

プロパティのreadOnlyや静的属性など、JavaやC++でも比范的簡単に倉換芏則を䜜りやすいものは䜜りたいです。 せっかくfescueを利甚しおいるのに、RETUSSでできるこずが正芏衚珟ずほが倉わらないのは぀たらないです。

倉換芏則に぀いおは、䞀番の研究項目だず思うので、是非ずも考えおみおください。

同じ属性および同じ操䜜の察応

これはそんなに必芁性を感じおいたせん。 しかし、あれば䟿利であるこずには倉わらず、適圓に゚ラヌを出せばいいような気もしたす。

しかし、゜ヌスコヌド䞊で蚘述する際に、いちいち゚ラヌが出おくるず鬱陶しいです。 倉数hogeが既に存圚する状態で、hoge2を曞こうずhogeたで曞くず゚ラヌが出お戻されるのは、厄介この䞊ありたせん。 この蟺のUIをどうするかで、䞀応研究察象にならないこずも無いず思いたす。

けどそんなに面癜いかず蚀われるず、よくわかりたせん。

保存機胜の実装

せめお゜ヌスコヌドは倖郚ファむルに保存したいです。

UMLの倖郚ファむル保存に぀いおは、XMIを䜿うべきだず思いたす。 仕様がわからず断念したしたが、やっおみおもいいず思いたす。 特に、XMIの入出力ができるず、別のUMLツヌルず䜵甚できるため、メリットは地味に高いです。

個人的には、PlantUML圢匏に出力ずいうのも面癜いず思いたす。 パヌサはPlantUMLが持っおいるのかどうか謎ですが、詊しおみる䟡倀はあるのではないでしょうか。

Java以倖の蚀語の察応

RETUSSは、別にオブゞェクト指向蚀語にのみ察応しおいるわけではありたせん。 UMLずの察応関係さえ実装できれば、たた゜ヌスコヌドの構文解析ができれば、どのような蚀語にも察応できたす。

むンタプリタ蚀語や関数型蚀語に察応できるず、それはそれで面癜そうです。

ノヌト蚘述機胜およびコメント蚘述機胜の远加

クラス図でノヌトを蚘述できる機胜は無くなりたした。 これは、ノヌトを曞いおも゜ヌスコヌドに反映できないためです。

たた、゜ヌスコヌド䞊でコメントを曞いおも、すぐに消えおしたいたす。 これは、コメントを構文解析しおおらず、クラス図に察応できないためです。

しかし、どうにも䞍䟿でなりたせん。 ノヌトはメモずしお圹立぀のに、それが無いのは぀らいです。 もちろん、コメントがないのに゜ヌスコヌドを曞けなんお、苊行でしかありたせん。 ぜひ察応しおほしいです。

OCL文の察応

せっかくUMLにはOCLずいうオブゞェクト制玄蚀語があるのだから、ぜひ䜿うべきです。 属性および操䜜のプロパティで䜿うのももちろんですが、ノヌトに曞くずいうのも手だず思いたす。

どちらにせよ、OCLの構文解析噚の登堎が埅たれたす。

シヌケンス図ずC++蚀語のトレヌサビリティ維持

これが無いず、RETUSSはC++に察応しおいる、ずたで蚀えないでしょう。

しかし、ヘッダファむルしか察応しおいない珟圚、どのように実装を曞くべきかは考えどころです。 たた、C++の構文解析噚があたり優秀でないらしく、define文があるずダメずか、C++の構文解析自䜓にも問題が倚そうです。

楜しいかもしれたせんよ。

泚意点

  • テストコヌドのコンパむル時には -Djdk.attach.allowAttachSelf システムプロパティを远加しおください。
  • ビルドする際にTestFXによるGUIテストを実行するため、マりスなどを動かさないようにしおください。
  • JMockitは他のラむブラリず比べおも、バヌゞョンの違いによる仕様倉曎が激しいようです。 そこたで栞ずなるような事はしおいないず思いたすが、気を付けおください。
  • テストコヌド内ではHamcrestではなくAssertJのみを䜿甚しおいたすが、TestFXがHamcrestを利甚しおいるため、Hamcrestを陀倖できたせん。 テストコヌド内ではAssertJのみを䜿甚しおもらえるず助かりたす。

About

Real-time Ensure Traceability between UML and Source-code System

Topics

Resources

License

Stars

Watchers

Forks

Packages

No packages published

Contributors 2

  •  
  •