ステート チャート 図。 あなたにもできるオブジェクト指向設計――UMLを覚えよう(第4回)

UMLとは?書き方とクラス図・シーケンス図などの9つの図を解説

ステート チャート 図

UML(Unified Modeling Language:統一モデリング言語)の定める の一つに「ステートチャート図 State Chart Diagram」があります。 状態遷移図を基本にし、簡略化した記述ができるように拡張されています。 遷移の矢線の上だけでなく、状態の入口と出口にアクションが記述できます。 状態遷移図には条件判定がありませんでした。 条件判定が必要な場合には、新たな状態を追加して表現するのですが、遷移図が無意味に複雑になる場合があります。 このような場合イベントに条件を追加して記述し、スッキリした図にすることができます。 状態遷移図を描く目的の一つは、複雑な要件の組み合わせを整理するためです。 したがって、チマチマとした条件判定をするのではなく、• 新たな状態を追加したらスッキリするのではないか• 全体を「 遷移後アクションする 」 に統一できないか(入場アクション)• 全体を「 アクションしてから遷移する 」 に統一できないか(退場アクション)• 状態数を減らせないか という検討をしてください。 ステートチャート図で全てを表現しようとすると記述が複雑になり、ステートチャート図の利点がそがれますが、 つぎのような機能もあります。 ステートチャート図の四角の中に状態名を記述する代わりに、別のステートチャート図を記述することができます。 四角の中を縦に破線で区切って、並行して状態遷移をする図を並べて記述することができます。

次の

18.4 ステートチャート図

ステート チャート 図

