SMART0.3 UML Modeler マニュアル
佐藤真紗美
平成 16 年 2 月 25 日
version 0.9
使い方よりもむしろ実装内容について説明しました。
連絡先は最後。わかりにくいところはどんどん加筆・修正しますので言っ
てください。
(そうでなくても思い出したことがあれば勝手に加筆すると思い
ます)
目次
1
SMART0.3 のパッケージ構造
2
2
main クラス
4
3
UML Modeler と STT の関係
4
4
UML2.0 対応
4
5
SMART UML Modeler
5.1 パッケージ構成 . . . . . .
5.1.1 logical パッケージ
5.1.2 gui パッケージ . .
5.1.3 model パッケージ .
.
.
.
.
6
7
7
7
8
5.1.4
ui パッケージ . . . . . . . . . . . . . . . . . . . . . . .
8
5.1.5
5.1.6
view パッケージ . . . . . . . . . . . . . . . . . . . . .
factory パッケージ . . . . . . . . . . . . . . . . . . . .
8
8
Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SmartClass . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
9
5.2
5.3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5.3.1
5.3.2
AttributeList . . . . . . . . . . . . . . . . . . . . . . . 9
OperationList . . . . . . . . . . . . . . . . . . . . . . . 10
5.3.3
5.3.4
EventList . . . . . . . . . . . . . . . . . . . . . . . . . 10
parent(継承関係) . . . . . . . . . . . . . . . . . . . . . 10
1
5.4
実装されたモデル要素 . . . . . . . . . . . . . . . . . . . . . . 10
5.4.1
5.4.2
5.4.3
5.5
StateMachine 図 . . . . . . . . . . . . . . . . . . . . . 10
Composite Structure 図 . . . . . . . . . . . . . . . . . 11
Sequence 図 . . . . . . . . . . . . . . . . . . . . . . . . 12
5.4.4 User Interface . . . . . . . . . . . . . . . . . . . . . . . 12
5.4.5 UseCase . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.5.1 Activity の扱い . . .
5.5.2 操作方法 . . . . . . .
5.6 dump/restore . . . . . . . .
5.7 Save/Load . . . . . . . . . .
5.8 Instanciation . . . . . . . .
5.9 実行 . . . . . . . . . . . . .
5.10 User Interface . . . . . . . .
5.10.1 作りつけ Model . . .
5.10.2 SubModel 生成 . . .
5.10.3 User Interface の属性
5.11 UML2.0 メタクラス実装 . .
6
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ログとその応用
6.1
6.2
6.3
6.4
7
.
.
.
.
.
.
.
.
.
.
.
パッケージ構成 . . . . . . . . . . . . . . . . . . . . . . . . . .
ログ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sequence 図 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Composite Structure のチェック機能 . . . . . . . . . . . . . .
未実装部分や発見済みバグ…と、個人的展望
7.1 重大なもの . . . . . . . . . . . . . . . .
7.2 すぐできそうなもの . . . . . . . . . . .
7.3 展望 . . . . . . . . . . . . . . . . . . . .
7.3.1 Suggestion . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
12
12
12
13
13
13
13
13
14
14
14
16
16
16
20
20
21
21
22
22
22
8
補足
22
9
連絡先
23
1
SMART0.3 のパッケージ構造
パッケージが山ほどありますが、eclipce で見えるパッケージの半分ほどは
UML2.0 のメタモデルのためのパッケージです。以下に構造を示します。
2
Fig 1: SMART Package
commonbehavior action のパッケージ。SMART0.2 からかなり変わって
います。潘さんが主に実装、佐藤も Statement.java を少しだけ触った記憶が
あります。
communications SMART Test Tool(STT) から UML Modeler に対して
通信するときに使います。たとえば MissingElement を作る場合です。佐藤が
実装しました。
core
RuntimeInstance 周辺のパッケージ。SMART0.2 の一部を修正した以
外はあまり変わっていません。(誰がいじったか忘れました…)
dump restore Dump、Restore、Instanciation を取り扱うパッケージ。森
さんが実装。User Interface の dump に関して少し佐藤が変更を加えました。
testtool
STT のパッケージ。潘さんが実装しました。
3
traceability SMART Traceability Web Tool(STWT) のパッケージ。潘さ
んの実装。
tracer
ログ、Sequence 図によるトレース、Composite Structure の構造チ
ェックを扱います。ほとんど佐藤が実装、Logger.java のみ潘さんが大部分を
実装しました。
uml UML2.0 のメタモデルをインタフェースの形で表現したパッケージ。
ただし、すべてのメタクラスをサポートしていません (SMART に必要そう
なところだけになっています)。佐藤が実装しました。umlmodeler の logical
パッケージから使われます。4 に実装の中身について書きました。
umlmodeler SMART0.2 の Statechart Modeler と UI(User Interface) Modeler を組み込んで UML Modeler を実装。主に佐藤が実装、Composite Structure 部分は薛さんの実装、dump/restore に関しては森さん(その後少し佐藤
が改造しています)。詳しくは 5 に書きます。
2
main クラス
SMART0.3 には main メソッドを持つクラスが 4 つあります。
1. smart.Main
2. smart.testtool.swingui.TestRunner
3. smart.traceability.gui.TraceabilityTool
4. smart.umlmodeler.UMLModeler
SMART システム全体を起動するときは、smart.Main の main メソッドを呼
び出せば起動できます。
3
UML Modeler と STT の関係
SMART Test Tool が UML Modeler に対して何か要求する場合は、必ず
smart.communications パッケージを通します。もしそれ以外の経路があった
ら、設計ミスの可能性大です。
4
UML2.0 対応
smart.uml パッケージは、UML2.0 の Superstructure の Specification(http:
//www.omg.org/) に従って作っています。ここでは、その実装の仕方につい
4
て説明しておきます。
smart.uml パッケージのクラス名はすべて UML2.0 のメタクラス
そのままです。パッケージ名も spec 通り使っています。ちなみに、UML の
メタクラスでは多重継承がありますが、Java のクラスでは多重継承を表現で
クラス名
きないので、smart.uml パッケージの中身はすべてインタフェースになって
います。
また、紛らわしいのでメタクラス名の最初に “I” をつけています。(たとえ
ばメタクラス名が “Operation” なら、インタフェース名は “IOperation” に
なっています)
Attribute と Association Spec で、メタクラスの説明として Attribute
と Association という段落がありますが、コードではどちらも属性扱いとし
て、get/set メソッドを用意しました。ただし、多重度が 1 より大きい場合は、
collection として実装しました。
たとえば、spec の Operation メタクラスは、次のような形になっています。
Attributes
. class : Class [0..1]
. /isOrdered : Boolean
(略)
Associations
(略)
. bodyCondition: Constraint[0..1]
(略)
このようなインタフェースは、次のように実装しました。
interface IOperation{
public IClass getClass();
public void setClass(IClass class_);
public boolean isOrdered();
public void setOrdered(boolean ordered);
public Collection getBodyConditions();
//Collection なので set メソッドは不要
}
5
5
SMART UML Modeler
ここからは UML Modeler の説明をします。ここで書くことは、smart.umlmodeler
パッケージだけではなく、UML Modeler に関係する部分すべてです。(つま
り、STT と STWT を除くところ全部ということ。)
Fig 2: SMART UML Modeler
6
5.1
パッケージ構成
Fig 3: smart.umlmodeler packages
5.1.1
logical パッケージ
図の通り、smart.uml パッケージ (4 参照) を実装します。詳しくは 5.11 に
述べます。
5.1.2
gui パッケージ
UML Modeler の GUI のほぼすべてを扱います(一部 model パッケージに
もあります)。swing 関係はほとんどここにあると思ってもらってかまいま
せん。
smart.umlmodeler.gui UML Modeler のメインウィンドウ (UmWindow)
やその中身(メニュー・ツールバー・ツリー・スクリーン・タブ部分)。InstanceWindow もここ。
smart.umlmodeler.gui.action UML Modeler の EditToolBar のボタン
から呼ばれる action 群。
smart.umlmodeler.gui.action.command smart.umlmodeler.gui.action
の中の save/load 絡みの action から呼ばれる、補助的 Command 群。特に、
通常の dump とは異なる処理となる activity、usecase の save/load。
7
smart.umlmodeler.gui.command SMART0.2 の smart.viewmodel.statechart.command
から直接持ってきた Command 群。追加されたのは ModelExecutionCommand ぐらいで、あとは UML Modeler に合わせて修正してあります。
smart.umlodeler.gui.dialog 新しいモデル要素を追加するときの Dialog
群です。
smart.umlmodeler.gui.handler モデル要素はかなり増えていますが (StateMachine に加えて Composite Structure や Sequence 図が増えたため)、ここは
SMART0.2 で、smart.statechartmodeler に存在していた handler クラス群と
構造的には全く変わりません。
smart.umlmodeler.gui.visitor ここも、モデル要素が増えた分 accepter
が増えています。(TreeNode もここの accepter になっていますが、これは本
当は分けたほうがよいような…)
5.1.3
model パッケージ
Model 図関係は全部ここ。
5.1.4
ui パッケージ
SMART0.2 の UI Modeler 部分はすべてここに入っています。User Interface
の実装については 5.10 に書きます。
5.1.5
view パッケージ
UML の各要素のうち、スクリーン上に描かれる、図としての情報を持つ
パッケージです。たとえば Sequence 図の Lifeline は、論理的な部分を logical
パッケージの MLifeline クラスにもち、図として描かれる部分は view パッケー
ジの LifelineView クラスに持っています。
5.1.6
factory パッケージ
モデル要素生成のためのパッケージです。
5.2
Model
Model は次のように構成されます。
8
Fig 4: SMART Model and SmartClass
1. この Model によって表される Classifier (SmartClass 型)
2. この Model のコンストラクタ(ただしこれは未実装。将来的に用いる
はずのもの)
3. インスタンスかどうかを表す bool 値
4. 実行状態にあるかどうかを表す bool 値
5. Model の名前
6. Model Instance の名前
5.3
SmartClass
SmartClass の中身は、次のようになっています。
5.3.1
AttributeList
この Classifier の持つ Attribute。UML2.0 では Property というメタクラ
スにあたります。Property はあくまでモデリング上での属性であるので、
「具
体的な値」というものを持ちませんが、SMART では簡略化して、Property
に value を持たせることで実行時に Attribute が値を持つことを表現してい
ます。
この場合、本来は Slot というメタクラスを新たに使うべきですが、Property
に isSlot という boolean 値を持たせることで、モデリング中も実行中も同じ
クラスを属性として使うことにしました。ただし、現在の実装ではこの isSlot
は実行中もモデリング中も常に false のままです。
9
5.3.2
OperationList
この Classifier の持つ Operation。SMART0.3 のうえでは、全く使われて
いないです。
5.3.3
EventList
この Classifier に起こりうる Event のリスト。Event は Trigger というメタ
クラスに対応させて考えます。現在サポートされているのは、CallTrigger だ
けです。他の SignalTrigger、ChangeTrigger、TimeTrigger、AnyTrigger は
未サポート(将来的にサポートするべきかどうかも怪しい)。
SMART0.2 の Statechart Modeler からの変更 StateMachine 図に新た
に Event の発生が書き込まれると、この EventList にも Event の追加を行い
ます。(StateMachine 図から Event が消された場合に、EventList から削除
するべきだが、これは未実装)
5.3.4
parent(継承関係)
SMART0.3 では、ひそかに継承関係が使われています。User Interface に
おける継承関係表現のため、SmartClass は親となる SmartClass を属性とし
て持っています。親を持たない場合は null です。
この継承関係は現在 User Interface にのみ使われており、将来的に User
Interface における継承関係が否定された場合は、この属性を SmartClass か
ら取り払う必要があります。
5.4
実装されたモデル要素
SMART0.3 の実装により、次の 5 つが表現できるようになりました。
5.4.1
StateMachine 図
これは SMART0.2 の Statechart 図と同じ。大きくは変わっていません。各
Model は 1 つだけ StateMachine を持つことができますので、新しい StateMachine を書こうとすると、以前の StateMachine は削除されます。
関係するパッケージ
smart.umlmodeler.logical.state_machines
10
UML1.X に準拠 SMART0.3 で UML1.X に準拠しているのはここだけで
す。そのため、まだ abort などには未対応。
5.4.2
Composite Structure 図
UML2.0 の Composite Structure に準拠。port の概念は完全に無視しまし
た。描けるのは、Class の Composite Structure と、Collaboration の Composite Structure です。
各 Model は、Composite Structure を 1 つだけ持てます。そのため、既に
Composite Structure がある時点で新しい Composite Structure を作ろうと
すると、それまでの Composite Structure は削除されます。
Fig5 に、CompositeStructure のときのツールバーを示します。
Fig 5: Composite Structure Toolbar
関係するパッケージ
smart.uml.composite_structures
smart.umlmodeler.logical.composite_structures
smart.umlmodeler.factory.composite_structures
smart.umlmodeler.view.composite_structures
Composite Structure で表現される下位の階層における
StateMachine の状態変化は、上位の階層の StateMachine にどのような影響
階層化に伴う問題
を与えるか。またその逆。これらは、本年度は重要な議論となりませんでした。
11
5.4.3
Sequence 図
UML2.0 に基づいた実装になっています。今年はユーザが書くよりもむし
ろログから書き起こすほうの意味が強くなりました。
(一応ユーザが書けるよ
うにもなっています)
UML2.0 では、Sequence 図はフレームの中に描くものとなったため、フ
レームなしでは描けないようにしています。また、Sequence 図中の各 Lifeline
は、元となる Composite Structure の Parts を必要とします。
各 Model は Sequence 図をいくつも持つことができます。
5.4.4
User Interface
これについては 5.10 参照。
5.4.5
UseCase
テキストの UseCase 記述。保存も可能です。
5.5
Activity
SMART0.3 では、Activity を SMART 上で編集できるようにしました。
5.5.1
Activity の扱い
Activity は各 Model からは独立なものとしました。つまり、この Acitivity
を持つ Model が消されても Activity のリストから消去されません。
5.5.2
操作方法
新しい Acitity 生成
Fig2 の「新しい Acitivity の生成」ボタンを押すと、新
しい Activity を書くダイアログが生成されます。
Activity の修正
画面右下の「Activity」タブをクリックすると、現在存在
するすべての Activity のリストが現れます。Activity を選ぶと、Modeler 上
にテキストボックスが現れます。
5.6
dump/restore
XML による実装。これについては森さんが一番詳しいはずなので説明不
要でしょう。
12
5.7
Save/Load
それぞれ、dump/restore により実装されています。
Save/Load 元 ユーザが指定できるようにしています。activity と usecase
も同じフォルダにサブフォルダを作って保存されます。
─保存先フォルダ名
├ dump.xml
├ activities
│├エアコン電源 On
│└...
└ usecases
├ usecase0
└...
5.8
Instanciation
Model から Model Instance を作るときは、dump 機構を使って Model を
コピーしてインスタンスを作ります (createInstance)。
5.9
実行
実行ボタンが押されると、それまでのモデリングの結果を反映させるため、
すべてのインスタンスを一旦削除し、再生成します (regenerateInstances メ
ソッド)。さらに、Model クラスの bool 値 isExecution をすべて true に変更
します。
5.10
User Interface
SMART0.2 の UI Modeler を引き継ぐ際、User Interface にも継承関係が
あるのではないかという考えが出たため、SMART0.3 では次のように実装し
ています。
5.10.1
作りつけ Model
最初に、次のような 5 つの User Interface の Model(UI Model) が存在して
います。
1. TextLabel
13
2. TextButton
3. ImageLabel
4. ImageButton
5. TransparentButton
これらは、UI Modeler の各 UI Parts に当たります。SMART システム起動時
に、smart.umlmodeler.BuiltInUIModelCreater クラスにより自動で生成され
ます。Fig2 の Model のリスト部分にあるように、最初から存在しています。
5.10.2
SubModel 生成
ユーザが User Interface を作るときには、作りつけ Model を親とする Sub-
Model を作ります (Model クラスの createSubModel)。createSubModel メソッ
ドでやっていることは、基本的にはインスタンスを生成する createInstance
と同様です。ただし、Model の属性 parent に親となる UI Model が代入され
る点が異なります。
5.10.3
User Interface の属性
SMART0.2 の UI Modeler では、UIParts クラスのサブクラス (ImageLabel
など) がそのまま背景色などの属性を持っていましたが、SMART0.3 では、
UIParts のサブクラスが属性を持つと同時に、UI Model も属性を持っていま
す。つまり、属性を持っているクラスが重複している状態です。
(改善が必要
ですが、これを考え出すと User Interface の議論に突っ込みます…)
5.11
UML2.0 メタクラス実装
4 で述べた smart.uml パッケージの各クラスを implement したのが、smart.umlmodeler.logical
パッケージです。インタフェースで指定された get/set メソッドが扱う属性を
各クラスで実装しています。(各クラスの接頭辞は “M” にしました)
たとえば、4 で書いた IOperation インタフェースを実装した MOperation
クラスは次のように実装されます。
class MOperation implements IOperation{
private IClass class_;
private boolean isOrdered=false;
private Collection bodyConditions=new HashSet();
public IClass getClass(){...};
14
public
public
public
public
void setClass(IClass class_){...};
boolean isOrdered(){...};
void setOrdered(boolean ordered){...};
Collection getBodyConditions(){...};
}
smart.uml パッケージのインタフェース同様、smart.umlmodeler.logical
の各クラスも UML メタモデルの継承関係を反映させました。
ただし、Java のクラスは UML のメタクラスと異なり、多重継承ができな
いので、多重継承のメタクラスを Java のクラスにする場合は、いくつか存在
する親クラスのうちどれを継承させるかを場合によって選んでいます。
(これ
を継承したほうがよい、と思ったものについては、smart.uml パッケージの
インタフェースの最初に/*extends XXX*/と書いておきました)
たとえば、StructuralFeature は、Feature、TypedElement、MultiplicityElement の 3 つを継承したメタクラスであり、次のように実装しました。
継承の扱い
インタフェース
public interface IStructualFeature
implements IFeature,ITypedElement,IMultiplicityElement{
...
}
クラス
public abstract class MStructuralFeature
extends MFeature
implements IStructuralFeature {
...
}
抽象メタクラス
UML2.0 の spec 上で abstract メタクラスとなっているも
のについては、実装クラスでも abstract としました。
なお、spec では各クラスの説明中に abstract クラスであることを明確に
書いてあるクラスは少ないです。したがって、spec の各 Chapter の abstract
syntax にあるメタクラス図から、抽象メタクラスかどうかを判断しています。
StateMachine 部分 logical パッケージでも、StateMachine 部分だけは SMART0.2
のままです。したがって、
1. メタモデルは UML1.X のまま。
15
2. logical も view も一緒になっている
という点で、他の部分の実装と異なります。
6
ログとその応用
ここでは、ログ関係の部分について説明します。
6.1
パッケージ構成
smart.tracer パッケージ
ケージです。
ログの記録と Sequence 図生成を担当するパッ
smart.tracer.composite checker パッケージ ログを利用して Composite
Structure 図をチェックする部分を担当するパッケージです。
6.2
ログ
次の 2 点でログを記録します。
1. STT の「run」中
2. UML Modeler 単体でのモデル実行
ログの記録を担当しているのは、Logger クラスです。Logger は clearLog
メソッドを持っていて、これを呼ぶことで trace.log ファイルをカラにし、古
いファイルを 10 個まで自動的に保管します。
ログの種類
論文には少ししか書かなかったので、ログの種類について詳し
く書いておきます。
注意:TransitionID
以下で出てくる TransitionID とは、Transition が生成
されたときに、一意となるように自動的に付与されているものです(smart.
umlmodeler. logical. state machines. behavior state machines パッケージ
の TransitionView クラスを見てください)。ただし、現在これは dump され
ていませんので、SMART を起動するたびに異なる番号が付与されている可
能性があります。
event-activity-execute-begin
16
event-activity-execute-begin:< activity 名>, < activity を起動
した StateMachine を持つ Object 名>. < activity が起動された TransitionID
>
activity の実行が開始されたときに記録されるログです。次に例を書きます。
event-activity-execute-begin:エアコン温度上昇, body.transition10
event-activity-execute-end
event-activity-execute-:activity 名、activity が起動された場所
acitivity の実行が終了したときに記録されるログです。
begin-testcase
begin-testcase:< testcase 名>, <時間>
TestCase の Run 開始時に記録されます。例は次のようになります。
begin-testcase:testcase,2004/1/4/7:51
end-testcase
end-testcase:< testcase 名>, <時間>
TestCase の Run 終了時に記録されます。
assert-equals
assert-equals:<期待値>, < assertion 対象のパラメータ>, <比較値
>, <実際の属性の値>, < assertion の結果{false,true}>
STT での assertion が実行されたときに記録されるログです。SAL のコード
と対応させると以下のようになります。
assertEquals(<期待値>, < assertion 対象のパラメータ>)
ログの例は次のようになります。
assert-equals:24,aircon. 設定温度 [0],24,21,false
assert-true
assert-true:< assertion 対象>, < assertion の結果{false,true}>
これも assertion が実行されたときのログです。SAL に対応させると次のよ
うになります。
assertTrue(< assertion 対象>)
17
failed-by-meerror
failed-by-meerror:< testcase 名>
TestCase が MEError によって失敗したときに記録されるログです。
setcurrent-state
setcurrent-state:< Object 名>. < State 名>, < setCurrent ステー
トメントを呼び出しているファイル名>
SAL の setCurrent が呼ばれたときのログです。
setcurrent-state:body. 電源 on,testcase2
iscurrent-state
iscurrent-state:< Object 名>. < State 名>, < isCurrent ステート
メントを呼び出しているファイル名>, < assertion 結果{false,true}>
SAL の isCurrent ステートメントが呼ばれたときのログです。
iscurrent-state:body. 電源 on,testsuiteroot\温度\testcase3,false
message-send-call-event
message-send-call-event:< event 名>, < callEvent ステートメント
を呼び出しているファイル名>, <メッセージの送信元>, <メッセージの
受信先>, < Event につく argument[値の列] >
イベントが発火されたときのログです。SAL では callEvent のときです。
message-send-call-event:温度設定,testsuiteroot\温度\testcase2,testcase2,aircon,[23]
message-send-return-event
message-send-return-event:< event 名>, < callEvent ステートメン
トを呼び出しているファイル名>, <メッセージの送信元>, <メッセージ
の受信先>
message-send-call-event に対応する return メッセージ。
message-send-call-activity
message-send-call-activity:< activity 名>, < callActivity ステー
トメントを呼び出しているファイル名>
activity が起動されたときのログです。SAL では callActivity の実行時にな
ります。
message-send-call-activity:エアコン温度下降,testsuiteroot\温度\testcase
18
message-send-return-activity
message-send-return-activity:< activity 名>, < callActivity ス
テートメントを呼び出しているファイル名>
message-send-call-activity に対応する return メッセージ。
read-attribute
read-attribute:< Object 名>. <属性名>, < read された値>, < read-attribute
している場所>
属性の値を読み込んだときのログですが、このログは現在使われていません。
write-attribute
write-attribute:< Object 名>. <属性名>, <代入文の左辺 (String
型) >, <代入文の右辺 (String 型) >, <代入前の属性の値>, <代入後
の属性の値>, < write-attribute している場所>
属性の値の書き込みを行っているときのログです。
write-attribute:controller. 設定温度, controller. 設定温度 [0], 23,23, 23, testsuiteroot\
温度\testcase1, testsuiteroot\温度\testcase1
transtion-begin
transition-begin:< transitionID >
状態遷移が始まったときのログです。
transtion-end
transition-end:< transitionID >
状態遷移が終わったときのログです。
補足:[値の列] について
値の列は [A,B,C,...] のように [] でくくり、コンマ
で区切って記録しました。
補足:メッセージについて
現在は同期メッセージのみ対応しています。最
終的には非同期メッセージのサポートが必要でしょう。(ConcurrentSAL が
組み込まれればなおさら)
19
6.3
Sequence 図
Fig2 の足跡ボタンをクリックすると、Tracer クラスがログを分析して Sequence 図を作ります。
このとき、6.2 の 1 のときは各 TestCase ごとにログを分析して表示します
が、2 の場合はログをすべて分析します。
なお、Sequence 図表示のために少しだけ smart.umlmodeler.logical パッケー
ジを拡張しています (smart.umlmodeler.logical.extensions)。
TestCase の扱い TestCase は本来 Object ではないですが、この Sequence
図では他の Object 同様 TestCase も Lifeline で表現しています。
個人的な希望…
いまはとりあえず記録されたものをできる限り全部 Sequence
図にしていますが、将来的には、ユーザがどの要素を表示するか決められた
ほうがよいです。たとえば、
「Sequence 図にはメッセージのやり取りだけ見え
ればよい」といったことです。(そのためにもログ要素抽出が必要。UML2.0
の枠組みがあるので、これに「実行」の概念を加えていけば、多分モデル実
行のログには十分でしょう)
6.4
Composite Structure のチェック機能
Sequence 図同様、実行ログを解析して、ユーザが書いた Composite Structure が正しいかどうかをチェックする機能です。CompositeStructureChecker
クラスを中心としています。
Fig 6: Composite Structure Checking
ユーザが “Check” ボタンを押すことによって、ログを解析します。そのと
き現れるのがこの画面で、上部に誤りのリストを、下部にその直し方を表示
20
します。
現在は、システムでは suggestion のみをしています。「ないから作る」と
いうところまでサポートしていません(作ろうと思えばすぐできるし、本質
的ではないので…)。
7
未実装部分や発見済みバグ…と、個人的展望
7.1
重大なもの
smart.tracer パッケージの Logger.java で、write メソッ
ドを呼び出すときに毎回ログファイルの open/close を繰り返すために、書き
込みの速度が追いついていません。そのため、STT でログを扱うときに、記
録されていないことがあったりなかったりするようです。
ログ記録時の問題
ログ記録は、STT から実行する場合と、STT なしで UML Modeler 単体で
実行を行う場合の 2 つがありますので、これらが開始される時点でログファ
イルを Open、終了時点で Close するように修正するのが最もよいと思いま
すが、flush のタイミングはもう少し考えないとまずい気がします。
Fig 7: AbstractWindow
AbstractWindow おそらくかなり危険な実装になっているのがここです。
現在、UMLModeler のメインウィンドウである UmWindow と、実行時にイン
スタンスの中身を見るための InstanceWindow はほぼ同じ見栄えをしていて、
モデリング画面である ModelScreen(smart.umlmodeler.gui パッケージ内) ク
ラスは、どちらのクラスからも使っています。そのため、プログラムのあちこ
ちで「いま選択されているのはどのウィンドウか」をチェックして、
「現在選択
しているウィンドウの ModelScreen を取ってくる」というような動きをやって
いますが、
「現在選択しているウィンドウ」となるのは、
「ウィンドウがフォー
21
カスを得た」ことを検知したウィンドウ、ということになっています。
(詳細
は、AbstractWindow クラスの内部クラスである AbstractWindowListener
クラスを見てください)
今年はそれほど「実行」にこだわらなかったのでそれほど問題にならなかっ
たのですが、研究が「実行」が重視され始める方向になると、この部分の実
装からバグが出る可能性があります(windowGainedFocus のイベントが正し
く検知されているかが微妙)。もしも、正しく ModelScreen を取得できない、
というバグが現れたら、まずこの部分を疑ってください。
7.2
すぐできそうなもの
本質的でないという理由から実装をサボっている部分を書きます。かなり
単純なものばかりなので、筆者に暇な時間があったらいつの間にか直してい
るかもしれません。
モデル要素の削除
要らなくなった UseCase や StateMachine を Model から
削除する。
保存先とロード先
保存先に保存したものが正しくロードされているかどう
か未確認。特に activity、usecase のセーブとロードはかなり怪しい。(STT
の内部で activity を使っている場合を含めて確認が必要)
7.3
7.3.1
展望
Suggestion
いま個人的にやりたいと思っている(だけど時間がない)のは、Compos-
ite Structure 図から Sequence 図への過程における suggestion です。特に、
Composite Structure の Connector と Sequence 図の Message 群の関係。こ
の Connector と Message 群は、粒度は異なりますが、意味論上同じことを指
している必要がありますので、ここをログから suggest できないかなと思っ
ています。
8
補足
実装に当たる前に書いていた文章がありますので、一緒においておきます。
https://cs33.scitec.kobe-u.ac.jp/dav/seminar/SMARTmanual/Implementation.
pdf
22
9
連絡先
何かあればこちらへどうぞ。
[email protected] ([email protected]す) も
しこっちに出したのに届かなかった場合は、aroma[email protected] へ。
23
ダウンロード

SMART0.3 UML Modeler マニュアル