UML作成ガイド
CacooのUMLガイドへようこそ！
このガイドは、こんな人に役立ちます。
- 複雑なシステムの視覚化に興味がある
- UMLの入門書を求めているシステムアーキテクト、ソフトウェアエンジニア、ソフトウェア開発者
- UMLの基本とUML 2.5でのアップデートについてブラッシュアップしたい
本ガイドは以下の3部構成で形成されています。UMLを基礎や応用など、自分が学びたいテーマを選択しましょう！
UMLの概要
モデリングとは？
モデリングとは、ソフトウェアアプリケーションの設計を視覚化し、チームがコーディングを開始する前に要件を満たしていることをチェックする方法です。
超高層ビルの建設を始める前に建築家が設計図を作成するように、開発者はモデリング図を使って、コーディングを始める前にこれから作るソフトウェアの設計を固め、テストすることができます。
どんなプロジェクトであれ、綿密な計画を立てることで最初の一歩を踏み出します。モデリングは、ソフトウェアプロジェクトの規模の大小にかかわらず、不可欠な要素です。アプリケーションが正常に機能するためには、スケーラビリティ、セキュリティ、実行が可能であるものを設計する必要があります。
統一モデリング言語（UML）図を使用すると、ソフトウェアシステムの設計を視覚化して検証できるので、コード実装後の困難かつハイコストな変更を未然に防げます。
統一モデリング言語とは？
UML 2.5最新版仕様書の適用範囲を見ると、「UMLの目的は、ビジネスなどのプロセスをモデリングすることに加え、システム設計者、ソフトウェアエンジニア、ソフトウェア開発者に、ソフトウェアベースのシステムの分析、設計、実装のためのツールを提供すること」とあります。
UML自体はプログラミング言語ではありませんが、UMLを使ってコードを生成できるツールはあります。 UMLはシステムを設計するためのモデリング言語です。オブジェクト指向設計（Booch）法、オブジェクトモデル化技法（OMT）、オブジェクト指向ソフトウェア工学（OOSE）という、複数のオブジェクト指向表記法を組み合わせて作成されました。そのため、C++、Java、C#などのオブジェクト指向言語や環境に自然に適合します。 しかし、Fortran、VB、COBOLといった言語で、オブジェクト指向ではないアプリケーションのモデリングにも使うことができます。
UMLは意味構造と構文構造の基準を統一させているので、ハードウェア、オペレーティングシステム、プログラミング言語、ネットワークなどとは無関係に、ほとんどすべてのタイプのアプリケーションをモデリングできます。 UMLを使用すると、コード化する前に構造・振る舞いの両方においてソフトウェアシステムのモデルを特定し、視覚化、文書化することができます。
UMLの歴史
UMLは、90年代半ばにグラディ・ブーチ、イヴァー・ヤコブソン、ジェームズ・ランボーの3人（別名「スリーアミーゴス」）によって開発されました。 UMLの初期バージョンは、それぞれUMLの創始者によって開発されたBooch、OMT、OOSEの3つの主要オブジェクト指向メソッドを統合して作られました。また、モデリング言語設計、オブジェクト指向プログラミング、アーキテクチャ記述言語のベストプラクティスも取り入れられています。彼らの努力の結果、UML 0.9と0.91がリリースされました。
1996年、スリーアミーゴスはUML仕様を完成させるためにUMLパートナーズというコンソーシアムを結成しました。HP、DEC、IBM、Microsoftなど、UMLパートナーズには主要な個人や組織も参加していました。その結果生まれたUML 1.1は、標準化のためにObject Management Group（OMG）に提案され、1997年11月に採択されました。以後、OMGがUMLを管理しています。
さらに規模を広げたコンソーシアムの助けを借りて、2005年にUML 2.0が完成し、国際標準化機構（ISO）の承認規格として公開されました。その後も複数のバージョンがリリースされた後、現在のバージョンUML 2.5の「インプロセス」版が2012年10月に、正式版が2015年6月にリリースされました。
こちらから完全版UML 2.5文書をダウンロードできます。
UMLのメリット
制作前にソフトウェアをモデル化すると、チームにとってメリットが沢山あります。 1つには、チームでの作業を論理的に順序立てるのに役立ちます。どのような成果物を開発する必要があるのか知ることで、チームで取り組むタスクをより正確に定義付けます。チームがプロジェクトの製品や過程を管理するための基準を確立するのにも、モデリングは役立ちます。
UMLを使うとウォーターフォールスタイルのソフトウェア開発に囚われてしまうのでは、と心配する人もいますが、必ずしもそうはなりません。 UMLは、開発のさまざまな段階で作成し活用でき、更新・実装を反復し続けることができます。
その他の主なメリットは次のとおりです。
- 冗長性の削減。 図を見ることで、プログラマーが冗長なコードに気づき、関数を書き換えるのではなく、すでにあるコードの一部を再利用できるようになります。
- 変更の簡素化。 最初に図に変更を加える方が、後でコードを再プログラミングするよりも簡単です。チームは貴重な時間とコストを節約できます。
- 不明瞭さを克服。 設計文書にできることは限られています。長期的には、製品の歴史を知らない開発者やリモートで働く開発者とコミュニケーションを取る必要性が出てくるでしょう。
UML図を選択する
UMLは最も広く使われ理解されているモデリング言語です。 UMLは、今日使用されている最も一般的なモデリング言語です。ほとんどの開発者が専門分野や職歴にかかわらず、少なくともUMLの一部に精通しているため、普遍性はそれ自体がメリットと言えます。また、プログラマーのタイプにかかわらず理解できるように意図されているので、特定のプログラミング言語を読み込む必要はありません。
よく使われる3つのUMLが、あなたのモデリングニーズの大部分をカバーします。 アプリケーションをモデリングするUMLは14種類ありますが、実際に開発者がソフトウェアシステムを文書化するのに使うUMLは限られています。最も一般的に使われているUMLは、クラス図、シーケンス図、ユースケース図の3つです。つまり、UMLの20％を使いこなす方法さえ知っていれば、ほとんどのプロジェクトで充分です。
UMLの種類
UML 2.5では、正式のUMLが14種類あり、2つのタイプに分類されています。
1. 構造図 は、システムの静的な部分の相互の関連を示します。各要素は特定の概念を表し、抽象的概観から、実世界、実装などの要素を含むことができます。
2. 振る舞い図 は、時間軸に即したシステムへの変化を含め、システム内のすべてのオブジェクトの動的な振る舞いを示します。 相互作用図は、振る舞い図のサブセットとみなします。
Cacooでアクティビティ図を作成する方法
構造図
UML 2.5には7つの構造図があります。
- クラス図：システムの構造を、クラスやインタフェースと、それらの機能、制約、関係性を関連づけて示す。
- コンポーネント図：コンポーネント間の依存関係を示す。
- コンポジット構造図：分類子の内部構造とその構造が可能にする連携された振る舞いを示す。
- 配置図：システムのさまざまなハードウェアと、ソフトウェアの配置を示す。
- オブジェクト図：ある時点での実際の構造例を示す。
- パッケージ図：パッケージとパッケージ間の依存関係を示す。
- プロファイル図：カスタムステレオタイプ、タグ付き値、制約を示す
振るまい図
また、7つの振る舞い図があり、そのうち最後の4つは相互作用図の一部です。
- アクティビティ図：システム内コンポーネントのビジネスプロセスや、オペレーションのワークフローを示す。
- ユースケース図：特定のアクター（利用者）と各機能がどのように関係するか示す。
- 状態マシン図：システムの状態と状態遷移を示す。
- コミュニケーション図*：オブジェクト間の相互作用を、時系列に沿ったメッセージによって示す。
- 相互作用概観図*：相互作用や相互作用の利用を表すノードによって制御フローの概観を示す。
- シーケンス図*：オブジェクト間の通信関係と、メッセージの順序を示す。
- タイミング図*ある時間枠内においてシステムのタイミング制約を示す。
UMLの作成
チュートリアル＆サンプル
パート1で紹介したとおり、UMLには14種類ありますが、開発者が通常モデリングに使うものは限られています。このセクションでは、アクティビティ図、クラス図、シーケンス図、ユースケース図を作成する方法について説明します。
上記4種類のUMLテンプレートと図形は、Cacooでご利用できます。
アクティビティ図
動作とは、ユーザー、システム、または両方が共同作業で行うタスクです。
コネクターはアクションを順番にリンクします。
ノードは、アクティビティの開始または終了を示します。フォークやマージを示すこともあります。
Cacooでアクティビティ図を作成する方法：
- Cacooエディタで、[テンプレート一覧]から[アクティビティ図]を選択します。
- 角丸長方形を使って、各アクションを表します。
- 線を引いて、アクションから別のアクションへ流れを実証します。
- 円形を使い、アクティビティの終了を示します。
- オプションとして、アクションを実行する異なるオブジェクトまたはビジネスロールに対応する領域（スイムレーン）に、アクションを配置します。
- 図を保存します。
クラス図
クラスは、データ型またはオブジェクト型を表し、上部にクラス名の入った長方形で表現されます。
属性は、型のすべてのインスタンスが持つことができる名前付きの値です。クラス名の下にリストされます。
メソッドは、型のインスタンスが実行できる関数です。属性の下にリストされます。
Cacooでクラス図を作成する方法：
- Cacooエディタで、[テンプレート一覧]から[クラス図]を選択します。
- すべてのクラス、属性、メソッドを追加します。
- データに応じて新しい図形を追加します。
- 線を使って、型間の関連、継承、または依存関係を描画します。あなたの表記スタイルが線のスタイルを決定します。
- 図を保存します。
シーケンス図
クラスは、データ型またはオブジェクト型を表し、長方形で表現されます。
生存線は、参加要素に起こる一連のイベントを表し、下方向に行くにつれ時間の経過を示す垂直線です。参加要素になるのは、クラス、コンポーネント、またはアクターのインスタンスです。
メッセージはオブジェクト間の線で表されます。
Cacooでシーケンス図を作成する方法：
- Cacooエディタで、[テンプレート一覧]から[シーケンス図]を選択します。
- 長方形ボックスを使ってクラスインスタンス名、クラス名、またはオブジェクトを示します。
- 垂直の生存線でメッセージを時間軸に沿って表示し、水平方向の要素によってメッセージが中継されるときのオブジェクトインスタンスを表示します。
- メッセージの送信側と受信側を表す線を引きます。同期メッセージはブロック矢印、非同期メッセージは実線矢印、コールバックメッセージは破線で表します。
- 図を保存します。
ユースケース図
アクターは、アプリケーションやシステムとやりとりするユーザー、組織、外部システムなどを表します。アクターは型の一種です。
ユースケースは、特定の目標を追求する際に1人または複数のアクターによって実行されるアクションを表します。ユースケースは型の一種です。
アソシエーションは、アクターがユースケースに参加することを示します。
Cacooでユースケース図を作成する方法：
- Cacooエディタで、[テンプレート一覧]から[ユースケース図]を選択します。
- アクターに棒人間（ステンシル> ソフトウェア> UML）または他の関連図を使ってラベルを付けます。
- 楕円形を使ってユースケースにラベルを付けます。
- 線を引いて、アクターとユースケースの関係をモデル化します。
- 図を保存します。
UMLテンプレートと図形
Cacooを使えばUMLを一から作るのも簡単ですが、テンプレートを利用すると作業時間を更に大幅に節約できます。
CacooにはUML用テンプレートを各種用意しております。エディタを開いてテンプレートを選択すれば、すぐに作図を始められます。作りたいUMLに合わせてカスタマイズしてください。
再利用したい図形があれば、新しいテンプレートかステンシルとして保存しておくことができます。カスタムテンプレートとステンシルを使用して、最高の作品を何度でも創り出せます。
高度なヒントとテクニック
UMLのベストプラクティス
図を他の人と共有するときは、見やすく、理解しやすく、一貫したルールに従っているか確認しましょう。実際のモデルを変更するものではありませんが、あなたが伝達したいシステムや目標の、チームに伝わる力が大きくアップします。
フォントと色は最小限に
読みやすさは理解を促進します。図を表示するときは、すべてのテキストを読みやすくしましょう。ズームでしかテキストが読めない場合、情報が多すぎるか、図が複雑すぎます。
また、フォントに凝りすぎないよう注意しましょう。通常フォントタイプは一つにします。タイポグラフィのスキルに自信がある人は、2つまたは3つのフォントに挑戦しても良いですが、見た目のためだけや特に理由がない場合は追加しません。デザインが図の読みやすさに貢献していないのなら、逆効果になりかねません。
色は、図を差別化するのに最適な方法です。図をより読みやすく、プロフェッショナルに仕上げることができます。色は控えめに使います。やりすぎてしまうと、大切な情報から読者の注意をそらすだけでなく、色使いが統一されていない場合、混乱を招く可能性もあります。図を明瞭化するために必要な色数は、最小限に抑えてください。色の凡例を示すと便利です。
情報は少ないほど有効
視点を限定し、重要な要素をしぼって作図しましょう。図に含まれる要素の数が多すぎると、あっという間に大きく複雑になり、誰にとっても読むのが難しくなってしまいます。
図が大きければ伝わる情報が多いわけではなく、大きすぎる図は混乱を招きます。複雑なシステムの場合は、情報を細分化し、消化しやすいサイズの図に分割しましょう。
どのくらいの情報量を入れ、どのくらいを外すべきか考えるとき、標準サイズの用紙に印刷した時にどう見えるか想像してください。読むのが難しそうな場合は、スケールを戻してもう一度やり直しましょう。
また、図に含まれるすべての属性、関連、または制約に名前を付ける必要はありません。図の現時点での視野に関するアイテムのみを表示します。その情報について別の図の中で詳述します。
線を交差させない
図中の線は交差させません。これは、図を分かりやすくするためだけでなく、システムに設計上の欠陥がないことを保証するためにも重要です。
図中で2本以上の線がどうしても交差してしまう場合、次のいずれかが当てはまります。
- 図中に情報が多すぎます。おそらく2つの異なる視点を組み合わせようとしているか、または1つの図で深く掘り下げすぎています。情報は少ないほど有効であると覚えておきましょう。
- モデルに設計上の欠陥があります。システムに設計上の欠陥が見つかるのは最悪のシナリオですが、できるだけ早く見極めることが大切です。すべての動作可能なシステムは、線を交差することなく表示できます。システムを視覚化するのが苦手な人は、要素を見落としていないかどうか確認してください。
直角を使う
図中のすべての線は、水平または垂直のどちらかに引き、角度はすべて直角にします。線をまっすぐ伸ばすことで、図が即座に明瞭になります。
唯一の例外がユースケース図ですが、相互関係を表すのに斜めの線を使うことがあります。
子の上に親
図に階層を表す場合、必ず親要素を子要素よりも上に配置し、矢印が常に上向きになるようにします。
ほとんどの人がこのルールを知らなくても守っていますが、階層構造を逆さまにしてしまう人が時々現れます。一貫性を守るために、常に親を最初に置きましょう。フローを理解するために、読者が新しい規則に合わせなくてはいけない事態を防ぎます。
一つの親から下りてくる子要素が複数ある場合は、縦のツリースタイルで階層を表します。
一貫性を保つ
フォントや色だけではなく、全体の一貫性を確認します。作図が終わったら、すべての要素を均一に扱えたか確認するために、以下を素早くチェックしましょう。
- 片側または中心に要素が整列されているか、必ずダブルチェックします。
- 可能であれば、同じタイプの要素が同サイズであることを確認します。
UMLは読みやすいほど有用です。見る人が理解できなければ、その時間を無駄にしてしまいます。これらのルールに従うことで、チームメンバーが素早く理解できる、整理された分かりやすい図を確実に提供できます。
UMLツールの選択
UMLを人前に出す必要がある場合は、アプリケーションやソフトウェアを使用して作成するのが良いでしょう。
ツールを選ぶ際に考慮すべき点は次のとおりです。
どんな共有機能があるか
あなたのデザインを他の人に見せたり、コメントをもらったり、編集までしてもらいたいとき、ツールにどのような共有オプションがあるか確認します。
同じツールをインストール済みの人とだけ共有できるのであれば、非常に限定されます。クラウドベースのツールなら、他の人があなたのデザインを見るときログインする必要があるか確認しましょう。
エクスポートに関しては、どのようなフォーマットオプションがありますか。UMLをウェブページに直接埋め込む場合はどうですか。
それぞれのツールに利点と欠点がありますが、共有機能が優先される場合は、図を共有できる相手や、コメントできる人、編集できる人が誰になるのかを把握しましょう。
共同作業ができるか
ツールによっては、共同作業のためにチームメイトにファイルをエクスポートする必要があります。これによりバージョン管理が難しくなり、他の人の作業が終わるのを待つ間にデザインプロセスが滞ることも起こり得ます。
その一方で、同じ図を見ながらリアルタイムで一緒に作業ができる、同時編集が可能なツールもあります。
単独で作業する場合は、共同作業の機能は重要でないかもしれません。反対に定期的にチームがファイルにアクセス・編集する必要がある場合、この機能があるとかなりの時間を節約できます。
どのデバイスで利用できるか
複数のデバイスを使用してチームで作業している場合は、どこにいてもチーム全体に楽にアクセスできるクラウドベースのツールが欲しくなるでしょう。
単独で作業している場合は、ダウンロードが必要なツールで十分かもしれません。締め切りぎりぎりに更新したくなったとき、自分のパソコンが近くにあるよう気を付けさえすれば問題ありません。
オフラインアクセスが必要か
インターネット接続の範囲外で作業することが多い人にとって、ウェブベースのツールは良い選択ではないかもしれません。
公共のWi-Fi接続やホットスポットが普及するにつれ、以前ほど大きな問題ではなくなりましたが、状況によってはまだオフラインアクセスを必要とする人もいるでしょう。
どんな既製テンプレートが利用できるか。自分で作ることはできるか
UMLを一から作成する必要はありません。ベースとして使える好きなテンプレートや、気に入っている図形が、誰にでもあると思います。各ツールにどのようなテンプレートの種類があるか見てみましょう。
さらに、独自のテンプレートや図形を作成しアップロードできるか確認します。特に大きなプロジェクトで多数のUMLをデザインしている場合、使用可能なテンプレートのライブラリをカスタマイズできると、作業スピードが上がります。
UML作成にCacooを選ぶ理由
素晴らしいデザインを制作するには、どのタイミングにどのツールを使うか適切に判断する必要があります。だからこそ、機能を網羅しようとするのではなく、各ツールが特定のニーズに対してどう役立つかを検討することが大切です。
習得しやすく簡単に使えるCacooは、インターネット接続さえあればどこにいても使えます。クラウドベースで図を作成することにより、リアルタイムでチームと共同作業でデザインでき、大切なステークホルダーとも共有できます。ソフトウェアのダウンロードやアカウントへのサインアップは必要ありません。
数分もあれば図を作成でき、UMLだけでなく、フローチャート、マインドマップ、サイトマップ、ネットワークダイアグラム、ワイヤーフレームなど、様々な種類の図を作成できます。
仕事の流れを管理するのにもCacooを活用いただけます。「チームプラン」では、個々のプロジェクトに図を保存したり、複数のグループと自動的に図を共有したり、アプリケーション内のコメントで簡単にフィードバックを受け取ったりすることが可能です。
他にも次のことができます。
- 柔軟な書き出しオプション（PNG、PDF、PPT、PostScript、SVG）
- 変更履歴（変更内容と日時を確認できます）
- アプリケーション内チャット（もちろんコメントも）
- ダウンロード不要の共有機能
- 図の埋め込み（外部のウェブページに図を埋め込みます）
- チーム管理（メンバーの招待、グループ作成、役割の割り当て）
- 高度なセキュリティ（アクセス権限を管理し、誰が見ているか正確に把握します）
無料トライアルで14日間お試しいただけます。図の作成からチームメンバーとの共同作業まで、Cacooがあなたにとって最適なツールかご確認ください。クレジットカードの登録は不要です。
共同作業の機能が不要な人には、プロプランがおすすめです。世界中のユーザーがなぜ Cacoo を選んでいるのか、ご自身の目でお確かめください。
