hi Zeng Yu, 愈大的團隊需要愈強的管理能力；不過在大團隊裡，這常是Project Manager的職責，不是oo設計師的主要工作。如果是一個小團隊合作開發小軟體，只需要簡單的管理能力就行了，首先分為OOAD與Coding兩組人員，然後oo設計師先分析出the most essential use case，接著分析出此use case的normal course，交由coding人員去implement，這是一個iteration。然後第2 iteration裡oo設計師分析此use case的其它courses，繼續implement。第3 iteration裡分析別的use case並implement，持續循環下去。我想，您可先練習這的最基礎的管理功夫，會逐漸成長的。 By Tom
Tom Kao
NN - Sunday, November 10, 2002 at 01:18:14 (CST) From 211.22.33.139我现在在做一个小软件，但感觉自己一个人开发速度太慢，所以想组成一个开发团队，但又怕自己管理能力不够。请问做oo设计师是不是要有很强的管理能力？
ZengYu <sarsor@sohu.com>
NN - Monday, November 04, 2002 at 22:43:17 (CST) From 61.151.230.115Hi ajian, 古典的需求分析才是從DFD和ER圖開始，oo分析應該從use case分析和domain分析開始，然後導出ER圖。雖然一些小系統常可由ER圖導出基礎的Class圖，但DFD已經不是UML的diagram了。 By Tom
Tom Kao
NN - Sunday, November 10, 2002 at 01:16:36 (CST) From 211.22.33.139高先生，我现在在做一个关于远程教育的的需求分析，请问能发给我一个完整的数据流图和ER图吗？非常感谢！！
ajian <yjj-wvf@163.net>
hangzhou, NN - Sunday, November 03, 2002 at 19:23:06 (CST) From 61.174.137.206hi openeyes, 您所說的「業務主角」是指業務流程(business process)的actors嗎？還是業務流程幕後的workers呢？如果指workers那是依據domain knowledge裡的concepts而分，依此原則，就自然能得到恰恰好的粒度。 By Tom
Tom Kao
NN - Sunday, November 10, 2002 at 01:15:45 (CST) From 211.22.33.139请问高先生： 在做业务建模时，划分业务主角的标准是什么？目的是什么？粒度又怎么定呢？ best regards
openeyes <zhongfei@163.net>
NN - Friday, November 01, 2002 at 16:54:44 (CST) From 218.72.19.34Hi王森, 10月21日聊天室裏，我猜您希望能深入理解軟體設計之哲理和技術，才會提到CRC和object thinking。我覺得大陸的軟體朋友們常從工程與應用的觀點去看軟體設計，例如umlchina.com網頁上有個標題強調「軟件以用為本」，所以偏向探討如何發覺UML之用途，於是常從UML的use case學起，希望軟體滿足現實流程之需求。但是老子說過：「大家皆知有用之用；卻莫知無用之用，為用大矣。」這就偏向架構美學的觀點，於是常從OO thinking學起，希望軟體滿足未來流程變化之需求。請問您較喜歡哪一個途徑呢？您贊成umlchina.com網頁上的標題改為「軟件以無用為本」嗎？ 無用的軟體才能有大用，是嗎？ By Tom
Tom Kao
NN - Sunday, November 10, 2002 at 01:14:49 (CST) From 211.22.33.139"我刚开始学习UML，同时从事系统分析工作，虽然买了不少UML方面书可应用起来还是不知道从哪下手，请问我该如何去做？" 这是我在10月21日的聊天室里提出的问题，您说“从CRC的技巧开始，然後才使用 UML 表达出来，先强化 object-thinking”，可我仍然不知该如何去做，您能具体的说一下吗，我只有中专文化，这些年从事软件开发工作完是自学的，我学习的时候往往是用到哪学到哪，您说我还应看些什么书，补充哪方面的知识？您认为更好的学习方法是什么？谢谢！！！！
王森 <xiangtu@163.net>
沈阳, 辽宁省 CHINA - Sunday, October 27, 2002 at 18:43:56 (CST) From 218.24.75.75Hi openeyes, 在分析時，如果您是business為blackbox的話，採購流程就是一個biz use case。此時，真正的actor可能是採購manager，也可能是IS( information system)等，不管是誰，他們都是在business 黑箱之內，都歸為business 本身。在UML表現上，就可表現如：「出貨biz use case > 採購biz use case」。這意味著，business 執行出貨uc時，某event觸發採購uc。 當您打開business為whitebox的話，而且由IS執行採購流程，就表示e化此流程了，它就成為system uc了。 By Tom
Tom Kao
NN - Sunday, November 10, 2002 at 01:12:26 (CST) From 211.22.33.139高教授： 请教你一个有关use case的问题： 对于一个零售店，要求在店中某种商品库存量下降到一定值时，触发采购流程。 那么： 1。对该零售店做业务分析建模时，采购流程能不能表现为一个biz use case? 如果能，primary actor是什么呢？如果不能，那么为了业务分析的完备，这个流程需要怎样来描述？ 2。假设要对该零售店做一个包含库存控制、商品采购的信息系统，采购流程能不能表现为一个system use case吗? 如果能，primary actor是什么呢？如果不能，那么为了业务分析的完备，这个流程需要怎样来描述？ 敬盼答复！ 谢谢！
openeyes <zhongfei@163.net>
NN - Monday, October 21, 2002 at 21:36:39 (CST) From 218.108.118.8Hi Designer, 在系統分析時需要釐清一個系統裡的components與另一系統裡components之間的相依性(dependency)，仔細思考並進可能將相依性高的components聚集在同一個系統內，然後在系統設計時，使用Façade pattern，將各系統封包(encapsulate)起來。 By Tom
Tom Kao
中国 - Sunday, November 10, 2002 at 01:11:00 (CST) From 211.22.33.139高先生您好：我在做系統開發時遇到如下的困難：1. 不同系統之間的接口問題，目前我們系統之間的耦合度比較高，請問有沒有可以降低這種耦合度的方法呢？2. 就系統之間或子系統之間的Interface有沒有很好的Design pattern可以借鑑呢？謝謝！！
Designer_761110 <javastudy@163.com>
NN - Monday, October 14, 2002 at 17:08:57 (CST) From 202.96.229.4hi wmz, Browser 是tier #1； Web service是tier #2； bpo是façade其封裝bo 形成tier #3； Bdso是façade其封裝data source形成tier #4。 By Tom
Tom Kao
NN - Sunday, November 10, 2002 at 01:09:21 (CST) From 211.22.33.139对不起高先生，在前一个问题中，您回答我说“構成一個4-tier架構”，我没能明白您的意思，哪4个tier？烦劳请您再指点一下，谢谢！
wmz
mainland - Monday, October 14, 2002 at 15:41:44 (CST) From 218.24.33.51高先生： sorry!刚才email输入错误！改为shangwl@sia.ac.cn
swl <shangwl@sia.ac.cn>
NN - Monday, October 14, 2002 at 10:12:11 (CST) From 210.72.132.12hi swl,1.roughInterface類是對的，能落實為web service支持asp的web form。 2.roughMgr類應該只負責協調各類，是business process object的角色。 3.可以新增roughBo類，完成複雜演算法，是business object的角色。將BPO與BO分開能大幅提升系統的彈性。 4.roughCollection類可以是roughMgr類的inner類。 5.rough類可改為roughDs類，是DB裡data record的Wrapper。 By Tom
Tom Kao
NN - Sunday, November 10, 2002 at 01:08:15 (CST) From 211.22.33.139高先生： 你好！向你请教一个问题。我在设计一个mis系统。我这样设计不知是否正确？以工厂领料单维护为例。我设计了四个类，roughInterface类，roughMgr类，roughCollection类，rough类。roughInterface类负责接收系统界面传来的信息；roughMgr类负责协调各类，同时完成复杂算法；roughCollection类可以进行集合的各种操作（交、并、差等），这样可以方便地进行选取、合并及排除等各项操作；rough类包含领料单据的信息，属性与数据库的表一一对应，同时操作中有领料单据的信息的保存、删除、修改、查询等操作。 我把这四个类包装为一个组件，接口包括信息的保存、删除、修改、查询及特殊算法等操作，供系统界面调用。系统界面用asp开发。 请问我这样设计合理吗？谢谢！
swl <shangwl2002@sia.ac.cn>
沈阳, NN - Monday, October 14, 2002 at 09:31:05 (CST) From 210.72.132.12hi wmz, 廣義的business objects包括: 1) business process objects,2) business entity object又稱為business conceptual objects,3) business data-source objects. 在您所提的case中, 可設計一個bpo類----Class EmployeeQuery, 一個bo類---- Class Employee, 一個bdso類---- Class Employee_db, 構成一個4-tier架構. SQL Select statement 應該放在Empolyee_db類裡面。By Tom
Tom Kao
NN - Sunday, October 13, 2002 at 10:32:32 (CST) From 211.22.33.10请教高先生：一个数据库应用程序，功能是根据用户输入的条件，查询公司的人事信息。界面由两个dialog配合工作，一个用于接收用户的查询条件，另一个用于显示查询得到的记录。我想问的是在此应用中,哪些处理应纳入到“business object”中？或者说“business object”中到底包括哪些动作？SQL SELECT字符串的生成处理应放在哪里？我对于类似的数据库应用程序的架构的划分总是一头雾水，请高先生指点一下，谢谢！
wmz
mainland - Saturday, October 12, 2002 at 10:22:22 (CST) From 61.161.189.72To wonzoon, 可參考: 1.Component-Based Software Engineering, ISBN: 0-201-70485-4. 2. Developing Enterprise Java Applications with J2EE and UML. ISBN: 0-201-73829-5. 3. UML components. ISBN: 0-201-70851-5. 4. Realizing e-Business with Components. ISBN: 0-201-67520-X.5. Software Reuse. ISBN: 0-201-92476-5. By Tom
Tom Kao
NN - Sunday, October 13, 2002 at 10:30:59 (CST) From 211.22.33.10高先生，请介绍一些讨论N-tier结构和layering观念的网路资源和书籍，谢谢！
wonzoon <wonzoon@sohu.com>
mainland - Friday, October 11, 2002 at 09:57:41 (CST) From 61.161.188.110hi laihaibao, 在您的struct内增加一个member： pointer_to_next，然后在您的List.AddItem(T) 内写码，将新增的struct item的reference值填入Pointer_to_next内即行了。By Tom。
Tom Kao
taipei, NN - Wednesday, October 09, 2002 at 15:56:36 (CST) From 211.22.33.10高老师： 我是一个c++初学者，想得到一个完美的c++的链表模板类，能支持结构的，比如struct student{ int num; char name[20];};struct Account{ char cardnum[20]; char name[20]; char password[20]; float money;};List stulist;List Acclist;能否给予指导，谢谢了！
赖赖 <laihaibao@163.com>
西安, china - Sunday, October 06, 2002 at 10:39:06 (CST) From 61.185.209.46hi lanisa, 您的意思是：asp或javascript calls remote components呢? 这答案是yes.还是remote application calls asp 或javascript service呢? 这答案是：新版都有提供web service了。不知以上是否猜对您的意思？By Tom。
Tom Kao
taipei, NN - Wednesday, October 09, 2002 at 15:56:36 (CST) From 211.22.33.10高先生：您好，请问用asp或javascript能实现程序的远程调用吗？
lanisa <lanisa@21cn.com>
wuhan, hubei cn - Friday, October 04, 2002 at 17:51:27 (CST) From 202.114.194.130hi wildmum, 我想您的情况已经接近于OLAP或Data Warehouse的使用了, 您需要增加一个新的Month表, 套用Data Warehouse的terms, 可说您有两个fact tables ----调动表和离职表, 各link 到三个dimemsion tables ---- Month, Employee, Department。以上看法您认为如何呢？。By Tom。
Tom Kao
taipei, NN - Wednesday, October 09, 2002 at 15:56:36 (CST) From 211.22.33.10我现在想根据人员信息库，比如有工号，姓名，部门，同时还有调动表：调动时间，工号，前部门，后部门，离职表：工号，部门，时间。根据上面的想动态获得某月的人员情况，如在职人员情况，离职人员情况，请问有没有一个合理的主表设计，可以很简单的获得动态的人事信息，我根据上面的表设计后处理起来很困难。 现在这个问题在实际中经常碰到。比如想统计以前某月公司的人员情况。查询某人在某月在公司的情况请问有没有一个很好的数据表设计方案呢 。这个问题我想 了很久了，就是没有一个想出很理想的方法。
wildmum <wildmum@etang.com>
NN - Thursday, September 26, 2002 at 08:39:25 (CST) From 61.145.235.9hi Zheng, 关于设计思维, 我目前的焦点是Architectural Style, 包括结构美学, 老子的虚实相依, 孙子的应行于无穷, 吴清源的整体、和谐、创新, 印度的空无哲学等等。大部分都跟Software Architecture(如Framework设计等)有关。建议的网站是www.wwisa.org。 软件工程包括有两项：结构设计和施工控管。像CMMI比较偏向施工控管, 降低成本。设计思维追求美感、创新应变和多样化。By Tom。
Tom Kao
taipei, NN - Wednesday, October 09, 2002 at 15:56:36 (CST) From 211.22.33.10高先生，您好。 注意到您说过"我主要是研究設計思維"，这也是我想深入提高的，想请您推荐几个与此相关网络资源，谢谢。
Zheng.w <bluegump_wz@yahoo.com.cn>
mainland, ln NN - Friday, September 13, 2002 at 17:01:34 (CST) From 61.243.183.103hi XGE, 您所提到：”有相同操作”。 但是use case的分合依据通常不是”操作的相不相同”，而是依据”goal的相同”来判断的，如果goal相同则应该合，否则就应该各自叙述了。记得, goal是从user’s view而得的, 操作是由developer’s view才看得到的。By Tom。
Tom Kao
taipei, NN - Wednesday, October 09, 2002 at 15:56:36 (CST) From 211.22.33.10老师您好：我现在做一个比较大的项目设计，用UML建模，用ROSE做为工具,请问我是不是要对每个有相同操作而不同内容的user case画一个Sequence图。例如系统里有订单管理、合同管理，这两个模块都有增、删、改功能，是不是相应的都要画Sequence图。
XGE <ODBCXU>
NN - Monday, August 19, 2002 at 09:14:02 (CST) From 210.51.240.137hi xzhqzz, asynchronous的沟通，只能依赖message queue system的反向notify而得知消息的接收, 或是server 透过其它管道如mail回传。当两个use cases的执行无法synchronous时，jms或MQ或MSMQ是必要的。By Tom。
Tom Kao
taipei, NN - Wednesday, October 09, 2002 at 15:56:36 (CST) From 211.22.33.10请问sun 的jms您用过吗？如何保证消息的可靠传输？什么时候需要用到jms？还有IBM的MQ什么时候应该使用？
xzhqzz <xiezh@cqmc.com>
NN - Wednesday, August 14, 2002 at 18:37:34 (CST) From 211.139.46.202hi bobby, Step1. Server组件提供webservice给UI使用. Step2. 分析出Server side的Business Components, 落实于Server的container里, 例如成为EJB的session beans. 这些buisiness compoments 是复用的目标. Step3. 建构DB的façade components去encapsulate DB, 例如落实为EJB的entity beans. 我想这是基本结构, 还要加上您的domain特色与设计技巧. By Tom。
Tom Kao
taipei, NN - Wednesday, October 09, 2002 at 15:56:36 (CST) From 211.22.33.10请问高老师,我现在写一个程序,想实现这样的目标,1.程序本身能非常容易的实现拆卸,组装和UI的改变.2.在本工程实现的组件很非常容易的被以后的工程复用.3.如何处理好UI和其功能的关系,采用什么结构比较好?请问如何设计能实现以上目标?非常感谢!注:本程序没有采用WIN32的标准UI.
bobby <good.girl@371.net>
NN - Saturday, August 10, 2002 at 06:43:53 (CST) From 63.173.11.194hi shenzhen, 如果您的RDB有个Tuser table，那就在AddUser()里发出SQL statement给RDBMS就行了，如果您的RDB经Normalization时将Tuser table分解为数个小tables，则AddUser()就必须逐一update这些tables了。我不知您的RDBMS厂牌及DB schema 所以无法提供代码。By Tom。
Tom Kao
taipei, NN - Wednesday, October 09, 2002 at 15:56:36 (CST) From 211.22.33.10高先生，您好！我有个关于OO对象如何存储于关系数据库的问题向请教您。假设我现在有个用户类TUser，属性是Name,Age,方法是AddUser()它的一个对象叫User,现在系统操作员想增加一个用户，他在窗体上输入User的相关信息，然后点击“确定”按钮。就这样一个过程，怎样报用户信息保存到关系数据库上，最好能给出相应的代码。多谢！
Wallace <wushenjian@hotmail.com>
shenzhen, Guangdong PRC - Thursday, August 08, 2002 at 15:12:11 (CST) From 61.144.40.93hi zjuxxl, 我想这是很好的研究方向，不过我这方面并无许多心得，无法给您意见。By Tom。
Tom Kao
taipei, NN - Wednesday, October 09, 2002 at 15:56:36 (CST) From 211.22.33.10高先生，你好！我选择了“基于UML自动测试系统建模方法的研究"作为博士课题，最初想法是通过对自动测试系统的共性与特征分析，提出一个通用的、可复用的对象框架，使用扩展的UML对框架进行描述，并提出一种形式语言来描述扩展的UM，最后基于该形式化语义研制CASE，随着课题的深入，感觉题目太大，希望高先生提一些宝贵意见。
zjuxxl <zjuxxl@sohu.com>
Hangzhou, China - Wednesday, August 07, 2002 at 11:43:51 (CST) From 61.175.193.50hi macro_fu, 您可能需要另外两个类：”购买”类和”购买细项”类。 客户类与购买类之间是association，购买类与细项类之间是aggregation，细项类与商品类之间是association。By Tom。
Tom Kao
taipei, NN - Wednesday, October 09, 2002 at 15:56:36 (CST) From 211.22.33.10现在我要对客户买东西建模，客户类和商品接口的关系是聚合、依赖还是关联？谢谢！
我什么都不知道 <macro_fu@msn.com>
NN - Tuesday, July 30, 2002 at 11:58:38 (CST) From 61.144.209.60hi Jethro, 我不清楚您的意思。因为UML model是RUP proscess的产物(artifact). By Tom。
Tom Kao
taipei, NN - Wednesday, October 09, 2002 at 15:56:36 (CST) From 211.22.33.10从哪儿能够找到一个符合rup的比较完善且复杂的UML模型
Jethro <gjethro@sohu.com>
NN - Thursday, July 25, 2002 at 17:48:15 (CST) From 61.144.188.158hi wenm, it’s sure. 尤其VB.net已经能充分表达UML的所有concepts了，您可从VB.net的class, interface等所学到的concepts迅速理解UML notation的涵义，是很有帮助的。By Tom
Tom Kao
taipei, NN - Wednesday, October 09, 2002 at 15:56:36 (CST) From 211.22.33.10我只会VB，能学UML吗？
唐文明 <wenm_tang@21cn.com>
NN - Saturday, July 13, 2002 at 21:54:35 (CST) From 61.186.83.104To张人清： 以我们的一些经验而言, 这似乎没有高招, 凡是高手写的code, 逆向生成都很困难。 By Tom
Tom Kao
NN - Wednesday, July 10, 2002 at 09:35:47 (CST) From 211.22.33.10我在使用Rational rose 2000 中，想根据现存的代码逆向生成软件模型，但很难受的是该功能的头文件搜索功能好像很差，当然，由于我们系统较大，头文件目录很多，嵌套层次较深。请问有无高招?先谢了！噢，我使用的是C++标准。
张人清 <zhangrenqing@huawei.com.cn>
NN - Tuesday, July 09, 2002 at 22:31:14 (CST) From 61.141.99.208To曲江： UML的建模工具有很多种, 各有特色, 例如 Rose最为流行, Together J提供完整的Patterns及多花样的逆向生成功能, Visio较便宜 ….. 我想没有好坏, 只是适合不适合, 或习惯的问题而已。 By Tom
Tom Kao
NN - Wednesday, July 10, 2002 at 09:37:08 (CST) From 211.22.33.10请问：UMl的建模工具，有多少种，分别是什么呢？它们之间的差别在于什么呢？哪一种建模工具更好一些呢？谢谢！！
曲江 <yanjs502@163.com>
xi'an, shannxi China - Tuesday, July 09, 2002 at 10:36:21 (CST) From 61.185.221.76To Albert： 在分布式系统里，subsystem之间的接口是Architect所考虑的重点通常在正式系统分析之前的Architectural Prototyping时就已经分析并测试了, 这个 very front-end的分析就是通称的Architectural Analysis。因为分布式的Web Service 系统整合愈来愈热门, 所以Architecture-centric策略愈重要, Architectural Analysis也愈是大型系统建构的基础。 By Tom
Tom Kao
NN - Wednesday, July 10, 2002 at 09:37:53 (CST) From 211.22.33.10你好。 请问在做面向对象分析设计的阶段，要不要考虑通讯（比如socket）和控制（多进程、线程），还是在构造的时候再考虑？举个简单的例子就是，开发一个分布式的系统，所以对象可能分布在不同机器，它们之间的消息只能通过socket通讯实现，但要不要在设计阶段就考虑呢？
Albert <song_gc@163.com>
NN - Thursday, July 04, 2002 at 18:06:18 (CST) From 61.171.20.137To sword_hero： 因工期紧，所以User和Boss愿意接受”quick & dirty”的code,是全世界都头痛的问题, 对于讲究结构美感的工程师而言, 是一件难受的事。随着系统愈来愈大愈复杂, 也愈分散, boss 和user愈来愈重视企业流程(business process)的整合串接。如果您能将Prototyping的目的转向优先展示”系统整合设计”, 然后才是测试”细节设计”, 通常您的Boss会欢迎。因此, 您应该坚持您的理想, 但必须改进Prototyping的焦点就行了。 By Tom
Tom Kao
NN - Wednesday, July 10, 2002 at 09:38:50 (CST) From 211.22.33.10老师，您好： 想问您一个问题，我在概要设计是这样做的，概据需求分析先想到一个框架，其中某些问题就直接想出来就行了，对于某些问题的细节我就通过编程来试试看实现，先编个大致的框架，在编程中我就可以大致的知道很多需要注意的地方以及如何分配功能，但由于工期比较紧，往往在我编程中想概要设计应该如何设计的阶段boss就要来催了，如果我说概要设计还没好，他就会说，我都看你在编程了，怎么回事？那我只有把编的代码略加修改就投入使用了，而概要设计书一般写的比较晚，我这样做行不行？有什么后果，请您指点一二，谢谢
sword_hero <sword_hero@21cn.com>
hz, zj cn - Sunday, June 30, 2002 at 10:28:36 (CST) From 61.174.156.2To kenzomancn：RequisitePro与microsoft sourcesafe系统与系统的直接连结, 我们并没有这方面的经验, 但是我们把RequisitePro用在前段的需求分析，而microsoft sourcesafe用在后段的开发管理, 之间的trace是人为的, 似乎有些落伍了。 By Tom
Tom Kao
NN - Wednesday, July 10, 2002 at 09:39:26 (CST) From 211.22.33.10RequisitePro如何与microsoft sourcesafe集成?
kenzomancn
NN - Thursday, June 13, 2002 at 17:08:12 (CST) From 218.104.34.139To maji：CRC是个好东西，让我们学习安排角色(role), 及各角色之间的合作，这是oo软件设计的基础思维(thinking)。过去软件设计者都是安排计算机担任所有工作(job)，其心中的焦点是”安排计算机依序工作”，好象安排一位演员依序演出水浒传，心中只关注演员。CRC让您忘记计算机(演员)，而专心写水浒传，于是您关心的是宋江、武松等角色了。这有待您的领悟了。Ocl约束表达式是针对一个集合，设定集合内的元素的property或behavior。例如, 一个”学校”class内有许多”学生”objects, 您能写OCL约束表达式限制只有”好”学生才能参加童子军等。至于Tool请您参考我回答曲江的问题。By Tom
Tom Kao
NN - Wednesday, July 10, 2002 at 09:40:07 (CST) From 211.22.33.10您好！我正在学习《uml用户指南》，有几个问题搞不懂想请你指教。 1。crc卡是何东西 2。ocl书写约束表达式是什么 3。在书中多次提到了uml的工具。请问这有哪些工具。 谢谢！
maji <majiji@online.sh.cn>
NN - Wednesday, June 12, 2002 at 14:58:59 (CST) From 61.171.80.228To aloely：通常设计到Class Diagram就行了。框架代码生成大多依据Class Diagram的静态关系而产生的, 因为框架代码几乎都是静态结构，您必须自行添加动态的部分。先画例图及类图, 再生成框架代码然后以这些代码作参考编程序。 By Tom
Tom Kao
NN - Wednesday, July 10, 2002 at 09:40:47 (CST) From 211.22.33.10请问，如何使用rational rose 实现最后的代码转换？是不是一定要分析到组件图?还有，rose中框架代码生成是如何实现的呢？我现在只会用rose画一些用例图这样的东西是不是先生成框架代码然后我们可以以这些代码作参考编程序？
aloely <aloely@sina.com>
NN - Tuesday, June 04, 2002 at 16:55:30 (CST) From 202.119.192.227To freeyourmind：依据我的理解, Subform是指GUI上的Form及Subform而已，也许直称为”子画面”就行了。 By Tom
Tom Kao
NN - Wednesday, July 10, 2002 at 09:41:30 (CST) From 211.22.33.10老师你好：我现在正在看user interface patterns这本书，里面有个术语，比如；We incorportated these decisions into patterns event Handler,Complete Update,and Multiple Update and used these patterns to refractor Subform,Alternative Sub forms,Subform Selection,Subform Match,and Subform Mismatch.这里的关键词就是subform,直译就是从属形式，但是我觉得放在界面模式里面讲好像不大通，我想翻译成子表类，但是完全和字典的意思不相关，不知道您怎么说。谢谢
freeyourmind <freeyourmind251@sina.com.cn>
wuhan, china - Tuesday, June 04, 2002 at 13:59:39 (CST) From 61.183.121.133To CFL：在Business level上，像公司、部门等大多是一功能而区分，因此用Package来mapping这些功能需求是恰当的。为何要避免功能分解呢? 其理由是: 功能分解无法引导人们发现共享(reuse or share)的机会，如果您的目的是共享software components，则在business level用package来定义boundary是合适的。到了software system level，就必须有个跨package(每个package内有数个use cases)的 class diagram 来呈现sharable components, 这就是object-decomposition了。所以您所提的导出过程是正确的。两种model是abstract与detailede之mapping关系, 只是共享相同的business concepts (例如两个level都有Customer、Account等concepts)而已, 我不明白您”衔接”的意思。 By Tom
Tom Kao
NN - Wednesday, July 10, 2002 at 09:42:01 (CST) From 211.22.33.101.在收集User requirement 使用Use Case 时, 若用package来定义Use Case bounday是否有思维上的错误? 但packgae若以功能来区分时,并由此packgae的分类来 group Use Case会不会太早陷入功能需求,而非User 需求? 2. 从Business Use Case 及 Business worker's goal 导出 system actor 及 System Use Case 来进一步分析而导出 business object ,并以其互动关系来验证是否满足Use Case 您认为这样的思维正确吗? 如果正确,在model里该如何衔接此二种model?? 谢谢!!
CFL
NN - Thursday, May 30, 2002 at 10:49:45 (CST) From 211.23.77.164To KSHANG: 因为您的功能只是单纯的数据传输, 并无显著的business logic, 所以在客户端的应用只需2-tier系统就够了。至于Server端可能为了维护数据库的高效率而需要3-tier模式，此3-tier模式也很简单, 只需在App Server上摆上一些Stateless objects就行了。如果有较复杂的business logic时才需要复杂的3-tier模式。两端若接提供Web service，就互相呼叫对方的Web service就通了。 By Tom
Tom Kao
NN - Wednesday, July 10, 2002 at 09:42:38 (CST) From 211.22.33.10高老师：您好，我是UML的初学者，准备用DELPHI开发一个与数据库有关的FTP客户端应用；系统的功能是实现一些客户数据文件的远程传输，（客户信息保存在数据库中），怎样设计一个3层模式来实现？
KSHANG <WHO3@SINA.COM>
SHENZHEN, NN - Monday, May 27, 2002 at 13:27:24 (CST) From 61.144.167.142To yangboy, 從use case view到logic view的前提條件是---- use case diagram和 use case description 必須正確, 但是在實務上, 常欠缺此條件, 尤其是初學者. 解決途徑之一是採取iterative策略, 另一途徑是parallel策略, 建議您參考”Advanced Use Case Modeling”一書(ISBN: 0-201-61592-4)的chapter 11 & 12, 其中也有蠻好的例子. 請留意, use case view 背後是flow thinkng, 而sequence diagram和logical view背後是object thinking, 只要兩種思維能均衡互補就能順利從use case view 落實為logic view 了. By Tom
Tom Kao
NN - Saturday, May 25, 2002 at 08:00:22 (CST) From 211.22.33.139我正在学rational rose 2000, 我发现从use case中实现具体的sequence diagram 是个难点。实现具体的类难把握，能否介绍一些 材料或书。有无具体的实现例子，如财务软件，通讯软件，从use case view 到logic view. 因为要考虑代码的复用性等。
yangboy <anhuiyh_cn@sina.com>
NN - Friday, May 17, 2002 at 12:42:42 (CST) From 218.2.140.82To sakurracn, 您可把agent視為一個system, 目標視為其use cases, 每一個use case背後皆有一個它專有的control object, 於是就有了a hierarchy of control objects了. 於是能使用Gamma的’composite’design patterns表達出目標樹之結構. 接著, identify出各use cases共用之entity objects, 然後從各control object裡盡量將共用的operations or rules移到適當的entity objects裡, 將control objects虛化, 而將entity objects實化, 就能work了. 至於如何將operations or rules正確assign到適當的entity objects裡, 請參閱’Applying UML and Patterns’一書( ISBN: 0-13-748880-7)的Grasp patterns. 以上只是可行的design 之一但非唯一之solution. By Tom
Tom kao
NN - Saturday, May 25, 2002 at 08:02:42 (CST) From 211.22.33.139关于UML在代理中的应用细节问题！！代理技术中，每个代理具有一个多层目标树。为了完成顶层目标，可能通过下层子目标的“and"或”or“完成。且不同的环境情况，顶层目标的完成可能会有不同的最优实现路径。对这种大任务分成小任务，好像结构化设计中的模块设计，应如何利用UML处理？用例图可以吗？但它似乎重点在系统与外界的区分，而不在内部细节上。
sakurracn <mayi@csru.edu.cn>
NN - Friday, May 17, 2002 at 11:19:59 (CST) From 61.187.64.26To xinxuesheng, 設計含有藝術成分, 其基本原則是: 用最少的圖而能清晰表達出您心中的完整設計,是最棒的。因為有藝術成分, 就常無法完全自動導出, 反之能自動導出的圖如E-R model或XMI model等就不需要人去做abstraction ---- 也就是不需要做’設計’了。由於是人在做設計, 則常見的行為是iterative, 沒有嚴格的前後關係。 By Tom
Tom Kao
NN - Saturday, May 25, 2002 at 08:06:24 (CST) From 211.22.33.139请问：一个完整的Rose设计文档至少包括哪些图？后一张图和前一张图的关系如何？哪些图是自动导出的？
xinxuesheng
NN - Thursday, May 16, 2002 at 15:16:53 (CST) From 159.226.93.31 To Linkspeed, 我個人常從cognitive觀點來詮釋OO concepts, 我想我的mathematics 或formal language等知識, 並不足以回答您的問題. 謹此 by Tom
Tom Kao
NN - Saturday, May 25, 2002 at 08:07:32 (CST) From 211.22.33.139Hi, Mr. Gao: Most OO books talks about the concepts of class and object. Is there any definition in mathematics, such as formal language? In my impression, the set and type theories are about all the computing languages, not just OO. There is another book that about object theory in which I could not understand one single page. Can you tell me what relationship between such theories and the class and object in pratical language? How can I map the concepts in theory and the real practices together? What's the difference between an OO language and Functional language or Imperative language at those theory level? They must have some differences, otherwise, there would not have a theory call "object theory" Many many thanks Linkspeed
Linkspeed
NN - Thursday, May 16, 2002 at 08:34:47 (CST) From 203.4.181.70To ken, 因為UML只是依種’表達’方法, 但不是’分析’方法, 我想您指的是’表達方法’吧! 我認為表達方法的目的是要溝通(communication), 大家越一致, 逐漸改進, 集思廣益, 就越像音樂裡的五線譜及其音符般, 放之四海皆準, 就夠棒了. 例如UML逐漸將IDEF的流程表達之優點涵括進來, 是它逐漸改進的現象. 請留意, 將’表達’方法與’分析’方法做細膩的分辨, 就會更了解 UML. By Tom
Tom Kao
NN - Saturday, May 25, 2002 at 08:08:26 (CST) From 211.22.33.139OO的分析方法,除了UML,您是否推荐其他方法,UML又有什麼缺失?
ken <ken@topsoft.com.cn>
NN - Thursday, May 16, 2002 at 08:33:01 (CST) From 210.15.1.163 To sakurran, 在activity diagram裡的一個’join’element符號是一個instance, 此element能link到多少個《send》elements和多少個《receive》elements的限制(constraints), 這是instance-level的link關係, 會在class-level的association關係上定義, association的visibility能限制link對象的個數。 在activity diagram裡的一個’join’符號是一個instance, 其class存在於UML metamodel裡, 而不是在UML model層級去撰寫OCL敘述, 您可以定義一個新的stereotype of ‘join’,並且設定其visibility property之值。 UML/MOF/XMI的關係很簡單, 您使用UML去建立應用系統的models, 使用MOF去定義及管理這些models的metadata, 利用XMI將models轉成XML DTDs 然後能在internet上傳遞。OMG的其他產品大多是來支援UML的應用, 也有應用到UML。 By Tom
Tom Kao
NN - Saturday, May 25, 2002 at 08:12:01 (CST) From 211.22.33.139高先生：请问1.针对商务应用活动，我们对活动图的join扩展构造型，包括《send》和《receive》.在join处，每次最多一个《send》发送信息，而允许多个《receive》接受信息。用OCL如何描述？2.UML/MOF/XMI的关系。有很多关于UML在代理技术中的应用的文章，不仅提到UML，还包括了OMG的其他产品。为什么，这同样是UML应用吗?
sakurracn <mayi@csru.edu.cn>
NN - Tuesday, May 14, 2002 at 09:54:18 (CST) From 61.187.64.26To Sunche, 您的目的似乎想讓procedure ----- 取出製程(para-1, para-2, … , para-n)的參數個數不變, 是嗎? 如果yes, 有些可選擇的方案. 因條件新增致新增一些流程片段, 此片段您可以新增到business class內, 其勢必更改business class的內容. 在此情形下, para-n等只是純data而已, 您就可以把這些data items擺入collection 裡, 則變成為 ----- 取出製程( collection para_coll ). 之後business object從para_coll裡取出data items, 逐一處理之. 另一種途徑是定義一個super class ---- ’條件’,然後針對各條件而建立subclasses ----例如 ‘生產時程’, 它繼承’條件’class. 流程的新增片段,各寫在subclass裡, 則變成為 ----- 取出製程( collection of instance of '條件’) , 之後business object會呼叫subclasses裡的新增流程片段, business class並不需要隨著條件的異動而更改, 這是polymorphism的應用.----- By Tom
Tom Kao
NN - Tuesday, May 14, 2002 at 05:19:40 (CST) From 211.22.33.139Dear 高老師.我有個問題要請教您,當從business concenpt悴取來的business rule如何表現在businessobject中,尤期是當bisiness rule中有很多的check條件且check的條件是善變時.如:C製造光碟類別有一個interface叫做 取出製程( float mm , CExptool machine)...它會傳回 一個製程的類別(C製程)製程往往和點幾製程有關,和製造機台也有關..現在有可能和生產時程有關,..所以我改變interface變成C製程 取出製程(float mm , CExptool machine , Date duedate)..雖然是同一個interface卻有這不同的參數,需要check.我心中覺的不夠美,那一天有多個check條件我不是又要修改interface.Best Regards,Sunche Chen( sunche_locus@yahoo.com.tw )
Sunche <sunche_locus@yahoo.com.tw>
新竹, - Sunday, May 12, 2002 at 23:40:37 (CST) From 61.230.170.111hi liu090, 在rose裡可以加上collection 型態的attribute. 不同語言特性會塑造不同的思維方式, 常會束縛人的創造力, 但UML的visualization效果卻有助於創意. 同時因為UML的標準化, 促進溝通激盪, 也有助於think out of box, 對創意大有幫助. 像音樂的五線譜語言對音樂創意也是有幫助的, 再如寫詩, 好的詩不是來自語言的技巧, 而是來自詩人對一切事務的看法和心靈. 當您愈熟悉軟件設計的美感時,就愈有能力超脫tools(如rose和UML)的限制. By Tom
Tom Kao
NN - Tuesday, May 14, 2002 at 05:20:31 (CST) From 211.22.33.139想问高先生一个问题： 我要在rose的类中加一个属性，且是interger类型的数组， 好象不可以吗？如何做？？？？？？？？？ 另外uml是否会束博人的创造力，，，，我很困惑？？？
liu090 <liu090@sina.com>
china, shanghai NN - Saturday, May 11, 2002 at 16:01:11 (CST) From 61.169.217.4to DzWang, 所謂需求就是What users want. UC就要抽取what users want to buy. 關於UC的問題大多來自於view point上, 只要您能換個立場看看, UC的問題就能迎刃而解了. 想像您是user, 您會列出您想買哪些service, 逐一列出並給予名稱, 就得出 use case diagram了.別忘了, 天文學家’哥白尼’換個立場---- 想像自己坐在太陽 ---- 而得到不同的認知. 請您想像自己是users, 您會把[增、删、改、查]視為一體嗎? 如果會, 就合成一個UC. 如此就很自然而決定粒度大小了. 軟件是工程與藝術的結晶, 藝術創作取決於思維角度. UC是model, 不要追求完整性, 而在於抽象出重點, 細節流程可交給programmer去處理即行了. By Tom
Tom Kao
NN - Tuesday, May 14, 2002 at 05:22:17 (CST) From 211.22.33.139高先生，您好。我刚刚用Use Case作需求分析，现有好多不解之处，请您多多指教。一、我认为Use Case在获取的需求情况基础上进行分析的工具，但Use Case的抽取原则是什么呢？二、Use Case的粒度多大合适？管理客户档案（包括增、删、改、查4项操作）和分成新增客户档案等4个Use Case 哪个更合适？新增操作也是有一定流程的。三、Use Case事件流描述是否有必要写权限判定和输入数据的完整性检查？四、Use Case事件流描述中是否有必要进行画面流程的设计？
DzWang <wdz0001@sina.com>
beijing, beijing NN - Friday, May 10, 2002 at 16:39:37 (CST) From 211.99.50.125to xzhqzz, 在企業組織上是3-tier, 但是軟件設計上並非3-tier. 例如在客戶端您是採2-tier. 此客戶端與組織的中間層之間是透過Database進行資料轉檔, 而不是軟件系統透過XML直接溝通, 所以我認為此並非3-tier軟件系統. 在軟件系統上分散式大量資料傳輸已不是問題, 但依據您所述還不足以判斷出問題點. By Tom
Tom kao
NN - Tuesday, May 14, 2002 at 05:23:00 (CST) From 211.22.33.139我想请教一下。我正在做一个发短信的系统，采用三层模式设计，客户端把短信提交到数据库中，然后中间层从数据库中读取数据，发给短信中心，但是客户端提交给10000个左右手机的时候，会出现丢包现象，请问如何处理这个问题？ 对于远程分布式的大批量数据提交，如何处理？？
xzhqzz <xzhqzz@hotmail.com>
NN - Wednesday, May 08, 2002 at 14:47:05 (CST) From 211.139.46.227to Lean, 這要看誰trigger中央信息處理的, 如果是由hardware直接發出event給中央系統,actor就是hardware. 如果是IP-SV系統trigger的, 則IP-SV就應該是actor. By Tom
Tom kao
NN - Tuesday, May 14, 2002 at 05:24:25 (CST) From 211.22.33.139你好，我有个关于Use case图的问题：该系统是对很多硬件设备进行管理的，有三方：第一方为硬件设备，中间方为IP-SV（主要是负责数模转换的），第三方是中央信息处理。现在对中央处理画Use case图，并且文档主要是介绍硬件设备过来的处理流程。请问我是以各硬件设备作为一个Actor，还是以IP-SV作为一个Actor？
Lean <lean9@163.net>
NN - Sunday, April 28, 2002 at 12:57:07 (CST) From 61.144.207.45To 大寶, 就畫出一個橢圓, 中間填上’售票’, 就行了. So easy, 但也許我誤解您的意思了. By tom
Tom kao
NN - Tuesday, May 14, 2002 at 05:25:10 (CST) From 211.22.33.139PLEASE HELP ME ,A TEST QUESTION,顾客将钱投入自动售票机，机器显示可以买的票（低于投入的钱）。客户选择要买的票，如果低于投入的钱，那么出票找钱，如果钱不够，那么等待客户投入钱。画出use case 图
大宝 <qinjiwy@yahoo.com>
NN - Friday, April 26, 2002 at 21:04:27 (CST) From 61.176.7.221to boyi_cj, 從物流配送的domain裡找出domain concepts, 視為objects, 然後嘗試把數學模型裡的functions指定給不同的objects, 例如預測POS的銷售量, 此預測的數學function可成為’POS’ class裡的method. 原來POS是被動地被預測, 轉變為 POS自己會預測, 則物流配送就能思考為物品, 車輛, 企業組織單位等objects的溝通合作, 協同執行複雜的數學模型. 不要把物品視為data而已, 請把物品視為object, 其有行為能力. By tom
Tom kao
NN - Tuesday, May 14, 2002 at 05:25:52 (CST) From 211.22.33.139高老师您好,我是uml的初学者,在许多uml的书籍中,经常提到uml用于非软件工程领域,可是这方面的资料太少,不过我觉得uml的图形化建模的方式,很值得其他专业在构建应用模型方面借鉴引用,我现在在写关于物流配送方面的论文,设计到许多繁杂的数学模型,不知道uml能否给我带来更广阔的思路?盼您指点
boyi_cj <boyi_cj@yahoo.com.cn>
chendu, sichuan china - Thursday, April 25, 2002 at 20:03:19 (CST) From 211.162.180.109To xiuyanfu, 我的建議是----1)先以Component diagram表達出 中心server, 本地server和 client之間的dependecy relationship, 凸顯出整體結構。2)建立 a hierarchy of use case diagrams. 因為在FetchTask裡本地server是中心server的actor, 就導出中心server的use case diagram了.同理, 在InventorTask裡client是本地server的actor, 就導出本地server的use case diagram了. 同理客戶是client的actor, 就導出client的use case diagram了. 例如, client的use case之一是 ---- UC:客戶login, 此use case會去trigger client的某些use cases, 而client的use case又會trigger sever的一些use cases.3)針對各use case而去繪制其sequence diagram. 所以應該有a hierarchy of sequence diagrams 而不是集中在一個sequence diagram.4)至於use cases之間的trigger關係並不表示在這些sequence diagrams裡, 因為這些sequence diagrams 是表達use case內的狀況, 而不是use case 之間的狀況, 其是不同level的事.5)根據這些sequence diagrams, 就能分工去編碼了, 然後再根據需要trigger等關係而將之組合成整體系統。記得, 擅用use case能對複雜的sequence diagrams作理想的partition而簡化系統的設計與編碼。 By Tom
Tom Kao
NN - Wednesday, April 24, 2002 at 23:22:03 (CST) From 163.31.9.91高老师你好： 我刚刚开始学习使用UML，现在我需要对一个软件画用例图和顺序图。这个软件是多线程的实时程序。我们开发的代理软件gameproxy的功能就是使我们自己的服务器能够实现VLAN中游戏的互通，保证游戏的联机对战。gameproxy把本地server地址报告给中心服务器；而中心服务器将各VLAN中gameproxy发送的信息列表；各gameproxy再把中心服务器中的列表下载到本地，并保存列表，当客户发出请求时给予响应。 软件开始运行时，首先根据Config的内容启动FetchTask和InventorTask两个线程，并将ProxyHandler注册到Reactor。FetchTask的任务是每隔30秒向中心服务器发一次请求，然后接收中心服务器的响应（即返回中心服务器统计的服务列表），再将服务列表注册到本地ServerVector数据库中。InventorTask的任务是查找本地Server，并发送给FetchTask，激活FetchTask。ProxyHandler的任务是接收客户的请求，查询ServerVector，将返回的服务列表发送给客户。 程序大体就是这样，但我怎么也想不出来该怎样画它的顺序图，它需要与本地服务器和中央服务器进行通信，还要接受客户的请求并给予响应，但顺序图中该如何表示呢？不知我是否表达清楚？ 我真的很着急，请您在百忙之中尽快给我答复好吗？谢谢您！！！您可以将您的答复发到我的信箱。
学生 <xiuyanfu@163.com>
NN - Tuesday, April 23, 2002 at 15:43:22 (CST) From 61.149.33.170To jenny, C++比較偏向傳統OO思維---- 也就是class-based (即program to class)思維, C#和Java則偏向Component-based(即program to interface)思維, 在Web環境裡後者比較有彈性,易於分工與快速整合。C#與Java在language level是一致的。 By Tom
Tom Kao
NN - Wednesday, April 24, 2002 at 23:26:06 (CST) From 163.31.9.127面向对象的思想在C++,C#,Java上各有什么优缺点，不同？
jenny <chenjenny@yeah.net>
NN - Tuesday, April 23, 2002 at 09:45:18 (CST) From 211.97.75.34To阿肖, 我手上關於面向物件資料倉庫的理論部分並不多。我們也一直把它視為OOAD的應用, 也就是透過OOAD程序而分析business domain & decision requirements而建立UML的class diagram, 然後導出star schema。使用OOAD及object model的理由就在於easy-to-change, 因為business decision environment是多變的, 透過iterative approach 能達到此效果。 By Tom
Tom Kao
NN - Wednesday, April 24, 2002 at 23:29:51 (CST) From 211.22.33.10高先生：对不起，前面我问的问题是从钱五哥答疑版拷贝过来的。后面的称呼忘了改，真不好意思。
阿肖
NN - Monday, April 22, 2002 at 19:07:20 (CST) From 202.119.32.49高先生:您好我目前在写硕士论文，主要内容是探讨用UML进行数据仓库建模。我的考虑出于以下：我手头有一本《面向对象数据仓库》，我觉得能使用面向对象方法应该就能用UML来表达。现在我的内容基本写好了，UML方面主要做的就是定义了相关的版型，用类图描画出了星型架构。但是我还希望能得到一些理论上的支持，尤其是面向对象领域和数据仓库领域的专家在这方面的论述。我在网上找到的不多，不知道钱五哥在这方面能不能做点推荐，谢谢。
阿肖 <xiaoysh@sina.com>
NN - Monday, April 22, 2002 at 19:05:49 (CST) From 202.119.32.49 To kent, Visibility通常反應出設計的considerations ---- 主要是 replace的問題。Component如果要達到高度的replacability, 就會採取黑箱(black-box)的設計, 既然是black-box那該 component的attributes就必須是private. 例如 PC的mother board 上有個CPU, CPU裡有control unit 和adder兩個components, 一般此CPU是採取黑箱設計, 所以CPU裡關於control unit和adder的attributes都是private ---- 也就是CPU的client是看不到的. 如此的設計, CPU就是一個easy-to replace的component. 當然您將CPU設計為白箱---client 可直接跟 adder溝通, 但CPU 的抽換性就降低了。 Aggregation 是composition的一種。 By Tom
Tom Kao
NN - Wednesday, April 24, 2002 at 23:30:57 (CST) From 163.31.9.149How are you? I am learn the O-O Modeling. I am confued about visibility of attributes especially when I am modelling a composer writes composition. The composer's attributes,like birthOfDate and nationality, are protect or public? How to determine what visibility markers I should use when i'm modeling? Is it according to its real visibility(i mean we can actually see with our eyes) or the scope of the attributes like in programmes? Thanks.Also.what is the difference between compositon and aggregation?
Kent LEE <musickent@21cn.com>
Sydney, NSW Australia - Saturday, April 20, 2002 at 08:45:40 (CST) From 203.109.250.98To lucy, 請您留意 ---- ‘課程管理’應該是一個subsystem, 而不是一個use case. 一旦您能分辨subsystem(或稱package)和use case的區別時,您的問題就可解決了. Use case是有頭有尾的一連串事件活動,但是課程管理的活動並非一連串, 它是一個function area而不是特定actor的expectation. By Tom
Tom Kao
NN - Wednesday, April 24, 2002 at 23:31:47 (CST) From 211.22.33.10高先生：你好 我是一个uml新手，现在正在做远程教育系统的uml建模。 在划分用例的时候，比如用例课程管理和它的子用例添加课程、修改课程、删除课程之间，是用extend，还是用include??? 我看到的一些例子，用例和子用例之间有的用extend，有的用include。 在uml1.1中用例间有extend和use关系，而uml1.3中出现了include、refine、derive、extend等关系，请问它们之间有什么联系和区别。我看到一本书上说1.3上是用include代替了use，这种说法确切吗？
lucy <lucy_lsf@263.net>
NN - Friday, April 19, 2002 at 09:20:56 (CST) From 202.114.36.89To柴青鋒, 從use case導出class diagram時必須注意use cases的不完整性, 也就是您必須掌握所有可能的use cases中的80%才能得出穩定的class diagram. 還有use case必須是對的,但是use case的設計偏偏常是錯誤的開始, 因為use case很容易學但很容易誤用. By Tom
Tom Kao
NN - Wednesday, April 24, 2002 at 23:32:50 (CST) From 211.22.33.10请问高先生，当我们从use case 中导出类图时应注意些什么
柴青锋 <chaiqf@couragetech.com.cn>
北京, NN - Thursday, April 18, 2002 at 17:05:09 (CST) From 202.108.60.140To qgf, 因為他們獨立而且非例外狀況, 所以一般都擺在同一個use case的normal course裡, 各個都是normal flow裡的subflows. 如此描述就可以了. By Tom
Tom Kao
NN - Wednesday, April 24, 2002 at 23:34:04 (CST) From 163.31.9.149高先生您好！我是个UML新手，有个浅显的问题请教，关于用例建模中用例的大小和事件流的关系：我们把目前着手的系统分成11个包，对于，例如“性能管理”包，中的用例“管理性能任务”，它的事件流中，创建性能任务、删除、修改等等10项操作，彼此独立，放在1个用例的件流中该如何描述对以后的OOAD有无影响？若分成10个用例似乎太多了（其它的包也有同样问题）。
qgf
NN - Wednesday, April 17, 2002 at 17:22:44 (CST) From 202.96.238.210To richard, 這個問題我並不清楚如何回答. 因為不知道您指的安全是人為的故意破壞或是非故意的網路安全問題. 這些都是需求的一部分. By Tom
Tom kao
NN - Tuesday, April 16, 2002 at 15:33:38 (CST) From 211.22.33.10高先生, 你好,我现在想构建一个系统的安全体系结构(含软件,硬件,管理等),不知道如何进行需求分析,用什么工具好? 谢谢,
richard <infor_share@sohu.com>
beijing, china - Wednesday, March 20, 2002 at 10:18:30 (CST) From 61.149.34.154To wlq, 使用use case圖表示制程時, 必須注意到use case 並不適合表達生產線上的工作流程. 1) use case只用來表達下訂單者與此生產線的互動對話的過程(dialogue process). 2) 該生產線有許多的workers, 您可以為每一個worker建立數個use cases以表示該worker與此WMS系統的對話流程. 3)整個制程就是這些workers的collaboration, 應該以sequence圖表示, 而不是完全由use case圖來表示. 以上我所談的是use case表達製程時, 很常見的錯誤. 記得use case是actor與系統的對話流程, 而不是系統內部的工作流程,所以use cases之整合是透過actor整合的, 而不是單就use cases之間來作整合. 在過去的function-based時代只談流程, 但當今的component-based 不能只談流程, 而必須以component為中心, 才有意義. By Tom
Tom kao
NN - Tuesday, April 16, 2002 at 15:34:41 (CST) From 211.22.33.10高先生您好一個典型WMS系統的描述1.生管部門下達訂單2.訂單經過几個制程﹐這几個制程是相似的﹕ a.本制程內的派工 b.手工/掃描入庫3.產品出貨如何用UseCase圖分析,特別是﹐各個制程由不同的人分析﹐最后如何把他們畫的圖綜合在一起
wlq <qjwlq@sina.com>
NN - Monday, March 18, 2002 at 09:10:51 (CST) From 202.104.180.142To linqier, Aggregation 與Association的差異在其行為(behavioral)和涵義(semantics)面向. 在涵義上Aggregation具有包含之意. 在行為上, Aggregation往往其lifetime是一致的, 也就是聚合類必須負責create被聚合類的instance. 您只要觀察其instance的誕生時刻就知道了. By Tom
Tom kao
NN - Tuesday, April 16, 2002 at 15:35:38 (CST) From 211.22.33.10我想请问一个问题：我们在编码的时候，类之间有3种明显得关系，聚合、继承和关联（消息），我在用Rose进行设计的时候，也发现这3种关系的标识，但是，当我转换代码的时候，发现关联（Association）和聚合，二者没有任何区别，我不明白是怎么回事？
linqier <linsw@mail.cbay.net.cn>
NN - Tuesday, March 12, 2002 at 18:49:14 (CST) From 211.141.65.125To kingfanqi, 如果您的是real-time系統, 雙向引用是常見的, 因為real-time system常會share object state, 所以會共用instance. 如果您是database-based的business system就可以盡量避免雙向的引用, 因為object state是persist在DB裡, 並不需要share instance. 每一個use case執行時, 都各自誕生其所需要的instance. 這個有利的條件, 讓我們有更多的design choice. 我們就能將之改變成為單向的client-server相依(dependency)關係, 使得系統能呈現layered & tiered結構, 這樣的系統具有理想的穩定性與彈性. 您可參閱Ivar Jacobson的Software Reuse一書的Layered Architecture部分. By Tom.
Tom kao
NN - Tuesday, April 16, 2002 at 15:36:16 (CST) From 211.22.33.10高先生 你好，请教一个问题，在设计类时，如果三个类之间存在多对多的引用关系，并且存在先后关系，第一个类引用第二个类，第二个类引用第三个类，那在设计三个类时，可不可以反向引用，即第二个类中可以引用第一个类，第三个类可以引用第二个类？ kingfanqi 2002-03-12
kingfanqi <kingfanqi@163.com>
NN - Tuesday, March 12, 2002 at 16:16:35 (CST) From 202.102.240.75To yanqi, 依據rose的 stereotype 還是可以發展出自己的diagram加入Rose環境成為model的一個新view. 但是受到其meta model的限制, 您必須找到結構相同的notation去附加stereotype. 這方面我們的經驗不多, 新加的diagram都只限於既有diagram的specailization而已. By Tom
Tom Kao
NN - Monday, March 11, 2002 at 00:04:03 (CST) From 163.31.15.28高先生，你好。我想请问在ROSE中如何添加自己设计的一些diagram（原有的diagram之外的），就我所知，ROSE支持自己设计sterotype和菜单选项。 如果可以加入自己设计的别种diagram，请给出方法或相关链接，谢谢！如果不可以，请问自己开发ROSE插件能行吗？ Regards,yanqi yanqi <yanqi@163.net>
Changsha, CN - Thursday, March 07, 2002 at 20:45:46 (CST) From 206.48.88.161To goldarcher, 只要是它的client, 來用它時必然有其goal或expectation. 所以使用uc捕獲功能需求是適當的. 這種系統通常採取iterative approach. 需求分析人員會分辨輕重緩急, 挑出重要的uc, 重要的process, 重要的components, 得出系統的architecture, 再逐漸增加uc, 流程細節及components. Uc和 系統範圍都是可變的. 雖然這是use case-driven, 但卻是architecture-centered. By Tom
Tom kao
NN - Monday, March 11, 2002 at 00:05:01 (CST) From 163.31.15.28高先生，你好！我想请教一下，对于中间件系统，怎么通过USECASE来捕获用户需求呢？对于这种系统，ACTOR常常都不是人，并且系统的范围也很不好划定。这种情况下是否不适合用USECASE来分析需求呢，请您给些建议和指导，谢谢！
goldarcher <d_linlin@hotmail.com>
NN - Monday, March 04, 2002 at 10:25:11 (CST) From 218.6.192.84To皇甫軍, 抱歉 我不知道大陸現在有多少關於CLEARCASE的書. By Tom
Tom Kao
NN - Monday, March 11, 2002 at 00:05:57 (CST) From 163.31.15.28高先生，您好！我刚学CLEARCASE，您知道有什么中文操作手册或是您的一些操作经验可以给我学习吗
皇甫军 <h20010124@etang.com>
NN - Tuesday, February 26, 2002 at 14:22:59 (CST) From 218.76.41.77To xxsmxl, The book: “Component-Based Software Engineering ---- Putting the Pieces Together” edited by George Heineman ISBN 0-201-70485-4 is an excellent reference. Especially, Part VI (pp.431-552) about measurement and metrics for software components. By Tom.
Tom Kao
NN - Monday, March 11, 2002 at 00:06:50 (CST) From 163.31.15.28how to measure oo program,Can you recommend some books,articles or web sites about this.thnak you.
edward <xxsmxl@hotmail.com>
NN - Tuesday, February 26, 2002 at 09:19:03 (CST) From 147.197.200.12To Carrol, Use case呈現特定user的觀點(view), 一個系統是一個整體(whole)Use case 是局部(part), 一個整體不等於所有局部的總合. 如果一個系統是tree,而use cases是leaves, 當我們知道全部leaf的information時, 並不表示我們得到整棵樹的information. 至少從樹葉無法得知樹幹的info ! 所以classes最好來自系統的整體觀(the whole view). 對此整體觀的model就domain model. 在Jacobson 的想法中, domain models偏向business use cases (氣頁的外觀)及其 ideal model(企業的內觀), 再從ideal model 導出system use cases. 然而,在另一位專家 ---- Peter Coad的想法中, 從企業的重要事件(event)著手, 可得出較穩定的domain models, 再反過來支援use cases. 就像樹幹支援樹葉一般. 如此, 樹幹能支援未來的use cases. 如果您的classes只是要支援現在的use cases, classes 是手段而use cases才是目的, 那就不必講究domain model了, 如果您認為use cases只是用來提煉classes, 而use cases是手段而不是目的, 那就會很講究classess的設計了. 請參閱Peter Coad 的”Object Models: Strategies, partterns, and applications”一書. By Tom
Tom Kao
NN - Monday, March 11, 2002 at 00:07:35 (CST) From 163.31.15.28高sir，在您给潘瑞輝的回答中有这样一段话：“Identifying classes的途徑有很多, 從use case 的description去找是個方法, 但是副作用也很大. 也就是說, 最好不要由企業流程去找classes, 而應該從domain model下手, 從domain concepts去找classes才是最佳的.”我现在对domain model 感觉很模糊，domain model到底指的是什么模型呢？是不是指系统用例？
Carroll <swpi_zhao_xg@163.net>
NN - Monday, February 25, 2002 at 09:34:18 (CST) From 61.157.91.9To zhou, 在n-tier上, 除了GUI外, 我們很少計算SLOC(source lines of code).但是也有專家常使用SLOC計算productivity. 例如您可參考 Jeffrey S. Poulin的文章 ----- The book: “Component-Based Software Engineering ---- Putting the Pieces Together” edited by George Heineman ISBN 0-201-70485-4 的 pp.435-452. by Tom.
Tom Kao
NN - Monday, March 11, 2002 at 00:08:18 (CST) From 163.31.15.28我想请问一下如何对一个n-tier enterprise project的代码量进行估算，一个程序员大概的每日编码量，以及有什么工具可以用来计算一个完成项目的代码行数，谢谢
zhou
NN - Thursday, February 21, 2002 at 17:11:58 (CST) From 61.152.195.163To netcom19, 因為在台灣, Object-Oriented 常翻譯為”物件導向”. By Tom.
Tom kao
NN - Monday, March 11, 2002 at 00:08:44 (CST) From 163.31.15.28高先生，您好！请问你创建的杂志为什么叫"物件导向杂志"，而不是其他名称，是不是有什么用意
netcom <netcom19@yahoo.com>
NN - Thursday, February 21, 2002 at 10:13:31 (CST) From 211.167.66.38To weblane, 是的, 通常會添加一個façade object, 避免business objects 的interface 被clint層抓住, 創造出business objects的彈性空間, 此façade object相當於RUP裡的control object ---- 此control object內部的control logic 大部分都已經assign給business objects了,成為虛化的object. 就滿足 façade pattern的精神了. 這只是façade pattern的小小應用而已. 可參考Dersign Pattern一書. By Tom Kao
Tom Kao
NN - Saturday, February 09, 2002 at 02:53:00 (CST) From 211.22.33.11在表示层与商业逻辑层之间添加中间层，能有效的分离表示层上的页面代码和程序代码，方便测试与维护。请问高先生对此怎么看？有这方面的资料吗？
weblane <weblane@sina.com>
NN - Thursday, February 07, 2002 at 17:42:22 (CST) From 218.21.71.215To ying0818, 這視您的process而定了, 若採用RUP的話, 應該設計出design classes. 不過, 在RUP裡如果您的目標是2-tier或是sevlet/ASP-based的2.5-tier架構, 這些design classes並不複雜. 但是如果您的目的是發展3-tier或component-based系統時, 您必須將control objects裡的control logic下移到適當的entity objects裡, 並且設計這些entity objects之間的關係, 並且考慮到transaction, stateless, stateful objects等distributed computing的問題. 還是建議您採取iterative approach, 逐步增加的設計複雜度, 只要progarmmer覺得能編碼就盡快去編碼, 不必太重視D&P的分界, 因為設計越細膩, 常錯越多! 多test才是良策.By Tom Kao
Tom Kao
NN - Saturday, February 09, 2002 at 02:54:07 (CST) From 211.22.33.11用OO做系统分析与设计有一些困惑，希望能够得到您的指点。困惑之一： 在设计阶段应该主要设计出什么东西才能进行下一步编码？ 困惑之二： OOADP时以什么为任务分配单元？比如：在结构化方法中可以以功能模块为任务分配单元
learningUML <ying0818@sina.com>
NN - Wednesday, February 06, 2002 at 11:43:42 (CST) From 211.88.8.131To wang, N-tier架構設計最主要的考量是change的因應策略. 也就是將”應變的策略”寫入software裡, 而不是把所有可能的變化皆寫入software裡. 聽起來似乎很玄, 其實道理並不難, 只不過是中國哲理裡的”虛實相依”之道理而已. 所謂相依就是洋人的dependency. 談到dependency就牽涉到interface概念了. 如果object A uses an interface of object B, then A depends on B. 這意味著如果B是善變的話, A就不得安寧. 此架構就是bad! 例如, 如果database是善變的, 在 ap server上的bisiness objects 若直接呼叫DB的API, 就是bad design. 因為business objects 需要穩定, 它是software系統的主幹, 需要穩定, 系統才能穩定發展. Business objects 和 database皆是實的, 兩者之間必須有一層虛的, 就是persistent objects. 只要您能with change in mind, 就能掌握N-tier的設計了, 就像古代的大禹治水---- 順應change , 而鯀的治水 ---- 想控制change, 兩者得出不一樣的設計. 易經的乾掛也告訴我們: 龍是善變而高能量, 只要有藝術之心就能leverage 它的潛能. 所以軟件工程和軟件藝術的均衡,是N-tier設計的基本心理素養. By Tom Kao 關於書籍---- John Cheesman 的UML Components ISBN:0-201-70851-5 ---- Heineman的 Component-based Software Engineering ISBN: 0-201-70485-4
Tom Kao
NN - Saturday, February 09, 2002 at 02:55:03 (CST) From 211.22.33.11高先生，我一直留意着您对N-tier架构及其层次划分问题的回答，细细品读之后还是不得其要领。我想请教高先生，对于N-tier架构的观念的掌握，应如何学习，可否为晚生介绍一些相关书籍，谢谢！
wang <yy5558@263.net>
huludao, liaoning mainland china - Wednesday, February 06, 2002 at 08:14:43 (CST) From 211.93.121.248To steven. 過去在2-tier時代, windows內涵有流程的行為控制, UI會蠻複雜的, 很號時間, 因而想去建立model 尋求reuse. 然而隨著HTML, XML, Web service的潮流, UI的model對象是Page 或XML Document等,而不是Form及buttons等了. 此外可為UI建構出UML statechart 及use case model.敘述系統UI的整體外部行為, 可參考物件導向雜誌第12 期 page. 82. By Tom kao
Tom Kao
NN - Wednesday, February 06, 2002 at 07:28:45 (CST) From 211.22.33.10高先生，您好！我觉得UI建模好像和OO设计的其它方面有很大不同，以下几个问题让我觉得疑惑：1）我应该把每个window作为对象体现在设计模型中吗？这样好像会使得设计模型非常易碎。2）如果把Window作为对象来建模的话，好像很难决定它的behavior，因为它接收的大多数消息来自用户的操作而不是来自其它内部对象。3）如果一个window中包含其它复杂的界面元素（例如TreeView等），我是否应当将这些界面元素也作为对象抽取出来？这样好像会变得很琐碎。4）普通的业务对象和控制对象都容易写出单元测试代码，但是UI对象怎样进行单元测试呢？window对象所响应的请求（比如鼠标点击）无法用代码激发呀！5）如果我使用RAD工具进行开发，情况有何不同？非常感谢您！ steven <steven@steven4u.net>
中山, 广东 China - Friday, February 01, 2002 at 12:02:31 (CST) From 61.142.76.34拜師學藝
劉智維 <dearwell.tw@yahoo.com.tw>
taipei, 中国 - Tuesday, January 29, 2002 at 10:54:52 (CST) From 202.154.192.30To wlq, 如果Data Sources是很單純的RDB, 而且集中式的RDB, 各種方法的效果大致相同. 如果Data Sources是多樣化的, 而且是分散式的, 採取物件訪問層方式應是較理想的. 穩定的介面是重要的考量. By Tom Kao
Tom Kao
NN - Wednesday, February 06, 2002 at 07:31:04 (CST) From 211.22.33.10Sir,你好！ 请问数据库服务方面，中间层的业务对象中是怎么样来进行与数据层的交互的，对于Persistant是怎么看的，在业务对象与数据库之间加上这个思想设计你觉得如何，用来解决跟数据库的交互问题，以进行跟业务的隔离，这样和加上一个对象访问层，哪一个好些？
wlq <wlq1978@263.net>
hangzhou, zhejiang NN - Monday, January 28, 2002 at 09:59:03 (CST) From 210.83.171.234To Alibaba, 請再敘述 ”介面和代碼分離” 之意義. Thank you . by Tom kao
Tom kao
NN - Wednesday, February 06, 2002 at 07:31:47 (CST) From 211.22.33.10高先生，占用您一点宝贵的时间，我是刚毕业的计算机系的学生，想学习 UML统一建模语言。对面向对象也不是很熟练。还有界面和代码分离是如何实现的？谢谢。
Alibaba <haitao_ma@sina.com>
SHENYANG, China - Thursday, January 24, 2002 at 00:02:45 (CST) From 61.176.54.81 If OO approach is new to you, it is better to do it with iterations. Try to identify the core business processes, and then to identify the derived core system use cases. So that you can analyze, design and implement the core use cases in a short time frame. This way may give you a happier experience. ---- By Tom Kao
Tom Kao
中国 - Wednesday, February 06, 2002 at 07:33:32 (CST) From 211.22.33.10Sometimes, I confuse about some design procedure, could you comments my steps?1. proposal: talking about why did this project2. techology overview and checklist: write down the step how to use the new package or library. Add some usecase diagram3. Write the specification with use case analysis4. Analyze: refine the noun, verb build the conceptual model5. design: draw collaboration and class diagram with every method with some pattern design method.6. build a complete check list for all procedure7. coding8. testing: I want to do "pressure testing", but don't know how.problem with the project:1. the class diagram and collaboration diagram is too complicated and can't print on one page. I feel hard to read them.2. about 3000 line code small project get too much diagram3. the step2 could go wrong because of new technology, so waste a lot of design, re-do a lot of work.Could you gave me some suggestion or comment my steps?thanks
xi rao <raoxi98@hotmail.com>
NN - Tuesday, January 22, 2002 at 05:02:12 (CST) From 156.56.103.155tO vans, 加上物件訪問層是合理的, 但訪問層的物件應該是stateless, 其db connection 的運用率才會提高, 既然是stateless物件, 就是functional 思維的產物, 與OOAD似乎是無關的. 除非Business物件與訪問層的物件是一對一. 但是一對一並不是很好! 因此, 加上物件訪問層是合理的, 但不會多家負擔. By Tom Kao
Tom Kao
NN - Wednesday, February 06, 2002 at 07:34:29 (CST) From 211.22.33.10商业逻辑层和数据层的区分: 我的设计是在商业逻辑层和数据层之间加上一对象访问层，它负责动态产生数据访问语句，逻辑层对数据的访问类似于类对其属性的访问，这样逻辑层和数据层的耦合度就降低了。 当然，这样做的前提是需求的OOAD要做好！ 不知道，高Sir对这种方法有什么意见，请多指教。
vans <peng.chang@china.com>
beijing, cn - Wednesday, January 16, 2002 at 18:26:21 (CST) From 202.112.138.62To yinxm, 這與您使用的platform有很大的關係, 如果您使用EJB, 只要follow其framework就行了---- 將business logic 落實到session bean 而data logic 落實到entity bean. 如果您採取Microsoft .Net, 就會受到其DataSet用法的影響.每個platform都有其assumption和框架,但是都會支持相同的目標---- 讓Data Base或Data Source能激烈變化, 但不至於激烈影響到mid-tier及representataion tier. 這一部分沒有一定途徑, 需要理解platform的特性,心中追求上述目標, 加上一些練習就會有把握了. By Tom Kao
Tom Kao
NN - Wednesday, February 06, 2002 at 07:35:46 (CST) From 211.22.33.10高先生，您好，我在三层设计的时候可以把用户界面和商业逻辑层分开，可是商业逻辑层和数据层的区分程度我总是把握不好，业务逻辑总要修改数据库吧，我想请教一下，这一部分有没有好的方法？谢谢您！
yinxm <lofa@263.bet>
beijing, NN - Thursday, January 10, 2002 at 14:01:31 (CST) From 211.157.248.42To潘瑞輝, Identifying classes的途徑有很多, 從use case 的description去找是個方法, 但是副作用也很大. 也就是說, 最好不要由企業流程去找classes, 而應該從domain model下手, 從domain concepts去找classes才是最佳的. 可參考Charles Richter 的 Designing Flexible Object-Oriented systems With UML 一書. 還有 Perter Coad的Object Models 一書. By Tom Kao
Tom Kao
NN - Wednesday, February 06, 2002 at 07:36:56 (CST) From 211.22.33.10我学UML有段时间了，我觉的用例图描述企业流程,辅之以顺序图和合作图应该来讲不是很困难（因为现在我做系统分析只是做到这一步而已），但是如何提炼出类图我觉得很不好处理，有没这方面的好书或建议提供一下，谢谢！
潘瑞辉 <prh1@21cn.com>
广州, 广东 中国 - Sunday, January 06, 2002 at 14:16:55 (CST) From 61.140.101.70To liuhongchao, 我想, UML Distilled 一書是蠻好的入門書. ---- by Tom Kao
Tom kao
NN - Wednesday, February 06, 2002 at 07:37:38 (CST) From 211.22.33.10高先生，占用您一点宝贵的时间，我是刚毕业的计算机系的学生，想学习 UML统一建模语言，我对它的重要性已经有了了解，但是不知道从哪里入手开始学习。我想请你推荐一本入门级的书籍，可不可以？？谢谢您！
liuhongchao <thisisfirst@263.net>
石家庄, china - Tuesday, January 01, 2002 at 10:51:19 (CST) From 61.182.99.136To Fox, 所謂business process是有很多個views, 有些人重視activity flow, 就會抽象出activities而抽掉data 及worker等, 成為activity diagram. 有些人重視data flow, 就會抽象出data而抽掉activities 及worker等, 成為Data Flow Diagram. 有些人重視workers之間的message passing及互助合作, 就會抽象出objects而把data 及activity納入objects內, 成為object model. UML是來自OO領域, 比較偏重object model, 需要習慣於object thinking, 一般人會覺得不太直觀. 但是要將MIS系統落實到N-tier或component-based環境, 就必須將activity flow & data flow的model轉為object model, 因為object model 的內涵(semantics)最豐富, 能提供充足的information給software developers. UML2.0已經吸收IDEF, 強化了business activity flow的表達.因為manager喜歡activity flow diagram, UML2.0 比較能抓到manager’s view 了. 記得, use case不是用來表達business內部的work flow! By Tom kao
Tom Kao
NN - Wednesday, February 06, 2002 at 07:38:22 (CST) From 211.22.33.10我感觉uml建模过程是使用文字描述和用例图描述企业流程,辅之以顺序图和合作图.但是这种模型不太直观,因为顺序图和合作图中没有表达业务数据的流动(虽然文字描述中有)，在IDEF分析方法,企业流程图要表达业务数据的流动,我以前使用uml进行MIS类系统的分析时,在业务分析阶段仍然使用业务流程图进行企业业务的描述，请高老师给与解答
fox <wrtf@21cn.com>
NN - Saturday, December 29, 2001 at 15:15:48 (CST) From 61.170.144.178高生，非常感谢你的指点。只是不知道那里有Building Web Applications with UML Rational Rose 2000e 可以下载呀？
coolwizard
NN - Thursday, December 20, 2001 at 15:50:05 (CST) From 202.103.148.136To coolwizard: 您看過 Rational 公司的Jim Conallen 所寫的一本書 -----‘Building Web Applications with UML’嗎? 也許它是個好得參考, 其中的icon都已經落實於Rational Rose 2000e version裡了. ---- Tom kao
Tom Kao
NN - Thursday, December 20, 2001 at 06:16:47 (CST) From 211.22.33.10高生，我用的是IBM WebSphere.我想问你的是在作WEB系统开发的时候怎样进行页面UI的设计，我觉得这一块要用UML表示出来比较棘手，因为JSP页面可能会很复杂。你可以看看图片共享中的（在线专家Class图、在线专家usercase图），我总觉得我的设计有问题，有些杂乱。有人建议我用组包的方式划分结构，但是总是要有一个图来表示他们之间的关系不是吗？我就是采用三层结构！在在线专家Class图中我并没有明显的划分他们是那一层的，我只是要说明他们之间的关系。只是给我的感觉这个图有点象部署图，我只想知道怎么避免这个问题，怎样改进它
coolwizard
NN - Wednesday, December 19, 2001 at 12:41:45 (CST) From 202.103.148.136To: coolwizard 如果您使用像 IBM 或BEA公司的Application Server(如BEA的Web Logic system) 的話, Servlet的內容就只剩下GUI logic而已, 因為Business logic 移到mid-tier的ap server了. 此時servlet的class diagram 裡的classes 是代表 html files 就是pages, 包括client page及server page. App Server裡的class diagram 的classes 就代表business concepts就是所謂的business components. --- Tom Kao
Tom kao
NN - Wednesday, December 19, 2001 at 12:06:24 (CST) From 211.22.33.10高生，我现在从事基于J2EE的WEB开发，在这些系统中尤其是前端JSP,Serlvet的设计上比较难以把握，我尝试画的Class Diagram我觉得有些象部署图，因为JSP的显示可能比较复杂，不知道你觉得在Web系统的设计上该注意些什么
coolwizard
NN - Tuesday, December 18, 2001 at 14:52:25 (CST) From 202.103.148.136 To xuean, 請教您, 您指的containment tree事像BOM(bill of material) 裡的物料item之間的關係嗎? ---- Tom Kao
Tom kao
NN - Wednesday, December 19, 2001 at 12:07:34 (CST) From 211.22.33.10Sir,I am not clear how to explain containment tree using UML.( In Q3 interface, we use this method to express the relationship of class) thank you
xuean <xiexa@263.net>
china, beijing NN - Monday, December 17, 2001 at 16:59:44 (CST) From 194.138.202.10To pherery: Behavior Subtype 為介面繼承, 注重於object的抽換性, 即支持polymorphism, 此是為了software的彈性, 以便應付多變的user requirements.這是近來對繼承的主流思維, code reuse可走binary code reuse, 就是經由interface的reuse, 因為經由繼承的source code reuse 會有大的副作用---- dependency太高. ----- Tom kao
Tom ako
NN - Wednesday, December 19, 2001 at 12:09:09 (CST) From 211.22.33.10高先生：您好！我想问您一下，有关对象继承的使用，一直有两种观点，一个是Code reuse，一个是Behavior Subtype。诚然这两者是截然不同的，但我始终不太明白，这样的区分，对于实际的应用开发来说，有什么意义呢？如果可以，您能举一个鲜明的例子说一下这样做的意义么？
pherery <runbo.li@intec.iscas.ac.cn>
Beijing, CN - Monday, December 17, 2001 at 13:56:58 (CST) From 211.155.173.173高先生您好，UML可以用来分析分层系统（layered systems）的各层接口吗？举一个大一点的例子：对于ISO OSI模型，我们对整个系统的各层进行了划分，如果想进一步确定各个层的接口，有什么好的方法和工具吗？我不知道可不可以用UML来分析这样的系统。如果可以得话，该怎么分析呢？我觉得每一层的接口相对于这一层都可以认为是它的use case。如果UML不擅长这种系统间接口的分析，能推荐几个合适的方法吗？//bow
slob <xuyq99@mails.tsinghua.edu.cn>
Beijing, NN - Sunday, December 16, 2001 at 16:15:51 (CST) From 166.111.69.133 To wangxh1000: 您的system內有細分為更小的components嗎? System內的Worker 會扮演小component的actor的角色. ‘計時器’或’clock’接能triger某些component的工作流程. 一旦您使用object-oriented thinking去細分出小copmponents, 會發現’計時器’triger某個component的use case ---- ‘警告提示”此Component可能繼續triger另一個component的use case ---- ‘顯示處理”. 這些內部小use cases串起來就是system的內部work flow, 而非system的external behavior---- 即use case. 記得use case thinking 必須搭配object thinking才能解決OO的設計問題. ---- Tom Kao
Tom kao
NN - Thursday, December 20, 2001 at 06:17:59 (CST) From 211.22.33.10高先生，请教两个有关Actor的问题。我有一个用例是“警告提示”，这个用例是由内部事件触发的，如“发生温度的异常现象”，我在选择Actor的时候选择什么呢，是选择“定时器”，选择“系统时钟”？我找了一些解释，用“定时器”作Actor的说明中并没有说事件触发的这种情况，另外也没有找到任何资料说“系统时钟”可以作Actor的，究竟应该如何理解？第二，如果用例分成主用例和从用例，Actor连接在哪种用例上好呢，我到网上查了一下，怎样的画法都有。比如，我的“警告提示”主用例include了“显示处理”的从用例，我有一个Actor“显示硬件单元”，是连在“显示处理”从用例上呢，还是连在“警告提示”主用例上，还是其他？请您帮我解答一下，谢谢
wangxh <wangxh1000@sina.com.cn>
shanghai, china - Wednesday, November 28, 2001 at 15:12:24 (CST) From 61.171.42.26To illfly: N-tier architecture的目的是要提升系統的彈性,以強化應變能力. 基於這個前提, software developer就得細心分析您的系統的change 因素以及來源為何.例如您認為DB是穩定還是善變呢? 如果您的答案是”善變”, 您就不能從DB層開始了. 因為房子的地基越穩固越好. 依據layered architecturte 原則, 善變者應該屬於上層, 所以DB若善變就不應該視為底層, 此為View的問題. 在 web service環境下DB是極端善變的. ---- Tom Kao
Tom Kao
NN - Thursday, December 20, 2001 at 06:18:54 (CST) From 211.22.33.10高先生，您好首先，谢谢你的回答。我的OOD的意思是面向对象设计的原则，我想您提到的体系结构优先原则，应该是对于软件设计阶段而言的。我的整个开发原则，是指Entire project life cycle。您认为设计多层结构的系统要从中间层开始，为什么不是从其它层，比如数据层（最低层）开始？另外，对于不同的体系结构，他们的过程和原则不同在何处？如果您太忙的话，能否推荐一些文章？
illfly <illfly@eyou.com>
beijing, CHINA PR. - Monday, November 26, 2001 at 16:30:31 (CST) From 159.226.7.71To illfly, 請問您, 您指的是ood還是ooa&ood? 請問您, 您指的整個開發程序是指整個ood程序還是the entire project development life cycle? 我想, 首要的原則是: architecture-first. 例如是real-time system? 2-tiered client-server system?還是n-tier enterprise / web service system ? 不同的architecture 其開發的detailed process and priciple是有很多差異的 例如 開發 n-tier enterprise system時, 有個重要原則就是: 先design mid-tier 裡的objecrts, , 之後才分析user的流程細節.
Tom Kao
NN - Thursday, November 22, 2001 at 16:02:24 (CST) From 203.149.189.158高先生，你在做ood的时候，遵循那些原则？在整个开发的过程中，你又遵循那些原则？另外，你能推荐一些关于这方面的文章吗？
illfly <illfly@eyou.com>
beijing, NN - Friday, November 16, 2001 at 13:44:49 (CST) From 159.226.7.71To Zlqf, OOA是要釐清Domain的objects, 及object之間的relationship, 例如OOA關心的是一個鳥巢裡含有哪些鳥蛋.然而在Programming時因使用relational DB, 其query時是以Set of objects為目標, 而非以object為目標,所以programmer每次query時是要找出 a set of 鳥巢, 及a set of 鳥蛋, 讓user挑選, 但OOA層次並無此Set思維. 從OOA的intance 思維到programming的table思維之轉換是OOD的主要工作, 解決方案是: 您可透過stateless object 去query 一個set, 如RecordSetor .Net的DataSet, 直接送往client side, 在mid tier不用object去留下set或object的內容, 只有在update, delete , insert時才用到mid-tier的object去處理object或record 的state.
Tom Kao
NN - Thursday, November 22, 2001 at 16:00:18 (CST) From 203.149.189.158谢谢高先生指点,我最后一个问题是想问:对于大数据量要返回到用户界面在ooa里处理的技巧性.
zlqf
NN - Friday, November 16, 2001 at 08:53:39 (CST) From 218.2.131.238To Zlqf, Midas 已經是4年前的系統了,並非標準的3-tier架構, OOA所分析出來的objects不易落實於Midas環境,建議您採用Dephi公司新的EJB-based Application Server就能發揮OOA帶來軟件彈性的益處.ERP使用OOA的開發成本會增高因為採用新的PM(project management)人員需要訓練成本. 但在Deployment及營運成本則能大幅降低. 至於最後的問題可否在敘述清楚些?
Tom Kao
NN - Thursday, November 15, 2001 at 01:35:01 (CST) From 61.13.213.127高先生：请问Delphi下的Midas的三层结构的开发和所说的OOA方式有什么同异点？如果ERP的产品用OOA的方式来开发，其成本是否很高？另外ooa分析出来的对象最终和用户界面如何整和，是否有这方面的范例？
zlqf
NN - Wednesday, November 14, 2001 at 11:18:56 (CST) From 218.2.131.238To westwf, 這是軟件比較不易於工程化的原因, 如果Software Engineering 含括分析與應變的話,效益是development team所有,而非工程師 專有,包括協助project的所有stakeholder都有貢獻,此為整體的貢 獻,想一想一支籃球隊得到冠軍時, 如何計算出每一位球員的貢獻呢? Software Engineering(SE)一辭因人而異, 而且數學難以計算整體 和諧的個別價值,SE本身有許多盲點,也有其極限! Tom Kao
Tom Kao
NN - Monday, November 12, 2001 at 10:35:56 (CST) From 61.13.17.82高先生： 请问软件工程中是如何估算软件工程师在一个项目中的贡献和产生的效益的,因为最终的代码运行在客户的机器上，而只凭几页文档资料是很难说明什么的;代码和文档资料很可能不一致！！！
westwf <westwf@hotmail.com>
NN - Sunday, November 11, 2001 at 11:55:33 (CST) From 61.151.234.125To Sunshine, 中間層的object不一定要成為COM component, 一般把sql statement 封裝於stateless的object, 其交給COM即可, 把business rules 封裝於stateful 或stateless內, 不一定 要給COM 因為它不需要sql and join transactions. Tom Kao
Tom Kao
NN - Monday, November 12, 2001 at 10:45:18 (CST) From 61.13.17.82我开始用COM/DCOM开发三层结构的应用系统，想请教几个问题，1.中间层如何用COM封装对数据库的访问？2.数据库中的表在OOA中为一些Class/Object，这些class如何和数据库中的表交互？
sunshine <sunshine@sdu.edu.cn>
NN - Thursday, November 08, 2001 at 15:31:34 (CST) From 210.77.126.233To Kick, 您是採取Waterfall還是Iterative approach? 如果是Iterative, 在從conceptual level 到specification level的設計過程中, programmers 由沒有參與呢? 如何feedback programmer's idea back to designers呢?
Tom kao
NN - Monday, November 12, 2001 at 10:54:17 (CST) From 61.13.17.82高先生，你好：我现在正在搞一个项目的设计，那么搞到概要设计到详细设计的时候很头痛，因为，我突然发现自己不知道要搞到什么地步才可以停下来。请问项目的大小、开发时间、和建模的程度是否会因为某一因素的限制改变其他因素，如果改变的话（我认为是无法避免的）改变到什么程度是不可容忍的。因为这个是我用OO做的第一个设计。项目不大，用UML建模。十分感谢
KICK
北京, NN - Thursday, November 08, 2001 at 14:36:59 (CST) From 211.157.180.129To TamRhui, robustness 分析是在尋找business workers 由它們合作完成business use cases, 再視這些為IS的candidate actors, 就能順利導出 IS的use cases 了. Tom Kao
Tom Kao
NN - Monday, November 12, 2001 at 11:11:53 (CST) From 61.13.17.82"Robustness analysis"主要是做什么工作？从书面上理解，是”健壮性分析“，在Ivar Jacobson的“Object-Oriented Software Engineering”书中介绍，是分析阶段的其中一个子阶段，根据requirements model进行Robustness analysis，输出Analysis model,但是，在这个分析中，我们主要针对什么进行，如何进行？请指教。
TamRhui <trw@mail.china.com>
ShenZhen, CN - Wednesday, November 07, 2001 at 19:34:25 (CST) From 61.144.250.10我对”Domain object model“（Ivar Jacobson 中提到）一直不理解，未搞懂具体什么意思，请指教。
TamRhui <trw@mail.china.com>
ShenZhen, CN - Wednesday, November 07, 2001 at 19:26:29 (CST) From 61.144.250.10To hotant, 一個project可使用不同的design patterns. 一般"design" patterns 與語言是無關的. 可否針對前一項舉個您的實際例子呢? Tom Kao
Tom Kao
NN - Monday, November 12, 2001 at 11:16:25 (CST) From 61.13.17.82我所说的正是design patterns。谢谢关注
hotant <dachshund@163.com>
shenzhen, china - Wednesday, November 07, 2001 at 13:55:30 (CST) From 61.141.206.97To: jiayu, 我主要是研究設計思維, 而非UML 就如同研究如何寫唐詩宋詞 而非研究中文語法 Tom Kao
Tom Kao
NN - Wednesday, November 07, 2001 at 01:10:24 (CST) From 61.13.17.35高先生，您好！我有几个问题想向您请教。UML既然已经成为一种标准的东西，如果要对UML进行研究，有哪些方面还有值得研究的潜力？请问您主要研究UML的哪些方面？如果要研究UML建模的支持工具，您认为哪些方面是有研究价值的？谢谢！
Li jiayu <yejituo@263.net>
Beijing, cn - Tuesday, November 06, 2001 at 09:00:51 (CST) From 211.71.12.135to hotant, 您所提的設計模式是指 Design Patterns 嗎?
Tom kao
NN - Wednesday, November 07, 2001 at 01:12:44 (CST) From 61.13.17.35你好，请问在做OOAD的过程中，在一个系统的开发中根据具体情况的不同在一个系统内使用多种设计模式是否可行？选择什么样的设计模式是否与语言实现完全无关？谢谢
hotant <dachshund@163.com>
NN - Monday, November 05, 2001 at 11:44:54 (CST) From 61.141.204.164To bobo, 關於.Net用途太廣 可否縮小您的問題?
Tom Kao
NN - Wednesday, November 07, 2001 at 01:15:05 (CST) From 61.13.17.35您好，我想问一下ms的.net平台到底有什么用？怎么用？希望能介绍一些相关的资料给我，非常感谢！！
qw.bobo <xb1@163.net>
NN - Monday, November 05, 2001 at 11:43:44 (CST) From 61.180.103.119to slovenboy, 一般而言, 先釐清Domain裡的concepts, 然後從concepts 選出 key concepts 成為components, 再把流程的 tasks 分派給適 當的components.
Tom kao
NN - Wednesday, November 07, 2001 at 01:20:22 (CST) From 61.13.17.35面向对象分析的一般过程是什么样子的？？
slovenboy
beijing, beingjin cn - Friday, November 02, 2001 at 11:19:07 (CST) From 211.167.66.152To akaji, Objects是元素, module是組合物, 就像H20是水, 而H 和O 是分子, 如何從水mapping 出H & O ? 先有H & O而後有水 ! module is what user want to buy. objects make up modules.
Tom Kao
NN - Wednesday, November 07, 2001 at 01:30:50 (CST) From 61.13.17.35Sir,what is the mapping between the functional module and object or class?一般来说，我们开发的系统整体上看仍是按照功能模块划分的，我想知道面向功能的模块划分和对象模型、oo的思想有什么差距？
akaji <mamie@39.net>
beijing, cn - Friday, November 02, 2001 at 11:07:22 (CST) From 202.106.167.133
