Topic: 对使用Together的建议 |
 Print this page
|
| 1.对使用Together的建议 | Copy to clipboard |
|
Posted by: jackzhuo Posted on: 2003-05-20 14:05 本来我是想回贴的,但那个贴已经超过回复时限了(不知这样做有什么时候好处?),所以只好另外再末一个贴了. -------------------------------------------------------------------------------------------------- 我觉得在现在的开发设计人员中存在误区,而从此贴看也有这方面的问题,说到使用Together,我有一些自己的体会,因为我们刚和BORLAND的工程师一起使用TOGETHER进行了一次实际的建模工作,对Together的使用有了一定的经验,被BORLAND称为他们收购Together后的第一批用户. 我觉得不管是用Together也好,用Rose也好,这些全都是工具来的(对只是tools),而tools只是为了给我们使用中提供一些方便,虽然很好用,但也解决不也根本问题,而基本的问题就是UML的使用,就是你的设计知识面是不是足够宽,你原来的是否有过设计的经验(当然失败的经验可能更好  ),也只能有了这些前提条件,你也才能用好Tools.在这次工作中,Borland工程师主要给我们讲解的是采用面向对象的设计方法,而不是怎么使用Together,而你在了解了这个思想以后,你会发现使用Together是水到渠成的事,而且如果你以后可能使用Rose的话,也没有问题. 所以我觉得大家应当将精力多集中在一些基本知识的积累上,尽可能少在工具本身花太多的时间,因为现在软件的更新太快了,很可能到最后你什么也没有得到! 另外,向大家推荐一本书,在书店都会有卖,<UML实用建模实践过程> 作者:尤克滨,这本书中是真正的经验之谈,现在我们的项目中已经是人手一册了! -------------------------------------------------------------------------------------------------- | |
| 2.Re:对使用Together的建议 [Re: jackzhuo] | Copy to clipboard |
|
Posted by: dawnroad Posted on: 2003-05-20 14:41 Rational的尤克滨 最近曾经组织翻译了一本关于配置管理和clearcase的书，那本书也很不错，不过翻译得一般，但不影响阅读 | |
| 3.Re:对使用Together的建议 [Re: jackzhuo] | Copy to clipboard |
|
Posted by: jackzhuo Posted on: 2003-05-20 17:05 他现在已经去Borland了,哈哈哈哈,我也算给他做个广告 ,不过那本书写了是非常好!
| |
| 4.Re:对使用Together的建议 [Re: jackzhuo] | Copy to clipboard |
|
Posted by: robinhoodx Posted on: 2003-05-20 17:54 网上提供了那么的多免费且优秀的UML电子书，看都看不过来。 他那本clearcase书翻译的比较差，所以不敢相信他这本书的水平。 | |
| 5.Re:对使用Together的建议 [Re: jackzhuo] | Copy to clipboard |
|
Posted by: jackzhuo Posted on: 2003-05-21 09:10 我们先不谈那本书怎么样,我所说的其它方面大家是否赞成？ 如果大家感兴趣的话，我想到时候抽时间写一下我们这个项目设计的过程，怎么样？ | |
| 6.Re:对使用Together的建议 [Re: jackzhuo] | Copy to clipboard |
|
Posted by: liwenguo Posted on: 2003-05-22 09:51 欢迎 | |
| 7.Re:对使用Together的建议 [Re: jackzhuo] | Copy to clipboard |
|
Posted by: robinhoodx Posted on: 2003-05-22 10:42 jackzhuo wrote: 好！支持！ | |
| 8.收集业务需求并进行整理 [Re: jackzhuo] | Copy to clipboard |
|
Posted by: jackzhuo Posted on: 2003-05-22 15:41 其实,我觉得我们的整个设计过程就是一个逐步求精的过程. 在开始设计前,我们花了大约两至三个人月的时间,采用use-case的方式,与系统所有相关业务部分的人员进行了讨论。在讨论中,主要是由我和另外一两个分析人员采用引导的方式，将他们脑子中想象的可能做的功能全部表达出来，在这时，我们其实只是起一个引导并整理的作用，很多时候都是业务人员在说，我们几个就是从他们很散乱的语言中抽取出有用的部分，然后按用例图的方式整理成文。在文档中包含了功能的分类、简单说明以及功能的流程图(对于一些不复杂的不需要画流程图)。 整理过程是经过几次沟通的，第一次沟通其实是为我们初步的工作先理出头绪，然后形成文档。再形成文档后，再与每个相关的业务部门沟通一到两次，首先，我们会讲解文档的组织方式以及文档中每个符号的作用，然后再由他们来提意见，这样在第二次以及以后的讨论中就不会无的放矢，能很好地提高工作的效率，也能将业务方面的需求进行很好的整理。 | |
| 9.对系统进行全局的分析 [Re: jackzhuo] | Copy to clipboard |
|
Posted by: jackzhuo Posted on: 2003-05-22 15:55 当需求整理完成后，下一步的工作就是全局的分析工作，主要要做下面几件事： (1) 采用UML中package的方式，将整个系统，按可重用的程度划分为若干个不同的基本包。它表示了系统的大的逻辑框架，在我们的系统中将整个系统分成了三个子系统，在每个子系统中又划分了若干个不同功能的包。 (2) 从需求文档中寻找关键的业务概念(它们可能是相关的实体信息，可能是需求文档中主要的名词)，这些词汇在现在是具有全局意义的，一定不要一开始就划分的太小。 (3) 寻找系统中可能涉及的技术问题，并将它们单独罗列出来，象我们系统中会用到池管理技术、缓冲技术、远程通讯等等(你们可能使用比我们还要多 )。这些技术问题可以称为设计经验(Design Experience)，可以是已经解决的也可以是还没有解决的，但它们都是纯粹的技术问题，将它们划分到一个独立的包上存在，在设计经验的包下，可以给每种设计经验再建立一个包，只起个名字就可以了，因为现在还没有到具体工作时候。(4) 对系统在开发中可能遇到的风险进行分析，如我们的系统中可能会遇到某种交易方式还没有完全确定、将来可能会涉及到大数据库的操作等等风险。做一个表格，以这些风险为行，以需求中可能的用例为列(当然你也可以反过来 )，然后采用打勾的方式，看一下每个用例可能会涉及到什么机关报技术风险，这里你会得到哪几个用例涉及的技术风险最多，一般只需要几个主要的功能用例就可以覆盖大部分的技术风险。到此为止，你就得到了一定的包结构，很多技术经验的列表以及你已经很清楚什么样的用例涉及最多的技术风险。 | |
| 10.对系统进行局部分析 [Re: jackzhuo] | Copy to clipboard |
|
Posted by: jackzhuo Posted on: 2003-05-22 16:06 当全局分析完成后，你已经知道什么样的用例已经涉及到了最多的技术风险，从分析的角度，你不需要对所有用例从一开始就进行分析，只需要抓住重点就可以了。 在开始局部分析以前，从前面全局分析中寻找的一些关键概念，以及你当前需要开始进行分析的功能需求的角度，可以再寻找出一些分析类，分析类的寻找是这样的：基本上每个关键的业务概念可能是一个实体类(Entity)；而在用例图中每一个Actor和UseCase之间的一个连线，就表示一个边界类(Boundary);对于每一个功能一般会有一个控制类(Control)。好找到后，将他们放在一个包中，最主要的是有一个比较好的命名方式。 都做好以后，你可以使用所有这些分析类，将你找到的关键的用例(即覆盖风险最多的几个用例)，使用这些分析类以及用例图中原来就有的Actor，画出针对一个用例的序列图，表达了一个用例的流程。 注意，在做此步时，你不需要考虑与技术相关的问题，也不需要考虑其它用例的情况，你一个时刻只是针对一个用例在进行局部分析。大家可能已经注意到，这样做其实已经屏蔽了很多复杂性，最重要的是通过逐步求精的过程，你会看到，随着工作的不断深入，每一阶段都会解决一些复杂性。这样，所有的复杂性是有条理地解决的，不会说你会忘记我还有什么问题没有解决，因为所有的事情都在计划中了。 | |
| 11.进行全局设计工作 [Re: jackzhuo] | Copy to clipboard |
|
Posted by: jackzhuo Posted on: 2003-05-22 16:17 当分析工作完成后，就开始进入设计，与分析一样，设计也是由大到小的逐步求精的过程，我们也从全局设计入手。 当你在局部分析中通过分析类将某些用例的功能流程表达清楚后，你可能会觉得其实那些图会很简单，对吧，因为我们已经屏蔽了很多的复杂性。 在全局设计中，你首先要做的就是将分析类转化为设计要素，这里存在的是映射的关系，对于一些行为比较简单的分析类可以直接转化成设计类；而对于一些行为比较复杂的分析类，可以转化为接口(Interface)以及子系统(SubSystem)，这也是为了在这个层面上屏蔽复杂性。(其实判断行为复杂不复杂的一个简单方法是在序列图中发到一个分析类的消息比较多可能它的行为就比较复杂，或发到它的消息不多，但一个消息要做很多工作也可以认为它的行为复杂)。 在上面的说明中，子系统会实现相应的接口，而子系统将来会对应我们一个语言上的包的概念(在JAVA中它可能是一个包含很多类的package，在C++中你可以把他们放在相同的名字空间中). 在这个时刻，你也可以去试着画一画系统可能的分布图会是什么样的,这一方面可以使开始小组中的人员都对系统有一个相对比较清晰的全局的认为，也可以以此为一个阶段性的成果向你的老板汇报寻求更多的支持 另外，到了这个时候，你也可以按你们约定的命名规则，对已经完成的所有设计元素的命名进行一个整理，使你的工程更加好看！ | |
| 12.进行局部设计工作 [Re: jackzhuo] | Copy to clipboard |
|
Posted by: jackzhuo Posted on: 2003-05-22 16:24 到了这个步骤，你其实已经有了系统中所有需要进行设计的一个比较完善的列表，在这个列表中包含了很多设计经验的东西需要进行设计或整理；有了一些子系统需要进一步进行细化。那你需要做的，就是将列表中所有的东西设计出来。 例如在我们项目中会使用很多开源的代码，象池呀、缓冲呀等，对于此你只需要说明你会用什么以及你怎么用可能就可以了。而对于一些没有现成的，就需要根据你的经验一个类一个类的设计了，当然经验很重要，一个新手是不可能做系统设计的。不过，需要记住的一点是，这样的设计只是系统中的一部分，它和整个系统是屏蔽开的，所以对这部分的设计只要遵循相同的接口，你就可以多寻找几种方案，然后选一个最好的方案就可以了。 另外，此时，你们的小组可以进行很明确的划分，只需要对照已经完成的列表分配工作就可以了(当然这样说是简单化了，如你们可能需要商定协调沟通的方式等，但这方面的工作你会发现已经很容易做了) | |
| 13.结论 [Re: jackzhuo] | Copy to clipboard |
|
Posted by: jackzhuo Posted on: 2003-05-22 16:27 上面说的这些所有的工作，你可以在ROSE中完成，也可以在Together中完成，这已经与<b>工具</b>无关了。 我们的小组现在工作的非常顺利，而且原来很多不清晰的东西也在慢慢变的清楚。 我就说这么多吧，也挺累了 ，大家如果有什么问题尽管提出来，我们多交流交流！
| |
| 14.Re:对使用Together的建议 [Re: jackzhuo] | Copy to clipboard |
|
Posted by: jackzhuo Posted on: 2003-05-24 10:28 没有人捧场吗  ?中我写的不明白 还是大家根本对此不感兴趣 ?
| |
| 15.Re:对使用Together的建议 [Re: jackzhuo] | Copy to clipboard |
|
Posted by: Julian13 Posted on: 2003-05-24 23:37 thx. should be a very good experience for you. in the sense of OOA and OOD, i guess these process or experience can be abstracted as a development procedure or guideline such that you can avoid to start from scratch next time in new project. ^.^ | |
| 16.Re:对使用Together的建议 [Re: jackzhuo] | Copy to clipboard |
|
Posted by: sothis Posted on: 2003-05-25 16:47 加分鼓励! | |
| 17.Re:对使用Together的建议 [Re: jackzhuo] | Copy to clipboard |
|
Posted by: jackzhuo Posted on: 2003-05-25 17:04 首先谢谢版主! 不过我最希望的是大家能就自己的经验多做交流,到现在我也没有看到大家切实的反馈!我觉得这次工作的经验确实解答了我多年在设计中存在的很多疑惑,也希望能给大家更多的帮助!!! | |
| 18.Re:对使用Together的建议 [Re: jackzhuo] | Copy to clipboard |
|
Posted by: Johnny Posted on: 2003-05-26 13:03 很好，很有用，不过我想问一下，在从设计到实施的过程中如果有比较大的疏漏或者忽略的情况下怎么处理，譬如说忽略了某两个或几个包中的某些联系，这些小的联系往往在设计的初级阶段不会发现，而随着设计或开发的进度才会体现出来，不知道你们项目进程中有没有出现过这种问题，如果有的话如何解决的。因为如果是包内的改变还是比较容易，但这种涉及到几个包的改变处理起来就比较繁琐了，有时候甚至会导致结构的重新设计。 | |
| 19.Re:对使用Together的建议 [Re: jackzhuo] | Copy to clipboard |
|
Posted by: jackzhuo Posted on: 2003-05-26 13:40 采用这种分析设计方式,是从需求出发的逐步求精的过程,在刚开始时,你可能只知道需求相关的东西(当然经验也是很重要的),对此你可以做出只针对业务的一些设计,如某个业务他的处理流程会是怎么样,在这个过程中,如我所写的,有很多关键的实体你可以列出来,而且也可以根据对项目风险的分析,把处理风险对应的一些技术也列出来,可能不全,不要紧! 如我上面所写,每一个步骤(如全局分析,局部分析,全局设计,局部设计,以及以后的精化设计)都会有一个目标,也就是要达到一定的结果,刚开始的时候你不会局限在小的地方,但需要把你在设计中遇到的问题都记下来,这是很重要的!这些只是问题,可能你还不知道怎么解决,没有关系,记下来!!!可以在设计模型中记录所有这些内容,让模型替你记录这些内容.(其实象Together和Rose这样的工具就是为了记录你的模型,他不会替你分析,它的主要工作还是记录!) 这样随着工作的不断深入,你会发现你记录的的内容会越来越全,而最主要的是你的思路会越来越清晰,而且很有可能对于每一个技术问题你会有不止一个的解决方案,没有问题把你的好思路都记录下来(还是让模型替你记录 ),其实这个时候你应该清楚了,经过这样的工作步骤你会发现你很少会遗漏重要的东西,如果有遗漏的话,也是一些锦上添花的东西,还是最重要的一点,小组中不止有一个人,当你发挥大家的积极性以后,不仅技术问题不会出现遗漏,而且整个小组很容易产生凝聚力,象我们现在在分析设计中小组讨论或几个人的讨论是经常会有的.这样你可能最后的很多工作是在若干个方案中寻找一个最好的方案了!
| |
| 20.Re:对使用Together的建议 [Re: jackzhuo] | Copy to clipboard |
|
Posted by: jackzhuo Posted on: 2003-05-26 13:44 还有,象我上面所说的,你在找分析类的时候,会分成三部分:实体类,边界类和控制类,这些所有的类在模型中可以通过构造型来表达,而我认为系统中最容易出现问题的地方是边界,而边界的设计是涉及到两个相关子系统的,这里就更需要整个小组或相关的人员共同来讨论了! | |
| 21.Re:对使用Together的建议 [Re: jackzhuo] | Copy to clipboard |
|
Posted by: Johnny Posted on: 2003-05-26 15:54 非常感谢，需要在实践中好好体会大侠的经典建议 | |
| 22.Re:对使用Together的建议 [Re: jackzhuo] | Copy to clipboard |
|
Posted by: supermy Posted on: 2003-05-27 08:27 9494,关键是流程，如:rup | |
| 23.Re:对使用Together的建议 [Re: jackzhuo] | Copy to clipboard |
|
Posted by: hitdemo2002 Posted on: 2003-06-03 10:27 面向对象的设计方法？这方面的要看一些什么样的书好？？ | |
| 24.Re:对使用Together的建议 [Re: jackzhuo] | Copy to clipboard |
|
Posted by: jackzhuo Posted on: 2003-06-03 13:17 其实我上面介绍的那本书就不错!另外我觉得你可以先看一些有关需求管理和UML基本知识方面的书. | |
| 25.Re:对使用Together的建议 [Re: jackzhuo] | Copy to clipboard |
|
Posted by: bjwulin Posted on: 2003-06-04 15:59 jackzhuo ，向你学习。 | |
| 26.Re:对使用Together的建议 [Re: jackzhuo] | Copy to clipboard |
|
Posted by: njord Posted on: 2003-06-28 03:25 谢谢！ 能花费这么多文字将自己的心得写出来的人是值得尊敬的。 | |
| 27.Re:对使用Together的建议 [Re: jackzhuo] | Copy to clipboard |
|
Posted by: jackzhuo Posted on: 2003-06-28 10:56 谢谢大家的支持! 由于现在我们的项目已经进入了很关键的时候,没有很多时间再写一些文字出来,希望在项目总结时能把更多更好的经验与大家分享! | |
| 28.Re:对使用Together的建议 [Re: jackzhuo] | Copy to clipboard |
|
Posted by: aihua Posted on: 2003-07-24 16:32 厉害！ 钦佩！ 我想我需要反复看了·～～ | |
| 29.Re:对使用Together的建议 [Re: jackzhuo] | Copy to clipboard |
|
Posted by: thincamel Posted on: 2003-08-14 13:04 上面基本上还是RUP的方法，根据不同的项目会有所裁减。Borland购买了Together主要目的是为了形成自己的一套标准现在以ALM出现，不久的将来应该会以BUP（Borland Unified Process）的思想结合现有的ALM 集成的工具。 | |
| 30.Re:对使用Together的建议 [Re: jackzhuo] | Copy to clipboard |
|
Posted by: jackzhuo Posted on: 2003-08-14 18:32 其实我在实际傅种也遇到了一些问题,和thincamel兄讲的差不多,主要原来在于RUP是针对ROSE做的,它更偏向于前期一些,而在于Together则更偏重于稍后期一些,一个很大的不同就是在Together中文件的组织基本上与Java的包结构相同,而Rose就不是这样,所以我们在设计做完转到编码时就出现了一些问题,主要是因为我们在设计时选用的语言不是Java而是选择了与语言无关的Design类型,所以从设计过渡到编码时就不是特别顺利. 不过,Together提供了输出源代码功能,我们在实际使用中就先将模型输出到源代码,然后建立另外一个工程专门用于源代码的处理,虽然解决了问题,但还有不足的地方,就是代码和模型的同步变得比较困难,所以我想等编码告一段落后,回过头来在将整个开发过程总结一下. | |
| 31.Re:对使用Together的建议 [Re: jackzhuo] | Copy to clipboard |
|
Posted by: bbbaby Posted on: 2003-09-04 11:15 支持 | |
| 32.Re:对使用Together的建议 [Re: jackzhuo] | Copy to clipboard |
|
Posted by: stevendu Posted on: 2003-09-27 11:29 jackzhuo, 您的这篇文章对我启发很大，以前做的项目虽然用的都是面向对象的语言，恰恰没有采用面向对象的分析方法，导致做成的项目成了四不像，我准备把最近做完的一个项目采用你讲的这些过程重新过一遍，我觉得这样会增强我面向对象的分析能力，你说是吗？ | |
| 33.Re:对使用Together的建议 [Re: jackzhuo] | Copy to clipboard |
|
Posted by: skyedge Posted on: 2003-09-27 15:37 很好。。收藏起来！我们刚有个新的项目要做，应该可以用到。 | |
| 34.Re:对使用Together的建议 [Re: jackzhuo] | Copy to clipboard |
|
Posted by: sendtome Posted on: 2003-09-27 16:26 非常感谢！ | |
| 35.Re:对使用Together的建议 [Re: jackzhuo] | Copy to clipboard |
|
Posted by: wayan Posted on: 2003-10-06 20:05 其实工具的实现还是要依附于思想的火花 | |
| 36.Re:对使用Together的建议 [Re: jackzhuo] | Copy to clipboard |
|
Posted by: wayan Posted on: 2003-10-09 13:08 个人意见,一个字,就是玄 你们真正的用uml做过项目吗?大哥们,理论上说,你们的构想很流畅,但是在实际的操作中,uml是会要你的小命的.在我领导的项目中,一般用uml交流,但是,还从来没有完整的按照你们的说法做过,为什么,计算一下费用,你们就会知道了. 个人意见,仅供参考 | |
| 37.Re:对使用Together的建议 [Re: jackzhuo] | Copy to clipboard |
|
Posted by: wayan Posted on: 2003-10-09 13:10 项目最重要的是一个核心,一两个牛人,他们可以充分理解和贯彻你的想法,而不是一味去追求uml的纯粹,要记得,uml仅仅是一种语言,不是一个项目的所有 | |
| 38.Re:对使用Together的建议 [Re: jackzhuo] | Copy to clipboard |
|
Posted by: enhydra Posted on: 2003-10-09 21:21 不要成为工具的奴隶. 关键还是方法, 工具只是要来提高工作效率, | |
| 39.Re:对使用Together的建议 [Re: jackzhuo] | Copy to clipboard |
|
Posted by: xp123 Posted on: 2003-12-24 11:34 挺好，正在尝试 | |
| 40.Re:对使用Together的建议 [Re: jackzhuo] | Copy to clipboard |
|
Posted by: hotyaya Posted on: 2004-02-10 15:50 我用下来,它可是个好东西 | |
| 41.Re:对使用Together的建议 [Re: jackzhuo] | Copy to clipboard |
|
Posted by: Wendy0007 Posted on: 2004-04-05 17:13 谢谢分析！！ 正在学习RUP…… | |
| 42.Re:对使用Together的建议 [Re: jackzhuo] | Copy to clipboard |
|
Posted by: Wendy0007 Posted on: 2004-04-05 17:40 感谢分享！！ 学习…… | |
 |
Powered by Jute Powerful Forum® Version Jute 1.5.6 Ent Copyright © 2002-2021 Cjsdn Team. All Righits Reserved. 闽ICP备05005120号-1 客服电话 18559299278 客服信箱 714923@qq.com 客服QQ 714923 |