日汉专业会话 - 软件工程开发实例

クラス図を書く

会話の背景：
ここにきて、やっと詳細設計に入る。
オブジェクト指向技術をベースにした開発する場合は、クラス図は詳細設計のベースとして位置づけられる。クラス図では、モデリング標準のUMLに従って、クラスおよびそれらの関係を表現し、各クラスの主な属性や操作などを記述する。

登場人物：

近藤　－　システムアーキテクト
鈴木　－　開発チームリーダー
山田、田中　－　開発チームメンバー

会話：

鈴木：こんにちは。
今週から詳細設計に入ります。予定としてはクラス図、シーケンス図、状態図、それとデータベース設計を中心に作業してほしいです。今日は近藤さんにクラス図の作成方法などを説明してもらいます。
それでは、近藤さん、よろしくお願いします。

近藤：承知しました。ここ数年まえから、オブジェクト指向やUMLなどはすでに分析設計の常識になってきました。説明するため、まずUMLについてちょっと触れたいです。UMLとはUnified Modeling Languageの略称で、言い換えると統一モデリング言語です。

山田：そうすると、UMLはすでに国際標準になっているわけですか？

近藤：そう言っても間違えないと思います。20世紀末の90年代にはたくさんのモデリングの提案が出まして、その後Booch、RumbaughとJacobsonの三人が揃って、統合的なUMLを提案した、この提案はOMG（Object Management Group）が1997年に発表しました。
今、UMLは単に設計モデリングだけではなく、プロセスの定義言語、テストのフレームワークなどさまざまな分野へ展開しています。

田中：私もこの前１つのUMLコースを勉強しましたが、UMLとは、単に設計図を書く記号にすぎないと感じましたけど。

近藤：UMLはもちろん設計図を書く記号ですが、しかし設計の意図を正しく、正確に伝えるため、やはりこの記号の後ろにあるオブジェクト指向技術をマスターしなければなりません。

田中：これはクラスやオブジェクトのことを指していますか？

近藤：そうです。
本質的なのはオブジェクト指向の考え方です。オブジェクトというのは、現実的なものをコンピューター世界へ反映させた表現です。たとえば、現実には車両があり、われわれのシステムではCarというオブジェクトで表現します。また、車両販売の現場では見積書があり、システムではそれに対応したQuotationオブジェクトが存在します。

山田：それならば、このQuotationオブジェクトは現場での見積もり情報の集まりでしょうか？
近藤：そうとも言えますが、それは、オブジェクトのある１つの側面です。オブジェクトとはデータを持つだけではなく、振る舞いも持ちます。データと振る舞いを統合することはオブジェクトの特徴ですね。

山田：なるほど。今回のクラス図はデータと振る舞いのどちらを表現するのでしょうか？

近藤:：UMLでモデリングするには大きくわけると２種類のモデリングがあります。すなわち、静的なあるいはStaticなモデリングと動的なあるいはDynamicなモデリングがあります。今日話したいクラス図は静的なモデリングの一種です。
クラス図は主にクラスの名前、属性、および操作を定義し、そのクラス間の関係付けを記述します。

田中：クラスの関係は複雑でしょうか？

近藤：そうでもありません。クラスの関係は大きく分類すると、継承関係、集約関係、それと関連関係という３種類があると思います。
継承関係とは基本的には同じタイプのものに対して、汎化性を抽出し、スーパークラスに定義します。特殊性はサブクラスになり、スーパークラスの持っている属性と操作を継承しながら、特別な属性や操作を記述します。

田中：それで、集約関係と関連関係の区別はなんでしょうか？

近藤：まず、関連関係とは、単にオブジェクトの関係をクラスレベルで表現したものです。たとえば、PersonというクラスとCarというクラスとの間には、「運転する」という関係があります。
集約関係は関連の特殊なものとも言えます。詳しくいうと、部品を表すクラスと、それを用いて組み立てられるクラスとの関係です。集約関係の特徴は、部品側オブジェクトが組立側オブジェクトに依存することです。

鈴木：例をあげると、自動車（Car）というクラスがあって、一般的には自動車ですが、日産社製自動車（NissanCar）とトヨタ社製自動車（ToyotaCar）はそれぞれ自動車に継承関係を持ちます。自動車（Car）が見積（Quotation）クラスや注文（Order）クラスとは関連関係を持っています。それと、自動車（Car）とタイア（Tyre）クラスは関連関係とも言えますが、依存関係がありそうなので、集約関係を持つことも考えられます。
このような考えはよろしいでしょうか？

近藤：なかなかいい例ですね。
分析の初期には、１つは継承関係の定義を慎重に使ったほうがいいと思います。なんでもかんでも継承関係をつけることはいけませんね。また深い継承関係も避けてください。２つ目は関連関係か集約関係かなどを悩む必要はありません。もしはっきりわからなければ、とりあえず関連関係でもいいですから。属性や操作を定義しながらわかってくると思います。
最後に言いたいことは、クラス図を書くときには、システムが大きすぎると1枚の紙で書き切れないこともよくありますから、クラスをグルーピングすることが必要です。
われわれが今回開発しようとする車両販売管理システムの場合は、いまのところのユースケースやコンセプト図を読むと、大体６０個以上のクラスがあると思います。そうするとおそらく3つまたは4つぐらいのグループに分割すればいいと思います。

