群组技术交流活动---UML与面向对象的分析设计

火龙果软件工程技术中心 报名咨询热线: 北京 010-62670835 上海 021-50800371 深圳 15801587207

时间: 北京时间2007年9月27日(周4)晚上18:00-20:00  

嘉宾: UML软件工程组织技术专家

相关资源:

   电子书:UML模式应用
   特惠课程:UML分析设计
   技术资源:UML应用基础工具
   相关课程:UML+OOAD

交流范围记录:

主持人: 大家好
俎涛: 先来了
俎涛: 呵呵
主持人: 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!

最新公开课计划

成功案例
某航空IT部门 业务分析与业务建模
联想 业务需求分析与建模
北京航管科技 EA工具与架构设计
使用EA和UML进行嵌入式系统分析
全球最大的茶业集团 UML系统分析
华为 基于EA的嵌入式系统建模
水资源服务商 基于EA进行UML建模
更多...   
 
 
 
 
 

相关培训课程

面向对象的分析设计
基于UML的面向对象分析设计
UML + 嵌入式系统分析设计
关系数据库面向OOAD设计
业务建模与业务架构
使用用例进行需求管理