0

プログラミング言語: Java . クラス図の問題。

Bridge という名前のクラスが与えられた場合、次の表現は正しいですか?

私の懸念は、次のような宣言をどのように処理するかについてです。

これは属性/メソッド宣言です:

public class Bridge {
    private Semaphore semaphore;
    private Lock lock:
    private Condition waitingCond;
    private int nNorthCars; .......
    public void getIn(int direction) throws InterruptedException{
    .....
The same goes for getOut()....
}

UML 表現:

 ---------------------
    Bridge
    ---------------------
    - semaphore: Semaphore
    - lock: Lock
    - waitingCond: Condition
    - nNorthCars: int
    - nSouthCars: int
    ---------------------
    + getIn(): void
    + getOut(): void
    ---------------------

さらに、メイン関数内の変数はローカルであると想定されているという事実を考えると、それらをプライベートとして扱う必要があると考えてよろしいですか? 例えば：

public static void main(String[] args) {
...........
int nThreads = Integer.parseInt(args[0]);
long time = 0; 
...}

UML の実装は次のとおりです。

---------------------
Main
---------------------
- nThreads: int
- time: long
---------------------
+ main()
---------------------

記号: - (プライベート)、+ (パブリック)

どんな助けでも大歓迎です。

ありがとう

4

1 に答える 1

0

一般に、UMLは実装/言語に依存しないことを意図しています-UMLダイアグラムを読むとき、実装されている言語を知ったり気にしたりしないでください。また、クラス図は、タイプ/クラス/概念を表す（またはモデル化する）ことを意図していますドメインの問題とそれらの関係の。したがって、これは実装の詳細であり、他のクラスや概念との関係には関係しないため、メソッド内のローカル変数について心配する必要はありません。

UML を使用して Java プログラムをモデル化 (またはリバース エンジニアリング) しようとしており、クラス図の一部としてプログラム内のすべての変数を含めたいと思われます。これは、取るべきアプローチではありません。

SemaPhore、lockおよびはすべて実装の詳細であり、の動作やと他のクラスとの関係waitingConditionに関する有用な情報を伝えません。プライベートです - これらをパブリック プロパティとして公開することは、あなたのモデルでは意味がありますか? モデル内の他のクラス/概念は、これらについて知る必要がありますか? これらの質問に「いいえ」の場合は、クラス図からこれらを削除することもできます。おそらくアクティビティ図でブリッジのメソッドをモデル化する場合は、それらを保持したい場合があります。Bridge は、UML ではおそらく次のようになりたいと考えています。BridgeBridgenNorthCarsnSouthCars

    ---------------------
    Bridge
    ---------------------

    ---------------------
    + getIn(): void
    + getOut(): void
    ---------------------

Bridge が何か他のもの (おそらく車のコレクション) と関係を持っている場合、それをモデル化できます。これは、その関係がモデル内の他の概念に外部から見えるためです。

Mainプログラムのエントリ ポイントのように見えますが、これをそのようにモデル化する必要はないかもしれません。他のすべての (または他のほとんどの) クラス/概念を集約する場合Mainは、先に進み、そのようにモデル化します。そうでない場合は、実装の詳細になります。

最後に、UML は実際には、コードに実装する概念をモデル化することを目的としています。これの逆を行っているようです。リバース エンジニアリングとラウンド トリップはある程度は問題ありませんが、そうしないと、UML をハッキングしてそこからコードを生成することになるので注意してください。UML の考え方は、ドメインをモデル化し、コードをカットする前にこのモデルを検証することです。

お役に立てれば...

于 2012-06-28T17:57:35.803 に答える