クラス図を書く
会話の背景:
ここにきて、やっと詳細設計に入る。
オブジェクト指向技術をベースにした開発する場合は、クラス図は詳細設計のベースとして位置づけられる。クラス図では、モデリング標準のUMLに従って、クラスおよびそれらの関係を表現し、各クラスの主な属性や操作などを記述する。
登場人物:
近藤 - システムアーキテクト
鈴木 - 開発チームリーダー
山田、田中 - 開発チームメンバー
会話:
鈴木:こんにちは。
今週から詳細設計に入ります。予定としてはクラス図、シーケンス図、状態図、それとデータベース設計を中心に作業してほしいです。今日は近藤さんにクラス図の作成方法などを説明してもらいます。
それでは、近藤さん、よろしくお願いします。
近藤:承知しました。ここ数年まえから、オブジェクト指向やUMLなどはすでに分析設計の常識になってきました。説明するため、まずUMLについてちょっと触れたいです。UMLとはUnified Modeling Languageの略称で、言い換えると統一モデリング言語です。
山田:そうすると、UMLはすでに国際標準になっているわけですか?
近藤:そう言っても間違えないと思います。20世紀末の90年代にはたくさんのモデリングの提案が出まして、その後Booch、RumbaughとJacobsonの三人が揃って、統合的なUMLを提案した、この提案はOMG(Object Management Group)が1997年に発表しました。
今、UMLは単に設計モデリングだけではなく、プロセスの定義言語、テストのフレームワークなどさまざまな分野へ展開しています。
田中:私もこの前1つのUMLコースを勉強しましたが、UMLとは、単に設計図を書く記号にすぎないと感じましたけど。
近藤:UMLはもちろん設計図を書く記号ですが、しかし設計の意図を正しく、正確に伝えるため、やはりこの記号の後ろにあるオブジェクト指向技術をマスターしなければなりません。
田中:これはクラスやオブジェクトのことを指していますか?
近藤:そうです。
本質的なのはオブジェクト指向の考え方です。オブジェクトというのは、現実的なものをコンピューター世界へ反映させた表現です。たとえば、現実には車両があり、われわれのシステムではCarというオブジェクトで表現します。また、車両販売の現場では見積書があり、システムではそれに対応したQuotationオブジェクトが存在します。
山田:それならば、このQuotationオブジェクトは現場での見積もり情報の集まりでしょうか?
近藤:そうとも言えますが、それは、オブジェクトのある1つの側面です。オブジェクトとはデータを持つだけではなく、振る舞いも持ちます。データと振る舞いを統合することはオブジェクトの特徴ですね。
山田:なるほど。今回のクラス図はデータと振る舞いのどちらを表現するのでしょうか?
近藤::UMLでモデリングするには大きくわけると2種類のモデリングがあります。すなわち、静的なあるいはStaticなモデリングと動的なあるいはDynamicなモデリングがあります。今日話したいクラス図は静的なモデリングの一種です。
クラス図は主にクラスの名前、属性、および操作を定義し、そのクラス間の関係付けを記述します。
田中:クラスの関係は複雑でしょうか?
近藤:そうでもありません。クラスの関係は大きく分類すると、継承関係、集約関係、それと関連関係という3種類があると思います。
継承関係とは基本的には同じタイプのものに対して、汎化性を抽出し、スーパークラスに定義します。特殊性はサブクラスになり、スーパークラスの持っている属性と操作を継承しながら、特別な属性や操作を記述します。
田中:それで、集約関係と関連関係の区別はなんでしょうか?
近藤:まず、関連関係とは、単にオブジェクトの関係をクラスレベルで表現したものです。たとえば、PersonというクラスとCarというクラスとの間には、「運転する」という関係があります。
集約関係は関連の特殊なものとも言えます。詳しくいうと、部品を表すクラスと、それを用いて組み立てられるクラスとの関係です。集約関係の特徴は、部品側オブジェクトが組立側オブジェクトに依存することです。
鈴木:例をあげると、自動車(Car)というクラスがあって、一般的には自動車ですが、日産社製自動車(NissanCar)とトヨタ社製自動車(ToyotaCar)はそれぞれ自動車に継承関係を持ちます。自動車(Car)が見積(Quotation)クラスや注文(Order)クラスとは関連関係を持っています。それと、自動車(Car)とタイア(Tyre)クラスは関連関係とも言えますが、依存関係がありそうなので、集約関係を持つことも考えられます。
このような考えはよろしいでしょうか?
近藤:なかなかいい例ですね。
分析の初期には、1つは継承関係の定義を慎重に使ったほうがいいと思います。なんでもかんでも継承関係をつけることはいけませんね。また深い継承関係も避けてください。2つ目は関連関係か集約関係かなどを悩む必要はありません。もしはっきりわからなければ、とりあえず関連関係でもいいですから。属性や操作を定義しながらわかってくると思います。
最後に言いたいことは、クラス図を書くときには、システムが大きすぎると1枚の紙で書き切れないこともよくありますから、クラスをグルーピングすることが必要です。
われわれが今回開発しようとする車両販売管理システムの場合は、いまのところのユースケースやコンセプト図を読むと、大体60個以上のクラスがあると思います。そうするとおそらく3つまたは4つぐらいのグループに分割すればいいと思います。
鈴木:そうですね、確かにグルーピングすることは必要ですね。わたしのイメージでは、たとえば車両や部品などのクラスは品物グループで、お客さん、メーカー、商社、営業マンなどは組織のグループになると思います。最後は、請求書、納品書、注文書などのクラスはまた1つのドキュメントグループになるかもしれません。
田中:わかりました。
鈴木:それでは。今日のミーティングはここまでです。近藤さん、どうもありがとうございました。
皆さん、ありがとうございました。
皆:どうもありがとうございました。
文章涉及的単語
詳細設計(しょうさいせっけい) :详细设计
クラス図(くらすず)(class diagram): 类图
位置づける(いちづける) :定位(于)
モデリング(modeling) :建模
従う(したがう) :根据
主な(おもな) :主要的
提案する(ていあんする) :提出方案
揃う(そろう) :合起来,联合起来
発表する(はっぴょうする) :公布,发布
単に。。。だけではなく(たんに。。。だけではなく) :不仅仅。。。
プロセス(process) :过程
フレームワーク(framework) :框架
さまざま :各种各样
分野(ぶんや) :领域
(。。。に)すぎない :仅仅。。。而已
マスター(master)する :掌握
クラス(class) :类
オブジェクト(object) :对象
考え方(かんがえがた) :思考方法
コンピューター(computer) :计算机
システム(system) :系统
(情報の)集まり (じょうほうのあつまり) :(信息的)集合体
データ(data) :数据
振る舞い (ふるまい) :行为,行动,操作
静的 (せいてき) :静态的
動的 (どうてき) :动态的
継承関係 (けいしょうかんけい) :继承关系
集約関係 (しゅうやくかんけい) :合成关系
関連関係 (かんれんかんけい) :关联关系
タイプ(type) :类型
汎化性 (はんかせい) :一般性
特殊性 (とくしゅせい) :特殊性
抽出する (ちゅうしゅつする) :抽象出来
スーパークラス(super-class) :超级类,父类
サブクラス(sub-class) :子类
クラスレベル(class level) :类的水平上
運転する (うんてんする) :驾驶
部品 (ぶひん) :零件,部件
表す (あらわす) :表示,表达
用いる (もちいる) :使用,应用
組み立てられる (くみたてられる) :被组合而成的
見積 (みつもり) :问价,报价
注文 (ちゅうもん) :订货
タイア(tyre) :轮胎
なかなか :(口语)非常
なんでもかんでも :不管三七二十一
避ける (さける) :避免
悩む (なやむ) :恼火,烦恼
書き切れない (かききれない) :画不下,写不下
グルーピングする(grouping) :分组,编组
イメージ(image) :印象,认为
品物グループ (しなものぐるーぷ)(material group) :材料的组
組織グループ (そしきぐるーぷ)(organization group) :人员组织的组
ドキュメントグループ(document group) :文档的组
中文翻译
类图设计
会话的背景:
到这个时候,总算进入了详细设计的阶段。 基于面向对象技术开发的情况下,类图的地位就是详细设计的基础。根据建模的标准UML,类图表现了类及其相互的关联关系,描述了各个类的主要属性和主要操作。