《OO技术与UML结合的实践》由会员分享，可在线阅读，更多相关《OO技术与UML结合的实践（41页珍藏版）》请在金锄头文库上搜索。
1、1OO技术与技术与UML结合的实践结合的实践Frank12议程议程1.OO技术与CMM流程的初步融合2.在推行实践中的具体问题分析和解决措施 3.OO分析设计案例4.总结和展望 23背景背景我们的技术、业务、人员都在不断变化，因此软件过程也必须不断改进自身与之相适应；面向对象的软件开发技术与CMM流程的融合过程在流程改进方面具有典型意义；过程过程(CMM)人人技术技术(OO)34早期状况早期状况多年来，面向对象(OO)技术的已经成为软件开发技术的主流，在很多地方得以应用实践。 另一方面，很多公司力推CMM软件开发流程，使软件开发过程的能力成熟度得到逐步的提高，为产品质量的提升提供了有力的保障。
2、 大部分公司在CMM流程的最初制定过程中，都要引入了一套软件需求规格、概要设计、详细设计等模板以及配套的指导书和Checklist，大部分是适用于结构化的软件开发方法的。45早期问题早期问题因此在执行CMM开发流程的过程中，出现了用结构化的文档模板来描述面向对象的分析设计方案的情况，带来了不少问题：在面向对象的需求规格描述、设计实体描述方面，各项目组出现了各种五花八门的、写法各异的文档；开发人员苦恼于分析设计方案得不到很好的表达；影响了交付件质量，并对检视和指导下一步开发造成了障碍；一些公司没有推行CMM之前，这种情况就已经存在，而CMM的推行暴露了我们的技术方法不统一带来的弊端。56解决问题
3、的总体思路解决问题的总体思路分析OO技术在CMM中应用的具体范围：需求分析的模板、指导书、Checklist；概要设计的模板、指导书、Checklist；详细设计的模板、指导书、Checklist；OO技术方法的选择：UML表示法；OO工具的选择：Rational Rose已大量采用，但是在纳入流程方面存在一些限制，如价格、license、标准化，工具与流程方法的兼容等等。67解决问题的具体方案解决问题的具体方案在需求规格描述中引入了Use case模型；在概要设计中，基于原有的分层架构模型，引入UML的分包/子系统表示方法；引入类(Class)作为概要设计的基本设计元素；详细设计的基本设计元
4、素是类的方法(Method)；UML的顺序图、交互图等大量用于需求和设计的动态建模。78实践中的问题 任何流程和技术的初次应用都会有一个磨合的过程，面向对象开发方法引入到CMM以后也是如此，各种应用问题很快涌现：首先，开发人员普遍希望有一套范例来指导大家写作分析设计文档；其次，通过与若干项目的交流和参与检视，发现各项目的设计文档交付件水平参差不齐，典型的问题如：需求规格的系统边界定义不清楚 ；架构方面的分层设计表达不清晰、不完整；软件模块与业务流程的实现关系表达不清晰、不完整；设计类与模块功能的实现关系表达不清晰、不完整；详细设计的粒度不一致；接口描述的方式不统一 ；某些设计要素如性能需求、软
5、件质量特性等，容易被开发人员忽略。89文档范例问题解决文档范例问题解决解决办法：开展优秀OO分析设计文档评选的活动；在此基础上，经过裁剪、修改，完成了一套OO分析设计文档范例，范例的推出，使OO套件在对实际开发的指导作用上迈进了一大步；OO工程组又对模板、指导书也进行了适当的优化，而培训材料更做了较大的优化，实例更加丰富了，问题针对性也更强了。910总结总结优秀需求文档特点优秀需求文档特点用例模型完整清晰，说明了用例之间的关系;除了基本事件流描述，还有详细的备选事件流描述；用户接口部分给出了界面原型图和规范的界面说明； 需求的分包概念比较清楚；性能需求和软件质量特性考虑比较全面；用例的前置条件
6、和后置条件能够区分出状态而不是事件；软件接口描述的格式和语法很规范；1011总结总结优秀设计文档特点优秀设计文档特点0层设计清楚说明了系统与外部实体的关系 业务流程说明全面而清楚，并且与一层模块划分的逻辑关系比较清晰；二层设计的设计类分解与功能实现说明的逻辑关系清晰；有完整的组件视图和进程视图；详细设计伪代码描述的逻辑清楚，详细程度适中，对编码有指导意义。1112案例案例下面通过几个案例，说明在软件二部的项目级OO分析设计实践中出现的典型问题和解决措施：1.Actor设计案例；2.平台二次开发接口设计案例；3.详细设计案例；4.增强开发/小特性设计案例；5.分层接口设计案例；1213Actor
7、设计案例设计案例REQ-TC-SM-002 输入经纬度坐标Use case描述Goal in Context 简要说明用户在创建网元、子网或者修改网元、子网时可以输入经纬度坐标Preconditions 前置条件无End Condition 后置条件Success End Condition 成功后置条件 对象在指定的经纬度坐标处显示。Failed End Condition 失败后置条件 无Actors 用户Trigger 触发条件无Basic Flow 基本事件流描述Step 步骤1、用户执行创建、修改网元或者子网的操作2、用户输入对象的经纬度坐标3、下发命令到后台4、拓扑前台收到事件，在
8、指定的经纬度坐标处显示 对象Alternative Flows 备选事件流2a、如果输入的经纬度无效，则提示“请重新输入”3a、如果命令发送失败，则前台保持现状1314平台二次开发接口设计案例平台二次开发接口设计案例问题：平台的二次开发接口在问题：平台的二次开发接口在SRS中如何描述？二次开发接口需求的中如何描述？二次开发接口需求的actor如何如何定义？定义？经过分析，目前比较常见的平台二次开发接口是类继承方式：产品应用平台1415平台二次开发接口设计案例平台二次开发接口设计案例指导原则指导原则1.原则是在接口处描述需求，在Use case描述中，产品应用模块是Actor，平台是目标系统，应
9、用模块是以平台的抽象类（或者代理）的形式出现；2.在Use case的事件流中，基于平台提供给应用模块的一个完整的接口功能，描述平台与应用模块的接口交互过程；3.所有平台二次开发接口都应该在SRS的Use case特殊需求或者集中在软件接口需求中说明具体的接口参数；4.在Use case特殊需求中，应说明抽象类的属性和方法的原型，作为此需求实现的约束；5.避免把二次开发的开发人员作为Actor、把编程活动作为事件流。1516平台二次开发接口设计案例平台二次开发接口设计案例需求描述需求描述用户操作的用例二次开发接口用例1617平台二次开发接口设计案例平台二次开发接口设计案例需求描述需求描述3.3
10、.3 R.FUNC.RTDBG.102 处理查询版本请求Use case描述1. Goal in Context 简要说明应用模块需要实现本模块的版本查询，即用户输入命令查询当前模块的版本信息时，通知应用模块需要处理此请求。2. Preconditions 前置条件应用模块正确使用动态调试框架。3. End Condition 后置条件Successful End Condition 成功后置条件：返回成功。Failed End Condition 失败后置条件：返回失败。4. Actors 应用模块5. Trigger 触发条件由用例R.FUNC.RTDBG.005 查询当前模块版本信息触发
11、。6. Description 基本事件流描述Step 步骤1、由R.FUNC.RTDBG.005 查询当前模块版本信息用例使用此用例，本用例开始；2、向应用模块查询版本信息；3、如果查询成功，显示版本信息，否则执行备选事件流3a；4、提示操作符，等待用户进一步操作，本用例成功结束。7. Extensions 备选事件流Step 步骤3a 查询信息失败3a1 输出错误提示，转向执行基本事件流4；1718平台二次开发接口设计案例平台二次开发接口设计案例需求描述需求描述Use case：处理查询版本请求处理查询版本请求特殊需求：特殊需求：本功能是平台提供给应用模块的二次开发接口，通过平台提供一个基
12、类，应用模块继承基类并重载接口方法的方式来实现，基类的原型如下：class PlatformClass1() public: operation1(); /查询版本信息接口方法1819平台二次开发接口设计案例平台二次开发接口设计案例需求描述需求描述REQ-TC-SM-003 二次开发者扩展查询条件二次开发者扩展查询条件1、Goal in Context 简要说明简要说明公共拓扑前台不可能实现所有的查询条件，但是产品需要根据特殊的条件来进行查询，而公共拓扑没有这些信息，因此需要公共拓扑提供可以扩展的手段以便产品可以提供自己需要的查询条件。2、Preconditions 前置条件前置条件无3、En
13、d Condition 后置条件后置条件Success End Condition 成功后置条件 无Failed End Condition 失败后置条件 无4、Actors 二次开发者5、Trigger 触发条件触发条件 无6、Basic Flow 基本事件流描述基本事件流描述Step 步骤1、二次开发者根据公共拓扑提供的扩展接口提供自己的编程实现7、Alternative Flows 备选事件流备选事件流无不好的例子！不好的例子！1920public AsnObjectTag objIdtof() AsnObjectTag tag = new AsnObjectTag(); for( in
14、t i = 0; i = 3，则属于关键方法（具有多重选择的case语句作为例外，不予以考虑）。简化判断方法：如果循环语句、条件语句之间存在一重以上嵌套，则V(G) = 3, 如例3。详细设计指导原则什么是“关键方法”？2324详细设计指导原则2425详细设计指导原则从ODC分析中发现，详细设计的指导原则有必要进一步优化，有一些代码只有很少的语句，但是反映重要的设计逻辑，也应该在详细设计中定义。2526问题：在实际开发过程中，许多项目都不是全新开发，而是在原问题：在实际开发过程中，许多项目都不是全新开发，而是在原有系统上进行增强或小特性的开发；有系统上进行增强或小特性的开发；增强开发/小特性的
15、需求可以单独描述，但是概要设计与原有系统的概要设计有很强的相关性，面临设计文档如何保持一致性、完整性，同时又避免重复描述设计的问题。对此，总的指导原则是：对此，总的指导原则是：对增强开发/小特性，首先应该在原有的设计文档上直接修改，并与配置管理相结合来实现对设计变更的控制；如果确实无法在原有文档上修改的，才容许单独写新的设计文档，并且应遵循模板中对增强开发/小特性的编写建议。增强开发/小特性设计案例26273.1System Architecture系统结构系统结构如果本文档是针对增强开发/小特性的设计，继承了原有的系统结构，那么应拷贝原有的系统结构说明，如系统结构图和相应的文字说明，然后在一
16、层设计中明显标识出新增功能在原有系统结构中的位置（属于原来哪一个模块的新增功能，与原有各模块之间有什么交互）。在后续的业务流程说明、模块分解描述、依赖性描述和接口描述中，如果与本次增强开发/小特性无关的，可以不再重复描述，如果有关联的，应该拷贝原有的设计说明，在此基础上再说明更改的内容。4.1Module Name (1) 模块模块1名称名称如果本文档是针对增强开发/小特性的设计，继承了原有的二层模块结构，那么那么应拷贝原有的模块结构说明，如包图/类图和相应的文字说明，然后在二层设计中明显标识出新增功能在原有模块结构中的位置（属于原来哪一个子模块/设计类的新增功能，与原有各子模块/设计类之间有
17、什么交互）。在后续的功能实现说明和设计类定义中，如果与本次增强开发/小特性无关的，可以不描述，如果有关联的，应该拷贝原有的设计说明，在此基础上再说明更改的内容。 对更改的设计类应该给出类的完整定义，再标识出更改的属性和方法。增强开发/小特性设计案例编写建议在在DVP05T06-High Level Design (OO method)模板中模板中2728问题：问题：在软件需求规格和一层设计中，都存在接口的描述，在软件需求规格和一层设计中，都存在接口的描述，两者有何不同，如何描述？两者有何不同，如何描述？REP01T02-Software Requirements Specification (
18、OO Method):5 Interface Requirements 接口需求 5.1 User Interface 用户接口5.2 Software Interface 软件接口 DVP05T06-High Level Design (OO method):3Level 1 Design Description第一层设计描述 3.4 Interface Description接口描述 分层接口设计案例28291、系统外部接口（0层）如图所示的Interface-S1S2，属于系统外部接口，这样的接口应该在系统System1的SRS中作为需求来说明，属于软件接口需求，在软件接口需求中应该详细
19、说明接口参数。分层接口设计案例分层接口设计案例29302、系统内部接口（一层）如图所示：接口Interface-M1M2，属于系统内的模块间接口，应该在HLD的一层设计中的接口描述部分说明，同样，在此应该详细说明接口参数。分层接口设计案例分层接口设计案例30311）如果模块接口Interface-M2S2完全实现了系统接口Interface-S1S2，那么对Interface-M2S2不需要再描述，只需要说明Interface-M2S2实现了Interface-S1S2既可；2）如果模块接口Interface-M2S2只是部分实现了系统接口Interface-S1S2，那么两者的接口参数应该各
20、自独立描述，并且在Interface-M2S2的描述中应说明与Interface-S1S2的实现关系。分层接口设计案例分层接口设计案例3132软件设计的七个基本原则软件设计的七个基本原则第一原则：存在的理由 一个软件系统存在的理由就是：为它的用户提供价值。你所有的决定都取决于这一点。在指定一个系统需求，在写下一段系统功能，在决定硬件平台和开发过程之前，问你自己一个问题，“这样做会为系统增加价值吗？“如果答案是”yes”，做！如果是”No”,不做！第二原：则能简单就简单 软件设计不是一个轻描淡写的过程。在做任何一个设计时，你必须考虑很多因素。所有设计应当尽可能简单，但是不要再比这简单了。这样产生
21、的系统才是可以理解和容易维护的。确实很多更优雅的设计往往更简单。事实上，简单是通过许多思考和一次一次的反复修改才达到的。这些努力的汇报就是更容易维护，代码错误更少。 3233第三原则 ：保持远见 清晰的远见是一个软件项目成功的基础。没有这样的远见，项目开发最后就变成天天为一个不好的设计做补丁。概念的完整性是系统设计中最重要的问题。 只有当你对系统的体系由一个清晰的感觉，才可能去发现通用的抽象和机制。开发这种通用性最终导致系统更简单，因此更小，更可靠 如果你不断地复制、粘贴、修改代码，最终你将陷入一个大泥潭(the Big Mud),你永远不可能对系统有一个清晰的认识。 第四原则：你制造的，别人
22、会消费 软件系统不是在真空中使用的。其他人会使用、维护、文档你的系统。这依赖于对你系统的理解。所以，你设计、实现的东西应当能够让别人理解。要记住，你写的代码并非只给计算机看，你要时时记住，代码还要给人看。如果到处泛滥似是而非的代码，别人如何能够辨别这些代码的相似和不同，如何去理解这些代码之间具有何种关系。 3334第五原则：对将来开放 一个成功的软件有很长的生命期。你必须能够使得软件能够适应这样和那样的变化。所以，一开始就不要软件设计到死角上去。请总是问一下自己“如果这样，那么。？“这个问题，你要考虑到各种各样的可能性，而不光光是图省事。复制，粘贴一下即可。 第六原则：为重用做好计划 软件模式
23、是重用计划的一种。不断重复的代码显然不是这样的计划。 第七原则：思考！ 在采取任何动作之前首先做一个清晰、完整的考虑，这样才能产生更好的结果。如果你考虑了，但还是产生错误的结果，那么这种努力也是值得的。在你学习或研究类似的问题时，更容易理解和掌握。 3435重复代码出来优化方法重复代码出来优化方法1 同一个类的两个方法中有相同的表达式,使用Extract method，然后大家都调用该method; 2 两个兄弟子类之间有相同的表达式，那么在这两个子类中使用Extract Method,接着使用pull up field,移到共同的超类 3 如果结构相似而并非完全相同，用Extract met
24、hod把相同部分和不同部分分开。然后使用form Template method. 4 如果方法使用不同的算法做相同的事情，那么使用substitute algorithm 5 如果在两个不相干的类中有重复代码，那么在一个类中使用Extract class，然后在其他类中使用该class对象作为元素。 3536 class Invoice. String asciiStatement() StringBuffer result = new StringBuffer(); result.append(“Bill for “ + customer + “n”); Iterator it = ite
25、ms.iterator(); while(it.hasNext() LineItem each = (LineItem) it.next(); result.append(“t” + each.product() + “tt” + each.amount()+“n”); result.append(“total owed:” + total + “n”); return result.toString(); String htmlStatement() StringBuffer result = new StringBuffer(); result.append(“Bill for ” + c
26、ustomer + “ ”); result.append(“”); Iterator it = items.iterator(); while(it.hasNext() LineItem each = (LineItem) it.next(); result.append(“ ” + each.product() + “ ” + each.amount() + “ ”); result.append(“ ”); result.append(“total owed:” + total + “ ”); return result.toString(); 3637 asciiStatement和h
27、tmlStatement具有类似的基础结构，但是它们的实际步骤却有所不同。他们都完成三件事情： 1 打印发票头 2 循环每一个项目，并打印 3 打印发票尾部 这种结构的相似性和意图马上上我们使用composed method(也就是Martin Fowler的(Extract method): interface Printer String header(Invoice iv); String item(LineItem line); String footer(Invoice iv); static class AsciiPrinter implements Printer public
28、String header(Invoice iv) return “Bill for “ + iv.customer + “n”; public String item(LineItem line) return “t” + line.product()+ “tt” + line.amount() +“n”; public String footer(Invoice iv) return “total owed:” + iv.total + “n”; 3738象html则可以实现htmlPrinter. class Invoice. public String statement(Printe
29、r pr) StringBuffer result = new StringBuffer(); result.append(pr.header(this); Iterator it = items.iterator(); while(it.hasNext() LineItem each = (LineItem) it.next(); result.append(pr.item(each); result.append(pr.footer(this); return result.toString(); class Invoice. public String asciiStatement2()
30、 return statement (new AsciiPrinter(); 3839实践总结实践总结OO与CMM2.0的结合是基于CMM以文档作为软件分析设计交付件的方式，在此前提下，已能够满足采用OO方法的软件开发项目的需要；需求规格和软件设计的文档模板已融入了UML的主要设计元素（Business Model的内容除外）；而UML的设计内容都是可以文档化的，这为模板的不断完善提供了基础；有一套完整的文档范例供开发人员参考；对一些典型的设计问题和项目运作特点相关的问题也有经过专家评审的解决方案；培训材料、指导书经过了优化，增加了不少实例；今后在设计案例方面还可以不断地丰富。3940展望展望 经过一年来的OO软件工程推行实践，我们觉得，无论是面向对象技术还是其他的软件开发技术，在与CMM流程结合的过程中，必然经过不断地优化和改进。当前流程方法存在的缺点：(1) 文档与代码之间的一致性问题；(2) Rose之类的建模工具得到广泛采用，开发人员倾向于用工具来维护模型，那么工具所维护的模型与文档之间也存在一致性问题。趋势：大型软件开发平台集成UML， 支持从分析、设计到编码、测试全套过程，对企业已定义的开发流程的影响？趋势：软件开发活动正在向基于模型设计和代码自动生成的方向发展，对开发流程的影响？4041 41
