小春网

 找回密码
 注册账号
查看: 7621|回复: 41
收起左侧

[经验分享] 日汉专业会话 - 软件工程开发实例

[复制链接]
发表于 2006-4-7 13:26:00 | 显示全部楼层 |阅读模式

马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。

您需要 登录 才可以下载或查看,没有账号?注册账号

x
不知道能不能对做软件工作的朋友们有点用处,下面奉上中文翻译。

クラス図を書く 会話の背景: ここにきて、やっと詳細設計に入る。 オブジェクト指向技術をベースにした開発する場合は、クラス図は詳細設計のベースとして位置づけられる。クラス図では、モデリング標準の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つのドキュメントグループになるかもしれません。 田中:わかりました。 鈴木:それでは。今日のミーティングはここまでです。近藤さん、どうもありがとうございました。        皆さん、ありがとうございました。 皆:どうもありがとうございました。

[此贴子已经被作者于2006-4-7 12:45:45编辑过]

 楼主| 发表于 2006-4-7 13:41:00 | 显示全部楼层

文章涉及的単語

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

クラス図(くらすず)(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) :文档的组
回复

使用道具 举报

 楼主| 发表于 2006-4-7 13:45:00 | 显示全部楼层

中文翻译

类图设计

会话的背景:

到这个时候,总算进入了详细设计的阶段。 基于面向对象技术开发的情况下,类图的地位就是详细设计的基础。根据建模的标准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个组比较好。


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

田中:明白了。

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

(众):谢谢。
回复

使用道具 举报

yamada 该用户已被删除
发表于 2006-4-7 14:10:00 | 显示全部楼层
提示: 作者被禁止或删除 内容自动屏蔽
回复

使用道具 举报

发表于 2006-4-7 21:26:00 | 显示全部楼层
piglittleさんに小春幣1円を贈呈します。
回复

使用道具 举报

发表于 2006-4-13 09:00:00 | 显示全部楼层
说实话这个好啊!多发多发!!!
回复

使用道具 举报

发表于 2006-4-13 10:29:00 | 显示全部楼层
好久没加过精华了阿  
回复

使用道具 举报

发表于 2006-4-13 15:20:00 | 显示全部楼层
我金钱不够哦,看不了,看来以后不能再潜水啦[em04][em04]
回复

使用道具 举报

 楼主| 发表于 2006-4-14 16:31:00 | 显示全部楼层
我自己来顶顶,不要沉了,有这样一本书的,上海译文出版社出版的,不过没有电子版
[em06][em06][em06]
回复

使用道具 举报

发表于 2006-4-16 17:21:00 | 显示全部楼层
好多专有名词我都经常用的,赫赫,不错!
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 注册账号

本版积分规则

小春网
常务客服微信
微信订阅号
手机客户端
扫一扫,查看更方便! 快速回复 返回顶部 返回列表