新软件建模技术幻灯片.ppt
《新软件建模技术幻灯片.ppt》由会员分享,可在线阅读,更多相关《新软件建模技术幻灯片.ppt(75页珍藏版)》请在淘文阁 - 分享文档赚钱的网站上搜索。
1、新软件建模技术第1页,共75页,编辑于2022年,星期六1.1UML和对象思想和对象思想UML是标准的图形化表示法,并不是OOA/D,没有掌握如何创建优秀的面向对象设计,或者如何评估和改进现有设计,那么学习UML或者UML CASE工具是毫无意义的。对象思想才是重点和难点。第2页,共75页,编辑于2022年,星期六1.2OOD的原则和模式的原则和模式系统设计中的关键问题:应该如何为对象分配职责(Responsibility)?对象之间应该如何协作?什么样的类应该做什么样的事?模式:某些针对设计问题的,经过反复验证的解决方案可以(和已经)被表示为最佳时间的原则、起始或模式(pattern),即问
2、题-解决方案公式,这些公式是系统化的、典范的设计原则。第3页,共75页,编辑于2022年,星期六1.3用例用例OOD(以及所有软件设计)与作为其先决活动的需求分析(requirements analysis)具有紧密联系,而在需求分析中通常包含用例的编写。第4页,共75页,编辑于2022年,星期六1.4什么是分析和设计什么是分析和设计分析(analysis)强调的是对问题和需求的调查和研究,而不是解决方案。需求分析:对需求的调查研究。面向对象分析:对领域对象的调查研究。设计(design):强调的是满足需求的概念(逻辑)上的解决方案(在软件和硬件方面),而不是实现。例如,对数据库方案和软件对象
3、的描述。设计细想通常排斥底层或“显而易见”的细节。最终,设计可以实现,而实现(入如代码)则表达了真实而完整的设计。第5页,共75页,编辑于2022年,星期六1.5什么是面向对象分析和设计什么是面向对象分析和设计在面向对象分析过程中,强调的是在问题领域内发现和描述对象(或概念)。例如,在航班信息系统中包含飞机、航班、和飞行员在面向对象设计过程中,强调的是定义软件对象以及如何写作以实现需求。例如,软件对象Plane可以有tailNumber属性和getFlightHistory方法。最后,在实现或面向对象程序设计过程中,会实现设计出来的对象,入Java中的Plane类。第6页,共75页,编辑于20
4、22年,星期六第7页,共75页,编辑于2022年,星期六1.5面向对象的分析与设计例子 一个简单的例子“掷骰子游戏”(dice game),在这个游戏中游戏者掷出两个骰子。如果总点数为7就赢了,否则就输了。第8页,共75页,编辑于2022年,星期六1.5.1定义用例定义用例需求分析可能包括人们如何使用应用的情节或场景,这些情节或场景可以被编写为用例(Use Case)。用例不是面向对象制品,而只是对情节的记录。但用例是需求分析中的一种常用工具。骰子游戏:第9页,共75页,编辑于2022年,星期六1.5.2定义领域模型 面向对象分析关注从对象的角度创建领域描述,需要鉴别重要的概念、属性和关联。结
5、果可以表示为领域模型(domain model)(展示重要的领域概念或对象)。领域模型不是对软件对象的描述,而是真是世界领域中的概念和想象的可视化。因此也被称为概念对象模型(conceptual object model)。第10页,共75页,编辑于2022年,星期六第11页,共75页,编辑于2022年,星期六1.5.3分配对象职责并绘制交互图 第12页,共75页,编辑于2022年,星期六第13页,共75页,编辑于2022年,星期六1.5.4定义设计类图定义设计类图第14页,共75页,编辑于2022年,星期六2.迭代、进化和敏捷 迭代开发是OOA/D成为最佳实践的核心。敏捷实践是有效应用UML
6、的关键。UP是相对流行的、示范性的迭代方法。相对于顺序或“瀑布”(waterfall)生命周期,迭代和进化式开发对部分系统及早地引入了编程和测试,并重复这一循环。这种方式通常会在还没有详细定义所有需求的情况下开始开发,同时使用反馈来明确和改进演化中的规格说明。依赖于短时快速的开发步骤、反馈和改写来不断明确需求和设计。第15页,共75页,编辑于2022年,星期六2.1UP 软件开发过程:描述了构造、部署以及维护软件的方式。统一过程已经成为一中流行的构造面向对象系统的迭代软件开发过程。UP把普遍认可的最佳实践结合起来,成为联系紧密并具有良好文档的过程描述。第16页,共75页,编辑于2022年,星期
7、六2.2迭代和进化式开发 迭代开发(iterative development)是UP和大多数其他现代方法中的关键实践。在这种生命周期法中,开发被组织成一系列国定的短期小项目,称为迭代(iteration);每次迭代都产生经过测试、集成并可执行的局部系统。每次迭代都具有各自的需求分析、设计、实现和测试活动。迭代生命周期基于对经过多次迭代的系统进行持续扩展和精化,并以循环反馈和调整为核心驱动力,使之最终成为适当的系统。随着时间和一次又一次迭代的递进,系统增量式地发展完善,因此这一方法也被称为迭代增量式开发。因为反馈和调整使规格说明和设计不断进化,所以这种方法也被称为迭代和进化式开发。第17页,共
8、75页,编辑于2022年,星期六2.3为什么要使用迭代开发 减少项目失败的可能性,提高生产率,降低缺陷率。在早期缓解高风险早期可见的进展早期反馈、用户参与和调整,会产生更接近涉众真是需求的精化系统。可控复杂性:团队不会被“分析瘫痪”或长期且复杂的步骤所淹没。一次迭代中的经验可以被系统地用于改进开发过程本身,并如此反复进行下去。第18页,共75页,编辑于2022年,星期六2.4一次迭代持续的时间一次迭代持续的时间在每个开发周期中有一个实用的策略,那就是为这个开发周期加上一个“时间盒”即一段固定的时间。在这个开发周期中所有的工作都应在这个时间内完成。一般来说,两周到两个月是比较合适的时间盒值,如果
9、时间再短一点,将很难完成任务;如果时间再长一些,一个开发周期中遇到的各种问题的复杂性将难以处理,并且得到反馈信息的时间将拖后。要成功实施“时间盒”调度,必须仔细选择所要处理的需求,并确保开发小组对所做出的选择负责。第19页,共75页,编辑于2022年,星期六2.5瀑布生命周期瀑布生命周期在瀑布(或顺序)生命周期中,试图在编程之前(详细)定义所有或大部分需求。而通常于编程之前创建出完整的设计(或模型集)。同样,试图在开始前定义“可控的”计划或时间表。但常常是“事与愿违”第20页,共75页,编辑于2022年,星期六2.6如何进行迭代和进化式分析和设计如何进行迭代和进化式分析和设计在第1次迭代之前,
10、召开第一个时间定量需求工作会议。在第1次迭代之前,召开迭代计划会议,(选择用例(或子集),在特定的时间内完成)。在3-4周内完成第1次迭代。在第1次迭代即将结束是,召开第2次需求工作会议,对上一次会议的所有材料进行复杂和精化。于周五上午,举行下一迭代计划会议。以相同步骤进行第2次迭代。反复进行4次迭代和5次需求工作会,这样在第4次迭代结束时,可能已经详细记录了约80-90%的需求,但只实现了系统的10%。带该推进了整个项目的20%。在UP术语中,这是细化阶段(elaboration phase)的结束。此后,一般不需要再召开需求工作会议;需求已经稳定了,接下来是一系列为期3周的迭代,在最有一个
11、周五召开的迭代计划会议上选择适宜的下一步工作,每次迭代都要反复询问:“就我么现在所知,下一个3周应该完成的、最关键的技术和业务特性是什么”第21页,共75页,编辑于2022年,星期六2.7UP的其他关键实践的其他关键实践在早期的迭代中解决高风险和高价值的问题不断让用户参与评估、反馈和需求在早期迭代中建立内聚的核心架构不断验证质量:提早、经常和实际的测试进行一些可视化建模认真管理需求实行变更请求和配置管理第22页,共75页,编辑于2022年,星期六2.8UP阶段阶段初始(Inception):大体上的构想、业务案例、范围和模糊评估。细化(Elaboration):已精化的构想、核心架构的迭代实现
12、、高风险的解决、确定大多数的需求以及进行更为实际的评估。构造(Construction):对遗留下来的风险较低和比较简单的元素进行迭代实现,准备部署。移交(Transition):进行beta测试和部署。第23页,共75页,编辑于2022年,星期六第二部分 第24页,共75页,编辑于2022年,星期六1.初始阶段初始阶段初始阶段是建立项目共同设想和基本范围的比较简短的起始步骤。为了在随后的细化阶段哪能够开始编程,它将包括对10%的用例进行分析、关键的非功能需求的分析、业务案例创建和开发环境的准备。在该阶段考虑以下几类问题:项目的设想和业务案例是什么?是否可行?购买还是开发?初略估算一下成本项目
13、应该继续下去还是停止?第25页,共75页,编辑于2022年,星期六2.进化式需求进化式需求第26页,共75页,编辑于2022年,星期六2.1定义需求定义需求需求(requirement)就是系统(更广义的说法是项目)必须提供的能力和必须遵从的条件。在变更不可避免,涉众意愿不明朗的情况下,UP更推崇“一种系统的方法来寻找、记录、组织和跟踪系统不断变更的需求”。通过迭代巧妙地进行需求分析,而非草率和随意为之。需求分析最大的挑战是寻找、沟通和记住什么是真正的需求,并能够清楚地讲解给客户和开发团队。第27页,共75页,编辑于2022年,星期六2.2进化式需求与瀑布式需求进化式需求与瀑布式需求第28页,
14、共75页,编辑于2022年,星期六2.3寻找需求可以采用的方法 与客户一同编写用例开发者与客户共同参加需求讨论会请客户代理参加焦点小组向客户演示每次迭代的成果以及求得反馈。第29页,共75页,编辑于2022年,星期六2.4需求的类型和种类 需求按照“FURPS+”模型进行分类:功能性(Functional):特性、功能、安全性可用性(Usability):人性化因素、帮助、文档性能(Performance):响应时间、吞吐量、准确性、有效性、资源利用率。可支持性(Supportability):适应性、可维护性、国际化、可配置性。第30页,共75页,编辑于2022年,星期六2.4需求的类型和种
15、类(续)“+”是指一些辅助性的和次要的因素:实现(Implementation):资源限制、语言和工具、硬件等。接口(Interface):强加于外部系统接口之上的约束。操作(Operation):对其操作设置的系统管理。包装(Packaging):授权(Legal):许可证或其他方式。在进行架构分析的时候,质量属性对系统架构具有极大影响。功能性需求和非功能性需求第31页,共75页,编辑于2022年,星期六2.5UP制品如何组织需求 用例模型:一组使用系统的典型场景。主要用于功能(行为)需求补充性规格说明:用例之外的所有内容。词汇表:重要的术语。设想:概括了高阶需求,这些需求在用例模型和补充性
16、规格说明中进行细化。也概括了项目的业务案例。帮助快速了解项目的主要思想。业务规则:描述凌驾于某一软件项目的需求或政策。第32页,共75页,编辑于2022年,星期六3用例 用例是文本形式的情节描述,用以说明某参与者使用系统以实现某些目标。广泛应用于需求的发现和记录中。不是图形,而是文本。通过编写使用系统实现用户目标的情节来发现和记录功能性需求,也就是使用的案例。第33页,共75页,编辑于2022年,星期六3.1定义:参与者、场景和用例 参与者(actor)是某些具有行为的事物,可以是人(由角色标识)、计算机系统或组织。场景(scenario)是参与者和系统之间的一系列特定的活动和交互,也称用例实
17、例(Use case instance)。是使用系统的一个特定情节或用例的一条执行路径。用例(Use case)就是一组相关的成功和失败场景的集合,用来描述参与者如何使用系统来实现其目标。第34页,共75页,编辑于2022年,星期六3.2用例和用例模型用例和用例模型用例模型是所有书面用例的集合,是系统功能性和环境的模型。用例是文本文档,而非图形;用例建模主要是编写文本的活动,而非制图。用例模型可以包含UML的用例图,以显示用例和参与者的名称及其关系。UML用例图可以为系统及其环境提供良好的语境图(context diagram:显示了领域内的广义应用(或者是目标系统)和与之通信的其他实体或抽象
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 建模 技术 幻灯片
限制150内