本連載は、未経験の人でもUMLを使いこなせるようになることを最終目標として、UMLについてゼロから解説しています。今回は、架空の宅配便会社「まいにち宅配便」の配達予約システムの開発プロジェクトを題材に、設計モデル(詳細設計のモデル)を作成する手順について解説します。
もし筆者が、初めて使うオブジェクト指向言語で詳細設計をするとしたら、設計モデルを作成する前に、その言語とUMLの対応付けについて考えます。なぜなら、詳細設計の目的の1つである保守性の向上を目指すには、プログラミング言語の特性を最大限に生かした形で詳細設計をしなければいけないからです。
表1にメジャーなオブジェクト指向言語の機能とUMLの要素の対応付けについてまとめました。C++がUMLのインタフェースに対応した機能を提供していないように、すべての言語がすべてのUMLの要素に対応した機能を提供しているわけではありません。よって、言語が提供していない機能に該当するUMLを不用意に使ってしまわないようにするためにも、表1のように言語とUMLの関連性をまとめることは重要です。
表1 主要なオブジェクト指向言語とUMLの対応付け
UML |
Java |
C# |
C++ |
|
---|---|---|---|---|
クラス図 パッケージ図 |
クラス |
クラス(class) |
クラス(class) |
クラス(class) |
抽象クラス |
abstractクラス |
抽象クラス(abstract) |
抽象クラス |
|
インタフェース |
インタフェース(interface) |
インタフェース(interface) |
なし |
|
プロパティ(属性・関連) |
フィールド |
フィールド |
データメンバ |
|
可視性 |
アクセス修飾子 |
アクセス修飾子 |
アクセス指定子 |
|
操作 |
メソッド |
メソッド |
メンバ関数 |
|
静的なプロパティ・操作 |
staticフィールド・メソッド |
静的フィールド・メソッド |
静的データメンバ・メンバ関数 |
|
汎化 |
継承(extends) |
継承(:) |
継承(:) |
|
インタフェース実現 |
実装(implements) |
インタフェース実装(:) |
なし |
|
パッケージ |
パッケージ(package) |
名前空間(namespace) |
名前空間(namespace) |
|
シーケンス図 |
メッセージ |
メソッド起動 |
メソッド呼出し |
メンバ関数呼出し |
生成メッセージ |
コンストラクタ、new |
インスタンス構築子、new |
コンストラクタ、new |
|
ループ複合フラグメント |
for文など |
for文など |
for文など |
オルタナティブ複合フラグメント |
if文など |
if文など |
if文など |
設計のためのパッケージ図
オブジェクト指向言語には、クラスやインタフェースをグループ化するための仕組みとして、パッケージ(Java)やネームスペース(C#やC++)が用意されています。この仕組みの主な用途としては、互いに関連が強いクラスを1つのパッケージにまとめて保守性や再利用性が高いコンポーネントとして扱うこと、パッケージを実装者の実装作業単位にすることが挙げられます。
当然ながら、UMLでもパッケージを記述することができます。パッケージ間の依存関係を設計・表現するための図として、パッケージ図があります。図1は「まいにち宅配便」の「配達予約システム」のパッケージ図です。presentationなどと名前が付けられている長方形を2つ組み合わせた要素が「パッケージ」であり、パッケージ間を結んでいる点線矢印を「依存」と呼びます。
図1では、presentationパッケージがserviceパッケージに依存すると記述されています。実際は、図2のように、presentationパッケージ内のDeliveryScheduleActionクラスがserviceパッケージ内のDeliveryReservationServiceインタフェースに依存していることを、パッケージ図ではクラスを省略して表現しているのです。
なお、パッケージ図では、パッケージのネスト構造を表現することもできます。図3におけるjpパッケージからcoパッケージに伸びている線を「ネスト」と呼びます。
『出典:システム開発ジャーナル Vol.6(2008年9月発刊)』
本稿は原稿執筆時点での内容に基づいているため、現在の状況とは異なる場合があります。ご了承ください。