> For the complete documentation index, see [llms.txt](https://yutakatay.gitbook.io/katapedia/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yutakatay.gitbook.io/katapedia/doc/uml.md). # UML ## ユースケース 最近図じゃなくて表（No,アクター名,ユースケース名,概要）でいい気がしてきた（2015/03/13） ### ユースケースの粒度 ・レベル１ プロセスチェーン（全社レベル） ・レベル２ ビジネスファンクション（部門レベル：研究開発、生産、販売など） ・レベル３ ビジネスプロセス（担当者レベル：受注処理、見積もり、請求） ・レベル４ タスク（作業レベル：注文を受ける、与信を確認する・・・） ・レベル５ バリアント（処理レベル：書面による受注・・・） ### 矢印の意味 「矢尻の付いていない方のアクターが各ユースケースを起動する主アクターになるという事を示している」という解釈をする人もいれば 「矢尻が付いている方向にデータ/指示の流れがある」と解釈する人もいる ## ユースケースシナリオ ### 書き方 * 代替系列は「Alt-xx」例外系列は「Ex-xx」とする * 例外系列は「本ユースケースを終了する」等どこにもどるかを明確にする。 * Alt,Exはその項番のユースケースを実行したのちに実施される。 ### チェックポイント 1. 文の主語がアクターまたはシステムのどちらかである 2. アクターのアクションに対するシステムの応答がある 3. 各ステップには1つのことだけを記述している 4. UIの動作を記述していない 5. 基本シナリオの終了を明示している 6. 代替シナリオに分岐する条件を記述している 7. 代替シナリオの最後にユースケースが終了するか別のステップに進むかを記述している 8. 設計や実装に関する情報がある場合、特記事項に記述している 9. 未決定事項、仮決定事項がある場合、明文化している ## クラス図 ### 関連線 #### 関係名の例 | 依存のタイプ | キーワードまたはステレオタイプ | 説明 | | ------- | ---------------------------------------------- | ----------------------------------------------------------------------------------------------------- | | 抽象化 | «abstraction»、«derive»、«refine»、または «trace» | 2 つのモデル要素またはモデル要素セットを関連付けます。 これらの要素は、異なる抽象化レベルにある同一の概念、 または異なる視点から見た同一の概念を表します。 | | 抽象化 | «abstraction»、«derive»、«refine»、または «trace» | 2 つのモデル要素またはモデル要素セットを関連付けます。 これらの要素は、異なる抽象化レベルにある同一の概念、 または異なる視点から見た同一の概念を表します。 | | バインディング | «bind» | テンプレートの引数をテンプレート・パラメーターに接続し、 テンプレートからモデル要素を作成します。 | | 実現 | «realize» | クライアントのモデル要素がサプライヤーのモデル要素の実装であり、 サプライヤーのモデル要素が仕様であることを表します。 | | 置換 | «substitute» | クライアントのモデル要素がサプライヤーの代わりとなることを示します。すなわち、クライアントのモデル要素は、サプライヤーのモデル要素で設定している規約 またはインターフェースに準拠している必要があります。 | | 使用 | «use»、«call»、«create»、«instantiate»、または «send» | あるモデル要素が、完全な実装やオペレーションのために、 別のモデル要素を要求することを表します。 | #### ロール名 * 書いても書かなくてもよい ## シーケンス図 #### 目的 * シーケンス図でのメッセージは、主にオブジェクト間の操作の呼び出しに対応します（操作の呼び出しを表す）。メッセージが存在するということは、呼び出される操作が存在するということなので、オブジェクト間に存在するメッセージを検討することで、クラスが持つべき操作を判断することができます。 * クラスやオブジェクトの新しい責務が見つける * シーケンス図の本来の目的は、あるシーンに登場するオブジェクトたちの役割分担を明確にすることです。役割が限定されたオブジェクトが、どのように連携して、１つの大きな動作を実現するのか。それを時間の経過とともに示したものがシーケンス図です。 #### 注意 * よく見られる間違いは、システムのあらゆるシーケンス図を作成しようとすることです。以前に見たプロジェクトチームでは、何ヶ月もかけて、アクションの基本コースに1つ、代替コースごとに1つずつと、ユースケースごとにいくつものシーケンス図を作成していました。シーケンス図を作成するのは、複雑なロジックについてじっくり考えたいときだけにすることを推奨します。ロジックが簡単であれば、シーケンス図を作成してもあまり意味はありません。直接コードを書けばよいのです。 * シーケンス図にすべての処理を描く必要はない * 順序だけのシーケンス図は意味がない * シーケンス図は、単に処理や手続きの順序を示すために描くものではありません。 ## ステートマシン図（状態遷移図） ### 直交状態 並列して動作する状態 ### フォーク擬似状態 直交状態のものに対して並行して処理させるときに使う ### entry,do,exit entry：状態に遷移したときに一度だけ実行される処理 exit：状態から離れる直前に一度だけ実行される処理 do：状態にいる間、継続して実行される処理 ### トリガー・ガード・アクション（エフェクト） トリガー：遷移のきっかけとなる事象を意味する。トリガーを省略したときは、状態のexitアクションが実行された後、自動的に遷移する ガード：遷移してもよいか判断するための条件。トリガーが発生したときにガードが成立する場合のみ次の状態に遷移する。ガードを省略したときは、トリガーが発生したときに無条件で遷移する アクション：遷移するときに実行される処理。省略されたときは、遷移時に実行される処理はない。（e.g. 警告音を鳴らすなど） ## UMLと言語の比較 | | UML | Java | C++ | | --------------------------------------------- | ----------------------------------------------- | -------------------------------- | ---------- | | /10^. クラス図 | クラス | クラス(class) | クラス(class) | | 抽象クラス | abstractクラス | 抽象クラス | | | インタフェース | インタフェース(interface) | なし | | | プロパティ(属性・関連) | フィールド | データメンバ | | | 可視性public(+)protected(#)package(\~)private(-) | アクセス修飾子public protected package private private | アクセス指定子 public protected private | | | 操作 | メソッド | メンバ関数 | | | 静的なプロパティ・操作 | staticフィールド・メソッド | 静的データメンバ・メンバ関数 | | | 汎化 | 継承(extends) | 継承(:) | | | インタフェース実現 | 実装(implements) | なし | | | パッケージ | パッケージ(package) | 名前空間(namespace) | | | /4^. シーケンス図 | メッセージ | メソッド起動 | メンバ関数呼出し | | 生成メッセージ | コンストラクタ、new | コンストラクタ、new | | | ループ複合フラグメント | for文など | for文など | | | オルタナティブ複合フラグメント | if文など | if文など | | ## Tips #### 誘導可能性 A→B：AはBを知っているがBはAを知らない場合。