「ソフトウェアの可視化と品質向上」セミナー参加メモ
「ソフトウェアの可視化と品質向上」へ参加した際のメモです．
■感想
- リバースモデリングの際の留意点について話を聞けたのは貴重な機会だったと思う．
- 品質スイートは進化すれば，モデリングにおけるTDDみたいなことができるのではないかと感じた．
- モデルの管理など，大規模にモデリングを活用していく際の問題は解決していない．
■前説：栗原さん@東陽テクニカ
- ソフトウェアの複雑化に対して，モデルの開発，活用がひとつの解になるのではないか．
■皆川さん@豆蔵：「モデルを利用したソースコードの可視化」
- ここでのモデルとは，対象を何らかの側面で抽象化したもの
- 対象は複数の側面でモデル化することで表現する
- 1つのモデルでは表現できない
- 対象は複数の側面でモデル化することで表現する
- 特に興味を持ったソースコードからのリバースモデリングの留意点についてまとめる
- 対象となるシステムの規模が大きい場合，全体を一律にリバースしても扱いきれなくなることがある．
- パレートの法則に基づき，戦略として{危なそう|理解が困難}な2割のモジュールを{特定|推定}して，それらの理解度を高くして可視化していくことが効率的．
- 機械的リバースは，複雑なものを単純な形で表現することができないため，意味が無い．
- リバースモデリングには，ドメイン知識や暗黙知，開発経験やツール・手法に関するスキル，モデリングに関するスキルが必要
- 視点の特定，不要な詳細の捨象は大事
- 複雑で大きすぎるクラス図はメンテされず役に立たない
- 各視点で分割・整理する．
- 静的構造・動的構造，機能的構造
- 固定部・変動部
- 共通部・機種固有部
- 特定機能毎・レイヤ毎
- 各視点で分割・整理する．
- Why/What/Howの区別
- 手段が変わると影響を受ける部分(How)とそうでない部分(What)，なぜそのような仕組みになっているのか(Why)，の区別を意識しながら，各々の依存関係を整理していく．
- 元々の意図が具体的な手段で隠されていることが多い．また，クラス名が具体的な手段に依存する名前になってしまっていることも多い．
- 意図を示すメソッドを公開インタフェースする
- リバース時に元の文脈から本来の意図を区別して記録しておくと，後のリファクタリング/再設計のための有効な足がかりとなる．-要求との対応付け(SysML)
- 元々の意図が具体的な手段で隠されていることが多い．また，クラス名が具体的な手段に依存する名前になってしまっていることも多い．
- リバース時に要求と結びつけておくことで，後々効率的になる
- 要求とクラスの結びつけは人によってでしかできない
- 手段が変わると影響を受ける部分(How)とそうでない部分(What)，なぜそのような仕組みになっているのか(Why)，の区別を意識しながら，各々の依存関係を整理していく．
- 動的モデルの復元
- 後の再実装で役に立つ．実装がきれいになる．
- コード上では状態の区別を複雑な条件式でおこなうことがある．その構造をSTM図で表現しておくと，再実装で役に立つ．
■中原さん@チェンジビジョン：
- astah*の拡張機能として「品質スイート」開発
- 品質スイート
- 開発者個人が仕様や設計をおこないながら，その場で改善サイクルを回す使い方
- 簡単かつ効率的に使えるようにした
- 品質スイートの機能
- 基本的には動的におこなわれる
- 状態遷移パスの抽出
- nスイッチの遷移パスを抽出
- 状態遷移表の表示
- 前状態/後状態表現，状態/イベント表現
- 外部イベントに対するソフトウェアの振る舞いを記述可能
- イベントが起こりえないのか，イベントを無視するのか定義可能
- DSM機能
- クラス間の循環参照，間接的循環参照，依存の集中の表現
- 動的・静的構造の不整合チェック
- 存在しないクラスやメソッドを利用した場合にエラーが表示される．
■宮野さん@東陽テクニカ(15分位)
□Imagix4D
- リバースツール
- メンテナンス時間の短縮
□Structure101
