FC2ブログ

クリプキクローネ日記帳

ある種の音楽と数学とランニングはミニマルなところが似ていると思う。

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
  1. --/--/--(--) --:--:--|
  2. スポンサー広告

かんたんUML入門 [改訂2版] [竹政昭利、他(著)]

今さらUMLに入門しました。


【ユースケース図】
アクターは棒人間(スティックマン)で書かなくてもよいということを知った。
クラス図のクラスみたいなハコで書いてもいいし、いっそのこと任意のアイコンでもいい。
人間じゃない場合もあるから助かる。
けど、スティックマンさんじゃないとユースケース図であると認識されない気もする(笑)。

共通のユースケースを抜き出して点線でつなぐのがinclude。
条件付で他のユースケースを利用する場合をextendで書く。
ユースケースもアクターも、クラス図みたいにis-a関係の汎化も書ける。

CRUD(Create, Read, Update, Delete)は「管理する」というユースケースにまとめるといいらしいけど、
管理するって抽象的すぎてどうなのと思ってしまう。


【オブジェクト図】
オブジェクト図ってクラス図を作るために作るものだったのか。


【クラス図】
参照が一方通行のときは矢印とその根元にバツを書いて「誘導可能性」を表す。
多重度が多くなる場合は、関連の先にハコを書いて識別IDの「限定子」を書くことで、多重度を1にできる。
(社員ID、みたいに)

集約(◇)とコンポジション(◆)はいつもあんまり区別がつかない。
部分インスタンスの生成と消滅の責務を全体インスタンスのみが担う場合、コンポジション(◆)を用いる。

インターフェースは汎化を点線にする。
親を明記する必要がない場合は実線と○(ロリポップ)で表してもいい。

粒度が難しいので、ざっくりの分析クラス図と実装用の設計クラス図を分けて考えるとよい。

多対多になるときは関連に関連クラスを接続して、そのあとで関連クラスを挟む形で書き直すとよい。


【シーケンス図】
同期メッセージは三角頭の矢印(▲)、非同期メッセージは普通の矢印(→)で表す。
りぷらいメッセージは点線の普通矢印で表す。
生成メッセージは点線普通矢印で、矢印の先からハコがスタートする。

メッセージの送信元を明記しない場合(ファウンドメッセージ)、●から延びるメッセージにする。
送信先を明記しない場合(ロストメッセージ)、●へつながるメッセージにする。

loop(繰り返し数)で繰り返し構造を書ける。
alt[条件] でif-else文的なものを書ける。
opt[条件] もほぼ同様。

ref でサブルーチンのように別定義参照ができる。
別定義はsdで書く。

par で並行制御を書ける。

critical で並行実行しないクリティカル領域を書ける。

シーケンス図ってある1パターンの制御について書くイメージだったので、
こんなに分岐とか細かく書けるのは意外。だけどかえって読みづらい感。


【コミュニケーション図】
変換したら「コミュニケーションズ」になった。そりゃそうだよな。
シーケンス図はモジュールが1次元に横に並ぶので、それを2次元配置したいとき用。
時間軸はメッセージに番号をつければ少しは表現できる。


【ステートマシン図】
状態遷移図。
状態の下半分にentry, do, exitというキーワードで開始時、継続中、終了時のアクションを書ける。
繊維の矢印には
トリガ[ガード] / エフェクト
が書ける。

サブ状態で階層化できる。
点線で区切ると同時に管理する別の状態遷移図を書ける。
前回の状態を表す履歴擬似状態(H)を書ける。

アクティビティ図の同期制御のように太い直線を使って、
フォーク擬似状態とジョイン擬似状態が書ける。
アクティビティ図の分岐のように洗濯擬似状態(◇)も書ける。
ただし、ステートマシン図で単なる一過性の一連の処理を書かないこと。

状態遷移表を合わせて書くべきだけど、表はUMLになっていない。


【アクティビティ図】
フローチャートの親戚な割にフローチャートと記法が必要以上に違うから困る。

開始ノード(●)
終了ノード(○の中に●)
アクション(角が丸い□)
デシジョンノードとマージノード(◇)
オブジェクト(□)
など。
さらにはタコさんウインナー的なイベント受信アクションや
シグナル送信アクションなどもある。

パーティションで区切ってもよい。


【パッケージ図】
パッケージ図の階層構造は素直に含有で書いてもいいし、
紙面節約のために○の中に+のコネクタでつなげてもよい。


【コンポーネント図】
オブジェクト図やコミュニケーション図でカバーできる気がする。
モジュールの持つインターフェースをアセンブリコネクタ --(○-- で書けるのがいいんだろうな。


【配置図】
これ大事だと思うけどほとんど見たことないな。
ハードウェアや実行環境、実際のファイル本体の関係を表現できる。


【合成構造図】
ハコの含有関係で要素の構造を書ける。
他の記法でカバーできる気がする。

別の書き方として、役割の依頼元や依頼先の関係を書ける。
というか目的も記法も全然違うのに両方合成構造図なのか…。


【タイミング図】
状態遷移をロジックアナライザの波形のようなもので書ける。
ステートマシン図より時間軸が明確なのがいいけど、1種類の遷移しか書けない。
状態遷移がたくさんあるときはタイミングチャートのようにアイパターンを横に並べる形でも書ける。
時間をより明確に表現したいときはタイミングルーラー( -+-+-+-+-+-)をつけてもよい。
複数のタイミング図を並べてメッセージの送受信を書いてもよい。


【相互作用概要図】
アクティビティ図の中のアクションにシーケンス図が埋め込まれた感じ。
これは読めない!


UMLはまだ知らないことだらけなのでおもしろかったけど、
実際に使って誰からもすぐ理解されるのって結局一番基本的な記法だけなので、
それ以外の記法を使うと定義の説明から始めないといけないからイマイチなんだよな…。
複雑になると読みにくくなるし、難しいところです。

  1. 2017/12/10(日) 01:37:23|
  2. 未分類
  3. | トラックバック:0
  4. | コメント:0
<<ソフトウェアプロジェクトの救済入門 [E.M.Bennatan(著), 富野壽,‎ 荒木貞雄(訳)] | ホーム | ビューティフルセキュリティ [Andy Oram, John Viega(編), 伊藤真浩(訳)]>>

コメント

コメントの投稿


管理者にだけ表示を許可する

トラックバック

トラックバックURLはこちら
http://myumbrella.blog42.fc2.com/tb.php/390-dfeb09f7
この記事にトラックバックする(FC2ブログユーザー)
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。