4

従来のバージョン管理システムでは、左側に[プロジェクト]->[フォルダ]->[ファイル]、右側に[詳細]ビューをグループ化してバージョン管理情報を表示します。次に、各項目をクリックして、その構成履歴の改訂履歴を確認します。

オブジェクト指向モデルの観点からプロジェクトで利用可能なすべての履歴バージョン情報（たとえば、クラス->メソッド->パラメーターなど）があると仮定すると、UIでそのような情報を表示するための最も効果的な方法は何だと思いますか？プロジェクトのスナップショットビューと履歴バージョン情報に簡単に移動してアクセスできますか？現在SVN、SS、Perforce、または任意のVCSシステムを使用しているように、このようなツールを日常業務で使用している立場に身を置いてください。これにより、ツールの使いやすさ、生産性、および有効性が向上します。

私は個人的に、上記のようなフォルダやファイルを表示するための古典的な方法は非常に制限的であり、深くネストされた論理モデルを表示するにはあまり効果的ではないと思います。これがグリーンフィールドプロジェクトであり、特定のテクノロジーによって制限されていないと仮定すると、これにどのようにアプローチするのが最善だと思いますか？

私は自分の研究プロジェクトに価値を加えるためのアイデアとインプットをここで探しています。価値があると思われる提案があれば、遠慮なく行ってください。考えを共有してくれた人にもう一度感謝します。

編集：より多くの情報、平均的な構成アイテムを提供するために、メソッドを取得すると、約6つのレベル（プロジェクト->アセンブリ->モジュール->名前空間->タイプ->メソッド、およびその中の子アイテムに移動するためのより多くのレベル）にネストされます）そしてこれは一貫して当てはまります。あるプロジェクトで時々深いネストされた構造を持つフォルダファイル構造の場合とは異なります。レベルが非常に多い場合、ツリーペインはナビゲートできなくなります。IMHO、ツリーペインも、このシナリオではシステムの全体的な構造を表示するのにあまり効果的ではありません。

4

5 に答える 5

3

茎と葉のプロットのバリエーションはどうですか？

http://en.wikipedia.org/wiki/Stemplot

これは統計からの概念ですが、ツリー内の各ファイルの右側にバージョンのリストを追加して、従来のツリー構造を拡張することができます。適切に配置すれば、これは視覚的に表現力があり、使用可能なソリューションになると思います。このようなもの：

* Root Directory
    * Sub Directory A
        * File A.A     | 1 2 3
        * File A.B     | 1 2
    * File A           | 1 2 3 4 5 6 7 8 9
    * File B           | 1 2 3 4 5

幹葉図は、ファイルが改訂された回数を視覚的に示し、表示（編集など）やバージョンにすばやくアクセスできます。

これは、データの1つのビューにすぎない可能性があります。ネストされた構造にはまだ悩まされますが、それを維持する必要がある場合は、おそらくこれが役立つでしょう。

于 2010-03-31T05:36:07.893 に答える
2

GUIでnレベルの情報をフィッティングするために、 1つのプレゼンテーションスキームを選択しようとするのではなく、ユーザーが必要または必要とする適切なレベルの詳細を選択できるようにしないのはなぜですか。

展望

Eclipseは、ユーザーがパースペクティブを定義できるようにする1つの例（1つだけではありません）です。

ワークベンチ内では、パースペクティブ機能を使用して、モデル内のアイテムの可視性とユーザーインターフェイスを制御します。
モデルに表示される内容（プロジェクト、フォルダー、またはファイル）とユーザーインターフェイスに表示される内容（アクションまたはビュー）を制御します。
これらのコントロールを使用すると、ユーザーのタスクに適した方法でワークスペースをナビゲートおよび変更できます。

パースペクティブは、あらゆる種類の階層情報表示に簡単に適合させることができます。

視点

タスクごとの情報フィルタリング

複雑な情報を表示するもう1つの効果的な方法は、現在のタスクに基づいて効果的なフィルタリングメカニズムを提案することです。
ユーザーが新しいタスクに切り替えるたびに、さまざまな情報ツリーに関連情報のみが表示されます。

たとえば、Mylynを参照してください。

Mylynは、タスクをIDEのファーストクラスの一部にし、ALMツールのリッチ編集とオフライン編集を統合し、プログラミングアクティビティを監視して、ワークスペースに焦点を合わせ、関連するすべての成果物を手元のタスクに自動的にリンクする「タスクコンテキスト」を作成します。
これにより、必要な情報をすぐに利用できるようになり、情報の過負荷が軽減され、マルチタスクが容易になり、専門知識の共有が容易になるため、生産性が向上します。

繰り返しますが、それはあらゆる種類の情報に適用できます。

http://www.tasktop.com/sites/default/files/images/part1-overview.jpg

于 2010-04-03T20:49:00.970 に答える
2

6つのレベルをネストしている場合は、おそらく複数の懸念事項を人為的に混合しています。5Dモデルについては、以下を参照してください。基本的なナビゲーションモデルとしてnamespace-class-methodを使用する必要があるようです。少なくとも、コード構造とディスク上の組織（ファイルとフォルダー）およびバリアントへのマッピングを組み合わせています。PharoのようなSmalltalkIDEは、いくつかの次元に沿ったナビゲーションを容易にする一連のコードブラウザーを提供し、他のナビゲーション次元用に独自のブラウザー構築キットGlamourを提供します。

