TOC
単語
| 位置づける | いちづける | 定位于，确定~的地位 | |
| モデリング | modeling | 建模 | |
| 従う | したがう | 根据 | |
| 揃う | そろう | 备齐，合起来，联合起来 | |
| 単に～だけではなく | 不仅仅 | ||
| ～にすぎない | 无非，不过 | ||
| マスターする | 掌握 | ||
| 考え方 | かんがえがた | 思考方法 | |
| （情報の）集まり | 信息的集合体 | ||
| 振舞い | ふるまい | 行为，操作 | |
| 静的 | せいてき | 静态的 | |
| 動的 | どうてき | 动态的 | |
| 継承関係 | けいしょうかんけい | 继承关系 | |
| 集約関係 | しゅうやくかんけい | 组成关系 | |
| 関連関係 | かんれんかんけい | 关联关系 | |
| 特殊性 | とくしゅせい | 特殊性 | |
| 抽出する | ちゅうしゅつする | 抽象出来 | |
| スーパークラス | 父类，超类 | ||
| サブクラス | 子类 | ||
| 用いる | もちいる | 使用，应用 | |
| 組み立てられる | くみたてられる | 被组合而成的 | |
| 日産社製 | にっさんしゃせい | 日产产 | |
| トヨタ社製 | 丰田产 | ||
| なかなか | （口语）非常 | ||
| なんでもかんでも | 无论如何，不管三七二十一 | ||
| 避ける | さける | 避免 | |
| 悩む | なやむ | 烦恼 | |
| 書き切れない | かききれない | 画不下，写不下 | |
| グルーピングする | 分组，编组 | ||
| 品物グループ | 物料组 | ||
| 組織グループ | 人员组 | ||
| ドキュメントグループ | 文档组 |
ポイント
-
国際標準になっているわけですか？ → 已经成为国际标准了对吧。
-
単に設計図を書く記号にすぎないと感じましたけど。 → 感觉不过是编写设计图的符号。
-
なかなかいい例ですね。
-
なんでもかんでも継承関係をつけることはいけませんね。
-
オブジェクト指向技術
-
静的なモデリング
会話
会話の背景
- ここにきて、やっと詳細設計に入る。
- オブジェクト指向技術をベースにした開発する場合は、クラス図は詳細設計のベースとして位置づけられる。クラス図では、モデリング標準の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）に継承関係を持ちます。
- 自動車（Car）が見積もり（Quotation）クラスや注文（Order）クラスとは関連関係を持っています。
- それと、自動車（Car）とタイヤ（Tyre）クラスは関連関係とも言えますが、依存関係がありそうなので、集約関係を持つことも考えられます。
- このような考えはよろしいでしょうか？
-
近藤：
- なかなかいい例ですね。
- 分析の初期には、一つは継承関係の定義を慎重に使ったほうがいいと思います。なんでもかんでも継承関係をつけることはいけませんね。また深い継承関係も避けてください。
- 二つ目は関連関係か集約関係かなどを悩む必要はありません。もしはっきり分からなければ、とりあえず関連関係でもいいですから。属性や操作を定義しながらわかってくると思います。
- 最後に言いたいことは、クラス図を書くときには、システムが大きすぎると一枚の紙で書き切れないこともよくありますから、クラスをグルーピングすることが必要です。
- 我々が今回開発しようとする車両販売管理システムの場合は、今のところのユースケースやコンセプト図を読むと、大体60個以上のクラスがあると思います。そうするとおそらく三つまたは四つぐらいのグループに分割すればいいと思います。
-
鈴木：
- そうですね。確かにグルーピングすることが必要ですね。私のイメージでは、たとえば車両や部品などのクラスは品物グループで、お客さん、メーカー、商社、営業マンなどは組織のグループになると思います。最後は、請求書、納品書、注文書などのクラスはまた一つのドキュメントグループになるかもしれません。
-
田中：
- 分かりました。
-
鈴木：
- それでは、今日のミーティングはここまでです。近藤さん、どうもありがとうございました。
- 皆さん、ありがとうございました。
-
皆：
- どうもありがとうございました。
「真诚赞赏，手留余香」
WZhong
真诚赞赏，手留余香
使用微信扫描二维码完成支付