UMLとは? UMLとは Unified Modeling Languageの略語です。 日本語では「 統一モデリング言語」と呼ばれています。 複雑なシステム開発をグラフィカルに表現し、記述方法を統一することで設計書の読みやすさやコミュニケーションの効率アップに役立ちます。 UMLというのは 手法の総称であって、UML自体が特定の記述方法を指すわけではないので注意しましょう。 たとえば「プログラミング言語」はシステムを動かす言語の総称であって、「Ruby」や「PHP」という個別の言語を指しているわけではないのと同じです。 UMLも同じように、個別の手法は「クラス図」や「ユースケース図」などさまざまです。 混乱しないように気をつけましょう。 UMLを使って何をするのか UMLを使うことによって「システムの分析と全体像の視覚的理解」、「欠陥部分を発見」、「コミュニケーションの促進」といった効果が期待できます。 たとえば、新しくシステムを開発するときや既存システムを保守・機能追加するときに設計書がすべて文字のみで構成されていたら大変ですよね。 作るほうもとても労力がかかりますし、別の人が読んだときに理解できるか怪しいです。 UMLはシステムの全体像(もしくは局所的な部分)を、図形を使って表現します。 文字ベースの設計書よりもシステムの概要を把握しやすく、問題点の発見も容易になるのがイメージできると思います。 特にUMLが優れているところは、記述のルールが明確に決まっている点です。 UMLを使用するメリット 図形を用いてグラフィカルにシステムを表現しても、作成方法が人によって異なると保守性が高いとは言えません。 AプロジェクトとBプロジェクトの設計図で、図表の書き方が異なっているとミスや誤解の原因にもなります。 そういった問題点を解消したのがUML図です。 従来の文字ベースの設計書に比べて視覚的に理解しやすく、かつ記述ルールが明確に決まっているので保守性の向上につながります。 UMLの歴史 UMLが普及する以前は数多くの表現ルールが乱立し、どのルールを使うべきかシステム開発者を悩ませていました。 それが OMG( Object Management Group:オブジェクト指向技術の標準化を行なう団体)によって正式に認定されたことを契機に普及が進みました。 UMLが共通言語として一気に普及して以来、開発者が母国語の違いを超えて設計図を読み書きできることができるようになり、その利便性は計り知れません。 また、日本語特有のあいまいな表現を使った文書ベースの設計書よりも、UML図を見せたほうがコミュニケーションがスムーズに済むようになりました。 現在ではUML自体を説明する機会は少ないかもしれません。 しかし、システム開発に馴染みのない人から質問をうけることが予想されます。 UMLはもはや、システム開発にかかわる人は理解必須の概念となっています。 正しく理解を深めましょう。 UMLを使って何ができるのか? 実は、UML自体はあくまで「図形を用いた設計図の記法」に関するルールを定めているだけで、使い方についての定義はありません。 つまり、UMLをどう使うかはシステム設計者の裁量に任せられています。 とはいえ、システム開発の実務においてはUMLの使い方はある程度パターンが決まっています。 下記で、システム開発時のUML活用法を3パターン紹介します。 どのパターンにも共通している点は「 イメージの共有」です。 モデリングを使って全体像を描く 要件定義の段階では、クライアントの要望をヒアリングしてシステムの全体像を描く「 モデリング」という作業が発生します。 このときに、UMLの手法の1つである「 クラス図」を用いてモデリングするケースが多いです。 UML(クラス図)を使ってモデリングする理由は、覚えるべきルールが少なく、かつ直感的に理解しやすいためです。 ITに詳しくないクライアントでも理解しやすいです。 クラス図については下記で詳述します。 ちなみに、モデリングをする人をモデラーと呼び、モデリングで作成した図のことを概念モデルと呼びます。 UMLを使って設計図を書く 全体像をUMLで記述した後、具体的な設計書に落とし込むときもUMLで記述することが可能です。 モデリング時と比べて、UML図を作成する目的と厳密性が異なります。 モデリング時は「どのようなシステムを作るか」を意識する一方で、設計時には「どのようにシステムを動かすか」を意識します。 モデリング時よりも詳細な内容をUML図に落とし込む必要があります。 また、小規模プロジェクト限定ですがメンバー間で設計方法が共有されている場合は、コーディング後のプログラムから設計書を作成することもあります。 モデリングや設計はUMLを使うことも可能ですが、「プログラミング」はプログラミング言語を使ってコーディングする必要があります。 しかし、ツールを使うことでモデリングからプログラミングまでの流れをUMLだけで完結することが可能です。 この技術を MDA( Model Driven Architecture)と呼びます。 しかし、実際の現場ではMDAはあまり普及していません。 ツール自体が未成熟な技術であることと、業務上の仕様などUMLで記述しきれない部分があるからです。 今後MDAの技術がさらに発展すればUMLのみでプログラミングまで完結するようになるかもしれません。 しかし現時点では、コーディングはいまだにプログラマーが設計書を見ながら手作業で行っています。 UMLの種類 最後にUML図の種類についてご紹介します。 上記でも少し登場したように、UML図には「アクティビティ図」や「クラス図」「シーケンス図」などといった複数の手法があります。 種類は多いですが、それぞれシステム開発において頻出する単語です。 この機会に概念だけでも覚えておきましょう。 クラス図 クラス図とは、クラス同士のつながりを表現した図です。 どのクラスがどこのクラスとつながっているか視覚的に理解できるため、システム全体の構成を理解するときに役立ちます。 上記で説明した、システムの全体像をモデリングするときによく使用されます。 直感的に理解しやすいので、クライアントへの説明時にも重宝します。 プレゼン時だけでなく、クラス図は分析・設計・実装など全段階で使用されます。 クラス図はUMLの中で最も基本的な手法です。 必ず理解しておきましょう。 コンポーネント図 コンポーネント図は、システムを実装する際に使われるダイアグラムです。 システムを構成する要素(コンポーネント)間の関係を図で視覚的に表します。 関係性を表す、という意味ではクラス図と似ています。 しかしコンポーネント図は「複数のクラスで構成される処理を、1つのクラスのように取り扱っている」点に注意です。 コンポーネント図は細かいクラスの集合を1つの要素(コンポーネント)として扱うことで、システムの内部構成を表現することができます。 内部構成図を表現できるので、システム実装時に便利です。 配置図 配置図は、システムの物理的な配置構造を図式表現したものです。 物理ハード要素と内部のコンポーネント、その間の通信関係を図で表します。 配置図によって、ハード要素ごとの依存関係を視覚的に理解することができます。 コンポーネント図に物理的な要素を追加し、要素間の関係を表現したのが配置図と理解すると分かりやすいです。 パッケージ図 パッケージ図はシステム全体のクラスをグループ化するときに使用します。 特にサブシステムやモジュール間の構造・依存関係を、視覚的に理解したいときに便利です。 パッケージ図とコンポーネント図は似ていますが、使う目的が異なります。 コンポーネント図はシステムのインターフェイスを説明するときに使います。 一方でパッケージ図は、システム内で関連しているクラスをグループ化するための手段です。 コンポーネント図はシステムの処理の流れを表現するときに便利です。 よってクライアントへの説明時によく利用します。 一方、パッケージ図はシステムの流れを把握するには不向きですが、関連する要素をひとつのパッケージとしてまとめて確認する作業に向いています。 よって開発時によく使用されます。 パッケージ図を作成するときのルールですが、パッケージはファイルフォルダの形で表します。 ユースケース図 ユースケースとは、利用者目線で「このシステムはこんなことができる」を表現することでシステムのイメージを掴む手法です。 ユースケース図を作成することによって、実際にシステムを利用するときの仕組みの流れと関係性が、視覚的に理解できます。 ユースケース図は、システムの機能分析で使用されます。 設計中のシステムと利用者、外部システムとのやり取りを記述します。 ユースケース図では「アクター」「システム」「ユースケース」「関係」の4要素が含まれます。 アクターとは、システムを操作・利用する人のことを指します。 それぞれの関係は詳細には示しません。 シーケンス図 シーケンス図は、アクターが操作したシステムがどのように実行されるか、相互作用の関係性を視覚的・時系列的に表した図です。 シーケンス図はユースケース図と似ています。 しかしシーケンス図の場合は、命令から実行までの流れを時系列的に詳述している点、オブジェクト間の通信関係を全体的に表示している点が特徴です。 ユースケース図の場合は、アクターとシステムの関係を確認する場合に使用されます。 一方、シーケンス図は「あるアクションに対するシステムの処理の流れ」を順番に表現できるので、エンジニア以外の方でも比較的理解しやすいのがポイントです。 コラボレーション図 コラボレーション図は、複雑なシステム処理の流れをロジックに基づいてモデル化するときに使用されます。 システム同士の関係性・相互作用を記述することによって、特定のタスクを実行する場合の、システムの相互関係を視覚的に把握できます。 コラボレーション図とシーケンス図はともてよく似ていますが、得意としている役割が若干異なります。 シーケンス図の特徴は「システム処理の時間の流れ」が分かりやすいという点です。 上から下に、順序付けて表現されているためシステムの時系列順の処理がとてもわかりやすいです。 一方のコラボレーション図は「アクターを含む、システム間の相互作用」を分かりやすく明示しています。 コラボレーション図でも時系列を番号付けすることで表現することができますが、シーケンス図よりも全体的なオブジェクトの相互関係・システム処理の流れを理解したいときに役立ちます。 ステートチャート ステートチャート図は、システム上でイベント(アクターからの入力など)が発生した場合、「オブジェクトが実行可能なすべての動作」を図示します。 ステートチャート作成の目的は、オブジェクトの動作開始から終了までの状態変化をすべてモデル化することです。 これをシステムのライフサイクルと言います。 シーケンス図では「ひとつのユースケースの事例を表現」するのに対して、ステートチャートは「オブジェクト(システム)の普遍的な状態」を表現しています。 アクティビティ図 アクティビティ図とは「システム実行の流れ」を表現した図です。 システムが実行されるときは必ず終了へ向けてプログラムが事項されます。 その流れを左から右に、流れに沿って図示したのがアクティビティ図です。 アクティビティ図はフローチャートとほぼ同じなので、比較的簡単に理解することができます。 シーケンス図と似ていると思うかもしれませんが、シーケンス図は「オブジェクト間の相互作用」を表した図です。 アクティビティ図はオブジェクトではなく、アクティビティ(処理内容)について順序立てて記述します。 場面に応じてUML図を使い分けよう UMLについて理解することはできたでしょうか。 概念的には理解できても、最後に紹介した手法を使いこなすには実践あるのみです。 UMLを理解するのは大変です。 しかし、覚えたらシステムの仕様書などが読めるようになり、一気にシステム開発への理解が深まります。 変化の激しいIT業界ですが、基礎的なルールは意外と変わらないです。 経験の浅いうちはUMLに限らず、基本的な用語・開発手法を理解するように心がけましょう。

