主持人: 大家好
俎涛: 先来了
俎涛: 呵呵
主持人: hi
他们叫我猫猫: 然后呢？
主持人: 今天活动的主题是《UML与面向对象的分析设计》。
主持人: 主讲是俎涛老师
主持人: 请大家稍等一会，还有一些朋友在加入
xucai: 哦,先提问,还是老师先讲
zhgx: 先问题呀还是先讲呀
zutao: 先问问题
主持人: 先提问
主持人: 我们会留时间给大家提问的
Jonson: UML中的用例圖部分
xucai: 用例图比较easy, 主要用在需求分析
Jonson: 是一個系統前期的大致方向嗎?
Jonson: 也就是系統流程的主要說明
主持人: Hi,大家晚上好！
主持人: 欢迎在线的所有朋友参加我们火龙果软件在2007-9-27日举办的第一场线上活动。
主持人: 本次讲座由UML软件工程组织联合火龙果软件推出
主持人: 目的是为了让大家有一个交流的平台，能够和专家在线直接沟通，交流经验，共享知识，
主持人: 同时，也欢迎每个人把自己的经验在讲座中与参与者分享。同时欢迎您向我们自荐作为在线讲座主讲
主持人: 今天活动的主题是《UML与面向对象的分析设计》。
主持人: 主讲是俎涛老师
主持人: 俎老师是 UML软件工程组织资深技术顾问
主持人: 从1998年基于国家九五科技攻关重点项目子题“特定领域基于构架与构件的软件复用”
主持人: 研究UML与面向对象开始，在多个企业级应用项目中对UML+OOAD有深入的实践
主持人: 目前已经为超过300家软件企业实施过UML&OOAD，设计模式，架构设计，嵌入式系统分析设计
主持人: 需求开发与管理，软件开发过程—RUP相关的培训和咨询，具有丰富的实际经验和理论基础
主持人: 俎老师同时是UML软件工程组织的发起人和火龙果软件的创始人
主持人: 今天的会议共设了三个部分：
主持人: 1. 大家提问，我们会收集6个问题，在会议最后为大家进行解答。（用时5分钟）
主持人: 2. 会议主题讨论（用时35分钟 ）：
主持人: a) 面向对象 　
主持人: b) UML
主持人: c) 需求与UML建模
主持人: d) 面现对象分析与UML建模
主持人: e) 面现对象设计与UML建模 　
主持人: f) RUP中的模型驱动的开发框架
主持人: g) Rose 中的RUP Framework
主持人: 3. 俎老师按照问题的优先级为大家解答问题，同时大家也可以发表自己的意见（每个问题20分钟）
主持人: 不好意思啊，我一个人说了那么多
Jonson: 啊
主持人: 把人都给吓跑了.........
Jonson: 呵呵
xucai: 没,还在
zhy: 呵呵
主持人: 还好
tmworks: HI
zutao: 好
tmworks: 大家好
zutao: 聊天室的超时
主持人: 现在大家提问吧
tmworks: 你们都在说什么啊
zhy: 超时的时间延长一些，可以吗
tmworks: 提问什么啊
zhy: 又怎么了？呵呵
石焱: 怎么老出问题？
zutao: 可以了
xiaoqiu: 面向对象分析 业务用例需要考虑和系统交互么？
zutao: 面向对象 分析要考虑系统交互，业务用例不需要
zutao: 业务用例主要考虑的是业务的场景
zutao: 很高兴在这里能和大家交流
zutao: 我是俎涛
Jonson: 對象的概念?
zutao: 刚才 主持已经介绍了
zhy: 业务场景具体是？
xucai: 问题1.怎样把UML/OO与软件需求分析设计结合的更好?
zutao: 业务场景就是业务中的故事，举个例子：如果我去存钱，业务场景就是把存钱的故事描述出来
zutao: 这就是业务用例
主持人: 记录了
zutao: 刚才有同学问对象的概念
Jonson: 是
zutao: 对象的概念 就是客观存在的，例如一个具体的物体
zutao: 客观存在就是不以我们的意志为转移的
Jonson: 那對於系統的一個角色可以把它看成一個對象
zutao: 现在有一个问题：一个实际存在的表单算不算对象
xiaoqiu: 如果我还想表述业务中需要信息系统来干什么是不是需要系统用例
zhiqiang: 我还是不清楚从用例到概念模型再到类模型的过渡 ？
amigo: 听着像哲学
zutao: 这个可能不是客观存在的
zutao: 因为表单是一种可以被优化的逻辑
zutao: 是的
jack: 什么是元元module?
zutao: 业务中信息系统做什么可以用系统用例表达
zutao: 不过 层次要高一些，可以称之为 ：系统业务流程
xiaoqiu: 哦 那刚才说的那个表就不是对象了 是数据的内容么
jack: 也即meta meta module
zutao: 是，表单是一种经过抽取的对象
zutao: 一种逻辑分析的结果，表单对应的客观的存在的东西才是对象
主持人: 第一步，我们先收集6个问题，然后俎老师讲今天的主题。
zutao: 元 moudle 应该和 元数据 是一样的概念，描述moudle的moudle
xucai: 问题1.怎样把UML/OO与软件需求分析设计结合的更好?
主持人: 请大家继续提问
xucai: 问题2.软件项目在分析/设计应该用哪些UML图?我们知道目前UML中一共有4大动态图,5大静图, 请老师解答,谢谢.
jack: to zutao: 能否举个例子说明下 谢谢了~
zhiqiang: 我还是不清楚从用例到概念模型再到类模型的过渡 ？
zutao: 我不知道这里的moudle指什么
jack: 比如描述一个calss 或者actor
xiaoqiu: 如果我只从业务活动的角度描述业务用例 进行业务活动图制作 和类的提取 信息开发人员能够据此进一步开发系统么
xucai: 问题3.怎样把OO,AOP,SOA三者结合的更好?
zutao: 这样如何
zutao: 大家有个顺序
zutao: 要不有些乱
zutao: 逐个进行
jack: 就是啊
zutao: 有我们的主持把问题列个顺序
zutao: 逐步进行
zutao: 现在开始5分钟，大家先发问题
zutao: 然后关闭问题，一个一个议题讨论
主持人: 我们已经收集了4个问题了
xucai: 怎样把UML/OO与软件需求分析设计结合的更好?
jack: 不过如果能标注字体颜色最好了 这样就可以分开了
xucai: 软件项目在分析/设计应该用哪些UML图?我们知道目前UML中一共有4大动态图,5大静图, 请老师解答,谢谢.
xucai: 怎样把OO,AOP,SOA三者结合的更好?
xucai: RUP中的模型驱动与UML怎样结合会更好,能否给出一个例子?
xucai: 好了,我就这几个问题了
主持人: 除了xucai同志的，谁还有问题呢
主持人: xiaoqiu　也已经收录了
xiaoqiu: 呵呵 谢谢
xucai: 不好意思,我还有一个问题: 软件架构时,怎样用好UML?
主持人: 现在我把收集到问题发上来
猫猫: 嵌入式架构时，怎么更好结合UML和OO？
主持人: xucai: 问题1.怎样把UML/OO与软件需求分析设计结合的更好?
主持人: 面向对象分析 业务用例需要考虑和系统交互么？
主持人: xucai: 问题2.软件项目在分析/设计应该用哪些UML图?我们知道目前UML中一共有4大动态图,5大静图, 请老师解答,谢谢.
主持人: 从用例到概念模型再到类模型的过渡 ？
主持人: xiaoqiu: 如果我只从业务活动的角度描述业务用例 进行业务活动图制作 和类的提取 信息开发人员能够据此进一步开发系统么
zutao: 好
zutao: 我们先讨论第一个问题，
主持人: 我们就第一个问题开始了
zutao: 如何
xucai: 好
xiaoqiu: 好
zhy: 好
猫猫: 好
zhiqiang: ok
z.neil: UML建模工具，能推荐几个好的工具吗？比如VISO EA ，ROSE 倾向哪个？
Jonson: 好
amigo: 同意
zutao: UML/OO在 需求中做好的关键是有一个有效的，和应用者相适应的方法，过程，工具，和模板
zutao: 具体说说方法吧，
主持人: 我们一个一个解决问题
zutao: 需求 中 UML/OO的用途：UML中的用例技术可以让我们通过案例捕获各种场景的需求，
zutao: 活动图可以用来表达业务流程，用例事件流，可以替代传统的数据流图，
zutao: 对象图和类图可以让我们对概念有一个深入的交流和分析，
zutao: 部署图可以让我们对系统未来的形态进行展望
zutao: 需求分析 需要以上的支持
zutao: 实现对业务的深入理解，对系统的充分分析和预测
zutao: 图可以让我们和客户进行专业级的交流，降低一致性
zutao: 不过也要注意一些误区：能够被看懂的图才是有用的
zutao: 能够被人认可的技术才是有效的
zutao: 所以要看看目前项目的客户，团队的UML/OO经验，适度的应用，但是不要偏离问题的核心：不是UML是一个稳健的系统
zutao: 需求完成后，一般会把需求中的概念模型向 分析类影射，
zutao: 然后针对用例进行实现性的分析，
zutao: 分析一般是独立于平台的，
zutao: 关注一个比较通用的软件方案
zutao: 具体应用就是：UML的类图表达领域模型-分析类的聚集体，
主持人: 呵呵，谁还有更好的想法
xucai: 老师,我想问一个问题,您好活动图可以替代传统的数据流图,那活动图和大学时学的程序流程图又有哪些区别呢?我觉得数据流图主要是面向数据流的,活动图则是面向对象的.
zutao: UML的交互图（包含顺序图，协作图，交互概览图，时间图）表达用例实现内部软件对象的交互
zutao: 活动图可以代替数据流图
zutao: 活动图的面向对象特点主要是可以划分职责到对象上
zutao: 可以把交互的数据封装为对象
zutao: 可以代替数据流图，却可以做比数据流图多的事情
zutao: 数据流图不是没有了，而是被活动图代替了，
zutao: 呵呵
主持人: OK
zutao: 不过说到方法，分析的方式有很大的不同
xucai: 哦,谢谢老师
主持人: 别人还有什么不同的看法吗？
jack: 那有没有控制流图呢
zhiqiang: 我插一句：是不是把用例图做成分块的比作成一个全局大图好一些呢？
zutao: 控制流图也是放在 活动图里的
zutao: 用例图的粒度（分块的，全局的）要考虑多个因素：系统的复杂性，人员的习惯，讨论问题的方式和粒度
zutao: 也就是 如何用好东西，也要看当时的工作形式
jack: 这些动态图能不能通过正向工程生成代码呢
zutao: 一般来说，分块每个部分更精细，不过整体感没有了
zutao: 有利有弊巴
xiaoqiu: 每一个用例都有它的活动图么？业务用例呢
zutao: 动态图可以生成代码
zutao: 主要是活动图和状态图
zutao: 用例的活动图表达用例的事件流
zutao: 业务用例的活动图表达业务事件流
zutao: 有些图就是为了表达，并不局限于特定的环节
jack: 有使用步骤么 为什么我只能生成静态图的代码呢
zutao: 有些和环节有关，例如用例
zutao: 那要看工具了
zutao: mda的工具是可以的
jack: 就使用rose工具
zutao: 大家用得最多的是什么图？
zutao: rose不行的
zutao: rose realtime可以的
jack: 一般是类图和活动图还有状态图
jack: 还有时序图
zutao: 呵呵，差不多是UML中最重要的几种图了
zhiqiang: 我画的比较多的是用例图
xucai: Design pattern和UML肯定有很大的关系,比如说状态模式就可用在状态图中,请老师解释一下.
zutao: 好的
zutao: 状态模式是采用类结构分离的策略分离状态极
zutao: 同时对状态作抽象
zutao: 好了
zutao: 第一个问题差不多了吧
zutao: 主持呢
zutao: 第二个问题
主持人: 因为时间关系　我们讨论第二个问题
主持人: 第二个问题：xiaoqiu: 面向对象分析业务用例需要考虑和系统交互么？
zutao: 业务用例分析分为2个阶段，开始的时候不用考虑系统交互，发现自然的业务，在业务搞清楚的基础上，集合系统考虑业务的形式
zutao: 所以业务用例最后还是要考虑系统交互的
zutao: 开始的时候不要，为了发现业务的自然形态，
主持人: xiaoqiu？
xiaoqiu: 那业务用例是不是必须要过渡到系统用例阿
zutao: 业务用例必须要过渡到系统用例
zutao: 不过有些业务用例如果不需要系统支持，不会产生系统用例
xiaoqiu: 我只想从业务的角度描述我门的业务 为了信息人员更好的理解
xiaoqiu: 哦
zutao: 您的意思是业务不需要考虑系统？
xiaoqiu: 但是不能说明系统要为我们干什么啊
zutao: 呵呵
zutao: 要说明的
zutao: 如果用系统支持业务，应该从业务的角度考虑，而不是系统的角度
zutao: 系统为业务服务的
zutao: 否则，这些由谁来定义呢？
zutao: 作系统的人么？角度已经不是合适的了
xiaoqiu: 呵呵 我以前没有学过信息的东西 就是想从业务角度说明用系统支持
jack: 那什么时间可以从系统用例考虑?
zutao: 业务的内容很多
zutao: 系统不会支持业务的所有，所以要定义清楚业务的系统范围
zutao: 这是业务分析的关键之一
xiaoqiu: 哦 最终还是要系统用例说明阿
xiaoqiu: 哦
zhiqiang: 我认为先应该从系统级别上考虑用例，再深入讨论。。。 难道我错了？ 请老师指教
zutao: 例如我去买东西，经历的事情非常多，我希望能够买个便宜的，这是业务，系统如何支持
xiaoqiu: 从业务中提取出系统支持的东西来
zutao: 有很多的可能性，
zutao: 这些要在业务分析的时候定义好的
zutao: 从哪里开始，也要看做的什么系统
xucai: 那什么时候从系统用例出发呢?
zutao: 如果是业务管理系统，一般要从业务开始，但是如何系统已经初步存在了，只是维护升级，系统结合更多
zutao: 如果是做一个聊天室，有2种可能，看一个聊天室的demo
zutao: 然后从系统的角度考虑需求
zutao: 或者分析 自然中人们聊天的场景，建立一个纯业务的业务需求，然后考虑系统如何定义
zutao: 2种方法都可以
zutao: 第一种高效，但是不深入
zutao: 第2种深入，但是对人要求较高
xiaoqiu: 哦 业务活动中不会涉及查询，登陆之类的活动吧 有时候业务用例会合系统用例混淆阿
jack: 什么时间可以从系统角度考虑需求? 什么时间可以从需求来考虑系统? 这两个谁起主要作用?
zutao: 业务中不会涉及纯粹系统特性的东西
zutao: 因为业务中不存在阿
zutao: 是从系统角度考虑需求，还是从业务，是2种策略
zutao: 都可以
zutao: 要康项目的特点和条件
xiaoqiu: 哦 具体到一个下通知的业务用例会有哪些活动呢 感觉只是一个单一的活动
zutao: 系统经验丰富，可以直接从系统考虑，业务经验不丰富，可以找个类似系统分析需求
zutao: 如果业务经验丰富，又有从业务导系统的技能，可以从业务开始，
zutao: 本质来说，从业务开始好
zhiqiang: 嗯，同意老师的观点
yughua: 业务需求是指跟客户沟通得到的需求?
jack: 但现在有些公司就的需求部门不懂系统 这怎么办呢?
zutao: 下通知 这个业务用例太小了，
zutao: 业务用例最好代表几个业务角色的交互
xiaoqiu: 啊 ？指挥协调呢？
jack: 也就是说需求设计人员不懂系统相关的知识
xiaoqiu: 呵呵
zutao: 业务需求并不单指和客户沟通的需求
zutao: 和客户沟通的需求叫涉众请求，也可能包含系统性的要求
zutao: 业务需求是指为了实现业务目标，希望系统支持的业务内容
zutao: 业务角色的交互 不见得是指挥协调，可能是一个触发器，例如 有人来买东西了
xucai: 现在很多情况是, 用户需求往往置后于实际需求,那有什么更好的解决办法吗?
zutao: 需求人员如果不懂系统的知识，应该说难以建立高质量的需求，需求不但是愿望，也是一种实现的承诺
xiaoqiu: 事件发生了 管理人员需要通知有关部门 指挥协调
s: ?
zutao: 也可能不是管理人员通知的，我们去商店买东西，经理并没有协调每个业务，不过经理的确建立了一个业务规则
xiaoqiu: 这不是一个单一的业务活动，不像类似取款的系统
主持人: OK　大家针对这个问题还有什么意见？
zutao: 用户需求滞后于实际需求，是因为用户看不到东西，也不知道说什么，所以要尽早然用户理解系统的含义
xiaoqiu: 继续下一个问题吧 不耽误大家时间拉
zutao: 业务有2个级别，规则和具体的协调，二者可以存在一个即可
主持人: 好的
yughua: 老师的意见是尽早做出个原型出来?
zutao: 规则可以作为一个协调的指挥棒
主持人: 那接下来我们进行第3个问题：怎样把OO,AOP,SOA三者结合的更好?
zutao: 是的，尽早原型
主持人: 每个问题20分钟
主持人: 希望大家能理解，因为时间有限
xucai: 嗯
jack: ok
zutao: OO是一种分析自然业务到系统的好的方法
zutao: AOP是一种切面构建系统的逻辑分割策略
zutao: SOA是一种按照服务组织架构的体系架构及其规则和环境
zutao: 如果做项目，贯穿始终应该是OO，重点也是OO
zutao: AOP可以认为是一种可选的分割系统的设计技术
主持人: 大家有什么好的想法
zutao: 虽然也说面向用例的切片
zutao: 不过那和面向对象没有什么本质的不同
zutao: 如果进行SOA,那业务分析中对业务的分解，业务服务粒度的把握可以和OO的业务分析结构起来
zutao: 大家有什么看法么
zutao: 一家之言，不要笑啊，呵呵
yughua: 没有,只是对aop不熟悉
jack: 恩
yughua: 只用过oo
yughua: soq
yughua: soa
jack: 还不太知道简写是什么呢
主持人: 行，那么我们换下个话题
yughua: 别换呀,越是不知道的,越值得学
主持人: 问题4　xiaoqiu: 如果我只从业务活动的角度描述业务用例 进行业务活动图制作 和类的提取 信息开发人员能够据此进一步开发系统么
zutao: 开发人员 应该说如果只是看到了你所描述的业务，是不知道如何进行系统的构造的，因为没有从系统的角度进行约束
yughua: 我觉得不能据此进一步开发系统
zutao: 就像你说你要 用这个房间作厨房，可以炒菜，做饭，烧水，
zutao: 一个施工人员是不知道如何施工的
zutao: 必须要有系统的明确的约束
xiaoqiu: 哦
zutao: 这个约束如果单纯让开发人员定义，应该说期望不对
jack: 约束就该需要用例图
yughua: 老师再把这些约束说的更细致点
xiaoqiu: 是啊 系统人员可能不了解某专业的问题
zutao: 需求应该给出系统明确的约束：功能支持那些，用户使用功能的体验（UseCase），系统的界面原型，系统未来的逻辑业务部署，
jack: 恩 支持
zutao: 系统的非功能性需求：可用性，可靠性，可支持性，性能，接口需求，物理需求，设计约束，实施需求
yughua: 哦,好
xiaoqiu: 系统开发人员是怎么和专业人员捕捉需求的？从他们的描述中自己设计么
zutao: 约束越细越好，不过也要约束对，不要约束了，范围成为了枷锁
zutao: 如果 模棱两可的地方，可以和开发人员，可以一起探讨
xiaoqiu: 哦
jack: 我觉得就像画一个长方形一样 没有长和宽 随意性比较大的
zutao: 系统开发人员首先自己整理清楚系统需要的约束
zutao: 然后主动地向业务人员获取
xiaoqiu: 哦 那业务活动图也没有说明系统做什么啊
zutao: 就像你要吃饭，我就会问你，想吃什么，咸的还是甜德，热得还是冷得
zutao: 可以在业务活动中表示系统的支持范围
jack: ok, 明白了 下一个~~
xiaoqiu: 哦 这样也可以阿
zutao: 呵呵，只要工作需要，能抓着好自己的就是好猫
主持人: 呵呵，别人还有什么疑问吗？
zutao: zutao: 呵呵，只要工作需要，能抓着耗子的就是好猫
yughua:呵呵
yughua: ok
主持人: NEXT?
jack: go on
主持人: 问题5　xucai: 软件项目在分析/设计应该用哪些UML图?我们知道目前UML中一共有4大动态图,5大静图
zutao: 首先纠正一下：UML目前的标准是2.1，有13种图
zutao: 一般分析中用的图：领域模型+参与类关系（类图）；关键逻辑：状态图，活动图；用例分析：交互图，
主持人: 有关这些图可以参考：http://www.uml.org.cn/oobject/OObject.asp
zutao: 设计中用的图：物理结构-组件图，分布结构-部署图，多任务：进程类图+进程状态图；设计类-类图；用例设计-交互图；
主持人: 对于每种图，我们整理了一些文章，希望对大家有帮助
zutao: 子系统设计-包图/类图
jack: 没有发现进程类图的使用啊
zutao: 13种图:6种静态图，7种动态图
zutao: UML2.0以后新增的图：交互概览图，时间图，复合结构图，包图
xucai: 哦,增加了这么多图啊
zutao: 如果要建立数据模型，类图是一种扩展
zutao: 是啊
jack: 数据库?
zutao: UML在不断完善，修订，虽然还有很多不足
zutao: 不过软件行业需要设计语言，
zutao: 是的
zutao: 数据库设计可以用类图的profile
zutao: profile是UML的扩展机制
zutao: 能够扩展的语言才有生命力
zutao: 语言应该能够适应环境的变化
jack: 能对uml的扩展机制多说点么
jack: 对这块不是很清楚
zutao: UML的扩展机制：构造型，标签值，约束，注释
zutao: 刚才说的属于构造型，
xucai: 老师能讲一下,UML中对高级行业的建模吗,如事件和信号,状态机等
jack: 哦 好象uml手册里面有
zutao: 是的
zutao: 时间和信号的建模
jack: 还没怎么看 呵呵
zutao: UML里面就有signal
zutao: 也有event
zutao: 非常适合
zutao: 可以说是强项，很多协议状态都使用状态图表达的
zutao: 我这里有个sip协议手册
zutao: 好多状态机
xucai: 抽象一些,比UML1.1中多了好多东西
jack: uml中的状态机和Petri网里面的状态机有没有什么类似的地方?
zutao: 信号和事件在状态图里都是非常重要的元素
zutao: 理论原理一样
zutao: UML的状态机就是状态机的专业图形表达
zutao: 其实UML中最重要的图之一 就是状态图
jack: 但Petri网里面好象有中间状态啊
zutao: UML也有阿
zutao: 你说的中间状态指什么
jack: 就是从状态1转移到状态2的过程中的一个状态
zutao: 汇聚，分支，是这些么
zutao: UML状态图也可以表达
zutao: 应该算作汇聚
jack: 恩 感觉差不多
主持人: 这个问题大家觉得差不多了吗
jack: ok
zutao: 或者如果是一个状态，单独增加一个状态，定义为 XXing
主持人: 第6个问题为：? 猫猫: 嵌入式架构时，怎么更好结合UML和OO？
zutao: 嵌入式架构的特点：分布性，实时性，多任务，硬件驱动
主持人: 猫猫还在吗？
jack: 一般嵌入式不都是采用c语言实现的么 oo的基本上是应用层才用到的
zutao: 首先说嵌入式的层次框架
zutao: c 语言也可以，有面向对象的c语言，面向对象首先是一种分析设计方法，实现技术可以有很多技巧的
zutao: 应用层，中间层，驱动层
zutao: 应用层可以采用oo的设计方法，建立面向对象的应用逻辑，例如 电机，基站片区，
zutao: 驱动层可以采用oo的设计方法，对硬件驱动进行封装，例如：Lcd，flash，port
zutao: 中间层，一般是处于应用层和驱动层之间，建立一个面向类似所有应用的基本api封装，或者容器
主持人: 别人的想法呢
zutao: 中间层的oo概念取决于应用层和驱动层的对接点，在这个层次上提炼一些关键概念，具备很好的通用性，例如:player
zutao: cell
zutao: 刚才说的是层次，
zutao: 还有多任务与实时性，可以采用uml进行任务的结构设计，参照一些实时系统设计模式，同时采用状态图进行任务状态设计，处理好人物的并发于同步
xucai: RUP的模型驱动开发和这里的驱动层有什么联系吗?
zutao: 分布型设计，可以采用复合结构图，定义各个part（分布式运行实例）之间port和connector
jack: 没有什么联系吧
zutao: 以及在port上面提供或者请求的接口
zutao: 这里的驱动开发是指封装设备的驱动层
zutao: 就是安装一个硬件的时候安装的驱动程序的封装
zutao: 大家可以发发言
zutao: 说说看法或者问题
zutao: 热闹一下，呵呵
主持人: 对
xucai: 嗯,老师能介绍一下RUP的模型驱动开发吗?
zutao: 好的，
zutao: rup的模型驱动开发 就是在各个阶段把模型作为分析，设计，文档化，和交流的核心
zhiqiang: 切入式不了解，不过port 和提供接口及请求接口，我倒是想知道多一些
zutao: 具体是用例驱动的
xucai: 您提到的模型与UML中的模型是一样的吗?
zutao: 需求的时候 捕获用例，分析：分析用力，设计：设计用例；实现：实现用例，测试：测试用例
zutao: uml是一种表达机制，更倾向于13种图的定义
zutao: rup里面的应该是图的组合体，例如：用例模型是用例图，活动图，交互图的组河图
zutao: 分析模型是：类图，交互图，状态图，包图的组合体
zutao: rup的模型更倾向于一个工作的结果，而不是一种表达角度
zutao: 可以是多个角度的表达一个工作的结果
xucai: 哦
zutao: 时间差不多了
主持人: 我们的时间不多了
zutao: 大家可以自由提问了吧
jack: 包图里面是不是可以有多个其他的图吧 一个包图里面应该算一个命名空间吧
lavalava: 能比较一下rup和xp吗
jack: ?
zutao: 包图示逻辑的容器，里面可以有包和其他的元素
xucai: Rose我用过,Rose 中的RUP Framework不是太了解,老师能介绍一下吗?
zutao: rup是一种注重工程各个方面结合的过程，所以规范看起来有些“重”
zutao: 其实可以剪裁的非常敏捷
zutao: xp更像是一种开发人员的过程视图，
zutao: 比较直接，贴近开发人员的工作，容易引入，
zutao: 好的过程，应该是能够被很好启动和运用的过程，也就是不要很难，
lavalava: 是啊！rup太重了，那如何去敏捷了
zutao: 从这点来说，rup的剪裁非常关键，如果不当，反而适得其反，不过如果要长久发展，需要一个更完善的框架
zutao: 火龙果现在再推自己的过程：myprocess
主持人: http://www.uml.org.cn/newumltrain/kecheng/process/myprocess.asp
主持人: 大家可以看看这个图
zutao: 注重 从我做起，
zutao: 建立自己可以掌控和过渡的过程
zutao: 过程改进需要以我为主，结合先进的理论
zutao: 从这点来看，比较赞成结合rup和xp
主持人: 别人有好的过程改进方法吗
主持人: 大家一块讨论讨论
zutao: rose 中的rup framework是 把rup中的模型建立了一个rose 包模板
zutao: 提示要建立的组织方式和内容
zutao: 我想听听大家的看法：UML如何
zutao: 说说自己的客观体会
zutao: 呵呵
xucai: 我觉得过程改进可以依照CMM3级要求软件过程定义,还有就是建立软件项目质量评估体系
zutao: 恩
zutao: cmmi是挺好的改进指南
zutao: 就是帽子有些大
xucai: 嗯
zutao: 过程改进可以由2个角度：别人（cmmi，rup，xp）-我，
xumingxsh: 能不能在哪儿找到今天交流的文本。我今天有事，没能准时参加。
zutao: 我 到 别人 - 别人（cmmi，rup，xp）-我，
zutao: 其实最重要的是，能够在自己逐步改进，逐步见效的方式下 不断改进
zutao: 改进不是一场革命，改进更像是一个自我的演化
主持人: 明后两天
主持人: 我们会整理出来
主持人: 放在www.uml.org.cn上面
lavalava: uml个人觉得，用他画太费事件，还不如敲代码快
主持人: 会在首页放链接的
zutao: 革命的风险太大了，有很多的反动势力，哈哈
zutao: lavalava说的很对，
zutao: uml不是目的
zutao: 不能认为uml代替代码，uml关注分析和设计
zutao: 他的价值在于把实现与 分析设计分离，
zutao: 但是如果我是一个实现人员，uml不应该是总是挂在嘴上的一个装饰
zutao: 时间差不多了
xucai: 嗯,谢谢老师
主持人: 今天我们就讨论到这吧
主持人: 感谢大家的参与，欢迎大家对我们的讲座提意见。
zutao: 不客气
lavalava: 谢谢
zutao: 希望大家多参与到今后的技术活动中来
lavalava: 辛苦了
zutao: 一起成长，
主持人: 大家有什么意见可以在UML@UML.NET.CN的群里说，也可以给我发邮件：XLL@UML.NET.CN
zutao: 呵呵，我也要吃饭去了，大家都饿肚子呢叭
主持人: 也谢谢俎老师的讲解。欢迎大家参加10-18号的讲座《协同产品开发（CPD）简介》
主持人: 祝大家国庆愉快，see you next time.
zutao: ok
zutao: 88
xucai: see you!
Bingo: see you next time
主持人: 大家　88！