鈴木：そうですね、確かにグルーピングすることは必要ですね。わたしのイメージでは、たとえば車両や部品などのクラスは品物グループで、お客さん、メーカー、商社、営業マンなどは組織のグループになると思います。最後は、請求書、納品書、注文書などのクラスはまた１つのドキュメントグループになるかもしれません。

田中：わかりました。

鈴木：それでは。今日のミーティングはここまでです。近藤さん、どうもありがとうございました。
皆さん、ありがとうございました。

皆：どうもありがとうございました。

 

文章涉及的単語

 詳細設計(しょうさいせっけい) ：详细设计

クラス図(くらすず)（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，类图表现了类及其相互的关联关系，描述了各个类的主要属性和主要操作。

 

 

出场的人物：

近藤　－　系统构架师
铃木　－　开发团队组长
山田、田中　－　开发团队成员

 

会话：
铃木：大家好。
　　从本周开始我们进入详细设计。按照预计，我们将分别围绕类图、时序图、状态图、以及数据库设计等作为中心来开展工作。今天请近藤把类图的开发给大家讲一下。 下面，请近藤讲解。

 

近藤：好的。 近几年来，面向对象和UML等已经成为分析设计的常识了。为了说明类图，我想先把UML关联的情况简单地带一下。UML是Unified Modelling Language的简称，也就是说统一建模语言。

山田：这么说，UML已经成为一个国际标准了？

 

近藤：我觉得这样说也没有错。在20世纪90年代，当时有很多建模的方案提出来。后来，由Booch、Rumbaugh、和Jacobson三人联合起来，提出了UML的方案。这个方案在1997年被OMG机构采纳后正式发表。 现在，UML已经不单单是设计建模，而且已经向其他领域发展，比如过程定义语言，测试的框架等等。

 

田中：我以前参加过一个UML的课程。给我的感觉是，所谓UML，只不过是编写设计图时候的符号而已。

 

近藤：UML本身当然就是编写设计图的符号了。但是，为了把设计的意图科学地、准确地表达出来，还是需要掌握在这些符号后面的面向对象技术才行。

 

田中：这里指的是类和对象吗？

 

近藤：是的，其本质是面向对象的思考方法。
　所谓对象，只是表现了现实世界的东西在计算机世界里的反映。比如说，现实世界里有汽车，在我们的系统里就有Car这样一个对象。还比如，在汽车销售的现场有问价单这样的对象，在系统里与此对应的就存在Quotation的对象。

 

山田：这样说，这个Quotation的对象就是把问价单的信息集中起来就是了？

 

近藤：这样说也可以。但是这只是对象的一个侧面。对象不仅具有数据，它还具有行为。把数据和行为统一起来就是对象的特点。

 

山田：原来如此。那么现在的类图究竟是要表现对象的数据和行为的哪一个侧面呢？

 

近藤：UML在建模的时候，从大的方面来划分，可以有2种类型的模型，那就是静态的或者说Static的模型和动态的或者说Dynamic的模型。我们现在说的类图是属于静态模型。
类图主要定义类的名称、属性、操作，并且描述各个类之间的相互关系。

 

田中：类的关系很复杂吧？

 

 

近藤：那也不见得。我认为类的关系大致可以分为三类，即：继承关系，关联关系，和组成关系。
　　 所谓继承关系，基本上就是针对同一类型的对象，把一般性提取出来，定义为超级类。把特殊性作为子类。子类一方面继承超级类具有的属性和操作，另一方面又可以描述特殊的属性和行为。

 

田中：那么，关联关系跟组成关系的区别是什么呢？

 

近藤：首先，关联关系就是对象之间的关联在类水平上的表现而已。比如，Person这个类跟Car这个类之间，就有一个“驾驶”的关系。
组成关系可以说是一种特殊的关联关系。详细的说，是一种作为零件的类，以及利用这种零件组装起来的类之间的关系。组成关系的一个特征就是，零件类依赖于组装类。

 

铃木：我来举个例吧。我们有一个汽车的类（Car）。汽车是一个一般的概念，具体来说有日产制造的汽车（NissanCar）和丰田制造的汽车(ToyotaCar)，它们跟汽车（Car）就是继承关系。汽车（Car）与问价单（Quotation）、汽车（Car）与订单（Order）都是一种关联关系。还有，汽车（Car）与轮胎（Tyre）的关系似乎可以说是关联关系，但是它们之间有着依赖关系，所以可以考虑为组成关系。
　这样的想法可以吗？

 

 

近藤：这个例子非常好。
　 在分析的初期，我建议各位，一是谨慎地使用继承关系。不要不管三七二十一都用继承关系，也不要使用太多太深层次的继承关系。二是没有必要为了确定这是关联关系还是组成关系而烦恼。如果不是很清楚，权且当做关联关系就可以了。我估计随着定义其属性和操作，自会慢慢明白的。
最后我想说的是，设计类图的时候，当系统过分大的时候，经常会发生用一张纸画不下全部的类的情况，所以有必要把类图进行分组。
　 就拿这一次要开发的车辆销售管理系统来说，根据目前的使用案例和概念图看来，我估计大概要有60多个类。这样的话，也许要分成3个或4个组比较好。

 

铃木：是的。类图的分组确实是必要的。我考虑的是，比如，车辆、零件等类可以作为物品的分组；客户、制造商、商社、营业员等可以建立一个组织的分组；最后，请求书、订货单等类或许可以再建立一个文档的分组。

 

田中：明白了。

 

铃木：好吧，今天的会议就到此结束。谢谢近藤，谢谢各位。

 

（众）：谢谢。