次の

ステートマシン図

ステート チャート 図

今回はアクティビティ図について説明します。 相互作用図やステートチャート図を描くにはオブジェクトが必要ですが、アクティビティ図を描くのにクラスやオブジェクトは不要です。 前回宿題として挙げておきました「弁当作成」の第3のモデルを考える前に、UMLのアクティビティ図について弁当作成の例題で説明します。 アクティビティ図 アクティビティ図は処理の流れを表現するのに使用し、フローチャート図と似ています。 お母さんが弁当を作成する手順は大きくは、「 (1)材料を準備する」「 (2)弁当を作る」という2つのステップからなります。 アクティビティ図で表現すると 図1のようになります。 黒丸で表された開始点からスタートし、(1)、(2)のアクティビティを順番に実行して終了します。 アクティビティは何かの処理を行っている状態です。 処理が終了すると次のアクティビティに遷移します。 図3 サブアクティビティ 分岐と合流 条件分岐はひし形で表現します。 フローチャートの条件分岐はYES/NOの2分岐ですが、アクティビティ図は2つ以上の分岐を表現できます。 条件は、ひし形の出口となるすべての遷移矢印の横にガード条件として記述します。 ガード条件は文章または式で記述して[]でくくって表します( 図4a)。 条件分岐のひし形は省略可能です。 図4bは1つのアクティビティから2つの遷移矢印が出ていますが、ガード条件を満足する方に遷移します。 それぞれのガード条件は排他的に記述します。 両方に同時に遷移することはできません。 条件分岐したフローが1つに合流する場合も同じひし形で表現します( 図4c)。 この場合ガード条件は不要です。 合流のひし形は省略可能で、1つのアクティビティに入力となる複数の遷移を直接記述することもできます( 図4a、 図4b)。 図4a、 図4b、 図4cは同じ意味で、ひし形は分岐・合流を特に明示したい場合に使用します。 図7 第7回の「弁当作成」の第3のモデル 【 シナリオ:卵焼き弁当を取得する】• Aさんは、母に弁当を依頼する• 母は、米びつから米1合を取得する• 母は、炊飯器に米1合をセットしてご飯を炊く• 母は、冷蔵庫から卵を取り出そうとしたがなかった• 母は、妹に買ってくるように依頼する• 妹は、卵を買ってきて母に渡す• 母は、フライパンで卵焼きを作る• 母は、弁当箱を洗って、ご飯と卵焼きをセットする• Aさんは、母から弁当を受け取る。 図7のシーケンス図はAさんがお母さんに弁当を依頼したところから始まります。 お母さんの作業は、 図1のアクティビティ図のとおり大きくは材料の準備と、弁当の作成です。 母は「材料を準備する()」という再帰呼び出しを行う• 母は「弁当を作る()」という再帰呼び出しを行う それぞれの内部処理は次のようになります。 1は 図2のアクティビティ図のとおり、大きくはご飯の準備と卵焼きの準備です。 この2つはどちらを先に実行しても構わないので非同期型で呼び出します。 2は 図3および 図5のアクティビティ図のとおり、ご飯と卵焼きの完成を待ってそれぞれを弁当箱にセットすることです。 この2つもどちらを先に実行しても構わないので非同期型で呼び出します。 そのほか詳細は 図8とその説明に示します。 図8 第3のモデルのシーケンス図(クリックすると拡大) 図8の説明 1 母は「材料を準備する()」という再帰呼び出しを行う 1-1 母は「ご飯を準備する()」という再帰呼び出しを行う 【非同期】 1-1-1 母は米びつの「米を取得する()」を呼び出し、米1合を取得する 1-1-2 母は炊飯器の「炊飯器をセットする()」を呼び出す 【非同期】 1-1-2-1 炊飯器は「米を炊く()」という再帰呼び出しを行う 1-2 母は「卵焼きを準備する()」という再帰呼び出しを行う 【非同期】 1-2-1 母は冷蔵庫の「材料を取得する()」を呼び出す(シナリオとしてここではエラーが返る) 1-2-2 母は妹の「材料を取得する()」を呼び出す 1-2-2-1 妹は「買い物をする()」という再帰呼び出しを実行し、卵を母に渡す 1-2-3 母はフライパンの「フライパンをセットする()」を呼び出す 【非同期】 1-2-3-1 フライパンは「調理する()」という再帰呼び出しを行う 2 母は「弁当を作る()」という再帰呼び出しを行う 2-1 母は「調理待ち()」という再帰呼び出しを行う 【非同期】 2-1-1 母はご飯の炊き上がりを待って弁当箱の「弁当をセットする()」を呼び出し、ご飯をセットする 2-2 母は「調理待ち()」という再帰呼び出しを行う 【非同期】 2-2-1 母は卵の焼き上がりを待って弁当箱の「弁当をセットする()」を呼び出し、卵焼きをセットする 最後のまとめ 第1回から第8回までの内容を振り返ってまとめてみましょう。 第1回から第3回まではオブジェクト指向の基本的考え方、第4回からはUMLを用いました。 【 】 ソフトウェアの世界は知らない間にオブジェクト指向の考え方が広く浸透して「どこでもオブジェクト」といった状況です。 最近広まりだした1つの理由はインターネットの普及があります。 オブジェクト指向の「自律分散協調動作」の考え方がインターネットやユビキタスコンピュータという時代の要請と方向性がよく合っているからです。 人間をオブジェクトと考え、日常の人間社会をオブジェクト指向でとらえる考え方が自然にできます。 今回の企画に用いた例題も日常生活をベースにしました。 オブジェクトとは単に存在する「もの」ではなく、まず認識する主体が存在し、その主体が認識する対象物がオブジェクトです。 【 】 認識の対象物で次の条件を満たすものをオブジェクトと呼びます。 固有の姿・形・性質を持つ(属性) 固有の振る舞いを持つ(操作) ほかのオブジェクトと何らかの関係を持つ 個別のオブジェクトとして識別できる 1つ1つ具体的なものをオブジェクトと呼び、同様のオブジェクトをグループ化して抽象化したものをクラスと呼びます。 クラスに属するオブジェクトをインスタンスと呼びます。 オブジェクトとインスタンスは結局同じですが、インスタンスといったときはクラスを明確に意識しています。 【 】 複雑なものを単純化して理解するための一般的な2つの手法「分類と分解」はオブジェクト指向にも取り込まれています。 汎化/特化関係によるクラス階層はクラスの「分類」です。 オブジェクトを全体と部分でとらえる複合オブジェクトはオブジェクトの「分解」です。 【 】 ここからUMLを用いますが、当企画はUMLそのものの形式的説明よりもあくまでオブジェクト指向の考え方を理解することに重点を置いています。 クラスの関連、多重度およびインスタンスのリンクをUMLで表現します。 【 】 クラスを階層化して分類する汎化/特化関係と、オブジェクトを分解して全体と部分でとらえる集約関係をUMLで表現します。 UMLの最も基本的なダイアグラムであるクラス図は、関連/汎化/集約などで表現します。 クラス図は静的構造を表すモデルです。 【 】 相互作用図は、オブジェクト間のメッセージによる協調動作を表現します。 相互作用図にはメッセージの時系列に焦点を当てるシーケンス図と、オブジェクト間のコラボレーションに焦点を当てるコラボレーション図があります。 【 】 ステートチャート図は、ある特定のオブジェクトに注目してその状態変化を表現します。 あるオブジェクトの生成から消滅までのライフサイクルを表現することもできます。 【 】 最終回は処理の流れを表現するアクティビティ図です。 アクティビティ図で処理の流れを示し、それを利用してシーケンス図を記述する例を示しました。 オブジェクト指向基礎講座は今回でいったん終了し、次は応用編として新たに企画したいと考えています。 オブジェクト指向の考え方や、UMLのダイアグラムがごく自然なもので、そんなに難しいものではないと感じていただければ幸いです。 ご愛読ありがとうございました。 オブジェクト指向の本質を追究すべく1998年に独立後、有限会社オブジェクトデザイン研究所設立、理論と実践を目指し現在に至る。 事業模型倶楽部、日本XPユーザ会、パターン言語のコミュニティなどソフトウェア新技術の学習と普及を行うコミュニティ活動に参画。 著書『まるごと図解 最新オブジェクト指向がわかる』(技術評論社)、『まるごと図解 最新UMLがわかる』(技術評論社)。 『UML Press』(技術評論社)、『ソリューションIT』(リックテレコム)ほかの専門誌に多数執筆。 ホームページ。 [an error occurred while processing this directive] [an error occurred while processing this directive].

次の