統一モデリング言語であるＵＭＬについて
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
クラス図は、ＵＭＬ(統一モデリング言語)における一番基本となる図で、システムを構成するクラスの属性やクラス間を表します。
オブジェクト指向でシステムをとらえると、システム化の対象となるものをオブジェクトとし、それには「データ」と「振る舞い」があると考えます。
たとえば、図書館の書籍というオブジェクトには、著作者や出版社といったデータと、貸出中と返却済と振る舞いがあるとします。書籍は一冊ずつに著作者が存在し出版社が決まっています。
システムとして考えるには、それらの情報を一つずつ個別に管理するのではなく、共通化した方が合理的といえますが、その共通化した情報をクラスとして定義します。
ＵＭＬのクラス図では、「データ」のことを「属性」と呼び、「振る舞い」のことは「操作」と呼んでいます。
ここで、「コンピュータ入門」という書籍があると考えてみた時、この書籍の著作者は「木村太郎」で「Ａ出版」から発行され、現在は貸出中と想定します。また、「プログラミング初級」という書籍があり、こちらは著作者が「田中一郎」で「Ｚ書房」から出版され、さきほど返却されたとしておきます。
これは、書籍というクラスがあり、その実体として「コンピュータ入門」という本が、「貸出」という操作により、図書館の書架から無くなっている状態となり、また、同じように実体としての「プログラミング初級」という本が、「返却」という操作により、図書館の書架に戻り存在している状態を表します。
オブジェクト指向では、クラスから生成される実体のことを「インスタンス」と名付けています。
システム的な考え方をすると、クラスごとに操作を実現させるためのプログラミングを用意しておき、クラスから生成されたインスタンス(オブジェクト)の状態を変化させるには、実現したい操作ごとに用意されたプログラムをインスタンス(オブジェクト)に対して実行する、ということになります。
これを上記の書籍を例に、クラス図で表現すると次のようになります。
クラスは、四角形で表現し、まず「クラス名」を記述します。
その下に横線を引いて「属性」を記述し、また横線を引いてから「操作」を記述します。
クラスのよっては、「属性」が無い場合や「操作」が無い場合がありますが、その時は省略します。
複数のクラスが関連しあってシステムは構成されます。
ここでは、「乗用車」「タクシー」「バス」「トラック」といったクラスで考えてみることとします。
ここに並べたクラスは、車の種類(バリエーション)となっています。「乗用車」「タクシー」「バス」「トラック」をまとめたものとして、「車」というクラスを用意することができそうです。
このように、共通するような性質や規則性を抽出してまとめて一般化(普遍化)することを汎化といいます。そして、汎化により導き出されたクラスのことをスーパークラスとか親クラスなどと呼んでいます。
それに対し、スーパークラスを導き出したクラスの方をサブクラスとか子クラスまたは派生クラスと呼び、汎化に対しては特化といい、このような関係性を汎化特化関係と名付けています。
この「車」というスーパークラスは、「タクシー」とか「トラック」といった具体性のあるものではなく、共通的な概念として作成されたものになるので、抽象クラスともいわれ、クラス図で表現する際にはクラス名を斜文字にすることで区別をしています。
クラス図上での汎化特化関係は、サブクラスからスーパークラスに対し、白抜き三角形の矢印線を引くこととしています。矢印線は、サブクラスからスーパークラスにそれぞれ直接引いても、集約して引いても、どちらでもかまいません。
また、スーパークラスはサブクラスを一般化して作られたクラスとなるので、スーパークラスが持つ「属性」や「操作」はサブクラスにも引き継がれることになります。例えば、エンジンやハンドルにタイヤといった「属性」や、発進するとか停止するといった「操作」が該当します。
このことを「継承」といいます。しかし、乗車人数とか荷台といったサブクラス独自のものは、サブクラスの「属性」として定義します。
クラスとクラスの関係性は、汎化だけではなく、関連や集約など、いくつか存在します。
車は駐車場に置きますが、必ずしも固定の駐車場場所に保管されるわけではありません。
バスやトラックなどの社用車であれば、その会社が所有する何か所かの駐車エリアに、運用の事情に合わせて駐車させています。個人であっても、車通勤の方ですと、自宅の車庫と会社の駐車場の２ヶ所を利用していることもあります。
このような制約や制限の無い関係を、クラス図で表現する時は「関連」として表現します。
「集約」というのは、全体－部分の関係が成り立つ時に用いられます。
「レンタカー会社」で考えると、普通の「乗用車」、荷物用の「トラック」、大人数での移動用としての「バス」などを保有しています。しかし、「トラック」も「バス」もレンタカー会社にしか存在しないというものではなく、「レンタカー会社」も「乗用車」だけも保有していたり、会社設立当初や倒産してしまった時など１台も貸し出すものを所有していないということがあります。
このような全体部分関係をクラス図で表現する場合、「集約」とし、全体を表すクラス側に白抜き菱形を持つ矢印線を引くこととしています。
ところが、全体と部分が依存しあっている関係もあります。
「車」で考えると、「エンジン」「ハンドル」「タイヤ」など、各パーツが集まって全体を構成するような関係で、タイヤが無い車のようなものは、たぶん車とはいわず、別の名前も存在となります。ハンドルも、車の装備として利用価値があるもので、それ以外は部屋の装飾品になるくらいです。
こういった依存関係は「コンポジション」と呼び、全体を表すクラス側に黒塗りつぶし菱形を持つ矢印線を引くこととしています。
クラスを似たような機能でグルーピングすることがありますが、そのグループのことをパッケージと呼んでいます。車を例にすると、乗用と荷物用(トラックなど)、個人ユースと商業ユース(タクシー・バスなど)といった分類の仕方になります。
スーパークラスにするような汎用性のあるクラスを作成するのではなく、類似性のある集合を作成する際に用いられます。
※パッケージに関しては、ＵＭＬにパッケージ図が用意されています。
データを保有するだけでなく、データに対する操作も含めた形で一つにまとめてしまうことを、クラスによる情報のカプセル化といいます。
クラスは、オブジェクトという実体を表すものになるので、属性としていくつかの情報を管理していますし、それらの情報に対する各種操作を問題なく制御するロジック(アルゴリズム)も管理することになります。
書籍で考えると、いくつも存在する本の中から一意に決まるように属性を定義しておくとともに、貸出や返却、また購入や廃棄など、図書館で行なわれる書籍に対する全ての操作が実現できるように過不足なくロジックを組み立てておく必要があります。
クラスにおける属性と操作がもれなくカプセル化できていると、データ構造やアルゴリズムを変更する必要が生じた場合、変更すべき部分はカプセル化されたクラスの内部だけとなり、それ以外を考慮する必要はありません。変更による他への影響を考えなくてもいい、ということはクラスが適切にカプセル化されていることの大きなメリットといえます。
なにか変更の要求が発生してもクラス内部の問題として解決できるということになり、したがってクラス内のロジック(アルゴリズム)を公開する必要がないということになり、アルゴリズムを隠蔽化することができ、外部からロジックを破壊されてしまうことを防止できることとなります。
属性についても、何でも全て公開する必要はなく、外部からのリクエストに応じて公開すべき情報だけを提供するということも考えられ、そこでクラスのカプセル化に伴い、情報隠蔽という形で公開可否を判断することとしています。
クラス図を作成する際は、情報の公開可否を可視性として、次のように４段階のレベルで表わします。先頭の記号は、クラス図で表記する際のシンボルです。
＋ : public : 全て参照可能
－ : private : 自クラスのみ参照可能
＃ : protected : 自クラスと派生クラスで参照可能
～ : package : 同じパッケージ内で参照可能
クラス図の「属性」や「操作」の先頭に記号を付して、参照範囲を指定します。
記事のトップへ戻る
オブジェクト指向でシステムを設計するというのは、システムをオブジェクトの組合せで作り上げていく考え方です。
オブジェクトというのは、システム的な操作や処理の対象となる実体を指します。
抽象的な概念ではなく、具体的な事例で説明をします。
次の３名が、ある会社に勤めているとします。
---
名前：佐藤 一郎
性別：男
誕生日：1980年1月23日
入社日：2002年4月1日
所属：営業部
職制：課長
---
名前：鈴木 令子
性別：女
誕生日：1990年4月5日
入社日：2013年4月1日
所属：開発部
職制：担当
---
名前：高橋 和男
性別：男
誕生日：1990年12月3日
入社日：2013年4月1日
所属：営業部
職制：担当
---
オブジェクト図は、佐藤さん、鈴木さん、高橋さん、それぞれがどんな人物で、現在どのような状態にあるか、を表現するものです。
オブジェクト図として表記すると、次のようになります。
オブジェクトは四角形で表現され、内部を上下に分け、上側には「オブジェクト名」下側には「属性」を記述します。
「オブジェクト名」は下線を引いて記入しますが、次の３種類の書き方があります。
・「オブジェクト名」のみ
・「オブジェクト名」＋「：」＋「クラス名」
・「：」＋「クラス名」
クラス名というのは、オブジェクトを総括的に表すものとして定義されたクラスの名称です。
今回の例では、佐藤さん、鈴木さん、高橋さんをひっくるめて、社員と考えているのですが、その社員という定義がクラスにあたります。
インスタンス名というのは、クラスの実体を指す用語として定義されるインスタンスを示す名称のことです。
社員の一人ひとりの実体として、佐藤さんや鈴木さん、それに高橋さんが存在していて、そのうちの佐藤さんについての情報を表現した図の時、インスタンス名は佐藤さんになります。
「属性」は、「変数名＝値」という形式になります。
そして、佐藤さんのオブジェクト図の属性部分には、佐藤さん固有の情報である性別、誕生日、入社日といった変数名と該当する値が記述されます。
オブジェクトは、相互に関連をもつ存在であり、それが状態として表現されます。
関連は、オブジェクトとオブジェクトを結ぶ線として表されますが、それを「リンク」と呼んでいます。
営業部と開発部を部門というクラスにして、営業部に佐藤さんと高橋さんが所属し、開発部に鈴木さんが所属していることを表現しています。また、部門をまとめるクラスとして会社を想定しています。
これにより、オブジェクト間の関係性を把握することができるようになります。
記事のトップへ戻る
ＵＭＬは、主にオブジェクト指向分析や設計のためのツールといえます。
では、オブジェクト指向とは、どういうものなのでしょう？
オブジェクト指向は、ソフトウェア工学の一つの理論で、ソフトウェア設計とプログラム記述において用いられる考え方です。
それまでのソフトウェアの設計や製作における考え方は、手続き型プログラミングまたは構造化プログラミングとよばれるもので、情報資源(データ)と処理手順(コード/メソッド)は別なものととらえて設計を行なっていました。データはコード/メソッドにより変化していくものと考え、いかにしてメソッドを組み立てるか、という視点でプログラミングが行なわれていました。
あるデータが複数のメソッドからの影響を受ける、という仕組みの場合、そのデータに対する変更が必要となると、いくつものメソッドを改変しなければなりません。その際、改変すべきメソッドが多く存在すると、メソッドの改変でミスやモレが発生してしまう可能性が高くなります。
そこで、データとメソッドを一体化してしまえば、データに変更が必要となった時、そのデータに属しているメソッドだけを改変すればよいということになります。
このような考え方が、オブジェクト指向のベースです。
オブジェクト指向では、システム化したい実体をオブジェクトと呼び、その実体が外部からの指示(メッセージ)により、どのように遷移すべきかを設計し、プログラムとして実装し、その集合体としてシステムが実現すると考えます。そこで、互いに関連するデータの集まりとそのデータ群に対する操作を一つの単位としてまとめたものを、情報のカプセル化と呼びます。カプセル化は、外部に公開された手続き(メソッド)によって、機能(操作結果)を影響する、という考えです。つまり、外部からメッセージを与えると、そのメッセージによりメソッドが動作し、結果を返すという形で、メソッドの内部構造は秘匿(ブラックボックス化)されます。カプセル化されたデータ群は、情報隠蔽された状態となっており、その値を取得するためには「データ参照」というメソッドを要求することで入手する、というスタイルです。
カプセル化により、その内部の仕様(設計)変更が外部に影響を与えないということと、データや実装(設計)内容が秘匿化されることで外部から破壊されることを防ぐことができるということになり、これがオブジェクト指向によるシステム化のメリットといえます。
記事のトップへ戻る
オブジェクト指向にてシステム設計をする時に用いられる記法に、ＵＭＬというものがあります。ＵＭＬというのは、Unified(統一)Modeling Language(モデリング言語)の頭文字です。
オブジェクト指向システム設計というのは、オブジェクトというデータとコードのセットを基本要素としてシステムを設計する考え方です。それまでのシステム設計は、情報と処理手順を別にして考えていましたが、オブジェクト指向ではデータ(情報)とコード(処理手順：メソッド)をひとまとめにして考えます。
オブジェクト指向は、1994年頃にラショナル・ソフトウェアという会社でスタートします。ジェームズ・ランボーがオブジェクトモデル化技法を、グラディ・ブーチがオブジェクト指向設計であるブーチ法を生み出し、二人は共同でその技法を統一することとしますが、そこにオブジェクト指向ソフトウェア工学の開発者であるイヴァー・ヤコブソンが加わることになります。彼ら３人は、スリーアミーゴスと呼ばれます。
当時、数多くのモデリング言語が存在していましたが、オブジェクト技術の普及を促すため、スリーアミーゴスが行なっていた技法統一作業を統一モデリング言語として統合することとなり、これがＵＭＬ誕生の契機となります。1996年にＵＭＬパートナーズという国際コンソーシアムが結成され、統一モデリング言語（ＵＭＬ）の仕様が完成し、ＵＭＬ1.0仕様ドラフト版が提案されます。仕様の策定・改訂は業界団体のＯＭＧ（Object Management Group）が行なうこととなり、1997年に正式版としてＵＭＬ1.1が公開され、2005年には改善版としてＵＭＬ2.0が完成し、モデリング言語として広く採用されるようになります。
ＵＭＬは、システムの構造や仕様を図によって表現することを目的とした表記法で、構造図と振る舞い図の２種類が用意されています。
構造図というのはシステムの構造を示すもので、クラス図・オブジェクト図・コンポーネント図・パッケージ図・配置図・複合構造図があります。
振る舞い図はシステムの動作や変化といった振る舞いを示すもので、アクティビティ図・ユースケース図・ステートマシン図、そして相互作用図がありますが、相互作用図は、シーケンス図・コミュニケーション図・タイミング図・相互作用概要図に分かれます。
・オブジェクト図
実体(オブジェクト)の状態を表現
クラス図の作成や検証に用いられる
・クラス図
クラスの構造を属性や操作とともに表現
クラス間の関連を表し、システム構造を明らかにする
・パッケージ図
クラスなどをグループ化したもの
システムの階層構造を表現
・コンポーネント図
システムの物理的な構成を表現
・配置図
コンポーネントの関係性を表現
システム実行時の構成や配分を可視化
・複合構造図
クラスやコンポーネントの構造を表現
・ユースケース図
システム利用者の要求を表現
システムが実現すべき役割を明らかにする
・アクティビティ図
処理の流れや制御など、実行手順を表現
フローチャートのＵＭＬ版
・ステートマシン図
オブジェクト(クラス)の状態遷移を表現
相互作用図
オブジェクト間のメッセージを表現
次の４図が用意されています
・シーケンス図
メッセージを時系列で表現
時間に沿ったオブジェクト間の関連を表す
・コミュニケーション図
クラスやオブジェクトの関連と応答を表現
（UML1.0の時のコラボレーション図）
・タイミング図
クラスやオブジェクトの状態を時系列で表現
状態遷移のタイミングとメッセージを視覚化
・相互作用概要図
相互作用図の関係性を表現
記事のトップへ戻る