あなたはリチャード・ウェッテルによって行われた仕事を見てみたいと思うでしょう。Codecityに似たもの。OpenGLを使用して、プロジェクトの開発履歴の3Dおよび4D（時間）表示を作成します。これは、ソフトウェアリエンジニアリングMOOSEの研究の一部です。

あなたの研究のために、あなたはこれのために5次元モデルを使用したいかもしれません：

  • バージョン（変更したい）
  • ステータス（ライフサイクル：作成、テスト、展開、廃止）
  • ビュー（要件、コード、テスト、ドキュメント）
  • 階層（モジュール、クラス、メソッド）
  • バリアント（大部分は類似しており、違い、製品ファミリを説明しています）

ほとんどのシステムは、これらの次元のいくつかのみを処理します。5つすべてを処理するには、開発プロセスを記述（修正）する必要があります。その場合、UIでサポートするユースケースを説明できます。そうでない場合は、5次元のフレキシブルディスプレイエンジンが必要です。それは使いやすいものではありません。

参照：

設計データの管理：CADフレームワーク、構成管理、および製品データ管理の5つの側面。
van den Hamer、P。Lepoeter、K。Philips
Res。、アイントホーフェン;

この論文は次の場所に掲載されています。IEEEの議事録
発行日：1996年1月
巻：84、発行：1
ページ：42-56
ISSN：0018-9219
引用文献：26
CODEN：IEEPAD
INSPECアクセッション番号：5175049
デジタルオブジェクト識別子：10.1109 / 5.476025
現在のバージョン公開日：2002-08-06

于 2010-04-07T20:27:50.583 に答える
1

うーん、私は各ブランチのサイロ、垂直シリンダーから始めます：dev、release、ここに1つ以上あります。そのサイロに歴史的にコミットされたバージョンを視覚的に配置する必要があります。これらのバージョン間では、最終的にループバックする他の変更がいくつもあります。

各ループに沿って、サイロの外側にx個の変更があるコミットポイントがあります。果物がぶら下がっているときに論理的に平らになっていることを視覚化します。高レベルからは少し混乱しますが、果物の質感、色、パターン、サイズから、何が起こったのかがわかります。また、フルーツにカーソルを合わせると、コミットで行われたコメントが表示されます。

次に、果物の茎をクリックします。ここでは、ビューをいくつかのスタイルに反転しますが、階層を変更に移動するのではなく、変更を使用して階層を移動します。左側に大きなスペースがあり、右側に少し階層的なスペースがあります。変更にカーソルを合わせると、階層がジッパーで移動します。変更をクリックすると階層がフリーズし、階層をクリックして再びサイロビューに移動できますが、今回はファイル/関数/その他のみが表示されます。

---編集---これは私が考えていたようなもののスケッチです。私のアイデアは、Mercurialをソース管理リポジトリとして使用することに基づいています。少なくとも私にとっては、各リビジョンで行われた変更の種類を理解する方が興味深いでしょう。これは、あなたが狙っていたものと一致しない可能性があるアイデアです。リポジトリが変更されたものを特徴づけて定量化できるように、変更の種類を確認することで、どのファイルが変更されたかよりも重要だと思います。小さな点は、メソッド自体の中でコードが変更されたか、場合によってはクラスへのプライベートメソッドの追加になります。果物を拡大すると、スペースがいっぱいになり、トランクが消えるか、薄暗い透かしなどにフェードインします。

この大まかなスケッチが私の考えをもう少しよく伝えてくれることを願っています。 代替テキストhttp://img704.imageshack.us/img704/9034/img0507h.jpg

于 2010-04-08T20:26:49.887 に答える
1

コードが変更された場所をすばやく見つけたい場合は、グラフィック表現を使用して、十分に低レベルの要素を選択する場合にのみ、ツリーのような表現（mcliedtkによって提示される表現など）に移動できます。 （名前空間、またはタイプ）。

各要素について、下位レベルから上位レベルまで、変更の％を計算します。

  • メソッドまたは属性の場合：作成/変更/削除された場合は100％、それ以外の場合は0％
  • クラスの場合：含まれるすべての要素（メソッドまたは属性）の平均、または作成/削除された場合は100％
  • 上位の要素についても同じです（作成/削除された場合は100％、それ以外の場合はコンポーネントの平均）。

ここで、階層構造を示す表現を取得する必要があります。
（たとえば）放射状のものを使用できます。プロジェクトは中央（つまり円）にあります。アセンブリはリングとして表示され、各アセンブリは同じスペースを取ります。3番目のレベルのリングはモジュールを表し、各モジュールはそのアセンブリに同じスペースを取ります（つまり、4つのアセンブリの場合、それぞれが90°になり、アセンブリに3つのモジュールがある場合、各モジュールはそれらの90°の1/3になります） 、 等々。各要素は、変更の％からマップされた色を取得します（0％=緑=変更なし、> 85％=赤=大幅な変更）

たとえば、 http：//www.neoformix.com/2006/BB_TopicRadialTreemapImages.pngまたはhttp://www.datavisualization.ch/wp-content/uploads/2009/04/stacked_wedge_01.pngのようになります。

プロ側では、変更が発生した場所とレベルをすばやく確認できます。
マイナス面では、これは参照日以降の変更を与え、1回または2回変更されたファイルは10回変更されたファイルと同じです。6レベルはすぐに判読できなくなる可能性があるため、ナビゲーションを容易にするためにツールチップを追加する必要がある場合もあります（ただし、5つの上位レベルのうち4つしか表示できません...）

よろしく
ギヨーム

于 2010-04-09T14:50:57.213 に答える